Exynos7 supports multiple idle states. Core power down is one such
idle state, where cores can be powered off independently.
This patch adds support for core power down idle state.
Entry latency for core power down idle state is calculated as follows:
1. Time difference is measured between cpuidl
This patch removes all unused static iomapping from
exynos4/5_iodesc table, and at the same time removes
related macros from map.h and map-s5p.h.
All such mappings are present in exynos.c but not currently
there are no users of these mappings, so its safe to remove these.
Signed-off-by: Pankaj Dub
On Fri, Nov 7, 2014 at 5:28 PM, Lorenzo Pieralisi
wrote:
> 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 stat
On November 10, 2014 11:39:31 AM PST, Mark Brown wrote:
>On Mon, Nov 10, 2014 at 10:32:24AM -0800, Dmitry Torokhov wrote:
>
>> - I do not see why sirincling platform specific code around i2c, spi,
>> etc bus code (which is not platform-specific) is OK, but a no-no
>for
>> the driver ocre.
>
>s
On Mon, Nov 10, 2014 at 10:32:24AM -0800, Dmitry Torokhov wrote:
> - I do not see why sirincling platform specific code around i2c, spi,
> etc bus code (which is not platform-specific) is OK, but a no-no for
> the driver ocre.
sirincling? In the case of I2C and SPI the buses don't define any
Kukjin Kim writes:
> Kevin Hilman wrote:
>>
>> From: Kevin Hilman
>>
>> The option CONFIG_EXYNOS5420_MCPM is causing imprecise external aborts
>> during boot testing, causing various userspace startup failures.
>>
>> Disable until it has gotten more testing.
>>
>> Cc: Kukjin Kim ,
>> Cc: Jav
On Mon, Nov 10, 2014 at 04:18:50PM +0100, Ulf Hansson wrote:
> [...]
>
> > I guess we do need it for 3.18, but when we are talking about 3.19,
> > before we make any more changes can we outline how power domains are
> > supposed to work?
> >
> > 1. How do we attach a device to power domain? Right
On Sun, Nov 9, 2014 at 3:25 PM, Tomasz Figa wrote:
> Please consider the following pull request containing queued changes for
> pinctrl-samsung driver.
Thanks, pulled!
> I'm sorry for all the delays in handling this. Things
> should get better from now on, though.
IIUC you are a hobbyist maint
[...]
> I guess we do need it for 3.18, but when we are talking about 3.19,
> before we make any more changes can we outline how power domains are
> supposed to work?
>
> 1. How do we attach a device to power domain? Right now it seems that
> individual buses are responsible for attaching their de
On Mon, Nov 10, 2014 at 07:39:51PM +0530, D Krishna Mohan wrote:
> Hi Mark Brown,
Don't top post.
> The codec driver is present in mainline as rt5631.c., Its realtek's
> alc5631 so retained that name.
> Similarly machine driver also is named as arndale_rt5631.c but inside that
> driver I have
Hi Mark Brown,
The codec driver is present in mainline as rt5631.c., Its realtek's
alc5631 so retained that name.
Similarly machine driver also is named as arndale_rt5631.c but inside that
driver I have used alc5631 naming as the
audio daughter card on arndale board mentions alc5631 so I ha
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 "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
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
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
Hello Mark,
This is the sixth 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
On Mon, Nov 10, 2014 at 01:31:56PM +0530, Krishna Mohan Dani wrote:
> Document the device tree binding for the ALC5631 codec and update vendor
> specific prefix for the Realtek.
This driver isn't in mainline, you need to submit the driver.
signature.asc
Description: Digital signature
Hi Kukjin,
On Tuesday, October 07, 2014 1:23 PM, Pankaj Dubey wrote:
> Subject: [PATCH v3 0/2] Handle reboot for Exynos SoC via restart_handler
>
> This patch removes restart hook from machine_desc of Exynos, and moves
respective
> code into reboot_notifiers.
> Exynos5440 handles reboot via clock
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
On Sat, Nov 8, 2014 at 12:15 AM, Kevin Hilman wrote:
> 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
Hi Kukjin,
On Sun, Nov 9, 2014 at 10:09 AM, Kukjin Kim wrote:
> Abhilash Kesavan wrote:
>>
>> On Mon, Nov 3, 2014 at 1:51 PM, Abhilash Kesavan
>> wrote:
>> > Hello Kukjin,
>> >
>> > On Fri, Oct 31, 2014 at 8:06 AM, Abhilash Kesavan
>> > wrote:
>> >> Hi Kukjin,
>> >>
>> >> On Tue, Oct 28, 2014 a
Signed-off-by: Krishna Mohan Dani
---
sound/soc/codecs/Kconfig |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index a68d173..2d85887 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -487,7 +487,8
Signed-off-by: Krishna Mohan Dani
---
sound/soc/codecs/rt5631.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/sound/soc/codecs/rt5631.c b/sound/soc/codecs/rt5631.c
index 1ba27db..d7c3f42 100644
--- a/sound/soc/codecs/rt5631.c
+++ b/sound/soc/codecs/rt5631.c
@@ -1690,6 +1690,1
Adding machine driver to instantiate I2S based realtek's ALC5631
sound card on Arndale board.
There are other variants of Audio Daughter Cards for Arndale
Board for which support already exists but there is no support for
Realtek's alc5631 codec hence support for ALC5631 based machine
driver is be
These patches add machine driver to instantiate I2S based realtek's
ALC5631 based sound card on Arndale board.
There are other variants of Audio Daughter Cards for Arndale
Board for which support already exists but there is no support for
Realtek's alc5631 codec based card hence support for ALC56
Document the device tree binding for the ALC5631 codec and update vendor
specific prefix for the Realtek.
Signed-off-by: Krishna Mohan Dani
---
Documentation/devicetree/bindings/sound/rt5631.txt | 41
1 file changed, 41 insertions(+)
create mode 100644 Documentation/devic
27 matches
Mail list logo