Re: [PATCH v2 11/14] regulator: s2mps11: Add opmode for S2MPS14 regulators
On Thu, 2014-02-13 at 19:28 +, Mark Brown wrote: On Thu, Feb 13, 2014 at 10:14:04AM +0100, Krzysztof Kozlowski wrote: 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). What is the difference between always off/on and the normal enable control? This sounds like a fairly standard register control that can be overridden by a GPIO. The usual way of specifying that is by keying off the presence of the GPIO. My initial idea was to do this similarly to the S5M8767 regulator (where there is also 4th mode: low power). The presence of GPIO in DTS can simplify the bindings but on the other hand it wouldn't be compatible with S5M8767 regulator driver. This may complicate the merge of these drivers. What is your opinion on this - should I abandon the op_mode idea and use presence of GPIO? Best regards, Krzysztof -- 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 RESEND v2 00/12] clk/exynos convert clock IDs to macros
Hi Kukjin, On 14.02.2014 01:17, Kukjin Kim wrote: On 02/14/14 09:10, Kukjin Kim wrote: On 01/28/14 06:49, Mike Turquette wrote: Quoting Tomasz Figa (2014-01-07 07:17:22) Hi Mike, On Tuesday 07 of January 2014 15:47:28 Andrzej Hajda wrote: Hi, This patch set adds header files with macros defining exynos clocks. Then it converts dts files and drivers to use macros instead of magic numbers or enums to describe clock bindings. The patch set is rebased on the latest samsung-clk/samsung-next branch. The patches are generated by script. Many clocks I have verified by hand. I have also tested it successfully on exynos4 based board. This is the 2nd version of the patchset. Changes: - corrected devicetree mailing list, - added comments to include/dt-bindings/clock/exynos4.h for clocks present only in particular chip, - added tab alignement in headers, - added comment to CLK_NR_CLKS, - added copyright headers, - split long lines in dts, - corrected example in bindings/clock/exynos5250-clock.txt, to point appropriate clocks. I believe this has been already acked before, so could you still take it for 3.14? For now I'd merge only the patches adding headers and updating clock drivers to avoid merge conflicts and then after release of 3.14-rc1 we could early merge dts patches for 3.15. Hi Tomasz, Let's go ahead and merge this after 3.14-rc1. I'll take it in when that drops and the DTS data will go in during the same merge window. Hi Mike, As I talked to Tomasz, would be better to us if this series could be handled in Samsung tree so I'm going to do it. How do you think? Oops, already merged into mainline ;-) Sorry, please kindly ignore my previous e-mail. As you probably found out already, we've merged clock-side part of the series for 3.14 to ease things a bit and let you simply merge the DT-side for 3.15. Also, since there were patches floating on the ML still using clock numbers, we decided to give them some more time to be applied, then stop accepting such patches and then finally rerun Andrzej's script on your tree and ask you to apply resulting conversion patches. Since you seem to have already applied most of such floating patches, Andrzej will send you new series soon. 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 6/9 v6] ARM: dts: exynos5250/5420: add dt node for sss module
Hi Kukjin,
On 14.02.2014 00:28, Kukjin Kim wrote:
On 02/07/14 14:24, Naveen Krishna Chatradhi wrote:
This patch adds the device tree node for SSS module
found on Exynos5420 and Exynos5250
Signed-off-by: Naveen Krishna Chatradhich.nav...@samsung.com
Reviewed-by: Tomasz Figat.f...@samsung.com
TO:linux-samsung-soc@vger.kernel.org
CC: Kukjin Kimkgene@samsung.com
CC:linux-cry...@vger.kernel.org
---
changes since v5:
1. Added Reviewed-by: Tomasz Figat.f...@samsung.com
arch/arm/boot/dts/exynos5250.dtsi |8
arch/arm/boot/dts/exynos5420.dtsi | 10 ++
2 files changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index b7dec41..46b04e8 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -706,4 +706,12 @@
io-channel-ranges;
status = disabled;
};
+
+sss@1083 {
+compatible = samsung,exynos4210-secss;
+reg =0x1083 0x1;
+interrupts =0 112 0;
+clocks =clock 348;
+clock-names = secss;
+};
};
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index 8db792b..b503e96 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -652,4 +652,14 @@
clocks =clock 319,clock 318;
clock-names = tmu_apbif, tmu_triminfo_apbif;
};
+
+sss@1083 {
+compatible = samsung,exynos4210-secss;
+reg =0x1083 0x1;
+interrupts =0 112 0;
+clocks =clock 471;
+clock-names = secss;
+samsung,power-domain =g2d_pd;
+};
+
};
Applied, thanks.
BTW, I think the numbering is strange...maybe I missed something?
[PATCH 5/5], [PATCH 5/6 V2], [PATCH 6/8 V3] and this [PATCH 6/9 V6]
I would wait with applying any patches from this series until they are
acked by crypto subsystem maintainer and DT bindings by DT maintainers.
I'd like Naveen to resend this series in separate thread, with proper
message threading, so we can make sure that we are not missing anything.
Naveen, please also add
David S. Miller da...@davemloft.net
to Cc list, as he is also listed as crypto maintainer in MAINTAINERS file.
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 RESEND v2 00/12] clk/exynos convert clock IDs to macros
Hi Tomasz, On 14 February 2014 16:11, Tomasz Figa t.f...@samsung.com wrote: Hi Kukjin, On 14.02.2014 01:17, Kukjin Kim wrote: On 02/14/14 09:10, Kukjin Kim wrote: On 01/28/14 06:49, Mike Turquette wrote: Quoting Tomasz Figa (2014-01-07 07:17:22) Hi Mike, On Tuesday 07 of January 2014 15:47:28 Andrzej Hajda wrote: Hi, This patch set adds header files with macros defining exynos clocks. Then it converts dts files and drivers to use macros instead of magic numbers or enums to describe clock bindings. The patch set is rebased on the latest samsung-clk/samsung-next branch. The patches are generated by script. Many clocks I have verified by hand. I have also tested it successfully on exynos4 based board. This is the 2nd version of the patchset. Changes: - corrected devicetree mailing list, - added comments to include/dt-bindings/clock/exynos4.h for clocks present only in particular chip, - added tab alignement in headers, - added comment to CLK_NR_CLKS, - added copyright headers, - split long lines in dts, - corrected example in bindings/clock/exynos5250-clock.txt, to point appropriate clocks. I believe this has been already acked before, so could you still take it for 3.14? For now I'd merge only the patches adding headers and updating clock drivers to avoid merge conflicts and then after release of 3.14-rc1 we could early merge dts patches for 3.15. Hi Tomasz, Let's go ahead and merge this after 3.14-rc1. I'll take it in when that drops and the DTS data will go in during the same merge window. Hi Mike, As I talked to Tomasz, would be better to us if this series could be handled in Samsung tree so I'm going to do it. How do you think? Oops, already merged into mainline ;-) Sorry, please kindly ignore my previous e-mail. As you probably found out already, we've merged clock-side part of the series for 3.14 to ease things a bit and let you simply merge the DT-side for 3.15. Also, since there were patches floating on the ML still using clock numbers, we decided to give them some more time to be applied, then stop accepting such patches and then finally rerun Andrzej's script on your tree and ask you to apply resulting conversion patches. Since you seem to have already applied most of such floating patches, Andrzej will send you new series soon. There are still quite a few board support patches of Arndale-octa and 5420 SMDK that need to be applied. I believe Kukjin will apply them over the weekend. -- With warm regards, Sachin -- 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
On 14.02.2014 12:28, Rahul Sharma wrote:
On 14 February 2014 08:54, Rahul Sharma r.sh.o...@gmail.com wrote:
Thanks Tomasz,
I will add these changes to v3.
Regards,
Rahul Sharma.
On 11 February 2014 15:34, Tomasz Figa tomasz.f...@gmail.com wrote:
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?
As you said, these are CLK, SS, MISO, MOSI (gpa2-0 to gpa2-3). Fourth pin is
CS. It can be defined as a simple GPIO but better to include it in the
SPI pingroup
as it belongs to there.
I have to disagree here.
If you define a pin in pinctrl group then it is tied to this specific
hardware function and you can't use it as GPIO.
Since it's board specific to use it as HW chip select or GPIO chip
select (the usual setup), it should not be included in this group.
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
[PATCH] spi: s3c24xx: Convert to let spi core validate bits_per_word
Set bits_per_word_mask so spi core will reject transfers that attempt to use
an unsupported bits_per_word value.
Signed-off-by: Axel Lin axel@ingics.com
---
drivers/spi/spi-s3c24xx.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/drivers/spi/spi-s3c24xx.c b/drivers/spi/spi-s3c24xx.c
index c20df45..a275445 100644
--- a/drivers/spi/spi-s3c24xx.c
+++ b/drivers/spi/spi-s3c24xx.c
@@ -122,25 +122,15 @@ static int s3c24xx_spi_update_state(struct spi_device
*spi,
{
struct s3c24xx_spi *hw = to_hw(spi);
struct s3c24xx_spi_devstate *cs = spi-controller_state;
- unsigned int bpw;
unsigned int hz;
unsigned int div;
unsigned long clk;
- bpw = t ? t-bits_per_word : spi-bits_per_word;
hz = t ? t-speed_hz : spi-max_speed_hz;
- if (!bpw)
- bpw = 8;
-
if (!hz)
hz = spi-max_speed_hz;
- if (bpw != 8) {
- dev_err(spi-dev, invalid bits-per-word (%d)\n, bpw);
- return -EINVAL;
- }
-
if (spi-mode != cs-mode) {
u8 spcon = SPCON_DEFAULT | S3C2410_SPCON_ENSCK;
@@ -543,6 +533,7 @@ static int s3c24xx_spi_probe(struct platform_device *pdev)
master-num_chipselect = hw-pdata-num_cs;
master-bus_num = pdata-bus_num;
+ master-bits_per_word_mask = SPI_BPW_MASK(8);
/* setup the state for the bitbang driver */
--
1.8.1.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 11/14] regulator: s2mps11: Add opmode for S2MPS14 regulators
On Thu, 2014-02-13 at 17:46 +0530, Yadwinder Singh Brar wrote: Hi, On Thu, Feb 13, 2014 at 2:44 PM, Krzysztof Kozlowski k.kozlow...@samsung.com wrote: 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. First thing since op_mode is not generic property, I think it should be appended with some driver specific prefix. But IMHO its quite generic property used and required by many other PMICs(almost all used by Samsung). I would like to use this opportunity to discuss about adding it as generic regulator constraint(as initial_mode) by providing a default mapping of generic Regulator operating modes(kernel specific) to operating modes supported by hardware in regulator driver itself. Regards, Yadwinder Hi, I was thinking about this. This relates also to ideas pointed by Mark: - Maybe s2mps11 and s5m8767 regulator drivers could be merged into one; - The external control should be determined by presence of attribute with gpios. The S5M8767 has following operation modes (except on/off): - external control by GPIO; - On/Off controlled by PWREN; - low-power mode; - low-power mode controlled by PWREN; Although not all are present for each regulator. The S2MPS14 is easier: - external control by GPIO; - On/Off controlled by PWREN; A generic solution for operating mode of regulators (not only s2mps11 and s5m8767) could cover all of these above or just a subset, for example regulator bindings could look like: - regulator-mode-suspend; /* PWR controls: on/off or low-power mode */ - regulator-mode-low-power; /* Low power mode */ What do you think? Best regards, Krzysztof -- 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 v3 2/3] ARM: dts: add dts files for exynos5260 SoC
The patch adds the dts files for exynos5260.
Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
Signed-off-by: Arun Kumar K arun...@samsung.com
---
arch/arm/boot/dts/exynos5260-pinctrl.dtsi | 574 +
arch/arm/boot/dts/exynos5260.dtsi | 304 +++
2 files changed, 878 insertions(+)
create mode 100644 arch/arm/boot/dts/exynos5260-pinctrl.dtsi
create mode 100644 arch/arm/boot/dts/exynos5260.dtsi
diff --git a/arch/arm/boot/dts/exynos5260-pinctrl.dtsi
b/arch/arm/boot/dts/exynos5260-pinctrl.dtsi
new file mode 100644
index 000..f6ee55e
--- /dev/null
+++ b/arch/arm/boot/dts/exynos5260-pinctrl.dtsi
@@ -0,0 +1,574 @@
+/*
+ * Samsung's Exynos5260 SoC pin-mux and pin-config device tree source
+ *
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Samsung's Exynos5260 SoC pin-mux and pin-config options are listed as device
+ * tree nodes are listed in this file.
+ *
+ * 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.
+*/
+
+#define PIN_PULL_NONE 0
+#define PIN_PULL_DOWN 1
+#define PIN_PULL_UP3
+
+pinctrl_0 {
+ gpa0: gpa0 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpa1: gpa1 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpa2: gpa2 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpb0: gpb0 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpb1: gpb1 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpb2: gpb2 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpb3: gpb3 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpb4: gpb4 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpb5: gpb5 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpd0: gpd0 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpd1: gpd1 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpd2: gpd2 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpe0: gpe0 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpe1: gpe1 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpf0: gpf0 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpf1: gpf1 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpk0: gpk0 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpx0: gpx0 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpx1: gpx1 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpx2: gpx2 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpx3: gpx3 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+
[PATCH v3 3/3] ARM: dts: add dts files for xyref5260 board
The patch adds the dts files for xyref5260 board which
is based on Exynos5260 Evt0 sample.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
arch/arm/boot/dts/Makefile |1 +
arch/arm/boot/dts/exynos5260-xyref5260-evt0.dts | 105 +++
2 files changed, 106 insertions(+)
create mode 100644 arch/arm/boot/dts/exynos5260-xyref5260-evt0.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index fa70ea2..c513a69 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -64,6 +64,7 @@ dtb-$(CONFIG_ARCH_EXYNOS) += exynos4210-origen.dtb \
exynos5250-arndale.dtb \
exynos5250-smdk5250.dtb \
exynos5250-snow.dtb \
+ exynos5260-xyref5260-evt0.dtb \
exynos5420-arndale-octa.dtb \
exynos5420-smdk5420.dtb \
exynos5440-sd5v1.dtb \
diff --git a/arch/arm/boot/dts/exynos5260-xyref5260-evt0.dts
b/arch/arm/boot/dts/exynos5260-xyref5260-evt0.dts
new file mode 100644
index 000..c4efc1e
--- /dev/null
+++ b/arch/arm/boot/dts/exynos5260-xyref5260-evt0.dts
@@ -0,0 +1,105 @@
+/*
+ * SAMSUNG XYREF5260 EVT0 board device tree source
+ *
+ * Copyright (c) 2013 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 exynos5260.dtsi
+
+/ {
+ model = SAMSUNG XYREF5260 EVT0 board based on EXYNOS5260;
+ compatible = samsung,xyref5260, samsung,exynos5260;
+
+ memory {
+ reg = 0x2000 0x8000;
+ };
+
+ chosen {
+ bootargs = console=ttySAC2,115200;
+ };
+
+ clocks {
+ compatible = simple-bus;
+ #address-cells = 1;
+ #size-cells = 0;
+
+ fin_pll: oscillator@0 {
+ compatible = fixed-clock;
+ reg = 0;
+ clock-frequency = 2400;
+ clock-output-names = fin_pll;
+ #clock-cells = 0;
+ };
+ };
+};
+
+pinctrl_0 {
+ hdmi_hpd_irq: hdmi-hpd-irq {
+ samsung,pins = gpx3-7;
+ samsung,pin-function = 0;
+ samsung,pin-pud = 1;
+ samsung,pin-drv = 0;
+ };
+};
+
+uart0 {
+ status = okay;
+};
+
+uart1 {
+ status = okay;
+};
+
+uart2 {
+ status = okay;
+};
+
+uart3 {
+ status = okay;
+};
+
+mmc_0 {
+ status = okay;
+ num-slots = 1;
+ broken-cd;
+ bypass-smu;
+ supports-highspeed;
+ supports-hs200-mode; /* 200 Mhz */
+ fifo-depth = 0x40;
+ card-detect-delay = 200;
+ samsung,dw-mshc-ciu-div = 3;
+ samsung,dw-mshc-sdr-timing = 0 4;
+ samsung,dw-mshc-ddr-timing = 0 2;
+ pinctrl-names = default;
+ pinctrl-0 = sd0_rdqs sd0_clk sd0_cmd sd0_bus1 sd0_bus4 sd0_bus8;
+
+ slot@0 {
+ reg = 0;
+ bus-width = 8;
+ };
+};
+
+mmc_2 {
+ status = okay;
+ num-slots = 1;
+ supports-highspeed;
+ fifo-depth = 0x40;
+ card-detect-delay = 200;
+ samsung,dw-mshc-ciu-div = 3;
+ samsung,dw-mshc-sdr-timing = 2 3;
+ samsung,dw-mshc-ddr-timing = 1 2;
+ pinctrl-names = default;
+ pinctrl-0 = sd2_clk sd2_cmd sd2_cd sd2_bus1 sd2_bus4;
+
+ slot@0 {
+ reg = 0;
+ bus-width = 4;
+ disable-wp;
+ };
+};
--
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 v3 0/3] exynos: arch: add support for exynos5260 SoC
From: Rahul Sharma rahul.sha...@samsung.com V3: 1) Addressed review comments from Tomasz figa. V2: 1) Split up DT patch into SoC and Board patch. This series is dependent on Sachin's patch ARM: EXYNOS: Consolidate CPU init code at http://comments.gmane.org/gmane.linux.kernel.samsung-soc/26560 This series is based on Kukjin's for-next branch at http://git.kernel.org/?p=linux/kernel/git/kgene/linux-samsung.git Pankaj Dubey (1): ARM: EXYNOS: initial board support for exynos5260 SoC Rahul Sharma (2): ARM: dts: add dts files for exynos5260 SoC ARM: dts: add dts files for xyref5260 board arch/arm/boot/dts/Makefile |1 + arch/arm/boot/dts/exynos5260-pinctrl.dtsi | 574 +++ arch/arm/boot/dts/exynos5260-xyref5260-evt0.dts | 105 + arch/arm/boot/dts/exynos5260.dtsi | 304 arch/arm/mach-exynos/Kconfig|9 + arch/arm/mach-exynos/common.c | 11 + arch/arm/mach-exynos/include/mach/map.h |1 + arch/arm/mach-exynos/mach-exynos5-dt.c |1 + arch/arm/plat-samsung/include/plat/cpu.h|8 + 9 files changed, 1014 insertions(+) create mode 100644 arch/arm/boot/dts/exynos5260-pinctrl.dtsi create mode 100644 arch/arm/boot/dts/exynos5260-xyref5260-evt0.dts create mode 100644 arch/arm/boot/dts/exynos5260.dtsi -- 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 v3] phy: Add new Exynos5 USB 3.0 PHY driver
Hi Tomasz,
On Thu, Feb 6, 2014 at 7:37 PM, Tomasz Figa t.f...@samsung.com wrote:
Hi Vivek,
This patch is just adding the PHY driver. I would also like to look at some
users of it, to see how this works when put together.
The DWC3's changes had been posted by Kishon sometime back, which will enable
DWC3 to use generic PHY dirver. [1]
I had skipped posting corresponding arch patch to use DWC3 on Exynos5
(although i had
posted that in earlier versions of the patch-series).
I will post the corresponding arch patches in the next version of the
patch-series.
For now, please see my comments inline.
On 20.01.2014 14:42, Vivek Gautam wrote:
Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs.
The new driver uses the generic PHY framework and will interact
with DWC3 controller present on Exynos5 series of SoCs.
Thereby, removing old phy-samsung-usb3 driver and related code
used untill now which was based on usb/phy framework.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
Changes from v2:
1) Added support for multiple PHYs (UTMI+ and PIPE3) and
related changes in the driver structuring.
I'm a bit skeptical about this separation. Can the PHY operate with just the
UTMI+ or PIPE3 part enabled alone without the other? Can any PHY consumer
operate this way?
Yes :-)
As also pointed by Kishon the PHY consumer (which is DWC3 in case of
Exynos5 SoC series)
should theoretically be able use either UTMI+ phy for High speed
operations or both (UTMI+ and PIPE3)
for Super Speed operations.
Introducing separation of something that can't exist alone doesn't add any
value, but instead makes things more difficult to work with. Of course, it's
fine if the answer to my questions above if yes, but better safe than sorry.
2) Added a xlate function to get the required phy out of
number of PHYs in mutiple PHY scenerio.
3) Changed the names of few structures and variables to
have a clearer meaning.
4) Added 'usb3phy_config' structure to take care of mutiple
phys for a SoC having 'exynos5_usb3phy_drv_data' driver data.
5) Not deleting support for old driver 'phy-samsung-usb3' until
required support for generic phy is added to DWC3.
[snip]
+
+- aliases: For SoCs like Exynos5420 having multiple USB PHY controllers,
+ 'usb3_phy' nodes should have numbered alias in the aliases
node,
+ in the form of usb3phyN, N = 0, 1... (depending on number of
+ controllers).
+Example:
+ aliases {
+ usb3phy0 = usb3_phy0;
+ usb3phy1 = usb3_phy1;
+ };
What is the reason to have these aliases?
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 330ef2d..32f9f38 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -51,4 +51,12 @@ config PHY_EXYNOS_DP_VIDEO
help
Support for Display Port PHY found on Samsung EXYNOS SoCs.
+config PHY_EXYNOS5_USB3
+ tristate Exynos5 SoC series USB 3.0 PHY driver
+ depends on ARCH_EXYNOS5
+ select GENERIC_PHY
+ select MFD_SYSCON
+ help
+ Enable USB 3.0 PHY support for Exynos 5 SoC series
+
endmenu
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index d0caae9..9c06a61 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -7,3 +7,4 @@ obj-$(CONFIG_PHY_EXYNOS_DP_VIDEO) +=
phy-exynos-dp-video.o
obj-$(CONFIG_PHY_EXYNOS_MIPI_VIDEO) += phy-exynos-mipi-video.o
obj-$(CONFIG_OMAP_USB2) += phy-omap-usb2.o
obj-$(CONFIG_TWL4030_USB) += phy-twl4030-usb.o
+obj-$(CONFIG_PHY_EXYNOS5_USB3) += phy-exynos5-usb3.o
diff --git a/drivers/phy/phy-exynos5-usb3.c
b/drivers/phy/phy-exynos5-usb3.c
new file mode 100644
index 000..24efed0
--- /dev/null
+++ b/drivers/phy/phy-exynos5-usb3.c
@@ -0,0 +1,621 @@
+/*
+ * Samsung EXYNOS5 SoC series USB 3.0 PHY driver
+ *
+ * Copyright (C) 2013 Samsung Electronics Co., Ltd.
+ * Author: Vivek Gautam gautam.vi...@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.
+ */
+
+#include linux/clk.h
+#include linux/delay.h
+#include linux/io.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/of.h
+#include linux/of_address.h
+#include linux/phy/phy.h
+#include linux/platform_device.h
+#include linux/mutex.h
+#include linux/mfd/syscon.h
+#include linux/regmap.h
+
+/* Exynos USB PHY registers */
+#define EXYNOS5_FSEL_9MHZ6 0x0
+#define EXYNOS5_FSEL_10MHZ 0x1
+#define EXYNOS5_FSEL_12MHZ 0x2
+#define EXYNOS5_FSEL_19MHZ20x3
+#define EXYNOS5_FSEL_20MHZ 0x4
+#define EXYNOS5_FSEL_24MHZ 0x5
+#define EXYNOS5_FSEL_50MHZ 0x7
+
+/* EXYNOS5: USB 3.0 DRD PHY registers */
+#define EXYNOS5_DRD_LINKSYSTEM
Re: Instructions to release your payment.
Attention Sir, Following an application brought, seeking the release of your due payment through British bank, I am directed to inform you that the application has been approved and Natwest bank of London has been mandated to make transfer of your payment to the bank account you will nominate. Please kindly reply for immediate release of your US$6.2 Million to you nominates account. Sir, for the avoidance of doubts, reconfirm the following information to me to enable us forward same to Natwest bank to contact you for your payment. Name: Address: Tel/Fax No.: Nationality: Occupation: Date of birth: As soon as I received the above information, I will forward them to Natwest bank to contact you for your approved payment. Please see in the attachment, letter I wrote to Natwest bank informing them of the transaction Yours faithfully Dr.William Davies Chairman,British Banking Regulatory Board. -- 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 v3] phy: Add new Exynos5 USB 3.0 PHY driver
Hi Vivek, On 14.02.2014 14:53, Vivek Gautam wrote: Changes from v2: 1) Added support for multiple PHYs (UTMI+ and PIPE3) and related changes in the driver structuring. I'm a bit skeptical about this separation. Can the PHY operate with just the UTMI+ or PIPE3 part enabled alone without the other? Can any PHY consumer operate this way? Yes :-) As also pointed by Kishon the PHY consumer (which is DWC3 in case of Exynos5 SoC series) should theoretically be able use either UTMI+ phy for High speed operations or both (UTMI+ and PIPE3) for Super Speed operations. OK, that's fine then. This is the explanation I needed, thanks. I believe the right thing to do here is to do all the initialization in .power_on() and let the driver simply call phy_power_on() when it needs the PHY and phy_power_off() otherwise. If this is what we should be doing then what will be the purpose of two separate APIs : phy_power_on() and phy_init(). Am i missing while understanding the things. I don't understand this separation as well. Operations that should be done together shouldn't be separated. Is there any case when you can call one of phy_power_on() and phy_init() without calling another one right before/after it? 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 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family
On Thursday 13 February 2014, Olof Johansson wrote: On Mon, Feb 10, 2014 at 6:52 PM, Kukjin Kim kgene@samsung.com wrote: On 02/13/14 04:14, Arnd Bergmann wrote: On Wednesday 12 February 2014 13:04:40 Kumar Gala wrote: Basically, I agreed with Arnd's suggestion to use ARCH_SBSA. Or we need to define level in Kconfig like ARCH_SBSA_L1 for level1. BTW, how about compliant with SBSA Level1 and having some specific features? My feeling is that we don't need to use the levels for Kconfig, although we might want to use them DT compatible strings, even if it ends up looking a little funny when you do compatible = arm,sbsa-l3, arm,sbsa-l2, arm,sbsa-l1; What kind of features are you expecting though? More IP blocks/devices? Those are just kernel config options to enable, ideally as modules. Right, I think we can just put them into defconfig. No need to select them from Kconfig since the extra options wouldn't be required for booting or using the system. Arnd -- 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] spi: s3c24xx: Convert to let spi core validate bits_per_word
On Fri, Feb 14, 2014 at 08:38:16PM +0800, Axel Lin wrote: Set bits_per_word_mask so spi core will reject transfers that attempt to use an unsupported bits_per_word value. Applied, thanks. signature.asc Description: Digital signature
Re: [PATCH v3 3/3] ARM: dts: add dts files for xyref5260 board
Hi Rahul,
The patch looks good, except one issue pointed inline.
On 14.02.2014 14:37, Rahul Sharma wrote:
diff --git a/arch/arm/boot/dts/exynos5260-xyref5260-evt0.dts
b/arch/arm/boot/dts/exynos5260-xyref5260-evt0.dts
new file mode 100644
index 000..c4efc1e
--- /dev/null
+++ b/arch/arm/boot/dts/exynos5260-xyref5260-evt0.dts
[snip]
+mmc_0 {
+ status = okay;
+ num-slots = 1;
+ broken-cd;
+ bypass-smu;
+ supports-highspeed;
+ supports-hs200-mode; /* 200 Mhz */
+ fifo-depth = 0x40;
This is a SoC-level property and it is already specified in your
exynos5260.dtsi.
+ card-detect-delay = 200;
+ samsung,dw-mshc-ciu-div = 3;
+ samsung,dw-mshc-sdr-timing = 0 4;
+ samsung,dw-mshc-ddr-timing = 0 2;
+ pinctrl-names = default;
+ pinctrl-0 = sd0_rdqs sd0_clk sd0_cmd sd0_bus1 sd0_bus4 sd0_bus8;
+
+ slot@0 {
+ reg = 0;
+ bus-width = 8;
+ };
+};
+
+mmc_2 {
+ status = okay;
+ num-slots = 1;
+ supports-highspeed;
+ fifo-depth = 0x40;
Ditto.
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 v3 1/3] ARM: EXYNOS: initial board support for exynos5260 SoC
Hi, On 14.02.2014 14:37, Rahul Sharma wrote: From: Pankaj Dubey pankaj.du...@samsung.com This patch add basic arch side support for exynos5260 SoC. Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com Signed-off-by: Arun Kumar K arun...@samsung.com Signed-off-by: Rahul Sharma rahul.sha...@samsung.com --- arch/arm/mach-exynos/Kconfig |9 + arch/arm/mach-exynos/common.c| 11 +++ arch/arm/mach-exynos/include/mach/map.h |1 + arch/arm/mach-exynos/mach-exynos5-dt.c |1 + arch/arm/plat-samsung/include/plat/cpu.h |8 5 files changed, 30 insertions(+) Reviewed-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 v1 0/2] exynos_mct driver: fix irq allocation and cleanup
On Thu, Feb 13, 2014 at 10:31 PM, Tarek Dakhran t.dakh...@gmail.com wrote: Hi Tomasz, On Thursday, February 13, 2014, Tomasz Figa t.f...@samsung.com wrote: Hi Tarek, On 13.02.2014 04:08, Tarek Dakhran wrote: exynos4_local_timer_setup called on the secondary cpu before irqs are enabled. request_irq can sleep, which produces next warning: on boot: [0.37] CPU0: thread -1, cpu 0, socket 0, mpidr 8000 [0.37] Setting up static identity map for 0x403b5700 - 0x403b5758 [0.395000] CPU1: Booted secondary processor [0.395000] [ cut here ] [0.395000] WARNING: CPU: 1 PID: 0 at kernel/locking/lockdep.c:2742 lockdep_trace_alloc+0xe0/0xfc() [0.395000] DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags)) [0.395000] Modules linked in: [0.395000] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.14.0-rc2-4-g0db95f4 #128 [0.395000] [c0014308] (unwind_backtrace) from [c0011690] (show_stack+0x10/0x14) [0.395000] [c0011690] (show_stack) from [c03ae7d0] (dump_stack+0x6c/0xb8) [0.395000] [c03ae7d0] (dump_stack) from [c001d504] (warn_slowpath_common+0x68/0x8c) [0.395000] [c001d504] (warn_slowpath_common) from [c001d5bc] (warn_slowpath_fmt+0x30/0x40) [0.395000] [c001d5bc] (warn_slowpath_fmt) from [c0059824] (lockdep_trace_alloc+0xe0/0xfc) [0.395000] [c0059824] (lockdep_trace_alloc) from [c00bee24] (kmem_cache_alloc+0x24/0x160) [0.395000] [c00bee24] (kmem_cache_alloc) from [c0068174] (request_threaded_irq+0x64/0x130) [0.395000] [c0068174] (request_threaded_irq) from [c02efaf8] (exynos4_local_timer_setup+0xd0/0x124) [0.395000] [c02efaf8] (exynos4_local_timer_setup) from [c02efc34] (exynos4_mct_cpu_notify+0x78/0xf0) [0.395000] [c02efc34] (exynos4_mct_cpu_notify) from [c003d318] (notifier_call_chain+0x44/0x84) [0.395000] [c003d318] (notifier_call_chain) from [c001d61c] (__cpu_notify+0x24/0x40) [0.395000] [c001d61c] (__cpu_notify) from [c0013314] (secondary_start_kernel+0xe4/0x134) [0.395000] [c0013314] (secondary_start_kernel) from [40008624] (0x40008624) [0.395000] ---[ end trace 347890460e745f50 ]--- [0.42] CPU1: update cpu_power 1024 [0.42] CPU1: thread -1, cpu 1, socket 0, mpidr 8001 on hotplug: [ 108.04] CPU3: Booted secondary processor [ 108.04] BUG: sleeping function called from invalid context at mm/slub.c:965 [ 108.04] in_atomic(): 1, irqs_disabled(): 128, pid: 0, name: swapper/3 [ 108.04] INFO: lockdep is turned off. [ 108.04] irq event stamp: 0 [ 108.04] hardirqs last enabled at (0): [ (null)] (null) [ 108.04] hardirqs last disabled at (0): [c001b768] copy_process.part.2+0x2a4/0x12f4 [ 108.04] softirqs last enabled at (0): [c001b768] copy_process.part.2+0x2a4/0x12f4 [ 108.04] softirqs last disabled at (0): [ (null)] (null) [ 108.04] CPU: 3 PID: 0 Comm: swapper/3 Tainted: GW 3.14.0-rc2-4-g0db95f4 #128 [ 108.04] [c0014308] (unwind_backtrace) from [c0011690] (show_stack+0x10/0x14) [ 108.04] [c0011690] (show_stack) from [c03ae7d0] (dump_stack+0x6c/0xb8) [ 108.04] [c03ae7d0] (dump_stack) from [c00beed4] (kmem_cache_alloc+0xd4/0x160) [ 108.04] [c00beed4] (kmem_cache_alloc) from [c0068174] (request_threaded_irq+0x64/0x130) [ 108.04] [c0068174] (request_threaded_irq) from [c02efaf8] (exynos4_local_timer_setup+0xd0/0x124) [ 108.04] [c02efaf8] (exynos4_local_timer_setup) from [c02efc34] (exynos4_mct_cpu_notify+0x78/0xf0) [ 108.04] [c02efc34] (exynos4_mct_cpu_notify) from [c003d318] (notifier_call_chain+0x44/0x84) [ 108.04] [c003d318] (notifier_call_chain) from [c001d61c] (__cpu_notify+0x24/0x40) [ 108.04] [c001d61c] (__cpu_notify) from [c0013314] (secondary_start_kernel+0xe4/0x134) [ 108.04] [c0013314] (secondary_start_kernel) from [40008624] (0x40008624) First patch fixes this problem by removing request_irq from exynos4_local_timer_setup Second removes non-dt stuff. Tested on linux kernel v3.14-rc2. It would be nice to say on which boards it has been tested. Let me check this on our boards anyway. Best regards, Tomasz Tested on smdk5410 reference board with lockdep enabled. I think the problem will present on all boards due to call sleeping function in irq_disabled context. Best Regards, Tarek Has anyone else tested this patches? if yes, what is the result? Best regards, . Tarek -- 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
