* OMAP baseline test results for v3.7-rc3
From: Mark Jackson @ 2012-11-06 9:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <79CD15C6BA57404B839C016229A409A83EB63609@DBDE01.ent.ti.com>
On 06/11/12 06:16, Hiremath, Vaibhav wrote:
>
> Where is your DTB? Is it appended to Kernel image?
> Can you try below sequence/commands from u-boot?
>
>
> mmc rescan 0
> fatload mmc 0 80000000 am335x-bone.dtb
> fatload mmc 0 81000000 uImage
> setenv bootargs console=ttyO0,115200n8 mem=256M root=/dev/mmcblk0p2 rw noinitrd rootfstype=ext3 rootwait earlyprink=serial
> sendln 'bootm 81000000 - 80000000'
>
>
>
> To build DTB files, use "make dtbs" command on your kernel home directory.
That works ... great !!
But now I'm confused, since I thought the DTB was appended to the uImage file.
I have the following in my .config:-
ARM_ATAG_DTB_COMPAT=y
ARM_APPENDED_DTB=y
ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER=y
And then I create my uImage file using:-
$ make -j 8 ARCH=arm CROSS_COMPILE=arm-linux- uImage
$ make -j 8 ARCH=arm CROSS_COMPILE=arm-linux- am335x-bone.dtb
$ cat arch/arm/boot/uImage arch/arm/boot/am335x-bone.dtb > arch/arm/boot/uImage-dtb.am335x-bone
$ cp arch/arm/boot/uImage-dtb.am335x-bone /media/boot/uImage
Do you now have to load the DTB as a separate file ?
Or should the appended DTB still work ?
Cheers
Mark J.
^ permalink raw reply
* [PATCH v3 06/11] clk: davinci - add build infrastructure for DaVinci clock drivers
From: Sekhar Nori @ 2012-11-06 9:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5097E6A1.2030804@ti.com>
On 11/5/2012 9:47 PM, Murali Karicheri wrote:
> On 11/04/2012 08:34 AM, Sekhar Nori wrote:
>> On 10/25/2012 9:41 PM, Murali Karicheri wrote:
>>> This updates clk Makefile and Kconfig to integrate the DaVinci specific
>>> clock drivers. Also add new Kconfig and Makefile for these drivers.
>>>
>>> Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
>> As mentioned before, this should be folded into previous patches which
>> actually add the particular functionality.
> Yes. Agreed.,
>>> ---
>>> drivers/clk/Kconfig | 2 ++
>>> drivers/clk/Makefile | 1 +
>>> drivers/clk/davinci/Kconfig | 44
>>> ++++++++++++++++++++++++++++++++++++++++++
>>> drivers/clk/davinci/Makefile | 5 +++++
>>> 4 files changed, 52 insertions(+)
>>> create mode 100644 drivers/clk/davinci/Kconfig
>>> create mode 100644 drivers/clk/davinci/Makefile
>>>
>>> diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
>>> index 7f0b5ca..1ad2ab0 100644
>>> --- a/drivers/clk/Kconfig
>>> +++ b/drivers/clk/Kconfig
>>> @@ -33,6 +33,8 @@ config COMMON_CLK_DEBUG
>>> clk_flags, clk_prepare_count, clk_enable_count &
>>> clk_notifier_count.
>>> +source "drivers/clk/davinci/Kconfig"
>>> +
>>> config COMMON_CLK_WM831X
>>> tristate "Clock driver for WM831x/2x PMICs"
>>> depends on MFD_WM831X
>>> diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
>>> index 5869ea3..b127b6f 100644
>>> --- a/drivers/clk/Makefile
>>> +++ b/drivers/clk/Makefile
>>> @@ -10,6 +10,7 @@ obj-$(CONFIG_ARCH_SOCFPGA) += socfpga/
>>> obj-$(CONFIG_PLAT_SPEAR) += spear/
>>> obj-$(CONFIG_ARCH_U300) += clk-u300.o
>>> obj-$(CONFIG_ARCH_INTEGRATOR) += versatile/
>>> +obj-$(CONFIG_DAVINCI_CLKS) += davinci/
>>> # Chip specific
>>> obj-$(CONFIG_COMMON_CLK_WM831X) += clk-wm831x.o
>>> diff --git a/drivers/clk/davinci/Kconfig b/drivers/clk/davinci/Kconfig
>>> new file mode 100644
>>> index 0000000..e53bbc3
>>> --- /dev/null
>>> +++ b/drivers/clk/davinci/Kconfig
>>> @@ -0,0 +1,44 @@
>>> +menu "TI DaVinci Clock drivers"
>>> + depends on COMMON_CLK
>>> +
>>> +config CLK_DAVINCI_PSC
>>> + bool "TI DaVici PSC clock driver"
>>> + default n
>>> + ---help---
>>> + Selects clock driver for DaVinci PSC clocks. This clock
>>> + hardware is found on TI DaVinci SoCs and other SoCs that
>>> + uses this hardware IP. This hardware has a local power
>>> + sleep control module that gate the clock to the IP.
>>> +
>>> +config CLK_DAVINCI_PLL
>>> + bool "DaVici main PLL clock"
>>> + ---help---
>>> + Selects clock driver for DaVinci main PLL. This clock
>>> + hardware is found on TI DaVinci SoCs. This typically has
>>> + a multiplier, a pre divider and post driver. Some of the
>>> + SoCs has the the dividers fixed, and others have it
>>> + programmable
>>> +
>>> +config CLK_DAVINCI_PLLDIV
>>> + bool "DaVici PLL divider clock"
>>> + ---help---
>>> + Selects clock driver for DaVinci PLL divider. This clock
>>> + hardware is found on TI DaVinci SoCs. This typically has
>>> + a divider and an enable bit to bypass or enable the
>>> + divider.
>>> +
>>> +config DAVINCI_CLKS
>>> + bool "TI DaVinci common clocks"
>>> + default n
>>> + select CLK_DAVINCI_PSC
>>> + select CLK_DAVINCI_PLLDIV
>>> + ---help---
>>> + Selects common clock drivers for DaVinci. These clocks
>>> + are re-used across many TI SoCs that are based on DaVinci and
>>> + Keystone (c6x) families. This config option is used to select
>>> + the common clock driver for DaVinci based SoCs. SoCs specific
>>> + Kconfig option needs to select the driver for clocks specific
>>> + to the SoC.
>>> +
>>> +endmenu
>> I wonder if all these configurations are really required. For complete
>> clock functionality you anyway require all this functionality so I
>> wonder why anyone would not select any of these. And to differentiate
>> between architecture changes, conditional build based on architecture
>> can be used:
> I know this is a grey area I need to improve and had a discussion with
> Mike sometime back. Are you also suggesting including davinci folder
> unconditionally under drivers/clk/Makefile? I think it will work. And
> then in clk/davinci/Makefile we can include on a per architecture basis.
> But I am not sure if calling the folder as davinci make sense and these
> drivers are used on non DaVinci architectures as well. I had initially
> named it as "ti" to include all ti drivers. But Mike had commented that
> current directory structure use platform/arch name instead of vendor
> name. Also OMAP is going to move the clk drivers to this folder soon. So
> for now, davinci may be used to house all of the non OMAP drivers. Later
> we can re-visit this as needed (wouldn't be that hard to do this within
> the clk driver folder later). We can keep the davinci folder name and
> unconditionally include it in clk/Makefile.
>
> clk/Makefile
>
> add
> obj-y += davinci/
I am not sure about this unconditional inclusion. Are you sure the
following will create problems when DaVinci and keystone are enabled
together?
obj-$(CONFIG_ARCH_DAVINCI) += davinci/
obj-$(CONFIG_ARCH_KEYSTONE) += davinci/
>
> clk/davinci/Makefile
>
> obj-$(CONFIG_ARCH_DAVINCI) += clk-pll.o clk-div.o clk-psc.o clock.o
> obj-$(CONFIG_ARCH_KEYSTONE) += clk-pll-keystone.o clk-div.o clk-psc.o
> clock.o
Rather
obj-y := clk-div.o clk-psc.o clock.o
obj-$(CONFIG_ARCH_DAVINCI) += clk-pll.o
obj-$(CONFIG_ARCH_KEYSTONE) += clk-pll-keystone.o
Thanks,
Sekhar
^ permalink raw reply
* [PATCH] i2c: omap: Move the remove constraint
From: Shubhrajyoti D @ 2012-11-06 9:54 UTC (permalink / raw)
To: linux-arm-kernel
Currently we just queue the transfer and release the
qos constraints, however we donot wait for the transfer
to complete to release the constraint. Move the remove
constraint after the bus busy as we are sure that the
transfers are completed by then.
Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com>
---
drivers/i2c/busses/i2c-omap.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 94ff685..8b079d7 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -655,13 +655,13 @@ omap_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg msgs[], int num)
break;
}
- if (dev->latency)
- pm_qos_remove_request(&dev->pm_qos_request);
-
if (r == 0)
r = num;
omap_i2c_wait_for_bb(dev);
+
+ if (dev->latency)
+ pm_qos_remove_request(&dev->pm_qos_request);
out:
pm_runtime_mark_last_busy(dev->dev);
pm_runtime_put_autosuspend(dev->dev);
--
1.7.5.4
^ permalink raw reply related
* [PATCH v3 07/11] ARM: davinci - restructure header files for common clock migration
From: Sekhar Nori @ 2012-11-06 10:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50980F57.1090507@ti.com>
On 11/6/2012 12:41 AM, Murali Karicheri wrote:
> On 11/04/2012 09:05 AM, Sekhar Nori wrote:
>>
>> On 10/25/2012 9:41 PM, Murali Karicheri wrote:
>>> pll.h is added to migrate some of the PLL controller defines for
>>> sleep.S.
>>> psc.h is modified to keep only PSC modules definitions needed by sleep.S
>>> after migrating to common clock. The definitions under
>>> ifdef CONFIG_COMMON_CLK will be removed in a subsequent patch.
>>> davinci_watchdog_reset prototype is moved to time.h as clock.h is
>>> being obsoleted. sleep.S and pm.c is modified to include the new header
>>> file replacements.
>>>
>>> Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
>>> ---
>>> arch/arm/mach-davinci/devices.c | 2 ++
>>> arch/arm/mach-davinci/include/mach/pll.h | 46
>>> +++++++++++++++++++++++++++++
>>> arch/arm/mach-davinci/include/mach/psc.h | 4 +++
>>> arch/arm/mach-davinci/include/mach/time.h | 4 ++-
>>> arch/arm/mach-davinci/pm.c | 4 +++
>>> arch/arm/mach-davinci/sleep.S | 4 +++
>>> 6 files changed, 63 insertions(+), 1 deletion(-)
>>> create mode 100644 arch/arm/mach-davinci/include/mach/pll.h
>> With this patch a _third_ copy of PLL definitions is created in kernel
>> sources. The existing PLL definitions in clock.h inside mach-davinci
>> should be moved to mach/pll.h and the pll.h you introduced inside
>> drivers/clk in 5/11 should be removed (this patch should appear before
>> 5/11).
>>
>> The biggest disadvantage of this approach is inclusion of mach/ includes
>> in drivers/clk. But duplicating code is definitely not the fix for this.
>> Anyway, mach/ includes are not uncommon in drivers/clk (they are all
>> probably suffering from the same issue).
> Sekhar,
>
> I have replied to patch 5/11 that also refers to this. The main reason
> we are not able to do this cleanly is the code in sleep.c and pm.c. That
> is something related to Power management. Could you take a look and see
> if you can do some clean up on this code? I believe It is more than just
> moving the header files.
I am not sure what more is required than moving header files? Can you
elaborate?
>
> Murali
>>
>> $ grep -rl "include <mach/" drivers/clk/*
>> drivers/clk/clk-u300.c
>> drivers/clk/mmp/clk-pxa168.c
>> drivers/clk/mmp/clk-mmp2.c
>> drivers/clk/mmp/clk-pxa910.c
>> drivers/clk/mxs/clk-imx23.c
>> drivers/clk/mxs/clk-imx28.c
>> drivers/clk/spear/spear6xx_clock.c
>> drivers/clk/spear/spear3xx_clock.c
>> drivers/clk/spear/spear1340_clock.c
>> drivers/clk/spear/spear1310_clock.c
>> drivers/clk/ux500/clk-prcc.c
>> drivers/clk/versatile/clk-integrator.c
>> drivers/clk/versatile/clk-realview.c
>>
>> pll.h can probably be moved to include/linux/clk/ to avoid this. Would
>> like to hear from Mike on this before going ahead.
>>
>> Anyway, instead of just commenting, I though I will be more useful and
>> went ahead and made some of the changes I have been talking about. I
>> fixed the multiple PLL definitions issue, the build infrastructure issue
>> and the commit ordering too.
>>
>> I pushed the patches I fixed to devel-common-clk branch of my git tree.
>> It is build tested using davinci_all_defconfig but its not runtime
>> tested.
>>
>> Can you start from here and provide me incremental changes on top of
>> this? That way we can collaborate to finish this faster.
> Thanks for offering some help. Yes I can provide you incremental patch.
> But then could you also help me to squash/rebase and send patches to the
> list for review?
No, no. I want you to own the submissions. Towards this, if it is easier
for you to build upon my work in your own tree, by all means, go ahead
and do it. Just share the branch/tree details so I can take a look and
contribute as well.
Thanks,
Sekhar
^ permalink raw reply
* OMAP baseline test results for v3.7-rc1
From: Shubhrajyoti Datta @ 2012-11-06 10:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87fw4neh0i.fsf@deeprootsystems.com>
On Tue, Nov 6, 2012 at 5:31 AM, Kevin Hilman
<khilman@deeprootsystems.com> wrote:
> Jean Pihet <jean.pihet@newoldbits.com> writes:
>
> [...]
>
>> I ran some intensive stress tests on the I2C and ... unfortunately I
>> could not trigger the problem. It looks like the issue is caused by
>> some transient situation where the CORE and/or I2C is in a low power
>> state.
>
> FYI... I just ran across what appears to be the same bug on 3430/n900
> during suspend/resume testing. With CPUidle enabled, this happens every
> time.
>
> Reverting the I2C QoS patch makes it work again.
I think we should defer the release of the constraints
Does this help
http://www.mail-archive.com/linux-omap at vger.kernel.org/msg79841.html
^ permalink raw reply
* [PATCH 3/7] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio module
From: Bedia, Vaibhav @ 2012-11-06 10:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352189545-26303-4-git-send-email-mugunthanvnm@ti.com>
On Tue, Nov 06, 2012 at 13:42:21, N, Mugunthan V wrote:
[...]
> +struct omap_hwmod_addr_space am33xx_mdio_addr_space[] = {
> + {
> + .pa_start = 0x4A101000,
> + .pa_end = 0x4A101000 + SZ_256 - 1,
> + .flags = ADDR_MAP_ON_INIT,
Based on the recent discussions and looking the hwmod code,
I guess ADDR_MAP_ON_INIT does not make sense here. Since you
are just creating a parent-child relationship here, maybe no
flag is needed?
> + },
> + { }
> +};
> +
> +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,
Is this flag necessary? Shouldn't you just skip the
user field since there's nothing for the hwmod code
to do here?
Regards,
Vaibhav
^ permalink raw reply
* [PATCH 3/8] ARM: OMAP: AM33xx hwmod: Add parent-child relationship for PWM subsystem
From: Bedia, Vaibhav @ 2012-11-06 10:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352106749-9437-4-git-send-email-avinashphilip@ti.com>
On Mon, Nov 05, 2012 at 14:42:24, Philip, Avinash wrote:
[...]
> +
> +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,
> +};
Noticed this in another patch which is quite similar so commenting here
again. Is the user field required if you are just creating a parent-child
relationship here?
Regards,
Vaibhav
^ permalink raw reply
* [PATCH 08/15] ARM: OMAP2+: hwmod: Fix the omap_hwmod_addr_space for CPGMAC0
From: Bedia, Vaibhav @ 2012-11-06 10:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5098D889.60909@ti.com>
On Tue, Nov 06, 2012 at 14:59:45, Hiremath, Vaibhav wrote:
[...]
> >
> > Ok I checked this one. The change I made was indirectly fixing another
> > issue with the AM33xx hwmod data. am33xx_cpgmac0_addr_space[] has two
> > entries and the SYSC register is part of the second entry. The function
> > _find_mpu_rt_addr_space in omap_hwmod.c looks for the first entry with
> > the flag ADDR_TYPE_RT flag. The change I made indirectly made the second
> > entry in am33xx_cpgmac0_addr_space[] become the first memory space with
> > the ADDR_TYPE_RT flag. Due to this the hwmod code wrote to the correct
> > SYSC address of CPGMAC0 and the IP went to standby during bootup.
> > After changing the order of the entries in am33xx_cpgmac0_addr_space[]
> > things work fine.
> >
>
> Good catch.
>
> Just a side note on this, driver expects the addresses in this order
> only, first SS and then WR.
>
Sorry I didn't understand your comment. For HWMOD code to work as expected,
we need to change the order. Are you saying that I should not be doing this
because the driver will get affected?
Regards,
Vaibhav
^ permalink raw reply
* scheduler clock for MXS [Was: Re: Wakeup latency measured with SCHED_TRACER depends on HZ]
From: Russell King - ARM Linux @ 2012-11-06 10:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121106024052.GA27643@S2100-06.ap.freescale.net>
On Tue, Nov 06, 2012 at 10:40:54AM +0800, Shawn Guo wrote:
> Here is the boot log on my imx23 board after applying both Stanislav's
> and Katsuki's patches.
>
> [ 0.000000] Booting Linux on physical CPU 0
> [ 0.000000] Linux version 3.7.0-rc1-00012-ga31941d (r65073 at S2101-09) (gcc ver
> sion 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #756 Tue Nov 6 10:04:30 CST 2012
> [ 0.000000] CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177
> [ 0.000000] CPU: VIVT data cache, VIVT instruction cache
> [ 0.000000] Machine: Freescale i.MX23 (Device Tree), model: Freescale i.MX23
> Evaluation Kit
> [ 0.000000] Memory policy: ECC disabled, Data cache writeback
> [ 0.000000] On node 0 totalpages: 32768
> [ 0.000000] free_area_init_node: node 0, pgdat c051ada8, node_mem_map c0a7000
> 0
> [ 0.000000] Normal zone: 256 pages used for memmap
> [ 0.000000] Normal zone: 0 pages reserved
> [ 0.000000] Normal zone: 32512 pages, LIFO batch:7
> [ 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 pag
> es: 32512
> [ 0.000000] Kernel command line: console=ttyAMA0,115200 debug earlyprintk roo
> t=/dev/mmcblk0p3 rw rootwait no_console_suspend
> [ 0.000000] PID hash table entries: 512 (order: -1, 2048 bytes)
> [ 0.000000] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
> [ 0.000000] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
> [ 0.000000] Memory: 128MB = 128MB total
> [ 0.000000] Memory: 119200k/119200k available, 11872k 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 : 0xc8800000 - 0xff000000 ( 872 MB)
> [ 0.000000] lowmem : 0xc0000000 - 0xc8000000 ( 128 MB)
> [ 0.000000] modules : 0xbf000000 - 0xc0000000 ( 16 MB)
> [ 0.000000] .text : 0xc0008000 - 0xc04bf150 (4829 kB)
> [ 0.000000] .init : 0xc04c0000 - 0xc04e29cc ( 139 kB)
> [ 0.000000] .data : 0xc04e4000 - 0xc051d5c0 ( 230 kB)
> [ 0.000000] .bss : 0xc051d5e4 - 0xc0a6ce38 (5439 kB)
> [ 0.000000] SLUB: Genslabs=13, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, N
> odes=1
> [ 0.000000] NR_IRQS:16 nr_irqs:16 16
> [ 0.000000] of_irq_init: children remain, but no parents
> [ 0.000000] sched_clock: 16 bits at 32kHz, resolution 31250ns, wraps every 20
> 47ms
So where are you setting this up? My guess is it's after time_init()
has done its stuff.
^ permalink raw reply
* [PATCH v3 05/11] clk: davinci - add dm644x clock initialization
From: Sekhar Nori @ 2012-11-06 10:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5097DE82.2090701@ti.com>
On 11/5/2012 9:12 PM, Murali Karicheri wrote:
> On 11/03/2012 09:30 AM, Sekhar Nori wrote:
>> On 10/25/2012 9:41 PM, Murali Karicheri wrote:
>>> This patch adds dm644x clock initialization code that consists of
>>> clocks data for various clocks and clock register callouts to
>>> various clock drivers. It uses following clk drivers for this
>>>
>>> 1. clk-fixed-rate - for ref clock
>>> 2. clk-mux - for mux at the input and output of main pll
>>> 3. davinci specific clk-pll for main pll clock
>>> 4. davinci specific clk-div for pll divider clock
>>> 5. clk-fixed-factor for fixed factor clock such as auxclk
>>> 6. davinci specific clk-psc for psc clocks
>>>
>>> This patch also moves all of the PLL and PSC register definitions
>>> from clock.h and psc.h under davinci to the clk/davinci folder so
>>> that various soc specific clock initialization code can share these
>>> definitions.
>> Except this patch does not move the defines, it creates a copy of them
>> (which is bad since you quickly lose track of which is the correct
>> copy). Is this done to avoid including mach/ header files here?
> Yes.
>> It will
>> actually be better to include the mach/ files here as a temporary
>> solution and then remove the include mach/ files once all the SoCs have
>> been converted over.
>
> I was thinking we are not allowed to include mach/* header files in
> driver files. But most of the clk drivers
> such clk-imx28, spear6xx_clock.c. versatile/clk-integrator.c etc are
> including mach/ headers. One issue is that the definitions in pll.h are
> re-usable across other machines falling under c6x and Keystone (new
> device we are working on) as well. Where do we keep includes that can be
> re-used across different architectures? include/linux/platform_data/ ?
In this case, it is not really platform data or even an interface for
drivers to use, so I prefer include/linux/clk/davinci-pll.h
> I
> see clk-integrator.h, clk-nomadik.h and clk-u300 sitting there. So I
> suggest moving any header files that defines utility functions, register
> definitions across different architectures to
> include/linux/platform_data. Candidate files would be clock.h, pll.h,
> clk-psc.h, clk-pll.h and clk-div.h. This way these can be used across
It is not clear to me why you would move these files outside of
drivers/clk/davinci. They are not used by any other code outside of this
directory.
> the above machines that use the above architectures. Can we do this in
> my next version? This way we don't have to make another move later. All
> these CLK IPs are re-used across multiple architectures and make perfect
> sense to me to move to the above folder.
Thanks,
Sekhar
^ permalink raw reply
* OMAP baseline test results for v3.7-rc3
From: Hiremath, Vaibhav @ 2012-11-06 10:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1211050239530.23228@utopia.booyaka.com>
On Tue, Nov 06, 2012 at 11:39:18, Hiremath, Vaibhav wrote:
> On Mon, Nov 05, 2012 at 08:11:24, Paul Walmsley wrote:
> > Hi
> >
> > On Tue, 30 Oct 2012, Vaibhav Hiremath wrote:
> >
> > > This is surprising, I have tested v3.7-rc3 branch on AM335xBone platform
> > > and its booting up for me without any issues.
> > > Jon had submitted another patch which fixes boot issue on Bone.
> > >
> > > https://patchwork.kernel.org/patch/1606471/
> >
> > v3.7-rc4 failed for me with a detached .dtb in a quick test. Probably it
> > is due to the original u-boot that was shipped with the MMC card:
> >
>
> Pulling the tree, let me try now and update you shortly...
>
Just tried -rc4, and it boots up fine for me. I tested it with Mainline u-
boot and mainline Kernel, I have pasted log below for reference -
> > U-Boot 2011.09-00009-gcf6e04d (Mar 08 2012 - 17:15:43)
> > arm-arago-linux-gnueabi-gcc (GCC) 4.5.3 20110311 (prerelease)
> >
I do not suspect anything here, but still think we should use mainline
u-boot version. Can you share the images with me, so that I can try them?
====================Log=======================
U-Boot SPL 2013.01-rc1-00071-g1cc619b (Nov 06 2012 - 15:33:43)
OMAP SD/MMC: 0
reading u-boot.img
reading u-boot.img
U-Boot 2013.01-rc1-00071-g1cc619b (Nov 06 2012 - 15:33:43)
I2C: ready
DRAM: 256 MiB
WARNING: Caches not enabled
MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
Using default environment
Net: cpsw
Hit any key to stop autoboot: 0
U-Boot#
U-Boot#
U-Boot# mmc rescan 0
U-Boot# fatload mmc 0 80000000 am335x-bone.dtb
reading am335x-bone.dtb
4391 bytes read
U-Boot# fatload mmc 0 81000000 uImage
reading uImage
3842256 bytes read
U-Boot# fatload mmc 0 82000000 ramdisk-pm.gz
reading ramdisk-pm.gz
2022580 bytes read
U-Boot# setenv bootargs console=ttyO0,115200n8 mem=256M root=/dev/ram rw initrd=0x82000000,16MB ramdisk_size=65536 earlyprintk=serial
U-Boot# bootm 81000000 - 80000000
## Booting kernel from Legacy Image at 81000000 ...
Image Name: Linux-3.7.0-rc4
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 3842192 Bytes = 3.7 MiB
Load Address: 80008000
Entry Point: 80008000
Verifying Checksum ... OK
## Flattened Device Tree blob at 80000000
Booting using the fdt blob at 0x80000000
Loading Kernel Image ... OK
OK
Loading Device Tree to 8fe65000, end 8fe69126 ... OK
Starting kernel ...
[ 0.000000] Booting Linux on physical CPU 0
[ 0.000000] Linux version 3.7.0-rc4 (a0393758 at psplinux064) (gcc version 4.5.3 20110311 (prerelease) (GCC) ) #1 SMP Tue Nov 6 15:28:21 IST 2012
[ 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: TI AM335x BeagleBone
[ 0.000000] Memory policy: ECC disabled, Data cache writeback
[ 0.000000] AM335X ES1.0 (neon )
[ 0.000000] PERCPU: Embedded 9 pages/cpu @c0f03000 s12928 r8192 d15744 u36864
[ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 64768
[ 0.000000] Kernel command line: console=ttyO0,115200n8 mem=256M root=/dev/ram rw initrd=0x82000000,16MB ramdisk_size=65536 earlyprintk=serial
[ 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] Memory: 255MB = 255MB total
[ 0.000000] Memory: 229112k/229112k available, 33032k 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] modules : 0xbf000000 - 0xbfe00000 ( 14 MB)
[ 0.000000] .text : 0xc0008000 - 0xc06c4b94 (6899 kB)
[ 0.000000] .init : 0xc06c5000 - 0xc0715280 ( 321 kB)
[ 0.000000] .data : 0xc0716000 - 0xc07a13a0 ( 557 kB)
[ 0.000000] .bss : 0xc07a13c4 - 0xc0cfbd6c (5483 kB)
[ 0.000000] Hierarchical RCU implementation.
[ 0.000000] RCU restricting CPUs from NR_CPUS=2 to nr_cpu_ids=1.
[ 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 24000000 Hz
[ 0.000000] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 178956ms
[ 0.000000] OMAP clocksource: GPTIMER2 at 24000000 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.001135] Calibrating delay loop... 364.48 BogoMIPS (lpj=1425408)
[ 0.107571] pid_max: default: 32768 minimum: 301
[ 0.108255] Security Framework initialized
[ 0.108464] Mount-cache hash table entries: 512
[ 0.118582] CPU: Testing write buffer coherency: ok
[ 0.119703] CPU0: thread -1, cpu 0, socket -1, mpidr 0
[ 0.119790] Setting up static identity map for 0x804d61e0 - 0x804d6250
[ 0.122980] Brought up 1 CPUs
[ 0.123012] SMP: Total of 1 processors activated (364.48 BogoMIPS).
[ 0.147821] pinctrl core: initialized pinctrl subsystem
[ 0.156108] regulator-dummy: no parameters
[ 0.158717] NET: Registered protocol family 16
[ 0.159696] DMA: preallocated 256 KiB pool for atomic coherent allocations
[ 0.161182] omap-gpmc omap-gpmc: GPMC revision 6.0
[ 0.161403] omap-gpmc omap-gpmc: failed to reserve memory
[ 0.161501] omap-gpmc: probe of omap-gpmc failed with error -16
[ 0.190475] OMAP GPIO hardware version 0.1
[ 0.206060] No ATAGs?
[ 0.206089] hw-breakpoint: debug architecture 0x4 unsupported.
[ 0.293133] bio: create slab <bio-0> at 0
[ 0.400112] omap-dma-engine omap-dma-engine: OMAP DMA engine driver
[ 0.407996] SCSI subsystem initialized
[ 0.410955] usbcore: registered new interface driver usbfs
[ 0.411594] usbcore: registered new interface driver hub
[ 0.413229] usbcore: registered new device driver usb
[ 0.418391] omap_i2c 44e0b000.i2c: bus 0 rev2.4.0 at 400 kHz
[ 0.430593] Switching to clocksource gp_timer
[ 0.586714] NET: Registered protocol family 2
[ 0.589620] TCP established hash table entries: 8192 (order: 4, 65536 bytes)
[ 0.590148] TCP bind hash table entries: 8192 (order: 6, 294912 bytes)
[ 0.595587] TCP: Hash tables configured (established 8192 bind 8192)
[ 0.595897] TCP: reno registered
[ 0.595941] UDP hash table entries: 256 (order: 2, 20480 bytes)
[ 0.596311] UDP-Lite hash table entries: 256 (order: 2, 20480 bytes)
[ 0.597375] NET: Registered protocol family 1
[ 0.599070] RPC: Registered named UNIX socket transport module.
[ 0.599101] RPC: Registered udp transport module.
[ 0.599117] RPC: Registered tcp transport module.
[ 0.599133] RPC: Registered tcp NFSv4.1 backchannel transport module.
[ 0.600475] Trying to unpack rootfs image as initramfs...
[ 0.603605] rootfs image is not initramfs (no cpio magic); looks like an initrd
[ 0.746420] Freeing initrd memory: 16384K
[ 0.746624] NetWinder Floating Point Emulator V0.97 (double precision)
[ 0.747263] CPU PMU: probing PMU on CPU 0
[ 0.747496] hw perfevents: enabled with ARMv7 Cortex-A8 PMU driver, 5 counters available
[ 0.953802] VFS: Disk quotas dquot_6.5.2
[ 0.954099] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[ 0.957740] NFS: Registering the id_resolver key type
[ 0.958396] Key type id_resolver registered
[ 0.958425] Key type id_legacy registered
[ 0.958612] jffs2: version 2.2. (NAND) (SUMMARY) (c) 2001-2006 Red Hat, Inc.
[ 0.959333] msgmni has been set to 479
[ 0.964156] io scheduler noop registered
[ 0.964191] io scheduler deadline registered
[ 0.964331] io scheduler cfq registered (default)
[ 0.967982] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[ 0.975911] omap_uart 44e09000.serial: did not get pins for uart0 error: -19
[ 0.976583] 44e09000.serial: ttyO0 at MMIO 0x44e09000 (irq = 88) is a OMAP UART0
[ 1.579209] console [ttyO0] enabled
[ 1.622741] brd: module loaded
[ 1.651866] loop: module loaded
[ 1.661935] mtdoops: mtd device (mtddev=name/number) must be supplied
[ 1.670613] OneNAND driver initializing
[ 1.682234] usbcore: registered new interface driver asix
[ 1.688544] usbcore: registered new interface driver cdc_ether
[ 1.695670] usbcore: registered new interface driver smsc95xx
[ 1.702759] usbcore: registered new interface driver net1080
[ 1.709533] usbcore: registered new interface driver cdc_subset
[ 1.716526] usbcore: registered new interface driver zaurus
[ 1.723296] usbcore: registered new interface driver cdc_ncm
[ 1.732034] usbcore: registered new interface driver cdc_wdm
[ 1.738182] Initializing USB Mass Storage driver...
[ 1.744230] usbcore: registered new interface driver usb-storage
[ 1.750559] USB Mass Storage support registered.
[ 1.756198] usbcore: registered new interface driver usbtest
[ 1.764520] mousedev: PS/2 mouse device common for all mice
[ 1.775792] i2c /dev entries driver
[ 1.782078] Driver for 1-wire Dallas network protocol.
[ 1.792090] omap_wdt: OMAP Watchdog Timer Rev 0x01: initial timeout 60 sec
[ 1.805350] usbcore: registered new interface driver usbhid
[ 1.811484] usbhid: USB HID core driver
[ 1.817257] oprofile: using arm/armv7
[ 1.822333] TCP: cubic registered
[ 1.825843] Initializing XFRM netlink socket
[ 1.830589] NET: Registered protocol family 17
[ 1.835398] NET: Registered protocol family 15
[ 1.840638] Key type dns_resolver registered
[ 1.845380] VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 3
[ 1.853623] ThumbEE CPU extension supported.
[ 1.870806] clock: disabling unused clocks to save power
[ 1.884043] drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
[ 1.895403] RAMDISK: gzip image found at block 0
[ 2.375558] VFS: Mounted root (ext2 filesystem) on device 1:0.
[ 2.382761] Freeing init memory: 320K
mount: mounting none on /var/shm failed: No such file or directory
::
:: Enabling hot-plug : [SUCCESS]
::
::
: Populating /dev : [SUCCESS]
[SUCCESS]
::
::
:: Setting PATH
::
: syslogd : [SUCCESS]
: telnetd : [SUCCESS]
Please press Enter to activate this console.
^ permalink raw reply
* [PATCH 15/15] ARM: OMAP2+: AM33XX: Basic suspend resume support
From: Bedia, Vaibhav @ 2012-11-06 10:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87txt4aqyc.fsf@deeprootsystems.com>
Hi Kevin,
On Mon, Nov 05, 2012 at 23:10:27, Kevin Hilman wrote:
[...]
>
> First, some general comments. This is a big patch and probably should
> be broken up a bit. I suspect it could be broken up a bit, maybe into
> at least:
>
> - EMIF interface
> - SCM interface, new APIs
> - assembly/OCM code
> - pm33xx.[ch]
> - lastly, the late_init stuff that actually initizlizes
Ok, I'll try splitting the patches in the next version.
>
> I have a handful of comments below. I wrote this up on the plane over
> the weekend, and I see that Santosh has already made some similar
> comments, but I'll send mine anyways.
[...]
>
> Doing this on every suspend looks a bit strange. Why not just have some
> init function handle these devices once at boot. If this is really
> needed on every suspend, it needs some more description, and probably
> some basic stub drivers need to be created.
We do require it for every suspend (but more below). I'll add in more
description in the comment that's already there.
>
> Also, if there are drivers for these devices, won't this interfere?
>
Hmm, I can think of the following scenarios
1. Runtime PM adapted drivers are compiled in - We'll have to ensure that
in their suspend callbacks they end up doing omap_hwmod_idle() via the
runtime PM APIs. In this case the omap_hwmod_enable() followed by
omap_hwmod_idle() is not necessary in the PM code.
2. The drivers are not compiled in - In this case, the hwmod code puts
the IPs in standby during bootup so the first suspend-resume iteration
will pass. During resuming, the SYSC configuration for forced standby will
be lost, so in the subsequent iterations these IPs won't go standby and the
hwmod code does not touch them since they never got enabled. In this case
we do need the sequence that is there currently.
3. For some reason the respective drivers don't idle the IPs during suspend -
(no_idle_on_suspend flag for the hwmod in DT?). In this scenario I think
we should abort the suspend process since we know that the suspend is not
going to work.
Is there some other scenario that needs to be covered?
How about adding some flag in hwmod code for handling this? Something
similar to what was done for MMC [1]. I think the problem that we have
is in some ways similar to the one addressed in [1].
> > + /* Put the GFX clockdomains to sleep */
> > + clkdm_sleep(gfx_l3_clkdm);
> > + clkdm_sleep(gfx_l4ls_clkdm);
> > +
> > + /* Try to put GFX to sleep */
> > + pwrdm_set_next_pwrst(gfx_pwrdm, PWRDM_POWER_OFF);
>
> ditto.
I'll check if this can be removed.
>
> [...]
>
> > +static int am33xx_pm_begin(suspend_state_t state)
> > +{
> > + int ret = 0;
> > +
> > + disable_hlt();
> > +
> > + /*
> > + * Physical resume address to be used by ROM code
> > + */
> > + wkup_m3->resume_addr = (AM33XX_OCMC_END - am33xx_do_wfi_sz +
> > + am33xx_resume_offset + 0x4);
>
> Why does this need to be calculated every suspend/resume?
>
Will move this to init phase.
> > + wkup_m3->sleep_mode = IPC_CMD_DS0;
> > + wkup_m3->ipc_data1 = DS_IPC_DEFAULT;
> > + wkup_m3->ipc_data2 = DS_IPC_DEFAULT;
> > +
> > + am33xx_ipc_cmd();
>
> This IPC needs a cleaner interface/API. Also, since it involves
> register writes to the SCM, it should be defined in control.c. (NOTE:
> we're in the process of creating a real driver out of the SCM, so all
> SCM register accesses need to be contained in control.c)
>
> For example, you probably want an am33xx_m3_* API in control.c, with
> some pre-baked commands for the M3.
Ok. I'll work on this for the next version.
>
> > + wkup_m3->state = M3_STATE_MSG_FOR_LP;
> >
> > + omap_mbox_enable_irq(wkup_m3->mbox, IRQ_RX);
> > +
> > + ret = omap_mbox_msg_send(wkup_m3->mbox, 0xABCDABCD);
> > + if (ret) {
> > + pr_err("A8<->CM3 MSG for LP failed\n");
> > + am33xx_m3_state_machine_reset();
> > + ret = -1;
> > + }
> > +
> > + if (!wait_for_completion_timeout(&wkup_m3_sync,
> > + msecs_to_jiffies(500))) {
>
> hmm, interesting. I know you're not implementing idle here, but I'm
> rather curious how this sync w/M3 is going to work for idle.
>
Like you mentioned in another thread we could probably not have
a sync in the idle path. (More in the other thread).
> > + pr_err("A8<->CM3 sync failure\n");
> > + am33xx_m3_state_machine_reset();
> > + ret = -1;
> > + } else {
> > + pr_debug("Message sent for entering DeepSleep mode\n");
> > + omap_mbox_disable_irq(wkup_m3->mbox, IRQ_RX);
> > + }
> > +
> > + return ret;
> > +}
> > +
>
> [...]
>
> > +static void am33xx_m3_state_machine_reset(void)
> > +{
> > + int ret = 0;
> > +
> > + wkup_m3->resume_addr = 0x0;
> > + wkup_m3->sleep_mode = IPC_CMD_RESET;
> > + wkup_m3->ipc_data1 = DS_IPC_DEFAULT;
> > + wkup_m3->ipc_data2 = DS_IPC_DEFAULT;
> > +
> > + am33xx_ipc_cmd();
> > +
> > + wkup_m3->state = M3_STATE_MSG_FOR_RESET;
> > +
> > + ret = omap_mbox_msg_send(wkup_m3->mbox, 0xABCDABCD);
>
> magic constant needs a #define
Ok.
>
> > + if (!ret) {
> > + pr_debug("Message sent for resetting M3 state machine\n");
> > + 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
> > + */
> > +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,
> > +};
>
> Why do you need a dummy notifier? Looks like maybe plat-omap/mailbox.c
> needs a few minor fixes to support not being passed a notifier instead?
>
Ok. Will add checks in the mailbox code instead. (I wasn't too sure
about the mailbox users so I tried to take the path of least resistance :)
> > +static irqreturn_t wkup_m3_txev_handler(int irq, void *unused)
> > +{
> > + omap_ctrl_writel(0x1, AM33XX_CONTROL_M3_TXEV_EOI);
>
> undocumented magic write (but presumably an IRQ ack?)
>
Yes, it's for clearing the interrupt. Will add a comment
put a #def for this and other places that you mentioned.
> Note this also needs to be moved to control.c and given a useful API.
>
> > + 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;
> > + omap_mbox_msg_rx_flush(wkup_m3->mbox);
> > + complete(&wkup_m3_sync);
> > + break;
> > + case M3_STATE_MSG_FOR_LP:
> > + omap_mbox_msg_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);
> > + omap_mbox_msg_rx_flush(wkup_m3->mbox);
> > + return IRQ_NONE;
> > + }
> > +
> > + omap_ctrl_writel(0x0, AM33XX_CONTROL_M3_TXEV_EOI);
>
> undoumented magic write?
>
Will fix. This is for re-arming the interrupt line.
[...]
> > +
> > + mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > + if (!mem)
> > + dev_err(wkup_m3->dev, "no memory resource\n");
>
> if !mem, this continues and still tries to ioremap NULL.
>
Will fix the error path.
[...]
> > +
> > +/*
> > + * This a subset of registers defined in drivers/memory/emif.h
> > + * Move that to include/linux/?
> > + */
>
> I'd probably suggest just moving the register definitions you
> need into <plat/emif_plat.h> so they can be shared with the driver.
>
> Also, the EMIF stuff would benefit greatly from using symbolic defines
> for the values being written. Probably having those in
> <plat/emif_plat.h> would also help out here.
>
> Or, maybe the EMIF driver can provide some self-contained stubs that can
> be copied to OCP RAM for the functionality needed here?
>
> Santosh, what do you think of that?
>
[...]
> Another user of the EMIF virtual addr is emif_self_refresh_dis, but I
> don't see that code actually used anywhere.
Will check and remove it.
>
> Looking closer, now I see the ddr_self_refresh macro is using
> emif_virt_addr (that macro should be fixed to take the base address, for
> readability.)
>
Ok.
> On a related note, just a quick glance at all the code running out of
> OCM RAM makes me wonder if any that could be done before jumping to OCM
> RAM. Ideally, we only want the absolute minimum running out of OCM RAM.
>
Some of the EMIF register saves could perhaps be moved in C but I kept it
in assembly to be consistent with the resume sequence for the case where
WFI ends up as NOP and the normal resume path.
[...]
> > +
> > +/* replicated define because linux/bitops.h cannot be included in assembly */
> > +#define BIT(nr) (1 << (nr))
>
> never used, just remove it. Using shifts as below is fine (but using
> symbolic constants would be even better.)
I recall using it one place. Looks like I got rid of it after all.
>
> In fact, there are lots of magic constants in this code that I'd like
> to see #defined.
>
Ok.
> [...]
>
> > + wfi
> > + nop
> > + nop
> > + nop
> > + nop
> > + nop
> > + nop
> > + nop
> > + nop
> > + nop
> > + nop
> > + nop
> > + nop
> > + nop
>
> Why all the nops? Some comments would be helpful there.
>
That was for the A8 pipeline. Will add a comment.
> [...]
>
> > +/* Values recommended by the HW team */
>
> A little documentation of these values would be helpful here.
>
Ok.
Thanks,
Vaibhav
[1] http://www.spinics.net/lists/linux-omap/msg80918.html
^ permalink raw reply
* [PATCH 0/7] ARM: AM33XX: net: Add DT support to CPGMAC and MDIO driver
From: Richard Cochran @ 2012-11-06 10:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352189545-26303-1-git-send-email-mugunthanvnm@ti.com>
On Tue, Nov 06, 2012 at 01:42:18PM +0530, Mugunthan V N wrote:
> This patch-series adds support for,
>
> [1/7]: Typo mistake in CPSW driver while invoking runtime_pm api's
>
> [2/7]: Adds parent<->child relation between CPSW & MDIO module inside cpsw
> driver, as in case of AM33XX, the resources are shared and common
> register bit-field is provided to control module/clock enable/disable,
> makes it difficult to handle common resource.
>
> So the solution here is, to create parent<->child relation between them.
>
> [3/7]: Add hwmod entry for MDIO module, required for MDIO driver.
>
> [4/7]: cpsw: simplify the setup of the register pointers
>
> [5/7]: Add DT device nodes for both CPSW and MDIO modules in am33xx.dtsi,
> am335x-evm.dts and am335x-bone.dts file
>
> [6/7]: Enable CPSW support to omap2plus_defconfig
>
> [7/7]: cpsw: Kernel warn fix during suspend
Acked-by: Richard Cochran <richardcochran@gmail.com>
^ permalink raw reply
* [PATCH v2] ARM: S3C64XX: Fix up IRQ mapping for balblair on Cragganmore
From: Kukjin Kim @ 2012-11-06 10:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121102142238.GX4413@opensource.wolfsonmicro.com>
Mark Brown wrote:
>
> On Fri, Nov 02, 2012 at 01:04:14PM +0000, Dimitris Papastamos wrote:
> > We are using S3C_EINT(4) instead of S3C_EINT(5).
>
> Reviwed-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Reviewed-by?
Applied with fixing typo :-)
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
^ permalink raw reply
* [PATCH] ARM: dts: exynos4: Add support for Exynos4x12 SoCs
From: Kukjin Kim @ 2012-11-06 10:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351089359-7318-1-git-send-email-t.figa@samsung.com>
Tomasz Figa wrote:
>
> This patch adds device tree sources for Exynos4x12 SoC series (currently
> Exynos4212 and Exynos4412) and enables mach-exynos4-dt to support these
> SoCs.
>
> Signed-off-by: Tomasz Figa <t.figa@samsung.com>
> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
> ---
> arch/arm/boot/dts/exynos4212.dtsi | 28 ++++++++++++++++++++++++++++
> arch/arm/boot/dts/exynos4412.dtsi | 28 ++++++++++++++++++++++++++++
> arch/arm/boot/dts/exynos4x12.dtsi | 31
> +++++++++++++++++++++++++++++++
> arch/arm/mach-exynos/mach-exynos4-dt.c | 2 ++
> 4 files changed, 89 insertions(+)
> create mode 100644 arch/arm/boot/dts/exynos4212.dtsi
> create mode 100644 arch/arm/boot/dts/exynos4412.dtsi
> create mode 100644 arch/arm/boot/dts/exynos4x12.dtsi
>
Looks good to me, applied.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
^ permalink raw reply
* [PATCH 6/7] pinctrl: exynos5440: add pinctrl driver for Samsung EXYNOS5440 SoC
From: Kukjin Kim @ 2012-11-06 10:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdZP_sTKV1Nq3FWVQJocg8C8H7J9vd9hmY4k-qAnMPJcLg@mail.gmail.com>
Linus Walleij wrote:
>
> On Fri, Oct 26, 2012 at 7:55 PM, Kukjin Kim <kgene.kim@samsung.com> wrote:
>
> > From: Thomas Abraham <thomas.abraham@linaro.org>
> >
> > Add a new pinctrl driver for Samsung EXYNOS5440 SoC. The pin controller
> > module in EXYNOS5440 is different from the pin controller found on other
> > Samsung SoC. Hence, the pin controller driver for EXYNOS5440 SoC is
> > independent of the Samsung pinctrl framework.
> >
> > Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org>
> > Cc: Linus Walleij <linus.walleij@linaro.org>
> > Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
>
> If I haven't ACK:ed this before here's an
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
>
Thanks for your ack.
> I expect this to go through the Samsung tree?
>
Yeah, this would be sent to upstream via Samsung tree.
Let me pick this up in my tree with your ack.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
^ permalink raw reply
* [PATCH] ARM: Fix the "WFI" instruction opcode definition.
From: Kukjin Kim @ 2012-11-06 11:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121105173604.GF2005@linaro.org>
Dave Martin wrote:
>
[...]
> > >> - asm(".word 0xe320f003\n"
> > >> + asm(__WFI
> > >
> > > Wouldn't using the actual wfi instruction fix this. There is a wfi()
> > > macro.
> > >
> > > Or just call cpu_do_idle() which will do any other things needed
> before
> > > wfi like a dsb instruction.
> > >
> > > Rob
> > >> :
> > >> :
> > >> : "memory", "cc");
> >
> > <Cut>
> >
> > Hi Rob,
> > Thanks for the reply. The way you suggested is more elegant. But
> > here we worried about the version of the compiler toolchain used to
> > build the kernel. The "WFI" assembler instruction may not be
> > recognized if the toolchain is too old. Need the related ARM board
> > maintainers to confirm this.
>
> Maybe all the exynos platforms are new enough for this not to be a
> problem?
>
Yeah, I think there is no problem on exynos now.
> I think mach-exynos is pretty new and v7-only anyway. If so, then it
Yes, right at the moment.
BTW, if mach-exynos includes ARMv8 later?...ARMv8 platform codes will be put
in the arch/arm/ or arch/arm/64/ if some platform codes share with ARMv7?
Just wondering...
> may be better to put
>
> CFLAGS_hotplug.o := -march=armv7-a
>
> in arch/arm/mach-exynos/Makefile, and use the real "wfi" mnemonic
> directly. People should _really_ not be building kernels containig
> v7 board support with tools that are too old to support this.
>
I think so...
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
^ permalink raw reply
* [PATCH 3/7] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio module
From: Mugunthan V N @ 2012-11-06 11:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <B5906170F1614E41A8A28DE3B8D121433EC049CC@DBDE01.ent.ti.com>
On 11/6/2012 3:39 PM, Bedia, Vaibhav wrote:
> On Tue, Nov 06, 2012 at 13:42:21, N, Mugunthan V wrote:
> [...]
>> +struct omap_hwmod_addr_space am33xx_mdio_addr_space[] = {
>> + {
>> + .pa_start = 0x4A101000,
>> + .pa_end = 0x4A101000 + SZ_256 - 1,
>> + .flags = ADDR_MAP_ON_INIT,
> Based on the recent discussions and looking the hwmod code,
> I guess ADDR_MAP_ON_INIT does not make sense here. Since you
> are just creating a parent-child relationship here, maybe no
> flag is needed?
>
>> + },
>> + { }
>> +};
>> +
>> +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,
> Is this flag necessary? Shouldn't you just skip the
> user field since there's nothing for the hwmod code
> to do here?
>
>
Will remove the unnecessary flags and submit the patch.
Regards
Mugunthan V N
^ permalink raw reply
* [PATCH] ARM: dts: add board dts file for Exynos4412 based SMDK board
From: Kukjin Kim @ 2012-11-06 11:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351954172-13645-1-git-send-email-thomas.abraham@linaro.org>
Thomas Abraham wrote:
>
> Add a minimal board dts file for Samsung Exynos4412 based SMDK board.
>
> Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org>
> ---
> This patch depends the on the following patch posted by Tomasz Figa.
> "ARM: dts: exynos4: Add support for Exynos4x12 SoCs"
>
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/exynos4412-smdk4412.dts | 45
> +++++++++++++++++++++++++++++
> 2 files changed, 46 insertions(+), 0 deletions(-)
> create mode 100644 arch/arm/boot/dts/exynos4412-smdk4412.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index f37cf9f..36488a5 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -23,6 +23,7 @@ dtb-$(CONFIG_ARCH_DOVE) += dove-cm-a510.dtb \
> dtb-$(CONFIG_ARCH_EXYNOS) += exynos4210-origen.dtb \
> exynos4210-smdkv310.dtb \
> exynos4210-trats.dtb \
> + exynos4412-smdk4412.dtb \
> exynos5250-smdk5250.dtb
> dtb-$(CONFIG_ARCH_HIGHBANK) += highbank.dtb
> dtb-$(CONFIG_ARCH_INTEGRATOR) += integratorap.dtb \
> diff --git a/arch/arm/boot/dts/exynos4412-smdk4412.dts
> b/arch/arm/boot/dts/exynos4412-smdk4412.dts
> new file mode 100644
> index 0000000..f05bf57
> --- /dev/null
> +++ b/arch/arm/boot/dts/exynos4412-smdk4412.dts
> @@ -0,0 +1,45 @@
> +/*
> + * Samsung's Exynos4412 based SMDK board device tree source
> + *
> + * Copyright (c) 2012-2013 Samsung Electronics Co., Ltd.
> + * http://www.samsung.com
> + *
> + * Device tree source file for Samsung's SMDK4412 board which is based on
> + * Samsung's Exynos4412 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/ "exynos4412.dtsi"
> +
> +/ {
> + model = "Samsung SMDK evaluation board based on Exynos4412";
> + compatible = "samsung,smdk4412", "samsung,exynos4412";
> +
> + memory {
> + reg = <0x40000000 0x40000000>;
> + };
> +
> + chosen {
> + bootargs ="root=/dev/ram0 rw ramdisk=8192
> initrd=0x41000000,8M console=ttySAC1,115200 init=/linuxrc";
> + };
> +
> + serial at 13800000 {
> + status = "okay";
> + };
> +
> + serial at 13810000 {
> + status = "okay";
> + };
> +
> + serial at 13820000 {
> + status = "okay";
> + };
> +
> + serial at 13830000 {
> + status = "okay";
> + };
> +};
> --
> 1.6.6.rc2
Looks good to me, will apply.
BTW, its default console is ttySAC1 not ttySAC2?
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
^ permalink raw reply
* [PATCHv2 1/6] arch: Change defconfigs to point to g_mass_storage.
From: Felipe Balbi @ 2012-11-06 11:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <46dde680f525562e9fd19567deb5247f0bf26842.1351715302.v2.git.mina86@mina86.com>
Hi,
On Fri, Nov 02, 2012 at 02:31:50PM +0100, Michal Nazarewicz wrote:
> From: Michal Nazarewicz <mina86@mina86.com>
>
> The File-backed Storage Gadget (g_file_storage) is being removed, since
> it has been replaced by Mass Storage Gadget (g_mass_storage). This commit
> changes defconfigs point to the new gadget.
>
> Signed-off-by: Michal Nazarewicz <mina86@mina86.com>
I need more Acks here. Only got one from Nicolas. Anyone else ?
> ---
> arch/arm/configs/afeb9260_defconfig | 2 +-
> arch/arm/configs/at91sam9260_defconfig | 2 +-
> arch/arm/configs/at91sam9261_defconfig | 2 +-
> arch/arm/configs/at91sam9263_defconfig | 2 +-
> arch/arm/configs/at91sam9g20_defconfig | 2 +-
> arch/arm/configs/corgi_defconfig | 2 +-
> arch/arm/configs/davinci_all_defconfig | 2 +-
> arch/arm/configs/h7202_defconfig | 3 +--
> arch/arm/configs/magician_defconfig | 2 +-
> arch/arm/configs/mini2440_defconfig | 2 +-
> arch/arm/configs/omap1_defconfig | 3 +--
> arch/arm/configs/prima2_defconfig | 1 -
> arch/arm/configs/spitz_defconfig | 2 +-
> arch/arm/configs/stamp9g20_defconfig | 2 +-
> arch/arm/configs/viper_defconfig | 2 +-
> arch/arm/configs/zeus_defconfig | 2 +-
> arch/avr32/configs/atngw100_defconfig | 2 +-
> arch/avr32/configs/atngw100_evklcd100_defconfig | 2 +-
> arch/avr32/configs/atngw100_evklcd101_defconfig | 2 +-
> arch/avr32/configs/atngw100_mrmt_defconfig | 2 +-
> arch/avr32/configs/atngw100mkii_defconfig | 2 +-
> .../avr32/configs/atngw100mkii_evklcd100_defconfig | 2 +-
> .../avr32/configs/atngw100mkii_evklcd101_defconfig | 2 +-
> arch/avr32/configs/atstk1002_defconfig | 2 +-
> arch/avr32/configs/atstk1003_defconfig | 2 +-
> arch/avr32/configs/atstk1004_defconfig | 2 +-
> arch/avr32/configs/atstk1006_defconfig | 2 +-
> arch/avr32/configs/favr-32_defconfig | 2 +-
> arch/avr32/configs/hammerhead_defconfig | 2 +-
> arch/blackfin/configs/CM-BF527_defconfig | 2 +-
> arch/blackfin/configs/CM-BF548_defconfig | 2 +-
> arch/blackfin/configs/CM-BF561_defconfig | 2 +-
> arch/mips/configs/bcm47xx_defconfig | 2 +-
> arch/mips/configs/mtx1_defconfig | 2 +-
> arch/sh/configs/ecovec24_defconfig | 2 +-
> arch/sh/configs/se7724_defconfig | 2 +-
> 37 files changed, 35 insertions(+), 39 deletions(-)
>
> diff --git a/arch/arm/configs/afeb9260_defconfig b/arch/arm/configs/afeb9260_defconfig
> index c285a9d..a8dbc1e 100644
> --- a/arch/arm/configs/afeb9260_defconfig
> +++ b/arch/arm/configs/afeb9260_defconfig
> @@ -79,7 +79,7 @@ CONFIG_USB_STORAGE=y
> CONFIG_USB_GADGET=y
> CONFIG_USB_ZERO=m
> CONFIG_USB_GADGETFS=m
> -CONFIG_USB_FILE_STORAGE=m
> +CONFIG_USB_MASS_STORAGE=m
> CONFIG_USB_G_SERIAL=m
> CONFIG_RTC_CLASS=y
> CONFIG_RTC_DEBUG=y
> diff --git a/arch/arm/configs/at91sam9260_defconfig b/arch/arm/configs/at91sam9260_defconfig
> index 505b376..0ea5d2c 100644
> --- a/arch/arm/configs/at91sam9260_defconfig
> +++ b/arch/arm/configs/at91sam9260_defconfig
> @@ -75,7 +75,7 @@ CONFIG_USB_STORAGE_DEBUG=y
> CONFIG_USB_GADGET=y
> CONFIG_USB_ZERO=m
> CONFIG_USB_GADGETFS=m
> -CONFIG_USB_FILE_STORAGE=m
> +CONFIG_USB_MASS_STORAGE=m
> CONFIG_USB_G_SERIAL=m
> CONFIG_RTC_CLASS=y
> CONFIG_RTC_DRV_AT91SAM9=y
> diff --git a/arch/arm/configs/at91sam9261_defconfig b/arch/arm/configs/at91sam9261_defconfig
> index 1e8712e..c87beb9 100644
> --- a/arch/arm/configs/at91sam9261_defconfig
> +++ b/arch/arm/configs/at91sam9261_defconfig
> @@ -125,7 +125,7 @@ CONFIG_USB_GADGET=y
> CONFIG_USB_ZERO=m
> CONFIG_USB_ETH=m
> CONFIG_USB_GADGETFS=m
> -CONFIG_USB_FILE_STORAGE=m
> +CONFIG_USB_MASS_STORAGE=m
> CONFIG_USB_G_SERIAL=m
> CONFIG_MMC=y
> CONFIG_MMC_ATMELMCI=m
> diff --git a/arch/arm/configs/at91sam9263_defconfig b/arch/arm/configs/at91sam9263_defconfig
> index d2050ca..c5212f4 100644
> --- a/arch/arm/configs/at91sam9263_defconfig
> +++ b/arch/arm/configs/at91sam9263_defconfig
> @@ -133,7 +133,7 @@ CONFIG_USB_GADGET=y
> CONFIG_USB_ZERO=m
> CONFIG_USB_ETH=m
> CONFIG_USB_GADGETFS=m
> -CONFIG_USB_FILE_STORAGE=m
> +CONFIG_USB_MASS_STORAGE=m
> CONFIG_USB_G_SERIAL=m
> CONFIG_MMC=y
> CONFIG_SDIO_UART=m
> diff --git a/arch/arm/configs/at91sam9g20_defconfig b/arch/arm/configs/at91sam9g20_defconfig
> index e1b0e80..3b18810 100644
> --- a/arch/arm/configs/at91sam9g20_defconfig
> +++ b/arch/arm/configs/at91sam9g20_defconfig
> @@ -96,7 +96,7 @@ CONFIG_USB_STORAGE=y
> CONFIG_USB_GADGET=y
> CONFIG_USB_ZERO=m
> CONFIG_USB_GADGETFS=m
> -CONFIG_USB_FILE_STORAGE=m
> +CONFIG_USB_MASS_STORAGE=m
> CONFIG_USB_G_SERIAL=m
> CONFIG_MMC=y
> CONFIG_MMC_ATMELMCI=m
> diff --git a/arch/arm/configs/corgi_defconfig b/arch/arm/configs/corgi_defconfig
> index 4b8a25d..1fd1d1d 100644
> --- a/arch/arm/configs/corgi_defconfig
> +++ b/arch/arm/configs/corgi_defconfig
> @@ -218,7 +218,7 @@ CONFIG_USB_GADGET=y
> CONFIG_USB_ZERO=m
> CONFIG_USB_ETH=m
> CONFIG_USB_GADGETFS=m
> -CONFIG_USB_FILE_STORAGE=m
> +CONFIG_USB_MASS_STORAGE=m
> CONFIG_USB_G_SERIAL=m
> CONFIG_MMC=y
> CONFIG_MMC_PXA=y
> diff --git a/arch/arm/configs/davinci_all_defconfig b/arch/arm/configs/davinci_all_defconfig
> index 67b5abb6..4ea7c95 100644
> --- a/arch/arm/configs/davinci_all_defconfig
> +++ b/arch/arm/configs/davinci_all_defconfig
> @@ -144,7 +144,7 @@ CONFIG_USB_GADGET_DEBUG_FS=y
> CONFIG_USB_ZERO=m
> CONFIG_USB_ETH=m
> CONFIG_USB_GADGETFS=m
> -CONFIG_USB_FILE_STORAGE=m
> +CONFIG_USB_MASS_STORAGE=m
> CONFIG_USB_G_SERIAL=m
> CONFIG_USB_G_PRINTER=m
> CONFIG_USB_CDC_COMPOSITE=m
> diff --git a/arch/arm/configs/h7202_defconfig b/arch/arm/configs/h7202_defconfig
> index 69405a7..e16d3f3 100644
> --- a/arch/arm/configs/h7202_defconfig
> +++ b/arch/arm/configs/h7202_defconfig
> @@ -34,8 +34,7 @@ CONFIG_FB_MODE_HELPERS=y
> CONFIG_USB_GADGET=m
> CONFIG_USB_ZERO=m
> CONFIG_USB_GADGETFS=m
> -CONFIG_USB_FILE_STORAGE=m
> -CONFIG_USB_FILE_STORAGE_TEST=y
> +CONFIG_USB_MASS_STORAGE=m
> CONFIG_USB_G_SERIAL=m
> CONFIG_EXT2_FS=y
> CONFIG_TMPFS=y
> diff --git a/arch/arm/configs/magician_defconfig b/arch/arm/configs/magician_defconfig
> index a691ef4..557dd29 100644
> --- a/arch/arm/configs/magician_defconfig
> +++ b/arch/arm/configs/magician_defconfig
> @@ -136,7 +136,7 @@ CONFIG_USB_PXA27X=y
> CONFIG_USB_ETH=m
> # CONFIG_USB_ETH_RNDIS is not set
> CONFIG_USB_GADGETFS=m
> -CONFIG_USB_FILE_STORAGE=m
> +CONFIG_USB_MASS_STORAGE=m
> CONFIG_USB_G_SERIAL=m
> CONFIG_USB_CDC_COMPOSITE=m
> CONFIG_USB_GPIO_VBUS=y
> diff --git a/arch/arm/configs/mini2440_defconfig b/arch/arm/configs/mini2440_defconfig
> index 00630e6..a07948a 100644
> --- a/arch/arm/configs/mini2440_defconfig
> +++ b/arch/arm/configs/mini2440_defconfig
> @@ -240,7 +240,7 @@ CONFIG_USB_GADGET_S3C2410=y
> CONFIG_USB_ZERO=m
> CONFIG_USB_ETH=m
> CONFIG_USB_GADGETFS=m
> -CONFIG_USB_FILE_STORAGE=m
> +CONFIG_USB_MASS_STORAGE=m
> CONFIG_USB_G_SERIAL=m
> CONFIG_USB_CDC_COMPOSITE=m
> CONFIG_MMC=y
> diff --git a/arch/arm/configs/omap1_defconfig b/arch/arm/configs/omap1_defconfig
> index dde2a1a..42eab9a 100644
> --- a/arch/arm/configs/omap1_defconfig
> +++ b/arch/arm/configs/omap1_defconfig
> @@ -214,8 +214,7 @@ CONFIG_USB_TEST=y
> CONFIG_USB_GADGET=y
> CONFIG_USB_ETH=m
> # CONFIG_USB_ETH_RNDIS is not set
> -CONFIG_USB_FILE_STORAGE=m
> -CONFIG_USB_FILE_STORAGE_TEST=y
> +CONFIG_USB_MASS_STORAGE=m
> CONFIG_MMC=y
> CONFIG_MMC_SDHCI=y
> CONFIG_MMC_SDHCI_PLTFM=y
> diff --git a/arch/arm/configs/prima2_defconfig b/arch/arm/configs/prima2_defconfig
> index 807d4e2..6a936c7 100644
> --- a/arch/arm/configs/prima2_defconfig
> +++ b/arch/arm/configs/prima2_defconfig
> @@ -37,7 +37,6 @@ CONFIG_SPI_SIRF=y
> CONFIG_SPI_SPIDEV=y
> # CONFIG_HWMON is not set
> CONFIG_USB_GADGET=y
> -CONFIG_USB_FILE_STORAGE=m
> CONFIG_USB_MASS_STORAGE=m
> CONFIG_MMC=y
> CONFIG_MMC_SDHCI=y
> diff --git a/arch/arm/configs/spitz_defconfig b/arch/arm/configs/spitz_defconfig
> index df77931..2e0419d 100644
> --- a/arch/arm/configs/spitz_defconfig
> +++ b/arch/arm/configs/spitz_defconfig
> @@ -214,7 +214,7 @@ CONFIG_USB_GADGET_DUMMY_HCD=y
> CONFIG_USB_ZERO=m
> CONFIG_USB_ETH=m
> CONFIG_USB_GADGETFS=m
> -CONFIG_USB_FILE_STORAGE=m
> +CONFIG_USB_MASS_STORAGE=m
> CONFIG_USB_G_SERIAL=m
> CONFIG_MMC=y
> CONFIG_MMC_PXA=y
> diff --git a/arch/arm/configs/stamp9g20_defconfig b/arch/arm/configs/stamp9g20_defconfig
> index 52f1488..b845f55 100644
> --- a/arch/arm/configs/stamp9g20_defconfig
> +++ b/arch/arm/configs/stamp9g20_defconfig
> @@ -97,7 +97,7 @@ CONFIG_USB_STORAGE=y
> CONFIG_USB_GADGET=m
> CONFIG_USB_ZERO=m
> CONFIG_USB_ETH=m
> -CONFIG_USB_FILE_STORAGE=m
> +CONFIG_USB_MASS_STORAGE=m
> CONFIG_USB_G_SERIAL=m
> CONFIG_MMC=y
> CONFIG_MMC_ATMELMCI=y
> diff --git a/arch/arm/configs/viper_defconfig b/arch/arm/configs/viper_defconfig
> index 1d01ddd..d36e0d3 100644
> --- a/arch/arm/configs/viper_defconfig
> +++ b/arch/arm/configs/viper_defconfig
> @@ -139,7 +139,7 @@ CONFIG_USB_SERIAL_MCT_U232=m
> CONFIG_USB_GADGET=m
> CONFIG_USB_ETH=m
> CONFIG_USB_GADGETFS=m
> -CONFIG_USB_FILE_STORAGE=m
> +CONFIG_USB_MASS_STORAGE=m
> CONFIG_USB_G_SERIAL=m
> CONFIG_USB_G_PRINTER=m
> CONFIG_RTC_CLASS=y
> diff --git a/arch/arm/configs/zeus_defconfig b/arch/arm/configs/zeus_defconfig
> index 547a3c1..731d4f9 100644
> --- a/arch/arm/configs/zeus_defconfig
> +++ b/arch/arm/configs/zeus_defconfig
> @@ -143,7 +143,7 @@ CONFIG_USB_GADGET=m
> CONFIG_USB_PXA27X=y
> CONFIG_USB_ETH=m
> CONFIG_USB_GADGETFS=m
> -CONFIG_USB_FILE_STORAGE=m
> +CONFIG_USB_MASS_STORAGE=m
> CONFIG_USB_G_SERIAL=m
> CONFIG_USB_G_PRINTER=m
> CONFIG_MMC=y
> diff --git a/arch/avr32/configs/atngw100_defconfig b/arch/avr32/configs/atngw100_defconfig
> index a06bfcc..f4025db 100644
> --- a/arch/avr32/configs/atngw100_defconfig
> +++ b/arch/avr32/configs/atngw100_defconfig
> @@ -109,7 +109,7 @@ CONFIG_USB_GADGET_VBUS_DRAW=350
> CONFIG_USB_ZERO=m
> CONFIG_USB_ETH=m
> CONFIG_USB_GADGETFS=m
> -CONFIG_USB_FILE_STORAGE=m
> +CONFIG_USB_MASS_STORAGE=m
> CONFIG_USB_G_SERIAL=m
> CONFIG_USB_CDC_COMPOSITE=m
> CONFIG_MMC=y
> diff --git a/arch/avr32/configs/atngw100_evklcd100_defconfig b/arch/avr32/configs/atngw100_evklcd100_defconfig
> index d8f1fe8..c76a49b 100644
> --- a/arch/avr32/configs/atngw100_evklcd100_defconfig
> +++ b/arch/avr32/configs/atngw100_evklcd100_defconfig
> @@ -125,7 +125,7 @@ CONFIG_USB_GADGET_VBUS_DRAW=350
> CONFIG_USB_ZERO=m
> CONFIG_USB_ETH=m
> CONFIG_USB_GADGETFS=m
> -CONFIG_USB_FILE_STORAGE=m
> +CONFIG_USB_MASS_STORAGE=m
> CONFIG_USB_G_SERIAL=m
> CONFIG_USB_CDC_COMPOSITE=m
> CONFIG_MMC=y
> diff --git a/arch/avr32/configs/atngw100_evklcd101_defconfig b/arch/avr32/configs/atngw100_evklcd101_defconfig
> index d4c5b19..2d8ab08 100644
> --- a/arch/avr32/configs/atngw100_evklcd101_defconfig
> +++ b/arch/avr32/configs/atngw100_evklcd101_defconfig
> @@ -124,7 +124,7 @@ CONFIG_USB_GADGET_VBUS_DRAW=350
> CONFIG_USB_ZERO=m
> CONFIG_USB_ETH=m
> CONFIG_USB_GADGETFS=m
> -CONFIG_USB_FILE_STORAGE=m
> +CONFIG_USB_MASS_STORAGE=m
> CONFIG_USB_G_SERIAL=m
> CONFIG_USB_CDC_COMPOSITE=m
> CONFIG_MMC=y
> diff --git a/arch/avr32/configs/atngw100_mrmt_defconfig b/arch/avr32/configs/atngw100_mrmt_defconfig
> index 77ca4f9..b189e0c 100644
> --- a/arch/avr32/configs/atngw100_mrmt_defconfig
> +++ b/arch/avr32/configs/atngw100_mrmt_defconfig
> @@ -99,7 +99,7 @@ CONFIG_SND_ATMEL_AC97C=m
> # CONFIG_SND_SPI is not set
> CONFIG_USB_GADGET=m
> CONFIG_USB_GADGET_DEBUG_FILES=y
> -CONFIG_USB_FILE_STORAGE=m
> +CONFIG_USB_MASS_STORAGE=m
> CONFIG_USB_G_SERIAL=m
> CONFIG_MMC=y
> CONFIG_MMC_ATMELMCI=y
> diff --git a/arch/avr32/configs/atngw100mkii_defconfig b/arch/avr32/configs/atngw100mkii_defconfig
> index 6e0dca4..2e4de42 100644
> --- a/arch/avr32/configs/atngw100mkii_defconfig
> +++ b/arch/avr32/configs/atngw100mkii_defconfig
> @@ -111,7 +111,7 @@ CONFIG_USB_GADGET_VBUS_DRAW=350
> CONFIG_USB_ZERO=m
> CONFIG_USB_ETH=m
> CONFIG_USB_GADGETFS=m
> -CONFIG_USB_FILE_STORAGE=m
> +CONFIG_USB_MASS_STORAGE=m
> CONFIG_USB_G_SERIAL=m
> CONFIG_USB_CDC_COMPOSITE=m
> CONFIG_MMC=y
> diff --git a/arch/avr32/configs/atngw100mkii_evklcd100_defconfig b/arch/avr32/configs/atngw100mkii_evklcd100_defconfig
> index 7f2a344..fad3cd2 100644
> --- a/arch/avr32/configs/atngw100mkii_evklcd100_defconfig
> +++ b/arch/avr32/configs/atngw100mkii_evklcd100_defconfig
> @@ -128,7 +128,7 @@ CONFIG_USB_GADGET_VBUS_DRAW=350
> CONFIG_USB_ZERO=m
> CONFIG_USB_ETH=m
> CONFIG_USB_GADGETFS=m
> -CONFIG_USB_FILE_STORAGE=m
> +CONFIG_USB_MASS_STORAGE=m
> CONFIG_USB_G_SERIAL=m
> CONFIG_USB_CDC_COMPOSITE=m
> CONFIG_MMC=y
> diff --git a/arch/avr32/configs/atngw100mkii_evklcd101_defconfig b/arch/avr32/configs/atngw100mkii_evklcd101_defconfig
> index 085eeba..2998623 100644
> --- a/arch/avr32/configs/atngw100mkii_evklcd101_defconfig
> +++ b/arch/avr32/configs/atngw100mkii_evklcd101_defconfig
> @@ -127,7 +127,7 @@ CONFIG_USB_GADGET_VBUS_DRAW=350
> CONFIG_USB_ZERO=m
> CONFIG_USB_ETH=m
> CONFIG_USB_GADGETFS=m
> -CONFIG_USB_FILE_STORAGE=m
> +CONFIG_USB_MASS_STORAGE=m
> CONFIG_USB_G_SERIAL=m
> CONFIG_USB_CDC_COMPOSITE=m
> CONFIG_MMC=y
> diff --git a/arch/avr32/configs/atstk1002_defconfig b/arch/avr32/configs/atstk1002_defconfig
> index d1a887e..a582465 100644
> --- a/arch/avr32/configs/atstk1002_defconfig
> +++ b/arch/avr32/configs/atstk1002_defconfig
> @@ -126,7 +126,7 @@ CONFIG_USB_GADGET=y
> CONFIG_USB_ZERO=m
> CONFIG_USB_ETH=m
> CONFIG_USB_GADGETFS=m
> -CONFIG_USB_FILE_STORAGE=m
> +CONFIG_USB_MASS_STORAGE=m
> CONFIG_USB_G_SERIAL=m
> CONFIG_USB_CDC_COMPOSITE=m
> CONFIG_MMC=y
> diff --git a/arch/avr32/configs/atstk1003_defconfig b/arch/avr32/configs/atstk1003_defconfig
> index 956f281..57a79df 100644
> --- a/arch/avr32/configs/atstk1003_defconfig
> +++ b/arch/avr32/configs/atstk1003_defconfig
> @@ -105,7 +105,7 @@ CONFIG_USB_GADGET=y
> CONFIG_USB_ZERO=m
> CONFIG_USB_ETH=m
> CONFIG_USB_GADGETFS=m
> -CONFIG_USB_FILE_STORAGE=m
> +CONFIG_USB_MASS_STORAGE=m
> CONFIG_USB_G_SERIAL=m
> CONFIG_USB_CDC_COMPOSITE=m
> CONFIG_MMC=y
> diff --git a/arch/avr32/configs/atstk1004_defconfig b/arch/avr32/configs/atstk1004_defconfig
> index 40c69f3..1a49bd8 100644
> --- a/arch/avr32/configs/atstk1004_defconfig
> +++ b/arch/avr32/configs/atstk1004_defconfig
> @@ -104,7 +104,7 @@ CONFIG_USB_GADGET=y
> CONFIG_USB_ZERO=m
> CONFIG_USB_ETH=m
> CONFIG_USB_GADGETFS=m
> -CONFIG_USB_FILE_STORAGE=m
> +CONFIG_USB_MASS_STORAGE=m
> CONFIG_USB_G_SERIAL=m
> CONFIG_USB_CDC_COMPOSITE=m
> CONFIG_MMC=y
> diff --git a/arch/avr32/configs/atstk1006_defconfig b/arch/avr32/configs/atstk1006_defconfig
> index 511eb8a..206a1b6 100644
> --- a/arch/avr32/configs/atstk1006_defconfig
> +++ b/arch/avr32/configs/atstk1006_defconfig
> @@ -129,7 +129,7 @@ CONFIG_USB_GADGET=y
> CONFIG_USB_ZERO=m
> CONFIG_USB_ETH=m
> CONFIG_USB_GADGETFS=m
> -CONFIG_USB_FILE_STORAGE=m
> +CONFIG_USB_MASS_STORAGE=m
> CONFIG_USB_G_SERIAL=m
> CONFIG_USB_CDC_COMPOSITE=m
> CONFIG_MMC=y
> diff --git a/arch/avr32/configs/favr-32_defconfig b/arch/avr32/configs/favr-32_defconfig
> index 19973b0..0421498 100644
> --- a/arch/avr32/configs/favr-32_defconfig
> +++ b/arch/avr32/configs/favr-32_defconfig
> @@ -117,7 +117,7 @@ CONFIG_USB_GADGET=y
> CONFIG_USB_ZERO=m
> CONFIG_USB_ETH=m
> CONFIG_USB_GADGETFS=m
> -CONFIG_USB_FILE_STORAGE=m
> +CONFIG_USB_MASS_STORAGE=m
> CONFIG_USB_G_SERIAL=m
> CONFIG_USB_CDC_COMPOSITE=m
> CONFIG_MMC=y
> diff --git a/arch/avr32/configs/hammerhead_defconfig b/arch/avr32/configs/hammerhead_defconfig
> index 6f45681..82f24eb 100644
> --- a/arch/avr32/configs/hammerhead_defconfig
> +++ b/arch/avr32/configs/hammerhead_defconfig
> @@ -127,7 +127,7 @@ CONFIG_USB_GADGET=y
> CONFIG_USB_ZERO=m
> CONFIG_USB_ETH=m
> CONFIG_USB_GADGETFS=m
> -CONFIG_USB_FILE_STORAGE=m
> +CONFIG_USB_MASS_STORAGE=m
> CONFIG_USB_G_SERIAL=m
> CONFIG_MMC=m
> CONFIG_MMC_ATMELMCI=m
> diff --git a/arch/blackfin/configs/CM-BF527_defconfig b/arch/blackfin/configs/CM-BF527_defconfig
> index c280a50..f59c80e 100644
> --- a/arch/blackfin/configs/CM-BF527_defconfig
> +++ b/arch/blackfin/configs/CM-BF527_defconfig
> @@ -106,7 +106,7 @@ CONFIG_MUSB_PIO_ONLY=y
> CONFIG_USB_STORAGE=m
> CONFIG_USB_GADGET=m
> CONFIG_USB_ETH=m
> -CONFIG_USB_FILE_STORAGE=m
> +CONFIG_USB_MASS_STORAGE=m
> CONFIG_USB_G_SERIAL=m
> CONFIG_USB_G_PRINTER=m
> CONFIG_RTC_CLASS=y
> diff --git a/arch/blackfin/configs/CM-BF548_defconfig b/arch/blackfin/configs/CM-BF548_defconfig
> index 349922b..e961483 100644
> --- a/arch/blackfin/configs/CM-BF548_defconfig
> +++ b/arch/blackfin/configs/CM-BF548_defconfig
> @@ -107,7 +107,7 @@ CONFIG_USB_ZERO=m
> CONFIG_USB_ETH=m
> # CONFIG_USB_ETH_RNDIS is not set
> CONFIG_USB_GADGETFS=m
> -CONFIG_USB_FILE_STORAGE=m
> +CONFIG_USB_MASS_STORAGE=m
> CONFIG_USB_G_SERIAL=m
> CONFIG_USB_G_PRINTER=m
> CONFIG_MMC=m
> diff --git a/arch/blackfin/configs/CM-BF561_defconfig b/arch/blackfin/configs/CM-BF561_defconfig
> index 0456dea..24936b9 100644
> --- a/arch/blackfin/configs/CM-BF561_defconfig
> +++ b/arch/blackfin/configs/CM-BF561_defconfig
> @@ -83,7 +83,7 @@ CONFIG_GPIOLIB=y
> CONFIG_GPIO_SYSFS=y
> CONFIG_USB_GADGET=m
> CONFIG_USB_ETH=m
> -CONFIG_USB_FILE_STORAGE=m
> +CONFIG_USB_MASS_STORAGE=m
> CONFIG_USB_G_SERIAL=m
> CONFIG_USB_G_PRINTER=m
> CONFIG_MMC=y
> diff --git a/arch/mips/configs/bcm47xx_defconfig b/arch/mips/configs/bcm47xx_defconfig
> index b6fde2b..4ca8e5c 100644
> --- a/arch/mips/configs/bcm47xx_defconfig
> +++ b/arch/mips/configs/bcm47xx_defconfig
> @@ -473,7 +473,7 @@ CONFIG_USB_GADGET_NET2280=y
> CONFIG_USB_ZERO=m
> CONFIG_USB_ETH=m
> CONFIG_USB_GADGETFS=m
> -CONFIG_USB_FILE_STORAGE=m
> +CONFIG_USB_MASS_STORAGE=m
> CONFIG_USB_G_SERIAL=m
> CONFIG_USB_MIDI_GADGET=m
> CONFIG_LEDS_CLASS=y
> diff --git a/arch/mips/configs/mtx1_defconfig b/arch/mips/configs/mtx1_defconfig
> index 46c61edc..a0277d4 100644
> --- a/arch/mips/configs/mtx1_defconfig
> +++ b/arch/mips/configs/mtx1_defconfig
> @@ -661,7 +661,7 @@ CONFIG_USB_GADGET_NET2280=y
> CONFIG_USB_ZERO=m
> CONFIG_USB_ETH=m
> CONFIG_USB_GADGETFS=m
> -CONFIG_USB_FILE_STORAGE=m
> +CONFIG_USB_MASS_STORAGE=m
> CONFIG_USB_G_SERIAL=m
> CONFIG_USB_MIDI_GADGET=m
> CONFIG_MMC=m
> diff --git a/arch/sh/configs/ecovec24_defconfig b/arch/sh/configs/ecovec24_defconfig
> index 911e30c9..c6c2bec 100644
> --- a/arch/sh/configs/ecovec24_defconfig
> +++ b/arch/sh/configs/ecovec24_defconfig
> @@ -112,7 +112,7 @@ CONFIG_USB_MON=y
> CONFIG_USB_R8A66597_HCD=y
> CONFIG_USB_STORAGE=y
> CONFIG_USB_GADGET=y
> -CONFIG_USB_FILE_STORAGE=m
> +CONFIG_USB_MASS_STORAGE=m
> CONFIG_MMC=y
> CONFIG_MMC_SPI=y
> CONFIG_MMC_SDHI=y
> diff --git a/arch/sh/configs/se7724_defconfig b/arch/sh/configs/se7724_defconfig
> index ed35093..1faa788 100644
> --- a/arch/sh/configs/se7724_defconfig
> +++ b/arch/sh/configs/se7724_defconfig
> @@ -109,7 +109,7 @@ CONFIG_USB_STORAGE=y
> CONFIG_USB_GADGET=y
> CONFIG_USB_ETH=m
> CONFIG_USB_GADGETFS=m
> -CONFIG_USB_FILE_STORAGE=m
> +CONFIG_USB_MASS_STORAGE=m
> CONFIG_USB_G_SERIAL=m
> CONFIG_MMC=y
> CONFIG_MMC_SPI=y
> --
> 1.7.7.3
>
--
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/20121106/a88acf8b/attachment.sig>
^ permalink raw reply
* [PATCH 1/2] ARM: i.MX27: Add platform support for IRAM.
From: Guennadi Liakhovetski @ 2012-11-06 11:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352131185-12079-1-git-send-email-javier.martin@vista-silicon.com>
Hi Javier
On Mon, 5 Nov 2012, Javier Martin wrote:
> Add support for IRAM to i.MX27 non-DT platforms using
> iram_init() function.
I'm not sure this belongs in a camera driver. Can IRAM not be used for
anything else? I'll check the i.MX27 datasheet when I'm back home after
the conference, so far this seems a bit odd.
Thanks
Guennadi
>
> Signed-off-by: Javier Martin <javier.martin@vista-silicon.com>
> ---
> arch/arm/mach-imx/mm-imx27.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/arm/mach-imx/mm-imx27.c b/arch/arm/mach-imx/mm-imx27.c
> index e7e24af..fd2416d 100644
> --- a/arch/arm/mach-imx/mm-imx27.c
> +++ b/arch/arm/mach-imx/mm-imx27.c
> @@ -27,6 +27,7 @@
> #include <asm/pgtable.h>
> #include <asm/mach/map.h>
> #include <mach/iomux-v1.h>
> +#include <mach/iram.h>
>
> /* MX27 memory map definition */
> static struct map_desc imx27_io_desc[] __initdata = {
> @@ -94,4 +95,6 @@ void __init imx27_soc_init(void)
> /* imx27 has the imx21 type audmux */
> platform_device_register_simple("imx21-audmux", 0, imx27_audmux_res,
> ARRAY_SIZE(imx27_audmux_res));
> + /* imx27 has an iram of 46080 bytes size */
> + iram_init(MX27_IRAM_BASE_ADDR, 46080);
> }
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" 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/
^ permalink raw reply
* [RFC patch v3 3/4] ASoC: atmel-ssc-dai: register dai and pcm directly
From: Mark Brown @ 2012-11-06 11:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5098D930.8030403@atmel.com>
On Tue, Nov 06, 2012 at 05:32:32PM +0800, Bo Shen wrote:
> On 11/6/2012 16:48, Mark Brown wrote:
> >On Tue, Nov 06, 2012 at 01:57:53PM +0800, Bo Shen wrote:
> >No, this isn't converting things to device tree which presumably is the
> >goal here and obviously just doing the rename doesn't accomplish an
> >enormous amount. What I said was that you should instantiate the ASoC
> >adaption when the machine driver needs to use them. You shouldn't even
> >need a separate device for this.
> Maybe this is not the best solution, but just abstract audio as a
> separate device. The other's still keep as a ssc library.
It's not abstracting things, that's the whole problem. It's putting the
internals of how the Linux audio stack is organised into the device
tree. The point is that the SSC should be a library to all users.
> >Please do look at other platforms with similar hardware and do something
> >similar to them.
> I take some reference (e.g: freescale, marvell, invidia soc, this
> RFC implement is similar with them), but don't find the similar
> hardware with us. Please help provide the information who's HW is
> similar with us. Thanks.
A *huge* range of SoCs have generic serial ports - off the top of my
head this includes at least OMAP, PXA and Freescale. The same issue
also applies to DMA controllers which affects almost all SoCs.
-------------- 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/20121106/d18e41e4/attachment.sig>
^ permalink raw reply
* [PATCH] ARM: Exynos: remove unused init_uarts callback for exynos4x12 platforms
From: Kukjin Kim @ 2012-11-06 11:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352125973-24228-1-git-send-email-thomas.abraham@linaro.org>
Thomas Abraham wrote:
>
> All the Exynos4x12 based platforms use only device tree based boot. So
> remove
> the unused 'init_uarts' callback from exynos cpu_ids table.
>
> Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org>
> ---
> arch/arm/mach-exynos/common.c | 2 --
> 1 files changed, 0 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
> index 56844d1..ce91cba 100644
> --- a/arch/arm/mach-exynos/common.c
> +++ b/arch/arm/mach-exynos/common.c
> @@ -78,7 +78,6 @@ static struct cpu_table cpu_ids[] __initdata = {
> .idmask = EXYNOS4_CPU_MASK,
> .map_io = exynos4_map_io,
> .init_clocks = exynos4_init_clocks,
> - .init_uarts = exynos_init_uarts,
> .init = exynos_init,
> .name = name_exynos4212,
> }, {
> @@ -86,7 +85,6 @@ static struct cpu_table cpu_ids[] __initdata = {
> .idmask = EXYNOS4_CPU_MASK,
> .map_io = exynos4_map_io,
> .init_clocks = exynos4_init_clocks,
> - .init_uarts = exynos_init_uarts,
> .init = exynos_init,
> .name = name_exynos4412,
> }, {
> --
> 1.6.6.rc2
Yes, correct. Applied.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
^ permalink raw reply
* [PATCH] ARM: Exynos: remove unused init_uarts callback for exynos4x12 platforms
From: Kukjin Kim @ 2012-11-06 11:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352125973-24228-1-git-send-email-thomas.abraham@linaro.org>
Kukjin Kim wrote:
>
> Thomas Abraham wrote:
> >
> > All the Exynos4x12 based platforms use only device tree based boot. So
> > remove
> > the unused 'init_uarts' callback from exynos cpu_ids table.
> >
> > Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org>
> > ---
> > arch/arm/mach-exynos/common.c | 2 --
> > 1 files changed, 0 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-
> exynos/common.c
> > index 56844d1..ce91cba 100644
> > --- a/arch/arm/mach-exynos/common.c
> > +++ b/arch/arm/mach-exynos/common.c
> > @@ -78,7 +78,6 @@ static struct cpu_table cpu_ids[] __initdata = {
> > .idmask = EXYNOS4_CPU_MASK,
> > .map_io = exynos4_map_io,
> > .init_clocks = exynos4_init_clocks,
> > - .init_uarts = exynos_init_uarts,
> > .init = exynos_init,
> > .name = name_exynos4212,
> > }, {
> > @@ -86,7 +85,6 @@ static struct cpu_table cpu_ids[] __initdata = {
> > .idmask = EXYNOS4_CPU_MASK,
> > .map_io = exynos4_map_io,
> > .init_clocks = exynos4_init_clocks,
> > - .init_uarts = exynos_init_uarts,
> > .init = exynos_init,
> > .name = name_exynos4412,
> > }, {
> > --
> > 1.6.6.rc2
>
> Yes, correct. Applied.
>
Well...
BTW, exynos4x12 can support non-DT yet so I just reverted this patch.
I think, this can be applied when we support only DT for exynos4 series next
time.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
^ permalink raw reply
* [PATCH 1/5] ARM: EXYNOS: fix the hotplug for Cortex-A15
From: Santosh Shilimkar @ 2012-11-06 12:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352182356-28989-2-git-send-email-a.kesavan@samsung.com>
On Tuesday 06 November 2012 12:12 AM, Abhilash Kesavan wrote:
> The sequence of cpu_enter_lowpower() for Cortex-A15
> is different from the sequence for Cortex-A9.
Are you sure ? Apart from integrated cache vs external, there
should be no change. And L2 doesn't need to come into picture
while powering down just a CPU.
> This patch implements cpu_enter_lowpower() for EXYNOS5
> SoC which has Cortex-A15 cores.
>
> Signed-off-by: Changhwan Youn <chaos.youn@samsung.com>
> Cc: Russell King <rmk+kernel@arm.linux.org.uk>
> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
> Tested-by: Abhilash Kesavan <a.kesavan@samsung.com>
> ---
> arch/arm/mach-exynos/hotplug.c | 45 +++++++++++++++++++++++++++++++++++++--
> 1 files changed, 42 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-exynos/hotplug.c b/arch/arm/mach-exynos/hotplug.c
> index f4d7dd2..8c06c4f 100644
> --- a/arch/arm/mach-exynos/hotplug.c
> +++ b/arch/arm/mach-exynos/hotplug.c
> @@ -20,10 +20,11 @@
> #include <asm/smp_plat.h>
>
> #include <mach/regs-pmu.h>
> +#include <plat/cpu.h>
>
> #include "common.h"
>
> -static inline void cpu_enter_lowpower(void)
> +static inline void cpu_enter_lowpower_a9(void)
> {
> unsigned int v;
>
> @@ -45,6 +46,35 @@ static inline void cpu_enter_lowpower(void)
> : "cc");
> }
>
> +static inline void cpu_enter_lowpower_a15(void)
> +{
> + unsigned int v;
> +
> + asm volatile(
> + " mrc p15, 0, %0, c1, c0, 0\n"
> + " bic %0, %0, %1\n"
> + " mcr p15, 0, %0, c1, c0, 0\n"
> + : "=&r" (v)
> + : "Ir" (CR_C)
> + : "cc");
> +
> + flush_cache_all();
> +
Why are flushing all the cache levels ?
flush_kern_louis() should be enough for CPU power
down.
> + asm volatile(
> + /*
> + * Turn off coherency
> + */
> + " mrc p15, 0, %0, c1, c0, 1\n"
> + " bic %0, %0, %1\n"
> + " mcr p15, 0, %0, c1, c0, 1\n"
> + : "=&r" (v)
> + : "Ir" (0x40)
> + : "cc");
> +
> + isb();
> + dsb();
> +}
> +
The above sequence should work on A9 as well. In general you should have
CPU power down code under one code block and avoid making use of stack
in between. Otherwise you will end up with stack corruption because of
the memory view change after C bit is disabled.
Regards
Santosh
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox