* Re: [PATCH v5] spi: rspi: Add DT support
From: Mark Brown @ 2014-01-29 18:00 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: devicetree, linux-spi, linux-sh, linux-kernel, Geert Uytterhoeven
In-Reply-To: <1390900898-31579-1-git-send-email-geert@linux-m68k.org>
[-- Attachment #1: Type: text/plain, Size: 204 bytes --]
On Tue, Jan 28, 2014 at 10:21:38AM +0100, Geert Uytterhoeven wrote:
> From: Geert Uytterhoeven <geert+renesas@linux-m68k.org>
Applied, thanks. I was expecting your last patch to be resubmitted as
well?
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [RFC PATCH v2 09/14] mtd: nand: add sunxi NFC dt bindings doc
From: Boris BREZILLON @ 2014-01-29 18:01 UTC (permalink / raw)
To: Rob Herring
Cc: Maxime Ripard, Rob Landley, Russell King, David Woodhouse,
Grant Likely, Brian Norris, Jason Gunthorpe, Arnd Bergmann,
devicetree@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-mtd, dev
In-Reply-To: <CAL_JsqLVr1gSLArqtfOiHce+u6ZK8FiKMX0o9bvMrMoGGhATvg@mail.gmail.com>
Hello Rob,
Le 29/01/2014 18:11, Rob Herring a écrit :
> On Wed, Jan 29, 2014 at 8:34 AM, Boris BREZILLON
> <b.brezillon.dev@gmail.com> wrote:
>> Add the sunxi NAND Flash Controller dt bindings documentation.
>>
>> Signed-off-by: Boris BREZILLON <b.brezillon.dev@gmail.com>
>> ---
>> .../devicetree/bindings/mtd/sunxi-nand.txt | 46 ++++++++++++++++++++
>> 1 file changed, 46 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/mtd/sunxi-nand.txt
>>
>> diff --git a/Documentation/devicetree/bindings/mtd/sunxi-nand.txt b/Documentation/devicetree/bindings/mtd/sunxi-nand.txt
>> new file mode 100644
>> index 0000000..b0e55a3
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mtd/sunxi-nand.txt
>> @@ -0,0 +1,46 @@
>> +Allwinner NAND Flash Controller (NFC)
>> +
>> +Required properties:
>> +- compatible : "allwinner,sun4i-nand".
>> +- reg : shall contain registers location and length for data and reg.
>> +- interrupts : shall define the nand controller interrupt.
>> +- #address-cells: shall be set to 1. Encode the nand CS.
>> +- #size-cells : shall be set to 0.
>> +- clocks : shall reference nand controller clocks.
>> +- clock-names : nand controller internal clock names. Shall contain :
>> + * "ahb_clk" : AHB gating clock
>> + * "sclk" : nand controller clock
>> +
>> +Optional children nodes:
>> +Children nodes represent the available nand chips.
>> +
>> +Optional properties:
> For the controller or per nand chip?
>
>> +- onfi,nand-timing-mode : mandatory if the chip does not support the ONFI
>> + standard.
> Add to generic nand binding.
>
>> +- allwinner,rb : shall contain the native Ready/Busy ids.
>> + or
>> +- rb-gpios : shall contain the gpios used as R/B pins.
> Isn't allwinner,rb implied by a lack of rb-gpios property. Or no R/B
> pin is an option?
Both are optional. In case none of the properties are defined the dev_ready
callback is set to NULL and the nand_base waiting loop is used.
> If so, don't you need some fixed time delay
> properties like max erase time?
This is handled in nand_base (using the chip_delay field), but I guess
we could
use the information retrieved from nand timings and the operation in
progress...
> rb-gpios could be added to the generic nand binding as well.
Sure.
>
> Rob
^ permalink raw reply
* RE: [RFC PATCH v2 09/14] mtd: nand: add sunxi NFC dt bindings doc
From: Gupta, Pekon @ 2014-01-29 18:02 UTC (permalink / raw)
To: Rob Herring, Boris BREZILLON,
Ezequiel Garcia (ezequiel.garcia@free-electrons.com)
Cc: devicetree@vger.kernel.org, Russell King, Arnd Bergmann,
linux-doc@vger.kernel.org, dev@linux-sunxi.org,
linux-kernel@vger.kernel.org, Jason Gunthorpe,
linux-mtd@lists.infradead.org, Rob Landley, Grant Likely,
Maxime Ripard, Brian Norris, David Woodhouse,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <CAL_JsqLVr1gSLArqtfOiHce+u6ZK8FiKMX0o9bvMrMoGGhATvg@mail.gmail.com>
Dear Rob, and other DT maintainers,
>From: Rob Herring
[...]
>> +- onfi,nand-timing-mode : mandatory if the chip does not support the ONFI
>> + standard.
>
>Add to generic nand binding.
>
>> +- allwinner,rb : shall contain the native Ready/Busy ids.
>> + or
>> +- rb-gpios : shall contain the gpios used as R/B pins.
>
>Isn't allwinner,rb implied by a lack of rb-gpios property. Or no R/B
>pin is an option? If so, don't you need some fixed time delay
>properties like max erase time?
>
>rb-gpios could be added to the generic nand binding as well.
>
I do think this should go into generic nand binding, as this is controller specific.
Some controllers have dedicated R/B pin (Ready/Busy) while others may use
GPIO instead. It's the way a hardware controller is designed.
Request you to please consider Ack from MTD Maintainers 'at-least' for
generic NAND DT bindings. There is already a discussion going in
a separate thread for which is still not awaiting replies [1].
[1] http://lists.infradead.org/pipermail/linux-mtd/2014-January/051625.html
with regards, pekon
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply
* Re: [PATCH v2 08/11] of: Increase MAX_PHANDLE_ARGS
From: Will Deacon @ 2014-01-29 18:03 UTC (permalink / raw)
To: Suravee Suthikulanit
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
Rob Herring, Rob Herring, Andreas Herrmann,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <52E940FC.9050602-5C7GfCeVMHo@public.gmane.org>
On Wed, Jan 29, 2014 at 05:57:16PM +0000, Suravee Suthikulanit wrote:
> On 1/29/2014 11:29 AM, Will Deacon wrote:
> > On Wed, Jan 29, 2014 at 05:26:35PM +0000, Suravee Suthikulanit wrote:
> >> On 1/29/2014 11:16 AM, Andreas Herrmann wrote:
> >>> On Wed, Jan 29, 2014 at 11:59:12AM -0500, Suravee Suthikulanit wrote:
> >>>> Actually, we are using 32 on the AMD system. So, do you think we can set
> >>>> this to 32 instead?
> >>>
> >>> I think that's ok.
> >>>
> >>> But are we really talking about number of SMRs or number of StreamIDs
> >>> per master device here? Ie. are you just having 32 SMRs for an SMMU on
> >>> your AMD system or do you have master devices which have 32 StreamIDs?
> >>>
> >>> If it's just number of SMRs we don't need to modify this macro.
> >>>
> >>
> >> I am referring to the case where each mmu-master can have upto 32 streamID.
> >
> > Crikey, how many SMRs do you have? Andreas and I have been struggling to
> > write a decent allocator for those, so if you have any algorithms that don't
> > require a quantum computer, we'd love to hear from you :)!
> >
> > Will
> >
>
> Are you talking about the __arm_smmu_alloc_bitmap()?
>
> Currently, we have configured the each SMMU to have 32 SMRs and using
> 15-bit streamID. However, we mostly have upto 32 streamID for each
> master, and most of the SMMU only have one master. So it looks like the
> current logic should be ok.
Interesting... how does that work for PCI? Do you force all devices behind a
given RC into the same address space?
Will
^ permalink raw reply
* [PATCH 0/2] ARM: dts/OMAP: add cpu clock nodes
From: Nishanth Menon @ 2014-01-29 18:19 UTC (permalink / raw)
To: Benoît Cousson, Tony Lindgren, Mike Turquette
Cc: Nishanth Menon, devicetree, linux-kernel, Tero Kristo, linux-omap,
linux-arm-kernel
Add clock nodes for all existing OMAP platforms where cpufreq-cpu0
can be used.
Sanity tested with linux next-20140128 tag, applies on
master 0e47c96 Merge tag 'for-linus-20140127' of git://git.infradead.org/linux-mtd
Ofcourse, I have send 7 different versions[1] previously, so I will start from
version 1 again considering that I have finally based on master.
If folks feel that the clock nodes must be split out into various platforms, I
can regenerate the series again.
Nishanth Menon (2):
clk: ti: am335x: remove unecessary cpu0 clk node
ARM: dts: OMAP3+: add clock nodes for CPU
arch/arm/boot/dts/am33xx.dtsi | 4 ++++
arch/arm/boot/dts/am4372.dtsi | 5 +++++
arch/arm/boot/dts/dra7.dtsi | 5 +++++
arch/arm/boot/dts/omap3.dtsi | 5 +++++
arch/arm/boot/dts/omap4.dtsi | 5 +++++
arch/arm/boot/dts/omap5.dtsi | 6 ++++++
drivers/clk/ti/clk-33xx.c | 1 -
7 files changed, 30 insertions(+), 1 deletion(-)
[1] Last version of the patch series was posted here:
http://marc.info/?l=linux-omap&m=138245695726479&w=2
--
1.7.9.5
Regards,
Nishanth Menon
^ permalink raw reply
* [PATCH 1/2] clk: ti: am335x: remove unecessary cpu0 clk node
From: Nishanth Menon @ 2014-01-29 18:19 UTC (permalink / raw)
To: Benoît Cousson, Tony Lindgren, Mike Turquette
Cc: Tero Kristo, linux-omap, devicetree, linux-arm-kernel,
linux-kernel, Nishanth Menon
In-Reply-To: <1391019557-22313-1-git-send-email-nm@ti.com>
cpu0 clock node has no functionality, since cpufreq-cpu0 is already
capable of picking up the clock from dts.
Signed-off-by: Nishanth Menon <nm@ti.com>
---
drivers/clk/ti/clk-33xx.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/clk/ti/clk-33xx.c b/drivers/clk/ti/clk-33xx.c
index 776ee45..028b337 100644
--- a/drivers/clk/ti/clk-33xx.c
+++ b/drivers/clk/ti/clk-33xx.c
@@ -34,7 +34,6 @@ static struct ti_dt_clk am33xx_clks[] = {
DT_CLK(NULL, "dpll_core_m5_ck", "dpll_core_m5_ck"),
DT_CLK(NULL, "dpll_core_m6_ck", "dpll_core_m6_ck"),
DT_CLK(NULL, "dpll_mpu_ck", "dpll_mpu_ck"),
- DT_CLK("cpu0", NULL, "dpll_mpu_ck"),
DT_CLK(NULL, "dpll_mpu_m2_ck", "dpll_mpu_m2_ck"),
DT_CLK(NULL, "dpll_ddr_ck", "dpll_ddr_ck"),
DT_CLK(NULL, "dpll_ddr_m2_ck", "dpll_ddr_m2_ck"),
--
1.7.9.5
^ permalink raw reply related
* [PATCH 2/2] ARM: dts: OMAP3+: add clock nodes for CPU
From: Nishanth Menon @ 2014-01-29 18:19 UTC (permalink / raw)
To: Benoît Cousson, Tony Lindgren, Mike Turquette
Cc: Tero Kristo, linux-omap, devicetree, linux-arm-kernel,
linux-kernel, Nishanth Menon
In-Reply-To: <1391019557-22313-1-git-send-email-nm@ti.com>
OMAP34xx, AM3517 and OMAP36xx platforms use dpll1 clock.
OMAP443x, OMAP446x, OMAP447x, OMAP5, DRA7, AM43xx platforms use
dpll_mpu clock.
Latency used is the generic latency defined in omap-cpufreq
driver.
Signed-off-by: Nishanth Menon <nm@ti.com>
---
arch/arm/boot/dts/am33xx.dtsi | 4 ++++
arch/arm/boot/dts/am4372.dtsi | 5 +++++
arch/arm/boot/dts/dra7.dtsi | 5 +++++
arch/arm/boot/dts/omap3.dtsi | 5 +++++
arch/arm/boot/dts/omap4.dtsi | 5 +++++
arch/arm/boot/dts/omap5.dtsi | 6 ++++++
6 files changed, 30 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 6d95d3d..4bbba26 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -58,6 +58,10 @@
275000 1125000
>;
voltage-tolerance = <2>; /* 2 percentage */
+
+ clocks = <&dpll_mpu_ck>;
+ clock-names = "cpu";
+
clock-latency = <300000>; /* From omap-cpufreq driver */
};
};
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index c6bd4d9..33798d9 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -33,6 +33,11 @@
compatible = "arm,cortex-a9";
device_type = "cpu";
reg = <0>;
+
+ clocks = <&dpll_mpu_ck>;
+ clock-names = "cpu";
+
+ clock-latency = <300000>; /* From omap-cpufreq driver */
};
};
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 1fd75aa..ce591e5 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -47,6 +47,11 @@
1000000 1060000
1176000 1160000
>;
+
+ clocks = <&dpll_mpu_ck>;
+ clock-names = "cpu";
+
+ clock-latency = <300000>; /* From omap-cpufreq driver */
};
cpu@1 {
device_type = "cpu";
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index a5fc83b..01f2b3b 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -35,6 +35,11 @@
compatible = "arm,cortex-a8";
device_type = "cpu";
reg = <0x0>;
+
+ clocks = <&dpll1_ck>;
+ clock-names = "cpu";
+
+ clock-latency = <300000>; /* From omap-cpufreq driver */
};
};
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index d3f8a6e..ce87996 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -36,6 +36,11 @@
device_type = "cpu";
next-level-cache = <&L2>;
reg = <0x0>;
+
+ clocks = <&dpll_mpu_ck>;
+ clock-names = "cpu";
+
+ clock-latency = <300000>; /* From omap-cpufreq driver */
};
cpu@1 {
compatible = "arm,cortex-a9";
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index a72813a..8bb4134 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -49,6 +49,12 @@
1000000 1060000
1500000 1250000
>;
+
+ clocks = <&dpll_mpu_ck>;
+ clock-names = "cpu";
+
+ clock-latency = <300000>; /* From omap-cpufreq driver */
+
/* cooling options */
cooling-min-level = <0>;
cooling-max-level = <2>;
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH v5 00/20] Armada 370/XP watchdog support
From: Ezequiel Garcia @ 2014-01-29 18:19 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-watchdog-u79uwXL29TY76Z2rM5mHXA
Cc: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, Gregory Clement,
Lior Amsalem, Tawfik Bayouk, Wim Van Sebroeck, Arnd Bergmann,
Daniel Lezcano, Guenter Roeck
In-Reply-To: <1390836440-12744-1-git-send-email-ezequiel.garcia-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
On Mon, Jan 27, 2014 at 12:27:00PM -0300, Ezequiel Garcia wrote:
> A new round, mostly fixing some minor nitpicks.
>
If anyone wants to give this a test, here's a public branch:
https://github.com/MISL-EBU-System-SW/mainline-public/tree/wdt_for_v3.14_v5
I'll be resending a new v6 adressing Russell's last comment about the
clock initialization, as soon as v3.14-rc1 is out.
Go, testers, go!
--
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC PATCH v2 09/14] mtd: nand: add sunxi NFC dt bindings doc
From: Boris BREZILLON @ 2014-01-29 18:30 UTC (permalink / raw)
To: Gupta, Pekon, Rob Herring,
Ezequiel Garcia (ezequiel.garcia-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org),
Brian Norris
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Russell King,
Arnd Bergmann, linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
dev-3kdeTeqwOZ9EV1b7eY7vFQ@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Jason Gunthorpe,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Rob Landley, Grant Likely, Maxime Ripard, David Woodhouse,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <20980858CB6D3A4BAE95CA194937D5E73EA6C01D-yXqyApvAXouIQmiDNMet8wC/G2K4zDHf@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2049 bytes --]
Le 29/01/2014 19:02, Gupta, Pekon a écrit :
> Dear Rob, and other DT maintainers,
>
>> From: Rob Herring
> [...]
>>> +- onfi,nand-timing-mode : mandatory if the chip does not support the ONFI
>>> + standard.
>> Add to generic nand binding.
>>
>>> +- allwinner,rb : shall contain the native Ready/Busy ids.
>>> + or
>>> +- rb-gpios : shall contain the gpios used as R/B pins.
>> Isn't allwinner,rb implied by a lack of rb-gpios property. Or no R/B
>> pin is an option? If so, don't you need some fixed time delay
>> properties like max erase time?
>>
>> rb-gpios could be added to the generic nand binding as well.
>>
> I do think this should go into generic nand binding, as this is controller specific.
> Some controllers have dedicated R/B pin (Ready/Busy) while others may use
> GPIO instead. It's the way a hardware controller is designed.
You meant "You do not think", right ?
If so, I think even if the retrieval and control of the GPIO is done is
each NAND
controller, we could at least use a common property name for all drivers
using
a GPIO to detect the R/B state.
>
> Request you to please consider Ack from MTD Maintainers 'at-least' for
> generic NAND DT bindings. There is already a discussion going in
> a separate thread for which is still not awaiting replies [1].
>
> [1] http://lists.infradead.org/pipermail/linux-mtd/2014-January/051625.html
I missed this thread, but I can definitely use the nand-ecc-strength and
nand-ecc-step-size instead of the one I defined (nand-ecc-level), as long
as there is a proper way to define these informations in the DT.
I'll let DT and MTD maintainers decide ;-).
Best Regards,
Boris
>
>
> with regards, pekon
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
[-- Attachment #2: Type: text/html, Size: 3581 bytes --]
^ permalink raw reply
* Re: [RFC PATCH v2 09/14] mtd: nand: add sunxi NFC dt bindings doc
From: Boris BREZILLON @ 2014-01-29 18:33 UTC (permalink / raw)
To: Gupta, Pekon, Rob Herring,
Ezequiel Garcia (ezequiel.garcia@free-electrons.com),
Brian Norris
Cc: devicetree@vger.kernel.org, Russell King, Arnd Bergmann,
linux-doc@vger.kernel.org, dev@linux-sunxi.org,
linux-kernel@vger.kernel.org, Jason Gunthorpe,
linux-mtd@lists.infradead.org, Rob Landley, Grant Likely,
Maxime Ripard, David Woodhouse,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20980858CB6D3A4BAE95CA194937D5E73EA6C01D@DBDE04.ent.ti.com>
Le 29/01/2014 19:02, Gupta, Pekon a écrit :
> Dear Rob, and other DT maintainers,
>
>> From: Rob Herring
> [...]
>>> +- onfi,nand-timing-mode : mandatory if the chip does not support the ONFI
>>> + standard.
>> Add to generic nand binding.
>>
>>> +- allwinner,rb : shall contain the native Ready/Busy ids.
>>> + or
>>> +- rb-gpios : shall contain the gpios used as R/B pins.
>> Isn't allwinner,rb implied by a lack of rb-gpios property. Or no R/B
>> pin is an option? If so, don't you need some fixed time delay
>> properties like max erase time?
>>
>> rb-gpios could be added to the generic nand binding as well.
>>
> I do think this should go into generic nand binding, as this is controller specific.
> Some controllers have dedicated R/B pin (Ready/Busy) while others may use
> GPIO instead. It's the way a hardware controller is designed.
You meant "You do not think", right ?
If so, I think even if the retrieval and control of the GPIO is done is
each NAND
controller, we could at least use a common property name for all drivers
using
a GPIO to detect the R/B state.
> Request you to please consider Ack from MTD Maintainers 'at-least' for
> generic NAND DT bindings. There is already a discussion going in
> a separate thread for which is still not awaiting replies [1].
>
> [1]http://lists.infradead.org/pipermail/linux-mtd/2014-January/051625.html
I missed this thread, but I can definitely use the nand-ecc-strength and
nand-ecc-step-size instead of the one I defined (nand-ecc-level), as long
as there is a proper way to define these informations in the DT.
I'll let DT and MTD maintainers decide ;-).
Best Regards,
Boris
>
> with regards, pekon
^ permalink raw reply
* RE: [RFC PATCH v2 09/14] mtd: nand: add sunxi NFC dt bindings doc
From: Gupta, Pekon @ 2014-01-29 18:36 UTC (permalink / raw)
To: Rob Herring, Boris BREZILLON,
Ezequiel Garcia (ezequiel.garcia@free-electrons.com),
Brian Norris
Cc: devicetree@vger.kernel.org, Russell King, Arnd Bergmann,
linux-doc@vger.kernel.org, dev@linux-sunxi.org,
linux-kernel@vger.kernel.org, Jason Gunthorpe,
linux-mtd@lists.infradead.org, Rob Landley, Grant Likely,
Maxime Ripard, David Woodhouse, Balbi, Felipe,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20980858CB6D3A4BAE95CA194937D5E73EA6C01D@DBDE04.ent.ti.com>
Dear Rob, and other DT maintainers,
(apologies, fixed typos in earlier mail)
>>From: Rob Herring
>[...]
>>> +- onfi,nand-timing-mode : mandatory if the chip does not support the ONFI
>>> + standard.
>>
>>Add to generic nand binding.
>>
>>> +- allwinner,rb : shall contain the native Ready/Busy ids.
>>> + or
>>> +- rb-gpios : shall contain the gpios used as R/B pins.
>>
>>Isn't allwinner,rb implied by a lack of rb-gpios property. Or no R/B
>>pin is an option? If so, don't you need some fixed time delay
>>properties like max erase time?
>>
>>rb-gpios could be added to the generic nand binding as well.
>>
I do _not_ think this should go into generic nand binding, as this is controller specific.
Some controllers have dedicated R/B pin (Ready/Busy) while others may use
GPIO instead. It's the way a hardware controller is designed.
Request you to please consider Ack from MTD Maintainers 'at-least' for
generic NAND DT bindings. There is already a discussion going in
a separate thread for which there are still no replies [1].
[1] http://lists.infradead.org/pipermail/linux-mtd/2014-January/051625.html
with regards, pekon
^ permalink raw reply
* Re: [RFC PATCH v2 03/14] of: mtd: add documentation for nand-ecc-level property
From: Boris BREZILLON @ 2014-01-29 18:39 UTC (permalink / raw)
To: Ezequiel Garcia
Cc: Maxime Ripard, Rob Landley, Russell King, David Woodhouse,
Grant Likely, Brian Norris, Jason Gunthorpe, Arnd Bergmann,
devicetree, linux-doc, dev, linux-kernel, linux-mtd,
linux-arm-kernel, Pekon Gupta
In-Reply-To: <20140129175331.GA27143@localhost>
Hello Ezequiel
Le 29/01/2014 18:53, Ezequiel Garcia a écrit :
> On Wed, Jan 29, 2014 at 03:34:13PM +0100, Boris BREZILLON wrote:
>> nand-ecc-level property statically defines NAND chip's ECC requirements.
>>
>> Signed-off-by: Boris BREZILLON <b.brezillon.dev@gmail.com>
>> ---
>> Documentation/devicetree/bindings/mtd/nand.txt | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/mtd/nand.txt b/Documentation/devicetree/bindings/mtd/nand.txt
>> index 03855c8..0c962296 100644
>> --- a/Documentation/devicetree/bindings/mtd/nand.txt
>> +++ b/Documentation/devicetree/bindings/mtd/nand.txt
>> @@ -3,5 +3,8 @@
>> - nand-ecc-mode : String, operation mode of the NAND ecc mode.
>> Supported values are: "none", "soft", "hw", "hw_syndrome", "hw_oob_first",
>> "soft_bch".
>> +- nand-ecc-level : Two cells property defining the ECC level requirements.
>> + The first cell represent the strength and the second cell the ECC block size.
>> + E.g. : nand-ecc-level = <4 512>; /* 4 bits / 512 bytes */
>> - nand-bus-width : 8 or 16 bus width if not present 8
>> - nand-on-flash-bbt: boolean to enable on flash bbt option if not present false
> Hm.. when was this proposal agreed?
Never, this is a proposal based on my needs, and this was not present in the
1st version of this series :-).
> It seems I've missed the
> discussion...
>
> FWIW, we've already proposed an equivalent one, but it received no
> feedback from the devicetree maintainers:
>
> http://comments.gmane.org/gmane.linux.drivers.devicetree/58764
>
> Maybe we can discuss about it now?
>
> nand-ecc-strength : integer ECC required strength.
> nand-ecc-size : integer step size associated to the ECC strength.
>
> vs.
>
> nand-ecc-level : Two cells property defining the ECC level requirements.
> The first cell represent the strength and the second cell the ECC block size.
> E.g. : nand-ecc-level = <4 512>; /* 4 bits / 512 bytes */
>
> It's really the same proposal but with a different format, right?
Yes it is.
> IMHO, the former is more human-readable, but other than that I see no
> difference.
As I already said to Pekon, I won't complain if my proposal is not chosen,
as long as there is a proper way to define these ECC requirements ;-).
Best Regards,
Boris
>
> Brian? DT-guys?
^ permalink raw reply
* Re: [RFC PATCH v2 08/14] mtd: nand: add sunxi NAND flash controller support
From: Ezequiel Garcia @ 2014-01-29 18:46 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Boris BREZILLON, devicetree-u79uwXL29TY76Z2rM5mHXA, Russell King,
Arnd Bergmann, linux-doc-u79uwXL29TY76Z2rM5mHXA,
dev-3kdeTeqwOZ9EV1b7eY7vFQ, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Rob Landley,
Grant Likely, Maxime Ripard, Brian Norris, David Woodhouse,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20140129175641.GF1427-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
On Wed, Jan 29, 2014 at 10:56:42AM -0700, Jason Gunthorpe wrote:
> On Wed, Jan 29, 2014 at 03:34:18PM +0100, Boris BREZILLON wrote:
>
> [..]
>
> > +static int sunxi_nand_chip_init(struct device *dev, struct sunxi_nfc *nfc,
> [..]
> > + ret = sunxi_nand_chip_init_timings(chip, np);
> > + if (ret)
> > + return ret;
> [..]
> > + ret = nand_scan_ident(mtd, nsels, NULL);
>
> This ordering looks a bit problematic, will onfi_get_async_timing_mode
> ever return anything other than ONFI_TIMING_MODE_UNKNOWN if it is
> called before nand_scan_ident ? What sets clk_rate to non-zero if there
> is no DT property?
>
> For a flow that uses onfi_get_async_timing_mode rather than DT the
> driver should set the interface to timing mode 0 (slowest) and then
> call nand_scan_ident, and then reset the interface to the detected
> timing mode.
>
Yes. And I believe this is a requirement from the ONFI 2.1 spec:
"""
4.1.4.3. Source Synchronous to Asynchronous
[..]
The host shall transition to the asynchronous data interface. Then the
host shall issue the Reset (FFh) command described in the previous paragraph
using asynchronous timing mode 0, thus the host transitions to the asynchronous
data interface prior to issuing the Reset (FFh). A device in any timing mode is
required to recognize a Reset (FFh) command issued in asynchronous timing
mode 0.
[..]
After CE# has been pulled high and then transitioned low again, the host
should issue a Set Features to select the appropriate asynchronous timing mode.
"""
--
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
^ permalink raw reply
* Re: [RFC PATCH v2 08/14] mtd: nand: add sunxi NAND flash controller support
From: Boris BREZILLON @ 2014-01-29 19:02 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Maxime Ripard, Rob Landley, Russell King, David Woodhouse,
Grant Likely, Brian Norris, Arnd Bergmann, devicetree, linux-doc,
linux-kernel, linux-arm-kernel, linux-mtd, dev
In-Reply-To: <20140129175641.GF1427@obsidianresearch.com>
Le 29/01/2014 18:56, Jason Gunthorpe a écrit :
> On Wed, Jan 29, 2014 at 03:34:18PM +0100, Boris BREZILLON wrote:
>
>> +static int sunxi_nand_chip_init_timings(struct sunxi_nand_chip *chip,
>> + struct device_node *np)
>> +{
>> + const struct nand_sdr_timings *timings;
>> + u32 min_clk_period = 0;
>> + int ret;
>> +
>> + ret = onfi_get_async_timing_mode(&chip->nand);
>> + if (ret == ONFI_TIMING_MODE_UNKNOWN) {
>> + ret = of_get_nand_onfi_timing_mode(np);
>> + if (ret < 0)
>> + return ret;
>> + }
> [..]
>
>> +static int sunxi_nand_chip_init(struct device *dev, struct sunxi_nfc *nfc,
> [..]
>> + ret = sunxi_nand_chip_init_timings(chip, np);
>> + if (ret)
>> + return ret;
> [..]
>> + ret = nand_scan_ident(mtd, nsels, NULL);
> This ordering looks a bit problematic, will onfi_get_async_timing_mode
> ever return anything other than ONFI_TIMING_MODE_UNKNOWN if it is
> called before nand_scan_ident ?
Indeed. I haven't tested this part as I don't own any board with an ONFI
compatible chip.
> What sets clk_rate to non-zero if there
> is no DT property?
It is set to 20 MHz by default, but it should definitely be set to the
rate fulfilling mode 0.
I'll fix this.
>
> For a flow that uses onfi_get_async_timing_mode rather than DT the
> driver should set the interface to timing mode 0 (slowest) and then
> call nand_scan_ident, and then reset the interface to the detected
> timing mode.
Absolutely.
>
> Maybe this should be implemented in the core code through a new
> callback (nand->set_timing_mode ?)
>
> Regards,
> Jason
^ permalink raw reply
* Re: [RFC PATCH v2 08/14] mtd: nand: add sunxi NAND flash controller support
From: Jason Gunthorpe @ 2014-01-29 19:10 UTC (permalink / raw)
To: Ezequiel Garcia
Cc: Boris BREZILLON, devicetree-u79uwXL29TY76Z2rM5mHXA, Russell King,
Arnd Bergmann, linux-doc-u79uwXL29TY76Z2rM5mHXA,
dev-3kdeTeqwOZ9EV1b7eY7vFQ, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Rob Landley,
Grant Likely, Maxime Ripard, Brian Norris, David Woodhouse,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20140129184619.GC27143@localhost>
On Wed, Jan 29, 2014 at 03:46:20PM -0300, Ezequiel Garcia wrote:
> After CE# has been pulled high and then transitioned low again, the host
> should issue a Set Features to select the appropriate asynchronous timing mode.
> """
Oh, I had forgot you should do a set feature too
Boris, I think the core core should handle this dance and the driver
should just implement a call back to change the timing mode on the
interface..
If I ever get a moment I can work on support for timing setting in the
mvebu driver, I have boards here with ONFI NAND..
Regards,
Jason
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v5] spi: rspi: Add DT support
From: Geert Uytterhoeven @ 2014-01-29 19:10 UTC (permalink / raw)
To: Mark Brown
Cc: devicetree@vger.kernel.org, linux-spi, Linux-sh list,
linux-kernel@vger.kernel.org, Geert Uytterhoeven
In-Reply-To: <20140129180009.GF22609@sirena.org.uk>
Hi Mark,
On Wed, Jan 29, 2014 at 7:00 PM, Mark Brown <broonie@kernel.org> wrote:
> On Tue, Jan 28, 2014 at 10:21:38AM +0100, Geert Uytterhoeven wrote:
>> From: Geert Uytterhoeven <geert+renesas@linux-m68k.org>
>
> Applied, thanks. I was expecting your last patch to be resubmitted as
Thanks!
> well?
As there were no code changes in v5 of "spi: rspi: Add DT support",
Patch "[14/14] spi: rspi: Add support for Quad and Dual SPI Transfers on QSPI"
should still apply fine.
Do you want me to resubmit?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus TorvaldsHi M
^ permalink raw reply
* Re: [PATCH 2/2] ARM: dts: OMAP3+: add clock nodes for CPU
From: Robert Nelson @ 2014-01-29 19:29 UTC (permalink / raw)
To: Nishanth Menon
Cc: Benoît Cousson, Tony Lindgren, Mike Turquette,
devicetree-u79uwXL29TY76Z2rM5mHXA, linux kernel, Tero Kristo,
linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <1391019557-22313-3-git-send-email-nm-l0cyMroinI0@public.gmane.org>
On Wed, Jan 29, 2014 at 12:19 PM, Nishanth Menon <nm-l0cyMroinI0@public.gmane.org> wrote:
> OMAP34xx, AM3517 and OMAP36xx platforms use dpll1 clock.
>
> OMAP443x, OMAP446x, OMAP447x, OMAP5, DRA7, AM43xx platforms use
> dpll_mpu clock.
>
> Latency used is the generic latency defined in omap-cpufreq
> driver.
>
> Signed-off-by: Nishanth Menon <nm-l0cyMroinI0@public.gmane.org>
Hi Nishanth,
After this patch, do you see any limitation to finally enabling 1Ghz
operation on the beagle-xm by default? Or are we still missing a
dependicy somewhere?
cpufreq stats: 300 MHz:98.64%, 600 MHz:0.04%, 800 MHz:0.09%, 1000
MHz:1.23% (11)
full cpufreq output: http://paste.debian.net/79073/
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index bb5dad0..b0e5863 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -16,9 +16,36 @@
cpus {
cpu@0 {
cpu0-supply = <&vcc>;
+ operating-points = <
+ /* kHz uV */
+ 300000 1012500
+ 600000 1200000
+ 800000 1325000
+ 1000000 1380000
+ >;
};
};
+ abb: regulator-abb {
+ compatible = "ti,abb-v1";
+ regulator-name = "abb";
+ #address-cell = <0>;
+ #size-cells = <0>;
+ reg = <0x483072f0 0x8>, <0x48306818 0x4>;
+ reg-names = "base-address", "int-address";
+ ti,tranxdone-status-mask = <0x4000000>;
+ clocks = <&dpll1_ck>;
+ ti,settling-time = <30>;
+ ti,clock-cycles = <8>;
+ ti,abb_info = <
+ /* uV ABB efuse rbb_m fbb_m
vset_m */
+ 1012500 0 0 0 0
0 /* Bypass */
+ 1200000 3 0 0 0
0 /* RBB mandatory */
+ 1320000 1 0 0 0
0 /* FBB mandatory */
+ 1380000 1 0 0 0 0
+ >;
+ };
+
memory {
device_type = "memory";
reg = <0x80000000 0x20000000>; /* 512 MB */
--
1.8.5.3
Regards,
--
Robert Nelson
http://www.rcn-ee.com/
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [RFC PATCH V2 1/4] pci: APM X-Gene PCIe controller driver
From: Arnd Bergmann @ 2014-01-29 19:36 UTC (permalink / raw)
To: Tanmay Inamdar
Cc: devicetree, linux-doc, linux-pci, Catalin Marinas, patches,
linux-kernel@vger.kernel.org, Jason Gunthorpe, Bjorn Helgaas,
Rob Herring, Rob Landley, Jon Masters, Grant Likely,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <CACoXjcnTnhWS-5yOgiHA5yVaBjdH1DVzmSsknEBJLB+CFR0EyA@mail.gmail.com>
On Monday 27 January 2014, Tanmay Inamdar wrote:
> On Sat, Jan 25, 2014 at 12:11 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Friday 24 January 2014 13:28:22 Tanmay Inamdar wrote:
> >> On Thu, Jan 16, 2014 at 5:10 PM, Tanmay Inamdar <tinamdar@apm.com> wrote:
> >> > On Wed, Jan 15, 2014 at 4:39 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> >> >> On Wednesday 15 January 2014, Tanmay Inamdar wrote:
> >> >>
> >> >> Maybe another msleep() in the loop? It seems weird to first do an
> >> >> unconditional sleep but then busy-wait for the result.
> >> >
> >> > ok.
> >>
> >> This loop can execute for maximum 4 msec. So putting msleep(1) won't
> >> get us much.
> >
> > 4 msec is still quite a long time for a busy loop that can be spent doing
> > useful work in another thread.
> >
>
> Right. If 'msleep(1)' is used, then 'checkpatch' throws a warning
> saying that it can actually sleep for 20ms in some cases. I will check
> if 'usleep_range' is useful here.
Sound good. This is really a false positive from checkpatch though,
with the timeout handling in place, everything's fine even with
msleep(1).
> >> >>
> >> >> Another general note: Your "compatible" strings are rather unspecific.
> >> >> Do you have a version number for this IP block? I suppose that it's related
> >> >> to one that has been used in other chips before, or will be used in future
> >> >> chips, if it's not actually licensed from some other company.
> >> >
> >> > I will have to check this.
> >> >
> >>
> >> We have decided to stick with current compatible string for now.
> >
> > Can you elaborate on your reasoning? Does this mean X-Gene is a one-off
> > product and you won't be doing any new chips based on the same hardware
> > components?
>
> The current convention is to key upon the family name - X-Gene. Future
> chips will also be a part of X-Gene family. Right now it is unclear if
> there are any obvious feature additions to be done in Linux PCIe
> driver. Until then same driver is expected to work as is in future
> chips.
This is not enough for me. Of course you hope that things keep working,
but experience shows that sometimes hardware has slight differences that
you need to work around later. It's better to always be specific and
at least as a secondary identifier list the exact model of the component,
or if that is not know, the model of the SoC. The driver can bind to
the most generic string, but in DT you should have a specific one as
well.
You could for instance have something like
compatible = "apm,xgene-1234w78-pcie", "thirdparty,pcie-1.23", "apm,xgene-pcie", "thirdparty,pcie";
as an example where you licensed the pcie block version 1.23 from a company
named thirdparty and integrated it into the xgene variant with product
code 1234w78.
Arnd
^ permalink raw reply
* Re: [PATCH v5 16/20] ARM: kirkwood: Add RSTOUT 'reg' entry to devicetree
From: Andrew Lunn @ 2014-01-29 20:15 UTC (permalink / raw)
To: Ezequiel Garcia
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-watchdog-u79uwXL29TY76Z2rM5mHXA, Jason Cooper, Andrew Lunn,
Sebastian Hesselbarth, Gregory Clement, Lior Amsalem,
Tawfik Bayouk, Wim Van Sebroeck, Arnd Bergmann, Daniel Lezcano,
Guenter Roeck
In-Reply-To: <1390836440-12744-17-git-send-email-ezequiel.garcia-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
On Mon, Jan 27, 2014 at 12:27:16PM -0300, Ezequiel Garcia wrote:
> In order to support multiplatform builds the watchdog devicetree binding
> was modified and now the 'reg' property is specified to need two
> entries. This commit adds the second entry as-per the new specification.
>
> Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Signed-off-by: Ezequiel Garcia <ezequiel.garcia-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Hi Ezequiel
I tested on Kirkwood, using the standard watchdog test cases. Works
great.
Tested-by: Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>
Thanks
Andrew
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v6 8/8] usb: ehci-exynos: Change to use phy provided by the generic phy framework
From: Alan Stern @ 2014-01-29 20:42 UTC (permalink / raw)
To: Kamil Debski
Cc: linux-kernel, linux-samsung-soc, linux-usb, devicetree,
kyungmin.park, kishon, t.figa, s.nawrocki, m.szyprowski,
gautam.vivek, mat.krawczuk, yulgon.kim, p.paneri, av.tikhomirov,
jg1.han, galak, matt.porter, tjakobi
In-Reply-To: <1391016574-25237-9-git-send-email-k.debski@samsung.com>
On Wed, 29 Jan 2014, Kamil Debski wrote:
> Change the phy provider used from the old one using the USB phy
> framework to a new one using the Generic phy framework.
>
> Signed-off-by: Kamil Debski <k.debski@samsung.com>
> ---
> .../devicetree/bindings/usb/exynos-usb.txt | 13 +++
> drivers/usb/host/ehci-exynos.c | 97 +++++++++++++-------
> 2 files changed, 76 insertions(+), 34 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/usb/exynos-usb.txt b/Documentation/devicetree/bindings/usb/exynos-usb.txt
> index d967ba1..25e199a 100644
> --- a/Documentation/devicetree/bindings/usb/exynos-usb.txt
> +++ b/Documentation/devicetree/bindings/usb/exynos-usb.txt
> @@ -12,6 +12,10 @@ Required properties:
> - interrupts: interrupt number to the cpu.
> - clocks: from common clock binding: handle to usb clock.
> - clock-names: from common clock binding: Shall be "usbhost".
> + - port: if in the SoC there are EHCI phys, they should be listed here.
> +One phy per port. Each port should have its reg entry with a consecutive
> +number. Also it should contain phys and phy-names entries specifying the
> +phy used by the port.
What is the reg entry number used for? As far as I can see, it isn't
used for anything. In which case, why have it at all?
> @@ -42,10 +42,10 @@
> static const char hcd_name[] = "ehci-exynos";
> static struct hc_driver __read_mostly exynos_ehci_hc_driver;
>
> +#define PHY_NUMBER 3
> struct exynos_ehci_hcd {
> struct clk *clk;
> - struct usb_phy *phy;
> - struct usb_otg *otg;
You have removed all the OTG stuff from the driver. This wasn't
mentioned in the patch description, and it has no connection with the
PHY work.
> + struct phy *phy[PHY_NUMBER];
> };
>
> #define to_exynos_ehci(hcd) (struct exynos_ehci_hcd *)(hcd_to_ehci(hcd)->priv)
> @@ -69,13 +69,43 @@ static void exynos_setup_vbus_gpio(struct platform_device *pdev)
> dev_err(dev, "can't request ehci vbus gpio %d", gpio);
> }
>
> +static int exynos_phys_on(struct phy *p[])
> +{
> + int i;
> + int ret = 0;
> +
> + for (i = 0; ret == 0 && i < PHY_NUMBER; i++)
> + if (p[i])
> + ret = phy_power_on(p[i]);
> + if (ret)
> + for (i--; i > 0; i--)
> + if (p[i])
> + phy_power_off(p[i]);
This loop runs while i > 0. Therefore you will never turn off the
power to p[0].
> @@ -102,14 +132,26 @@ static int exynos_ehci_probe(struct platform_device *pdev)
> "samsung,exynos5440-ehci"))
> goto skip_phy;
>
> - phy = devm_usb_get_phy(&pdev->dev, USB_PHY_TYPE_USB2);
> - if (IS_ERR(phy)) {
> - usb_put_hcd(hcd);
You omitted this line from the new error returns below.
> - dev_warn(&pdev->dev, "no platform data or transceiver defined\n");
> - return -EPROBE_DEFER;
> - } else {
> - exynos_ehci->phy = phy;
> - exynos_ehci->otg = phy->otg;
> + for_each_available_child_of_node(pdev->dev.of_node, child) {
> + err = of_property_read_u32(child, "reg", &phy_number);
> + if (err) {
> + dev_err(&pdev->dev, "Failed to parse device tree\n");
> + of_node_put(child);
> + return err;
Here, for example. Wouldn't it be better to goto fail_clk?
Alan Stern
^ permalink raw reply
* Re: [PATCH v6 3/8] dts: Add usb2phy to Exynos 4
From: Olof Johansson @ 2014-01-29 20:50 UTC (permalink / raw)
To: Kamil Debski
Cc: linux-kernel@vger.kernel.org, linux-samsung-soc@vger.kernel.org,
linux-usb@vger.kernel.org, devicetree@vger.kernel.org,
Kyungmin Park, Kishon Vijay Abraham I, Tomasz Figa,
Sylwester Nawrocki, Marek Szyprowski, Vivek Gautam, mat.krawczuk,
yulgon.kim, p.paneri, av.tikhomirov, Jingoo Han, Kumar Gala,
Matt Porter, tjakobi, Alan Stern
In-Reply-To: <1391016574-25237-4-git-send-email-k.debski@samsung.com>
On Wed, Jan 29, 2014 at 9:29 AM, Kamil Debski <k.debski@samsung.com> wrote:
> Add support to PHY of USB2 of the Exynos 4 SoC.
>
> Signed-off-by: Kamil Debski <k.debski@samsung.com>
> ---
> .../devicetree/bindings/arm/samsung/pmu.txt | 2 ++
> arch/arm/boot/dts/exynos4.dtsi | 31 ++++++++++++++++++++
> arch/arm/boot/dts/exynos4210.dtsi | 17 +++++++++++
> arch/arm/boot/dts/exynos4x12.dtsi | 17 +++++++++++
> 4 files changed, 67 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/samsung/pmu.txt b/Documentation/devicetree/bindings/arm/samsung/pmu.txt
> index 307e727..a76f91d 100644
> --- a/Documentation/devicetree/bindings/arm/samsung/pmu.txt
> +++ b/Documentation/devicetree/bindings/arm/samsung/pmu.txt
> @@ -3,6 +3,8 @@ SAMSUNG Exynos SoC series PMU Registers
> Properties:
> - name : should be 'syscon';
> - compatible : should contain two values. First value must be one from following list:
> + - "samsung,exynos4210-pmu" - for Exynos4210 SoC,
> + - "samsung,exynos4x12-pmu" - for Exynos4212 SoC,
> - "samsung,exynos5250-pmu" - for Exynos5250 SoC,
> - "samsung,exynos5420-pmu" - for Exynos5420 SoC.
> second value must be always "syscon".
This and other PMU related bindings/dts changes should probably go in
separate patch(es) instead of being snuck in with USB changes.
-Olof
^ permalink raw reply
* Re: [PATCH v6 8/8] usb: ehci-exynos: Change to use phy provided by the generic phy framework
From: Olof Johansson @ 2014-01-29 20:55 UTC (permalink / raw)
To: Kamil Debski
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Kyungmin Park,
Kishon Vijay Abraham I, Tomasz Figa, Sylwester Nawrocki,
Marek Szyprowski, Vivek Gautam,
mat.krawczuk-Re5JQEeQqe8AvxtiuMwx3w,
yulgon.kim-Sze3O3UU22JBDgjK7y7TUQ,
p.paneri-Sze3O3UU22JBDgjK7y7TUQ,
av.tikhomirov-Sze3O3UU22JBDgjK7y7TUQ, Jingoo Han, Kumar Gala,
Matt Porter, tjakobi-o02PS0xoJP9W0yFyLvAVXMxlOr/tl8fh, Alan Stern
In-Reply-To: <1391016574-25237-9-git-send-email-k.debski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
Hi,
On Wed, Jan 29, 2014 at 9:29 AM, Kamil Debski <k.debski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org> wrote:
> Change the phy provider used from the old one using the USB phy
> framework to a new one using the Generic phy framework.
>
> Signed-off-by: Kamil Debski <k.debski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
> ---
> .../devicetree/bindings/usb/exynos-usb.txt | 13 +++
> drivers/usb/host/ehci-exynos.c | 97 +++++++++++++-------
> 2 files changed, 76 insertions(+), 34 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/usb/exynos-usb.txt b/Documentation/devicetree/bindings/usb/exynos-usb.txt
> index d967ba1..25e199a 100644
> --- a/Documentation/devicetree/bindings/usb/exynos-usb.txt
> +++ b/Documentation/devicetree/bindings/usb/exynos-usb.txt
> @@ -12,6 +12,10 @@ Required properties:
> - interrupts: interrupt number to the cpu.
> - clocks: from common clock binding: handle to usb clock.
> - clock-names: from common clock binding: Shall be "usbhost".
> + - port: if in the SoC there are EHCI phys, they should be listed here.
> +One phy per port. Each port should have its reg entry with a consecutive
> +number. Also it should contain phys and phy-names entries specifying the
> +phy used by the port.
>
> Optional properties:
> - samsung,vbus-gpio: if present, specifies the GPIO that
> @@ -27,6 +31,15 @@ Example:
>
> clocks = <&clock 285>;
> clock-names = "usbhost";
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> + port@0 {
> + reg = <0>;
> + phys = <&usb2phy 1>;
> + phy-names = "host";
> + status = "disabled";
> + };
> };
>
> OHCI
[...]
> @@ -102,14 +132,26 @@ static int exynos_ehci_probe(struct platform_device *pdev)
> "samsung,exynos5440-ehci"))
> goto skip_phy;
>
> - phy = devm_usb_get_phy(&pdev->dev, USB_PHY_TYPE_USB2);
> - if (IS_ERR(phy)) {
> - usb_put_hcd(hcd);
> - dev_warn(&pdev->dev, "no platform data or transceiver defined\n");
> - return -EPROBE_DEFER;
> - } else {
> - exynos_ehci->phy = phy;
> - exynos_ehci->otg = phy->otg;
> + for_each_available_child_of_node(pdev->dev.of_node, child) {
> + err = of_property_read_u32(child, "reg", &phy_number);
> + if (err) {
> + dev_err(&pdev->dev, "Failed to parse device tree\n");
> + of_node_put(child);
> + return err;
> + }
> + if (phy_number >= PHY_NUMBER) {
> + dev_err(&pdev->dev, "Failed to parse device tree - number out of range\n");
> + of_node_put(child);
> + return -EINVAL;
> + }
> + phy = devm_of_phy_get(&pdev->dev, child, 0);
> + of_node_put(child);
> + if (IS_ERR(phy)) {
> + dev_err(&pdev->dev, "Failed to get phy number %d",
> + phy_number);
> + return PTR_ERR(phy);
> + }
> + exynos_ehci->phy[phy_number] = phy;
this looks like it is now breaking older device trees, where ports
might not be described. Since device tree interfaces need to be
backwards compatible, you still need to handle the old case of not
having ports described.
There are two ways of doing this:
1. Fall back to the old behavior if there are no ports
2. Use a new compatible value for the new model with port subnodes,
and if the old compatible value is used, then fall back to the old
behavior.
I'm guessing (1) might be easiest since you can check for the presence
of #address-cells to tell if this is just an old style node, or if
it's a new-style node without any ports below it.
-Olof
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 0/5] IIO pulse capture support for TI ECAP
From: Matt Porter @ 2014-01-29 20:59 UTC (permalink / raw)
To: Jonathan Cameron, Grant Likely, Rob Herring, Benoit Cousson,
Tony Lindgren, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Thierry Reding
Cc: linux-iio-u79uwXL29TY76Z2rM5mHXA, Linux Kernel Mailing List,
Devicetree List, linux-pwm-u79uwXL29TY76Z2rM5mHXA,
Linux OMAP List, Linux ARM Kernel List, Linaro Patches
This series adds support for PWM capture devices within IIO and
adds a TI ECAP IIO driver.
PWM capture devices are supported using a new IIO "pulse" channel type.
The IIO ECAP driver implements interrupt driven triggered buffer capture
only as raw sample reads are not applicable to this hardware.
Initially, the driver supports a single pulse width measurement with
configurable polarity. The ECAP hardware can support measurement of a
complete period and duty cycle but this is not yet implemented.
Matt Porter (5):
iio: add support for pulse width capture devices
iio: pulse: add TI ECAP driver
iio: enable selection and build of pulse drivers
pwm: enable TI PWMSS if the IIO tiecap driver is selected
ARM: dts: AM33XX: Add ecap interrupt properties
arch/arm/boot/dts/am33xx.dtsi | 6 +
drivers/iio/Kconfig | 1 +
drivers/iio/Makefile | 1 +
drivers/iio/industrialio-core.c | 1 +
drivers/iio/pulse/Kconfig | 20 ++
drivers/iio/pulse/Makefile | 6 +
drivers/iio/pulse/tiecap.c | 493 ++++++++++++++++++++++++++++++++++++++++
drivers/pwm/Kconfig | 2 +-
include/linux/iio/types.h | 1 +
9 files changed, 530 insertions(+), 1 deletion(-)
create mode 100644 drivers/iio/pulse/Kconfig
create mode 100644 drivers/iio/pulse/Makefile
create mode 100644 drivers/iio/pulse/tiecap.c
--
1.8.4
^ permalink raw reply
* [PATCH 1/5] iio: add support for pulse width capture devices
From: Matt Porter @ 2014-01-29 20:59 UTC (permalink / raw)
To: Jonathan Cameron, Grant Likely, Rob Herring, Benoit Cousson,
Tony Lindgren, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Thierry Reding
Cc: linux-iio, Linux Kernel Mailing List, Devicetree List, linux-pwm,
Linux OMAP List, Linux ARM Kernel List, Linaro Patches
In-Reply-To: <1391029199-3670-1-git-send-email-mporter@linaro.org>
Add a channel type to support pulse width capture devices.
These devices capture the timing of a PWM signal based on a
configurable trigger
Signed-off-by: Matt Porter <mporter@linaro.org>
---
drivers/iio/industrialio-core.c | 1 +
include/linux/iio/types.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
index acc911a..6ea0cf8 100644
--- a/drivers/iio/industrialio-core.c
+++ b/drivers/iio/industrialio-core.c
@@ -70,6 +70,7 @@ static const char * const iio_chan_type_name_spec[] = {
[IIO_CCT] = "cct",
[IIO_PRESSURE] = "pressure",
[IIO_HUMIDITYRELATIVE] = "humidityrelative",
+ [IIO_PULSE] = "pulse",
};
static const char * const iio_modifier_names[] = {
diff --git a/include/linux/iio/types.h b/include/linux/iio/types.h
index 084d882..4fa8840 100644
--- a/include/linux/iio/types.h
+++ b/include/linux/iio/types.h
@@ -30,6 +30,7 @@ enum iio_chan_type {
IIO_CCT,
IIO_PRESSURE,
IIO_HUMIDITYRELATIVE,
+ IIO_PULSE,
};
enum iio_modifier {
--
1.8.4
^ permalink raw reply related
* [PATCH 2/5] iio: pulse: add TI ECAP driver
From: Matt Porter @ 2014-01-29 20:59 UTC (permalink / raw)
To: Jonathan Cameron, Grant Likely, Rob Herring, Benoit Cousson,
Tony Lindgren, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Thierry Reding
Cc: linux-iio, Linux Kernel Mailing List, Devicetree List, linux-pwm,
Linux OMAP List, Linux ARM Kernel List, Linaro Patches
In-Reply-To: <1391029199-3670-1-git-send-email-mporter@linaro.org>
Adds support for capturing PWM signals using the TI ECAP peripheral.
This driver supports triggered buffer capture of pulses on multiple
ECAP instances. In addition, the driver supports configurable polarity
of the signal to be captured.
Signed-off-by: Matt Porter <mporter@linaro.org>
---
drivers/iio/pulse/Kconfig | 20 ++
drivers/iio/pulse/Makefile | 6 +
drivers/iio/pulse/tiecap.c | 493 +++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 519 insertions(+)
create mode 100644 drivers/iio/pulse/Kconfig
create mode 100644 drivers/iio/pulse/Makefile
create mode 100644 drivers/iio/pulse/tiecap.c
diff --git a/drivers/iio/pulse/Kconfig b/drivers/iio/pulse/Kconfig
new file mode 100644
index 0000000..9864d4b
--- /dev/null
+++ b/drivers/iio/pulse/Kconfig
@@ -0,0 +1,20 @@
+#
+# Pulse Capture Devices
+#
+# When adding new entries keep the list in alphabetical order
+
+menu "Pulse Capture Devices"
+
+config IIO_TIECAP
+ tristate "TI ECAP Pulse Capture"
+ depends on SOC_AM33XX
+ select IIO_BUFFER
+ select IIO_TRIGGERED_BUFFER
+ help
+ If you say yes here you get support for the TI ECAP peripheral
+ in pulse capture mode.
+
+ This driver can also be built as a module. If so, the module
+ will be called tiecap
+
+endmenu
diff --git a/drivers/iio/pulse/Makefile b/drivers/iio/pulse/Makefile
new file mode 100644
index 0000000..94d4b00
--- /dev/null
+++ b/drivers/iio/pulse/Makefile
@@ -0,0 +1,6 @@
+#
+# Makefile for IIO PWM Capture Devices
+#
+
+# When adding new entries keep the list in alphabetical order
+obj-$(CONFIG_IIO_TIECAP) += tiecap.o
diff --git a/drivers/iio/pulse/tiecap.c b/drivers/iio/pulse/tiecap.c
new file mode 100644
index 0000000..8e2b3a0
--- /dev/null
+++ b/drivers/iio/pulse/tiecap.c
@@ -0,0 +1,493 @@
+/*
+ * ECAP IIO pulse capture driver
+ *
+ * Copyright (C) 2014 Linaro Limited
+ * Author: Matt Porter <mporter@linaro.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include <linux/clk.h>
+#include <linux/err.h>
+#include <linux/iio/buffer.h>
+#include <linux/iio/iio.h>
+#include <linux/iio/sysfs.h>
+#include <linux/iio/trigger.h>
+#include <linux/iio/trigger_consumer.h>
+#include <linux/iio/triggered_buffer.h>
+#include <linux/io.h>
+#include <linux/interrupt.h>
+#include <linux/irq.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/pm_runtime.h>
+
+#include "../../pwm/pwm-tipwmss.h"
+
+/* ECAP regs and bits */
+#define CAP1 0x08
+#define CAP2 0x0c
+#define ECCTL1 0x28
+#define ECCTL1_RUN_FREE BIT(15)
+#define ECCTL1_CAPLDEN BIT(8)
+#define ECCTL1_CAP2POL BIT(2)
+#define ECCTL1_CTRRST1 BIT(1)
+#define ECCTL1_CAP1POL BIT(0)
+#define ECCTL2 0x2a
+#define ECCTL2_SYNCO_SEL_DIS BIT(7)
+#define ECCTL2_TSCTR_FREERUN BIT(4)
+#define ECCTL2_REARM BIT(3)
+#define ECCTL2_STOP_WRAP_2 BIT(1)
+#define ECEINT 0x2c
+#define ECFLG 0x2e
+#define ECCLR 0x30
+#define ECINT_CTRCMP BIT(7)
+#define ECINT_CTRPRD BIT(6)
+#define ECINT_CTROVF BIT(5)
+#define ECINT_CEVT4 BIT(4)
+#define ECINT_CEVT3 BIT(3)
+#define ECINT_CEVT2 BIT(2)
+#define ECINT_CEVT1 BIT(1)
+#define ECINT_ALL (ECINT_CTRCMP | \
+ ECINT_CTRPRD | \
+ ECINT_CTROVF | \
+ ECINT_CEVT4 | \
+ ECINT_CEVT3 | \
+ ECINT_CEVT2 | \
+ ECINT_CEVT1)
+
+/* ECAP driver flags */
+#define ECAP_POLARITY_HIGH BIT(1)
+#define ECAP_ENABLED BIT(0)
+
+struct ecap_context {
+ u32 cap1;
+ u32 cap2;
+ u16 ecctl1;
+ u16 ecctl2;
+ u16 eceint;
+};
+
+struct ecap_state {
+ unsigned long flags;
+ unsigned int clk_rate;
+ void __iomem *regs;
+ u32 *buf;
+ struct ecap_context ctx;
+};
+
+#define dev_to_ecap_state(d) iio_priv(dev_to_iio_dev(d))
+
+static const struct iio_chan_spec ecap_channels[] = {
+ {
+ .type = IIO_PULSE,
+ .channel = 0,
+ .info_mask_separate =
+ BIT(IIO_CHAN_INFO_RAW) | BIT(IIO_CHAN_INFO_SCALE),
+ .scan_index = 0,
+ .scan_type = {
+ .sign = 'u',
+ .realbits = 32,
+ .storagebits = 32,
+ .endianness = IIO_LE,
+ },
+ .modified = 0,
+ },
+ IIO_CHAN_SOFT_TIMESTAMP(1)
+};
+
+static ssize_t ecap_attr_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct ecap_state *state = dev_to_ecap_state(dev);
+
+ return sprintf(buf, "%d\n",
+ test_bit(ECAP_POLARITY_HIGH, &state->flags));
+}
+
+static ssize_t ecap_attr_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf,
+ size_t len)
+{
+ int ret;
+ bool val;
+ struct ecap_state *state = dev_to_ecap_state(dev);
+
+ if (test_bit(ECAP_ENABLED, &state->flags))
+ return -EINVAL;
+
+ ret = strtobool(buf, &val);
+ if (ret)
+ return ret;
+
+ if (val)
+ set_bit(ECAP_POLARITY_HIGH, &state->flags);
+ else
+ clear_bit(ECAP_POLARITY_HIGH, &state->flags);
+
+ return len;
+}
+
+static IIO_DEVICE_ATTR(in_pulse_polarity, S_IRUGO | S_IWUSR,
+ ecap_attr_show, ecap_attr_store, 0);
+
+static struct attribute *ecap_attributes[] = {
+ &iio_dev_attr_in_pulse_polarity.dev_attr.attr,
+ NULL,
+};
+
+static struct attribute_group ecap_attribute_group = {
+ .attrs = ecap_attributes,
+};
+
+static int ecap_read_raw(struct iio_dev *idev,
+ struct iio_chan_spec const *ch, int *val,
+ int *val2, long mask)
+{
+ struct ecap_state *state = iio_priv(idev);
+
+ switch (mask) {
+ case IIO_CHAN_INFO_RAW:
+ /*
+ * Always return 0 as a pulse width sample
+ * is only valid in a triggered condition
+ */
+ *val = 0;
+ *val2 = 0;
+ return IIO_VAL_INT;
+ case IIO_CHAN_INFO_SCALE:
+ *val = 0;
+ *val2 = NSEC_PER_SEC / state->clk_rate;
+ return IIO_VAL_INT_PLUS_NANO;
+ default:
+ return -EINVAL;
+ }
+}
+
+static const struct iio_info ecap_info = {
+ .driver_module = THIS_MODULE,
+ .attrs = &ecap_attribute_group,
+ .read_raw = &ecap_read_raw,
+};
+
+static irqreturn_t ecap_trigger_handler(int irq, void *private)
+{
+ struct iio_poll_func *pf = private;
+ struct iio_dev *idev = pf->indio_dev;
+ struct ecap_state *state = iio_priv(idev);
+
+ /* Read pulse counter value */
+ *state->buf = readl(state->regs + CAP2);
+
+ iio_push_to_buffers_with_timestamp(idev, state->buf, iio_get_time_ns());
+
+ iio_trigger_notify_done(idev->trig);
+
+ return IRQ_HANDLED;
+};
+
+
+static const struct iio_trigger_ops iio_interrupt_trigger_ops = {
+ .owner = THIS_MODULE,
+};
+
+static irqreturn_t ecap_interrupt_handler(int irq, void *private)
+{
+ struct iio_dev *idev = private;
+ struct ecap_state *state = iio_priv(idev);
+ u16 ints;
+
+ iio_trigger_poll(idev->trig, 0);
+
+ /* Clear CAP2 interrupt */
+ ints = readw(state->regs + ECFLG);
+ if (ints & ECINT_CEVT2)
+ writew(ECINT_CEVT2, state->regs + ECCLR);
+ else
+ dev_warn(&idev->dev, "unhandled interrupt flagged: %04x\n",
+ ints);
+
+ return IRQ_HANDLED;
+}
+
+static int ecap_buffer_predisable(struct iio_dev *idev)
+{
+ struct ecap_state *state = iio_priv(idev);
+ int ret = 0;
+ u16 ecctl2;
+
+ /* Stop capture */
+ clear_bit(ECAP_ENABLED, &state->flags);
+ ecctl2 = readw(state->regs + ECCTL2) & ~ECCTL2_TSCTR_FREERUN;
+ writew(ecctl2, state->regs + ECCTL2);
+
+ /* Disable and clear all interrupts */
+ writew(0, state->regs + ECEINT);
+ writew(ECINT_ALL, state->regs + ECCLR);
+
+ ret = iio_triggered_buffer_predisable(idev);
+
+ pm_runtime_put_sync(idev->dev.parent);
+
+ return ret;
+}
+
+static int ecap_buffer_postenable(struct iio_dev *idev)
+{
+ struct ecap_state *state = iio_priv(idev);
+ int ret = 0;
+ u16 ecctl1, ecctl2;
+
+ pm_runtime_get_sync(idev->dev.parent);
+
+ /* Configure pulse polarity */
+ ecctl1 = readw(state->regs + ECCTL1);
+ if (test_bit(ECAP_POLARITY_HIGH, &state->flags)) {
+ /* CAP1 rising, CAP2 falling */
+ ecctl1 |= ECCTL1_CAP2POL;
+ ecctl1 &= ~ECCTL1_CAP1POL;
+ } else {
+ /* CAP1 falling, CAP2 rising */
+ ecctl1 &= ~ECCTL1_CAP2POL;
+ ecctl1 |= ECCTL1_CAP1POL;
+ }
+ writew(ecctl1, state->regs + ECCTL1);
+
+ /* Enable CAP2 interrupt */
+ writew(ECINT_CEVT2, state->regs + ECEINT);
+
+ /* Enable capture */
+ ecctl2 = readw(state->regs + ECCTL2);
+ ecctl2 |= ECCTL2_TSCTR_FREERUN | ECCTL2_REARM;
+ writew(ecctl2, state->regs + ECCTL2);
+ set_bit(ECAP_ENABLED, &state->flags);
+
+ ret = iio_triggered_buffer_postenable(idev);
+
+ return ret;
+}
+
+static const struct iio_buffer_setup_ops ecap_buffer_setup_ops = {
+ .postenable = &ecap_buffer_postenable,
+ .predisable = &ecap_buffer_predisable,
+};
+
+static void ecap_init_hw(struct iio_dev *idev)
+{
+ struct ecap_state *state = iio_priv(idev);
+
+ clear_bit(ECAP_ENABLED, &state->flags);
+ set_bit(ECAP_POLARITY_HIGH, &state->flags);
+
+ writew(ECCTL1_RUN_FREE | ECCTL1_CAPLDEN |
+ ECCTL1_CAP2POL | ECCTL1_CTRRST1,
+ state->regs + ECCTL1);
+
+ writew(ECCTL2_SYNCO_SEL_DIS | ECCTL2_STOP_WRAP_2,
+ state->regs + ECCTL2);
+}
+
+static const struct of_device_id ecap_of_ids[] = {
+ { .compatible = "ti,am33xx-ecap" },
+ { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, ecap_of_ids);
+
+static int ecap_probe(struct platform_device *pdev)
+{
+ int irq, ret;
+ struct iio_dev *idev;
+ struct ecap_state *state;
+ struct resource *r;
+ struct clk *clk;
+ struct iio_trigger *trig;
+ u16 status;
+
+ idev = devm_iio_device_alloc(&pdev->dev, sizeof(struct ecap_state));
+ if (!idev)
+ return -ENOMEM;
+
+ state = iio_priv(idev);
+
+ clk = devm_clk_get(&pdev->dev, "fck");
+ if (IS_ERR(clk)) {
+ dev_err(&pdev->dev, "failed to get clock\n");
+ return PTR_ERR(clk);
+ }
+
+ state->clk_rate = clk_get_rate(clk);
+ if (!state->clk_rate) {
+ dev_err(&pdev->dev, "failed to get clock rate\n");
+ return -EINVAL;
+ }
+
+ platform_set_drvdata(pdev, idev);
+
+ idev->dev.parent = &pdev->dev;
+ idev->name = dev_name(&pdev->dev);
+ idev->modes = INDIO_DIRECT_MODE;
+ idev->info = &ecap_info;
+ idev->channels = ecap_channels;
+ /* One h/w capture and one s/w timestamp channel per instance */
+ idev->num_channels = 2;
+
+ trig = devm_iio_trigger_alloc(&pdev->dev, "%s-dev%d",
+ idev->name, idev->id);
+ if (!trig)
+ return -ENOMEM;
+ trig->dev.parent = idev->dev.parent;
+ iio_trigger_set_drvdata(trig, idev);
+ trig->ops = &iio_interrupt_trigger_ops;
+
+ ret = iio_trigger_register(trig);
+ if (ret) {
+ dev_err(&pdev->dev, "failed to register trigger\n");
+ return ret;
+ }
+
+ ret = iio_triggered_buffer_setup(idev, NULL,
+ &ecap_trigger_handler,
+ &ecap_buffer_setup_ops);
+ if (ret)
+ return ret;
+
+ irq = platform_get_irq(pdev, 0);
+ if (irq < 0) {
+ dev_err(&pdev->dev, "no irq is specified\n");
+ return irq;
+ }
+ ret = devm_request_irq(&pdev->dev, irq,
+ &ecap_interrupt_handler,
+ 0, dev_name(&pdev->dev), idev);
+ if (ret) {
+ dev_err(&pdev->dev, "unable to request irq\n");
+ goto uninit_buffer;
+ }
+
+ r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ state->regs = devm_ioremap_resource(&pdev->dev, r);
+ if (IS_ERR(state->regs)) {
+ dev_err(&pdev->dev, "unable to remap registers\n");
+ ret = PTR_ERR(state->regs);
+ goto uninit_buffer;
+ };
+
+ ret = iio_device_register(idev);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "unable to register device\n");
+ goto uninit_buffer;
+ }
+
+ state->buf = devm_kzalloc(&idev->dev, idev->scan_bytes, GFP_KERNEL);
+ if (!state->buf) {
+ ret = -ENOMEM;
+ goto uninit_buffer;
+ }
+
+ pm_runtime_enable(&pdev->dev);
+ pm_runtime_get_sync(&pdev->dev);
+
+ status = pwmss_submodule_state_change(pdev->dev.parent,
+ PWMSS_ECAPCLK_EN);
+ if (!(status & PWMSS_ECAPCLK_EN_ACK)) {
+ dev_err(&pdev->dev, "failed to enable PWMSS config space clock\n");
+ ret = -EINVAL;
+ goto pwmss_clk_failure;
+ }
+
+ ecap_init_hw(idev);
+
+ pm_runtime_put_sync(&pdev->dev);
+
+ return 0;
+
+pwmss_clk_failure:
+ pm_runtime_put_sync(&pdev->dev);
+ pm_runtime_disable(&pdev->dev);
+ iio_device_unregister(idev);
+
+uninit_buffer:
+ iio_triggered_buffer_cleanup(idev);
+
+ return ret;
+}
+
+static int ecap_remove(struct platform_device *pdev)
+{
+ struct iio_dev *idev = platform_get_drvdata(pdev);
+
+ pm_runtime_get_sync(&pdev->dev);
+
+ pwmss_submodule_state_change(pdev->dev.parent, PWMSS_ECAPCLK_STOP_REQ);
+
+ pm_runtime_put_sync(&pdev->dev);
+ pm_runtime_disable(&pdev->dev);
+
+ iio_device_unregister(idev);
+
+ return 0;
+}
+
+#ifdef CONFIG_PM_SLEEP
+static int ecap_suspend(struct device *dev)
+{
+ struct ecap_state *state = dev_to_ecap_state(dev);
+
+ pm_runtime_get_sync(dev);
+ state->ctx.cap1 = readl(state->regs + CAP1);
+ state->ctx.cap2 = readl(state->regs + CAP2);
+ state->ctx.eceint = readw(state->regs + ECEINT);
+ state->ctx.ecctl1 = readw(state->regs + ECCTL1);
+ state->ctx.ecctl2 = readw(state->regs + ECCTL2);
+ pm_runtime_put_sync(dev);
+
+ /* If capture was active, disable ECAP */
+ if (test_bit(ECAP_ENABLED, &state->flags))
+ pm_runtime_put_sync(dev);
+
+ return 0;
+}
+
+static int ecap_resume(struct device *dev)
+{
+ struct ecap_state *state = dev_to_ecap_state(dev);
+
+ /* If capture was active, enable ECAP */
+ if (test_bit(ECAP_ENABLED, &state->flags))
+ pm_runtime_get_sync(dev);
+
+ pm_runtime_get_sync(dev);
+ writel(state->ctx.cap1, state->regs + CAP1);
+ writel(state->ctx.cap2, state->regs + CAP2);
+ writew(state->ctx.eceint, state->regs + ECEINT);
+ writew(state->ctx.ecctl1, state->regs + ECCTL1);
+ writew(state->ctx.ecctl2, state->regs + ECCTL2);
+ pm_runtime_put_sync(dev);
+
+ return 0;
+}
+#endif
+
+static SIMPLE_DEV_PM_OPS(ecap_pm_ops, ecap_suspend, ecap_resume);
+
+static struct platform_driver ecap_iio_driver = {
+ .driver = {
+ .name = "ecap",
+ .owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(ecap_of_ids),
+ .pm = &ecap_pm_ops,
+ },
+ .probe = ecap_probe,
+ .remove = ecap_remove,
+};
+
+module_platform_driver(ecap_iio_driver);
+
+MODULE_DESCRIPTION("ECAP IIO pulse capture driver");
+MODULE_AUTHOR("Matt Porter <mporter@linaro.org>");
+MODULE_LICENSE("GPL");
--
1.8.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox