On 2/11/14 11:56 PM, Jingoo Han wrote:
> On Wednesday, February 12, 2014 2:34 PM, Stephen Warren wrote:
>> On 02/04/2014 02:45 PM, dingu...@altera.com wrote:
>>> From: Dinh Nguyen
>>>
>>> This means that the driver can be in host or peripheral mode when the
>>> appropriate
>>> connector is used.
On Wednesday, February 12, 2014 2:34 PM, Stephen Warren wrote:
> On 02/04/2014 02:45 PM, dingu...@altera.com wrote:
> > From: Dinh Nguyen
> >
> > This means that the driver can be in host or peripheral mode when the
> > appropriate
> > connector is used. When an A-cable is plugged in, the driver
On 02/04/2014 02:45 PM, dingu...@altera.com wrote:
> From: Dinh Nguyen
>
> This means that the driver can be in host or peripheral mode when the
> appropriate
> connector is used. When an A-cable is plugged in, the driver behaves in host
> mode, and when a B-cable is used, the driver will be in
On 11 February 2014 23:20, Tomasz Figa wrote:
> Apparently, if G3D regulator is powered off, the SoC cannot enter low
> power modes and just hangs. This patch fixes this by keeping the
> regulator always on when the system is running, as suggested by Exynos 4
> User's Manual in case of Exynos4210/
Am Freitag, 10. Januar 2014, 17:17:43 schrieb kg...@kernel.org:
> Heiko Stübner wrote:
> > Commit 48cf83dc12f2 (ARM: samsung: remove unused tick.h) removed some
> > occurences of tick.h. tick.h itself and s3c24xx_ostimer_pending was only
> > used by the old timer driver and is not used anymore.
> >
Am Sonntag, 12. Januar 2014, 21:34:29 schrieb Heiko Stübner:
> The function is nearly empty and samsung_cpu_rev is static so already 0
> making the function obsolete, therefore remove it.
>
> Signed-off-by: Heiko Stuebner
ping :-)
> ---
> arch/arm/mach-s3c24xx/common.c |1 -
> a
On Mon, Feb 10, 2014 at 10:29 PM, Kukjin Kim wrote:
> This patch adds support for Samsung GH7 SoC in arm64/Kconfig.
>
> Signed-off-by: Kukjin Kim
> Cc: Catalin Marinas
The overhead of building one more device tree isn't very large, and I
don't see any other need to have a Kconfig entry per SoC
Hi,
Besides what Mark Rutland already commented on:
On Mon, Feb 10, 2014 at 10:29 PM, Kukjin Kim wrote:
> +/ {
> + model = "SAMSUNG GH7";
> + compatible = "samsung,gh7";
Model and compatible in the dtsi should probably always be overridden
by a dts that includes it, so there's littl
On Tue, Feb 11, 2014 at 06:29:41AM +, Kukjin Kim wrote:
> Signed-off-by: Kukjin Kim
> Reviewed-by: Thomas Abraham
> Cc: Catalin Marinas
> ---
> arch/arm64/boot/dts/samsung-gh7.dtsi | 108
> ++
> arch/arm64/boot/dts/samsung-ssdk-gh7.dts | 26 +++
> 2 f
On 06.02.2014 20:12, Tomasz Figa wrote:
Current Samsung PM code is heavily unprepared for multiplatform systems.
The design implies accessing functions and global variables defined in
particular mach- subdirectory from common code in plat-, which is not
allowed when building ARCH_MULTIPLATFORM. I
Apparently, if G3D regulator is powered off, the SoC cannot enter low
power modes and just hangs. This patch fixes this by keeping the
regulator always on when the system is running, as suggested by Exynos 4
User's Manual in case of Exynos4210/4x12 SoCs (Exynos5250 UM does not
have such note, but o
On Mon, Feb 10, 2014 at 10:25:31PM +0100, Paul Bolle wrote:
> Signed-off-by: Paul Bolle
Applied, thanks.
signature.asc
Description: Digital signature
Hi Dmitry,
On Tue, Jan 28, 2014 at 10:24 PM, Manish Badarkhe
wrote:
> Instead of "#ifdef CONFIG_OF" use "IS_ENABLED(CONFIG_OF)"
> option for DT code to avoid if-deffery in code.
>
> Signed-off-by: Manish Badarkhe
> ---
> Changes since V1:
> 1.Updated code to use "IS_ENABLED" during retrieval
>
Constify the regulator_desc 'regulators' array.
Signed-off-by: Krzysztof Kozlowski
Cc: Mark Brown
Cc: Liam Girdwood
---
drivers/regulator/s2mps11.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/regulator/s2mps11.c b/drivers/regulator/s2mps11.c
index 89966213315
This patch prepares for adding support for S2MPS14 RTC device to the
rtc-s5m driver:
1. Renames SEC* symbols to S5M.
2. Adds S5M prefix to some of defines which are different between S5M876X
and S2MPS14.
This is only a rename-like patch, new code is not added.
Signed-off-by: Krzysztof Kozlowski
Add maximum register to the regmap used by rtc-s5m driver.
Signed-off-by: Krzysztof Kozlowski
---
drivers/mfd/sec-core.c |2 ++
include/linux/mfd/samsung/rtc.h |2 ++
2 files changed, 4 insertions(+)
diff --git a/drivers/mfd/sec-core.c b/drivers/mfd/sec-core.c
index 7c6ce2e4aaa
The S2MPS11 RTC has two alarms: alarm0 and alarm1 (corresponding
interrupts are named similarly). Use consistent names for interrupts to
limit possible errors.
Signed-off-by: Krzysztof Kozlowski
---
drivers/mfd/sec-irq.c |8
include/linux/mfd/samsung/irq.h |4 ++--
2 f
This patch prepares for adding support for S2MPS14 RTC device to the
rtc-s5m driver:
1. Adds a map of registers used by the driver which differ between
the chipsets (S5M876X and S2MPS14).
2. Moves code of checking for alarm pending to separate function.
Signed-off-by: Krzysztof Kozlowski
Cc: Ales
Document the "op_mode" properties parsed from DTS by s2mps11 driver.
S2MPS11/S2MPS14 regulators support different modes of operation:
- Always off;
- On/Off controlled by pin/GPIO (PWREN/LDOEN/EMMCEN);
- Always on;
This is very similar to S5M8767 regulator driver which also supports
opmodes (a
Add support for S2MPS14 to the rtc-s5m driver. Differences in S2MPS14
(in comparison to S5M8767):
- Layout of registers;
- Lack of century support for time and alarms (7 registers used for
storing time/alarm);
- Two buffer control registers: WUDR and RUDR;
- No register for enabling writing
S2MPS11/S2MPS14 regulators support different modes of operation:
- Always off;
- On/Off controlled by pin/GPIO (PWREN/LDOEN/EMMCEN);
- Always on;
This is very similar to S5M8767 regulator driver which also supports
opmodes (although S5M8767 have also low-power mode).
This patch adds parsing the
Add support for S2MPS14 PMIC regulators to s2mps11 driver. The S2MPS14
has fewer BUCK-s and LDO-s than S2MPS11. It also does not support
controlling the BUCK ramp delay.
Signed-off-by: Krzysztof Kozlowski
Cc: Mark Brown
Cc: Liam Girdwood
---
drivers/regulator/s2mps11.c | 251 +
This patch prepares for adding support for S2MPS14 RTC driver by
selecting different regmaps for S2MPS1X/S5M876X RTC devices.
Signed-off-by: Krzysztof Kozlowski
---
drivers/mfd/sec-core.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/mfd/sec-core.
Add bindings documentation for S2MPS14 device to the s2mps11 driver.
Signed-off-by: Krzysztof Kozlowski
Cc: Mark Brown
Cc: Liam Girdwood
Cc: Tomasz Figa
Cc: devicet...@vger.kernel.org
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kumar Gala
---
Documentation/device
During probe choose how many regulators will be supported according to
device ID. Allocate array of of_regulator_match() dynamically (based
number of regulators) instead of allocation on the stack.
This is needed for supporting different devices in s2mps11
driver and actually prepares the regulato
Add support for S2MPS14 PMIC device to the MFD sec-core driver.
The S2MPS14 is similar to S2MPS11 but it has fewer regulators, two
clocks instead of three and a little different registers layout.
Signed-off-by: Krzysztof Kozlowski
---
drivers/mfd/sec-core.c | 48 +--
drive
-next: next-20140211 *with* today's patch:
mfd: sec-core: Fix possible NULL pointer dereference when i2c_new_dummy error
TODO
Add support for S2MPS14 to the S2MPS11 clock driver. The patch
is actually ready but it is based on the "Add support for clocks in S5M8767"
http://t
This patch removes the code for initializing time if this is first boot.
The code for detecting first boot uses undocumented field RTC_TCON in
RTC_UDR_CON register. According to S5M8767's datasheet this field is
reserved. On S2MPS14 it is not documented at all. On device first boot
the registers w
On Tue, 11 Feb 2014, Krzysztof Kozlowski wrote:
> During probe the driver allocates dummy I2C devices for MUIC and haptic
> with i2c_new_dummy() but it does not check the return value of this
> calls.
>
> In case of error (i2c_new_device(): memory allocation failure or I2C
> address cannot be use
On Tue, 11 Feb 2014, Krzysztof Kozlowski wrote:
> During probe the driver allocates dummy I2C device for companion chip
> and then allocates a regmap for it. If regmap_init_i2c() fails then the
> I2C driver (allocated with i2c_new_dummy()) is not freed and this
> resource leaks.
>
> Signed-off-by
On Tue, 11 Feb 2014, Krzysztof Kozlowski wrote:
> During probe the driver allocates dummy I2C devices for RTC, haptic and
> MUIC with i2c_new_dummy() but it does not check the return value of this
> calls.
>
> In case of error (i2c_new_device(): memory allocation failure or I2C
> address cannot b
On Tue, 11 Feb 2014, Krzysztof Kozlowski wrote:
> During probe the driver allocates dummy I2C device for RTC with
> i2c_new_dummy() but it does not check the return value of this call.
>
> In case of error (i2c_new_device(): memory allocation failure or I2C
> address cannot be used) this functio
On Tue, 11 Feb 2014, Krzysztof Kozlowski wrote:
> During probe the driver allocates dummy I2C devices for RTC and ADC
> with i2c_new_dummy() but it does not check the return value of this
> calls.
>
> In case of error (i2c_new_device(): memory allocation failure or I2C
> address cannot be used) t
On Tue, 11 Feb 2014, Krzysztof Kozlowski wrote:
> During probe the driver allocates dummy I2C device for RTC with
> i2c_new_dummy() but it does not check the return value of this call.
>
> In case of error (i2c_new_device(): memory allocation failure or I2C
> address cannot be used) this function
On Tue, 11 Feb 2014, Krzysztof Kozlowski wrote:
> During probe the driver allocates dummy I2C device for companion chip
> with i2c_new_dummy() but it does not check the return value of this call.
>
> In case of error (i2c_new_device(): memory allocation failure or I2C
> address cannot be used) th
On 11.02.2014 07:30, Olof Johansson wrote:
Hi,
On Mon, Feb 10, 2014 at 10:10 PM, Kukjin Kim wrote:
2014-02-10 10:20 GMT+05:30 Sachin Kamat :
On 7 February 2014 22:03, Tomasz Figa wrote:
On 06.02.2014 19:59, Olof Johansson wrote:
On Thu, Feb 6, 2014 at 10:43 AM, Bartlomiej Zolnierkiewic
On 11.02.2014 07:10, Kukjin Kim wrote:
2014-02-10 10:20 GMT+05:30 Sachin Kamat :
On 7 February 2014 22:03, Tomasz Figa wrote:
On 06.02.2014 19:59, Olof Johansson wrote:
On Thu, Feb 6, 2014 at 10:43 AM, Bartlomiej Zolnierkiewicz
wrote:
Well, once again, seeing some numbers would be good
During probe the driver allocates dummy I2C devices for RTC and ADC
with i2c_new_dummy() but it does not check the return value of this
calls.
In case of error (i2c_new_device(): memory allocation failure or I2C
address cannot be used) this function returns NULL which is later used
by i2c_unregist
During probe the driver allocates dummy I2C devices for RTC, haptic and
MUIC with i2c_new_dummy() but it does not check the return value of this
calls.
In case of error (i2c_new_device(): memory allocation failure or I2C
address cannot be used) this function returns NULL which is later used
by i2c
During probe the driver allocates dummy I2C devices for MUIC and haptic
with i2c_new_dummy() but it does not check the return value of this
calls.
In case of error (i2c_new_device(): memory allocation failure or I2C
address cannot be used) this function returns NULL which is later used
by devm_reg
During probe the driver allocates dummy I2C device for RTC with i2c_new_dummy()
but it does not check the return value of this call.
In case of error (i2c_new_device(): memory allocation failure or I2C
address cannot be used) this function returns NULL which is later used
by i2c_unregister_device
Hi Rahul,
On 11.02.2014 06:22, Rahul Sharma wrote:
Hi Tomasz,
On 6 February 2014 18:51, Tomasz Figa wrote:
Hi Rahul, Pankaj, Arun,
[adding linux-arm-kernel, devicetree MLs and DT people on Cc]
I think it's good time to stop accepting DTS files like this and force new
ones to use the proper
During probe the driver allocates dummy I2C device for companion chip
and then allocates a regmap for it. If regmap_init_i2c() fails then the
I2C driver (allocated with i2c_new_dummy()) is not freed and this
resource leaks.
Signed-off-by: Krzysztof Kozlowski
Cc: sta...@vger.kernel.org
---
driver
During probe the driver allocates dummy I2C device for RTC with
i2c_new_dummy() but it does not check the return value of this call.
In case of error (i2c_new_device(): memory allocation failure or I2C
address cannot be used) this function returns NULL which is later used
by i2c_unregister_device(
During probe the driver allocates dummy I2C device for companion chip
with i2c_new_dummy() but it does not check the return value of this call.
In case of error (i2c_new_device(): memory allocation failure or I2C
address cannot be used) this function returns NULL which is later used
by regmap_init
> During probe the sec-core driver allocates dummy I2C device for RTC with
> i2c_new_dummy() but return value is not checked. In case of error
> (i2c_new_device(): memory allocation failure or I2C address cannot be
> used) this function returns NULL which is later used by
> devm_regmap_init_i2c() o
Hi Tarek,
On 11 February 2014 12:56, Tarek Dakhran wrote:
> Hi Sachin,
>
>
>
> Current implementation allow to boot only one secondary core.
>
> This patch makes possible to boot 4 cores on Exynos5420 and Exynos5410 SoC's
I also get 4 cores up with the mainline kernel on SMDK 5420 board
without
Hi Kukjin,
Am Dienstag, 11. Februar 2014, 11:46:13 schrieb Kukjin Kim:
> 2014-02-10 1:26 GMT+05:30 Tomasz Figa :
> >
> > For patches 4, 5, 9, 10, 11, 12:
> >
> > Reviewed-by: Tomasz Figa
> >
> > For patches 6, 7:
> >
> > Acked-by: Tomasz Figa
>
> Really nice series.
> Heiko, thanks for your
During probe the sec-core driver allocates dummy I2C device for RTC with
i2c_new_dummy() but return value is not checked. In case of error
(i2c_new_device(): memory allocation failure or I2C address cannot be
used) this function returns NULL which is later used by
devm_regmap_init_i2c() or i2c_unre
49 matches
Mail list logo