* [PATCH RFC] ARM: EXYNOS5: Setup legacy i2c controller interrupts on SMDK5250
From: Thomas Abraham @ 2012-11-06 8:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352182726-29221-1-git-send-email-a.kesavan@samsung.com>
On 6 November 2012 11:48, Abhilash Kesavan <a.kesavan@samsung.com> wrote:
> On Exynos5 we have a new high-speed i2c controller. The interrupt
> sources for the legacy and new controller are muxed and are controlled
> via the SYSCON I2C_CFG register.
> At reset the interrupt source is configured for the high-speed controller,
> to continue using the old i2c controller we need to modify the I2C_CFG
> register.
If the high-speed i2c controllers are not used, can this configuration
be moved into the bootloader?
The other option could be, in the exynos5250_dt_machine_init()
function, first check if the platform is compatible with
"samsung,exynos5250" and if so search for a high-speed i2c controller
compatible node. If a high-speed controller node is found and if that
node is not disabled, then do not change the reset value of I2C_CFG
register.
Thanks,
Thomas.
>
> Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com>
> ---
> This is a hack, I am not quite clear on how to handle this via DT. Suggestions
> welcome.
>
> arch/arm/mach-exynos/mach-exynos5-dt.c | 10 ++++++++++
> 1 files changed, 10 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-exynos/mach-exynos5-dt.c b/arch/arm/mach-exynos/mach-exynos5-dt.c
> index ed37273..badffd4 100644
> --- a/arch/arm/mach-exynos/mach-exynos5-dt.c
> +++ b/arch/arm/mach-exynos/mach-exynos5-dt.c
> @@ -13,10 +13,12 @@
> #include <linux/serial_core.h>
> #include <linux/memblock.h>
> #include <linux/of_fdt.h>
> +#include <linux/io.h>
>
> #include <asm/mach/arch.h>
> #include <asm/hardware/gic.h>
> #include <mach/map.h>
> +#include <mach/regs-pmu.h>
>
> #include <plat/cpu.h>
> #include <plat/regs-serial.h>
> @@ -89,6 +91,12 @@ static const struct of_dev_auxdata exynos5250_auxdata_lookup[] __initconst = {
> {},
> };
>
> +static void exynos5_i2c_setup(void)
> +{
> + /* Setup the low-speed i2c controller interrupts */
> + writel(0x0, EXYNOS5_SYS_I2C_CFG);
> +}
> +
> static void __init exynos5250_dt_map_io(void)
> {
> exynos_init_io(NULL, 0);
> @@ -97,6 +105,8 @@ static void __init exynos5250_dt_map_io(void)
>
> static void __init exynos5250_dt_machine_init(void)
> {
> + exynos5_i2c_setup();
> +
> of_platform_populate(NULL, of_default_bus_match_table,
> exynos5250_auxdata_lookup, NULL);
> }
> --
> 1.6.6.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/2] ASoC: Ux500: Fixup use of clocks
From: Mark Brown @ 2012-11-06 8:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPDyKFqgFvY67QR8LA_KTEQwDi3o2wH=MY-D89k023-2S=ioFw@mail.gmail.com>
On Mon, Nov 05, 2012 at 03:27:08PM +0100, Ulf Hansson wrote:
> I can not find this patch on any "next-tree" yet. Same goes for:
> "[PATCH 2/2] ASoC: Ux500: Control apb clock".
> Maybe I should be more patient, but thought it make sense to send a
> ping on this. :-)
As I've had to tell you before pings are pointless, don't do this - to
repeat, if you think something has been missed resend 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/20121106/d3358676/attachment.sig>
^ permalink raw reply
* [PATCH V2 4/5] pinctrl: SPEAr: Add gpio ranges support
From: Linus Walleij @ 2012-11-06 8:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKohpo=n9=z+UuvYbrzz2isi+BN-0RMsDgPCL-zhQMsa8m0ZSg@mail.gmail.com>
On Tue, Nov 6, 2012 at 9:11 AM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> On 6 November 2012 13:39, Linus Walleij <linus.walleij@linaro.org> wrote:
>>
>> This does not apply to my devel branch, so I guess it is dependent
>> on some of the stuff I just merged to fixes. I will send the
>> fixes up to Torvalds, then merge fixes to the devel branch
>> so we can proceed with patches 4 and 5, OK?
>
> When will i learn how to send patches x-(
>
> Yes, they were rebased over fixes.
You are doing everything right, it is perfectly OK to assume
fixes to be merged first, and in either way the subsystem
maintainer will get some small conflicts, but he (i.e. me)
gets to deal with them. I have to do something as well
you know ;-)
Yours,
Linus Walleij
^ permalink raw reply
* [GIT PULL v2] Renesas ARM-based SoC defconfig for v3.8
From: Arnd Bergmann @ 2012-11-06 8:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121106023232.GP2944@verge.net.au>
On Tuesday 06 November 2012, Simon Horman wrote:
> On Thu, Nov 01, 2012 at 09:02:08AM +0800, Simon Horman wrote:
> > Hi Olof, Hi Arnd,
> >
> > please consider the following defconfig enhancements for 3.8.
>
> Ping.
>
Thanks for the reminder. Olof and I were both attending Linaro Connect last
week and did not merge any pull requests. Olof just started new merges
yesterday, he'll get to it today I assume. If not, I can take care of them
tomorrow.
Arnd
^ permalink raw reply
* scheduler clock for MXS
From: Stanislav Meduna @ 2012-11-06 8:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121105222859.GI28327@n2100.arm.linux.org.uk>
On 05.11.2012 23:28, Russell King - ARM Linux wrote:
> It most certainly does handle the wrapping correctly - it was designed
> to from the very start.
I'm not an expert on Linux kernel and its core infrastructure,
but how is the sched_clock_timer armed for the first time
after calling setup_sched_clock?
The explicitely called update_sched_clock() does _not_ arm it.
Shawn: could you try change the
update_sched_clock();
to
sched_clock_poll(sched_clock_timer.data);
right after update_sched_clock call in setup_sched_clock?
Regards
--
Stano
^ permalink raw reply
* [PATCH 0/2] clk: ux500: Add some more clk lookups for u8500
From: Linus Walleij @ 2012-11-06 8:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121105221759.GH28327@n2100.arm.linux.org.uk>
On Mon, Nov 5, 2012 at 11:17 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Mon, Nov 05, 2012 at 12:40:20PM +0100, Linus Walleij wrote:
>> They have the right name and all, apb_pclk is
>> "AMBA peripheral bus, peripheral block clock"
>> so a clock for the silicon, right.
>>
>> ... then how it's supposed to be used, that's another
>> issue...
>
> Well, the apb pclk is the APB bus clock which times all transfers on
> the APB bus. Without the APB bus clock running, you can't talk to any
> peripherals attached to that bus.
>
> If your SoC controls the APB bus clock to each peripheral individually
> (like, I seem to remember your Ux500 stuff does) and the peripheral is
> not being clocked, then although the bus master may be seeing a clock,
> and will manipulate the bus signals, the target will remain unresponsive
> due to lack of clock.
Yes .. for the PrimeCell derivates we are using the bus code in
drivers/amba/bus.c now, so pclk is taken care of at the bus level.
And I'm trying to move things that have PrimeCell ID registers
to that bus.
For platform devices we're not handling the pclk in the bus layer,
and when I talked to Kevin Hilman about it it turns out that
OMAP is doing all that in the PM domains, as is SH (-mobile)
and have the platform bus not intervene.
Both the above rely on drivers simply doing pm_runtime_get()
and friends so for drivers it looks the same.
And then some drivers have been grabbing the pclk directly.
This is probably not to be encouraged.
That's what I was referring to when saying I wasn't clear on
where it was to be handled. But I think I'm more on the
clear now.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 6/8] mfd/ab8500-core: use irq_domain_add_simple()
From: Linus Walleij @ 2012-11-06 8:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121105225922.GF7965@sortiz-mobl>
On Mon, Nov 5, 2012 at 11:59 PM, Samuel Ortiz <sameo@linux.intel.com> wrote:
> On Thu, Oct 18, 2012 at 07:19:15PM +0200, Linus Walleij wrote:
>> From: Linus Walleij <linus.walleij@linaro.org>
>>
>> To be able to use SPARSE_IRQ while yet not using device tree,
>> we need to use irq_domain_add_simple() that will allocate
>> descriptors for the IRQs in the non-DT case, and fall back
>> to using the linear irqdomain in the DT case.
>>
>> Cc: Lee Jones <lee.jones@linaro.org>
>> Cc: Samuel Ortiz <sameo@linux.intel.com>
>> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> In case it's not too late:
>
> Acked-by: Samuel Ortiz <sameo@linux.intel.com>
Too late for my pull request to ARM SoC, but the important
thing is that the ARM SoC people see that you're OK with it
so they can pull in my patches :-)
Thanks Sam!
Yours,
Linus Walleij
^ permalink raw reply
* [RFC patch v3 3/4] ASoC: atmel-ssc-dai: register dai and pcm directly
From: Mark Brown @ 2012-11-06 8:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352181474-19597-3-git-send-email-voice.shen@atmel.com>
On Tue, Nov 06, 2012 at 01:57:53PM +0800, Bo Shen wrote:
> static struct platform_device at91sam9260_ssc_device = {
> - .name = "at91rm9200_ssc",
> + .name = "at91rm9200_ssc_dai",
> .id = 0,
> .dev = {
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.
Please do look at other platforms with similar hardware and do something
similar to them.
-------------- 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/e051f0f7/attachment.sig>
^ permalink raw reply
* [PATCH] pinctrl: sirf: Staticize non-exported symbol
From: Linus Walleij @ 2012-11-06 8:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352123068.14769.6.camel@phoenix>
On Mon, Nov 5, 2012 at 2:44 PM, Axel Lin <axel.lin@ingics.com> wrote:
> Staticize sirfsoc_gpio_irq_map() function.
>
> Signed-off-by: Axel Lin <axel.lin@ingics.com>
Applied with Barry's ACK, thanks!
Linus Walleij
^ permalink raw reply
* [Patch v2 3/4] ASoC: atmel-ssc-dai: register platform from DAIs
From: Mark Brown @ 2012-11-06 8:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5098A280.7070301@atmel.com>
On Tue, Nov 06, 2012 at 01:39:12PM +0800, Bo Shen wrote:
> On 11/5/2012 13:25, Bo Shen wrote:
Note that there's less than 24 hours between these two mails...
> >Sorry for misunderstand. I split your e-mail into two parts. May be you
> >miss some parts of my e-mail. You can check the last mail from me. Or
> >check the following fully quote.
> Anyway, I will sent out a RFC patch series (which will be v3) which
> register dai and platform directly in Linux.
> > > This seems to be a purely virtual device which remaps the SSC onto the
> > > Linux audio subsystem? If that is the case then it shouldn't appear in
> > > the device tree,
> >Yes. This is a purely virtual device. I add this as to the following
> >reason.
> >In our case, the ssc can connect to audio codec, DAC and other devices.
> >In order to avoid duplicate the code, so keep ssc as a library, register
> >it directly in Linux and use remap method to let it work onto other
> >different subsystem.
The whole point here is that this remapping shouldn't appear in the
device tree since it's a purely Linux internal issue, the code that uses
the SSC should have a reference to the SSC and then do whatever
remapping is required.
-------------- 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/b4fff9ac/attachment.sig>
^ permalink raw reply
* [PATCH v2 1/2] mailbox: OMAP: introduce mailbox framework
From: Linus Walleij @ 2012-11-06 8:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <509886A2.5060509@wwwdotorg.org>
On Tue, Nov 6, 2012 at 4:40 AM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> Is this a public interface to the driver? If so, shouldn't the header be
> in include/linux somewhere?
I think the split out of the public header is done in patch 2/2.
Yours,
Linus Walleij
^ permalink raw reply
* [RFC patch v3 1/4] ARM: at91: atmel-ssc: add platform device id table
From: Mark Brown @ 2012-11-06 8:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352181474-19597-1-git-send-email-voice.shen@atmel.com>
On Tue, Nov 06, 2012 at 01:57:51PM +0800, Bo Shen wrote:
> Add platform device id to check whether the SSC controller support
> pdc or dam for data transfer
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/20121106/fd3e2547/attachment.sig>
^ permalink raw reply
* [RFC patch v3 2/4] ARM: at91: atmel-ssc: add device tree support
From: Mark Brown @ 2012-11-06 8:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352181474-19597-2-git-send-email-voice.shen@atmel.com>
On Tue, Nov 06, 2012 at 01:57:52PM +0800, Bo Shen wrote:
> Add atmel-ssc for device tree support
>
> Match "atmel,at91rm9200-ssc" for using pdc for data transfer
> Match "atmel,at91sam9g45-ssc" for using pdc for data transfer
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/20121106/86221379/attachment.sig>
^ permalink raw reply
* [PATCH v2 1/2] mailbox: OMAP: introduce mailbox framework
From: Greg Kroah-Hartman @ 2012-11-06 8:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdb0nCaV5L5xCnzje3w=t7+TZpcvCCUDRPi-10t+oF8UGg@mail.gmail.com>
On Tue, Nov 06, 2012 at 09:55:52AM +0100, Linus Walleij wrote:
> On Tue, Nov 6, 2012 at 4:40 AM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>
> > Is this a public interface to the driver? If so, shouldn't the header be
> > in include/linux somewhere?
>
> I think the split out of the public header is done in patch 2/2.
Yes, but the names are still omap_*, which doesn't make much sense here.
greg k-h
^ permalink raw reply
* [PATCHv9 6/8] ARM: OMAP4: retrigger localtimers after re-enabling gic
From: Tero Kristo @ 2012-11-06 9:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <878vafg008.fsf@deeprootsystems.com>
On Mon, 2012-11-05 at 14:25 -0800, Kevin Hilman wrote:
> Tero Kristo <t-kristo@ti.com> writes:
>
> > From: Colin Cross <ccross@android.com>
> >
> > 'Workaround for ROM bug because of CA9 r2pX gic control'
> > register change disables the gic distributor while the secondary
>
> Just to clarify: this is referring to PATCH 3/8 of this series, correct?
>
Yes.
-Tero
^ permalink raw reply
* [PATCHv9 0/8] ARM: OMAP4: core retention support
From: Tero Kristo @ 2012-11-06 9:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87d2zrg04t.fsf@deeprootsystems.com>
Hi Kevin,
On Mon, 2012-11-05 at 14:23 -0800, Kevin Hilman wrote:
> Hi Tero,
>
> Tero Kristo <t-kristo@ti.com> writes:
>
> > Hi,
> >
> > Changes compared to previous version:
> > - rebased on top of 3.7-rc1
> > - applies on top of latest func pwrst code (v6)
> > - added back patch #1 to this set (it wasn't queued yet after all)
> > - added patch #7 for fixing a bug in the functional pwrst code
> > - added patch #8 for fixing a regression with MUSB PHY power handling
> > (not quite sure if this is the correct way to fix this or not)
> >
> > Tested with omap4460 gp panda + omap4430 emu blaze boards, with cpuidle +
> > suspend.
> >
> > Branch also available here:
> > git://gitorious.org/~kristo/omap-pm/omap-pm-work.git
> > branch: mainline-3.7-rc1-omap4-ret-v9
>
> I tested this branch on 4430/Panda and 4460/Panda-ES and I'm seeing
> several domains not hitting target power state in suspend[1].
>
> Am I missing some other fixes? Using omap2plus_defconfig, I tried your
> branch alone, and merged with v3.7-rc4, and I get the same errors.
>
> Kevin
>
> [1]
> # echo enabled > /sys/devices/platform/omap_uart.2/tty/ttyO2/power/wakeup
> # echo mem > /sys/power/state
> [ 102.271087] PM: Syncing filesystems ... done.
> [ 102.282196] Freezing user space processes ... (elapsed 0.02 seconds) done.
> [ 102.312133] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done.
> [ 102.343353] Suspending console(s) (use no_console_suspend to debug)
> ?[ 102.363433] PM: suspend of devices complete after 10.650 msecs
> [ 102.365631] PM: late suspend of devices complete after 2.166 msecs
> [ 102.369201] PM: noirq suspend of devices complete after 3.509 msecs
> [ 102.369232] Disabling non-boot CPUs ...
> [ 102.373016] CPU1: shutdown
> [ 104.357421] Powerdomain (core_pwrdm) didn't enter target state 1
> [ 104.357452] Powerdomain (tesla_pwrdm) didn't enter target state 1
> [ 104.357452] Powerdomain (ivahd_pwrdm) didn't enter target state 1
> [ 104.357482] Powerdomain (l3init_pwrdm) didn't enter target state 1
> [ 104.357482] Could not enter target state in pm_suspend
> [ 104.357666] Enabling non-boot CPUs ...
> [ 104.359863] CPU1: Booted secondary processor
> [ 104.360626] cpu cpu0: opp_init_cpufreq_table: Device OPP not found (-19)
> [ 104.360656] cpu cpu0: omap_cpu_init: cpu1: failed creating freq table[-19]
> [ 104.360656] CPU1 is up
> [ 104.362579] PM: noirq resume of devices complete after 1.892 msecs
> [ 104.364807] PM: early resume of devices complete after 1.373 msecs
> [ 104.710937] PM: resume of devices complete after 346.099 msecs
> [ 104.817901] Restarting tasks ... done.
This looks like a combination of boot loader/kernel problems. My guess
is that l3init is probably held on by the USB, and both ivahd / tesla
are held on by some DSP/IVA modules which are not idling properly.
The last patch in this set should fix the USB problems at least
partially, but also the USB DPLL itself might be in wrong state,
attached patch might help for that one and get l3init to idle.
For DSP I don't have a patch right now, what is the boot loader you are
using? (Can you provide git / commit / config info?)
-Tero
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-ARM-OMAP4-clock-setup-USB-DPLL-during-init.patch
Type: text/x-patch
Size: 1199 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121106/aa09bad8/attachment.bin>
^ permalink raw reply
* OMAP baseline test results for v3.7-rc1
From: Jean Pihet @ 2012-11-06 9:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87fw4neh0i.fsf@deeprootsystems.com>
Hi Kevin, Paul,
On Tue, Nov 6, 2012 at 1:01 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.
That makes sense with CPU_IDLE enabled and suspend. The cause of the
problem is that the cpuidle influences the MPU and CORE states,
depending on the constraints set and the latency figures for the power
domains (in arch/arm/mach-omap2/cpuidle34xx.c). Since the latency
numbers have not been updated to measured (i.e. realistic) values in
too-low power state is used, hence the timeout problem.
Note: that does not explain why the I2C timeout issue is present
without CPU_IDLE enabled, since in that case PM QoS should not have
any effect on the power domains states.
So yes the PM QoS I2C patch shall be reverted as long as the PM QoS
support for OMAP is not merged in.
For the records here are the patches that have been submitted to
support the OMAP PM QoS:
- func power states [1],
- OMAP PM QoS support [2], which includes the latency figures update
and which depends on [1],
- the conversion of I2C to PM QoS [3],
- the removal of the old no-op OMAP PM API [4], which depends on [3],
The chicken-and-egg problem is clearly visible since [3] depends on [2].
What to do now with those patches?
As said above [3] and [4] must be held until [1] and [2] are merged in.
[1] http://marc.info/?l=linux-arm-kernel&m=134744383120921&w=2
[2] http://marc.info/?l=linux-omap&m=134795835604288&w=2
[3] http://marc.info/?l=linux-omap&m=134815730108344&w=2
[4] http://marc.info/?l=linux-omap&m=134795836904299&w=2
> Kevin
Thanks for testing and reporting the issue.
Jean
>
>
> # rtcwake -m mem -s 1
> Date: Fri Dec 31 17:00:34 MST 1999
> hwclock: Sat Jan 1 00:00:34 2000 0.000000 seconds
> [ 38.819732] omap_i2c omap_i2c.1: timeout waiting for bus ready
> wakeup from "mem" at Sat Jan 1 00:00:36 2000
> [ 38.841949] PM: Syncing filesystems ... done.
> [ 38.859466] Freezing user space processes ... (elapsed 0.01 seconds) done.
> [ 38.885284] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done.
> [ 38.916412] Suspending console(s) (use no_console_suspend to debug)
> [ 39.944274] omap_i2c omap_i2c.1: timeout waiting for bus ready
> [ 39.944305] twl: i2c_read failed to transfer all messages
> [ 39.944305] twl_rtc: Could not read TWLregister D - error -110
> [ 39.944335] twl_rtc twl_rtc: twl_rtc_read_time: reading CTRL_REG, error -110
> [ 40.975524] omap_i2c omap_i2c.1: timeout waiting for bus ready
> [ 40.975555] twl: i2c_read failed to transfer all messages
> [ 40.975555] VMMC2_IO_18: failed to disable
> [ 40.978698] PM: suspend of devices complete after 2049.163 msecs
> [ 40.984222] PM: late suspend of devices complete after 5.493 msecs
> [ 40.992126] PM: noirq suspend of devices complete after 7.873 msecs
> [ 40.992187] Disabling non-boot CPUs ...
> [ 40.992675] Successfully put all powerdomains to target state
> [ 40.997009] PM: noirq resume of devices complete after 4.058 msecs
> [ 41.002014] PM: early resume of devices complete after 3.601 msecs
> [ 41.179016] PM: resume of devices complete after 176.818 msecs
> [ 41.277740] Restarting tasks ... done.
> real 0m 3.50s
> user 0m 0.00s
> sys 0m 0.10s
> Date: Fri Dec 31 17:00:40 MST 1999
> hwclock: Sat Jan 1 00:00:40 2000 0.000000 seconds
^ permalink raw reply
* [PATCH 08/15] ARM: OMAP2+: hwmod: Fix the omap_hwmod_addr_space for CPGMAC0
From: Vaibhav Hiremath @ 2012-11-06 9:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <B5906170F1614E41A8A28DE3B8D121433EC00B9B@DBDE01.ent.ti.com>
On 11/5/2012 2:40 PM, Bedia, Vaibhav wrote:
> On Sun, Nov 04, 2012 at 20:54:17, Bedia, Vaibhav wrote:
>> On Sat, Nov 03, 2012 at 21:48:48, Shilimkar, Santosh wrote:
>>> On Friday 02 November 2012 06:02 PM, Vaibhav Bedia wrote:
>>>> The first entry for CPGMAC0 should be ADDR_MAP_ON_INIT
>>>> instead of ADDR_TYPE_RT to ensure the omap hwmod code
>>>> maps the memory space at init and writes to the SYSCONFIG
>>>> registers.
>>>>
>>>> Signed-off-by: Vaibhav Bedia <vaibhav.bedia@ti.com>
>>>> ---
>>> Sorry again similar question.
>>>
>>> Why CPGMAC0 should be mapped and sysconfig updated early ?
>>>
>>
>> Hmm I need to revisit this one. CPGMAC0 was not going to standby
>> without this. Maybe something else is wrong in the hwmod data and
>> needs fixing.
>>
>
> 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.
Thanks,
Vaibhav
> I'll make the changes in the next version.
>
> Regards,
> Vaibhav
> --
> 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
>
^ permalink raw reply
* [PATCH v3 03/11] clk: davinci - common clk utilities to init clk driver
From: Sekhar Nori @ 2012-11-06 9:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5097D93E.10403@ti.com>
On 11/5/2012 8:50 PM, Murali Karicheri wrote:
> On 11/03/2012 08:35 AM, Sekhar Nori wrote:
>> On 10/25/2012 9:41 PM, Murali Karicheri wrote:
>>> This is the common clk driver initialization functions for DaVinci
>>> SoCs and other SoCs that uses similar hardware architecture.
>>> clock.h also defines struct types for clock definitions in a SoC
>>> and clock data type for configuring clk-mux. The initialization
>>> functions are used by clock initialization code in a specific
>>> platform/SoC.
>>>
>>> Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
>>> ---
>>> drivers/clk/davinci/clock.c | 112
>>> +++++++++++++++++++++++++++++++++++++++++++
>>> drivers/clk/davinci/clock.h | 80 +++++++++++++++++++++++++++++++
>>> 2 files changed, 192 insertions(+)
>>> create mode 100644 drivers/clk/davinci/clock.c
>>> create mode 100644 drivers/clk/davinci/clock.h
>>>
>>> diff --git a/drivers/clk/davinci/clock.c b/drivers/clk/davinci/clock.c
>>> new file mode 100644
>>> index 0000000..ad02149
>>> --- /dev/null
>>> +++ b/drivers/clk/davinci/clock.c
>>> @@ -0,0 +1,112 @@
>>> +/*
>>> + * clock.c - davinci clock initialization functions for various clocks
>>> + *
>>> + * Copyright (C) 2006-2012 Texas Instruments.
>>> + * Copyright (C) 2008-2009 Deep Root Systems, LLC
>>> + *
>>> + * 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/clk-provider.h>
>>> +#include <linux/clkdev.h>
>>> +#include <linux/io.h>
>>> +#include <linux/slab.h>
>>> +
>>> +#include "clk-pll.h"
>>> +#include "clk-psc.h"
>>> +#include "clk-div.h"
>>> +#include "clock.h"
>>> +
>>> +static DEFINE_SPINLOCK(_lock);
>>> +
>>> +#ifdef CONFIG_CLK_DAVINCI_PLL
>>> +struct clk *davinci_pll_clk(const char *name, const char *parent,
>>> + u32 phys_pllm, u32 phys_prediv, u32 phys_postdiv,
>>> + struct clk_pll_data *pll_data)
>>> +{
>>> + struct clk *clkp = NULL;
>>> +
>>> + pll_data->reg_pllm = ioremap(phys_pllm, 4);
>>> + if (WARN_ON(!pll_data->reg_pllm))
>>> + return clkp;
>> I would prefer ERR_PTR(-ENOMEM) here. Same comment applies to other
>> instances elsewhere in the patch.
>>
>>> diff --git a/drivers/clk/davinci/clock.h b/drivers/clk/davinci/clock.h
>>> new file mode 100644
>>> index 0000000..73204b8
>>> --- /dev/null
>>> +++ b/drivers/clk/davinci/clock.h
>>> @@ -0,0 +1,80 @@
>>> +/*
>>> + * TI DaVinci Clock definitions - Contains Macros and Types used for
>>> + * defining various clocks on a DaVinci SoC
>>> + *
>>> + * Copyright (C) 2012 Texas Instruments
>>> + *
>>> + * 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 __DAVINCI_CLOCK_H
>>> +#define __DAVINCI_CLOCK_H
>>> +
>>> +#include <linux/types.h>
>>> +
>>> +/* general flags: */
>>> +#define ALWAYS_ENABLED BIT(0)
>> This is not used in this patch. Can you add the define along with its
>> usage so it is immediately clear why you need it?
> This is used on the next patch as this adds a bunch of utilities or
> types for the platform specific clock code. Do you want to combine this
> patch with 05/11? It will become a bigger patch then? Is that fine.
> IMO, this is a logical group that can be a standalone patch than
> combining with 05/11.
It is more important to divide patches in logical functional blocks
rather than split it based on files. Reading this patch, I have no idea
what that define is for.
Thanks,
Sekhar
^ permalink raw reply
* [RFC patch v3 3/4] ASoC: atmel-ssc-dai: register dai and pcm directly
From: Bo Shen @ 2012-11-06 9:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121106084814.GC5044@opensource.wolfsonmicro.com>
On 11/6/2012 16:48, Mark Brown wrote:
> On Tue, Nov 06, 2012 at 01:57:53PM +0800, Bo Shen wrote:
>
>> static struct platform_device at91sam9260_ssc_device = {
>> - .name = "at91rm9200_ssc",
>> + .name = "at91rm9200_ssc_dai",
>> .id = 0,
>> .dev = {
>
> 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.
> 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.
BRs,
Bo Shen
^ permalink raw reply
* [PATCH] ARM: tegra: retain L2 content over CPU suspend/resume
From: Joseph Lo @ 2012-11-06 9:32 UTC (permalink / raw)
To: linux-arm-kernel
The L2 RAM is in different power domain from the CPU cluster. So the
L2 content can be retained over CPU suspend/resume. To do that, we
need to disable L2 after the MMU is disabled, and enable L2 before
the MMU is enabled. But the L2 controller is in the same power domain
with the CPU cluster. We need to restore it's settings and re-enable
it after the power be resumed.
Signed-off-by: Joseph Lo <josephl@nvidia.com>
---
arch/arm/mach-tegra/common.c | 6 +++++-
arch/arm/mach-tegra/headsmp.S | 11 +++++++++++
arch/arm/mach-tegra/pm.c | 2 --
arch/arm/mach-tegra/pm.h | 2 ++
arch/arm/mach-tegra/sleep.S | 7 +++++++
arch/arm/mach-tegra/sleep.h | 28 ++++++++++++++++++++++++++++
6 files changed, 53 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-tegra/common.c b/arch/arm/mach-tegra/common.c
index 35b7dd3..c25746e 100644
--- a/arch/arm/mach-tegra/common.c
+++ b/arch/arm/mach-tegra/common.c
@@ -36,6 +36,7 @@
#include "pmc.h"
#include "apbio.h"
#include "sleep.h"
+#include "pm.h"
/*
* Storage for debug-macro.S's state.
@@ -117,6 +118,7 @@ static __initdata struct tegra_clk_init_table tegra30_clk_init_table[] = {
static void __init tegra_init_cache(void)
{
#ifdef CONFIG_CACHE_L2X0
+ int ret;
void __iomem *p = IO_ADDRESS(TEGRA_ARM_PERIF_BASE) + 0x3000;
u32 aux_ctrl, cache_type;
@@ -124,7 +126,9 @@ static void __init tegra_init_cache(void)
aux_ctrl = (cache_type & 0x700) << (17-8);
aux_ctrl |= 0x6C000001;
- l2x0_of_init(aux_ctrl, 0x8200c3fe);
+ ret = l2x0_of_init(aux_ctrl, 0x8200c3fe);
+ if (!ret)
+ l2x0_saved_regs_addr = virt_to_phys(&l2x0_saved_regs);
#endif
}
diff --git a/arch/arm/mach-tegra/headsmp.S b/arch/arm/mach-tegra/headsmp.S
index 82dc84b..4a317fa 100644
--- a/arch/arm/mach-tegra/headsmp.S
+++ b/arch/arm/mach-tegra/headsmp.S
@@ -2,6 +2,8 @@
#include <linux/init.h>
#include <asm/cache.h>
+#include <asm/asm-offsets.h>
+#include <asm/hardware/cache-l2x0.h>
#include "flowctrl.h"
#include "iomap.h"
@@ -113,10 +115,19 @@ ENTRY(tegra_resume)
str r1, [r0]
#endif
+ /* L2 cache resume & re-enable */
+ l2_cache_resume r0, r1, r2, l2x0_saved_regs_addr
+
b cpu_resume
ENDPROC(tegra_resume)
#endif
+#ifdef CONFIG_CACHE_L2X0
+ .globl l2x0_saved_regs_addr
+l2x0_saved_regs_addr:
+ .long 0
+#endif
+
.align L1_CACHE_SHIFT
ENTRY(__tegra_cpu_reset_handler_start)
diff --git a/arch/arm/mach-tegra/pm.c b/arch/arm/mach-tegra/pm.c
index 1460c3d..1b11707 100644
--- a/arch/arm/mach-tegra/pm.c
+++ b/arch/arm/mach-tegra/pm.c
@@ -207,11 +207,9 @@ void tegra_idle_lp2_last(u32 cpu_on_time, u32 cpu_off_time)
cpu_cluster_pm_enter();
suspend_cpu_complex();
- outer_disable();
cpu_suspend(PHYS_OFFSET - PAGE_OFFSET, &tegra_sleep_cpu);
- outer_resume();
restore_cpu_complex();
cpu_cluster_pm_exit();
}
diff --git a/arch/arm/mach-tegra/pm.h b/arch/arm/mach-tegra/pm.h
index 512345c..787335c 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_
+extern unsigned long l2x0_saved_regs_addr;
+
void save_cpu_arch_register(void);
void restore_cpu_arch_register(void);
diff --git a/arch/arm/mach-tegra/sleep.S b/arch/arm/mach-tegra/sleep.S
index 88f4de9..26afa7c 100644
--- a/arch/arm/mach-tegra/sleep.S
+++ b/arch/arm/mach-tegra/sleep.S
@@ -27,6 +27,7 @@
#include <asm/assembler.h>
#include <asm/cache.h>
#include <asm/cp15.h>
+#include <asm/hardware/cache-l2x0.h>
#include "iomap.h"
@@ -98,6 +99,12 @@ ENTRY(tegra_shut_off_mmu)
dsb
mcr p15, 0, r3, c1, c0, 0
isb
+#ifdef CONFIG_CACHE_L2X0
+ /* Disable L2 cache */
+ mov32 r4, TEGRA_ARM_PERIF_BASE + 0x3000
+ mov r5, #0
+ str r5, [r4, #L2X0_CTRL]
+#endif
mov pc, r0
ENDPROC(tegra_shut_off_mmu)
.popsection
diff --git a/arch/arm/mach-tegra/sleep.h b/arch/arm/mach-tegra/sleep.h
index 6e1b949..45d4d08 100644
--- a/arch/arm/mach-tegra/sleep.h
+++ b/arch/arm/mach-tegra/sleep.h
@@ -71,6 +71,34 @@
str \tmp2, [\tmp1] @ invalidate SCU tags for CPU
dsb
.endm
+
+/* Macro to resume & re-enable L2 cache */
+#ifdef CONFIG_CACHE_L2X0
+.macro l2_cache_resume, tmp1, tmp2, tmp3, phys_l2x0_saved_regs
+ adr \tmp1, \phys_l2x0_saved_regs
+ ldr \tmp1, [\tmp1]
+ ldr \tmp2, [\tmp1, #L2X0_R_PHY_BASE]
+ ldr \tmp3, [\tmp2, #L2X0_CTRL]
+ tst \tmp3, #L2X0_CTRL_EN
+ bne exit_l2_resume
+ ldr \tmp3, [\tmp1, #L2X0_R_TAG_LATENCY]
+ str \tmp3, [\tmp2, #L2X0_TAG_LATENCY_CTRL]
+ ldr \tmp3, [\tmp1, #L2X0_R_DATA_LATENCY]
+ str \tmp3, [\tmp2, #L2X0_DATA_LATENCY_CTRL]
+ ldr \tmp3, [\tmp1, #L2X0_R_PREFETCH_CTRL]
+ str \tmp3, [\tmp2, #L2X0_PREFETCH_CTRL]
+ ldr \tmp3, [\tmp1, #L2X0_R_PWR_CTRL]
+ str \tmp3, [\tmp2, #L2X0_POWER_CTRL]
+ ldr \tmp3, [\tmp1, #L2X0_R_AUX_CTRL]
+ str \tmp3, [\tmp2, #L2X0_AUX_CTRL]
+ mov \tmp3, #L2X0_CTRL_EN
+ str \tmp3, [\tmp2, #L2X0_CTRL]
+exit_l2_resume:
+.endm
+#else /* CONFIG_CACHE_L2X0 */
+.macro l2_cache_resume, tmp1, tmp2, tmp3, phys_l2x0_saved_regs
+.endm
+#endif /* CONFIG_CACHE_L2X0 */
#else
void tegra_resume(void);
int tegra_sleep_cpu_finish(unsigned long);
--
1.7.0.4
^ permalink raw reply related
* [PATCH 12/15] ARM: OMAP: timer: Add suspend-resume callbacks for clockevent device
From: Bedia, Vaibhav @ 2012-11-06 9:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50982DB2.4000104@ti.com>
Hi Jon,
On Tue, Nov 06, 2012 at 02:50:50, Hunter, Jon wrote:
[...]
>
> Why is this? How is the dmtimer TIOCP_CFG register configured on AM33xx?
> Is it using smart-idle?
>
Yes, it is set to smart-idle with wakeup capable mode. (this needs a fixup
since this timer is not wakeup capable) but unfortunately this is not
sufficient. On AM33xx there's no HW_AUTO mode magic so unless the IPs in
PER domain are disabled by s/w, PER domain can't transition.
> > The next one is that
> > the clockevent doesn't generate any further interrupts once the
> > system resumes. We need to restore the pre-suspend configuration.
> > I haven't tried but I guess we could have used the save and restore
> > of timer registers here.
>
> It would be interesting to try using an non-wakeup domain timer on
> OMAP3/4 for clock events and seeing if suspend/resume works.
>
> Do you know what the exact problem here is? I understand that the timer
> context could get lost, but exactly what is not getting restarted by the
> kernel? For example, the only place we set the interrupt enable is
> during the clock event init and so if the context is lost, then I could
> see no more interrupts occurring. So is it enough to just restore the
> interrupt enable register, do you really need to program the timer again?
>
Just restoring the interrupt enable register works. But since there's no logic
retention I think a context save-restore would be better.
Regards,
Vaibhav
^ permalink raw reply
* [PATCH v3 05/11] clk: davinci - add dm644x clock initialization
From: Sekhar Nori @ 2012-11-06 9:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50984A6A.8050505@ti.com>
On 11/6/2012 4:53 AM, 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? 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.
>>
>>> Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
>>> ---
>>> drivers/clk/davinci/dm644x-clock.c | 304
>>> ++++++++++++++++++++++++++++++++++++
>>> drivers/clk/davinci/pll.h | 83 ++++++++++
>>> drivers/clk/davinci/psc.h | 215 +++++++++++++++++++++++++
>>> 3 files changed, 602 insertions(+)
>>> create mode 100644 drivers/clk/davinci/dm644x-clock.c
>>> create mode 100644 drivers/clk/davinci/pll.h
>>> create mode 100644 drivers/clk/davinci/psc.h
>>>
>>> +/* all clocks available in DM644x SoCs */
>>> +enum dm644x_clk {
>>> + clkin, oscin, ref_clk_mux, pll1, pll1_plldiv_clk_mux, auxclk,
>>> + clk_pll1_sysclk1, clk_pll1_sysclk2, clk_pll1_sysclk3,
>>> clk_pll1_sysclk4,
>>> + clk_pll1_sysclk5, clk_pll1_sysclkbp, pll2, pll2_plldiv_clk_mux,
>>> + clk_pll2_sysclk1, clk_pll2_sysclk2, clk_pll2_sysclkbp, dsp, arm,
>>> vicp,
>>> + vpss_master, vpss_slave, uart0, uart1, uart2, emac, i2c, ide, asp,
>>> + mmcsd, spi, gpio, usb, vlynq, aemif, pwm0, pwm1, pwm2, timer0,
>>> timer1,
>>> + timer2, clk_max
>>> +};
>>> +
>>> +static struct davinci_clk *psc_clocks[] = {
>>> + &clk_dsp, &clk_arm, &clk_vicp, &clk_vpss_master, &clk_vpss_slave,
>>> + &clk_uart0, &clk_uart1, &clk_uart2, &clk_emac, &clk_i2c, &clk_ide,
>>> + &clk_asp0, &clk_mmcsd, &clk_spi, &clk_gpio, &clk_usb, &clk_vlynq,
>>> + &clk_aemif, &clk_pwm0, &clk_pwm1, &clk_pwm2, &clk_timer0,
>>> &clk_timer1,
>>> + &clk_timer2
>>> +};
>> You rely on perfect order between this array and dm644x_clk enum above.
>> Can you initialize this array using the enum as the index so that it is
>> clear. Current method is too error prone.
> Are you expecting something like this?
>
> static struct davinci_clk *psc_clocks[] = {
> [dsp - dsp] = &clk_dsp,
> [arm - dsp] = &clk_arm,
> [vicp - dsp] = &clk_vicp,
> [vpss_maste - dsp] = &clk_vpss_master,
> [vpss_slave - dsp] = &clk_vpss_slave,
> [uart0 - dsp] = &clk_uart0,
> [uart1 - dsp] = &clk_uart1,
Well, sort of! But the '- dsp' is really ugly. You can either define the
array for the full list of clocks (like 'clks') or move the psc clocks
to the beginning of the enum (less preferable to me).
Thanks,
Sekhar
^ permalink raw reply
* scheduler clock for MXS
From: Russell King - ARM Linux @ 2012-11-06 9:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5098CB9F.9030401@meduna.org>
On Tue, Nov 06, 2012 at 09:34:39AM +0100, Stanislav Meduna wrote:
> On 05.11.2012 23:28, Russell King - ARM Linux wrote:
>
> > It most certainly does handle the wrapping correctly - it was designed
> > to from the very start.
>
> I'm not an expert on Linux kernel and its core infrastructure,
> but how is the sched_clock_timer armed for the first time
> after calling setup_sched_clock?
>
> The explicitely called update_sched_clock() does _not_ arm it.
Correct, but sched_clock_postinit() does, which is called from time_init().
^ permalink raw reply
* 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
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