From: Eduardo Valentin <eduardo.valentin@ti.com>
To: "Shilimkar, Santosh" <santosh.shilimkar@ti.com>
Cc: amit.kucheria@linaro.org, kbaidarov@dev.rtsoft.ru, kishon@ti.com,
balbi@ti.com, J Keerthy <j-keerthy@ti.com>,
linux-pm@lists.linux-foundation.org, linux-omap@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC PATCH 05/11] mfd: omap: control: core system control driver
Date: Mon, 28 May 2012 14:42:25 +0300 [thread overview]
Message-ID: <20120528114225.GH3923@besouro> (raw)
In-Reply-To: <CAMQu2gy_rgLidHWy7xxZBiVD4wfFuTvA+wC7joogrcFptwsx8w@mail.gmail.com>
Hello,
On Mon, May 28, 2012 at 03:24:01PM +0530, Shilimkar, Santosh wrote:
> On Fri, May 25, 2012 at 1:55 PM, Eduardo Valentin
> <eduardo.valentin@ti.com> wrote:
> > This patch introduces a MFD core device driver for
> > OMAP system control module.
> >
> > The control module allows software control of
> > various static modes supported by the device. It is
> > composed of two control submodules: general control
> > module and device (padconfiguration) control
> > module.
> >
> > In this patch, the children defined are for:
> > . USB-phy pin control
> > . Bangap temperature sensor
> >
> > Device driver is probed with postcore_initcall.
> > However, as some of the APIs exposed by this driver
> > may be needed in very early init phase, an early init
> > class is also available: "early_omap_control".
> >
> > Signed-off-by: J Keerthy <j-keerthy@ti.com>
> > Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> > Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
> > ---
>
> [..]
> > diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
> > index ad95c7a..222dbad 100644
> > --- a/arch/arm/plat-omap/Kconfig
> > +++ b/arch/arm/plat-omap/Kconfig
> > @@ -5,6 +5,9 @@ menu "TI OMAP Common Features"
> > config ARCH_OMAP_OTG
> > bool
> >
> > +config ARCH_HAS_CONTROL_MODULE
> > + bool
> > +
> Thanks for getting rid of OMAP CONFIG here.
OK. ARCH_HAS_CONTROL_MODULE is a bit too generic though..
>
> > choice
> > prompt "OMAP System Type"
> > default ARCH_OMAP2PLUS
> > diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> > index 11e4438..25a66d8 100644
> > --- a/drivers/mfd/Kconfig
> > +++ b/drivers/mfd/Kconfig
> > @@ -795,6 +795,15 @@ config MFD_WL1273_CORE
> > driver connects the radio-wl1273 V4L2 module and the wl1273
> > audio codec.
> >
> > +config MFD_OMAP_CONTROL
> > + bool "Texas Instruments OMAP System control module"
> > + depends on ARCH_HAS_CONTROL_MODULE
> > + help
> > + This is the core driver for system control module. This driver
> > + is responsible for creating the control module mfd child,
> > + like USB-pin control, pin muxing, MMC-pbias and DDR IO dynamic
> > + change for off mode.
> > +
> > config MFD_OMAP_USB_HOST
> > bool "Support OMAP USBHS core driver"
> > depends on USB_EHCI_HCD_OMAP || USB_OHCI_HCD_OMAP3
> > diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> > index 05fa538..00f99d6 100644
> > --- a/drivers/mfd/Makefile
> > +++ b/drivers/mfd/Makefile
> > @@ -106,6 +106,7 @@ obj-$(CONFIG_MFD_TPS6586X) += tps6586x.o
> > obj-$(CONFIG_MFD_VX855) += vx855.o
> > obj-$(CONFIG_MFD_WL1273_CORE) += wl1273-core.o
> > obj-$(CONFIG_MFD_CS5535) += cs5535-mfd.o
> > +obj-$(CONFIG_MFD_OMAP_CONTROL) += omap-control-core.o
> > obj-$(CONFIG_MFD_OMAP_USB_HOST) += omap-usb-host.o
> > obj-$(CONFIG_MFD_PM8921_CORE) += pm8921-core.o
> > obj-$(CONFIG_MFD_PM8XXX_IRQ) += pm8xxx-irq.o
> > diff --git a/drivers/mfd/omap-control-core.c b/drivers/mfd/omap-control-core.c
> > new file mode 100644
> > index 0000000..7d8d408
> > --- /dev/null
> > +++ b/drivers/mfd/omap-control-core.c
> > @@ -0,0 +1,211 @@
> > +/*
> > + * OMAP system control module driver file
> > + *
> > + * Copyright (C) 2011-2012 Texas Instruments Incorporated - http://www.ti.com/
> > + * Contacts:
> > + * Based on original code written by:
> > + * J Keerthy <j-keerthy@ti.com>
> > + * Moiz Sonasath <m-sonasath@ti.com>
> > + * MFD clean up and re-factoring:
> > + * Eduardo Valentin <eduardo.valentin@ti.com>
> > + *
> > + * This program is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU General Public License
> > + * version 2 as published by the Free Software Foundation.
> > + *
> > + * This program is distributed in the hope that it will be useful, but
> > + * WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> > + * General Public License for more details.
> > + *
> > + */
> > +
> > +#include <linux/module.h>
> > +#include <linux/export.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/slab.h>
> > +#include <linux/io.h>
> > +#include <linux/err.h>
> > +#include <linux/of_platform.h>
> > +#include <linux/of_address.h>
> > +#include <linux/mfd/core.h>
> > +#include <linux/mfd/omap_control.h>
> > +
> > +static struct omap_control *omap_control_module;
> > +
> > +/**
> > + * omap_control_readl: Read a single omap control module register.
> > + *
> > + * @dev: device to read from.
> > + * @reg: register to read.
> > + * @val: output with register value.
> > + *
> > + * returns 0 on success or -EINVAL in case struct device is invalid.
> > + */
> > +int omap_control_readl(struct device *dev, u32 reg, u32 *val)
> > +{
> > + struct omap_control *omap_control = dev_get_drvdata(dev);
> > +
> > + if (!omap_control)
> > + return -EINVAL;
> > +
> > + *val = readl(omap_control->base + reg);
> > +
> > + return 0;
> > +}
> > +EXPORT_SYMBOL_GPL(omap_control_readl);
> > +
> I might have missed in the last scan, but can you let
> function return the register value.
Why?
>
> I am guessing, you did this for error case handling. You might
> want to stick to read API semantic and just have WARN_ON()
> to take care of error case.
Yeah, that was for error handling and to do not confuse register
values with error values.
>
> > +/**
> > + * omap_control_writel: Write a single omap control module register.
> > + *
> > + * @dev: device to read from.
> > + * @val: value to write.
> > + * @reg: register to write to.
> > + *
> > + * returns 0 on success or -EINVAL in case struct device is invalid.
> > + */
> > +int omap_control_writel(struct device *dev, u32 val, u32 reg)
> > +{
> > + struct omap_control *omap_control = dev_get_drvdata(dev);
> > + unsigned long flags;
> > +
> > + if (!omap_control)
> > + return -EINVAL;
> > +
> > + spin_lock_irqsave(&omap_control->reg_lock, flags);
> > + writel(val, omap_control->base + reg);
> > + spin_unlock_irqrestore(&omap_control->reg_lock, flags);
> > +
> > + return 0;
> > +}
> > +EXPORT_SYMBOL_GPL(omap_control_writel);
> > +
> > +/**
> > + * omap_control_get: returns the control module device pinter
> > + *
> > + * The modules which has to use control module API's to read or write should
> > + * call this API to get the control module device pointer.
> > + */
> > +struct device *omap_control_get(void)
> > +{
> > + unsigned long flags;
> > +
> > + if (!omap_control_module)
> > + return ERR_PTR(-ENODEV);
> > +
> > + spin_lock_irqsave(&omap_control_module->reg_lock, flags);
> > + omap_control_module->use_count++;
> > + spin_unlock_irqrestore(&omap_control_module->reg_lock, flags);
> > +
> > + return omap_control_module->dev;
> > +}
> > +EXPORT_SYMBOL_GPL(omap_control_get);
> > +
> > +/**
> > + * omap_control_put: returns the control module device pinter
> > + *
> > + * The modules which has to use control module API's to read or write should
> > + * call this API to get the control module device pointer.
> > + */
> > +void omap_control_put(struct device *dev)
> > +{
> > + struct omap_control *omap_control = dev_get_drvdata(dev);
> > + unsigned long flags;
> > +
> > + if (!omap_control)
> > + return;
> > +
> > + spin_lock_irqsave(&omap_control->reg_lock, flags);
> > + omap_control->use_count--;
> > + spin_unlock_irqrestore(&omap_control_module->reg_lock, flags);
> > +}
> > +EXPORT_SYMBOL_GPL(omap_control_put);
> > +
> > +static const struct of_device_id of_omap_control_match[] = {
> > + { .compatible = "ti,omap3-control", },
> > + { .compatible = "ti,omap4-control", },
> > + { .compatible = "ti,omap5-control", },
> > + { },
> > +};
> > +
> > +static int __devinit omap_control_probe(struct platform_device *pdev)
> > +{
> > + struct resource *res;
> > + void __iomem *base;
> > + struct device *dev = &pdev->dev;
> > + struct device_node *np = dev->of_node;
> > + struct omap_control *omap_control;
> > +
> > + omap_control = devm_kzalloc(dev, sizeof(*omap_control), GFP_KERNEL);
> > + if (!omap_control) {
> > + dev_err(dev, "not enough memory for omap_control\n");
> > + return -ENOMEM;
> > + }
> > +
> > + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > + if (!res) {
> > + dev_err(dev, "missing memory base resource\n");
> > + return -EINVAL;
> > + }
> > +
> > + base = devm_request_and_ioremap(dev, res);
> > + if (!base) {
> > + dev_err(dev, "ioremap failed\n");
> > + return -EADDRNOTAVAIL;
> > + }
> > +
> > + omap_control->base = base;
> > + omap_control->dev = dev;
> > + spin_lock_init(&omap_control->reg_lock);
> > +
> > + platform_set_drvdata(pdev, omap_control);
> > + omap_control_module = omap_control;
> > +
> > + return of_platform_populate(np, of_omap_control_match, NULL, dev);
> > +}
> > +
>
> Will the probe get called on multiple devices and race ?
It depends. If we decide to have an early device for scm, then the probe will
be called more than once. If not, then only once.
>
> > +static int __devexit omap_control_remove(struct platform_device *pdev)
> > +{
> > + struct omap_control *omap_control = platform_get_drvdata(pdev);
> > +
> > + spin_lock(&omap_control->reg_lock);
> > + if (omap_control->use_count > 0) {
> > + spin_unlock(&omap_control->reg_lock);
> > + dev_err(&pdev->dev, "device removed while still being used\n");
> > + return -EBUSY;
> > + }
> > + spin_unlock(&omap_control->reg_lock);
> > +
> Do you really need above lock where you are just doing the
> register read. smp_rmb(), should be enough, I guess.
It is locking the use counter not a register..
>
> Regards
> Santosh
WARNING: multiple messages have this Message-ID (diff)
From: eduardo.valentin@ti.com (Eduardo Valentin)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 05/11] mfd: omap: control: core system control driver
Date: Mon, 28 May 2012 14:42:25 +0300 [thread overview]
Message-ID: <20120528114225.GH3923@besouro> (raw)
In-Reply-To: <CAMQu2gy_rgLidHWy7xxZBiVD4wfFuTvA+wC7joogrcFptwsx8w@mail.gmail.com>
Hello,
On Mon, May 28, 2012 at 03:24:01PM +0530, Shilimkar, Santosh wrote:
> On Fri, May 25, 2012 at 1:55 PM, Eduardo Valentin
> <eduardo.valentin@ti.com> wrote:
> > This patch introduces a MFD core device driver for
> > OMAP system control module.
> >
> > The control module allows software control of
> > various static modes supported by the device. It is
> > composed of two control submodules: general control
> > module and device (padconfiguration) control
> > module.
> >
> > In this patch, the children defined are for:
> > . USB-phy pin control
> > . Bangap temperature sensor
> >
> > Device driver is probed with postcore_initcall.
> > However, as some of the APIs exposed by this driver
> > may be needed in very early init phase, an early init
> > class is also available: "early_omap_control".
> >
> > Signed-off-by: J Keerthy <j-keerthy@ti.com>
> > Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> > Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
> > ---
>
> [..]
> > diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
> > index ad95c7a..222dbad 100644
> > --- a/arch/arm/plat-omap/Kconfig
> > +++ b/arch/arm/plat-omap/Kconfig
> > @@ -5,6 +5,9 @@ menu "TI OMAP Common Features"
> > ?config ARCH_OMAP_OTG
> > ? ? ? ?bool
> >
> > +config ARCH_HAS_CONTROL_MODULE
> > + ? ? ? bool
> > +
> Thanks for getting rid of OMAP CONFIG here.
OK. ARCH_HAS_CONTROL_MODULE is a bit too generic though..
>
> > ?choice
> > ? ? ? ?prompt "OMAP System Type"
> > ? ? ? ?default ARCH_OMAP2PLUS
> > diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> > index 11e4438..25a66d8 100644
> > --- a/drivers/mfd/Kconfig
> > +++ b/drivers/mfd/Kconfig
> > @@ -795,6 +795,15 @@ config MFD_WL1273_CORE
> > ? ? ? ? ?driver connects the radio-wl1273 V4L2 module and the wl1273
> > ? ? ? ? ?audio codec.
> >
> > +config MFD_OMAP_CONTROL
> > + ? ? ? bool "Texas Instruments OMAP System control module"
> > + ? ? ? depends on ARCH_HAS_CONTROL_MODULE
> > + ? ? ? help
> > + ? ? ? ? This is the core driver for system control module. This driver
> > + ? ? ? ? is responsible for creating the control module mfd child,
> > + ? ? ? ? like USB-pin control, pin muxing, MMC-pbias and DDR IO dynamic
> > + ? ? ? ? change for off mode.
> > +
> > ?config MFD_OMAP_USB_HOST
> > ? ? ? ?bool "Support OMAP USBHS core driver"
> > ? ? ? ?depends on USB_EHCI_HCD_OMAP || USB_OHCI_HCD_OMAP3
> > diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> > index 05fa538..00f99d6 100644
> > --- a/drivers/mfd/Makefile
> > +++ b/drivers/mfd/Makefile
> > @@ -106,6 +106,7 @@ obj-$(CONFIG_MFD_TPS6586X) ?+= tps6586x.o
> > ?obj-$(CONFIG_MFD_VX855) ? ? ? ? ? ? ? ?+= vx855.o
> > ?obj-$(CONFIG_MFD_WL1273_CORE) ?+= wl1273-core.o
> > ?obj-$(CONFIG_MFD_CS5535) ? ? ? += cs5535-mfd.o
> > +obj-$(CONFIG_MFD_OMAP_CONTROL) += omap-control-core.o
> > ?obj-$(CONFIG_MFD_OMAP_USB_HOST) ? ? ? ?+= omap-usb-host.o
> > ?obj-$(CONFIG_MFD_PM8921_CORE) ?+= pm8921-core.o
> > ?obj-$(CONFIG_MFD_PM8XXX_IRQ) ? += pm8xxx-irq.o
> > diff --git a/drivers/mfd/omap-control-core.c b/drivers/mfd/omap-control-core.c
> > new file mode 100644
> > index 0000000..7d8d408
> > --- /dev/null
> > +++ b/drivers/mfd/omap-control-core.c
> > @@ -0,0 +1,211 @@
> > +/*
> > + * OMAP system control module driver file
> > + *
> > + * Copyright (C) 2011-2012 Texas Instruments Incorporated - http://www.ti.com/
> > + * Contacts:
> > + * Based on original code written by:
> > + * ? ?J Keerthy <j-keerthy@ti.com>
> > + * ? ?Moiz Sonasath <m-sonasath@ti.com>
> > + * MFD clean up and re-factoring:
> > + * ? ?Eduardo Valentin <eduardo.valentin@ti.com>
> > + *
> > + * This program is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU General Public License
> > + * version 2 as published by the Free Software Foundation.
> > + *
> > + * This program is distributed in the hope that it will be useful, but
> > + * WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ?See the GNU
> > + * General Public License for more details.
> > + *
> > + */
> > +
> > +#include <linux/module.h>
> > +#include <linux/export.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/slab.h>
> > +#include <linux/io.h>
> > +#include <linux/err.h>
> > +#include <linux/of_platform.h>
> > +#include <linux/of_address.h>
> > +#include <linux/mfd/core.h>
> > +#include <linux/mfd/omap_control.h>
> > +
> > +static struct omap_control *omap_control_module;
> > +
> > +/**
> > + * omap_control_readl: Read a single omap control module register.
> > + *
> > + * @dev: device to read from.
> > + * @reg: register to read.
> > + * @val: output with register value.
> > + *
> > + * returns 0 on success or -EINVAL in case struct device is invalid.
> > + */
> > +int omap_control_readl(struct device *dev, u32 reg, u32 *val)
> > +{
> > + ? ? ? struct omap_control *omap_control = dev_get_drvdata(dev);
> > +
> > + ? ? ? if (!omap_control)
> > + ? ? ? ? ? ? ? return -EINVAL;
> > +
> > + ? ? ? *val = readl(omap_control->base + reg);
> > +
> > + ? ? ? return 0;
> > +}
> > +EXPORT_SYMBOL_GPL(omap_control_readl);
> > +
> I might have missed in the last scan, but can you let
> function return the register value.
Why?
>
> I am guessing, you did this for error case handling. You might
> want to stick to read API semantic and just have WARN_ON()
> to take care of error case.
Yeah, that was for error handling and to do not confuse register
values with error values.
>
> > +/**
> > + * omap_control_writel: Write a single omap control module register.
> > + *
> > + * @dev: device to read from.
> > + * @val: value to write.
> > + * @reg: register to write to.
> > + *
> > + * returns 0 on success or -EINVAL in case struct device is invalid.
> > + */
> > +int omap_control_writel(struct device *dev, u32 val, u32 reg)
> > +{
> > + ? ? ? struct omap_control *omap_control = dev_get_drvdata(dev);
> > + ? ? ? unsigned long flags;
> > +
> > + ? ? ? if (!omap_control)
> > + ? ? ? ? ? ? ? return -EINVAL;
> > +
> > + ? ? ? spin_lock_irqsave(&omap_control->reg_lock, flags);
> > + ? ? ? writel(val, omap_control->base + reg);
> > + ? ? ? spin_unlock_irqrestore(&omap_control->reg_lock, flags);
> > +
> > + ? ? ? return 0;
> > +}
> > +EXPORT_SYMBOL_GPL(omap_control_writel);
> > +
> > +/**
> > + * omap_control_get: returns the control module device pinter
> > + *
> > + * The modules which has to use control module API's to read or write should
> > + * call this API to get the control module device pointer.
> > + */
> > +struct device *omap_control_get(void)
> > +{
> > + ? ? ? unsigned long flags;
> > +
> > + ? ? ? if (!omap_control_module)
> > + ? ? ? ? ? ? ? return ERR_PTR(-ENODEV);
> > +
> > + ? ? ? spin_lock_irqsave(&omap_control_module->reg_lock, flags);
> > + ? ? ? omap_control_module->use_count++;
> > + ? ? ? spin_unlock_irqrestore(&omap_control_module->reg_lock, flags);
> > +
> > + ? ? ? return omap_control_module->dev;
> > +}
> > +EXPORT_SYMBOL_GPL(omap_control_get);
> > +
> > +/**
> > + * omap_control_put: returns the control module device pinter
> > + *
> > + * The modules which has to use control module API's to read or write should
> > + * call this API to get the control module device pointer.
> > + */
> > +void omap_control_put(struct device *dev)
> > +{
> > + ? ? ? struct omap_control *omap_control = dev_get_drvdata(dev);
> > + ? ? ? unsigned long flags;
> > +
> > + ? ? ? if (!omap_control)
> > + ? ? ? ? ? ? ? return;
> > +
> > + ? ? ? spin_lock_irqsave(&omap_control->reg_lock, flags);
> > + ? ? ? omap_control->use_count--;
> > + ? ? ? spin_unlock_irqrestore(&omap_control_module->reg_lock, flags);
> > +}
> > +EXPORT_SYMBOL_GPL(omap_control_put);
> > +
> > +static const struct of_device_id of_omap_control_match[] = {
> > + ? ? ? { .compatible = "ti,omap3-control", },
> > + ? ? ? { .compatible = "ti,omap4-control", },
> > + ? ? ? { .compatible = "ti,omap5-control", },
> > + ? ? ? { },
> > +};
> > +
> > +static int __devinit omap_control_probe(struct platform_device *pdev)
> > +{
> > + ? ? ? struct resource *res;
> > + ? ? ? void __iomem *base;
> > + ? ? ? struct device *dev = &pdev->dev;
> > + ? ? ? struct device_node *np = dev->of_node;
> > + ? ? ? struct omap_control *omap_control;
> > +
> > + ? ? ? omap_control = devm_kzalloc(dev, sizeof(*omap_control), GFP_KERNEL);
> > + ? ? ? if (!omap_control) {
> > + ? ? ? ? ? ? ? dev_err(dev, "not enough memory for omap_control\n");
> > + ? ? ? ? ? ? ? return -ENOMEM;
> > + ? ? ? }
> > +
> > + ? ? ? res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > + ? ? ? if (!res) {
> > + ? ? ? ? ? ? ? dev_err(dev, "missing memory base resource\n");
> > + ? ? ? ? ? ? ? return -EINVAL;
> > + ? ? ? }
> > +
> > + ? ? ? base = devm_request_and_ioremap(dev, res);
> > + ? ? ? if (!base) {
> > + ? ? ? ? ? ? ? dev_err(dev, "ioremap failed\n");
> > + ? ? ? ? ? ? ? return -EADDRNOTAVAIL;
> > + ? ? ? }
> > +
> > + ? ? ? omap_control->base = base;
> > + ? ? ? omap_control->dev = dev;
> > + ? ? ? spin_lock_init(&omap_control->reg_lock);
> > +
> > + ? ? ? platform_set_drvdata(pdev, omap_control);
> > + ? ? ? omap_control_module = omap_control;
> > +
> > + ? ? ? return of_platform_populate(np, of_omap_control_match, NULL, dev);
> > +}
> > +
>
> Will the probe get called on multiple devices and race ?
It depends. If we decide to have an early device for scm, then the probe will
be called more than once. If not, then only once.
>
> > +static int __devexit omap_control_remove(struct platform_device *pdev)
> > +{
> > + ? ? ? struct omap_control *omap_control = platform_get_drvdata(pdev);
> > +
> > + ? ? ? spin_lock(&omap_control->reg_lock);
> > + ? ? ? if (omap_control->use_count > 0) {
> > + ? ? ? ? ? ? ? spin_unlock(&omap_control->reg_lock);
> > + ? ? ? ? ? ? ? dev_err(&pdev->dev, "device removed while still being used\n");
> > + ? ? ? ? ? ? ? return -EBUSY;
> > + ? ? ? }
> > + ? ? ? spin_unlock(&omap_control->reg_lock);
> > +
> Do you really need above lock where you are just doing the
> register read. smp_rmb(), should be enough, I guess.
It is locking the use counter not a register..
>
> Regards
> Santosh
next prev parent reply other threads:[~2012-05-28 11:42 UTC|newest]
Thread overview: 198+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-25 8:25 [RFC PATCH 00/11] OMAP System Control Module Eduardo Valentin
2012-05-25 8:25 ` Eduardo Valentin
2012-05-25 8:25 ` [RFC PATCH 01/11] ARM: OMAP4: Remove un-used control module headers and defines Eduardo Valentin
2012-05-25 8:25 ` Eduardo Valentin
2012-05-28 9:12 ` Shilimkar, Santosh
2012-05-28 9:12 ` Shilimkar, Santosh
2012-05-25 8:25 ` [RFC PATCH 02/11] ARM: OMAP: expose control.h to mach area Eduardo Valentin
2012-05-25 8:25 ` Eduardo Valentin
2012-05-28 9:25 ` Shilimkar, Santosh
2012-05-28 9:25 ` Shilimkar, Santosh
2012-05-28 10:30 ` Valentin, Eduardo
2012-05-28 10:30 ` Valentin, Eduardo
2012-06-01 11:19 ` Tony Lindgren
2012-06-01 11:19 ` Tony Lindgren
2012-05-25 8:25 ` [RFC PATCH 03/11] arm: omap: device: create a device for system control module Eduardo Valentin
2012-05-25 8:25 ` Eduardo Valentin
2012-05-25 12:30 ` Cousson, Benoit
2012-05-25 12:30 ` Cousson, Benoit
2012-05-29 9:44 ` Eduardo Valentin
2012-05-29 9:44 ` Eduardo Valentin
2012-06-14 13:50 ` Konstantin Baydarov
2012-06-14 13:50 ` Konstantin Baydarov
2012-06-15 9:22 ` Valentin, Eduardo
2012-06-15 9:22 ` Valentin, Eduardo
2012-05-29 13:39 ` Konstantin Baydarov
2012-05-29 13:39 ` Konstantin Baydarov
2012-05-25 8:25 ` [RFC PATCH 04/11] OMAP: Add early " Eduardo Valentin
2012-05-25 8:25 ` Eduardo Valentin
2012-05-25 11:32 ` Konstantin Baydarov
2012-05-25 11:32 ` Konstantin Baydarov
2012-05-25 11:44 ` Valentin, Eduardo
2012-05-25 11:44 ` Valentin, Eduardo
2012-05-25 11:54 ` Konstantin Baydarov
2012-05-25 11:54 ` Konstantin Baydarov
2012-05-25 12:32 ` Cousson, Benoit
2012-05-25 12:32 ` Cousson, Benoit
2012-05-28 9:58 ` Shilimkar, Santosh
2012-05-28 9:58 ` Shilimkar, Santosh
2012-05-25 8:25 ` [RFC PATCH 05/11] mfd: omap: control: core system control driver Eduardo Valentin
2012-05-25 8:25 ` Eduardo Valentin
2012-05-25 12:52 ` Cousson, Benoit
2012-05-25 12:52 ` Cousson, Benoit
2012-05-28 11:35 ` Eduardo Valentin
2012-05-28 11:35 ` Eduardo Valentin
2012-05-29 13:25 ` Cousson, Benoit
2012-05-29 13:25 ` Cousson, Benoit
2012-06-01 11:29 ` Tony Lindgren
2012-06-01 11:29 ` Tony Lindgren
2012-06-01 12:30 ` Shilimkar, Santosh
2012-06-01 12:30 ` Shilimkar, Santosh
2012-06-01 12:43 ` Cousson, Benoit
2012-06-01 12:43 ` Cousson, Benoit
2012-06-01 17:19 ` Eduardo Valentin
2012-06-01 17:19 ` Eduardo Valentin
2012-06-01 13:40 ` Konstantin Baydarov
2012-06-01 13:40 ` Konstantin Baydarov
2012-06-01 14:13 ` Tony Lindgren
2012-06-01 14:13 ` Tony Lindgren
2012-06-01 14:26 ` Konstantin Baydarov
2012-06-01 14:26 ` Konstantin Baydarov
2012-05-28 9:54 ` Shilimkar, Santosh
2012-05-28 9:54 ` Shilimkar, Santosh
2012-05-28 11:42 ` Eduardo Valentin [this message]
2012-05-28 11:42 ` Eduardo Valentin
2012-05-28 13:15 ` Shilimkar, Santosh
2012-05-28 13:15 ` Shilimkar, Santosh
2012-05-29 13:31 ` Cousson, Benoit
2012-05-29 13:31 ` Cousson, Benoit
2012-05-25 8:25 ` [RFC PATCH 06/11] OMAP2+: use control module mfd driver in omap_type Eduardo Valentin
2012-05-25 8:25 ` Eduardo Valentin
2012-05-25 12:53 ` Cousson, Benoit
2012-05-25 12:53 ` Cousson, Benoit
2012-05-28 10:02 ` Shilimkar, Santosh
2012-05-28 10:02 ` Shilimkar, Santosh
2012-05-28 11:24 ` Eduardo Valentin
2012-05-28 11:24 ` Eduardo Valentin
2012-06-01 11:35 ` Tony Lindgren
2012-06-01 11:35 ` Tony Lindgren
2012-05-25 8:25 ` [RFC PATCH 07/11] mfd: omap: control: usb-phy: introduce the ctrl-module usb driver Eduardo Valentin
2012-05-25 8:25 ` Eduardo Valentin
2012-05-25 13:35 ` Shubhrajyoti Datta
2012-05-25 13:35 ` Shubhrajyoti Datta
2012-05-25 15:06 ` Cousson, Benoit
2012-05-25 15:06 ` Cousson, Benoit
2012-06-01 11:38 ` Tony Lindgren
2012-06-01 11:38 ` Tony Lindgren
2012-06-01 13:20 ` [linux-pm] " Tony Lindgren
2012-06-01 13:20 ` Tony Lindgren
2012-06-01 14:07 ` Kevin Hilman
2012-06-01 14:07 ` Kevin Hilman
2012-06-01 14:15 ` Tony Lindgren
2012-06-01 14:15 ` Tony Lindgren
2012-05-25 8:25 ` [RFC PATCH 08/11] ARM: OMAP4+: Adding the temperature sensor register set bit fields Eduardo Valentin
2012-05-25 8:25 ` Eduardo Valentin
2012-05-25 15:13 ` Cousson, Benoit
2012-05-25 15:13 ` Cousson, Benoit
2012-05-28 11:17 ` Eduardo Valentin
2012-05-28 11:17 ` Eduardo Valentin
2012-05-28 10:04 ` Shilimkar, Santosh
2012-05-28 10:04 ` Shilimkar, Santosh
2012-05-28 11:18 ` Eduardo Valentin
2012-05-28 11:18 ` Eduardo Valentin
2012-05-25 8:25 ` [RFC PATCH 09/11] ARM: OMAP4+: thermal: introduce bandgap temperature sensor Eduardo Valentin
2012-05-25 8:25 ` Eduardo Valentin
2012-05-25 15:49 ` Cousson, Benoit
2012-05-25 15:49 ` Cousson, Benoit
2012-05-28 11:06 ` Eduardo Valentin
2012-05-28 11:06 ` Eduardo Valentin
2012-05-28 11:16 ` Eduardo Valentin
2012-05-28 11:16 ` Eduardo Valentin
2012-05-29 13:14 ` Cousson, Benoit
2012-05-29 13:14 ` Cousson, Benoit
2012-05-29 17:51 ` Mike Turquette
2012-05-29 17:51 ` Mike Turquette
2012-05-25 16:39 ` Konstantin Baydarov
2012-05-25 16:39 ` Konstantin Baydarov
2012-05-28 10:55 ` Eduardo Valentin
2012-05-28 10:55 ` Eduardo Valentin
2012-06-01 11:42 ` Tony Lindgren
2012-06-01 11:42 ` Tony Lindgren
2012-05-25 8:26 ` [RFC PATCH 10/11] omap4: thermal: add basic CPU thermal zone Eduardo Valentin
2012-05-25 8:26 ` Eduardo Valentin
2012-05-28 9:33 ` Shilimkar, Santosh
2012-05-28 9:33 ` Shilimkar, Santosh
2012-05-28 9:48 ` Felipe Balbi
2012-05-28 9:48 ` Felipe Balbi
2012-05-28 10:26 ` Valentin, Eduardo
2012-05-28 10:26 ` Valentin, Eduardo
2012-05-29 12:54 ` Cousson, Benoit
2012-05-29 12:54 ` Cousson, Benoit
2012-05-25 8:26 ` [RFC PATCH 11/11] ARM: DT: Add support to system control module for OMAP4 Eduardo Valentin
2012-05-25 8:26 ` Eduardo Valentin
2012-05-29 9:49 ` Konstantin Baydarov
2012-05-29 9:49 ` Konstantin Baydarov
2012-05-30 8:38 ` Cousson, Benoit
2012-05-30 8:38 ` Cousson, Benoit
2012-05-30 9:05 ` Konstantin Baydarov
2012-05-30 9:05 ` Konstantin Baydarov
2012-05-30 9:26 ` Cousson, Benoit
2012-05-30 9:26 ` Cousson, Benoit
2012-05-30 10:17 ` Konstantin Baydarov
2012-05-30 10:17 ` Konstantin Baydarov
2012-05-30 10:22 ` Cousson, Benoit
2012-05-30 10:22 ` Cousson, Benoit
2012-05-30 10:42 ` Eduardo Valentin
2012-05-30 10:42 ` Eduardo Valentin
2012-05-30 12:16 ` Cousson, Benoit
2012-05-30 12:16 ` Cousson, Benoit
2012-05-31 12:06 ` Konstantin Baydarov
2012-05-31 12:06 ` Konstantin Baydarov
2012-05-31 12:49 ` Eduardo Valentin
2012-05-31 12:49 ` Eduardo Valentin
2012-05-31 12:52 ` Cousson, Benoit
2012-05-31 12:52 ` Cousson, Benoit
2012-05-31 14:51 ` Konstantin Baydarov
2012-05-31 14:51 ` Konstantin Baydarov
2012-05-25 8:35 ` [RFC PATCH 00/11] OMAP System Control Module Eduardo Valentin
2012-05-25 8:35 ` Eduardo Valentin
2012-05-25 10:50 ` Konstantin Baydarov
2012-05-25 10:50 ` Konstantin Baydarov
2012-05-25 11:11 ` Valentin, Eduardo
2012-05-25 11:11 ` Valentin, Eduardo
2012-05-25 12:21 ` Konstantin Baydarov
2012-05-25 12:21 ` Konstantin Baydarov
2012-06-01 0:12 ` [linux-pm] " Kevin Hilman
2012-06-01 0:12 ` Kevin Hilman
2012-06-18 11:32 ` [RFC PATCH v2 01/11] ARM: OMAP4: Remove un-used control module headers and defines Konstantin Baydarov
2012-06-18 11:32 ` Konstantin Baydarov
2012-06-18 11:32 ` [RFC PATCH v2 02/11] ARM: OMAP: expose control.h to mach area Konstantin Baydarov
2012-06-18 11:32 ` Konstantin Baydarov
2012-06-20 10:17 ` Tony Lindgren
2012-06-20 10:17 ` Tony Lindgren
2012-06-18 11:32 ` [RFC PATCH v2 03/11] mfd: omap: control: core system control driver Konstantin Baydarov
2012-06-18 11:32 ` Konstantin Baydarov
2012-06-20 10:22 ` Tony Lindgren
2012-06-20 10:22 ` Tony Lindgren
2012-06-20 14:13 ` Konstantin Baydarov
2012-06-20 14:13 ` Konstantin Baydarov
2012-06-26 11:17 ` Tony Lindgren
2012-06-26 11:17 ` Tony Lindgren
2012-06-18 11:32 ` [RFC PATCH v2 04/11] OMAP2+: use control module mfd driver in omap_type Konstantin Baydarov
2012-06-18 11:32 ` Konstantin Baydarov
2012-06-20 10:24 ` Tony Lindgren
2012-06-20 10:24 ` Tony Lindgren
2012-06-18 11:32 ` [RFC PATCH v2 05/11] mfd: omap: control: usb-phy: introduce the ctrl-module usb driver Konstantin Baydarov
2012-06-18 11:32 ` Konstantin Baydarov
2012-06-18 11:32 ` [RFC PATCH v2 06/11] ARM: OMAP4+: Adding the temperature sensor register set bit fields Konstantin Baydarov
2012-06-18 11:32 ` Konstantin Baydarov
2012-06-20 10:25 ` Tony Lindgren
2012-06-20 10:25 ` Tony Lindgren
2012-06-18 11:32 ` [RFC PATCH v2 07/11] ARM: OMAP4+: thermal: introduce bandgap temperature sensor Konstantin Baydarov
2012-06-18 11:32 ` Konstantin Baydarov
2012-06-18 11:32 ` [RFC PATCH v2 08/11] omap4: thermal: add basic CPU thermal zone Konstantin Baydarov
2012-06-18 11:32 ` Konstantin Baydarov
2012-06-18 11:32 ` [RFC PATCH v2 09/11] ARM: DT: Add support to system control module for OMAP4 Konstantin Baydarov
2012-06-18 11:32 ` Konstantin Baydarov
2012-06-18 12:13 ` Sergei Shtylyov
2012-06-18 12:13 ` Sergei Shtylyov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120528114225.GH3923@besouro \
--to=eduardo.valentin@ti.com \
--cc=amit.kucheria@linaro.org \
--cc=balbi@ti.com \
--cc=j-keerthy@ti.com \
--cc=kbaidarov@dev.rtsoft.ru \
--cc=kishon@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux-pm@lists.linux-foundation.org \
--cc=santosh.shilimkar@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.