[PATCH] mfd: sec-core: Fix possible NULL pointer dereference when i2c_new_dummy error
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_unregister_device().
If i2c_new_dummy() fails for RTC device, fail also the probe for main
MFD driver.
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
Cc: sta...@vger.kernel.org
---
drivers/mfd/sec-core.c |4
1 file changed, 4 insertions(+)
diff --git a/drivers/mfd/sec-core.c b/drivers/mfd/sec-core.c
index a139798b8065..7c6ce2e4aaa6 100644
--- a/drivers/mfd/sec-core.c
+++ b/drivers/mfd/sec-core.c
@@ -252,6 +252,10 @@ static int sec_pmic_probe(struct i2c_client *i2c,
}
sec_pmic-rtc = i2c_new_dummy(i2c-adapter, RTC_I2C_ADDR);
+ if (!sec_pmic-rtc) {
+ dev_err(i2c-dev, Failed to allocate I2C for RTC\n);
+ return -ENODEV;
+ }
i2c_set_clientdata(sec_pmic-rtc, sec_pmic);
sec_pmic-regmap_rtc = devm_regmap_init_i2c(sec_pmic-rtc,
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/12] ARM: S3C24XX: convert s3c2410, s3c2440 s3c2442 to common clock framework
Hi Kukjin, Am Dienstag, 11. Februar 2014, 11:46:13 schrieb Kukjin Kim: 2014-02-10 1:26 GMT+05:30 Tomasz Figa tomasz.f...@gmail.com: For patches 4, 5, 9, 10, 11, 12: Reviewed-by: Tomasz Figa t.f...@samsung.com For patches 6, 7: Acked-by: Tomasz Figa t.f...@samsung.com Really nice series. Heiko, thanks for your effort and Tomasz, thanks for your review and ack. OK, I'll apply this whole series and this will be sent to arm-soc in this week. not this fast :-) Tomasz hat some comments about the two clk-drivers included, which I'll need to address first. Also, this series, as well as the other two at the moment conflict with Tomasz' clock-pm changes. Our (Tomasz and me) current plan was for me to respin the 3 ccf conversion series against his clock-pm series, which I hope to do in the next two days or so. Heiko -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 0/1] Boot all secondary cores on Exynos SoC's
Hi Tarek, On 11 February 2014 12:56, Tarek Dakhran t.dakh...@samsung.com 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 this patch. Please see log below: [0.00] Linux version 3.14.0-rc2-00027-gce8ee8a (sachin@linaro) (gcc version 4.8.2 20130805 (prerelease) (crosstool-NG linaro-1 .13.1-4.8-2013.08 - Linaro GCC 2013.08) ) #76 SMP PREEMPT Tue Feb 11 15:18:30 IST 2014 [0.00] CPU: ARMv7 Processor [412fc0f3] revision 3 (ARMv7), cr=10c5387d [0.00] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache [0.00] Machine model: Samsung SMDK5420 board based on EXYNOS5420 [0.00] NR_BANKS too low, ignoring high memory [0.00] Memory policy: Data cache writealloc [0.00] CPU EXYNOS5420 (id 0xe5420200) [0.00] On node 0 totalpages: 522240 [0.00] Normal zone: 1520 pages used for memmap [0.00] Normal zone: 0 pages reserved [0.00] Normal zone: 194560 pages, LIFO batch:31 [0.00] HighMem zone: 2576 pages used for memmap [0.00] HighMem zone: 327680 pages, LIFO batch:31 [0.00] PERCPU: Embedded 7 pages/cpu @ee795000 s7424 r8192 d13056 u32768 [0.00] pcpu-alloc: s7424 r8192 d13056 u32768 alloc=8*4096 [0.00] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 [0] 4 [0] 5 [0] 6 [0] 7 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 520720 [0.00] Kernel command line: root=/dev/mmcblk1p1 rw rootwait console=ttySAC2,115200n8 init=/linuxrc earlyprintk loglevel=8 no_c onsole_suspend [0.00] PID hash table entries: 4096 (order: 2, 16384 bytes) [0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) [0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) [0.00] Memory: 2065876K/2088960K available (3705K kernel code, 227K rwdata, 1124K rodata, 223K init, 263K bss, 23084K reserved , 1310720K highmem) [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xfff0 - 0xfffe ( 896 kB) [0.00] vmalloc : 0xf000 - 0xff00 ( 240 MB) [0.00] lowmem : 0xc000 - 0xef80 ( 760 MB) [0.00] pkmap : 0xbfe0 - 0xc000 ( 2 MB) [0.00] modules : 0xbf00 - 0xbfe0 ( 14 MB) [0.00] .text : 0xc0008000 - 0xc04bf6e8 (4830 kB) [0.00] .init : 0xc04c - 0xc04f7d00 ( 224 kB) [0.00] .data : 0xc04f8000 - 0xc0530e80 ( 228 kB) [0.00].bss : 0xc0530e8c - 0xc0572e34 ( 264 kB) [0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=8, Nodes=1 [0.00] Preemptible hierarchical RCU implementation. [0.00] NR_IRQS:16 nr_irqs:16 16 [0.00] sched_clock: 32 bits at 200 Hz, resolution 500ns, wraps every 1073741824000ns [0.00] Console: colour dummy device 80x30 [0.045000] Calibrating delay loop... 1590.88 BogoMIPS (lpj=3977216) [0.045000] pid_max: default: 32768 minimum: 301 [0.045000] Mount-cache hash table entries: 512 [0.055000] CPU: Testing write buffer coherency: ok [0.055000] CPU0: update cpu_power 1535 [0.055000] CPU0: thread -1, cpu 0, socket 0, mpidr 8000 [0.055000] Setting up static identity map for 0x20387210 - 0x20387268 [0.075000] CPU1: Booted secondary processor [0.125000] CPU1: update cpu_power 1535 [0.125000] CPU1: thread -1, cpu 1, socket 0, mpidr 8001 [0.135000] CPU2: Booted secondary processor [0.175000] CPU2: update cpu_power 1535 [0.175000] CPU2: thread -1, cpu 2, socket 0, mpidr 8002 [0.185000] CPU3: Booted secondary processor [0.235000] CPU3: update cpu_power 1535 [0.235000] CPU3: thread -1, cpu 3, socket 0, mpidr 8003 [1.245000] CPU4: failed to boot: -38 [2.245000] CPU5: failed to boot: -38 [3.255000] CPU6: failed to boot: -38 [4.255000] CPU7: failed to boot: -38 [4.255000] Brought up 4 CPUs [4.255000] SMP: Total of 4 processors activated. Regards, Sachin On Tue, Feb 11, 2014 at 3:17 PM, Sachin Kamat sachin.ka...@linaro.org wrote: Hi Tarek, On 11 February 2014 07:45, Tarek Dakhran t.dakh...@samsung.com wrote: Due to implementation of exynos_boot_secondary function only one secondary core boots on Exynos SoC's. Even without this patch I could boot the secondary CPUs on Exynos4210, 4412 and 5250 based boards with the latest Linux kernel (v3.14-rc2+). Is this patch required for a specific use case or am I missing something? --- With warm regards, Sachin Best regards, Tarek Dakhran -- With warm regards, Sachin -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to
Re: [PATCH] mfd: sec-core: Fix possible NULL pointer dereference when i2c_new_dummy error
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_unregister_device(). If i2c_new_dummy() fails for RTC device, fail also the probe for main MFD driver. Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com Cc: sta...@vger.kernel.org --- drivers/mfd/sec-core.c |4 1 file changed, 4 insertions(+) Applied, thanks. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/7] mfd: 88pm860x: Fix possible NULL pointer dereference on i2c_new_dummy error
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_i2c().
If i2c_new_dummy() fails for companion device, fail also the probe for
main MFD driver.
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
Cc: sta...@vger.kernel.org
---
drivers/mfd/88pm860x-core.c |5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/mfd/88pm860x-core.c b/drivers/mfd/88pm860x-core.c
index c9b1f6422941..e456be9a7c67 100644
--- a/drivers/mfd/88pm860x-core.c
+++ b/drivers/mfd/88pm860x-core.c
@@ -1179,6 +1179,11 @@ static int pm860x_probe(struct i2c_client *client,
chip-companion_addr = pdata-companion_addr;
chip-companion = i2c_new_dummy(chip-client-adapter,
chip-companion_addr);
+ if (!chip-companion) {
+ dev_err(client-dev,
+ Failed to allocate I2C companion device\n);
+ return -ENODEV;
+ }
chip-regmap_companion = regmap_init_i2c(chip-companion,
pm860x_regmap_config);
if (IS_ERR(chip-regmap_companion)) {
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/7] mfd: max77686: Fix possible NULL pointer dereference on i2c_new_dummy error
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().
If i2c_new_dummy() fails for RTC device, fail also the probe for main
MFD driver.
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
Cc: sta...@vger.kernel.org
---
drivers/mfd/max77686.c |4
1 file changed, 4 insertions(+)
diff --git a/drivers/mfd/max77686.c b/drivers/mfd/max77686.c
index f53d5823a3f7..e5fce765accb 100644
--- a/drivers/mfd/max77686.c
+++ b/drivers/mfd/max77686.c
@@ -121,6 +121,10 @@ static int max77686_i2c_probe(struct i2c_client *i2c,
dev_info(max77686-dev, device found\n);
max77686-rtc = i2c_new_dummy(i2c-adapter, I2C_ADDR_RTC);
+ if (!max77686-rtc) {
+ dev_err(max77686-dev, Failed to allocate I2C device for
RTC\n);
+ return -ENODEV;
+ }
i2c_set_clientdata(max77686-rtc, max77686);
max77686_irq_init(max77686);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/7] mfd: 88pm860x: Fix I2C device resource leak on regmap init fail
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 k.kozlow...@samsung.com Cc: sta...@vger.kernel.org --- drivers/mfd/88pm860x-core.c |1 + 1 file changed, 1 insertion(+) diff --git a/drivers/mfd/88pm860x-core.c b/drivers/mfd/88pm860x-core.c index e456be9a7c67..bcfc9e85b4a0 100644 --- a/drivers/mfd/88pm860x-core.c +++ b/drivers/mfd/88pm860x-core.c @@ -1190,6 +1190,7 @@ static int pm860x_probe(struct i2c_client *client, ret = PTR_ERR(chip-regmap_companion); dev_err(chip-companion-dev, Failed to allocate register map: %d\n, ret); + i2c_unregister_device(chip-companion); return ret; } i2c_set_clientdata(chip-companion, chip); -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 2/3] ARM: dts: add dts files for exynos5260 SoC
Hi Rahul,
On 11.02.2014 06:22, Rahul Sharma wrote:
Hi Tomasz,
On 6 February 2014 18:51, Tomasz Figa t.f...@samsung.com 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 structure with soc node, labels for every node and
node references.
I am unable to find information on SoC node and grouping inside SoC node. Please
share some pointers.
Well, there is not much information needed about this. Basically all the
devices built into the SoC should be listed under respective bus nodes
or a single soc node, instead of root level. Such node should be a
simple-bus and just group the components together to separate
board-specific devices (which are still at root level) from SoC devices.
Even though it might seem useless, it improves DT readability a bit and
still most of the platforms use this approach, so for consistency,
Exynos should use too.
Just for reference, back in April 2013, in his review of S3C64xx DT
series [1], Rob Herring requested that we don't submit any new device
trees using flat approach and start using bus hierarchy.
[1]
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-April/163659.html
+ spi0_bus: spi0-bus {
+ samsung,pins = gpa2-0, gpa2-1, gpa2-2,
gpa2-3;
What is the reason for SPI0 to have 4 pins, while SPI1 has just 3?
I should align SPI1 with SPI0.
Are you sure that SPI0 is the correct one? SPI usually uses four pins -
SDI, SDO, SCK and nCS, but we always used to treat nCS as a simple GPIO,
due to the fact that the controller can only support one dedicated chip
select and with direct GPIO control you can have more.
What is the fourth pin here?
+ cpu@1 {
+ device_type = cpu;
+ compatible = arm,cortex-a15;
+ reg = 1;
+ cci-control-port = cci_control1;
+ };
+ cpu@100 {
+ device_type = cpu;
+ compatible = arm,cortex-a7;
+ reg = 0x100;
+ cci-control-port = cci_control0;
+ };
+ cpu@101 {
+ device_type = cpu;
+ compatible = arm,cortex-a7;
+ reg = 0x101;
+ cci-control-port = cci_control0;
+ };
+ cpu@102 {
+ device_type = cpu;
+ compatible = arm,cortex-a7;
+ reg = 0x102;
+ cci-control-port = cci_control0;
+ };
+ cpu@103 {
+ device_type = cpu;
+ compatible = arm,cortex-a7;
+ reg = 0x103;
+ cci-control-port = cci_control0;
+ };
+ };
+
+ cmus {
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+
I don't think there is a need to group these nodes under a parent node that
doesn't give any additional information, especially when the CMUs are
scattered trough the whole address space, while we'd like to keep the nodes
ordered by their addresses, as most platforms do.
This is exactly the same case as cpus. I mean, cpus also doesn't provide
any common information about child cpu nodes. This looks to me as a logical
grouping and I have implemented same thing for cmu nodes.
I am ok with removing this grouping Just want to understand the rational behind
grouping cpus which seems similar to cmus.
The cpus node is a defined standard node that should be present at
root of device tree and include subnodes for all CPUs. This is a
standard binding defined for low level code to be able to simply find
nodes of all CPUs in the system - so they can expect that at /cpus node
all the subnodes are subsequent CPUs.
Similarly soc is just a logical entity used to group SoC elements which looks
optional to me. What are we achieving with this? Please help me in understanding
this better.
Also soc has a slightly wider meaning. It is a node grouping all nodes
from a single address space - the node specifies #address-cells and
#size-cells of this address space and all the devices under this
simple-bus can be accessed using addresses in this format. In
addition, it separates board-level devices from generic SoC devices.
Now, in case of cmus, the only purpose is to group all CMU nodes
together and, while this improves readability a bit, it doesn't make the
DT better express the hardware topology, because the CMUs in the
hardware are in fact scattered through the whole address space, not
under a contiguous block of it, as the grouping would suggest.
Best regards,
Tomasz
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the
[PATCH 7/7] mfd: max8998: Fix possible NULL pointer dereference on i2c_new_dummy error
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().
If i2c_new_dummy() fails for RTC device, fail also the probe for
main MFD driver.
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
Cc: sta...@vger.kernel.org
---
drivers/mfd/max8998.c |4
1 file changed, 4 insertions(+)
diff --git a/drivers/mfd/max8998.c b/drivers/mfd/max8998.c
index 612ca404e150..61ea1826f8b4 100644
--- a/drivers/mfd/max8998.c
+++ b/drivers/mfd/max8998.c
@@ -215,6 +215,10 @@ static int max8998_i2c_probe(struct i2c_client *i2c,
mutex_init(max8998-iolock);
max8998-rtc = i2c_new_dummy(i2c-adapter, RTC_I2C_ADDR);
+ if (!max8998-rtc) {
+ dev_err(i2c-dev, Failed to allocate I2C device for RTC\n);
+ return -ENODEV;
+ }
i2c_set_clientdata(max8998-rtc, max8998);
max8998_irq_init(max8998);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/7] mfd: max77693: Fix possible NULL pointer dereference on i2c_new_dummy error
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_regmap_init_i2c() and i2c_unregister_device().
If i2c_new_dummy() fails for MUIC or haptic devices, fail also the probe
for main MFD driver.
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
Cc: sta...@vger.kernel.org
---
drivers/mfd/max77693.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/mfd/max77693.c b/drivers/mfd/max77693.c
index e0859987ab6b..c5535f018466 100644
--- a/drivers/mfd/max77693.c
+++ b/drivers/mfd/max77693.c
@@ -148,9 +148,18 @@ static int max77693_i2c_probe(struct i2c_client *i2c,
dev_info(max77693-dev, device ID: 0x%x\n, reg_data);
max77693-muic = i2c_new_dummy(i2c-adapter, I2C_ADDR_MUIC);
+ if (!max77693-muic) {
+ dev_err(max77693-dev, Failed to allocate I2C device for
MUIC\n);
+ return -ENODEV;
+ }
i2c_set_clientdata(max77693-muic, max77693);
max77693-haptic = i2c_new_dummy(i2c-adapter, I2C_ADDR_HAPTIC);
+ if (!max77693-haptic) {
+ dev_err(max77693-dev, Failed to allocate I2C device for
Haptic\n);
+ ret = -ENODEV;
+ goto err_i2c_haptic;
+ }
i2c_set_clientdata(max77693-haptic, max77693);
/*
@@ -184,8 +193,9 @@ err_mfd:
max77693_irq_exit(max77693);
err_irq:
err_regmap_muic:
- i2c_unregister_device(max77693-muic);
i2c_unregister_device(max77693-haptic);
+err_i2c_haptic:
+ i2c_unregister_device(max77693-muic);
return ret;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/7] mfd: max8997: Fix possible NULL pointer dereference on i2c_new_dummy error
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_unregister_device().
If i2c_new_dummy() fails for RTC, haptic or MUIC devices, fail also the
probe for main MFD driver.
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
Cc: sta...@vger.kernel.org
---
drivers/mfd/max8997.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/mfd/max8997.c b/drivers/mfd/max8997.c
index be88a3bf7b85..3ffc11dfc3b6 100644
--- a/drivers/mfd/max8997.c
+++ b/drivers/mfd/max8997.c
@@ -208,10 +208,26 @@ static int max8997_i2c_probe(struct i2c_client *i2c,
mutex_init(max8997-iolock);
max8997-rtc = i2c_new_dummy(i2c-adapter, I2C_ADDR_RTC);
+ if (!max8997-rtc) {
+ dev_err(max8997-dev, Failed to allocate I2C device for
RTC\n);
+ return -ENODEV;
+ }
i2c_set_clientdata(max8997-rtc, max8997);
+
max8997-haptic = i2c_new_dummy(i2c-adapter, I2C_ADDR_HAPTIC);
+ if (!max8997-haptic) {
+ dev_err(max8997-dev, Failed to allocate I2C device for
Haptic\n);
+ ret = -ENODEV;
+ goto err_i2c_haptic;
+ }
i2c_set_clientdata(max8997-haptic, max8997);
+
max8997-muic = i2c_new_dummy(i2c-adapter, I2C_ADDR_MUIC);
+ if (!max8997-muic) {
+ dev_err(max8997-dev, Failed to allocate I2C device for
MUIC\n);
+ ret = -ENODEV;
+ goto err_i2c_muic;
+ }
i2c_set_clientdata(max8997-muic, max8997);
pm_runtime_set_active(max8997-dev);
@@ -239,7 +255,9 @@ static int max8997_i2c_probe(struct i2c_client *i2c,
err_mfd:
mfd_remove_devices(max8997-dev);
i2c_unregister_device(max8997-muic);
+err_i2c_muic:
i2c_unregister_device(max8997-haptic);
+err_i2c_haptic:
i2c_unregister_device(max8997-rtc);
return ret;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/7] mfd: max8925: Fix possible NULL pointer dereference on i2c_new_dummy error
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_unregister_device().
If i2c_new_dummy() fails for RTC or ADC devices, fail also the probe
for main MFD driver.
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
Cc: sta...@vger.kernel.org
---
drivers/mfd/max8925-i2c.c |9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/mfd/max8925-i2c.c b/drivers/mfd/max8925-i2c.c
index 176aa26fc787..a83eed5c15ca 100644
--- a/drivers/mfd/max8925-i2c.c
+++ b/drivers/mfd/max8925-i2c.c
@@ -181,9 +181,18 @@ static int max8925_probe(struct i2c_client *client,
mutex_init(chip-io_lock);
chip-rtc = i2c_new_dummy(chip-i2c-adapter, RTC_I2C_ADDR);
+ if (!chip-rtc) {
+ dev_err(chip-dev, Failed to allocate I2C device for RTC\n);
+ return -ENODEV;
+ }
i2c_set_clientdata(chip-rtc, chip);
chip-adc = i2c_new_dummy(chip-i2c-adapter, ADC_I2C_ADDR);
+ if (!chip-adc) {
+ dev_err(chip-dev, Failed to allocate I2C device for ADC\n);
+ i2c_unregister_device(chip-rtc);
+ return -ENODEV;
+ }
i2c_set_clientdata(chip-adc, chip);
device_init_wakeup(client-dev, 1);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] ARM: EXYNOS: Consolidate Kconfig entries
On 11.02.2014 07:10, Kukjin Kim wrote: 2014-02-10 10:20 GMT+05:30 Sachin Kamat sachin.ka...@linaro.org: On 7 February 2014 22:03, Tomasz Figa t.f...@samsung.com wrote: On 06.02.2014 19:59, Olof Johansson wrote: On Thu, Feb 6, 2014 at 10:43 AM, Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com wrote: Well, once again, seeing some numbers would be good. :) What numbers do you want? Size comparisons with all SoC options on vs only one? Yes, size comparisions with all SoCs (for given family) turned on vs only one turned on (done on kernel without this patch applied). Also size comparisons for ARCH_EXYNOS4 and ARCH_EXYNOS5 both turned on vs only ARCH_EXYNOS4 or ARCH_EXYNOS5 turned on (with this patch applied). exynos_defconfig-based build data below. textdata bss dec hex filename 5109986 319952 270196 5700134 56fa26 obj-tmp/vmlinux # all 4+5 SoCs enabled 5088312 296912 270196 5655420 564b7c obj-tmp/vmlinux # EXYNOS5 off, all EXYNOS4 SoCs enabled 5088032 296896 270196 5655124 564a54 obj-tmp/vmlinux # Only 4210 enabled 5079205 299928 270068 5649201 563331 obj-tmp/vmlinux # EXYNOS4 off, all EXYNOS5 SoCs enabled 5063355 286792 270068 5620215 55c1f7 obj-tmp/vmlinux # Only 5250 enabled 5067815 298152 270068 5636035 55ffc3 obj-tmp/vmlinux# Only 5250+5420 enabled 5053357 278480 269364 5601201 5577b1 obj-tmp/vmlinux # Only 5440 enabled The main difference of disabling 5440 is that it removed the PCI support, which explains that reduction in size. So, I would argue that theere might be some value in disabling whole families (since it saves about 20k of text and the same of data), but that there's less gain per SoC member. 5440 is an oddball in this setup so it might make sense to treat it differently due to the PCI aspect. Well, the numbers basically represent what I expected. Thanks for checking this. Thanks to Olof for coming out with these numbers. So I second this patch even more now, Thanks Tomasz :) but maybe let's change it a bit and introduce third entry for Exynos5440, since it doesn't really belong to either of ARCHs. Candidates that come to my mind are ARCH_EXYNOS5440 (seems to specific) or ARCH_EXYNOS5_SERVER. Feel free to suggest anything better, though. Though Exynos5440 belongs to the Exynos5 family, it is different in a few ways and hence I preferred to keep it as a separate entry for now. I agree with your suggestion to have a third ARCH category but I would prefer to wait for a while until we have one more candidate for this category so that we have a bit more data for naming and grouping. Well, I also, having soc number would be good like 5440 you thought because I can't say upcoming exynos ARMv7 based SoCs are familiar with previous exynos SoCs or not at this moment. And it means sometimes we need to add the numbering and sometime we don't need. It's not fair enough I think. And I have strong objection on Thomasz' suggestion about ARCH_EXYNOS5_SERVER? Please don't guess. As I said, feel free to suggest anything better. I just came up with 2 examples. The fact that Exynos 5440 does not have much in common with other Exynos 5 SoCs is completely obvious and so a third option should be present in Kconfig, to not enable 5440 if you want support for just the other Exynos 5 SoCs and vice versa. Best regards, Tomasz -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] ARM: EXYNOS: Consolidate Kconfig entries
On 11.02.2014 07:30, Olof Johansson wrote: Hi, On Mon, Feb 10, 2014 at 10:10 PM, Kukjin Kim kgene@gmail.com wrote: 2014-02-10 10:20 GMT+05:30 Sachin Kamat sachin.ka...@linaro.org: On 7 February 2014 22:03, Tomasz Figa t.f...@samsung.com wrote: On 06.02.2014 19:59, Olof Johansson wrote: On Thu, Feb 6, 2014 at 10:43 AM, Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com wrote: Well, once again, seeing some numbers would be good. :) What numbers do you want? Size comparisons with all SoC options on vs only one? Yes, size comparisions with all SoCs (for given family) turned on vs only one turned on (done on kernel without this patch applied). Also size comparisons for ARCH_EXYNOS4 and ARCH_EXYNOS5 both turned on vs only ARCH_EXYNOS4 or ARCH_EXYNOS5 turned on (with this patch applied). exynos_defconfig-based build data below. textdata bss dec hex filename 5109986 319952 270196 5700134 56fa26 obj-tmp/vmlinux # all 4+5 SoCs enabled 5088312 296912 270196 5655420 564b7c obj-tmp/vmlinux # EXYNOS5 off, all EXYNOS4 SoCs enabled 5088032 296896 270196 5655124 564a54 obj-tmp/vmlinux # Only 4210 enabled 5079205 299928 270068 5649201 563331 obj-tmp/vmlinux # EXYNOS4 off, all EXYNOS5 SoCs enabled 5063355 286792 270068 5620215 55c1f7 obj-tmp/vmlinux # Only 5250 enabled 5067815 298152 270068 5636035 55ffc3 obj-tmp/vmlinux# Only 5250+5420 enabled 5053357 278480 269364 5601201 5577b1 obj-tmp/vmlinux # Only 5440 enabled The main difference of disabling 5440 is that it removed the PCI support, which explains that reduction in size. So, I would argue that theere might be some value in disabling whole families (since it saves about 20k of text and the same of data), but that there's less gain per SoC member. 5440 is an oddball in this setup so it might make sense to treat it differently due to the PCI aspect. Well, the numbers basically represent what I expected. Thanks for checking this. Thanks to Olof for coming out with these numbers. So I second this patch even more now, Thanks Tomasz :) but maybe let's change it a bit and introduce third entry for Exynos5440, since it doesn't really belong to either of ARCHs. Candidates that come to my mind are ARCH_EXYNOS5440 (seems to specific) or ARCH_EXYNOS5_SERVER. Feel free to suggest anything better, though. Though Exynos5440 belongs to the Exynos5 family, it is different in a few ways and hence I preferred to keep it as a separate entry for now. I agree with your suggestion to have a third ARCH category but I would prefer to wait for a while until we have one more candidate for this category so that we have a bit more data for naming and grouping. Well, I also, having soc number would be good like 5440 you thought because I can't say upcoming exynos ARMv7 based SoCs are familiar with previous exynos SoCs or not at this moment. And it means sometimes we need to add the numbering and sometime we don't need. It's not fair enough I think. And I have strong objection on Thomasz' suggestion about ARCH_EXYNOS5_SERVER? Please don't guess. Well, we know that we do not want to see new options for every single new SoC that are similar to existing ones. It's just not needed, as the size comparisons above shows. So, I think today, we should have three options: EXYNOS4 EXYNOS5 EXYNOS5440 5440 can depend on EXYNOS5 today if it makes sense. Only reason to let it have its own option is that it's substantially different from the others in that it pulls in PCI and causes kernel size to go up. Well, hardware-wise it's completely different. Even the pin controller needs a separate driver (pinctrl-exynos5440.c vs pinctrl-exynos.c+pinctrl-samsung.c), so I believe a third option is completely justified. If other SoCs are added that are quire similar to 5440, then the right option is probably to group them under an option together with 5440. It doesn't matter if it's called server or something else as long as they're mostly kept together. And for now that's just theoretical anwyay: Let's keep calling it 5440 until there's reason to change it. Fair enough. That was basically my first proposal, which sounded a bit too specific to me, but I guess it can't be helped. Best regards, Tomasz -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/7] mfd: max77686: Fix possible NULL pointer dereference on i2c_new_dummy error
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 returns NULL which is later used
by i2c_unregister_device().
If i2c_new_dummy() fails for RTC device, fail also the probe for main
MFD driver.
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
Cc: sta...@vger.kernel.org
---
drivers/mfd/max77686.c |4
1 file changed, 4 insertions(+)
diff --git a/drivers/mfd/max77686.c b/drivers/mfd/max77686.c
index f53d5823a3f7..e5fce765accb 100644
--- a/drivers/mfd/max77686.c
+++ b/drivers/mfd/max77686.c
@@ -121,6 +121,10 @@ static int max77686_i2c_probe(struct i2c_client *i2c,
dev_info(max77686-dev, device found\n);
max77686-rtc = i2c_new_dummy(i2c-adapter, I2C_ADDR_RTC);
+ if (!max77686-rtc) {
+ dev_err(max77686-dev, Failed to allocate I2C device for
RTC\n);
+ return -ENODEV;
+ }
i2c_set_clientdata(max77686-rtc, max77686);
max77686_irq_init(max77686);
Applied, thanks.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/7] mfd: 88pm860x: Fix possible NULL pointer dereference on i2c_new_dummy error
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) this function returns NULL which is later used
by regmap_init_i2c().
If i2c_new_dummy() fails for companion device, fail also the probe for
main MFD driver.
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
Cc: sta...@vger.kernel.org
---
drivers/mfd/88pm860x-core.c |5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/mfd/88pm860x-core.c b/drivers/mfd/88pm860x-core.c
index c9b1f6422941..e456be9a7c67 100644
--- a/drivers/mfd/88pm860x-core.c
+++ b/drivers/mfd/88pm860x-core.c
@@ -1179,6 +1179,11 @@ static int pm860x_probe(struct i2c_client *client,
chip-companion_addr = pdata-companion_addr;
chip-companion = i2c_new_dummy(chip-client-adapter,
chip-companion_addr);
+ if (!chip-companion) {
+ dev_err(client-dev,
+ Failed to allocate I2C companion device\n);
+ return -ENODEV;
+ }
chip-regmap_companion = regmap_init_i2c(chip-companion,
pm860x_regmap_config);
if (IS_ERR(chip-regmap_companion)) {
Applied, thanks.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/7] mfd: max8997: Fix possible NULL pointer dereference on i2c_new_dummy error
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 be used) this function returns NULL which is later used
by i2c_unregister_device().
If i2c_new_dummy() fails for RTC, haptic or MUIC devices, fail also the
probe for main MFD driver.
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
Cc: sta...@vger.kernel.org
---
drivers/mfd/max8997.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/mfd/max8997.c b/drivers/mfd/max8997.c
index be88a3bf7b85..3ffc11dfc3b6 100644
--- a/drivers/mfd/max8997.c
+++ b/drivers/mfd/max8997.c
@@ -208,10 +208,26 @@ static int max8997_i2c_probe(struct i2c_client *i2c,
mutex_init(max8997-iolock);
max8997-rtc = i2c_new_dummy(i2c-adapter, I2C_ADDR_RTC);
+ if (!max8997-rtc) {
+ dev_err(max8997-dev, Failed to allocate I2C device for
RTC\n);
+ return -ENODEV;
+ }
i2c_set_clientdata(max8997-rtc, max8997);
+
max8997-haptic = i2c_new_dummy(i2c-adapter, I2C_ADDR_HAPTIC);
+ if (!max8997-haptic) {
+ dev_err(max8997-dev, Failed to allocate I2C device for
Haptic\n);
+ ret = -ENODEV;
+ goto err_i2c_haptic;
+ }
i2c_set_clientdata(max8997-haptic, max8997);
+
max8997-muic = i2c_new_dummy(i2c-adapter, I2C_ADDR_MUIC);
+ if (!max8997-muic) {
+ dev_err(max8997-dev, Failed to allocate I2C device for
MUIC\n);
+ ret = -ENODEV;
+ goto err_i2c_muic;
+ }
i2c_set_clientdata(max8997-muic, max8997);
pm_runtime_set_active(max8997-dev);
@@ -239,7 +255,9 @@ static int max8997_i2c_probe(struct i2c_client *i2c,
err_mfd:
mfd_remove_devices(max8997-dev);
i2c_unregister_device(max8997-muic);
+err_i2c_muic:
i2c_unregister_device(max8997-haptic);
+err_i2c_haptic:
i2c_unregister_device(max8997-rtc);
return ret;
}
Applied, thanks.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 7/7] mfd: max8998: Fix possible NULL pointer dereference on i2c_new_dummy error
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 returns NULL which is later used
by i2c_unregister_device().
If i2c_new_dummy() fails for RTC device, fail also the probe for
main MFD driver.
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
Cc: sta...@vger.kernel.org
---
drivers/mfd/max8998.c |4
1 file changed, 4 insertions(+)
diff --git a/drivers/mfd/max8998.c b/drivers/mfd/max8998.c
index 612ca404e150..61ea1826f8b4 100644
--- a/drivers/mfd/max8998.c
+++ b/drivers/mfd/max8998.c
@@ -215,6 +215,10 @@ static int max8998_i2c_probe(struct i2c_client *i2c,
mutex_init(max8998-iolock);
max8998-rtc = i2c_new_dummy(i2c-adapter, RTC_I2C_ADDR);
+ if (!max8998-rtc) {
+ dev_err(i2c-dev, Failed to allocate I2C device for RTC\n);
+ return -ENODEV;
+ }
i2c_set_clientdata(max8998-rtc, max8998);
max8998_irq_init(max8998);
Applied, thanks.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/7] mfd: max8925: Fix possible NULL pointer dereference on i2c_new_dummy error
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) this function returns NULL which is later used
by i2c_unregister_device().
If i2c_new_dummy() fails for RTC or ADC devices, fail also the probe
for main MFD driver.
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
Cc: sta...@vger.kernel.org
---
drivers/mfd/max8925-i2c.c |9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/mfd/max8925-i2c.c b/drivers/mfd/max8925-i2c.c
index 176aa26fc787..a83eed5c15ca 100644
--- a/drivers/mfd/max8925-i2c.c
+++ b/drivers/mfd/max8925-i2c.c
@@ -181,9 +181,18 @@ static int max8925_probe(struct i2c_client *client,
mutex_init(chip-io_lock);
chip-rtc = i2c_new_dummy(chip-i2c-adapter, RTC_I2C_ADDR);
+ if (!chip-rtc) {
+ dev_err(chip-dev, Failed to allocate I2C device for RTC\n);
+ return -ENODEV;
+ }
i2c_set_clientdata(chip-rtc, chip);
chip-adc = i2c_new_dummy(chip-i2c-adapter, ADC_I2C_ADDR);
+ if (!chip-adc) {
+ dev_err(chip-dev, Failed to allocate I2C device for ADC\n);
+ i2c_unregister_device(chip-rtc);
+ return -ENODEV;
+ }
i2c_set_clientdata(chip-adc, chip);
device_init_wakeup(client-dev, 1);
Applied, thanks.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/7] mfd: max77693: Fix possible NULL pointer dereference on i2c_new_dummy error
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 used) this function returns NULL which is later used
by devm_regmap_init_i2c() and i2c_unregister_device().
If i2c_new_dummy() fails for MUIC or haptic devices, fail also the probe
for main MFD driver.
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
Cc: sta...@vger.kernel.org
---
drivers/mfd/max77693.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/mfd/max77693.c b/drivers/mfd/max77693.c
index e0859987ab6b..c5535f018466 100644
--- a/drivers/mfd/max77693.c
+++ b/drivers/mfd/max77693.c
@@ -148,9 +148,18 @@ static int max77693_i2c_probe(struct i2c_client *i2c,
dev_info(max77693-dev, device ID: 0x%x\n, reg_data);
max77693-muic = i2c_new_dummy(i2c-adapter, I2C_ADDR_MUIC);
+ if (!max77693-muic) {
+ dev_err(max77693-dev, Failed to allocate I2C device for
MUIC\n);
+ return -ENODEV;
+ }
i2c_set_clientdata(max77693-muic, max77693);
max77693-haptic = i2c_new_dummy(i2c-adapter, I2C_ADDR_HAPTIC);
+ if (!max77693-haptic) {
+ dev_err(max77693-dev, Failed to allocate I2C device for
Haptic\n);
+ ret = -ENODEV;
+ goto err_i2c_haptic;
+ }
i2c_set_clientdata(max77693-haptic, max77693);
/*
@@ -184,8 +193,9 @@ err_mfd:
max77693_irq_exit(max77693);
err_irq:
err_regmap_muic:
- i2c_unregister_device(max77693-muic);
i2c_unregister_device(max77693-haptic);
+err_i2c_haptic:
+ i2c_unregister_device(max77693-muic);
return ret;
}
Applied, thanks.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/7] mfd: 88pm860x: Fix I2C device resource leak on regmap init fail
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: Krzysztof Kozlowski k.kozlow...@samsung.com Cc: sta...@vger.kernel.org --- drivers/mfd/88pm860x-core.c |1 + 1 file changed, 1 insertion(+) diff --git a/drivers/mfd/88pm860x-core.c b/drivers/mfd/88pm860x-core.c index e456be9a7c67..bcfc9e85b4a0 100644 --- a/drivers/mfd/88pm860x-core.c +++ b/drivers/mfd/88pm860x-core.c @@ -1190,6 +1190,7 @@ static int pm860x_probe(struct i2c_client *client, ret = PTR_ERR(chip-regmap_companion); dev_err(chip-companion-dev, Failed to allocate register map: %d\n, ret); + i2c_unregister_device(chip-companion); return ret; } i2c_set_clientdata(chip-companion, chip); Applied, thanks. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 04/14] rtc: s5m: Remove undocumented time init on first boot
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 will be initialized with reset value (2000-01-01
00:00:00).
The code might work on S5M8763 but still this does not look like a task
for RTC driver.
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
Cc: Alessandro Zummo a.zu...@towertech.it
Cc: rtc-li...@googlegroups.com
---
drivers/rtc/rtc-s5m.c | 30 --
1 file changed, 30 deletions(-)
diff --git a/drivers/rtc/rtc-s5m.c b/drivers/rtc/rtc-s5m.c
index d26e2480f8b3..b1627e9ab8f0 100644
--- a/drivers/rtc/rtc-s5m.c
+++ b/drivers/rtc/rtc-s5m.c
@@ -502,16 +502,7 @@ static void s5m_rtc_enable_smpl(struct s5m_rtc_info *info,
bool enable)
static int s5m8767_rtc_init_reg(struct s5m_rtc_info *info)
{
u8 data[2];
- unsigned int tp_read;
int ret;
- struct rtc_time tm;
-
- ret = regmap_read(info-regmap, S5M_RTC_UDR_CON, tp_read);
- if (ret 0) {
- dev_err(info-dev, %s: fail to read control reg(%d)\n,
- __func__, ret);
- return ret;
- }
/* Set RTC control register : Binary mode, 24hour mode */
data[0] = (1 BCD_EN_SHIFT) | (1 MODEL24_SHIFT);
@@ -525,27 +516,6 @@ static int s5m8767_rtc_init_reg(struct s5m_rtc_info *info)
return ret;
}
- /* In first boot time, Set rtc time to 1/1/2012 00:00:00(SUN) */
- if ((tp_read RTC_TCON_MASK) == 0) {
- dev_dbg(info-dev, rtc init\n);
- tm.tm_sec = 0;
- tm.tm_min = 0;
- tm.tm_hour = 0;
- tm.tm_wday = 0;
- tm.tm_mday = 1;
- tm.tm_mon = 0;
- tm.tm_year = 112;
- tm.tm_yday = 0;
- tm.tm_isdst = 0;
- ret = s5m_rtc_set_time(info-dev, tm);
- }
-
- ret = regmap_update_bits(info-regmap, S5M_RTC_UDR_CON,
-RTC_TCON_MASK, tp_read | RTC_TCON_MASK);
- if (ret 0)
- dev_err(info-dev, %s: fail to update TCON reg(%d)\n,
- __func__, ret);
-
return ret;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/14] mfd/regulator/rtc: sec: Add support for S2MPS14
Hi, This patchset adds support for S2MPS14 device to the Samsung MFD driver family. The S2MPS14 is similar to S2MPS11 but it has fewer regulators, two clocks instead of three and a little different registers layout. The patchset is organized in following way: 1. Patches from 1 to 7 clean up the S2MPS1X/S5M876X drivers and prepare for adding S2MPS14 support (some symbol renaming is needed). 2. Patches from 8 to 10 add support for S2MPS14 to the MFD and regulator drivers. They depend on previous patches. 3. Patches 11 and 12 add opmode support for S2MPS14 regulator driver. 4. Patches 13 and 14 add support for S2MPS14 RTC and they depend on previous MFD and RTC patches. Probably the best way to get everything working and merged into the linux-next would be to obtain ACK-s from all maintainers and to put all the patches into the mfd-next tree. The patchset is based on linux-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://thread.gmane.org/gmane.linux.kernel/1587881/focus=1587882 which didn't get their way into clk-next. I will wait for them. Krzysztof Kozlowski (14): mfd: sec: Add maximum RTC register for regmap config mfd: sec: Select different RTC regmaps for devices mfd/rtc: sec/sec: Rename SEC* symbols to S5M rtc: s5m: Remove undocumented time init on first boot mfd: sec: Use consistent S2MPS11 RTC alarm interrupt indexes regulator: s2mps11: Constify regulator_desc array regulator: s2mps11: Choose number of supported regulators during probe mfd: sec: Add support for S2MPS14 regulator: s2mps11: Add support for S2MPS14 regulators Documentation: mfd: s2mps11: Document support for S2MPS14 regulator: s2mps11: Add opmode for S2MPS14 regulators Documentation: mfd/regulator: s2mps11: Document the op_mode bindings rtc: s5m: Support different register layout rtc: s5m: Add support for S2MPS14 RTC Documentation/devicetree/bindings/mfd/s2mps11.txt | 58 ++- drivers/mfd/sec-core.c| 57 ++- drivers/mfd/sec-irq.c | 97 - drivers/regulator/s2mps11.c | 393 + drivers/rtc/rtc-s5m.c | 284 ++- include/linux/mfd/samsung/core.h |1 + include/linux/mfd/samsung/irq.h | 31 +- include/linux/mfd/samsung/rtc.h | 132 --- include/linux/mfd/samsung/s2mps14.h | 169 + 9 files changed, 1000 insertions(+), 222 deletions(-) create mode 100644 include/linux/mfd/samsung/s2mps14.h -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/14] Documentation: mfd: s2mps11: Document support for S2MPS14
Add bindings documentation for S2MPS14 device to the s2mps11 driver. Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com Cc: Mark Brown broo...@kernel.org Cc: Liam Girdwood lgirdw...@gmail.com Cc: Tomasz Figa t.f...@samsung.com Cc: devicet...@vger.kernel.org Cc: Rob Herring robh...@kernel.org Cc: Pawel Moll pawel.m...@arm.com Cc: Mark Rutland mark.rutl...@arm.com Cc: Ian Campbell ijc+devicet...@hellion.org.uk Cc: Kumar Gala ga...@codeaurora.org --- Documentation/devicetree/bindings/mfd/s2mps11.txt | 12 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/Documentation/devicetree/bindings/mfd/s2mps11.txt b/Documentation/devicetree/bindings/mfd/s2mps11.txt index 15ee89c3cc7b..f69bec294f02 100644 --- a/Documentation/devicetree/bindings/mfd/s2mps11.txt +++ b/Documentation/devicetree/bindings/mfd/s2mps11.txt @@ -1,5 +1,5 @@ -* Samsung S2MPS11 Voltage and Current Regulator +* Samsung S2MPS11 and S2MPS14 Voltage and Current Regulator The Samsung S2MPS11 is a multi-function device which includes voltage and current regulators, RTC, charger controller and other sub-blocks. It is @@ -7,7 +7,7 @@ interfaced to the host controller using an I2C interface. Each sub-block is addressed by the host system using different I2C slave addresses. Required properties: -- compatible: Should be samsung,s2mps11-pmic. +- compatible: Should be samsung,s2mps11-pmic or samsung,s2mps14-pmic. - reg: Specifies the I2C slave address of the pmic block. It should be 0x66. Optional properties: @@ -59,10 +59,14 @@ supports. Note: The 'n' in LDOn and BUCKn represents the LDO or BUCK number as per the datasheet of s2mps11. - LDOn - - valid values for n are 1 to 38 + - valid values for n are: + - S2MPS11: 1 to 38 + - S2MPS14: 1 to 25 - Example: LDO1, LD02, LDO28 - BUCKn - - valid values for n are 1 to 10. + - valid values for n are: + - S2MPS11: 1 to 10 + - S2MPS14: 1 to 5 - Example: BUCK1, BUCK2, BUCK9 Example: -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 07/14] regulator: s2mps11: Choose number of supported regulators during probe
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 regulator driver for supporting the
S2MPS14 device.
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Cc: Mark Brown broo...@kernel.org
Cc: Liam Girdwood lgirdw...@gmail.com
---
drivers/regulator/s2mps11.c | 46 +--
1 file changed, 36 insertions(+), 10 deletions(-)
diff --git a/drivers/regulator/s2mps11.c b/drivers/regulator/s2mps11.c
index d44bd5b3fe8e..43a2eefb9aa4 100644
--- a/drivers/regulator/s2mps11.c
+++ b/drivers/regulator/s2mps11.c
@@ -25,10 +25,9 @@
#include linux/mfd/samsung/core.h
#include linux/mfd/samsung/s2mps11.h
-#define S2MPS11_REGULATOR_CNT ARRAY_SIZE(regulators)
-
struct s2mps11_info {
- struct regulator_dev *rdev[S2MPS11_REGULATOR_MAX];
+ struct regulator_dev **rdev;
+ unsigned int rdev_num;
int ramp_delay2;
int ramp_delay34;
@@ -345,7 +344,7 @@ static struct regulator_ops s2mps11_buck_ops = {
.enable_mask= S2MPS11_ENABLE_MASK \
}
-static const struct regulator_desc regulators[] = {
+static const struct regulator_desc s2mps11_regulators[] = {
regulator_desc_ldo2(1),
regulator_desc_ldo1(2),
regulator_desc_ldo1(3),
@@ -399,18 +398,31 @@ static const struct regulator_desc regulators[] = {
static int s2mps11_pmic_probe(struct platform_device *pdev)
{
struct sec_pmic_dev *iodev = dev_get_drvdata(pdev-dev.parent);
- struct sec_platform_data *pdata = dev_get_platdata(iodev-dev);
- struct of_regulator_match rdata[S2MPS11_REGULATOR_MAX];
+ struct sec_platform_data *pdata = iodev-pdata;
+ struct of_regulator_match *rdata = NULL;
struct device_node *reg_np = NULL;
struct regulator_config config = { };
struct s2mps11_info *s2mps11;
int i, ret;
+ const struct regulator_desc *regulators;
+ enum sec_device_type dev_type;
s2mps11 = devm_kzalloc(pdev-dev, sizeof(struct s2mps11_info),
GFP_KERNEL);
if (!s2mps11)
return -ENOMEM;
+ dev_type = platform_get_device_id(pdev)-driver_data;
+ switch (dev_type) {
+ case S2MPS11X:
+ s2mps11-rdev_num = ARRAY_SIZE(s2mps11_regulators);
+ regulators = s2mps11_regulators;
+ break;
+ default:
+ dev_err(pdev-dev, Invalid device type: %u\n, dev_type);
+ return -EINVAL;
+ };
+
if (!iodev-dev-of_node) {
if (pdata) {
goto common_reg;
@@ -421,7 +433,17 @@ static int s2mps11_pmic_probe(struct platform_device *pdev)
}
}
- for (i = 0; i S2MPS11_REGULATOR_CNT; i++)
+ s2mps11-rdev = devm_kzalloc(pdev-dev,
+ sizeof(*s2mps11-rdev)*s2mps11-rdev_num, GFP_KERNEL);
+ if (!s2mps11-rdev)
+ return -ENOMEM;
+
+ rdata = devm_kzalloc(pdev-dev, sizeof(*rdata)*s2mps11-rdev_num,
+ GFP_KERNEL);
+ if (!rdata)
+ return -ENOMEM;
+
+ for (i = 0; i s2mps11-rdev_num; i++)
rdata[i].name = regulators[i].name;
reg_np = of_find_node_by_name(iodev-dev-of_node, regulators);
@@ -430,7 +452,7 @@ static int s2mps11_pmic_probe(struct platform_device *pdev)
return -EINVAL;
}
- of_regulator_match(pdev-dev, reg_np, rdata, S2MPS11_REGULATOR_MAX);
+ of_regulator_match(pdev-dev, reg_np, rdata, s2mps11-rdev_num);
common_reg:
platform_set_drvdata(pdev, s2mps11);
@@ -438,7 +460,7 @@ common_reg:
config.dev = pdev-dev;
config.regmap = iodev-regmap_pmic;
config.driver_data = s2mps11;
- for (i = 0; i S2MPS11_REGULATOR_MAX; i++) {
+ for (i = 0; i s2mps11-rdev_num; i++) {
if (!reg_np) {
config.init_data = pdata-regulators[i].initdata;
config.of_node = pdata-regulators[i].reg_node;
@@ -457,11 +479,15 @@ common_reg:
}
}
+ /* rdata was needed only for of_regulator_match() during probe */
+ if (rdata)
+ devm_kfree(pdev-dev, rdata);
+
return 0;
}
static const struct platform_device_id s2mps11_pmic_id[] = {
- { s2mps11-pmic, 0},
+ { s2mps11-pmic, S2MPS11X},
{ },
};
MODULE_DEVICE_TABLE(platform, s2mps11_pmic_id);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 08/14] mfd: sec: Add support for S2MPS14
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 k.kozlow...@samsung.com
---
drivers/mfd/sec-core.c | 48 +--
drivers/mfd/sec-irq.c | 89 +++-
include/linux/mfd/samsung/core.h|1 +
include/linux/mfd/samsung/irq.h | 27 +++
include/linux/mfd/samsung/rtc.h | 56 +++--
include/linux/mfd/samsung/s2mps14.h | 152 +++
6 files changed, 361 insertions(+), 12 deletions(-)
create mode 100644 include/linux/mfd/samsung/s2mps14.h
diff --git a/drivers/mfd/sec-core.c b/drivers/mfd/sec-core.c
index 8504de82b7e0..6e5343255633 100644
--- a/drivers/mfd/sec-core.c
+++ b/drivers/mfd/sec-core.c
@@ -27,6 +27,7 @@
#include linux/mfd/samsung/irq.h
#include linux/mfd/samsung/rtc.h
#include linux/mfd/samsung/s2mps11.h
+#include linux/mfd/samsung/s2mps14.h
#include linux/mfd/samsung/s5m8763.h
#include linux/mfd/samsung/s5m8767.h
#include linux/regmap.h
@@ -69,6 +70,16 @@ static const struct mfd_cell s2mps11_devs[] = {
}
};
+static const struct mfd_cell s2mps14_devs[] = {
+ {
+ .name = s2mps14-pmic,
+ }, {
+ .name = s2mps14-rtc,
+ }, {
+ .name = s2mps14-clk,
+ }
+};
+
#ifdef CONFIG_OF
static struct of_device_id sec_dt_match[] = {
{ .compatible = samsung,s5m8767-pmic,
@@ -77,6 +88,9 @@ static struct of_device_id sec_dt_match[] = {
{ .compatible = samsung,s2mps11-pmic,
.data = (void *)S2MPS11X,
},
+ { .compatible = samsung,s2mps14-pmic,
+ .data = (void *)S2MPS14X,
+ },
{},
};
#endif
@@ -120,6 +134,15 @@ static const struct regmap_config s2mps11_regmap_config = {
.cache_type = REGCACHE_FLAT,
};
+static const struct regmap_config s2mps14_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+
+ .max_register = S2MPS14_REG_LDODSCH3,
+ .volatile_reg = s2mps11_volatile,
+ .cache_type = REGCACHE_FLAT,
+};
+
static const struct regmap_config s5m8763_regmap_config = {
.reg_bits = 8,
.val_bits = 8,
@@ -138,13 +161,20 @@ static const struct regmap_config s5m8767_regmap_config =
{
.cache_type = REGCACHE_FLAT,
};
-static const struct regmap_config sec_rtc_regmap_config = {
+static const struct regmap_config s5m_rtc_regmap_config = {
.reg_bits = 8,
.val_bits = 8,
.max_register = S5M_RTC_REG_MAX,
};
+static const struct regmap_config s2mps14_rtc_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+
+ .max_register = S2MPS_RTC_REG_MAX,
+};
+
#ifdef CONFIG_OF
/*
* Only the common platform data elements for s5m8767 are parsed here from the
@@ -239,19 +269,23 @@ static int sec_pmic_probe(struct i2c_client *i2c,
* However we must pass something to devm_regmap_init_i2c()
* so use S5M-like regmap config even though it wouldn't work.
*/
- regmap_rtc = sec_rtc_regmap_config;
+ regmap_rtc = s5m_rtc_regmap_config;
+ break;
+ case S2MPS14X:
+ regmap = s2mps14_regmap_config;
+ regmap_rtc = s2mps14_rtc_regmap_config;
break;
case S5M8763X:
regmap = s5m8763_regmap_config;
- regmap_rtc = sec_rtc_regmap_config;
+ regmap_rtc = s5m_rtc_regmap_config;
break;
case S5M8767X:
regmap = s5m8767_regmap_config;
- regmap_rtc = sec_rtc_regmap_config;
+ regmap_rtc = s5m_rtc_regmap_config;
break;
default:
regmap = sec_regmap_config;
- regmap_rtc = sec_rtc_regmap_config;
+ regmap_rtc = s5m_rtc_regmap_config;
break;
}
@@ -302,6 +336,10 @@ static int sec_pmic_probe(struct i2c_client *i2c,
ret = mfd_add_devices(sec_pmic-dev, -1, s2mps11_devs,
ARRAY_SIZE(s2mps11_devs), NULL, 0, NULL);
break;
+ case S2MPS14X:
+ ret = mfd_add_devices(sec_pmic-dev, -1, s2mps14_devs,
+ ARRAY_SIZE(s2mps14_devs), NULL, 0, NULL);
+ break;
default:
/* If this happens the probe function is problem */
BUG();
diff --git a/drivers/mfd/sec-irq.c b/drivers/mfd/sec-irq.c
index e403c293b437..64e7913aadc6 100644
--- a/drivers/mfd/sec-irq.c
+++ b/drivers/mfd/sec-irq.c
@@ -1,7 +1,7 @@
/*
* sec-irq.c
*
- * Copyright (c) 2011 Samsung Electronics Co., Ltd
+ * Copyright (c) 2011-2014 Samsung Electronics Co., Ltd
* http://www.samsung.com
*
* This program is free software; you can
[PATCH 09/14] regulator: s2mps11: Add support for S2MPS14 regulators
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 k.kozlow...@samsung.com
Cc: Mark Brown broo...@kernel.org
Cc: Liam Girdwood lgirdw...@gmail.com
---
drivers/regulator/s2mps11.c | 251 ---
1 file changed, 190 insertions(+), 61 deletions(-)
diff --git a/drivers/regulator/s2mps11.c b/drivers/regulator/s2mps11.c
index 43a2eefb9aa4..c37869fb6c7a 100644
--- a/drivers/regulator/s2mps11.c
+++ b/drivers/regulator/s2mps11.c
@@ -1,13 +1,18 @@
/*
* s2mps11.c
*
- * Copyright (c) 2012 Samsung Electronics Co., Ltd
+ * Copyright (c) 2012-2014 Samsung Electronics Co., Ltd
* http://www.samsung.com
*
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the
- * Free Software Foundation; either version 2 of the License, or (at your
- * option) any later version.
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
*
*/
@@ -24,6 +29,7 @@
#include linux/regulator/of_regulator.h
#include linux/mfd/samsung/core.h
#include linux/mfd/samsung/s2mps11.h
+#include linux/mfd/samsung/s2mps14.h
struct s2mps11_info {
struct regulator_dev **rdev;
@@ -235,7 +241,7 @@ static struct regulator_ops s2mps11_buck_ops = {
.set_ramp_delay = s2mps11_set_ramp_delay,
};
-#define regulator_desc_ldo1(num) { \
+#define regulator_desc_s2mps11_ldo1(num) { \
.name = LDO#num,\
.id = S2MPS11_LDO##num, \
.ops= s2mps11_ldo_ops, \
@@ -249,7 +255,7 @@ static struct regulator_ops s2mps11_buck_ops = {
.enable_reg = S2MPS11_REG_L1CTRL + num - 1, \
.enable_mask= S2MPS11_ENABLE_MASK \
}
-#define regulator_desc_ldo2(num) { \
+#define regulator_desc_s2mps11_ldo2(num) { \
.name = LDO#num,\
.id = S2MPS11_LDO##num, \
.ops= s2mps11_ldo_ops, \
@@ -264,7 +270,7 @@ static struct regulator_ops s2mps11_buck_ops = {
.enable_mask= S2MPS11_ENABLE_MASK \
}
-#define regulator_desc_buck1_4(num){ \
+#define regulator_desc_s2mps11_buck1_4(num) { \
.name = BUCK#num, \
.id = S2MPS11_BUCK##num,\
.ops= s2mps11_buck_ops,\
@@ -280,7 +286,7 @@ static struct regulator_ops s2mps11_buck_ops = {
.enable_mask= S2MPS11_ENABLE_MASK \
}
-#define regulator_desc_buck5 { \
+#define regulator_desc_s2mps11_buck5 { \
.name = BUCK5, \
.id = S2MPS11_BUCK5,\
.ops= s2mps11_buck_ops,\
@@ -296,7 +302,7 @@ static struct regulator_ops s2mps11_buck_ops = {
.enable_mask= S2MPS11_ENABLE_MASK \
}
-#define regulator_desc_buck6_8(num){ \
+#define regulator_desc_s2mps11_buck6_8(num) { \
.name = BUCK#num, \
.id = S2MPS11_BUCK##num,\
.ops= s2mps11_buck_ops,\
@@ -312,7 +318,7 @@ static struct regulator_ops s2mps11_buck_ops = {
.enable_mask= S2MPS11_ENABLE_MASK \
}
-#define regulator_desc_buck9 { \
+#define regulator_desc_s2mps11_buck9 { \
.name = BUCK9, \
.id = S2MPS11_BUCK9,\
.ops= s2mps11_buck_ops,\
@@ -328,7 +334,7 @@ static struct regulator_ops s2mps11_buck_ops = {
.enable_mask= S2MPS11_ENABLE_MASK \
}
-#define regulator_desc_buck10 { \
+#define regulator_desc_s2mps11_buck10 {\
.name = BUCK10, \
.id = S2MPS11_BUCK10,
[PATCH 02/14] mfd: sec: Select different RTC regmaps for devices
This patch prepares for adding support for S2MPS14 RTC driver by
selecting different regmaps for S2MPS1X/S5M876X RTC devices.
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
---
drivers/mfd/sec-core.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/mfd/sec-core.c b/drivers/mfd/sec-core.c
index 6021c54f74cf..0efa69e123ee 100644
--- a/drivers/mfd/sec-core.c
+++ b/drivers/mfd/sec-core.c
@@ -199,7 +199,7 @@ static int sec_pmic_probe(struct i2c_client *i2c,
const struct i2c_device_id *id)
{
struct sec_platform_data *pdata = dev_get_platdata(i2c-dev);
- const struct regmap_config *regmap;
+ const struct regmap_config *regmap, *regmap_rtc;
struct sec_pmic_dev *sec_pmic;
int ret;
@@ -233,15 +233,25 @@ static int sec_pmic_probe(struct i2c_client *i2c,
switch (sec_pmic-device_type) {
case S2MPS11X:
regmap = s2mps11_regmap_config;
+ /*
+* The rtc-s5m driver does not support S2MPS11 and there
+* is no mfd_cell for S2MPS11 RTC device.
+* However we must pass something to devm_regmap_init_i2c()
+* so use S5M-like regmap config even though it wouldn't work.
+*/
+ regmap_rtc = sec_rtc_regmap_config;
break;
case S5M8763X:
regmap = s5m8763_regmap_config;
+ regmap_rtc = sec_rtc_regmap_config;
break;
case S5M8767X:
regmap = s5m8767_regmap_config;
+ regmap_rtc = sec_rtc_regmap_config;
break;
default:
regmap = sec_regmap_config;
+ regmap_rtc = sec_rtc_regmap_config;
break;
}
@@ -260,8 +270,7 @@ static int sec_pmic_probe(struct i2c_client *i2c,
}
i2c_set_clientdata(sec_pmic-rtc, sec_pmic);
- sec_pmic-regmap_rtc = devm_regmap_init_i2c(sec_pmic-rtc,
- sec_rtc_regmap_config);
+ sec_pmic-regmap_rtc = devm_regmap_init_i2c(sec_pmic-rtc, regmap_rtc);
if (IS_ERR(sec_pmic-regmap_rtc)) {
ret = PTR_ERR(sec_pmic-regmap_rtc);
dev_err(i2c-dev, Failed to allocate RTC register map: %d\n,
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 11/14] regulator: s2mps11: Add opmode for S2MPS14 regulators
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 operation mode from DTS by reading a
op_mode property from regulator child node.
The op_mode is then used for enabling the S2MPS14 regulators.
On S2MPS11 the DTS op_mode property is parsed but not used for
enabling, as this was not tested.
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Cc: Mark Brown broo...@kernel.org
Cc: Liam Girdwood lgirdw...@gmail.com
---
drivers/regulator/s2mps11.c | 98 ++-
include/linux/mfd/samsung/s2mps14.h | 17 ++
2 files changed, 114 insertions(+), 1 deletion(-)
diff --git a/drivers/regulator/s2mps11.c b/drivers/regulator/s2mps11.c
index c37869fb6c7a..b30fa6cd370d 100644
--- a/drivers/regulator/s2mps11.c
+++ b/drivers/regulator/s2mps11.c
@@ -34,6 +34,7 @@
struct s2mps11_info {
struct regulator_dev **rdev;
unsigned int rdev_num;
+ struct sec_opmode_data *opmode;
int ramp_delay2;
int ramp_delay34;
@@ -43,6 +44,48 @@ struct s2mps11_info {
int ramp_delay9;
};
+/* LDO_EN/BUCK_EN register values for enabling/disabling regulator */
+static unsigned int s2mps14_opmode_reg[4] = {
+ [S2MPS14_REGULATOR_OPMODE_OFF] = 0x0,
+ [S2MPS14_REGULATOR_OPMODE_ON] = 0x3,
+ [S2MPS14_REGULATOR_OPMODE_RESERVED] = 0x2,
+ [S2MPS14_REGULATOR_OPMODE_SUSPEND] = 0x1,
+};
+
+static int s2mps14_get_opmode(struct regulator_dev *rdev)
+{
+ int i, reg_id = rdev_get_id(rdev);
+ int mode = -EINVAL;
+ struct s2mps11_info *s2mps11 = rdev_get_drvdata(rdev);
+
+ for (i = 0; i s2mps11-rdev_num; i++) {
+ if (s2mps11-opmode[i].id == reg_id) {
+ mode = s2mps11-opmode[i].mode;
+ break;
+ }
+ }
+
+ if (mode == -EINVAL) {
+ dev_warn(rdev_get_dev(rdev),
+ No op_mode in the driver for regulator %s\n,
+ rdev-desc-name);
+ return mode;
+ }
+
+ return s2mps14_opmode_reg[mode] S2MPS14_ENCTRL_SHIFT;
+}
+
+static int s2mps14_reg_enable(struct regulator_dev *rdev)
+{
+ int enable_ctrl = s2mps14_get_opmode(rdev);
+
+ if (enable_ctrl 0)
+ return enable_ctrl;
+
+ return regmap_update_bits(rdev-regmap, rdev-desc-enable_reg,
+ S2MPS14_ENCTRL_MASK, enable_ctrl);
+}
+
static int get_ramp_delay(int ramp_delay)
{
unsigned char cnt = 0;
@@ -405,7 +448,7 @@ static struct regulator_ops s2mps14_reg_ops = {
.list_voltage = regulator_list_voltage_linear,
.map_voltage= regulator_map_voltage_linear,
.is_enabled = regulator_is_enabled_regmap,
- .enable = regulator_enable_regmap,
+ .enable = s2mps14_reg_enable,
.disable= regulator_disable_regmap,
.get_voltage_sel= regulator_get_voltage_sel_regmap,
.set_voltage_sel= regulator_set_voltage_sel_regmap,
@@ -519,6 +562,54 @@ static const struct regulator_desc s2mps14_regulators[] = {
regulator_desc_s2mps14_buck1235(5),
};
+static inline void s2mps11_dt_read_opmode(struct platform_device *pdev,
+ struct device_node *np, unsigned int *mode)
+{
+ if (of_property_read_u32(np, op_mode, mode)) {
+ dev_warn(pdev-dev, no op_mode property property at %s\n,
+ np-full_name);
+ *mode = S2MPS14_REGULATOR_OPMODE_ON;
+ } else if (*mode = S2MPS14_REGULATOR_OPMODE_MAX ||
+ *mode == S2MPS14_REGULATOR_OPMODE_RESERVED) {
+ dev_warn(pdev-dev, wrong op_mode value at %s\n,
+ np-full_name);
+ *mode = S2MPS14_REGULATOR_OPMODE_ON;
+ }
+ /* else: 'mode' was read from DTS and it is valid */
+}
+
+/*
+ * Returns allocated array with opmodes for regulators. The opmodes are read
+ * from DTS.
+ */
+static struct sec_opmode_data *
+s2mps11_pmic_dt_parse_opmode(struct platform_device *pdev,
+ struct s2mps11_info *s2mps11, struct of_regulator_match *rdata,
+ const struct regulator_desc *regulators)
+{
+ struct sec_opmode_data *rmode;
+ int i;
+
+ rmode = devm_kzalloc(pdev-dev, sizeof(*rmode) * s2mps11-rdev_num,
+ GFP_KERNEL);
+ if (!rmode) {
+ dev_err(pdev-dev,
+ could not allocate memory for regulator mode\n);
+ return NULL;
+ }
+
+ for (i = 0; i s2mps11-rdev_num; i++) {
+ /*
+
[PATCH 13/14] rtc: s5m: Support different register layout
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 k.kozlow...@samsung.com
Cc: Alessandro Zummo a.zu...@towertech.it
Cc: rtc-li...@googlegroups.com
---
drivers/rtc/rtc-s5m.c | 157 ++---
1 file changed, 109 insertions(+), 48 deletions(-)
diff --git a/drivers/rtc/rtc-s5m.c b/drivers/rtc/rtc-s5m.c
index b1627e9ab8f0..6a1290f8709a 100644
--- a/drivers/rtc/rtc-s5m.c
+++ b/drivers/rtc/rtc-s5m.c
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2013 Samsung Electronics Co., Ltd
+ * Copyright (c) 2013-2014 Samsung Electronics Co., Ltd
* http://www.samsung.com
*
* Copyright (C) 2013 Google, Inc
@@ -38,6 +38,42 @@
*/
#define UDR_READ_RETRY_CNT 5
+/* Registers used by the driver which are different between chipsets. */
+struct s5m_rtc_reg_config {
+ /* Number of registers used for setting time/alarm0/alarm1 */
+ unsigned int regs_count;
+ /* First register for time, seconds */
+ unsigned int time;
+ /* RTC control register */
+ unsigned int ctrl;
+ /* First register for alarm 0, seconds */
+ unsigned int alarm0;
+ /* First register for alarm 1, seconds */
+ unsigned int alarm1;
+ /* SMPL/WTSR register */
+ unsigned int smpl_wtsr;
+ /*
+* Register for update flag (UDR). Typically setting UDR field to 1
+* will enable update of time or alarm register. Then it will be
+* auto-cleared after successful update.
+*/
+ unsigned int rtc_udr_update;
+ /* Mask for UDR field in 'rtc_udr_update' register */
+ unsigned int rtc_udr_mask;
+};
+
+/* Register map for S5M8763 and S5M8767 */
+static const struct s5m_rtc_reg_config s5m_rtc_regs = {
+ .regs_count = 8,
+ .time = S5M_RTC_SEC,
+ .ctrl = S5M_ALARM1_CONF,
+ .alarm0 = S5M_ALARM0_SEC,
+ .alarm1 = S5M_ALARM1_SEC,
+ .smpl_wtsr = S5M_WTSR_SMPL_CNTL,
+ .rtc_udr_update = S5M_RTC_UDR_CON,
+ .rtc_udr_mask = S5M_RTC_UDR_MASK,
+};
+
struct s5m_rtc_info {
struct device *dev;
struct sec_pmic_dev *s5m87xx;
@@ -47,6 +83,7 @@ struct s5m_rtc_info {
int device_type;
int rtc_24hr_mode;
bool wtsr_smpl;
+ const struct s5m_rtc_reg_config *regs;
};
static void s5m8767_data_to_tm(u8 *data, struct rtc_time *tm,
@@ -104,8 +141,9 @@ static inline int s5m8767_wait_for_udr_update(struct
s5m_rtc_info *info)
unsigned int data;
do {
- ret = regmap_read(info-regmap, S5M_RTC_UDR_CON, data);
- } while (--retry (data S5M_RTC_UDR_MASK) !ret);
+ ret = regmap_read(info-regmap, info-regs-rtc_udr_update,
+ data);
+ } while (--retry (data info-regs-rtc_udr_mask) !ret);
if (!retry)
dev_err(info-dev, waiting for UDR update, reached max number
of retries\n);
@@ -113,21 +151,47 @@ static inline int s5m8767_wait_for_udr_update(struct
s5m_rtc_info *info)
return ret;
}
+static inline int s5m_check_peding_alarm_interrupt(struct s5m_rtc_info *info,
+ struct rtc_wkalrm *alarm)
+{
+ int ret;
+ unsigned int val;
+
+ switch (info-device_type) {
+ case S5M8767X:
+ case S5M8763X:
+ ret = regmap_read(info-regmap, S5M_RTC_STATUS, val);
+ val = S5M_ALARM0_STATUS;
+ break;
+ default:
+ return -EINVAL;
+ }
+ if (ret 0)
+ return ret;
+
+ if (val)
+ alarm-pending = 1;
+ else
+ alarm-pending = 0;
+
+ return 0;
+}
+
static inline int s5m8767_rtc_set_time_reg(struct s5m_rtc_info *info)
{
int ret;
unsigned int data;
- ret = regmap_read(info-regmap, S5M_RTC_UDR_CON, data);
+ ret = regmap_read(info-regmap, info-regs-rtc_udr_update, data);
if (ret 0) {
dev_err(info-dev, failed to read update reg(%d)\n, ret);
return ret;
}
data |= S5M_RTC_TIME_EN_MASK;
- data |= S5M_RTC_UDR_MASK;
+ data |= info-regs-rtc_udr_mask;
- ret = regmap_write(info-regmap, S5M_RTC_UDR_CON, data);
+ ret = regmap_write(info-regmap, info-regs-rtc_udr_update, data);
if (ret 0) {
dev_err(info-dev, failed to write update reg(%d)\n, ret);
return ret;
@@ -143,7 +207,7 @@ static inline int s5m8767_rtc_set_alarm_reg(struct
s5m_rtc_info *info)
int ret;
unsigned int data;
- ret = regmap_read(info-regmap, S5M_RTC_UDR_CON, data);
+ ret = regmap_read(info-regmap,
[PATCH 12/14] Documentation: mfd/regulator: s2mps11: Document the op_mode bindings
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 (although S5M8767 have also low-power mode).
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Cc: Mark Brown broo...@kernel.org
Cc: Liam Girdwood lgirdw...@gmail.com
Cc: Tomasz Figa t.f...@samsung.com
Cc: devicet...@vger.kernel.org
Cc: Rob Herring robh...@kernel.org
Cc: Pawel Moll pawel.m...@arm.com
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Ian Campbell ijc+devicet...@hellion.org.uk
Cc: Kumar Gala ga...@codeaurora.org
---
Documentation/devicetree/bindings/mfd/s2mps11.txt | 46 +
1 file changed, 46 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/s2mps11.txt
b/Documentation/devicetree/bindings/mfd/s2mps11.txt
index f69bec294f02..ffad6bfe2ebf 100644
--- a/Documentation/devicetree/bindings/mfd/s2mps11.txt
+++ b/Documentation/devicetree/bindings/mfd/s2mps11.txt
@@ -54,6 +54,15 @@ BUCK[3, 4], and BUCK[7, 8, 10]
The regulator constraints inside the regulator nodes use the standard regulator
bindings which are documented elsewhere.
+On S2MPS14 chipset the driver additionally supports op_mode properties for
+each regulator.
+ - op_mode: describes the different operating modes of the regulators with
+ power mode change in SOC. The different possible values are,
+ 0 - always off mode
+ 1 - on in normal mode
+ 3 - suspend mode
+ (NOTE: value of 2 is reserved)
+
The following are the names of the regulators that the s2mps11 pmic block
supports. Note: The 'n' in LDOn and BUCKn represents the LDO or BUCK number
as per the datasheet of s2mps11.
@@ -112,3 +121,40 @@ Example:
};
};
};
+
+ s2mps14_pmic@66 {
+ compatible = samsung,s2mps14-pmic;
+ reg = 0x66;
+
+ s2m_osc: clocks {
+ compatible = samsung,s2mps14-clk;
+ #clock-cells = 1;
+ clock-output-names = xx, , zz;
+ };
+
+ regulators {
+ ldo1_reg: LDO1 {
+ regulator-name = VAP_ALIVE_1.0V;
+ regulator-min-microvolt = 100;
+ regulator-max-microvolt = 100;
+ regulator-always-on;
+ op_mode = 1; /* Normal Mode */
+ };
+
+ ldo2_reg: LDO2 {
+ regulator-name = VAP_M1_1.2V;
+ regulator-min-microvolt = 120;
+ regulator-max-microvolt = 120;
+ regulator-always-on;
+ op_mode = 1; /* Normal Mode */
+ };
+
+ buck1_reg: BUCK1 {
+ regulator-name = VAP_MIF_1.0V;
+ regulator-min-microvolt = 100;
+ regulator-max-microvolt = 100;
+ regulator-always-on;
+ op_mode = 3; /* Standby Mode */
+ };
+ };
+ };
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 14/14] rtc: s5m: Add support for S2MPS14 RTC
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 time;
- RTC interrupts are reported in main PMIC I2C device;
This patch also adds missing mfd_cell for RTC in the MFD core driver.
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
Cc: Alessandro Zummo a.zu...@towertech.it
Cc: rtc-li...@googlegroups.com
---
drivers/rtc/rtc-s5m.c | 89 +++--
1 file changed, 78 insertions(+), 11 deletions(-)
diff --git a/drivers/rtc/rtc-s5m.c b/drivers/rtc/rtc-s5m.c
index 6a1290f8709a..6e4faffe4b5b 100644
--- a/drivers/rtc/rtc-s5m.c
+++ b/drivers/rtc/rtc-s5m.c
@@ -17,16 +17,14 @@
#include linux/module.h
#include linux/i2c.h
-#include linux/slab.h
#include linux/bcd.h
-#include linux/bitops.h
#include linux/regmap.h
#include linux/rtc.h
-#include linux/delay.h
#include linux/platform_device.h
#include linux/mfd/samsung/core.h
#include linux/mfd/samsung/irq.h
#include linux/mfd/samsung/rtc.h
+#include linux/mfd/samsung/s2mps14.h
/*
* Maximum number of retries for checking changes in UDR field
@@ -74,6 +72,21 @@ static const struct s5m_rtc_reg_config s5m_rtc_regs = {
.rtc_udr_mask = S5M_RTC_UDR_MASK,
};
+/*
+ * Register map for S2MPS14.
+ * It may be also suitable for S2MPS11 but this was not tested.
+ */
+static const struct s5m_rtc_reg_config s2mps_rtc_regs = {
+ .regs_count = 7,
+ .time = S2MPS_RTC_SEC,
+ .ctrl = S2MPS_RTC_CTRL,
+ .alarm0 = S2MPS_ALARM0_SEC,
+ .alarm1 = S2MPS_ALARM1_SEC,
+ .smpl_wtsr = S2MPS_WTSR_SMPL_CNTL,
+ .rtc_udr_update = S2MPS_RTC_UDR_CON,
+ .rtc_udr_mask = S2MPS_RTC_WUDR_MASK,
+};
+
struct s5m_rtc_info {
struct device *dev;
struct sec_pmic_dev *s5m87xx;
@@ -163,6 +176,11 @@ static inline int s5m_check_peding_alarm_interrupt(struct
s5m_rtc_info *info,
ret = regmap_read(info-regmap, S5M_RTC_STATUS, val);
val = S5M_ALARM0_STATUS;
break;
+ case S2MPS14X:
+ ret = regmap_read(info-s5m87xx-regmap_pmic, S2MPS14_REG_ST2,
+ val);
+ val = S2MPS_ALARM0_STATUS;
+ break;
default:
return -EINVAL;
}
@@ -188,8 +206,9 @@ static inline int s5m8767_rtc_set_time_reg(struct
s5m_rtc_info *info)
return ret;
}
- data |= S5M_RTC_TIME_EN_MASK;
data |= info-regs-rtc_udr_mask;
+ if (info-device_type == S5M8763X || info-device_type == S5M8767X)
+ data |= S5M_RTC_TIME_EN_MASK;
ret = regmap_write(info-regmap, info-regs-rtc_udr_update, data);
if (ret 0) {
@@ -214,8 +233,18 @@ static inline int s5m8767_rtc_set_alarm_reg(struct
s5m_rtc_info *info)
return ret;
}
- data = ~S5M_RTC_TIME_EN_MASK;
data |= info-regs-rtc_udr_mask;
+ switch (info-device_type) {
+ case S5M8763X:
+ case S5M8767X:
+ data = ~S5M_RTC_TIME_EN_MASK;
+ break;
+ case S2MPS14X:
+ data |= S2MPS_RTC_RUDR_MASK;
+ break;
+ default:
+ return -EINVAL;
+ }
ret = regmap_write(info-regmap, info-regs-rtc_udr_update, data);
if (ret 0) {
@@ -267,6 +296,17 @@ static int s5m_rtc_read_time(struct device *dev, struct
rtc_time *tm)
u8 data[info-regs-regs_count];
int ret;
+ if (info-device_type == S2MPS14X) {
+ ret = regmap_update_bits(info-regmap,
+ info-regs-rtc_udr_update,
+ S2MPS_RTC_RUDR_MASK, S2MPS_RTC_RUDR_MASK);
+ if (ret) {
+ dev_err(dev,
+ Failed to prepare registers for time reading:
%d\n,
+ ret);
+ return ret;
+ }
+ }
ret = regmap_bulk_read(info-regmap, info-regs-time, data,
info-regs-regs_count);
if (ret 0)
@@ -278,6 +318,7 @@ static int s5m_rtc_read_time(struct device *dev, struct
rtc_time *tm)
break;
case S5M8767X:
+ case S2MPS14X:
s5m8767_data_to_tm(data, tm, info-rtc_24hr_mode);
break;
@@ -303,6 +344,7 @@ static int s5m_rtc_set_time(struct device *dev, struct
rtc_time *tm)
s5m8763_tm_to_data(tm, data);
break;
case S5M8767X:
+ case S2MPS14X:
ret = s5m8767_tm_to_data(tm, data);
break;
default:
@@ -349,6 +391,7 @@ static int
[PATCH 05/14] mfd: sec: Use consistent S2MPS11 RTC alarm interrupt indexes
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 k.kozlow...@samsung.com
---
drivers/mfd/sec-irq.c |8
include/linux/mfd/samsung/irq.h |4 ++--
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/mfd/sec-irq.c b/drivers/mfd/sec-irq.c
index 4de494f51d40..e403c293b437 100644
--- a/drivers/mfd/sec-irq.c
+++ b/drivers/mfd/sec-irq.c
@@ -59,13 +59,13 @@ static const struct regmap_irq s2mps11_irqs[] = {
.reg_offset = 1,
.mask = S2MPS11_IRQ_RTC60S_MASK,
},
- [S2MPS11_IRQ_RTCA1] = {
+ [S2MPS11_IRQ_RTCA0] = {
.reg_offset = 1,
- .mask = S2MPS11_IRQ_RTCA1_MASK,
+ .mask = S2MPS11_IRQ_RTCA0_MASK,
},
- [S2MPS11_IRQ_RTCA2] = {
+ [S2MPS11_IRQ_RTCA1] = {
.reg_offset = 1,
- .mask = S2MPS11_IRQ_RTCA2_MASK,
+ .mask = S2MPS11_IRQ_RTCA1_MASK,
},
[S2MPS11_IRQ_SMPL] = {
.reg_offset = 1,
diff --git a/include/linux/mfd/samsung/irq.h b/include/linux/mfd/samsung/irq.h
index d43b4f9e7fb2..abe1a6aae3b7 100644
--- a/include/linux/mfd/samsung/irq.h
+++ b/include/linux/mfd/samsung/irq.h
@@ -24,8 +24,8 @@ enum s2mps11_irq {
S2MPS11_IRQ_MRB,
S2MPS11_IRQ_RTC60S,
+ S2MPS11_IRQ_RTCA0,
S2MPS11_IRQ_RTCA1,
- S2MPS11_IRQ_RTCA2,
S2MPS11_IRQ_SMPL,
S2MPS11_IRQ_RTC1S,
S2MPS11_IRQ_WTSR,
@@ -47,7 +47,7 @@ enum s2mps11_irq {
#define S2MPS11_IRQ_RTC60S_MASK(1 0)
#define S2MPS11_IRQ_RTCA1_MASK (1 1)
-#define S2MPS11_IRQ_RTCA2_MASK (1 2)
+#define S2MPS11_IRQ_RTCA0_MASK (1 2)
#define S2MPS11_IRQ_SMPL_MASK (1 3)
#define S2MPS11_IRQ_RTC1S_MASK (1 4)
#define S2MPS11_IRQ_WTSR_MASK (1 5)
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/14] mfd: sec: Add maximum RTC register for regmap config
Add maximum register to the regmap used by rtc-s5m driver.
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
---
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 7c6ce2e4aaa6..6021c54f74cf 100644
--- a/drivers/mfd/sec-core.c
+++ b/drivers/mfd/sec-core.c
@@ -141,6 +141,8 @@ static const struct regmap_config s5m8767_regmap_config = {
static const struct regmap_config sec_rtc_regmap_config = {
.reg_bits = 8,
.val_bits = 8,
+
+ .max_register = SEC_RTC_REG_MAX,
};
#ifdef CONFIG_OF
diff --git a/include/linux/mfd/samsung/rtc.h b/include/linux/mfd/samsung/rtc.h
index 94b7cd6d8891..4627f59ebd84 100644
--- a/include/linux/mfd/samsung/rtc.h
+++ b/include/linux/mfd/samsung/rtc.h
@@ -43,6 +43,8 @@ enum sec_rtc_reg {
SEC_RTC_STATUS,
SEC_WTSR_SMPL_CNTL,
SEC_RTC_UDR_CON,
+
+ SEC_RTC_REG_MAX,
};
#define RTC_I2C_ADDR (0x0C 1)
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/14] mfd/rtc: sec/sec: Rename SEC* symbols to S5M
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 k.kozlow...@samsung.com
Cc: Alessandro Zummo a.zu...@towertech.it
Cc: rtc-li...@googlegroups.com
---
drivers/mfd/sec-core.c |2 +-
drivers/rtc/rtc-s5m.c | 64 -
include/linux/mfd/samsung/rtc.h | 76 +++
3 files changed, 71 insertions(+), 71 deletions(-)
diff --git a/drivers/mfd/sec-core.c b/drivers/mfd/sec-core.c
index 0efa69e123ee..8504de82b7e0 100644
--- a/drivers/mfd/sec-core.c
+++ b/drivers/mfd/sec-core.c
@@ -142,7 +142,7 @@ static const struct regmap_config sec_rtc_regmap_config = {
.reg_bits = 8,
.val_bits = 8,
- .max_register = SEC_RTC_REG_MAX,
+ .max_register = S5M_RTC_REG_MAX,
};
#ifdef CONFIG_OF
diff --git a/drivers/rtc/rtc-s5m.c b/drivers/rtc/rtc-s5m.c
index 476af93543f6..d26e2480f8b3 100644
--- a/drivers/rtc/rtc-s5m.c
+++ b/drivers/rtc/rtc-s5m.c
@@ -30,10 +30,10 @@
/*
* Maximum number of retries for checking changes in UDR field
- * of SEC_RTC_UDR_CON register (to limit possible endless loop).
+ * of S5M_RTC_UDR_CON register (to limit possible endless loop).
*
* After writing to RTC registers (setting time or alarm) read the UDR field
- * in SEC_RTC_UDR_CON register. UDR is auto-cleared when data have
+ * in S5M_RTC_UDR_CON register. UDR is auto-cleared when data have
* been transferred.
*/
#define UDR_READ_RETRY_CNT 5
@@ -104,8 +104,8 @@ static inline int s5m8767_wait_for_udr_update(struct
s5m_rtc_info *info)
unsigned int data;
do {
- ret = regmap_read(info-regmap, SEC_RTC_UDR_CON, data);
- } while (--retry (data RTC_UDR_MASK) !ret);
+ ret = regmap_read(info-regmap, S5M_RTC_UDR_CON, data);
+ } while (--retry (data S5M_RTC_UDR_MASK) !ret);
if (!retry)
dev_err(info-dev, waiting for UDR update, reached max number
of retries\n);
@@ -118,16 +118,16 @@ static inline int s5m8767_rtc_set_time_reg(struct
s5m_rtc_info *info)
int ret;
unsigned int data;
- ret = regmap_read(info-regmap, SEC_RTC_UDR_CON, data);
+ ret = regmap_read(info-regmap, S5M_RTC_UDR_CON, data);
if (ret 0) {
dev_err(info-dev, failed to read update reg(%d)\n, ret);
return ret;
}
- data |= RTC_TIME_EN_MASK;
- data |= RTC_UDR_MASK;
+ data |= S5M_RTC_TIME_EN_MASK;
+ data |= S5M_RTC_UDR_MASK;
- ret = regmap_write(info-regmap, SEC_RTC_UDR_CON, data);
+ ret = regmap_write(info-regmap, S5M_RTC_UDR_CON, data);
if (ret 0) {
dev_err(info-dev, failed to write update reg(%d)\n, ret);
return ret;
@@ -143,17 +143,17 @@ static inline int s5m8767_rtc_set_alarm_reg(struct
s5m_rtc_info *info)
int ret;
unsigned int data;
- ret = regmap_read(info-regmap, SEC_RTC_UDR_CON, data);
+ ret = regmap_read(info-regmap, S5M_RTC_UDR_CON, data);
if (ret 0) {
dev_err(info-dev, %s: fail to read update reg(%d)\n,
__func__, ret);
return ret;
}
- data = ~RTC_TIME_EN_MASK;
- data |= RTC_UDR_MASK;
+ data = ~S5M_RTC_TIME_EN_MASK;
+ data |= S5M_RTC_UDR_MASK;
- ret = regmap_write(info-regmap, SEC_RTC_UDR_CON, data);
+ ret = regmap_write(info-regmap, S5M_RTC_UDR_CON, data);
if (ret 0) {
dev_err(info-dev, %s: fail to write update reg(%d)\n,
__func__, ret);
@@ -203,7 +203,7 @@ static int s5m_rtc_read_time(struct device *dev, struct
rtc_time *tm)
u8 data[8];
int ret;
- ret = regmap_bulk_read(info-regmap, SEC_RTC_SEC, data, 8);
+ ret = regmap_bulk_read(info-regmap, S5M_RTC_SEC, data, 8);
if (ret 0)
return ret;
@@ -251,7 +251,7 @@ static int s5m_rtc_set_time(struct device *dev, struct
rtc_time *tm)
1900 + tm-tm_year, 1 + tm-tm_mon, tm-tm_mday,
tm-tm_hour, tm-tm_min, tm-tm_sec, tm-tm_wday);
- ret = regmap_raw_write(info-regmap, SEC_RTC_SEC, data, 8);
+ ret = regmap_raw_write(info-regmap, S5M_RTC_SEC, data, 8);
if (ret 0)
return ret;
@@ -267,20 +267,20 @@ static int s5m_rtc_read_alarm(struct device *dev, struct
rtc_wkalrm *alrm)
unsigned int val;
int ret, i;
- ret = regmap_bulk_read(info-regmap, SEC_ALARM0_SEC, data, 8);
+ ret = regmap_bulk_read(info-regmap, S5M_ALARM0_SEC, data, 8);
if (ret 0)
return ret;
switch (info-device_type) {
case S5M8763X:
s5m8763_data_to_tm(data, alrm-time);
-
[PATCH 06/14] regulator: s2mps11: Constify regulator_desc array
Constify the regulator_desc 'regulators' array.
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
Cc: Mark Brown broo...@kernel.org
Cc: Liam Girdwood lgirdw...@gmail.com
---
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 89966213315c..d44bd5b3fe8e 100644
--- a/drivers/regulator/s2mps11.c
+++ b/drivers/regulator/s2mps11.c
@@ -345,7 +345,7 @@ static struct regulator_ops s2mps11_buck_ops = {
.enable_mask= S2MPS11_ENABLE_MASK \
}
-static struct regulator_desc regulators[] = {
+static const struct regulator_desc regulators[] = {
regulator_desc_ldo2(1),
regulator_desc_ldo1(2),
regulator_desc_ldo1(3),
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V4] max8925_power: Use IS_ENABLED(CONFIG_OF) for DT code.
Hi Dmitry,
On Tue, Jan 28, 2014 at 10:24 PM, Manish Badarkhe
badarkhe.man...@gmail.com 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 badarkhe.man...@gmail.com
---
Changes since V1:
1.Updated code to use IS_ENABLED during retrieval
of platform/DT data.
Changes since V2:
1.Updated code as per Dmitry's comment to give preferance to
platform data.
Changes since V3:
1.Updated code to use IS_ENABLED(CONFIG_OF) to remove
DT data retrieval function during compilation itself
when CONFIG_OF option is not set.
:100644 100644 b4513f2... a7482db... M drivers/power/max8925_power.c
drivers/power/max8925_power.c | 17 +
1 file changed, 5 insertions(+), 12 deletions(-)
diff --git a/drivers/power/max8925_power.c b/drivers/power/max8925_power.c
index b4513f2..a7482db 100644
--- a/drivers/power/max8925_power.c
+++ b/drivers/power/max8925_power.c
@@ -427,7 +427,6 @@ static int max8925_deinit_charger(struct
max8925_power_info *info)
return 0;
}
-#ifdef CONFIG_OF
static struct max8925_power_pdata *
max8925_power_dt_init(struct platform_device *pdev)
{
@@ -440,9 +439,6 @@ max8925_power_dt_init(struct platform_device *pdev)
int no_insert_detect;
struct max8925_power_pdata *pdata;
- if (!nproot)
- return pdev-dev.platform_data;
-
np = of_find_node_by_name(nproot, charger);
if (!np) {
dev_err(pdev-dev, failed to find charger node\n);
@@ -468,13 +464,6 @@ max8925_power_dt_init(struct platform_device *pdev)
return pdata;
}
-#else
-static struct max8925_power_pdata *
-max8925_power_dt_init(struct platform_device *pdev)
-{
- return pdev-dev.platform_data;
-}
-#endif
static int max8925_power_probe(struct platform_device *pdev)
{
@@ -483,7 +472,11 @@ static int max8925_power_probe(struct platform_device
*pdev)
struct max8925_power_info *info;
int ret;
- pdata = max8925_power_dt_init(pdev);
+ pdata = dev_get_platdata(pdev-dev);
+
+ if (IS_ENABLED(CONFIG_OF) !pdata chip-dev-of_node)
+ pdata = max8925_power_dt_init(pdev);
+
if (!pdata) {
dev_err(pdev-dev, platform data isn't assigned to
power supply\n);
Gentle ping!!
Please let me know, are there any review comments on this patch?
Thanks
Manish Badarkhe
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ASoC: smdk_wm8994: Fix typo wm8894
On Mon, Feb 10, 2014 at 10:25:31PM +0100, Paul Bolle wrote: Signed-off-by: Paul Bolle pebo...@tiscali.nl Applied, thanks. signature.asc Description: Digital signature
[PATCH] ARM: dts: exynos5250-arndale: Keep G3D regulator always on
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 observed behavior seems to confirm that it is true for this SoC as well). This fixes an issue preventing Arndale board from entering sleep mode observed since commit 346f372f7b72a0 clk: exynos5250: Add CLK_IGNORE_UNUSED flag for pmu clock that landed in kernel 3.11, which has fixed the clock driver to make the SoC actually try to enter the sleep mode. Signed-off-by: Tomasz Figa t.f...@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com Cc: sta...@vger.kernel.org --- arch/arm/boot/dts/exynos5250-arndale.dts | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts b/arch/arm/boot/dts/exynos5250-arndale.dts index e14dd62..5e9ddb8 100644 --- a/arch/arm/boot/dts/exynos5250-arndale.dts +++ b/arch/arm/boot/dts/exynos5250-arndale.dts @@ -287,6 +287,7 @@ regulator-name = vdd_g3d; regulator-min-microvolt = 100; regulator-max-microvolt = 100; + regulator-always-on; regulator-boot-on; op_mode = 1; }; -- 1.8.5.2 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 00/12] Samsung PM consolidation part 2 (multiplatform)
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. In addition there is a lot of forced code unification, which makes common function handle any possible quirks of all supported SoCs. In the end this design turned out to not work too well, ending with a lot of empty functions exported from mach-, just because code in common pm.c calls them. Moreover, recent trend of moving lower level suspend/resume code to proper drivers, like pinctrl or clk, made a lot of code there redundant, especially on DT-only platforms like Exynos. This patch series attempts to untie Exynos PM support from the legacy Samsung PM core and make it multiplatform-aware, by isolating truly generic parts of the latter, making them multiplatform-friendly and then reimplementing Exynos PM support in a multiplatform-capable way by using those generic parts. The result is that now PM initialization is started from mach-exynos*-dt, which calls Exynos-specific initialization code that registers platform_suspend_ops, so control flow is basically reversed ending with mach- code calling more generic plat- code if needed. This is limited to Exynos right now, but remaining SoCs could follow in further series. Depends on Samsung PM consolidation part 1 (clocks) series: - http://thread.gmane.org/gmane.linux.kernel.samsung-soc/26816 On Exynos4210-based Trats, Exynos4412-based Trats2 and Exynos5250-based Arndale boards (except suspend/resume, which is broken because of unrelated reasons): Tested-by: Tomasz Figa t.f...@samsung.com Changes since v1 (RFC): - fixed l2x0 resume, - fixed checkpatch complaints (about issues in existing code being moved), - rebased on top of current linux-next, - slightly reordered patches to make the order more logical. Tomasz Figa (12): ARM: EXYNOS: Do not resume l2x0 if not enabled before suspend ARM: SAMSUNG: Add soc_is_s3c2410() helper ARM: SAMSUNG: pm: Save UART DIVSLOT register based on SoC type ARM: SAMSUNG: pm: Use debug_ll_addr() to get UART base address ARM: SAMSUNG: pm: Consolidate PM debug functions ARM: SAMSUNG: pm: Move Samsung PM debug code into separate file ARM: SAMSUNG: Move common save/restore helpers to separate file ARM: SAMSUNG: pm: Move s3c_pm_check_* prototypes to plat/pm-common.h ARM: EXYNOS: Kconfig: Fix abuse of CONFIG_PM ARM: EXYNOS: Remove PM initcalls and useless indirection ARM: EXYNOS: Stop using legacy Samsung PM code ARM: exynos: Allow wake-up using GIC interrupts arch/arm/mach-exynos/Kconfig | 16 +-- arch/arm/mach-exynos/Makefile | 2 +- arch/arm/mach-exynos/common.c | 1 + arch/arm/mach-exynos/common.h | 14 ++ arch/arm/mach-exynos/include/mach/pm-core.h| 75 --- arch/arm/mach-exynos/pm.c | 172 +++-- arch/arm/mach-exynos/regs-pmu.h| 2 + arch/arm/mach-exynos/sleep.S | 85 arch/arm/mach-s3c64xx/pm.c | 1 - arch/arm/mach-s5p64x0/pm.c | 1 - arch/arm/plat-samsung/Makefile | 2 + arch/arm/plat-samsung/include/plat/cpu.h | 6 + arch/arm/plat-samsung/include/plat/pm-common.h | 110 arch/arm/plat-samsung/include/plat/pm.h| 80 +--- arch/arm/plat-samsung/pm-check.c | 2 +- arch/arm/plat-samsung/pm-common.c | 75 +++ arch/arm/plat-samsung/pm-debug.c | 98 ++ arch/arm/plat-samsung/pm.c | 146 - arch/arm/plat-samsung/s5p-sleep.S | 43 --- 19 files changed, 531 insertions(+), 400 deletions(-) delete mode 100644 arch/arm/mach-exynos/include/mach/pm-core.h create mode 100644 arch/arm/mach-exynos/sleep.S create mode 100644 arch/arm/plat-samsung/include/plat/pm-common.h create mode 100644 arch/arm/plat-samsung/pm-common.c create mode 100644 arch/arm/plat-samsung/pm-debug.c With patch [PATCH] ARM: dts: exynos5250-arndale: Keep G3D regulator always on on Exynos5250-based Arndale board, including suspend to RAM: Tested-by: Tomasz Figa t.f...@samsung.com Best regards, Tomasz -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] arm64: dts: add initial dts for Samsung GH7 SoC and SSDK-GH7 board
On Tue, Feb 11, 2014 at 06:29:41AM +, Kukjin Kim wrote:
Signed-off-by: Kukjin Kim kgene@samsung.com
Reviewed-by: Thomas Abraham thomas...@samsung.com
Cc: Catalin Marinas catalin.mari...@arm.com
---
arch/arm64/boot/dts/samsung-gh7.dtsi | 108
++
arch/arm64/boot/dts/samsung-ssdk-gh7.dts | 26 +++
2 files changed, 134 insertions(+)
create mode 100644 arch/arm64/boot/dts/samsung-gh7.dtsi
create mode 100644 arch/arm64/boot/dts/samsung-ssdk-gh7.dts
diff --git a/arch/arm64/boot/dts/samsung-gh7.dtsi
b/arch/arm64/boot/dts/samsung-gh7.dtsi
new file mode 100644
index 000..5b8785c
--- /dev/null
+++ b/arch/arm64/boot/dts/samsung-gh7.dtsi
@@ -0,0 +1,108 @@
+/*
+ * SAMSUNG GH7 SoC device tree source
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+/dts-v1/;
+
+/memreserve/ 0x8000 0x0C40;
That looks _very_ large. What is this for?
[...]
+ timer {
+ compatible = arm,armv8-timer;
+ interrupts = 1 13 0xff01, /* Secure Phys IRQ */
+ 1 14 0xff01, /* Non-secure Phys IRQ */
+ 1 11 0xff01, /* Virt IRQ */
+ 1 10 0xff01; /* Hyp IRQ */
+ clock-frequency = 1;
Please, get your bootloader to set CNTFREQ. The clock frequency property
for the timer node is a horrible hack for buggy firmware.
[...]
+ amba {
+ compatible = arm,amba-bus;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+
+ serial@12c0 {
+ compatible = arm,pl011, arm,primecell;
+ reg = 0x12c0 0x1;
+ interrupts = 418;
+ };
+
+ serial@12c2 {
+ compatible = arm,pl011, arm,primecell;
+ reg = 0x12c2 0x1;
+ interrupts = 420;
+ };
Don't these need clocks?
[...]
+ memory@8000 {
+ device_type = memory;
+ reg = 0x 0x8000 0 0x8000;
Minor nit, but it would be nice for the 0 values to be consistently padded.
Thanks,
Mark.
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] arm64: dts: add initial dts for Samsung GH7 SoC and SSDK-GH7 board
Hi,
Besides what Mark Rutland already commented on:
On Mon, Feb 10, 2014 at 10:29 PM, Kukjin Kim kgene@samsung.com 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 little use in having it here.
+ interrupt-parent = gic;
+ #address-cells = 2;
+ #size-cells = 2;
+
+ cpus {
+ #address-cells = 2;
+ #size-cells = 0;
+
+ cpu@000 {
+ device_type = cpu;
+ compatible = arm,armv8;
+ reg = 0x0 0x000;
No need to zero-pad cpu numbers in unit address or reg.
+ enable-method = spin-table;
+ cpu-release-addr = 0x0 0x8000fff8;
+ };
+ cpu@001 {
+ device_type = cpu;
+ compatible = arm,armv8;
+ reg = 0x0 0x001;
+ enable-method = spin-table;
+ cpu-release-addr = 0x0 0x8000fff8;
+ };
+ cpu@002 {
+ device_type = cpu;
+ compatible = arm,armv8;
+ reg = 0x0 0x002;
+ enable-method = spin-table;
+ cpu-release-addr = 0x0 0x8000fff8;
+ };
+ cpu@003 {
+ device_type = cpu;
+ compatible = arm,armv8;
+ reg = 0x0 0x003;
+ enable-method = spin-table;
+ cpu-release-addr = 0x0 0x8000fff8;
+ };
+ };
+
+ gic: interrupt-controller@1C00 {
+ compatible = arm,cortex-a15-gic, arm,cortex-a9-gic;
This looks incorrect -- you should at the very least have a more
specific one than a15-gic? Marc?
+ #interrupt-cells = 3;
+ #address-cells = 0;
+ interrupt-controller;
+ reg = 0x0 0x1C001000 0 0x1000,/* GIC Dist */
+ 0x0 0x1C002000 0 0x1000,/* GIC CPU */
+ 0x0 0x1C004000 0 0x2000,/* GIC VCPU Control */
+ 0x0 0x1C006000 0 0x2000;/* GIC VCPU */
+ interrupts = 1 9 0xf04; /* GIC Maintenence IRQ */
+ };
+
+ timer {
+ compatible = arm,armv8-timer;
+ interrupts = 1 13 0xff01, /* Secure Phys IRQ */
+1 14 0xff01, /* Non-secure Phys IRQ */
+1 11 0xff01, /* Virt IRQ */
+1 10 0xff01; /* Hyp IRQ */
+ clock-frequency = 1;
+ };
+
+ pmu {
+ compatible = arm,armv8-pmuv3;
+ interrupts = 0 294 8,
+0 295 8,
+0 296 8,
+0 297 8,
+0 298 8,
+0 299 8,
+0 300 8,
+0 301 8;
+ };
+
+ amba {
+ compatible = arm,amba-bus;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+
+ serial@12c0 {
+ compatible = arm,pl011, arm,primecell;
+ reg = 0x12c0 0x1;
+ interrupts = 418;
+ };
+
+ serial@12c2 {
+ compatible = arm,pl011, arm,primecell;
+ reg = 0x12c2 0x1;
+ interrupts = 420;
+ };
+ };
+};
diff --git a/arch/arm64/boot/dts/samsung-ssdk-gh7.dts
b/arch/arm64/boot/dts/samsung-ssdk-gh7.dts
new file mode 100644
index 000..47afbc4
--- /dev/null
+++ b/arch/arm64/boot/dts/samsung-ssdk-gh7.dts
@@ -0,0 +1,26 @@
+/*
+ * SAMSUNG SSDK-GH7 board device tree source
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+/dts-v1/;
+#include samsung-gh7.dtsi
+
+/ {
+ model = SAMSUNG SSDK-GH7 board based on GH7 SoC;
+ compatible = samsung,ssdk-gh7, samsung,gh7;
+
+ chosen {
+ };
+
+ memory@8000 {
+ device_type = memory;
+ reg = 0x 0x8000 0 0x8000;
+ };
+};
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc
in
the body of a message to majord...@vger.kernel.org
More majordomo info at
Re: [PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family
On Mon, Feb 10, 2014 at 10:29 PM, Kukjin Kim kgene@samsung.com wrote: This patch adds support for Samsung GH7 SoC in arm64/Kconfig. Signed-off-by: Kukjin Kim kgene@samsung.com Cc: Catalin Marinas catalin.mari...@arm.com 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 at this time. It's of course up to Catalin, but you might just want to always compile all dts files instead. -Olof -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: SAMSUNG: remove unneeded s3c24xx_init_cpu()
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 he...@sntech.de
ping :-)
---
arch/arm/mach-s3c24xx/common.c |1 -
arch/arm/plat-samsung/cpu.c |7 ---
arch/arm/plat-samsung/include/plat/cpu.h |1 -
3 files changed, 9 deletions(-)
diff --git a/arch/arm/mach-s3c24xx/common.c b/arch/arm/mach-s3c24xx/common.c
index bf57d4c..97edd4d 100644
--- a/arch/arm/mach-s3c24xx/common.c
+++ b/arch/arm/mach-s3c24xx/common.c
@@ -232,7 +232,6 @@ void __init s3c24xx_init_io(struct map_desc *mach_desc,
int size) } else {
samsung_cpu_id = s3c24xx_read_idcode_v4();
}
- s3c24xx_init_cpu();
s3c_init_cpu(samsung_cpu_id, cpu_ids, ARRAY_SIZE(cpu_ids));
diff --git a/arch/arm/plat-samsung/cpu.c b/arch/arm/plat-samsung/cpu.c
index 46b426e..364963a 100644
--- a/arch/arm/plat-samsung/cpu.c
+++ b/arch/arm/plat-samsung/cpu.c
@@ -28,13 +28,6 @@ unsigned int samsung_rev(void)
}
EXPORT_SYMBOL(samsung_rev);
-void __init s3c24xx_init_cpu(void)
-{
- /* nothing here yet */
-
- samsung_cpu_rev = 0;
-}
-
void __init s3c64xx_init_cpu(void)
{
samsung_cpu_id = __raw_readl(S3C_VA_SYS + 0x118);
diff --git a/arch/arm/plat-samsung/include/plat/cpu.h
b/arch/arm/plat-samsung/include/plat/cpu.h index 8f09488..262ef86 100644
--- a/arch/arm/plat-samsung/include/plat/cpu.h
+++ b/arch/arm/plat-samsung/include/plat/cpu.h
@@ -207,7 +207,6 @@ extern void s5p_init_irq(u32 *vic, u32 num_vic);
extern void s3c24xx_init_io(struct map_desc *mach_desc, int size);
-extern void s3c24xx_init_cpu(void);
extern void s3c64xx_init_cpu(void);
extern void s5p_init_cpu(void __iomem *cpuid_addr);
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: SAMSUNG: remove obsolete tick.h
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. Therefore remove the last 3 occurences. Signed-off-by: Heiko Stuebner he...@sntech.de --- arch/arm/mach-s3c24xx/include/mach/tick.h | 15 -- arch/arm/mach-s3c64xx/include/mach/tick.h | 31 - arch/arm/mach-s5pc100/include/mach/tick.h | 31 - 3 files changed, 77 deletions(-) delete mode 100644 arch/arm/mach-s3c24xx/include/mach/tick.h delete mode 100644 arch/arm/mach-s3c64xx/include/mach/tick.h delete mode 100644 arch/arm/mach-s5pc100/include/mach/tick.h Nice cleanup :-) Applied, thanks, did this make its way into your tree? Because as of now I can't see it in the linux-samsung.git. Thanks Heiko -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: exynos5250-arndale: Keep G3D regulator always on
On 11 February 2014 23:20, Tomasz Figa t.f...@samsung.com 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/4x12 SoCs (Exynos5250 UM does not have such note, but observed behavior seems to confirm that it is true for this SoC as well). This fixes an issue preventing Arndale board from entering sleep mode observed since commit 346f372f7b72a0 clk: exynos5250: Add CLK_IGNORE_UNUSED flag for pmu clock that landed in kernel 3.11, which has fixed the clock driver to make the SoC actually try to enter the sleep mode. Signed-off-by: Tomasz Figa t.f...@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com Cc: sta...@vger.kernel.org Thanks for the patch. Tested-by: Tushar Behera tushar.beh...@linaro.org -- Tushar Behera -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCHv1] usb: dwc2: Combine the dwc2 and s3c_hsotg into a single USB DRD driver.
On 02/04/2014 02:45 PM, dingu...@altera.com wrote: From: Dinh Nguyen dingu...@altera.com 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 peripheral mode. Sorry for the slow response. When building ARCH=arm bcm2835_defconfig, I get build errors: drivers/built-in.o: In function `dwc2_gadget_init': drivers/usb/dwc2/s3c-hsotg.c:3335: undefined reference to `usb_add_gadget_udc' drivers/built-in.o: In function `s3c_hsotg_remove': drivers/usb/dwc2/s3c-hsotg.c:3358: undefined reference to `usb_del_gadget_udc' drivers/usb/dwc2/s3c-hsotg.c:3364: undefined reference to `usb_gadget_unregister_driver' -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCHv1] usb: dwc2: Combine the dwc2 and s3c_hsotg into a single USB DRD driver.
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 dingu...@altera.com 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 peripheral mode. Sorry for the slow response. When building ARCH=arm bcm2835_defconfig, I get build errors: drivers/built-in.o: In function `dwc2_gadget_init': drivers/usb/dwc2/s3c-hsotg.c:3335: undefined reference to `usb_add_gadget_udc' drivers/built-in.o: In function `s3c_hsotg_remove': drivers/usb/dwc2/s3c-hsotg.c:3358: undefined reference to `usb_del_gadget_udc' drivers/usb/dwc2/s3c-hsotg.c:3364: undefined reference to `usb_gadget_unregister_driver' These errors happen when CONFIG_USB_GADGET=n. 's3c-hsotg.c' supports only gadget mode. In the case of USB_DWC2_HOST mode, CONFIG_USB_GADGET is NOT enabled. I don't know how to solve it. Best regards, Jingoo Han -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCHv1] usb: dwc2: Combine the dwc2 and s3c_hsotg into a single USB DRD driver.
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 dingu...@altera.com 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 peripheral mode. Sorry for the slow response. When building ARCH=arm bcm2835_defconfig, I get build errors: Thanks for testing. drivers/built-in.o: In function `dwc2_gadget_init': drivers/usb/dwc2/s3c-hsotg.c:3335: undefined reference to `usb_add_gadget_udc' drivers/built-in.o: In function `s3c_hsotg_remove': drivers/usb/dwc2/s3c-hsotg.c:3358: undefined reference to `usb_del_gadget_udc' drivers/usb/dwc2/s3c-hsotg.c:3364: undefined reference to `usb_gadget_unregister_driver' These errors happen when CONFIG_USB_GADGET=n. 's3c-hsotg.c' supports only gadget mode. In the case of USB_DWC2_HOST mode, CONFIG_USB_GADGET is NOT enabled. I don't know how to solve it. I'm working on v2 of this patch. I think I can make the Kconfig more flexible by selecting USB_GADGET for dual-role or gadget. Or I can make the new driver more independent for the various modes, meaning if the driver is built for HOST mode, it shouldn't be dependent on gadget functions. Dinh Best regards, Jingoo Han -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
