hi there,
I am writing a very generic alsa soc i2s driver for a very generic i2s
device.
The platform is an Exynos 5250 SoC board.
Having trouble was looking for some help ...
I have tried to start this driver in two ways. 1] Using the
module_init/module_exit method and 2] Using the
On 7 August 2014 18:07, Bartlomiej Zolnierkiewicz
b.zolnier...@samsung.com wrote:
Runtime Power Management handling for the sdhci_add_host() failure
case in sdhci_s3c_probe() should match the code in sdhci_s3c_remove()
(which uses pm_runtime_disable() call which matches the earlier
Hi Inki, Andrzej
On 08/11/2014 04:09 PM, Inki Dae wrote:
On 2014년 08월 08일 18:40, Andrzej Hajda wrote:
On 08/08/2014 11:02 AM, Andrzej Hajda wrote:
On 08/08/2014 09:37 AM, Inki Dae wrote:
On 2014년 08월 08일 16:03, Thierry Reding wrote:
On Fri, Aug 08, 2014 at 10:45:47AM +0900, Inki Dae wrote:
On 1 July 2014 10:10, Marek Szyprowski m.szyprow...@samsung.com wrote:
This is a long awaited patch series enabling support for HDMI output
available on Exynos4412-based Odroid boards (X/X2/U2/U3/U3+) and
Exynos4210 Universal C210 board.
Hello,
have tested a few of these patches on an
Tested on an Odroid-U2:
Tested-by: Tomeu Vizoso to...@tomeuvizoso.net
Thanks,
Tomeu
On 16 July 2014 10:50, Daniel Drake dr...@endlessm.com wrote:
The ODROID kernel shows that the PMIC interrupt line is hooked up
to pin GPX3-2.
This is needed for the max77686-irq driver to create the PMIC
On 2014년 08월 12일 20:54, YoungJun Cho wrote:
Hi Inki, Andrzej
On 08/11/2014 04:09 PM, Inki Dae wrote:
On 2014년 08월 08일 18:40, Andrzej Hajda wrote:
On 08/08/2014 11:02 AM, Andrzej Hajda wrote:
On 08/08/2014 09:37 AM, Inki Dae wrote:
On 2014년 08월 08일 16:03, Thierry Reding wrote:
On Fri, Aug
Tested on an Odroid-U2:
Tested-by: Tomeu Vizoso tomeu.viz...@collabora.com
Thanks,
Tomeu
On 16 July 2014 10:50, Daniel Drake dr...@endlessm.com wrote:
Increase max i2c bus frequency beyond the default for faster
data transfers. According to the manual, these faster speeds are
only available
Acked-By: Carlos Hernandez c...@ti.com
-Original Message-
From: linux-kernel-ow...@vger.kernel.org
[mailto:linux-kernel-ow...@vger.kernel.org] On Behalf Of Punit Agrawal
Sent: Friday, July 18, 2014 10:10 AM
To: linux...@vger.kernel.org; linux-samsung-soc@vger.kernel.org
Cc:
Hi,
This patch series fixes builds with CONFIG_PM_SLEEP config option
disabled. It has been runtime tested on Exynos4210 based Origen
board.
Depends on:
- next-20140811 branch of linux-next kernel
Changes since v1:
(http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg34079.html)
-
Fix building of exynos_defconfig with CONFIG_PM_SLEEP disabled and
CONFIG_ARM_EXYNOS_CPUIDLE enabled by:
* adding EXYNOS_CPU_SUSPEND config option
* building pm.o and sleep.o if EXYNOS_CPU_SUSPEND is enabled
* moving suspend specific code from pm.c to suspend.c
* enabling pm-common.o build also
Ifdef around cpu_\name\()_do_suspend and cpu_\name\()_do_resume
ops in proc-macros.S should check for CONFIG_ARM_CPU_SUSPEND and
not CONFIG_PM_SLEEP. Fix it.
[ Please note that cpu_v7_do_[suspend,resume] code in proc-v7.S
already correctly checks for CONFIG_ARM_CPU_SUSPEND, same is
true for
Fix building of exynos_defconfig with disabled CONFIG_PM_SLEEP by
adding checking whether Exynos cpuidle support is enabled before
accessing exynos_enter_aftr.
The build error message:
arch/arm/mach-exynos/built-in.o:(.data+0x74): undefined reference to
`exynos_enter_aftr'
make: *** [vmlinux]
Peach Pit and Pi machines have the same regulators connection
and regulator name so the cros-tps65090 dtsi file can be used
to remove duplicated code.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
arch/arm/boot/dts/exynos5420-peach-pit.dts | 95
The DeviceTree files for the Peach Pit and Pi machines have
a simplistic model of the connections between the different
regulators since not all the tps65090 regulators get their
input supply voltage from the VDC. DCDC1-3, LD0-1 and fet7
parent supply is indded VDC but the fet1-6 get their input
The tps65090 PMU is a component used in many ChromeOS devices
so instead of having the same device tree definitions in many
files, create a .dtsi fragment that can be included in DTS.
This fragment is based on the DT definitions for Peach boards.
Signed-off-by: Javier Martinez Canillas
This series does a refactoring by creating dtsi files for the
tps65090 PMU that can be included by DT board files that have
this component. This not only allow to remove duplicated code
but also makes it easier to maintain the tps65090 information.
So the series also improve the tps65090
The tps65090 PMU data manual [0] has a table that list the
Recommended operating conditions for each regulator. Add
the information about the FET constraints to its dtsi file.
[0]: http://www.ti.com/lit/ds/symlink/tps65090.pdf
Signed-off-by: Javier Martinez Canillas
On Tue, Aug 12, 2014 at 06:44:23PM +0200, Javier Martinez Canillas wrote:
The tps65090 is a Power Management Unit (PMU) used in several
boards so the same information is described on different DTS.
It is better to create a .dtsi fragment that can be included.
Why is it better to do this?
+
On Monday, August 11, 2014 07:57:17 PM Javier Martinez Canillas wrote:
Many Exynos5 boards (e.g: Snow, Peach Pit and Pi) have
a SBS-compliant gas gauge battery. Enable to built it
so the needed support is available for these boards.
Suggested-by: Doug Anderson diand...@chromium.org
Hello Mark,
On 08/12/2014 06:58 PM, Mark Brown wrote:
On Tue, Aug 12, 2014 at 06:44:23PM +0200, Javier Martinez Canillas wrote:
The tps65090 is a Power Management Unit (PMU) used in several
boards so the same information is described on different DTS.
It is better to create a .dtsi fragment
Javier,
On Tue, Aug 12, 2014 at 9:44 AM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
The tps65090 PMU is a component used in many ChromeOS devices
so instead of having the same device tree definitions in many
files, create a .dtsi fragment that can be included in DTS.
On 08/12/2014 07:25 PM, Mark Brown wrote:
tps65090_fet1: fet1 {
+regulator-min-microvolt = 500;
+regulator-max-microvolt = 1700;
};
No, this is completely broken and exactly the sort of thing that makes
doing
Hello Doug,
Thanks for your feedback.
On 08/12/2014 07:26 PM, Doug Anderson wrote:
Javier,
On Tue, Aug 12, 2014 at 9:44 AM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
The tps65090 PMU is a component used in many ChromeOS devices
so instead of having the same device
On 08/12/2014 05:11 PM, Bartlomiej Zolnierkiewicz wrote:
Fix building of exynos_defconfig with disabled CONFIG_PM_SLEEP by
adding checking whether Exynos cpuidle support is enabled before
accessing exynos_enter_aftr.
The build error message:
arch/arm/mach-exynos/built-in.o:(.data+0x74):
On Tue, Aug 12, 2014 at 08:49:29PM +0200, Javier Martinez Canillas wrote:
So, is adding these voltages ranges (the design limits) in the Peach Pit DTS
file directly an acceptable solution? Basically what my previous patch [0]
did.
That matches what is in the board schematic so I assume that
--- Original Message ---
Sender : Hernandez, Carlosc...@ti.com
Date : 2014-08-12 22:49 (GMT+09:00)
Title : RE: [PATCH 1/2] PM / devfreq: Export helper functions for drivers
Acked-By: Carlos Hernandez
-Original Message-
From: linux-kernel-ow...@vger.kernel.org
26 matches
Mail list logo
