Re: [PATCH 10/13] twl4030_charger: add software controlled linear charging mode.

[Pavel Machek]

Hi!

> Pavel Machek  writes:
> > On Thu 2015-07-30 10:11:24, NeilBrown wrote:
> >> 
> >> Add a 'continuous' option for usb charging which enables
> >> the "linear" charging mode of the twl4030.
> >> 
> >> Linear charging does a good job with not-so-reliable power sources.
> >> Auto mode does not work well as it switches off when voltage drops
> >> momentarily.  Care must be taken not to over-charge.
> >
> > Can you explain how the user can "care not to over-charge"?
> 
> The following text reads:
> 
> It was used with a bike hub dynamo since a year or so. In that case
> there are automatically charging stops when the cyclist needs a break.
> 
> so: take a break from cycling occasionally.

If the charger does not exceed 4.2V, I'd not call it overcharge. (Yes, some 
clever
chargers actually let the battery drop below 4.2V when charge is done, but...)

If the charger _does_ exceed 4.2V, then the battery will explode. Don't do 
that. Don't
offer that to the user.

On a related note... I've just killed USB charger by overloading it. They are 
not protected.

I believe your automatically-pull-max-power really should stick to the 
well-known charging
currents (.5A, 1A, 1.7A), at the very minimum.


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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: All OMAP platforms: MMC is broken

[Russell King - ARM Linux]

On Tue, Oct 06, 2015 at 04:06:09PM +0530, Kishon Vijay Abraham I wrote:
> Hi,
> 
> On Tuesday 06 October 2015 03:41 PM, Ulf Hansson wrote:
> > On 6 October 2015 at 11:44, Tony Lindgren  wrote:
> >> * Russell King - ARM Linux  [151006 02:04]:
> >>> On Mon, Oct 05, 2015 at 07:38:13PM +0100, Russell King - ARM Linux wrote:
>  On Mon, Oct 05, 2015 at 10:11:56AM -0700, Tony Lindgren wrote:
> > * Tony Lindgren  [151005 07:57]:
> >> * Tony Lindgren  [151005 07:44]:
> >>> * Tony Lindgren  [151005 04:28]:
> >>>
> >>> Based on some tests it seems that the duovero unpaired regulator usage
> >>> is fixed by reverting:
> >>>
> >>> c55d7a055364 ("mmc: host: omap_hsmmc: use regulator_is_enabled to
> >>> find pbias status")
> >>
> >> With commit c55d7a055364 my guess is that the PBIAS regulator is
> >> already on from an earlier MMC probe and getting re-enabled when
> >> a deferred probe happens?
> >
> > Unless somebody has a better fix in mind for the above, I suggest
> > we revert it for the -rc kernel.
> 
>  Let me try reverting that in my build tree, and...
> 
> >>> And it seems that omap3 legacy MMC is broken earlier in the
> >>> series with:
> >>>
> >>> 7d607f917008 ("mmc: host: omap_hsmmc: use
> >>> devm_regulator_get_optional() for vmmc")
> >>>
> >>> This one does not cleanly revert so have not yet tried reverting
> >>> it.
> >>
> >> And with commit 7d607f917008 I'm guessing we can't return anHi,
> >> error if the PBIAS regulator does not exist as that's not there
> >> for the legacy booting.
> >
> > For omap3 legacy booting, we keep getting -EPROBE_DEFER for
> > all the optional regulators.
> >
> > Something like the following might be the minimal fix for the -rc
> > cycle?
> 
>  applying this patch.  If that gets things going again, then we
>  _definitely_ should get both of these to Linus ASAP.  The breakage
>  has been around far too long already.
> >>>
> >>> Last night's build shows that this fixes the non-DT LDP3430 booting, but
> >>> DT-based LDP3430 and SDP4430 both remain broken for the same reason -
> >>> neither can find their SD cards.
> >>
> >> Hmm DT-based boot finds the MMC card for LDP, dmesg below from DT boot [1].
> >> Looks like you're on on -rc4 and not -rc3. My guess is that MMC is not
> >> working for you with DT-based booting because you don't seem to have
> >> CONFIG_REGULATOR_PBIAS in your seed config for. Care to try enabling that
> >> for both your omap3 and omap4 seed config files?
> >>
> >>> We're at -rc4.  That means we're could be only three weeks away from 4.3
> >>> being released, and DT OMAP has yet to boot _once_ here.
> >>>
> >>> What I find *totally* unacceptable is the lack of reaction from the MMC
> >>> and TI people: it's just like "we'll break your crap, and we'll ignore
> >>> reports of regressions."  That is *not* acceptable in any shape or form,
> >>> and people who do this _should_ have their future patches ignored until
> >>> they demonstrate that they understand the need to not break stuff.
> >>>
> >>> I'm at the point of suggesting that there should be a moritorium on all
> >>> OMAP related development for 4.4: delay all development to 4.5, and have
> >>> 4.4 as a pure bug-fixing _only_ cycle for OMAP.  If 4.3 is released and
> >>> OMAP is still broken, then I don't think there's an option on that.
> >>>
> >>> Maybe the idea that development work won't hit mainline for another 4
> >>> months will help focus the minds on not breaking stuff and then ignoring
> >>> regression reports.
> >>
> >> I'm thinking along the same lines. In general, I do not and will not
> >> apply any patches that are not fixes until all critical regressions are
> >> out of the way. So not applying anything new for v4.4 until these MMC
> >> regressions are fixed for v4.3.
> >>
> > 
> > Tony, Russell - just wanted to say thanks for putting a big effort in
> > fixing this. I was expecting support from Kishon, but I guess he's
> > busy.
> > 
> > Unfortunate, I don't have any of the hardware that fails, otherwise I
> > would of course be helping out more. The only thing I can think of is
> > to revert the entire patchset I picked up for 4.3 from Kishon for the
> > omap_hsmmc driver, but then I am not sure if that would cause other
> > issues...
> 
> Please don't do that as that will just mask lot of bugs in the
> devicetree and might get MMC working. Indeed I was busy but I'll try to
> get this resolved asap. The 2 pending issues as far as I know

Sorry, but no.  None of this "mask bugs ... might" crap.  Either they're
bug fixes, or they aren't bug fixes.  This should be a definite decision,
not some vague crap.

If they're bug fixes, why the _hell_ aren't they queued for -rc kernels?

This sounds really screwed up to me, and it's no 

Re: [RFC/PATCH 11/11] arm: boot: dts: omap: add missing default status for 32k counter

[Felipe Balbi]

Hi,

Tony Lindgren  writes:

> * Felipe Balbi  [151006 08:02]:
>> - ti,timer-alwon:Indicates the timer is in an alway-on power
>>   domain.
>> 
>> Tony, care to comment if we should add timer-alwon to 32k ?
>
> No that should not be needed for the 32k counter. We should be able
> to do everything we want with CLOCK_SOURCE_SUSPEND_NONSTOP for the
> 32k counter.
>
> We still need ti,timer-alwon for a while for gptimers 1 and 12 as
> they are the only ones in the always-on domain. I guess that need
> will eventually go away too once we have a proper interconnect
> driver and are using genpd.

cool, thanks. I'll try to respin this series, hopefully still this week.

-- 
balbi


signature.asc
Description: PGP signature

Re: All OMAP platforms: MMC is broken

[Tony Lindgren]

* Russell King - ARM Linux  [151006 08:04]:
> On Tue, Oct 06, 2015 at 02:44:25AM -0700, Tony Lindgren wrote:
> > 
> > Hmm DT-based boot finds the MMC card for LDP, dmesg below from DT boot [1].
> > Looks like you're on on -rc4 and not -rc3. My guess is that MMC is not
> > working for you with DT-based booting because you don't seem to have
> > CONFIG_REGULATOR_PBIAS in your seed config for. Care to try enabling that
> > for both your omap3 and omap4 seed config files?
> 
> This is precisely the kind of crap I'm objecting to.  New kernel versions
> come along, and things break because people add extra Kconfig symbols that
> previous versions did not rely upon - and there's no communication of
> what's required for new kernel versions.
> 
> This stuff needs documenting, so that people are aware what changes they
> need to make - please put something in Documentation/arm/OMAP which
> tracks what new additions are required to the Kconfig to keep things
> working.

Good idea, how about something like the following? AFAIK that's the
only .config option needed as MFD_SYSCON is selected by Kconfig
already.

Regrds,

Tony

8< --
From: Tony Lindgren 
Date: Tue, 6 Oct 2015 08:33:16 -0700
Subject: [PATCH] Documentation: ARM: List new omap MMC requirements

Earlier the PBIAS regulator was optional, not so with recent
omap_hsmmc changes. To make things easier for people with
custom .config files, let's add minimal documentation for it
as suggested by Russell King .

Signed-off-by: Tony Lindgren 

--- /dev/null
+++ b/Documentation/arm/OMAP/README
@@ -0,0 +1,7 @@
+This file contains documentation for running mainline
+kernel on omaps.
+
+KERNEL NEW DEPENDENCIES
+v4.3+  Update is needed for custom .config files to make sure
+   CONFIG_REGULATOR_PBIAS is enabled for MMC1 to work
+   properly.
--
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: cpufreq-dt error: failed to init cpufreq table: -61

[Felipe Balbi]

Belisko Marek  writes:

> Hi,
>
> On Tue, Oct 6, 2015 at 4:03 PM, Belisko Marek  wrote:
>> Hi Felipe,
>>
>> On Tue, Oct 6, 2015 at 4:00 PM, Felipe Balbi  wrote:
>>>
>>> Hi,
>>>
>>> Belisko Marek  writes:
 Hi Tony,

 I'm using custom am33xx board where mpu voltage can be changed through
 gpio regulator on 4.1 (latest stable) kernel. I defined gpio-regulator
 node and also operating-points to DT. Gpio regulator seems to be
 working fine but during probing cpufreq-dt I get error:
 failed to init cpufreq table: -61

 I did small investigation and seem that dev_pm_opp_init_cpufreq_table
 fails at first condition dev_pm_opp_get_opp_count <= 0 and this is
 because opp_list is empty. So it seems that any opp for am33xx aren't
 defined if I'm getting it right. I did look to mach-omap2/opp3xxx_data
 but there is nothing am33xx specific. It is known problem or exist
 some patches around to fix that? Many thanks.
>>>
>>> OPP initialization is not in mainline yet, there are some out-of-tree
>>> patches which TI has been working on. If you want to use them, have a
>>> look at TI's vendor kernel at [1]
>> Thanks for link. One thing which is still not puzzled before I use 3.9
>> kernel and it was working fine
>> it's stops working when bumped to 4.1.
>
> Sorry information was incorrect. On 3.9 kernel we did use tps, pmic
> now we have only gpio regulator so this is the difference.

okay, if it's only a regulator how can you set different voltages ?
Seems like you won't be able to do anything more than enable/disable a
voltage rail.

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v2] arm: omap2: timer: don't disable our timers

[Felipe Balbi]

Tony Lindgren  writes:

> * Felipe Balbi  [151005 17:49]:
>> We actually want these devices to be created because
>> we will be moving timers to drivers/clocksource and
>> this will prevent them from probing.
>
> Great. Is this safe to appy on it's own? We are not getting
> system timers re-inited to the default values?

not that I could notice. I booted on BBB and AM4. If you give me a few
minutes I can boot again and save console logs for reference.

-- 
balbi


signature.asc
Description: PGP signature

Re: [RFC/PATCH 11/11] arm: boot: dts: omap: add missing default status for 32k counter

[Tony Lindgren]

* Felipe Balbi  [151006 08:02]:
> Arnd Bergmann  writes:
> 
> > On Monday 05 October 2015 14:41:07 Felipe Balbi wrote:
> >> 
> >> /**
> >>  * omap_get_timer_dt - get a timer using device-tree
> >>  * @match   - device-tree match structure for matching a device type
> >>  * @property- optional timer property to match
> >>  *
> >>  * Helper function to get a timer during early boot using device-tree for 
> >> use
> >>  * as kernel system timer. Optionally, the property argument can be used to
> >>  * select a timer with a specific property. Once a timer is found then mark
> >>  * the timer node in device-tree as disabled, to prevent the kernel from
> >>  * registering this timer as a platform device and so no one else can use 
> >> it.
> >>  */
> >> static struct device_node * __init omap_get_timer_dt(const struct 
> >> of_device_id *match,
> >>  const char *property)
> >> {
> >> struct device_node *np;
> >> 
> >> for_each_matching_node(np, match) {
> >> if (!of_device_is_available(np))
> >> continue;
> >> 
> >> if (property && !of_get_property(np, property, NULL))
> >> continue;
> >> 
> >> if (!property && (of_get_property(np, "ti,timer-alwon", 
> >> NULL) ||
> >>   of_get_property(np, "ti,timer-dsp", 
> >> NULL) ||
> >>   of_get_property(np, "ti,timer-pwm", 
> >> NULL) ||
> >>   of_get_property(np, "ti,timer-secure", 
> >> NULL)))
> >> continue;
> >> 
> >> of_add_property(np, _disabled);
> >> return np;
> >> }
> >> 
> >> return NULL;
> >> }
> >> 
> >> I'll patch this up and drop $subject
> >> 
> >
> > Ah, good.
> >
> > I'm seeing the "ti,timer-alwon" property here, we probably need to take
> > that into account when setting the CLOCK_SOURCE_SUSPEND_NONSTOP flag, if
> > that isn't how it gets done already.
> 
> that flag is not set for 32k in any dts. Seems like it should, though,
> judging by the binding documentation:
> 
> - ti,timer-alwon: Indicates the timer is in an alway-on power
>   domain.
> 
> Tony, care to comment if we should add timer-alwon to 32k ?

No that should not be needed for the 32k counter. We should be able
to do everything we want with CLOCK_SOURCE_SUSPEND_NONSTOP for the
32k counter.

We still need ti,timer-alwon for a while for gptimers 1 and 12 as
they are the only ones in the always-on domain. I guess that need
will eventually go away too once we have a proper interconnect
driver and are using genpd.

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: All OMAP platforms: MMC is broken

[Russell King - ARM Linux]

On Tue, Oct 06, 2015 at 02:44:25AM -0700, Tony Lindgren wrote:
> * Russell King - ARM Linux  [151006 02:04]:
> > On Mon, Oct 05, 2015 at 07:38:13PM +0100, Russell King - ARM Linux wrote:
> > > On Mon, Oct 05, 2015 at 10:11:56AM -0700, Tony Lindgren wrote:
> > > > * Tony Lindgren  [151005 07:57]:
> > > > > * Tony Lindgren  [151005 07:44]:
> > > > > > * Tony Lindgren  [151005 04:28]:
> > > > > > 
> > > > > > Based on some tests it seems that the duovero unpaired regulator 
> > > > > > usage
> > > > > > is fixed by reverting:
> > > > > > 
> > > > > > c55d7a055364 ("mmc: host: omap_hsmmc: use regulator_is_enabled to
> > > > > > find pbias status")
> > > > > 
> > > > > With commit c55d7a055364 my guess is that the PBIAS regulator is
> > > > > already on from an earlier MMC probe and getting re-enabled when
> > > > > a deferred probe happens?
> > > > 
> > > > Unless somebody has a better fix in mind for the above, I suggest
> > > > we revert it for the -rc kernel.
> > > 
> > > Let me try reverting that in my build tree, and...
> > > 
> > > > > > And it seems that omap3 legacy MMC is broken earlier in the
> > > > > > series with:
> > > > > > 
> > > > > > 7d607f917008 ("mmc: host: omap_hsmmc: use
> > > > > > devm_regulator_get_optional() for vmmc")
> > > > > > 
> > > > > > This one does not cleanly revert so have not yet tried reverting
> > > > > > it.
> > > > > 
> > > > > And with commit 7d607f917008 I'm guessing we can't return an
> > > > > error if the PBIAS regulator does not exist as that's not there
> > > > > for the legacy booting.
> > > > 
> > > > For omap3 legacy booting, we keep getting -EPROBE_DEFER for
> > > > all the optional regulators.
> > > > 
> > > > Something like the following might be the minimal fix for the -rc
> > > > cycle?
> > > 
> > > applying this patch.  If that gets things going again, then we
> > > _definitely_ should get both of these to Linus ASAP.  The breakage
> > > has been around far too long already.
> > 
> > Last night's build shows that this fixes the non-DT LDP3430 booting, but
> > DT-based LDP3430 and SDP4430 both remain broken for the same reason -
> > neither can find their SD cards.
> 
> Hmm DT-based boot finds the MMC card for LDP, dmesg below from DT boot [1].
> Looks like you're on on -rc4 and not -rc3. My guess is that MMC is not
> working for you with DT-based booting because you don't seem to have
> CONFIG_REGULATOR_PBIAS in your seed config for. Care to try enabling that
> for both your omap3 and omap4 seed config files?

This is precisely the kind of crap I'm objecting to.  New kernel versions
come along, and things break because people add extra Kconfig symbols that
previous versions did not rely upon - and there's no communication of
what's required for new kernel versions.

This stuff needs documenting, so that people are aware what changes they
need to make - please put something in Documentation/arm/OMAP which
tracks what new additions are required to the Kconfig to keep things
working.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
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/11] clocksource: add TI 32.768 Hz counter driver

[Felipe Balbi]

Hi,

Daniel Lezcano  writes:

> On 10/06/2015 07:02 PM, Felipe Balbi wrote:
>> Introduce a new clocksource driver for Texas
>> Instruments 32.768 Hz device which is available
>> on most OMAP-like devices.
>>
>> Signed-off-by: Felipe Balbi 
>
> Hi Felipe,
>
> With the couple of nits below fixed, you can my:
>
> Acked-by: Daniel Lezcano 
>
> [ ... ]
>
>> +#define OMAP2_32KSYNCNT_REV_OFF 0x0
>> +#define OMAP2_32KSYNCNT_REV_SCHEME  (0x3 << 30)
>> +#define OMAP2_32KSYNCNT_CR_OFF_LOW  0x10
>> +#define OMAP2_32KSYNCNT_CR_OFF_HIGH 0x30
>> +
>> +struct ti_32k {
>> +void __iomem*base;
>> +void __iomem*counter;
>> +struct clocksource  cs;
>> +};
>> +#define to_ti_32k(cs)   (container_of((cs), struct ti_32k, cs))
>
> Usually a static inline is used instead of a macro for that.

not so true and also completely unnecessary, considering container_of()
already type safety ;-)

Try this:

$ git grep -e "#define.*container_of" | wc -l

no strong feelings though. I tend to prefer a macro to wrap
container_of() but won't go into an argument

-- 
balbi


signature.asc
Description: PGP signature

Re: All OMAP platforms: MMC is broken

[Kishon Vijay Abraham I]

Hi,

On Tuesday 06 October 2015 08:37 PM, Russell King - ARM Linux wrote:
> On Tue, Oct 06, 2015 at 04:06:09PM +0530, Kishon Vijay Abraham I wrote:
>> Hi,
>>
>> On Tuesday 06 October 2015 03:41 PM, Ulf Hansson wrote:
>>> On 6 October 2015 at 11:44, Tony Lindgren  wrote:
 * Russell King - ARM Linux  [151006 02:04]:
> On Mon, Oct 05, 2015 at 07:38:13PM +0100, Russell King - ARM Linux wrote:
>> On Mon, Oct 05, 2015 at 10:11:56AM -0700, Tony Lindgren wrote:
>>> * Tony Lindgren  [151005 07:57]:
 * Tony Lindgren  [151005 07:44]:
> * Tony Lindgren  [151005 04:28]:
>
> Based on some tests it seems that the duovero unpaired regulator usage
> is fixed by reverting:
>
> c55d7a055364 ("mmc: host: omap_hsmmc: use regulator_is_enabled to
> find pbias status")

 With commit c55d7a055364 my guess is that the PBIAS regulator is
 already on from an earlier MMC probe and getting re-enabled when
 a deferred probe happens?
>>>
>>> Unless somebody has a better fix in mind for the above, I suggest
>>> we revert it for the -rc kernel.
>>
>> Let me try reverting that in my build tree, and...
>>
> And it seems that omap3 legacy MMC is broken earlier in the
> series with:
>
> 7d607f917008 ("mmc: host: omap_hsmmc: use
> devm_regulator_get_optional() for vmmc")
>
> This one does not cleanly revert so have not yet tried reverting
> it.

 And with commit 7d607f917008 I'm guessing we can't return anHi,
 error if the PBIAS regulator does not exist as that's not there
 for the legacy booting.
>>>
>>> For omap3 legacy booting, we keep getting -EPROBE_DEFER for
>>> all the optional regulators.
>>>
>>> Something like the following might be the minimal fix for the -rc
>>> cycle?
>>
>> applying this patch.  If that gets things going again, then we
>> _definitely_ should get both of these to Linus ASAP.  The breakage
>> has been around far too long already.
>
> Last night's build shows that this fixes the non-DT LDP3430 booting, but
> DT-based LDP3430 and SDP4430 both remain broken for the same reason -
> neither can find their SD cards.

 Hmm DT-based boot finds the MMC card for LDP, dmesg below from DT boot [1].
 Looks like you're on on -rc4 and not -rc3. My guess is that MMC is not
 working for you with DT-based booting because you don't seem to have
 CONFIG_REGULATOR_PBIAS in your seed config for. Care to try enabling that
 for both your omap3 and omap4 seed config files?

> We're at -rc4.  That means we're could be only three weeks away from 4.3
> being released, and DT OMAP has yet to boot _once_ here.
>
> What I find *totally* unacceptable is the lack of reaction from the MMC
> and TI people: it's just like "we'll break your crap, and we'll ignore
> reports of regressions."  That is *not* acceptable in any shape or form,
> and people who do this _should_ have their future patches ignored until
> they demonstrate that they understand the need to not break stuff.
>
> I'm at the point of suggesting that there should be a moritorium on all
> OMAP related development for 4.4: delay all development to 4.5, and have
> 4.4 as a pure bug-fixing _only_ cycle for OMAP.  If 4.3 is released and
> OMAP is still broken, then I don't think there's an option on that.
>
> Maybe the idea that development work won't hit mainline for another 4
> months will help focus the minds on not breaking stuff and then ignoring
> regression reports.

 I'm thinking along the same lines. In general, I do not and will not
 apply any patches that are not fixes until all critical regressions are
 out of the way. So not applying anything new for v4.4 until these MMC
 regressions are fixed for v4.3.

>>>
>>> Tony, Russell - just wanted to say thanks for putting a big effort in
>>> fixing this. I was expecting support from Kishon, but I guess he's
>>> busy.
>>>
>>> Unfortunate, I don't have any of the hardware that fails, otherwise I
>>> would of course be helping out more. The only thing I can think of is
>>> to revert the entire patchset I picked up for 4.3 from Kishon for the
>>> omap_hsmmc driver, but then I am not sure if that would cause other
>>> issues...
>>
>> Please don't do that as that will just mask lot of bugs in the
>> devicetree and might get MMC working. Indeed I was busy but I'll try to
>> get this resolved asap. The 2 pending issues as far as I know
> 
> Sorry, but no.  None of this "mask bugs ... might" crap.  Either they're
> bug fixes, or they aren't bug fixes.  This should be a definite decision,
> not some vague crap.

What I meant is the patches merged by 

Re: cpufreq-dt error: failed to init cpufreq table: -61

[Belisko Marek]

On Tue, Oct 6, 2015 at 5:07 PM, Felipe Balbi  wrote:
> Belisko Marek  writes:
>
>> Hi,
>>
>> On Tue, Oct 6, 2015 at 4:03 PM, Belisko Marek  
>> wrote:
>>> Hi Felipe,
>>>
>>> On Tue, Oct 6, 2015 at 4:00 PM, Felipe Balbi  wrote:

 Hi,

 Belisko Marek  writes:
> Hi Tony,
>
> I'm using custom am33xx board where mpu voltage can be changed through
> gpio regulator on 4.1 (latest stable) kernel. I defined gpio-regulator
> node and also operating-points to DT. Gpio regulator seems to be
> working fine but during probing cpufreq-dt I get error:
> failed to init cpufreq table: -61
>
> I did small investigation and seem that dev_pm_opp_init_cpufreq_table
> fails at first condition dev_pm_opp_get_opp_count <= 0 and this is
> because opp_list is empty. So it seems that any opp for am33xx aren't
> defined if I'm getting it right. I did look to mach-omap2/opp3xxx_data
> but there is nothing am33xx specific. It is known problem or exist
> some patches around to fix that? Many thanks.

 OPP initialization is not in mainline yet, there are some out-of-tree
 patches which TI has been working on. If you want to use them, have a
 look at TI's vendor kernel at [1]
>>> Thanks for link. One thing which is still not puzzled before I use 3.9
>>> kernel and it was working fine
>>> it's stops working when bumped to 4.1.
>>
>> Sorry information was incorrect. On 3.9 kernel we did use tps, pmic
>> now we have only gpio regulator so this is the difference.
>
> okay, if it's only a regulator how can you set different voltages ?
> Seems like you won't be able to do anything more than enable/disable a
> voltage rail.
Sorry I wasn't precise. There are 2 gpios's with some small logic so
we have 4 voltage
states.
>
> --
> balbi

BR,

marek

-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.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 04/11] arm: omap2: timer: provide generic sync32k_timer_init function

[Felipe Balbi]

Hi,

Suman Anna  writes:
>> diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
>> index 976ff9fa3594..d14e25b2d7a4 100644
>> --- a/arch/arm/mach-omap2/timer.c
>> +++ b/arch/arm/mach-omap2/timer.c
>> @@ -608,21 +608,13 @@ static void __init __omap_sync32k_timer_init(int 
>> clkev_nr, const char *clkev_src
>>  omap2_sync32k_clocksource_init();
>>  }
>>  
>> -#ifdef CONFIG_ARCH_OMAP2
>> -void __init omap2_sync32k_timer_init(void)
>> +void __init omap_sync32k_timer_init(void)
>>  {
>>  __omap_sync32k_timer_init(1, "timer_32k_ck", "ti,timer-alwon",
>>  2, "timer_sys_ck", NULL, false);
>>  }
>> -#endif /* CONFIG_ARCH_OMAP2 */
>>  
>>  #if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_SOC_AM43XX)
>> -void __init omap3_sync32k_timer_init(void)
>> -{
>> -__omap_sync32k_timer_init(1, "timer_32k_ck", "ti,timer-alwon",
>> -2, "timer_sys_ck", NULL, false);
>> -}
>> -
>>  void __init omap3_secure_sync32k_timer_init(void)
>>  {
>>  __omap_sync32k_timer_init(12, "secure_32k_fck", "ti,timer-secure",
>> @@ -640,15 +632,9 @@ void __init omap3_gptimer_timer_init(void)
>>  
>>  #if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5) || \
>>  defined(CONFIG_SOC_DRA7XX) || defined(CONFIG_SOC_AM43XX)
>> -static void __init omap4_sync32k_timer_init(void)
>> -{
>> -__omap_sync32k_timer_init(1, "timer_32k_ck", "ti,timer-alwon",
>> -2, "sys_clkin_ck", NULL, false);
>> -}
>> -
>>  void __init omap4_local_timer_init(void)
>>  {
>> -omap4_sync32k_timer_init();
>> +omap_sync32k_timer_init();
>
> Hmm, this is changing the parent clock source for the timer from
> sys_clkin_ck to timer_sys_ck for OMAP4 and OMAP5 below. I am not sure of
> the history behind the parent source, but is this what you intended to
> do here.

good catch. I'll fix this for next revision

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH] arm: omap2: timer: don't disable our timers

[Suman Anna]

On 10/06/2015 12:14 PM, Felipe Balbi wrote:
> 
> Hi,
> 
> Suman Anna  writes:
>> On 10/05/2015 02:48 PM, Balbi, Felipe wrote:
>>> We actually want these devices to be created because
>>> we will be moving timers to drivers/clocksource and
>>> this will prevent them from probing.
>>
>> This logic is also used to remove the secure timer from being
>> registered to the kernel on HS devices, while allowing the timer to be
>> available on GP devices. Your patch actually would break that
>> functionality. I suggest that you look at the history of the code that
>
> heh, that's a silly way of doing so. Could just detect if we're running
> on HS or not.

 This function is invoked only after detecting that we are running on a
 HS device.
>>>
>>> What actually disables the timer is omap_get_timer_dt() and that's
>>> called in more than one place.
>>
>> Yes indeed, and this patch is changing the behavior of
>> omap_get_timer_dt(), so you have to check all call-sites. Also, one
>> another thing is that this trick was used for DT boots so that the
>> timers used for clocksource and clockevent are eliminated from the
>> omap_dm_timer_request() API. The legacy boot used a specific API to mark
>> those as reserved so that the _request API does not give them out.
>> Granted that it may not have been the best approach, but that needs a
>> solution if you change the behavior of this API.
> 
> no doubt this needs a solution, but seesm like a solution here will have
> to be incremental. See new revision of my series. I'm now skipping 32k
> only and keeping it enabled so drivers/clocksource/ can use it.

Yeah, have noticed, and it's better for the current problem at hand than
this patch.

> 
>>> Signed-off-by: Felipe Balbi 
>>> ---
>>>
>>> Tony, I wonder if you can get merged as a fix, or do you
>>> prefer receiving it together with my timer series ?
>>
>> NAK for rc, as it breaks other stuff.
>
> a single stuff which is likely easy enough to fix. But fair enough

 Don't think this patch is fixing any critical bug either, better to club
 it with your cleanup series.
>>>
>>> it is kinda critical when you consider that the timer is disabled
>>> outside of the soc type detection.
>>
>> This has been like this since DMTimer is converted to DT (from 3.8
>> kernel), and is a need for your counter32k clocksource series. The
>> problem seems to stem from the reuse of omap_get_timer_dt for counter32k
>> nodes. A better solution would be to remove the omap_get_timer_dt() from
>> omap2_sync32k_clocksource_init() code and just replace it with
>> of_find_compatible_node - you seem to be limiting the majority of that
>> function to legacy mode in Patch 10 of your RFC series anyways.
> 
> I still need omap_hwmod_enable() to be called, that's why it's still
> used. I don't think replacing it with of_find_compatible_node() will buy
> us much, we will still need to check for of_device_is_available()
> anyway. Sure we skip all the timer flags (alwon, dsp, pwm, secure), but
> that really isn't big deal.

Yeah, I would think the counter_32k and the timer code will have to be
decoupled in the future anyway, so it is best to localize the change now
rather than later, so that the omap2_sync32k_clocksource_init() function
can be decoupled cleanly from the timr code. The check for
of_device_is_available may be moot if this device is always needed. But
as long as current timer functionality is unchanged, I am not too
particular about this. If it is always needed, the check for of_device

regards
Suman


> When converting gptimer to clocksource, then I'll look at what I can do
> for the timer request side of things. For now, things are working,
> apparently without regressions (or at least I couldn't catch any so far)
> and it seems clean enough that it could possibly be queued for v4.4
> merge window. For v4.5 I'll look at this again and try to figure out how
> to handle gptimer.


--
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 04/11] arm: omap2: timer: provide generic sync32k_timer_init function

[Suman Anna]

On 10/06/2015 12:02 PM, Balbi, Felipe wrote:
> instead of constantly defining a small wrapper
> around __omap_sync32k_timer_init(), let's define
> a generic one which can be used by all OMAPs.
> 
> Signed-off-by: Felipe Balbi 
> ---
>  arch/arm/mach-omap2/board-generic.c | 10 +-
>  arch/arm/mach-omap2/board-ldp.c |  2 +-
>  arch/arm/mach-omap2/board-rx51.c|  2 +-
>  arch/arm/mach-omap2/common.h|  3 +--
>  arch/arm/mach-omap2/timer.c | 20 +++-
>  5 files changed, 11 insertions(+), 26 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/board-generic.c 
> b/arch/arm/mach-omap2/board-generic.c
> index 9df14ed7dab1..871db0f0fa66 100644
> --- a/arch/arm/mach-omap2/board-generic.c
> +++ b/arch/arm/mach-omap2/board-generic.c
> @@ -46,7 +46,7 @@ DT_MACHINE_START(OMAP242X_DT, "Generic OMAP2420 (Flattened 
> Device Tree)")
>   .map_io = omap242x_map_io,
>   .init_early = omap2420_init_early,
>   .init_machine   = omap_generic_init,
> - .init_time  = omap2_sync32k_timer_init,
> + .init_time  = omap_sync32k_timer_init,
>   .dt_compat  = omap242x_boards_compat,
>   .restart= omap2xxx_restart,
>  MACHINE_END
> @@ -63,7 +63,7 @@ DT_MACHINE_START(OMAP243X_DT, "Generic OMAP2430 (Flattened 
> Device Tree)")
>   .map_io = omap243x_map_io,
>   .init_early = omap2430_init_early,
>   .init_machine   = omap_generic_init,
> - .init_time  = omap2_sync32k_timer_init,
> + .init_time  = omap_sync32k_timer_init,
>   .dt_compat  = omap243x_boards_compat,
>   .restart= omap2xxx_restart,
>  MACHINE_END
> @@ -82,7 +82,7 @@ DT_MACHINE_START(OMAP3_N900_DT, "Nokia RX-51 board")
>   .init_early = omap3430_init_early,
>   .init_machine   = omap_generic_init,
>   .init_late  = omap3_init_late,
> - .init_time  = omap3_sync32k_timer_init,
> + .init_time  = omap_sync32k_timer_init,
>   .dt_compat  = n900_boards_compat,
>   .restart= omap3xxx_restart,
>  MACHINE_END
> @@ -100,7 +100,7 @@ DT_MACHINE_START(OMAP3_DT, "Generic OMAP3 (Flattened 
> Device Tree)")
>   .init_early = omap3430_init_early,
>   .init_machine   = omap_generic_init,
>   .init_late  = omap3_init_late,
> - .init_time  = omap3_sync32k_timer_init,
> + .init_time  = omap_sync32k_timer_init,
>   .dt_compat  = omap3_boards_compat,
>   .restart= omap3xxx_restart,
>  MACHINE_END
> @@ -116,7 +116,7 @@ DT_MACHINE_START(OMAP36XX_DT, "Generic OMAP36xx 
> (Flattened Device Tree)")
>   .init_early = omap3630_init_early,
>   .init_machine   = omap_generic_init,
>   .init_late  = omap3_init_late,
> - .init_time  = omap3_sync32k_timer_init,
> + .init_time  = omap_sync32k_timer_init,
>   .dt_compat  = omap36xx_boards_compat,
>   .restart= omap3xxx_restart,
>  MACHINE_END
> diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-ldp.c
> index c2975af4cd5d..0d3a57c6931f 100644
> --- a/arch/arm/mach-omap2/board-ldp.c
> +++ b/arch/arm/mach-omap2/board-ldp.c
> @@ -424,6 +424,6 @@ MACHINE_START(OMAP_LDP, "OMAP LDP board")
>   .init_irq   = omap3_init_irq,
>   .init_machine   = omap_ldp_init,
>   .init_late  = omap3430_init_late,
> - .init_time  = omap3_sync32k_timer_init,
> + .init_time  = omap_sync32k_timer_init,
>   .restart= omap3xxx_restart,
>  MACHINE_END
> diff --git a/arch/arm/mach-omap2/board-rx51.c 
> b/arch/arm/mach-omap2/board-rx51.c
> index 2d1e5a6beb85..830256c434ec 100644
> --- a/arch/arm/mach-omap2/board-rx51.c
> +++ b/arch/arm/mach-omap2/board-rx51.c
> @@ -136,6 +136,6 @@ MACHINE_START(NOKIA_RX51, "Nokia RX-51 board")
>   .init_irq   = omap3_init_irq,
>   .init_machine   = rx51_init,
>   .init_late  = omap3430_init_late,
> - .init_time  = omap3_sync32k_timer_init,
> + .init_time  = omap_sync32k_timer_init,
>   .restart= omap3xxx_restart,
>  MACHINE_END
> diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
> index 92e92cfc2775..844ad031f7f0 100644
> --- a/arch/arm/mach-omap2/common.h
> +++ b/arch/arm/mach-omap2/common.h
> @@ -88,8 +88,7 @@ static inline int omap_mux_late_init(void)
>  
>  extern void omap2_init_common_infrastructure(void);
>  
> -extern void omap2_sync32k_timer_init(void);
> -extern void omap3_sync32k_timer_init(void);
> +extern void omap_sync32k_timer_init(void);
>  extern void omap3_secure_sync32k_timer_init(void);
>  extern void omap3_gptimer_timer_init(void);
>  extern void omap4_local_timer_init(void);
> diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
> index 976ff9fa3594..d14e25b2d7a4 100644
> --- a/arch/arm/mach-omap2/timer.c
> +++ b/arch/arm/mach-omap2/timer.c
> @@ -608,21 +608,13 @@ static void __init __omap_sync32k_timer_init(int 
> clkev_nr, const char *clkev_src
> 

Re: [PATCH v4 00/25] dmaengine/ARM: Merge the edma drivers into one

[Peter Ujfalusi]

Hi

On 09/24/2015 01:01 PM, Peter Ujfalusi wrote:
> Hi,
> 
> Changes since v3:
> - Separated the two (patch 10/11 in v2 patch 10 in v3) patch which got 
> squashed
>   by accident for v3
> - Added Tony's Acked-by to patch 11 (for mach-oamp2 part)

Gentle ping on this series ;)

-- 
Péter

> Changes since v2:
> - devm_kasprintf format string fixed
> - Additional patch to enable dynamic paRAM slot usage when the channel mapping
>   is supported by the eDMA module.
>   On am335x we have 256 paRAM slots and 64 DMA channels, this means that we 
> had
>   64 slots 'locked away' all the time. The dynamic paRAM slot logic will allow
>   us to use all 256 slots freely for any purpose.
> 
> Changes since v1:
> - Convert edma platform device registration to use 
> platform_device_register_full
> - Moved the PM callback also to the dmaengine driver - missed in v1
> - Commit message added to:
>   ARM/dmaengine: edma: Remove limitation on the number of eDMA controllers
> - New patch which reads the flag for the channel mapping support in one place
> 
> Cover letter:
> 
> with this series the edma two driver setup will be changed to have only one
> driver to support eDMA3. The legacy edma interface will be removed and eDMA 
> can
> only be used via dmaengine API from this point on.
> In order to do the merge the following improvements has been done:
> - One driver instance per eDMA:
>  - Any number of eDMA instances are supported (both legacy and DT boot)
> - Not relying on global variables, arrays, etc
> - Code simplification and optimizations in several places
> 
> This change will also help us to do bigger changes in the eDMA driver since,
> since now we have only one driver to work with.
> 
> The series has been tested on:
> da850-evm (OMAP-L138)
> - with legacy and DT boot (both eDMA0 and eDMA1 is enabled)
> - In code swapping the eDMA instances in legacy mode to make sure the second
>   instance is handled correctly.
> 
> am335x-evmsk
> - DT boot
> 
> I think this series could go via the dmaengine tree. Changes are trivial under
> arch/arm/
> 
> Regards,
> Peter
> ---
> Peter Ujfalusi (25):
>   ARM: common: edma: Fix channel parameter for irq callbacks
>   ARM: common: edma: Remove unused functions
>   dmaengine: edma: Simplify and optimize the edma_execute path
>   ARM: davinci/common: Convert edma driver to handle one eDMA instance
> per driver
>   ARM/dmaengine: edma: Move of_dma_controller_register to the dmaengine
> driver
>   ARM: common: edma: Internal API to use pointer to 'struct edma'
>   ARM/dmaengine: edma: Public API to use private struct pointer
>   ARM/dmaengine: edma: Remove limitation on the number of eDMA
> controllers
>   ARM: davinci: Use platform_device_register_full() to create pdev for
> eDMA
>   ARM: davinci: Add dma_mask to eDMA devices
>   ARM/dmaengine: edma: Merge the two drivers under drivers/dma/
>   dmaengine: edma: Allocate memory dynamically for bitmaps and
> structures
>   dmaengine: edma: Parameter alignment and long line fixes
>   dmaengine: edma: Use devm_kcalloc when possible
>   dmaengine: edma: Cleanup regarding the use of dev around the code
>   dmaengine: edma: Use dev_dbg instead pr_debug
>   dmaengine: edma: Use the edma_write_slot instead open coded
> memcpy_toio
>   dmaengine: edma: Print warning when linking slots from different eDMA
>   dmaengine: edma: Consolidate the comments for functions
>   dmaengine: edma: Simplify the interrupt handling
>   dmaengine: edma: Move the pending error check into helper function
>   dmaengine: edma: Simplify and optimize ccerr interrupt handler
>   dmaengine: edma: Read channel mapping support only once from HW
>   dmaengine: edma: Rename bitfields for slot and channel usage tracking
>   dmaengine: edma: Dynamic paRAM slot handling if HW supports it
> 
>  arch/arm/Kconfig  |1 -
>  arch/arm/common/Kconfig   |3 -
>  arch/arm/common/Makefile  |1 -
>  arch/arm/common/edma.c| 1876 
> -
>  arch/arm/mach-davinci/devices-da8xx.c |  122 +--
>  arch/arm/mach-davinci/dm355.c |   40 +-
>  arch/arm/mach-davinci/dm365.c |   25 +-
>  arch/arm/mach-davinci/dm644x.c|   40 +-
>  arch/arm/mach-davinci/dm646x.c|   44 +-
>  arch/arm/mach-omap2/Kconfig   |1 -
>  drivers/dma/Kconfig   |1 -
>  drivers/dma/edma.c| 1569 ---
>  include/linux/platform_data/edma.h|  101 --
>  13 files changed, 1523 insertions(+), 2301 deletions(-)
>  delete mode 100644 arch/arm/common/edma.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

Re: [PATCH v4 00/25] dmaengine/ARM: Merge the edma drivers into one

[Koul, Vinod]

On Tue, 2015-10-06 at 09:15 +0300, Peter Ujfalusi wrote:
> Hi
> 
> On 09/24/2015 01:01 PM, Peter Ujfalusi wrote:
> > Hi,
> > 
> > Changes since v3:
> > - Separated the two (patch 10/11 in v2 patch 10 in v3) patch which got 
> > squashed
> >   by accident for v3
> > - Added Tony's Acked-by to patch 11 (for mach-oamp2 part)
> 
> Gentle ping on this series ;)

Its a long one :)

I hope to get this done next week after am back from Dublin

> 
-- 
~Vinod

Re: [PATCH] pwm: tipwmss: enable on TI DRA7x and AM437x

[Sekhar Nori]

On Monday 05 October 2015 08:50 PM, Thierry Reding wrote:
> On Tue, Sep 08, 2015 at 08:44:05PM +0530, Sekhar Nori wrote:
>> From: Vignesh R 
>>
>> TIPWMSS is present on TI's DRA7x and
>> AM437x SoCs. Enable its usage.
>>
>> Instead of adding each SoC individually,
>> use the more generic ARCH_OMAP2PLUS
>> instead.
>>
>> Signed-off-by: Vignesh R 
>> Signed-off-by: Sekhar Nori 
>> ---
>>  drivers/pwm/Kconfig | 6 +++---
>>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> Applied, thanks. In the future, try to make use of the 78 columns. There
> is no need to make lines as short as you did.

Alright.

Thanks,
Sekhar
--
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: All OMAP platforms: MMC is broken

[Russell King - ARM Linux]

On Wed, Oct 07, 2015 at 12:59:29AM +0530, Kishon Vijay Abraham I wrote:
> Hi,
> 
> On Tuesday 06 October 2015 08:37 PM, Russell King - ARM Linux wrote:
> > On Tue, Oct 06, 2015 at 04:06:09PM +0530, Kishon Vijay Abraham I wrote:
> >> Hi,
> >>
> >> On Tuesday 06 October 2015 03:41 PM, Ulf Hansson wrote:
> >>> On 6 October 2015 at 11:44, Tony Lindgren  wrote:
>  * Russell King - ARM Linux  [151006 02:04]:
> > On Mon, Oct 05, 2015 at 07:38:13PM +0100, Russell King - ARM Linux 
> > wrote:
> >> On Mon, Oct 05, 2015 at 10:11:56AM -0700, Tony Lindgren wrote:
> >>> * Tony Lindgren  [151005 07:57]:
>  * Tony Lindgren  [151005 07:44]:
> > * Tony Lindgren  [151005 04:28]:
> >
> > Based on some tests it seems that the duovero unpaired regulator 
> > usage
> > is fixed by reverting:
> >
> > c55d7a055364 ("mmc: host: omap_hsmmc: use regulator_is_enabled to
> > find pbias status")
> 
>  With commit c55d7a055364 my guess is that the PBIAS regulator is
>  already on from an earlier MMC probe and getting re-enabled when
>  a deferred probe happens?
> >>>
> >>> Unless somebody has a better fix in mind for the above, I suggest
> >>> we revert it for the -rc kernel.
> >>
> >> Let me try reverting that in my build tree, and...
> >>
> > And it seems that omap3 legacy MMC is broken earlier in the
> > series with:
> >
> > 7d607f917008 ("mmc: host: omap_hsmmc: use
> > devm_regulator_get_optional() for vmmc")
> >
> > This one does not cleanly revert so have not yet tried reverting
> > it.
> 
>  And with commit 7d607f917008 I'm guessing we can't return anHi,
>  error if the PBIAS regulator does not exist as that's not there
>  for the legacy booting.
> >>>
> >>> For omap3 legacy booting, we keep getting -EPROBE_DEFER for
> >>> all the optional regulators.
> >>>
> >>> Something like the following might be the minimal fix for the -rc
> >>> cycle?
> >>
> >> applying this patch.  If that gets things going again, then we
> >> _definitely_ should get both of these to Linus ASAP.  The breakage
> >> has been around far too long already.
> >
> > Last night's build shows that this fixes the non-DT LDP3430 booting, but
> > DT-based LDP3430 and SDP4430 both remain broken for the same reason -
> > neither can find their SD cards.
> 
>  Hmm DT-based boot finds the MMC card for LDP, dmesg below from DT boot 
>  [1].
>  Looks like you're on on -rc4 and not -rc3. My guess is that MMC is not
>  working for you with DT-based booting because you don't seem to have
>  CONFIG_REGULATOR_PBIAS in your seed config for. Care to try enabling that
>  for both your omap3 and omap4 seed config files?
> 
> > We're at -rc4.  That means we're could be only three weeks away from 4.3
> > being released, and DT OMAP has yet to boot _once_ here.
> >
> > What I find *totally* unacceptable is the lack of reaction from the MMC
> > and TI people: it's just like "we'll break your crap, and we'll ignore
> > reports of regressions."  That is *not* acceptable in any shape or form,
> > and people who do this _should_ have their future patches ignored until
> > they demonstrate that they understand the need to not break stuff.
> >
> > I'm at the point of suggesting that there should be a moritorium on all
> > OMAP related development for 4.4: delay all development to 4.5, and have
> > 4.4 as a pure bug-fixing _only_ cycle for OMAP.  If 4.3 is released and
> > OMAP is still broken, then I don't think there's an option on that.
> >
> > Maybe the idea that development work won't hit mainline for another 4
> > months will help focus the minds on not breaking stuff and then ignoring
> > regression reports.
> 
>  I'm thinking along the same lines. In general, I do not and will not
>  apply any patches that are not fixes until all critical regressions are
>  out of the way. So not applying anything new for v4.4 until these MMC
>  regressions are fixed for v4.3.
> 
> >>>
> >>> Tony, Russell - just wanted to say thanks for putting a big effort in
> >>> fixing this. I was expecting support from Kishon, but I guess he's
> >>> busy.
> >>>
> >>> Unfortunate, I don't have any of the hardware that fails, otherwise I
> >>> would of course be helping out more. The only thing I can think of is
> >>> to revert the entire patchset I picked up for 4.3 from Kishon for the
> >>> omap_hsmmc driver, but then I am not sure if that would cause other
> >>> issues...
> >>
> >> Please don't do that as that will just mask lot of bugs in the
> >> devicetree and might get MMC working. Indeed I was busy 

[PATCH 2/2] memory: omap-gpmc: expand the description of the debug facility

[Uwe Kleine-König]

Most register values for the chip select setup depend on the frequency
of the fck clock.
So add a hint that the values setup by the bootloader might differ from
the right setup for Linux if the bootloader uses a different frequency.

Signed-off-by: Uwe Kleine-König 
---
 drivers/memory/Kconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig
index c6a644b22af4..1414dd53be57 100644
--- a/drivers/memory/Kconfig
+++ b/drivers/memory/Kconfig
@@ -64,6 +64,9 @@ config OMAP_GPMC_DEBUG
  Enables verbose debugging mostly to decode the bootloader provided
  timings. Enable this during development to configure devices
  connected to the GPMC bus.
+ Note that you cannot just tweak your device tree until the registers
+ setup by linux match what the bootloader did because that one might
+ use a different fck frequency influencing most register settings.
 
 config MVEBU_DEVBUS
bool "Marvell EBU Device Bus Controller"
-- 
2.6.0

--
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/2] memory: omap-gpmc: dump "before" state before first modification

[Uwe Kleine-König]

When gpmc_cs_show_timings is called in gpmc_cs_set_timings()
gpmc_cs_program_settings() was already run which modifies the CONFIG1
register. So to be more useful do the "before" dump earlier.

Signed-off-by: Uwe Kleine-König 
---
 drivers/memory/omap-gpmc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
index 32ac049f2bc4..6515dfc2b805 100644
--- a/drivers/memory/omap-gpmc.c
+++ b/drivers/memory/omap-gpmc.c
@@ -696,7 +696,6 @@ int gpmc_cs_set_timings(int cs, const struct gpmc_timings 
*t,
int div;
u32 l;
 
-   gpmc_cs_show_timings(cs, "before gpmc_cs_set_timings");
div = gpmc_calc_divider(t->sync_clk);
if (div < 0)
return div;
@@ -1988,6 +1987,7 @@ static int gpmc_probe_generic_child(struct 
platform_device *pdev,
if (ret < 0)
goto err;
 
+   gpmc_cs_show_timings(cs, "before gpmc_cs_program_settings");
ret = gpmc_cs_program_settings(cs, _s);
if (ret < 0)
goto err;
-- 
2.6.0

--
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] genirq: export handle_bad_irq

[Arnd Bergmann]

A cleanup of the omap gpio driver introduced a use of the
handle_bad_irq() function in a device driver that can be
a loadable module.

This broke the ARM allmodconfig build:

ERROR: "handle_bad_irq" [drivers/gpio/gpio-omap.ko] undefined!

This patch exports the handle_bad_irq symbol in order to
allow the use in modules.

Signed-off-by: Arnd Bergmann 
Fixes: 450fa54cfd66 ("gpio: omap: convert to use generic irq handler")

diff --git a/kernel/irq/handle.c b/kernel/irq/handle.c
index ea7b5fd99ba5..142bbf3b607f 100644
--- a/kernel/irq/handle.c
+++ b/kernel/irq/handle.c
@@ -35,6 +35,7 @@ void handle_bad_irq(struct irq_desc *desc)
kstat_incr_irqs_this_cpu(desc);
ack_bad_irq(irq);
 }
+EXPORT_SYMBOL_GPL(handle_bad_irq);
 
 /*
  * Special, empty irq handler:

--
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] genirq: export handle_bad_irq

[kbuild test robot]

Hi Arnd,

[auto build test WARNING on v4.3-rc4 -- if it's inappropriate base, please 
ignore]

reproduce: make htmldocs

All warnings (new ones prefixed by >>):

   kernel/irq/handle.c:31: warning: Excess function parameter 'irq' description 
in 'handle_bad_irq'
>> kernel/irq/handle.c:1: warning: no structured comments found

vim +1 kernel/irq/handle.c

^1da177e Linus Torvalds 2005-04-16  @1  /*
^1da177e Linus Torvalds 2005-04-16   2   * linux/kernel/irq/handle.c
^1da177e Linus Torvalds 2005-04-16   3   *
a34db9b2 Ingo Molnar2006-06-29   4   * Copyright (C) 1992, 1998-2006 
Linus Torvalds, Ingo Molnar
a34db9b2 Ingo Molnar2006-06-29   5   * Copyright (C) 2005-2006, Thomas 
Gleixner, Russell King
^1da177e Linus Torvalds 2005-04-16   6   *
^1da177e Linus Torvalds 2005-04-16   7   * This file contains the core 
interrupt handling code.
a34db9b2 Ingo Molnar2006-06-29   8   *
a34db9b2 Ingo Molnar2006-06-29   9   * Detailed information is 
available in Documentation/DocBook/genericirq
a34db9b2 Ingo Molnar2006-06-29  10   *
^1da177e Linus Torvalds 2005-04-16  11   */
^1da177e Linus Torvalds 2005-04-16  12  
^1da177e Linus Torvalds 2005-04-16  13  #include 
^1da177e Linus Torvalds 2005-04-16  14  #include 
3795de23 Thomas Gleixner2010-09-22  15  #include 
^1da177e Linus Torvalds 2005-04-16  16  #include 
^1da177e Linus Torvalds 2005-04-16  17  #include 
3795de23 Thomas Gleixner2010-09-22  18  
ad8d75ff Steven Rostedt 2009-04-14  19  #include 
^1da177e Linus Torvalds 2005-04-16  20  
^1da177e Linus Torvalds 2005-04-16  21  #include "internals.h"
^1da177e Linus Torvalds 2005-04-16  22  
6a6de9ef Thomas Gleixner2006-06-29  23  /**
6a6de9ef Thomas Gleixner2006-06-29  24   * handle_bad_irq - handle spurious 
and unhandled irqs
43a1dd50 Henrik Kretzschmar 2006-08-31  25   * @irq:   the interrupt number
43a1dd50 Henrik Kretzschmar 2006-08-31  26   * @desc:  description of the 
interrupt
43a1dd50 Henrik Kretzschmar 2006-08-31  27   *
43a1dd50 Henrik Kretzschmar 2006-08-31  28   * Handles spurious and unhandled 
IRQ's. It also prints a debugmessage.
6a6de9ef Thomas Gleixner2006-06-29  29   */
bd0b9ac4 Thomas Gleixner2015-09-14  30  void handle_bad_irq(struct irq_desc 
*desc)
6a6de9ef Thomas Gleixner2006-06-29 @31  {
bd0b9ac4 Thomas Gleixner2015-09-14  32  unsigned int irq = 
irq_desc_get_irq(desc);
bd0b9ac4 Thomas Gleixner2015-09-14  33  
43f77759 Ingo Molnar2006-06-29  34  print_irq_desc(irq, desc);

:: The code at line 1 was first introduced by commit
:: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 Linux-2.6.12-rc2

:: TO: Linus Torvalds 
:: CC: Linus Torvalds 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

[PATCH] genirq: fix handle_bad_irq kerneldoc comment

[Arnd Bergmann]

A recent cleanup removed the 'irq' parameter from many functions, but
left the documentation for this in place for at least one function.

This removes it.

Signed-off-by: Arnd Bergmann 
Fixes: bd0b9ac405e1 ("genirq: Remove irq argument from irq flow handlers")
---
On Wednesday 07 October 2015 04:51:56 kbuild test robot wrote:
> [auto build test WARNING on v4.3-rc4 -- if it's inappropriate base, please 
> ignore]
> 
> reproduce: make htmldocs
> 
> All warnings (new ones prefixed by >>):
> 
>kernel/irq/handle.c:31: warning: Excess function parameter 'irq' 
> description in 'handle_bad_irq'
> >> kernel/irq/handle.c:1: warning: no structured comments found

This seems to be an unrelated bug, not sure why it wasn't caught earlier:

diff --git a/kernel/irq/handle.c b/kernel/irq/handle.c
index 142bbf3b607f..a302cf9a2126 100644
--- a/kernel/irq/handle.c
+++ b/kernel/irq/handle.c
@@ -22,7 +22,6 @@
 
 /**
  * handle_bad_irq - handle spurious and unhandled irqs
- * @irq:   the interrupt number
  * @desc:  description of the interrupt
  *
  * Handles spurious and unhandled IRQ's. It also prints a debugmessage.

--
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 3/4] ARM: dts: DRA7: Add timer12 node

[Tony Lindgren]

* Felipe Balbi  [151005 17:51]:
> 
> according to Tony we should avoid using status at all for in-SoC
> devices.
> 
> Tony, can you confirm I understood you correctly ?

Yes. With status = "disabled" kernel completely ignores the
device and struct device is not created at all even with the
device being there. In general we're better off trying to
probe the device and idle it.

The only time we really want to mark something with
status = "disabled" is if some coprocessor firmware is
using that device and the kernel should not touch it at
all.

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/PATCH 11/11] arm: boot: dts: omap: add missing default status for 32k counter

[Arnd Bergmann]

On Monday 05 October 2015 14:41:07 Felipe Balbi wrote:
> 
> /**
>  * omap_get_timer_dt - get a timer using device-tree
>  * @match   - device-tree match structure for matching a device type
>  * @property- optional timer property to match
>  *
>  * Helper function to get a timer during early boot using device-tree for use
>  * as kernel system timer. Optionally, the property argument can be used to
>  * select a timer with a specific property. Once a timer is found then mark
>  * the timer node in device-tree as disabled, to prevent the kernel from
>  * registering this timer as a platform device and so no one else can use it.
>  */
> static struct device_node * __init omap_get_timer_dt(const struct 
> of_device_id *match,
>  const char *property)
> {
> struct device_node *np;
> 
> for_each_matching_node(np, match) {
> if (!of_device_is_available(np))
> continue;
> 
> if (property && !of_get_property(np, property, NULL))
> continue;
> 
> if (!property && (of_get_property(np, "ti,timer-alwon", NULL) 
> ||
>   of_get_property(np, "ti,timer-dsp", NULL) ||
>   of_get_property(np, "ti,timer-pwm", NULL) ||
>   of_get_property(np, "ti,timer-secure", 
> NULL)))
> continue;
> 
> of_add_property(np, _disabled);
> return np;
> }
> 
> return NULL;
> }
> 
> I'll patch this up and drop $subject
> 

Ah, good.

I'm seeing the "ti,timer-alwon" property here, we probably need to take
that into account when setting the CLOCK_SOURCE_SUSPEND_NONSTOP flag, if
that isn't how it gets done already.

Arnd
--
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: timer: don't disable our timers

[Tony Lindgren]

* Felipe Balbi  [151005 18:02]:
> 
> Hi,
> 
> Sebastian Reichel  writes:
> > On Mon, Oct 05, 2015 at 06:41:37PM -0500, Suman Anna wrote:
> >> We will gain a user from OMAP remoteproc driver as well (out of tree at
> >> the moment, but it does follow the DT phandle and
> >> omap_dm_timer_request_by_node semantics). I do not think ir-rx51.c is
> >> converted to DT, and also some of the API are alive just because of the
> >> continued OMAP3 legacy boot support. Guess, it is a just a question of
> >> not breaking existing API until we kill some of them.
> >
> > Right, ir-rx51 has not yet been converted to DT. Additionally it
> > depends !ARCH_MULTIPLATFORM, since it requires .
> >
> > I remember a patchset adding a omap-pwm driver using dmtimers. If
> > that was added to the kernel, ir-rx51 could probably be switched to
> > the PWM API + hrtimer API instead of depending on the dmtimer API.
> > At the end not much is gained, though, since then the PWM driver
> > would probably require the dmtimer API.
> 
> Tony has been talking about an HRTimer API for some time, but I guess it
> didn't happen yet. Until then, cleanups will have to continue to cope
> with legacy users.

Yeh.. Well meanwhile, here's how we can easily support hardware
timers for pwm in a non-intrusive way:

1. We add irqchip support to gptimer code

2. We create omap-gptimer-pwm.c and pass hwtimer_get/set type
   function pointers in pdata to avoid exposing the gptimer
   custom functions to drivers until we have a hwtimer framework

3. Then omap-gptimer-pwm.c does request_irq on the hardware timer(s)
   configured in the board specific dts file to get the right timer

4. Then ir-rx51 can just use he Linux PWM API and omap-gptimer-pwm.c

5. We get rid of the pdata when we have a generic API available

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: All OMAP platforms: MMC is broken

[Russell King - ARM Linux]

On Mon, Oct 05, 2015 at 07:38:13PM +0100, Russell King - ARM Linux wrote:
> On Mon, Oct 05, 2015 at 10:11:56AM -0700, Tony Lindgren wrote:
> > * Tony Lindgren  [151005 07:57]:
> > > * Tony Lindgren  [151005 07:44]:
> > > > * Tony Lindgren  [151005 04:28]:
> > > > 
> > > > Based on some tests it seems that the duovero unpaired regulator usage
> > > > is fixed by reverting:
> > > > 
> > > > c55d7a055364 ("mmc: host: omap_hsmmc: use regulator_is_enabled to
> > > > find pbias status")
> > > 
> > > With commit c55d7a055364 my guess is that the PBIAS regulator is
> > > already on from an earlier MMC probe and getting re-enabled when
> > > a deferred probe happens?
> > 
> > Unless somebody has a better fix in mind for the above, I suggest
> > we revert it for the -rc kernel.
> 
> Let me try reverting that in my build tree, and...
> 
> > > > And it seems that omap3 legacy MMC is broken earlier in the
> > > > series with:
> > > > 
> > > > 7d607f917008 ("mmc: host: omap_hsmmc: use
> > > > devm_regulator_get_optional() for vmmc")
> > > > 
> > > > This one does not cleanly revert so have not yet tried reverting
> > > > it.
> > > 
> > > And with commit 7d607f917008 I'm guessing we can't return an
> > > error if the PBIAS regulator does not exist as that's not there
> > > for the legacy booting.
> > 
> > For omap3 legacy booting, we keep getting -EPROBE_DEFER for
> > all the optional regulators.
> > 
> > Something like the following might be the minimal fix for the -rc
> > cycle?
> 
> applying this patch.  If that gets things going again, then we
> _definitely_ should get both of these to Linus ASAP.  The breakage
> has been around far too long already.

Last night's build shows that this fixes the non-DT LDP3430 booting, but
DT-based LDP3430 and SDP4430 both remain broken for the same reason -
neither can find their SD cards.

We're at -rc4.  That means we're could be only three weeks away from 4.3
being released, and DT OMAP has yet to boot _once_ here.

What I find *totally* unacceptable is the lack of reaction from the MMC
and TI people: it's just like "we'll break your crap, and we'll ignore
reports of regressions."  That is *not* acceptable in any shape or form,
and people who do this _should_ have their future patches ignored until
they demonstrate that they understand the need to not break stuff.

I'm at the point of suggesting that there should be a moritorium on all
OMAP related development for 4.4: delay all development to 4.5, and have
4.4 as a pure bug-fixing _only_ cycle for OMAP.  If 4.3 is released and
OMAP is still broken, then I don't think there's an option on that.

Maybe the idea that development work won't hit mainline for another 4
months will help focus the minds on not breaking stuff and then ignoring
regression reports.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
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 3/3] mmc: omap: Fix module autoload for OF platform driver

[Tony Lindgren]

* Luis de Bethencourt  [150917 14:54]:
> This platform driver has a OF device ID table but the OF module
> alias information is not created so module autoloading won't work.
> 
> Signed-off-by: Luis de Bethencourt 

Looks OK to me, this would be mostly for n8x0:

Acked-by: Tony Lindgren 

> ---
>  drivers/mmc/host/omap.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/mmc/host/omap.c b/drivers/mmc/host/omap.c
> index b763b11..b9958a1 100644
> --- a/drivers/mmc/host/omap.c
> +++ b/drivers/mmc/host/omap.c
> @@ -1490,6 +1490,7 @@ static const struct of_device_id mmc_omap_match[] = {
>   { .compatible = "ti,omap2420-mmc", },
>   { },
>  };
> +MODULE_DEVICE_TABLE(of, mmc_omap_match);
>  #endif
>  
>  static struct platform_driver mmc_omap_driver = {
> -- 
> 2.4.6
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 
--
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: Use defined GPIO constants in flags cell for OMAP2+ boards

[Javier Martinez Canillas]

Many OMAP2+ DTS are not using the defined constants to express
the GPIO polarity. Replace these so the DTS are easier to read.

Signed-off-by: Javier Martinez Canillas 

---

 arch/arm/boot/dts/omap2420-n8x0-common.dtsi|  6 +++---
 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-lcd-common.dtsi |  2 +-
 arch/arm/boot/dts/omap3-evm-common.dtsi|  4 ++--
 arch/arm/boot/dts/omap3-gta04.dtsi | 10 +-
 arch/arm/boot/dts/omap3-gta04a5.dts|  2 +-
 arch/arm/boot/dts/omap3-ldp.dts|  2 +-
 arch/arm/boot/dts/omap3-lilly-a83x.dtsi|  2 +-
 arch/arm/boot/dts/omap3-lilly-dbb056.dts   |  4 ++--
 arch/arm/boot/dts/omap3-n950-n9.dtsi   |  2 +-
 arch/arm/boot/dts/omap3-overo-base.dtsi|  2 +-
 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-pandora-common.dtsi|  4 ++--
 arch/arm/boot/dts/omap3-tao3530.dtsi   |  4 ++--
 arch/arm/boot/dts/omap3-zoom3.dts  |  2 +-
 arch/arm/boot/dts/omap4-panda-common.dtsi  |  4 ++--
 arch/arm/boot/dts/omap4-sdp.dts|  6 +++---
 arch/arm/boot/dts/omap4-var-som-om44-wlan.dtsi |  2 +-
 arch/arm/boot/dts/omap4-var-som-om44.dtsi  |  2 +-
 arch/arm/boot/dts/omap4460.dtsi|  2 +-
 arch/arm/boot/dts/omap5-cm-t54.dts |  2 +-
 arch/arm/boot/dts/omap5-uevm.dts   |  2 +-
 25 files changed, 38 insertions(+), 38 deletions(-)

diff --git a/arch/arm/boot/dts/omap2420-n8x0-common.dtsi 
b/arch/arm/boot/dts/omap2420-n8x0-common.dtsi
index c9f1e93a95ae..8491f46c61b7 100644
--- a/arch/arm/boot/dts/omap2420-n8x0-common.dtsi
+++ b/arch/arm/boot/dts/omap2420-n8x0-common.dtsi
@@ -9,9 +9,9 @@
ocp {
i2c@0 {
compatible = "i2c-cbus-gpio";
-   gpios = < 2 0 /* gpio66 clk */
- 1 0 /* gpio65 dat */
- 0 0 /* gpio64 sel */
+   gpios = < 2 GPIO_ACTIVE_HIGH /* gpio66 clk */
+ 1 GPIO_ACTIVE_HIGH /* gpio65 dat */
+ 0 GPIO_ACTIVE_HIGH /* gpio64 sel */
>;
#address-cells = <1>;
#size-cells = <0>;
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts 
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index 7c4dca122a91..73f1e3a8f62c 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -80,7 +80,7 @@
regulator-name = "hsusb2_vbus";
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
-   gpio = <_gpio 18 0>;/* GPIO LEDA */
+   gpio = <_gpio 18 GPIO_ACTIVE_HIGH>; /* GPIO LEDA */
startup-delay-us = <7>;
};
 
diff --git a/arch/arm/boot/dts/omap3-beagle.dts 
b/arch/arm/boot/dts/omap3-beagle.dts
index 67659a0ed13e..274c2c482aaa 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -55,7 +55,7 @@
regulator-name = "hsusb2_vbus";
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
-   gpio = <_gpio 18 0>;/* GPIO LEDA */
+   gpio = <_gpio 18 GPIO_ACTIVE_HIGH>; /* GPIO LEDA */
startup-delay-us = <7>;
};
 
diff --git a/arch/arm/boot/dts/omap3-cm-t3x.dtsi 
b/arch/arm/boot/dts/omap3-cm-t3x.dtsi
index 4d091ca43e25..8c813e77b17f 100644
--- a/arch/arm/boot/dts/omap3-cm-t3x.dtsi
+++ b/arch/arm/boot/dts/omap3-cm-t3x.dtsi
@@ -224,7 +224,7 @@
 
interrupt-parent = <>;
interrupts = <25 0>;/* gpio_57 */
-   pendown-gpio = < 25 0>;
+   pendown-gpio = < 25 GPIO_ACTIVE_HIGH>;
 
ti,x-min = /bits/ 16 <0x0>;
ti,x-max = /bits/ 16 <0x0fff>;
diff --git a/arch/arm/boot/dts/omap3-devkit8000-lcd-common.dtsi 
b/arch/arm/boot/dts/omap3-devkit8000-lcd-common.dtsi
index e84184de2a4a..4813e96157b3 100644
--- a/arch/arm/boot/dts/omap3-devkit8000-lcd-common.dtsi
+++ b/arch/arm/boot/dts/omap3-devkit8000-lcd-common.dtsi
@@ -54,7 +54,7 @@
 
interrupt-parent = <>;
interrupts = <27 0>;/* gpio_27 */
-   pendown-gpio = < 27 0>;
+   pendown-gpio = < 27 GPIO_ACTIVE_HIGH>;
 
ti,x-min = /bits/ 16 <0x0>;
ti,x-max = /bits/ 16 <0x0fff>;
diff --git a/arch/arm/boot/dts/omap3-evm-common.dtsi 
b/arch/arm/boot/dts/omap3-evm-common.dtsi
index 

Re: [PATCH v2] arm: omap2: timer: don't disable our timers

[Tony Lindgren]

* Felipe Balbi  [151005 17:49]:
> We actually want these devices to be created because
> we will be moving timers to drivers/clocksource and
> this will prevent them from probing.

Great. Is this safe to appy on it's own? We are not getting
system timers re-inited to the default values?

> The only situation where we want secure timers to be
> actually disabled is when we *know* we're running on
> non-GP (read: HS or EMU) chips, because the secure
> timer will NOT be available for the public world.

Yup.

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 v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

[Tony Lindgren]

* Roger Quadros  [150930 04:04]:
> Tony,
> 
> On 18/09/15 17:53, Roger Quadros wrote:
> > Hi,
> > 
> > We do a couple of things in this series which result in
> > cleaner device tree implementation, faster perfomance and
> > multi-platform support. As an added bonus we get new GPI/Interrupt pins
> > for use in the system.
> > 
> > - Establish a custom interface between NAND and GPMC driver. This is
> > needed because all of the NAND registers sit in the GPMC register space.
> > Some bits like NAND IRQ are even shared with GPMC.
> > 
> > - Remove NAND IRQ handling from omap-gpmc driver, share the GPMC IRQ
> > with the omap2-nand driver and handle NAND IRQ events in the NAND driver.
> > This causes performance increase when using prefetch-irq mode.
> > 30% increase in read, 17% increase in write in prefetch-irq mode.
> > 
> > - Clean up device tree support so that omap-gpmc IP and the omap2 NAND
> > driver can be used on non-OMAP platforms. e.g. Keystone.
> > 
> > - Implement GPIOCHIP + IRQCHIP for the GPMC WAITPINS. SoCs can contain
> > 2 to 4 of these and most of them would be unused otherwise. It also
> > allows a cleaner implementation of NAND Ready pin status for the NAND 
> > driver.
> > 
> > - Implement GPIOlib based NAND ready pin checking for OMAP NAND driver.
> > 
> > This series is available at
> > g...@github.com:rogerq/linux.git
> > in branch
> > for-v4.4/gpmc-v3

In general, very nice work :)

> I've verified this series with the following boards
> -dra7-evm
> -am437x-gp-evm
> -am335x-evm
> -beagleboard-c4
> 
> For legacy boot I've checked only on beagleboard-c4.

Great.

Does build and boot and use NAND work throughtout the series?
Otherwise we'll have hard time bisecting anything..

> Test procedure was to read an existing ubifs partition,
> create a new one and read it back.
> 
> Need you to Ack if it looks good.
> Do you mind taking it via omap-soc once MTD maintainers ack their relevant 
> parts?

Sure. I'll try to do some testing on the series first too.

Can the dts changes be merged separtely? Otherwise we'll have
a dependency between dts branch and the GPMC/NAND changes.

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: dts: omap3-lilly-a83x: Don't use IRQ level flag for a GPIO

[Javier Martinez Canillas]

The card detect GPIO is using IRQ_TYPE_LEVEL_LOW in the GPIO flag cells
but this defined constant is meant to be used for a IRQ and not a GPIO.
So instead use GPIO_ACTIVE_LOW that seems to be the original intention.

Signed-off-by: Javier Martinez Canillas 

---

 arch/arm/boot/dts/omap3-lilly-a83x.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap3-lilly-a83x.dtsi 
b/arch/arm/boot/dts/omap3-lilly-a83x.dtsi
index 46f88f86a50b..57d7c93cc72b 100644
--- a/arch/arm/boot/dts/omap3-lilly-a83x.dtsi
+++ b/arch/arm/boot/dts/omap3-lilly-a83x.dtsi
@@ -284,7 +284,7 @@
 };
 
  {
-   cd-gpios = < 30 IRQ_TYPE_LEVEL_LOW>;
+   cd-gpios = < 30 GPIO_ACTIVE_LOW>;
cd-inverted;
vmmc-supply = <>;
bus-width = <4>;
-- 
2.4.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 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

[Roger Quadros]

On 06/10/15 11:33, Tony Lindgren wrote:
> * Roger Quadros  [150930 04:04]:
>> Tony,
>>
>> On 18/09/15 17:53, Roger Quadros wrote:
>>> Hi,
>>>
>>> We do a couple of things in this series which result in
>>> cleaner device tree implementation, faster perfomance and
>>> multi-platform support. As an added bonus we get new GPI/Interrupt pins
>>> for use in the system.
>>>
>>> - Establish a custom interface between NAND and GPMC driver. This is
>>> needed because all of the NAND registers sit in the GPMC register space.
>>> Some bits like NAND IRQ are even shared with GPMC.
>>>
>>> - Remove NAND IRQ handling from omap-gpmc driver, share the GPMC IRQ
>>> with the omap2-nand driver and handle NAND IRQ events in the NAND driver.
>>> This causes performance increase when using prefetch-irq mode.
>>> 30% increase in read, 17% increase in write in prefetch-irq mode.
>>>
>>> - Clean up device tree support so that omap-gpmc IP and the omap2 NAND
>>> driver can be used on non-OMAP platforms. e.g. Keystone.
>>>
>>> - Implement GPIOCHIP + IRQCHIP for the GPMC WAITPINS. SoCs can contain
>>> 2 to 4 of these and most of them would be unused otherwise. It also
>>> allows a cleaner implementation of NAND Ready pin status for the NAND 
>>> driver.
>>>
>>> - Implement GPIOlib based NAND ready pin checking for OMAP NAND driver.
>>>
>>> This series is available at
>>> g...@github.com:rogerq/linux.git
>>> in branch
>>> for-v4.4/gpmc-v3
> 
> In general, very nice work :)

Thanks :)

> 
>> I've verified this series with the following boards
>> -dra7-evm
>> -am437x-gp-evm
>> -am335x-evm
>> -beagleboard-c4
>>
>> For legacy boot I've checked only on beagleboard-c4.
> 
> Great.
> 
> Does build and boot and use NAND work throughtout the series?
> Otherwise we'll have hard time bisecting anything..

Yes it does with the following exceptions.

- Patch 7 "memory: omap-gpmc: Remove NAND IRQ code" breaks prefetch-irq mode
but none of the boards seem to be using it so it shouldn't break NAND on 
existing boards.
At patch 9 "mtd: nand: omap2: manage NAND interrupts" prefetch-irq mode is 
working again.
Do you want me to squash patches 7,8,9 so that pre-fetch irq is not broken at 
any point?

- Then at patch 11 "mtd: nand: omap: Clean up device tree support" we break 
NAND on all DT
boards as we expect NAND to be a real child node with compatible id. Simply 
applying the
DT patch at this point makes it work again.

> 
>> Test procedure was to read an existing ubifs partition,
>> create a new one and read it back.
>>
>> Need you to Ack if it looks good.
>> Do you mind taking it via omap-soc once MTD maintainers ack their relevant 
>> parts?
> 
> Sure. I'll try to do some testing on the series first too.
> 
Thanks.

> Can the dts changes be merged separtely? Otherwise we'll have
> a dependency between dts branch and the GPMC/NAND changes.

I'm afraid no. Patch 11 makes us incompatible with the old DT.

cheers,
-roger
--
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 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

[Tony Lindgren]

* Roger Quadros  [151006 02:59]:
> On 06/10/15 11:33, Tony Lindgren wrote:
> > Does build and boot and use NAND work throughtout the series?
> > Otherwise we'll have hard time bisecting anything..
> 
> Yes it does with the following exceptions.
> 
> - Patch 7 "memory: omap-gpmc: Remove NAND IRQ code" breaks prefetch-irq mode
> but none of the boards seem to be using it so it shouldn't break NAND on 
> existing boards.
> At patch 9 "mtd: nand: omap2: manage NAND interrupts" prefetch-irq mode is 
> working again.
> Do you want me to squash patches 7,8,9 so that pre-fetch irq is not broken at 
> any point?

OK, no that's fine, no need to squash them together then.

> - Then at patch 11 "mtd: nand: omap: Clean up device tree support" we break 
> NAND on all DT
> boards as we expect NAND to be a real child node with compatible id. Simply 
> applying the
> DT patch at this point makes it work again.

Hmm can we at least warn about incompatible DT entry when somebody boots
with an older dtb?

> >> Test procedure was to read an existing ubifs partition,
> >> create a new one and read it back.
> >>
> >> Need you to Ack if it looks good.
> >> Do you mind taking it via omap-soc once MTD maintainers ack their relevant 
> >> parts?
> > 
> > Sure. I'll try to do some testing on the series first too.
> > 
> Thanks.
> 
> > Can the dts changes be merged separtely? Otherwise we'll have
> > a dependency between dts branch and the GPMC/NAND changes.
> 
> I'm afraid no. Patch 11 makes us incompatible with the old DT.

OK. If we can warn about that, then the out of tree users will
have easier time to update their dts file.

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: All OMAP platforms: MMC is broken

[Ulf Hansson]

On 6 October 2015 at 11:44, Tony Lindgren  wrote:
> * Russell King - ARM Linux  [151006 02:04]:
>> On Mon, Oct 05, 2015 at 07:38:13PM +0100, Russell King - ARM Linux wrote:
>> > On Mon, Oct 05, 2015 at 10:11:56AM -0700, Tony Lindgren wrote:
>> > > * Tony Lindgren  [151005 07:57]:
>> > > > * Tony Lindgren  [151005 07:44]:
>> > > > > * Tony Lindgren  [151005 04:28]:
>> > > > >
>> > > > > Based on some tests it seems that the duovero unpaired regulator 
>> > > > > usage
>> > > > > is fixed by reverting:
>> > > > >
>> > > > > c55d7a055364 ("mmc: host: omap_hsmmc: use regulator_is_enabled to
>> > > > > find pbias status")
>> > > >
>> > > > With commit c55d7a055364 my guess is that the PBIAS regulator is
>> > > > already on from an earlier MMC probe and getting re-enabled when
>> > > > a deferred probe happens?
>> > >
>> > > Unless somebody has a better fix in mind for the above, I suggest
>> > > we revert it for the -rc kernel.
>> >
>> > Let me try reverting that in my build tree, and...
>> >
>> > > > > And it seems that omap3 legacy MMC is broken earlier in the
>> > > > > series with:
>> > > > >
>> > > > > 7d607f917008 ("mmc: host: omap_hsmmc: use
>> > > > > devm_regulator_get_optional() for vmmc")
>> > > > >
>> > > > > This one does not cleanly revert so have not yet tried reverting
>> > > > > it.
>> > > >
>> > > > And with commit 7d607f917008 I'm guessing we can't return an
>> > > > error if the PBIAS regulator does not exist as that's not there
>> > > > for the legacy booting.
>> > >
>> > > For omap3 legacy booting, we keep getting -EPROBE_DEFER for
>> > > all the optional regulators.
>> > >
>> > > Something like the following might be the minimal fix for the -rc
>> > > cycle?
>> >
>> > applying this patch.  If that gets things going again, then we
>> > _definitely_ should get both of these to Linus ASAP.  The breakage
>> > has been around far too long already.
>>
>> Last night's build shows that this fixes the non-DT LDP3430 booting, but
>> DT-based LDP3430 and SDP4430 both remain broken for the same reason -
>> neither can find their SD cards.
>
> Hmm DT-based boot finds the MMC card for LDP, dmesg below from DT boot [1].
> Looks like you're on on -rc4 and not -rc3. My guess is that MMC is not
> working for you with DT-based booting because you don't seem to have
> CONFIG_REGULATOR_PBIAS in your seed config for. Care to try enabling that
> for both your omap3 and omap4 seed config files?
>
>> We're at -rc4.  That means we're could be only three weeks away from 4.3
>> being released, and DT OMAP has yet to boot _once_ here.
>>
>> What I find *totally* unacceptable is the lack of reaction from the MMC
>> and TI people: it's just like "we'll break your crap, and we'll ignore
>> reports of regressions."  That is *not* acceptable in any shape or form,
>> and people who do this _should_ have their future patches ignored until
>> they demonstrate that they understand the need to not break stuff.
>>
>> I'm at the point of suggesting that there should be a moritorium on all
>> OMAP related development for 4.4: delay all development to 4.5, and have
>> 4.4 as a pure bug-fixing _only_ cycle for OMAP.  If 4.3 is released and
>> OMAP is still broken, then I don't think there's an option on that.
>>
>> Maybe the idea that development work won't hit mainline for another 4
>> months will help focus the minds on not breaking stuff and then ignoring
>> regression reports.
>
> I'm thinking along the same lines. In general, I do not and will not
> apply any patches that are not fixes until all critical regressions are
> out of the way. So not applying anything new for v4.4 until these MMC
> regressions are fixed for v4.3.
>

Tony, Russell - just wanted to say thanks for putting a big effort in
fixing this. I was expecting support from Kishon, but I guess he's
busy.

Unfortunate, I don't have any of the hardware that fails, otherwise I
would of course be helping out more. The only thing I can think of is
to revert the entire patchset I picked up for 4.3 from Kishon for the
omap_hsmmc driver, but then I am not sure if that would cause other
issues...

Kind regards
Uffe
--
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: All OMAP platforms: MMC is broken

[Tony Lindgren]

* Russell King - ARM Linux  [151006 02:04]:
> On Mon, Oct 05, 2015 at 07:38:13PM +0100, Russell King - ARM Linux wrote:
> > On Mon, Oct 05, 2015 at 10:11:56AM -0700, Tony Lindgren wrote:
> > > * Tony Lindgren  [151005 07:57]:
> > > > * Tony Lindgren  [151005 07:44]:
> > > > > * Tony Lindgren  [151005 04:28]:
> > > > > 
> > > > > Based on some tests it seems that the duovero unpaired regulator usage
> > > > > is fixed by reverting:
> > > > > 
> > > > > c55d7a055364 ("mmc: host: omap_hsmmc: use regulator_is_enabled to
> > > > > find pbias status")
> > > > 
> > > > With commit c55d7a055364 my guess is that the PBIAS regulator is
> > > > already on from an earlier MMC probe and getting re-enabled when
> > > > a deferred probe happens?
> > > 
> > > Unless somebody has a better fix in mind for the above, I suggest
> > > we revert it for the -rc kernel.
> > 
> > Let me try reverting that in my build tree, and...
> > 
> > > > > And it seems that omap3 legacy MMC is broken earlier in the
> > > > > series with:
> > > > > 
> > > > > 7d607f917008 ("mmc: host: omap_hsmmc: use
> > > > > devm_regulator_get_optional() for vmmc")
> > > > > 
> > > > > This one does not cleanly revert so have not yet tried reverting
> > > > > it.
> > > > 
> > > > And with commit 7d607f917008 I'm guessing we can't return an
> > > > error if the PBIAS regulator does not exist as that's not there
> > > > for the legacy booting.
> > > 
> > > For omap3 legacy booting, we keep getting -EPROBE_DEFER for
> > > all the optional regulators.
> > > 
> > > Something like the following might be the minimal fix for the -rc
> > > cycle?
> > 
> > applying this patch.  If that gets things going again, then we
> > _definitely_ should get both of these to Linus ASAP.  The breakage
> > has been around far too long already.
> 
> Last night's build shows that this fixes the non-DT LDP3430 booting, but
> DT-based LDP3430 and SDP4430 both remain broken for the same reason -
> neither can find their SD cards.

Hmm DT-based boot finds the MMC card for LDP, dmesg below from DT boot [1].
Looks like you're on on -rc4 and not -rc3. My guess is that MMC is not
working for you with DT-based booting because you don't seem to have
CONFIG_REGULATOR_PBIAS in your seed config for. Care to try enabling that
for both your omap3 and omap4 seed config files?

> We're at -rc4.  That means we're could be only three weeks away from 4.3
> being released, and DT OMAP has yet to boot _once_ here.
> 
> What I find *totally* unacceptable is the lack of reaction from the MMC
> and TI people: it's just like "we'll break your crap, and we'll ignore
> reports of regressions."  That is *not* acceptable in any shape or form,
> and people who do this _should_ have their future patches ignored until
> they demonstrate that they understand the need to not break stuff.
> 
> I'm at the point of suggesting that there should be a moritorium on all
> OMAP related development for 4.4: delay all development to 4.5, and have
> 4.4 as a pure bug-fixing _only_ cycle for OMAP.  If 4.3 is released and
> OMAP is still broken, then I don't think there's an option on that.
> 
> Maybe the idea that development work won't hit mainline for another 4
> months will help focus the minds on not breaking stuff and then ignoring
> regression reports.

I'm thinking along the same lines. In general, I do not and will not
apply any patches that are not fixes until all critical regressions are
out of the way. So not applying anything new for v4.4 until these MMC
regressions are fixed for v4.3.

Regards,

Tony

[1] http://muru.com/for-rmk/dmesg-ldp-v4.3-rc4-mmc-fixes.txt
--
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 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

[Roger Quadros]

On 06/10/15 13:00, Tony Lindgren wrote:
> * Roger Quadros  [151006 02:59]:
>> On 06/10/15 11:33, Tony Lindgren wrote:
>>> Does build and boot and use NAND work throughtout the series?
>>> Otherwise we'll have hard time bisecting anything..
>>
>> Yes it does with the following exceptions.
>>
>> - Patch 7 "memory: omap-gpmc: Remove NAND IRQ code" breaks prefetch-irq mode
>> but none of the boards seem to be using it so it shouldn't break NAND on 
>> existing boards.
>> At patch 9 "mtd: nand: omap2: manage NAND interrupts" prefetch-irq mode is 
>> working again.
>> Do you want me to squash patches 7,8,9 so that pre-fetch irq is not broken 
>> at any point?
> 
> OK, no that's fine, no need to squash them together then.
> 
>> - Then at patch 11 "mtd: nand: omap: Clean up device tree support" we break 
>> NAND on all DT
>> boards as we expect NAND to be a real child node with compatible id. Simply 
>> applying the
>> DT patch at this point makes it work again.
> 
> Hmm can we at least warn about incompatible DT entry when somebody boots
> with an older dtb?

Yes that could be done. It looks like we can use the missing compatible 
property to identify
that it is and old DT entry.

I'll send a v4 of patch 11.

cheers,
-roger


> 
 Test procedure was to read an existing ubifs partition,
 create a new one and read it back.

 Need you to Ack if it looks good.
 Do you mind taking it via omap-soc once MTD maintainers ack their relevant 
 parts?
>>>
>>> Sure. I'll try to do some testing on the series first too.
>>>
>> Thanks.
>>
>>> Can the dts changes be merged separtely? Otherwise we'll have
>>> a dependency between dts branch and the GPMC/NAND changes.
>>
>> I'm afraid no. Patch 11 makes us incompatible with the old DT.
> 
> OK. If we can warn about that, then the out of tree users will
> have easier time to update their dts file.
> 
> 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 09/11] clocksource: add TI 32.768 Hz counter driver

[Daniel Lezcano]

On 10/06/2015 07:02 PM, Felipe Balbi wrote:

Introduce a new clocksource driver for Texas
Instruments 32.768 Hz device which is available
on most OMAP-like devices.

Signed-off-by: Felipe Balbi 


Hi Felipe,

With the couple of nits below fixed, you can my:

Acked-by: Daniel Lezcano 

[ ... ]


+#define OMAP2_32KSYNCNT_REV_OFF0x0
+#define OMAP2_32KSYNCNT_REV_SCHEME (0x3 << 30)
+#define OMAP2_32KSYNCNT_CR_OFF_LOW 0x10
+#define OMAP2_32KSYNCNT_CR_OFF_HIGH0x30
+
+struct ti_32k {
+   void __iomem*base;
+   void __iomem*counter;
+   struct clocksource  cs;
+};
+#define to_ti_32k(cs)  (container_of((cs), struct ti_32k, cs))


Usually a static inline is used instead of a macro for that.


+static cycle_t ti_32k_read_cycles(struct clocksource *cs)
+{
+   struct ti_32k   *ti = to_ti_32k(cs);


format


--
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

--
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 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

[Roger Quadros]

On 06/10/15 13:05, Roger Quadros wrote:
> On 06/10/15 13:00, Tony Lindgren wrote:
>> * Roger Quadros  [151006 02:59]:
>>> On 06/10/15 11:33, Tony Lindgren wrote:
 Does build and boot and use NAND work throughtout the series?
 Otherwise we'll have hard time bisecting anything..
>>>
>>> Yes it does with the following exceptions.
>>>
>>> - Patch 7 "memory: omap-gpmc: Remove NAND IRQ code" breaks prefetch-irq mode
>>> but none of the boards seem to be using it so it shouldn't break NAND on 
>>> existing boards.
>>> At patch 9 "mtd: nand: omap2: manage NAND interrupts" prefetch-irq mode is 
>>> working again.
>>> Do you want me to squash patches 7,8,9 so that pre-fetch irq is not broken 
>>> at any point?
>>
>> OK, no that's fine, no need to squash them together then.
>>
>>> - Then at patch 11 "mtd: nand: omap: Clean up device tree support" we break 
>>> NAND on all DT
>>> boards as we expect NAND to be a real child node with compatible id. Simply 
>>> applying the
>>> DT patch at this point makes it work again.
>>
>> Hmm can we at least warn about incompatible DT entry when somebody boots
>> with an older dtb?
> 
> Yes that could be done. It looks like we can use the missing compatible 
> property to identify
> that it is and old DT entry.
> 
> I'll send a v4 of patch 11.

There is another issue. Some of the old DT nodes set the NAND IO address to 0.
As we prevent mapping into first 16MB we see the following message for those 
nodes. e.g. dra7-evm

[1.727598] omap-gpmc 5000.gpmc: cannot remap GPMC CS 0 to 0x
[1.727605] omap-gpmc 5000.gpmc: GPMC CS 0 start cannot be lesser than 
0x100
[1.727611] omap-gpmc 5000.gpmc: failed to probe DT children

Hope this is good enough information that DT needs to be updated?

cheers,
-roger
--
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 11/27] mtd: nand: omap: Clean up device tree support

[Roger Quadros]

Move NAND specific device tree parsing to NAND driver.

The NAND controller node must have a compatible id, register space
resource and interrupt resource.

Signed-off-by: Roger Quadros 
---
v4: Warn if using older incompatible DT i.e. compatible property not present
in nand node.

 arch/arm/mach-omap2/gpmc-nand.c  |   5 +-
 drivers/memory/omap-gpmc.c   | 143 +++
 drivers/mtd/nand/omap2.c | 136 +
 include/linux/platform_data/mtd-nand-omap2.h |   3 +-
 4 files changed, 155 insertions(+), 132 deletions(-)

diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index ffe646a..e07ca27 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -95,10 +95,7 @@ int gpmc_nand_init(struct omap_nand_platform_data 
*gpmc_nand_data,
gpmc_nand_res[1].start = gpmc_get_irq();
 
memset(, 0, sizeof(struct gpmc_settings));
-   if (gpmc_nand_data->of_node)
-   gpmc_read_settings_dt(gpmc_nand_data->of_node, );
-   else
-   gpmc_set_legacy(gpmc_nand_data, );
+   gpmc_set_legacy(gpmc_nand_data, );
 
s.device_nand = true;
 
diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
index e75226d..318c187 100644
--- a/drivers/memory/omap-gpmc.c
+++ b/drivers/memory/omap-gpmc.c
@@ -29,7 +29,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 #include 
@@ -1716,105 +1715,6 @@ static void __maybe_unused gpmc_read_timings_dt(struct 
device_node *np,
of_property_read_bool(np, "gpmc,time-para-granularity");
 }
 
-#if IS_ENABLED(CONFIG_MTD_NAND)
-
-static const char * const nand_xfer_types[] = {
-   [NAND_OMAP_PREFETCH_POLLED] = "prefetch-polled",
-   [NAND_OMAP_POLLED]  = "polled",
-   [NAND_OMAP_PREFETCH_DMA]= "prefetch-dma",
-   [NAND_OMAP_PREFETCH_IRQ]= "prefetch-irq",
-};
-
-static int gpmc_probe_nand_child(struct platform_device *pdev,
-struct device_node *child)
-{
-   u32 val;
-   const char *s;
-   struct gpmc_timings gpmc_t;
-   struct omap_nand_platform_data *gpmc_nand_data;
-
-   if (of_property_read_u32(child, "reg", ) < 0) {
-   dev_err(>dev, "%s has no 'reg' property\n",
-   child->full_name);
-   return -ENODEV;
-   }
-
-   gpmc_nand_data = devm_kzalloc(>dev, sizeof(*gpmc_nand_data),
- GFP_KERNEL);
-   if (!gpmc_nand_data)
-   return -ENOMEM;
-
-   gpmc_nand_data->cs = val;
-   gpmc_nand_data->of_node = child;
-
-   /* Detect availability of ELM module */
-   gpmc_nand_data->elm_of_node = of_parse_phandle(child, "ti,elm-id", 0);
-   if (gpmc_nand_data->elm_of_node == NULL)
-   gpmc_nand_data->elm_of_node =
-   of_parse_phandle(child, "elm_id", 0);
-
-   /* select ecc-scheme for NAND */
-   if (of_property_read_string(child, "ti,nand-ecc-opt", )) {
-   pr_err("%s: ti,nand-ecc-opt not found\n", __func__);
-   return -ENODEV;
-   }
-
-   if (!strcmp(s, "sw"))
-   gpmc_nand_data->ecc_opt = OMAP_ECC_HAM1_CODE_SW;
-   else if (!strcmp(s, "ham1") ||
-!strcmp(s, "hw") || !strcmp(s, "hw-romcode"))
-   gpmc_nand_data->ecc_opt =
-   OMAP_ECC_HAM1_CODE_HW;
-   else if (!strcmp(s, "bch4"))
-   if (gpmc_nand_data->elm_of_node)
-   gpmc_nand_data->ecc_opt =
-   OMAP_ECC_BCH4_CODE_HW;
-   else
-   gpmc_nand_data->ecc_opt =
-   OMAP_ECC_BCH4_CODE_HW_DETECTION_SW;
-   else if (!strcmp(s, "bch8"))
-   if (gpmc_nand_data->elm_of_node)
-   gpmc_nand_data->ecc_opt =
-   OMAP_ECC_BCH8_CODE_HW;
-   else
-   gpmc_nand_data->ecc_opt =
-   OMAP_ECC_BCH8_CODE_HW_DETECTION_SW;
-   else if (!strcmp(s, "bch16"))
-   if (gpmc_nand_data->elm_of_node)
-   gpmc_nand_data->ecc_opt =
-   OMAP_ECC_BCH16_CODE_HW;
-   else
-   pr_err("%s: BCH16 requires ELM support\n", __func__);
-   else
-   pr_err("%s: ti,nand-ecc-opt invalid value\n", __func__);
-
-   /* select data transfer mode for NAND controller */
-   if (!of_property_read_string(child, "ti,nand-xfer-type", ))
-   for (val = 0; val < ARRAY_SIZE(nand_xfer_types); val++)
-   if (!strcasecmp(s, nand_xfer_types[val])) {
-   gpmc_nand_data->xfer_type = val;
-   break;
-   }
-
- 

Re: All OMAP platforms: MMC is broken

[Kishon Vijay Abraham I]

Hi,

On Tuesday 06 October 2015 03:41 PM, Ulf Hansson wrote:
> On 6 October 2015 at 11:44, Tony Lindgren  wrote:
>> * Russell King - ARM Linux  [151006 02:04]:
>>> On Mon, Oct 05, 2015 at 07:38:13PM +0100, Russell King - ARM Linux wrote:
 On Mon, Oct 05, 2015 at 10:11:56AM -0700, Tony Lindgren wrote:
> * Tony Lindgren  [151005 07:57]:
>> * Tony Lindgren  [151005 07:44]:
>>> * Tony Lindgren  [151005 04:28]:
>>>
>>> Based on some tests it seems that the duovero unpaired regulator usage
>>> is fixed by reverting:
>>>
>>> c55d7a055364 ("mmc: host: omap_hsmmc: use regulator_is_enabled to
>>> find pbias status")
>>
>> With commit c55d7a055364 my guess is that the PBIAS regulator is
>> already on from an earlier MMC probe and getting re-enabled when
>> a deferred probe happens?
>
> Unless somebody has a better fix in mind for the above, I suggest
> we revert it for the -rc kernel.

 Let me try reverting that in my build tree, and...

>>> And it seems that omap3 legacy MMC is broken earlier in the
>>> series with:
>>>
>>> 7d607f917008 ("mmc: host: omap_hsmmc: use
>>> devm_regulator_get_optional() for vmmc")
>>>
>>> This one does not cleanly revert so have not yet tried reverting
>>> it.
>>
>> And with commit 7d607f917008 I'm guessing we can't return anHi,
>> error if the PBIAS regulator does not exist as that's not there
>> for the legacy booting.
>
> For omap3 legacy booting, we keep getting -EPROBE_DEFER for
> all the optional regulators.
>
> Something like the following might be the minimal fix for the -rc
> cycle?

 applying this patch.  If that gets things going again, then we
 _definitely_ should get both of these to Linus ASAP.  The breakage
 has been around far too long already.
>>>
>>> Last night's build shows that this fixes the non-DT LDP3430 booting, but
>>> DT-based LDP3430 and SDP4430 both remain broken for the same reason -
>>> neither can find their SD cards.
>>
>> Hmm DT-based boot finds the MMC card for LDP, dmesg below from DT boot [1].
>> Looks like you're on on -rc4 and not -rc3. My guess is that MMC is not
>> working for you with DT-based booting because you don't seem to have
>> CONFIG_REGULATOR_PBIAS in your seed config for. Care to try enabling that
>> for both your omap3 and omap4 seed config files?
>>
>>> We're at -rc4.  That means we're could be only three weeks away from 4.3
>>> being released, and DT OMAP has yet to boot _once_ here.
>>>
>>> What I find *totally* unacceptable is the lack of reaction from the MMC
>>> and TI people: it's just like "we'll break your crap, and we'll ignore
>>> reports of regressions."  That is *not* acceptable in any shape or form,
>>> and people who do this _should_ have their future patches ignored until
>>> they demonstrate that they understand the need to not break stuff.
>>>
>>> I'm at the point of suggesting that there should be a moritorium on all
>>> OMAP related development for 4.4: delay all development to 4.5, and have
>>> 4.4 as a pure bug-fixing _only_ cycle for OMAP.  If 4.3 is released and
>>> OMAP is still broken, then I don't think there's an option on that.
>>>
>>> Maybe the idea that development work won't hit mainline for another 4
>>> months will help focus the minds on not breaking stuff and then ignoring
>>> regression reports.
>>
>> I'm thinking along the same lines. In general, I do not and will not
>> apply any patches that are not fixes until all critical regressions are
>> out of the way. So not applying anything new for v4.4 until these MMC
>> regressions are fixed for v4.3.
>>
> 
> Tony, Russell - just wanted to say thanks for putting a big effort in
> fixing this. I was expecting support from Kishon, but I guess he's
> busy.
> 
> Unfortunate, I don't have any of the hardware that fails, otherwise I
> would of course be helping out more. The only thing I can think of is
> to revert the entire patchset I picked up for 4.3 from Kishon for the
> omap_hsmmc driver, but then I am not sure if that would cause other
> issues...

Please don't do that as that will just mask lot of bugs in the
devicetree and might get MMC working. Indeed I was busy but I'll try to
get this resolved asap. The 2 pending issues as far as I know

1) warn dump while enabling pbias regulator in duovero. As I mentioned
in some other thread it might be because the PBIAS regulator in 4430 is
not setting the status bit properly because of which we can't use the
regulator_is_enabled API to enable/disable the regulator. I don't think
there is any other way to fix this other than reverting c55d7a055364.

2) legacy booting is not working with OMAP3.
I'm not sure what is causing this. I'm right now in ELCE and will be
able to look at this on Friday when I'll be able to get hold of LDP3430.

I really didn't 

Re: [PATCH v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

[Tony Lindgren]

* Roger Quadros  [151006 03:32]:
> On 06/10/15 13:05, Roger Quadros wrote:
> > On 06/10/15 13:00, Tony Lindgren wrote:
> >> * Roger Quadros  [151006 02:59]:
> >>> On 06/10/15 11:33, Tony Lindgren wrote:
>  Does build and boot and use NAND work throughtout the series?
>  Otherwise we'll have hard time bisecting anything..
> >>>
> >>> Yes it does with the following exceptions.
> >>>
> >>> - Patch 7 "memory: omap-gpmc: Remove NAND IRQ code" breaks prefetch-irq 
> >>> mode
> >>> but none of the boards seem to be using it so it shouldn't break NAND on 
> >>> existing boards.
> >>> At patch 9 "mtd: nand: omap2: manage NAND interrupts" prefetch-irq mode 
> >>> is working again.
> >>> Do you want me to squash patches 7,8,9 so that pre-fetch irq is not 
> >>> broken at any point?
> >>
> >> OK, no that's fine, no need to squash them together then.
> >>
> >>> - Then at patch 11 "mtd: nand: omap: Clean up device tree support" we 
> >>> break NAND on all DT
> >>> boards as we expect NAND to be a real child node with compatible id. 
> >>> Simply applying the
> >>> DT patch at this point makes it work again.
> >>
> >> Hmm can we at least warn about incompatible DT entry when somebody boots
> >> with an older dtb?
> > 
> > Yes that could be done. It looks like we can use the missing compatible 
> > property to identify
> > that it is and old DT entry.
> > 
> > I'll send a v4 of patch 11.
> 
> There is another issue. Some of the old DT nodes set the NAND IO address to 0.
> As we prevent mapping into first 16MB we see the following message for those 
> nodes. e.g. dra7-evm
> 
> [1.727598] omap-gpmc 5000.gpmc: cannot remap GPMC CS 0 to 0x
> [1.727605] omap-gpmc 5000.gpmc: GPMC CS 0 start cannot be lesser than 
> 0x100
> [1.727611] omap-gpmc 5000.gpmc: failed to probe DT children
> 
> Hope this is good enough information that DT needs to be updated?

Yes I think that should allow users update the out of tree dts file
easily.

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 00/25] dmaengine/ARM: Merge the edma drivers into one

[Peter Ujfalusi]

On 10/06/2015 10:30 AM, Koul, Vinod wrote:
> On Tue, 2015-10-06 at 09:15 +0300, Peter Ujfalusi wrote:
>> Hi
>>
>> On 09/24/2015 01:01 PM, Peter Ujfalusi wrote:
>>> Hi,
>>>
>>> Changes since v3:
>>> - Separated the two (patch 10/11 in v2 patch 10 in v3) patch which got 
>>> squashed
>>>   by accident for v3
>>> - Added Tony's Acked-by to patch 11 (for mach-oamp2 part)
>>
>> Gentle ping on this series ;)
> 
> Its a long one :)

Yes, it is and I have already 7 mode on top of this series :o

> I hope to get this done next week after am back from Dublin

Sure, thank you,
Péter
--
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 RFC] ASoC: simple-card: Update clocks binding for simple-card DAI subnodes

[Mark Brown]

On Mon, Sep 28, 2015 at 09:49:35PM +0300, Jyri Sarha wrote:
> On 09/19/15 21:42, Mark Brown wrote:

> >What's the use case again?  Can we address this by converting the
> >relevant drivers to the clock API (or improving their clock API
> >support)?

> Sorry, I forgot to reply this earlier. The reason why we need this is the
> way McASP driver uses and provides clocks for different purposes. The most
> pressing need is to be able to select if we want to use some external clock
> pin as an input for McASP clock divider that produces the i2s bit-clock or
> if we want to use McASP's internal clock source.

> There are several other things this binding would allow us, and others with
> flexible i2s HW, to do. Some TI codecs would also benefit from a flexible
> way of describing the used clock configuration, but Peter know that part
> better.

> I tried to make the binding as flexible and generic as possible. But I do
> not currently see any immediate need for more than one set_sysclk() call per
> dai. I just did not see any reason to not allow it either.

This explains why you want to do this but what about the clock API
portion of the question - it would be good to move the ASoC clocking
more into the clock API, this would help integration with wider clock
trees.


signature.asc
Description: Digital signature

Re: [PATCH v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

[Roger Quadros]

On 06/10/15 14:01, Tony Lindgren wrote:
> * Roger Quadros  [151006 03:32]:
>> On 06/10/15 13:05, Roger Quadros wrote:
>>> On 06/10/15 13:00, Tony Lindgren wrote:
 * Roger Quadros  [151006 02:59]:
> On 06/10/15 11:33, Tony Lindgren wrote:
>> Does build and boot and use NAND work throughtout the series?
>> Otherwise we'll have hard time bisecting anything..
>
> Yes it does with the following exceptions.
>
> - Patch 7 "memory: omap-gpmc: Remove NAND IRQ code" breaks prefetch-irq 
> mode
> but none of the boards seem to be using it so it shouldn't break NAND on 
> existing boards.
> At patch 9 "mtd: nand: omap2: manage NAND interrupts" prefetch-irq mode 
> is working again.
> Do you want me to squash patches 7,8,9 so that pre-fetch irq is not 
> broken at any point?

 OK, no that's fine, no need to squash them together then.

> - Then at patch 11 "mtd: nand: omap: Clean up device tree support" we 
> break NAND on all DT
> boards as we expect NAND to be a real child node with compatible id. 
> Simply applying the
> DT patch at this point makes it work again.

 Hmm can we at least warn about incompatible DT entry when somebody boots
 with an older dtb?
>>>
>>> Yes that could be done. It looks like we can use the missing compatible 
>>> property to identify
>>> that it is and old DT entry.
>>>
>>> I'll send a v4 of patch 11.
>>
>> There is another issue. Some of the old DT nodes set the NAND IO address to 
>> 0.
>> As we prevent mapping into first 16MB we see the following message for those 
>> nodes. e.g. dra7-evm
>>
>> [1.727598] omap-gpmc 5000.gpmc: cannot remap GPMC CS 0 to 0x
>> [1.727605] omap-gpmc 5000.gpmc: GPMC CS 0 start cannot be lesser 
>> than 0x100
>> [1.727611] omap-gpmc 5000.gpmc: failed to probe DT children
>>
>> Hope this is good enough information that DT needs to be updated?
> 
> Yes I think that should allow users update the out of tree dts file
> easily.

Fine. The updated series is now at

g...@github.com:rogerq/linux.git
 * [new branch]  for-v4.4/gpmc-v4

cheers,
-roger
--
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 0/7] ARM: OMAP2+: support for DT based pwrdm/clkdm data

[Tony Lindgren]

* Tero Kristo  [150814 05:36]:
> 
> Basically the question with this set is, whether the DT node layout /
> compatible string arrangement looks sane or not. Some of the compatibles
> can be squashed together especially at clkdm data side, seeing the
> remaining stub data portions are rather minimal. They could also just be
> retained just in case we need to tweak something later

Well does this play along with the genpd? Let's assume that within
a few merge cycles we have proper s3220 interconnect driver for
each L4 instance along the lines of simple-pm-bus ;)

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: cpufreq-dt error: failed to init cpufreq table: -61

[Felipe Balbi]

Hi,

Belisko Marek  writes:
> Hi Tony,
>
> I'm using custom am33xx board where mpu voltage can be changed through
> gpio regulator on 4.1 (latest stable) kernel. I defined gpio-regulator
> node and also operating-points to DT. Gpio regulator seems to be
> working fine but during probing cpufreq-dt I get error:
> failed to init cpufreq table: -61
>
> I did small investigation and seem that dev_pm_opp_init_cpufreq_table
> fails at first condition dev_pm_opp_get_opp_count <= 0 and this is
> because opp_list is empty. So it seems that any opp for am33xx aren't
> defined if I'm getting it right. I did look to mach-omap2/opp3xxx_data
> but there is nothing am33xx specific. It is known problem or exist
> some patches around to fix that? Many thanks.

OPP initialization is not in mainline yet, there are some out-of-tree
patches which TI has been working on. If you want to use them, have a
look at TI's vendor kernel at [1]

[1] 
http://git.ti.com/ti-linux-kernel/ti-linux-kernel/blobs/ti-lsk-linux-4.1.y/arch/arm/mach-omap2/opp33xx_data.c

-- 
balbi


signature.asc
Description: PGP signature

Re: cpufreq-dt error: failed to init cpufreq table: -61

[Belisko Marek]

Hi Felipe,

On Tue, Oct 6, 2015 at 4:00 PM, Felipe Balbi  wrote:
>
> Hi,
>
> Belisko Marek  writes:
>> Hi Tony,
>>
>> I'm using custom am33xx board where mpu voltage can be changed through
>> gpio regulator on 4.1 (latest stable) kernel. I defined gpio-regulator
>> node and also operating-points to DT. Gpio regulator seems to be
>> working fine but during probing cpufreq-dt I get error:
>> failed to init cpufreq table: -61
>>
>> I did small investigation and seem that dev_pm_opp_init_cpufreq_table
>> fails at first condition dev_pm_opp_get_opp_count <= 0 and this is
>> because opp_list is empty. So it seems that any opp for am33xx aren't
>> defined if I'm getting it right. I did look to mach-omap2/opp3xxx_data
>> but there is nothing am33xx specific. It is known problem or exist
>> some patches around to fix that? Many thanks.
>
> OPP initialization is not in mainline yet, there are some out-of-tree
> patches which TI has been working on. If you want to use them, have a
> look at TI's vendor kernel at [1]
Thanks for link. One thing which is still not puzzled before I use 3.9
kernel and it was working fine
it's stops working when bumped to 4.1.
>
> [1] 
> http://git.ti.com/ti-linux-kernel/ti-linux-kernel/blobs/ti-lsk-linux-4.1.y/arch/arm/mach-omap2/opp33xx_data.c
>
> --
> balbi

BR,

marek

-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.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] memory: omap-gpmc: Fix unselectable debug option for GPMC

[Tony Lindgren]

Commit 63aa945b1013 ("memory: omap-gpmc: Add Kconfig option for debug")
added a debug option for GPMC, but somehow managed to keep it unselectable.

This probably happened because I had some uncommitted changes and the
GPMC option is selected in the platform specific Kconfig.

Let's also update the description a bit, it does not mention that
enabling the debug option also disables the reset of GPMC controller
during the init as pointed out by Uwe Kleine-König
.

Fixes: 63aa945b1013 ("memory: omap-gpmc: Add Kconfig option for debug")
Reported-by: Uwe Kleine-König 
Signed-off-by: Tony Lindgren 
---
 drivers/memory/Kconfig | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

--- a/drivers/memory/Kconfig
+++ b/drivers/memory/Kconfig
@@ -58,12 +58,13 @@ config OMAP_GPMC
  memory drives like NOR, NAND, OneNAND, SRAM.
 
 config OMAP_GPMC_DEBUG
-   bool
+   bool "Enable GPMC debug output and skip reset of GPMC during init"
depends on OMAP_GPMC
help
  Enables verbose debugging mostly to decode the bootloader provided
- timings. Enable this during development to configure devices
- connected to the GPMC bus.
+ timings. To preserve the bootloader provided timings, the reset
+ of GPMC is skipped during init. Enable this during development to
+ configure devices connected to the GPMC bus.
 
 config MVEBU_DEVBUS
bool "Marvell EBU Device Bus Controller"
-- 
2.1.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: [RFC 0/7] ARM: OMAP2+: support for DT based pwrdm/clkdm data

[Tero Kristo]

On 10/06/2015 03:09 PM, Tony Lindgren wrote:

* Tero Kristo  [150814 05:36]:


Basically the question with this set is, whether the DT node layout /
compatible string arrangement looks sane or not. Some of the compatibles
can be squashed together especially at clkdm data side, seeing the
remaining stub data portions are rather minimal. They could also just be
retained just in case we need to tweak something later


Well does this play along with the genpd? Let's assume that within
a few merge cycles we have proper s3220 interconnect driver for
each L4 instance along the lines of simple-pm-bus ;)


I guess the question is what shall we represent under genpd. This series 
represents/registers each clockdomain / powerdomain as a single genpd 
entity (see patch #6, it adds the support for registering genpds.) If 
the plan is to represent also each hwmod device as a genpd entity, it 
should work fine I think, as each device can have a single clkdm as 
their parent.


Patch #6 is still missing support for actual control of the domains, the 
functions are just dummies. Hwmod should use genpd also instead of 
direct control of clkdms.


We could also add support for voltagedomains under genpd if required.

This RFC series is rather minimal in functionality still just to get 
some feedback of the approaches taken.


-Tero
--
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 01/17] ARM: OMAP2+: PRM: add support for reset controller

[Tony Lindgren]

* Tero Kristo  [150924 07:30]:
> PRM driver now supports reset controller for the defined reset lines.
> Reset configurations are provided through device tree. Later, functionality
> like hwmod and system reboot will be changed to use the generic framework.

This approach seems good to me in general. This should have the related
reset driver documentation too for the binding 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] memory: omap-gpmc: Fix unselectable debug option for GPMC

[Roger Quadros]

On 06/10/15 15:13, Tony Lindgren wrote:
> Commit 63aa945b1013 ("memory: omap-gpmc: Add Kconfig option for debug")
> added a debug option for GPMC, but somehow managed to keep it unselectable.
> 
> This probably happened because I had some uncommitted changes and the
> GPMC option is selected in the platform specific Kconfig.
> 
> Let's also update the description a bit, it does not mention that
> enabling the debug option also disables the reset of GPMC controller
> during the init as pointed out by Uwe Kleine-König
> .
> 
> Fixes: 63aa945b1013 ("memory: omap-gpmc: Add Kconfig option for debug")
> Reported-by: Uwe Kleine-König 
> Signed-off-by: Tony Lindgren 

Acked-by: Roger Quadros 

> ---
>  drivers/memory/Kconfig | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> --- a/drivers/memory/Kconfig
> +++ b/drivers/memory/Kconfig
> @@ -58,12 +58,13 @@ config OMAP_GPMC
> memory drives like NOR, NAND, OneNAND, SRAM.
>  
>  config OMAP_GPMC_DEBUG
> - bool
> + bool "Enable GPMC debug output and skip reset of GPMC during init"
>   depends on OMAP_GPMC
>   help
> Enables verbose debugging mostly to decode the bootloader provided
> -   timings. Enable this during development to configure devices
> -   connected to the GPMC bus.
> +   timings. To preserve the bootloader provided timings, the reset
> +   of GPMC is skipped during init. Enable this during development to
> +   configure devices connected to the GPMC bus.
>  
>  config MVEBU_DEVBUS
>   bool "Marvell EBU Device Bus Controller"
> 

--
cheers,
-roger
--
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

cpufreq-dt error: failed to init cpufreq table: -61

[Belisko Marek]

Hi Tony,

I'm using custom am33xx board where mpu voltage can be changed through
gpio regulator on 4.1 (latest stable) kernel. I defined gpio-regulator
node and also operating-points to DT. Gpio regulator seems to be
working fine but during probing cpufreq-dt I get error:
failed to init cpufreq table: -61

I did small investigation and seem that dev_pm_opp_init_cpufreq_table
fails at first condition dev_pm_opp_get_opp_count <= 0 and this is
because opp_list is empty. So it seems that any opp for am33xx aren't
defined if I'm getting it right. I did look to mach-omap2/opp3xxx_data
but there is nothing am33xx specific. It is known problem or exist
some patches around to fix that? Many thanks.

BR,

marek

-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.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: omap2: timer: don't disable our timers

[Suman Anna]

Hi Felipe,


 On 10/05/2015 02:48 PM, Balbi, Felipe wrote:
> We actually want these devices to be created because
> we will be moving timers to drivers/clocksource and
> this will prevent them from probing.

 This logic is also used to remove the secure timer from being
 registered to the kernel on HS devices, while allowing the timer to be
 available on GP devices. Your patch actually would break that
 functionality. I suggest that you look at the history of the code that
>>>
>>> heh, that's a silly way of doing so. Could just detect if we're running
>>> on HS or not.
>>
>> This function is invoked only after detecting that we are running on a
>> HS device.
> 
> What actually disables the timer is omap_get_timer_dt() and that's
> called in more than one place.

Yes indeed, and this patch is changing the behavior of
omap_get_timer_dt(), so you have to check all call-sites. Also, one
another thing is that this trick was used for DT boots so that the
timers used for clocksource and clockevent are eliminated from the
omap_dm_timer_request() API. The legacy boot used a specific API to mark
those as reserved so that the _request API does not give them out.
Granted that it may not have been the best approach, but that needs a
solution if you change the behavior of this API.

> 
 originally added this logic - this function seems to be designed to
 actually remove the node. The OMAP DMTimer provides an API to request
 timers, and I think this logic was used to eliminate giving out the
 timers used for clocksource and clockevent when the driver got adapted
 to DT.
>>>
>>> again not the best way of achieving what you want. In any case, other
>>> than ir-rx51.c who's using that API ? Seems like we could just pass a
>>> phandle to ir-rx51 and be done with it.
>>
>> We will gain a user from OMAP remoteproc driver as well (out of tree at
>> the moment, but it does follow the DT phandle and
>> omap_dm_timer_request_by_node semantics). I do not think ir-rx51.c is
>> converted to DT, and also some of the API are alive just because of the
>> continued OMAP3 legacy boot support. Guess, it is a just a question of
>> not breaking existing API until we kill some of them.
> 
> sure, but until remoteproc gets upstream, it's only 1 user ;-)
> 
> Signed-off-by: Felipe Balbi 
> ---
>
> Tony, I wonder if you can get merged as a fix, or do you
> prefer receiving it together with my timer series ?

 NAK for rc, as it breaks other stuff.
>>>
>>> a single stuff which is likely easy enough to fix. But fair enough
>>
>> Don't think this patch is fixing any critical bug either, better to club
>> it with your cleanup series.
> 
> it is kinda critical when you consider that the timer is disabled
> outside of the soc type detection.

This has been like this since DMTimer is converted to DT (from 3.8
kernel), and is a need for your counter32k clocksource series. The
problem seems to stem from the reuse of omap_get_timer_dt for counter32k
nodes. A better solution would be to remove the omap_get_timer_dt() from
omap2_sync32k_clocksource_init() code and just replace it with
of_find_compatible_node - you seem to be limiting the majority of that
function to legacy mode in Patch 10 of your RFC series anyways.

regards
Suman

--
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 02/11] arm: omap2: timer: add a gptimer argument to sync32k_timer_init()

[Felipe Balbi]

as it turns out, __omap_gptimer_init() and
__omap_sync32k_timer_init() are essentially
the same thing, but __omap_gptimer_init() wants
to always use gptimer.

Instead of forcing all those devices to pass
a use_gptimer cmdline argument, we add a new
function argument to __omap_sync32k_timer_init()
in preparation to deleting __omap_gptimer_init().

On a follow-up patch, we will remove uses of
__omap_gptimer_init() and replace them with
__omap_sync32k_timer_init() and pass the last
argument as true.

Signed-off-by: Felipe Balbi 
---
 arch/arm/mach-omap2/timer.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 23e58ea6a171..f53ed049d710 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -604,14 +604,14 @@ static void __init __omap_gptimer_init(int clkev_nr, 
const char *clkev_src,
 
 static void __init __omap_sync32k_timer_init(int clkev_nr, const char 
*clkev_src,
const char *clkev_prop, int clksrc_nr, const char *clksrc_src,
-   const char *clksrc_prop)
+   const char *clksrc_prop, bool gptimer)
 {
omap_clk_init();
omap_dmtimer_init();
omap2_gp_clockevent_init(clkev_nr, clkev_src, clkev_prop);
 
/* Enable the use of clocksource="gp_timer" kernel parameter */
-   if (use_gptimer_clksrc)
+   if (use_gptimer_clksrc || gptimer)
omap2_gptimer_clocksource_init(clksrc_nr, clksrc_src,
clksrc_prop);
else
@@ -622,7 +622,7 @@ static void __init __omap_sync32k_timer_init(int clkev_nr, 
const char *clkev_src
 void __init omap2_sync32k_timer_init(void)
 {
__omap_sync32k_timer_init(1, "timer_32k_ck", "ti,timer-alwon",
-   2, "timer_sys_ck", NULL);
+   2, "timer_sys_ck", NULL, false);
 }
 #endif /* CONFIG_ARCH_OMAP2 */
 
@@ -630,13 +630,13 @@ void __init omap2_sync32k_timer_init(void)
 void __init omap3_sync32k_timer_init(void)
 {
__omap_sync32k_timer_init(1, "timer_32k_ck", "ti,timer-alwon",
-   2, "timer_sys_ck", NULL);
+   2, "timer_sys_ck", NULL, false);
 }
 
 void __init omap3_secure_sync32k_timer_init(void)
 {
__omap_sync32k_timer_init(12, "secure_32k_fck", "ti,timer-secure",
-   2, "timer_sys_ck", NULL);
+   2, "timer_sys_ck", NULL, false);
 }
 #endif /* CONFIG_ARCH_OMAP3 */
 
@@ -653,7 +653,7 @@ void __init omap3_gptimer_timer_init(void)
 static void __init omap4_sync32k_timer_init(void)
 {
__omap_sync32k_timer_init(1, "timer_32k_ck", "ti,timer-alwon",
-  2, "sys_clkin_ck", NULL);
+   2, "sys_clkin_ck", NULL, false);
 }
 
 void __init omap4_local_timer_init(void)
-- 
2.5.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

[PATCH 11/11] arm: omap2: timer: limit hwmod usage to non-DT boots

[Felipe Balbi]

now that we have a working 32k clocksource driver,
we can limit HWMOD usage to non-DT boots and rely
on clocksource_of_init() every time we boot
with DT.

While at that, also make sure that we don't disable
the 32-counter device so it gets probed by its driver.

Signed-off-by: Felipe Balbi 
---
 arch/arm/mach-omap2/timer.c | 33 +
 1 file changed, 13 insertions(+), 20 deletions(-)

diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 01452cb190cb..7c1b13fee68f 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -183,7 +183,8 @@ static struct device_node * __init omap_get_timer_dt(const 
struct of_device_id *
  of_get_property(np, "ti,timer-secure", NULL)))
continue;
 
-   of_add_property(np, _disabled);
+   if (!of_device_is_compatible(np, "ti,omap-counter32k"))
+   of_add_property(np, _disabled);
return np;
}
 
@@ -394,7 +395,6 @@ static int __init __maybe_unused 
omap2_sync32k_clocksource_init(void)
int ret;
struct device_node *np = NULL;
struct omap_hwmod *oh;
-   void __iomem *vbase;
const char *oh_name = "counter_32k";
 
/*
@@ -420,18 +420,6 @@ static int __init __maybe_unused 
omap2_sync32k_clocksource_init(void)
 
omap_hwmod_setup_one(oh_name);
 
-   if (np) {
-   vbase = of_iomap(np, 0);
-   of_node_put(np);
-   } else {
-   vbase = omap_hwmod_get_mpu_rt_va(oh);
-   }
-
-   if (!vbase) {
-   pr_warn("%s: failed to get counter_32k resource\n", __func__);
-   return -ENXIO;
-   }
-
ret = omap_hwmod_enable(oh);
if (ret) {
pr_warn("%s: failed to enable counter_32k module (%d)\n",
@@ -439,13 +427,18 @@ static int __init __maybe_unused 
omap2_sync32k_clocksource_init(void)
return ret;
}
 
-   ret = omap_init_clocksource_32k(vbase);
-   if (ret) {
-   pr_warn("%s: failed to initialize counter_32k as a clocksource 
(%d)\n",
-   __func__, ret);
-   omap_hwmod_idle(oh);
-   }
+   if (!of_have_populated_dt()) {
+   void __iomem *vbase;
 
+   vbase = omap_hwmod_get_mpu_rt_va(oh);
+
+   ret = omap_init_clocksource_32k(vbase);
+   if (ret) {
+   pr_warn("%s: failed to initialize counter_32k as a 
clocksource (%d)\n",
+   __func__, ret);
+   omap_hwmod_idle(oh);
+   }
+   }
return ret;
 }
 
-- 
2.5.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] arm: omap2: timer: don't disable our timers

[Felipe Balbi]

Hi,

Suman Anna  writes:
> On 10/05/2015 02:48 PM, Balbi, Felipe wrote:
>> We actually want these devices to be created because
>> we will be moving timers to drivers/clocksource and
>> this will prevent them from probing.
>
> This logic is also used to remove the secure timer from being
> registered to the kernel on HS devices, while allowing the timer to be
> available on GP devices. Your patch actually would break that
> functionality. I suggest that you look at the history of the code that

 heh, that's a silly way of doing so. Could just detect if we're running
 on HS or not.
>>>
>>> This function is invoked only after detecting that we are running on a
>>> HS device.
>> 
>> What actually disables the timer is omap_get_timer_dt() and that's
>> called in more than one place.
>
> Yes indeed, and this patch is changing the behavior of
> omap_get_timer_dt(), so you have to check all call-sites. Also, one
> another thing is that this trick was used for DT boots so that the
> timers used for clocksource and clockevent are eliminated from the
> omap_dm_timer_request() API. The legacy boot used a specific API to mark
> those as reserved so that the _request API does not give them out.
> Granted that it may not have been the best approach, but that needs a
> solution if you change the behavior of this API.

no doubt this needs a solution, but seesm like a solution here will have
to be incremental. See new revision of my series. I'm now skipping 32k
only and keeping it enabled so drivers/clocksource/ can use it.

>> Signed-off-by: Felipe Balbi 
>> ---
>>
>> Tony, I wonder if you can get merged as a fix, or do you
>> prefer receiving it together with my timer series ?
>
> NAK for rc, as it breaks other stuff.

 a single stuff which is likely easy enough to fix. But fair enough
>>>
>>> Don't think this patch is fixing any critical bug either, better to club
>>> it with your cleanup series.
>> 
>> it is kinda critical when you consider that the timer is disabled
>> outside of the soc type detection.
>
> This has been like this since DMTimer is converted to DT (from 3.8
> kernel), and is a need for your counter32k clocksource series. The
> problem seems to stem from the reuse of omap_get_timer_dt for counter32k
> nodes. A better solution would be to remove the omap_get_timer_dt() from
> omap2_sync32k_clocksource_init() code and just replace it with
> of_find_compatible_node - you seem to be limiting the majority of that
> function to legacy mode in Patch 10 of your RFC series anyways.

I still need omap_hwmod_enable() to be called, that's why it's still
used. I don't think replacing it with of_find_compatible_node() will buy
us much, we will still need to check for of_device_is_available()
anyway. Sure we skip all the timer flags (alwon, dsp, pwm, secure), but
that really isn't big deal.

When converting gptimer to clocksource, then I'll look at what I can do
for the timer request side of things. For now, things are working,
apparently without regressions (or at least I couldn't catch any so far)
and it seems clean enough that it could possibly be queued for v4.4
merge window. For v4.5 I'll look at this again and try to figure out how
to handle gptimer.

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v2 3/4] ARM: dts: DRA7: Add timer12 node

[Suman Anna]

On 10/06/2015 02:52 AM, Tony Lindgren wrote:
> * Felipe Balbi  [151005 17:51]:
>>
>> according to Tony we should avoid using status at all for in-SoC
>> devices.
>>
>> Tony, can you confirm I understood you correctly ?
> 
> Yes. With status = "disabled" kernel completely ignores the
> device and struct device is not created at all even with the
> device being there. In general we're better off trying to
> probe the device and idle it.
> 
> The only time we really want to mark something with
> status = "disabled" is if some coprocessor firmware is
> using that device and the kernel should not touch it at
> all.

Not always, since some of the PM clocking logic depends on the state
machine variables within the kernel.

We are also using this to deal with paper-spins (atleast in the DRA7
case) and the DTS include model, wherein certain instances may not be
present on all variations of the SoC, and enabled specifically on the
instances that matter. Obviously, it could be done the other way too,
but as far as what Nishanth mentioned sometime back, we are following
the former for DRA7.

In anycase, the status property on the Timer12 node can be removed, it
doesn't fall into the above category, and we are fixing it up properly
on HS devices in the kernel.

regards
Suman

--
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: cpufreq-dt error: failed to init cpufreq table: -61

[Felipe Balbi]

Felipe Balbi  writes:

> Belisko Marek  writes:
>
>> Hi,
>>
>> On Tue, Oct 6, 2015 at 4:03 PM, Belisko Marek  
>> wrote:
>>> Hi Felipe,
>>>
>>> On Tue, Oct 6, 2015 at 4:00 PM, Felipe Balbi  wrote:

 Hi,

 Belisko Marek  writes:
> Hi Tony,
>
> I'm using custom am33xx board where mpu voltage can be changed through
> gpio regulator on 4.1 (latest stable) kernel. I defined gpio-regulator
> node and also operating-points to DT. Gpio regulator seems to be
> working fine but during probing cpufreq-dt I get error:
> failed to init cpufreq table: -61
>
> I did small investigation and seem that dev_pm_opp_init_cpufreq_table
> fails at first condition dev_pm_opp_get_opp_count <= 0 and this is
> because opp_list is empty. So it seems that any opp for am33xx aren't
> defined if I'm getting it right. I did look to mach-omap2/opp3xxx_data
> but there is nothing am33xx specific. It is known problem or exist
> some patches around to fix that? Many thanks.

 OPP initialization is not in mainline yet, there are some out-of-tree
 patches which TI has been working on. If you want to use them, have a
 look at TI's vendor kernel at [1]
>>> Thanks for link. One thing which is still not puzzled before I use 3.9
>>> kernel and it was working fine
>>> it's stops working when bumped to 4.1.
>>
>> Sorry information was incorrect. On 3.9 kernel we did use tps, pmic
>> now we have only gpio regulator so this is the difference.
>
> okay, if it's only a regulator how can you set different voltages ?
   ^
   GPIO, rather


> Seems like you won't be able to do anything more than enable/disable a
> voltage rail.
>
> -- 
> balbi

-- 
balbi


signature.asc
Description: PGP signature

[PATCH 08/11] arm: omap2: timer: rename omap_sync32k_timer_init()

[Felipe Balbi]

this function is not only about the 32k sync
timer, it's OMAP's generic init_time implementation.

Let's rename it to make that detail easier to
notice.

Signed-off-by: Felipe Balbi 
---
 arch/arm/mach-omap2/board-generic.c | 14 +++---
 arch/arm/mach-omap2/board-ldp.c |  2 +-
 arch/arm/mach-omap2/board-rx51.c|  2 +-
 arch/arm/mach-omap2/common.h|  2 +-
 arch/arm/mach-omap2/timer.c |  4 ++--
 5 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/arch/arm/mach-omap2/board-generic.c 
b/arch/arm/mach-omap2/board-generic.c
index 20d5e82ab6ee..e51fb8245704 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -46,7 +46,7 @@ DT_MACHINE_START(OMAP242X_DT, "Generic OMAP2420 (Flattened 
Device Tree)")
.map_io = omap242x_map_io,
.init_early = omap2420_init_early,
.init_machine   = omap_generic_init,
-   .init_time  = omap_sync32k_timer_init,
+   .init_time  = omap_init_time,
.dt_compat  = omap242x_boards_compat,
.restart= omap2xxx_restart,
 MACHINE_END
@@ -63,7 +63,7 @@ DT_MACHINE_START(OMAP243X_DT, "Generic OMAP2430 (Flattened 
Device Tree)")
.map_io = omap243x_map_io,
.init_early = omap2430_init_early,
.init_machine   = omap_generic_init,
-   .init_time  = omap_sync32k_timer_init,
+   .init_time  = omap_init_time,
.dt_compat  = omap243x_boards_compat,
.restart= omap2xxx_restart,
 MACHINE_END
@@ -82,7 +82,7 @@ DT_MACHINE_START(OMAP3_N900_DT, "Nokia RX-51 board")
.init_early = omap3430_init_early,
.init_machine   = omap_generic_init,
.init_late  = omap3_init_late,
-   .init_time  = omap_sync32k_timer_init,
+   .init_time  = omap_init_time,
.dt_compat  = n900_boards_compat,
.restart= omap3xxx_restart,
 MACHINE_END
@@ -100,7 +100,7 @@ DT_MACHINE_START(OMAP3_DT, "Generic OMAP3 (Flattened Device 
Tree)")
.init_early = omap3430_init_early,
.init_machine   = omap_generic_init,
.init_late  = omap3_init_late,
-   .init_time  = omap_sync32k_timer_init,
+   .init_time  = omap_init_time,
.dt_compat  = omap3_boards_compat,
.restart= omap3xxx_restart,
 MACHINE_END
@@ -116,7 +116,7 @@ DT_MACHINE_START(OMAP36XX_DT, "Generic OMAP36xx (Flattened 
Device Tree)")
.init_early = omap3630_init_early,
.init_machine   = omap_generic_init,
.init_late  = omap3_init_late,
-   .init_time  = omap_sync32k_timer_init,
+   .init_time  = omap_init_time,
.dt_compat  = omap36xx_boards_compat,
.restart= omap3xxx_restart,
 MACHINE_END
@@ -228,7 +228,7 @@ DT_MACHINE_START(OMAP4_DT, "Generic OMAP4 (Flattened Device 
Tree)")
.init_irq   = omap_gic_of_init,
.init_machine   = omap_generic_init,
.init_late  = omap4430_init_late,
-   .init_time  = omap_sync32k_timer_init,
+   .init_time  = omap_init_time,
.dt_compat  = omap4_boards_compat,
.restart= omap44xx_restart,
 MACHINE_END
@@ -272,7 +272,7 @@ DT_MACHINE_START(AM43_DT, "Generic AM43 (Flattened Device 
Tree)")
.init_late  = am43xx_init_late,
.init_irq   = omap_gic_of_init,
.init_machine   = omap_generic_init,
-   .init_time  = omap_sync32k_timer_init,
+   .init_time  = omap_init_time,
.dt_compat  = am43_boards_compat,
.restart= omap44xx_restart,
 MACHINE_END
diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-ldp.c
index 0d3a57c6931f..d9c3ffc39329 100644
--- a/arch/arm/mach-omap2/board-ldp.c
+++ b/arch/arm/mach-omap2/board-ldp.c
@@ -424,6 +424,6 @@ MACHINE_START(OMAP_LDP, "OMAP LDP board")
.init_irq   = omap3_init_irq,
.init_machine   = omap_ldp_init,
.init_late  = omap3430_init_late,
-   .init_time  = omap_sync32k_timer_init,
+   .init_time  = omap_init_time,
.restart= omap3xxx_restart,
 MACHINE_END
diff --git a/arch/arm/mach-omap2/board-rx51.c b/arch/arm/mach-omap2/board-rx51.c
index 830256c434ec..41161ca97d74 100644
--- a/arch/arm/mach-omap2/board-rx51.c
+++ b/arch/arm/mach-omap2/board-rx51.c
@@ -136,6 +136,6 @@ MACHINE_START(NOKIA_RX51, "Nokia RX-51 board")
.init_irq   = omap3_init_irq,
.init_machine   = rx51_init,
.init_late  = omap3430_init_late,
-   .init_time  = omap_sync32k_timer_init,
+   .init_time  = omap_init_time,
.restart= omap3xxx_restart,
 MACHINE_END
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index bf42fc4e78f4..e1e274334290 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -88,7 +88,7 @@ static inline int omap_mux_late_init(void)
 
 extern void 

[PATCH 05/11] arm: omap2: timer: move realtime_counter_init() around

[Felipe Balbi]

no functional changes, just moving that function
closer to its calling location.

Signed-off-by: Felipe Balbi 
---
 arch/arm/mach-omap2/timer.c | 102 ++--
 1 file changed, 50 insertions(+), 52 deletions(-)

diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index d14e25b2d7a4..dcc0f032e717 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -476,7 +476,55 @@ static void __init omap2_gptimer_clocksource_init(int 
gptimer_id,
clocksource_gpt.name, clksrc.rate);
 }
 
-#ifdef CONFIG_SOC_HAS_REALTIME_COUNTER
+static void __init __omap_sync32k_timer_init(int clkev_nr, const char 
*clkev_src,
+   const char *clkev_prop, int clksrc_nr, const char *clksrc_src,
+   const char *clksrc_prop, bool gptimer)
+{
+   omap_clk_init();
+   omap_dmtimer_init();
+   omap2_gp_clockevent_init(clkev_nr, clkev_src, clkev_prop);
+
+   /* Enable the use of clocksource="gp_timer" kernel parameter */
+   if (use_gptimer_clksrc || gptimer)
+   omap2_gptimer_clocksource_init(clksrc_nr, clksrc_src,
+   clksrc_prop);
+   else
+   omap2_sync32k_clocksource_init();
+}
+
+void __init omap_sync32k_timer_init(void)
+{
+   __omap_sync32k_timer_init(1, "timer_32k_ck", "ti,timer-alwon",
+   2, "timer_sys_ck", NULL, false);
+}
+
+#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_SOC_AM43XX)
+void __init omap3_secure_sync32k_timer_init(void)
+{
+   __omap_sync32k_timer_init(12, "secure_32k_fck", "ti,timer-secure",
+   2, "timer_sys_ck", NULL, false);
+}
+#endif /* CONFIG_ARCH_OMAP3 */
+
+#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_SOC_AM33XX)
+void __init omap3_gptimer_timer_init(void)
+{
+   __omap_sync32k_timer_init(2, "timer_sys_ck", NULL,
+   1, "timer_sys_ck", "ti,timer-alwon", true);
+}
+#endif
+
+#if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5) || \
+   defined(CONFIG_SOC_DRA7XX) || defined(CONFIG_SOC_AM43XX)
+void __init omap4_local_timer_init(void)
+{
+   omap_sync32k_timer_init();
+   clocksource_of_init();
+}
+#endif
+
+#if defined(CONFIG_SOC_OMAP5) || defined(CONFIG_SOC_DRA7XX)
+
 /*
  * The realtime counter also called master counter, is a free-running
  * counter, which is related to real time. It produces the count used
@@ -488,6 +536,7 @@ static void __init omap2_gptimer_clocksource_init(int 
gptimer_id,
  */
 static void __init realtime_counter_init(void)
 {
+#ifdef CONFIG_SOC_HAS_REALTIME_COUNTER
void __iomem *base;
static struct clk *sys_clk;
unsigned long rate;
@@ -586,60 +635,9 @@ sysclk1_based:
set_cntfreq();
 
iounmap(base);
-}
-#else
-static inline void __init realtime_counter_init(void)
-{}
 #endif
-
-static void __init __omap_sync32k_timer_init(int clkev_nr, const char 
*clkev_src,
-   const char *clkev_prop, int clksrc_nr, const char *clksrc_src,
-   const char *clksrc_prop, bool gptimer)
-{
-   omap_clk_init();
-   omap_dmtimer_init();
-   omap2_gp_clockevent_init(clkev_nr, clkev_src, clkev_prop);
-
-   /* Enable the use of clocksource="gp_timer" kernel parameter */
-   if (use_gptimer_clksrc || gptimer)
-   omap2_gptimer_clocksource_init(clksrc_nr, clksrc_src,
-   clksrc_prop);
-   else
-   omap2_sync32k_clocksource_init();
-}
-
-void __init omap_sync32k_timer_init(void)
-{
-   __omap_sync32k_timer_init(1, "timer_32k_ck", "ti,timer-alwon",
-   2, "timer_sys_ck", NULL, false);
 }
 
-#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_SOC_AM43XX)
-void __init omap3_secure_sync32k_timer_init(void)
-{
-   __omap_sync32k_timer_init(12, "secure_32k_fck", "ti,timer-secure",
-   2, "timer_sys_ck", NULL, false);
-}
-#endif /* CONFIG_ARCH_OMAP3 */
-
-#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_SOC_AM33XX)
-void __init omap3_gptimer_timer_init(void)
-{
-   __omap_sync32k_timer_init(2, "timer_sys_ck", NULL,
-   1, "timer_sys_ck", "ti,timer-alwon", true);
-}
-#endif
-
-#if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5) || \
-   defined(CONFIG_SOC_DRA7XX) || defined(CONFIG_SOC_AM43XX)
-void __init omap4_local_timer_init(void)
-{
-   omap_sync32k_timer_init();
-   clocksource_of_init();
-}
-#endif
-
-#if defined(CONFIG_SOC_OMAP5) || defined(CONFIG_SOC_DRA7XX)
 void __init omap5_realtime_timer_init(void)
 {
omap_sync32k_timer_init();
-- 
2.5.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

[PATCH 04/11] arm: omap2: timer: provide generic sync32k_timer_init function

[Felipe Balbi]

instead of constantly defining a small wrapper
around __omap_sync32k_timer_init(), let's define
a generic one which can be used by all OMAPs.

Signed-off-by: Felipe Balbi 
---
 arch/arm/mach-omap2/board-generic.c | 10 +-
 arch/arm/mach-omap2/board-ldp.c |  2 +-
 arch/arm/mach-omap2/board-rx51.c|  2 +-
 arch/arm/mach-omap2/common.h|  3 +--
 arch/arm/mach-omap2/timer.c | 20 +++-
 5 files changed, 11 insertions(+), 26 deletions(-)

diff --git a/arch/arm/mach-omap2/board-generic.c 
b/arch/arm/mach-omap2/board-generic.c
index 9df14ed7dab1..871db0f0fa66 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -46,7 +46,7 @@ DT_MACHINE_START(OMAP242X_DT, "Generic OMAP2420 (Flattened 
Device Tree)")
.map_io = omap242x_map_io,
.init_early = omap2420_init_early,
.init_machine   = omap_generic_init,
-   .init_time  = omap2_sync32k_timer_init,
+   .init_time  = omap_sync32k_timer_init,
.dt_compat  = omap242x_boards_compat,
.restart= omap2xxx_restart,
 MACHINE_END
@@ -63,7 +63,7 @@ DT_MACHINE_START(OMAP243X_DT, "Generic OMAP2430 (Flattened 
Device Tree)")
.map_io = omap243x_map_io,
.init_early = omap2430_init_early,
.init_machine   = omap_generic_init,
-   .init_time  = omap2_sync32k_timer_init,
+   .init_time  = omap_sync32k_timer_init,
.dt_compat  = omap243x_boards_compat,
.restart= omap2xxx_restart,
 MACHINE_END
@@ -82,7 +82,7 @@ DT_MACHINE_START(OMAP3_N900_DT, "Nokia RX-51 board")
.init_early = omap3430_init_early,
.init_machine   = omap_generic_init,
.init_late  = omap3_init_late,
-   .init_time  = omap3_sync32k_timer_init,
+   .init_time  = omap_sync32k_timer_init,
.dt_compat  = n900_boards_compat,
.restart= omap3xxx_restart,
 MACHINE_END
@@ -100,7 +100,7 @@ DT_MACHINE_START(OMAP3_DT, "Generic OMAP3 (Flattened Device 
Tree)")
.init_early = omap3430_init_early,
.init_machine   = omap_generic_init,
.init_late  = omap3_init_late,
-   .init_time  = omap3_sync32k_timer_init,
+   .init_time  = omap_sync32k_timer_init,
.dt_compat  = omap3_boards_compat,
.restart= omap3xxx_restart,
 MACHINE_END
@@ -116,7 +116,7 @@ DT_MACHINE_START(OMAP36XX_DT, "Generic OMAP36xx (Flattened 
Device Tree)")
.init_early = omap3630_init_early,
.init_machine   = omap_generic_init,
.init_late  = omap3_init_late,
-   .init_time  = omap3_sync32k_timer_init,
+   .init_time  = omap_sync32k_timer_init,
.dt_compat  = omap36xx_boards_compat,
.restart= omap3xxx_restart,
 MACHINE_END
diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-ldp.c
index c2975af4cd5d..0d3a57c6931f 100644
--- a/arch/arm/mach-omap2/board-ldp.c
+++ b/arch/arm/mach-omap2/board-ldp.c
@@ -424,6 +424,6 @@ MACHINE_START(OMAP_LDP, "OMAP LDP board")
.init_irq   = omap3_init_irq,
.init_machine   = omap_ldp_init,
.init_late  = omap3430_init_late,
-   .init_time  = omap3_sync32k_timer_init,
+   .init_time  = omap_sync32k_timer_init,
.restart= omap3xxx_restart,
 MACHINE_END
diff --git a/arch/arm/mach-omap2/board-rx51.c b/arch/arm/mach-omap2/board-rx51.c
index 2d1e5a6beb85..830256c434ec 100644
--- a/arch/arm/mach-omap2/board-rx51.c
+++ b/arch/arm/mach-omap2/board-rx51.c
@@ -136,6 +136,6 @@ MACHINE_START(NOKIA_RX51, "Nokia RX-51 board")
.init_irq   = omap3_init_irq,
.init_machine   = rx51_init,
.init_late  = omap3430_init_late,
-   .init_time  = omap3_sync32k_timer_init,
+   .init_time  = omap_sync32k_timer_init,
.restart= omap3xxx_restart,
 MACHINE_END
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 92e92cfc2775..844ad031f7f0 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -88,8 +88,7 @@ static inline int omap_mux_late_init(void)
 
 extern void omap2_init_common_infrastructure(void);
 
-extern void omap2_sync32k_timer_init(void);
-extern void omap3_sync32k_timer_init(void);
+extern void omap_sync32k_timer_init(void);
 extern void omap3_secure_sync32k_timer_init(void);
 extern void omap3_gptimer_timer_init(void);
 extern void omap4_local_timer_init(void);
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 976ff9fa3594..d14e25b2d7a4 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -608,21 +608,13 @@ static void __init __omap_sync32k_timer_init(int 
clkev_nr, const char *clkev_src
omap2_sync32k_clocksource_init();
 }
 
-#ifdef CONFIG_ARCH_OMAP2
-void __init omap2_sync32k_timer_init(void)
+void __init omap_sync32k_timer_init(void)
 {
   

[PATCH 09/11] clocksource: add TI 32.768 Hz counter driver

[Felipe Balbi]

Introduce a new clocksource driver for Texas
Instruments 32.768 Hz device which is available
on most OMAP-like devices.

Signed-off-by: Felipe Balbi 
---
 drivers/clocksource/Kconfig|   7 +++
 drivers/clocksource/Makefile   |   1 +
 drivers/clocksource/timer-ti-32k.c | 122 +
 3 files changed, 130 insertions(+)
 create mode 100644 drivers/clocksource/timer-ti-32k.c

diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index a7726db13abb..98b2a9b9bfad 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -115,6 +115,13 @@ config CLKSRC_PISTACHIO
bool
select CLKSRC_OF
 
+config CLKSRC_TI_32K
+   bool "Texas Instruments 32.768 Hz Clocksource" if COMPILE_TEST
+   select CLKSRC_OF if OF
+   help
+ This option enables support for Texas Instruments 32.768 Hz 
clocksource
+ available on many OMAP-like platforms.
+
 config CLKSRC_STM32
bool "Clocksource for STM32 SoCs" if !ARCH_STM32
depends on OF && ARM && (ARCH_STM32 || COMPILE_TEST)
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index 5c00863c3e33..749abc3665b3 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -45,6 +45,7 @@ obj-$(CONFIG_VF_PIT_TIMER)+= vf_pit_timer.o
 obj-$(CONFIG_CLKSRC_QCOM)  += qcom-timer.o
 obj-$(CONFIG_MTK_TIMER)+= mtk_timer.o
 obj-$(CONFIG_CLKSRC_PISTACHIO) += time-pistachio.o
+obj-$(CONFIG_CLKSRC_TI_32K)+= timer-ti-32k.o
 
 obj-$(CONFIG_ARM_ARCH_TIMER)   += arm_arch_timer.o
 obj-$(CONFIG_ARM_GLOBAL_TIMER) += arm_global_timer.o
diff --git a/drivers/clocksource/timer-ti-32k.c 
b/drivers/clocksource/timer-ti-32k.c
new file mode 100644
index ..12e2ca7bcc49
--- /dev/null
+++ b/drivers/clocksource/timer-ti-32k.c
@@ -0,0 +1,122 @@
+/**
+ * timer-ti-32k.c - OMAP2 32k Timer Support
+ *
+ * Copyright (C) 2009 Nokia Corporation
+ *
+ * Update to use new clocksource/clockevent layers
+ * Author: Kevin Hilman, MontaVista Software, Inc. 
+ * Copyright (C) 2007 MontaVista Software, Inc.
+ *
+ * Original driver:
+ * Copyright (C) 2005 Nokia Corporation
+ * Author: Paul Mundt 
+ * Juha Yrjölä 
+ * OMAP Dual-mode timer framework support by Timo Teras
+ *
+ * Some parts based off of TI's 24xx code:
+ *
+ * Copyright (C) 2004-2009 Texas Instruments, Inc.
+ *
+ * Roughly modelled after the OMAP1 MPU timer code.
+ * Added OMAP4 support - Santosh Shilimkar 
+ *
+ * Copyright (C) 2015 Texas Instruments Incorporated - http://www.ti.com
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2  of
+ * the License as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * 32KHz clocksource ... always available, on pretty most chips except
+ * OMAP 730 and 1510.  Other timers could be used as clocksources, with
+ * higher resolution in free-running counter modes (e.g. 12 MHz xtal),
+ * but systems won't necessarily want to spend resources that way.
+ */
+
+#define OMAP2_32KSYNCNT_REV_OFF0x0
+#define OMAP2_32KSYNCNT_REV_SCHEME (0x3 << 30)
+#define OMAP2_32KSYNCNT_CR_OFF_LOW 0x10
+#define OMAP2_32KSYNCNT_CR_OFF_HIGH0x30
+
+struct ti_32k {
+   void __iomem*base;
+   void __iomem*counter;
+   struct clocksource  cs;
+};
+#define to_ti_32k(cs)  (container_of((cs), struct ti_32k, cs))
+
+static cycle_t ti_32k_read_cycles(struct clocksource *cs)
+{
+   struct ti_32k   *ti = to_ti_32k(cs);
+
+   return (cycle_t)readl_relaxed(ti->counter);
+}
+
+static struct ti_32k ti_32k_timer = {
+   .cs = {
+   .name   = "32k_counter",
+   .rating = 250,
+   .read   = ti_32k_read_cycles,
+   .mask   = CLOCKSOURCE_MASK(32),
+   .flags  = CLOCK_SOURCE_IS_CONTINUOUS |
+   CLOCK_SOURCE_SUSPEND_NONSTOP,
+   },
+};
+
+static u64 notrace omap_32k_read_sched_clock(void)
+{
+   return ti_32k_read_cycles(_32k_timer.cs);
+}
+
+static void __init ti_32k_timer_init(struct device_node *np)
+{
+   int ret;
+
+   ti_32k_timer.base = of_iomap(np, 0);
+   if (!ti_32k_timer.base) {
+   pr_err("Can't ioremap 32k timer base\n");
+   

[PATCH 07/11] arm: omap2: timer: remove omap4_local_timer_init

[Felipe Balbi]

We're now always calling clocksource_of_init()
whenever booting with DT, so we can use the
generic omap_sync32k_timer_init() (which will
be renamed in a follow-up patch) for OMAP4
as well.

Signed-off-by: Felipe Balbi 
---
 arch/arm/mach-omap2/board-generic.c | 4 ++--
 arch/arm/mach-omap2/common.h| 1 -
 arch/arm/mach-omap2/timer.c | 8 
 3 files changed, 2 insertions(+), 11 deletions(-)

diff --git a/arch/arm/mach-omap2/board-generic.c 
b/arch/arm/mach-omap2/board-generic.c
index 871db0f0fa66..20d5e82ab6ee 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -228,7 +228,7 @@ DT_MACHINE_START(OMAP4_DT, "Generic OMAP4 (Flattened Device 
Tree)")
.init_irq   = omap_gic_of_init,
.init_machine   = omap_generic_init,
.init_late  = omap4430_init_late,
-   .init_time  = omap4_local_timer_init,
+   .init_time  = omap_sync32k_timer_init,
.dt_compat  = omap4_boards_compat,
.restart= omap44xx_restart,
 MACHINE_END
@@ -272,7 +272,7 @@ DT_MACHINE_START(AM43_DT, "Generic AM43 (Flattened Device 
Tree)")
.init_late  = am43xx_init_late,
.init_irq   = omap_gic_of_init,
.init_machine   = omap_generic_init,
-   .init_time  = omap4_local_timer_init,
+   .init_time  = omap_sync32k_timer_init,
.dt_compat  = am43_boards_compat,
.restart= omap44xx_restart,
 MACHINE_END
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 844ad031f7f0..bf42fc4e78f4 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -91,7 +91,6 @@ extern void omap2_init_common_infrastructure(void);
 extern void omap_sync32k_timer_init(void);
 extern void omap3_secure_sync32k_timer_init(void);
 extern void omap3_gptimer_timer_init(void);
-extern void omap4_local_timer_init(void);
 #ifdef CONFIG_CACHE_L2X0
 int omap_l2_cache_init(void);
 #define OMAP_L2C_AUX_CTRL  (L2C_AUX_CTRL_SHARED_OVERRIDE | \
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index b523426f38a5..f41e526ffa46 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -517,14 +517,6 @@ void __init omap3_gptimer_timer_init(void)
 }
 #endif
 
-#if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5) || \
-   defined(CONFIG_SOC_DRA7XX) || defined(CONFIG_SOC_AM43XX)
-void __init omap4_local_timer_init(void)
-{
-   omap_sync32k_timer_init();
-}
-#endif
-
 #if defined(CONFIG_SOC_OMAP5) || defined(CONFIG_SOC_DRA7XX)
 
 /*
-- 
2.5.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 v2] arm: omap2: timer: don't disable our timers

[Felipe Balbi]

Felipe Balbi  writes:

> Tony Lindgren  writes:
>
>> * Felipe Balbi  [151005 17:49]:
>>> We actually want these devices to be created because
>>> we will be moving timers to drivers/clocksource and
>>> this will prevent them from probing.
>>
>> Great. Is this safe to appy on it's own? We are not getting
>> system timers re-inited to the default values?
>
> not that I could notice. I booted on BBB and AM4. If you give me a few
> minutes I can boot again and save console logs for reference.

found another dependency. This will have to be done only after my
clocksource conversion is finished. Oh well

-- 
balbi


signature.asc
Description: PGP signature

[PATCH 00/11] arm: omap: counter32k rework

[Felipe Balbi]

Hi,

the following patches de-obfuscate arch/arm/mach-omap2/timer.c
and start moving code to drivers/clocksource. So far only counter32k
has been moved over.

Note that we can't get rid of all the code (yet) because there are
still platforms relying to legacy boot and because of the strong
coupling with OMAP's hwmod layer.

This has a dependency on [1]. Boot tested with AM335x and AM437x.

[1] http://marc.info/?l=linux-omap=144354336924308=2

Here are the changes since v1:

  - removed register_persistent_clock() in favor of CLOCK_SOURCE_SUSPEND_NONSTOP
  - make dropped patch setting status=okay to 32k
  - made sure hwmod wouldn't disable 32k counter
  - rebased on v4.3-rc4

Boot logs:

  - AM437x SK:  http://hastebin.com/zuvetojaqe
  - BBB:http://hastebin.com/ihuponayap

Felipe Balbi (11):
  arm: omap2: timer: get rid of obfuscating macros
  arm: omap2: timer: add a gptimer argument to sync32k_timer_init()
  arm: omap2: timer: remove __omap_gptimer_init()
  arm: omap2: timer: provide generic sync32k_timer_init function
  arm: omap2: timer: move realtime_counter_init() around
  arm: omap2: timer: always call clocksource_of_init() when DT
  arm: omap2: timer: remove omap4_local_timer_init
  arm: omap2: timer: rename omap_sync32k_timer_init()
  clocksource: add TI 32.768 Hz counter driver
  arm: omap2+: select 32k clocksource driver
  arm: omap2: timer: limit hwmod usage to non-DT boots

 arch/arm/mach-omap2/Kconfig |   1 +
 arch/arm/mach-omap2/board-generic.c |  14 ++--
 arch/arm/mach-omap2/board-ldp.c |   2 +-
 arch/arm/mach-omap2/board-rx51.c|   2 +-
 arch/arm/mach-omap2/common.h|   4 +-
 arch/arm/mach-omap2/timer.c | 141 +++-
 drivers/clocksource/Kconfig |   7 ++
 drivers/clocksource/Makefile|   1 +
 drivers/clocksource/timer-ti-32k.c  | 122 +++
 9 files changed, 199 insertions(+), 95 deletions(-)
 create mode 100644 drivers/clocksource/timer-ti-32k.c

-- 
2.5.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

[PATCH 01/11] arm: omap2: timer: get rid of obfuscating macros

[Felipe Balbi]

those macros just make it a lot more difficult
to grep around and actually find similarities.

In this patch, we will simply remove them and
replace with actual functions and later commits
will come to further clean this up.

Signed-off-by: Felipe Balbi 
---
 arch/arm/mach-omap2/timer.c | 70 -
 1 file changed, 43 insertions(+), 27 deletions(-)

diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 548d922cb107..23e58ea6a171 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -592,53 +592,69 @@ static inline void __init realtime_counter_init(void)
 {}
 #endif
 
-#define OMAP_SYS_GP_TIMER_INIT(name, clkev_nr, clkev_src, clkev_prop,  \
-  clksrc_nr, clksrc_src, clksrc_prop)  \
-void __init omap##name##_gptimer_timer_init(void)  \
-{  \
-   omap_clk_init();\
-   omap_dmtimer_init();\
-   omap2_gp_clockevent_init((clkev_nr), clkev_src, clkev_prop);\
-   omap2_gptimer_clocksource_init((clksrc_nr), clksrc_src, \
-   clksrc_prop);   \
+static void __init __omap_gptimer_init(int clkev_nr, const char *clkev_src,
+   const char *clkev_prop, int clksrc_nr, const char *clksrc_src,
+   const char *clksrc_prop)
+{
+   omap_clk_init();
+   omap_dmtimer_init();
+   omap2_gp_clockevent_init(clkev_nr, clkev_src, clkev_prop);
+   omap2_gptimer_clocksource_init(clksrc_nr, clksrc_src, clksrc_prop);
 }
 
-#define OMAP_SYS_32K_TIMER_INIT(name, clkev_nr, clkev_src, clkev_prop, \
-   clksrc_nr, clksrc_src, clksrc_prop) \
-void __init omap##name##_sync32k_timer_init(void)  \
-{  \
-   omap_clk_init();\
-   omap_dmtimer_init();\
-   omap2_gp_clockevent_init((clkev_nr), clkev_src, clkev_prop);\
-   /* Enable the use of clocksource="gp_timer" kernel parameter */ \
-   if (use_gptimer_clksrc) \
-   omap2_gptimer_clocksource_init((clksrc_nr), clksrc_src, \
-   clksrc_prop);   \
-   else\
-   omap2_sync32k_clocksource_init();   \
+static void __init __omap_sync32k_timer_init(int clkev_nr, const char 
*clkev_src,
+   const char *clkev_prop, int clksrc_nr, const char *clksrc_src,
+   const char *clksrc_prop)
+{
+   omap_clk_init();
+   omap_dmtimer_init();
+   omap2_gp_clockevent_init(clkev_nr, clkev_src, clkev_prop);
+
+   /* Enable the use of clocksource="gp_timer" kernel parameter */
+   if (use_gptimer_clksrc)
+   omap2_gptimer_clocksource_init(clksrc_nr, clksrc_src,
+   clksrc_prop);
+   else
+   omap2_sync32k_clocksource_init();
 }
 
 #ifdef CONFIG_ARCH_OMAP2
-OMAP_SYS_32K_TIMER_INIT(2, 1, "timer_32k_ck", "ti,timer-alwon",
+void __init omap2_sync32k_timer_init(void)
+{
+   __omap_sync32k_timer_init(1, "timer_32k_ck", "ti,timer-alwon",
2, "timer_sys_ck", NULL);
+}
 #endif /* CONFIG_ARCH_OMAP2 */
 
 #if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_SOC_AM43XX)
-OMAP_SYS_32K_TIMER_INIT(3, 1, "timer_32k_ck", "ti,timer-alwon",
+void __init omap3_sync32k_timer_init(void)
+{
+   __omap_sync32k_timer_init(1, "timer_32k_ck", "ti,timer-alwon",
2, "timer_sys_ck", NULL);
-OMAP_SYS_32K_TIMER_INIT(3_secure, 12, "secure_32k_fck", "ti,timer-secure",
+}
+
+void __init omap3_secure_sync32k_timer_init(void)
+{
+   __omap_sync32k_timer_init(12, "secure_32k_fck", "ti,timer-secure",
2, "timer_sys_ck", NULL);
+}
 #endif /* CONFIG_ARCH_OMAP3 */
 
 #if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_SOC_AM33XX)
-OMAP_SYS_GP_TIMER_INIT(3, 2, "timer_sys_ck", NULL,
+void __init omap3_gptimer_timer_init(void)
+{
+   __omap_gptimer_init(2, "timer_sys_ck", NULL,
   1, "timer_sys_ck", "ti,timer-alwon");
+}
 #endif
 
 #if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5) || \
defined(CONFIG_SOC_DRA7XX) || defined(CONFIG_SOC_AM43XX)
-static OMAP_SYS_32K_TIMER_INIT(4, 1, "timer_32k_ck", "ti,timer-alwon",
+static void __init omap4_sync32k_timer_init(void)
+{
+   __omap_sync32k_timer_init(1, "timer_32k_ck", "ti,timer-alwon",
   2, "sys_clkin_ck", NULL);
+}
 
 void __init omap4_local_timer_init(void)
 {
-- 
2.5.3

--
To unsubscribe from this list: send the line "unsubscribe 

[PATCH 10/11] arm: omap2+: select 32k clocksource driver

[Felipe Balbi]

Now that we have a 32k clocksource driver, let's
select it for OMAP2PLUS builds.

Signed-off-by: Felipe Balbi 
---
 arch/arm/mach-omap2/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 871d6cc450a5..9ac5909ca59d 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -99,6 +99,7 @@ config ARCH_OMAP2PLUS
select SOC_BUS
select TI_PRIV_EDMA
select OMAP_IRQCHIP
+   select CLKSRC_TI_32K
help
  Systems based on OMAP2, OMAP3, OMAP4 or OMAP5
 
-- 
2.5.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

[PATCH 06/11] arm: omap2: timer: always call clocksource_of_init() when DT

[Felipe Balbi]

If booting with DT, let's make sure to always
call clocksource_of_init() as this will make
it easier to move timer code to drivers/clocksource
in the future.

Signed-off-by: Felipe Balbi 
---
 arch/arm/mach-omap2/timer.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index dcc0f032e717..b523426f38a5 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -496,6 +496,9 @@ void __init omap_sync32k_timer_init(void)
 {
__omap_sync32k_timer_init(1, "timer_32k_ck", "ti,timer-alwon",
2, "timer_sys_ck", NULL, false);
+
+   if (of_have_populated_dt())
+   clocksource_of_init();
 }
 
 #if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_SOC_AM43XX)
@@ -519,7 +522,6 @@ void __init omap3_gptimer_timer_init(void)
 void __init omap4_local_timer_init(void)
 {
omap_sync32k_timer_init();
-   clocksource_of_init();
 }
 #endif
 
@@ -640,10 +642,8 @@ sysclk1_based:
 
 void __init omap5_realtime_timer_init(void)
 {
-   omap_sync32k_timer_init();
realtime_counter_init();
-
-   clocksource_of_init();
+   omap_sync32k_timer_init();
 }
 #endif /* CONFIG_SOC_OMAP5 || CONFIG_SOC_DRA7XX */
 
-- 
2.5.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: cpufreq-dt error: failed to init cpufreq table: -61

[Belisko Marek]

Hi,

On Tue, Oct 6, 2015 at 4:03 PM, Belisko Marek  wrote:
> Hi Felipe,
>
> On Tue, Oct 6, 2015 at 4:00 PM, Felipe Balbi  wrote:
>>
>> Hi,
>>
>> Belisko Marek  writes:
>>> Hi Tony,
>>>
>>> I'm using custom am33xx board where mpu voltage can be changed through
>>> gpio regulator on 4.1 (latest stable) kernel. I defined gpio-regulator
>>> node and also operating-points to DT. Gpio regulator seems to be
>>> working fine but during probing cpufreq-dt I get error:
>>> failed to init cpufreq table: -61
>>>
>>> I did small investigation and seem that dev_pm_opp_init_cpufreq_table
>>> fails at first condition dev_pm_opp_get_opp_count <= 0 and this is
>>> because opp_list is empty. So it seems that any opp for am33xx aren't
>>> defined if I'm getting it right. I did look to mach-omap2/opp3xxx_data
>>> but there is nothing am33xx specific. It is known problem or exist
>>> some patches around to fix that? Many thanks.
>>
>> OPP initialization is not in mainline yet, there are some out-of-tree
>> patches which TI has been working on. If you want to use them, have a
>> look at TI's vendor kernel at [1]
> Thanks for link. One thing which is still not puzzled before I use 3.9
> kernel and it was working fine
> it's stops working when bumped to 4.1.
Sorry information was incorrect. On 3.9 kernel we did use tps, pmic
now we have only gpio regulator
so this is the difference.
>>
>> [1] 
>> http://git.ti.com/ti-linux-kernel/ti-linux-kernel/blobs/ti-lsk-linux-4.1.y/arch/arm/mach-omap2/opp33xx_data.c
>>
>> --
>> balbi
>

BR,

marek

-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.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: [RFC/PATCH 11/11] arm: boot: dts: omap: add missing default status for 32k counter

[Felipe Balbi]

Arnd Bergmann  writes:

> On Monday 05 October 2015 14:41:07 Felipe Balbi wrote:
>> 
>> /**
>>  * omap_get_timer_dt - get a timer using device-tree
>>  * @match   - device-tree match structure for matching a device type
>>  * @property- optional timer property to match
>>  *
>>  * Helper function to get a timer during early boot using device-tree for use
>>  * as kernel system timer. Optionally, the property argument can be used to
>>  * select a timer with a specific property. Once a timer is found then mark
>>  * the timer node in device-tree as disabled, to prevent the kernel from
>>  * registering this timer as a platform device and so no one else can use it.
>>  */
>> static struct device_node * __init omap_get_timer_dt(const struct 
>> of_device_id *match,
>>  const char *property)
>> {
>> struct device_node *np;
>> 
>> for_each_matching_node(np, match) {
>> if (!of_device_is_available(np))
>> continue;
>> 
>> if (property && !of_get_property(np, property, NULL))
>> continue;
>> 
>> if (!property && (of_get_property(np, "ti,timer-alwon", 
>> NULL) ||
>>   of_get_property(np, "ti,timer-dsp", NULL) 
>> ||
>>   of_get_property(np, "ti,timer-pwm", NULL) 
>> ||
>>   of_get_property(np, "ti,timer-secure", 
>> NULL)))
>> continue;
>> 
>> of_add_property(np, _disabled);
>> return np;
>> }
>> 
>> return NULL;
>> }
>> 
>> I'll patch this up and drop $subject
>> 
>
> Ah, good.
>
> I'm seeing the "ti,timer-alwon" property here, we probably need to take
> that into account when setting the CLOCK_SOURCE_SUSPEND_NONSTOP flag, if
> that isn't how it gets done already.

that flag is not set for 32k in any dts. Seems like it should, though,
judging by the binding documentation:

- ti,timer-alwon:   Indicates the timer is in an alway-on power
  domain.

Tony, care to comment if we should add timer-alwon to 32k ?

-- 
balbi


signature.asc
Description: PGP signature