Re: [PATCH V2 00/19] bus: omap_l3_noc: driver cleanups and support for DRA7/AM4372
On 04/24/2014 05:19 PM, Nishanth Menon wrote: On 04/24/2014 03:55 AM, Peter Ujfalusi wrote: On 04/18/2014 12:00 AM, Nishanth Menon wrote: On 04/17/2014 03:57 PM, Santosh Shilimkar wrote: I looked at the series and its looks pretty good. Thanks for fixups, updates. For whole series, Acked-by: Santosh Shilimkar santosh.shilim...@ti.com Thanks. Patches(including Peter's) is available here: https://github.com/nmenon/linux-2.6-playground/commits/l3noc/driver-fixes-v2 Can Tony pull this branch for 3.16 then which includes Peter's series as well ? there is just an empty commit with information about peter's patches that i lined up to differentiate the series.. I can drop it if Tony would like me to. Looking at the branch I see my patches underneath so they are in the branch. It would be great if Tony pulls this... Will be a great present to my patches (omap_l3 patches in the branch) for their 1 year anniversary of being out on the mailing list ;) Peter, can I take this as an Ack for this series? if yes, I can repost a v3 with all the acks, updates together. Nishanth, sure you can add my Ack or Reviewed-by. -- Péter -- To unsubscribe from this list: send the line unsubscribe linux-omap 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: am43x-clock: add tbclk data for ehrpwm.
On 04/25/2014 08:42 AM, sourav wrote:
Hi Tero,
On Tuesday 22 April 2014 06:11 PM, Tero Kristo wrote:
On 04/22/2014 01:25 PM, Sourav Poddar wrote:
We need tblclk clock data for the functioning of ehrpwm
module. Hence, populating the required clock information
in clock dts file.
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
arch/arm/boot/dts/am43xx-clocks.dtsi | 84
++
drivers/clk/ti/clk-43xx.c|6 +++
2 files changed, 90 insertions(+)
diff --git a/arch/arm/boot/dts/am43xx-clocks.dtsi
b/arch/arm/boot/dts/am43xx-clocks.dtsi
index 142009c..869f9a5 100644
--- a/arch/arm/boot/dts/am43xx-clocks.dtsi
+++ b/arch/arm/boot/dts/am43xx-clocks.dtsi
@@ -87,6 +87,90 @@
clock-mult = 1;
clock-div = 1;
};
+
+ehrpwm0_gate_tbclk: ehrpwm0_gate_tbclk {
+#clock-cells = 0;
+compatible = ti,composite-no-wait-gate-clock;
+clocks = dpll_per_m2_ck;
+ti,bit-shift = 0;
+reg = 0x0664;
+};
+
+ehrpwm0_tbclk: ehrpwm0_tbclk {
+#clock-cells = 0;
+compatible = ti,composite-clock;
+clocks = ehrpwm0_gate_tbclk;
+};
Why do you use composite-clock type here? I see only add one sub-clock
to the composite, thus the composite part is unused. How about using a
gate-clock type only? Same question applies for the rest of the patch
also.
Yes, I though of doing so and I think it should be fine to use
gate-clock only. I did this following the ehrpwm clock data in
am33xx-clock.dtsi file, where we use composite clock for ehrpwm. I
think it needs to be changed there also.?
Yeah, that seems to be a quirk that was generated by the automatic
conversion script, there is no reason for these being composite clocks
either.
-Tero
-Sourav
-Tero
+
+ehrpwm1_gate_tbclk: ehrpwm1_gate_tbclk {
+#clock-cells = 0;
+compatible = ti,composite-no-wait-gate-clock;
+clocks = dpll_per_m2_ck;
+ti,bit-shift = 1;
+reg = 0x0664;
+};
+
+ehrpwm1_tbclk: ehrpwm1_tbclk {
+#clock-cells = 0;
+compatible = ti,composite-clock;
+clocks = ehrpwm1_gate_tbclk;
+};
+
+ehrpwm2_gate_tbclk: ehrpwm2_gate_tbclk {
+#clock-cells = 0;
+compatible = ti,composite-no-wait-gate-clock;
+clocks = dpll_per_m2_ck;
+ti,bit-shift = 2;
+reg = 0x0664;
+};
+
+ehrpwm2_tbclk: ehrpwm2_tbclk {
+#clock-cells = 0;
+compatible = ti,composite-clock;
+clocks = ehrpwm2_gate_tbclk;
+};
+
+ehrpwm3_gate_tbclk: ehrpwm3_gate_tbclk {
+#clock-cells = 0;
+compatible = ti,composite-no-wait-gate-clock;
+clocks = dpll_per_m2_ck;
+ti,bit-shift = 2;
+reg = 0x0664;
+};
+
+ehrpwm3_tbclk: ehrpwm3_tbclk {
+#clock-cells = 0;
+compatible = ti,composite-clock;
+clocks = ehrpwm3_gate_tbclk;
+};
+
+ehrpwm4_gate_tbclk: ehrpwm4_gate_tbclk {
+#clock-cells = 0;
+compatible = ti,composite-no-wait-gate-clock;
+clocks = dpll_per_m2_ck;
+ti,bit-shift = 2;
+reg = 0x0664;
+};
+
+ehrpwm4_tbclk: ehrpwm4_tbclk {
+#clock-cells = 0;
+compatible = ti,composite-clock;
+clocks = ehrpwm4_gate_tbclk;
+};
+
+ehrpwm5_gate_tbclk: ehrpwm5_gate_tbclk {
+#clock-cells = 0;
+compatible = ti,composite-no-wait-gate-clock;
+clocks = dpll_per_m2_ck;
+ti,bit-shift = 2;
+reg = 0x0664;
+};
+
+ehrpwm5_tbclk: ehrpwm5_tbclk {
+#clock-cells = 0;
+compatible = ti,composite-clock;
+clocks = ehrpwm5_gate_tbclk;
+};
};
prcm_clocks {
clk_32768_ck: clk_32768_ck {
diff --git a/drivers/clk/ti/clk-43xx.c b/drivers/clk/ti/clk-43xx.c
index 67c8de5..5413a6a 100644
--- a/drivers/clk/ti/clk-43xx.c
+++ b/drivers/clk/ti/clk-43xx.c
@@ -105,6 +105,12 @@ static struct ti_dt_clk am43xx_clks[] = {
DT_CLK(NULL, func_12m_clk, func_12m_clk),
DT_CLK(NULL, vtp_clk_div, vtp_clk_div),
DT_CLK(NULL, usbphy_32khz_clkmux, usbphy_32khz_clkmux),
+DT_CLK(48300200.ehrpwm, tbclk, ehrpwm0_tbclk),
+DT_CLK(48302200.ehrpwm, tbclk, ehrpwm1_tbclk),
+DT_CLK(48304200.ehrpwm, tbclk, ehrpwm2_tbclk),
+DT_CLK(48306200.ehrpwm, tbclk, ehrpwm0_tbclk),
+DT_CLK(48308200.ehrpwm, tbclk, ehrpwm1_tbclk),
+DT_CLK(4830a200.ehrpwm, tbclk, ehrpwm2_tbclk),
{ .node_name = NULL },
};
--
To unsubscribe from this list: send the line unsubscribe linux-omap 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: am43x-clock: add tbclk data for ehrpwm.
On Friday 25 April 2014 12:19 PM, Tero Kristo wrote:
On 04/25/2014 08:42 AM, sourav wrote:
Hi Tero,
On Tuesday 22 April 2014 06:11 PM, Tero Kristo wrote:
On 04/22/2014 01:25 PM, Sourav Poddar wrote:
We need tblclk clock data for the functioning of ehrpwm
module. Hence, populating the required clock information
in clock dts file.
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
arch/arm/boot/dts/am43xx-clocks.dtsi | 84
++
drivers/clk/ti/clk-43xx.c|6 +++
2 files changed, 90 insertions(+)
diff --git a/arch/arm/boot/dts/am43xx-clocks.dtsi
b/arch/arm/boot/dts/am43xx-clocks.dtsi
index 142009c..869f9a5 100644
--- a/arch/arm/boot/dts/am43xx-clocks.dtsi
+++ b/arch/arm/boot/dts/am43xx-clocks.dtsi
@@ -87,6 +87,90 @@
clock-mult = 1;
clock-div = 1;
};
+
+ehrpwm0_gate_tbclk: ehrpwm0_gate_tbclk {
+#clock-cells = 0;
+compatible = ti,composite-no-wait-gate-clock;
+clocks = dpll_per_m2_ck;
+ti,bit-shift = 0;
+reg = 0x0664;
+};
+
+ehrpwm0_tbclk: ehrpwm0_tbclk {
+#clock-cells = 0;
+compatible = ti,composite-clock;
+clocks = ehrpwm0_gate_tbclk;
+};
Why do you use composite-clock type here? I see only add one sub-clock
to the composite, thus the composite part is unused. How about using a
gate-clock type only? Same question applies for the rest of the patch
also.
Yes, I though of doing so and I think it should be fine to use
gate-clock only. I did this following the ehrpwm clock data in
am33xx-clock.dtsi file, where we use composite clock for ehrpwm. I
think it needs to be changed there also.?
Yeah, that seems to be a quirk that was generated by the automatic
conversion script, there is no reason for these being composite clocks
either.
OK, I will send the updated patch for both am33xx and am43xx devices.
Thanks,
Sourav
-Tero
-Sourav
-Tero
+
+ehrpwm1_gate_tbclk: ehrpwm1_gate_tbclk {
+#clock-cells = 0;
+compatible = ti,composite-no-wait-gate-clock;
+clocks = dpll_per_m2_ck;
+ti,bit-shift = 1;
+reg = 0x0664;
+};
+
+ehrpwm1_tbclk: ehrpwm1_tbclk {
+#clock-cells = 0;
+compatible = ti,composite-clock;
+clocks = ehrpwm1_gate_tbclk;
+};
+
+ehrpwm2_gate_tbclk: ehrpwm2_gate_tbclk {
+#clock-cells = 0;
+compatible = ti,composite-no-wait-gate-clock;
+clocks = dpll_per_m2_ck;
+ti,bit-shift = 2;
+reg = 0x0664;
+};
+
+ehrpwm2_tbclk: ehrpwm2_tbclk {
+#clock-cells = 0;
+compatible = ti,composite-clock;
+clocks = ehrpwm2_gate_tbclk;
+};
+
+ehrpwm3_gate_tbclk: ehrpwm3_gate_tbclk {
+#clock-cells = 0;
+compatible = ti,composite-no-wait-gate-clock;
+clocks = dpll_per_m2_ck;
+ti,bit-shift = 2;
+reg = 0x0664;
+};
+
+ehrpwm3_tbclk: ehrpwm3_tbclk {
+#clock-cells = 0;
+compatible = ti,composite-clock;
+clocks = ehrpwm3_gate_tbclk;
+};
+
+ehrpwm4_gate_tbclk: ehrpwm4_gate_tbclk {
+#clock-cells = 0;
+compatible = ti,composite-no-wait-gate-clock;
+clocks = dpll_per_m2_ck;
+ti,bit-shift = 2;
+reg = 0x0664;
+};
+
+ehrpwm4_tbclk: ehrpwm4_tbclk {
+#clock-cells = 0;
+compatible = ti,composite-clock;
+clocks = ehrpwm4_gate_tbclk;
+};
+
+ehrpwm5_gate_tbclk: ehrpwm5_gate_tbclk {
+#clock-cells = 0;
+compatible = ti,composite-no-wait-gate-clock;
+clocks = dpll_per_m2_ck;
+ti,bit-shift = 2;
+reg = 0x0664;
+};
+
+ehrpwm5_tbclk: ehrpwm5_tbclk {
+#clock-cells = 0;
+compatible = ti,composite-clock;
+clocks = ehrpwm5_gate_tbclk;
+};
};
prcm_clocks {
clk_32768_ck: clk_32768_ck {
diff --git a/drivers/clk/ti/clk-43xx.c b/drivers/clk/ti/clk-43xx.c
index 67c8de5..5413a6a 100644
--- a/drivers/clk/ti/clk-43xx.c
+++ b/drivers/clk/ti/clk-43xx.c
@@ -105,6 +105,12 @@ static struct ti_dt_clk am43xx_clks[] = {
DT_CLK(NULL, func_12m_clk, func_12m_clk),
DT_CLK(NULL, vtp_clk_div, vtp_clk_div),
DT_CLK(NULL, usbphy_32khz_clkmux, usbphy_32khz_clkmux),
+DT_CLK(48300200.ehrpwm, tbclk, ehrpwm0_tbclk),
+DT_CLK(48302200.ehrpwm, tbclk, ehrpwm1_tbclk),
+DT_CLK(48304200.ehrpwm, tbclk, ehrpwm2_tbclk),
+DT_CLK(48306200.ehrpwm, tbclk, ehrpwm0_tbclk),
+DT_CLK(48308200.ehrpwm, tbclk, ehrpwm1_tbclk),
+DT_CLK(4830a200.ehrpwm, tbclk, ehrpwm2_tbclk),
{ .node_name = NULL },
};
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] arm: dts: am33xx-clock: Fix ehrpwm tbclk data.
tbclk does not need to be a composite clock, we can simply
use gate clock for this purpose.
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
arch/arm/boot/dts/am33xx-clocks.dtsi | 42 ++
1 file changed, 12 insertions(+), 30 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx-clocks.dtsi
b/arch/arm/boot/dts/am33xx-clocks.dtsi
index 9ccfe50..a45d27f 100644
--- a/arch/arm/boot/dts/am33xx-clocks.dtsi
+++ b/arch/arm/boot/dts/am33xx-clocks.dtsi
@@ -96,46 +96,28 @@
clock-div = 1;
};
- ehrpwm0_gate_tbclk: ehrpwm0_gate_tbclk {
+ ehrpwm0_tbclk: ehrpwm0_tbclk@44e10664 {
#clock-cells = 0;
- compatible = ti,composite-no-wait-gate-clock;
+ compatible = gate-clock;
clocks = dpll_per_m2_ck;
- ti,bit-shift = 0;
- reg = 0x0664;
+ bit-shift = 0;
+ reg = 0x44e10664 0x4;
};
- ehrpwm0_tbclk: ehrpwm0_tbclk {
+ ehrpwm1_tbclk: ehrpwm1_tbclk@44e10664 {
#clock-cells = 0;
- compatible = ti,composite-clock;
- clocks = ehrpwm0_gate_tbclk;
- };
-
- ehrpwm1_gate_tbclk: ehrpwm1_gate_tbclk {
- #clock-cells = 0;
- compatible = ti,composite-no-wait-gate-clock;
+ compatible = gate-clock;
clocks = dpll_per_m2_ck;
- ti,bit-shift = 1;
- reg = 0x0664;
- };
-
- ehrpwm1_tbclk: ehrpwm1_tbclk {
- #clock-cells = 0;
- compatible = ti,composite-clock;
- clocks = ehrpwm1_gate_tbclk;
+ bit-shift = 1;
+ reg = 0x44e10664 0x4;
};
- ehrpwm2_gate_tbclk: ehrpwm2_gate_tbclk {
+ ehrpwm2_tbclk: ehrpwm2_tbclk@44e10664 {
#clock-cells = 0;
- compatible = ti,composite-no-wait-gate-clock;
+ compatible = gate-clock;
clocks = dpll_per_m2_ck;
- ti,bit-shift = 2;
- reg = 0x0664;
- };
-
- ehrpwm2_tbclk: ehrpwm2_tbclk {
- #clock-cells = 0;
- compatible = ti,composite-clock;
- clocks = ehrpwm2_gate_tbclk;
+ bit-shift = 2;
+ reg = 0x44e10664 0x4;
};
};
prcm_clocks {
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] arm: dts: am43x-clock: add tbclk data for ehrpwm.
We need tbclk clock data for the functioning of ehrpwm
module. Hence, populating the required clock information
in clock dts file.
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
arch/arm/boot/dts/am43xx-clocks.dtsi | 48 ++
drivers/clk/ti/clk-43xx.c|6 +
2 files changed, 54 insertions(+)
diff --git a/arch/arm/boot/dts/am43xx-clocks.dtsi
b/arch/arm/boot/dts/am43xx-clocks.dtsi
index 142009c..54f68e8 100644
--- a/arch/arm/boot/dts/am43xx-clocks.dtsi
+++ b/arch/arm/boot/dts/am43xx-clocks.dtsi
@@ -87,6 +87,54 @@
clock-mult = 1;
clock-div = 1;
};
+
+ ehrpwm0_tbclk: ehrpwm0_tbclk@44e10664 {
+ #clock-cells = 0;
+ compatible = gate-clock;
+ clocks = dpll_per_m2_ck;
+ bit-shift = 0;
+ reg = 0x44e10664 0x4;
+ };
+
+ ehrpwm1_tbclk: ehrpwm1_tbclk@44e10664 {
+ #clock-cells = 0;
+ compatible = gate-clock;
+ clocks = dpll_per_m2_ck;
+ bit-shift = 1;
+ reg = 0x44e10664 0x4;
+ };
+
+ ehrpwm2_tbclk: ehrpwm2_tbclk@44e10664 {
+ #clock-cells = 0;
+ compatible = gate-clock;
+ clocks = dpll_per_m2_ck;
+ bit-shift = 2;
+ reg = 0x44e10664 0x4;
+ };
+
+ ehrpwm3_tbclk: ehrpwm3_tbclk@44e10664 {
+ #clock-cells = 0;
+ compatible = gate-clock;
+ clocks = dpll_per_m2_ck;
+ bit-shift = 3;
+ reg = 0x44e10664 0x4;
+ };
+
+ ehrpwm4_tbclk: ehrpwm4_tbclk@44e10664 {
+ #clock-cells = 0;
+ compatible = gate-clock;
+ clocks = dpll_per_m2_ck;
+ bit-shift = 4;
+ reg = 0x44e10664 0x4;
+ };
+
+ ehrpwm5_tbclk: ehrpwm5_tbclk@44e10664 {
+ #clock-cells = 0;
+ compatible = gate-clock;
+ clocks = dpll_per_m2_ck;
+ bit-shift = 5;
+ reg = 0x44e10664 0x4;
+ };
};
prcm_clocks {
clk_32768_ck: clk_32768_ck {
diff --git a/drivers/clk/ti/clk-43xx.c b/drivers/clk/ti/clk-43xx.c
index 67c8de5..527a43d 100644
--- a/drivers/clk/ti/clk-43xx.c
+++ b/drivers/clk/ti/clk-43xx.c
@@ -105,6 +105,12 @@ static struct ti_dt_clk am43xx_clks[] = {
DT_CLK(NULL, func_12m_clk, func_12m_clk),
DT_CLK(NULL, vtp_clk_div, vtp_clk_div),
DT_CLK(NULL, usbphy_32khz_clkmux, usbphy_32khz_clkmux),
+ DT_CLK(48300200.ehrpwm, tbclk, ehrpwm0_tbclk),
+ DT_CLK(48302200.ehrpwm, tbclk, ehrpwm1_tbclk),
+ DT_CLK(48304200.ehrpwm, tbclk, ehrpwm2_tbclk),
+ DT_CLK(48306200.ehrpwm, tbclk, ehrpwm3_tbclk),
+ DT_CLK(48308200.ehrpwm, tbclk, ehrpwm4_tbclk),
+ DT_CLK(4830a200.ehrpwm, tbclk, ehrpwm5_tbclk),
{ .node_name = NULL },
};
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 10/13] tty: serial: omap: remove some dead code
On Thu, 24 Apr 2014 15:19:14 +0100 One Thousand Gnomes gno...@lxorguk.ukuu.org.uk wrote: But I don't have discrete hardware. I have a bunch of stuff soldered onto a board with ad-hoc connections chosen to make the life of the hardware builder easy rather than chosen to make the life of the software developer easy (which I think is the correct choice). So I need to tell DT This device is plugged into this UART, and there is no DTR line, but when the UARTs DTR line would be asserted (if it had one), then I need that regulator of there turned on. or maybe I need to toggle this GPIO with exactly this pattern, while watching that GPIO to see if it is working. So I thought: 1/ give the UART a virtual DTR so it could drive any GPIO 2/ create a gpio-to-regulator driver which presented as a (virtual) gpio and responded to state changes on that GPIO by turning on or off the regulator 3/ create a dedicated driver which knows how to toggle the magic GPIO while watching the other GPIO to convince the silly device to wakeup, or go to sleep, as required, and have this appear as a (virtual) GPIO. Unless you are using it as a real' DTR line then I think this is the wrong approach. This problem actually is turning up in both PC class and ARM boxes now all over the place for three reasons I am seeing. 1. We are getting a lot of hardware moving to serial attached bluetooth/gps/etc because of the power win. In addition ACPI can describe power relationships and what is on the other end of a UART embedded in the device 2. We've got cheap hardware with modem lines being retrofitted via gpio 3. There are a subset of devices that have extra control lines beyond the usual serial port ones. These range from additional control lines for things like smartcard programmers to port muxing. I have no problem either way, just that unused code doesn't have to be sitting in the tree and I'm not entirely sure this GPIO should be handled by omap-serial.c, perhaps something more generic inside serial-core so other UART drivers can benefit from it. serial-core provides power hooks. If the goal is that this comes on when you power up the uart and goes away on the last close then the hooks are there already. Could you be a bit more explicit, or point to an example user of these hooks? I had a quick look and I guess that uart_change_pm() is the most likely candidate for what you are referring to. I can see how that interfaces to the specific piece of uart hardware, such as omap-serial.c But I cannot see how you would plumb that though to the device that was plugged in to the serial port. I guess if that device could be registered as a child of the omap_serial device, then power management inheritance might come in to play, but I cannot see any way to tell a serial port that it has some arbitrary child device. So maybe I'm missing something. If its ldisc specific then the tty layer also calls the device on ldisc changes precisely so it can make hardware specific twiddles in such cases. A set of gpios on the tty_port object would not go amiss and would also address the PC case. considering this is a BTUART device, why didn't you do this at the ldisc level ? hci_uart_open() sounds like a good choice from a quick thinking. ldiscs are hardware independent. Nothing about hardware belongs in an ldisc. Any ldisc should within reason work on any port. What I propsed when it came up ages ago was to expose some gpio settings in the tty, to provide ways for them to be set by default and also ioctls to configure them. I still think this (but moved into the tty_port as its a persistent hardware property) is a good idea now that we are starting to see more use cases than weird dongles and muxes on pre-production reference boards. With my tty and serial hat on I think a power gpio is a no-brainer even without doing the other work and therefore it should probably be described generically for a serial port in the DT as well as in the ACPI data. If you should also be able to give it a regulator to use as well that also seems to make complete sense. In one case the power on sequence is substantially more complex that just a gpio or regulator. I would need to write a device driver for the (GPS) chip which could receive a poweron/poweroff signal from the uart and do the required magic. Having serial-core know about gpios and regulators and random other stuff seems wrong. I would really like to see the runtime interpreted power sequences become a real thing. Then serial-core could activate a RIPS, and that would have the flexibility to do whatever is needed without adding complexity to serial-core. Using a virtual GPIO was my poor-mans RIPS. Using gpiolib, and driver can pretend to be a gpio so it is a simple pipe to send a power-on/power-off signal over. So ... with
Re: [PATCH 10/13] tty: serial: omap: remove some dead code
On Fri, Apr 25, 2014 at 11:34 AM, NeilBrown ne...@suse.de wrote: On Thu, 24 Apr 2014 15:19:14 +0100 One Thousand Gnomes gno...@lxorguk.ukuu.org.uk wrote: But I don't have discrete hardware. I have a bunch of stuff soldered onto a board with ad-hoc connections chosen to make the life of the hardware builder easy rather than chosen to make the life of the software developer easy (which I think is the correct choice). So I need to tell DT This device is plugged into this UART, and there is no DTR line, but when the UARTs DTR line would be asserted (if it had one), then I need that regulator of there turned on. or maybe I need to toggle this GPIO with exactly this pattern, while watching that GPIO to see if it is working. So I thought: 1/ give the UART a virtual DTR so it could drive any GPIO 2/ create a gpio-to-regulator driver which presented as a (virtual) gpio and responded to state changes on that GPIO by turning on or off the regulator 3/ create a dedicated driver which knows how to toggle the magic GPIO while watching the other GPIO to convince the silly device to wakeup, or go to sleep, as required, and have this appear as a (virtual) GPIO. Unless you are using it as a real' DTR line then I think this is the wrong approach. This problem actually is turning up in both PC class and ARM boxes now all over the place for three reasons I am seeing. 1. We are getting a lot of hardware moving to serial attached bluetooth/gps/etc because of the power win. In addition ACPI can describe power relationships and what is on the other end of a UART embedded in the device 2. We've got cheap hardware with modem lines being retrofitted via gpio 3. There are a subset of devices that have extra control lines beyond the usual serial port ones. These range from additional control lines for things like smartcard programmers to port muxing. I have no problem either way, just that unused code doesn't have to be sitting in the tree and I'm not entirely sure this GPIO should be handled by omap-serial.c, perhaps something more generic inside serial-core so other UART drivers can benefit from it. serial-core provides power hooks. If the goal is that this comes on when you power up the uart and goes away on the last close then the hooks are there already. Could you be a bit more explicit, or point to an example user of these hooks? I had a quick look and I guess that uart_change_pm() is the most likely candidate for what you are referring to. I can see how that interfaces to the specific piece of uart hardware, such as omap-serial.c But I cannot see how you would plumb that though to the device that was plugged in to the serial port. I guess if that device could be registered as a child of the omap_serial device, then power management inheritance might come in to play, but I cannot see any way to tell a serial port that it has some arbitrary child device. So maybe I'm missing something. If its ldisc specific then the tty layer also calls the device on ldisc changes precisely so it can make hardware specific twiddles in such cases. A set of gpios on the tty_port object would not go amiss and would also address the PC case. considering this is a BTUART device, why didn't you do this at the ldisc level ? hci_uart_open() sounds like a good choice from a quick thinking. ldiscs are hardware independent. Nothing about hardware belongs in an ldisc. Any ldisc should within reason work on any port. What I propsed when it came up ages ago was to expose some gpio settings in the tty, to provide ways for them to be set by default and also ioctls to configure them. I still think this (but moved into the tty_port as its a persistent hardware property) is a good idea now that we are starting to see more use cases than weird dongles and muxes on pre-production reference boards. With my tty and serial hat on I think a power gpio is a no-brainer even without doing the other work and therefore it should probably be described generically for a serial port in the DT as well as in the ACPI data. If you should also be able to give it a regulator to use as well that also seems to make complete sense. In one case the power on sequence is substantially more complex that just a gpio or regulator. I would need to write a device driver for the (GPS) chip which could receive a poweron/poweroff signal from the uart and do the required magic. Having serial-core know about gpios and regulators and random other stuff seems wrong. I would really like to see the runtime interpreted power sequences become a real thing. Then serial-core could activate a RIPS, and that would have the flexibility to do whatever is needed without adding complexity to serial-core. Using a virtual GPIO was my poor-mans RIPS. Using gpiolib, and driver can pretend to be a
Re: [PATCH 01/23] OMAPDSS: HDMI: lane config support
Hi,
On Thursday 24 April 2014 03:46 PM, Tomi Valkeinen wrote:
Add support to configure the pins used for the HDMI lanes. The order and
polarity of the lanes can be defined in the DT data.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
+static void hdmi_phy_configure_lanes(struct hdmi_phy_data *phy)
+{
+ static const u16 pad_cfg_list[] = {
+ 0x0123,
+ 0x0132,
+ 0x0312,
+ 0x0321,
+ 0x0231,
+ 0x0213,
+ 0x1023,
+ 0x1032,
+ 0x3012,
+ 0x3021,
+ 0x2031,
+ 0x2013,
+ 0x1203,
+ 0x1302,
+ 0x3102,
+ 0x3201,
+ 0x2301,
+ 0x2103,
+ 0x1230,
+ 0x1320,
+ 0x3120,
+ 0x3210,
+ 0x2310,
+ 0x2130,
+ };
+
+ u16 lane_cfg = 0;
+ int i;
+ unsigned lane_cfg_val;
+ u16 pol_val = 0;
+
+ for (i = 0; i 4; ++i)
+ lane_cfg |= phy-lane_function[i] ((3 - i) * 4);
+
+ pol_val |= phy-lane_polarity[0] 0;
+ pol_val |= phy-lane_polarity[1] 3;
+ pol_val |= phy-lane_polarity[2] 2;
+ pol_val |= phy-lane_polarity[3] 1;
+
+ for (i = 0; i ARRAY_SIZE(pad_cfg_list); ++i)
+ if (pad_cfg_list[i] == lane_cfg)
+ break;
+
+ if (WARN_ON(i == ARRAY_SIZE(pad_cfg_list)))
+ i = 0;
+
+ lane_cfg_val = i;
I spent some time to see if we could get create lane_cfg_val without
having the table above, looks like there is no pattern at all in the
register field.
+
+ REG_FLD_MOD(phy-base, HDMI_TXPHY_PAD_CFG_CTRL, lane_cfg_val, 26, 22);
+ REG_FLD_MOD(phy-base, HDMI_TXPHY_PAD_CFG_CTRL, pol_val, 30, 27);
+}
+
int hdmi_phy_enable(struct hdmi_phy_data *phy, struct hdmi_wp_data *wp,
struct hdmi_config *cfg)
{
@@ -92,8 +183,7 @@ int hdmi_phy_enable(struct hdmi_phy_data *phy, struct
hdmi_wp_data *wp,
/* Setup max LDO voltage */
REG_FLD_MOD(phy-base, HDMI_TXPHY_POWER_CTRL, 0xB, 3, 0);
- /* Write to phy address 3 to change the polarity control */
- REG_FLD_MOD(phy-base, HDMI_TXPHY_PAD_CFG_CTRL, 0x1, 27, 27);
wow, didn't realize it was hardcoded like this.
Reviewed-by: Archit Taneja arc...@ti.com?
Archit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/23] OMAPDSS: HDMI: lane config support
On 25/04/14 13:06, Archit Taneja wrote:
I spent some time to see if we could get create lane_cfg_val without
having the table above, looks like there is no pattern at all in the
register field.
There is a pattern, but I wasn't able to figure out a formula to model
it. And as the array was not very long, and was easy to create with copy
paste and search-replace from the TRM, I thought it's just simplest way
to do it.
+
+REG_FLD_MOD(phy-base, HDMI_TXPHY_PAD_CFG_CTRL, lane_cfg_val, 26,
22);
+REG_FLD_MOD(phy-base, HDMI_TXPHY_PAD_CFG_CTRL, pol_val, 30, 27);
+}
+
int hdmi_phy_enable(struct hdmi_phy_data *phy, struct hdmi_wp_data *wp,
struct hdmi_config *cfg)
{
@@ -92,8 +183,7 @@ int hdmi_phy_enable(struct hdmi_phy_data *phy,
struct hdmi_wp_data *wp,
/* Setup max LDO voltage */
REG_FLD_MOD(phy-base, HDMI_TXPHY_POWER_CTRL, 0xB, 3, 0);
-/* Write to phy address 3 to change the polarity control */
-REG_FLD_MOD(phy-base, HDMI_TXPHY_PAD_CFG_CTRL, 0x1, 27, 27);
wow, didn't realize it was hardcoded like this.
Reviewed-by: Archit Taneja arc...@ti.com?
Thanks!
Tomi
signature.asc
Description: OpenPGP digital signature
Re: [PATCH 06/23] ARM: OMAP: add OMAP5 DSI muxing
Hi, On Thursday 24 April 2014 03:47 PM, Tomi Valkeinen wrote: Add support to set OMAP5 DSI pin muxing. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com Cc: Tony Lindgren t...@atomide.com --- arch/arm/mach-omap2/display.c | 35 ++- 1 file changed, 34 insertions(+), 1 deletion(-) diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c index 16d33d831287..974461441fc3 100644 --- a/arch/arm/mach-omap2/display.c +++ b/arch/arm/mach-omap2/display.c @@ -137,11 +137,42 @@ static int omap4_dsi_mux_pads(int dsi_id, unsigned lanes) return 0; } +#define CONTROL_PAD_BASE 0x4A002800 +#define CONTROL_DSIPHY 0x614 + I guess this is something we can move to our driver, and use sysconf to get the register from DT. Archit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 06/23] ARM: OMAP: add OMAP5 DSI muxing
On 25/04/14 14:11, Archit Taneja wrote: Hi, On Thursday 24 April 2014 03:47 PM, Tomi Valkeinen wrote: Add support to set OMAP5 DSI pin muxing. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com Cc: Tony Lindgren t...@atomide.com --- arch/arm/mach-omap2/display.c | 35 ++- 1 file changed, 34 insertions(+), 1 deletion(-) diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c index 16d33d831287..974461441fc3 100644 --- a/arch/arm/mach-omap2/display.c +++ b/arch/arm/mach-omap2/display.c @@ -137,11 +137,42 @@ static int omap4_dsi_mux_pads(int dsi_id, unsigned lanes) return 0; } +#define CONTROL_PAD_BASE0x4A002800 +#define CONTROL_DSIPHY0x614 + I guess this is something we can move to our driver, and use sysconf to get the register from DT. I just copied the same method as used for OMAP4. I guess sysconf is an option. But I really dislike the idea of moving omap control module code to a display driver... I'm not sure what other options we have, though. Maybe an OMAP DSI specific pinctrl driver? Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 10/13] tty: serial: omap: remove some dead code
As soon as this patch (http://www.spinics.net/lists/arm-kernel/msg325197.html) will be applied, we don't really need this DTR GPIO any more. For the omap specific case, not for the general case of sorting out power hierarchies. Alan -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 10/13] tty: serial: omap: remove some dead code
I had a quick look and I guess that uart_change_pm() is the most likely candidate for what you are referring to. I can see how that interfaces to the specific piece of uart hardware, such as omap-serial.c But I cannot see how you would plumb that though to the device that was plugged in to the serial port. I guess if that device could be registered as a child of the omap_serial device, then power management inheritance might come in to play, but I cannot see any way to tell a serial port that it has some arbitrary child device. If your device is powered by something like a regulator then you can drive the regulator from the uart_pm helpers. In one case the power on sequence is substantially more complex that just a gpio or regulator. I would need to write a device driver for the (GPS) chip which could receive a poweron/poweroff signal from the uart and do the required magic. In which case giving the tty a child device (or devices) would probably be more sensible yes. No problem with that either. I would really like to see the runtime interpreted power sequences become a real thing. Then serial-core could activate a RIPS, and that would have the flexibility to do whatever is needed without adding complexity to serial-core. Something like ACPI has you mean ? When we put the device into D0 the ACPI methods can do stuff. So ... with your serial hat on, if I were to write/test a patch to allow any serial port to have a power-gpio described in DT and the gpio would be driven in uart_change_pm(), would you consider accepting that patch, or did I misunderstand? We are going to need it anyway for other devices fairly soon. It's common for new PC class hardware to have gpio management for the bluetooth, gps and and sometimes sensor devices attached to the tty. That's true irrespective of whether you happen to choose to use it for virtual gpio hacks. Alan -- To unsubscribe from this list: send the line unsubscribe linux-omap 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: am33xx-clock: Fix ehrpwm tbclk data.
On 04/25/2014 11:55 AM, Sourav Poddar wrote:
tbclk does not need to be a composite clock, we can simply
use gate clock for this purpose.
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
arch/arm/boot/dts/am33xx-clocks.dtsi | 42 ++
1 file changed, 12 insertions(+), 30 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx-clocks.dtsi
b/arch/arm/boot/dts/am33xx-clocks.dtsi
index 9ccfe50..a45d27f 100644
--- a/arch/arm/boot/dts/am33xx-clocks.dtsi
+++ b/arch/arm/boot/dts/am33xx-clocks.dtsi
@@ -96,46 +96,28 @@
clock-div = 1;
};
- ehrpwm0_gate_tbclk: ehrpwm0_gate_tbclk {
+ ehrpwm0_tbclk: ehrpwm0_tbclk@44e10664 {
#clock-cells = 0;
- compatible = ti,composite-no-wait-gate-clock;
+ compatible = gate-clock;
ti,gate-clock? Simple gate-clock is not supported.
clocks = dpll_per_m2_ck;
- ti,bit-shift = 0;
- reg = 0x0664;
+ bit-shift = 0;
Should be ti,bit-shift as above.
+ reg = 0x44e10664 0x4;
You are using an obsolete register format here, the one you removed from
above was correct.
Same comment applies for the rest of this patch.
-Tero
};
- ehrpwm0_tbclk: ehrpwm0_tbclk {
+ ehrpwm1_tbclk: ehrpwm1_tbclk@44e10664 {
#clock-cells = 0;
- compatible = ti,composite-clock;
- clocks = ehrpwm0_gate_tbclk;
- };
-
- ehrpwm1_gate_tbclk: ehrpwm1_gate_tbclk {
- #clock-cells = 0;
- compatible = ti,composite-no-wait-gate-clock;
+ compatible = gate-clock;
clocks = dpll_per_m2_ck;
- ti,bit-shift = 1;
- reg = 0x0664;
- };
-
- ehrpwm1_tbclk: ehrpwm1_tbclk {
- #clock-cells = 0;
- compatible = ti,composite-clock;
- clocks = ehrpwm1_gate_tbclk;
+ bit-shift = 1;
+ reg = 0x44e10664 0x4;
};
- ehrpwm2_gate_tbclk: ehrpwm2_gate_tbclk {
+ ehrpwm2_tbclk: ehrpwm2_tbclk@44e10664 {
#clock-cells = 0;
- compatible = ti,composite-no-wait-gate-clock;
+ compatible = gate-clock;
clocks = dpll_per_m2_ck;
- ti,bit-shift = 2;
- reg = 0x0664;
- };
-
- ehrpwm2_tbclk: ehrpwm2_tbclk {
- #clock-cells = 0;
- compatible = ti,composite-clock;
- clocks = ehrpwm2_gate_tbclk;
+ bit-shift = 2;
+ reg = 0x44e10664 0x4;
};
};
prcm_clocks {
--
To unsubscribe from this list: send the line unsubscribe linux-omap 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: am43x-clock: add tbclk data for ehrpwm.
On 04/25/2014 11:55 AM, Sourav Poddar wrote:
We need tbclk clock data for the functioning of ehrpwm
module. Hence, populating the required clock information
in clock dts file.
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
arch/arm/boot/dts/am43xx-clocks.dtsi | 48 ++
drivers/clk/ti/clk-43xx.c|6 +
2 files changed, 54 insertions(+)
diff --git a/arch/arm/boot/dts/am43xx-clocks.dtsi
b/arch/arm/boot/dts/am43xx-clocks.dtsi
index 142009c..54f68e8 100644
--- a/arch/arm/boot/dts/am43xx-clocks.dtsi
+++ b/arch/arm/boot/dts/am43xx-clocks.dtsi
@@ -87,6 +87,54 @@
clock-mult = 1;
clock-div = 1;
};
+
+ ehrpwm0_tbclk: ehrpwm0_tbclk@44e10664 {
+ #clock-cells = 0;
+ compatible = gate-clock;
Should be ti,gate-clock.
+ clocks = dpll_per_m2_ck;
+ bit-shift = 0;
Should be ti,bit-shift.
+ reg = 0x44e10664 0x4;
Should be reg = 0x664. Mainline kernel uses offsets for clock data,
not absolute register addresses.
Similar comments for the rest of the patch.
-Tero
+ };
+
+ ehrpwm1_tbclk: ehrpwm1_tbclk@44e10664 {
+ #clock-cells = 0;
+ compatible = gate-clock;
+ clocks = dpll_per_m2_ck;
+ bit-shift = 1;
+ reg = 0x44e10664 0x4;
+ };
+
+ ehrpwm2_tbclk: ehrpwm2_tbclk@44e10664 {
+ #clock-cells = 0;
+ compatible = gate-clock;
+ clocks = dpll_per_m2_ck;
+ bit-shift = 2;
+ reg = 0x44e10664 0x4;
+ };
+
+ ehrpwm3_tbclk: ehrpwm3_tbclk@44e10664 {
+ #clock-cells = 0;
+ compatible = gate-clock;
+ clocks = dpll_per_m2_ck;
+ bit-shift = 3;
+ reg = 0x44e10664 0x4;
+ };
+
+ ehrpwm4_tbclk: ehrpwm4_tbclk@44e10664 {
+ #clock-cells = 0;
+ compatible = gate-clock;
+ clocks = dpll_per_m2_ck;
+ bit-shift = 4;
+ reg = 0x44e10664 0x4;
+ };
+
+ ehrpwm5_tbclk: ehrpwm5_tbclk@44e10664 {
+ #clock-cells = 0;
+ compatible = gate-clock;
+ clocks = dpll_per_m2_ck;
+ bit-shift = 5;
+ reg = 0x44e10664 0x4;
+ };
};
prcm_clocks {
clk_32768_ck: clk_32768_ck {
diff --git a/drivers/clk/ti/clk-43xx.c b/drivers/clk/ti/clk-43xx.c
index 67c8de5..527a43d 100644
--- a/drivers/clk/ti/clk-43xx.c
+++ b/drivers/clk/ti/clk-43xx.c
@@ -105,6 +105,12 @@ static struct ti_dt_clk am43xx_clks[] = {
DT_CLK(NULL, func_12m_clk, func_12m_clk),
DT_CLK(NULL, vtp_clk_div, vtp_clk_div),
DT_CLK(NULL, usbphy_32khz_clkmux, usbphy_32khz_clkmux),
+ DT_CLK(48300200.ehrpwm, tbclk, ehrpwm0_tbclk),
+ DT_CLK(48302200.ehrpwm, tbclk, ehrpwm1_tbclk),
+ DT_CLK(48304200.ehrpwm, tbclk, ehrpwm2_tbclk),
+ DT_CLK(48306200.ehrpwm, tbclk, ehrpwm3_tbclk),
+ DT_CLK(48308200.ehrpwm, tbclk, ehrpwm4_tbclk),
+ DT_CLK(4830a200.ehrpwm, tbclk, ehrpwm5_tbclk),
{ .node_name = NULL },
};
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 06/23] ARM: OMAP: add OMAP5 DSI muxing
On Friday 25 April 2014 04:48 PM, Tomi Valkeinen wrote: On 25/04/14 14:11, Archit Taneja wrote: Hi, On Thursday 24 April 2014 03:47 PM, Tomi Valkeinen wrote: Add support to set OMAP5 DSI pin muxing. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com Cc: Tony Lindgren t...@atomide.com --- arch/arm/mach-omap2/display.c | 35 ++- 1 file changed, 34 insertions(+), 1 deletion(-) diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c index 16d33d831287..974461441fc3 100644 --- a/arch/arm/mach-omap2/display.c +++ b/arch/arm/mach-omap2/display.c @@ -137,11 +137,42 @@ static int omap4_dsi_mux_pads(int dsi_id, unsigned lanes) return 0; } +#define CONTROL_PAD_BASE0x4A002800 +#define CONTROL_DSIPHY0x614 + I guess this is something we can move to our driver, and use sysconf to get the register from DT. I just copied the same method as used for OMAP4. I guess sysconf is an option. But I really dislike the idea of moving omap control module code to a display driver... I'm not sure what other options we have, though. Maybe an OMAP DSI specific pinctrl driver? OMAP4 has CONTROL_DSIPHY for configuring both lane enable/disbale, and pull up/down, but OMAP5 has normal PAD_CONF registers for DSI lines(2 pins per register) for configuring pull up/down, and CONTROL_DSIPHY for lane enable/disable. We would have a very messed up pinctrl driver, but it would probably be better than doing all this stuff in the driver. Archit -- To unsubscribe from this list: send the line unsubscribe linux-omap 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 01/13] Documentation: add extcon devicetree bindings
On 04/22/2014 09:51 PM, Mark Brown wrote:
On Mon, Apr 14, 2014 at 01:46:12PM +0200, Robert Baldyga wrote:
That's quite some CC list you've got there, and the mail seems a bit
corrupted too (it confused my MUA).
This patch adds extcon devicetree bindings. Documentation describes in
general
client and provider bindings, and contains detailed desctiprion of bindings
for each extcon provider.
Signed-off-by: Robert Baldyga r.bald...@samsung.com
---
.../devicetree/bindings/extcon/extcon-adc-jack.txt | 60
+++
.../devicetree/bindings/extcon/extcon-arizona.txt | 47 +++
.../devicetree/bindings/extcon/extcon-bindings.txt | 36 +++
.../devicetree/bindings/extcon/extcon-gpio.txt | 63
.../devicetree/bindings/extcon/extcon-max14577.txt | 49 +++
.../devicetree/bindings/extcon/extcon-max77693.txt | 56 +
.../devicetree/bindings/extcon/extcon-max8997.txt | 49 +++
.../devicetree/bindings/extcon/extcon-palmas.txt | 37 ++--
This is creating device tree bindings for MFD components as devices when
those MFD components aren't well isolated from the rest of the device.
If we need to add extcon bindings the device should have the flexibility
to decide where to add the properties, and really things should be set
up so there's less duplication in the documentation.
Those components has their own addresses on i2c bus, so they are,
technically, separate devices, and they can (should?) be described by
separate nodes. And I think it doesn't matter if they are grouped in one
chip.
However, it's easy to change it (give mfd master driver node to extcon),
and we can have extcon device defined without additional node, and then
parent node is an extcon node.
Best regards
Robert Baldyga
Samsung RD Institute Poland
+The following is the list of cables detected by the controller. Each
+cable is assigned an identifier and client nodes use this identifies
+to specify the cable which they are interested in.
+
+ Cable ID
+
+
+ Mechanical0
+ Microphone1
+ Headphone 2
+ Line-out 3
+
+Example 1: An example of a extcon controller node is listed below.
+
+extcon: arizona-extcon {
The above doesn't entirely reflect what the hardware is capable of doing
- it reflects the default software configuration for the device but it's
got a wider feature set.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: dts: am335x-boneblack: remove use of ti,vcc-aux-disable-is-sleep
Remove use of property ti,vcc-aux-disable-is-sleep, which does not
exist.
Signed-off-by: Johan Hovold jhov...@gmail.com
---
arch/arm/boot/dts/am335x-boneblack.dts | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/boot/dts/am335x-boneblack.dts
b/arch/arm/boot/dts/am335x-boneblack.dts
index 6b71ad95a5cf..305975d3f531 100644
--- a/arch/arm/boot/dts/am335x-boneblack.dts
+++ b/arch/arm/boot/dts/am335x-boneblack.dts
@@ -26,7 +26,6 @@
pinctrl-0 = emmc_pins;
bus-width = 8;
status = okay;
- ti,vcc-aux-disable-is-sleep;
};
am33xx_pinmux {
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap 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/19] bus: omap_l3_noc: driver cleanups and support for DRA7/AM4372
On 04/25/2014 01:27 AM, Peter Ujfalusi wrote: On 04/24/2014 05:19 PM, Nishanth Menon wrote: On 04/24/2014 03:55 AM, Peter Ujfalusi wrote: On 04/18/2014 12:00 AM, Nishanth Menon wrote: On 04/17/2014 03:57 PM, Santosh Shilimkar wrote: I looked at the series and its looks pretty good. Thanks for fixups, updates. For whole series, Acked-by: Santosh Shilimkar santosh.shilim...@ti.com Thanks. Patches(including Peter's) is available here: https://github.com/nmenon/linux-2.6-playground/commits/l3noc/driver-fixes-v2 Can Tony pull this branch for 3.16 then which includes Peter's series as well ? there is just an empty commit with information about peter's patches that i lined up to differentiate the series.. I can drop it if Tony would like me to. Looking at the branch I see my patches underneath so they are in the branch. It would be great if Tony pulls this... Will be a great present to my patches (omap_l3 patches in the branch) for their 1 year anniversary of being out on the mailing list ;) Peter, can I take this as an Ack for this series? if yes, I can repost a v3 with all the acks, updates together. Nishanth, sure you can add my Ack or Reviewed-by. Thanks Peter. i will pick up your ack. Seems that I have to respin the series given a few further updates for AM437x - some, ummm... variations in definition that we did not expect but Sekhar found when reviewing internal functional specs :( -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 06/23] ARM: OMAP: add OMAP5 DSI muxing
On 25/04/14 15:58, Archit Taneja wrote:
On Friday 25 April 2014 04:48 PM, Tomi Valkeinen wrote:
On 25/04/14 14:11, Archit Taneja wrote:
Hi,
On Thursday 24 April 2014 03:47 PM, Tomi Valkeinen wrote:
Add support to set OMAP5 DSI pin muxing.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/display.c | 35
++-
1 file changed, 34 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/display.c
b/arch/arm/mach-omap2/display.c
index 16d33d831287..974461441fc3 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -137,11 +137,42 @@ static int omap4_dsi_mux_pads(int dsi_id,
unsigned lanes)
return 0;
}
+#define CONTROL_PAD_BASE0x4A002800
+#define CONTROL_DSIPHY0x614
+
I guess this is something we can move to our driver, and use sysconf to
get the register from DT.
I just copied the same method as used for OMAP4.
I guess sysconf is an option. But I really dislike the idea of moving
omap control module code to a display driver... I'm not sure what other
options we have, though. Maybe an OMAP DSI specific pinctrl driver?
OMAP4 has CONTROL_DSIPHY for configuring both lane enable/disbale, and
pull up/down, but OMAP5 has normal PAD_CONF registers for DSI lines(2
pins per register) for configuring pull up/down, and CONTROL_DSIPHY for
lane enable/disable.
We would have a very messed up pinctrl driver, but it would probably be
better than doing all this stuff in the driver.
Actually, this patch is not good. I should've looked at the code more
carefully =).
This one does ioremap every time the function is called, which could be
done multiple times.
And I think omap4_ctrl_pad_readl() can be used to access the registers.
Like this (not tested):
#define OMAP5_CONTROL_DSIPHY0x614
static int omap5_dsi_mux_pads(int dsi_id, unsigned lanes)
{
u32 enable_mask, enable_shift, reg;
if (dsi_id == 0) {
enable_mask = OMAP4_DSI1_LANEENABLE_MASK;
enable_shift = OMAP4_DSI1_LANEENABLE_SHIFT;
} else if (dsi_id == 1) {
enable_mask = OMAP4_DSI2_LANEENABLE_MASK;
enable_shift = OMAP4_DSI2_LANEENABLE_SHIFT;
} else {
return -ENODEV;
}
reg = omap4_ctrl_pad_readl(OMAP5_CONTROL_DSIPHY);
reg = ~enable_mask;
reg |= (lanes enable_shift) enable_mask;
omap4_ctrl_pad_writel(reg, OMAP5_CONTROL_DSIPHY);
return 0;
}
Tomi
signature.asc
Description: OpenPGP digital signature
Re: [PATCH v2 01/13] Documentation: add extcon devicetree bindings
On Fri, Apr 25, 2014 at 03:19:59PM +0200, Robert Baldyga wrote: On 04/22/2014 09:51 PM, Mark Brown wrote: .../devicetree/bindings/extcon/extcon-adc-jack.txt | 60 +++ .../devicetree/bindings/extcon/extcon-arizona.txt | 47 +++ .../devicetree/bindings/extcon/extcon-bindings.txt | 36 +++ .../devicetree/bindings/extcon/extcon-gpio.txt | 63 .../devicetree/bindings/extcon/extcon-max14577.txt | 49 +++ .../devicetree/bindings/extcon/extcon-max77693.txt | 56 + .../devicetree/bindings/extcon/extcon-max8997.txt | 49 +++ .../devicetree/bindings/extcon/extcon-palmas.txt | 37 ++-- This is creating device tree bindings for MFD components as devices when those MFD components aren't well isolated from the rest of the device. If we need to add extcon bindings the device should have the flexibility to decide where to add the properties, and really things should be set up so there's less duplication in the documentation. Those components has their own addresses on i2c bus, so they are, technically, separate devices, and they can (should?) be described by separate nodes. And I think it doesn't matter if they are grouped in one chip. That's definitely not true for the arizona devices, I haven't specifically checked for any of the others. It's all one device and the isolation isn't particularly solid. signature.asc Description: Digital signature
Re: [PATCH 11/23] ARM: dts: omap5-uevm.dts: add tca6424a
On 24/04/14 19:53, Sergei Shtylyov wrote: Right. I wonder what the name should be... gpio is out, as the name should be more specific. No, it's not out. The name should be gpio@22, I think it would be unique. We already have gpio1-8, which are the gpio banks from the SoC. I don't understand why you are indexing the names while you probably have the address part after @ that makes them unique already. Ah sorry for the confusion, I misunderstood. I was talking about the label, not the name, of the node. So the labels for the gpio banks are 'gpio2' etc. The names are 'gpio@123456' etc. And yes, here the name should be 'gpio@22' as you said. I didn't see any rules about the labels in the ePARP doc, so I guess 'tca6424a' would be a valid one. Maybe not a good one, though, especially if there are multiple tca6424a chips on the board (I need to check). Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH v6 1/3] tty/serial: Add GPIOLIB helpers for controlling modem lines
2014-04-22 15:08 GMT+02:00 Yegor Yefremov yegor_s...@visionsystems.de:
On 10.03.2014 17:45, Richard Genoud wrote:
This patch add some helpers to control modem lines (CTS/RTS/DSR...) via
GPIO.
This will be useful for many boards which have a serial controller that
only handle CTS/RTS pins (or even just RX/TX).
Signed-off-by: Richard Genoud richard.gen...@gmail.com
+
+struct mctrl_gpios {
+ struct gpio_desc *gpio[UART_GPIO_MAX];
+};
+
+static const struct {
+ const char *name;
+ unsigned int mctrl;
+ bool dir_out;
+} mctrl_gpios_desc[UART_GPIO_MAX] = {
+ { cts, TIOCM_CTS, false, },
+ { dsr, TIOCM_DSR, false, },
+ { dcd, TIOCM_CD, false, },
+ { rng, TIOCM_RNG, false, },
+ { rts, TIOCM_RTS, true, },
+ { dtr, TIOCM_DTR, true, },
+ { out1, TIOCM_OUT1, true, },
+ { out2, TIOCM_OUT2, true, },
+};
+
+void mctrl_gpio_set(struct mctrl_gpios *gpios, unsigned int mctrl)
+{
+ enum mctrl_gpio_idx i;
+
+ if (IS_ERR_OR_NULL(gpios))
+ return;
+
+ for (i = 0; i UART_GPIO_MAX; i++)
+ if (!IS_ERR_OR_NULL(gpios-gpio[i])
+ mctrl_gpios_desc[i].dir_out)
+ gpiod_set_value(gpios-gpio[i],
+ !!(mctrl mctrl_gpios_desc[i].mctrl));
+}
+EXPORT_SYMBOL_GPL(mctrl_gpio_set);
+
+struct gpio_desc *mctrl_gpio_to_gpiod(struct mctrl_gpios *gpios,
+ enum mctrl_gpio_idx gidx)
+{
+ if (!IS_ERR_OR_NULL(gpios) !IS_ERR_OR_NULL(gpios-gpio[gidx]))
+ return gpios-gpio[gidx];
+ else
+ return NULL;
+}
+EXPORT_SYMBOL_GPL(mctrl_gpio_to_gpiod);
+
+unsigned int mctrl_gpio_get(struct mctrl_gpios *gpios, unsigned int *mctrl)
+{
+ enum mctrl_gpio_idx i;
+
+ /*
+ * return it unchanged if the structure is not allocated
+ */
+ if (IS_ERR_OR_NULL(gpios))
+ return *mctrl;
+
+ for (i = 0; i UART_GPIO_MAX; i++) {
+ if (!IS_ERR_OR_NULL(gpios-gpio[i])
+ !mctrl_gpios_desc[i].dir_out) {
+ if (gpiod_get_value(gpios-gpio[i]))
+ *mctrl |= mctrl_gpios_desc[i].mctrl;
+ else
+ *mctrl = ~mctrl_gpios_desc[i].mctrl;
+ }
+ }
+
+ return *mctrl;
+}
+EXPORT_SYMBOL_GPL(mctrl_gpio_get);
Should this routine be renamed to msr_gpio_get() or perhaps better to give
all values (inputs and outputs)?
I'm trying to port this approach to omap-serial to implement RS485 switching.
I need to know if RTS is already on or not and set it accordingly.
What would be the best solution for this task using this new API?
Sorry, but I don't really get what you're trying to do.
Could you explain a little bit more ?
Richard.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 06/23] ARM: OMAP: add OMAP5 DSI muxing
* Tomi Valkeinen tomi.valkei...@ti.com [140425 07:08]:
On 25/04/14 15:58, Archit Taneja wrote:
On Friday 25 April 2014 04:48 PM, Tomi Valkeinen wrote:
On 25/04/14 14:11, Archit Taneja wrote:
Hi,
On Thursday 24 April 2014 03:47 PM, Tomi Valkeinen wrote:
Add support to set OMAP5 DSI pin muxing.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/display.c | 35
++-
1 file changed, 34 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/display.c
b/arch/arm/mach-omap2/display.c
index 16d33d831287..974461441fc3 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -137,11 +137,42 @@ static int omap4_dsi_mux_pads(int dsi_id,
unsigned lanes)
return 0;
}
+#define CONTROL_PAD_BASE0x4A002800
+#define CONTROL_DSIPHY0x614
+
I guess this is something we can move to our driver, and use sysconf to
get the register from DT.
I just copied the same method as used for OMAP4.
I guess sysconf is an option. But I really dislike the idea of moving
omap control module code to a display driver... I'm not sure what other
options we have, though. Maybe an OMAP DSI specific pinctrl driver?
OMAP4 has CONTROL_DSIPHY for configuring both lane enable/disbale, and
pull up/down, but OMAP5 has normal PAD_CONF registers for DSI lines(2
pins per register) for configuring pull up/down, and CONTROL_DSIPHY for
lane enable/disable.
We would have a very messed up pinctrl driver, but it would probably be
better than doing all this stuff in the driver.
Actually, this patch is not good. I should've looked at the code more
carefully =).
This one does ioremap every time the function is called, which could be
done multiple times.
And I think omap4_ctrl_pad_readl() can be used to access the registers.
Like this (not tested):
#define OMAP5_CONTROL_DSIPHY 0x614
static int omap5_dsi_mux_pads(int dsi_id, unsigned lanes)
{
u32 enable_mask, enable_shift, reg;
if (dsi_id == 0) {
enable_mask = OMAP4_DSI1_LANEENABLE_MASK;
enable_shift = OMAP4_DSI1_LANEENABLE_SHIFT;
} else if (dsi_id == 1) {
enable_mask = OMAP4_DSI2_LANEENABLE_MASK;
enable_shift = OMAP4_DSI2_LANEENABLE_SHIFT;
} else {
return -ENODEV;
}
reg = omap4_ctrl_pad_readl(OMAP5_CONTROL_DSIPHY);
reg = ~enable_mask;
reg |= (lanes enable_shift) enable_mask;
omap4_ctrl_pad_writel(reg, OMAP5_CONTROL_DSIPHY);
return 0;
}
Chances are any mux register in the syscon area already works with
pinctrl-single,pins or pinctrl-single,bits option. The ones in the
padconf area should be already mapped so the driver just has to
request them.
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 5/5] ARM: dts: am43x-epos-evm: Enable USB
On Wed, Mar 19, 2014 at 03:40:03PM +0530, George Cherian wrote:
Enable
- USB PHY
- USB
for am43x-epos-evm
Signed-off-by: George Cherian george.cher...@ti.com
Acked-by: Roger Quadros rog...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
---
arch/arm/boot/dts/am43x-epos-evm.dts | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/am43x-epos-evm.dts
b/arch/arm/boot/dts/am43x-epos-evm.dts
index 167dbc8..1a4946a 100644
--- a/arch/arm/boot/dts/am43x-epos-evm.dts
+++ b/arch/arm/boot/dts/am43x-epos-evm.dts
@@ -367,3 +367,21 @@
pinctrl-0 = spi1_pins;
status = okay;
};
+
+usb2_phy1 {
+ status = okay;
+};
+
+usb1 {
+ dr_mode = peripheral;
+ status = okay;
+};
+
+usb2_phy2 {
+ status = okay;
+};
+
+usb2 {
+ dr_mode = host;
+ status = okay;
+};
--
1.8.3.1
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v5 0/5] Add USB nodes for am43xx epos and gp evm
On Wed, Mar 19, 2014 at 03:39:58PM +0530, George Cherian wrote: The patch series adds USB dt nodes for am43xx epos and gp evm Boot tested with linux-next + Tony's omap-for-v3.15/dt Changes from v1 - v2 * Reorder doc: Add ti,am437x-dwc3 comaptible for dwc3 glue * Address v1 coments on ARM: dts: AM4372: Add USB nodes Changes from v2 - v3 * Removed unwanted dwc3_1 and dwc3_2 nodes from am437x-gp-evm.dts and am43x-epos-evm.dts Changes from v3 - v4 * Refreshed on top of Tony's omap-for-v3.15/dt tree * Added usb_phy0_always_on_clk32k and usb_phy1_always_on_clk32k Patch 2 * Used the above clocks in Patch 3 * Patch 4 and 5 edited the unwanted portions of commit log Changes from v4 - v5 * Address Roger's comment for the clock data George Cherian (5): doc: Add ti,am437x-dwc3 comaptible for dwc3 glue ARM: dts: am43xx clock data ARM: dts: AM4372: Add USB nodes ARM: dts: am437x-gp-evm: Enable USB ARM: dts: am43x-epos-evm: Enable USB Documentation/devicetree/bindings/usb/omap-usb.txt | 4 +- arch/arm/boot/dts/am4372.dtsi | 94 ++ arch/arm/boot/dts/am437x-gp-evm.dts| 18 + arch/arm/boot/dts/am43x-epos-evm.dts | 18 + arch/arm/boot/dts/am43xx-clocks.dtsi | 32 5 files changed, 165 insertions(+), 1 deletion(-) Is this applied anywhere yet ? Benoit, are you taking this for v3.16 merge window ? -- balbi signature.asc Description: Digital signature
Re: [PATCH v5 4/5] ARM: dts: am437x-gp-evm: Enable USB
On Wed, Mar 19, 2014 at 03:40:02PM +0530, George Cherian wrote:
Enable
- USB PHY
- USB
for am437x-gp-evm
Signed-off-by: George Cherian george.cher...@ti.com
Acked-by: Roger Quadros rog...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
---
arch/arm/boot/dts/am437x-gp-evm.dts | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts
b/arch/arm/boot/dts/am437x-gp-evm.dts
index df8798e..9e57538 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -125,3 +125,21 @@
pinctrl-0 = mmc1_pins;
cd-gpios = gpio0 6 GPIO_ACTIVE_HIGH;
};
+
+usb2_phy1 {
+ status = okay;
+};
+
+usb1 {
+ dr_mode = peripheral;
+ status = okay;
+};
+
+usb2_phy2 {
+ status = okay;
+};
+
+usb2 {
+ dr_mode = host;
+ status = okay;
+};
--
1.8.3.1
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v5 3/5] ARM: dts: AM4372: Add USB nodes
On Wed, Mar 19, 2014 at 03:40:01PM +0530, George Cherian wrote:
Add nodes for 2 instances each of
- ocp2scp
- USB PHY control module
- USB PHY
- dwc3_omap
- USB
for AM43xx.
Signed-off-by: George Cherian george.cher...@ti.com
Acked-by: Roger Quadros rog...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
---
arch/arm/boot/dts/am4372.dtsi | 94
+++
1 file changed, 94 insertions(+)
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index 36d523a..cedb9d4 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -735,6 +735,100 @@
#size-cells = 1;
status = disabled;
};
+
+ am43xx_control_usb2phy1: control-phy@44e10620 {
+ compatible = ti,control-phy-usb2-am437;
+ reg = 0x44e10620 0x4;
+ reg-names = power;
+ };
+
+ am43xx_control_usb2phy2: control-phy@0x44e10628 {
+ compatible = ti,control-phy-usb2-am437;
+ reg = 0x44e10628 0x4;
+ reg-names = power;
+ };
+
+ ocp2scp0: ocp2scp@483a8000 {
+ compatible = ti,omap-ocp2scp;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+ ti,hwmods = ocp2scp0;
+
+ usb2_phy1: phy@483a8000 {
+ compatible = ti,am437x-usb2;
+ reg = 0x483a8000 0x8000;
+ ctrl-module = am43xx_control_usb2phy1;
+ clocks = usb_phy0_always_on_clk32k,
+ usb_otg_ss0_refclk960m;
+ clock-names = wkupclk, refclk;
+ #phy-cells = 0;
+ status = disabled;
+ };
+ };
+
+ ocp2scp1: ocp2scp@483e8000 {
+ compatible = ti,omap-ocp2scp;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+ ti,hwmods = ocp2scp1;
+
+ usb2_phy2: phy@483e8000 {
+ compatible = ti,am437x-usb2;
+ reg = 0x483e8000 0x8000;
+ ctrl-module = am43xx_control_usb2phy2;
+ clocks = usb_phy1_always_on_clk32k,
+ usb_otg_ss1_refclk960m;
+ clock-names = wkupclk, refclk;
+ #phy-cells = 0;
+ status = disabled;
+ };
+ };
+
+ dwc3_1: omap_dwc3@4838 {
+ compatible = ti,am437x-dwc3;
+ ti,hwmods = usb_otg_ss0;
+ reg = 0x4838 0x1;
+ interrupts = GIC_SPI 172 IRQ_TYPE_LEVEL_HIGH;
+ #address-cells = 1;
+ #size-cells = 1;
+ utmi-mode = 1;
+ ranges;
+
+ usb1: usb@4839 {
+ compatible = synopsys,dwc3;
+ reg = 0x4839 0x17000;
+ interrupts = GIC_SPI 168 IRQ_TYPE_LEVEL_HIGH;
+ phys = usb2_phy1;
+ phy-names = usb2-phy;
+ maximum-speed = high-speed;
+ dr_mode = otg;
+ status = disabled;
+ };
+ };
+
+ dwc3_2: omap_dwc3@483c {
+ compatible = ti,am437x-dwc3;
+ ti,hwmods = usb_otg_ss1;
+ reg = 0x483c 0x1;
+ interrupts = GIC_SPI 178 IRQ_TYPE_LEVEL_HIGH;
+ #address-cells = 1;
+ #size-cells = 1;
+ utmi-mode = 1;
+ ranges;
+
+ usb2: usb@483d {
+ compatible = synopsys,dwc3;
+ reg = 0x483d 0x17000;
+ interrupts = GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH;
+ phys = usb2_phy2;
+ phy-names = usb2-phy;
+ maximum-speed = high-speed;
+ dr_mode = otg;
+ status = disabled;
+ };
+ };
};
};
--
1.8.3.1
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v5 2/5] ARM: dts: am43xx clock data
On Wed, Mar 19, 2014 at 03:40:00PM +0530, George Cherian wrote:
Add USB and USB PHY reference clock data
Signed-off-by: George Cherian george.cher...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
---
arch/arm/boot/dts/am43xx-clocks.dtsi | 32
1 file changed, 32 insertions(+)
diff --git a/arch/arm/boot/dts/am43xx-clocks.dtsi
b/arch/arm/boot/dts/am43xx-clocks.dtsi
index 142009c..5171d3e 100644
--- a/arch/arm/boot/dts/am43xx-clocks.dtsi
+++ b/arch/arm/boot/dts/am43xx-clocks.dtsi
@@ -653,4 +653,36 @@
clocks = clk_32768_ck, clk_32k_tpm_ck;
reg = 0x4260;
};
+
+ usb_phy0_always_on_clk32k: usb_phy0_always_on_clk32k {
+ #clock-cells = 0;
+ compatible = ti,gate-clock;
+ clocks = usbphy_32khz_clkmux;
+ ti,bit-shift = 8;
+ reg = 0x2a40;
+ };
+
+ usb_phy1_always_on_clk32k: usb_phy1_always_on_clk32k {
+ #clock-cells = 0;
+ compatible = ti,gate-clock;
+ clocks = usbphy_32khz_clkmux;
+ ti,bit-shift = 8;
+ reg = 0x2a48;
+ };
+
+ usb_otg_ss0_refclk960m: usb_otg_ss0_refclk960m {
+ #clock-cells = 0;
+ compatible = ti,gate-clock;
+ clocks = dpll_per_clkdcoldo;
+ ti,bit-shift = 8;
+ reg = 0x8a60;
+ };
+
+ usb_otg_ss1_refclk960m: usb_otg_ss1_refclk960m {
+ #clock-cells = 0;
+ compatible = ti,gate-clock;
+ clocks = dpll_per_clkdcoldo;
+ ti,bit-shift = 8;
+ reg = 0x8a68;
+ };
};
--
1.8.3.1
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v5 1/5] doc: Add ti,am437x-dwc3 comaptible for dwc3 glue
On Wed, Mar 19, 2014 at 03:39:59PM +0530, George Cherian wrote: Add the compatible ti,am437x-dwc3 for dwc3 glue driver. Signed-off-by: George Cherian george.cher...@ti.com Acked-by: Roger Quadros rog...@ti.com Acked-by: Felipe Balbi ba...@ti.com --- Documentation/devicetree/bindings/usb/omap-usb.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt b/Documentation/devicetree/bindings/usb/omap-usb.txt index 38b2fae..38d9bb8 100644 --- a/Documentation/devicetree/bindings/usb/omap-usb.txt +++ b/Documentation/devicetree/bindings/usb/omap-usb.txt @@ -44,7 +44,9 @@ Board specific device node entry }; OMAP DWC3 GLUE - - compatible : Should be ti,dwc3 + - compatible : Should be + * ti,dwc3 for OMAP5 and DRA7 + * ti,am437x-dwc3 for AM437x - ti,hwmods : Should be usb_otg_ss - reg : Address and length of the register set for the device. - interrupts : The irq number of this device that is used to interrupt the -- 1.8.3.1 -- balbi signature.asc Description: Digital signature
Re: [PATCH 1/1] ARM: dts: omap3-igep0020: use SMSC9221 timings
* Javier Martinez Canillas javier.marti...@collabora.co.uk [140424 09:54]: The IGEPv2 board has a SMSC LAN9221i ethernet chip and not a SMSC LAN911x connected to the GPMC. Each chip needs different timings in order to operate correctly so is wrong to include omap-gpmc-smsc911x.dtsi instead of omap-gpmc-smsc9221.dtsi. Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk --- Hi Tony, I see no performance difference when measuring network throughput using iperf(1) but this change is the correct one nonetheless since if we later better adjust the timings it will already include the right dtsi. Yes, let's fix this as wrong timings can cause memory corruption. Applying into omap-for-v3.15/fixes-v2. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap 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] ARM: OMAP5: Switch to THUMB mode if needed on secondary CPU
* Joel Fernandes jo...@ti.com [140422 12:41]: On my DRA7 system, when the kernel is built in Thumb-2 mode, the secondary CPU (Cortex A15) fails to come up causing SMP boot on second CPU to timeout. This seems to be because the CPU is in ARM mode once the ROM hands over control to the kernel. Switch to Thumb-2 mode if required once the kernel is control of secondary CPU. On OMAP4 on the other hand, it appears to be in Thumb-2 mode on entry so this is not required and SMP boot works as is. Also corrected a spurious '+' and updated copyright information. Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Russell King li...@arm.linux.org.uk Cc: Nishanth Menon n...@ti.com Cc: Tony Lindgren t...@atomide.com Tested-by: Nishanth Menon n...@ti.com Acked-by: Santosh Shilimkar santosh.shilim...@ti.com Signed-off-by: Joel Fernandes jo...@ti.com Thanks applying into omap-for-v3.15/fixes-v2. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap 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: am437x-gp-evm: Boot fixes
* Dave Gerlach d-gerl...@ti.com [140423 10:25]: On 04/23/2014 09:59 AM, Tony Lindgren wrote: * Dave Gerlach d-gerl...@ti.com [140422 12:53]: On 04/22/2014 02:01 PM, Tony Lindgren wrote: * Dave Gerlach d-gerl...@ti.com [140422 11:52]: This patch, along with patch here [1], fixes boot for am437x-gp-evm. The bootloader configures gpio5_7 to control the DDR3 termination regulator, the linked patch prevents that gpio bank from being reset and losing the previously configured state, and this patch binds the gpio to a regulator so the kernel is aware of the state of the gpio. [1] https://www.mail-archive.com/linux-omap@vger.kernel.org/msg102941.html Setting up the GPIO regulator makes sense to me. But the hack in the link above is potentially a nasty time bomb for anybody trying to use GPIO bank 5 on that board. What tests have been done that the GPIO bank behaves properly when it's not reset? We've been using this configuration on this board for a while without any apparent issues. Also, am335x-evmsk already uses the same idea for the VTT regulator on board from commit 6046adb6ad701026c10adeac8d6a4138895f12e5 [ARM: dts: am335x-evmsk: Do not reset gpio0] and I am unaware of any issues with that either. OK. Do you have other GPIOs in use as interrupts for devices in these banks and do they work fine? I dont see any interrupts in use from gpio5 bank but as a quick test if I add ti,no-reset-on-init to gpio3 and gpio4 I see no issue with matrix-keypad operation which uses gpios from each of those banks. OK thanks for testing. I'll apply the ti,no-reset-on-init patch from [1] above into omap-for-v3.15/fixes-v2. The regulator patch can wait for v3.16, and should be also implemented for the am335x-evmsk the same way, so maybe add that too to your patch? Also, can you please test to make sure this works with the most recent Javier's GPIO patches that had the issue of not booting on am335x-evmsk? Yes, when using Javier's patches in addition to this patch [1], which was found to be necessary through this discussion [2], the AM437x GP EVM boots fine with linux-next with my regulator patch and gpio5 no reset patch applied. OK good to hear. Tony [1] https://patchwork.kernel.org/patch/4041881/ [2] http://marc.info/?t=139817273800014r=1w=2 Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap 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: am437x-gp-evm: Do not reset gpio5
* Tony Lindgren t...@atomide.com [140417 09:34]: * Nishanth Menon n...@ti.com [140325 08:05]: On 03/21/2014 12:20 AM, Lokesh Vutla wrote: From: Dave Gerlach d-gerl...@ti.com Do not reset GPIO5 at boot-up because GPIO5_7 is used on AM437x GP-EVM to control VTT regulators on DDR3. Without this some GP-EVM boards will fail to boot because of DDR3 corruption. How funny :) Ideally we would be able to specify which GPIO pins should maintain their state during the boot. AFAIK, this patch currently means that the kernel has no idea what state the whole GPIO bank is in. At minimum we should parse the GPIO bank state so the kernel knows it and then it should be safe to set the no reset flag. So for the workaround, can you guys please try to see test if the old mux trick in the bootloader works to mux the pin into something PIN_INPUT_PULLUP | MUX_MODE7? Or a PULLDOWN depending on the direction naturally. That would allow leaving out the GPIO completely from this. OK so no safe mode as MUX_MODE7 on am335x. So based on the tests done by Dave on various GPIO banks without the reset, this seems OK to do. So applying into omap-for-v3.15/fixes-v2 to get the board booting properly. Naturally this is not a reason to stop further work on making sure the GPIO driver actually knows what state the bank is as suggested by Felipe. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] Minor OMAP DTS fixes
* Suman Anna s-a...@ti.com [140422 15:24]: Hi Tony, Benoit, This series includes couple of minor fixes in the OMAP DTS files. The patches are based on 3.15-rc2. The first patch fixes the only WARN_ON trace present during kernel boot on OMAP5 uEVM, and this has been present since some time now. [0.045578] [ cut here ] [0.045598] WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2538 _init+0x1c0/0x3dc() [0.045605] omap_hwmod: mailbox: doesn't have mpu register target base [0.045611] Modules linked in: [0.045625] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.15.0-rc2-1-gb5e85a0 #45 [0.045653] [c0015724] (unwind_backtrace) from [c00120f4] (show_stack+0x10/0x14) [0.045672] [c00120f4] (show_stack) from [c05a1ccc] (dump_stack+0x78/0x94) [0.045686] [c05a1ccc] (dump_stack) from [c0042a74] (warn_slowpath_common+0x6c/0x8c) [0.045698] [c0042a74] (warn_slowpath_common) from [c0042b28] (warn_slowpath_fmt+0x30/0x40) [0.045710] [c0042b28] (warn_slowpath_fmt) from [c0803b40] (_init+0x1c0/0x3dc) [0.045724] [c0803b40] (_init) from [c0029c8c] (omap_hwmod_for_each+0x34/0x5c) [0.045736] [c0029c8c] (omap_hwmod_for_each) from [c08042b0] (__omap_hwmod_setup_all+0x24/0x40) [0.045748] [c08042b0] (__omap_hwmod_setup_all) from [c00088b8] (do_one_initcall+0x34/0x160) [0.045761] [c00088b8] (do_one_initcall) from [c07f7bf4] (kernel_init_freeable+0xfc/0x1c8) [0.045772] [c07f7bf4] (kernel_init_freeable) from [c059c4f4] (kernel_init+0x8/0xe4) [0.045784] [c059c4f4] (kernel_init) from [c000eaa8] (ret_from_fork+0x14/0x2c) [0.045826] ---[ end trace c25fc521f2569d3c ]--- The last patch eliminates the following traces on AM3517 based boards. [0.418496] platform iva.2: Cannot lookup hwmod 'iva' [0.454352] platform 48094000.mailbox: Cannot lookup hwmod 'mailbox' [0.460610] platform 480bd400.mmu: Cannot lookup hwmod 'mmu_isp' [0.464065] platform 480c9000.smartreflex: Cannot lookup hwmod 'smartreflex_mpu_iva' There are a few other such traces remaining, but these are all on valid nodes. [0.420275] platform 480c5000.aes: Cannot lookup hwmod 'aes' [0.462403] platform 480c3000.sham: Cannot lookup hwmod 'sham' [0.463246] platform 480cb000.smartreflex: Cannot lookup hwmod 'smartreflex_core' [0.477243] platform 480ab000.usb_otg_hs: Cannot lookup hwmod 'usb_otg_hs' Thanks applying all three into omap-for-v3.15/fixes-v2 with patch updated with the above warnings. Next time, please include the warnings into the patch description, just leave out the time stamps. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] Minor OMAP DTS fixes
Tony, On 04/25/2014 11:57 AM, Tony Lindgren wrote: * Suman Anna s-a...@ti.com [140422 15:24]: Hi Tony, Benoit, This series includes couple of minor fixes in the OMAP DTS files. The patches are based on 3.15-rc2. The first patch fixes the only WARN_ON trace present during kernel boot on OMAP5 uEVM, and this has been present since some time now. [0.045578] [ cut here ] [0.045598] WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2538 _init+0x1c0/0x3dc() [0.045605] omap_hwmod: mailbox: doesn't have mpu register target base [0.045611] Modules linked in: [0.045625] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.15.0-rc2-1-gb5e85a0 #45 [0.045653] [c0015724] (unwind_backtrace) from [c00120f4] (show_stack+0x10/0x14) [0.045672] [c00120f4] (show_stack) from [c05a1ccc] (dump_stack+0x78/0x94) [0.045686] [c05a1ccc] (dump_stack) from [c0042a74] (warn_slowpath_common+0x6c/0x8c) [0.045698] [c0042a74] (warn_slowpath_common) from [c0042b28] (warn_slowpath_fmt+0x30/0x40) [0.045710] [c0042b28] (warn_slowpath_fmt) from [c0803b40] (_init+0x1c0/0x3dc) [0.045724] [c0803b40] (_init) from [c0029c8c] (omap_hwmod_for_each+0x34/0x5c) [0.045736] [c0029c8c] (omap_hwmod_for_each) from [c08042b0] (__omap_hwmod_setup_all+0x24/0x40) [0.045748] [c08042b0] (__omap_hwmod_setup_all) from [c00088b8] (do_one_initcall+0x34/0x160) [0.045761] [c00088b8] (do_one_initcall) from [c07f7bf4] (kernel_init_freeable+0xfc/0x1c8) [0.045772] [c07f7bf4] (kernel_init_freeable) from [c059c4f4] (kernel_init+0x8/0xe4) [0.045784] [c059c4f4] (kernel_init) from [c000eaa8] (ret_from_fork+0x14/0x2c) [0.045826] ---[ end trace c25fc521f2569d3c ]--- The last patch eliminates the following traces on AM3517 based boards. [0.418496] platform iva.2: Cannot lookup hwmod 'iva' [0.454352] platform 48094000.mailbox: Cannot lookup hwmod 'mailbox' [0.460610] platform 480bd400.mmu: Cannot lookup hwmod 'mmu_isp' [0.464065] platform 480c9000.smartreflex: Cannot lookup hwmod 'smartreflex_mpu_iva' There are a few other such traces remaining, but these are all on valid nodes. [0.420275] platform 480c5000.aes: Cannot lookup hwmod 'aes' [0.462403] platform 480c3000.sham: Cannot lookup hwmod 'sham' [0.463246] platform 480cb000.smartreflex: Cannot lookup hwmod 'smartreflex_core' [0.477243] platform 480ab000.usb_otg_hs: Cannot lookup hwmod 'usb_otg_hs' Thanks applying all three into omap-for-v3.15/fixes-v2 with patch updated with the above warnings. Next time, please include the warnings into the patch description, just leave out the time stamps. Thanks. I have mentioned the warning for the OMAP5 one very briefly, and wasn't sure if I needed to copy the entire backtrace, but will remember to include them in the future. regards Suman -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 05/14] HSI: Add channel resource support to HSI clients
On Sat, Apr 19, 2014 at 09:11:26PM +0200, Pavel Machek wrote:
Hi!
Make HSI channel ids platform data, which can be provided
by platform data.
static void hsi_client_release(struct device *dev)
{
- kfree(to_hsi_client(dev));
+ struct hsi_client *cl = to_hsi_client(dev);
+
+ if (cl-tx_cfg.channels)
+ kfree(cl-tx_cfg.channels);
+ if (cl-rx_cfg.channels cl-rx_cfg.channels != cl-tx_cfg.channels)
+ kfree(cl-rx_cfg.channels);
+
+ kfree(cl);
Can cl-rx_cfg.channels == cl-tx_cfg.channels happen? That seems
like quite a hack :-(.
Yes it could happen. I have updated this for PATCHv4 (so that it can
no longer happen).
-- Sebastian
signature.asc
Description: Digital signature
Re: [PATCHv3 07/14] HSI: Add common DT binding for HSI client devices
On Sat, Apr 19, 2014 at 09:16:12PM +0200, Pavel Machek wrote:
On Sat 2014-03-29 01:31:43, Sebastian Reichel wrote:
Implement and document generic DT bindings for HSI clients.
Signed-off-by: Sebastian Reichel s...@kernel.org
Reviewed-by: Pavel Machek pa...@ucw.cz
diff --git a/drivers/hsi/hsi.c b/drivers/hsi/hsi.c
index 07e1639..5973906 100644
--- a/drivers/hsi/hsi.c
+++ b/drivers/hsi/hsi.c
@@ -26,8 +26,14 @@
#include linux/slab.h
#include linux/string.h
#include linux/notifier.h
+#include linux/of.h
+#include linux/of_device.h
#include hsi_core.h
+ err = hsi_of_property_parse_mode(client, hsi-mode, mode);
+ if (err) {
+ err = hsi_of_property_parse_mode(client, hsi-rx-mode,
+cl-rx_cfg.mode);
+ if (err)
+ goto err;
+
+ err = hsi_of_property_parse_mode(client, hsi-tx-mode,
+cl-tx_cfg.mode);
+ if (err)
+ goto err;
Will this need some #ifdef CONFIG_OF?
It would only be needed to reduce the amount of kernel code for
disabled Device Tree. I don't think its worth it, since there is no
platform in the mainline kernel, which uses HSI without DT.
-- Sebastian
signature.asc
Description: Digital signature
Re: [PATCHv3 07/14] HSI: Add common DT binding for HSI client devices
On Mon, Apr 21, 2014 at 11:52:11AM -0500, Rob Herring wrote:
On Fri, Mar 28, 2014 at 7:31 PM, Sebastian Reichel s...@kernel.org wrote:
Implement and document generic DT bindings for HSI clients.
Signed-off-by: Sebastian Reichel s...@kernel.org
Seems pretty reasonable although I know little about HSI.
ok.
---
.../devicetree/bindings/hsi/client-devices.txt | 44 +
drivers/hsi/hsi.c | 197
-
include/linux/hsi/hsi.h| 2 +
3 files changed, 241 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/hsi/client-devices.txt
diff --git a/Documentation/devicetree/bindings/hsi/client-devices.txt
b/Documentation/devicetree/bindings/hsi/client-devices.txt
new file mode 100644
index 000..7504cb1
--- /dev/null
+++ b/Documentation/devicetree/bindings/hsi/client-devices.txt
@@ -0,0 +1,44 @@
+Each HSI port is supposed to have one child node, which
+symbols the remote device connected to the HSI port. The
+following properties are standardized for HSI clients:
+
+Required HSI configuration properties:
+
+- reg: A list of channel ids
+
+- hsi-rx-mode: Receiver Bit transmission mode (stream or frame)
+- hsi-tx-mode: Transmitter Bit transmission mode (stream or
frame)
+- hsi-mode:May be used instead hsi-rx-mode and hsi-tx-mode if
+ the transmission mode is the same for receiver and
+ transmitter
+- hsi-speed-kbps: Max bit transmission speed in kbit/s
+- hsi-flow:RX flow type (synchronized or pipeline)
+- hsi-arb-mode:Arbitration mode for TX frame
(round-robin, priority)
+
+Optional HSI configuration properties:
+
+- reg-names: A list with one name per channel specified in the
+ reg property
+
+
+Device Tree node example for an HSI client:
+
+hsi-controller {
+ hsi-port {
+ modem: hsi-client {
+ compatible = nokia,n900-modem;
Is there only 1 version of HSI? If not, then perhaps you need to
know what version a client is.
There is HSI (High-speed Synchronous Serial Interface) and a legacy
variant from Texas Instruments called SSI (Synchronous Serial Interface).
The main difference is the speed and I don't think the difference
must be encoded in the Device Tree.
+ reg = 0, 1, 2, 3;
Where do these numbers get defined?
HSI provides multiple serial connections and this describes which
channels are used for the remote device.
Are they always 0-N?
From what I understand they don't have to.
I don't see much advantage to using reg. Perhaps something like
hsi-channel-ids would be better.
I will change it to hsi-channel-ids for PATCHv4.
-- Sebastian
signature.asc
Description: Digital signature
Re: [PATCHv3 08/14] HSI: Introduce OMAP SSI driver
On Sat, Apr 19, 2014 at 09:30:51PM +0200, Pavel Machek wrote:
Add OMAP SSI driver to the HSI subsystem.
The Synchronous Serial Interface (SSI) is a legacy version
of HSI. As in the case of HSI, it is mainly used to connect
Application engines (APE) with cellular modem engines (CMT)
in cellular handsets.
It provides a multichannel, full-duplex, multi-core communication
with no reference clock. The OMAP SSI block is capable of reaching
speeds of 110 Mbit/s.
Signed-off-by: Carlos Chinea carlos.chi...@nokia.com
Signed-off-by: Sebastian Reichel s...@kernel.org
+ boolwktest:1; /* FIXME: HACK to be removed */
+ boolwkin_cken:1; /* Workaround */
There is more thanone FIXME in the code. It may be better to fix after
merge...
I would prefer to keep them in there and have a look after the
merge. Most FIXMEs in the code are for the wakeline test and some
concern the timings. Since the current code works I would prefer
to add it to the mainline kernel and tackle this afterwards.
+DEFINE_SIMPLE_ATTRIBUTE(ssi_sst_div_fops, ssi_div_get, ssi_div_set,
%llu\n);
+
+static int __init ssi_debug_add_port(struct omap_ssi_port *omap_port,
+ struct dentry *dir)
+{
A little strange indentation. Is it intentional?
[...] (more ugly indentation cases)
Fixed in v4.
-- Sebastian
signature.asc
Description: Digital signature
Re: [PATCH v6 1/3] tty/serial: Add GPIOLIB helpers for controlling modem lines
On Fri, Apr 25, 2014 at 4:56 PM, Richard Genoud
richard.gen...@gmail.com wrote:
2014-04-22 15:08 GMT+02:00 Yegor Yefremov yegor_s...@visionsystems.de:
On 10.03.2014 17:45, Richard Genoud wrote:
This patch add some helpers to control modem lines (CTS/RTS/DSR...) via
GPIO.
This will be useful for many boards which have a serial controller that
only handle CTS/RTS pins (or even just RX/TX).
Signed-off-by: Richard Genoud richard.gen...@gmail.com
+
+struct mctrl_gpios {
+ struct gpio_desc *gpio[UART_GPIO_MAX];
+};
+
+static const struct {
+ const char *name;
+ unsigned int mctrl;
+ bool dir_out;
+} mctrl_gpios_desc[UART_GPIO_MAX] = {
+ { cts, TIOCM_CTS, false, },
+ { dsr, TIOCM_DSR, false, },
+ { dcd, TIOCM_CD, false, },
+ { rng, TIOCM_RNG, false, },
+ { rts, TIOCM_RTS, true, },
+ { dtr, TIOCM_DTR, true, },
+ { out1, TIOCM_OUT1, true, },
+ { out2, TIOCM_OUT2, true, },
+};
+
+void mctrl_gpio_set(struct mctrl_gpios *gpios, unsigned int mctrl)
+{
+ enum mctrl_gpio_idx i;
+
+ if (IS_ERR_OR_NULL(gpios))
+ return;
+
+ for (i = 0; i UART_GPIO_MAX; i++)
+ if (!IS_ERR_OR_NULL(gpios-gpio[i])
+ mctrl_gpios_desc[i].dir_out)
+ gpiod_set_value(gpios-gpio[i],
+ !!(mctrl
mctrl_gpios_desc[i].mctrl));
+}
+EXPORT_SYMBOL_GPL(mctrl_gpio_set);
+
+struct gpio_desc *mctrl_gpio_to_gpiod(struct mctrl_gpios *gpios,
+ enum mctrl_gpio_idx gidx)
+{
+ if (!IS_ERR_OR_NULL(gpios) !IS_ERR_OR_NULL(gpios-gpio[gidx]))
+ return gpios-gpio[gidx];
+ else
+ return NULL;
+}
+EXPORT_SYMBOL_GPL(mctrl_gpio_to_gpiod);
+
+unsigned int mctrl_gpio_get(struct mctrl_gpios *gpios, unsigned int *mctrl)
+{
+ enum mctrl_gpio_idx i;
+
+ /*
+ * return it unchanged if the structure is not allocated
+ */
+ if (IS_ERR_OR_NULL(gpios))
+ return *mctrl;
+
+ for (i = 0; i UART_GPIO_MAX; i++) {
+ if (!IS_ERR_OR_NULL(gpios-gpio[i])
+ !mctrl_gpios_desc[i].dir_out) {
+ if (gpiod_get_value(gpios-gpio[i]))
+ *mctrl |= mctrl_gpios_desc[i].mctrl;
+ else
+ *mctrl = ~mctrl_gpios_desc[i].mctrl;
+ }
+ }
+
+ return *mctrl;
+}
+EXPORT_SYMBOL_GPL(mctrl_gpio_get);
Should this routine be renamed to msr_gpio_get() or perhaps better to give
all values (inputs and outputs)?
I'm trying to port this approach to omap-serial to implement RS485
switching. I need to know if RTS is already on or not and set it accordingly.
What would be the best solution for this task using this new API?
Sorry, but I don't really get what you're trying to do.
Could you explain a little bit more ?
Never mind, I've solved this in this patch:
http://www.spinics.net/lists/arm-kernel/msg325197.html via using
gpiod_set_value() and gpiod_get_value() directly.
Yegor
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 09/14] Documentation: DT: omap-ssi binding documentation
Hi,
On Mon, Apr 21, 2014 at 11:43:47AM -0500, Rob Herring wrote:
On Fri, Mar 28, 2014 at 7:31 PM, Sebastian Reichel s...@kernel.org wrote:
Create device tree binding documentation for
OMAP Synchronous Serial Interface (SSI) device.
Signed-off-by: Sebastian Reichel s...@kernel.org
---
Documentation/devicetree/bindings/hsi/omap-ssi.txt | 85
++
1 file changed, 85 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hsi/omap-ssi.txt
diff --git a/Documentation/devicetree/bindings/hsi/omap-ssi.txt
b/Documentation/devicetree/bindings/hsi/omap-ssi.txt
new file mode 100644
index 000..709419b
--- /dev/null
+++ b/Documentation/devicetree/bindings/hsi/omap-ssi.txt
@@ -0,0 +1,85 @@
+OMAP SSI controller bindings
+
+OMAP Synchronous Serial Interface (SSI) controller implements a legacy
+variant of MIPI's High Speed Synchronous Serial Interface (HSI).
+
+Required properties:
+- compatible: Should include ti,omap3-ssi.
+- reg-names: Contains the values sys and gdd.
+- reg: Contains a register specifier for each entry in
+ reg-names.
You need to define the order here unless you have a strong
argument why you can't.
ok.
+- interrupt-names: Contains the value gdd_mpu.
+- interrupts: Contains interrupt information for each entry in
+ interrupt-names.
+- ranges: Represents the bus address mapping between the main
+ controller node and the child nodes below.
+- clocks: Contains clock specifiers for each entry in
+clock-names.
+- clock-names: Must include the following entries:
+ ssi_ssr_fck: The OMAP clock of that name
+ ssi_sst_fck: The OMAP clock of that name
+ ssi_ick: The OMAP clock of that name
+- #address-cells: Should be set to 1
+- #size-cells: Should be set to 1
+
+Each port is represented as a sub-node of the ti,omap3-ssi device.
+
+Required Port sub-node properties:
+- compatible: Should be set to the following value
+ti,omap3-ssi-port (applicable to OMAP34xx devices)
+- reg-names: Contains the values rx and tx.
+- reg: Contains a register specifier for each entry in
+ reg-names.
You need to define the order here unless you have a strong argument
why you can't.
ok.
+- interrupt-parent Should be a phandle for the interrupt controller
+- interrupt-names: Contains the values mpu_irq0 and mpu_irq1.
Those names aren't exactly useful.
I removed interrupt-names in PATCHv4.
+- interrupts: Contains interrupt information for each entry in
+ interrupt-names.
You need to define the order here unless you have a strong argument
why you can't.
ok.
+- ti,ssi-cawake-gpio: Defines which GPIO pin is used to signify CAWAKE
+ events for the port. This is an optional
board-specific
+ property. If it's missing the port will not be
+ enabled.
+
+Example for Nokia N900:
+
+ssi-controller@48058000 {
+ compatible = ti,omap3-ssi;
+
+ /* needed until hwmod is updated to use the compatible string */
+ ti,hwmods = ssi;
+
+ reg = 0x48058000 0x1000,
+ 0x48059000 0x1000;
+ reg-names = sys,
+ gdd;
+
+ interrupts = 55;
+ interrupt-names = gdd_mpu;
+
+ clocks = ssi_ssr_fck,
+ssi_sst_fck,
+ssi_ick;
+ clock-names = ssi_ssr_fck,
+ ssi_sst_fck,
+ ssi_ick;
+
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+
+ ssi-port@0 {
Does this h/w really have more than 1 port?
Yes. I added this to the example in PATCHv4.
This should really be ssi-port@4805a800 Or you need to fill in
ranges to have a local offset.
ok.
[...]
-- Sebastian
signature.asc
Description: Digital signature
Re: [PATCHv3 10/14] HSI: Introduce driver for SSI Protocol
On Sat, Apr 19, 2014 at 09:49:36PM +0200, Pavel Machek wrote: Hi! This adds a driver for the SSI McSAAB protocol as used in the Nokia N900. Signed-off-by: Carlos Chinea carlos.chi...@nokia.com Signed-off-by: Sebastian Reichel s...@kernel.org +#define SSIP_MIN_PN_HDR6 /* FIXME: Revisit */ +#define SSIP_WDTOUT2000/* FIXME: has to be 500 msecs */ Can they be fixed now, or do they have to wait? I would prefer to wait. The timing above works and having it in the git history doesn't hurt. +#ifdef __LITTLE_ENDIAN + ((u16 *)skb-data)[2] = swab16(((u16 *)skb-data)[2]); + dev_dbg(dev-dev, RX length fixed (%04x - %u)\n, + ((u16 *)skb-data)[2], ntohs(((u16 *)skb-data)[2])); +#endif Uh. Can this be replaced by ((u16 *)skb-data)[2] = htons(((u16 *)skb-data)[2]); (without the ifdef?) Yes. + /* +* Modem sends Phonet messages over SSI with its own endianess... +* Assume that modem has the same endianess as we do. +*/ + if (skb_cow_head(skb, 0)) + goto drop; +#ifdef __LITTLE_ENDIAN + ((u16 *)skb-data)[2] = swab16(((u16 *)skb-data)[2]); +#endif Here, too? Fixed in PATCHv4. But it looks like the comment does not match the code, because we swap. The swap only converts the package length field from/to network byte order. I think the comment still applies for the other actual message. I added a comment for the length field and kept the other comment as is for PATCHv4. -- Sebastian signature.asc Description: Digital signature
[PATCHv4 04/13] HSI: method to unregister clients from an hsi port
This exports a method to unregister all clients from
an hsi port.
Signed-off-by: Sebastian Reichel s...@kernel.org
Reviewed-by: Pavel Machek pa...@ucw.cz
---
drivers/hsi/hsi.c | 10 ++
include/linux/hsi/hsi.h | 1 +
2 files changed, 11 insertions(+)
diff --git a/drivers/hsi/hsi.c b/drivers/hsi/hsi.c
index 749f7b5..e96a987 100644
--- a/drivers/hsi/hsi.c
+++ b/drivers/hsi/hsi.c
@@ -130,6 +130,16 @@ static void hsi_port_release(struct device *dev)
}
/**
+ * hsi_unregister_port - Unregister an HSI port
+ * @port: The HSI port to unregister
+ */
+void hsi_port_unregister_clients(struct hsi_port *port)
+{
+ device_for_each_child(port-device, NULL, hsi_remove_client);
+}
+EXPORT_SYMBOL_GPL(hsi_port_unregister_clients);
+
+/**
* hsi_unregister_controller - Unregister an HSI controller
* @hsi: The HSI controller to register
*/
diff --git a/include/linux/hsi/hsi.h b/include/linux/hsi/hsi.h
index 39bfd5b..5a9f121 100644
--- a/include/linux/hsi/hsi.h
+++ b/include/linux/hsi/hsi.h
@@ -282,6 +282,7 @@ struct hsi_controller *hsi_alloc_controller(unsigned int
n_ports, gfp_t flags);
void hsi_put_controller(struct hsi_controller *hsi);
int hsi_register_controller(struct hsi_controller *hsi);
void hsi_unregister_controller(struct hsi_controller *hsi);
+void hsi_port_unregister_clients(struct hsi_port *port);
static inline void hsi_controller_set_drvdata(struct hsi_controller *hsi,
void *data)
--
1.9.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv4 11/13] HSI: Introduce Nokia N900 modem driver
The Nokia N900's modem is connected via Synchronous Serial Interface (SSI),
which is a legacy version of MIPI's High-speed Synchronous Serial Interface
(HSI).
The handles the GPIOs for enabling and resetting the modem and instanciates
ssi-protocol for data exchange. It does not yet support exchanging voice data
with the modem.
Signed-off-by: Sebastian Reichel s...@kernel.org
Reviewed-by: Pavel Machek pa...@ucw.cz
---
.../devicetree/bindings/hsi/nokia-modem.txt| 57 +
drivers/hsi/clients/Kconfig| 9 +
drivers/hsi/clients/Makefile | 1 +
drivers/hsi/clients/nokia-modem.c | 272 +
4 files changed, 339 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hsi/nokia-modem.txt
create mode 100644 drivers/hsi/clients/nokia-modem.c
diff --git a/Documentation/devicetree/bindings/hsi/nokia-modem.txt
b/Documentation/devicetree/bindings/hsi/nokia-modem.txt
new file mode 100644
index 000..8a97978
--- /dev/null
+++ b/Documentation/devicetree/bindings/hsi/nokia-modem.txt
@@ -0,0 +1,57 @@
+Nokia modem client bindings
+
+The Nokia modem HSI client follows the common HSI client binding
+and inherits all required properties. The following additional
+properties are needed by the Nokia modem HSI client:
+
+Required properties:
+- compatible: Should be one of
+ nokia,n900-modem
+- hsi-channel-names: Should contain the following strings
+ mcsaab-control
+ speech-control
+ speech-data
+ mcsaab-data
+- gpios: Should provide a GPIO handler for each GPIO listed in
+gpio-names
+- gpio-names: Should contain the following strings
+ cmt_apeslpx
+ cmt_rst_rq
+ cmt_en
+ cmt_rst
+ cmt_bsi
+- interrupts: Should be IRQ handle for modem's reset indication
+
+Example:
+
+ssi_port {
+ modem: hsi-client {
+ compatible = nokia,n900-modem;
+
+ pinctrl-names = default;
+ pinctrl-0 = modem_pins;
+
+ hsi-channel-ids = 0, 1, 2, 3;
+ hsi-channel-names = mcsaab-control,
+ speech-control,
+ speech-data,
+ mcsaab-data;
+ hsi-speed-kbps = 55000;
+ hsi-mode = frame;
+ hsi-flow = synchronized;
+ hsi-arb-mode = round-robin;
+
+ interrupts-extended = gpio3 8 IRQ_TYPE_EDGE_FALLING; /* 72 */
+
+ gpios = gpio3 6 GPIO_ACTIVE_HIGH, /* 70 */
+ gpio3 9 GPIO_ACTIVE_HIGH, /* 73 */
+ gpio3 10 GPIO_ACTIVE_HIGH, /* 74 */
+ gpio3 11 GPIO_ACTIVE_HIGH, /* 75 */
+ gpio5 29 GPIO_ACTIVE_HIGH; /* 157 */
+ gpio-names = cmt_apeslpx,
+cmt_rst_rq,
+cmt_en,
+cmt_rst,
+cmt_bsi;
+ };
+};
diff --git a/drivers/hsi/clients/Kconfig b/drivers/hsi/clients/Kconfig
index 0c70861..6ce1ea2 100644
--- a/drivers/hsi/clients/Kconfig
+++ b/drivers/hsi/clients/Kconfig
@@ -4,6 +4,15 @@
comment HSI clients
+config NOKIA_MODEM
+ tristate Nokia Modem
+ depends on SSI_PROTOCOL
+ help
+ Say Y here if you want to add support for the modem on Nokia
+ N900 (Nokia RX-51) hardware.
+
+ If unsure, say N.
+
config SSI_PROTOCOL
tristate SSI protocol
depends on HSI OMAP_SSI PHONET
diff --git a/drivers/hsi/clients/Makefile b/drivers/hsi/clients/Makefile
index ccbf768..4d5bc0e 100644
--- a/drivers/hsi/clients/Makefile
+++ b/drivers/hsi/clients/Makefile
@@ -2,5 +2,6 @@
# Makefile for HSI clients
#
+obj-$(CONFIG_NOKIA_MODEM) += nokia-modem.o
obj-$(CONFIG_SSI_PROTOCOL) += ssi_protocol.o
obj-$(CONFIG_HSI_CHAR) += hsi_char.o
diff --git a/drivers/hsi/clients/nokia-modem.c
b/drivers/hsi/clients/nokia-modem.c
new file mode 100644
index 000..b3af9d3
--- /dev/null
+++ b/drivers/hsi/clients/nokia-modem.c
@@ -0,0 +1,272 @@
+/*
+ * nokia-modem.c
+ *
+ * HSI client driver for Nokia N900 modem.
+ *
+ * Copyright (C) 2014 Sebastian Reichel s...@kernel.org
+ *
+ * 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.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ */
+
+#include
[PATCHv4 13/13] DTS: ARM: OMAP3-N900: Add modem support
Add modem device tree data to Nokia N900's DTS file.
Signed-off-by: Sebastian Reichel s...@kernel.org
Reviewed-by: Pavel Machek pa...@ucw.cz
---
arch/arm/boot/dts/omap3-n900.dts | 43 +++-
1 file changed, 42 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
index ef8b241..3cd899d 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -186,6 +186,17 @@
0x15a (PIN_OUTPUT | MUX_MODE1) /* ssi1_wake */
;
};
+
+ modem_pins: pinmux_modem {
+ pinctrl-single,pins =
+ 0x0ac (PIN_OUTPUT | MUX_MODE4) /* gpio 70 =
cmt_apeslpx */
+ 0x0b0 (PIN_INPUT | WAKEUP_EN | MUX_MODE4) /* gpio 72 =
ape_rst_rq */
+ 0x0b2 (PIN_OUTPUT | MUX_MODE4) /* gpio 73 =
cmt_rst_rq */
+ 0x0b4 (PIN_OUTPUT | MUX_MODE4) /* gpio 74 =
cmt_en */
+ 0x0b6 (PIN_OUTPUT | MUX_MODE4) /* gpio 75 =
cmt_rst */
+ 0x15e (PIN_OUTPUT | MUX_MODE4) /* gpio 157 =
cmt_bsi */
+ ;
+ };
};
i2c1 {
@@ -681,8 +692,38 @@
pinctrl-0 = ssi_pins;
ti,ssi-cawake-gpio = gpio5 23 GPIO_ACTIVE_HIGH; /* 151 */
+
+ modem: hsi-client {
+ compatible = nokia,n900-modem;
+
+ pinctrl-names = default;
+ pinctrl-0 = modem_pins;
+
+ hsi-channel-ids = 0, 1, 2, 3;
+ hsi-channel-names = mcsaab-control,
+ speech-control,
+ speech-data,
+ mcsaab-data;
+ hsi-speed-kbps = 55000;
+ hsi-mode = frame;
+ hsi-flow = synchronized;
+ hsi-arb-mode = round-robin;
+
+ interrupts-extended = gpio3 8 IRQ_TYPE_EDGE_FALLING; /* 72 */
+
+ gpios = gpio3 6 GPIO_ACTIVE_HIGH, /* 70 */
+ gpio3 9 GPIO_ACTIVE_HIGH, /* 73 */
+ gpio3 10 GPIO_ACTIVE_HIGH, /* 74 */
+ gpio3 11 GPIO_ACTIVE_HIGH, /* 75 */
+ gpio5 29 GPIO_ACTIVE_HIGH; /* 157 */
+ gpio-names = cmt_apeslpx,
+cmt_rst_rq,
+cmt_en,
+cmt_rst,
+cmt_bsi;
+ };
};
ssi_port2 {
status = disabled;
-};
\ No newline at end of file
+};
--
1.9.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv4 12/13] DTS: ARM: OMAP3-N900: Add SSI support
Add SSI device tree data for OMAP3 and Nokia N900.
Signed-off-by: Sebastian Reichel s...@kernel.org
Reviewed-by: Pavel Machek pa...@ucw.cz
---
arch/arm/boot/dts/omap3-n900.dts | 24 +
arch/arm/boot/dts/omap3.dtsi | 45
arch/arm/boot/dts/omap34xx.dtsi | 11 ++
arch/arm/boot/dts/omap36xx.dtsi | 11 ++
4 files changed, 91 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
index 1a57b61..ef8b241 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -173,6 +173,19 @@
0x0da (PIN_OUTPUT | MUX_MODE1) /* dss_data23.sdi_clkn
*/
;
};
+
+ ssi_pins: pinmux_ssi {
+ pinctrl-single,pins =
+ 0x150 (PIN_INPUT_PULLUP | MUX_MODE1)/* ssi1_rdy_tx
*/
+ 0x14e (PIN_OUTPUT | MUX_MODE1) /* ssi1_flag_tx
*/
+ 0x152 (PIN_INPUT | WAKEUP_EN | MUX_MODE4) /*
ssi1_wake_tx (cawake) */
+ 0x14c (PIN_OUTPUT | MUX_MODE1) /* ssi1_dat_tx
*/
+ 0x154 (PIN_INPUT | MUX_MODE1) /* ssi1_dat_rx
*/
+ 0x156 (PIN_INPUT | MUX_MODE1) /* ssi1_flag_rx
*/
+ 0x158 (PIN_OUTPUT | MUX_MODE1) /* ssi1_rdy_rx
*/
+ 0x15a (PIN_OUTPUT | MUX_MODE1) /* ssi1_wake */
+ ;
+ };
};
i2c1 {
@@ -662,3 +675,14 @@
};
};
};
+
+ssi_port1 {
+ pinctrl-names = default;
+ pinctrl-0 = ssi_pins;
+
+ ti,ssi-cawake-gpio = gpio5 23 GPIO_ACTIVE_HIGH; /* 151 */
+};
+
+ssi_port2 {
+ status = disabled;
+};
\ No newline at end of file
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 5e5790f..2852b23 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -757,6 +757,51 @@
clock-names = fck;
};
};
+
+ ssi: ssi-controller@48058000 {
+ compatible = ti,omap3-ssi;
+ ti,hwmods = ssi;
+
+ status = disabled;
+
+ reg = 0x48058000 0x1000,
+ 0x48059000 0x1000;
+ reg-names = sys,
+ gdd;
+
+ interrupts = 71;
+ interrupt-names = gdd_mpu;
+
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+
+ ssi_port1: ssi-port@4805a000 {
+ compatible = ti,omap3-ssi-port;
+
+ reg = 0x4805a000 0x800,
+ 0x4805a800 0x800;
+ reg-names = tx,
+ rx;
+
+ interrupt-parent = intc;
+ interrupts = 67,
+68;
+ };
+
+ ssi_port2: ssi-port@4805b000 {
+ compatible = ti,omap3-ssi-port;
+
+ reg = 0x4805b000 0x800,
+ 0x4805b800 0x800;
+ reg-names = tx,
+ rx;
+
+ interrupt-parent = intc;
+ interrupts = 69,
+70;
+ };
+ };
};
};
diff --git a/arch/arm/boot/dts/omap34xx.dtsi b/arch/arm/boot/dts/omap34xx.dtsi
index 2e92360..3819c1e 100644
--- a/arch/arm/boot/dts/omap34xx.dtsi
+++ b/arch/arm/boot/dts/omap34xx.dtsi
@@ -40,6 +40,17 @@
};
};
+ssi {
+ status = ok;
+
+ clocks = ssi_ssr_fck,
+ssi_sst_fck,
+ssi_ick;
+ clock-names = ssi_ssr_fck,
+ ssi_sst_fck,
+ ssi_ick;
+};
+
/include/ omap34xx-omap36xx-clocks.dtsi
/include/ omap36xx-omap3430es2plus-clocks.dtsi
/include/ omap36xx-am35xx-omap3430es2plus-clocks.dtsi
diff --git a/arch/arm/boot/dts/omap36xx.dtsi b/arch/arm/boot/dts/omap36xx.dtsi
index 22cf464..541704a 100644
--- a/arch/arm/boot/dts/omap36xx.dtsi
+++ b/arch/arm/boot/dts/omap36xx.dtsi
@@ -78,6 +78,17 @@
clock-names = fck, tv_dac_clk;
};
+ssi {
+ status = ok;
+
+ clocks = ssi_ssr_fck,
+ssi_sst_fck,
+ssi_ick;
+ clock-names = ssi_ssr_fck,
+ ssi_sst_fck,
+ ssi_ick;
+};
+
/include/ omap34xx-omap36xx-clocks.dtsi
/include/ omap36xx-omap3430es2plus-clocks.dtsi
/include/ omap36xx-am35xx-omap3430es2plus-clocks.dtsi
--
1.9.2
--
To unsubscribe from this
[PATCHv4 09/13] Documentation: DT: omap-ssi binding documentation
Create device tree binding documentation for
OMAP Synchronous Serial Interface (SSI) device.
Signed-off-by: Sebastian Reichel s...@kernel.org
Reviewed-by: Pavel Machek pa...@ucw.cz
---
Documentation/devicetree/bindings/hsi/omap-ssi.txt | 97 ++
1 file changed, 97 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hsi/omap-ssi.txt
diff --git a/Documentation/devicetree/bindings/hsi/omap-ssi.txt
b/Documentation/devicetree/bindings/hsi/omap-ssi.txt
new file mode 100644
index 000..f26625e
--- /dev/null
+++ b/Documentation/devicetree/bindings/hsi/omap-ssi.txt
@@ -0,0 +1,97 @@
+OMAP SSI controller bindings
+
+OMAP Synchronous Serial Interface (SSI) controller implements a legacy
+variant of MIPI's High Speed Synchronous Serial Interface (HSI).
+
+Required properties:
+- compatible: Should include ti,omap3-ssi.
+- reg-names: Contains the values sys and gdd (in this order).
+- reg: Contains a matching register specifier for each entry
+ in reg-names.
+- interrupt-names: Contains the value gdd_mpu.
+- interrupts: Contains matching interrupt information for each entry
+ in interrupt-names.
+- ranges: Represents the bus address mapping between the main
+ controller node and the child nodes below.
+- clock-names: Must include the following entries:
+ ssi_ssr_fck: The OMAP clock of that name
+ ssi_sst_fck: The OMAP clock of that name
+ ssi_ick: The OMAP clock of that name
+- clocks: Contains a matching clock specifier for each entry in
+ clock-names.
+- #address-cells: Should be set to 1
+- #size-cells: Should be set to 1
+
+Each port is represented as a sub-node of the ti,omap3-ssi device.
+
+Required Port sub-node properties:
+- compatible: Should be set to the following value
+ ti,omap3-ssi-port (applicable to OMAP34xx devices)
+- reg-names: Contains the values tx and rx (in this order).
+- reg: Contains a matching register specifier for each entry
+ in reg-names.
+- interrupt-parent Should be a phandle for the interrupt controller
+- interrupts: Should contain interrupt specifiers for mpu interrupts
+ 0 and 1 (in this order).
+- ti,ssi-cawake-gpio: Defines which GPIO pin is used to signify CAWAKE
+ events for the port. This is an optional board-specific
+ property. If it's missing the port will not be
+ enabled.
+
+Example for Nokia N900:
+
+ssi-controller@48058000 {
+ compatible = ti,omap3-ssi;
+
+ /* needed until hwmod is updated to use the compatible string */
+ ti,hwmods = ssi;
+
+ reg = 0x48058000 0x1000,
+ 0x48059000 0x1000;
+ reg-names = sys,
+ gdd;
+
+ interrupts = 55;
+ interrupt-names = gdd_mpu;
+
+ clocks = ssi_ssr_fck,
+ssi_sst_fck,
+ssi_ick;
+ clock-names = ssi_ssr_fck,
+ ssi_sst_fck,
+ ssi_ick;
+
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+
+ ssi-port@4805a000 {
+ compatible = ti,omap3-ssi-port;
+
+ reg = 0x4805a000 0x800,
+ 0x4805a800 0x800;
+ reg-names = tx,
+ rx;
+
+ interrupt-parent = intc;
+ interrupts = 67,
+68;
+
+ ti,ssi-cawake-gpio = gpio5 23 GPIO_ACTIVE_HIGH; /* 151 */
+ }
+
+ ssi-port@4805a000 {
+ compatible = ti,omap3-ssi-port;
+
+ reg = 0x4805b000 0x800,
+ 0x4805b800 0x800;
+ reg-names = tx,
+ rx;
+
+ interrupt-parent = intc;
+ interrupts = 69,
+70;
+
+ status = disabled; /* second port is not used on N900 */
+ }
+}
--
1.9.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv4 10/13] HSI: Introduce driver for SSI Protocol
This adds a driver for the SSI McSAAB protocol as used in
the Nokia N900.
Signed-off-by: Carlos Chinea carlos.chi...@nokia.com
Signed-off-by: Sebastian Reichel s...@kernel.org
---
drivers/hsi/clients/Kconfig|8 +
drivers/hsi/clients/Makefile |3 +-
drivers/hsi/clients/ssi_protocol.c | 1190
include/linux/hsi/ssi_protocol.h | 42 ++
4 files changed, 1242 insertions(+), 1 deletion(-)
create mode 100644 drivers/hsi/clients/ssi_protocol.c
create mode 100644 include/linux/hsi/ssi_protocol.h
diff --git a/drivers/hsi/clients/Kconfig b/drivers/hsi/clients/Kconfig
index 3bacd27..0c70861 100644
--- a/drivers/hsi/clients/Kconfig
+++ b/drivers/hsi/clients/Kconfig
@@ -4,6 +4,14 @@
comment HSI clients
+config SSI_PROTOCOL
+ tristate SSI protocol
+ depends on HSI OMAP_SSI PHONET
+ help
+ If you say Y here, you will enable the SSI protocol aka McSAAB.
+
+ If unsure, say N.
+
config HSI_CHAR
tristate HSI/SSI character driver
depends on HSI
diff --git a/drivers/hsi/clients/Makefile b/drivers/hsi/clients/Makefile
index 327c0e2..ccbf768 100644
--- a/drivers/hsi/clients/Makefile
+++ b/drivers/hsi/clients/Makefile
@@ -2,4 +2,5 @@
# Makefile for HSI clients
#
-obj-$(CONFIG_HSI_CHAR) += hsi_char.o
+obj-$(CONFIG_SSI_PROTOCOL) += ssi_protocol.o
+obj-$(CONFIG_HSI_CHAR) += hsi_char.o
diff --git a/drivers/hsi/clients/ssi_protocol.c
b/drivers/hsi/clients/ssi_protocol.c
new file mode 100644
index 000..cb2f4f1
--- /dev/null
+++ b/drivers/hsi/clients/ssi_protocol.c
@@ -0,0 +1,1190 @@
+/*
+ * ssi_protocol.c
+ *
+ * Implementation of the SSI McSAAB improved protocol.
+ *
+ * Copyright (C) 2010 Nokia Corporation. All rights reserved.
+ * Copyright (C) 2013 Sebastian Reichel s...@kernel.org
+ *
+ * Contact: Carlos Chinea carlos.chi...@nokia.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.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ */
+
+#include linux/atomic.h
+#include linux/clk.h
+#include linux/device.h
+#include linux/err.h
+#include linux/gpio.h
+#include linux/if_ether.h
+#include linux/if_arp.h
+#include linux/if_phonet.h
+#include linux/init.h
+#include linux/irq.h
+#include linux/list.h
+#include linux/module.h
+#include linux/netdevice.h
+#include linux/notifier.h
+#include linux/scatterlist.h
+#include linux/skbuff.h
+#include linux/slab.h
+#include linux/spinlock.h
+#include linux/timer.h
+#include linux/hsi/hsi.h
+#include linux/hsi/ssi_protocol.h
+
+void ssi_waketest(struct hsi_client *cl, unsigned int enable);
+
+#define SSIP_TXQUEUE_LEN 100
+#define SSIP_MAX_MTU 65535
+#define SSIP_DEFAULT_MTU 4000
+#define PN_MEDIA_SOS 21
+#define SSIP_MIN_PN_HDR6 /* FIXME: Revisit */
+#define SSIP_WDTOUT2000/* FIXME: has to be 500 msecs */
+#define SSIP_KATOUT15 /* 15 msecs */
+#define SSIP_MAX_CMDS 5 /* Number of pre-allocated commands buffers */
+#define SSIP_BYTES_TO_FRAMES(x) x) - 1) 2) + 1)
+#define SSIP_CMT_LOADER_SYNC 0x11223344
+/*
+ * SSI protocol command definitions
+ */
+#define SSIP_COMMAND(data) ((data) 28)
+#define SSIP_PAYLOAD(data) ((data) 0xfff)
+/* Commands */
+#define SSIP_SW_BREAK 0
+#define SSIP_BOOTINFO_REQ 1
+#define SSIP_BOOTINFO_RESP 2
+#define SSIP_WAKETEST_RESULT 3
+#define SSIP_START_TRANS 4
+#define SSIP_READY 5
+/* Payloads */
+#define SSIP_DATA_VERSION(data)((data) 0xff)
+#define SSIP_LOCAL_VERID 1
+#define SSIP_WAKETEST_OK 0
+#define SSIP_WAKETEST_FAILED 1
+#define SSIP_PDU_LENGTH(data) (((data) 8) 0x)
+#define SSIP_MSG_ID(data) ((data) 0xff)
+/* Generic Command */
+#define SSIP_CMD(cmd, payload) (((cmd) 28) | ((payload) 0xfff))
+/* Commands for the control channel */
+#define SSIP_BOOTINFO_REQ_CMD(ver) \
+ SSIP_CMD(SSIP_BOOTINFO_REQ, SSIP_DATA_VERSION(ver))
+#define SSIP_BOOTINFO_RESP_CMD(ver) \
+ SSIP_CMD(SSIP_BOOTINFO_RESP, SSIP_DATA_VERSION(ver))
+#define SSIP_START_TRANS_CMD(pdulen, id) \
+ SSIP_CMD(SSIP_START_TRANS, (((pdulen) 8) | SSIP_MSG_ID(id)))
+#define SSIP_READY_CMD SSIP_CMD(SSIP_READY, 0)
+#define SSIP_SWBREAK_CMD SSIP_CMD(SSIP_SW_BREAK, 0)
+
+/* Main state machine states */
+enum {
+ INIT,
+ HANDSHAKE,
+ ACTIVE,
+};
+
[PATCHv4 06/13] HSI: export method to (un)register clients
Expose method for registering and unregistering HSI clients, so that
client drivers can register other client drivers.
This is useful for HSI drivers, which want to use the functionality
of other HSI drivers. For example the N900 modem driver can load HSI
drivers for mcsaab protocol and speech protocol.
Signed-off-by: Sebastian Reichel s...@kernel.org
Reviewed-by: Pavel Machek pa...@ucw.cz
---
drivers/hsi/hsi.c | 11 ---
include/linux/hsi/hsi.h | 3 +++
2 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/hsi/hsi.c b/drivers/hsi/hsi.c
index de2ad8f..834a2d6 100644
--- a/drivers/hsi/hsi.c
+++ b/drivers/hsi/hsi.c
@@ -69,14 +69,15 @@ static void hsi_client_release(struct device *dev)
kfree(cl);
}
-static void hsi_new_client(struct hsi_port *port, struct hsi_board_info *info)
+struct hsi_client *hsi_new_client(struct hsi_port *port,
+ struct hsi_board_info *info)
{
struct hsi_client *cl;
size_t size;
cl = kzalloc(sizeof(*cl), GFP_KERNEL);
if (!cl)
- return;
+ return NULL;
cl-tx_cfg = info-tx_cfg;
if (cl-tx_cfg.channels) {
@@ -103,7 +104,10 @@ static void hsi_new_client(struct hsi_port *port, struct
hsi_board_info *info)
pr_err(hsi: failed to register client: %s\n, info-name);
put_device(cl-device);
}
+
+ return cl;
}
+EXPORT_SYMBOL_GPL(hsi_new_client);
static void hsi_scan_board_info(struct hsi_controller *hsi)
{
@@ -119,12 +123,13 @@ static void hsi_scan_board_info(struct hsi_controller
*hsi)
}
}
-static int hsi_remove_client(struct device *dev, void *data __maybe_unused)
+int hsi_remove_client(struct device *dev, void *data __maybe_unused)
{
device_unregister(dev);
return 0;
}
+EXPORT_SYMBOL_GPL(hsi_remove_client);
static int hsi_remove_port(struct device *dev, void *data __maybe_unused)
{
diff --git a/include/linux/hsi/hsi.h b/include/linux/hsi/hsi.h
index e3cff94..e20a399 100644
--- a/include/linux/hsi/hsi.h
+++ b/include/linux/hsi/hsi.h
@@ -296,6 +296,9 @@ struct hsi_controller *hsi_alloc_controller(unsigned int
n_ports, gfp_t flags);
void hsi_put_controller(struct hsi_controller *hsi);
int hsi_register_controller(struct hsi_controller *hsi);
void hsi_unregister_controller(struct hsi_controller *hsi);
+struct hsi_client *hsi_new_client(struct hsi_port *port,
+ struct hsi_board_info *info);
+int hsi_remove_client(struct device *dev, void *data);
void hsi_port_unregister_clients(struct hsi_port *port);
static inline void hsi_controller_set_drvdata(struct hsi_controller *hsi,
--
1.9.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv4 07/13] HSI: Add common DT binding for HSI client devices
Implement and document generic DT bindings for HSI clients.
Signed-off-by: Sebastian Reichel s...@kernel.org
Reviewed-by: Pavel Machek pa...@ucw.cz
---
.../devicetree/bindings/hsi/client-devices.txt | 44 +
drivers/hsi/hsi.c | 206 -
include/linux/hsi/hsi.h| 2 +
3 files changed, 250 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/hsi/client-devices.txt
diff --git a/Documentation/devicetree/bindings/hsi/client-devices.txt
b/Documentation/devicetree/bindings/hsi/client-devices.txt
new file mode 100644
index 000..104c9a3
--- /dev/null
+++ b/Documentation/devicetree/bindings/hsi/client-devices.txt
@@ -0,0 +1,44 @@
+Each HSI port is supposed to have one child node, which
+symbols the remote device connected to the HSI port. The
+following properties are standardized for HSI clients:
+
+Required HSI configuration properties:
+
+- hsi-channel-ids: A list of channel ids
+
+- hsi-rx-mode: Receiver Bit transmission mode (stream or frame)
+- hsi-tx-mode: Transmitter Bit transmission mode (stream or frame)
+- hsi-mode:May be used instead hsi-rx-mode and hsi-tx-mode if
+ the transmission mode is the same for receiver and
+ transmitter
+- hsi-speed-kbps: Max bit transmission speed in kbit/s
+- hsi-flow:RX flow type (synchronized or pipeline)
+- hsi-arb-mode:Arbitration mode for TX frame (round-robin,
priority)
+
+Optional HSI configuration properties:
+
+- hsi-channel-names: A list with one name per channel specified in the
+ hsi-channel-ids property
+
+
+Device Tree node example for an HSI client:
+
+hsi-controller {
+ hsi-port {
+ modem: hsi-client {
+ compatible = nokia,n900-modem;
+
+ hsi-channel-ids = 0, 1, 2, 3;
+ hsi-channel-names = mcsaab-control,
+ speech-control,
+ speech-data,
+ mcsaab-data;
+ hsi-speed-kbps = 55000;
+ hsi-mode = frame;
+ hsi-flow = synchronized;
+ hsi-arb-mode = round-robin;
+
+ /* more client specific properties */
+ };
+ };
+};
diff --git a/drivers/hsi/hsi.c b/drivers/hsi/hsi.c
index 834a2d6..2b4f9da 100644
--- a/drivers/hsi/hsi.c
+++ b/drivers/hsi/hsi.c
@@ -26,8 +26,14 @@
#include linux/slab.h
#include linux/string.h
#include linux/notifier.h
+#include linux/of.h
+#include linux/of_device.h
#include hsi_core.h
+static struct hsi_board_info hsi_char_dev_info = {
+ .name = hsi_char,
+};
+
static ssize_t modalias_show(struct device *dev,
struct device_attribute *a __maybe_unused, char *buf)
{
@@ -50,7 +56,13 @@ static int hsi_bus_uevent(struct device *dev, struct
kobj_uevent_env *env)
static int hsi_bus_match(struct device *dev, struct device_driver *driver)
{
- return strcmp(dev_name(dev), driver-name) == 0;
+ if (of_driver_match_device(dev, driver))
+ return true;
+
+ if (strcmp(dev_name(dev), driver-name) == 0)
+ return true;
+
+ return false;
}
static struct bus_type hsi_bus_type = {
@@ -123,6 +135,196 @@ static void hsi_scan_board_info(struct hsi_controller
*hsi)
}
}
+static int hsi_of_property_parse_mode(struct device_node *client, char *name,
+ unsigned int *result)
+{
+ const char *mode;
+ int err;
+
+ err = of_property_read_string(client, name, mode);
+ if (err 0)
+ return err;
+
+ if (strcmp(mode, stream) == 0)
+ *result = HSI_MODE_STREAM;
+ else if (strcmp(mode, frame) == 0)
+ *result = HSI_MODE_FRAME;
+ else
+ return -EINVAL;
+
+ return 0;
+}
+
+static int hsi_of_property_parse_flow(struct device_node *client, char *name,
+ unsigned int *result)
+{
+ const char *flow;
+ int err;
+
+ err = of_property_read_string(client, name, flow);
+ if (err 0)
+ return err;
+
+ if (strcmp(flow, synchronized) == 0)
+ *result = HSI_FLOW_SYNC;
+ else if (strcmp(flow, pipeline) == 0)
+ *result = HSI_FLOW_PIPE;
+ else
+ return -EINVAL;
+
+ return 0;
+}
+
+static int hsi_of_property_parse_arb_mode(struct device_node *client,
+ char *name, unsigned int *result)
+{
+ const char *arb_mode;
+ int err;
+
+ err = of_property_read_string(client, name, arb_mode);
+ if (err 0)
+ return err;
+
+ if (strcmp(arb_mode, round-robin) ==
[PATCHv4 05/13] HSI: Add channel resource support to HSI clients
Make HSI channel ids platform data, which can be provided
by platform data.
Signed-off-by: Sebastian Reichel s...@kernel.org
---
drivers/hsi/clients/hsi_char.c | 12 +--
drivers/hsi/hsi.c | 46 +-
include/linux/hsi/hsi.h| 24 ++
3 files changed, 71 insertions(+), 11 deletions(-)
diff --git a/drivers/hsi/clients/hsi_char.c b/drivers/hsi/clients/hsi_char.c
index 3073320..57f70c2 100644
--- a/drivers/hsi/clients/hsi_char.c
+++ b/drivers/hsi/clients/hsi_char.c
@@ -367,7 +367,7 @@ static int hsc_rx_set(struct hsi_client *cl, struct
hsc_rx_config *rxc)
return -EINVAL;
tmp = cl-rx_cfg;
cl-rx_cfg.mode = rxc-mode;
- cl-rx_cfg.channels = rxc-channels;
+ cl-rx_cfg.num_hw_channels = rxc-channels;
cl-rx_cfg.flow = rxc-flow;
ret = hsi_setup(cl);
if (ret 0) {
@@ -383,7 +383,7 @@ static int hsc_rx_set(struct hsi_client *cl, struct
hsc_rx_config *rxc)
static inline void hsc_rx_get(struct hsi_client *cl, struct hsc_rx_config *rxc)
{
rxc-mode = cl-rx_cfg.mode;
- rxc-channels = cl-rx_cfg.channels;
+ rxc-channels = cl-rx_cfg.num_hw_channels;
rxc-flow = cl-rx_cfg.flow;
}
@@ -402,7 +402,7 @@ static int hsc_tx_set(struct hsi_client *cl, struct
hsc_tx_config *txc)
return -EINVAL;
tmp = cl-tx_cfg;
cl-tx_cfg.mode = txc-mode;
- cl-tx_cfg.channels = txc-channels;
+ cl-tx_cfg.num_hw_channels = txc-channels;
cl-tx_cfg.speed = txc-speed;
cl-tx_cfg.arb_mode = txc-arb_mode;
ret = hsi_setup(cl);
@@ -417,7 +417,7 @@ static int hsc_tx_set(struct hsi_client *cl, struct
hsc_tx_config *txc)
static inline void hsc_tx_get(struct hsi_client *cl, struct hsc_tx_config *txc)
{
txc-mode = cl-tx_cfg.mode;
- txc-channels = cl-tx_cfg.channels;
+ txc-channels = cl-tx_cfg.num_hw_channels;
txc-speed = cl-tx_cfg.speed;
txc-arb_mode = cl-tx_cfg.arb_mode;
}
@@ -435,7 +435,7 @@ static ssize_t hsc_read(struct file *file, char __user
*buf, size_t len,
return -EINVAL;
if (len max_data_size)
len = max_data_size;
- if (channel-ch = channel-cl-rx_cfg.channels)
+ if (channel-ch = channel-cl-rx_cfg.num_hw_channels)
return -ECHRNG;
if (test_and_set_bit(HSC_CH_READ, channel-flags))
return -EBUSY;
@@ -492,7 +492,7 @@ static ssize_t hsc_write(struct file *file, const char
__user *buf, size_t len,
return -EINVAL;
if (len max_data_size)
len = max_data_size;
- if (channel-ch = channel-cl-tx_cfg.channels)
+ if (channel-ch = channel-cl-tx_cfg.num_hw_channels)
return -ECHRNG;
if (test_and_set_bit(HSC_CH_WRITE, channel-flags))
return -EBUSY;
diff --git a/drivers/hsi/hsi.c b/drivers/hsi/hsi.c
index e96a987..de2ad8f 100644
--- a/drivers/hsi/hsi.c
+++ b/drivers/hsi/hsi.c
@@ -62,18 +62,36 @@ static struct bus_type hsi_bus_type = {
static void hsi_client_release(struct device *dev)
{
- kfree(to_hsi_client(dev));
+ struct hsi_client *cl = to_hsi_client(dev);
+
+ kfree(cl-tx_cfg.channels);
+ kfree(cl-rx_cfg.channels);
+ kfree(cl);
}
static void hsi_new_client(struct hsi_port *port, struct hsi_board_info *info)
{
struct hsi_client *cl;
+ size_t size;
cl = kzalloc(sizeof(*cl), GFP_KERNEL);
if (!cl)
return;
+
cl-tx_cfg = info-tx_cfg;
+ if (cl-tx_cfg.channels) {
+ size = cl-tx_cfg.num_channels * sizeof(*cl-tx_cfg.channels);
+ cl-tx_cfg.channels = kzalloc(size , GFP_KERNEL);
+ memcpy(cl-tx_cfg.channels, info-tx_cfg.channels, size);
+ }
+
cl-rx_cfg = info-rx_cfg;
+ if (cl-rx_cfg.channels) {
+ size = cl-rx_cfg.num_channels * sizeof(*cl-rx_cfg.channels);
+ cl-rx_cfg.channels = kzalloc(size , GFP_KERNEL);
+ memcpy(cl-rx_cfg.channels, info-rx_cfg.channels, size);
+ }
+
cl-device.bus = hsi_bus_type;
cl-device.parent = port-device;
cl-device.release = hsi_client_release;
@@ -502,6 +520,32 @@ int hsi_event(struct hsi_port *port, unsigned long event)
}
EXPORT_SYMBOL_GPL(hsi_event);
+/**
+ * hsi_get_channel_id_by_name - acquire channel id by channel name
+ * @cl: HSI client, which uses the channel
+ * @name: name the channel is known under
+ *
+ * Clients can call this function to get the hsi channel ids similar to
+ * requesting IRQs or GPIOs by name. This function assumes the same
+ * channel configuration is used for RX and TX.
+ *
+ * Returns -errno on error or channel id on success.
+ */
+int hsi_get_channel_id_by_name(struct hsi_client *cl, char *name)
+{
+ int i;
+
+ if (!cl-rx_cfg.channels)
+ return -ENOENT;
+
+ for (i = 0; i
[PATCHv4 03/13] HSI: hsi-char: fix driver for multiport scenarios
Fix return code check of alloc_chrdev_region, which
returns 0 on success.
Signed-off-by: Sebastian Reichel s...@kernel.org
Reviewed-by: Pavel Machek pa...@ucw.cz
---
drivers/hsi/clients/hsi_char.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hsi/clients/hsi_char.c b/drivers/hsi/clients/hsi_char.c
index e61e5f9..3073320 100644
--- a/drivers/hsi/clients/hsi_char.c
+++ b/drivers/hsi/clients/hsi_char.c
@@ -705,7 +705,7 @@ static int hsc_probe(struct device *dev)
if (!hsc_major) {
ret = alloc_chrdev_region(hsc_dev, hsc_baseminor,
HSC_DEVS, devname);
- if (ret 0)
+ if (ret == 0)
hsc_major = MAJOR(hsc_dev);
} else {
hsc_dev = MKDEV(hsc_major, hsc_baseminor);
--
1.9.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv4 02/13] MAINTAINERS: update HSI entry
Add git tree for hsi subsystem, update Sebastian Reichel's e-mail address and add Documentation/hsi.txt as maintained file. Signed-off-by: Sebastian Reichel s...@kernel.org Reviewed-by: Pavel Machek pa...@ucw.cz --- MAINTAINERS | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index e67ea24..08d2233 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4203,9 +4203,11 @@ S: Maintained F: fs/hpfs/ HSI SUBSYSTEM -M: Sebastian Reichel s...@debian.org +M: Sebastian Reichel s...@kernel.org +T: git git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-hsi.git S: Maintained F: Documentation/ABI/testing/sysfs-bus-hsi +F: Documentation/hsi.txt F: drivers/hsi/ F: include/linux/hsi/ F: include/uapi/linux/hsi/ -- 1.9.2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv4 01/13] Documentation: HSI: Add some general description for the HSI subsystem
Add a document, which gives a rough introduction about what HSI is and how its handled by the Linux kernel. Signed-off-by: Sebastian Reichel s...@kernel.org Reviewed-by: Pavel Machek pa...@ucw.cz --- Documentation/hsi.txt | 75 +++ 1 file changed, 75 insertions(+) create mode 100644 Documentation/hsi.txt diff --git a/Documentation/hsi.txt b/Documentation/hsi.txt new file mode 100644 index 000..6ac6cd5 --- /dev/null +++ b/Documentation/hsi.txt @@ -0,0 +1,75 @@ +HSI - High-speed Synchronous Serial Interface + +1. Introduction +~~~ + +High Speed Syncronous Interface (HSI) is a fullduplex, low latency protocol, +that is optimized for die-level interconnect between an Application Processor +and a Baseband chipset. It has been specified by the MIPI alliance in 2003 and +implemented by multiple vendors since then. + +The HSI interface supports full duplex communication over multiple channels +(typically 8) and is capable of reaching speeds up to 200 Mbit/s. + +The serial protocol uses two signals, DATA and FLAG as combined data and clock +signals and an additional READY signal for flow control. An additional WAKE +signal can be used to wakeup the chips from standby modes. The signals are +commonly prefixed by AC for signals going from the application die to the +cellular die and CA for signals going the other way around. + +++ +---+ +| Cellular | | Application | +|Die | | Die | +|| - - - - - - CAWAKE - - - - - - | | +| T| CADATA |R | +| X| CAFLAG |X | +||--- ACREADY | | +|| | | +|| | | +|| - - - - - ACWAKE - - - - - - -| | +| R|--- ACDATA -|T | +| X|--- ACFLAG -|X | +|| CAREADY ---| | +|| | | +|| | | +++ +---+ + +2. HSI Subsystem in Linux +~ + +In the Linux kernel the hsi subsystem is supposed to be used for HSI devices. +The hsi subsystem contains drivers for hsi controllers including support for +multi-port controllers and provides a generic API for using the HSI ports. + +It also contains HSI client drivers, which make use of the generic API to +implement a protocol used on the HSI interface. These client drivers can +use an arbitrary number of channels. + +3. hsi-char Device +~~ + +Each port automatically registers a generic client driver called hsi_char, +which provides a charecter device for userspace representing the HSI port. +It can be used to communicate via HSI from userspace. Userspace may +configure the hsi_char device using the following ioctl commands: + +* HSC_RESET: + - flush the HSI port + +* HSC_SET_PM + - enable or disable the client. + +* HSC_SEND_BREAK + - send break + +* HSC_SET_RX + - set RX configuration + +* HSC_GET_RX + - get RX configuration + +* HSC_SET_TX + - set TX configuration + +* HSC_GET_TX + - get TX configuration -- 1.9.2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv4 00/13] OMAP SSI driver / N900 modem support
Hi, This is the eigth round of the OMAP SSI driver patches. The plan is to get it merged into 3.16. Changes since PATCHv3 [0]: * Rebased devel branch to current master * Dropped ARM: dts: omap3 clocks: simplify ssi aliases (included in 3.15-rc) * Added Reviewed-by tag from Pavel Machek to some of the patches * Changed some style issues in nokia-modem driver found by Pavel (and some more found by checkpatch) * Fixed indention issues in omap_ssi_port.c found by Pavel * Use hsi-channel-ids instead of reg as property name for channels IDs as suggested by Rob Herring * Use hsi-channel-names instead of reg-names (which is the logical consequence of the previous change) * Use port addresses instead of port ids in the port node names * Add second port to the example dts to make it more clear, that the controller has two ports * Define order for memory and interrupt DT properties * Drop interrupt names for ssi ports * Remove ugly endianess #ifdef from ssi protocol driver by properly using ntohs() and htons() macros * Use for_each_available_child_of_node with of_platform_device_create instead of of_platform_bus_create to make sure *only* omap3-ssi-port subdevices are probed * Removed hack, that the same resource is used for rx and tx channel for clients initialized from DT * Update my mail address in MODULE_AUTHOR to s...@kernel.org Please send feedback (e.g. Tested-By or Reviewed-By :)), so that I can send a pull request for 3.16. You can either apply this patchset or use the n900-modem-support-2 branch available on [1]. For testing the patchset you should build the kernel with all config entries in the HSI subsystem activated and boot using the updated device tree information, since platform data based booting is not supported. Testing the patchset with ofono works like this: # provide cmt device for ofono ln -sf /sys/bus/hsi/n900-modem /dev/cmt # start ofono ofono --nodetach --debug # enable the modem mdbus2 -s org.ofono /n900_0 org.ofono.Modem.SetProperty Powered true # enable modem's RF parts mdbus2 -s org.ofono /n900_0 org.ofono.Modem.SetProperty Online true # scan for available networks (takes some time) mdbus2 -s org.ofono /n900_0 org.ofono.NetworkRegistration.Scan TODO (post-merge): * Central Message Queue in HSI framework * Remove the hwmod DT hack * Implement proper context loss detection * Implement N900 modem PM * Remove wakeline checks (- FIXMEs) [0] https://lkml.org/lkml/2014/3/28/492 [1] git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-hsi.git -- Sebastian Sebastian Reichel (13): Documentation: HSI: Add some general description for the HSI subsystem MAINTAINERS: update HSI entry HSI: hsi-char: fix driver for multiport scenarios HSI: method to unregister clients from an hsi port HSI: Add channel resource support to HSI clients HSI: export method to (un)register clients HSI: Add common DT binding for HSI client devices HSI: Introduce OMAP SSI driver Documentation: DT: omap-ssi binding documentation HSI: Introduce driver for SSI Protocol HSI: Introduce Nokia N900 modem driver DTS: ARM: OMAP3-N900: Add SSI support DTS: ARM: OMAP3-N900: Add modem support .../devicetree/bindings/hsi/client-devices.txt | 44 + .../devicetree/bindings/hsi/nokia-modem.txt| 57 + Documentation/devicetree/bindings/hsi/omap-ssi.txt | 97 ++ Documentation/hsi.txt | 75 ++ MAINTAINERS|4 +- arch/arm/boot/dts/omap3-n900.dts | 65 + arch/arm/boot/dts/omap3.dtsi | 45 + arch/arm/boot/dts/omap34xx.dtsi| 11 + arch/arm/boot/dts/omap36xx.dtsi| 11 + drivers/hsi/Kconfig|1 + drivers/hsi/Makefile |1 + drivers/hsi/clients/Kconfig| 17 + drivers/hsi/clients/Makefile |4 +- drivers/hsi/clients/hsi_char.c | 14 +- drivers/hsi/clients/nokia-modem.c | 272 drivers/hsi/clients/ssi_protocol.c | 1190 + drivers/hsi/controllers/Kconfig| 19 + drivers/hsi/controllers/Makefile |6 + drivers/hsi/controllers/omap_ssi.c | 625 + drivers/hsi/controllers/omap_ssi.h | 166 +++ drivers/hsi/controllers/omap_ssi_port.c| 1399 drivers/hsi/controllers/omap_ssi_regs.h| 171 +++ drivers/hsi/hsi.c | 273 +++- include/linux/hsi/hsi.h| 30 +- include/linux/hsi/ssi_protocol.h | 42 + 25 files changed, 4620 insertions(+), 19 deletions(-) create mode 100644 Documentation/devicetree/bindings/hsi/client-devices.txt create mode 100644 Documentation/devicetree/bindings/hsi/nokia-modem.txt
[GIT PULL] somewhat urgent omap fixes against v3.15-rc1, fixes gpmc
The following changes since commit fb677ef70b65e22cd4401d31b700a8b4041efae1: ARM: OMAP2+: Fix GPMC remap for devices using an offset (2014-04-23 11:09:22 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.15/fixes-gpmc for you to fetch changes up to 4c05160342f16361fc37ae34dcae9210306a83e9: ARM: dts: AM3517: Disable absent IPs inherited from OMAP3 (2014-04-25 09:55:00 -0700) Mostly fixes for occasional memory corruption caused by bad timings for smc911x LAN9220 (and potentially LAN9221) devices that were noted on a cm-t3730 system. Also fix THUMB mode for SMP, and mailbox related warnings when booted with device tree. Dave Gerlach (1): ARM: dts: am437x-gp-evm: Do not reset gpio5 Javier Martinez Canillas (1): ARM: dts: omap3-igep0020: use SMSC9221 timings Joel Fernandes (1): ARM: OMAP5: Switch to THUMB mode if needed on secondary CPU Suman Anna (3): ARM: dts: OMAP5: Add mailbox dt node to fix boot warning ARM: dts: OMAP2: Fix interrupts for OMAP2420 mailbox ARM: dts: AM3517: Disable absent IPs inherited from OMAP3 Tony Lindgren (3): ARM: dts: Fix bad OTG muxing for cm-t boards ARM: dts: Fix GPMC Ethernet timings for omap cm-t sbc-t boards for device tree ARM: dts: Fix GPMC timings for LAN9220 arch/arm/boot/dts/am3517.dtsi | 16 arch/arm/boot/dts/am437x-gp-evm.dts | 5 +++ arch/arm/boot/dts/omap-gpmc-smsc911x.dtsi | 19 - arch/arm/boot/dts/omap2.dtsi | 7 arch/arm/boot/dts/omap2420.dtsi | 8 arch/arm/boot/dts/omap2430.dtsi | 7 arch/arm/boot/dts/omap3-cm-t3x30.dtsi | 66 +++ arch/arm/boot/dts/omap3-igep.dtsi | 2 +- arch/arm/boot/dts/omap3-igep0020.dts | 4 +- arch/arm/boot/dts/omap3-sb-t35.dtsi | 37 + arch/arm/boot/dts/omap3-sbc-t3517.dts | 13 ++ arch/arm/boot/dts/omap3.dtsi | 2 +- arch/arm/boot/dts/omap5.dtsi | 7 arch/arm/mach-omap2/omap-headsmp.S| 8 +++- 14 files changed, 99 insertions(+), 102 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] power: twl4030_charger: clear IRQs after handling them
On 04/16/2014 11:35 AM, Tony Lindgren wrote: * Felipe Balbi ba...@ti.com [140416 08:18]: TRM says we *must* write 1 to each bit we're handling in order to clear the IRQ status and bring IRQ line low. This patch implements that. Signed-off-by: Felipe Balbi ba...@ti.com --- Russell, I don't have HW to test, but this should solve the problem you saw when not using battery with Zoom board. Let me know if it doesn't. BTW, looks like we're enabling BCI automatically in twl4030.dtsi while the legacy booting does not have TWL_COMMON_PDATA_BCI enabled for LDP. Anyways, for LDP BCI should be enabled for sure, that's the only way to power at least the earlier LDP revisions. I picked up https://patchwork.kernel.org/patch/4002371/ for testing. Unfortunately, it does not seem to work in my tests: ldp-board-no-battery uses upstream u-boot in a chainloaded configuration + does not have battery plugged in, instead, just J58 (charger) is connected - this is plugged on a remote farm setup for developers to work with. ldp-board-with-battery uses legacy bootloader with a battery simulator. omap2plus_defconfig + CONFIG_CHARGER_TWL4030 enabled. Result: v3-15-rc2-ldp-board-no-battery: Boot FAIL: http://slexy.org/raw/s20riTwu04 v3-15-rc2-ldp-board-with-battery: Boot PASS: http://slexy.org/raw/s2elKdJpI7 v3-15-rc2-with-felipe-fix-ldp-board-no-battery: Boot FAIL: http://slexy.org/raw/s20lKp2o0s This patch should probably also acknowledge that Russell reported this issue. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 07/14] HSI: Add common DT binding for HSI client devices
On Fri, Apr 25, 2014 at 08:25:36PM +0200, Sebastian Reichel wrote:
On Sat, Apr 19, 2014 at 09:16:12PM +0200, Pavel Machek wrote:
On Sat 2014-03-29 01:31:43, Sebastian Reichel wrote:
Implement and document generic DT bindings for HSI clients.
Signed-off-by: Sebastian Reichel s...@kernel.org
Reviewed-by: Pavel Machek pa...@ucw.cz
diff --git a/drivers/hsi/hsi.c b/drivers/hsi/hsi.c
index 07e1639..5973906 100644
--- a/drivers/hsi/hsi.c
+++ b/drivers/hsi/hsi.c
@@ -26,8 +26,14 @@
#include linux/slab.h
#include linux/string.h
#include linux/notifier.h
+#include linux/of.h
+#include linux/of_device.h
#include hsi_core.h
+ err = hsi_of_property_parse_mode(client, hsi-mode, mode);
+ if (err) {
+ err = hsi_of_property_parse_mode(client, hsi-rx-mode,
+ cl-rx_cfg.mode);
+ if (err)
+ goto err;
+
+ err = hsi_of_property_parse_mode(client, hsi-tx-mode,
+ cl-tx_cfg.mode);
+ if (err)
+ goto err;
Will this need some #ifdef CONFIG_OF?
It would only be needed to reduce the amount of kernel code for
disabled Device Tree. I don't think its worth it, since there is no
platform in the mainline kernel, which uses HSI without DT.
mh actually it is needed, since there is no stub provided for
of_modalias_node in non DT mode (there are stubs for all other
of_* methods used). I will include the ifdef in PATCHv5.
-- Sebastian
signature.asc
Description: Digital signature
Re: [PATCH] power: twl4030_charger: clear IRQs after handling them
On Fri, Apr 25, 2014 at 03:58:10PM -0500, Nishanth Menon wrote: On 04/16/2014 11:35 AM, Tony Lindgren wrote: * Felipe Balbi ba...@ti.com [140416 08:18]: TRM says we *must* write 1 to each bit we're handling in order to clear the IRQ status and bring IRQ line low. This patch implements that. Signed-off-by: Felipe Balbi ba...@ti.com --- Russell, I don't have HW to test, but this should solve the problem you saw when not using battery with Zoom board. Let me know if it doesn't. BTW, looks like we're enabling BCI automatically in twl4030.dtsi while the legacy booting does not have TWL_COMMON_PDATA_BCI enabled for LDP. Anyways, for LDP BCI should be enabled for sure, that's the only way to power at least the earlier LDP revisions. I picked up https://patchwork.kernel.org/patch/4002371/ for testing. Unfortunately, it does not seem to work in my tests: alright, I'll have a look after I get this other issue out of the way. Probably not until next week. This patch should probably also acknowledge that Russell reported this issue. sure I can add that, although it doesn't solve anything as it is ... -- balbi signature.asc Description: Digital signature
[PATCH 00/10] ARM: OMAP: dts and HWMOD entries for crypto modules
Hi Tony, Benoit, Here are some dts/hwmod patches for crypto on OMAP4 and DRA7, couple of them are resends and some are sent for first time now that clock nodes are available in dts. If there's no other feedback, I would like these queued for v3.16. Thanks. Patches 1,2 and 3 are dts, the rest are hwmod entries. The patches are rebased on v3.15-rc2. and can pulled from the Git repo below: https://github.com/joelagnel/linux-kernel.git (branch v3.16/prep-dts) Joel Fernandes (9): ARM: OMAP: hwmod: Add SYSC offsets for AES IP ARM: DRA7xx: hwmod: Add hwmod data for DES IP ARM: DRA7xx: hwmod: Add hwmod data for AES IP ARM: DRA7xx: Add hwmod entries for RNG module ARM: OMAP4: hwmod: Add hwmod data for AES IP ARM: OMAP4: hwmod: add hwmod data for DES IP ARM: dts: DRA7: Add DT node for DES IP ARM: dts: DRA7: Add DT node for AES IP ARM: dts: OMAP4: Add clock nodes for AES/DES nodes Lokesh Vutla (1): ARM: dts: OMAP4: clk: Add clk node for DES IP arch/arm/boot/dts/dra7.dtsi | 22 + arch/arm/boot/dts/omap4.dtsi |4 + arch/arm/boot/dts/omap44xx-clocks.dtsi |8 ++ arch/arm/mach-omap2/omap_hwmod.h | 11 +++ arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 78 ++ arch/arm/mach-omap2/omap_hwmod_7xx_data.c| 113 ++ arch/arm/mach-omap2/omap_hwmod_common_data.c | 10 +++ drivers/clk/ti/clk-44xx.c|1 + 8 files changed, 247 insertions(+) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 07/10] ARM: dts: DRA7: Add DT node for DES IP
DRA7xx SoCs have a DES3DES IP. Add DT data for the same.
Signed-off-by: Joel Fernandes jo...@ti.com
---
arch/arm/boot/dts/dra7.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 1c0f8e1..0533b89 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -789,6 +789,17 @@
dma-names = tx0, rx0;
status = disabled;
};
+
+ des: des@480a5000 {
+ compatible = ti,omap4-des;
+ ti,hwmods = des;
+ reg = 0x480a5000 0xa0;
+ interrupts = GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH;
+ dmas = sdma 117, sdma 116;
+ dma-names = tx, rx;
+ clocks = l3_iclk_div;
+ clock-names = fck;
+ };
};
};
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 04/10] ARM: DRA7xx: Add hwmod entries for RNG module
Add the CLKCTRL offsets, SYSC offsets to the RNG module.
Signed-off-by: Joel Fernandes jo...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 35 +
1 file changed, 35 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index e76e712..7c75e5f 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -583,6 +583,15 @@ static struct omap_hwmod_class_sysconfig dra7xx_des_sysc =
{
.sysc_fields= omap_hwmod_sysc_type4,
};
+/* rng */
+static struct omap_hwmod_class_sysconfig dra7xx_rng_sysc = {
+.rev_offs = 0x1fe0,
+.sysc_offs = 0x1fe4,
+.sysc_flags = SYSC_HAS_AUTOIDLE | SYSC_HAS_SIDLEMODE,
+.idlemodes = SIDLE_FORCE | SIDLE_NO,
+.sysc_fields= omap_hwmod_sysc_type1,
+};
+
static struct omap_hwmod_class dra7xx_aes_hwmod_class = {
.name = aes,
.sysc = dra7xx_aes_sysc,
@@ -595,6 +604,11 @@ static struct omap_hwmod_class dra7xx_des_hwmod_class = {
.rev= 2,
};
+static struct omap_hwmod_class dra7xx_rng_hwmod_class = {
+.name = rng,
+.sysc = dra7xx_rng_sysc,
+};
+
/* gpio dev_attr */
static struct omap_gpio_dev_attr gpio_dev_attr = {
.bank_width = 32,
@@ -810,6 +824,19 @@ static struct omap_hwmod dra7xx_des_hwmod = {
},
};
+static struct omap_hwmod dra7xx_rng_hwmod = {
+.name = rng,
+.class = dra7xx_rng_hwmod_class,
+.clkdm_name = l4sec_clkdm,
+.prcm = {
+.omap4 = {
+.clkctrl_offs = DRA7XX_CM_L4SEC_RNG_CLKCTRL_OFFSET,
+.context_offs = DRA7XX_RM_L4SEC_RNG_CONTEXT_OFFSET,
+.modulemode = MODULEMODE_HWCTRL,
+},
+},
+};
+
/*
* 'gpmc' class
*
@@ -2246,6 +2273,13 @@ static struct omap_hwmod_ocp_if dra7xx_l4_per1__des = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/* l4_per1 - rng */
+static struct omap_hwmod_ocp_if dra7xx_l4_per1__rng = {
+.master = dra7xx_l4_per1_hwmod,
+.slave = dra7xx_rng_hwmod,
+.user = OCP_USER_MPU,
+};
+
static struct omap_hwmod_addr_space dra7xx_gpmc_addrs[] = {
{
.pa_start = 0x5000,
@@ -2782,6 +2816,7 @@ static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[]
__initdata = {
dra7xx_l4_per1__uart5,
dra7xx_l4_per1__uart6,
dra7xx_l4_per1__des,
+ dra7xx_l4_per1__rng,
dra7xx_l4_per3__usb_otg_ss1,
dra7xx_l4_per3__usb_otg_ss2,
dra7xx_l4_per3__usb_otg_ss3,
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 08/10] ARM: dts: DRA7: Add DT node for AES IP
DRA7 SoC has same AES IP as on OMAP4. Add DT entries for the same.
Signed-off-by: Joel Fernandes jo...@ti.com
---
arch/arm/boot/dts/dra7.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 0533b89..c45f7e9 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -790,6 +790,17 @@
status = disabled;
};
+ aes: aes@4b50 {
+ compatible = ti,omap4-aes;
+ ti,hwmods = aes;
+ reg = 0x4b50 0xa0;
+ interrupts = GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH;
+ dmas = sdma 111, sdma 110;
+ dma-names = tx, rx;
+ clocks = l3_iclk_div;
+ clock-names = fck;
+ };
+
des: des@480a5000 {
compatible = ti,omap4-des;
ti,hwmods = des;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/10] ARM: dts: OMAP4: Add clock nodes for AES/DES nodes
AES/DES nodes have clock nodes in the clock tree, use them. Internal trees were
using hwmod, but now that clock nodes are there, we can use them instead and
upstream it.
Signed-off-by: Joel Fernandes jo...@ti.com
---
arch/arm/boot/dts/omap4.dtsi |4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 27fcac8..f19ffa8 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -806,6 +806,8 @@
interrupts = GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH;
dmas = sdma 111, sdma 110;
dma-names = tx, rx;
+ clocks = aes1_fck;
+ clock-names = fck;
};
des: des@480a5000 {
@@ -815,6 +817,8 @@
interrupts = GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH;
dmas = sdma 117, sdma 116;
dma-names = tx, rx;
+ clocks = des_fck;
+ clock-names = fck;
};
abb_mpu: regulator-abb-mpu {
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/10] ARM: OMAP: hwmod: Add SYSC offsets for AES IP
The AES IP has the SIDLE offset by 2 and not 3, to allow SIDLE modes
to work for AES, we add a new SYSC type to HWMOD code.
Signed-off-by: Joel Fernandes jo...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.h | 11 +++
arch/arm/mach-omap2/omap_hwmod_common_data.c | 10 ++
2 files changed, 21 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod.h b/arch/arm/mach-omap2/omap_hwmod.h
index 0f97d63..b2efcc8 100644
--- a/arch/arm/mach-omap2/omap_hwmod.h
+++ b/arch/arm/mach-omap2/omap_hwmod.h
@@ -41,6 +41,7 @@ struct omap_device;
extern struct omap_hwmod_sysc_fields omap_hwmod_sysc_type1;
extern struct omap_hwmod_sysc_fields omap_hwmod_sysc_type2;
extern struct omap_hwmod_sysc_fields omap_hwmod_sysc_type3;
+extern struct omap_hwmod_sysc_fields omap_hwmod_sysc_type4;
/*
* OCP SYSCONFIG bit shifts/masks TYPE1. These are for IPs compliant
@@ -81,6 +82,16 @@ extern struct omap_hwmod_sysc_fields omap_hwmod_sysc_type3;
#define SYSC_TYPE3_MIDLEMODE_SHIFT 2
#define SYSC_TYPE3_MIDLEMODE_MASK (0x3 SYSC_TYPE3_MIDLEMODE_SHIFT)
+/*
+ * OCP SYSCONFIG bit shifts/masks TYPE4.
+ */
+#define SYSC_TYPE4_SIDLEMODE_SHIFT 2
+#define SYSC_TYPE4_SIDLEMODE_MASK (0x3 SYSC_TYPE4_SIDLEMODE_SHIFT)
+#define SYSC_TYPE4_SOFTRESET_SHIFT 1
+#define SYSC_TYPE4_SOFTRESET_MASK (1 SYSC_TYPE4_SOFTRESET_SHIFT)
+#define SYSC_TYPE4_AUTOIDLE_SHIFT 0
+#define SYSC_TYPE4_AUTOIDLE_MASK (1 SYSC_TYPE4_AUTOIDLE_SHIFT)
+
/* OCP SYSSTATUS bit shifts/masks */
#define SYSS_RESETDONE_SHIFT 0
#define SYSS_RESETDONE_MASK(1 SYSS_RESETDONE_SHIFT)
diff --git a/arch/arm/mach-omap2/omap_hwmod_common_data.c
b/arch/arm/mach-omap2/omap_hwmod_common_data.c
index 79d623b..7443dc0 100644
--- a/arch/arm/mach-omap2/omap_hwmod_common_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_common_data.c
@@ -59,6 +59,16 @@ struct omap_hwmod_sysc_fields omap_hwmod_sysc_type3 = {
.sidle_shift= SYSC_TYPE3_SIDLEMODE_SHIFT,
};
+/**
+ * struct omap_hwmod_sysc_type4 - TYPE4 sysconfig scheme.
+ * Used by some IPs on AM33xx
+ */
+struct omap_hwmod_sysc_fields omap_hwmod_sysc_type4 = {
+ .sidle_shift= SYSC_TYPE4_SIDLEMODE_SHIFT,
+ .srst_shift = SYSC_TYPE4_SOFTRESET_SHIFT,
+ .autoidle_shift = SYSC_TYPE4_AUTOIDLE_SHIFT,
+};
+
struct omap_dss_dispc_dev_attr omap2_3_dss_dispc_dev_attr = {
.manager_count = 2,
.has_framedonetv_irq= 0
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 06/10] ARM: OMAP4: hwmod: add hwmod data for DES IP
OMAP4 has a DES IP for DES and 3DES encryption, Add hwmod data for the same.
Signed-off-by: Joel Fernandes jo...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 35
1 file changed, 35 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 3b12244..8bf6083 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -4824,6 +4824,40 @@ static struct omap_hwmod_ocp_if omap4_l3_main_2__aes1 = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/* DES3DES */
+static struct omap_hwmod_class_sysconfig omap4_des_sysc = {
+ .rev_offs = 0x30,
+ .sysc_offs = 0x34,
+ .syss_offs = 0x38,
+ .sysc_flags = SYSS_HAS_RESET_STATUS,
+ .sysc_fields= omap_hwmod_sysc_type4,
+};
+
+static struct omap_hwmod_class omap4_des_hwmod_class = {
+ .name = des,
+ .sysc = omap4_des_sysc,
+};
+
+static struct omap_hwmod omap4_des_hwmod = {
+ .name = des,
+ .class = omap4_des_hwmod_class,
+ .clkdm_name = l4_secure_clkdm,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = OMAP4_CM_L4SEC_DES3DES_CLKCTRL_OFFSET,
+ .context_offs = OMAP4_RM_L4SEC_DES3DES_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+};
+
+static struct omap_hwmod_ocp_if omap4_l4_per__des = {
+ .master = omap44xx_l4_per_hwmod,
+ .slave = omap4_des_hwmod,
+ .clk= des_fck,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
static struct omap_hwmod_ocp_if *omap44xx_hwmod_ocp_ifs[] __initdata = {
omap44xx_l3_main_1__dmm,
omap44xx_mpu__dmm,
@@ -4979,6 +5013,7 @@ static struct omap_hwmod_ocp_if *omap44xx_hwmod_ocp_ifs[]
__initdata = {
omap44xx_mpu__emif1,
omap44xx_mpu__emif2,
omap4_l3_main_2__aes1,
+ omap4_l4_per__des,
NULL,
};
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 05/10] ARM: OMAP4: hwmod: Add hwmod data for AES IP
Crypto modules AES0/1 belong to:
PD_L4_PER power domain
CD_L4_SEC clock domain
On the L3, the AES modules are mapped to
L3_CLK2: Peripherals and multimedia sub clock domain
We add hwmod data for the same.
Signed-off-by: Joel Fernandes jo...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 43
1 file changed, 43 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 1219280..3b12244 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -4782,6 +4782,48 @@ static struct omap_hwmod_ocp_if omap44xx_mpu__emif2 = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/*
+Crypto modules AES0/1 belong to:
+ PD_L4_PER power domain
+ CD_L4_SEC clock domain
+ On the L3, the AES modules are mapped to
+ L3_CLK2: Peripherals and multimedia sub clock domain
+*/
+
+static struct omap_hwmod_class_sysconfig omap4_aes1_sysc = {
+ .rev_offs = 0x80,
+ .sysc_offs = 0x84,
+ .syss_offs = 0x88,
+ .sysc_flags = SYSS_HAS_RESET_STATUS,
+ .sysc_fields= omap_hwmod_sysc_type4,
+};
+
+static struct omap_hwmod_class omap4_aes1_hwmod_class = {
+ .name = aes1,
+ .sysc = omap4_aes1_sysc,
+};
+
+static struct omap_hwmod omap4_aes1_hwmod = {
+ .name = aes,
+ .class = omap4_aes1_hwmod_class,
+ .clkdm_name = l4_secure_clkdm,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = OMAP4_CM_L4SEC_AES1_CLKCTRL_OFFSET,
+ .context_offs = OMAP4_RM_L4SEC_AES1_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+};
+
+/* l3_main_2 - aes1 */
+static struct omap_hwmod_ocp_if omap4_l3_main_2__aes1 = {
+ .master = omap44xx_l3_main_2_hwmod,
+ .slave = omap4_aes1_hwmod,
+ .clk= aes1_fck,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
static struct omap_hwmod_ocp_if *omap44xx_hwmod_ocp_ifs[] __initdata = {
omap44xx_l3_main_1__dmm,
omap44xx_mpu__dmm,
@@ -4936,6 +4978,7 @@ static struct omap_hwmod_ocp_if *omap44xx_hwmod_ocp_ifs[]
__initdata = {
omap44xx_l4_abe__wd_timer3_dma,
omap44xx_mpu__emif1,
omap44xx_mpu__emif2,
+ omap4_l3_main_2__aes1,
NULL,
};
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 09/10] ARM: dts: OMAP4: clk: Add clk node for DES IP
From: Lokesh Vutla lokeshvu...@ti.com
DES IP already has main and interface clk as des_fck.
Node for des_fck is missing in clk tree. Adding the same.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
Signed-off-by: Joel Fernandes jo...@ti.com
---
arch/arm/boot/dts/omap44xx-clocks.dtsi |8
drivers/clk/ti/clk-44xx.c |1 +
2 files changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/omap44xx-clocks.dtsi
b/arch/arm/boot/dts/omap44xx-clocks.dtsi
index c821ff5..83cf189 100644
--- a/arch/arm/boot/dts/omap44xx-clocks.dtsi
+++ b/arch/arm/boot/dts/omap44xx-clocks.dtsi
@@ -985,6 +985,14 @@
reg = 0x15a8;
};
+ des_fck: des_fck@4a0095b0 {
+ #clock-cells = 0;
+ compatible = gate-clock;
+ clocks = l3_div_ck;
+ bit-shift = 1;
+ reg = 0x4a0095b0 0x4;
+ };
+
dss_sys_clk: dss_sys_clk {
#clock-cells = 0;
compatible = ti,gate-clock;
diff --git a/drivers/clk/ti/clk-44xx.c b/drivers/clk/ti/clk-44xx.c
index 02517a8..85d97c3 100644
--- a/drivers/clk/ti/clk-44xx.c
+++ b/drivers/clk/ti/clk-44xx.c
@@ -120,6 +120,7 @@ static struct ti_dt_clk omap44xx_clks[] = {
DT_CLK(NULL, syc_clk_div_ck, syc_clk_div_ck),
DT_CLK(NULL, aes1_fck, aes1_fck),
DT_CLK(NULL, aes2_fck, aes2_fck),
+ DT_CLK(NULL, des_fck, des_fck),
DT_CLK(NULL, dmic_sync_mux_ck, dmic_sync_mux_ck),
DT_CLK(NULL, func_dmic_abe_gfclk, func_dmic_abe_gfclk),
DT_CLK(NULL, dss_sys_clk, dss_sys_clk),
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/10] ARM: DRA7xx: hwmod: Add hwmod data for DES IP
dra7xx SoC has a DES module. Add the required data to hwmod.
Signed-off-by: Joel Fernandes jo...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 39 +
1 file changed, 39 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index 810c205..24ab160 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -561,6 +561,23 @@ static struct omap_hwmod_class dra7xx_gpio_hwmod_class = {
.rev= 2,
};
+static struct omap_hwmod_class_sysconfig dra7xx_des_sysc = {
+ .rev_offs = 0x0030,
+ .sysc_offs = 0x0034,
+ .syss_offs = 0x0038,
+ .sysc_flags = (SYSC_HAS_AUTOIDLE |
+ SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET |
+ SYSS_HAS_RESET_STATUS),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO),
+ .sysc_fields= omap_hwmod_sysc_type4,
+};
+
+static struct omap_hwmod_class dra7xx_des_hwmod_class = {
+ .name = des,
+ .sysc = dra7xx_des_sysc,
+ .rev= 2,
+};
+
/* gpio dev_attr */
static struct omap_gpio_dev_attr gpio_dev_attr = {
.bank_width = 32,
@@ -750,6 +767,19 @@ static struct omap_hwmod dra7xx_gpio8_hwmod = {
.dev_attr = gpio_dev_attr,
};
+static struct omap_hwmod dra7xx_des_hwmod = {
+ .name = des,
+ .class = dra7xx_des_hwmod_class,
+ .clkdm_name = l4sec_clkdm,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = DRA7XX_CM_L4SEC_DES3DES_CLKCTRL_OFFSET,
+ .context_offs = DRA7XX_RM_L4SEC_DES3DES_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_HWCTRL,
+ },
+ },
+};
+
/*
* 'gpmc' class
*
@@ -2170,6 +2200,14 @@ static struct omap_hwmod_ocp_if dra7xx_l4_per1__gpio8 = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/* l4_per1 - des */
+static struct omap_hwmod_ocp_if dra7xx_l4_per1__des = {
+ .master = dra7xx_l4_per1_hwmod,
+ .slave = dra7xx_des_hwmod,
+ .clk= l3_iclk_div,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
static struct omap_hwmod_addr_space dra7xx_gpmc_addrs[] = {
{
.pa_start = 0x5000,
@@ -2704,6 +2742,7 @@ static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[]
__initdata = {
dra7xx_l4_per1__uart4,
dra7xx_l4_per1__uart5,
dra7xx_l4_per1__uart6,
+ dra7xx_l4_per1__des,
dra7xx_l4_per3__usb_otg_ss1,
dra7xx_l4_per3__usb_otg_ss2,
dra7xx_l4_per3__usb_otg_ss3,
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC 3/4] of/clk: Register clocks suitable for Runtime PM with the PM core
Geert Uytterhoeven geert+rene...@glider.be writes:
When adding a device from DT, check if its clocks are suitable for Runtime
PM, and register them with the PM core.
If Runtime PM is disabled, just enable the clock.
This allows the PM core to automatically manage gate clocks of devices for
Runtime PM.
...unless the device is already in an existing pm_domain, right?
I like this approach, and it extends nicely what we already do on
platforms using drivers/base/power/clock_ops.c into DT land.
My only concern is how this will interact if it's used along with
devices that have existing pm_domains. I don't have any specific
concerns (yet, because it's Friday, and my brain is turing off), but it
just made me wonder if this will be potentially confusing.
Also...
[...]
+static int of_clk_register(struct device *dev, struct clk *clk)
+{
+ int error;
+
+ if (!dev-pm_domain) {
+ error = pm_clk_create(dev);
+ if (error)
+ return error;
+
+ dev-pm_domain = of_clk_pm_domain;
+ }
+
+ dev_dbg(dev, Setting up clock for runtime PM management\n);
+ return pm_clk_add_clk(dev, clk);
I would've expected these 2 lines to be inside the pm_domain check.
What's the reason for doing the pm_clk_add() when the pm_domain isn't
going to be used? I suppose it's harmless, but it's a bit confusing.
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 19/41] OMAPDSS: panel-dpi: Add DT support
* Tomi Valkeinen tomi.valkei...@ti.com [140424 02:53]:
On 18/04/14 18:51, Tony Lindgren wrote:
+ gpio = of_get_gpio(node, 0);
+ if (gpio_is_valid(gpio) || gpio == -ENOENT) {
+ ddata-enable_gpio = gpio;
+ } else {
+ dev_err(pdev-dev, failed to parse enable gpio\n);
+ return gpio;
+ }
We should set the GPIO polarity based on the OF_GPIO_ACTIVE_LOW like
gpio_backlight_probe_dt is doing.
Instead of doing it with the old gpio API, and checking the 'active'
flag everywhere, I think we can use the new gpiod API which handles the
polarity automatically.
I attached prototype patches (based on -rc2) for panel dpi using that
approach. It's a bit messier than I'd like, because for non-DT boot we
need to request the gpio using the old API, and then convert it to
gpio_desc. We can remove that code when all the boards use DT.
I've compiled tested this only, as I don't have DPI panels I could use.
I did try similar approach for TFP410, and it seemed to work fine.
Got these working by updating my test patch to use enable-gpios instead
of gpios, and had to change from GPIO_ACTIVE_LOW to GPIO_ACTIVE_HIGH.
Are we now also breaking legacy booting by reversing the polarity?
In any case, looks like we have some duplicate panel code.. Turns
out most panel dpi users for omap3 board-*.c files are just
sharp-ls037v7dw01 panels but configured in QVGA mode. At least for
EVM and and LDP based on looking at the pictures and the configuration
pins (using the names kernel):
QVGA = lcd MO
reset = lcd RESB
...
Then the enable_gpio should be just a GPIO controlled 3.3V regulator
in most cases. I suggest we move them over to ls037v7dw01 and allow
configuring them both for VGA and QVGA depending on the orientation.
I guess you do have some device with ls037v7dw01 since you've been
patching it?
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3 4/5] Input: tsc2005: add DT support
This adds DT support to the tsc2005 touchscreen
driver.
Signed-off-by: Sebastian Reichel s...@kernel.org
---
drivers/input/touchscreen/tsc2005.c | 96 +
1 file changed, 77 insertions(+), 19 deletions(-)
diff --git a/drivers/input/touchscreen/tsc2005.c
b/drivers/input/touchscreen/tsc2005.c
index 9daaddd..a83d1be 100644
--- a/drivers/input/touchscreen/tsc2005.c
+++ b/drivers/input/touchscreen/tsc2005.c
@@ -28,6 +28,8 @@
#include linux/interrupt.h
#include linux/delay.h
#include linux/pm.h
+#include linux/of.h
+#include linux/of_gpio.h
#include linux/spi/spi.h
#include linux/spi/tsc2005.h
@@ -100,6 +102,11 @@
TSC2005_CFR2_AVG_7)
#define MAX_12BIT 0xfff
+#define TSC2005_DEF_X_FUZZ 4
+#define TSC2005_DEF_Y_FUZZ 8
+#define TSC2005_DEF_P_FUZZ 2
+#define TSC2005_DEF_RESISTOR 280
+
#define TSC2005_SPI_MAX_SPEED_HZ 1000
#define TSC2005_PENUP_TIME_MS 40
@@ -143,6 +150,7 @@ struct tsc2005 {
boolpen_down;
+ int reset_gpio;
void(*set_reset)(bool enable);
};
@@ -337,6 +345,14 @@ static void tsc2005_stop_scan(struct tsc2005 *ts)
tsc2005_cmd(ts, TSC2005_CMD_STOP);
}
+static void tsc2005_set_reset(struct tsc2005 *ts, bool enable)
+{
+ if (ts-reset_gpio = 0)
+ gpio_set_value(ts-reset_gpio, enable);
+ else if (ts-set_reset)
+ ts-set_reset(enable);
+}
+
/* must be called with ts-mutex held */
static void __tsc2005_disable(struct tsc2005 *ts)
{
@@ -355,7 +371,7 @@ static void __tsc2005_enable(struct tsc2005 *ts)
{
tsc2005_start_scan(ts);
- if (ts-esd_timeout ts-set_reset) {
+ if (ts-esd_timeout (ts-set_reset || ts-reset_gpio)) {
ts-last_valid_interrupt = jiffies;
schedule_delayed_work(ts-esd_work,
round_jiffies_relative(
@@ -414,9 +430,9 @@ static ssize_t tsc2005_selftest_show(struct device *dev,
}
/* hardware reset */
- ts-set_reset(false);
+ tsc2005_set_reset(ts, false);
usleep_range(100, 500); /* only 10us required */
- ts-set_reset(true);
+ tsc2005_set_reset(ts, true);
if (!success)
goto out;
@@ -459,7 +475,7 @@ static umode_t tsc2005_attr_is_visible(struct kobject *kobj,
umode_t mode = attr-mode;
if (attr == dev_attr_selftest.attr) {
- if (!ts-set_reset)
+ if (!ts-set_reset !ts-reset_gpio)
mode = 0;
}
@@ -509,9 +525,9 @@ static void tsc2005_esd_work(struct work_struct *work)
tsc2005_update_pen_state(ts, 0, 0, 0);
- ts-set_reset(false);
+ tsc2005_set_reset(ts, false);
usleep_range(100, 500); /* only 10us required */
- ts-set_reset(true);
+ tsc2005_set_reset(ts, true);
enable_irq(ts-spi-irq);
tsc2005_start_scan(ts);
@@ -572,29 +588,47 @@ static void tsc2005_setup_spi_xfer(struct tsc2005 *ts)
static int tsc2005_probe(struct spi_device *spi)
{
const struct tsc2005_platform_data *pdata = dev_get_platdata(spi-dev);
+ struct device_node *np = spi-dev.of_node;
+
struct tsc2005 *ts;
struct input_dev *input_dev;
- unsigned int max_x, max_y, max_p;
- unsigned int fudge_x, fudge_y, fudge_p;
+ unsigned int max_x = MAX_12BIT;
+ unsigned int max_y = MAX_12BIT;
+ unsigned int max_p = MAX_12BIT;
+ unsigned int fudge_x = TSC2005_DEF_X_FUZZ;
+ unsigned int fudge_y = TSC2005_DEF_Y_FUZZ;
+ unsigned int fudge_p = TSC2005_DEF_P_FUZZ;
+ unsigned int x_plate_ohm = TSC2005_DEF_RESISTOR;
+ unsigned int esd_timeout;
int error;
- if (!pdata) {
+ if (!np !pdata) {
dev_err(spi-dev, no platform data\n);
return -ENODEV;
}
- fudge_x = pdata-ts_x_fudge? : 4;
- fudge_y = pdata-ts_y_fudge? : 8;
- fudge_p = pdata-ts_pressure_fudge ? : 2;
- max_x = pdata-ts_x_max ? : MAX_12BIT;
- max_y = pdata-ts_y_max ? : MAX_12BIT;
- max_p = pdata-ts_pressure_max ? : MAX_12BIT;
-
if (spi-irq = 0) {
dev_err(spi-dev, no irq\n);
return -ENODEV;
}
+ if (pdata) {
+ fudge_x = pdata-ts_x_fudge;
+ fudge_y = pdata-ts_y_fudge;
+ fudge_p = pdata-ts_pressure_fudge;
+ max_x = pdata-ts_x_max;
+ max_y = pdata-ts_y_max;
+ max_p = pdata-ts_pressure_max;
+ x_plate_ohm = pdata-ts_x_plate_ohm;
+ esd_timeout = pdata-esd_timeout_ms;
+ } else {
+ x_plate_ohm = TSC2005_DEF_RESISTOR;
+ of_property_read_u32(np, ti,x-plate-ohms, x_plate_ohm);
+
[PATCHv3 5/5] Documentation: dt: Document TSC2005 DT binding
Add devicetree binding documentation for TSC2005 touchscreen.
Signed-off-by: Sebastian Reichel s...@kernel.org
---
.../bindings/input/touchscreen/tsc2005.txt | 39 ++
1 file changed, 39 insertions(+)
create mode 100644
Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt
diff --git a/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt
b/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt
new file mode 100644
index 000..663f8ab
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt
@@ -0,0 +1,39 @@
+* Texas Instruments tsc2005 touchscreen controller
+
+Required properties:
+ - compatible: ti,tsc2005
+ - reg : SPI device address
+ - spi-max-frequency : Maximal SPI speed
+ - interrupts: IRQ specifier
+ - reset-gpios : GPIO specifier
+
+Optional properties:
+ - ti,x-plate-ohms : integer, resistance of the touchscreen's X
plates
+ in ohm (defaults to 280)
+ - ti,esd-recovery-timeout-ms : integer, if the touchscreen does not respond
after
+ the configured time (in milli seconds), the
driver
+ will reset it. This is disabled by default.
+ - properties defined in touchscreen.txt
+
+Example:
+
+mcspi1 {
+ tsc2005@0 {
+ compatible = ti,tsc2005;
+ spi-max-frequency = 600;
+ reg = 0;
+
+ reset-gpios = gpio4 8 GPIO_ACTIVE_HIGH; /* 104 */
+ interrupts-extended = gpio4 4 IRQ_TYPE_NONE; /* 100 */
+
+ touchscreen-fuzz-x = 4;
+ touchscreen-fuzz-y = 7;
+ touchscreen-fuzz-pressure = 2;
+ touchscreen-max-x = 4096;
+ touchscreen-max-y = 4096;
+ touchscreen-max-pressure = 2048;
+
+ ti,x-plate-ohms = 280;
+ ti,esd-recovery-timeout-ms = 8000;
+ };
+}
--
1.9.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3 0/5] tsc2005 DT binding
Hi, This adds device tree support for the tsc2005 touchscreen controller, which is currently only used by the Nokia N900 board. The patch does not update the reset pin handling for platform data based probe to avoid merge conflicts. The n900 platform code will be removed in the near future (3.16?) and the driver can be simplified once that has happened. Changes since v2 [0]: * rename ti,x-plate-resistance to ti,x-plate-ohms, so that the same property name is used for tsc2005 and tsc2007 * document x-size and y-size as deprecated form of touchscreen-size-x and touchscreen-size-y * add documentation for touchscreen-inverted-x and touchscreen-inverted-y to the common touchscreen binding and mark x-invert and y-invert as deprecated. * add units to the property descriptions in the common touchscreen binding Documentation * document moving-threshold as deprecated form of touchscreen-fuzz-x and touchscreen-fuzz-y combination * document contact-threshold as deprecated form of touchscreen-fuzz-pressure [0] https://lkml.org/lkml/2014/4/5/103 -- Sebastian Sebastian Reichel (5): Input: add common DT binding for touchscreens Input: tsc2005: use dev_err for error messages Input: tsc2005: convert driver to use devm_* Input: tsc2005: add DT support Documentation: dt: Document TSC2005 DT binding .../bindings/input/touchscreen/touchscreen.txt | 27 + .../bindings/input/touchscreen/tsc2005.txt | 39 +++ drivers/input/input.c | 34 ++ drivers/input/touchscreen/tsc2005.c| 130 ++--- include/linux/input.h | 8 ++ 5 files changed, 197 insertions(+), 41 deletions(-) create mode 100644 Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt create mode 100644 Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt -- 1.9.2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3 3/5] Input: tsc2005: convert driver to use devm_*
Simplify the driver by using managed resources for memory allocation of
internal struct, input device allocation and irq request.
Signed-off-by: Sebastian Reichel s...@kernel.org
---
drivers/input/touchscreen/tsc2005.c | 30 ++
1 file changed, 10 insertions(+), 20 deletions(-)
diff --git a/drivers/input/touchscreen/tsc2005.c
b/drivers/input/touchscreen/tsc2005.c
index 520e673..9daaddd 100644
--- a/drivers/input/touchscreen/tsc2005.c
+++ b/drivers/input/touchscreen/tsc2005.c
@@ -604,12 +604,10 @@ static int tsc2005_probe(struct spi_device *spi)
if (error)
return error;
- ts = kzalloc(sizeof(*ts), GFP_KERNEL);
- input_dev = input_allocate_device();
- if (!ts || !input_dev) {
- error = -ENOMEM;
- goto err_free_mem;
- }
+ ts = devm_kzalloc(spi-dev, sizeof(*ts), GFP_KERNEL);
+ input_dev = devm_input_allocate_device(spi-dev);
+ if (!ts || !input_dev)
+ return -ENOMEM;
ts-spi = spi;
ts-idev = input_dev;
@@ -649,12 +647,13 @@ static int tsc2005_probe(struct spi_device *spi)
/* Ensure the touchscreen is off */
tsc2005_stop_scan(ts);
- error = request_threaded_irq(spi-irq, NULL, tsc2005_irq_thread,
-IRQF_TRIGGER_RISING | IRQF_ONESHOT,
-tsc2005, ts);
+ error = devm_request_threaded_irq(spi-dev, spi-irq, NULL,
+ tsc2005_irq_thread,
+ IRQF_TRIGGER_RISING | IRQF_ONESHOT,
+ tsc2005, ts);
if (error) {
dev_err(spi-dev, Failed to request irq, err: %d\n, error);
- goto err_free_mem;
+ return error;
}
spi_set_drvdata(spi, ts);
@@ -662,7 +661,7 @@ static int tsc2005_probe(struct spi_device *spi)
if (error) {
dev_err(spi-dev,
Failed to create sysfs attributes, err: %d\n, error);
- goto err_clear_drvdata;
+ return error;
}
error = input_register_device(ts-idev);
@@ -677,11 +676,6 @@ static int tsc2005_probe(struct spi_device *spi)
err_remove_sysfs:
sysfs_remove_group(spi-dev.kobj, tsc2005_attr_group);
-err_clear_drvdata:
- free_irq(spi-irq, ts);
-err_free_mem:
- input_free_device(input_dev);
- kfree(ts);
return error;
}
@@ -691,10 +685,6 @@ static int tsc2005_remove(struct spi_device *spi)
sysfs_remove_group(ts-spi-dev.kobj, tsc2005_attr_group);
- free_irq(ts-spi-irq, ts);
- input_unregister_device(ts-idev);
- kfree(ts);
-
return 0;
}
--
1.9.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3 2/5] Input: tsc2005: use dev_err for error messages
Change some dev_dbg() invocations to dev_err() ones, because they
are supposed to output error messages.
Signed-off-by: Sebastian Reichel s...@kernel.org
---
drivers/input/touchscreen/tsc2005.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/input/touchscreen/tsc2005.c
b/drivers/input/touchscreen/tsc2005.c
index 550adcb..520e673 100644
--- a/drivers/input/touchscreen/tsc2005.c
+++ b/drivers/input/touchscreen/tsc2005.c
@@ -579,7 +579,7 @@ static int tsc2005_probe(struct spi_device *spi)
int error;
if (!pdata) {
- dev_dbg(spi-dev, no platform data\n);
+ dev_err(spi-dev, no platform data\n);
return -ENODEV;
}
@@ -591,7 +591,7 @@ static int tsc2005_probe(struct spi_device *spi)
max_p = pdata-ts_pressure_max ? : MAX_12BIT;
if (spi-irq = 0) {
- dev_dbg(spi-dev, no irq\n);
+ dev_err(spi-dev, no irq\n);
return -ENODEV;
}
--
1.9.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3 1/5] Input: add common DT binding for touchscreens
Add common DT binding documentation for touchscreen devices and
implement input_parse_touchscreen_of_params, which parses the common
properties and configures the input device accordingly.
The method currently does not interpret the axis inversion properties,
since there is no matching flag in the generic linux input device.
Signed-off-by: Sebastian Reichel s...@kernel.org
---
.../bindings/input/touchscreen/touchscreen.txt | 27 +
drivers/input/input.c | 34 ++
include/linux/input.h | 8 +
3 files changed, 69 insertions(+)
create mode 100644
Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
diff --git
a/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
b/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
new file mode 100644
index 000..d8e0616
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
@@ -0,0 +1,27 @@
+General Touchscreen Properties:
+
+Optional properties for Touchscreens:
+ - touchscreen-size-x : horizontal resolution of touchscreen
+ (in pixels)
+ - touchscreen-size-y : vertical resolution of touchscreen
+ (in pixels)
+ - touchscreen-max-pressure: maximum reported pressure (arbitrary range
+ dependent on the controller)
+ - touchscreen-fuzz-x : horizontal noise value of the absolute input
+ device (in pixels)
+ - touchscreen-fuzz-y : vertical noise value of the absolute input
+ device (in pixels)
+ - touchscreen-fuzz-pressure : pressure noise value of the absolute input
+ device (arbitrary range dependent on the
+ controller)
+ - touchscreen-inverted-x : X axis is inverted (boolean)
+ - touchscreen-inverted-y : Y axis is inverted (boolean)
+
+Deprecated properties for Touchscreens:
+ - x-size : deprecated name for touchscreen-size-x
+ - y-size : deprecated name for touchscreen-size-y
+ - moving-threshold: deprecated name for a combination of
+ touchscreen-fuzz-x and touchscreen-fuzz-y
+ - contact-threshold : deprecated name for touchscreen-fuzz-pressure
+ - x-invert: deprecated name for touchscreen-inverted-x
+ - y-invert: deprecated name for touchscreen-inverted-y
diff --git a/drivers/input/input.c b/drivers/input/input.c
index 1c4c0db..97966d93 100644
--- a/drivers/input/input.c
+++ b/drivers/input/input.c
@@ -27,6 +27,7 @@
#include linux/device.h
#include linux/mutex.h
#include linux/rcupdate.h
+#include linux/of.h
#include input-compat.h
MODULE_AUTHOR(Vojtech Pavlik vojt...@suse.cz);
@@ -2398,6 +2399,39 @@ void input_free_minor(unsigned int minor)
}
EXPORT_SYMBOL(input_free_minor);
+#if defined(CONFIG_OF)
+/**
+ * input_parse_touchscreen_of_params - parse common touchscreen DT properties
+ * @dev: device that should be parsed
+ *
+ * This function parses common DT properties for touchscreens and setups the
+ * input device accordingly. The function keeps previously setuped default
+ * values if no value is specified via DT.
+ */
+void input_parse_touchscreen_of_params(struct input_dev *dev)
+{
+ struct device_node *np = dev-dev.parent-of_node;
+ struct input_absinfo *absinfo;
+
+ input_alloc_absinfo(dev);
+ if (!dev-absinfo)
+ return;
+
+ absinfo = dev-absinfo[ABS_X];
+ of_property_read_u32(np, touchscreen-size-x, absinfo-maximum);
+ of_property_read_u32(np, touchscreen-fuzz-x, absinfo-fuzz);
+
+ absinfo = dev-absinfo[ABS_Y];
+ of_property_read_u32(np, touchscreen-size-y, absinfo-maximum);
+ of_property_read_u32(np, touchscreen-fuzz-y, absinfo-fuzz);
+
+ absinfo = dev-absinfo[ABS_PRESSURE];
+ of_property_read_u32(np, touchscreen-max-pressure, absinfo-maximum);
+ of_property_read_u32(np, touchscreen-fuzz-pressure, absinfo-fuzz);
+}
+EXPORT_SYMBOL(input_parse_touchscreen_of_params);
+#endif
+
static int __init input_init(void)
{
int err;
diff --git a/include/linux/input.h b/include/linux/input.h
index 82ce323..3dc3b1e 100644
--- a/include/linux/input.h
+++ b/include/linux/input.h
@@ -531,4 +531,12 @@ int input_ff_erase(struct input_dev *dev, int effect_id,
struct file *file);
int input_ff_create_memless(struct input_dev *dev, void *data,
int (*play_effect)(struct input_dev *, void *, struct ff_effect
*));
+#if defined(CONFIG_OF)
+void input_parse_touchscreen_of_params(struct input_dev *dev);
+#else
+static inline void input_parse_touchscreen_of_params(struct input_dev *dev) {
+ return;
+}
+#endif
+
#endif
--
1.9.2
--
To unsubscribe from this
Re: [PATCH/RFC 3/4] of/clk: Register clocks suitable for Runtime PM with the PM core
On 24.04.2014 15:11, Ulf Hansson wrote:
On 24 April 2014 12:13, Geert Uytterhoeven geert+rene...@glider.be wrote:
When adding a device from DT, check if its clocks are suitable for Runtime
PM, and register them with the PM core.
If Runtime PM is disabled, just enable the clock.
This allows the PM core to automatically manage gate clocks of devices for
Runtime PM.
Normally I don't think it's a good idea to automatically manage
clocks from PM core or any other place but from the driver (and
possibly the subsystem).
The reason is simply that we hide things that normally is supposed to
be handled by the driver. Typically a cross SOC driver should work
fine both with and without a pm_domain. It should also not rely on
CONFIG_PM_RUNTIME.
Signed-off-by: Geert Uytterhoeven geert+rene...@glider.be
---
drivers/of/Makefile|1 +
drivers/of/of_clk.c| 103
drivers/of/platform.c |3 ++
include/linux/of_clk.h | 18 +
4 files changed, 125 insertions(+)
create mode 100644 drivers/of/of_clk.c
create mode 100644 include/linux/of_clk.h
diff --git a/drivers/of/Makefile b/drivers/of/Makefile
index ed9660adad77..49bcd413906f 100644
--- a/drivers/of/Makefile
+++ b/drivers/of/Makefile
@@ -10,3 +10,4 @@ obj-$(CONFIG_OF_PCI) += of_pci.o
obj-$(CONFIG_OF_PCI_IRQ) += of_pci_irq.o
obj-$(CONFIG_OF_MTD) += of_mtd.o
obj-$(CONFIG_OF_RESERVED_MEM) += of_reserved_mem.o
+obj-$(CONFIG_COMMON_CLK) += of_clk.o
diff --git a/drivers/of/of_clk.c b/drivers/of/of_clk.c
new file mode 100644
index ..35f5e9f3dd42
--- /dev/null
+++ b/drivers/of/of_clk.c
@@ -0,0 +1,103 @@
+/*
+ * Copyright (C) 2014 Glider bvba
+ */
+
+#include linux/clk.h
+#include linux/err.h
+#include linux/of.h
+#include linux/of_clk.h
+#include linux/platform_device.h
+#include linux/pm_clock.h
+#include linux/pm_runtime.h
+
+
+#ifdef CONFIG_PM_RUNTIME
+
+static int of_clk_pm_runtime_suspend(struct device *dev)
+{
+ int ret;
+
+ ret = pm_generic_runtime_suspend(dev);
+ if (ret)
+ return ret;
+
+ ret = pm_clk_suspend(dev);
+ if (ret) {
+ pm_generic_runtime_resume(dev);
+ return ret;
+ }
+
+ return 0;
+}
+
+static int of_clk_pm_runtime_resume(struct device *dev)
+{
+ pm_clk_resume(dev);
+ return pm_generic_runtime_resume(dev);
+}
+
+static struct dev_pm_domain of_clk_pm_domain = {
+ .ops = {
+ .runtime_suspend = of_clk_pm_runtime_suspend,
+ .runtime_resume = of_clk_pm_runtime_resume,
+ USE_PLATFORM_PM_SLEEP_OPS
+ },
+};
+
+static int of_clk_register(struct device *dev, struct clk *clk)
+{
+ int error;
+
+ if (!dev-pm_domain) {
+ error = pm_clk_create(dev);
+ if (error)
+ return error;
+
+ dev-pm_domain = of_clk_pm_domain;
I am concerned about how this will work in conjunction with the
generic power domain.
A device can't reside in more than one pm_domain; thus I think it
would be better to always use the generic power domain and not have a
specific one for clocks. Typically the genpd should invoke
pm_clk_resume|suspend from it's runtime PM callbacks.
I'm not sure about this. A typical use case would be to gate clocks ASAP
and then wait until device is idle long enough to consider turning off
the power domain worthwhile. Also sometimes we may want to gate the
clocks, but prevent power domain from being powered off to retain
hardware state (e.g. because there is no way to read it and restore later).
I believe, though, that for devices that are not inside a controllable
power domain, this might be a good solution.
Best regards,
Tomasz
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
