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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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,

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

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

musb module names in 4.4.0-rc7

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

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

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