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

[Arnd Bergmann]

On Tuesday 22 December 2015 17:44:46 Tony Lindgren wrote:
> Add minimal SoC support for dra62x also known as j5eco. As it's closely
> related to dm814x, we can treat it as a dm814x variant for now and do
> rest of the configuration with DTS just files. And let's add hwmod
> support for MMC and USB on dm814x and dra62x.
> 

Pulled into omap/soc, thanks!

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: [GIT PULL 3/3] reworked dts changes for ti81xx devices and minimal dra62x j5ec-evm support

[Arnd Bergmann]

On Tuesday 22 December 2015 17:44:47 Tony Lindgren wrote:
> Add minimal device tree support for dra62x also known j5eco. It is
> related to dm814x, just the clocks are a bit different and it has a
> different set of integrated devices. And let's get some basic dm814x
> and dra62x devices working as many of the devices are like on am33xx::
> 
> - pinctrl using the pinctrl defines as for am33xx
> 
> - Updated EDMA bindings with support for using exma_xbar
> 
> - MMC support for dm814x-evm, t410 and dra62x-j5eco-evm
> 
> - USB support for dm814x-evm, t410 and dra62x-j5eco-evm
> 
> This branch depends on an earlier omap-for-v4.5/81xx-fixes-signed
> branch that has dm814x dts fixes interlaced with SoC related fixes to
> keep things booting. The interlaced SoC and dts fixes were needed
> because of issues with the device tree defined clocks that just
> happened to work on bootloader timings for t410 earlier.
> 

Merged into next/dt, thanks!

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: [GIT PULL 1/3] reworked fix for earlier ti81xx changes for v4.5 merge window

[Arnd Bergmann]

On Tuesday 22 December 2015 17:44:45 Tony Lindgren wrote:
> Here are reworked pull requests to separate the dts changes as requested
> by Olof.
> 
> The pull request below, and the third pull request in this series,
> still depend on the earlier branch omap-for-v4.5/81xx-fixes-signed.
> The pull request number two in this series does not.
> 
> My updated for-next has zero diff with these merged in compared to the
> earlier single branch merged in, so this is just regrouping of the patches
> into three separate pull requests.
> 

Merged into next/fixes-non-critical, thanks!

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: [RFC PATCH] thermal: Schedule a backup thermal shutdown workqueue after a known period of time to tackle failed poweroff

[Eduardo Valentin]

can we have a shorter title?

On Tue, Dec 29, 2015 at 02:46:49PM +0530, Keerthy wrote:
> Hi Nishanth,
> 

 
> >
> >I am not sure if this #ifdeffery is even needed.
> >
> >
> >Eduardo, Rui: If this is not the suggested technique, maybe you guys
> >could suggest how we could handle a case where userspace might be
> >hungup due to some reason and a case where a critical temperature
> >event in the middle of device probe was triggered?

Orderly power off is supposed to take care of this. Looking at the code,
it will force a shutdown in case execution of userland command fails:

static int __orderly_poweroff(bool force)
{
int ret;

ret = run_cmd(poweroff_cmd);

if (ret && force) {
pr_warn("Failed to start orderly shutdown: forcing the 
issue\n");

/*
 * I guess this should try to kick off some daemon to sync and
 * poweroff asap.  Or not even bother syncing if we're doing an
 * emergency shutdown?
 */
emergency_sync();
kernel_power_off();
}

> >
> >Obviously, we'd like to take into consideration userspace latencies as
> >well- but that is very specific to fs being run.. not really a simple
> >problem, IMHO..
> >
--
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] thermal: Schedule a backup thermal shutdown workqueue after a known period of time to tackle failed poweroff

[Nishanth Menon]

On 12/31/2015 12:20 PM, Eduardo Valentin wrote:
> On Thu, Dec 31, 2015 at 11:47:57AM -0600, Nishanth Menon wrote:
>> On 12/31/2015 11:29 AM, Eduardo Valentin wrote:
>>> can we have a shorter title?
>>>
>>>
>>> Orderly power off is supposed to take care of this. Looking at the code,
>>> it will force a shutdown in case execution of userland command fails:
>>>
>>> static int __orderly_poweroff(bool force)
>>> {
>>> int ret;
>>>
>>> ret = run_cmd(poweroff_cmd);
>>>
>>> if (ret && force) {
>>> pr_warn("Failed to start orderly shutdown: forcing the 
>>> issue\n");
>>>
>>> /*
>>>  * I guess this should try to kick off some daemon to sync 
>>> and
>>>  * poweroff asap.  Or not even bother syncing if we're 
>>> doing an
>>>  * emergency shutdown?
>>>  */
>>> emergency_sync();
>>> kernel_power_off();
>>> }
>>
>> Yes, it will *IF* userspace fails. the condition that I had tracked
>> was before identifying the following fix[1] - Example fail is here[2]
>>
> 
> OK. But still, why other users of orderly_poweroff do not
> deserve to be fixed, then?
> 


I'd agree as well.. I guess the comment from Robin Holt 
anticipated something like this will eventually occur.

"* I guess this should try to kick off some daemon to sync and
* poweroff asap.  Or not even bother syncing if we're doing an
* emergency shutdown?
"

Keerthy - would you spin this as a generic fix?

>>
>> I hope this explains the problem.
>>
>> [1]
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=00917b5c55aeb01322d5ab51af8c025b82959224
>> [2] http://pastebin.ubuntu.com/14326688/
>>
>> [3]
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/am57xx-beagle-x15.dts#n738
>>
>> -- 
>> Regards,
>> Nishanth Menon


-- 
Regards,
Nishanth Menon
--
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] thermal: Schedule a backup thermal shutdown workqueue after a known period of time to tackle failed poweroff

[Eduardo Valentin]

On Mon, Dec 21, 2015 at 11:16:18AM +0530, Keerthy wrote:
> In few rare conditions like during boot up the orderly_poweroff
> function might not be able to complete fully leaving the device
> running at dangerously high temperatures. Hence adding a backup
> workqueue to act after a known period of time and poweroff the device.

I really wish a better description of what is going on. I am not really
sure why thermal subsystem must deal with the case of a failing kernel
API. If orderly power off is failing, why don't we fix it instead?
What are the failing conditions? few rare conditions seams very odd.
How does it fail? Why fixing it in thermal? Other users of it don't
deserver the same fix?

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

Re: [RFC PATCH] thermal: Schedule a backup thermal shutdown workqueue after a known period of time to tackle failed poweroff

[Eduardo Valentin]

On Thu, Dec 31, 2015 at 11:47:57AM -0600, Nishanth Menon wrote:
> On 12/31/2015 11:29 AM, Eduardo Valentin wrote:
> > can we have a shorter title?
> > 
> > 
> > Orderly power off is supposed to take care of this. Looking at the code,
> > it will force a shutdown in case execution of userland command fails:
> > 
> > static int __orderly_poweroff(bool force)
> > {
> > int ret;
> > 
> > ret = run_cmd(poweroff_cmd);
> > 
> > if (ret && force) {
> > pr_warn("Failed to start orderly shutdown: forcing the 
> > issue\n");
> > 
> > /*
> >  * I guess this should try to kick off some daemon to sync 
> > and
> >  * poweroff asap.  Or not even bother syncing if we're 
> > doing an
> >  * emergency shutdown?
> >  */
> > emergency_sync();
> > kernel_power_off();
> > }
> 
> Yes, it will *IF* userspace fails. the condition that I had tracked
> was before identifying the following fix[1] - Example fail is here[2]
> 

OK. But still, why other users of orderly_poweroff do not
deserve to be fixed, then?

> 
> I hope this explains the problem.
> 
> [1]
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=00917b5c55aeb01322d5ab51af8c025b82959224
> [2] http://pastebin.ubuntu.com/14326688/
> 
> [3]
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/am57xx-beagle-x15.dts#n738
> 
> -- 
> Regards,
> Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: dts: omap3: Include missing bandgap data for ti-soc-thermal driver

[Eduardo Valentin]

Hello,

On Sat, Dec 26, 2015 at 12:32:25AM +0100, Pali Rohár wrote:
> Driver for omap3 with documentation is there since v4.4-rc1.
> 
> Signed-off-by: Pali Rohár 


> ---
>  arch/arm/boot/dts/omap34xx.dtsi |5 +
>  arch/arm/boot/dts/omap36xx.dtsi |5 +
>  2 files changed, 10 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/omap34xx.dtsi b/arch/arm/boot/dts/omap34xx.dtsi
> index 4f6b2d5..c3f488f 100644
> --- a/arch/arm/boot/dts/omap34xx.dtsi
> +++ b/arch/arm/boot/dts/omap34xx.dtsi
> @@ -54,6 +54,11 @@
>   #size-cells = <0>;
>   };
>   };
> +
> + bandgap {
> + reg = <0x48002524 0x4>;
> + compatible = "ti,omap34xx-bandgap";
> + };
>   };
>  };
>  
> diff --git a/arch/arm/boot/dts/omap36xx.dtsi b/arch/arm/boot/dts/omap36xx.dtsi
> index 86253de..00f98c1 100644
> --- a/arch/arm/boot/dts/omap36xx.dtsi
> +++ b/arch/arm/boot/dts/omap36xx.dtsi
> @@ -86,6 +86,11 @@
>   #size-cells = <0>;
>   };
>   };
> +
> + bandgap {
> + reg = <0x48002524 0x4>;
> + compatible = "ti,omap36xx-bandgap";

Can you please already add on both cases

#thermal-sensor-cells = <0>;
?

This way we can already use them to define thermal zones. Of course,
that alone won't add the thermal zones. A separated patch would be
needed to add the thermal zone for OMAP3.

> + };
>   };
>  };
>  
> -- 
> 1.7.9.5
> 
--
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] thermal: Schedule a backup thermal shutdown workqueue after a known period of time to tackle failed poweroff

[Nishanth Menon]

On 12/31/2015 11:29 AM, Eduardo Valentin wrote:
> can we have a shorter title?
> 
> On Tue, Dec 29, 2015 at 02:46:49PM +0530, Keerthy wrote:
>> Hi Nishanth,
>>
> 
>  
>>>
>>> I am not sure if this #ifdeffery is even needed.
>>>
>>>
>>> Eduardo, Rui: If this is not the suggested technique, maybe you guys
>>> could suggest how we could handle a case where userspace might be
>>> hungup due to some reason and a case where a critical temperature
>>> event in the middle of device probe was triggered?
> 
> Orderly power off is supposed to take care of this. Looking at the code,
> it will force a shutdown in case execution of userland command fails:
> 
> static int __orderly_poweroff(bool force)
> {
> int ret;
> 
> ret = run_cmd(poweroff_cmd);
> 
> if (ret && force) {
> pr_warn("Failed to start orderly shutdown: forcing the 
> issue\n");
> 
> /*
>  * I guess this should try to kick off some daemon to sync and
>  * poweroff asap.  Or not even bother syncing if we're doing 
> an
>  * emergency shutdown?
>  */
> emergency_sync();
> kernel_power_off();
> }

Yes, it will *IF* userspace fails. the condition that I had tracked
was before identifying the following fix[1] - Example fail is here[2]

In this case, tmp102 is setup for X15 as [3] - and built as a module.
as the kernel startsup filesystem and starts a modprobe of all modules
via udev rules, the probe of tmp102 detects (falsely) a critical
temperature condition. Shutdown attempt in the middle of driver probe
is always a tricky business.

As we look at the log in [2], Line  472
> thermal thermal_zone3: critical temperature reached(108 C),shutting down
We have userspace trigger for shutdown taking place.

Line 495: INIT: Sending processes the TERM signal

userspace starts shutting down services. (but note that probe for
other devices were either in progress or queued up to complete)..

at line 647 - we are in a weird place -> sysrq shows that system is
idled and userspace is shutdown and system is still active.


In this case, we entered the case thanks to a driver bug, but if this
situation was a real world temperature scenario, then we'd probably in
an overtemp scenario, then device damage could take place OR something
much worse.

The only alternative is to run a parallel thread in case userspace
fails to complete the job in some given period of time - due to what
ever be the condition triggering the problem.

I hope this explains the problem.

[1]
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=00917b5c55aeb01322d5ab51af8c025b82959224
[2] http://pastebin.ubuntu.com/14326688/

[3]
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/am57xx-beagle-x15.dts#n738

-- 
Regards,
Nishanth Menon
--
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 4/6] regulator: lp872x: Add enable GPIO pin support

[Mark Brown]

On Thu, Dec 31, 2015 at 10:59:06PM +0100, Paul Kocialkowski wrote:

> I understand, thanks for pointing this out. Well, for my use case, there
> is no use in disabling the chip at any point as it powers the external
> mmc.

Presumably someone might decide not to use the MMC in some case (perhaps
only mounting it when explicitly needed in order to save power for
example, or the MMC subsystem might figure out a way to power down an
idle MMC block device).

> Would you agree to have the enable pin handled directly (and by that, I
> mean enabled once, when requested, as I first suggested in the patchset)
> in the driver then?

That's probably fine, or do it via runtime PM (the framework is fairly
simple to use, I'll probably go add support in the core for it in the
next day or two as this seems like a sensible use case).  I can't
remember if this device is a MFD or not and I'm just on my way out the
door.


signature.asc
Description: PGP signature

Re: [PATCH 4/6] regulator: lp872x: Add enable GPIO pin support

[Paul Kocialkowski]

Le jeudi 31 décembre 2015 à 21:40 +, Mark Brown a écrit :
> On Wed, Dec 30, 2015 at 07:37:19PM +0100, Paul Kocialkowski wrote:
> > Le mercredi 30 décembre 2015 à 16:33 +, Mark Brown a écrit :
> > > On Wed, Dec 30, 2015 at 09:35:21AM +0100, Paul Kocialkowski wrote:
> 
> > > > In my opinion, it would be more elegant to adapt the core regulator
> > > > framework to first enable the GPIO and then call the regulator enable
> > > > ops callback instead of handling the GPIO in the driver.
> 
> > > Why would we want to actively manage both things at runtime?  It's more
> > > work, what do we gain from it?
> 
> > Well, I figured that it would be best to disable the EN pin when we're
> > not using any of the regulators, since that allows the chip to enter
> > standby mode (and thus consume less power).
> 
> This doesn't sound like it's anything to do with the regulators, that's
> a chip wide power management function which should be implemented via
> runtime PM if there's any value in implementing it at all (if the device
> is a primary PMIC normally this would be handled by the CPU core when it
> enters low power state without any software).  It's not something we
> should be considering on a per regulator basis since it's at the chip
> level and on a per regulator basis it's not doing anything useful for
> the reasons above.

I understand, thanks for pointing this out. Well, for my use case, there
is no use in disabling the chip at any point as it powers the external
mmc.

Would you agree to have the enable pin handled directly (and by that, I
mean enabled once, when requested, as I first suggested in the patchset)
in the driver then?

> > It also doesn't hurt regulators that only use a GPIO for enable.
> 
> It causes problems for any device with an optional GPIO,  it means that
> we end up mantaining both GPIO and register which as I've said a couple
> of times now defeats the point of having the GPIO.

Fair enough.


signature.asc
Description: This is a digitally signed message part

Re: [PATCH 4/6] regulator: lp872x: Add enable GPIO pin support

[Mark Brown]

On Wed, Dec 30, 2015 at 07:37:19PM +0100, Paul Kocialkowski wrote:
> Le mercredi 30 décembre 2015 à 16:33 +, Mark Brown a écrit :
> > On Wed, Dec 30, 2015 at 09:35:21AM +0100, Paul Kocialkowski wrote:

> > > In my opinion, it would be more elegant to adapt the core regulator
> > > framework to first enable the GPIO and then call the regulator enable
> > > ops callback instead of handling the GPIO in the driver.

> > Why would we want to actively manage both things at runtime?  It's more
> > work, what do we gain from it?

> Well, I figured that it would be best to disable the EN pin when we're
> not using any of the regulators, since that allows the chip to enter
> standby mode (and thus consume less power).

This doesn't sound like it's anything to do with the regulators, that's
a chip wide power management function which should be implemented via
runtime PM if there's any value in implementing it at all (if the device
is a primary PMIC normally this would be handled by the CPU core when it
enters low power state without any software).  It's not something we
should be considering on a per regulator basis since it's at the chip
level and on a per regulator basis it's not doing anything useful for
the reasons above.

> It also doesn't hurt regulators that only use a GPIO for enable.

It causes problems for any device with an optional GPIO,  it means that
we end up mantaining both GPIO and register which as I've said a couple
of times now defeats the point of having the GPIO.


signature.asc
Description: PGP signature

musb module names in 4.4.0-rc7

[Andreas Färber]

Hi Felipe,

Using the openSUSE kernel config [1] I've noticed the following modules
get built for recent RCs:

/lib/modules/4.4.0-rc7-1.g276c9f4-lpae/kernel/drivers/usb/musb> ls
am35x.ko  musb_am335x.ko  musb_dsps.ko  musb_hdrc.ko  omap2430.ko  sunxi.ko

In my case I was testing on a sun9i based Optimus Board and needed to
specify "sunxi" as driver for dracut to add to my initrd for USB root.
Shouldn't that rather be "musb_sunxi" for module name uniqueness?

Same issue with am35x and omap2430 above, I guess.

Cheers and Happy New Year,
Andreas

[1] http://kernel.opensuse.org/cgit/kernel-source/tree/config/armv7hl

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Michael Turquette]

Hi Tero,

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

I'm really happy to see this series. Looks pretty good to me.

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

This should really be a .prepare callback if you plan to keep the delays
in there.

Regards,
Mike
--
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