On Friday, November 07, 2014 02:27:27 PM Ulf Hansson wrote:
> The initial state of the device's need_restore flag should'nt depend on
> the current state of the PM domain. For example it should be perfectly
> valid to attach an inactive device to a powered PM domain.
>
> The pm_genpd_dev_need_rest
Hi Lukasz,
On Fri, Nov 7, 2014 at 2:05 AM, Lukasz Majewski wrote:
> Hi Eduardo,
>
>> On Thu, Oct 09, 2014 at 06:38:39PM +0200, Lukasz Majewski wrote:
>> > This patch extends the of-thermal.c to provide information about
>> > number of available non critical (i.e. non HW) trip points in the
>> > s
Dmitry Torokhov writes:
> On Fri, Nov 07, 2014 at 11:47:53AM -0800, Kevin Hilman wrote:
>> Ulf Hansson writes:
>>
>> > The initial state of the device's need_restore flag should'nt depend on
>> > the current state of the PM domain. For example it should be perfectly
>> > valid to attach an inac
On Fri, Nov 07, 2014 at 11:47:53AM -0800, Kevin Hilman wrote:
> Ulf Hansson writes:
>
> > The initial state of the device's need_restore flag should'nt depend on
> > the current state of the PM domain. For example it should be perfectly
> > valid to attach an inactive device to a powered PM domai
Ulf Hansson writes:
> The initial state of the device's need_restore flag should'nt depend on
> the current state of the PM domain. For example it should be perfectly
> valid to attach an inactive device to a powered PM domain.
>
> The pm_genpd_dev_need_restore() API allow us to update the need_r
Hi Bartlomiej,
On Mon, Oct 20, 2014 at 02:41:07PM +0200, Bartlomiej Zolnierkiewicz wrote:
>
> Hi,
>
> Eduardo, could you please merge this patch?
>
I queued this in my -fixes branch. It should appear also in linux-next.
Can you please refresh your patch series
https://lkml.org/lkml/2014/9/18/
On 07/11/14 14:27, Ulf Hansson wrote:
[...]
> To handle things more properly in the generic PM domain, let's change
> the default initial value of the need_restore flag to reflect that the
> state is unknown. As soon as some of the runtime PM callbacks gets
> invoked, update the initial value accor
Sylwester Nawrocki writes:
> On 04/11/14 07:44, amit daniel kachhap wrote:
>> On Mon, Nov 3, 2014 at 11:53 PM, Kevin Hilman wrote:
>>> "Rafael J. Wysocki" writes:
On Monday, November 03, 2014 09:23:01 AM Amit Daniel Kachhap wrote:
> These power domain transition notifiers will assist i
Commit c2dd114d2486 ("ARM: EXYNOS: fix register setup for AFTR mode
code") added S5P_CENTRAL_SEQ_OPTION register setup fix for all
Exynos SoCs to AFTR mode code-path. It turned out that for coupled
cpuidle AFTR mode on Exynos4210 (added by the next patch) applying
this fix causes lockup so enable
The following patch adds coupled cpuidle support for Exynos4210 to
an existing cpuidle-exynos driver. As a result it enables AFTR mode
to be used by default on Exynos4210 without the need to hot unplug
CPU1 first.
The patch is heavily based on earlier cpuidle-exynos4210 driver from
Daniel Lezcano
Hi,
The following patchset adds coupled cpuidle support for Exynos4210
to an existing cpuidle-exynos driver. As a result it enables AFTR
mode to be used by default on Exynos4210 without the need to hot
unplug CPU1 first.
This work is heavily based on earlier cpuidle-exynos4210 driver from
Daniel
Hi All,
Uh... just finished reading this thread and finally decided to add my 5 cents
here
as I've already had very bad experience with some changes introduced to DD/PM
core :(
(just check the history of the change 1e2ef05bb
"PM: Limit race conditions between runtime PM and system sleep (v2)"
O
Hi Eduardo,
>
> Hello Lukasz,
>
> On Fri, Nov 07, 2014 at 11:05:51AM +0100, Lukasz Majewski wrote:
> > Hi Eduardo,
> >
> > > On Thu, Oct 09, 2014 at 06:38:39PM +0200, Lukasz Majewski wrote:
> > > > This patch extends the of-thermal.c to provide information about
> > > > number of available non
On Fri, Nov 07, 2014 at 12:11:24PM +0100, Andrzej Hajda wrote:
> On 11/06/2014 06:08 PM, Sjoerd Simons wrote:
> > On Thu, 2014-11-06 at 23:10 +0900, Inki Dae wrote:
> >> This patch resovles the infinite loop issue incurred
> >> when Exyno drm driver is enabled but all kms drivers
> >> are disabled
On Fri, Nov 07, 2014 at 05:15:38PM +0100, Javier Martinez Canillas wrote:
> On 11/07/2014 04:47 PM, Mark Brown wrote:
> >> + if (!of_property_read_u32(np, "regulator-initial-mode", &pval)) {
> >> + if (desc && desc->map_modes)
> >> + constraints->initial_mode = desc->map
On Fri, Nov 07, 2014 at 02:00:05PM +0100, Javier Martinez Canillas wrote:
> + if (!of_property_read_u32(np, "regulator-initial-mode", &pval)) {
> + if (desc && desc->map_modes)
> + constraints->initial_mode = desc->map_modes(pval);
> + else
> +
On Fri, Nov 07, 2014 at 02:00:03PM +0100, Javier Martinez Canillas wrote:
> - initdata = of_get_regulator_init_data(dev, np);
> sreg = devm_kzalloc(dev, sizeof(*sreg), GFP_KERNEL);
> if (!sreg)
> return -ENOMEM;
> - sreg->initdata = initdata;
> sreg->name =
Hello Mark,
On 11/07/2014 05:10 PM, Mark Brown wrote:
>
> You're also saying that the OS won't manage the mode here, that's a step
> further.
>
I see
>> So should I just explain what each property is about without trying to make
>> assumptions about the limitations that different devices could
On 11/07/2014 04:54 PM, Mark Brown wrote:
> of_map_mode - it's only one mode and this is mapping to/from DT.
>
Ok
>> + * If the callback is not defined, the "regulator-initial-mode"
>> + * and suspend states "regulator-mode" properties won't be
>> parsed.
>
> Just remov
On 11/07/2014 04:47 PM, Mark Brown wrote:
> On Fri, Nov 07, 2014 at 02:00:05PM +0100, Javier Martinez Canillas wrote:
>
>> +if (!of_property_read_u32(np, "regulator-initial-mode", &pval)) {
>> +if (desc && desc->map_modes)
>> +constraints->initial_mode = desc->m
Hello Krzysztof,
On 11/07/2014 04:23 PM, Krzysztof Kozlowski wrote:
>>
>> static struct fan53555_platform_data *fan53555_parse_dt(struct device *dev,
>> -struct device_node *np)
>> +struct device_nod
On Fri, Nov 07, 2014 at 04:38:04PM +0100, Javier Martinez Canillas wrote:
> On 11/07/2014 03:58 PM, Mark Brown wrote:
> > On Fri, Nov 07, 2014 at 02:00:01PM +0100, Javier Martinez Canillas wrote:
> >> +The "regulator-mode" property only takes effect if the regulator is
> >> +enabled for th
Hello Lukasz,
On Fri, Nov 07, 2014 at 11:05:51AM +0100, Lukasz Majewski wrote:
> Hi Eduardo,
>
> > On Thu, Oct 09, 2014 at 06:38:39PM +0200, Lukasz Majewski wrote:
> > > This patch extends the of-thermal.c to provide information about
> > > number of available non critical (i.e. non HW) trip poi
On Fri, Nov 07, 2014 at 02:00:02PM +0100, Javier Martinez Canillas wrote:
> + * @map_modes: Callback invoked to translate from hardware to standard modes.
> + * The function returns the standard REGULATOR_MODE that maps to
> + * the hardware specific mode passed as an argum
Hello Mark,
On 11/07/2014 04:07 PM, Mark Brown wrote:
>
> This is using the regulator descriptor before it is initialized which
> doesn't seem ideal...
>
You are right, even if most of them are not used currently, that may
change in the future so is safer to use it after all fields have been
ini
Hello Mark,
Thanks a lot for your feedback.
On 11/07/2014 03:58 PM, Mark Brown wrote:
> On Fri, Nov 07, 2014 at 02:00:01PM +0100, Javier Martinez Canillas wrote:
>
>> + The "regulator-mode" property only takes effect if the regulator is
>> + enabled for the given suspend state using "r
On pią, 2014-11-07 at 14:00 +0100, Javier Martinez Canillas wrote:
> Hello Mark,
>
> This is the fifth version of the series that adds regulator initial
> and suspend operating modes support. It relies on the existing work
> that added suspend states bindings. The opmodes are parsed by the
> regul
On pią, 2014-11-07 at 14:00 +0100, Javier Martinez Canillas wrote:
> The of_get_regulator_init_data() function is used to extract the regulator
> init_data but information on how to extract certain data is defined in the
> static regulator descriptor (e.g: how to map the hardware operating modes).
On Fri, Nov 07, 2014 at 02:00:01PM +0100, Javier Martinez Canillas wrote:
> + The "regulator-mode" property only takes effect if the regulator is
> + enabled for the given suspend state using "regulator-on-in-suspend".
Why?
> + If the regulator has not been explicitly disabled
During system resume from suspend to RAM the Exynos DRM driver forced
CRTC mode thus turning display on (DPMS_ON). This lead to runtime resuming
of DSI which failed because whole LCD power domain was off and it was
not allowed to turn on because of system resume in progress.
Forcing mode should no
Add runtime Power Management to the Exynos DSI driver so the LCD power
domain could be turned off.
This slightly reduces the energy consumption when screen is completely
turned off. On Trats2 board when the system was idle the energy
consumption dropped by 1% (from 92.2 mA to 91.1 mA).
Before the
Hi,
Changes since v1
1. Replace patch 1 changing PM core with fix only for DRM exynos driver.
Description
===
The goal of the patch 2 is to add runtime PM to the Exynos DSI driver.
This allows LCD power domain to be turned off.
However after adding this patch an interesi
Existing code updates cupfreq policy only while executing
cpufreq_apply_cooling() function (i.e. when notify_device != NOTIFY_INVALID).
It doesn't apply constraints when cpufreq policy update happens from any other
place but it should update the cpufreq policy with thermal constraints every
time wh
The initial state of the device's need_restore flag should'nt depend on
the current state of the PM domain. For example it should be perfectly
valid to attach an inactive device to a powered PM domain.
The pm_genpd_dev_need_restore() API allow us to update the need_restore
flag to somewhat cope wi
The "regulator-initial-mode" and "regulator-mode" DT properties allows
to configure the regulator operating modes at startup or when a system
enters into a susend state.
But these properties use as valid values the operating modes supported
by each device while the core deals with the standard ope
Some regulators can run on different operating modes (opmodes). This
allows systems to choose the most efficient opmode for each regulator.
This patch builds on top of (291d761 regulator: Document binding for
regulator suspend state for PM state) adding a regulator-initial-mode
DT property to conf
The of_get_regulator_init_data() function is used to extract the regulator
init_data but information on how to extract certain data is defined in the
static regulator descriptor (e.g: how to map the hardware operating modes).
Add a const struct regulator_desc * parameter to the function signature
Drivers can use the of_regulator_match() function to parse the regulator
init_data from DT. A match table is used to specify the name of the node
containing the regulators, the device node and to return the init_data
to the caller.
But also the static regulator descriptor is needed to correctly ex
Some regulators support their operating mode to be changed on startup
or by consumers when the system is running while others only support
their operating mode to be changed while the system has entered in a
suspend state.
The regulator Device Tree binding documents a set of properties to
configur
Hello Mark,
This is the fifth version of the series that adds regulator initial
and suspend operating modes support. It relies on the existing work
that added suspend states bindings. The opmodes are parsed by the
regulator core and drivers should only define a translation function
to map between
This patch fixes possible infinite loop issue by postponing
registration to non kms drivers after component_master_add_with_match
call, which can be incurred in all cases that non kms driver is probed
and then component bind is failed
This patch should be applied on top of below patches,
h
On Wed, Nov 05, 2014 at 01:15:31PM +, Chander Kashyap wrote:
> Exynos7 has core power down state where cores can be powered off
> independently.
"...has a core power down idle state..."
> This patch adds support for this state.
"...for this idle state."
> Entry latency for the core power d
On pią, 2014-11-07 at 20:50 +0900, Chanwoo Choi wrote:
> Hi Krzysztof,
>
> On 11/07/2014 08:44 PM, Krzysztof Kozlowski wrote:
> > The bootloader on market Rinato (Gear 2) device checks for revision in
> > compatible field of DTB. If it is not present or lower than required
> > then booting fails w
Hi Krzysztof,
On 11/07/2014 08:44 PM, Krzysztof Kozlowski wrote:
> The bootloader on market Rinato (Gear 2) device checks for revision in
> compatible field of DTB. If it is not present or lower than required
> then booting fails with: "Could not do normal boot. (no DTB found)".
>
> Log of bootlo
The bootloader on market Rinato (Gear 2) device checks for revision in
compatible field of DTB. If it is not present or lower than required
then booting fails with: "Could not do normal boot. (no DTB found)".
Log of bootloader in case of failure:
h/w: revision = 0x06
h/w: schematic = SM-R380_Rev0
This patch fixes a null pointer dereference issue incurred by
calling g2d_remove when exynos_drm_platform_probe is failed.
cmdlist_pool of g2d is allocated when g2d sub driver is probed.
So if exynos_drm_platform_probe is failed, the g2d sub driver is
not probed and the cmdlist_pool is still NULL.
Hello Eduardo Valentin,
On Thursday, November 06, 2014 1:19 PM, Eduardo Valentin wrote:
> Hello Yadwinder,
>
> On Thu, Nov 06, 2014 at 04:26:27PM +0530, Yadwinder Singh Brar wrote:
> > Hello Eduardo Valentin,
> >
> > On Thursday, November 06, 2014 2:17 AM, Eduardo Valentin wrote:
> > > Hello Yad
On 2014년 11월 07일 17:29, Andrzej Hajda wrote:
> On 11/06/2014 03:10 PM, Inki Dae wrote:
>> This patch resovles the infinite loop issue incurred
>> when Exyno drm driver is enabled but all kms drivers
>> are disabled on Exynos board by returning -EPROBE_DEFER
>> only in case that there is kms device
Hi Eduardo,
> Hello,
>
> On Thu, Oct 09, 2014 at 06:38:40PM +0200, Lukasz Majewski wrote:
> > Before this change it was only possible to set get_temp() and
> > get_trend() methods to be used in the common code handling passing
> > parameters via device tree to "cpu-thermal" CPU thermal zone devic
On 11/06/2014 06:08 PM, Sjoerd Simons wrote:
> On Thu, 2014-11-06 at 23:10 +0900, Inki Dae wrote:
>> This patch resovles the infinite loop issue incurred
>> when Exyno drm driver is enabled but all kms drivers
>> are disabled on Exynos board by returning -EPROBE_DEFER
>> only in case that there is
On Fri, Nov 07, 2014 at 12:24:40PM +0530, Padmavathi Venna wrote:
> Exynos7 I2S controller has no internal dma, supports more
> no. of root clock sampling frequencies and has more no.of Rx
> fifos to support 7.1CH recording in TDM mode. Due to more no.
Applied, thanks.
signature.asc
Description:
On Fri, Nov 07, 2014 at 12:24:39PM +0530, Padmavathi Venna wrote:
> Internal DMA is available only on some of Samsung platforms.
> So added a quirk for the same and made it optional.
Applied, thanks.
signature.asc
Description: Digital signature
On Fri, Nov 07, 2014 at 02:01:57PM +0530, Padma Venkat wrote:
> CS can also be controlled automatically by setting AUTO_N_MANUAL to 1
> in CS_CFG. When it is auto CS automatically toggles between packet to
> packet. NCS_TIME_COUNT in CS_CFG controls the inactive period. The
> driver by default use
Hi Eduardo,
> On Thu, Oct 09, 2014 at 06:38:39PM +0200, Lukasz Majewski wrote:
> > This patch extends the of-thermal.c to provide information about
> > number of available non critical (i.e. non HW) trip points in the
> > system.
> >
> > Signed-off-by: Lukasz Majewski
> > ---
> > drivers/therma
Hi Eduardo,
> Hello Lukasz,
>
> On Thu, Oct 09, 2014 at 06:38:38PM +0200, Lukasz Majewski wrote:
> > This patch extends the of-thermal.c to provide check if trip point
> > is enabled.
> >
> > Signed-off-by: Lukasz Majewski
> > ---
> > drivers/thermal/of-thermal.c | 9 +
> > drivers/t
Hi Eduardo,
> Hello Lukasz,
>
> On Thu, Oct 09, 2014 at 06:38:37PM +0200, Lukasz Majewski wrote:
> > This patch extends the of-thermal.c to provide information about
> > number of available trip points.
> >
> > Signed-off-by: Lukasz Majewski
> > ---
> > drivers/thermal/of-thermal.c | 6 +
On Thu, Nov 06, 2014 at 02:09:40PM +, Charles Keepax wrote:
> On Thu, Nov 06, 2014 at 03:01:56PM +0100, Stam, Michel [FINT] wrote:
> > Hello Charles and Riku,
> >
> > I've quickly tested this on a 3.10 kernel i had around;
> > I enabled CONFIG_PM, CONFIG_PM_RUNTIME, CONFIG_PM_AUTOSLEEP,
> > CO
Hi Mark,
CCing Kukjin Kim.
On 11/6/14, Mark Brown wrote:
> On Thu, Nov 06, 2014 at 03:21:49PM +0530, Padmavathi Venna wrote:
>> Exynos7 SPI controller supports only the auto Selection of
>> CS toggle mode and Exynos7 SoC includes six SPI controllers.
>> Add support for these changes in Exynos7 S
On 11/06/2014 03:10 PM, Inki Dae wrote:
> This patch resovles the infinite loop issue incurred
> when Exyno drm driver is enabled but all kms drivers
> are disabled on Exynos board by returning -EPROBE_DEFER
> only in case that there is kms device registered.
There are many different cases it can
59 matches
Mail list logo
