Re: [PATCH v3] mfd: da9052: add device-tree support for i2c driver
On Sat, Apr 14, 2012 at 09:39:06PM +0800, Ying-Chun Liu (PaulLiu) wrote:
> From: "Ying-Chun Liu (PaulLiu)"
>
> This patch adds device-tree support for dialog MFD and the binding
> documentations.
>
> Signed-off-by: Ying-Chun Liu (PaulLiu)
> Cc: Samuel Ortiz
> Cc: Mark Brown
> Cc: Shawn Guo
> Cc: Ashish Jangam
> ---
> .../devicetree/bindings/mfd/da9052-i2c.txt | 60
>
> drivers/mfd/da9052-i2c.c | 51 ++---
> 2 files changed, 103 insertions(+), 8 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/mfd/da9052-i2c.txt
>
> diff --git a/Documentation/devicetree/bindings/mfd/da9052-i2c.txt
> b/Documentation/devicetree/bindings/mfd/da9052-i2c.txt
> new file mode 100644
> index 000..1857f4a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/da9052-i2c.txt
> @@ -0,0 +1,60 @@
> +* Dialog DA9052/53 Power Management Integrated Circuit (PMIC)
> +
> +Required properties:
> +- compatible : Should be "dlg,da9052", "dlg,da9053-aa",
> + "dlg,da9053-ab", or "dlg,da9053-bb"
> +
> +Sub-nodes:
> +- regulators : Contain the regulator nodes. The DA9052/53 regulators are
> + bound using their names as listed below:
> +
> +buck0 : regulator BUCK0
> +buck1 : regulator BUCK1
> +buck2 : regulator BUCK2
> +buck3 : regulator BUCK3
> +ldo4 : regulator LDO4
> +ldo5 : regulator LDO5
> +ldo6 : regulator LDO6
> +ldo7 : regulator LDO7
> +ldo8 : regulator LDO8
> +ldo9 : regulator LDO9
> +ldo10 : regulator LDO10
> +ldo11 : regulator LDO11
> +ldo12 : regulator LDO12
> +ldo13 : regulator LDO13
> +
> + The bindings details of individual regulator device can be found in:
> + Documentation/devicetree/bindings/regulator/regulator.txt
> +
> +Examples:
> +
> +i2c@63fc8000 { /* I2C1 */
> + status = "okay";
> +
> + pmic: dialog@48 {
> + compatible = "dlg,da9053-aa";
> + reg = <0x48>;
> +
> + regulators {
> + buck0 {
> + regulator-min-microvolt = <50>;
> + regulator-max-microvolt = <2075000>;
> + };
> +
> + buck1 {
> + regulator-min-microvolt = <50>;
> + regulator-max-microvolt = <2075000>;
> + };
> +
> + buck2 {
> + regulator-min-microvolt = <925000>;
> + regulator-max-microvolt = <250>;
> + };
> +
> + buck3 {
> + regulator-min-microvolt = <925000>;
> + regulator-max-microvolt = <250>;
> + };
> + };
> + };
> +};
> diff --git a/drivers/mfd/da9052-i2c.c b/drivers/mfd/da9052-i2c.c
> index 36b88e3..b946b0ff 100644
> --- a/drivers/mfd/da9052-i2c.c
> +++ b/drivers/mfd/da9052-i2c.c
> @@ -22,6 +22,11 @@
> #include
> #include
>
> +#ifdef CONFIG_OF
> +#include
> +#include
> +#endif
> +
I'm not a big fan of "#ifdef CONFIG_OF", but maintainers may like
to compile out DT support for non-DT build, so I leave it there.
> static int da9052_i2c_enable_multiwrite(struct da9052 *da9052)
> {
> int reg_val, ret;
> @@ -41,6 +46,24 @@ static int da9052_i2c_enable_multiwrite(struct da9052
> *da9052)
> return 0;
> }
>
> +static struct i2c_device_id da9052_i2c_id[] = {
> + {"da9052", DA9052},
> + {"da9053-aa", DA9053_AA},
> + {"da9053-ba", DA9053_BA},
> + {"da9053-bb", DA9053_BB},
> + {}
> +};
> +
> +#ifdef CONFIG_OF
> +static const struct of_device_id dialog_dt_ids[] = {
> + { .compatible = "dlg,da9052", .data = &da9052_i2c_id[0] },
> + { .compatible = "dlg,da9053-aa", .data = &da9052_i2c_id[1] },
> + { .compatible = "dlg,da9053-ab", .data = &da9052_i2c_id[2] },
> + { .compatible = "dlg,da9053-bb", .data = &da9052_i2c_id[3] },
> + { /* sentinel */ }
> +};
> +#endif
> +
> static int __devinit da9052_i2c_probe(struct i2c_client *client,
> const struct i2c_device_id *id)
> {
> @@ -76,6 +99,23 @@ static int __devinit da9052_i2c_probe(struct i2c_client
> *client,
> if (ret < 0)
> goto err_regmap;
>
> +#ifdef CONFIG_OF
> + if (!id) {
> + int i;
What is this for?
> + struct device_node *np = client->dev.of_node;
> + const struct of_device_id *deviceid;
> +
> + deviceid = of_match_node(np, dialog_dt_ids);
> + id = (const struct i2c_device_id *)(deviceid->data);
Unnecessary parentheses around deviceid->data.
Regards,
Shawn
> + }
> +#endif
> +
> + if (!id) {
> + ret = -ENODEV;
> + dev_err(&client->dev, "id is null.\n");
> + goto err_regmap;
> +
Re: Getting from a CI report to a hardware pack
On 12-04-14 11:59 AM, Fathi Boudra wrote: On 14 April 2012 18:02, Christian Robottom Reis wrote: On Sat, Apr 14, 2012 at 04:29:26PM +0200, Alexander Sack wrote: http://snapshots.linaro.org/kernel-hwpack/TI-working-tree/TI-working-tree_tilt-linux-linaro-3.1_panda-omap4plus/ Is that right? For some background, we got this inquiry on IRC: [...] We don't export the .deb package itself. What we export is the complete hwpack for such "pure" upstream CI jobs: http://ci.linaro.org/kernel_hwpack/(in this case: http://ci.linaro.org/kernel_hwpack/TI-working-tree/TI-working-tree_tilt-linux-linaro-3.1_panda-omap4plus/) ... can you find that build there? Note the link I provided above ;-) The immediate question is why isn't this linked to from the CI page? Publishing from CI to snapshots has been done recently. In the long term, ci.linaro.org will have a frontend like we do for android-build to make it easier to have various information (LAVA tests result, etc...). In the meantime, it's up to the CI job maintainer to update the job description and provide useful information like a link to snapshots (now added). This is my CI job and I've been too busy to garden it for the last week. Scott -- Scott Bambrough Technical Director, Member Services Linaro Ltd. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Thermal release for this month.
On Sat, Apr 14, 2012 at 3:49 AM, Christian Robottom Reis wrote: > On Sat, Apr 14, 2012 at 01:02:59AM +0400, Andrey Konovalov wrote: > > 2) So the new thermal_exynos4_imx6_work obsoletes the old > > exynos_thermal_framework_V2 topic. You should mention that > > explicitly when asking to add the new one to linux-linaro! > > I was a bit surprised at something related to this as well -- the new > Exynos4 thermal patchset actually includes the generic cpu cooling > patchset instead of keeping it separate. I realized later this was added > because the maintainer suggested including a user of the generic code to > demonstrate its usefulness, so it seems fine to me, though it might have > been easier to understand if you had maintained the original subject > "Add generic cpu cooling devices" and just expanded the patchset by > including the Exynos4 implementation at the end. > > At any range, Andrey's comment is right -- you need to let him know when > you're merging or splitting patchsets/topics or it'll be hard for him to > keep track of them. > I agree it would be hard for Andrey to resolve conflicts. Andrey: what percentage of external branches you're pulling are completely new versions of the patches (refactored or rebased) vs. those that build on top of the old stuff? I expect most of our work to be rebased/refactored work so that it would require reverting all old patches. Would it help if you were told that in the beginning of a feature integration? So we'd say, for example, "Please pull in this XXX thermal branch from git.linaro.org/foo.git and this will be constantly rebased, so pull a new version of it everytime you recreate the tree". ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Getting from a CI report to a hardware pack
On 14 April 2012 18:02, Christian Robottom Reis wrote: > On Sat, Apr 14, 2012 at 04:29:26PM +0200, Alexander Sack wrote: >> > http://snapshots.linaro.org/kernel-hwpack/TI-working-tree/TI-working-tree_tilt-linux-linaro-3.1_panda-omap4plus/ >> > >> > Is that right? For some background, we got this inquiry on IRC: > > [...] > >> We don't export the .deb package itself. What we export is the complete >> hwpack for such "pure" upstream CI jobs: >> http://ci.linaro.org/kernel_hwpack/(in this case: >> http://ci.linaro.org/kernel_hwpack/TI-working-tree/TI-working-tree_tilt-linux-linaro-3.1_panda-omap4plus/) >> ... can you find that build there? > > Note the link I provided above ;-) The immediate question is why isn't > this linked to from the CI page? Publishing from CI to snapshots has been done recently. In the long term, ci.linaro.org will have a frontend like we do for android-build to make it easier to have various information (LAVA tests result, etc...). In the meantime, it's up to the CI job maintainer to update the job description and provide useful information like a link to snapshots (now added). ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Getting from a CI report to a hardware pack
On Sat, Apr 14, 2012 at 04:29:26PM +0200, Alexander Sack wrote: > > http://snapshots.linaro.org/kernel-hwpack/TI-working-tree/TI-working-tree_tilt-linux-linaro-3.1_panda-omap4plus/ > > > > Is that right? For some background, we got this inquiry on IRC: [...] > We don't export the .deb package itself. What we export is the complete > hwpack for such "pure" upstream CI jobs: > http://ci.linaro.org/kernel_hwpack/(in this case: > http://ci.linaro.org/kernel_hwpack/TI-working-tree/TI-working-tree_tilt-linux-linaro-3.1_panda-omap4plus/) > ... can you find that build there? Note the link I provided above ;-) The immediate question is why isn't this linked to from the CI page? -- Christian Robottom Reis | [+55 16] 3376 0125 | http://launchpad.net/~kiko Canonical Ltd.| [+55 16] 9112 6430 | http://async.com.br/~kiko ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Getting from a CI report to a hardware pack
On Sat, Apr 14, 2012 at 4:29 PM, Alexander Sack wrote: > > > On Sat, Apr 14, 2012 at 2:41 PM, Christian Robottom Reis > wrote: > >> I think there's a standard link missing from CI pages such as >> >> >> https://ci.linaro.org/jenkins/job/TI-working-tree_tilt-linux-linaro-3.1_panda-omap4plus/ >> >> to the output directory at >> >> >> http://snapshots.linaro.org/kernel-hwpack/TI-working-tree/TI-working-tree_tilt-linux-linaro-3.1_panda-omap4plus/ >> >> Is that right? For some background, we got this inquiry on IRC: >> >> rsalveti: are there prebuilt linaro kernels for ubuntu that >>have hdmi fixes described in bug 919378? >> >> I went to look at the bug and then figured the latest CI build might >> have the code included. Indeed it does: >> >> >> https://ci.linaro.org/jenkins/job/TI-working-tree_tilt-linux-linaro-3.1_panda-omap4plus/4/changes#detail2 >> >> However, I couldn't find a way of getting the binary generated from the >> build, and had to actually use my rapidly deteriorating memory to get to >> snapshots.linaro.org, where I had to also go through a confusing set of >> directories to get to what I think is the actual build. >> > > We don't export the .deb package itself. What we export is the complete > hwpack for such "pure" upstream CI jobs: > http://ci.linaro.org/kernel_hwpack/ (in this case: > http://ci.linaro.org/kernel_hwpack/TI-working-tree/TI-working-tree_tilt-linux-linaro-3.1_panda-omap4plus/) > ... can you find that build there? > > (I don't know about the retention policy on that place atm.) > > And yes, this location is definitely not the real one: consider it an unofficial place until we have figured how we want to generally map the ci output into a reasonable snapshots hierarchy for ubuntu rootfs, hwpacks and hwpacks coming out of our mainline CI job types. BTW, this is already happening on the ubuntu rootfs/hwpack side: we are moving our rootfs production and hwpack production for our Ubuntu LEB to ci.linaro.org and as part of that I am sure we are inventing such a hierarchy mapping as we speak. I can imagine that whatever we do there for the official LEB hwpacks should be easily adaptable for our pure mainline focused CI jobs. -- Alexander Sack Technical Director, Linaro Platform Teams http://www.linaro.org | Open source software for ARM SoCs http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Getting from a CI report to a hardware pack
On Sat, Apr 14, 2012 at 2:41 PM, Christian Robottom Reis wrote: > I think there's a standard link missing from CI pages such as > > > https://ci.linaro.org/jenkins/job/TI-working-tree_tilt-linux-linaro-3.1_panda-omap4plus/ > > to the output directory at > > > http://snapshots.linaro.org/kernel-hwpack/TI-working-tree/TI-working-tree_tilt-linux-linaro-3.1_panda-omap4plus/ > > Is that right? For some background, we got this inquiry on IRC: > > rsalveti: are there prebuilt linaro kernels for ubuntu that >have hdmi fixes described in bug 919378? > > I went to look at the bug and then figured the latest CI build might > have the code included. Indeed it does: > > > https://ci.linaro.org/jenkins/job/TI-working-tree_tilt-linux-linaro-3.1_panda-omap4plus/4/changes#detail2 > > However, I couldn't find a way of getting the binary generated from the > build, and had to actually use my rapidly deteriorating memory to get to > snapshots.linaro.org, where I had to also go through a confusing set of > directories to get to what I think is the actual build. > We don't export the .deb package itself. What we export is the complete hwpack for such "pure" upstream CI jobs: http://ci.linaro.org/kernel_hwpack/(in this case: http://ci.linaro.org/kernel_hwpack/TI-working-tree/TI-working-tree_tilt-linux-linaro-3.1_panda-omap4plus/) ... can you find that build there? (I don't know about the retention policy on that place atm.) Short term I see two things that would be really important: 1. a really easy to find link to the LAVA job submitted 2. good display of the meta information of the build/lava job submitted which would include the link to the hwpack (as that is what is passed to LAVA as one artifact) as well as information about the git source and commit (and we could make a link to gitweb out of it when visualizing this job). Ultimately, we want to have a way to have all meta-information for all steps of a CI job nicely visualized (e.g. automerging, auto buiding, validating, etc.). Anyway, we should start thinking about visualizing CI jobs and make them navigatable soon. I don't want to see us making the mistake again to wait for a nice UI until all the plumming is done. That approach just leave lots of value on the floor! I am sure Andy, Ricardo and Danilo are already thinking about this though :). -- Alexander Sack Technical Director, Linaro Platform Teams http://www.linaro.org | Open source software for ARM SoCs http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH v3] mfd: da9052: add device-tree support for i2c driver
From: "Ying-Chun Liu (PaulLiu)"
This patch adds device-tree support for dialog MFD and the binding
documentations.
Signed-off-by: Ying-Chun Liu (PaulLiu)
Cc: Samuel Ortiz
Cc: Mark Brown
Cc: Shawn Guo
Cc: Ashish Jangam
---
.../devicetree/bindings/mfd/da9052-i2c.txt | 60
drivers/mfd/da9052-i2c.c | 51 ++---
2 files changed, 103 insertions(+), 8 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mfd/da9052-i2c.txt
diff --git a/Documentation/devicetree/bindings/mfd/da9052-i2c.txt
b/Documentation/devicetree/bindings/mfd/da9052-i2c.txt
new file mode 100644
index 000..1857f4a
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/da9052-i2c.txt
@@ -0,0 +1,60 @@
+* Dialog DA9052/53 Power Management Integrated Circuit (PMIC)
+
+Required properties:
+- compatible : Should be "dlg,da9052", "dlg,da9053-aa",
+"dlg,da9053-ab", or "dlg,da9053-bb"
+
+Sub-nodes:
+- regulators : Contain the regulator nodes. The DA9052/53 regulators are
+ bound using their names as listed below:
+
+buck0 : regulator BUCK0
+buck1 : regulator BUCK1
+buck2 : regulator BUCK2
+buck3 : regulator BUCK3
+ldo4 : regulator LDO4
+ldo5 : regulator LDO5
+ldo6 : regulator LDO6
+ldo7 : regulator LDO7
+ldo8 : regulator LDO8
+ldo9 : regulator LDO9
+ldo10 : regulator LDO10
+ldo11 : regulator LDO11
+ldo12 : regulator LDO12
+ldo13 : regulator LDO13
+
+ The bindings details of individual regulator device can be found in:
+ Documentation/devicetree/bindings/regulator/regulator.txt
+
+Examples:
+
+i2c@63fc8000 { /* I2C1 */
+ status = "okay";
+
+ pmic: dialog@48 {
+ compatible = "dlg,da9053-aa";
+ reg = <0x48>;
+
+ regulators {
+ buck0 {
+ regulator-min-microvolt = <50>;
+ regulator-max-microvolt = <2075000>;
+ };
+
+ buck1 {
+ regulator-min-microvolt = <50>;
+ regulator-max-microvolt = <2075000>;
+ };
+
+ buck2 {
+ regulator-min-microvolt = <925000>;
+ regulator-max-microvolt = <250>;
+ };
+
+ buck3 {
+ regulator-min-microvolt = <925000>;
+ regulator-max-microvolt = <250>;
+ };
+ };
+ };
+};
diff --git a/drivers/mfd/da9052-i2c.c b/drivers/mfd/da9052-i2c.c
index 36b88e3..b946b0ff 100644
--- a/drivers/mfd/da9052-i2c.c
+++ b/drivers/mfd/da9052-i2c.c
@@ -22,6 +22,11 @@
#include
#include
+#ifdef CONFIG_OF
+#include
+#include
+#endif
+
static int da9052_i2c_enable_multiwrite(struct da9052 *da9052)
{
int reg_val, ret;
@@ -41,6 +46,24 @@ static int da9052_i2c_enable_multiwrite(struct da9052
*da9052)
return 0;
}
+static struct i2c_device_id da9052_i2c_id[] = {
+ {"da9052", DA9052},
+ {"da9053-aa", DA9053_AA},
+ {"da9053-ba", DA9053_BA},
+ {"da9053-bb", DA9053_BB},
+ {}
+};
+
+#ifdef CONFIG_OF
+static const struct of_device_id dialog_dt_ids[] = {
+ { .compatible = "dlg,da9052", .data = &da9052_i2c_id[0] },
+ { .compatible = "dlg,da9053-aa", .data = &da9052_i2c_id[1] },
+ { .compatible = "dlg,da9053-ab", .data = &da9052_i2c_id[2] },
+ { .compatible = "dlg,da9053-bb", .data = &da9052_i2c_id[3] },
+ { /* sentinel */ }
+};
+#endif
+
static int __devinit da9052_i2c_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
@@ -76,6 +99,23 @@ static int __devinit da9052_i2c_probe(struct i2c_client
*client,
if (ret < 0)
goto err_regmap;
+#ifdef CONFIG_OF
+ if (!id) {
+ int i;
+ struct device_node *np = client->dev.of_node;
+ const struct of_device_id *deviceid;
+
+ deviceid = of_match_node(np, dialog_dt_ids);
+ id = (const struct i2c_device_id *)(deviceid->data);
+ }
+#endif
+
+ if (!id) {
+ ret = -ENODEV;
+ dev_err(&client->dev, "id is null.\n");
+ goto err_regmap;
+ }
+
ret = da9052_device_init(da9052, id->driver_data);
if (ret != 0)
goto err_regmap;
@@ -100,14 +140,6 @@ static int __devexit da9052_i2c_remove(struct i2c_client
*client)
return 0;
}
-static struct i2c_device_id da9052_i2c_id[] = {
- {"da9052", DA9052},
- {"da9053-aa", DA9053_AA},
- {"da9053-ba", DA9053_BA},
- {"da9053-bb", DA9053_BB},
- {}
-};
-
static struct i2c_driver da9052_i2c_driver = {
.p
Getting from a CI report to a hardware pack
I think there's a standard link missing from CI pages such as https://ci.linaro.org/jenkins/job/TI-working-tree_tilt-linux-linaro-3.1_panda-omap4plus/ to the output directory at http://snapshots.linaro.org/kernel-hwpack/TI-working-tree/TI-working-tree_tilt-linux-linaro-3.1_panda-omap4plus/ Is that right? For some background, we got this inquiry on IRC: rsalveti: are there prebuilt linaro kernels for ubuntu that have hdmi fixes described in bug 919378? I went to look at the bug and then figured the latest CI build might have the code included. Indeed it does: https://ci.linaro.org/jenkins/job/TI-working-tree_tilt-linux-linaro-3.1_panda-omap4plus/4/changes#detail2 However, I couldn't find a way of getting the binary generated from the build, and had to actually use my rapidly deteriorating memory to get to snapshots.linaro.org, where I had to also go through a confusing set of directories to get to what I think is the actual build. Thanks, -- Christian Robottom Reis, Engineering VP Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935 Linaro.org: Open Source Software for ARM SoCs ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v2] rtc: add support for Freescale SNVS RTC
On Sat, Apr 14, 2012 at 03:07:17PM +0800, Ying-Chun Liu (PaulLiu) wrote:
> From: "Ying-Chun Liu (PaulLiu)"
>
> This adds an RTC driver for the Low Power (LP) section of SNVS.
> It hooks into the /dev/rtc interface and supports ioctl to complete RTC
> features. This driver supports device tree bindings.
> It only uses the RTC hw in non-secure mode.
>
> Signed-off-by: Anish Trivedi
> Signed-off-by: Eric Miao
> Signed-off-by: Anson Huang
> Signed-off-by: Ying-Chun Liu (PaulLiu)
> Cc: Alessandro Zummo
> Cc: Shawn Guo
> Cc: Sascha Hauer
> ---
> Documentation/devicetree/bindings/rtc/snvs-rtc.txt | 18 +
> drivers/rtc/Kconfig| 10 +
> drivers/rtc/Makefile |1 +
> drivers/rtc/rtc-snvs.c | 644
>
> 4 files changed, 673 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/rtc/snvs-rtc.txt
> create mode 100644 drivers/rtc/rtc-snvs.c
>
> +#define CNTR_TO_SECS_SH 15 /* Converts 47-bit counter to 32-bit seconds */
> +
> +struct rtc_drv_data {
> + struct rtc_device *rtc;
> + void __iomem *ioaddr;
> + int irq;
> + bool irq_enable;
> +};
> +
> +static DEFINE_SPINLOCK(rtc_lock);
Put this three lines above.
> + writel(time >> (32 - CNTR_TO_SECS_SH), ioaddr + SNVS_LPSRTCMR);
> +
> + /* Enable RTC again */
> + writel(lp_cr | SNVS_LPCR_SRTC_ENV, ioaddr + SNVS_LPCR);
> + timeout = jiffies + msecs_to_jiffies(3000);
> + while (!(readl(ioaddr + SNVS_LPCR) & SNVS_LPCR_SRTC_ENV)) {
> + if (time_after(jiffies, timeout)) {
> + dev_err(dev, "timeout on enabling RTC back\n");
> + return -EBUSY;
> + }
> + }
> +
> + rtc_write_sync_lp(ioaddr);
> +
> + new_time_47bit = (((u64) (readl(ioaddr + SNVS_LPSRTCMR) &
> + ((0x1 << CNTR_TO_SECS_SH) - 1)) << 32) |
> + ((u64) readl(ioaddr + SNVS_LPSRTCLR)));
> +
> + time_diff = new_time_47bit - old_time_47bit;
time_diff, old_time_47bit and new_time_47bit are set and never read.
Remove.
> +
> + return 0;
> +}
> +
> +static int snvs_rtc_proc(struct device *dev, struct seq_file *seq)
> +{
> + struct rtc_drv_data *pdata = dev_get_drvdata(dev);
> + void __iomem *ioaddr = pdata->ioaddr;
> +
> + seq_printf(seq, "alarm_IRQ\t: %s\n",
> +(((readl(ioaddr + SNVS_LPCR)) & SNVS_LPCR_LPTA_EN) !=
> + 0) ? "yes" : "no");
> +
> + return 0;
> +}
> +
> +static int snvs_rtc_alarm_irq_enable(struct device *dev, unsigned int enable)
> +{
> + struct rtc_drv_data *pdata = dev_get_drvdata(dev);
> + void __iomem *ioaddr = pdata->ioaddr;
> + u32 lp_cr;
> + unsigned long lock_flags = 0;
> +
> + spin_lock_irqsave(&rtc_lock, lock_flags);
> +
> + if (enable) {
> + if (!pdata->irq_enable) {
> + enable_irq(pdata->irq);
> + pdata->irq_enable = true;
> + }
Why this enable_irq/disable_irq everywhere? You seem to have irq enable
bits in your registers which should be enough.
> +/* SNVS RTC Power management control */
> +static int __devinit snvs_rtc_probe(struct platform_device *pdev)
> +{
> + struct timespec tv;
> + struct rtc_device *rtc;
> + struct rtc_drv_data *pdata = NULL;
No need to initialize this. I think you should use another name for this
variable. People usually expect pdata for platform_data. Driver data is
usually called priv, or snvs_rtc in this case.
> + void __iomem *ioaddr;
> + u32 lp_cr;
> + int ret = 0;
No need to initialize this.
> +
> + ioaddr = of_iomap(pdev->dev.of_node, 0);
> + if (!ioaddr)
> + return -EADDRNOTAVAIL;
> +
> + pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
> + if (!pdata)
> + return -ENOMEM;
> +
> + pdata->ioaddr = ioaddr;
> +
> + /* Configure and enable the RTC */
> + pdata->irq = platform_get_irq(pdev, 0);
> + if (pdata->irq >= 0) {
Is there any hardware without an interrupt? If no, just bail out here
and get rid of the additional complexity.
> + if (request_irq(pdata->irq, snvs_rtc_interrupt, IRQF_SHARED,
> + pdev->name, pdev) < 0) {
> + dev_warn(&pdev->dev, "interrupt not available.\n");
> + pdata->irq = -1;
> + } else {
> + disable_irq(pdata->irq);
> + pdata->irq_enable = false;
> + }
> + }
> +
> + /* initialize glitch detect */
> + writel(SNVS_LPPGDR_INIT, ioaddr + SNVS_LPPGDR);
> + udelay(100);
> +
> + /* clear lp interrupt status */
> + writel(0x, ioaddr + SNVS_LPSR);
> +
> + /* Enable RTC */
> + lp_cr = readl(ioaddr + SNVS_LPCR);
> + if ((lp_cr & SNVS_LPCR_SRTC_ENV) == 0)
> + writel(lp_cr | SNVS_LPCR_SRTC_ENV, ioaddr + SNVS_LPCR);
> + udelay(100);
> +
> + w
[PATCH v2] rtc: add support for Freescale SNVS RTC
From: "Ying-Chun Liu (PaulLiu)"
This adds an RTC driver for the Low Power (LP) section of SNVS.
It hooks into the /dev/rtc interface and supports ioctl to complete RTC
features. This driver supports device tree bindings.
It only uses the RTC hw in non-secure mode.
Signed-off-by: Anish Trivedi
Signed-off-by: Eric Miao
Signed-off-by: Anson Huang
Signed-off-by: Ying-Chun Liu (PaulLiu)
Cc: Alessandro Zummo
Cc: Shawn Guo
Cc: Sascha Hauer
---
Documentation/devicetree/bindings/rtc/snvs-rtc.txt | 18 +
drivers/rtc/Kconfig| 10 +
drivers/rtc/Makefile |1 +
drivers/rtc/rtc-snvs.c | 644
4 files changed, 673 insertions(+)
create mode 100644 Documentation/devicetree/bindings/rtc/snvs-rtc.txt
create mode 100644 drivers/rtc/rtc-snvs.c
diff --git a/Documentation/devicetree/bindings/rtc/snvs-rtc.txt
b/Documentation/devicetree/bindings/rtc/snvs-rtc.txt
new file mode 100644
index 000..95b0a75
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/snvs-rtc.txt
@@ -0,0 +1,18 @@
+* Freescale SNVS RTC
+
+Required properties:
+- compatible : Should be "fsl,snvs-rtc"
+- reg: physical base address of the controller and length of memory mapped
+ region.
+- interrupts: Two interrupt numbers to the cpu should be specified. First
+ interrupt number is the consolidated interrupt in non TrustZone. The second
+ interrupt number is the security interrupt in TrustZone. The number of cells
+ representing a interrupt depends on the parent interrupt controller.
+
+Example:
+
+snvs@020cc000 {
+ compatible = "fsl,snvs-rtc";
+ reg = <0x020cc000 0x4000>;
+ interrupts = <0 19 0x04 0 20 0x04>;
+};
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 8c8377d..6597ab6 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -641,6 +641,16 @@ config RTC_MXC
This driver can also be built as a module, if so, the module
will be called "rtc-mxc".
+config RTC_DRV_SNVS
+ tristate "Freescale SNVS Real Time Clock"
+ depends on ARCH_MXC
+ help
+ If you say yes here you get support for the Freescale SNVS
+ Low Power (LP) RTC module.
+
+ This driver can also be built as a module, if so, the module
+ will be called "rtc-snvs".
+
config RTC_DRV_BQ4802
tristate "TI BQ4802"
help
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index 727ae77..c91042b 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -95,6 +95,7 @@ obj-$(CONFIG_RTC_DRV_S35390A) += rtc-s35390a.o
obj-$(CONFIG_RTC_DRV_S3C) += rtc-s3c.o
obj-$(CONFIG_RTC_DRV_SA1100) += rtc-sa1100.o
obj-$(CONFIG_RTC_DRV_SH) += rtc-sh.o
+obj-$(CONFIG_RTC_DRV_SNVS) += rtc-snvs.o
obj-$(CONFIG_RTC_DRV_SPEAR)+= rtc-spear.o
obj-$(CONFIG_RTC_DRV_STARFIRE) += rtc-starfire.o
obj-$(CONFIG_RTC_DRV_STK17TA8) += rtc-stk17ta8.o
diff --git a/drivers/rtc/rtc-snvs.c b/drivers/rtc/rtc-snvs.c
new file mode 100644
index 000..a717084
--- /dev/null
+++ b/drivers/rtc/rtc-snvs.c
@@ -0,0 +1,644 @@
+/*
+ * Copyright (C) 2011 Freescale Semiconductor, Inc.
+ */
+
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * 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 Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ */
+/*
+ * Implementation based on rtc-ds1553.c
+ */
+
+/*
+ * RTC Real Time Clock (RTC) Driver
+ *
+ * Secure Real Time Clock (SRTC) interface in Freescale's SNVS module
+ *
+ * This file contains Real Time Clock interface for Linux. The Freescale
+ * SNVS module's Low Power (LP) SRTC functionality is utilized in this driver,
+ * in non-secure mode.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Register definitions */
+#define SNVS_HPSR 0x14/* HP Status Register */
+#define SNVS_LPCR 0x38/* LP Control Register */
+#define SNVS_LPSR 0x4C/* LP Status Register */
+#define SNVS_LPSRTCMR 0x50/* LP Secure Real Time Counter MSB Register */
+#define SNVS_LPSRTCLR 0x54/* LP Secure Real Time Counter LSB Register */
+#define SNVS_LPTAR 0x58/* LP Time Alarm Register */
+#define SNVS_LPSMCMR 0x5C/* LP Secure Monotonic Counter MSB Register */
+#define SNVS_LPSMCLR 0x60/* LP Secure Monotonic
