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 module_p
On 7 August 2014 18:07, Bartlomiej Zolnierkiewicz
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
> pm_runtime_enable() one). Fix i
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 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 Odroid-U2 on top of
linux/mas
Tested on an Odroid-U2:
Tested-by: Tomeu Vizoso
Thanks,
Tomeu
On 16 July 2014 10:50, Daniel Drake 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 IRQ
> domain, which is needed by max
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 wrot
Tested on an Odroid-U2:
Tested-by: Tomeu Vizoso
Thanks,
Tomeu
On 16 July 2014 10:50, Daniel Drake wrote:
> Increase max i2c bus frequency beyond the default for faster
> data transfers. According to the manual, these faster speeds are
> only available when the board is wired up the right way.
Acked-By: Carlos Hernandez
-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: orjan.e...@arm.com; linux
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 fo
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 f
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] Err
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
---
arch/arm/boot/dts/exynos5420-peach-pit.dts | 95 +++---
arch/arm/boot/dts/exy
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
su
Now that there is a .dtsi fragment file for the tps65090 PMU,
include it in the Exynos Snow DTS file to reduce duplication.
Signed-off-by: Javier Martinez Canillas
---
arch/arm/boot/dts/exynos5250-snow.dts | 108 +-
1 file changed, 54 insertions(+), 54 deletions(-
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.
Signed-off-by: Javier Martinez Canillas
---
arch/arm/boot/dts/tps65090.dtsi | 57 +
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
---
arch
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 descripti
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
---
arch/arm/boot/dts/tps6
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
> Signed-off-by: Javier Ma
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 frag
Javier,
On Tue, Aug 12, 2014 at 9:44 AM, Javier Martinez Canillas
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.
>
> This fragment is based on the
On Tue, Aug 12, 2014 at 06:44:28PM +0200, Javier Martinez Canillas wrote:
> 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.
> tps65090_fet1: fet1 {
>
On Tue, Aug 12, 2014 at 07:21:35PM +0200, Javier Martinez Canillas wrote:
> 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
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 make
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
> wrote:
>> The tps65090 PMU is a component used in many ChromeOS devices
>> so instead of having the same device tree definitions in many
>
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): undefine
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 t
> --- Original Message ---
> Sender : Hernandez, Carlos
> 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
> [mailto:
Hi,
On Tuesday, August 12, 2014 10:49:12 PM Daniel Lezcano wrote:
> 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.
31 matches
Mail list logo