On Wed, Sep 23, 2015 at 5:44 AM, Dave Gerlach wrote:
> The mailbox framework controls the transmission queue and requires
> either its controller implementations or clients to run the state
> machine for the Tx queue. The OMAP mailbox controller uses a Tx-ready
> interrupt as the equivalent of a T
AM437x-based boards, can use omap4_local_timer_init()
just fine. Let's use that instead.
Signed-off-by: Felipe Balbi
---
arch/arm/mach-omap2/board-generic.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generi
Signed-off-by: Adam Ford
---
arch/arm/boot/dts/logicpd-torpedo-37xx-devkit.dts | 10 ++
arch/arm/boot/dts/logicpd-torpedo-som.dtsi| 13 +
2 files changed, 23 insertions(+)
diff --git a/arch/arm/boot/dts/logicpd-torpedo-37xx-devkit.dts
b/arch/arm/boot/dts/logicpd-torp
The following changes since commit be146412501bc2ed49183637605da97f47125696:
ARM: dts: omap3-igep: Use OMAP3_CORE1_IOPAD pinmux macro (2015-10-14 12:28:13
-0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap
tags/omap-for-v4.4/dt-pt
The following changes since commit d8e1f5ed11a39a68da00f05000466c4f6db4456e:
Documentation: ARM: List new omap MMC requirements (2015-10-12 16:23:34 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap
tags/omap-for-v4.3/fixes-rc6
f
* H. Nikolaus Schaller [151020 09:48]:
>
> We have our own OMAP5 board in the pipeline and there it will help
> as well to rebase it using arch/arm/boot/dts/omap5-board-common.dts
Yes and then we can hopefully fix up the regulators properly and get
rid of the fixed-regulator flags..
Regards,
T
* Javier Martinez Canillas [151020 10:26]:
>
> Thanks, I'm planning to convert the remaining OMAP dts but I'm quite busy
> this week and traveling the next one so that would have to wait for v4.5
OK sounds good to me.
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap"
* Keerthy [151018 21:44]:
> On Friday 16 October 2015 11:18 PM, Tony Lindgren wrote:
> >
> >I decided to rework the earlier patches by Keerthy
> >to keep changes down to minimum to avoid potential errors and stick
> >to just search and replace.
> >
>
> Compile tested individual SoC Configs and b
Hello Tony,
On 10/20/2015 06:26 PM, Tony Lindgren wrote:
> * Javier Martinez Canillas [151019 08:39]:
>> Hello,
>>
>> This series use the IOPAD pinmux macros for the remaining IGEP boards that
>> still used the register offset instead of the physical address using these
>> macros so the DTS match
Hi,
Am 20.10.2015 um 18:24 schrieb Tony Lindgren :
> Hi,
>
> * H. Nikolaus Schaller [151016 05:58]:
>> Signed-off-by: H. Nikolaus Schaller
>> ---
>> arch/arm/boot/dts/omap5-uevm.dts | 10 ++
>> 1 file changed, 10 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/omap5-uevm.dts
>> b/a
On Tue, Oct 20, 2015 at 07:14:28PM +0300, Aaro Koskinen wrote:
> Hi,
>
> On Tue, Oct 20, 2015 at 05:05:24PM +0100, Russell King - ARM Linux wrote:
> > On Tue, Oct 20, 2015 at 10:07:00AM +0100, Russell King - ARM Linux wrote:
> > > On Tue, Oct 20, 2015 at 11:50:03AM +0300, Aaro Koskinen wrote:
> >
* Javier Martinez Canillas [151019 08:39]:
> Hello,
>
> This series use the IOPAD pinmux macros for the remaining IGEP boards that
> still used the register offset instead of the physical address using these
> macros so the DTS matches what is in the Technical Reference Manual.
>
> The changes a
Hi,
* H. Nikolaus Schaller [151016 05:58]:
> Signed-off-by: H. Nikolaus Schaller
> ---
> arch/arm/boot/dts/omap5-uevm.dts | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/arch/arm/boot/dts/omap5-uevm.dts
> b/arch/arm/boot/dts/omap5-uevm.dts
> index 0e8128b..63f81bb 100644
* Vignesh R [151014 06:59]:
> On am437x-gp-evm, pixcir_i2c_ts can wakeup the system from low power
> state via pinctrl and IO daisy chain using generic wakeirq framework.
> With commit 3fffd1283927 ("i2c: allow specifying separate wakeup
> interrupt in device tree") i2c core allows optional wakeir
Hi all,
* Dave Gerlach [150922 17:20]:
> Hi,
> This series is version 3 of the code to introduce a wkup_m3_ipc driver
> to handle communication between the MPU and Cortex M3 present on TI AM335x
> and AM437x SoCs. v2 of this series can be found at [1]. Only patch 3
> has been changed based on a r
* Javier Martinez Canillas [151014 03:05]:
> I see that people are still sending emails to my old address (that no
> longer exists) since is the one mentioned in the IGEP DTS. Replace it
> with my current email address to avoid this.
Applying this into omap-for-v4.4/dt thanks.
Tony
--
To unsubsc
* Mugunthan V N [150921 07:58]:
> With the current implementation of GPIO hogging and with
> gpio-pcf857x is built as module, ethernet doesn't work on boot
> and doesn't throw any error/warning to user. Ethernet becomes
> operational when inserting gpio-pcf857x module, even this time
> there is no
Hi,
On Tue, Oct 20, 2015 at 05:05:24PM +0100, Russell King - ARM Linux wrote:
> On Tue, Oct 20, 2015 at 10:07:00AM +0100, Russell King - ARM Linux wrote:
> > On Tue, Oct 20, 2015 at 11:50:03AM +0300, Aaro Koskinen wrote:
> > > On Mon, Oct 19, 2015 at 11:50:33PM +0100, Russell King - ARM Linux wrot
On Tue, Oct 20, 2015 at 10:07:00AM +0100, Russell King - ARM Linux wrote:
> On Tue, Oct 20, 2015 at 11:50:03AM +0300, Aaro Koskinen wrote:
> > On Mon, Oct 19, 2015 at 11:50:33PM +0100, Russell King - ARM Linux wrote:
> > > It shouldn't (I've been through the resulting assembly code.) I wonder
> >
* Pau Pajuel [151020 03:34]:
> 2015-10-19 16:50 GMT+02:00 Tony Lindgren :
> >
> > My guess is that you need to play with initrd_high etc, try doing something
> > like this in u-boot:
> >
> > setenv fdtaddr 80a0
> > setenv loadaddr 80c0
> > setenv rdaddr 8140
> > setenv fdt_high 8c0
On 20.10.2015 18:20, Marc Kleine-Budde wrote:
> On 10/20/2015 05:18 PM, Marc Kleine-Budde wrote:
>> On 10/20/2015 05:09 PM, Anton.Glukhov wrote:
> It's OMAP3 based arch, but HECC is implemented only in AM3505 and AM3517
> SoCs.
> So, I'm confused about what's "name" should I use.
>>>
On 10/20/2015 05:18 PM, Marc Kleine-Budde wrote:
> On 10/20/2015 05:09 PM, Anton.Glukhov wrote:
It's OMAP3 based arch, but HECC is implemented only in AM3505 and AM3517
SoCs.
So, I'm confused about what's "name" should I use.
>>>
>>> Which SoC was available first? Pick that.
>
>> W
On 10/20/2015 05:09 PM, Anton.Glukhov wrote:
>>> It's OMAP3 based arch, but HECC is implemented only in AM3505 and AM3517
>>> SoCs.
>>> So, I'm confused about what's "name" should I use.
>>
>> Which SoC was available first? Pick that.
> What do you mean available? I know only that HECC appear in
On 10/20/2015 04:57 PM, Anton.Glukhov wrote:
> Hello Marc, Heiko!
> I'm sorry for the delay!
>
> On 19.10.2015 10:31, Marc Kleine-Budde wrote:
>> On 10/19/2015 09:27 AM, Heiko Schocher wrote:
> .../devicetree/bindings/net/can/ti_hecc-can.txt| 20 ++
> arch/arm/boot/dts/am351
On 20.10.2015 18:05, Marc Kleine-Budde wrote:
> On 10/20/2015 04:57 PM, Anton.Glukhov wrote:
>> Hello Marc, Heiko!
>> I'm sorry for the delay!
>>
>> On 19.10.2015 10:31, Marc Kleine-Budde wrote:
>>> On 10/19/2015 09:27 AM, Heiko Schocher wrote:
>> .../devicetree/bindings/net/can/ti_hecc-can
Hello Marc, Heiko!
I'm sorry for the delay!
On 19.10.2015 10:31, Marc Kleine-Budde wrote:
> On 10/19/2015 09:27 AM, Heiko Schocher wrote:
.../devicetree/bindings/net/can/ti_hecc-can.txt| 20 ++
arch/arm/boot/dts/am3517.dtsi | 13 +++
drivers/
* John Ogness [151020 00:33]:
> On 2015-10-20, Sekhar Nori wrote:
> >> Do you know what really is causing the spurious interrupts in your
> >> case?
> >
> > No, not yet.
>
> According to the TRM this is normal behavior if conditions that might
> affect priority are changed during priority sortin
Hi,
* Aaro Koskinen [151020 01:51]:
>
> With newer kernels and this fix the kernel now hangs during FB
> initialization. I tried to bisect it and it seemed to point to OMAP1
> sparse IRQ changes. Unfortunately those are difficult to test because
> e.g. commit 685e2d08c54b1a1bf31bbe6562f06db089d3
On Tue, Oct 20, 2015 at 05:40:00AM -0700, Michael Turquette wrote:
> Why not keep the reference to the struct clk after get'ing it the first
> time?
Yes, that's exactly what you're supposed to do in this case.
--
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to
Hi Tony,
2015-10-19 16:50 GMT+02:00 Tony Lindgren :
> * Pau Pajuel [151019 06:40]:
>> Hi Tony,
>> 2015-10-16 16:57 GMT+02:00 Tony Lindgren :
>> > >
>> > > So far I've tested that basic things work, such as serial, USB
>> > > Ethernet, HDMI and WLAN.
>
> Also mSATA works too BTW.
>
>> I am testing
On Tue, Oct 20, 2015 at 11:50:03AM +0300, Aaro Koskinen wrote:
> On Mon, Oct 19, 2015 at 11:50:33PM +0100, Russell King - ARM Linux wrote:
> > It shouldn't (I've been through the resulting assembly code.) I wonder
> > if this is fixing the problem, but it's now failing elsewhere instead.
> >
> >
On Mon, Oct 19, 2015 at 11:50:33PM +0100, Russell King - ARM Linux wrote:
> It shouldn't (I've been through the resulting assembly code.) I wonder
> if this is fixing the problem, but it's now failing elsewhere instead.
>
> What happens if you change it to:
>
> l = clkdev_create(r, alias,
On Fri, 16 Oct 2015, Roger Quadros wrote:
> On 15/10/15 19:27, Franklin S Cooper Jr wrote:
> > ELM address information is provided by device tree. No longer need
> > to include this information within hwmod.
> >
> > Signed-off-by: Franklin S Cooper Jr
>
> Acked-by: Roger Quadros
Thanks, queue
On Fri, 16 Oct 2015, Roger Quadros wrote:
> On 15/10/15 19:27, Franklin S Cooper Jr wrote:
> > GPMC address information is provided by device tree. No longer need
> > to include this information within hwmod.
> >
> > Signed-off-by: Franklin S Cooper Jr
>
> Acked-by: Roger Quadros
Thanks, queu
On 2015-10-20, Sekhar Nori wrote:
>> Do you know what really is causing the spurious interrupts in your
>> case?
>
> No, not yet.
According to the TRM this is normal behavior if conditions that might
affect priority are changed during priority sorting.
6.2.5 ARM A8 INTC Spurious Interrupt Ha
35 matches
Mail list logo