Re: [PATCH 2/2] memory: omap-gpmc: Add Kconfig option for debug

[Tony Lindgren]

* Sebastian Reichel <s...@kernel.org> [160106 09:41]:
> Hi,
> 
> On Tue, Jan 05, 2016 at 02:49:29PM -0800, Tony Lindgren wrote:
> > Commit 63aa945b1013 ("memory: omap-gpmc: Add Kconfig option for debug")
> > unified the GPMC debug for the SoCs with GPMC. The commit also left
> > out the option for HWMOD_INIT_NO_RESET as we now require proper timings
> > for GPMC to be able to remap GPMC devices out of address 0.
> > 
> > Unfortunately on 900, onenand now only partially works with the device
> 
> You may want to change 900 to n900 (maybe even Nokia N900) before
> actually committing this.

Thanks will do.

Tony


--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] memory: omap-gpmc: Add Kconfig option for debug

[Tony Lindgren]

* Ivaylo Dimitrov  [160106 10:01]:
> 
> Unfortunately, it seems there is more to be fixed. It booted several times
> to the userspace, but after a couple of shutdowns, rootfs became corrupted
> again. I flashed, installed linux 4.4, but the same happened after the first
> shutdown with 4.4:

Hmm. Care to verify that your onenand really gets detected at 83 MHz like
your earlier logs show? Below is a patch that should show it.

Also, do things now work reliably for you with CONFIG_OMAP_GPMC_DEBUG
enabled? Or does that also produce corruption after few reboots?

Regards,

Tony

8< --
--- a/arch/arm/mach-omap2/gpmc-onenand.c
+++ b/arch/arm/mach-omap2/gpmc-onenand.c
@@ -153,6 +153,8 @@ static int omap2_onenand_get_freq(struct 
omap_onenand_platform_data *cfg,
freq = 0;
}
 
+   pr_info("onenand rate detected: %i\n", freq);
+
return freq;
 }
 
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] memory: omap-gpmc: Add Kconfig option for debug

[Tony Lindgren]

* Pali Rohár <pali.ro...@gmail.com> [160106 01:06]:
> On Wednesday 06 January 2016 10:55:51 Ivaylo Dimitrov wrote:
> > On  6.01.2016 00:49, Tony Lindgren wrote:
> > >
> > >Suggested fix below, please test and reply with your Tested-by's if
> > >it solves the problem so we may still be able to get this into v4.4.
> > >
> > >8< ---
> > >From: Tony Lindgren <t...@atomide.com>
> > >Date: Tue, 5 Jan 2016 12:04:20 -0800
> > >Subject: [PATCH] ARM: OMAP2+: Fix onenand rate detection to avoid 
> > >filesystem
> > >  corruption
> > >
> > >Commit 63aa945b1013 ("memory: omap-gpmc: Add Kconfig option for debug")
> > >unified the GPMC debug for the SoCs with GPMC. The commit also left
> > >out the option for HWMOD_INIT_NO_RESET as we now require proper timings
> > >for GPMC to be able to remap GPMC devices out of address 0.
> > >
> > >Unfortunately on 900, onenand now only partially works with the device
> > >tree provided timings. It works enough to get detected but the clock
> > >rate supported by the onenand chip gets misdetected. This in turn causes
> > >the GPMC timings to be miscalculated and this leads into file system
> > >corruption on n900.
> > >
> > >Looks like onenand needs CS_CONFIG1 bit 27 WRITETYPE set for for sync
> > >write. This is needed also for async timings when we write to onenand
> > >with omap2_onenand_set_async_mode(). Without sync write bit set, the
> > >async read for the onenand ONENAND_REG_VERSION_ID will return 0xfff.
> > >
> > >Let's exit with an error if onenand rate is not detected. And let's
> > >remove the extra call to omap2_onenand_set_async_mode() as we only
> > >need to do this once at the end of omap2_onenand_setup_async().
> > >
> > >Reported-by: Ivaylo Dimitrov <ivo.g.dimitrov...@gmail.com>
> > >Signed-off-by: Tony Lindgren <t...@atomide.com>
> > >
> > >--- a/arch/arm/mach-omap2/gpmc-onenand.c
> > >+++ b/arch/arm/mach-omap2/gpmc-onenand.c
> > 
> > Bellow is gpmc dmesg output with that fix. I also disabled
> > CONFIG_OMAP_GPMC_DEBUG and am still able to boot to maemo with no obvious
> > problems.
> > 
> > So, seems that fixes the problem, feel free to  add:
> > 
> > Tested-by: Ivaylo Dimitrov <ivo.g.dimitrov...@gmail.com>
> 
> Great! Thank you for fixing and testing this problem!

Good to hear it fixes the issue. I'll wait to hear from Aaro before
committing.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery

[Tony Lindgren]

* H. Nikolaus Schaller <h...@goldelico.com> [160106 08:48]:
> Hi Tony,
> 
> Am 06.01.2016 um 17:41 schrieb Tony Lindgren <t...@atomide.com>:
> 
> > Hi,
> > 
> > * H. Nikolaus Schaller <h...@goldelico.com> [160106 00:12]:
> >> Am 06.01.2016 um 02:00 schrieb Tony Lindgren <t...@atomide.com>:
> >>> 
> >>> Also I'm not seeing just zeroes coming from RTC after typing hwclock
> >>> on omap5-uevm. It's working on x15 though.
> >>> 
> >>> Nikolaus, is hwclock command working for you on omap5-uevm?
> >> 
> >> Well, yes and no. It appears it *was* working when tested last time
> >> (we sometimes have months of delay for submitting patches upstream).
> >> 
> >> I have found an SD image with 4.3-rc6 with this patch in the dtb and
> >> there it works. With 4.4-rc8 it does not work. hwclock command hangs for
> >> 10 seconds (I guess some timeout).
> >> 
> >> I have checked the dtb and in both cases it is interrupts = <8 0>;
> >> 
> >> xxd /sys/firmware/devicetree/base/ocp/i2c@4807/palmas@48/rtc/interrupts
> >> 000:  0008  
> >> 
> >> So I think something has changed in the rtc driver or somewhere else.
> > 
> > I just gave it a try on v4.3-rc6 with omap5-uevm.dts patched for
> > RTC, and I still don't have hwclock working with RTC.
> > 
> > It seems you have some additional patches there that make it work?
> 
> Hm. Not that I am aware of. We just did add the rtc nodes but did not
> touch palmas drivers (except adding the gpadc of this patch series).

OK

> > I guess it could also be a bootloader change if it's a different
> > SD image that works for you.
> 
> Yes, it is using a 2 years old U-Boot instead 2015.10 compiled from
> source. I will try to find out if it makes a difference.

OK. It could be also some .config change with something built-in?

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery

[Tony Lindgren]

Hi,

* H. Nikolaus Schaller <h...@goldelico.com> [160106 00:12]:
> Am 06.01.2016 um 02:00 schrieb Tony Lindgren <t...@atomide.com>:
> > 
> > Also I'm not seeing just zeroes coming from RTC after typing hwclock
> > on omap5-uevm. It's working on x15 though.
> > 
> > Nikolaus, is hwclock command working for you on omap5-uevm?
> 
> Well, yes and no. It appears it *was* working when tested last time
> (we sometimes have months of delay for submitting patches upstream).
> 
> I have found an SD image with 4.3-rc6 with this patch in the dtb and
> there it works. With 4.4-rc8 it does not work. hwclock command hangs for
> 10 seconds (I guess some timeout).
> 
> I have checked the dtb and in both cases it is interrupts = <8 0>;
> 
> xxd /sys/firmware/devicetree/base/ocp/i2c@4807/palmas@48/rtc/interrupts
> 000:  0008  
> 
> So I think something has changed in the rtc driver or somewhere else.

I just gave it a try on v4.3-rc6 with omap5-uevm.dts patched for
RTC, and I still don't have hwclock working with RTC.

It seems you have some additional patches there that make it work?

I guess it could also be a bootloader change if it's a different
SD image that works for you.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] memory: omap-gpmc: Add Kconfig option for debug

[Tony Lindgren]

* Pali Rohár <pali.ro...@gmail.com> [160105 00:50]:
> On Monday 04 January 2016 20:13:56 Tony Lindgren wrote:
> > * Ivaylo Dimitrov <ivo.g.dimitrov...@gmail.com> [160104 10:59]:
> > > Hi,
> > > 
> > > On  4.01.2016 19:40, Tony Lindgren wrote:
> > > >>On Monday 04 January 2016 18:02:06 Tony Lindgren wrote:
> > > >>>> >Care to boot with CONFIG_OMAP_GPMC_DEBUG=y and post the gpmc related
> > > >>>> >dmesg output?
> > > 
> > > Here it is, including the pre-gpmc log, keep in mind this is with restored
> > > HWMOD_INIT_NO_RESET flag so rootfs is functional and I can get dmesg 
> > > output
> > > from the syslog. Don't know if it is helpful :). Also, this device has
> > > Numonyx onenand (HW rev. 2204), unlike most of the others which have 
> > > Samsung
> > > onenand (HW rev. 2101 etc), no idea if it is relevant.
> > 
> > Thanks. I got the problem reproduced here too.
> > 
> > [1.915557] gpmc cs0 after gpmc_cs_set_timings:
> > [1.920410] cs0 GPMC_CS_CONFIG1: 0xfb001201
> > 
> > Looks like in the failing case the clock rates are not properly
> > calculated in GPMC and GPMCFCLKDIVIDER is set wrong in
> > GPMC_CS_CONFIG1. Need to look at it more to figure out what's the
> > best way to fix this.
> > 
> > Regards,
> > 
> > Tony
> 
> Hm... Maybe this problem is in U-Boot too?

Yeah maybe. Looks like we need sync write bit set also for async
timings for omap2_onenand_set_async_mode() to work to detect the
onenand rate for sync mode :)

Suggested fix below, please test and reply with your Tested-by's if
it solves the problem so we may still be able to get this into v4.4.

Regards,

Tony

8< ---
From: Tony Lindgren <t...@atomide.com>
Date: Tue, 5 Jan 2016 12:04:20 -0800
Subject: [PATCH] ARM: OMAP2+: Fix onenand rate detection to avoid filesystem
 corruption

Commit 63aa945b1013 ("memory: omap-gpmc: Add Kconfig option for debug")
unified the GPMC debug for the SoCs with GPMC. The commit also left
out the option for HWMOD_INIT_NO_RESET as we now require proper timings
for GPMC to be able to remap GPMC devices out of address 0.

Unfortunately on 900, onenand now only partially works with the device
tree provided timings. It works enough to get detected but the clock
rate supported by the onenand chip gets misdetected. This in turn causes
the GPMC timings to be miscalculated and this leads into file system
corruption on n900.

Looks like onenand needs CS_CONFIG1 bit 27 WRITETYPE set for for sync
write. This is needed also for async timings when we write to onenand
with omap2_onenand_set_async_mode(). Without sync write bit set, the
async read for the onenand ONENAND_REG_VERSION_ID will return 0xfff.

Let's exit with an error if onenand rate is not detected. And let's
remove the extra call to omap2_onenand_set_async_mode() as we only
need to do this once at the end of omap2_onenand_setup_async().

Reported-by: Ivaylo Dimitrov <ivo.g.dimitrov...@gmail.com>
Signed-off-by: Tony Lindgren <t...@atomide.com>

--- a/arch/arm/mach-omap2/gpmc-onenand.c
+++ b/arch/arm/mach-omap2/gpmc-onenand.c
@@ -149,8 +149,8 @@ static int omap2_onenand_get_freq(struct 
omap_onenand_platform_data *cfg,
freq = 104;
break;
default:
-   freq = 54;
-   break;
+   pr_err("onenand rate not detected, bad GPMC async timings?\n");
+   freq = 0;
}
 
return freq;
@@ -271,6 +271,11 @@ static int omap2_onenand_setup_async(void __iomem 
*onenand_base)
struct gpmc_timings t;
int ret;
 
+   /*
+* Note that we need to keep sync_write set for the call to
+* omap2_onenand_set_async_mode() to work to detect the onenand
+* supported clock rate for the sync timings.
+*/
if (gpmc_onenand_data->of_node) {
gpmc_read_settings_dt(gpmc_onenand_data->of_node,
  _async);
@@ -281,12 +286,9 @@ static int omap2_onenand_setup_async(void __iomem 
*onenand_base)
else
gpmc_onenand_data->flags |= ONENAND_SYNC_READ;
onenand_async.sync_read = false;
-   onenand_async.sync_write = false;
}
}
 
-   omap2_onenand_set_async_mode(onenand_base);
-
omap2_onenand_calc_async_timings();
 
ret = gpmc_cs_program_settings(gpmc_onenand_data->cs, _async);
@@ -310,6 +312,8 @@ static int omap2_onenand_setup_sync(void __iomem 
*onenand_base, int *freq_ptr)
if (!freq) {
/* Very first call freq is not known */
freq = omap2_onenand_get_freq(gpmc_onenand_data, onenand_base);
+   if (!freq)
+   return -ENODEV;
set_onenand_cfg(onenand_base);
}
 
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery

[Tony Lindgren]

* Nishanth Menon  [160105 15:40]:
> On 01/05/2016 06:01 AM, H. Nikolaus Schaller wrote:
> > tested on OMP5432 EVM
> > 
> > Signed-off-by: H. Nikolaus Schaller 
> > ---
> >  arch/arm/boot/dts/omap5-board-common.dtsi | 8 
> >  1 file changed, 8 insertions(+)
> > 
> > diff --git a/arch/arm/boot/dts/omap5-board-common.dtsi 
> > b/arch/arm/boot/dts/omap5-board-common.dtsi
> > index 5cf76a1..30c0d3b 100644
> > --- a/arch/arm/boot/dts/omap5-board-common.dtsi
> > +++ b/arch/arm/boot/dts/omap5-board-common.dtsi
> > @@ -358,6 +358,14 @@
> > #clock-cells = <0>;
> > };
> >  
> > +   rtc {
> > +   compatible = "ti,palmas-rtc";
> > +   interrupt-parent = <>;
> > +   interrupts = <8 IRQ_TYPE_NONE>;
> 
> IRQ_TYPE_NONE is not correct here -> it should have some polarity - if
> it had none, there'd be no interrupt, right?

Also I'm not seeing just zeroes coming from RTC after typing hwclock
on omap5-uevm. It's working on x15 though.

Nikolaus, is hwclock command working for you on omap5-uevm?

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Nokia N900: Broken lirc ir-rx51 driver

[Tony Lindgren]

* Pali Rohár <pali.ro...@gmail.com> [160105 02:19]:
> On Saturday 02 January 2016 09:06:57 Tony Lindgren wrote:
> >
> > Yup please take a look at thread "[PATCH 0/3] pwm: omap: Add PWM support
> > using dual-mode timers". Chances are we still need to set up the dmtimer
> > code to provide also irqchip functions. That way ir-rx51.c can just do
> > request_irq on the selected dmtimer for interrupts.
> 
> No I see that patch from that thread uses dmtimer.h from plat-omap. So
> it is really OK?

It's using the header to populate the platform data in mach-omap2 so
that's fine. But we do not want to directly expose the dmtimer functions
to device drivers as they are not Linux generic at this point.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] memory: omap-gpmc: Add Kconfig option for debug

[Tony Lindgren]

* Ivaylo Dimitrov <ivo.g.dimitrov...@gmail.com> [160104 10:59]:
> Hi,
> 
> On  4.01.2016 19:40, Tony Lindgren wrote:
> >>On Monday 04 January 2016 18:02:06 Tony Lindgren wrote:
> >>>> >Care to boot with CONFIG_OMAP_GPMC_DEBUG=y and post the gpmc related
> >>>> >dmesg output?
> 
> Here it is, including the pre-gpmc log, keep in mind this is with restored
> HWMOD_INIT_NO_RESET flag so rootfs is functional and I can get dmesg output
> from the syslog. Don't know if it is helpful :). Also, this device has
> Numonyx onenand (HW rev. 2204), unlike most of the others which have Samsung
> onenand (HW rev. 2101 etc), no idea if it is relevant.

Thanks. I got the problem reproduced here too.

[1.915557] gpmc cs0 after gpmc_cs_set_timings:
[1.920410] cs0 GPMC_CS_CONFIG1: 0xfb001201

Looks like in the failing case the clock rates are not properly
calculated in GPMC and GPMCFCLKDIVIDER is set wrong in
GPMC_CS_CONFIG1. Need to look at it more to figure out what's the
best way to fix this.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 6/9] clk: ti: add support for omap4 module clocks

[Tony Lindgren]

* Russell King - ARM Linux  [160104 06:43]:
> On Mon, Jan 04, 2016 at 03:27:57PM +0200, Tero Kristo wrote:
> > On 01/04/2016 12:21 PM, Geert Uytterhoeven wrote:
> > >FWIW, there are small loops with just a cpu_relax() in various clock 
> > >drivers
> > >under drivers/clk/shmobile/.
> > 
> > Just did a quick profiling round, and the clk_enable/disable delay loops
> > take anything from 0...1500ns, most typically consuming some 400-600ns. So,
> > based on this, dropping the udelay and adding cpu_relax instead looks like a
> > good change. I just verified that changing the udelay to cpu_relax works
> > fine also, I just need to change the bail-out period to be something sane.
> 
> Was that profiling done with lockdep/lock debugging enabled or disabled?

And also the thing to check from the hw folks is what all do these clkctrl
bits really control. If they group together the OCP clock and an extra
functional clock for some devices the delays could be larger.

In general, I think we need to get rid of pm_runtime_irq_safe usage to
allow clocks to sleep properly. The other option is to allow toggling
pm_runtime_irq_safe but that probably gets super messy.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] memory: omap-gpmc: Add Kconfig option for debug

[Tony Lindgren]

* Pali Rohár <pali.ro...@gmail.com> [160104 09:35]:
> On Monday 04 January 2016 18:02:06 Tony Lindgren wrote:
> > Care to boot with CONFIG_OMAP_GPMC_DEBUG=y and post the gpmc related
> > dmesg output?
> 
> Hi Tony. We do not have serial console for N900 and so when kernel is 
> not fully bootable to userspace we cannot provide dmesg for you :-(

OK

> Maybe something with simple initramfs could work, but really if you have 
> serial console for N900 it should be for you lot of easier to get it.

Yeah OK will take a look ASAP. Is this happening with both legacy
booting and dts based booting?

For testing, CONFIG_INITRAMFS_SOURCE etc allow building initramfs
that's appended to the kernel.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Nokia N900: twl4030-power different data in DTS and board code

[Tony Lindgren]

* Pali Rohár <pali.ro...@gmail.com> [160102 13:39]:
> On Saturday 02 January 2016 18:14:31 Tony Lindgren wrote:
> 
> > The n900 specific code was based on something before the TI generic
> > values were available I think. And the last time I looked at it I
> > came to the conclusion the n900 specific code is no better.
> 
> Hm... if generic values are better, why old values are still there (in 
> board n900 code)?

We never had PM working in a generic way for the legacy booting but
relied on board specific configuration instead for the ones that did
work. Probably not worth changing the board-*.c file configuration
unless you want to test that the new generic settings work.

> > Or did I miss something? Are you seeing some issues with PM with dts
> > based code?
> 
> I'm just asking why we have different code for DST and board...

OK. Yeah no reason beyond somebody taking the time to verify that the
generic settings work on n900 in legacy booting mode :)

> > We can certainly add it to twl4030-power if it provides something
> > that the "ti,twl4030-power-idle-osc-off" does not.
> 
> But do we need 'compatible = "ti,twl4030-power-n900"' specification in 
> omap3-n900.dts file at all?

Well that generally done to allow adding support for the board specific
configuration if needed with a fallback to the generic configuration.
That's used quite a bit, for example boards typically set the compatible
to the specific board but still end up booting with a generic one
sucha as "ti,omap3".

Regards,

Tony


--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] memory: omap-gpmc: Add Kconfig option for debug

[Tony Lindgren]

* Ivaylo Dimitrov <ivo.g.dimitrov...@gmail.com> [160101 03:29]:
> Hi Tony,
> 
> On 21.05.2015 00:21, Tony Lindgren wrote:
> >We support decoding the bootloader values if DEBUG is defined.
> >But we also need to change the struct omap_hwmod flags to have
> >HWMOD_INIT_NO_RESET to avoid the GPMC being reset during the
> >boot. Otherwise just the default timings will be displayed
> >instead of the bootloader configured timings.
> >
> >This also allows us to clean up the various GPMC related
> >hwmod flags. For debugging, we only need HWMOD_INIT_NO_RESET,
> >and HWMOD_INIT_NO_IDLE is not needed.
> >
> >Cc: Brian Hutchinson <b.hutch...@gmail.com>
> >Cc: Paul Walmsley <p...@pwsan.com>
> >Cc: Roger Quadros <rog...@ti.com>
> >Signed-off-by: Tony Lindgren <t...@atomide.com>
> >---
> >  arch/arm/mach-omap2/omap_hwmod.h|  6 ++
> >  arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c  | 12 ++--
> >  arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c |  3 ++-
> >  arch/arm/mach-omap2/omap_hwmod_3xxx_data.c  | 12 ++--
> >  arch/arm/mach-omap2/omap_hwmod_44xx_data.c  | 11 ++-
> >  arch/arm/mach-omap2/omap_hwmod_7xx_data.c   |  4 ++--
> >  arch/arm/mach-omap2/omap_hwmod_81xx_data.c  |  2 ++
> >  drivers/memory/Kconfig  |  8 
> >  drivers/memory/omap-gpmc.c  |  6 +++---
> >  9 files changed, 29 insertions(+), 35 deletions(-)
> >
> 
> 1. Happy new year :)

Same to you :)

> 2. It was a while I tested upstream on N900 but I had some spare time during
> the holidays to play, so I tried to boot 4.4-rc6 with Maemo 5. To my
> surprise, after that try, Maemo 5 rootfs, which is located on onenand became
> irreversibly corrupted. I bisected the tree to the $subject commit and after
> restoring HWMOD_INIT_NO_RESET in omap3xxx_gpmc_hwmod flags, the problem was
> solved. It seems that GPMC is either incorrectly or incompletely setup by
> the kernel, leading to failed onenand reads/writes and whatnot.
> Unfortunately, what I have here is a release device, so I am unable to
> capture any logs through the serial port. BTW keep in mind that rootfs
> corruption happens as soon as a boot is attempted, even after a freshly
> flashed rootfs.

Oh crap, sorry to hear that :(

Care to boot with CONFIG_OMAP_GPMC_DEBUG=y and post the gpmc related dmesg
output? The dmesg timings with CONFIG_OMAP_GPMC_DEBUG enabled should be
compared against omap3-n900.dts gpmc timings. And if you don't see the whole
dmesg after booting, you may need to also increase CONFIG_LOG_BUF_SHIFT.
Meanwhile, I'll try to also produce it here.

Chances are we have bad or incomplete timings in the n900 :(

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Nokia N900: Adjust MPU OPP values

[Tony Lindgren]

* Pali Rohár  [160102 06:31]:
> Hello,
> 
> MPU OPP table table (omap36xx_vddcore_volt_data) defined in
> opp3xxx_data.c does not match Nokia N900 phone. For a long time we have
> dirty patch in linux-n900 tree for it, see:
> 
> https://github.com/pali/linux-n900/commit/4644c5801d7469e2be01d847c61df3d934dadd8c
> 
> Now when doing transition to device tree, is there any way how correct
> MPU OOP table for Nokia N900 could be defined in DT file?

Hmm I'd assume we can just define this in the dts.. Nishanth, got
any comments on this one?

Regards,

Tony

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Nokia N900: Broken lirc ir-rx51 driver

[Tony Lindgren]

Hi,

* Pali Rohár  [160102 06:46]:
> --- a/drivers/media/rc/ir-rx51.c
> +++ b/drivers/media/rc/ir-rx51.c
> @@ -25,9 +25,9 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
> -#include 
> -#include 
> +#include "../../../arch/arm/plat-omap/include/plat/dmtimer.h"

Well we don't want to export the dmtimer functions to drivers..But
we now have the PWM driver that can be already used for most of the
ir-rx51.c.

>  #include 
>  #include 
> @@ -208,7 +208,7 @@ static int lirc_rx51_init_port(struct lirc_rx51 
> *lirc_rx51)
>   }
>  
>   clk_fclk = omap_dm_timer_get_fclk(lirc_rx51->pwm_timer);
> - lirc_rx51->fclk_khz = clk_fclk->rate / 1000;
> + lirc_rx51->fclk_khz = clk_get_rate(clk_fclk) / 1000;
>  
>   return 0;
>  
> 
> So Tony, you are author of that commit (a62a6e98c3) which broke ir-rx51
> module for Nokia N900. Do you know how to fix this driver for upstream
> kernel? It would be great to have driver working and not to have it in
> this dead state...

Yup please take a look at thread "[PATCH 0/3] pwm: omap: Add PWM support
using dual-mode timers". Chances are we still need to set up the dmtimer
code to provide also irqchip functions. That way ir-rx51.c can just do
request_irq on the selected dmtimer for interrupts.

> Also platform data for this driver are only in legacy board code.
> Support in DTS is missing, so driver (after fixing above problem) cannot
> be used on DT booted kernel.

Yeah those parts should be already doable with the PWM timer code AFAIK.

Regards,

Tony


--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Nokia N900: twl4030-power different data in DTS and board code

[Tony Lindgren]

* Pali Rohár  [160102 06:14]:
> Hello,
> 
> now I'm looking at differences between legacy board code and DTS file
> for Nokia N900 and I see some inconsistency for twl4030-power driver.
> 
> In board code are defined more twl4030 power scripts which override
> defaults defined in twl4030-power code. See:
> 
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/mach-omap2/board-rx51-peripherals.c#n790
> 
> Next in DTS file is defined just "compatible" keyword, but no custom
> scripts, see:
> 
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/omap3-n900.dts#n416
> 
> And the last in DTS file is defined line:
> 
> compatible = "ti,twl4030-power-n900" 
> 
> which is not in twl4030-power driver itself, see:
> 
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/mfd/twl4030-power.c#n851
> 
> So all this stuff looks like some errors when board code was ported to
> DTS. Tony, can you look at this at all?

AFAIK it should work fine with the generic "ti,twl4030-power-idle-osc-off".
This means reboot works and regulators are cut off during off mode.

The n900 specific code was based on something before the TI generic values
were available I think. And the last time I looked at it I came to the
conclusion the n900 specific code is no better.

Or did I miss something? Are you seeing some issues with PM with dts based
code?

We can certainly add it to twl4030-power if it provides something that
the "ti,twl4030-power-idle-osc-off" does not.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mmc: pwrseq_simple: Fix regression with optional GPIOs

[Tony Lindgren]

* Ulf Hansson <ulf.hans...@linaro.org> [151228 04:18]:
> On 18 December 2015 at 23:31, Tony Lindgren <t...@atomide.com> wrote:
> > * Ulf Hansson <ulf.hans...@linaro.org> [151218 14:20]:
> >> On 18 December 2015 at 17:14, Tony Lindgren <t...@atomide.com> wrote:
> >> > * Ulf Hansson <ulf.hans...@linaro.org> [151207 16:20]:
> >> >> +Linus
> >> >>
> >> >> On 7 December 2015 at 23:54, Tony Lindgren <t...@atomide.com> wrote:
> >> >> > Commit ce037275861e ("mmc: pwrseq_simple: use GPIO descriptors array 
> >> >> > API")
> >> >> > changed the handling MMC power sequence so GPIOs no longer are 
> >> >> > optional.
> >> >> >
> >> >> > This broke SDIO WLAN at least for omap5 that can't yet use the reset 
> >> >> > GPIOs
> >> >> > with pwrseq_simple as a wait is needed after enabling the SDIO device.
> >> >>
> >> >> Can you elaborate on this. Did it break omap5 or not? :-)
> >> >
> >> > Ulf, is this patch queued for v4.4 as a regression fix? I don't see it
> >> > in Linux next or mainline trees?
> >>
> >> Ohh, I guess there where some misunderstanding. I made a bunch of
> >> comments on your patch as well, so I have been expecting a new
> >> version.
> >
> > Well this $subject patch was intended as a regression fix for v4.4-rc cycle.
> > All the other things discussed are not fixes but new features instead.
> >
> >> Sorry if that was unclear!
> >
> > I think this patch should be still fine as is, care to take a look again?
> 
> No, the patch have issues that needs to be fixed.
> http://www.spinics.net/lists/linux-mmc/msg34399.html

Oh sorry, somehow I did not notice those comments earlier, will take a look.

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] ARM: ATAGS: move save_atags() to include/asm arch/arm/include/asm/setup.h

[Tony Lindgren]

* Pali Rohár <pali.ro...@gmail.com> [151224 09:48]:
> On Thursday 24 December 2015 17:37:55 Ivaylo Dimitrov wrote:
> > So it can be used by code outside arch/arm/kernel/. Fix save_atags()
> > declaration to match its definition while at it.
> > 
> > Signed-off-by: Ivaylo Dimitrov <ivo.g.dimitrov...@gmail.com>
> 
> Tested-by: Pali Rohár <pali.ro...@gmail.com>

Nice, please upload both to Russell's patch system after no
more comments:

Acked-by: Tony Lindgren <t...@atomide.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] OMAP: RX51: save ATAGS data in the early boot stage

[Tony Lindgren]

* Pali Rohár <pali.ro...@gmail.com> [151224 09:49]:
> On Thursday 24 December 2015 17:37:56 Ivaylo Dimitrov wrote:
> > Nokia N900 (RX51) legacy userspace needs various ATAGS passed by the
> > bootloader (boot reason, device serial, boot mode, various GPIO
> > swithes, etc). Save that data early enough in the boot process, so
> > it can be exported later in /proc/atags
> > 
> > Signed-off-by: Ivaylo Dimitrov <ivo.g.dimitrov...@gmail.com>
> 
> Working fine in qemu.
> 
> Tested-by: Pali Rohár <pali.ro...@gmail.com>

Maybe update the description to say "This fixes a regression with
device tree based booting compared to legacy booting for n900 to
make the n900 legacy user space to also work with device tree based
booting".

It would be nice to get these two in as fixes after -rc1 assuming
people have no objections to it. So please upload this one also
into Russell's patch system after no more comments:

Acked-by: Tony Lindgren <t...@atomide.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 5/6] ARM: LG Optimus Black (P970) codename sniper support, with basic features

[Tony Lindgren]

Hi,

* Paul Kocialkowski  [151223 03:00]:
> The LG Optimus Black (P970) codename sniper is a smartphone that was designed
> and manufactured by LG Electronics (LGE) and released back in 2011.
> It is using an OMAP3630 SoC, GP version.
> 
> This adds devicetree support for the device, with only a few basic features
> supported, such as debug uart, i2c, internal emmc and external mmc.

Cool :)

> + {
> + ti,no-reset-on-init;
> +};
> +
> + {
> + ti,no-reset-on-init;
> +};
> +
> + {
> + ti,no-reset-on-init;
> +};
> +
> + {
> + ti,no-reset-on-init;
> +};
> +
> + {
> + ti,no-reset-on-init;
> +};
> +
> + {
> + ti,no-reset-on-init;
> +};

Care to try to narrow down exactly which GPIO(s) need to be preserved?
Chances are this will unnecessarily block deeper idle states in hardware
otherwise.

My guess is that the GPIO pins that need to be preserved if any are in
the GPIO bank 1 as that's always powered..

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] wlcore/wl12xx: spi: add device tree support

[Tony Lindgren]

* Uri Mashiach  [151223 06:38]:
> On 12/23/2015 12:25 PM, Grygorii Strashko wrote:
> 
> >>+that services interrupts for this device
> >>+- vwlan-supply :Point the node of the regulator that controls the 
> >>wl1271 chip WLAN_EN pin
> >
> >Pls, use gpio if this is required just to toggle WLAN_EN pin.
> >
> >[ti,] power-gpio or en-gpio
> >
> >
> 
> The controller's power might need toggling in some board implementation.
> Maybe GPIO and regulator should be implemented?

Yes a regulator for wlcore is best here because to properly control it
and the wait needed.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] ARM: dts: am335x-evm: add shared transport device tree bindings

[Tony Lindgren]

* Reizer, Eyal  [151223 03:40]:
> The shared Shared Transport (ST) software enables BT and GPS protocols
> or software components to interact with their respective cores over
> single physical port.
> Add the uart and enable pin device tree bindings
...
> --- a/arch/arm/boot/dts/am335x-evm.dts
> +++ b/arch/arm/boot/dts/am335x-evm.dts
> @@ -160,6 +160,18 @@
>   system-clock-frequency = <1200>;
>   };
>   };
> +
> + kim {
> + compatible = "kim";
> + nshutdown-gpios = < 21 GPIO_ACTIVE_HIGH>;
> + serial-device = <>;
> + flow_cntrl = <1>;
> + baud_rate = <300>;
> + };
> +
> + btwilink {
> + compatible = "btwilink";
> + };
>  };

I think this "kim" binding got dropped.. We need some sane binding and
solution for it.

Regards,

Tony

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] ARM: dts: am335x-evm: add shared transport device tree bindings

[Tony Lindgren]

* Tony Lindgren <t...@atomide.com> [151223 10:19]:
> * Reizer, Eyal <ey...@ti.com> [151223 03:40]:
> > The shared Shared Transport (ST) software enables BT and GPS protocols
> > or software components to interact with their respective cores over
> > single physical port.
> > Add the uart and enable pin device tree bindings
> ...
> > --- a/arch/arm/boot/dts/am335x-evm.dts
> > +++ b/arch/arm/boot/dts/am335x-evm.dts
> > @@ -160,6 +160,18 @@
> > system-clock-frequency = <1200>;
> > };
> > };
> > +
> > +   kim {
> > +   compatible = "kim";
> > +   nshutdown-gpios = < 21 GPIO_ACTIVE_HIGH>;
> > +   serial-device = <>;
> > +   flow_cntrl = <1>;
> > +   baud_rate = <300>;
> > +   };
> > +
> > +   btwilink {
> > +   compatible = "btwilink";
> > +   };
> >  };
> 
> I think this "kim" binding got dropped.. We need some sane binding and
> solution for it.

Oh sorry, this is a new binding you've done :) Nice good to see this
get fixed.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4] clk: ti: Add support for dm814x ADPLL

[Tony Lindgren]

On dm814x we have 13 ADPLLs with 3 to 4 outputs on each. The
ADPLLs have several dividers and muxes controlled by a shared
control register for each PLL.

Note that for the clocks to work as device drivers for booting on
dm814x, this patch depends on "ARM: OMAP2+: Change core_initcall
levels to postcore_initcall".

Also note that this patch does not implement clk_set_rate for the
PLL, that will be posted later on when available.

Cc: Michael Turquette <mturque...@baylibre.com>
Cc: Stephen Boyd <sb...@codeaurora.org>
Cc: Tero Kristo <t-kri...@ti.com>
Signed-off-by: Tony Lindgren <t...@atomide.com>
---

If no more comments, Tero can you please apply into an immutable
branch against v4.4-rc1 that I can merge in too?

Changes since v3:

- We want to create the clkdev entry for all clocks, not just outputs
- ti_adpll_wait_lock loops did not do the right thing
- We want to use CLK_GET_RATE_NOCACHE in ti_adpll_init_dco

---
 .../devicetree/bindings/clock/ti/adpll.txt |   43 +
 drivers/clk/Kconfig|1 +
 drivers/clk/ti/Kconfig |6 +
 drivers/clk/ti/Makefile|2 +
 drivers/clk/ti/adpll.c | 1004 
 drivers/clk/ti/clk-814x.c  |   53 ++
 6 files changed, 1109 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/ti/adpll.txt
 create mode 100644 drivers/clk/ti/Kconfig
 create mode 100644 drivers/clk/ti/adpll.c

diff --git a/Documentation/devicetree/bindings/clock/ti/adpll.txt 
b/Documentation/devicetree/bindings/clock/ti/adpll.txt
new file mode 100644
index 000..3c41aea
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/ti/adpll.txt
@@ -0,0 +1,43 @@
+Binding for Texas Instruments ADPLL clock.
+
+Binding status: Unstable - ABI compatibility may be broken in the future
+
+This binding uses the common clock binding[1]. It assumes a
+register-mapped ADPLL with two to three selectable input clocks
+and three to four children..
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+- compatible : shall be one of "ti,dm814-adpll-s-clock" or
+  "ti,dm814-adpll-lj-clock" depending on the type of the ADPLL
+- #clock-cells : from common clock binding; shall be set to 0.
+- clocks : link phandles of parent clocks clkinp and clkinpulow, note
+  that the adpll-s-clock also has an optional clkinphif
+- reg : address and length of the register set for controlling the ADPLL.
+
+Examples:
+   adpll_mpu_ck: adpll@40 {
+   #clock-cells = <1>;
+   compatible = "ti,dm814-adpll-s-clock";
+   reg = <0x40 0x40>;
+   clocks = <_ck _ck _ck>;
+   clock-names = "clkinp", "clkinpulow", "clkinphif";
+   clock-indices = <0>, <1>, <2>, <3>;
+   clock-output-names = "481c5040.adpll.dcoclkldo",
+"481c5040.adpll.clkout",
+"481c5040.adpll.clkoutx2",
+"481c5040.adpll.clkouthif";
+   };
+
+   adpll_dsp_ck: adpll@80 {
+   #clock-cells = <1>;
+   compatible = "ti,dm814-adpll-lj-clock";
+   reg = <0x80 0x30>;
+   clocks = <_ck _ck>;
+   clock-names = "clkinp", "clkinpulow";
+   clock-indices = <0>, <1>, <2>;
+   clock-output-names = "481c5080.adpll.dcoclkldo",
+"481c5080.adpll.clkout",
+"481c5080.adpll.clkoutldo";
+   };
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index c3e3a02f..c0c9868 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -190,6 +190,7 @@ config COMMON_CLK_CDCE706
 
 source "drivers/clk/bcm/Kconfig"
 source "drivers/clk/hisilicon/Kconfig"
+source "drivers/clk/ti/Kconfig"
 source "drivers/clk/qcom/Kconfig"
 
 endmenu
diff --git a/drivers/clk/ti/Kconfig b/drivers/clk/ti/Kconfig
new file mode 100644
index 000..a9d5474
--- /dev/null
+++ b/drivers/clk/ti/Kconfig
@@ -0,0 +1,6 @@
+config COMMON_CLK_TI_ADPLL
+   tristate "Clock driver for dm814x ADPLL"
+   depends on ARCH_OMAP2PLUS
+   default y if SOC_TI81XX
+   ---help---
+ ADPLL clock driver for the dm814x SoC using common clock framework.
diff --git a/drivers/clk/ti/Makefile b/drivers/clk/ti/Makefile
index d4ac960..dfe91d7 100644
--- a/drivers/clk/ti/Makefile
+++ b/drivers/clk/ti/Makefile
@@ -18,3 +18,5 @@ obj-$(CONFIG_SOC_AM43XX)  += $(clk-common) 
dpll3xxx.o clk-43xx.o
 ifdef CONFIG_ATAGS
 obj-$(CONFIG

Re: [PATCH v2] ARM: dts: Add clocks for dm814x ADPLL

[Tony Lindgren]

* Tero Kristo <t-kri...@ti.com> [151222 12:08]:
> On 12/22/2015 05:53 PM, Tony Lindgren wrote:
> >These use the standard clock bindings and now we can make some
> >of the fixed clocks into real clocks.
> >
> >Cc: Tero Kristo <t-kri...@ti.com>
> >Signed-off-by: Tony Lindgren <t...@atomide.com>
> >---
> >Changes since v1:
> >
> >- Updated for changed clock names for "dcoclkldo"
> >- Merged in the dra62x changes
> >
> >---
> >  arch/arm/boot/dts/dm814x-clocks.dtsi | 256 
> > ++-
> >  arch/arm/boot/dts/dra62x-clocks.dtsi |  26 
> >  2 files changed, 251 insertions(+), 31 deletions(-)
> >
> >diff --git a/arch/arm/boot/dts/dm814x-clocks.dtsi 
> >b/arch/arm/boot/dts/dm814x-clocks.dtsi
> >index e0ea6a9..b75ca91 100644
> >--- a/arch/arm/boot/dts/dm814x-clocks.dtsi
> >+++ b/arch/arm/boot/dts/dm814x-clocks.dtsi
> >@@ -4,6 +4,170 @@
> >   * published by the Free Software Foundation.
> >   */
> >
> >+ {
> >+/*
> >+ * See TRM "2.6.10 Connected outputso DPLLS" and
> >+ * "2.6.11 Connected Outputs of DPLLJ". Only clkout is
> >+ * connected except for hdmi and usb.
> >+ */
> >+adpll_mpu_ck: adpll@40 {
> >+#clock-cells = <1>;
> >+compatible = "ti,dm814-adpll-s-clock";
> >+reg = <0x40 0x40>;
> >+clocks = <_ck _ck _ck>;
> >+clock-names = "clkinp", "clkinpulow", "clkinphif";
> >+clock-indices = <0>, <1>, <2>, <3>;
> >+clock-output-names = "481c5040.adpll.dcoclkldo",
> >+ "481c5040.adpll.clkout",
> >+ "481c5040.adpll.clkoutx2",
> >+ "481c5040.adpll.clkouthif";
> 
> Discussed this offline, but looks like most of the clock output names can
> probably be generated runtime, as they seem duplicate across adplls?
> Including the address component.

Yes the output names could be generated if not separately specified.
Eventually we probably want to use more descriptive names here though.

> Based on the offline discussion though:
> 
> Acked-by: Tero Kristo <t-kri...@ti.com>

OK thanks,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL 2/4] omap changes for ti81xx devices and minimal dra62x j5eco-evm support

[Tony Lindgren]

Hi,

* Olof Johansson <o...@lixom.net> [151222 15:41]:
> On Tue, Dec 22, 2015 at 3:33 PM, Tony Lindgren <t...@atomide.com> wrote:
> > * Olof Johansson <o...@lixom.net> [151222 14:58]:
> >>
> >> I'm a little puzzled by how you chose to organize this branch. We usually
> >> ask for SoC enablement and new DT files separately. Is there a reason you
> >> couldn't split out the SoC pieces and include those in the soc branch, and
> >> leave the DT contents for this one?
> >
> > Hmm yeah I guess I kept all the 81xx stuff in a single branch because of the
> > earlier largeish set of 81xx fixes that had interlaced dts and SoC changes
> > that had to be in a specific order to keep system booting because of bugs in
> > the dts defined clocks.
> >
> > If you want to, I can respin these patches into two branches, one for dts 
> > and
> > one for SoC changes. Probably both branches have to be based on the earlier
> > branch "omap-for-v4.5/81xx-fixes-signed" to avoid merge conflicts though.
> 
> Yeah, that sounds good. Please do.

OK updated pull requests sent. It's now three separate pull requests starting
with "[GIT PULL 1/3] reworked fix for earlier ti81xx changes for v4.5 merge
window".

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[GIT PULL 3/3] reworked dts changes for ti81xx devices and minimal dra62x j5ec-evm support

[Tony Lindgren]

The following changes since commit d893656e61040f3ff7b5f72a986052a348f3c94e:

  ARM: OMAP2+: Remove useless check for legacy booting for dm814x (2015-12-09 
16:53:46 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap 
tags/omap-for-v4.5/81xx-dts-signed

for you to fetch changes up to 43fe6de38ea57bf3ef20e89d8bf9b799a7ff0c0b:

  ARM: dts: Add usb support for j5-eco evm (2015-12-22 16:01:41 -0800)


Add minimal device tree support for dra62x also known j5eco. It is
related to dm814x, just the clocks are a bit different and it has a
different set of integrated devices. And let's get some basic dm814x
and dra62x devices working as many of the devices are like on am33xx::

- pinctrl using the pinctrl defines as for am33xx

- Updated EDMA bindings with support for using exma_xbar

- MMC support for dm814x-evm, t410 and dra62x-j5eco-evm

- USB support for dm814x-evm, t410 and dra62x-j5eco-evm

This branch depends on an earlier omap-for-v4.5/81xx-fixes-signed
branch that has dm814x dts fixes interlaced with SoC related fixes to
keep things booting. The interlaced SoC and dts fixes were needed
because of issues with the device tree defined clocks that just
happened to work on bootloader timings for t410 earlier.


Tony Lindgren (12):
  ARM: dts: Add basic support for dra62x j5-eco SoC
  ARM: dts: Add minimal dra62x j5-eco evm support
  ARM: dts: Add pinctrl macros for dm814x
  ARM: dts: Update edma bindings on dm814x to use edma_xbar
  ARM: dts: Add mmc device entries for dm814x
  ARM: dts: Add mmc support for dm8148-evm
  ARM: dts: Add mmc support for dra62x j5-eco evm
  ARM: dts: Enable emmc on hp t410
  ARM: dts: Add usb support for dm814x and dra62x
  ARM: dts: Add usb support for dm814x-evm
  ARM: dts: Add usb support for hp t410
  ARM: dts: Add usb support for j5-eco evm

 arch/arm/boot/dts/Makefile |   3 +-
 arch/arm/boot/dts/dm8148-evm.dts   |  55 
 arch/arm/boot/dts/dm8148-t410.dts  |  70 ++
 arch/arm/boot/dts/dm814x.dtsi  | 226 +++--
 arch/arm/boot/dts/dra62x-clocks.dtsi   |  23 
 arch/arm/boot/dts/dra62x-j5eco-evm.dts |  80 
 arch/arm/boot/dts/dra62x.dtsi  |  23 
 include/dt-bindings/pinctrl/dm814x.h   |  48 +++
 include/dt-bindings/pinctrl/omap.h |   1 +
 9 files changed, 517 insertions(+), 12 deletions(-)
 create mode 100644 arch/arm/boot/dts/dra62x-clocks.dtsi
 create mode 100644 arch/arm/boot/dts/dra62x-j5eco-evm.dts
 create mode 100644 arch/arm/boot/dts/dra62x.dtsi
 create mode 100644 include/dt-bindings/pinctrl/dm814x.h
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[GIT PULL 2/3] reworked soc changes for ti81xx devices and minimal dra62x j5ec-evm support

[Tony Lindgren]

The following changes since commit f2e6a0a913b53f5af87c7e9a783ceae5bb4ae2c4:

  ARM: OMAP2+: Remove device creation for omap-pcm-audio (2015-12-17 10:34:41 
-0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap 
tags/omap-for-v4.5/81xx-soc-signed

for you to fetch changes up to f53850b5dc625ca37ae84b47f4f92b1d55df2aa0:

  ARM: OMAP2+: Add support for dm814x and dra62x usb (2015-12-22 16:23:08 -0800)


Add minimal SoC support for dra62x also known as j5eco. As it's closely
related to dm814x, we can treat it as a dm814x variant for now and do
rest of the configuration with DTS just files. And let's add hwmod
support for MMC and USB on dm814x and dra62x.


Tony Lindgren (4):
  ARM: OMAP2+: Fix SoC detection for dra62x j5-eco
  ARM: OMAP2+: Update 81xx clock and power domains for default, active and 
sgx
  ARM: OMAP2+: Add mmc hwmod entries for dm814x
  ARM: OMAP2+: Add support for dm814x and dra62x usb

 arch/arm/mach-omap2/clockdomains81xx_data.c |  29 +++---
 arch/arm/mach-omap2/cm81xx.h|   6 +-
 arch/arm/mach-omap2/id.c|   4 +-
 arch/arm/mach-omap2/omap_hwmod_81xx_data.c  | 131 
 arch/arm/mach-omap2/powerdomains3xxx_data.c |  10 ++-
 5 files changed, 139 insertions(+), 41 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[GIT PULL 1/3] reworked fix for earlier ti81xx changes for v4.5 merge window

[Tony Lindgren]

Hi,

Here are reworked pull requests to separate the dts changes as requested
by Olof.

The pull request below, and the third pull request in this series,
still depend on the earlier branch omap-for-v4.5/81xx-fixes-signed.
The pull request number two in this series does not.

My updated for-next has zero diff with these merged in compared to the
earlier single branch merged in, so this is just regrouping of the patches
into three separate pull requests.

Regards,

Tony


The following changes since commit d893656e61040f3ff7b5f72a986052a348f3c94e:

  ARM: OMAP2+: Remove useless check for legacy booting for dm814x (2015-12-09 
16:53:46 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap 
tags/omap-for-v4.5/81xx-fix-signed

for you to fetch changes up to dbb7e70a69288980c8a89fdb5ffb97e06b806b19:

  ARM: OMAP2+: Fix randconfig build warning for dm814_pllss_data (2015-12-22 
17:01:02 -0800)


Fix a randconfig build warning introduced in the earlier branch
omap-for-v4.5/81xx-fixes-signed.


Tony Lindgren (1):
  ARM: OMAP2+: Fix randconfig build warning for dm814_pllss_data

 arch/arm/mach-omap2/prm_common.c | 2 ++
 1 file changed, 2 insertions(+)
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL 2/4] omap changes for ti81xx devices and minimal dra62x j5eco-evm support

[Tony Lindgren]

* Olof Johansson <o...@lixom.net> [151222 14:58]:
> Hi Tony,
> 
> On Mon, Dec 21, 2015 at 01:06:35PM -0800, Tony Lindgren wrote:
> > The following changes since commit d893656e61040f3ff7b5f72a986052a348f3c94e:
> > 
> >   ARM: OMAP2+: Remove useless check for legacy booting for dm814x 
> > (2015-12-09 16:53:46 -0800)
> > 
> > are available in the git repository at:
> > 
> >   git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap 
> > tags/omap-for-v4.5/81xx-devices
> > 
> > for you to fetch changes up to 8f2cf92a912ca7173d29c045d225588c9630ed94:
> > 
> >   ARM: dts: Add usb support for j5-eco evm (2015-12-21 10:43:29 -0800)
> > 
> > 
> > Now with dm814x support fixed up enough where we can make use of some 
> > clocks,
> > we can adds some more basic devices for dm814x. And we can also add minimal
> > support for dra62x j5eco-evm that is another ti81xx variant related to 
> > dm814x.
> > 
> > I would have rather merged this series toghether with the ADPLL clock 
> > driver,
> > and was waiting for that to get merged before sending out these patches. But
> > the ADPLL clock driver can be merged separately, and at least dm814x-evm,
> > dra62x-j5eco-evm, and t410 all boot with this series alone. So let's merge
> > these patches separately as that allows people to do development on these
> > platforms for other device drivers using the mainline kernel.
> > 
> > Note that this series depends on the earlier 81xx-fixes and omap initcall
> > changes. It also depends on the DMA commit ae0add740cd0 that's already in
> > mainline. As this series is mostly DTS changes with a few related hwmod
> > changes, it's probably best merged along with the other DTS changes.
> 
> I'm a little puzzled by how you chose to organize this branch. We usually
> ask for SoC enablement and new DT files separately. Is there a reason you
> couldn't split out the SoC pieces and include those in the soc branch, and
> leave the DT contents for this one?

Hmm yeah I guess I kept all the 81xx stuff in a single branch because of the
earlier largeish set of 81xx fixes that had interlaced dts and SoC changes
that had to be in a specific order to keep system booting because of bugs in
the dts defined clocks.

If you want to, I can respin these patches into two branches, one for dts and
one for SoC changes. Probably both branches have to be based on the earlier
branch "omap-for-v4.5/81xx-fixes-signed" to avoid merge conflicts though.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4] clk: ti: Add support for dm814x ADPLL

[Tony Lindgren]

* Michael Turquette <mturque...@baylibre.com> [151222 12:56]:
> On 12/22, Tony Lindgren wrote:
> > * Tero Kristo <t-kri...@ti.com> [151222 12:28]:
> > > On 12/22/2015 05:27 PM, Tony Lindgren wrote:
> > > >On dm814x we have 13 ADPLLs with 3 to 4 outputs on each. The
> > > >ADPLLs have several dividers and muxes controlled by a shared
> > > >control register for each PLL.
> > > >
> > > >Note that for the clocks to work as device drivers for booting on
> > > >dm814x, this patch depends on "ARM: OMAP2+: Change core_initcall
> > > >levels to postcore_initcall".
> > > >
> > > >Also note that this patch does not implement clk_set_rate for the
> > > >PLL, that will be posted later on when available.
> > > >
> > > >Cc: Michael Turquette <mturque...@baylibre.com>
> > > >Cc: Stephen Boyd <sb...@codeaurora.org>
> > > >Cc: Tero Kristo <t-kri...@ti.com>
> > > >Signed-off-by: Tony Lindgren <t...@atomide.com>
> > > >---
> > > >
> > > >If no more comments, Tero can you please apply into an immutable
> > > >branch against v4.4-rc1 that I can merge in too?
> > > >
> > > >Changes since v3:
> > > >
> > > >- We want to create the clkdev entry for all clocks, not just outputs
> > > >- ti_adpll_wait_lock loops did not do the right thing
> > > >- We want to use CLK_GET_RATE_NOCACHE in ti_adpll_init_dco
> > > 
> > > I have just one comment below still, once that is addressed:
> > > 
> > > Conditionally-acked-by: Tero Kristo <t-kri...@ti.com>
> > > 
> > > Stephen / Michael, can you pick this up for next merge? I don't have
> > > anything else coming for the window this time, and I am probably going to 
> > > be
> > > on vacation just nicely to not be able to push anything anyway.
> > 
> > Also, I managed to remove the dependency to the dts changes. So there's
> > no longer any need to set up an immutable branch for this patch.
> 
> Can you split the binding description into a separate patch and send it
> to the dt mailing list? Feel free to add my Ack to it.

OK will do thanks.

> Stephen and I are trying to not take that stuff anymore.

Sure, no problem.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2] ARM: dts: Add clocks for dm814x ADPLL

[Tony Lindgren]

These use the standard clock bindings and now we can make some
of the fixed clocks into real clocks.

Cc: Tero Kristo <t-kri...@ti.com>
Signed-off-by: Tony Lindgren <t...@atomide.com>
---
Changes since v1:

- Updated for changed clock names for "dcoclkldo"
- Merged in the dra62x changes

---
 arch/arm/boot/dts/dm814x-clocks.dtsi | 256 ++-
 arch/arm/boot/dts/dra62x-clocks.dtsi |  26 
 2 files changed, 251 insertions(+), 31 deletions(-)

diff --git a/arch/arm/boot/dts/dm814x-clocks.dtsi 
b/arch/arm/boot/dts/dm814x-clocks.dtsi
index e0ea6a9..b75ca91 100644
--- a/arch/arm/boot/dts/dm814x-clocks.dtsi
+++ b/arch/arm/boot/dts/dm814x-clocks.dtsi
@@ -4,6 +4,170 @@
  * published by the Free Software Foundation.
  */
 
+ {
+   /*
+* See TRM "2.6.10 Connected outputso DPLLS" and
+* "2.6.11 Connected Outputs of DPLLJ". Only clkout is
+* connected except for hdmi and usb.
+*/
+   adpll_mpu_ck: adpll@40 {
+   #clock-cells = <1>;
+   compatible = "ti,dm814-adpll-s-clock";
+   reg = <0x40 0x40>;
+   clocks = <_ck _ck _ck>;
+   clock-names = "clkinp", "clkinpulow", "clkinphif";
+   clock-indices = <0>, <1>, <2>, <3>;
+   clock-output-names = "481c5040.adpll.dcoclkldo",
+"481c5040.adpll.clkout",
+"481c5040.adpll.clkoutx2",
+"481c5040.adpll.clkouthif";
+   };
+
+   adpll_dsp_ck: adpll@80 {
+   #clock-cells = <1>;
+   compatible = "ti,dm814-adpll-lj-clock";
+   reg = <0x80 0x30>;
+   clocks = <_ck _ck>;
+   clock-names = "clkinp", "clkinpulow";
+   clock-indices = <0>, <1>, <2>;
+   clock-output-names = "481c5080.adpll.dcoclkldo",
+"481c5080.adpll.clkout",
+"481c5080.adpll.clkoutldo";
+   };
+
+   adpll_sgx_ck: adpll@b0 {
+   #clock-cells = <1>;
+   compatible = "ti,dm814-adpll-lj-clock";
+   reg = <0xb0 0x30>;
+   clocks = <_ck _ck>;
+   clock-names = "clkinp", "clkinpulow";
+   clock-indices = <0>, <1>, <2>;
+   clock-output-names = "481c50b0.adpll.dcoclkldo",
+"481c50b0.adpll.clkout",
+"481c50b0.adpll.clkoutldo";
+   };
+
+   adpll_hdvic_ck: adpll@e0 {
+   #clock-cells = <1>;
+   compatible = "ti,dm814-adpll-lj-clock";
+   reg = <0xe0 0x30>;
+   clocks = <_ck _ck>;
+   clock-names = "clkinp", "clkinpulow";
+   clock-indices = <0>, <1>, <2>;
+   clock-output-names = "481c50e0.adpll.dcoclkldo",
+"481c50e0.adpll.clkout",
+"481c50e0.adpll.clkoutldo";
+   };
+
+   adpll_l3_ck: adpll@110 {
+   #clock-cells = <1>;
+   compatible = "ti,dm814-adpll-lj-clock";
+   reg = <0x110 0x30>;
+   clocks = <_ck _ck>;
+   clock-names = "clkinp", "clkinpulow";
+   clock-indices = <0>, <1>, <2>;
+   clock-output-names = "481c5110.adpll.dcoclkldo",
+"481c5110.adpll.clkout",
+"481c5110.adpll.clkoutldo";
+   };
+
+   adpll_isp_ck: adpll@140 {
+   #clock-cells = <1>;
+   compatible = "ti,dm814-adpll-lj-clock";
+   reg = <0x140 0x30>;
+   clocks = <_ck _ck>;
+   clock-names = "clkinp", "clkinpulow";
+   clock-indices = <0>, <1>, <2>;
+   clock-output-names = "481c5140.adpll.dcoclkldo",
+"481c5140.adpll.clkout",
+"481c5140.adpll.clkoutldo";
+   };
+
+   adpll_dss_ck: adpll@170 {
+   #clock-cells = <1>;
+   compatible = "ti,dm814-adpll-lj-clock";
+   reg = <0x170 0x30>;
+   clocks = <_ck _ck>;
+   clock-names = "clkinp", "clki

[PATCH 0/3] Add GPMC and NAND support for dm814x-evm and dra62x-j5eco-evm

[Tony Lindgren]

Hi all,

Here's support for GPMC and NAND on j5-eco evm and dm814x-evm.
Probably too late for v4.5 merge window , but seems to work here if
somebody wants to play with GPMC.

To test, please use Linux next-20151222 or later and the following
patches:

[PATCH v4] clk: ti: Add support for dm814x ADPLL
[PATCH v2] ARM: dts: Add clocks for dm814x ADPLL

Check that you have CONFIG_COMMON_CLK_TI_ADPLL=y. And then you
probably want to apply this for an unrelated DSS build breakage:

[PATCH] OMAPDSS: fix omapfb build error due missing feat functions declaration

Regards,

Tony


Tony Lindgren (3):
  ARM: dts: Add support for GPMC for dm814x and dra62x
  ARM: dts: Add NAND support for j5-eco evm
  ARM: dts: Add NAND support for dm8148-evm

 arch/arm/boot/dts/dm8148-evm.dts   | 56 ++
 arch/arm/boot/dts/dm814x.dtsi  | 12 
 arch/arm/boot/dts/dra62x-j5eco-evm.dts | 56 ++
 3 files changed, 124 insertions(+)

-- 
2.6.2

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/3] ARM: dts: Add NAND support for dm8148-evm

[Tony Lindgren]

Add NAND support for dm8148-evm.

Signed-off-by: Tony Lindgren <t...@atomide.com>
---
 arch/arm/boot/dts/dm8148-evm.dts | 56 
 1 file changed, 56 insertions(+)

diff --git a/arch/arm/boot/dts/dm8148-evm.dts b/arch/arm/boot/dts/dm8148-evm.dts
index e070862..862977f 100644
--- a/arch/arm/boot/dts/dm8148-evm.dts
+++ b/arch/arm/boot/dts/dm8148-evm.dts
@@ -35,6 +35,62 @@
phy-mode = "rgmii";
 };
 
+ {
+   ranges = <0 0 0x0400 0x0100>;   /* CS0: 16MB for NAND */
+
+   nand@0,0 {
+   linux,mtd-name= "micron,mt29f2g16aadwp";
+   reg = <0 0 4>; /* CS0, offset 0, IO size 4 */
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ti,nand-ecc-opt = "bch8";
+   nand-bus-width = <16>;
+   gpmc,device-width = <2>;
+   gpmc,sync-clk-ps = <0>;
+   gpmc,cs-on-ns = <0>;
+   gpmc,cs-rd-off-ns = <44>;
+   gpmc,cs-wr-off-ns = <44>;
+   gpmc,adv-on-ns = <6>;
+   gpmc,adv-rd-off-ns = <34>;
+   gpmc,adv-wr-off-ns = <44>;
+   gpmc,we-on-ns = <0>;
+   gpmc,we-off-ns = <40>;
+   gpmc,oe-on-ns = <0>;
+   gpmc,oe-off-ns = <54>;
+   gpmc,access-ns = <64>;
+   gpmc,rd-cycle-ns = <82>;
+   gpmc,wr-cycle-ns = <82>;
+   gpmc,wait-on-read = "true";
+   gpmc,wait-on-write = "true";
+   gpmc,bus-turnaround-ns = <0>;
+   gpmc,cycle2cycle-delay-ns = <0>;
+   gpmc,clk-activation-ns = <0>;
+   gpmc,wait-monitoring-ns = <0>;
+   gpmc,wr-access-ns = <40>;
+   gpmc,wr-data-mux-bus-ns = <0>;
+   partition@0 {
+   label = "X-Loader";
+   reg = <0 0x8>;
+   };
+   partition@0x8 {
+   label = "U-Boot";
+   reg = <0x8 0x1c>;
+   };
+   partition@0x1c {
+   label = "Environment";
+   reg = <0x24 0x4>;
+   };
+   partition@0x28 {
+   label = "Kernel";
+   reg = <0x28 0x50>;
+   };
+   partition@0x78 {
+   label = "Filesystem";
+   reg = <0x78 0xf88>;
+   };
+   };
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_pins>;
-- 
2.6.2

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/3] ARM: dts: Add support for GPMC for dm814x and dra62x

[Tony Lindgren]

Add support for GPMC for dm814x and dra62x

Signed-off-by: Tony Lindgren <t...@atomide.com>
---
 arch/arm/boot/dts/dm814x.dtsi | 12 
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/boot/dts/dm814x.dtsi b/arch/arm/boot/dts/dm814x.dtsi
index a25cd51..3fe68b1 100644
--- a/arch/arm/boot/dts/dm814x.dtsi
+++ b/arch/arm/boot/dts/dm814x.dtsi
@@ -548,6 +548,18 @@
reg-names = "gmii-sel";
};
};
+
+   gpmc: gpmc@5000 {
+   compatible = "ti,am3352-gpmc";
+   ti,hwmods = "gpmc";
+   ti,no-idle-on-init;
+   reg = <0x5000 0x2000>;
+   interrupts = <100>;
+   gpmc,num-cs = <7>;
+   gpmc,num-waitpins = <2>;
+   #address-cells = <2>;
+   #size-cells = <1>;
+   };
};
 };
 
-- 
2.6.2

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/3] ARM: dts: Add NAND support for j5-eco evm

[Tony Lindgren]

Add NAND support for j5-eco evm.

Signed-off-by: Tony Lindgren <t...@atomide.com>
---
 arch/arm/boot/dts/dra62x-j5eco-evm.dts | 56 ++
 1 file changed, 56 insertions(+)

diff --git a/arch/arm/boot/dts/dra62x-j5eco-evm.dts 
b/arch/arm/boot/dts/dra62x-j5eco-evm.dts
index 7900806..3937a58 100644
--- a/arch/arm/boot/dts/dra62x-j5eco-evm.dts
+++ b/arch/arm/boot/dts/dra62x-j5eco-evm.dts
@@ -35,6 +35,62 @@
phy-mode = "rgmii";
 };
 
+ {
+   ranges = <0 0 0x0400 0x0100>;   /* CS0: 16MB for NAND */
+
+   nand@0,0 {
+   linux,mtd-name= "micron,mt29f2g16aadwp";
+   reg = <0 0 4>; /* CS0, offset 0, IO size 4 */
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ti,nand-ecc-opt = "bch8";
+   nand-bus-width = <16>;
+   gpmc,device-width = <2>;
+   gpmc,sync-clk-ps = <0>;
+   gpmc,cs-on-ns = <0>;
+   gpmc,cs-rd-off-ns = <44>;
+   gpmc,cs-wr-off-ns = <44>;
+   gpmc,adv-on-ns = <6>;
+   gpmc,adv-rd-off-ns = <34>;
+   gpmc,adv-wr-off-ns = <44>;
+   gpmc,we-on-ns = <0>;
+   gpmc,we-off-ns = <40>;
+   gpmc,oe-on-ns = <0>;
+   gpmc,oe-off-ns = <54>;
+   gpmc,access-ns = <64>;
+   gpmc,rd-cycle-ns = <82>;
+   gpmc,wr-cycle-ns = <82>;
+   gpmc,wait-on-read = "true";
+   gpmc,wait-on-write = "true";
+   gpmc,bus-turnaround-ns = <0>;
+   gpmc,cycle2cycle-delay-ns = <0>;
+   gpmc,clk-activation-ns = <0>;
+   gpmc,wait-monitoring-ns = <0>;
+   gpmc,wr-access-ns = <40>;
+   gpmc,wr-data-mux-bus-ns = <0>;
+   partition@0 {
+   label = "X-Loader";
+   reg = <0 0x8>;
+   };
+   partition@0x8 {
+   label = "U-Boot";
+   reg = <0x8 0x1c>;
+   };
+   partition@0x1c {
+   label = "Environment";
+   reg = <0x24 0x4>;
+   };
+   partition@0x28 {
+   label = "Kernel";
+   reg = <0x28 0x50>;
+   };
+   partition@0x78 {
+   label = "Filesystem";
+   reg = <0x78 0xf88>;
+   };
+   };
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_pins>;
-- 
2.6.2

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] ARM: dts: The rate for auxclk is 22.59792 by default

[Tony Lindgren]

The rate for auxclk is 22.59792 by default.

Signed-off-by: Tony Lindgren <t...@atomide.com>
---
 arch/arm/boot/dts/dm814x-clocks.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/dm814x-clocks.dtsi 
b/arch/arm/boot/dts/dm814x-clocks.dtsi
index 2600158..e0ea6a9 100644
--- a/arch/arm/boot/dts/dm814x-clocks.dtsi
+++ b/arch/arm/boot/dts/dm814x-clocks.dtsi
@@ -41,11 +41,11 @@
reg = <0x0040>;
};
 
-   /* Optional auxosc, 20 - 30 MHz range, assume 27 MHz by default */
+   /* Optional auxosc, 20 - 30 MHz range, assume 22.5729 MHz by default */
auxosc_ck: auxosc_ck {
#clock-cells = <0>;
compatible = "fixed-clock";
-   clock-frequency = <2700>;
+   clock-frequency = <22572900>;
};
 
/* Optional 32768Hz crystal or clock on RTCOSC pins */
-- 
2.6.2

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4] clk: ti: Add support for dm814x ADPLL

[Tony Lindgren]

* Tero Kristo <t-kri...@ti.com> [151222 12:28]:
> On 12/22/2015 05:27 PM, Tony Lindgren wrote:
> >On dm814x we have 13 ADPLLs with 3 to 4 outputs on each. The
> >ADPLLs have several dividers and muxes controlled by a shared
> >control register for each PLL.
> >
> >Note that for the clocks to work as device drivers for booting on
> >dm814x, this patch depends on "ARM: OMAP2+: Change core_initcall
> >levels to postcore_initcall".
> >
> >Also note that this patch does not implement clk_set_rate for the
> >PLL, that will be posted later on when available.
> >
> >Cc: Michael Turquette <mturque...@baylibre.com>
> >Cc: Stephen Boyd <sb...@codeaurora.org>
> >Cc: Tero Kristo <t-kri...@ti.com>
> >Signed-off-by: Tony Lindgren <t...@atomide.com>
> >---
> >
> >If no more comments, Tero can you please apply into an immutable
> >branch against v4.4-rc1 that I can merge in too?
> >
> >Changes since v3:
> >
> >- We want to create the clkdev entry for all clocks, not just outputs
> >- ti_adpll_wait_lock loops did not do the right thing
> >- We want to use CLK_GET_RATE_NOCACHE in ti_adpll_init_dco
> 
> I have just one comment below still, once that is addressed:
> 
> Conditionally-acked-by: Tero Kristo <t-kri...@ti.com>
> 
> Stephen / Michael, can you pick this up for next merge? I don't have
> anything else coming for the window this time, and I am probably going to be
> on vacation just nicely to not be able to push anything anyway.

Also, I managed to remove the dependency to the dts changes. So there's
no longer any need to set up an immutable branch for this patch.

> 
> 
> >+
> >+/* Warn if clkout or clkoutx2 try to set unavailable parent */
> >+static int ti_adpll_clkout_set_parent(struct clk_hw *hw, u8 index)
> >+{
> >+struct ti_adpll_clkout_data *co = to_clkout(hw);
> >+struct ti_adpll_data *d = co->adpll;
> >+
> >+if (ti_adpll_clock_is_bypass(d) != index)
> >+return -EAGAIN;
> >+
> 
> I think this part is still somewhat weird. You are not doing anything useful
> in this function, so do you need to implement it at all? Just returning
> -EINVAL always might work also. EAGAIN is wrong return value anyway as it
> can pretty much never succeed.

OK thanks sounds good to me, I'll check it this after lunch.

Also noticed the do_div should be div64_u64 so v5 coming later
today.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] ARM: OMAP2+: Fix randconfig build warning for dm814_pllss_data

[Tony Lindgren]

Fix warning for arch/arm/mach-omap2/prm_common.c:666:35: warning:
‘dm814_pllss_data’ defined but not used [-Wunused-variable]".

This can happen if CONFIG_SOC_TI81XX is not selected.

Signed-off-by: Tony Lindgren <t...@atomide.com>
---
 arch/arm/mach-omap2/prm_common.c | 2 ++
 1 file changed, 2 insertions(+)

--- a/arch/arm/mach-omap2/prm_common.c
+++ b/arch/arm/mach-omap2/prm_common.c
@@ -662,7 +662,9 @@ static struct omap_prcm_init_data am3_prm_data __initdata = 
{
.index = TI_CLKM_PRM,
.init = am33xx_prm_init,
 };
+#endif
 
+#ifdef CONFIG_SOC_TI81XX
 static struct omap_prcm_init_data dm814_pllss_data __initdata = {
.index = TI_CLKM_PLLSS,
.init = am33xx_prm_init,
-- 
2.6.2

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] ARM: OMAP: am43xx: enable GENERIC_CLOCKEVENTS_BROADCAST

[Tony Lindgren]

* Grygorii Strashko  [151214 12:35]:
> System will misbehave in the following case:
> - AM43XX only build (UP);
> - CONFIG_CPU_IDLE=y
> - ARM TWD timer enabled and selected as clockevent device.
> 
> In the above case, It's expected that broadcast timer will be used as
> backup timer when CPUIdle will put MPU in low power states where ARM
> TWD will stop and lose its context. But, the CONFIG_SMP might not be
> selected when kernel is built for AM43XX SoC only and, as result,
> GENERIC_CLOCKEVENTS_BROADCAST option will not be selected also. This
> will break CPUIdle and System will stuck in low power states.
> 
> Hence, fix it by selecting GENERIC_CLOCKEVENTS_BROADCAST option for
> AM43XX SoCs always and add empty tick_broadcast() function
> implementation - no need to send any IPI on UP. After this change
> timer1 will be selected as broadcast timer the same way as for SMP,
> and CPUIdle will work properly.

I've applied both of these into omap-for-v4.4/fixes because of the
description above.

Regards,

Tony

> 
> Signed-off-by: Grygorii Strashko 
> ---
>  arch/arm/mach-omap2/Kconfig | 1 +
>  arch/arm/mach-omap2/timer.c | 6 ++
>  2 files changed, 7 insertions(+)
> 
> diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
> index 4b4371d..32a0086 100644
> --- a/arch/arm/mach-omap2/Kconfig
> +++ b/arch/arm/mach-omap2/Kconfig
> @@ -65,6 +65,7 @@ config SOC_AM43XX
>   select MACH_OMAP_GENERIC
>   select MIGHT_HAVE_CACHE_L2X0
>   select HAVE_ARM_SCU
> + select GENERIC_CLOCKEVENTS_BROADCAST
>  
>  config SOC_DRA7XX
>   bool "TI DRA7XX"
> diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
> index 3bfde44..f34a809 100644
> --- a/arch/arm/mach-omap2/timer.c
> +++ b/arch/arm/mach-omap2/timer.c
> @@ -320,6 +320,12 @@ static int __init omap_dm_timer_init_one(struct 
> omap_dm_timer *timer,
>   return r;
>  }
>  
> +#if !defined(CONFIG_SMP) && defined(CONFIG_GENERIC_CLOCKEVENTS_BROADCAST)
> +void tick_broadcast(const struct cpumask *mask)
> +{
> +}
> +#endif
> +
>  static void __init omap2_gp_clockevent_init(int gptimer_id,
>   const char *fck_source,
>   const char *property)
> -- 
> 2.6.4
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: OMAP2+: LogicPD Torpedo: Add Touchscreen Support

[Tony Lindgren]

* Adam Ford  [151220 07:26]:
> The development kit uses a TSC2004 chip attached to I2C3.

Applying into omap-for-v4.5/dt thanks.

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[GIT PULL] few minor omap fixes against v4.4-rc6

[Tony Lindgren]

The following changes since commit 14054fb1da099fd89208b8b319a00e0b902c7645:

  ARM: dts: am4372: fix clock source for arm twd and global timers (2015-12-09 
16:46:25 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap 
tags/omap-for-v4.4/fixes-rc6

for you to fetch changes up to 0b4d6972d7b052b23d33ff9bdbb52958664fbb26:

  ARM: dts: Fix UART wakeirq for omap4 duovero parlor (2015-12-18 16:43:22 
-0800)


Few fixes for omaps to allow am437x only builds to boot properly with
CPU_IDLE and ARM TWD timer. This is probably a common configuration setup
for people making products with these SoCs so let's make sure it works.

Also a wakeirq fix for duovero parlor making my life a bit easier as that
allows me to run basic PM regression tests on it.

It would be nice to have these in v4.4, but if it gets too late for that
because of the holidays, it is not super critical if these get merged for
v4.5.


Felipe Balbi (1):
  ARM: OMAP2+: AM43xx: select ARM TWD timer

Grygorii Strashko (1):
  ARM: OMAP2+: am43xx: enable GENERIC_CLOCKEVENTS_BROADCAST

Tony Lindgren (1):
  ARM: dts: Fix UART wakeirq for omap4 duovero parlor

 arch/arm/boot/dts/omap4-duovero-parlor.dts | 4 
 arch/arm/mach-omap2/Kconfig| 2 ++
 arch/arm/mach-omap2/timer.c| 6 ++
 3 files changed, 12 insertions(+)

---
diff --git a/arch/arm/boot/dts/omap4-duovero-parlor.dts 
b/arch/arm/boot/dts/omap4-duovero-parlor.dts
index 1a78f01..b75f7b2 100644
--- a/arch/arm/boot/dts/omap4-duovero-parlor.dts
+++ b/arch/arm/boot/dts/omap4-duovero-parlor.dts
@@ -189,3 +189,7 @@
};
 };
 
+ {
+   interrupts-extended = < GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH
+  _pmx_core OMAP4_UART3_RX>;
+};
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 4b4371d..0517f0c 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -65,6 +65,8 @@ config SOC_AM43XX
select MACH_OMAP_GENERIC
select MIGHT_HAVE_CACHE_L2X0
select HAVE_ARM_SCU
+   select GENERIC_CLOCKEVENTS_BROADCAST
+   select HAVE_ARM_TWD
 
 config SOC_DRA7XX
bool "TI DRA7XX"
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index b18ebbe..f86692d 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -320,6 +320,12 @@ static int __init omap_dm_timer_init_one(struct 
omap_dm_timer *timer,
return r;
 }
 
+#if !defined(CONFIG_SMP) && defined(CONFIG_GENERIC_CLOCKEVENTS_BROADCAST)
+void tick_broadcast(const struct cpumask *mask)
+{
+}
+#endif
+
 static void __init omap2_gp_clockevent_init(int gptimer_id,
const char *fck_source,
const char *property)
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[GIT PULL 3/4] omap wakeup-m3 driver for v4.5 merge window

[Tony Lindgren]

The following changes since commit 8005c49d9aea74d382f474ce11afbbc7d7130bec:

  Linux 4.4-rc1 (2015-11-15 17:00:27 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap 
tags/omap-for-v4.5/wakeup-m3

for you to fetch changes up to cdd5de500b2c90d5181ebc963826019a0a4234ba:

  soc: ti: Add wkup_m3_ipc driver (2015-12-03 07:24:29 -0800)


TI wakeup M3 IPC device driver for v4.5 merge window. This driver will
eventually allow am33xx and am437x to support PM with their Cortex-M3
power management processor.

This driver has been waiting to get merged for quite a while but has
had dependencies to the remoteproc that are now out of the way.


Dave Gerlach (2):
  Documentation: dt: add bindings for TI Wakeup M3 IPC device
  soc: ti: Add wkup_m3_ipc driver

 .../devicetree/bindings/soc/ti/wkup_m3_ipc.txt |  57 +++
 drivers/soc/ti/Kconfig |  10 +
 drivers/soc/ti/Makefile|   1 +
 drivers/soc/ti/wkup_m3_ipc.c   | 508 +
 include/linux/wkup_m3_ipc.h|  55 +++
 5 files changed, 631 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/soc/ti/wkup_m3_ipc.txt
 create mode 100644 drivers/soc/ti/wkup_m3_ipc.c
 create mode 100644 include/linux/wkup_m3_ipc.h
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[GIT PULL 2/4] omap changes for ti81xx devices and minimal dra62x j5eco-evm support

[Tony Lindgren]

The following changes since commit d893656e61040f3ff7b5f72a986052a348f3c94e:

  ARM: OMAP2+: Remove useless check for legacy booting for dm814x (2015-12-09 
16:53:46 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap 
tags/omap-for-v4.5/81xx-devices

for you to fetch changes up to 8f2cf92a912ca7173d29c045d225588c9630ed94:

  ARM: dts: Add usb support for j5-eco evm (2015-12-21 10:43:29 -0800)


Now with dm814x support fixed up enough where we can make use of some clocks,
we can adds some more basic devices for dm814x. And we can also add minimal
support for dra62x j5eco-evm that is another ti81xx variant related to dm814x.

I would have rather merged this series toghether with the ADPLL clock driver,
and was waiting for that to get merged before sending out these patches. But
the ADPLL clock driver can be merged separately, and at least dm814x-evm,
dra62x-j5eco-evm, and t410 all boot with this series alone. So let's merge
these patches separately as that allows people to do development on these
platforms for other device drivers using the mainline kernel.

Note that this series depends on the earlier 81xx-fixes and omap initcall
changes. It also depends on the DMA commit ae0add740cd0 that's already in
mainline. As this series is mostly DTS changes with a few related hwmod
changes, it's probably best merged along with the other DTS changes.


Peter Ujfalusi (2):
  dmaengine: edma: DT: Change memcpy channel array from 16bit to 32bit type
  dmaengine: edma: DT: Change reserved slot array from 16bit to 32bit type

Tony Lindgren (19):
  ARM: OMAP2+: Change core_initcall levels to postcore_initcall
  ARM: OMAP2+: Fix randconfig build warning for dm814_pllss_data
  Merge branch 'omap-for-v4.5/initcall'; commit 
'ae0add740cd06169cd124f9aaa6eceb11e5b3060' into omap-for-v4.5/81xx-fixes
  ARM: OMAP2+: Fix SoC detection for dra62x j5-eco
  ARM: dts: Add basic support for dra62x j5-eco SoC
  ARM: dts: Add minimal dra62x j5-eco evm support
  ARM: dts: Add pinctrl macros for dm814x
  ARM: dts: Update edma bindings on dm814x to use edma_xbar
  ARM: OMAP2+: Add mmc hwmod entries for dm814x
  ARM: dts: Add mmc device entries for dm814x
  ARM: dts: Add mmc support for dm8148-evm
  ARM: dts: Add mmc support for dra62x j5-eco evm
  ARM: dts: Enable emmc on hp t410
  ARM: OMAP2+: Update 81xx clock and power domains for default, active and 
sgx
  ARM: OMAP2+: Add support for dm814x and dra62x usb
  ARM: dts: Add usb support for dm814x and dra62x
  ARM: dts: Add usb support for dm814x-evm
  ARM: dts: Add usb support for hp t410
  ARM: dts: Add usb support for j5-eco evm

 Documentation/devicetree/bindings/dma/ti-edma.txt |  10 +-
 arch/arm/boot/dts/Makefile|   3 +-
 arch/arm/boot/dts/dm8148-evm.dts  |  55 ++
 arch/arm/boot/dts/dm8148-t410.dts |  70 +++
 arch/arm/boot/dts/dm814x.dtsi | 226 --
 arch/arm/boot/dts/dra62x-clocks.dtsi  |  23 +++
 arch/arm/boot/dts/dra62x-j5eco-evm.dts|  80 
 arch/arm/boot/dts/dra62x.dtsi |  23 +++
 arch/arm/mach-omap2/clockdomains81xx_data.c   |  29 +--
 arch/arm/mach-omap2/cm81xx.h  |   6 +-
 arch/arm/mach-omap2/id.c  |   4 +-
 arch/arm/mach-omap2/omap2-restart.c   |   2 +-
 arch/arm/mach-omap2/omap_device.c |   2 +-
 arch/arm/mach-omap2/omap_hwmod.c  |   2 +-
 arch/arm/mach-omap2/omap_hwmod_81xx_data.c| 131 +++--
 arch/arm/mach-omap2/powerdomains3xxx_data.c   |  10 +-
 arch/arm/mach-omap2/prm_common.c  |   2 +
 arch/arm/mach-omap2/serial.c  |   2 +-
 drivers/dma/edma.c|  53 +++--
 include/dt-bindings/pinctrl/dm814x.h  |  48 +
 include/dt-bindings/pinctrl/omap.h|   1 +
 include/linux/platform_data/edma.h|   2 +-
 22 files changed, 702 insertions(+), 82 deletions(-)
 create mode 100644 arch/arm/boot/dts/dra62x-clocks.dtsi
 create mode 100644 arch/arm/boot/dts/dra62x-j5eco-evm.dts
 create mode 100644 arch/arm/boot/dts/dra62x.dtsi
 create mode 100644 include/dt-bindings/pinctrl/dm814x.h
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[GIT PULL 1/4] omap soc changes for v4.5 merge window

[Tony Lindgren]

The following changes since commit 1ec218373b8ebda821aec00bb156a9c94fad9cd4:

  Linux 4.4-rc2 (2015-11-22 16:45:59 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap 
tags/omap-for-v4.5/soc-initcall

for you to fetch changes up to f2e6a0a913b53f5af87c7e9a783ceae5bb4ae2c4:

  ARM: OMAP2+: Remove device creation for omap-pcm-audio (2015-12-17 10:34:41 
-0800)


SoC changes for omaps for v4.5 merge window. The main change here is to
change the omap initcall levels a bit to initialize things later to allow
early device drivers at core_initcall level. This makes things easier
for us as most clocks can be made into regular device drivers except for
a few early clocks needed to initialize system timers. I wanted to have
these changes sit in Linux next for a few weeks before sending out a pull
request, and so far now issues have showed up.

The other changes in this series are timer changes for making use of the
new PWM driver, and timer changes to support more high security SoCs.
Also few minor improvments for module autoidle settings for ti81xx spinbox
and dra7 debug on uart4 in hwmod code. The rest is pretty much just removal
of platform data for SoCs that are all device tree only nowadays.


Aaro Koskinen (1):
  ARM: OMAP: RX-51: fix a typo in log writing

Franklin S Cooper Jr (1):
  ARM: omap4: hwmod: Remove elm address space from hwmod data

J.D. Schroeder (1):
  ARM: DRA7: hwmod: Enable DEBUG_LL for UART4

Neil Armstrong (3):
  ARM: OMAP: dmtimer: Add clock source from DT
  ARM: OMAP: add DT support for ti,dm816-timer
  ARM: OMAP2+: Add hwmod spinbox support for dm816x

Peter Ujfalusi (2):
  ARM: OMAP1: Remove device creation for omap-pcm-audio
  ARM: OMAP2+: Remove device creation for omap-pcm-audio

Suman Anna (6):
  ARM: OMAP2+: Remove legacy device instantiation of IOMMUs
  ARM: OMAP3: hwmod data: Remove legacy IOMMU data
  ARM: OMAP4: hwmod data: Remove legacy IOMMU attr and addrs
  ARM: OMAP2+: Remove omap_mmu_dev_attr structure
  ARM: OMAP: dmtimer: check for fixed timers during config
  ARM: OMAP2+: timer: Remove secure timer for DRA7xx HS devices

Tony Lindgren (2):
  ARM: OMAP2+: Change core_initcall levels to postcore_initcall
  Merge branch 'omap-for-v4.5/initcall' into omap-for-v4.5/soc-v2

 arch/arm/mach-omap1/devices.c| 19 
 arch/arm/mach-omap2/Makefile |  2 -
 arch/arm/mach-omap2/board-rx51-peripherals.c |  2 +-
 arch/arm/mach-omap2/devices.c| 25 ++-
 arch/arm/mach-omap2/omap-iommu.c | 66 
 arch/arm/mach-omap2/omap2-restart.c  |  2 +-
 arch/arm/mach-omap2/omap_device.c|  2 +-
 arch/arm/mach-omap2/omap_hwmod.c |  2 +-
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c   | 42 --
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c   | 41 -
 arch/arm/mach-omap2/omap_hwmod_7xx_data.c|  2 +-
 arch/arm/mach-omap2/omap_hwmod_81xx_data.c   | 35 +++
 arch/arm/mach-omap2/pdata-quirks.c   |  2 +-
 arch/arm/mach-omap2/serial.c |  2 +-
 arch/arm/mach-omap2/timer.c  |  6 +--
 arch/arm/plat-omap/dmtimer.c | 42 +-
 include/linux/platform_data/iommu-omap.h |  9 
 17 files changed, 90 insertions(+), 211 deletions(-)
 delete mode 100644 arch/arm/mach-omap2/omap-iommu.c
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[GIT PULL 4/4] omap device tree changes for v4.5, part 2

[Tony Lindgren]

The following changes since commit 89c6f2e5ab7a0499c6bcb25d281977ada205765d:

  ARM: dts: omap3-igep0030: Use MMC pwrseq to init SDIO WiFi (2015-12-07 
16:11:43 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap 
tags/omap-for-v4.5/dt-pt2

for you to fetch changes up to 6c95771f8c71cd4dd6ed7ab84a3aea7d509d7704:

  ARM: OMAP2+: LogicPD Torpedo: Add Touchscreen Support (2015-12-21 11:10:40 
-0800)


Second set of omap device tree changes for v4.5 merge window. This series
updates the EDMA bindings based on the various fixes to split EDMA into
separate independent devices. It also adds support for more devices on the
CompuLab cm-t335 and LogicPD Torpedo boards, and enables the new bindings
for qspi for am437x and dra7. There are also few dra7 regulator fixes, and
change of gpoi-key,wakeup to wakeup-source.

These depend on commit ae0add740cd0 ("dmaengine: edma: DT: Change reserved
slot array from 16bit to 32bit type") already merged into mainline.


Adam Ford (4):
  ARM: OMAP2+: LogicPD Torpedo: Add LCD Type 15 Support
  ARM: OMAP2+: LogicPD Torpedo + Wireless: Add Bluetooth
  ARM: OMAP2+: LogicPD Torpedo: Revert Duplicative Entries
  ARM: OMAP2+: LogicPD Torpedo: Add Touchscreen Support

Ilya Ledvich (1):
  ARM: dts: cm-t335: add support for USB0

Keerthy (2):
  ARM: dts: DRA72-EVM: Add regulator-allow-bypass property for ldo1 and ldo2
  ARM: dts: DRA7-EVM: Add regulator-allow-bypass property for ldo9

Peter Ujfalusi (4):
  dmaengine: edma: DT: Change memcpy channel array from 16bit to 32bit type
  dmaengine: edma: DT: Change reserved slot array from 16bit to 32bit type
  ARM: DTS: am33xx: Use the new DT bindings for the eDMA3
  ARM: DTS: am437x: Use the new DT bindings for the eDMA3

Sudeep Holla (2):
  ARM: dts: am335x: replace gpio-key,wakeup with wakeup-source property
  ARM: dts: omap: replace legacy *,wakeup property with wakeup-source

Tony Lindgren (1):
  Merge commit 'ae0add740cd06169cd124f9aaa6eceb11e5b3060' into 
omap-for-v4.5/dt

Uri Mashiach (4):
  ARM: dts: cm-t335: add support for SBC-T335
  ARM: dts: cm-t335: add support for I2C GPIO expander
  ARM: dts: cm-t335: add support for DVI/LCD
  ARM: dts: cm-t335: add support for bluetooth

Vignesh R (2):
  ARM: dts: DRA7: add entry for qspi mmap region
  ARM: dts: AM4372: add entry for qspi mmap region

 .../devicetree/bindings/arm/omap/omap.txt  |   3 +
 Documentation/devicetree/bindings/dma/ti-edma.txt  |  10 +-
 Documentation/devicetree/bindings/spi/ti_qspi.txt  |  22 ++-
 arch/arm/boot/dts/Makefile |   1 +
 arch/arm/boot/dts/am335x-cm-t335.dts   |  51 -
 arch/arm/boot/dts/am335x-evm.dts   |  13 +-
 arch/arm/boot/dts/am335x-evmsk.dts |   2 +-
 arch/arm/boot/dts/am335x-pepper.dts|  17 +-
 arch/arm/boot/dts/am335x-sbc-t335.dts  | 219 +
 arch/arm/boot/dts/am33xx.dtsi  |  94 ++---
 arch/arm/boot/dts/am4372.dtsi  |  84 ++--
 arch/arm/boot/dts/am437x-gp-evm.dts|   9 +-
 arch/arm/boot/dts/dra7-evm.dts |   1 +
 arch/arm/boot/dts/dra7.dtsi|   6 +-
 arch/arm/boot/dts/dra72-evm.dts|   2 +
 arch/arm/boot/dts/logicpd-torpedo-37xx-devkit.dts  | 145 --
 arch/arm/boot/dts/omap3-beagle-xm.dts  |   2 +-
 arch/arm/boot/dts/omap3-beagle.dts |   2 +-
 arch/arm/boot/dts/omap3-cm-t3x.dtsi|   2 +-
 arch/arm/boot/dts/omap3-devkit8000-common.dtsi |   2 +-
 arch/arm/boot/dts/omap3-devkit8000-lcd-common.dtsi |   2 +-
 arch/arm/boot/dts/omap3-gta04.dtsi |   2 +-
 arch/arm/boot/dts/omap3-ldp.dts|  18 +-
 arch/arm/boot/dts/omap3-lilly-a83x.dtsi|   2 +-
 arch/arm/boot/dts/omap3-n900.dts   |  10 +-
 arch/arm/boot/dts/omap3-overo-alto35-common.dtsi   |   2 +-
 .../boot/dts/omap3-overo-chestnut43-common.dtsi|   4 +-
 arch/arm/boot/dts/omap3-overo-common-lcd35.dtsi|   2 +-
 arch/arm/boot/dts/omap3-overo-common-lcd43.dtsi|   2 +-
 arch/arm/boot/dts/omap3-overo-gallop43-common.dtsi |   4 +-
 arch/arm/boot/dts/omap3-overo-palo35-common.dtsi   |   4 +-
 arch/arm/boot/dts/omap3-overo-palo43-common.dtsi   |   4 +-
 arch/arm/boot/dts/omap3-pandora-common.dtsi|  34 ++--
 .../boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi|   2 +-
 arch/arm/boot/dts/omap4-duovero-parlor.dts |   2 +-
 arch/arm/boot/dts/omap4-var-om44customboard.dtsi   |   2 +-
 arch/arm/boot/dts/omap5-cm-t54.dts |   2 +-
 arch/arm/mach-omap2/pdata-quirks.c |  24 ++-
 drivers/dma/edma.c

Re: [PATCH v3] clk: ti: Add support for dm814x ADPLL

[Tony Lindgren]

* Tony Lindgren <t...@atomide.com> [151215 13:02]:
> On dm814x we have 13 ADPLLs with 3 to 4 outputs on each. The
> ADPLLs have several dividers and muxes controlled by a shared
> control register for each PLL.
> 
> Note that for the clocks to work as device drivers for booting on
> dm814x, this patch depends on "ARM: OMAP2+: Change core_initcall
> levels to postcore_initcall".
> 
> Also note that this patch does not implement clk_set_rate for the
> PLL, that will be posted later on when available.
> 
> Cc: Michael Turquette <mturque...@baylibre.com>
> Cc: Stephen Boyd <sb...@codeaurora.org>
> Cc: Tero Kristo <t-kri...@ti.com>
> Signed-off-by: Tony Lindgren <t...@atomide.com>
> ---
> Changes from v2 to v3 are listed below, hopefully I addressed everybody's
> comments,please check and let me know if I missed something.

Everybody OK with this version as no more comments?

I found a few issues that are worth merging while testing:

- We want to create the clkdev entry for all clocks, not just outputs
- ti_adpll_wait_lock loops did not do the right thing
- We want to use CLK_GET_RATE_NOCACHE in ti_adpll_init_dco

Diff against v3 below for reference, will also send out v4 separately.

Regards,

Tony

8< -
--- a/drivers/clk/ti/adpll.c
+++ b/drivers/clk/ti/adpll.c
@@ -228,9 +228,6 @@ static int ti_adpll_setup_clock(struct ti_adpll_data *d, 
struct clk *clock,
d->clocks[index].clk = clock;
d->clocks[index].unregister = unregister;
 
-   if (output_index < 0)
-   return 0;
-
/* Separate con_id in format "pll040dcoclkldo" to fit MAX_CON_ID */
postfix = strrchr(name, '.');
if (strlen(postfix) > 1) {
@@ -246,6 +243,9 @@ static int ti_adpll_setup_clock(struct ti_adpll_data *d, 
struct clk *clock,
dev_warn(d->dev, "no con_id for clock %s\n", name);
}
 
+   if (output_index < 0)
+   return 0;
+
d->outputs.clks[output_index] = clock;
d->outputs.clk_num++;
 
@@ -418,7 +418,7 @@ static int ti_adpll_wait_lock(struct ti_adpll_data *d)
if (ti_adpll_is_locked(d))
return 0;
usleep_range(200, 300);
-   } while (retries-- <= 0);
+   } while (retries--);
 
dev_err(d->dev, "pll failed to lock\n");
return -ETIMEDOUT;
@@ -527,6 +527,7 @@ static int ti_adpll_init_dco(struct ti_adpll_data *d)
init.parent_names = d->parent_names;
init.num_parents = d->c->nr_max_inputs;
init.ops = _adpll_ops;
+   init.flags = CLK_GET_RATE_NOCACHE;
d->dco.hw.init = 
 
if (d->c->is_type_s)
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: OMAP PM question

[Tony Lindgren]

Hi,

* Renju Liu  [151220 15:00]:
> Hello all,
> 
> For omap4, I wonder how should emif be handled when suspending the entire SoC.
> 
> In playing with Robert Nelson's 4.2 kernel tree [1], I noticed that
> the suspend seems broken: the kernel, in the suspend_noirq phase,
> tries to disable the emif hwmod by calling omap_device_idle(); the
> board thus hangs. It appears to me that the DDR shouldn't be disabled
> at this moment or it needs special treatment -- in comparison, the
> AM35xx kernel switches its execution to on-chip SRAM before turning
> off the emif.
> 
> I tried to examine earlier kernels (3.2, 3.4) for omap4 to see how
> emif is power-managed. However I didn't see much useful information.

Hmm am437x is different where it's using a GPIO pin to power the memory.
That's not the case on pandaboard or typical omap2/3/4/5 boards and
seems to be limited to am33xx/am437x designs.

Things should work with current mainline, at least this works for
me on omap4430:

# rtcwake -m mem -s 5

And wakes up properly five seconds later.

And this also works for me with current mainline kernel:

#!/bin/bash

uarts=$(find /sys/class/tty/tty[SO]*/device/power/ -type d)
for uart in $uarts; do
echo 3000 > $uart/autosuspend_delay_ms 2>&1
done

uarts=$(find /sys/class/tty/tty[SO]*/power/ -type d 2>/dev/null)
for uart in $uarts; do
echo enabled > $uart/wakeup 2>&1
echo auto > $uart/control 2>&1
done

echo 1 > /sys/kernel/debug/pm_debug/enable_off_mode

And then echo mem > /sys/power/state will wake up to serial console
activity.

This is with duovero and the wakeriq patch for it's console UART that
I posted last week. AFAIK panda already has that enabled.

Regards,

Tony


> 1. https://eewiki.net/display/linuxonarm/PandaBoard
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 1/9] ARM: OMAP2+: omap_device: create clock alias purely from DT data

[Tony Lindgren]

* Tero Kristo  [151218 05:57]:
> This avoids the need to add most of the clock aliases under
> drivers/clk/ti/clk-xyz.c files.

Yup is badly needed. Right now we have strange hidden dependencies
in multiple subsystems to enable a single device driver:

1. Add a clock alias for a device
2. Add hwmod entries for a device
3. Add dts entries for a device
4. Add a device driver

We really should only need steps 3 and 4 to do that, hopefully
this takes out #1 on the list above.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 8/9] ARM: OMAP4: hwmod_data: use module clocks from DT

[Tony Lindgren]

* Tero Kristo  [151218 05:57]:
> Replace the usage of prcm->clkstctrl with main_clk:s provided via DT.
> This is done in preparation to get rid of hwmod data from kernel.
...
> --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> @@ -334,10 +329,9 @@ static struct omap_hwmod omap44xx_counter_32k_hwmod = {
>   .class  = _counter_hwmod_class,
>   .clkdm_name = "l4_wkup_clkdm",
>   .flags  = HWMOD_SWSUP_SIDLE,
> - .main_clk   = "sys_32k_ck",
> + .main_clk   = "counter_32k_mod_ck",
>   .prcm = {
>   .omap4 = {
> - .clkctrl_offs = OMAP4_CM_WKUP_SYNCTIMER_CLKCTRL_OFFSET,
>   .context_offs = OMAP4_RM_WKUP_SYNCTIMER_CONTEXT_OFFSET,
>   },
>   },

Care to describe why the main_clk now needs to be modified or
added? Can that too come from dts now?

Regards,

Tony

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mmc: pwrseq_simple: Fix regression with optional GPIOs

[Tony Lindgren]

* Ulf Hansson <ulf.hans...@linaro.org> [151207 16:20]:
> +Linus
> 
> On 7 December 2015 at 23:54, Tony Lindgren <t...@atomide.com> wrote:
> > Commit ce037275861e ("mmc: pwrseq_simple: use GPIO descriptors array API")
> > changed the handling MMC power sequence so GPIOs no longer are optional.
> >
> > This broke SDIO WLAN at least for omap5 that can't yet use the reset GPIOs
> > with pwrseq_simple as a wait is needed after enabling the SDIO device.
> 
> Can you elaborate on this. Did it break omap5 or not? :-)

Ulf, is this patch queued for v4.4 as a regression fix? I don't see it
in Linux next or mainline trees?

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: OMAP display kconfig options changing

[Tony Lindgren]

* Tomi Valkeinen <tomi.valkei...@ti.com> [151218 07:01]:
> 
> 
> On 18/12/15 15:53, Tony Lindgren wrote:
> > Hi,
> > 
> > * Tomi Valkeinen <tomi.valkei...@ti.com> [151218 00:55]:
> >> Hi Tony,
> >>
> >> I've just pushed a patch series to fbdev for-next branch which makes the
> >> OMAP DRM and FB drivers independent of each other. This requires
> >> changing the related Kconfig options.
> > 
> > OK
> 
> Note that nothing has changed with omapfb and omapdrm as such. The only
> (visible) change is the needed Kconfig options.

OK

> >> What should I do with omap2plus_defconfig?
> >>
> >> At the moment omap2plus_defconfig enables the omapfb driver and panels
> >> as modules. Should I change it to do the same with the new code? Or
> >> should I change it to use omapdrm, which is the better maintained and
> >> developed driver (although no one has probably tried omapdrm on omap2)?
> > 
> > I'm all for changing omap2plus_defconfnig to use omapdrm.
> > 
> > Do you have a link to a page we can point people to for instructions
> > for what needs to be changed to get things working with omapdrm?
> 
> Are you referring to Kconfig options? Or userspace?

Well sounds like both need updating :)

> But no, I don't have links to either.

So change the Kconfig options and then deal with the flood
of angry emails? :) I think we need instructions..

> For the Kconfig options, it's pretty similar to omapfb. After the
> patches I'm pushing, one needs to enable DRM, DRM_OMAP, and then the
> individual panel/encoder drivers (as for omapfb).
> 
> > For omap2, I can try to peek into my rack for n800.
> 
> There were a few fixes sent a few days ago which are needed for OMAP2/3.
> I think both are now in Linus' tree.

OK I guess we have to wait your patches then to give it
a try.

Regards,

Tony

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 6/9] clk: ti: add support for omap4 module clocks

[Tony Lindgren]

* Tero Kristo  [151218 05:57]:
> Previously, hwmod core has been used for controlling the hwmod level
> clocks. This has certain drawbacks, like being unable to share the
> clocks for multiple users, missing usecounting and generally being
> totally incompatible with common clock framework.
> 
> Add support for new clock type under the TI clock driver, which will
> be used to convert all the existing hwmod clocks to. This helps to
> get rid of the clock related hwmod data from kernel and instead
> parsing this from DT.

Good to see this happening, few comments on what I've noticed so
far that should be considered.

We should be able to do a generic "ti,mux-div-gate" clock and use
it for the clkctrl too I think. See the suggested binding elsewhere
in this thread. That would also work for the clkout register at least.
Maybe the "ti,mux-div-gate" clock needs a separate clkctrl type
compatible to know it needs to sleep to wait for the status bit.

Also, we already know these clkctrl register do have multiple clocks,
like the GPIO debounce and dividers for debugss clock. And we want
to get rid of the overlapping reg entries.

> +static int _omap4_hwmod_clk_enable(struct clk_hw *hw)
> +{
> + struct clk_hw_omap *clk = to_clk_hw_omap(hw);
> + u32 val;
> + int timeout = 0;
> + int ret;
> +
> + if (!clk->enable_bit)
> + return 0;
> +
> + if (clk->clkdm) {
> + ret = ti_clk_ll_ops->clkdm_clk_enable(clk->clkdm, hw->clk);
> + if (ret) {
> + WARN(1,
> +  "%s: could not enable %s's clockdomain %s: %d\n",
> +  __func__, clk_hw_get_name(hw),
> +  clk->clkdm_name, ret);
> + return ret;
> + }
> + }
> +
> + val = ti_clk_ll_ops->clk_readl(clk->enable_reg);
> +
> + val &= ~OMAP4_MODULEMODE_MASK;
> + val |= clk->enable_bit;
> +
> + ti_clk_ll_ops->clk_writel(val, clk->enable_reg);
> +
> + /* Wait until module is enabled */
> + while (!_omap4_is_ready(val)) {
> + udelay(1);
> + timeout++;
> + if (timeout > OMAP4_MAX_MODULE_READY_TIME) {
> + pr_err("%s: failed to enable\n", clk_hw_get_name(hw));
> + return -EBUSY;
> + }
> + val = ti_clk_ll_ops->clk_readl(clk->enable_reg);
> + }
> +
> + return 0;
> +}

Clocks that need to wait to lock need to be set up with clk_prepare
instead of clk_enable as pointed out by TGLX recently. Also see the
"[PATCH] clk: ti: Fix FAPLL udelay in clk_enable with clk_prepare".

Not sure what all needs to be fixed in the hwmod code for that to
happen and PM to work, but that probably needs to be done first.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: OMAP display kconfig options changing

[Tony Lindgren]

Hi,

* Tomi Valkeinen  [151218 00:55]:
> Hi Tony,
> 
> I've just pushed a patch series to fbdev for-next branch which makes the
> OMAP DRM and FB drivers independent of each other. This requires
> changing the related Kconfig options.

OK

> What should I do with omap2plus_defconfig?
> 
> At the moment omap2plus_defconfig enables the omapfb driver and panels
> as modules. Should I change it to do the same with the new code? Or
> should I change it to use omapdrm, which is the better maintained and
> developed driver (although no one has probably tried omapdrm on omap2)?

I'm all for changing omap2plus_defconfnig to use omapdrm.

Do you have a link to a page we can point people to for instructions
for what needs to be changed to get things working with omapdrm?

For omap2, I can try to peek into my rack for n800.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 4/5] ARM: dts: DRA7: add entry for qspi mmap region

[Tony Lindgren]

* Vignesh R <vigne...@ti.com> [151217 21:51]:
> 
> 
> On 12/18/2015 12:15 AM, Tony Lindgren wrote:
> > * Rob Herring <r...@kernel.org> [151211 07:10]:
> >> On Fri, Dec 11, 2015 at 09:39:59AM +0530, Vignesh R wrote:
> >>> Add qspi memory mapped region entries for DRA7xx based SoCs. Also,
> >>> update the binding documents for the controller to document this change.
> >>>
> >>> Signed-off-by: Vignesh R <vigne...@ti.com>
> >>
> >> Acked-by: Rob Herring <r...@kernel.org>
> > 
> > Vignes, are patches 4 and 5 safe to apply separately already or
> > do things break if we do that?
> 
> Yes, 4 and 5 can be applied separately w/o driver changes.

OK picking 4 and 5 into omap-for-v4.5/dt thanks.

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/3] ARM: dts: DRA72-EVM: Add regulator-allow-bypass property for ldo1 and ldo2

[Tony Lindgren]

* Keerthy <a0393...@ti.com> [151217 21:15]:
> Hi Tony,
> 
> On Friday 18 December 2015 12:14 AM, Tony Lindgren wrote:
> >* Keerthy <j-keer...@ti.com> [151213 22:38]:
> >>Add regulator-allow-bypass property for ldo1 and ldo2.
> >
> >Are patches 2 and 3 safe to apply separately already or do
> >we need to wait for the regulator patch to go in first?
> 
> Yes they are okay to apply. I boot tested them without regulator patch and i
> saw no boot issues on dra7-evm.

OK thanks picking 2 and 3 into omap-for-v4.5/dt.

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] ARM: dts: Fix UART wakeirq for omap4 duovero parlor

[Tony Lindgren]

Looks like we're missing the wakeirq for the console uart for
duovero parlor. Let's add that as without it console acess just
hangs with PM enabled.

Cc: Arun Bharadwaj <a...@gumstix.com>
Cc: Ash Charles <a...@gumstix.com>
Cc: Florian Vaussard <florian.vauss...@epfl.ch>
Signed-off-by: Tony Lindgren <t...@atomide.com>
---
 arch/arm/boot/dts/omap4-duovero-parlor.dts | 4 
 1 file changed, 4 insertions(+)

--- a/arch/arm/boot/dts/omap4-duovero-parlor.dts
+++ b/arch/arm/boot/dts/omap4-duovero-parlor.dts
@@ -189,3 +189,7 @@
};
 };
 
+ {
+   interrupts-extended = < GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH
+  _pmx_core OMAP4_UART3_RX>;
+};
-- 
2.6.2

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mtd: onenand: omap2: Simplify the DMA setup for various paths

[Tony Lindgren]

* Brian Norris  [151218 10:11]:
> On Mon, Dec 14, 2015 at 11:49:32AM +0200, Peter Ujfalusi wrote:
> > We have 4 functions containing almost identical DMA setup code. Create one
> > function which can set up the DMA for both read and write and use this in
> > place for the setup code in the driver.
> > The new function will use wait_for_completion_timeout() and it will figure
> > out the best data_type to be used for the transfer instead of hardwiring
> > 32 or 16 bit data.
> > 
> > Signed-off-by: Peter Ujfalusi 
> 
> Does anyone use this driver? I've seen practically zero activity on the
> entire OneNAND codebase in the last few years, and I presumed it was
> essentially dead.
> 
> If it's not dead, I'd like to know some contingency of people who are
> willing to actually maintain (or at least review) this stuff.
> 
> Kyungmin, are you still out there? Or Tony, do you know of any users for
> this?
> 
> Peter, are you actually using this, or are you just refactoring for the
> fun of it?

It's used for n8x0 and n900, but mostly in read-only mode. I suggest we
remove the DMA support for it completely because of the following:

1. The DMA support for this driver is not done correctly. The pin used
   as GPIO should be used as external DMA request line.

2. AFAIK the DMA for this driver is mostly disabld, probably largely
   due to #1 above

3. If we remove DMA support, we can then easily switch to use the
   generic onenand driver.

I'd like to hear Aaro's comments too before doing this tough.

Regards,

Tony



> >  drivers/mtd/onenand/omap2.c | 106 
> > ++--
> >  1 file changed, 42 insertions(+), 64 deletions(-)
> > 
> > diff --git a/drivers/mtd/onenand/omap2.c b/drivers/mtd/onenand/omap2.c
> > index 0aacf125938b..58576c9babb0 100644
> > --- a/drivers/mtd/onenand/omap2.c
> > +++ b/drivers/mtd/onenand/omap2.c
> > @@ -291,6 +291,30 @@ static inline int 
> > omap2_onenand_bufferram_offset(struct mtd_info *mtd, int area)
> > return 0;
> >  }
> >  
> > +static inline int omap2_onenand_dma_transfer(struct omap2_onenand *c,
> > +dma_addr_t src, dma_addr_t dst,
> > +size_t count)
> > +{
> > +   int data_type = __ffs((src | dst | count));
> > +
> > +   if (data_type > OMAP_DMA_DATA_TYPE_S32)
> > +   data_type = OMAP_DMA_DATA_TYPE_S32;
> > +
> > +   omap_set_dma_transfer_params(c->dma_channel, OMAP_DMA_DATA_TYPE_S32,
> > +count / BIT(data_type), 1, 0, 0, 0);
> > +   omap_set_dma_src_params(c->dma_channel, 0, OMAP_DMA_AMODE_POST_INC,
> > +   src, 0, 0);
> > +   omap_set_dma_dest_params(c->dma_channel, 0, OMAP_DMA_AMODE_POST_INC,
> > +dst, 0, 0);
> > +
> > +   reinit_completion(>dma_done);
> > +   omap_start_dma(c->dma_channel);
> > +   if (wait_for_completion_timeout(>dma_done, msecs_to_jiffies(20)))
> > +   return -ETIMEDOUT;
> > +
> > +   return 0;
> > +}
> > +
> >  #if defined(CONFIG_ARCH_OMAP3) || defined(MULTI_OMAP2)
> >  
> >  static int omap3_onenand_read_bufferram(struct mtd_info *mtd, int area,
> > @@ -301,10 +325,9 @@ static int omap3_onenand_read_bufferram(struct 
> > mtd_info *mtd, int area,
> > struct onenand_chip *this = mtd->priv;
> > dma_addr_t dma_src, dma_dst;
> > int bram_offset;
> > -   unsigned long timeout;
> > void *buf = (void *)buffer;
> > size_t xtra;
> > -   volatile unsigned *done;
> > +   int ret;
> >  
> > bram_offset = omap2_onenand_bufferram_offset(mtd, area) + area + offset;
> > if (bram_offset & 3 || (size_t)buf & 3 || count < 384)
> > @@ -341,25 +364,10 @@ static int omap3_onenand_read_bufferram(struct 
> > mtd_info *mtd, int area,
> > goto out_copy;
> > }
> >  
> > -   omap_set_dma_transfer_params(c->dma_channel, OMAP_DMA_DATA_TYPE_S32,
> > -count >> 2, 1, 0, 0, 0);
> > -   omap_set_dma_src_params(c->dma_channel, 0, OMAP_DMA_AMODE_POST_INC,
> > -   dma_src, 0, 0);
> > -   omap_set_dma_dest_params(c->dma_channel, 0, OMAP_DMA_AMODE_POST_INC,
> > -dma_dst, 0, 0);
> > -
> > -   reinit_completion(>dma_done);
> > -   omap_start_dma(c->dma_channel);
> > -
> > -   timeout = jiffies + msecs_to_jiffies(20);
> > -   done = >dma_done.done;
> > -   while (time_before(jiffies, timeout))
> > -   if (*done)
> > -   break;
> > -
> > +   ret = omap2_onenand_dma_transfer(c, dma_src, dma_dst, count);
> > dma_unmap_single(>pdev->dev, dma_dst, count, DMA_FROM_DEVICE);
> >  
> > -   if (!*done) {
> > +   if (ret) {
> > dev_err(>pdev->dev, "timeout waiting for DMA\n");
> > goto out_copy;
> > }
> > @@ -379,9 +387,8 @@ static int omap3_onenand_write_bufferram(struct 
> > mtd_info *mtd, int area,
> > struct onenand_chip *this = mtd->priv;
> > 

Re: [PATCH v02 0/2] ARM: DTS: am33xx/am437x: Use the new eDMA bindings

[Tony Lindgren]

* Vinod Koul <vinod.k...@intel.com> [151217 21:14]:
> On Thu, Dec 17, 2015 at 09:48:44AM -0800, Tony Lindgren wrote:
> > * Peter Ujfalusi <peter.ujfal...@ti.com> [151217 05:33]:
> > > Hi,
> > > 
> > > Changes since v1:
> > > - Updated to use the non 16bit arrays [1]
> > > - send the two patch as a series
> > > 
> > > [1]
> > > As it has been discussed earlier:
> > > https://www.mail-archive.com/linux-omap@vger.kernel.org/msg122117.html
> > > 
> > > the DT bindings has been changes compared to what we had in 4.4-rc1: the 
> > > arrays
> > > now don't have the 16bit type.
> > > The changes are now merged to mainline and Vinod provided us a branch:
> > > 
> > > git://git.infradead.org/users/vkoul/slave-dma.git fix/edma
> > > 
> > > Which is based on 4.4-rc1 and only contains the two patch for changing 
> > > the eDMA
> > > bindings.
> > 
> > Great, I'll merge the fix/edma also into omap-for-v4.5/dt and apply
> > your two patches.
> 
> FWIW, fix/edma is in Linu's tree now and should be in -rc6

Yes that's great, but now I can keep my branches at early -rc's
and that leaves out the need of late -rc backmerges to the
whole arm soc tree.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mmc: pwrseq_simple: Fix regression with optional GPIOs

[Tony Lindgren]

* Ulf Hansson <ulf.hans...@linaro.org> [151218 14:20]:
> On 18 December 2015 at 17:14, Tony Lindgren <t...@atomide.com> wrote:
> > * Ulf Hansson <ulf.hans...@linaro.org> [151207 16:20]:
> >> +Linus
> >>
> >> On 7 December 2015 at 23:54, Tony Lindgren <t...@atomide.com> wrote:
> >> > Commit ce037275861e ("mmc: pwrseq_simple: use GPIO descriptors array 
> >> > API")
> >> > changed the handling MMC power sequence so GPIOs no longer are optional.
> >> >
> >> > This broke SDIO WLAN at least for omap5 that can't yet use the reset 
> >> > GPIOs
> >> > with pwrseq_simple as a wait is needed after enabling the SDIO device.
> >>
> >> Can you elaborate on this. Did it break omap5 or not? :-)
> >
> > Ulf, is this patch queued for v4.4 as a regression fix? I don't see it
> > in Linux next or mainline trees?
> 
> Ohh, I guess there where some misunderstanding. I made a bunch of
> comments on your patch as well, so I have been expecting a new
> version.

Well this $subject patch was intended as a regression fix for v4.4-rc cycle.
All the other things discussed are not fixes but new features instead.

> Sorry if that was unclear!

I think this patch should be still fine as is, care to take a look again?

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2] ARM: OMAP2+: LogicPD Torpedo + Wireless: Add Bluetooth

[Tony Lindgren]

* Adam Ford  [151216 13:34]:
> Bindings for the WL1283 Bluetooth was removed from the shared transport
> driver in commit c0bd1b9e5895 ("Revert ti-st: add device tree support")
> Until we havea better binding, we need to use the platform data to
> initialize Bluetooth.

Yeah I don't see other better solutions until we have some real binding
for it. Applying into omap-for-v4.5/dt thanks.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/3] ARM: dts: DRA72-EVM: Add regulator-allow-bypass property for ldo1 and ldo2

[Tony Lindgren]

* Keerthy  [151213 22:38]:
> Add regulator-allow-bypass property for ldo1 and ldo2.

Are patches 2 and 3 safe to apply separately already or do
we need to wait for the regulator patch to go in first?

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v02 0/2] ARM: DTS: am33xx/am437x: Use the new eDMA bindings

[Tony Lindgren]

* Peter Ujfalusi  [151217 05:33]:
> Hi,
> 
> Changes since v1:
> - Updated to use the non 16bit arrays [1]
> - send the two patch as a series
> 
> [1]
> As it has been discussed earlier:
> https://www.mail-archive.com/linux-omap@vger.kernel.org/msg122117.html
> 
> the DT bindings has been changes compared to what we had in 4.4-rc1: the 
> arrays
> now don't have the 16bit type.
> The changes are now merged to mainline and Vinod provided us a branch:
> 
> git://git.infradead.org/users/vkoul/slave-dma.git fix/edma
> 
> Which is based on 4.4-rc1 and only contains the two patch for changing the 
> eDMA
> bindings.

Great, I'll merge the fix/edma also into omap-for-v4.5/dt and apply
your two patches.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: OMAP2+: LogicPD Torpedo: Add LCD Type 15 Support

[Tony Lindgren]

* Adam Ford  [151216 19:18]:
> Add basic support for Logic PD type 15 display for older development kits.
> This uses GPIO for the backlight.
> 
> Signed-off-by: Adam Ford 

Applying into omap-for-v4.5/dt thanks.

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 09/19] ARM: dts: am335x: replace gpio-key,wakeup with wakeup-source property

[Tony Lindgren]

* Sudeep Holla <sudeep.ho...@arm.com> [151215 08:33]:
> 
> 
> On 21/10/15 11:10, Sudeep Holla wrote:
> >Though the keyboard driver for GPIO buttons(gpio-keys) will continue to
> >check for/support the legacy "gpio-key,wakeup" boolean property to
> >enable gpio buttons as wakeup source, "wakeup-source" is the new
> >standard binding.
> >
> >This patch replaces the legacy "gpio-key,wakeup" with the unified
> >"wakeup-source" property in order to avoid any futher copy-paste
> >duplication.
> >
> >Cc: "Benoît Cousson" <bcous...@baylibre.com>
> >Cc: Tony Lindgren <t...@atomide.com>
> 
> Ping, do you prefer taking via your tree or should I send to armsoc
> directly ?

Sorry I did not realized you're waiting for me to pick this one,
applying into omap-for-v4.5/dt thanks.

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/5] ARM: dts: cm-t335: add support for SBC-T335

[Tony Lindgren]

* Rob Herring  [151213 17:26]:
> On Sun, Dec 13, 2015 at 10:55:36AM +0200, Uri Mashiach wrote:
> > Add basic support for the SBC-T335.
> > 
> > CompuLab SBC-T335 is a single baseboard computer.
> > The SBC-T335 is based on the Texas Instruments Cortex-A8 Sitara AM3354
> > SoC.
> > 
> > Signed-off-by: Uri Mashiach 
> > Acked-by: Igor Grinberg 
> 
> Acked-by: Rob Herring 

Thanks applying the whole series into omap-for-v4.5/dt.

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 15/19] ARM: dts: omap: replace legacy *,wakeup property with wakeup-source

[Tony Lindgren]

* Sudeep Holla <sudeep.ho...@arm.com> [151215 08:37]:
> 
> 
> On 21/10/15 11:10, Sudeep Holla wrote:
> >Though the keyboard and other driver will continue to support the legacy
> >"gpio-key,wakeup", "linux,wakeup" boolean property to enable the wakeup
> >source, "wakeup-source" is the new standard binding.
> >
> >This patch replaces all the legacy wakeup properties with the unified
> >"wakeup-source" property in order to avoid any futher copy-paste
> >duplication.
> >
> >Cc: "Benoît Cousson" <bcous...@baylibre.com>
> >Cc: Tony Lindgren <t...@atomide.com>
> 
> Ping, do you prefer taking via your tree or should I send to armsoc
> directly ?

Applying this one too thanks.

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/2] ARM: OMAP1/2+: DO not create omap-pcm-audio device

[Tony Lindgren]

* Peter Ujfalusi  [151211 04:51]:
> Hi,
> 
> The ASoC omap-pcm has been converted to be non platform device a long time 
> ago,
> so it is no longer needed to create the device for it since there will be no
> driver to be loaded for it.

OK, applying into omap-for-v4.5/soc-v2 thanks.

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: OMAP2+: LogicPD Torpedo + Wireless: Revert duplicative DTS entries

[Tony Lindgren]

* Adam Ford  [151216 18:39]:
> Revert commit 6f0f6c40b66 ("ARM: dts: Set VAUX1 and VAUX4 on Logic PD 
> Torpedo")
> because it It was already done and it's just a duplicate.  See:
> commit 2d11961f3e55 ("ARM: dts: Set VAUX1 and VAUX4 to 3.0V and 1.8V 
> respectively")

Care to reply with your Signed-off-by for this one?

> ---
>  arch/arm/boot/dts/logicpd-torpedo-37xx-devkit.dts | 10 --
>  1 file changed, 10 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/logicpd-torpedo-37xx-devkit.dts 
> b/arch/arm/boot/dts/logicpd-torpedo-37xx-devkit.dts
> index b017871..b07d1d9 100644
> --- a/arch/arm/boot/dts/logicpd-torpedo-37xx-devkit.dts
> +++ b/arch/arm/boot/dts/logicpd-torpedo-37xx-devkit.dts
> @@ -83,16 +83,6 @@
>   regulator-max-microvolt = <180>;
>  };
>  
> - {
> - regulator-min-microvolt = <300>;
> - regulator-max-microvolt = <300>;
> -};
> -
> - {
> - regulator-min-microvolt = <180>;
> - regulator-max-microvolt = <180>;
> -};
> -
>   {
>   status = "okay";
>  };
> -- 
> 1.9.1
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 4/5] ARM: dts: DRA7: add entry for qspi mmap region

[Tony Lindgren]

* Rob Herring  [151211 07:10]:
> On Fri, Dec 11, 2015 at 09:39:59AM +0530, Vignesh R wrote:
> > Add qspi memory mapped region entries for DRA7xx based SoCs. Also,
> > update the binding documents for the controller to document this change.
> > 
> > Signed-off-by: Vignesh R 
> 
> Acked-by: Rob Herring 

Vignes, are patches 4 and 5 safe to apply separately already or
do things break if we do that?

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2] ARM: OMAP2+: LogicPD Torpedo: Revert Duplicative Entries

[Tony Lindgren]

* Adam Ford  [151217 16:52]:
> Revert 6f0f6c40b66 ("ARM: dts: Set VAUX1 and VAUX4 on Logic PD Torpedo")
> because it It was already done and it's just a duplicate.  See:
> 2d11961f3e55 ("ARM: dts: Set VAUX1 and VAUX4 to 3.0V and 1.8V respectively")
> 
> Signed-off-by: Adam Ford 

Thanks applying into omap-for-v4.5/dt.

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv2] clk: ti: omap5+: dpll: implement errata i810

[Tony Lindgren]

* Tero Kristo <t-kri...@ti.com> [151216 01:00]:
> Errata i810 states that DPLL controller can get stuck while transitioning
> to a power saving state, while its M/N ratio is being re-programmed.
> 
> As a workaround, before re-programming the M/N ratio, SW has to ensure
> the DPLL cannot start an idle state transition. SW can disable DPLL
> idling by setting the DPLL AUTO_DPLL_MODE=0 or keeping a clock request
> active by setting a dependent clock domain in SW_WKUP.
> 
> This errata is known to impact OMAP5 and DRA7 chips, but lets enable it
> unconditionally to avoid any potential problems with earlier generation
> SoCs also.
> 
> Signed-off-by: Tero Kristo <t-kri...@ti.com>
> ---
> v2: made the fix to be applied unconditionally on all OMAP3+ SoCs

Thanks looks good to me now:

Acked-by: Tony Lindgren <t...@atomide.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3] clk: ti: Add support for dm814x ADPLL

[Tony Lindgren]

On dm814x we have 13 ADPLLs with 3 to 4 outputs on each. The
ADPLLs have several dividers and muxes controlled by a shared
control register for each PLL.

Note that for the clocks to work as device drivers for booting on
dm814x, this patch depends on "ARM: OMAP2+: Change core_initcall
levels to postcore_initcall".

Also note that this patch does not implement clk_set_rate for the
PLL, that will be posted later on when available.

Cc: Michael Turquette <mturque...@baylibre.com>
Cc: Stephen Boyd <sb...@codeaurora.org>
Cc: Tero Kristo <t-kri...@ti.com>
Signed-off-by: Tony Lindgren <t...@atomide.com>
---
Changes from v2 to v3 are listed below, hopefully I addressed everybody's
comments,please check and let me know if I missed something.

After review, it is suggested that Tero applies this patch into an
immutable branch against v4.4-rc1 that then gets submitted as a pull
request along with other omap clock patches to Mike and Stephen. That
way I can merge the clock driver too into my omap-for-v4.5/soc branch.

Changes since v2:

Addressed comments from RMK:

- Use clkdev_create() and set up separate con id from name in format
  "pll260dcoclkldo" to avoid the MAX_CON_ID limitations

Addressed comments from Tero:

- Change register access to use offsets from d->regs instead of setting
  up separate void __iomem * registers

- Change ti_adpll_clkout_set_parent() to return -EAGAIN if unavailable
  parent is selected

Addressed comments from Matthijs:

- Standardize on "dcoclkldo" output name and use that name also for TRM
  "clkdcoldo"

- Use "bypass" name instead of "ulow" used in TRM 

- Use 16-bit register access in ti_adpll_recalc_rate() to simplify
  the code

- Use ti_adpll_set_idle_bypass() naming to make it clear it's the idle
  mode

- Check PLL lock for both ti_adpll_is_prepared() and ti_adpll_wait_lock()

---
 .../devicetree/bindings/clock/ti/adpll.txt |   43 +
 drivers/clk/Kconfig|1 +
 drivers/clk/ti/Kconfig |6 +
 drivers/clk/ti/Makefile|2 +
 drivers/clk/ti/adpll.c | 1003 
 drivers/clk/ti/clk-814x.c  |   53 ++
 6 files changed, 1108 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/ti/adpll.txt
 create mode 100644 drivers/clk/ti/Kconfig
 create mode 100644 drivers/clk/ti/adpll.c

diff --git a/Documentation/devicetree/bindings/clock/ti/adpll.txt 
b/Documentation/devicetree/bindings/clock/ti/adpll.txt
new file mode 100644
index 000..3c41aea
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/ti/adpll.txt
@@ -0,0 +1,43 @@
+Binding for Texas Instruments ADPLL clock.
+
+Binding status: Unstable - ABI compatibility may be broken in the future
+
+This binding uses the common clock binding[1]. It assumes a
+register-mapped ADPLL with two to three selectable input clocks
+and three to four children..
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+- compatible : shall be one of "ti,dm814-adpll-s-clock" or
+  "ti,dm814-adpll-lj-clock" depending on the type of the ADPLL
+- #clock-cells : from common clock binding; shall be set to 0.
+- clocks : link phandles of parent clocks clkinp and clkinpulow, note
+  that the adpll-s-clock also has an optional clkinphif
+- reg : address and length of the register set for controlling the ADPLL.
+
+Examples:
+   adpll_mpu_ck: adpll@40 {
+   #clock-cells = <1>;
+   compatible = "ti,dm814-adpll-s-clock";
+   reg = <0x40 0x40>;
+   clocks = <_ck _ck _ck>;
+   clock-names = "clkinp", "clkinpulow", "clkinphif";
+   clock-indices = <0>, <1>, <2>, <3>;
+   clock-output-names = "481c5040.adpll.dcoclkldo",
+"481c5040.adpll.clkout",
+"481c5040.adpll.clkoutx2",
+"481c5040.adpll.clkouthif";
+   };
+
+   adpll_dsp_ck: adpll@80 {
+   #clock-cells = <1>;
+   compatible = "ti,dm814-adpll-lj-clock";
+   reg = <0x80 0x30>;
+   clocks = <_ck _ck>;
+   clock-names = "clkinp", "clkinpulow";
+   clock-indices = <0>, <1>, <2>;
+   clock-output-names = "481c5080.adpll.dcoclkldo",
+"481c5080.adpll.clkout",
+"481c5080.adpll.clkoutldo";
+   };
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index c3e3a02f..c0c9868 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/c

Re: [PATCH v3] irqchip: omap-intc: add support for spurious irq handling

[Tony Lindgren]

* Sekhar Nori <nsek...@ti.com> [151215 06:26]:
> Under some conditions, irq sorting procedure used
> by INTC can go wrong resulting in a spurious irq
> getting reported.
> 
> If this condition is not handled, it results in
> endless stream of:
> 
> unexpected IRQ trap at vector 00
> 
> messages from ack_bad_irq()
> 
> Handle the spurious interrupt condition in omap-intc
> driver to prevent this.
> 
> Measurements using kernel function profiler on AM335x
> EVM running at 720MHz show that after this patch
> omap_intc_handle_irq() takes about 37.4us against
> 34us before this patch.
> 
> Signed-off-by: Sekhar Nori <nsek...@ti.com>

Looks good to me, probably should get tagged Cc stable when
committing:

Acked-by: Tony Lindgren <t...@atomide.com>


> ---
> v3: add unlikely(), add profiling information
> to commit message.
> 
> v2: increment error irq counter, use pr_err_once,
> add a comment on tips to debug spurious irq
> condition.
> 
> This patch results in a checkpatch warning about
> extern definition of irq_err_count, but looks like
> thats the prevalent method of accessing that counter.
> 
>  drivers/irqchip/irq-omap-intc.c | 27 ++-
>  1 file changed, 26 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/irqchip/irq-omap-intc.c b/drivers/irqchip/irq-omap-intc.c
> index 8587d0f8d8c0..f6cb1b8bb981 100644
> --- a/drivers/irqchip/irq-omap-intc.c
> +++ b/drivers/irqchip/irq-omap-intc.c
> @@ -47,6 +47,7 @@
>  #define INTC_ILR00x0100
>  
>  #define ACTIVEIRQ_MASK   0x7f/* omap2/3 active interrupt 
> bits */
> +#define SPURIOUSIRQ_MASK (0x1ff << 7)
>  #define INTCPS_NR_ILR_REGS   128
>  #define INTCPS_NR_MIR_REGS   4
>  
> @@ -330,11 +331,35 @@ static int __init omap_init_irq(u32 base, struct 
> device_node *node)
>  static asmlinkage void __exception_irq_entry
>  omap_intc_handle_irq(struct pt_regs *regs)
>  {
> + extern unsigned long irq_err_count;
>   u32 irqnr;
>  
>   irqnr = intc_readl(INTC_SIR);
> +
> + /*
> +  * A spurious IRQ can result if interrupt that triggered the
> +  * sorting is no longer active during the sorting (10 INTC
> +  * functional clock cycles after interrupt assertion). Or a
> +  * change in interrupt mask affected the result during sorting
> +  * time. There is no special handling required except ignoring
> +  * the SIR register value just read and retrying.
> +  * See section 6.2.5 of AM335x TRM Literature Number: SPRUH73K
> +  *
> +  * Many a times, a spurious interrupt situation has been fixed
> +  * by adding a flush for the posted write acking the IRQ in
> +  * the device driver. Typically, this is going be the device
> +  * driver whose interrupt was handled just before the spurious
> +  * IRQ occurred. Pay attention to those device drivers if you
> +  * run into hitting the spurious IRQ condition below.
> +  */
> + if (unlikely((irqnr & SPURIOUSIRQ_MASK) == SPURIOUSIRQ_MASK)) {
> + pr_err_once("%s: spurious irq!\n", __func__);
> + irq_err_count++;
> + omap_ack_irq(NULL);
> + return;
> + }
> +
>   irqnr &= ACTIVEIRQ_MASK;
> - WARN_ONCE(!irqnr, "Spurious IRQ ?\n");
>   handle_domain_irq(domain, irqnr, regs);
>  }
>  
> -- 
> 2.6.3
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 0/9] phy: use syscon framework APIs to set ctrl mod reg

[Tony Lindgren]

* Kishon Vijay Abraham I  [151215 04:47]:
> On Tuesday 15 December 2015 05:25 PM, Arnd Bergmann wrote:
> >>>
> >>> Can you explain here what the conversion is good for? Why do you
> >>> prefer the syscon mapping over a high-level driver in this case?
> >>
> >> phy-omap-control driver was added when there was no proper
> >> infrastructure for doing control module initializations. The
> >> phy-omap-control driver is not an 'actual' PHY driver and it
> >> was just a hack to do PHY related control module initializations.
> >> phy-omap-control is also getting unmanageable with the number of
> >> platforms each having number of modules (like USB, SATA, PCIe),
> >> using the same driver for control module initializations.
> >>
> >> Now with SYSCON framework being added to the kernel, phy-omap-control
> >> shouldn't be needed and it also provides a uniform API across all the
> >> modules to program the control module.
> > 
> > Ok, so the "phy-control" devices were really just a few registers of
> > a system controller device that does a lot of other things as well, right?
> 
> right.
> > 
> > Can you put your description above into the cover-letter for the series,
> > and the merge commit?

Just to confirm.. Seems like this series keeps USB working and the dts
changes can be done later after the driver changes have been merged?

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: OMAP2+: LogicPD Torpedo + Wireless: add Bluetooth support Add WL1283 support through pdata-quirks since the driver lacks DT support

[Tony Lindgren]

* Adam Ford  [151212 19:08]:

Please add a description here like "The binding for wl12xx bluetooth
got removed by commit xyz and until we have a better binding we need
to use the platform data to initialize bluetooth".

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] clk: ti: Add support for dm814x ADPLL

[Tony Lindgren]

* Matthijs van Duin <matthijsvand...@gmail.com> [151214 01:16]:
> On Thu, Dec 10, 2015 at 06:26:32PM -0800, Tony Lindgren wrote:
> > +- compatible : shall be one of "ti,dm814-adpll-s-clock" or
> > +  "ti,dm814-adpll-j-clock" depending on the type of the ADPLL
> 
> There's still a j -> lj you missed.

Oops thanks will fix.

> Also, since the device series almost always referred to as dm814x, any 
> reason the x is omitted here?  Based on a quick google, dm814 mostly seems 
> to be a moose hunting area in alaska ;-)

Well we don't want any any wild cards in the dts compatible names.
Typically the first piece of hardware is selected, but that causes
confusion too. So we're using comaptible names like dra7 and dm814.

> > +- clocks : link phandles of parent clocks (clk-ref and clk-bypass)
> 
> The documentation and your later example calls these clkinp and clkinpulow. 
> In theory adpll-s has a third input (clkinphif).
> 
> Calling the input clock "clk-ref" is potentially misleading since the 
> documentation uses the name "refclk" for clkinp/(N+1). Also, while I'll 
> admit "clkinpulow" is an awful name, "clk-bypass" is also misleading since 
> it is merely an optional alternative bypass clock, the default being 
> clkinp/(N2+1).
> 
> Are you aware of any dm814x-sibling that actually uses clkinpulow, or are 
> you just including it for completeness or consistency with DPLL instances 
> in other devices like the omap4 or am335x?

I don't know of any instances using it.. I'll take a look but seems like we
could just leave it out.

> > +   clock-output-names = "481c5040.adpll.dcoclkldo",
> > ...
> > +   clock-output-names = "481c5080.adpll.clkdcoldo",
> 
> I know this inconsistency comes straight out of the TRM, but may I vote for 
> picking one of them and sticking to it? :-)

I vote for dcoclkldo then :) The "cold" name embedded in the other one just
causes me confusion reading it every time..

> > +#define ADPLL_CLKINPHIFSEL_ADPLL_S 19  /* REVISIT: which bit? */
> 
> Impossible to say unless a dm814x sibling shows up that actually uses it; 
> pll_mpu lacks the HIF clocks entirely.  Note that it's quite possible bit 19 
> is indeed officially assigned to it, CLKINPHIFSEL and CLKOUTLDOEN do not 
> conflict since they apply to different PLL types.

Yup.

> > +static void ti_adpll_set_bypass(struct ti_adpll_data *d)
> > +static void ti_adpll_clear_bypass(struct ti_adpll_data *d)
> 
> These functions relate to a specific "Idle Bypass" mode of the PLL,
> which gates the refclk and sort of freezes the PLL state.  Various other
> control/status bits become unresponsive in this mode as a result.
> 
> I would suggest reflecting this in the name, or at least a comment,
> since "bypass" refers to a much more general state.  Clearing the IDLE
> bit is necessary to take the PLL out of bypass, but other conditions
> need to be satisfied as well.  Hence, "clear_bypass" does not not
> literally do what its name would seem to suggest.
> 
> > +static int ti_adpll_wait_lock(struct ti_adpll_data *d)
> > ...
> > +   while (ti_adpll_clock_is_bypass(d)) {

Yeah I have to take a closer look at this whole bypass thing..

> Locked and bypass are not actually mutually exclusive:  if you only care
> about the DCO clock and not CLKOUT you can clear M2PWDNZ before enabling
> the PLL, resulting in status (FREQLOCK | PHASELOCK | BYPASS) after lock.
> 
> I don't know if there's any reason to take this obscure configuration
> into consideration, but I just wanted to make you aware of it.

OK good to know thanks.

> > +static int ti_adpll_is_prepared(struct clk_hw *hw)
> > ...
> > +   return (v & ADPLL_STATUS_PREPARED_MASK) == ADPLL_STATUS_PREPARED_MASK;
> 
> Yet here you do actually test whether the PLL is locked... why the use a
> different condition here than in ti_adpll_wait_lock?
> 
> 
> > +static unsigned long ti_adpll_recalc_rate(struct clk_hw *hw,
> > ...
> > +   if (ti_adpll_clock_is_bypass(d))
> > +   return clk_get_rate(d->clocks[TI_ADPLL_N2].clk);
> 
> Bypass refers to clkout. This function calculates the DCO clock, which
> is never subject to bypass: if the PLL is off, dcoclk is low.

Thanks will check.

> 
> Although I understand the reasoning behind using abstractions like
> readl_relaxed() for I/O access to allow portability to platforms where
> I/O is not simply memory-mapped, this concern does not exist for
> platform-specific devices like this.  There's really no reason in my
> humble opinion this code could not simply do
> 
>   /* read predivider and multiplier, 

Re: [PATCH] clk: ti: omap5+: dpll: implement errata i810

[Tony Lindgren]

* Tero Kristo <t-kri...@ti.com> [151211 00:42]:
> On 12/03/2015 06:48 PM, Tony Lindgren wrote:
> >* Tero Kristo <t-kri...@ti.com> [151130 06:44]:
> >>+   /*
> >>+* Errata i810 - DPLL controller can get stuck while transitioning
> >>+* to a power saving state. Software must ensure the DPLL can not
> >>+* transition to a low power state while changing M/N values.
> >>+* Easiest way to accomplish this is to prevent DPLL autoidle
> >>+* before doing the M/N re-program.
> >>+*/
> >>+   errata_i810 = ti_clk_get_features()->flags & TI_CLK_ERRATA_I810;
> >>+
> >>+   if (errata_i810) {
> >>+   ai = omap3_dpll_autoidle_read(clk);
> >>+   if (ai) {
> >>+   omap3_dpll_deny_idle(clk);
> >>+
> >>+   /* OCP barrier */
> >>+   omap3_dpll_autoidle_read(clk);
> >>+   }
> >>+   }
> >
> >Should we just do this unconditionally? It seems like disabling the
> >autoidle always before reprogramming is a good idea.
> 
> Well, that is a few extra register accesses, but given the DPLL
> re-programming is a slow operation it probably does not matter. Let me spin
> a new version of this patch, it will avoid the need for the errata flag
> also.

OK thanks,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] clk: ti: Add support for dm814x ADPLL

[Tony Lindgren]

* Tero Kristo <t-kri...@ti.com> [151210 23:45]:
> On 12/11/2015 04:26 AM, Tony Lindgren wrote:
> 
> Looks mostly good to me, added some minor comments inline below. Sorry again
> for latencies in my replies.

No problme, thanks for looking.

> >+static bool ti_adpll_clock_is_bypass(struct ti_adpll_data *d)
> >+{
> >+unsigned long flags;
> >+u32 v;
> >+
> >+spin_lock_irqsave(>lock, flags);
> >+v = readl_relaxed(d->status);
> >+spin_unlock_irqrestore(>lock, flags);
> 
> What do you need the lock for in here?

Yeah seems pointless, will remove.

> >+static int ti_adpll_clkout_set_parent(struct clk_hw *hw, u8 index)
> >+{
> >+struct ti_adpll_clkout_data *co = to_clkout(hw);
> >+struct ti_adpll_data *d = co->adpll;
> >+
> >+return ti_adpll_clock_is_bypass(d) == index;

Hmm yeah that seems broken. I need to check what all really goes
to bypass mode with ulowclken signal.

> What is the point of this? It doesn't seem to set anything.

> >+/* Internal mux, sources sources from DCO and clkinphf */
> 
> Double "sources" in comment?
> 
> >+/* Output clkout clkout, sources M2 or ulow */
> 
> Double "clkout" in comment?

Oops will fix.

> >+d->pwrctrl = d->base + register_offset + ADPLL_PWRCTRL_OFFSET;
> >+d->clkctrl = d->base + register_offset + ADPLL_CLKCTRL_OFFSET;
> >+d->tenable = d->base + register_offset + ADPLL_TENABLE_OFFSET;
> >+d->tenablediv = d->base + register_offset + ADPLL_TENABLEDIV_OFFSET;
> >+d->m2ndiv = d->base + register_offset + ADPLL_M2NDIV_OFFSET;
> >+d->mn2div = d->base + register_offset + ADPLL_MN2DIV_OFFSET;
> >+d->fracdiv = d->base + register_offset + ADPLL_FRACDIV_OFFSET;
> >+d->bwctrl = d->base + register_offset + ADPLL_BWCTRL_OFFSET;
> >+d->status = d->base + register_offset + ADPLL_STATUS_OFFSET;
> >+d->m3div = d->base + register_offset + ADPLL_M3DIV_OFFSET;
> >+d->rampctrl = d->base + register_offset + ADPLL_RAMPCTRL_OFFSET;
> 
> Do you need the individual pointers to each of these registers within the
> struct? Seems the offsets are pretty static so could just use d->base +
> offset + MAGIC calculation where used.
> 
> Most of these registers are not used for anything either at the moment it
> seems.

Well I guess I was initially thinking that we can set up separate instances
for the children and don't need locking for the registers.. But all of them
really share the clkctl register so that did not work out.

Yeah I can change these to use offsets no problem.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] clk: ti: Add support for dm814x ADPLL

[Tony Lindgren]

* Russell King - ARM Linux <li...@arm.linux.org.uk> [151211 08:16]:
> On Fri, Dec 11, 2015 at 07:48:54AM -0800, Tony Lindgren wrote:
> > There's a problem with MAX_CON_ID 16 hardcoded allocated name length.
> 
> Absolutely right...

Well adding the warning there allows people to at least see what's going
on.

> > In this case I have 13 instances of plls with 3 - 4 outputs each and I'd
> > like to use "481c5040.adpll.clkout" style naming starting with the instance
> > address. Also "adpll5.clkdcoldo" style naming would work,
> 
> Because it's a connection ID, not a clock _name_.  I see that we're still
> making all the same mistakes with clocks that were made years ago, and
> which lead down the path of amazingly complex drivers having conditional
> clock names and the like.

Yeah we certainly want to get out of the conditional name business.

> Is there a reason why you can't split this into separate device and input
> names, and use clk_get_sys() rather than passing NULL as the device to
> clk_get().  This is exactly why we've ended up with clk_get_sys(), to
> cater for the cases where there is no struct device to associate with the
> connection ID: the idea behind clk_get_sys() is that you pass the device
> name explicitly, along with the connection ID.

For most code yes, there's still a pile of shared legacy code relying on
the clock connection ID only.

So what do you envision people using for the connection ID in cases like
this? It needs to be unique, should relate to the documentation and fit
MAX_CON_ID. Something like "pll5.clkdcoldo" will still overflow for pll13
unless also the dot is left out :)

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] clk: ti: Add support for dm814x ADPLL

[Tony Lindgren]

* Russell King - ARM Linux <li...@arm.linux.org.uk> [151211 05:53]:
> On Thu, Dec 10, 2015 at 06:26:32PM -0800, Tony Lindgren wrote:
> > +   /* Released with kfree() by clkdev_drop() */
> > +   cl = kzalloc(sizeof(*cl), GFP_KERNEL);
> > +   if (!cl)
> > +   return -ENOMEM;
> > +
> > +   /* Use clkdev_add, clk_register_clkdev limits length to MAX_CON_ID */
> > +   cl->con_id = name;
> > +   cl->clk = clock;
> > +   cl->clk_hw = __clk_get_hw(clock);
> > +   clkdev_add(cl);
> > +   d->clocks[index].cl = cl;
> 
> NAK.  I've no idea why you're open-coding the clkdev internals (which
> seems to have been a historical habbit in OMAP code.)  Please stop
> doing this.
>
> You are provided with clkdev_alloc() which will allocate the structure
> and initialise it for you, and clkdev_add() which will add the allocated
> and initialised struct to the list of lookups.  Everything you're doing
> above can be done with clkdev_alloc() + clkdev_add() which have been
> there for a _very_ long time.  They're even documented (thanks for
> providing me with more proof that documentation is nothing but a waste
> of time. :))

I tried, but I was seeing mysterious silent failures for some clocks.

> Even better is clkdev_create() which eliminates the two step clkdev_alloc()
> and clkdev_add() process.
> 
> So, the whole of the above can be reduced down to:
> 
>   cl = clkdev_create(clock, name, NULL);
>   if (!cl)
>   return -ENOMEM;
> 

There's a problem with MAX_CON_ID 16 hardcoded allocated name length.

In this case I have 13 instances of plls with 3 - 4 outputs each and I'd
like to use "481c5040.adpll.clkout" style naming starting with the instance
address. Also "adpll5.clkdcoldo" style naming would work,

Below is a patch we should probably apply as a band aid to produce a proper
warning.

Naturally we don't want to allocate longer names for all the clocks.. And
we already do have some const names coming from device tree we could use.

What if we optionally allow passing a name to clkdev and add some flag
that tells clkdev code not to attempt to free it? Or do you have better
ideas in mind to fix the issue?

Regards,

Tony

8< 
From: Tony Lindgren <t...@atomide.com>
Date: Fri, 11 Dec 2015 07:28:36 -0800
Subject: [PATCH] clkdev: Make silent failures of clk_get() produce a proper
 warning

Otherwise we can see mysterious failures with some clocks where
the name is longer than MAX_CON_ID 16. This can easily happen with
clock names coming from device tree for example in the form of
"481c5040.adpll.clkout" or "adpll1.clkdcoldo".

Let's make things a bit easier to debug by adding a warning for
the clock name. Note that we don't want to error out here as the
string matching still probably does the right thing for most
clocks.

Also note that we should also remove the hardcoded name allocation
in clkdev by adding functions that allow passing a name to clkdev
optionally.

Signed-off-by: Tony Lindgren <t...@atomide.com>

--- a/drivers/clk/clkdev.c
+++ b/drivers/clk/clkdev.c
@@ -256,6 +256,10 @@ vclkdev_alloc(struct clk_hw *hw, const char *con_id, const 
char *dev_fmt,
 {
struct clk_lookup_alloc *cla;
 
+   if (strlen(con_id) > MAX_CON_ID)
+   pr_warn("%s length of %s > %i, clock lookup can fail\n",
+   __func__, con_id, MAX_CON_ID);
+
cla = __clkdev_alloc(sizeof(*cla));
if (!cla)
return NULL;
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 4/5] ARM: dts: DRA7: add entry for qspi mmap region

[Tony Lindgren]

* Vignesh R <vigne...@ti.com> [151209 21:05]:
> 
> 
> On 12/03/2015 03:51 PM, Vignesh R wrote:
> > 
> > 
> > On 12/01/2015 10:09 PM, Tony Lindgren wrote:
> >> * Vignesh R <vigne...@ti.com> [151130 20:46]:
> >>> On 12/01/2015 04:04 AM, Tony Lindgren wrote:
> >>>>
> ...
> >>
> >> OK. They are both on L3 main so that won't cause any issues for separate
> >> interconnect driver instances. As they are still separate targets flushing
> >> a posted write to one area will not flush anything to the other.
> >>
> > 
> > I didn't quite understand what you meant by interconnect driver instance.
> > qspi_base and qspi_mmap region are tightly bound to each other and both
> > needs to be accessed by ti-qspi driver (though different targets).
> > Besides qspi_mmap region is only used to read data, there will not be
> > any write accesses to this target. Are you saying this binding is not
> > viable?
> > 
> 
> As I stated above qspi_base and qspi_mmap region are tightly bound,
> there is no way to use qspi_mmap region w/o accessing qspi_base. So I am
> planning to keep them as it is. I will move qspi_ctrlmod to use syscon.
> Something like:
> 
> qspi: qspi@4b30 {
>compatible = "ti,dra7xxx-qspi";
>reg = <0x4b30 0x100>,
>  <0x5c00 0x400>,
>reg-names = "qspi_base", "qspi_mmap";
>syscon-chipselects = <_conf 0x558>;
>#address-cells = <1>;
>#size-cells = <0>;
>spi-max-frequency = <4800>;
>ti,hwmods = "qspi";
> };
> 
> Do you think this is not viable in future?

That's OK, they are on the same interconnect instance. And with the
syscon you're not directly tinkering with the SCM registers. So
yeah, that should work in the long run too.

The absolute addresses will get changed to just offsets from the
interconnect target. But if you use the Linux standard functions like
platform_get_resource_byname + devm_request_mem_region + devm_ioremap
then no changes are needed to your driver later on.

Thanks,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] pinctrl:Convert the composition of devm_request_mem_region and devm_ioremap to a single call

[Tony Lindgren]

* Linus Walleij <linus.wall...@linaro.org> [151210 10:18]:
> On Thu, Dec 3, 2015 at 10:44 PM, Tony Lindgren <t...@atomide.com> wrote:
> > * Linus Walleij <linus.wall...@linaro.org> [151030 12:54]:
> >> Please run posts like this by the maintainers. Tony Lindgren is one
> >> user, Haojian is another.
> >
> > I think we need to add ourselves to MAINTAINERS for this driver,
> > otherwise we'll keep on missing emails.
> 
> Good idea! Patches accepted.

How about this one below?

Regards,

Tony

8< ---
From: Tony Lindgren <t...@atomide.com>
Date: Thu, 10 Dec 2015 14:27:32 -0800
Subject: [PATCH] MAINTAINERS: pinctrl: Add maintainers for pinctrl-single

Otherwise we keep missing patches related to this driver.

Cc: Haojian Zhuang <haojian.zhu...@linaro.org>
Signed-off-by: Tony Lindgren <t...@atomide.com>

--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8379,6 +8379,14 @@ L:   linux-samsung-...@vger.kernel.org (moderated 
for non-subscribers)
 S: Maintained
 F: drivers/pinctrl/samsung/
 
+PIN CONTROLLER - SINGLE
+M: Tony Lindgren <t...@atomide.com>
+M: Haojian Zhuang <haojian.zhu...@linaro.org>
+L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
+L: linux-omap@vger.kernel.org
+S: Maintained
+F: drivers/pinctrl/pinctrl-single.c
+
 PIN CONTROLLER - ST SPEAR
 M: Viresh Kumar <vire...@kernel.org>
 L: spear-de...@list.st.com
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[GIT PULL] omap fixes against v4.4-rc4

[Tony Lindgren]

The following changes since commit 31ade3b83e1821da5fbb2f11b5b3d4ab2ec39db8:

  Linux 4.4-rc3 (2015-11-29 18:58:26 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap 
tags/omap-for-v4.4/fixes-rc4

for you to fetch changes up to 14054fb1da099fd89208b8b319a00e0b902c7645:

  ARM: dts: am4372: fix clock source for arm twd and global timers (2015-12-09 
16:46:25 -0800)


Few fixes for omaps for v4.4-rc cycle:

- Fix clock source for ARM TWD and global timers on am437x

- Always select REGULATOR_FIXED_VOLTAGE for omap2+ instead of
  when MACH_OMAP3_PANDORA is selected

- Fix SPI DMA handles for dm816x as only some were mapped

- Fix up mbox cells for dm816x to make mailbox usable


Grygorii Strashko (2):
  ARM: OMAP2+: enable REGULATOR_FIXED_VOLTAGE
  ARM: dts: am4372: fix clock source for arm twd and global timers

Neil Armstrong (2):
  ARM: dts: add dm816x missing #mbox-cells
  ARM: dts: add dm816x missing spi DT dma handles

 arch/arm/boot/dts/am4372.dtsi| 4 ++--
 arch/arm/boot/dts/am43xx-clocks.dtsi | 8 
 arch/arm/boot/dts/dm816x.dtsi| 8 ++--
 arch/arm/mach-omap2/Kconfig  | 2 +-
 4 files changed, 17 insertions(+), 5 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] omap fixes against v4.4-rc4

[Tony Lindgren]

* Arnd Bergmann <a...@arndb.de> [151210 15:46]:
> On Thursday 10 December 2015 15:39:08 Tony Lindgren wrote:
> > Few fixes for omaps for v4.4-rc cycle:
> > 
> > - Fix clock source for ARM TWD and global timers on am437x
> > 
> > - Always select REGULATOR_FIXED_VOLTAGE for omap2+ instead of
> >   when MACH_OMAP3_PANDORA is selected
> > 
> > - Fix SPI DMA handles for dm816x as only some were mapped
> > 
> > - Fix up mbox cells for dm816x to make mailbox usable
> > 
> 
> Just when I had finished pulling in all other fixes and was about
> to go to bed.

Oops sorry I should have sent this earlier today!

> Pulled into fixes, too.

Thanks & good night,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[GIT PULL 1/2] omap fixes for 81xx for v4.5 merge window

[Tony Lindgren]

The following changes since commit 29f5b34ca1a191c2cf4f6c8c12f4dec56e8d3bc1:

  arm: omap2+: add missing HWMOD_NO_IDLEST in 81xx hwmod data (2015-11-25 
10:54:22 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap 
tags/omap-for-v4.5/81xx-fixes-signed

for you to fetch changes up to d893656e61040f3ff7b5f72a986052a348f3c94e:

  ARM: OMAP2+: Remove useless check for legacy booting for dm814x (2015-12-09 
16:53:46 -0800)


Fixes for ti81xx for v4.5 merge window. We have hp t410 already booting
in mainline kernel with it's bootloader configured clocks.  However,
trying to boot dm814x-evm uncovered all kind of issues with the timer
clock. To keep t410 booting, these issues need to be fixed in a specific
order and this branch contains both device tree and code changes.

To summarize the changes, we had missing ranges for clocks to probe,
missing aliase for clocks, wrong registers for divder clocks, and bad
address for the control module. All these went unnoticed earlier as
things worked without errors by luck and I did not pay much attention
to them until I got hold of a dm814x-evm and I noticed it did not boot.

As these are fixes for features that never worked, these can wait for
v4.5 merge window no problem.


Tony Lindgren (9):
  ARM: dts: Fix dm814x entries for pllss and prcm
  clk: ti: Add few dm814x clock aliases
  ARM: OMAP2+: Add DPPLS clock manager for dm814x
  ARM: dts: Fix some mux and divider clocks to get dm814x-evm booting
  ARM: OMAP2+: Fix timer entries for dm814x
  ARM: dts: Fix dm8148 control modules ranges
  ARM: dts: Fix dm814x pinctrl address and mask
  ARM: OMAP2+: Enable GPIO for dm814x
  ARM: OMAP2+: Remove useless check for legacy booting for dm814x

 arch/arm/boot/dts/dm814x-clocks.dtsi   | 109 +
 arch/arm/boot/dts/dm814x.dtsi  |  33 ++---
 arch/arm/mach-omap2/io.c   |   3 +-
 arch/arm/mach-omap2/omap_hwmod_81xx_data.c |  12 ++--
 arch/arm/mach-omap2/prm_common.c   |   6 ++
 drivers/clk/ti/clk-814x.c  |   4 ++
 include/linux/clk/ti.h |   1 +
 7 files changed, 122 insertions(+), 46 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[GIT PULL 2/2] omap device tree changes for v4.5, part 1

[Tony Lindgren]

The following changes since commit 1ec218373b8ebda821aec00bb156a9c94fad9cd4:

  Linux 4.4-rc2 (2015-11-22 16:45:59 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap 
tags/omap-for-v4.5/dt-pt1

for you to fetch changes up to 89c6f2e5ab7a0499c6bcb25d281977ada205765d:

  ARM: dts: omap3-igep0030: Use MMC pwrseq to init SDIO WiFi (2015-12-07 
16:11:43 -0800)


Device tree changes for omaps for v4.5 merge window:

- Update all omaps to use pinctrl macros. This makes comparing the pinmux
  settings against the documentation much earlier. Javier compared the
  checksums of the generated dtb files to make sure nothing changed for
  the dtb files.

- Updates for dm816x

- Add GPMC DMA channels for am437x

- Updates for LogicPD Torpedo

- Basic support for CompuLab cm-t335

- Remove tps65217.dtsi file, we're better off adding SoC generic board
  dtsi files for the common features

- Add support for ELM on am33xx

- Add support for Bosch shc c3 board

- Add qspi aliases for am437x and dra7

- Wake-up support for dra7-evm uart1

- Basic support for CompuLab sbc-t43

- Basic support for CompuLab cl-som-am57x

- Use MMC pwrseq for libertas WLAN on igep0020 and igep0030


Adam Ford (6):
  ARM: dts: Add audio support for LogicPD Torpedo DM3730 devkit
  ARM: dts: Change I2C2 and I2C3 to 400KHz for LogicPD Torpedo DM3730 devkit
  ARM: dts: Set VAUX1 and VAUX4 to 3.0V and 1.8V respectively
  ARM: dts: Enable UART2 pinctrl on LogicPD Torpedo + Wireless module
  ARM: dts: Change I2C2 and I2C3 to 400KHz for LogicPD Torpedo DM3730 devkit
  ARM: dts: Set VAUX1 and VAUX4 on Logic PD Torpedo

Andrew F. Davis (1):
  ARM: dts: am335x-boneblack: Use pinctrl constants and AM33XX_IOPAD macro

Dmitry Lifshitz (19):
  ARM: dts: am57xx: cl-som-am57x: add basic module support
  ARM: dts: am57xx: cl-som-am57x: dts: add RTC support
  ARM: dts: am57xx: cl-som-am57x: add I2C3 support
  ARM: dts: am57xx: cl-som-am57x: add EEPROM support
  ARM: dts: am57xx: cl-som-am57x: add eMMC support
  ARM: dts: am57xx: cl-som-am57x: add spi-flash support
  ARM: dts: am57xx: cl-som-am57x: add dual EMAC support
  ARM: dts: am57xx: cl-som-am57x: add USB support
  ARM: dts: am57xx: cl-som-am57x: add touchscreen support
  ARM: dts: am57xx: cl-som-am57x: add analog audio support
  ARM: dts: am57xx: sbc-am57x: add basic board support
  ARM: dts: am57xx: cl-som-am57x: add MMC1 support
  ARM: dts: am57xx: sbc-am57x: add usb vbus pinmux
  ARM: dts: am57xx: sbc-am57x: add EEPROM support
  ARM: dts: am57xx: sbc-am57x: add GPIO expander support
  ARM: dts: am57xx: sbc-am57x: add LCD support
  ARM: dts: am57xx: compulab-sb-som: add HDMI connector
  ARM: dts: am57xx: sbc-am57x: add HDMI support
  ARM: dts: am57xx: cl-som-am57x: skip resetting ETH PHYs

Franklin S Cooper Jr (2):
  ARM: dts: am437x/am33xx/omap/dm816x: Add gpmc dma channel
  ARM: dts: omap4: Add elm node

Heiko Schocher (2):
  regulator: tps65217: remove tps65217.dtsi file
  arm, am335x: add support for the bosch shc board

Ilya Ledvich (6):
  ARM: dts: cm-t335: add initial support
  ARM: dts: cm-t335: add basic support for I2C
  ARM: dts: cm-t335: add support for NAND flash
  ARM: dts: cm-t335: add support for MMC
  ARM: dts: cm-t335: add support for network device
  ARM: dts: cm-t335: add support for PWM backlight

Javier Martinez Canillas (41):
  pinctrl: Move am4372 and dra7 macros to the the SoC header files
  ARM: dts: am335x-baltos-ir5221: Remove leftover pinctrl lines
  ARM: dts: am335x-baltos-ir5221: Use AM33XX_IOPAD pinmux macro
  ARM: dts: am335x-bone-common: Use AM33XX_IOPAD pinmux macro
  ARM: dts: am335x-bonegreen: Use AM33XX_IOPAD pinmux macro
  ARM: dts: am335x-chiliboard: Use AM33XX_IOPAD pinmux macro
  ARM: dts: am335x-chilisom: Use AM33XX_IOPAD pinmux macro
  ARM: dts: am335x-evm: Use AM33XX_IOPAD pinmux macro
  ARM: dts: am335x-evmsk: Use AM33XX_IOPAD pinmux macro
  ARM: dts: am335x-lxm: Use AM33XX_IOPAD pinmux macro
  ARM: dts: am335x-nano: Use AM33XX_IOPAD pinmux macro
  ARM: dts: am335x-pepper: Use AM33XX_IOPAD pinmux macro
  ARM: dts: am335x-phycore-som: Use AM33XX_IOPAD pinmux macro
  ARM: dts: am335x-wega: Use AM33XX_IOPAD pinmux macro
  ARM: dts: am3517-craneboard: Use OMAP3_CORE1_IOPAD pinmux macro
  ARM: dts: am437x-gp-evm: Use AM4372_IOPAD pinmux macro
  ARM: dts: am437x-idk-evm: Use AM4372_IOPAD pinmux macro
  ARM: dts: am437x-sk-evm: Use AM4372_IOPAD pinmux macro
  ARM: dts: am43x-epos-evm: Use AM4372_IOPAD pinmux macro
  ARM: dts: am57xx-beagle-x15: Use DRA7XX_CORE_IOPAD pinmux macro
  ARM: dts: dra7-evm: Use DRA7XX_CORE_IOPAD pinmux macro
  ARM: dts: 

[PATCH v2] clk: ti: Add support for dm814x ADPLL

[Tony Lindgren]

On dm814x we have 13 ADPLLs with 3 to 4 outputs on each. The
ADPLLs have several dividers and muxes controlled by a shared
control register for each PLL.

Note that for the clocks to work as device drivers for booting on
dm814x, this patch depends on "ARM: OMAP2+: Change core_initcall
levels to postcore_initcall".

Also note that this patch does not implement clk_set_rate,
that will be posted later on when available.

Signed-off-by: Tony Lindgren <t...@atomide.com>
---

Updated to use adpll_lj and adpll_s naming and s/FAPLL/ADPLL/ in the
documentation as suggested by Matthijs.

If no other comments, I'd like to have this patch alone in an immutable
branch againt v4.4-rc1 that I can merge in too. Maybe Tero wants to do
that and merge this along with the other omap clock patches?

---
 .../devicetree/bindings/clock/ti/adpll.txt |   42 +
 drivers/clk/Kconfig|1 +
 drivers/clk/ti/Kconfig |6 +
 drivers/clk/ti/Makefile|2 +
 drivers/clk/ti/adpll.c | 1028 
 drivers/clk/ti/clk-814x.c  |   53 +
 6 files changed, 1132 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/ti/adpll.txt
 create mode 100644 drivers/clk/ti/Kconfig
 create mode 100644 drivers/clk/ti/adpll.c

diff --git a/Documentation/devicetree/bindings/clock/ti/adpll.txt 
b/Documentation/devicetree/bindings/clock/ti/adpll.txt
new file mode 100644
index 000..8d951de
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/ti/adpll.txt
@@ -0,0 +1,42 @@
+Binding for Texas Instruments ADPLL clock.
+
+Binding status: Unstable - ABI compatibility may be broken in the future
+
+This binding uses the common clock binding[1]. It assumes a
+register-mapped ADPLL with two to three selectable input clocks
+and three to four children..
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+- compatible : shall be one of "ti,dm814-adpll-s-clock" or
+  "ti,dm814-adpll-j-clock" depending on the type of the ADPLL
+- #clock-cells : from common clock binding; shall be set to 0.
+- clocks : link phandles of parent clocks (clk-ref and clk-bypass)
+- reg : address and length of the register set for controlling the ADPLL.
+
+Examples:
+   adpll_mpu_ck: adpll@40 {
+   #clock-cells = <1>;
+   compatible = "ti,dm814-adpll-s-clock";
+   reg = <0x40 0x40>;
+   clocks = <_ck _ck _ck>;
+   clock-names = "clkinp", "clkinpulow", "clkinphif";
+   clock-indices = <0>, <1>, <2>, <3>;
+   clock-output-names = "481c5040.adpll.dcoclkldo",
+"481c5040.adpll.clkout",
+"481c5040.adpll.clkoutx2",
+"481c5040.adpll.clkouthif";
+   };
+
+   adpll_dsp_ck: adpll@80 {
+   #clock-cells = <1>;
+   compatible = "ti,dm814-adpll-lj-clock";
+   reg = <0x80 0x30>;
+   clocks = <_ck _ck>;
+   clock-names = "clkinp", "clkinpulow";
+   clock-indices = <0>, <1>, <2>;
+   clock-output-names = "481c5080.adpll.clkdcoldo",
+"481c5080.adpll.clkout",
+"481c5080.adpll.clkoutldo";
+   };
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index c3e3a02f..c0c9868 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -190,6 +190,7 @@ config COMMON_CLK_CDCE706
 
 source "drivers/clk/bcm/Kconfig"
 source "drivers/clk/hisilicon/Kconfig"
+source "drivers/clk/ti/Kconfig"
 source "drivers/clk/qcom/Kconfig"
 
 endmenu
diff --git a/drivers/clk/ti/Kconfig b/drivers/clk/ti/Kconfig
new file mode 100644
index 000..a9d5474
--- /dev/null
+++ b/drivers/clk/ti/Kconfig
@@ -0,0 +1,6 @@
+config COMMON_CLK_TI_ADPLL
+   tristate "Clock driver for dm814x ADPLL"
+   depends on ARCH_OMAP2PLUS
+   default y if SOC_TI81XX
+   ---help---
+ ADPLL clock driver for the dm814x SoC using common clock framework.
diff --git a/drivers/clk/ti/Makefile b/drivers/clk/ti/Makefile
index d4ac960..dfe91d7 100644
--- a/drivers/clk/ti/Makefile
+++ b/drivers/clk/ti/Makefile
@@ -18,3 +18,5 @@ obj-$(CONFIG_SOC_AM43XX)  += $(clk-common) 
dpll3xxx.o clk-43xx.o
 ifdef CONFIG_ATAGS
 obj-$(CONFIG_ARCH_OMAP3)+= clk-3xxx-legacy.o
 endif
+
+obj-$(CONFIG_COMMON_CLK_TI_ADPLL)  += adpll.o
diff --git a/drivers/clk/ti/adpll.c b/drivers/clk/ti/adpll.c
new file mode 100644
index 000..2c75c55
--- /dev/null
+++ b/dri

Re: [PATCH 1/2] clk: ti: Add support for dm814x ADPLL

[Tony Lindgren]

Hi,

* Tony Lindgren <t...@atomide.com> [151203 08:08]:
> * Tony Lindgren <t...@atomide.com> [151202 17:36]:
> > On dm814x we have 13 ADPLLs with 3 to 4 outputs on each. The
> > ADPLLs have several dividers and muxes controlled by a shared
> > control register for each PLL.
> > 
> > Note that for the clocks to work as device drivers for booting on
> > dm814x, this patch depends on "ARM: OMAP2+: Change core_initcall
> > levels to postcore_initcall".
> > 
> > Also note that this patch does not implement clk_set_rate,
> > that will be posted later on when available.
> 
> Mike & Stephen, after review, can we have this patch alone in an
> immutable branch against v4.4-rc1 that I can merge in too?

Matthijs wanted to rename adpllj naming to adpll_lj and remove remaining
fapll references, so I'll do that today and repost this series.

Tero, do you have any comments on this one? After repost, do you want
to take this into your clock branch and send a pull request to
Mike & Stephen along with other omap clock changes?

> Also, the dts changes I need to queue separately FYI to avoid merge
> conflicts.

I'd still like to have just this clock driver patch alone in an
immutable branch that I can merge in too. Otherwise we'll get oopses
during booting when devices are being added.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH for 4.4 0/2] DT/dmaengine: edma: Convert 16bit arrays to 32bit

[Tony Lindgren]

* Peter Ujfalusi <peter.ujfal...@ti.com> [151209 00:19]:
> Hi,
> 
> Based on the discussion regarding to (convert am33xx to use the new eDMA
> bindings):
> https://www.mail-archive.com/linux-omap@vger.kernel.org/msg122117.html
> 
> This two patch will convert the new eDMA binding to not use 16bit arrays for
> memcpy channel selection and for marking slots reserved.
> The '/bits/ 16' seams to be causing confusion so it is probably better to just
> use standard type for the arrays.
> 
> The new bindings for the eDMA is introduced for 4.4 and we do not have users 
> of
> it, which means that we can still change it w/o the risk of breaking anything
> and we do not need to maintain the compatibility with 16bit arrays.
> 
> The changes in the eDMA driver is local to the DT parsing and should not
> conflict with other changes (like the filter function mapping support). Hrm,
> there might be trivial conflict in the include/linux/platform_data/edma.h with
> the "dmaengine 'universal' API".
> 
> Tony, Arnd, Vinod: Can you agree on the practicalities on how these patches 
> are
> going to be handled? I would like to send the updated am33xx/am437x conversion
> for 4.5 based on these changes.

Yes this should go into v4.4 as discussed, otherwise it will be a mess.
For both, please feel free to add:

Acked-by: Tony Lindgren <t...@atomide.com>

I suggest Vinod sets up an immutable branch against v4.4-rc1 with just these
two patches. Then it can get merged into whichever branch needs it, I
certainly will need it as most of my v4.5 branches are v4.4-rc1 or -rc2
based.

Then the immutable branch can be merged into v4.4 by Vinod or Arnd.

Regards,

Tony

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: debugging

[Tony Lindgren]

* Ryan  [151209 09:03]:
> Hello,
> 
> On a custom 4460 board. The x-loader hangs at some place when we
> reboot. This happens occasionally on an android port by linaro.
> 
> I just want to find out how to debug in this case. How can i get to
> know where the hang takes place. After boot rom, i can see the mmc clk
> toggling
> indicating that xloader is in sram when the hang takes place and not
> sure where the hang is.
> 
> Do i need Lauterbach to debug - Is it possible to connect the emulator
> across reboot. If so, how? or is there any other way i can debug this
> 
> Also, i want to check - If i can turn off the dplls? If so, how?
> 
> I tried to do a disable on all the clocks in the clock list using
> clk_disable call just before reboot and that does not seem to help.

You can add selected serial print statements very early into u-boot
MLO (and probably x-loader). You need to keep them down to minimum
so the image still fits into SRAM. If you enable debug, then that also
needs to be limited to selected files only as enabling debug for the
whole MLO/x-loader in the Makefile will make it too big.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [4.4-rc][PATCH v2] ARM: dts: am4372: fix clock source for arm twd and global timers

[Tony Lindgren]

* Felipe Balbi <ba...@ti.com> [151208 10:05]:
> 
> Hi,
> 
> Grygorii Strashko <grygorii.stras...@ti.com> writes:
> > ARM TWD and Global timer are clocked by PERIPHCLK which is MPU_CLK/2.
> > But now they are clocked by dpll_mpu_m2_ck == MPU_CLK and, as result.
> > Timekeeping core misbehaves. For example, execution of command
> > "sleep 5" will take 10 sec instead of 5.
> >
> > Hence, fix it by adding mpu_periphclk ("fixed-factor-clock") and use
> > it for clocking ARM TWD and Global timer (same way as on OMAP4).
> >
> > Cc: Tony Lindgren <t...@atomide.com>
> > Cc: Felipe Balbi <ba...@ti.com>
> > Cc: Tero Kristo <t-kri...@ti.com>
> > Fixes:commit 8cbd4c2f6a99 ("arm: boot: dts: am4372: add ARM timers and SCU 
> > nodes")
> > Signed-off-by: Grygorii Strashko <grygorii.stras...@ti.com>
> 
> this seems to be the best fix for this problem, yeah.
> 
> Reviewed-by: Felipe Balbi <ba...@ti.com>

OK applying into omap-for-v4.4/fixes thanks.

Tony


--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 02/10] clk: ti: Add few dm814x clock aliases

[Tony Lindgren]

* Tero Kristo <t-kri...@ti.com> [151208 23:50]:
> On 12/08/2015 10:11 PM, Tony Lindgren wrote:
> >* Tero Kristo <t-kri...@ti.com> [151208 11:25]:
> >>On 12/08/2015 06:57 PM, Tony Lindgren wrote:
> >>>
> >>>Anybody from the clock department care to ack this one?
> >>
> >>Sorry been rather busy lately...
> >>
> >>>I'd like to
> >>>get this series into Linux next as it fixes some some issues.
> >>
> >>Yeah looks good to me, don't have access to dm814x so can't test.
> >>
> >>Acked-by: Tero Kristo <t-kri...@ti.com>
> >
> >Thanks.
> >
> >>Are you planning to push this via omap tree if this is critical for you?
> >
> >Yes this series needs to be merged in certain order to keep t410
> >booting. Should not conflict with anything else AFAIK.
> 
> Ok at least I am fine with that. The dm81xx clock alias file is pretty
> independent of anything else.

Pushing this series except for the GPIO reset change into
omap-for-v4.5/81xx-fixes.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 004/182] gpio: generic: factor into gpio_chip struct

[Tony Lindgren]

* Linus Walleij <linus.wall...@linaro.org> [151209 05:14]:
> The separate struct bgpio_chip has been a pain to handle, both
> by being confusingly similar in name to struct gpio_chip and
> for being contained inside a struct so that struct gpio_chip
> is contained in a struct contained in a struct, making several
> steps of dereferencing necessary.
> 
> Make things simpler: include the fields directly into
> , #ifdef:ed for CONFIG_GENERIC_GPIO, and
> get rid of the  altogether. Prefix
> some of the member variables with bgpio_* and add proper
> kerneldoc while we're at it.
> 
> Modify all users to handle the change and use a struct
> gpio_chip directly. And while we're at it: replace all
> container_of() dereferencing by gpiochip_get_data() and
> registering the gpio_chip with gpiochip_add_data().
...

> ---
> ARM SoC folks and Lee: it would be great if you could
> ACK the few lines hitting arch/arm/* and drivers/mfd/* in this
> so I can take it through the GPIO tree.

For omap:

Acked-by: Tony Lindgren <t...@atomide.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: DTS: am33xx: Use the new DT bindings for the eDMA3

[Tony Lindgren]

* Arnd Bergmann <a...@arndb.de> [151208 02:26]:
> On Tuesday 08 December 2015 12:22:09 Peter Ujfalusi wrote:
> > On 12/08/2015 11:51 AM, Arnd Bergmann wrote:
> > > On Tuesday 08 December 2015 09:42:26 Peter Ujfalusi wrote:
> > >> On 12/04/2015 11:51 PM, Tony Lindgren wrote:
> > >>>>
> > >>>> Please just drop the /bits/ 16 and use normal cells.
> > >>>
> > >>> Yeah agreed, makes things less confusing for sure 
> > >>
> > >> 4.4 will be the first kernel where we will have the new eDMA bindings. I 
> > >> have
> > >> chosen to use 16bit array for specifying the channels used for memcpy
> > >> (ti,edma-memcpy-channels) and for the reserving paRAM slots
> > >> (ti,edma-reserved-slot-ranges). As of now we have maximum of 64 channels 
> > >> and
> > >> 512 paRAM slots. 16bit is more than enough to store this information and 
> > >> it
> > >> even gives us enough room if ever in the future these numbers are going 
> > >> to
> > >> increase (which  they are not).
> > >>
> > >> But in order to change them to 32bit the driver needs to be changed as 
> > >> well.
> > >> Currently we do not have drivers (in 4.4) using the new bindings, 4.4 is 
> > >> not
> > >> yet out, so it might be possible to change the binding document and the 
> > >> driver
> > >> to use 32bit arrays. The driver internally uses 16bit type for these 
> > >> which I'm
> > >> not going to change, but the code parsing the DT needs to be adjusted 
> > >> for the
> > >> new data type.
> > >>
> > >> If Vinod is willing to take update for the DT binding of eDMA for 
> > >> 4.4-rc, I
> > >> can cook up the patch(es) to do so.
> > > 
> > > I hadn't realized that it was already in 4.4-rc. The change should be 
> > > trivial
> > > enough though, so I'd still do it. If Vinod would rather not change it 
> > > now,
> > > it's not overly important though.
> > 
> > But this change must be done before we have actual users of these 
> > properties,
> > which is the am33xx, am437x and the da850 conversion series I have sent 
> > recently.
> > We might want to have this changed for 4.4 since it is going to be an LTS
> > release...
> 
> Yes, that's what I meant: We either get the patch into 4.4 by creating a
> branch for Vinod to pull with this change, and base all other changes in your
> 4.5 series on the same branch, or we don't change it at all.

Sounds good to me. If there's an immutable branch against v4.4-rc1 with just
that change in it will make our lives easier.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Re: BUG: TI CPSW driver hanging up when setting mac-address to early

[Tony Lindgren]

* ker...@iktek.de  [151207 09:17]:
> Hi Tony,
> 
> there are two ethernet interfaces ( dual-emac-configuration ) used.
> One is connected to another 100mbit switch-ic ( refclk should come from
> switch ic ) via rmii, the other one is connected to a 1gbit fpga rgmii
> interface ( where the clock is served from the fpga ).
> 
> On both interfaces it may happen that the clock isn't present while the
> mac-address is set (fpga may not have been inited, switch chip could be
> held in reset), but this was the same behaviour with previous kernel
> (3.14 with cpsw patched from ti tree) where this configuration worked.
> As the hardware is in field now there is no chance to change hardware.
> 
> On the other hand: when not setting the mac of the interface that early,
> the cpsw seems to init proberly but a ping to the outer world does not
> work either, so something else may be different on the new kernel.

Maybe Mugunthan has some ideas what's going on here.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mmc: pwrseq_simple: Fix regression with optional GPIOs

[Tony Lindgren]

* Ulf Hansson <ulf.hans...@linaro.org> [151208 05:18]:
> On 8 December 2015 at 01:32, Tony Lindgren <t...@atomide.com> wrote:
> > * Ulf Hansson <ulf.hans...@linaro.org> [151207 16:20]:
> >> +Linus
> >>
> >> On 7 December 2015 at 23:54, Tony Lindgren <t...@atomide.com> wrote:
> >> > Commit ce037275861e ("mmc: pwrseq_simple: use GPIO descriptors array 
> >> > API")
> >> > changed the handling MMC power sequence so GPIOs no longer are optional.
> >> >
> >> > This broke SDIO WLAN at least for omap5 that can't yet use the reset 
> >> > GPIOs
> >> > with pwrseq_simple as a wait is needed after enabling the SDIO device.
> >>
> >> Can you elaborate on this. Did it break omap5 or not? :-)
> >
> > Yes it broke WLAN for omap5 that I just got fixed.. It only uses the clocks
> > art of the pwrseq currently because of the delay needed.
> >
> >> Also, I am interested to know more about the waiting period you need.
> >> I assume that's because of the HW's characteristic?
> >
> > At least TI wl12xx and Marvell 8787 need a delay after enabling the the 
> > WLAN.
> >
> >> Why can't we have that being described in DT and then make
> >> pwrseq_simple *wait* if needed?
> >
> > We can, but I'm thinking that we might be better off adding support for
> > regulators to pwrseq. Both TI wl12xx and Marvell 8787 get power from the
> > battery, and probably have an integrated regulator.
> 
> Sounds very reasonable! Perhaps some of the delays can be handled
> within the context of the regulator then!?

Yes that's in the regulator binding. As long as the pwrseq code can sleep
there's no problem with that.

> > Also, the delay and the power up sequencey can be more complicated than what
> > we currently support. In the 8787 case, pdn pin needs to be asserted for 
> > 300ms
> > after power pins are stable and while reset is held high.
> 
> I am for sure open to extend pwrseq_simple, please go ahead!
> 
> The initial version provided a proof of concept and the
> infrastructure. I expect and want people to extend it to suit their
> HWs.
> 
> If we at some point find that pwrseq_simple starts to become too
> complex, we may add another pwrseq type with a corresponding new
> compatible string.

Yeah OK I'll take a look when I get a chance.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 02/10] clk: ti: Add few dm814x clock aliases

[Tony Lindgren]

* Tony Lindgren <t...@atomide.com> [151201 15:43]:
> The timer clock aliases are needed early on dm814x. Let's also
> add the aliases for the interconnects and MMC.
> 
> Cc: Michael Turquette <mturque...@baylibre.com>
> Cc: Stephen Boyd <sb...@codeaurora.org>
> Cc: Tero Kristo <t-kri...@ti.com>
> Signed-off-by: Tony Lindgren <t...@atomide.com>

Anybody from the clock department care to ack this one? I'd like to
get this series into Linux next as it fixes some some issues.

Regards,

Tony


>  drivers/clk/ti/clk-814x.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/clk/ti/clk-814x.c b/drivers/clk/ti/clk-814x.c
> index e172920..9e85fcc 100644
> --- a/drivers/clk/ti/clk-814x.c
> +++ b/drivers/clk/ti/clk-814x.c
> @@ -14,10 +14,14 @@ static struct ti_dt_clk dm814_clks[] = {
>   DT_CLK(NULL, "devosc_ck", "devosc_ck"),
>   DT_CLK(NULL, "mpu_ck", "mpu_ck"),
>   DT_CLK(NULL, "sysclk4_ck", "sysclk4_ck"),
> + DT_CLK(NULL, "sysclk5_ck", "sysclk5_ck"),
>   DT_CLK(NULL, "sysclk6_ck", "sysclk6_ck"),
> + DT_CLK(NULL, "sysclk8_ck", "sysclk8_ck"),
>   DT_CLK(NULL, "sysclk10_ck", "sysclk10_ck"),
>   DT_CLK(NULL, "sysclk18_ck", "sysclk18_ck"),
>   DT_CLK(NULL, "timer_sys_ck", "devosc_ck"),
> + DT_CLK(NULL, "timer1_fck", "timer1_fck"),
> + DT_CLK(NULL, "timer2_fck", "timer2_fck"),
>   DT_CLK(NULL, "cpsw_125mhz_gclk", "cpsw_125mhz_gclk"),
>   DT_CLK(NULL, "cpsw_cpts_rft_clk", "cpsw_cpts_rft_clk"),
>   { .node_name = NULL },
> -- 
> 2.6.2
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 02/10] clk: ti: Add few dm814x clock aliases

[Tony Lindgren]

* Tero Kristo <t-kri...@ti.com> [151208 11:25]:
> On 12/08/2015 06:57 PM, Tony Lindgren wrote:
> >
> >Anybody from the clock department care to ack this one?
> 
> Sorry been rather busy lately...
>
> >I'd like to
> >get this series into Linux next as it fixes some some issues.
> 
> Yeah looks good to me, don't have access to dm814x so can't test.
> 
> Acked-by: Tero Kristo <t-kri...@ti.com>

Thanks.

> Are you planning to push this via omap tree if this is critical for you?

Yes this series needs to be merged in certain order to keep t410
booting. Should not conflict with anything else AFAIK.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] usb: musb: core: Fix handling of the phy notifications

[Tony Lindgren]

* Kishon Vijay Abraham I <kis...@ti.com> [151206 23:03]:
> On Tuesday 01 December 2015 11:07 AM, Tony Lindgren wrote:
> > We currently can't unload omap2430 MUSB platform glue driver module and
> > this cause issues for fixing the MUSB code further. The reason we can't
> > remove omap2430 is because it uses the PHY functions and also exports the
> > omap_musb_mailbox function that some PHY drivers are using.
> > 
> > Let's fix the issue by exporting a more generic musb_mailbox function
> > from the MUSB core and allow platform glue layers to register phy_callback
> > function as needed.
> > 
> > And now we can now also get rid of the include/linux/musb-omap.h.
> > 
> > Cc: Bin Liu <b-...@ti.com>
> > Cc: Felipe Balbi <ba...@ti.com>
> > Cc: Kishon Vijay Abraham I <kis...@ti.com>
> > Cc: NeilBrown <n...@brown.name>
> > Signed-off-by: Tony Lindgren <t...@atomide.com>
> 
> Reviewed-by: Kishon Vijay Abraham I <kis...@ti.com>
> > 
> > Probably best that Felipe merges this patch via the USB tree after
> > comments if that works for Kishon? I have another two fixes for the
> 
> That should be okay.

OK thanks!

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html