Re: [GIT PULL] ARM: OMAP: Device Tree for 3.11
Arnd & Olof, * Benoit Cousson [130619 16:10]: > Hi Tony, > > Please pull the following commits for OMAP Device Tree for v3.11. > > It does contains as well 2 clock data patches, I hope it will not generate > any conflict with Paul's tree. > > Special thanks to Florian for his nice cleanup using the C preprocessor. It's best that Arnd and Olof take this pull request directly as we're getting so close to the merge window. These patches should be pretty much independent of the other branches I've sent, and are needed to keep omap4 booting now that we've flipped the switch for omap4 to be DT only. Regards, Tony > The following changes since commit 7d132055814ef17a6c7b69f342244c410a5e000f: > > Linux 3.10-rc6 (2013-06-15 11:51:07 -1000) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git > for_3.11/dts > > for you to fetch changes up to 153030c22defea2f96546d0f1a74fe954551c4cd: > > ARM: dts: omap5-uevm: Provide USB Host PHY clock frequency (2013-06-19 > 16:59:28 -0500) > > > Afzal Mohammed (2): > ARM: dts: AM43x: Initial support > ARM: dts: AM43x EPOS EVM support > > Dan Murphy (3): > ARM: dts: omap4-panda: Update the LED support for the panda > ARM: dts: omap4-panda: Update the twl6040 gpio to macro definition > ARM: dts: omap5-uevm: Add LED support for uEVM blue LED > > Eduardo Valentin (3): > ARM: dts: OMAP443x: Add bandgap entry for OMAP443x devices > ARM: dts: OMAP4460: Add bandgap entry for OMAP4460 devices > ARM: dts: OMAP5: Add bandgap DT entry > > Florian Vaussard (15): > ARM: dts: OMAP2+: Use #include for all device trees > ARM: dts: OMAP2+: Use existing constants for GPIOs > ARM: dts: OMAP4/5: Use existing constants for IRQs > ARM: dts: OMAP2+: Header file for pinctrl constants > ARM: dts: OMAP2+: Use pinctrl constants > ARM: dts: AM3XXX: Use #include for all device trees > ARM: dts: AM33XX: Use existing constants for GPIOs > ARM: dts: AM33XX: Specific pinctrl header > ARM: dts: AM33XX: Use pinctrl constants > ARM: dts: OMAP4/AM35xx: Add missing dtb in the dtbs target > ARM: dts: Protect pinctrl headers against multiple inclusions > ARM: dts: OMAP3: Include IRQ header > ARM: dts: omap3-tobi: Add SMSC911X node > ARM: dts: omap3-tobi: Correct polarity for GPIO LED > ARM: dts: omap3-overo: Add default trigger for TWL4030 LED > > J Keerthy (1): > ARM: dts: OMAP5: Add Palmas MFD node and regulator nodes > > Javier Martinez Canillas (3): > ARM: dts: omap3-igep0020: Add SMSC911x LAN chip support > ARM: dts: omap3-igep0020: Add NAND flash support > ARM: dts: omap3-igep0030: Add NAND flash support > > Kevin Hilman (3): > ARM: dts: OMAP3: beagle/overo: mux console UART, enable wakeup > ARM: dts: OMAP3: beagle: enable user button via gpio_keys, enable wakeup > ARM: dts: TWL4030: fix mux and wakeup for SYS_NIRQ line > > Mugunthan V N (3): > ARM: dts: AM33XX: Add pinmux configuration for CPSW to beaglebone > ARM: dts: AM33XX: Add pinmux configuration for CPSW to EVMsk > ARM: dts: AM33XX: Add pinmux configuration for CPSW to am335x EVM > > Philip Avinash (4): > ARM: dts: AM33XX: Add NAND flash device tree data to am335x-evm > ARM: dts: AM33XX: Add PWMSS device tree nodes > ARM: dts: AM33XX: Add PWM backlight DT data to am335x-evm > ARM: dts: AM33XX: Add PWM backlight DT data to am335x-evmsk > > Philip, Avinash (1): > ARM: dts: AM33XX: Add ELM node > > Roger Quadros (4): > ARM: dts: omap5-uevm: Add USB Host support > ARM: dts: omap4-panda: Add USB Host support > ARM: dts: omap4-panda: Fix DVI EDID reads > ARM: dts: omap5-uevm: Provide USB Host PHY clock frequency > > Sourav Poddar (1): > ARM: dts: omap5-uevm: Add uart pinctrl data > > Sricharan R (1): > ARM: dts: omap5: Make uevm as the official board and deprecate sevm > support > > Suman Anna (1): > ARM: dts: OMAP4+: Remove multimedia carveouts > > Vaibhav Hiremath (7): > ARM: dts: AM33XX: Add default pinctrl binding for I2C device > ARM: dts: AM33XX: Add pinctrl binding to gpio-leds node > ARM: dts: AM33XX: Fix uart numbering to match hardware/TRM > ARM: dts: AM33XX: Add default pinctrl binding for UART0 device > ARM: dts: AM33XX: Set pinmux for clkout2 pad used for clock output > ARM: AM33XX: clock: Add debugSS clock nodes > ARM: AM33XX: clock data: Enable clkout2 as part of init > > .../devicetree/bindings/arm/omap/omap.txt |3 + > arch/arm/boot/dts/Makefile |8 +- > arch/arm/boot/dts/am335x-bone.dts | 118 - > arch/arm/boot/dts/am335x-evm.dts | 264 ++- > arch/arm/boot/dts/am335x-evmsk.dts
RE: [PATCH v5, 0/3] DT support for NAND on OMAP2
Hi, In the following series, 1 got merged, while other 2 are awaiting. Request you to please look into these. [PATCH 1/3] ARM: dts: AM33XX: Add ELM node -- awaiting -- [PATCH 2/3a] ARM: dts: AM33XX: Add GPMC node -- accepted by Tony [PATCH 2/3b] ARM: dts: AM33xx: Fix properties on gpmc node -- accepted by Benoit (follow-up) [PATCH 3/3] ARM: dts: AM33XX: Add NAND flash device tree data to am335x-evm --awaiting -- with regards, pekon > -Original Message- > From: Gupta, Pekon > Sent: Friday, May 31, 2013 1:19 PM > To: Tony Lindgren; linux-omap@vger.kernel.org > Cc: Gupta, Pekon; Philip, Avinash; Nori, Sekhar; Balbi, Felipe; Hiremath, > Vaibhav; Cousson, Benoit; jac...@sunsite.dk; zon...@gmail.com; Jon > Hunter > Subject: [PATCH v5, 0/3] DT support for NAND on OMAP2 > > From: "Gupta, Pekon" > > Changes v4->v5 > - updated commit descriptions. > - included patch by "Lars Poeschel" instead of [Patch 2/3] > > Changes v3->v4 > - rebased to linux-3.10-rc3 > - updated newly supported DT properties based on following > commits > [d36b4cd] jon-hun...@ti.com ARM: OMAP2+: Add additional GPMC > timing ... > [8c8a777] jon-hun...@ti.com ARM: OMAP2+: Add function to read > GPMC ... > [9f83315] jon-hun...@ti.com ARM: OMAP2+: Add variable to store > number > > Changes v2->v3 > - rebased to linux-3.9-rc8 > - AM335x-evm.dts: moved GPMC pin-mux config to nand node > > Changes v1->v2 > - Change number of chip select to 7 > - Replace literals to 52 > - remove tab > > Lars Poeschel (1): > dts: am33xx: Correct properties on gpmc node > > Philip Avinash (1): > ARM: dts: AM33XX: Add NAND flash device tree data to am335x-evm > > Philip, Avinash (1): > ARM: dts: AM33XX: Add ELM node > > arch/arm/boot/dts/am335x-evm.dts | 105 > +++ > arch/arm/boot/dts/am33xx.dtsi| 12 - > 2 files changed, 115 insertions(+), 2 deletions(-) > > -- > 1.8.1 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ARM: OMAP2: reboot: Include common.h to fix build error
Hi,
On Wed, Jun 19, 2013 at 23:16:41, Axel Lin wrote:
> Include common.h which will include linux/reboot.h to fix below build error.
>
> CC arch/arm/mach-omap2/omap4-restart.o
> arch/arm/mach-omap2/omap4-restart.c:21:28: warning: 'enum reboot_mode'
> declared inside parameter list [enabled by default]
> arch/arm/mach-omap2/omap4-restart.c:21:28: warning: its scope is only this
> definition or declaration, which is probably not what you want [enabled by
> default]
> arch/arm/mach-omap2/omap4-restart.c:21:40: error: parameter 1 ('mode') has
> incomplete type
> arch/arm/mach-omap2/omap4-restart.c:21:6: warning: function declaration isn't
> a prototype [-Wstrict-prototypes]
> make[1]: *** [arch/arm/mach-omap2/omap4-restart.o] Error 1
> make: *** [arch/arm/mach-omap2] Error 2
>
> Signed-off-by: Axel Lin
> ---
> Seems this build error is introduced by commit 7507d035f3cf40c
> "reboot: arm: change reboot_mode to use enum reboot_mode"
>
> This patch is against linux-next 20130619.
> diff --git a/arch/arm/mach-omap2/omap4-restart.c
> b/arch/arm/mach-omap2/omap4-restart.c
> index 652adde..7306d9b 100644
> --- a/arch/arm/mach-omap2/omap4-restart.c
> +++ b/arch/arm/mach-omap2/omap4-restart.c
> @@ -9,6 +9,7 @@
>
> #include
> #include "prminst44xx.h"
> +#include "common.h"
Arnd has posted a patch [1] that includes reboot.h directly for
multiple platforms including this one.
Regards
Afzal
[1] https://lkml.org/lkml/2013/6/19/498
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj"��!�i
Re: [PATCH v7 1/9] drivers: phy: add generic PHY framework
Hi,
On Wednesday 19 June 2013 09:19 PM, Sylwester Nawrocki wrote:
Hi,
On 06/13/2013 10:43 AM, Kishon Vijay Abraham I wrote:
+/**
+ * phy_create() - create a new phy
+ * @dev: device that is creating the new phy
+ * @id: id of the phy
+ * @ops: function pointers for performing phy operations
+ * @label: label given to the phy
+ * @priv: private data from phy driver
+ *
+ * Called to create a phy using phy framework.
+ */
+struct phy *phy_create(struct device *dev, u8 id, const struct phy_ops *ops,
+ const char *label, void *priv)
+{
+ int ret;
+ struct phy *phy;
+
+ if (!dev) {
+ dev_WARN(dev, "no device provided for PHY\n");
+ ret = -EINVAL;
+ goto err0;
+ }
+
+ phy = kzalloc(sizeof(*phy), GFP_KERNEL);
+ if (!phy) {
+ ret = -ENOMEM;
+ goto err0;
+ }
+
+ device_initialize(&phy->dev);
+
+ phy->dev.class = phy_class;
+ phy->dev.parent = dev;
+ phy->dev.of_node = dev->of_node;
+ phy->id = id;
+ phy->ops = ops;
+ phy->label = label;
Perhaps we could make it:
phy->label = kstrdup(label, GFP_KERNEL);
and free the label in phy_destroy() ?
yeah.. Fixed.
That way the users would't need to keep the label around. It might
be useful when PHY provider generates the labels dynamically. I guess
it is OK for PHY providers to hard code the labels and having the PHY
user drivers passed labels in platform data ?
yeah. But the only concern here is there is no way to enforce the
labels are passed in platform data. The PHY user driver can also
hard code the labels while getting the reference to the PHY and we can
catch such cases only by review.
+ dev_set_drvdata(&phy->dev, priv);
+
+ ret = dev_set_name(&phy->dev, "%s.%d", dev_name(dev), id);
+ if (ret)
+ goto err1;
+
+ ret = device_add(&phy->dev);
+ if (ret)
+ goto err1;
+
+ if (pm_runtime_enabled(dev))
+ pm_runtime_enable(&phy->dev);
+
+ return phy;
+
+err1:
+ put_device(&phy->dev);
+ kfree(phy);
+
+err0:
+ return ERR_PTR(ret);
+}
+EXPORT_SYMBOL_GPL(phy_create);
+/**
+ * phy_destroy() - destroy the phy
+ * @phy: the phy to be destroyed
+ *
+ * Called to destroy the phy.
+ */
+void phy_destroy(struct phy *phy)
+{
+ pm_runtime_disable(&phy->dev);
+ device_unregister(&phy->dev);
Isn't kfree(phy); missing here ?
Not actually. Its done in phy_release (class's dev_release method)
Thanks
Kishon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v11 3/8] ARM: edma: Add EDMA crossbar event mux support
On 6/20/2013 6:06 AM, Joel A Fernandes wrote:
>>> + /* Clear the xbar mapped channels in unused list */
>>> + xbar_chans = info[j]->xbar_chans;
>>> + if (xbar_chans) {
>>> + for (i = 0; xbar_chans[i][1] != -1; i++) {
>>> + off = xbar_chans[i][1];
>>> + clear_bits(off, 1,
>>> + edma_cc[j]->edma_unused);
>>
>> Please fix the alignment here.
>
> I noticed the alignment was off in a few other places in that driver.
> Fixed those up too.
If you do, please make it a separate (pre)patch.
Thanks,
Sekhar
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3 2/4] MFD: Palmas: Add SMPS10_BOOST feature
Hello Samuel,
> -Original Message-
> From: J, KEERTHY
> Sent: Wednesday, June 19, 2013 11:28 AM
> To: linux-omap@vger.kernel.org
> Cc: broo...@kernel.org; J, KEERTHY; ldewan...@nvidia.com;
> sa...@linux.intel.com; grant.lik...@secretlab.ca; swar...@nvidia.com;
> linux-ker...@vger.kernel.org; linux-...@vger.kernel.org; devicetree-
> disc...@lists.ozlabs.org; g...@slimlogic.co.uk
> Subject: [PATCH v3 2/4] MFD: Palmas: Add SMPS10_BOOST feature
>
> From: J Keerthy
>
> The SMPS10 regulator is not presesnt in all the variants of the PALMAS
> PMIC family. Hence adding a feature to distingush between them.
>
Could you please pull this patch?
> Signed-off-by: J Keerthy
> ---
> drivers/mfd/palmas.c | 27 --
> -
> drivers/regulator/palmas-regulator.c |3 +++
> include/linux/mfd/palmas.h | 14 ++
> 3 files changed, 37 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/mfd/palmas.c b/drivers/mfd/palmas.c index
> b24bee3..1cacc6a 100644
> --- a/drivers/mfd/palmas.c
> +++ b/drivers/mfd/palmas.c
> @@ -231,6 +231,16 @@ static void palmas_dt_to_pdata(struct i2c_client
> *i2c,
> palmas_set_pdata_irq_flag(i2c, pdata); }
>
> +static unsigned int palmas_features =
> PALMAS_PMIC_FEATURE_SMPS10_BOOST;
> +
> +static const struct of_device_id of_palmas_match_tbl[] = {
> + {
> + .compatible = "ti,palmas",
> + .data = &palmas_features,
> + },
> + { },
> +};
> +
> static int palmas_i2c_probe(struct i2c_client *i2c,
> const struct i2c_device_id *id)
> {
> @@ -238,8 +248,9 @@ static int palmas_i2c_probe(struct i2c_client *i2c,
> struct palmas_platform_data *pdata;
> struct device_node *node = i2c->dev.of_node;
> int ret = 0, i;
> - unsigned int reg, addr;
> + unsigned int reg, addr, *features;
> int slave;
> + const struct of_device_id *match;
>
> pdata = dev_get_platdata(&i2c->dev);
>
> @@ -261,9 +272,16 @@ static int palmas_i2c_probe(struct i2c_client
> *i2c,
>
> i2c_set_clientdata(i2c, palmas);
> palmas->dev = &i2c->dev;
> - palmas->id = id->driver_data;
> palmas->irq = i2c->irq;
>
> + match = of_match_device(of_match_ptr(of_palmas_match_tbl), &i2c-
> >dev);
> +
> + if (!match)
> + return -ENODATA;
> +
> + features = (unsigned int *)match->data;
> + palmas->features = *features;
> +
> for (i = 0; i < PALMAS_NUM_CLIENTS; i++) {
> if (i == 0)
> palmas->i2c_clients[i] = i2c;
> @@ -433,11 +451,6 @@ static const struct i2c_device_id palmas_i2c_id[]
> = { }; MODULE_DEVICE_TABLE(i2c, palmas_i2c_id);
>
> -static struct of_device_id of_palmas_match_tbl[] = {
> - { .compatible = "ti,palmas", },
> - { /* end */ }
> -};
> -
> static struct i2c_driver palmas_i2c_driver = {
> .driver = {
> .name = "palmas",
> diff --git a/drivers/regulator/palmas-regulator.c
> b/drivers/regulator/palmas-regulator.c
> index 3ae44ac..1ae1e83 100644
> --- a/drivers/regulator/palmas-regulator.c
> +++ b/drivers/regulator/palmas-regulator.c
> @@ -838,6 +838,9 @@ static int palmas_regulators_probe(struct
> platform_device *pdev)
> continue;
> ramp_delay_support = true;
> break;
> + case PALMAS_REG_SMPS10:
> + if (!PALMAS_PMIC_HAS(palmas, SMPS10_BOOST))
> + continue;
> }
>
> if ((id == PALMAS_REG_SMPS6) || (id == PALMAS_REG_SMPS8))
> diff --git a/include/linux/mfd/palmas.h b/include/linux/mfd/palmas.h
> index 8f21daf..98058ca 100644
> --- a/include/linux/mfd/palmas.h
> +++ b/include/linux/mfd/palmas.h
> @@ -32,6 +32,19 @@
> ((a) == PALMAS_CHIP_ID))
> #define is_palmas_charger(a) ((a) == PALMAS_CHIP_CHARGER_ID)
>
> +/**
> + * Palmas PMIC feature types
> + *
> + * PALMAS_PMIC_FEATURE_SMPS10_BOOST - used when the PMIC provides
> SMPS10_BOOST
> + * regulator.
> + *
> + * PALMAS_PMIC_HAS(b, f) - macro to check if a bandgap device is
> capable of a
> + * specific feature (above) or not. Return non-zero, if yes.
> + */
> +#define PALMAS_PMIC_FEATURE_SMPS10_BOOST BIT(0)
> +#define PALMAS_PMIC_HAS(b, f)\
> + ((b)->features & PALMAS_PMIC_FEATURE_ ## f)
> +
> struct palmas_pmic;
> struct palmas_gpadc;
> struct palmas_resource;
> @@ -46,6 +59,7 @@ struct palmas {
> /* Stored chip id */
> int id;
>
> + unsigned int features;
> /* IRQ Data */
> int irq;
> u32 irq_mask;
> --
> 1.7.5.4
Regards,
Keerthy
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3 1/4] MFD: Palmas: Check if irq is valid
Hi Samuel, > -Original Message- > From: Stephen Warren [mailto:swar...@wwwdotorg.org] > Sent: Wednesday, June 19, 2013 10:39 PM > To: J, KEERTHY > Cc: linux-omap@vger.kernel.org; broo...@kernel.org; > ldewan...@nvidia.com; sa...@linux.intel.com; grant.lik...@secretlab.ca; > swar...@nvidia.com; linux-ker...@vger.kernel.org; linux- > d...@vger.kernel.org; devicetree-disc...@lists.ozlabs.org; > g...@slimlogic.co.uk > Subject: Re: [PATCH v3 1/4] MFD: Palmas: Check if irq is valid > > On 06/18/2013 11:57 PM, Keerthy wrote: > > From: J Keerthy > > > > Check if irq value obtained is valid. If it is not valid then skip > the > > irq request step and go ahead with the probe. > > Reviewed-by: Stephen Warren Could you please pull this? Kind Regards, Keerthy -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3 1/4] MFD: Palmas: Check if irq is valid
> -Original Message- > From: Stephen Warren [mailto:swar...@wwwdotorg.org] > Sent: Wednesday, June 19, 2013 10:39 PM > To: J, KEERTHY > Cc: linux-omap@vger.kernel.org; broo...@kernel.org; > ldewan...@nvidia.com; sa...@linux.intel.com; grant.lik...@secretlab.ca; > swar...@nvidia.com; linux-ker...@vger.kernel.org; linux- > d...@vger.kernel.org; devicetree-disc...@lists.ozlabs.org; > g...@slimlogic.co.uk > Subject: Re: [PATCH v3 1/4] MFD: Palmas: Check if irq is valid > > On 06/18/2013 11:57 PM, Keerthy wrote: > > From: J Keerthy > > > > Check if irq value obtained is valid. If it is not valid then skip > the > > irq request step and go ahead with the probe. > > Reviewed-by: Stephen Warren Thanks Stephen. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3 4/4] regulator: Palmas: Add TPS659038 support
> -Original Message- > From: Mark Brown [mailto:broo...@kernel.org] > Sent: Wednesday, June 19, 2013 10:12 PM > To: J, KEERTHY > Cc: linux-omap@vger.kernel.org; ldewan...@nvidia.com; > sa...@linux.intel.com; grant.lik...@secretlab.ca; swar...@nvidia.com; > linux-ker...@vger.kernel.org; linux-...@vger.kernel.org; devicetree- > disc...@lists.ozlabs.org; g...@slimlogic.co.uk > Subject: Re: [PATCH v3 4/4] regulator: Palmas: Add TPS659038 support > > On Wed, Jun 19, 2013 at 11:27:50AM +0530, Keerthy wrote: > > From: J Keerthy > > > > Add TPS659038 support. > > > > Signed-off-by: J Keerthy > > This doesn't apply against my current tree as the PMIC bindings > document isn't in mainline yet. It was pulled by Grant. > > Acked-by: Mark Brown > > assuming there's a tree where that does exist. Thanks. I will check if Grant can pull this. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3 1/4] MFD: Palmas: Check if irq is valid
> -Original Message- > From: Mark Brown [mailto:broo...@kernel.org] > Sent: Wednesday, June 19, 2013 10:13 PM > To: J, KEERTHY > Cc: linux-omap@vger.kernel.org; ldewan...@nvidia.com; > sa...@linux.intel.com; grant.lik...@secretlab.ca; swar...@nvidia.com; > linux-ker...@vger.kernel.org; linux-...@vger.kernel.org; devicetree- > disc...@lists.ozlabs.org; g...@slimlogic.co.uk > Subject: Re: [PATCH v3 1/4] MFD: Palmas: Check if irq is valid > > On Wed, Jun 19, 2013 at 11:27:47AM +0530, Keerthy wrote: > > From: J Keerthy > > > > Check if irq value obtained is valid. If it is not valid then skip > the > > irq request step and go ahead with the probe. > > > > Signed-off-by: J Keerthy > > Reviewed-by: Mark Brown Thanks Mark. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] mailbox/omap: add a parent structure common to all mboxes
On Tue, Jun 18, 2013 at 3:34 PM, Suman Anna wrote:
> A new structure, omap_mbox_device, is added to contain
> the global variables pertinent to a mailbox h/w IP block.
> This enables the support for having multiple instances of
> the same h/w IP block in the SoC. The startup sequence for
> each mailbox is also simplified along the way, removing the
> usage of single global configuration variables for all h/w
> instances.
>
> Signed-off-by: Suman Anna
Reviewed-by: Russ Dill
> ---
> drivers/mailbox/mailbox-omap1.c | 27 +---
> drivers/mailbox/mailbox-omap2.c | 95
> +
> drivers/mailbox/omap-mailbox.c | 32 ++
> drivers/mailbox/omap-mbox.h | 10 +
> 4 files changed, 102 insertions(+), 62 deletions(-)
>
> diff --git a/drivers/mailbox/mailbox-omap1.c b/drivers/mailbox/mailbox-omap1.c
> index 9001b76..5e38ffc 100644
> --- a/drivers/mailbox/mailbox-omap1.c
> +++ b/drivers/mailbox/mailbox-omap1.c
> @@ -26,7 +26,7 @@
> #define MAILBOX_DSP2ARM1_Flag 0x1c
> #define MAILBOX_DSP2ARM2_Flag 0x20
>
> -static void __iomem *mbox_base;
> +static struct omap_mbox_device omap1_mbox_device;
>
> struct omap_mbox1_fifo {
> unsigned long cmd;
> @@ -41,12 +41,12 @@ struct omap_mbox1_priv {
>
> static inline int mbox_read_reg(size_t ofs)
> {
> - return __raw_readw(mbox_base + ofs);
> + return __raw_readw(omap1_mbox_device.mbox_base + ofs);
> }
>
> static inline void mbox_write_reg(u32 val, size_t ofs)
> {
> - __raw_writew(val, mbox_base + ofs);
> + __raw_writew(val, omap1_mbox_device.mbox_base + ofs);
> }
>
> /* msg */
> @@ -139,6 +139,7 @@ static struct omap_mbox mbox_dsp_info = {
> .name = "dsp",
> .ops= &omap1_mbox_ops,
> .priv = &omap1_mbox_dsp_priv,
> + .parent = &omap1_mbox_device,
> };
>
> static struct omap_mbox *omap1_mboxes[] = { &mbox_dsp_info, NULL };
> @@ -148,6 +149,7 @@ static int omap1_mbox_probe(struct platform_device *pdev)
> struct resource *mem;
> int ret;
> struct omap_mbox **list;
> + struct omap_mbox_device *mdev = &omap1_mbox_device;
>
> list = omap1_mboxes;
> list[0]->irq = platform_get_irq_byname(pdev, "dsp");
> @@ -156,13 +158,18 @@ static int omap1_mbox_probe(struct platform_device
> *pdev)
> if (!mem)
> return -ENOENT;
>
> - mbox_base = ioremap(mem->start, resource_size(mem));
> - if (!mbox_base)
> + mdev->mbox_base = ioremap(mem->start, resource_size(mem));
> + if (!mdev->mbox_base)
> return -ENOMEM;
> + mutex_init(&mdev->cfg_lock);
> + mdev->dev = &pdev->dev;
> + mdev->mboxes = omap1_mboxes;
> + mdev->num_users = 2;
> + mdev->num_fifos = 4;
>
> ret = omap_mbox_register(&pdev->dev, list);
> if (ret) {
> - iounmap(mbox_base);
> + iounmap(mdev->mbox_base);
> return ret;
> }
>
> @@ -171,8 +178,14 @@ static int omap1_mbox_probe(struct platform_device *pdev)
>
> static int omap1_mbox_remove(struct platform_device *pdev)
> {
> + struct omap_mbox_device *mdev = &omap1_mbox_device;
> +
> omap_mbox_unregister();
> - iounmap(mbox_base);
> + iounmap(mdev->mbox_base);
> + mdev->mbox_base = NULL;
> + mdev->mboxes = NULL;
> + mdev->dev = NULL;
> +
> return 0;
> }
>
> diff --git a/drivers/mailbox/mailbox-omap2.c b/drivers/mailbox/mailbox-omap2.c
> index eba380d..6c0687c 100644
> --- a/drivers/mailbox/mailbox-omap2.c
> +++ b/drivers/mailbox/mailbox-omap2.c
> @@ -42,8 +42,6 @@
> #define MBOX_NR_REGS (MBOX_REG_SIZE / sizeof(u32))
> #define OMAP4_MBOX_NR_REGS (OMAP4_MBOX_REG_SIZE / sizeof(u32))
>
> -static void __iomem *mbox_base;
> -
> struct omap_mbox2_fifo {
> unsigned long msg;
> unsigned long fifo_stat;
> @@ -62,34 +60,38 @@ struct omap_mbox2_priv {
> u32 intr_type;
> };
>
> -static inline unsigned int mbox_read_reg(size_t ofs)
> +static inline
> +unsigned int mbox_read_reg(struct omap_mbox_device *mdev, size_t ofs)
> {
> - return __raw_readl(mbox_base + ofs);
> + return __raw_readl(mdev->mbox_base + ofs);
> }
>
> -static inline void mbox_write_reg(u32 val, size_t ofs)
> +static inline
> +void mbox_write_reg(struct omap_mbox_device *mdev, u32 val, size_t ofs)
> {
> - __raw_writel(val, mbox_base + ofs);
> + __raw_writel(val, mdev->mbox_base + ofs);
> }
>
> /* Mailbox H/W preparations */
> static int omap2_mbox_startup(struct omap_mbox *mbox)
> {
> - u32 l;
> -
> - pm_runtime_enable(mbox->dev->parent);
> - pm_runtime_get_sync(mbox->dev->parent);
> + pm_runtime_get_sync(mbox->parent->dev);
>
> - l = mbox_read_reg(MAILBOX_REVISION);
> - pr_debug("omap mailbox rev %d.%d\n", (l & 0xf0) >> 4, (l & 0x0f));
> + /*
> +* just print the raw revision register, t
Re: [PATCH 3/3] ARM: dts: OMAP2+: Add mailbox nodes
On Tue, Jun 18, 2013 at 3:35 PM, Suman Anna wrote:
> The mailbox DT node data has been added for OMAP2420,
> OMAP2430, OMAP3430/OMAP3630, OMAP44xx devices. Data for
> OMAP5 is skipped for now since the corresponding hwmod
> entry is not present.
>
> The mailbox static device initialization logic is also
> adjusted for a DT boot.
>
> Signed-off-by: Suman Anna
Reviewed-by: Russ Dill
> ---
> arch/arm/boot/dts/omap2420.dtsi | 13 +
> arch/arm/boot/dts/omap2430.dtsi | 12
> arch/arm/boot/dts/omap3.dtsi| 12
> arch/arm/boot/dts/omap4.dtsi| 12
> arch/arm/mach-omap2/devices.c | 2 +-
> 5 files changed, 50 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/omap2420.dtsi b/arch/arm/boot/dts/omap2420.dtsi
> index c8f9c55..e0f4e47 100644
> --- a/arch/arm/boot/dts/omap2420.dtsi
> +++ b/arch/arm/boot/dts/omap2420.dtsi
> @@ -114,6 +114,19 @@
> dma-names = "tx", "rx";
> };
>
> + mailbox: mailbox@48094000 {
> + compatible = "ti,omap2-mailbox";
> + reg = <0x48094000 0x200>;
> + interrupts = <26>, /* DSP Interrupt */
> +<34>; /* IVA Interrupt */
> + ti,hwmods = "mailbox";
> + ti,mbox-num-users = <4>;
> + ti,mbox-num-fifos = <6>;
> + #ti,mbox-data-cells = <4>;
> + ti,mbox-names = "dsp", "iva";
> + ti,mbox-data = <0 1 0 0>, <2 3 1 3>;
> + };
> +
> timer1: timer@48028000 {
> compatible = "ti,omap2420-timer";
> reg = <0x48028000 0x400>;
> diff --git a/arch/arm/boot/dts/omap2430.dtsi b/arch/arm/boot/dts/omap2430.dtsi
> index c535a5a..b413423 100644
> --- a/arch/arm/boot/dts/omap2430.dtsi
> +++ b/arch/arm/boot/dts/omap2430.dtsi
> @@ -175,6 +175,18 @@
> dma-names = "tx", "rx";
> };
>
> + mailbox: mailbox@48094000 {
> + compatible = "ti,omap2-mailbox";
> + reg = <0x48094000 0x200>;
> + interrupts = <26>;
> + ti,hwmods = "mailbox";
> + ti,mbox-num-users = <4>;
> + ti,mbox-num-fifos = <6>;
> + #ti,mbox-data-cells = <4>;
> + ti,mbox-names = "dsp";
> + ti,mbox-data = <0 1 0 0>;
> + };
> +
> timer1: timer@49018000 {
> compatible = "ti,omap2420-timer";
> reg = <0x49018000 0x400>;
> diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
> index 6d05ee0..3cc7c28 100644
> --- a/arch/arm/boot/dts/omap3.dtsi
> +++ b/arch/arm/boot/dts/omap3.dtsi
> @@ -380,6 +380,18 @@
> dma-names = "tx", "rx";
> };
>
> + mailbox: mailbox@48094000 {
> + compatible = "ti,omap2-mailbox";
> + reg = <0x48094000 0x200>;
> + interrupts = <26>;
> + ti,hwmods = "mailbox";
> + ti,mbox-num-users = <2>;
> + ti,mbox-num-fifos = <2>;
> + #ti,mbox-data-cells = <4>;
> + ti,mbox-names = "dsp";
> + ti,mbox-data = <0 1 0 0>;
> + };
> +
> timer1: timer@48318000 {
> compatible = "ti,omap3430-timer";
> reg = <0x48318000 0x400>;
> diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
> index 463b97d..0155182 100644
> --- a/arch/arm/boot/dts/omap4.dtsi
> +++ b/arch/arm/boot/dts/omap4.dtsi
> @@ -516,6 +516,18 @@
> };
> };
>
> + mailbox: mailbox@4a0f4000 {
> + compatible = "ti,omap4-mailbox";
> + reg = <0x4a0f4000 0x200>;
> + interrupts = ;
> + ti,hwmods = "mailbox";
> + ti,mbox-num-users = <3>;
> + ti,mbox-num-fifos = <8>;
> + #ti,mbox-data-cells = <4>;
> + ti,mbox-names = "mbox-ipu", "mbox-dsp";
> + ti,mbox-data = <0 1 0 0>, <3 2 0 0>;
> + };
> +
> timer1: timer@4a318000 {
> compatible = "ti,omap3430-timer";
> reg = <0x4a318000 0x80>;
> diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
> index 73762ac..2058f24 100644
> --- a/arch/arm/mach-omap2/devices.c
> +++ b/arch/arm/mach-omap2/devices.c
> @@ -655,11 +655,11 @@ static int __init omap2_init_devices(void)
> omap_init_audio();
> omap_init_camera()
Re: [PATCH 2/3] mailbox/omap: add support for parsing dt devices
On Tue, Jun 18, 2013 at 3:34 PM, Suman Anna wrote:
> Logic has been added to the OMAP2+ mailbox code to
> parse the mailbox dt nodes and construct the different
> mailboxes associated with the instance. The design is
> based on gathering the same information that was being
> passed previously through the platform data, except for
> the interrupt type configuration information.
>
> Signed-off-by: Suman Anna
Reviewed-by: Russ Dill
> ---
> .../devicetree/bindings/mailbox/omap-mailbox.txt | 46 +++
> drivers/mailbox/mailbox-omap2.c| 141
> ++---
> 2 files changed, 172 insertions(+), 15 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/mailbox/omap-mailbox.txt
>
> diff --git a/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt
> b/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt
> new file mode 100644
> index 000..913bc13
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt
> @@ -0,0 +1,46 @@
> +OMAP2+ Mailbox Driver
> +
> +Required properties:
> +- compatible: Should be one of the following,
> + "ti,omap2-mailbox" for
> + OMAP2420, OMAP2430, OMAP3430, OMAP3630 SoCs
> + "ti,omap4-mailbox" for
> + OMAP44xx, OMAP54xx, AM33xx, AM43xx, DRA7xx
> SoCs
> +- reg: Contains the mailbox register address range (base
> address
> + and length)
> +- interrupts: Contains the interrupt information for the mailbox
> + device. The format is dependent on which interrupt
> + controller the OMAP device uses
> +- ti,hwmods: Name of the hwmod associated with the mailbox
> +- ti,mbox-num-users: Number of targets (processor devices) that the
> mailbox device
> + can interrupt
> +- ti,mbox-num-fifos: Number of h/w fifos within the mailbox device
> +- #ti,mbox-data-cells: Cell size for describing a mailbox
> + (currently should be 4)
> +- ti,mbox-names: Array of the names of the mailboxes
> +- ti,mbox-data:Mailbox descriptor data private to each
> mailbox. The 4
> + cells represent the following data,
> + Cell #1 (tx_id) - mailbox fifo id used for
> + transmitting messages
> + Cell #2 (rx_id) - mailbox fifo id on which messages
> + are received
> + Cell #3 (irq_id) - irq identifier index number to
> use
> + from the interrupts data
> + Cell #4 (usr_id) - mailbox user id for identifying
> the
> + interrupt into the MPU
> interrupt
> + controller.
> +
> +Example:
> +
> +/* OMAP4 */
> +mailbox: mailbox@4a0f4000 {
> + compatible = "ti,omap4-mailbox";
> + reg = <0x4a0f4000 0x200>;
> + interrupts = ;
> + ti,hwmods = "mailbox";
> + ti,mbox-num-users = <3>;
> + ti,mbox-num-fifos = <8>;
> + #ti,mbox-data-cells = <4>
> + ti,mbox-names = "mbox-ipu", "mbox-dsp";
> + ti,mbox-data = <0 1 0 0>, <3 2 0 0>;
> +};
> diff --git a/drivers/mailbox/mailbox-omap2.c b/drivers/mailbox/mailbox-omap2.c
> index 6c0687c..3fe08de 100644
> --- a/drivers/mailbox/mailbox-omap2.c
> +++ b/drivers/mailbox/mailbox-omap2.c
> @@ -14,6 +14,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -222,6 +223,21 @@ static struct omap_mbox_ops omap2_mbox_ops = {
> .restore_ctx= omap2_mbox_restore_ctx,
> };
>
> +static const struct of_device_id omap_mailbox_of_match[] = {
> + {
> + .compatible = "ti,omap2-mailbox",
> + .data = (void *) MBOX_INTR_CFG_TYPE1,
> + },
> + {
> + .compatible = "ti,omap4-mailbox",
> + .data = (void *) MBOX_INTR_CFG_TYPE2,
> + },
> + {
> + /* end */
> + },
> +};
> +MODULE_DEVICE_TABLE(of, omap_mailbox_of_match);
> +
> static int omap2_mbox_probe(struct platform_device *pdev)
> {
> struct resource *mem;
> @@ -229,47 +245,138 @@ static int omap2_mbox_probe(struct platform_device
> *pdev)
> struct omap_mbox **list, *mbox, *mboxblk;
> struct omap_mbox2_priv *priv, *privblk;
> struct omap_mbox_pdata *pdata = pdev->dev.platform_data;
> - struct omap_mbox_dev_info *info;
> struct omap_mbox_device *mdev;
> - int i;
> -
> - if (!pdata || !pdata->info_cnt || !pdata->info) {
> + struct omap_mbox_dev_info *info, *of_info = NULL;
> + struct device_node *node = pdev->dev.of_node;
> + int i, j;
> +
Re: [PATCH v11 3/8] ARM: edma: Add EDMA crossbar event mux support
Hi Sekhar,
Thanks for the feedback.
On Tue, Jun 18, 2013 at 5:19 AM, Sekhar Nori wrote:
> On 6/18/2013 12:08 PM, Joel A Fernandes wrote:
>> From: Matt Porter
>>
>> Changes by Joel:
>> * Split EDMA xbar support out of original EDMA DT parsing patch
>> to keep it easier for review.
>> * Rewrite shift and offset calculation.
>>
>> Suggested-by: Sekhar Nori
>> Suggested by: Andy Shevchenko
>> Signed-off-by: Joel A Fernandes
>>
>> Reference:
>> [1] https://patchwork.kernel.org/patch/2226991/
>> ---
>> arch/arm/common/edma.c | 59
>>
>> include/linux/platform_data/edma.h |1 +
>> 2 files changed, 60 insertions(+)
>>
>> diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
>> index 9823b79..1c2fb15 100644
>> --- a/arch/arm/common/edma.c
>> +++ b/arch/arm/common/edma.c
>> @@ -1410,6 +1410,52 @@ static int edma_of_read_u32_to_s16_array(const struct
>> device_node *np,
>> return 0;
>> }
>>
>> +static int edma_xbar_event_map(struct device *dev,
>> +struct device_node *node,
>> +struct edma_soc_info *pdata, int len)
>> +{
>> + int ret = 0;
>> + int i;
>> + struct resource res;
>> + void *xbar;
>
> void __iomem *xbar;
OK.
>> + const s16 (*xbar_chans)[2];
>> + u32 shift, offset, mux;
>> +
>> + xbar_chans = devm_kzalloc(dev,
>> + len/sizeof(s16) + 2*sizeof(s16),
>> + GFP_KERNEL);
>> + if (!xbar_chans)
>> + return -ENOMEM;
>> +
>> + ret = of_address_to_resource(node, 1, &res);
>> + if (ret)
>> + return -EIO;
>> +
>> + xbar = devm_ioremap(dev, res.start, resource_size(&res));
>> + if (!xbar)
>> + return -ENOMEM;
>> +
>> + ret = edma_of_read_u32_to_s16_array(node,
>> + "ti,edma-xbar-event-map",
>> + (s16 *)xbar_chans,
>> + len/sizeof(u32));
>> + if (ret)
>> + return -EIO;
>> +
>> + for (i = 0; xbar_chans[i][0] != -1; i++) {
>> + shift = (xbar_chans[i][1] & 0x03) << 3;
>> + offset = xbar_chans[i][1] & 0xfffc;
>> + mux = readl((void *)((u32)xbar + offset));
>
> Please drop unnecessary casting. Simply:
Done.
>
> mux = readl(xbar + offset);
>
>> + mux &= ~(0xff << shift);
>> + mux |= xbar_chans[i][0] << shift;
>> + writel(mux, (void *)((u32)xbar + offset));
>
> Fix the writel likewise.
Done.
>> }
>>
>> + /* Clear the xbar mapped channels in unused list */
>> + xbar_chans = info[j]->xbar_chans;
>> + if (xbar_chans) {
>> + for (i = 0; xbar_chans[i][1] != -1; i++) {
>> + off = xbar_chans[i][1];
>> + clear_bits(off, 1,
>> + edma_cc[j]->edma_unused);
>
> Please fix the alignment here.
I noticed the alignment was off in a few other places in that driver.
Fixed those up too.
Thanks,
Joel
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH -next] ARM: OMAP2+: devices: remove duplicated include from devices.c
From: Wei Yongjun Remove duplicated include. Signed-off-by: Wei Yongjun --- arch/arm/mach-omap2/devices.c | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c index c0f99ab..8349238 100644 --- a/arch/arm/mach-omap2/devices.c +++ b/arch/arm/mach-omap2/devices.c @@ -15,7 +15,6 @@ #include #include #include -#include #include #include #include -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH -next] ARM: OMAP1: remove duplicated include from board-voiceblue.c
From: Wei Yongjun Remove duplicated include. Signed-off-by: Wei Yongjun --- arch/arm/mach-omap1/board-voiceblue.c | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/arm/mach-omap1/board-voiceblue.c b/arch/arm/mach-omap1/board-voiceblue.c index 4677a9c..4b382a0 100644 --- a/arch/arm/mach-omap1/board-voiceblue.c +++ b/arch/arm/mach-omap1/board-voiceblue.c @@ -26,7 +26,6 @@ #include #include #include -#include #include #include -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] ARM: OMAP: Device Tree for 3.11
Hi Tony, Please pull the following commits for OMAP Device Tree for v3.11. It does contains as well 2 clock data patches, I hope it will not generate any conflict with Paul's tree. Special thanks to Florian for his nice cleanup using the C preprocessor. Thanks, Benoit The following changes since commit 7d132055814ef17a6c7b69f342244c410a5e000f: Linux 3.10-rc6 (2013-06-15 11:51:07 -1000) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.11/dts for you to fetch changes up to 153030c22defea2f96546d0f1a74fe954551c4cd: ARM: dts: omap5-uevm: Provide USB Host PHY clock frequency (2013-06-19 16:59:28 -0500) Afzal Mohammed (2): ARM: dts: AM43x: Initial support ARM: dts: AM43x EPOS EVM support Dan Murphy (3): ARM: dts: omap4-panda: Update the LED support for the panda ARM: dts: omap4-panda: Update the twl6040 gpio to macro definition ARM: dts: omap5-uevm: Add LED support for uEVM blue LED Eduardo Valentin (3): ARM: dts: OMAP443x: Add bandgap entry for OMAP443x devices ARM: dts: OMAP4460: Add bandgap entry for OMAP4460 devices ARM: dts: OMAP5: Add bandgap DT entry Florian Vaussard (15): ARM: dts: OMAP2+: Use #include for all device trees ARM: dts: OMAP2+: Use existing constants for GPIOs ARM: dts: OMAP4/5: Use existing constants for IRQs ARM: dts: OMAP2+: Header file for pinctrl constants ARM: dts: OMAP2+: Use pinctrl constants ARM: dts: AM3XXX: Use #include for all device trees ARM: dts: AM33XX: Use existing constants for GPIOs ARM: dts: AM33XX: Specific pinctrl header ARM: dts: AM33XX: Use pinctrl constants ARM: dts: OMAP4/AM35xx: Add missing dtb in the dtbs target ARM: dts: Protect pinctrl headers against multiple inclusions ARM: dts: OMAP3: Include IRQ header ARM: dts: omap3-tobi: Add SMSC911X node ARM: dts: omap3-tobi: Correct polarity for GPIO LED ARM: dts: omap3-overo: Add default trigger for TWL4030 LED J Keerthy (1): ARM: dts: OMAP5: Add Palmas MFD node and regulator nodes Javier Martinez Canillas (3): ARM: dts: omap3-igep0020: Add SMSC911x LAN chip support ARM: dts: omap3-igep0020: Add NAND flash support ARM: dts: omap3-igep0030: Add NAND flash support Kevin Hilman (3): ARM: dts: OMAP3: beagle/overo: mux console UART, enable wakeup ARM: dts: OMAP3: beagle: enable user button via gpio_keys, enable wakeup ARM: dts: TWL4030: fix mux and wakeup for SYS_NIRQ line Mugunthan V N (3): ARM: dts: AM33XX: Add pinmux configuration for CPSW to beaglebone ARM: dts: AM33XX: Add pinmux configuration for CPSW to EVMsk ARM: dts: AM33XX: Add pinmux configuration for CPSW to am335x EVM Philip Avinash (4): ARM: dts: AM33XX: Add NAND flash device tree data to am335x-evm ARM: dts: AM33XX: Add PWMSS device tree nodes ARM: dts: AM33XX: Add PWM backlight DT data to am335x-evm ARM: dts: AM33XX: Add PWM backlight DT data to am335x-evmsk Philip, Avinash (1): ARM: dts: AM33XX: Add ELM node Roger Quadros (4): ARM: dts: omap5-uevm: Add USB Host support ARM: dts: omap4-panda: Add USB Host support ARM: dts: omap4-panda: Fix DVI EDID reads ARM: dts: omap5-uevm: Provide USB Host PHY clock frequency Sourav Poddar (1): ARM: dts: omap5-uevm: Add uart pinctrl data Sricharan R (1): ARM: dts: omap5: Make uevm as the official board and deprecate sevm support Suman Anna (1): ARM: dts: OMAP4+: Remove multimedia carveouts Vaibhav Hiremath (7): ARM: dts: AM33XX: Add default pinctrl binding for I2C device ARM: dts: AM33XX: Add pinctrl binding to gpio-leds node ARM: dts: AM33XX: Fix uart numbering to match hardware/TRM ARM: dts: AM33XX: Add default pinctrl binding for UART0 device ARM: dts: AM33XX: Set pinmux for clkout2 pad used for clock output ARM: AM33XX: clock: Add debugSS clock nodes ARM: AM33XX: clock data: Enable clkout2 as part of init .../devicetree/bindings/arm/omap/omap.txt |3 + arch/arm/boot/dts/Makefile |8 +- arch/arm/boot/dts/am335x-bone.dts | 118 - arch/arm/boot/dts/am335x-evm.dts | 264 ++- arch/arm/boot/dts/am335x-evmsk.dts | 184 +++- arch/arm/boot/dts/am33xx.dtsi | 121 - arch/arm/boot/dts/am3517-evm.dts |2 +- arch/arm/boot/dts/am3517_mt_ventoux.dts|2 +- arch/arm/boot/dts/am4372.dtsi | 68 +++ arch/arm/boot/dts/am43x-epos-evm.dts | 18 + arch/arm/boot/dts/omap2.dtsi |5 +- arch/arm/boot/dts/omap2420-h4.dts |2 +- arch/arm/boot/dts/omap2420.dtsi|2 +- arch/arm/boot/dts/omap2430
Re: [PATCH v2 1/4] ARM: dts: omap4-panda: Add USB Host support
On 06/19/2013 09:05 AM, Roger Quadros wrote:
On 06/19/2013 03:23 PM, Benoit Cousson wrote:
On 06/19/2013 07:05 AM, Florian Vaussard wrote:
Hello,
On 06/19/2013 01:03 PM, Roger Quadros wrote:
On 06/19/2013 01:10 PM, Benoit Cousson wrote:
On 06/19/2013 02:46 AM, Tony Lindgren wrote:
* Roger Quadros [130619 00:42]:
Hi Benoit,
On 06/19/2013 04:17 AM, Benoit Cousson wrote:
Hi Roger,
On 06/18/2013 11:04 AM, Roger Quadros wrote:
Provide the RESET and Power regulators for the USB PHY,
the USB Host port mode and the PHY device.
Also provide pin multiplexer information for the USB host
pins.
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 62
+
1 files changed, 62 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 00cbaa5..7a21e8e 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -59,6 +59,42 @@
"AFML", "Line In",
"AFMR", "Line In";
};
+
+/* HS USB Port 1 RESET */
+hsusb1_reset: hsusb1_reset_reg {
+compatible = "regulator-fixed";
+regulator-name = "hsusb1_reset";
+regulator-min-microvolt = <330>;
+regulator-max-microvolt = <330>;
+gpio = <&gpio2 30 0>;/* gpio_62 */
+startup-delay-us = <7>;
+enable-active-high;
+};
Is this really a regulator? Or just a GPIO line used to reset the
USB PHY?
It is in fact a GPIO line used as reset.
If this is the case, I don't think it should be represented as a
regulator.
Why not? I think it fits very well in the regulator device model.
I'm not sure fitting very well is the correct term.
It works, for sure, but it is no different than when we were trying
to abuse the regulator fmwk to enable the 32k clock in phoenix.
It is just a hack.
The only difference is there is a dedicated framework for clocks.
Since there is nothing specific to
handle reset lines it is left to the driver writer how he wants to
manage it.
There is a proposed binding for gpio-controlled reset lines, but it is
not yet merged [1].
I guess it can fit most usage patterns, and it can be an interesting
move in the future.
I'm glad to see that I was not the only one thinking that the regulator was not
the right fmwk to do that :-)
Thanks for the pointer Florian.
Thanks again Florian.
I guess that series should be merged for 3.11? Based on the thread, it should
to through arm-soc.
Roger,
It might be tricky to have dependency on that series, but if this is possible,
you should try. Otherwise, just keep the existing one, adding that a new
solution will be available soon as a disclaimer.
I will rework the PHY driver to use the new gpio-reset driver. But for 3.11
let's proceed the way it is.
I'll resend this one with a disclaimer.
OK, I've just done it myself while applying your series.
Regards,
Benoit
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] regulator: core: allow consumers to request to closes step voltage
On Wed, Jun 19, 2013 at 02:17:54PM -0500, Nishanth Menon wrote: > Account for step size accuracy when exact voltage requests are send for > step based regulators. If the consumer can tolerate a different voltage why not just request the range that can be tolerated? Your problem here is specifying an exact voltage. > The specific example I faced was using cpufreq-cpu0 driver with voltages > for OPPs for MPU rail and attempting the common definitions against voltages > that are non-exact multiples of stepsize of PMIC. > The alternative would be implement custom set_voltage (as againsta simpler > set_voltage_sel and using linear map/list functions) for the regulator which > will account for the same. > Yet another alternative might be to introduce yet another custom function > similar > to regulator_set_voltage_tol which accounts for this. something like: > regulator_set_voltage_floor(regulator, voltage, tol) or something to that > effect. Or as I keep telling you guys the consumer can just do that directly using the existing API; the whole point in specifying the voltage as a range is to allow the consumer to cope with arbatrary regulators by giving a range of voltages that it can accept. The API is deliberately very conservative in these matters since there is a danger of physical damage if things really go wrong in some applications, it makes sure that both the drivers and the system integration are involved. signature.asc Description: Digital signature
Re: [PATCH 1/5] i2c: omap: fix spurious IRQs: disable/enable IRQ at INTC when idle
Hi, On Wed, Jun 19, 2013 at 01:01:28PM -0700, Kevin Hilman wrote: > Felipe Balbi writes: > > [...] > > > If you have 200 pm_runtime_get() followed by 200 pm_runtime_put() (put > > is called only after 200 gets, no put-get ping-pong), your > > ->runtime_resume() gets called once, your ->runtime_suspend() gets > > called once but your ->runtime_idle() will get called 200 times. > > No. The driver's ->runtime_idle() will only be called when the usecount > goes to zero. Indeed, just re-read the code. -- balbi signature.asc Description: Digital signature
Re: [PATCH 1/5] i2c: omap: fix spurious IRQs: disable/enable IRQ at INTC when idle
Felipe Balbi writes: [...] > If you have 200 pm_runtime_get() followed by 200 pm_runtime_put() (put > is called only after 200 gets, no put-get ping-pong), your > ->runtime_resume() gets called once, your ->runtime_suspend() gets > called once but your ->runtime_idle() will get called 200 times. No. The driver's ->runtime_idle() will only be called when the usecount goes to zero. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP5: Enable Cortex A15 errata 798181
ARM errata 798181 is applicable for OMAP5 based devices. So enable the same in the build. Errata extract and workaround information is as below. On Cortex-A15 (r0p0..r3p2) the TLBI*IS/DSB operations are not adequately shooting down all use of the old entries. The ARM_ERRATA_798181 option enables the Linux kernel workaround for this erratum which sends an IPI to the CPUs that are running the same ASID as the one being invalidated. Cc: Tony Lindgren Signed-off-by: Santosh Shilimkar --- arch/arm/mach-omap2/Kconfig |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index f49cd51..fbd2b9f 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -112,6 +112,7 @@ config SOC_OMAP5 select HAVE_SMP select COMMON_CLK select HAVE_ARM_ARCH_TIMER + select ARM_ERRATA_798181 comment "OMAP Core Type" depends on ARCH_OMAP2 -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] i2c: omap: handle all irqs befor unblocking omap_i2c_xfer_msg()
On Wed, Jun 19, 2013 at 09:43:04PM +0300, Grygorii Strashko wrote: > Hi Felipe, > On 06/07/2013 10:05 PM, Felipe Balbi wrote: > >Hi, > > > >On Fri, Jun 07, 2013 at 09:46:06PM +0300, Grygorii Strashko wrote: > >>ARDY|NACK and ARDY|AL are set together in OMAP_I2C_STAT_REG, which will be > >Have you seen that happen ever ? AL is Arbitration Lost, we never put > >OMAP in a multi-master environment before. > This is an example from real life: > [0.271942] omap_i2c omap_i2c.1: bus 1 rev2.4.0 at 400 kHz > [1.283416] omap_i2c omap_i2c.1: timeout waiting for bus ready > [1.300109] OMAP_I2C DEBUG: stat=1001 > [1.300140] omap_i2c omap_i2c.1: Arbitration lost > [1.300140] OMAP_I2C DEBUG: IE=601F > [1.300140] OMAP_I2C DEBUG: STAT=1000 > [1.300170] OMAP_I2C DEBUG: IV=636F > [1.300170] OMAP_I2C DEBUG: WE=636F > [1.300170] OMAP_I2C DEBUG: SYSS=1 > [1.300170] OMAP_I2C DEBUG: BUF=707 > [1.300201] OMAP_I2C DEBUG: CNT=1 > [1.300201] OMAP_I2C DEBUG: DATA=1 > [1.300201] OMAP_I2C DEBUG: SYSC=215 > [1.300201] OMAP_I2C DEBUG: CON=8200 > [1.300231] OMAP_I2C DEBUG: OA=0 > [1.300231] OMAP_I2C DEBUG: SA=49 > [1.300231] OMAP_I2C DEBUG: PSC=9 > [1.300262] OMAP_I2C DEBUG: SCLL=9 > [1.300262] OMAP_I2C DEBUG: SCLH=3 > [1.300262] OMAP_I2C DEBUG: SYSTEST=1E0 > [1.300262] OMAP_I2C DEBUG: BUFSTAT=4000 > > and my headache now :..( have you looked for erratas around that ? Maybe you just found a silicon issue. Why is AL bit being set ? Have you tried to reach the IP owner ? If there are no other I2C masters in the system, there will be no arbitration, hence we would never loose the arbitration. > >ARDY | NACK I also find it a bit hard for those two to happen together > >since ARDY will be set when you can change controller's register > >*again*, mening that a transfer has completed. > There are examples: > [3.544952] omap_i2c 4806.i2c: IRQ (ISR = 0x0006) > > [ 25.574523] omap_i2c 4835.i2c: IRQ (ISR = 0x0014) > [ 25.579925] omap_i2c 4835.i2c: IRQ (ISR = 0x0012) > > to see it - enable debug output in omap_i2c_isr_thread: > dev_dbg(dev->dev, "IRQ (ISR = 0x%04x)\n", stat); then you need to figure out why that's happening, right ? What do you do to trigger that particular condition, have you looked in the wire to see if you find a real NACK or is the OMAP I2C controller misbehaving ? > >Also, we need to follow what the programming model says. And, I don't > >have docs with me right now, but IIRC it tells us to bail out if any of > >the error conditions are met. > > > yep, but first of all - all IRQs need to be acked before exit. that's alright, then fix only that... OTOH, you don't want to ack a read while data is still sitting in the FIFO, data you haven't read out of the FIFO, I mean. Not sure if that could happen though. -- balbi signature.asc Description: Digital signature
Re: [PATCH 5/5] i2c: omap: remove omap_i2c_isr() hw irq handler
On Wed, Jun 19, 2013 at 09:43:17PM +0300, Grygorii Strashko wrote: > Hi Felipe, > > On 06/07/2013 10:07 PM, Felipe Balbi wrote: > >Hi, > > > >On Fri, Jun 07, 2013 at 09:46:08PM +0300, Grygorii Strashko wrote: > >>The omap_i2c_isr() does the irq check and schedules threaded handler if any > >>of > >>enabled IRQs is active, but currently the I2C IRQs are enabled just once, > >>when I2C IP is enabling (transfer started) and they aren't changed after > >>that. > >>More over, now the I2C INTC IRQ is disabled when I2C IP is idled. > >>Thus, I2C IRQs will start coming only when we want that, and there is > >>no sense to have omap_i2c_isr() anymore: > >so ? we still want to check if this device generated IRQs in hardirq > >context. What if the IRQ line is shared ? > > > Pleas see, https://patchwork.kernel.org/patch/2689211/ > [1/5] i2c: omap: fix spurious IRQs: disable/enable IRQ at INTC when idle > > It covers shared IRQ problem then you don't need $SUBJECT. -- balbi signature.asc Description: Digital signature
Re: [PATCH 2/5] i2c: omap: add runtime check in isr to be sure that i2c is enabled
On Wed, Jun 19, 2013 at 09:42:25PM +0300, Grygorii Strashko wrote:
> Hi Felipe,
> On 06/07/2013 10:02 PM, Felipe Balbi wrote:
> >Hi,
> >
> >On Fri, Jun 07, 2013 at 09:46:05PM +0300, Grygorii Strashko wrote:
> >>Add runtime check at the beginning of omap_i2c_isr/omap_i2c_isr_thread
> >>to be sure that i2c is enabled, before performing IRQ handling and accessing
> >>I2C IP registers:
> >>if (pm_runtime_suspended(dev->dev)) {
> >>WARN_ONCE(true, "We should never be here!\n");
> >>return IRQ_NONE;
> >>}
> >>
> >>Produce warning in case if ISR called when i2c is disabled
> >>
> >>CC: Kevin Hilman
> >>Signed-off-by: Grygorii Strashko
> >>---
> >> drivers/i2c/busses/i2c-omap.c | 10 ++
> >> 1 file changed, 10 insertions(+)
> >>
> >>diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> >>index 97844ff..2dac598 100644
> >>--- a/drivers/i2c/busses/i2c-omap.c
> >>+++ b/drivers/i2c/busses/i2c-omap.c
> >>@@ -885,6 +885,11 @@ omap_i2c_isr(int irq, void *dev_id)
> >>u16 stat;
> >>spin_lock(&dev->lock);
> >>+ if (pm_runtime_suspended(dev->dev)) {
> >>+ WARN_ONCE(true, "We should never be here!\n");
> >>+ return IRQ_NONE;
> >>+ }
> >returning IRQ_NONE is not what you want to do in this case. You want to
> >setup a flag so that your runtime_resume() knows that there are pending
> >events to be handled and you handle those in runtime_resume time.
> I don't want to handle this IRQ - we should never be here.
> Will be changed to IRQ_HANDLED.
blindly returning IRQ_HANDLED won't do you any good either. Your line
will be re-enabled anyway and you'll get another IRQ even being fired.
If you have found a bug in the driver, fix it, don't try to mask it.
> >But to be frank, I don't see how this can trigger since we're calling
> >pm_runtime_get_sync() from omap_i2c_xfer() which means by the time
> >pm_runtime_get_sync() returns, assuming no errors, i2c module should be
> >fully resumed and ready to go. Perhaps you have found a bug somewhere
> >else ?
> May be it's better to revert this patch:
> e3a36b207f76364c281aeecaf14c1b22a7247278
> i2c: omap: remove unnecessary pm_runtime_suspended check
>
> which doesn't cover case when transfer is *finished*.
what happens when transfer is finished ? After we come out of the loop
in omap_i2c_xfer() we will mark last busy and
pm_runtime_put_autosuspend()
633 static int
634 omap_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg msgs[], int num)
635 {
636 struct omap_i2c_dev *dev = i2c_get_adapdata(adap);
637 int i;
638 int r;
639
640 r = pm_runtime_get_sync(dev->dev);
641 if (IS_ERR_VALUE(r))
642 goto out;
643
644 r = omap_i2c_wait_for_bb(dev);
645 if (r < 0)
646 goto out;
647
648 if (dev->set_mpu_wkup_lat != NULL)
649 dev->set_mpu_wkup_lat(dev->dev, dev->latency);
650
651 for (i = 0; i < num; i++) {
652 r = omap_i2c_xfer_msg(adap, &msgs[i], (i == (num - 1)));
653 if (r != 0)
654 break;
655 }
656
657 if (r == 0)
658 r = num;
659
660 omap_i2c_wait_for_bb(dev);
661
662 if (dev->set_mpu_wkup_lat != NULL)
663 dev->set_mpu_wkup_lat(dev->dev, -1);
664
665 out:
666 pm_runtime_mark_last_busy(dev->dev);
667 pm_runtime_put_autosuspend(dev->dev);
668 return r;
669 }
When that timer expires, we will mask the controller's IRQs on our
->runtime_suspend().
Now, if another IRQ comes before we ->runtime_suspend(), then we need to
figure out what's generating that event, we don't want to be "fixing"
what's not broken in this driver.
> Please, see https://patchwork.kernel.org/patch/2689211/ and
> cover-latter.
that patch is fine, but doesn't seem like has nothing to do with what
you're talking about here.
> >Also, your 'We should never be here' message isn't helpfull at all.
nor is your explanation of the problem. It's not sufficient.
I'm telling you that we should never reach this case because that's the
assumption that the driver makes. It assumes that no IRQs will be fired
unless a transfer is started and by the time that for loop ends, no
transfer will be started.
> >>@@ -905,6 +910,11 @@ omap_i2c_isr_thread(int this_irq, void *dev_id)
> >>u16 stat;
> >>int err = 0, count = 0;
> >>+ if (pm_runtime_suspended(dev->dev)) {
> >>+ WARN_ONCE(true, "We should never be here!\n");
> >>+ return IRQ_NONE;
> >>+ }
> >because of IRQF_ONESHOT I can't see how this would *ever* be a valid
> >check.
> >
> Please, see https://patchwork.kernel.org/patch/2689211/ and
> cover-latter.
explain to me how would we get to this point, meaning the IRQ thread
handler, with the device disabled.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH] gpio: Enable pcf857x GPIO expander for Device Tree
On Mon, Jun 17, 2013 at 1:46 PM, Archit Taneja wrote:
> On Monday 17 June 2013 02:35 PM, Linus Walleij wrote:
>Just a query, there is an example in gpio.txt in the gpio
> bindings documentation which sets #gpio-cells as 1. Is this is a wrong
> example, or are 1 cell gpio controllers valid?
I don't think so. Try it and see if it works!
(If you want it, you may have to go in and fix drivers/gpio/gpiolib-of.c.)
> About this chip, a change in any of it's GPIOs configured as inputs will
> generate an interrupt, then it's up to the driver to figure out which GPIOs
> changed and handle their corresponding irqs. So shouldn't a device connected
> to the chip describe the gpio number within the pcf857x chip as it's first
> cell?
I guess so...
> I've made a hypothetical example of a pcf8575 chip, which has it's interrupt
> line connected to an omap gpio, and pcf8575's 7th gpio is connected to
> 'pcf_slave'. The pcf_slave's driver requests for an interrupt. Is this the
> correct way to describe this? :
>
> pcf: pcf8575@23 {
> compatible = "ti,pcf8575";
> reg = <0x23>;
> gpio-controller;
> #gpio-cells = <2>;
> #interrupt-controller;
> #interrupt-cells = <1>;
> interrupt-parent = <&gpio2>;/* an omap gpio bank */
> interrupts = <2 8>; /* gpio line 34, low triggered*/
> };
>
> pcf_slave: slave {
> ...
> ...
> #interrupt-parent = <&pcf>;
> interrupts = <7>; /* connected to 7th IO pin of pcf857x*/
> };
There are two paths for dereferencing GPIOs and IRQs.
Simple approach:
give your slave a gpios = <...>;
and in the driver use gpio_to_irq() to dereference an IRQ number
from the GPIO number you get. The IRQdomain etc in the
GPIO driver will take care of the rest.
How to code up a driver so that it can use irqs directly from a GPIO
controller without referring to the GPIO line it is tied into is currently
quite unclear. Atleast to me. It's been discussed for the OMAP
case so search the archives...
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] MFD: Change TWL6025 references to TWL6032
On Wed, Jun 19, 2013 at 03:24:02PM +0300, Oleksandr Kozaruk wrote: > There are non-mainline branches that use twl6032 by its name (for example > git://git.omapzoom.org/kernel/omap.git). There is intention to add support > of twl6032 device in mainline, but we'd like to know if we can use twl6032 > instead of twl6025 in our new patches, that we are going to provide. > Related discussion: https://patchwork.kernel.org/patch/2686331/ It's always been OK to use the new name, the only question was if it was better to keep the old name supported as well. Given that the chips are essentially nonexistant now your current approach seems sensible so Reviwed-by: Mark Brown signature.asc Description: Digital signature
Re: [PATCH] gpio: Enable pcf857x GPIO expander for Device Tree
On Tue, Jun 18, 2013 at 12:57 PM, Stijn Devriendt wrote:
> On Thu, Jun 6, 2013 at 4:05 PM, Archit Taneja wrote:
>> +static struct pcf857x_platform_data *of_gpio_pcf857x(struct device *dev)
>> +{
>> + struct pcf857x_platform_data *pdata;
>> + int r;
>> +
>> + pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
>
>
> This memory is never freed, is it?
Why should it, given it's allocated with devres?
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] i2c: omap: fix spurious IRQs: disable/enable IRQ at INTC when idle
Hi, On Wed, Jun 19, 2013 at 09:35:38PM +0300, Grygorii Strashko wrote: > On 06/07/2013 11:51 PM, Kevin Hilman wrote: > >Grygorii Strashko writes: > > > >>From: Kevin Hilman > >> > >>Currently, runtime PM is used to keep the device enabled only during > >>active transfers and for a configurable runtime PM autosuspend timout > >>after an xfer. > >> > >>In addition to idling the device, driver's ->runtime_suspend() method > >>currently disables device interrupts when idle. However, on some SoCs > >>(notably OMAP4+), the I2C hardware may shared with other coprocessors. > >>This means that the MPU will still recieve interrupts if a coprocessor > >>is using the I2C device. To avoid this, also disable interrupts at > >>the MPU INTC when idling the device in ->runtime_suspend() (and > >>re-enable them in ->runtime_resume().) This part based on an original > >>patch from Shubhrajyoti Datta. NOTE: for proper sharing the I2C with > >>a coprocessor, this driver still needs hwspinlock support added. > >> > >>More over, this patch fixes the kernel boot failure which happens when > >>CONFIG_SENSORS_LM75=y: > >> > >>[2.251220] WARNING: at drivers/bus/omap_l3_noc.c:113 > >>l3_interrupt_handler+0x140/0x184() > >>[2.257781] L3 custom error: MASTER:MPU TARGET:L4 PER2 > >>[2.264373] Modules linked in: > >>[2.268463] CPU: 0 PID: 2 Comm: kthreadd Not tainted > >>3.10.0-rc4-00034-g042dd60-dirty #64 > >>[2.270385] [] (unwind_backtrace+0x0/0xf0) from [] > >>(show_stack+0x10/0x14) > >>[2.286102] [] (show_stack+0x10/0x14) from [] > >>(warn_slowpath_common+0x4c/0x68) > >>[2.295593] [] (warn_slowpath_common+0x4c/0x68) from > >>[] (warn_slowpath_fmt+0x30/0x40) > >>[2.299987] [] (warn_slowpath_fmt+0x30/0x40) from [] > >>(l3_interrupt_handler+0x140/0x184) > >>[2.315582] [] (l3_interrupt_handler+0x140/0x184) from > >>[] (handle_irq_event_percpu+0x58/0x258) > >>[2.323364] [] (handle_irq_event_percpu+0x58/0x258) from > >>[] (handle_irq_event+0x3c/0x5c) > >>[2.327819] [] (handle_irq_event+0x3c/0x5c) from [] > >>(handle_fasteoi_irq+0xbc/0x164) > >>[2.337829] [] (handle_fasteoi_irq+0xbc/0x164) from > >>[] (generic_handle_irq+0x20/0x30) > >>[2.357513] [] (generic_handle_irq+0x20/0x30) from > >>[] (handle_IRQ+0x4c/0xac) > >>[2.366821] [] (handle_IRQ+0x4c/0xac) from [] > >>(gic_handle_irq+0x28/0x5c) > >>[2.375762] [] (gic_handle_irq+0x28/0x5c) from [] > >>(__irq_svc+0x44/0x5c) > >>[2.379821] Exception stack(0xdb085ec0 to 0xdb085f08) > >>[2.389953] 5ec0: 0001 0001 db07ea00 4113 db2317a8 > >>db084000 02f1 > >>[2.389953] 5ee0: db07ea00 c04fd990 db085f08 > >>c009170c c04f03e8 > >>[2.405609] 5f00: 2113 > >>[2.408355] [] (__irq_svc+0x44/0x5c) from [] > >>(_raw_spin_unlock_irqrestore+0x34/0x44) > >>[2.418304] [] (_raw_spin_unlock_irqrestore+0x34/0x44) from > >>[] (do_fork+0xa4/0x2d4) > >>[2.427795] [] (do_fork+0xa4/0x2d4) from [] > >>(kernel_thread+0x30/0x38) > >>[2.437805] [] (kernel_thread+0x30/0x38) from [] > >>(kthreadd+0xd4/0x13c) > >>[2.448364] [] (kthreadd+0xd4/0x13c) from [] > >>(ret_from_fork+0x14/0x2c) > >>[2.448364] ---[ end trace da8cf92c433d1616 ]--- > >> > >>The root casue of crash is race between omap_i2c_runtime_suspend() > >> and omap_i2c_isr_thread() > >If there's a race here, then it's not the same problem which is > >described above, unless the CPU2 IRQ is happening because of a shared > >user of I2C, in which case it doesn't need any additional explanation. > no shared users here > >>CPU1: CPU2: > >>|-omap_i2c_xfer | > >> |- pm_runtime_put_autosuspend() | > >> |-timeout |-omap_i2c_isr() > >> |-return IRQ_WAKE_THREAD; > >> |-omap_i2c_runtime_suspend() | > >> |-omap_i2c_isr_thread() > >> |- oops is here - I2C module is > >> in idle state > >If this is happening, I don't think it's related to $SUBJECT patch (but > >is probably hidden by it.) > I can remove "fix spurious IRQs: " from $SUBJECT. What do you think? > > > >Instead, what probably needs to happen in this is case is that > >omap_i2c_isr() should be doing a "mark last busy" to reset the > >autosuspend timeout. And, that should be done in a separate patch. this doesn't make sense... mark last busy is done after the I2C message is actually complete, so is pm_runtime_put_autosuspend() which is done following mark_last_busy. autosuspend timer shouldn't be firing since put won't be called until we're dead sure I2C message (all of them, in fact) are finalized. > Yes - from one side. From other side, this patch prevents such > situation to happen. > disable_irq(_dev->irq); - waits for any pending IRQ handlers for this > interrupt > to complete before returning. IRQ
[RFC PATCH] regulator: core: allow consumers to request to closes step voltage
Regulator consumers are not aware of the characteristics of regulator
used to supply. For example:
consumerX requests for voltage min_uV = 500mV, max_uV = 500mV
On a regulator which has a step size of 10mV, this can be exactly
achieved.
However, on a regulator which is non-exact divider step size (example
12.66mV step size), the closest achievable would be 506.4.
regulator_set_voltage_tol does not work out either as <500mV is not an
operational voltage.
Account for step size accuracy when exact voltage requests are send for
step based regulators.
Signed-off-by: Nishanth Menon
---
The specific example I faced was using cpufreq-cpu0 driver with voltages
for OPPs for MPU rail and attempting the common definitions against voltages
that are non-exact multiples of stepsize of PMIC.
The alternative would be implement custom set_voltage (as againsta simpler
set_voltage_sel and using linear map/list functions) for the regulator which
will account for the same.
Yet another alternative might be to introduce yet another custom function
similar
to regulator_set_voltage_tol which accounts for this. something like:
regulator_set_voltage_floor(regulator, voltage, tol) or something to that
effect.
drivers/regulator/core.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 288c75a..98c96b2 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -2407,6 +2407,9 @@ static int _regulator_do_set_voltage(struct regulator_dev
*rdev,
}
} else if (rdev->desc->ops->set_voltage_sel) {
+ if (min_uV == max_uV && rdev->desc->uV_step)
+ max_uV += rdev->desc->uV_step;
+
if (rdev->desc->ops->map_voltage) {
ret = rdev->desc->ops->map_voltage(rdev, min_uV,
max_uV);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] i2c: omap: fix spurious IRQs: disable/enable IRQ at INTC when idle
On 06/07/2013 11:51 PM, Kevin Hilman wrote: Grygorii Strashko writes: From: Kevin Hilman Currently, runtime PM is used to keep the device enabled only during active transfers and for a configurable runtime PM autosuspend timout after an xfer. In addition to idling the device, driver's ->runtime_suspend() method currently disables device interrupts when idle. However, on some SoCs (notably OMAP4+), the I2C hardware may shared with other coprocessors. This means that the MPU will still recieve interrupts if a coprocessor is using the I2C device. To avoid this, also disable interrupts at the MPU INTC when idling the device in ->runtime_suspend() (and re-enable them in ->runtime_resume().) This part based on an original patch from Shubhrajyoti Datta. NOTE: for proper sharing the I2C with a coprocessor, this driver still needs hwspinlock support added. More over, this patch fixes the kernel boot failure which happens when CONFIG_SENSORS_LM75=y: [2.251220] WARNING: at drivers/bus/omap_l3_noc.c:113 l3_interrupt_handler+0x140/0x184() [2.257781] L3 custom error: MASTER:MPU TARGET:L4 PER2 [2.264373] Modules linked in: [2.268463] CPU: 0 PID: 2 Comm: kthreadd Not tainted 3.10.0-rc4-00034-g042dd60-dirty #64 [2.270385] [] (unwind_backtrace+0x0/0xf0) from [] (show_stack+0x10/0x14) [2.286102] [] (show_stack+0x10/0x14) from [] (warn_slowpath_common+0x4c/0x68) [2.295593] [] (warn_slowpath_common+0x4c/0x68) from [] (warn_slowpath_fmt+0x30/0x40) [2.299987] [] (warn_slowpath_fmt+0x30/0x40) from [] (l3_interrupt_handler+0x140/0x184) [2.315582] [] (l3_interrupt_handler+0x140/0x184) from [] (handle_irq_event_percpu+0x58/0x258) [2.323364] [] (handle_irq_event_percpu+0x58/0x258) from [] (handle_irq_event+0x3c/0x5c) [2.327819] [] (handle_irq_event+0x3c/0x5c) from [] (handle_fasteoi_irq+0xbc/0x164) [2.337829] [] (handle_fasteoi_irq+0xbc/0x164) from [] (generic_handle_irq+0x20/0x30) [2.357513] [] (generic_handle_irq+0x20/0x30) from [] (handle_IRQ+0x4c/0xac) [2.366821] [] (handle_IRQ+0x4c/0xac) from [] (gic_handle_irq+0x28/0x5c) [2.375762] [] (gic_handle_irq+0x28/0x5c) from [] (__irq_svc+0x44/0x5c) [2.379821] Exception stack(0xdb085ec0 to 0xdb085f08) [2.389953] 5ec0: 0001 0001 db07ea00 4113 db2317a8 db084000 02f1 [2.389953] 5ee0: db07ea00 c04fd990 db085f08 c009170c c04f03e8 [2.405609] 5f00: 2113 [2.408355] [] (__irq_svc+0x44/0x5c) from [] (_raw_spin_unlock_irqrestore+0x34/0x44) [2.418304] [] (_raw_spin_unlock_irqrestore+0x34/0x44) from [] (do_fork+0xa4/0x2d4) [2.427795] [] (do_fork+0xa4/0x2d4) from [] (kernel_thread+0x30/0x38) [2.437805] [] (kernel_thread+0x30/0x38) from [] (kthreadd+0xd4/0x13c) [2.448364] [] (kthreadd+0xd4/0x13c) from [] (ret_from_fork+0x14/0x2c) [2.448364] ---[ end trace da8cf92c433d1616 ]--- The root casue of crash is race between omap_i2c_runtime_suspend() and omap_i2c_isr_thread() If there's a race here, then it's not the same problem which is described above, unless the CPU2 IRQ is happening because of a shared user of I2C, in which case it doesn't need any additional explanation. no shared users here CPU1: CPU2: |-omap_i2c_xfer | |- pm_runtime_put_autosuspend() | |-timeout |-omap_i2c_isr() |-return IRQ_WAKE_THREAD; |-omap_i2c_runtime_suspend() | |-omap_i2c_isr_thread() |- oops is here - I2C module is in idle state If this is happening, I don't think it's related to $SUBJECT patch (but is probably hidden by it.) I can remove "fix spurious IRQs: " from $SUBJECT. What do you think? Instead, what probably needs to happen in this is case is that omap_i2c_isr() should be doing a "mark last busy" to reset the autosuspend timeout. And, that should be done in a separate patch. Yes - from one side. From other side, this patch prevents such situation to happen. disable_irq(_dev->irq); - waits for any pending IRQ handlers for this interrupt to complete before returning. If we are in .runtime_idle() callback - it means I2C transaction has been finished (and It doesn't matter successfully or not) and we don't want to receive IRQs any more. As I mentioned in cover-latter this happens because PM runtime auto-suspend isn't working properly during the boot: [ 23.190002] omap_i2c 4835.i2c: i2c_add_numbered_adapter [ 23.204681] omap_i2c 4835.i2c: bus 3 rev0.11 at 400 kHz [ 23.211669] omap_i2c 4835.i2c: == rpm_suspend elapsed 0 last_busy 4294939616 [ 23.219879] omap_i2c 4835.i2c: == rpm_suspend expires 4294939716 last_busy 4294939616 autosuspend_delay 1000 [ 23.219879] omap_i2c 4835.i2c: == rpm_suspend expires 4294939700 [ 23.237274
Re: [PATCH 5/5] i2c: omap: remove omap_i2c_isr() hw irq handler
Hi Felipe, On 06/07/2013 10:07 PM, Felipe Balbi wrote: Hi, On Fri, Jun 07, 2013 at 09:46:08PM +0300, Grygorii Strashko wrote: The omap_i2c_isr() does the irq check and schedules threaded handler if any of enabled IRQs is active, but currently the I2C IRQs are enabled just once, when I2C IP is enabling (transfer started) and they aren't changed after that. More over, now the I2C INTC IRQ is disabled when I2C IP is idled. Thus, I2C IRQs will start coming only when we want that, and there is no sense to have omap_i2c_isr() anymore: so ? we still want to check if this device generated IRQs in hardirq context. What if the IRQ line is shared ? Pleas see, https://patchwork.kernel.org/patch/2689211/ [1/5] i2c: omap: fix spurious IRQs: disable/enable IRQ at INTC when idle It covers shared IRQ problem Sorry, for delayed reply - I've had problems with my e-mail. - grygorii -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5] i2c: omap: add runtime check in isr to be sure that i2c is enabled
Hi Felipe,
On 06/07/2013 10:02 PM, Felipe Balbi wrote:
Hi,
On Fri, Jun 07, 2013 at 09:46:05PM +0300, Grygorii Strashko wrote:
Add runtime check at the beginning of omap_i2c_isr/omap_i2c_isr_thread
to be sure that i2c is enabled, before performing IRQ handling and accessing
I2C IP registers:
if (pm_runtime_suspended(dev->dev)) {
WARN_ONCE(true, "We should never be here!\n");
return IRQ_NONE;
}
Produce warning in case if ISR called when i2c is disabled
CC: Kevin Hilman
Signed-off-by: Grygorii Strashko
---
drivers/i2c/busses/i2c-omap.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 97844ff..2dac598 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -885,6 +885,11 @@ omap_i2c_isr(int irq, void *dev_id)
u16 stat;
spin_lock(&dev->lock);
+ if (pm_runtime_suspended(dev->dev)) {
+ WARN_ONCE(true, "We should never be here!\n");
+ return IRQ_NONE;
+ }
returning IRQ_NONE is not what you want to do in this case. You want to
setup a flag so that your runtime_resume() knows that there are pending
events to be handled and you handle those in runtime_resume time.
I don't want to handle this IRQ - we should never be here.
Will be changed to IRQ_HANDLED.
But to be frank, I don't see how this can trigger since we're calling
pm_runtime_get_sync() from omap_i2c_xfer() which means by the time
pm_runtime_get_sync() returns, assuming no errors, i2c module should be
fully resumed and ready to go. Perhaps you have found a bug somewhere
else ?
May be it's better to revert this patch:
e3a36b207f76364c281aeecaf14c1b22a7247278
i2c: omap: remove unnecessary pm_runtime_suspended check
which doesn't cover case when transfer is *finished*.
Please, see https://patchwork.kernel.org/patch/2689211/ and
cover-latter.
Also, your 'We should never be here' message isn't helpfull at all.
@@ -905,6 +910,11 @@ omap_i2c_isr_thread(int this_irq, void *dev_id)
u16 stat;
int err = 0, count = 0;
+ if (pm_runtime_suspended(dev->dev)) {
+ WARN_ONCE(true, "We should never be here!\n");
+ return IRQ_NONE;
+ }
because of IRQF_ONESHOT I can't see how this would *ever* be a valid
check.
Please, see https://patchwork.kernel.org/patch/2689211/ and
cover-latter.
Sorry, for delayed reply - I've had problems with my e-mail.
- grygorii
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] i2c: omap: handle all irqs befor unblocking omap_i2c_xfer_msg()
Hi Felipe, On 06/07/2013 10:05 PM, Felipe Balbi wrote: Hi, On Fri, Jun 07, 2013 at 09:46:06PM +0300, Grygorii Strashko wrote: ARDY|NACK and ARDY|AL are set together in OMAP_I2C_STAT_REG, which will be Have you seen that happen ever ? AL is Arbitration Lost, we never put OMAP in a multi-master environment before. This is an example from real life: [0.271942] omap_i2c omap_i2c.1: bus 1 rev2.4.0 at 400 kHz [1.283416] omap_i2c omap_i2c.1: timeout waiting for bus ready [1.300109] OMAP_I2C DEBUG: stat=1001 [1.300140] omap_i2c omap_i2c.1: Arbitration lost [1.300140] OMAP_I2C DEBUG: IE=601F [1.300140] OMAP_I2C DEBUG: STAT=1000 [1.300170] OMAP_I2C DEBUG: IV=636F [1.300170] OMAP_I2C DEBUG: WE=636F [1.300170] OMAP_I2C DEBUG: SYSS=1 [1.300170] OMAP_I2C DEBUG: BUF=707 [1.300201] OMAP_I2C DEBUG: CNT=1 [1.300201] OMAP_I2C DEBUG: DATA=1 [1.300201] OMAP_I2C DEBUG: SYSC=215 [1.300201] OMAP_I2C DEBUG: CON=8200 [1.300231] OMAP_I2C DEBUG: OA=0 [1.300231] OMAP_I2C DEBUG: SA=49 [1.300231] OMAP_I2C DEBUG: PSC=9 [1.300262] OMAP_I2C DEBUG: SCLL=9 [1.300262] OMAP_I2C DEBUG: SCLH=3 [1.300262] OMAP_I2C DEBUG: SYSTEST=1E0 [1.300262] OMAP_I2C DEBUG: BUFSTAT=4000 and my headache now :..( ARDY | NACK I also find it a bit hard for those two to happen together since ARDY will be set when you can change controller's register *again*, mening that a transfer has completed. There are examples: [3.544952] omap_i2c 4806.i2c: IRQ (ISR = 0x0006) [ 25.574523] omap_i2c 4835.i2c: IRQ (ISR = 0x0014) [ 25.579925] omap_i2c 4835.i2c: IRQ (ISR = 0x0012) to see it - enable debug output in omap_i2c_isr_thread: dev_dbg(dev->dev, "IRQ (ISR = 0x%04x)\n", stat); Also, we need to follow what the programming model says. And, I don't have docs with me right now, but IIRC it tells us to bail out if any of the error conditions are met. yep, but first of all - all IRQs need to be acked before exit. Sorry, for delayed reply - I've had problems with my e-mail. - grygorii -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 5/6] ARM: dts: omap3beagle-xm: Add idle state pins for USB host
Roger Quadros writes:
> Add the Idle state pins for USB host and enable WAKEUP on
> DIR, DAT0-3, so that the PHY can wakeup the OMAP SoC from
> sleep on any USB activity (e.g. remote wakeup or connect/disconnect).
>
> CC: Benoît Cousson
> Signed-off-by: Roger Quadros
This one doesn't apply...
> ---
> arch/arm/boot/dts/omap3-beagle-xm.dts | 29 +++--
> 1 files changed, 23 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts
> b/arch/arm/boot/dts/omap3-beagle-xm.dts
> index d3808ed..f1d56c2 100644
> --- a/arch/arm/boot/dts/omap3-beagle-xm.dts
> +++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
> @@ -89,12 +89,7 @@
> };
>
> &omap3_pmx_core {
> - pinctrl-names = "default";
> - pinctrl-0 = <
> - &hsusbb2_pins
> - >;
> -
> - hsusbb2_pins: pinmux_hsusbb2_pins {
This omap3_pmx_core section doesn't exist upstream in the xM DTS file
(but does in omap3-beagle.dts.)
Is there a dependency patch missing?
Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 2/2] i2c: gpio: drop class based instantiation of slaves
Class based instantiation mechanism can cause huge delays when booting. For example: when CONFIG_SENSORS_LM75 option is enabled for or omap5-uevm board, where i2c-gpio is used for HDMI edid reading - it introduces up to 5 sec boot delay. It's not recommended to use this mechanism with embedded I2C, so disable it by leaving I2C adapter "class" field undefined (remove I2C_CLASS_HWMON and I2C_CLASS_SPD) and add a deprecation warning to allow users, relying on this mechanism, to switch to something better. CC: Haavard Skinnemoen Signed-off-by: Grygorii Strashko --- drivers/i2c/busses/i2c-gpio.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/i2c/busses/i2c-gpio.c b/drivers/i2c/busses/i2c-gpio.c index bc6e139..33e3d0e 100644 --- a/drivers/i2c/busses/i2c-gpio.c +++ b/drivers/i2c/busses/i2c-gpio.c @@ -215,7 +215,7 @@ static int i2c_gpio_probe(struct platform_device *pdev) snprintf(adap->name, sizeof(adap->name), "i2c-gpio%d", pdev->id); adap->algo_data = bit_data; - adap->class = I2C_CLASS_HWMON | I2C_CLASS_SPD; + adap->class = I2C_CLASS_DEPRECATED; adap->dev.parent = &pdev->dev; adap->dev.of_node = pdev->dev.of_node; -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 1/2] i2c: omap: drop class based instantiation of slaves
Class based instantiation mechanism can cause huge delays when booting. For example: when CONFIG_SENSORS_LM75 option is enabled for omap4-sdp board - it introduces 5-6 ms boot delay. It's not recommended to use this mechanism with embedded I2C, so disable it by leaving I2C adapter "class" field undefined (remove I2C_CLASS_HWMON). CC: Tony Lindgren Signed-off-by: Grygorii Strashko --- drivers/i2c/busses/i2c-omap.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index f06109f..ae2b27f 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -1231,7 +1231,7 @@ omap_i2c_probe(struct platform_device *pdev) adap = &dev->adapter; i2c_set_adapdata(adap, dev); adap->owner = THIS_MODULE; - adap->class = I2C_CLASS_HWMON | I2C_CLASS_DEPRECATED; + adap->class = I2C_CLASS_DEPRECATED; strlcpy(adap->name, "OMAP I2C adapter", sizeof(adap->name)); adap->algo = &omap_i2c_algo; adap->dev.parent = &pdev->dev; -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] i2c: add deprecation warning for class based instantiation
On 06/07/2013 12:09 PM, Wolfram Sang wrote: Class based instantiation can cause huge delays when booting. This mechanism was used when it was not possible to describe slaves on I2C busses. We now have other mechanisms, so most embedded I2C will not need classes and it was explicitly not recommended to use them. Add a deprecation warning for drivers who want to disable class based in the near future to gain boot-up time, so users relying on this technique can switch to something better. They really should. Signed-off-by: Wolfram Sang --- drivers/i2c/busses/i2c-omap.c |2 +- drivers/i2c/i2c-core.c|6 ++ include/linux/i2c.h |1 + 3 files changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index e02f9e3..f06109f 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -1231,7 +1231,7 @@ omap_i2c_probe(struct platform_device *pdev) adap = &dev->adapter; i2c_set_adapdata(adap, dev); adap->owner = THIS_MODULE; - adap->class = I2C_CLASS_HWMON; + adap->class = I2C_CLASS_HWMON | I2C_CLASS_DEPRECATED; strlcpy(adap->name, "OMAP I2C adapter", sizeof(adap->name)); adap->algo = &omap_i2c_algo; adap->dev.parent = &pdev->dev; diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c index 48e31ed..47ea1f0 100644 --- a/drivers/i2c/i2c-core.c +++ b/drivers/i2c/i2c-core.c @@ -999,6 +999,12 @@ static int i2c_register_adapter(struct i2c_adapter *adap) return -EINVAL; } + if (adap->class & I2C_CLASS_DEPRECATED) + dev_warn(&adap->dev, "This adapter will soon drop class based " + "instantiation of slaves\nPlease make sure all its I2C " + "devices are instantiated by other means.\nCheck " + "'Documentation/i2c/instantiating-devices' for details\n"); + Seems, this need to be moved down - after res = device_register(&adap->dev); - or - right before: bus_for_each_drv(&i2c_bus_type, NULL, adap, __process_new_adapter); rt_mutex_init(&adap->bus_lock); mutex_init(&adap->userspace_clients_lock); INIT_LIST_HEAD(&adap->userspace_clients); diff --git a/include/linux/i2c.h b/include/linux/i2c.h index e988fa9..ffab838 100644 --- a/include/linux/i2c.h +++ b/include/linux/i2c.h @@ -473,6 +473,7 @@ void i2c_unlock_adapter(struct i2c_adapter *); #define I2C_CLASS_HWMON (1<<0)/* lm_sensors, ... */ #define I2C_CLASS_DDC (1<<3)/* DDC bus on graphics adapters */ #define I2C_CLASS_SPD (1<<7)/* Memory modules */ +#define I2C_CLASS_DEPRECATED (1<<8)/* Warn users that adapter will stop using classes */ /* Internal numbers to terminate lists */ #define I2C_CLIENT_END0xfffeU - grygorii -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] i2c: add deprecation warning for class based instantiation
Hi Wolfram,
On 06/19/2013 01:15 PM, Wolfram Sang wrote:
On Fri, Jun 07, 2013 at 11:09:26AM +0200, Wolfram Sang wrote:
Class based instantiation can cause huge delays when booting. This
mechanism was used when it was not possible to describe slaves on I2C
busses. We now have other mechanisms, so most embedded I2C will not need
classes and it was explicitly not recommended to use them. Add a
deprecation warning for drivers who want to disable class based in the
near future to gain boot-up time, so users relying on this technique can
switch to something better. They really should.
Signed-off-by: Wolfram Sang
No reactions on this, pity. Deferring.
Sorry, for delayed reply - I've had problems with my e-mail.
I've tested this patch on our TI K3.4 product kernel with additional
change below:
diff --git a/drivers/i2c/busses/i2c-gpio.c b/drivers/i2c/busses/i2c-gpio.c
index c0330a4..442101d 100644
--- a/drivers/i2c/busses/i2c-gpio.c
+++ b/drivers/i2c/busses/i2c-gpio.c
@@ -186,7 +186,7 @@ static int __devinit i2c_gpio_probe(struct
platform_device *pdev)
adap->owner = THIS_MODULE;
snprintf(adap->name, sizeof(adap->name), "i2c-gpio%d", pdev->id);
adap->algo_data = bit_data;
- adap->class = I2C_CLASS_HWMON | I2C_CLASS_SPD;
+ adap->class = I2C_CLASS_HWMON | I2C_CLASS_SPD |
I2C_CLASS_DEPRECATED;
adap->dev.parent = &pdev->dev;
adap->dev.of_node = pdev->dev.of_node;
It works fine, in general - see my minor comment inline.
[0.662536] omap_i2c omap_i2c.2: bus 2 rev2.4.0 at 400 kHz
[0.662567] (null): This adapter will soon drop class based
instantiation of slaves
^ invalid adapter device name here
[0.662567] Please make sure all its I2C devices are instantiated by
other means.
[0.662567] Check 'Documentation/i2c/instantiating-devices' for details
Also tested on Linux master - OMAP4 SDP board.
In addition, I've found the following users of *i2c-gpio* (just FYI):
./arch/powerpc/boot/dts/wii.dts:compatible = "i2c-gpio";
./arch/mips/alchemy/board-gpr.c:.name= "i2c-gpio",
./arch/mips/ath79/mach-pb44.c:.name= "i2c-gpio",
./arch/avr32/boards/merisc/setup.c:.name= "i2c-gpio",
./arch/avr32/boards/atngw100/setup.c:.name= "i2c-gpio",
./arch/avr32/boards/hammerhead/setup.c:.name= "i2c-gpio",
./arch/avr32/boards/mimc200/setup.c:.name= "i2c-gpio",
./arch/blackfin/mach-bf533/boards/blackstamp.c:.name=
"i2c-gpio",
./arch/blackfin/mach-bf533/boards/ezkit.c:.name= "i2c-gpio",
./arch/blackfin/mach-bf533/boards/stamp.c:.name= "i2c-gpio",
./arch/blackfin/mach-bf561/boards/ezkit.c:.name= "i2c-gpio",
./arch/arm/mach-ep93xx/core.c:.name= "i2c-gpio",
./arch/arm/mach-shmobile/board-armadillo800eva.c:.name = "i2c-gpio",
./arch/arm/mach-pxa/viper.c:.name= "i2c-gpio",
./arch/arm/mach-pxa/viper.c:tpm_device =
platform_device_alloc("i2c-gpio", 2);
./arch/arm/mach-pxa/palmz72.c:.name= "i2c-gpio",
./arch/arm/boot/dts/at91sam9g45.dtsi:compatible = "i2c-gpio";
./arch/arm/boot/dts/at91sam9263.dtsi:compatible = "i2c-gpio";
./arch/arm/boot/dts/at91sam9x5.dtsi:compatible = "i2c-gpio";
./arch/arm/boot/dts/at91sam9x5.dtsi:compatible = "i2c-gpio";
./arch/arm/boot/dts/at91sam9x5.dtsi:compatible = "i2c-gpio";
./arch/arm/boot/dts/usb_a9g20-dab-mmx.dtsi:i2c-gpio@0 {
./arch/arm/boot/dts/ste-nomadik-stn8815.dtsi:compatible =
"i2c-gpio";
./arch/arm/boot/dts/ste-nomadik-stn8815.dtsi:compatible =
"i2c-gpio";
./arch/arm/boot/dts/ste-nomadik-stn8815.dtsi:compatible =
"i2c-gpio";
./arch/arm/boot/dts/at91sam9260.dtsi:compatible = "i2c-gpio";
./arch/arm/boot/dts/at91rm9200.dtsi:compatible = "i2c-gpio";
./arch/arm/boot/dts/at91sam9n12.dtsi:compatible = "i2c-gpio";
./arch/arm/mach-ks8695/board-acs5k.c:.name= "i2c-gpio",
./arch/arm/mach-s5pv210/mach-goni.c:.name= "i2c-gpio",
./arch/arm/mach-s5pv210/mach-goni.c:.name= "i2c-gpio",
./arch/arm/mach-s5pv210/mach-aquila.c:.name= "i2c-gpio",
./arch/arm/mach-s5pv210/mach-aquila.c:.name= "i2c-gpio",
./arch/arm/mach-sa1100/simpad.c:.name = "i2c-gpio",
./arch/arm/mach-exynos/mach-universal_c210.c:.name= "i2c-gpio",
./arch/arm/mach-exynos/mach-nuri.c:.name= "i2c-gpio",
./arch/arm/mach-at91/at91sam9263_devices.c:.name=
"i2c-gpio",
./arch/arm/mach-at91/at91sam9261_devices.c:.name=
"i2c-gpio",
./arch/arm/mach-at91/at91sam9g45_devices.c:.name=
"i2c-gpio",
./arch/arm/mach-at91/at91sam9g45_devices.c:.name=
"i2c-gpio",
./arch/arm/mach-at91/at91rm9200_devices.c:.name= "i2c-gpio",
./arch/arm/mach-at91/at91sam9260_devices.c:.name=
"i2c-gpio",
./arch/arm/mach-at91/at91sam9rl_de
Re: [PATCH v2 1/4] ARM: dts: omap4-panda: Add USB Host support
On 06/19/2013 09:05 AM, Roger Quadros wrote:
On 06/19/2013 03:23 PM, Benoit Cousson wrote:
On 06/19/2013 07:05 AM, Florian Vaussard wrote:
Hello,
On 06/19/2013 01:03 PM, Roger Quadros wrote:
On 06/19/2013 01:10 PM, Benoit Cousson wrote:
On 06/19/2013 02:46 AM, Tony Lindgren wrote:
* Roger Quadros [130619 00:42]:
Hi Benoit,
On 06/19/2013 04:17 AM, Benoit Cousson wrote:
Hi Roger,
On 06/18/2013 11:04 AM, Roger Quadros wrote:
Provide the RESET and Power regulators for the USB PHY,
the USB Host port mode and the PHY device.
Also provide pin multiplexer information for the USB host
pins.
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 62
+
1 files changed, 62 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 00cbaa5..7a21e8e 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -59,6 +59,42 @@
"AFML", "Line In",
"AFMR", "Line In";
};
+
+/* HS USB Port 1 RESET */
+hsusb1_reset: hsusb1_reset_reg {
+compatible = "regulator-fixed";
+regulator-name = "hsusb1_reset";
+regulator-min-microvolt = <330>;
+regulator-max-microvolt = <330>;
+gpio = <&gpio2 30 0>;/* gpio_62 */
+startup-delay-us = <7>;
+enable-active-high;
+};
Is this really a regulator? Or just a GPIO line used to reset the
USB PHY?
It is in fact a GPIO line used as reset.
If this is the case, I don't think it should be represented as a
regulator.
Why not? I think it fits very well in the regulator device model.
I'm not sure fitting very well is the correct term.
It works, for sure, but it is no different than when we were trying
to abuse the regulator fmwk to enable the 32k clock in phoenix.
It is just a hack.
The only difference is there is a dedicated framework for clocks.
Since there is nothing specific to
handle reset lines it is left to the driver writer how he wants to
manage it.
There is a proposed binding for gpio-controlled reset lines, but it is
not yet merged [1].
I guess it can fit most usage patterns, and it can be an interesting
move in the future.
I'm glad to see that I was not the only one thinking that the regulator was not
the right fmwk to do that :-)
Thanks for the pointer Florian.
Thanks again Florian.
I guess that series should be merged for 3.11? Based on the thread, it should
to through arm-soc.
Roger,
It might be tricky to have dependency on that series, but if this is possible,
you should try. Otherwise, just keep the existing one, adding that a new
solution will be available soon as a disclaimer.
I will rework the PHY driver to use the new gpio-reset driver. But for 3.11
let's proceed the way it is.
I'll resend this one with a disclaimer.
OK, sounds good.
Thanks,
Benoit
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP2: reboot: Include common.h to fix build error
Include common.h which will include linux/reboot.h to fix below build error.
CC arch/arm/mach-omap2/omap4-restart.o
arch/arm/mach-omap2/omap4-restart.c:21:28: warning: 'enum reboot_mode' declared
inside parameter list [enabled by default]
arch/arm/mach-omap2/omap4-restart.c:21:28: warning: its scope is only this
definition or declaration, which is probably not what you want [enabled by
default]
arch/arm/mach-omap2/omap4-restart.c:21:40: error: parameter 1 ('mode') has
incomplete type
arch/arm/mach-omap2/omap4-restart.c:21:6: warning: function declaration isn't a
prototype [-Wstrict-prototypes]
make[1]: *** [arch/arm/mach-omap2/omap4-restart.o] Error 1
make: *** [arch/arm/mach-omap2] Error 2
Signed-off-by: Axel Lin
---
Seems this build error is introduced by commit 7507d035f3cf40c
"reboot: arm: change reboot_mode to use enum reboot_mode"
This patch is against linux-next 20130619.
arch/arm/mach-omap2/omap4-restart.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-omap2/omap4-restart.c
b/arch/arm/mach-omap2/omap4-restart.c
index 652adde..7306d9b 100644
--- a/arch/arm/mach-omap2/omap4-restart.c
+++ b/arch/arm/mach-omap2/omap4-restart.c
@@ -9,6 +9,7 @@
#include
#include "prminst44xx.h"
+#include "common.h"
/**
* omap44xx_restart - trigger a software restart of the SoC
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 4/6] USB: ehci-omap: Suspend the controller during bus suspend
Hi Roger, Roger Quadros writes: > Runtime suspend the controller during bus suspend and resume it > during bus resume. This will ensure that the USB Host power domain > enters lower power state and does not prevent the SoC from > endering deeper sleep states. > > Remote wakeup will come up as an interrupt while the controller > is suspended, so tackle it carefully using a workqueue. I don't think you need a special workqueue here. The workqueue of the PM core (pm_wq) will be used if you just use an asynchronous 'get' in the ISR. Then, the driver's own runtime PM callbacks can be used instead of an additional workqueue. Another thing to worry about here when using runtime PM to implement suspend/resume is that runtime PM can be disabled from userspace (e.g. echo disabled > /sys/devices/.../power/control.) If that's the case, all the pm_runtime_suspended() checks will always fail becuase that call also checks if runtime PM is disabled. You'll likely want to use the pm_runtime_status_suspended() check instead, which checks only the status, and doesn't matter if runtime PM is currently disabled. Because of the corner issues here, please test system suspend/resume when runtime PM has been disabled. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 6/6] ARM: OMAP3: Enable Hardware Save and Restore for USB Host
Hello.
On 06/19/2013 06:05 PM, Roger Quadros wrote:
To ensure hardware context is restored while resuming from
OFF mode we need to enable the Hardware SAR bit for the
USB Host power domain.
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap2/powerdomains3xxx_data.c |8 +---
1 files changed, 1 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomains3xxx_data.c
b/arch/arm/mach-omap2/powerdomains3xxx_data.c
index f0e14e9..9554d2b 100644
--- a/arch/arm/mach-omap2/powerdomains3xxx_data.c
+++ b/arch/arm/mach-omap2/powerdomains3xxx_data.c
@@ -289,13 +289,7 @@ static struct powerdomain usbhost_pwrdm = {
.prcm_offs= OMAP3430ES2_USBHOST_MOD,
.pwrsts = PWRSTS_OFF_RET_ON,
.pwrsts_logic_ret = PWRSTS_RET,
- /*
-* REVISIT: Enabling usb host save and restore mechanism seems to
-* leave the usb host domain permanently in ACTIVE mode after
-* changing the usb host power domain state from OFF to active once.
-* Disabling for now.
-*/
- /*.flags = PWRDM_HAS_HDWR_SAR,*/ /* for USBHOST ctrlr only */
+ .flags= PWRDM_HAS_HDWR_SAR, /* for USBHOST ctrlr only */
Looks like you're not indenting = right, in accordance to the other
fields...
.banks= 1,
.pwrsts_mem_ret = {
[0] = PWRSTS_RET, /* MEMRETSTATE */
WBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] musb: musb: dsps: support multiple instances
On 06/18/2013 10:27 AM, Felipe Balbi wrote:
>> --- a/arch/arm/boot/dts/am33xx.dtsi +++
>> b/arch/arm/boot/dts/am33xx.dtsi @@ -341,6 +341,14 @@ port1-mode =
>> <3>; power = <250>; ti,hwmods = "usb_otg_hs"; + phys =
>> <&nopphy0 &nopphy1>; + }; + + nopphy0: usbphy@0 { +
>> compatible = "usb-nop-xceiv"; + }; +nopphy1:
>> usbphy@1 { +
>> compatible = "usb-nop-xceiv"; };
>>
>> mac: ethernet@4a10 {
Any opinion on those phy nodes? Is it likely that we need a real phy
driver here and also expose a little more information like the memory
register or reset / vcc supply?
Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 2/6] mfd: omap-usb-host: Put pins in IDLE state on suspend
Hi Roger, Roger Quadros writes: > In order to support wake up from suspend use the pinctrl > framework to put the USB host pins in IDLE state during suspend. > > CC: Samuel Ortiz > Signed-off-by: Roger Quadros You should use helpers for this now in the pinctrl core: http://lists.infradead.org/pipermail/linux-arm-kernel/2013-June/173514.html Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/4] MFD: Palmas: Check if irq is valid
On 06/18/2013 11:57 PM, Keerthy wrote: > From: J Keerthy > > Check if irq value obtained is valid. If it is not valid > then skip the irq request step and go ahead with the probe. Reviewed-by: Stephen Warren -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/4] MFD: Palmas: Check if irq is valid
On Wed, Jun 19, 2013 at 11:27:47AM +0530, Keerthy wrote: > From: J Keerthy > > Check if irq value obtained is valid. If it is not valid > then skip the irq request step and go ahead with the probe. > > Signed-off-by: J Keerthy Reviewed-by: Mark Brown signature.asc Description: Digital signature
Re: [PATCH v3 4/4] regulator: Palmas: Add TPS659038 support
On Wed, Jun 19, 2013 at 11:27:50AM +0530, Keerthy wrote: > From: J Keerthy > > Add TPS659038 support. > > Signed-off-by: J Keerthy This doesn't apply against my current tree as the PMIC bindings document isn't in mainline yet. Acked-by: Mark Brown assuming there's a tree where that does exist. signature.asc Description: Digital signature
[PATCH 1/1] ARM: OMAP3: igep0020: Set DSS pins in correct mux mode.
From: Enric Balletbo i Serra
Platform code used to depend on bootloadres for correctly setting the mux
pin modes. But bootloaders should only set the minimum required mux pins.
So, DSS mux pins are not set in U-Boot anymore and video display is broken
on IGEPv2 when booting with newer U-Boot versions.
Setup the DSS pin muxes to enable display functionality.
Signed-off-by: Enric Balletbo i Serra
Reviewed-by: Javier Martinez Canillas
---
Tony,
Can you please take this until we have finished the OMAP3 migration to DT?
I think it falls under the critical fix category that you were talking about.
Thanks a lot and best regards,
Javier
arch/arm/mach-omap2/board-igep0020.c | 31 +++
1 files changed, 31 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
index b54562d..87e65dd 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -553,6 +553,37 @@ static struct usbhs_omap_platform_data igep3_usbhs_bdata
__initdata = {
#ifdef CONFIG_OMAP_MUX
static struct omap_board_mux board_mux[] __initdata = {
+ /* Display Sub System */
+ OMAP3_MUX(DSS_PCLK, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_HSYNC, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_VSYNC, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_ACBIAS, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA0, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA1, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA2, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA3, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA4, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA5, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA6, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA7, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA8, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA9, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA10, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA11, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA12, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA13, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA14, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA15, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA16, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA17, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA18, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA19, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA20, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA21, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA22, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA23, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ /* TFP410 PanelBus DVI Transmitte (GPIO_170) */
+ OMAP3_MUX(HDQ_SIO, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT),
/* SMSC9221 LAN Controller ETH IRQ (GPIO_176) */
OMAP3_MUX(MCSPI1_CS2, OMAP_MUX_MODE4 | OMAP_PIN_INPUT),
{ .reg_offset = OMAP_MUX_TERMINATOR },
--
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 1/9] drivers: phy: add generic PHY framework
Hi,
On 06/13/2013 10:43 AM, Kishon Vijay Abraham I wrote:
> +/**
> + * phy_create() - create a new phy
> + * @dev: device that is creating the new phy
> + * @id: id of the phy
> + * @ops: function pointers for performing phy operations
> + * @label: label given to the phy
> + * @priv: private data from phy driver
> + *
> + * Called to create a phy using phy framework.
> + */
> +struct phy *phy_create(struct device *dev, u8 id, const struct phy_ops *ops,
> + const char *label, void *priv)
> +{
> + int ret;
> + struct phy *phy;
> +
> + if (!dev) {
> + dev_WARN(dev, "no device provided for PHY\n");
> + ret = -EINVAL;
> + goto err0;
> + }
> +
> + phy = kzalloc(sizeof(*phy), GFP_KERNEL);
> + if (!phy) {
> + ret = -ENOMEM;
> + goto err0;
> + }
> +
> + device_initialize(&phy->dev);
> +
> + phy->dev.class = phy_class;
> + phy->dev.parent = dev;
> + phy->dev.of_node = dev->of_node;
> + phy->id = id;
> + phy->ops = ops;
> + phy->label = label;
Perhaps we could make it:
phy->label = kstrdup(label, GFP_KERNEL);
and free the label in phy_destroy() ?
That way the users would't need to keep the label around. It might
be useful when PHY provider generates the labels dynamically. I guess
it is OK for PHY providers to hard code the labels and having the PHY
user drivers passed labels in platform data ?
> + dev_set_drvdata(&phy->dev, priv);
> +
> + ret = dev_set_name(&phy->dev, "%s.%d", dev_name(dev), id);
> + if (ret)
> + goto err1;
> +
> + ret = device_add(&phy->dev);
> + if (ret)
> + goto err1;
> +
> + if (pm_runtime_enabled(dev))
> + pm_runtime_enable(&phy->dev);
> +
> + return phy;
> +
> +err1:
> + put_device(&phy->dev);
> + kfree(phy);
> +
> +err0:
> + return ERR_PTR(ret);
> +}
> +EXPORT_SYMBOL_GPL(phy_create);
> +/**
> + * phy_destroy() - destroy the phy
> + * @phy: the phy to be destroyed
> + *
> + * Called to destroy the phy.
> + */
> +void phy_destroy(struct phy *phy)
> +{
> + pm_runtime_disable(&phy->dev);
> + device_unregister(&phy->dev);
Isn't kfree(phy); missing here ?
> +}
> +EXPORT_SYMBOL_GPL(phy_destroy);
Thanks,
Sylwester
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/6] Suspend USB Host controller on bus suspend
On Wed, 19 Jun 2013, Roger Quadros wrote: > Hi, > > This series attempts to suspend the OMAP EHCI host controller on USB > Bus suspend. Why do you want to suspend the host controller during bus suspend? They are two different operations and should be carried out at two different times. The controller should be suspended during controller suspend, not during bus suspend. > As the omap-ehci controller driver needs to do some additional work to put > itself into suspend/resume and make sure it is resumed to process an > interrupt, > we need to be able to override irq, bus_suspend, and bus_resume handlers. This > provision is done in patch 3. Do you still need to override these things if you do the controller suspend at the right time? Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 3/6] USB: ehci: allow controller drivers to override irq & bus_suspend/resume
Some drivers (e.g. ehci_omap) need to do additional work in
bus suspend/resume and interrupt handler to support low power
modes and remote wakeup.
Allow drivers to override these functions through ehci_driver_overrides.
Also export the ehci_irq(), ehci_bus_suspend() and ehci_bus_resume()
functions so they can be called from the controller drivers.
CC: Alan Stern
Signed-off-by: Roger Quadros
---
drivers/usb/host/ehci-hcd.c |9 -
drivers/usb/host/ehci-hub.c |6 --
drivers/usb/host/ehci.h |6 ++
3 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index 246e124..8d35dd4 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -681,7 +681,7 @@ EXPORT_SYMBOL_GPL(ehci_setup);
/*-*/
-static irqreturn_t ehci_irq (struct usb_hcd *hcd)
+irqreturn_t ehci_irq(struct usb_hcd *hcd)
{
struct ehci_hcd *ehci = hcd_to_ehci (hcd);
u32 status, masked_status, pcd_status = 0, cmd;
@@ -828,6 +828,7 @@ dead:
usb_hcd_poll_rh_status(hcd);
return IRQ_HANDLED;
}
+EXPORT_SYMBOL_GPL(ehci_irq);
/*-*/
@@ -1211,6 +1212,12 @@ void ehci_init_driver(struct hc_driver *drv,
drv->hcd_priv_size += over->extra_priv_size;
if (over->reset)
drv->reset = over->reset;
+ if (over->bus_suspend)
+ drv->bus_suspend = over->bus_suspend;
+ if (over->bus_resume)
+ drv->bus_resume = over->bus_resume;
+ if (over->irq)
+ drv->irq = over->irq;
}
}
EXPORT_SYMBOL_GPL(ehci_init_driver);
diff --git a/drivers/usb/host/ehci-hub.c b/drivers/usb/host/ehci-hub.c
index 9ab4a4d..1fc03f9 100644
--- a/drivers/usb/host/ehci-hub.c
+++ b/drivers/usb/host/ehci-hub.c
@@ -218,7 +218,7 @@ static void ehci_adjust_port_wakeup_flags(struct ehci_hcd
*ehci,
spin_unlock_irq(&ehci->lock);
}
-static int ehci_bus_suspend (struct usb_hcd *hcd)
+int ehci_bus_suspend(struct usb_hcd *hcd)
{
struct ehci_hcd *ehci = hcd_to_ehci (hcd);
int port;
@@ -348,10 +348,11 @@ static int ehci_bus_suspend (struct usb_hcd *hcd)
hrtimer_cancel(&ehci->hrtimer);
return 0;
}
+EXPORT_SYMBOL_GPL(ehci_bus_suspend);
/* caller has locked the root hub, and should reset/reinit on error */
-static int ehci_bus_resume (struct usb_hcd *hcd)
+int ehci_bus_resume(struct usb_hcd *hcd)
{
struct ehci_hcd *ehci = hcd_to_ehci (hcd);
u32 temp;
@@ -489,6 +490,7 @@ static int ehci_bus_resume (struct usb_hcd *hcd)
spin_unlock_irq(&ehci->lock);
return -ESHUTDOWN;
}
+EXPORT_SYMBOL_GPL(ehci_bus_resume);
#else
diff --git a/drivers/usb/host/ehci.h b/drivers/usb/host/ehci.h
index 7c978b2..992d626 100644
--- a/drivers/usb/host/ehci.h
+++ b/drivers/usb/host/ehci.h
@@ -795,15 +795,21 @@ static inline u32 hc32_to_cpup (const struct ehci_hcd
*ehci, const __hc32 *x)
struct ehci_driver_overrides {
size_t extra_priv_size;
int (*reset)(struct usb_hcd *hcd);
+ int (*bus_suspend)(struct usb_hcd *hcd);
+ int (*bus_resume)(struct usb_hcd *hcd);
+ irqreturn_t (*irq) (struct usb_hcd *hcd);
};
extern voidehci_init_driver(struct hc_driver *drv,
const struct ehci_driver_overrides *over);
extern int ehci_setup(struct usb_hcd *hcd);
+extern irqreturn_t ehci_irq(struct usb_hcd *hcd);
#ifdef CONFIG_PM
extern int ehci_suspend(struct usb_hcd *hcd, bool do_wakeup);
extern int ehci_resume(struct usb_hcd *hcd, bool hibernated);
+extern int ehci_bus_suspend(struct usb_hcd *hcd);
+extern int ehci_bus_resume(struct usb_hcd *hcd);
#endif /* CONFIG_PM */
#endif /* __LINUX_EHCI_HCD_H */
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 2/6] mfd: omap-usb-host: Put pins in IDLE state on suspend
In order to support wake up from suspend use the pinctrl
framework to put the USB host pins in IDLE state during suspend.
CC: Samuel Ortiz
Signed-off-by: Roger Quadros
---
drivers/mfd/omap-usb-host.c | 46 +++
1 files changed, 46 insertions(+), 0 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 6601a49..171cc3b 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include "omap-usb.h"
@@ -111,6 +112,10 @@ struct usbhs_hcd_omap {
struct usbhs_omap_platform_data *pdata;
u32 usbhs_rev;
+
+ struct pinctrl *pinctrl;
+ struct pinctrl_state *pins_default;
+ struct pinctrl_state *pins_idle;
};
/*-*/
@@ -325,6 +330,10 @@ static int usbhs_runtime_resume(struct device *dev)
dev_dbg(dev, "usbhs_runtime_resume\n");
+ if (!IS_ERR(omap->pins_default))
+ if (pinctrl_select_state(omap->pinctrl, omap->pins_default))
+ dev_err(dev, "Could not select DEFAULT pin state\n");
+
omap_tll_enable(pdata);
if (!IS_ERR(omap->ehci_logic_fck))
@@ -402,6 +411,10 @@ static int usbhs_runtime_suspend(struct device *dev)
omap_tll_disable(pdata);
+ if (!IS_ERR(omap->pins_idle))
+ if (pinctrl_select_state(omap->pinctrl, omap->pins_idle))
+ dev_err(dev, "Could not select IDLE pin state\n");
+
return 0;
}
@@ -608,6 +621,30 @@ static int usbhs_omap_probe(struct platform_device *pdev)
return -ENOMEM;
}
+ omap->pinctrl = devm_pinctrl_get(dev);
+ if (!IS_ERR(omap->pinctrl)) {
+ omap->pins_default = pinctrl_lookup_state(omap->pinctrl,
+PINCTRL_STATE_DEFAULT);
+ if (IS_ERR(omap->pins_default))
+ dev_err(dev, "Could not get DEFAULT state pins\n");
+
+ omap->pins_idle = pinctrl_lookup_state(omap->pinctrl,
+ PINCTRL_STATE_IDLE);
+ if (IS_ERR(omap->pins_idle))
+ dev_err(dev, "Could not get IDLE state pins\n");
+
+ } else {
+ dev_info(dev, "pinctrl_get error\n");
+ if (PTR_ERR(omap->pinctrl) == -EPROBE_DEFER) {
+ dev_info(dev, "defer\n");
+ return -EPROBE_DEFER;
+ }
+
+ omap->pins_default = omap->pins_idle = ERR_PTR(-EINVAL);
+ dev_dbg(dev, "Proceeding without pinctrl: %ld\n",
+ PTR_ERR(omap->pinctrl));
+ }
+
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
omap->uhh_base = devm_ioremap_resource(dev, res);
if (IS_ERR(omap->uhh_base))
@@ -796,6 +833,10 @@ static int usbhs_omap_probe(struct platform_device *pdev)
}
}
+ if (!IS_ERR(omap->pins_default))
+ if (pinctrl_select_state(omap->pinctrl, omap->pins_default))
+ dev_err(dev, "Could not select DEFAULT pin state\n");
+
return 0;
err_alloc:
@@ -872,6 +913,11 @@ static int usbhs_omap_remove(struct platform_device *pdev)
/* remove children */
device_for_each_child(&pdev->dev, NULL, usbhs_omap_remove_child);
+
+ if (!IS_ERR(omap->pins_idle))
+ if (pinctrl_select_state(omap->pinctrl, omap->pins_idle))
+ dev_err(&pdev->dev, "Could not select IDLE pin
state\n");
+
return 0;
}
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 1/6] mfd: omap-usb-host: move initialization to module_init()
We no longer need to be initialized in any particular order
so move driver initialization to the standard place i.e. module_init()
CC: Samuel Ortiz
Signed-off-by: Roger Quadros
---
drivers/mfd/omap-usb-host.c | 10 +-
drivers/mfd/omap-usb-tll.c |8 +---
2 files changed, 2 insertions(+), 16 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 759fae3..6601a49 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -908,15 +908,7 @@ static int __init omap_usbhs_drvinit(void)
{
return platform_driver_probe(&usbhs_omap_driver, usbhs_omap_probe);
}
-
-/*
- * init before ehci and ohci drivers;
- * The usbhs core driver should be initialized much before
- * the omap ehci and ohci probe functions are called.
- * This usbhs core driver should be initialized after
- * usb tll driver
- */
-fs_initcall_sync(omap_usbhs_drvinit);
+module_init(omap_usbhs_drvinit);
static void __exit omap_usbhs_drvexit(void)
{
diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c
index e59ac4c..fb7c73e 100644
--- a/drivers/mfd/omap-usb-tll.c
+++ b/drivers/mfd/omap-usb-tll.c
@@ -482,13 +482,7 @@ static int __init omap_usbtll_drvinit(void)
{
return platform_driver_register(&usbtll_omap_driver);
}
-
-/*
- * init before usbhs core driver;
- * The usbtll driver should be initialized before
- * the usbhs core driver probe function is called.
- */
-fs_initcall(omap_usbtll_drvinit);
+module_init(omap_usbtll_drvinit);
static void __exit omap_usbtll_drvexit(void)
{
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 4/6] USB: ehci-omap: Suspend the controller during bus suspend
Runtime suspend the controller during bus suspend and resume it
during bus resume. This will ensure that the USB Host power domain
enters lower power state and does not prevent the SoC from
endering deeper sleep states.
Remote wakeup will come up as an interrupt while the controller
is suspended, so tackle it carefully using a workqueue.
Signed-off-by: Roger Quadros
---
drivers/usb/host/ehci-omap.c | 82 ++
1 files changed, 82 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index 16d7150..91f14f1 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -44,6 +44,8 @@
#include
#include
#include
+#include
+#include
#include "ehci.h"
@@ -69,6 +71,7 @@ static const char hcd_name[] = "ehci-omap";
struct omap_hcd {
struct usb_phy *phy[OMAP3_HS_USB_PORTS]; /* one PHY for each port */
int nports;
+ struct work_struct work;
};
static inline void ehci_write(void __iomem *base, u32 reg, u32 val)
@@ -81,6 +84,76 @@ static inline u32 ehci_read(void __iomem *base, u32 reg)
return __raw_readl(base + reg);
}
+static void omap_ehci_work(struct work_struct *work)
+{
+ struct omap_hcd *omap = container_of(work, struct omap_hcd, work);
+ struct ehci_hcd *ehci = container_of((void *) omap,
+ struct ehci_hcd, priv);
+ struct usb_hcd *hcd = ehci_to_hcd(ehci);
+ struct device *dev = hcd->self.controller;
+
+ pm_runtime_get_sync(dev);
+ enable_irq(hcd->irq);
+ /*
+* enable_irq() should preempt us with a pending IRQ
+* so we can be sure that IRQ handler completes before
+* we call pm_runtime_put_sync()
+*/
+ pm_runtime_put_sync(dev);
+}
+
+static irqreturn_t omap_ehci_irq(struct usb_hcd *hcd)
+{
+ struct omap_hcd *omap = (struct omap_hcd *)hcd_to_ehci(hcd)->priv;
+ struct device *dev = hcd->self.controller;
+ irqreturn_t ret;
+
+ if (pm_runtime_suspended(dev)) {
+ schedule_work(&omap->work);
+ disable_irq_nosync(hcd->irq);
+ ret = IRQ_HANDLED;
+ } else
+ ret = ehci_irq(hcd);
+
+ return ret;
+}
+
+#ifdef CONFIG_PM
+static int omap_ehci_bus_suspend(struct usb_hcd *hcd)
+{
+ struct device *dev;
+ int ret;
+
+ dev = hcd->self.controller;
+ ret = ehci_bus_suspend(hcd);
+ if (ret)
+ return ret;
+
+ ret = pm_runtime_put_sync(dev);
+ if (ret < 0 && !(ret == -EBUSY || ret == -EAGAIN)) {
+ dev_err(dev, "Failed to runtime suspend :%d\n", ret);
+ return ret;
+ }
+
+ return 0;
+}
+
+static int omap_ehci_bus_resume(struct usb_hcd *hcd)
+{
+ struct device *dev;
+ int ret;
+
+ dev = hcd->self.controller;
+ ret = pm_runtime_get_sync(dev);
+ if (ret < 0) {
+ dev_err(dev, "Failed to runtime resume :%d\n", ret);
+ return ret;
+ }
+
+ return ehci_bus_resume(hcd);
+}
+#endif /* CONFIG_PM */
+
/* configure so an HC device and id are always provided */
/* always called with process context; sleeping is OK */
@@ -88,6 +161,11 @@ static struct hc_driver __read_mostly ehci_omap_hc_driver;
static const struct ehci_driver_overrides ehci_omap_overrides __initdata = {
.extra_priv_size = sizeof(struct omap_hcd),
+#ifdef CONFIG_PM
+ .bus_suspend = omap_ehci_bus_suspend,
+ .bus_resume = omap_ehci_bus_resume,
+#endif
+ .irq = omap_ehci_irq,
};
/**
@@ -163,6 +241,7 @@ static int ehci_hcd_omap_probe(struct platform_device *pdev)
omap = (struct omap_hcd *)hcd_to_ehci(hcd)->priv;
omap->nports = pdata->nports;
+ INIT_WORK(&omap->work, omap_ehci_work);
platform_set_drvdata(pdev, hcd);
@@ -257,6 +336,9 @@ static int ehci_hcd_omap_remove(struct platform_device
*pdev)
struct omap_hcd *omap = (struct omap_hcd *)hcd_to_ehci(hcd)->priv;
int i;
+ if (pm_runtime_suspended(dev))
+ pm_runtime_get_sync(dev);
+
usb_remove_hcd(hcd);
for (i = 0; i < omap->nports; i++) {
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 5/6] ARM: dts: omap3beagle-xm: Add idle state pins for USB host
Add the Idle state pins for USB host and enable WAKEUP on
DIR, DAT0-3, so that the PHY can wakeup the OMAP SoC from
sleep on any USB activity (e.g. remote wakeup or connect/disconnect).
CC: Benoît Cousson
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/omap3-beagle-xm.dts | 29 +++--
1 files changed, 23 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index d3808ed..f1d56c2 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -89,12 +89,7 @@
};
&omap3_pmx_core {
- pinctrl-names = "default";
- pinctrl-0 = <
- &hsusbb2_pins
- >;
-
- hsusbb2_pins: pinmux_hsusbb2_pins {
+ hsusb2_pins: pinmux_hsusb2_pins {
pinctrl-single,pins = <
0x5c0 (PIN_OUTPUT | MUX_MODE3) /*
etk_d10.hsusb2_clk */
0x5c2 (PIN_OUTPUT | MUX_MODE3) /*
etk_d11.hsusb2_stp */
@@ -110,6 +105,25 @@
0x1ae (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi2_cs1.hsusb2_data3 */
>;
};
+
+ /* WAKEUP enabled on DIR, DAT0-3 */
+ hsusb2_idle_pins: pinmux_hsusb2_idle_pins {
+ pinctrl-single,pins = <
+ 0x5c0 (PIN_OUTPUT | MUX_MODE3) /*
etk_d10.hsusb2_clk */
+ 0x5c2 (PIN_OUTPUT | MUX_MODE3) /*
etk_d11.hsusb2_stp */
+ 0x5c4 (PIN_INPUT_PULLDOWN | WAKEUP_EN | MUX_MODE3)
/* etk_d12.hsusb2_dir */
+ 0x5c6 (PIN_INPUT_PULLDOWN | MUX_MODE3)
/* etk_d13.hsusb2_nxt */
+ 0x5c8 (PIN_INPUT_PULLDOWN | WAKEUP_EN | MUX_MODE3)
/* etk_d14.hsusb2_data0 */
+ 0x5cA (PIN_INPUT_PULLDOWN | WAKEUP_EN | MUX_MODE3)
/* etk_d15.hsusb2_data1 */
+ 0x1a4 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi1_cs3.hsusb2_data2 */
+ 0x1a6 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi2_clk.hsusb2_data7 */
+ 0x1a8 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi2_simo.hsusb2_data4 */
+ 0x1aa (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi2_somi.hsusb2_data5 */
+ 0x1ac (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi2_cs0.hsusb2_data6 */
+ 0x1ae (PIN_INPUT_PULLDOWN | WAKEUP_EN | MUX_MODE3)
/* mcspi2_cs1.hsusb2_data3 */
+ >;
+ interrupts = <77>; /* route padconf wakeup to EHCI IRQ */
+ };
};
&i2c1 {
@@ -181,6 +195,9 @@
};
&usbhshost {
+ pinctrl-names = "default", "idle";
+ pinctrl-0 = <&hsusb2_pins>;
+ pinctrl-1 = <&hsusb2_idle_pins>;
port2-mode = "ehci-phy";
};
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 6/6] ARM: OMAP3: Enable Hardware Save and Restore for USB Host
To ensure hardware context is restored while resuming from
OFF mode we need to enable the Hardware SAR bit for the
USB Host power domain.
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap2/powerdomains3xxx_data.c |8 +---
1 files changed, 1 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomains3xxx_data.c
b/arch/arm/mach-omap2/powerdomains3xxx_data.c
index f0e14e9..9554d2b 100644
--- a/arch/arm/mach-omap2/powerdomains3xxx_data.c
+++ b/arch/arm/mach-omap2/powerdomains3xxx_data.c
@@ -289,13 +289,7 @@ static struct powerdomain usbhost_pwrdm = {
.prcm_offs= OMAP3430ES2_USBHOST_MOD,
.pwrsts = PWRSTS_OFF_RET_ON,
.pwrsts_logic_ret = PWRSTS_RET,
- /*
-* REVISIT: Enabling usb host save and restore mechanism seems to
-* leave the usb host domain permanently in ACTIVE mode after
-* changing the usb host power domain state from OFF to active once.
-* Disabling for now.
-*/
- /*.flags = PWRDM_HAS_HDWR_SAR,*/ /* for USBHOST ctrlr only */
+ .flags= PWRDM_HAS_HDWR_SAR, /* for USBHOST ctrlr only */
.banks= 1,
.pwrsts_mem_ret = {
[0] = PWRSTS_RET, /* MEMRETSTATE */
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 0/6] Suspend USB Host controller on bus suspend
Hi, This series attempts to suspend the OMAP EHCI host controller on USB Bus suspend. This will cause its parent, the OMAP USB Host Module as well as the USB TLL Module to be put in suspend and hence allow the USB power domain to be put in a lower power state. Then we no longer prevent the rest of the OMAP SoC from entering lower power states like RETention or OFF mode when USB (or system) is suspended. This was one of the main reason why EHCI_OMAP is still not enabled in OMAP2 defconfig. In order for remote wakeup or hub events (connect/disconnect) to be detected while in suspend, we need to rely on the IO daisy chaining mechanism on OMAP. This is nothing but configuring a pin to be wakeup capable and triggering an interrupt on any pin activity while the hardware module or the entire SoC is in sleep state. For this to work, we rely on the wakeup feature added to the omap-pinctrl-single driver in [1]. This takes care of routing IO pad wakeup interrupt to the right driver's interrupt handler (i.e. ehci_irq in our case). The pin state information for DEFAULT and IDLE is specified for the omap3beagle-xm board in patch 5. So this is tested only on omap3beagle-xm board. As the omap-ehci controller driver needs to do some additional work to put itself into suspend/resume and make sure it is resumed to process an interrupt, we need to be able to override irq, bus_suspend, and bus_resume handlers. This provision is done in patch 3. Patch 2 uses pinctrl framework to toggle USB host pins from DEFAULT state when active to IDLE state with wakeups enabled while in suspend. Patch 5 implements the suspend feature in ehci-omap driver and ensures that we don't loose events while in suspend. Please let me know what you think about it. I'm not 100% confident about tackling interrupt when the device is runtime suspended in patch 5. Please let me know if a race condition is possible here. [1] - OMAP pinctrl wakeup support http://thread.gmane.org/gmane.linux.ports.arm.omap/99010/focus=99041 cheers, -roger Roger Quadros (6): mfd: omap-usb-host: move initialization to module_init() mfd: omap-usb-host: Put pins in IDLE state on suspend USB: ehci: allow controller drivers to override irq & bus_suspend/resume USB: ehci-omap: Suspend the controller during bus suspend ARM: dts: omap3beagle-xm: Add idle state pins for USB host ARM: OMAP3: Enable Hardware Save and Restore for USB Host arch/arm/boot/dts/omap3-beagle-xm.dts | 29 -- arch/arm/mach-omap2/powerdomains3xxx_data.c |8 +-- drivers/mfd/omap-usb-host.c | 56 +++--- drivers/mfd/omap-usb-tll.c |8 +-- drivers/usb/host/ehci-hcd.c |9 +++- drivers/usb/host/ehci-hub.c |6 +- drivers/usb/host/ehci-omap.c| 82 +++ drivers/usb/host/ehci.h |6 ++ 8 files changed, 172 insertions(+), 32 deletions(-) -- 1.7.4.1 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/4] ARM: dts: omap4-panda: Add USB Host support
On 06/19/2013 03:23 PM, Benoit Cousson wrote:
> On 06/19/2013 07:05 AM, Florian Vaussard wrote:
>> Hello,
>>
>> On 06/19/2013 01:03 PM, Roger Quadros wrote:
>>> On 06/19/2013 01:10 PM, Benoit Cousson wrote:
On 06/19/2013 02:46 AM, Tony Lindgren wrote:
> * Roger Quadros [130619 00:42]:
>> Hi Benoit,
>>
>> On 06/19/2013 04:17 AM, Benoit Cousson wrote:
>>> Hi Roger,
>>>
>>> On 06/18/2013 11:04 AM, Roger Quadros wrote:
Provide the RESET and Power regulators for the USB PHY,
the USB Host port mode and the PHY device.
Also provide pin multiplexer information for the USB host
pins.
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 62
+
1 files changed, 62 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 00cbaa5..7a21e8e 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -59,6 +59,42 @@
"AFML", "Line In",
"AFMR", "Line In";
};
+
+/* HS USB Port 1 RESET */
+hsusb1_reset: hsusb1_reset_reg {
+compatible = "regulator-fixed";
+regulator-name = "hsusb1_reset";
+regulator-min-microvolt = <330>;
+regulator-max-microvolt = <330>;
+gpio = <&gpio2 30 0>;/* gpio_62 */
+startup-delay-us = <7>;
+enable-active-high;
+};
>>>
>>> Is this really a regulator? Or just a GPIO line used to reset the
>>> USB PHY?
>>
>> It is in fact a GPIO line used as reset.
>>>
>>> If this is the case, I don't think it should be represented as a
>>> regulator.
>>
>> Why not? I think it fits very well in the regulator device model.
I'm not sure fitting very well is the correct term.
It works, for sure, but it is no different than when we were trying
to abuse the regulator fmwk to enable the 32k clock in phoenix.
It is just a hack.
>>>
>>> The only difference is there is a dedicated framework for clocks.
>>> Since there is nothing specific to
>>> handle reset lines it is left to the driver writer how he wants to
>>> manage it.
>>>
>>
>> There is a proposed binding for gpio-controlled reset lines, but it is
>> not yet merged [1].
>> I guess it can fit most usage patterns, and it can be an interesting
>> move in the future.
>
> I'm glad to see that I was not the only one thinking that the regulator was
> not the right fmwk to do that :-)
>
> Thanks for the pointer Florian.
Thanks again Florian.
>
> I guess that series should be merged for 3.11? Based on the thread, it should
> to through arm-soc.
>
> Roger,
>
> It might be tricky to have dependency on that series, but if this is
> possible, you should try. Otherwise, just keep the existing one, adding that
> a new solution will be available soon as a disclaimer.
>
I will rework the PHY driver to use the new gpio-reset driver. But for 3.11
let's proceed the way it is.
I'll resend this one with a disclaimer.
cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/4] ARM: dts: omap4-panda: Add USB Host support
On 06/19/2013 02:30 PM, Benoit Cousson wrote:
> On 06/19/2013 06:03 AM, Roger Quadros wrote:
>> On 06/19/2013 01:10 PM, Benoit Cousson wrote:
>>> On 06/19/2013 02:46 AM, Tony Lindgren wrote:
* Roger Quadros [130619 00:42]:
> Hi Benoit,
>
> On 06/19/2013 04:17 AM, Benoit Cousson wrote:
>> Hi Roger,
>>
>> On 06/18/2013 11:04 AM, Roger Quadros wrote:
>>> Provide the RESET and Power regulators for the USB PHY,
>>> the USB Host port mode and the PHY device.
>>>
>>> Also provide pin multiplexer information for the USB host
>>> pins.
>>>
>>> Signed-off-by: Roger Quadros
>>> ---
>>> arch/arm/boot/dts/omap4-panda-common.dtsi | 62
>>> +
>>> 1 files changed, 62 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
>>> b/arch/arm/boot/dts/omap4-panda-common.dtsi
>>> index 00cbaa5..7a21e8e 100644
>>> --- a/arch/arm/boot/dts/omap4-panda-common.dtsi
>>> +++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
>>> @@ -59,6 +59,42 @@
>>> "AFML", "Line In",
>>> "AFMR", "Line In";
>>> };
>>> +
>>> +/* HS USB Port 1 RESET */
>>> +hsusb1_reset: hsusb1_reset_reg {
>>> +compatible = "regulator-fixed";
>>> +regulator-name = "hsusb1_reset";
>>> +regulator-min-microvolt = <330>;
>>> +regulator-max-microvolt = <330>;
>>> +gpio = <&gpio2 30 0>;/* gpio_62 */
>>> +startup-delay-us = <7>;
>>> +enable-active-high;
>>> +};
>>
>> Is this really a regulator? Or just a GPIO line used to reset the USB
>> PHY?
>
> It is in fact a GPIO line used as reset.
>>
>> If this is the case, I don't think it should be represented as a
>> regulator.
>
> Why not? I think it fits very well in the regulator device model.
>>>
>>> I'm not sure fitting very well is the correct term.
>>> It works, for sure, but it is no different than when we were trying to
>>> abuse the regulator fmwk to enable the 32k clock in phoenix.
>>> It is just a hack.
>>>
>>
>> The only difference is there is a dedicated framework for clocks. Since
>> there is nothing specific to
>> handle reset lines it is left to the driver writer how he wants to manage it.
>
> Well, at that time, it was not available either. The point is still that
> using a existing fmwk that has nothing to do with the signal you need to
> handle just because it works is not a very good justification.
>
> I couldn't find a better
> way to represent this. It gives us a way to specify not only the GPIO
> line but also
> the polarity. I know mostly reset is active low but still there is
> flexibility as you never
> know for sure.
>>>
>>> Mmm, and what about just controlling the gpio from the driver?
>>
>> Yes gpio is possible. But then you need to add additional code in the driver
>> to parse GPIO number and polarity.
>> Using regulator_get() was plain simple for me.
>
> Maybe, but it is not the right thing to do.
> Can you explain me the commonality between a reset line and a regulator???
>
I cannot prove that a reset line is a regulator, because it is not. However,
the necessary features
required to manage a reset line were provided by the regulator framework e.g.
gpio control, polarity,
enable delay time. It was much less hassle for me to use the regulator
framework than manage
this in the phy driver.
Now that we have something specific for reset gpio I will migrate the PHY
driver to that, when it is
merged.
cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 10/11] ARM: dts: omap4 clock data
On 16:49-20130619, Tero Kristo wrote: > On 06/19/2013 04:30 PM, Nishanth Menon wrote: > >On 16:19-20130619, Tero Kristo wrote: > >[...] > >>+ > >>+/* > >>+ * clocks specific to omap4460 > >>+ */ > >>+/* > >>+ * clocks specific to omap4430 > >>+ */ > >>+/* > >>+ * clocks common to omap44xx > >>+ */ > >could be dropped? > > Same. > > > > >btw, are we differentiating 4430 and 4460?A > >Example: > >bandgap_fclk in 4430 > >Vs > >div_ts_ck, bandgap_ts_fclk in 4460? > > Both nodes are available for both SoCs as of now. Driver should > differentiate which clock node to use though. Added Eduardo for > commenting this part, maybe we should add a couple of entries to the > list in cclock44xx_data.c...? How about this: we do have 443x.dtsi and 4460.dtsi -> add the corresponding clock nodes there? ideally, driver should just do devm_clk_get and should not worry about what SoC revision it is running on. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 10/11] ARM: dts: omap4 clock data
On 06/19/2013 04:30 PM, Nishanth Menon wrote:
On 16:19-20130619, Tero Kristo wrote:
diff --git a/arch/arm/boot/dts/omap4-clocks.dtsi
b/arch/arm/boot/dts/omap4-clocks.dtsi
new file mode 100644
index 000..b420d8a
--- /dev/null
+++ b/arch/arm/boot/dts/omap4-clocks.dtsi
[...]
+/* XXX Missing round_rate, set_rate in ops */
could be dropped?
+dpll_core_m3x2_div_ck: dpll_core_m3x2_div_ck@4a004134 {
+ compatible = "divider-clock";
+ clocks = <&dpll_core_x2_ck>;
+ #clock-cells = <0>;
+ reg = <0x4a004134 0x4>;
+ bit-mask = <0x1f>;
+ index-starts-at-one;
+};
[..]
+
+/* XXX Missing round_rate, set_rate in ops */
could be dropped?
Yeah, I blame my bugged script here. :)
+dpll_per_m3x2_div_ck: dpll_per_m3x2_div_ck@4a008154 {
+ compatible = "divider-clock";
+ clocks = <&dpll_per_x2_ck>;
+ #clock-cells = <0>;
+ reg = <0x4a008154 0x4>;
+ bit-mask = <0x1f>;
+ index-starts-at-one;
+};
+
[...]
+
+/*
+ * clocks specific to omap4460
+ */
+/*
+ * clocks specific to omap4430
+ */
+/*
+ * clocks common to omap44xx
+ */
could be dropped?
Same.
btw, are we differentiating 4430 and 4460?A
Example:
bandgap_fclk in 4430
Vs
div_ts_ck, bandgap_ts_fclk in 4460?
Both nodes are available for both SoCs as of now. Driver should
differentiate which clock node to use though. Added Eduardo for
commenting this part, maybe we should add a couple of entries to the
list in cclock44xx_data.c...?
-Tero
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: dts: AM33XX: Add support for IGEP COM AQUILA
Hi,
On Wed, Jun 19, 2013 at 12:46 PM, Benoit Cousson wrote:
> Hi Enric,
>
>
> On 06/19/2013 03:27 AM, Enric Balletbo i Serra wrote:
>>
>> The IGEP COM AQUILA is industrial processors SODIMM module with
>> following highlights:
>>
>> o AM3352/AM3354/AM3358/AM3359 Texas Instruments processor
>> o Cortex-A8 ARM CPU
>> o 3.3 volts Inputs / Outputs use industrial
>> o 256 MB DDR3 SDRAM / 128 Megabytes FLASH
>> o MicroSD card reader on-board
>> o Ethernet controller on-board
>> o JTAG debug connector available
>> o Designed for industrial range purposes
>>
>> Signed-off-by: Enric Balletbo i Serra
>> ---
>> arch/arm/boot/dts/am335x-igep0033.dtsi | 269
>> +
>> 1 file changed, 269 insertions(+)
>> create mode 100644 arch/arm/boot/dts/am335x-igep0033.dtsi
>>
>> diff --git a/arch/arm/boot/dts/am335x-igep0033.dtsi
>> b/arch/arm/boot/dts/am335x-igep0033.dtsi
>> new file mode 100644
>> index 000..1d70141
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/am335x-igep0033.dtsi
>> @@ -0,0 +1,269 @@
>> +/*
>> + * Copyright (C) 2013 ISEE 2007 SL - http://www.isee.biz/
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + */
>> +
>> +/dts-v1/;
>> +
>> +#include "am33xx.dtsi"
>> +
>> +/ {
>> + cpus {
>> + cpu@0 {
>> + cpu0-supply = <&vdd1_reg>;
>> + };
>> + };
>> +
>> + memory {
>> + device_type = "memory";
>> + reg = <0x8000 0x1000>; /* 256 MB */
>> + };
>> +
>> + am33xx_pinmux: pinmux@44e10800 {
>
>
> That node should be inside the ocp one since the control module is a regular
> IP connected to the OCP interconnect.
>
>
>
In fact, I don't think that there should be a definition of the On
Chip Peripherals interconnect or any child node of the ocp in a DTS
file.
These should be defined in the included dtsi file since it will be
common to all boards based on this SoC.
DTS files that describe a board can reference these nodes defined in
the dtsi and add their custom peripherals as childs of them.
So, instead defining in the DTS:
am33xx_pinmux: pinmux@44e10800 {
...
};
gpmc: gpmc@5000 {
...
};
i2c0: i2c@44e0b000 {
...
};
uart0: serial@44e09000 {
..
};
It has to be defined as:
&am33xx_pinmux {
...
};
&gpmc {
...
};
&i2c0 {
...
}
I'm looking at other am33xx dts such as am335x-bone.dts and
am335x-evm.dts and I see that these define device nodes already
defined in the included .dtsi which is wrong in my opinion.
The OMAP{3,4,5} dtsi and dts do correctly and can be used as a
reference on how the device nodes have to be defined and referenced.
Best regards,
Javier
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 10/11] ARM: dts: omap4 clock data
On 16:19-20130619, Tero Kristo wrote:
> diff --git a/arch/arm/boot/dts/omap4-clocks.dtsi
> b/arch/arm/boot/dts/omap4-clocks.dtsi
> new file mode 100644
> index 000..b420d8a
> --- /dev/null
> +++ b/arch/arm/boot/dts/omap4-clocks.dtsi
[...]
> +/* XXX Missing round_rate, set_rate in ops */
could be dropped?
> +dpll_core_m3x2_div_ck: dpll_core_m3x2_div_ck@4a004134 {
> + compatible = "divider-clock";
> + clocks = <&dpll_core_x2_ck>;
> + #clock-cells = <0>;
> + reg = <0x4a004134 0x4>;
> + bit-mask = <0x1f>;
> + index-starts-at-one;
> +};
[..]
> +
> +/* XXX Missing round_rate, set_rate in ops */
could be dropped?
> +dpll_per_m3x2_div_ck: dpll_per_m3x2_div_ck@4a008154 {
> + compatible = "divider-clock";
> + clocks = <&dpll_per_x2_ck>;
> + #clock-cells = <0>;
> + reg = <0x4a008154 0x4>;
> + bit-mask = <0x1f>;
> + index-starts-at-one;
> +};
> +
[...]
> +
> +/*
> + * clocks specific to omap4460
> + */
> +/*
> + * clocks specific to omap4430
> + */
> +/*
> + * clocks common to omap44xx
> + */
could be dropped?
btw, are we differentiating 4430 and 4460?A
Example:
bandgap_fclk in 4430
Vs
div_ts_ck, bandgap_ts_fclk in 4460?
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 03/11] CLK: divider: fix table parsing logic for DT
The existing implementation had a couple of bugs:
1) table_size was attempted to read improperly, it has to be calculated
from the 'len' parameter of a property
2) Reading the integer entries from the table was reading only first
two entries of the DT data
Signed-off-by: Tero Kristo
---
drivers/clk/clk-divider.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
index 3413602..2fa7932 100644
--- a/drivers/clk/clk-divider.c
+++ b/drivers/clk/clk-divider.c
@@ -325,15 +325,18 @@ struct clk *clk_register_divider_table(struct device
*dev, const char *name,
struct clk_div_table *of_clk_get_div_table(struct device_node *node)
{
int i;
- int table_size = 0;
+ u32 table_size;
struct clk_div_table *table;
- u32 pair[2];
+ const __be32 *tablespec;
+ u32 val;
- table_size = of_count_phandle_with_args(node, "table", "#clock-cells");
+ tablespec = of_get_property(node, "table", &table_size);
- if (table_size < 1)
+ if (!tablespec)
return NULL;
+ table_size /= sizeof(struct clk_div_table);
+
table = kzalloc(sizeof(struct clk_div_table) * table_size, GFP_KERNEL);
if (!table) {
pr_err("%s: unable to allocate memory for %s table\n",
__func__, node->name);
@@ -341,10 +344,10 @@ struct clk_div_table *of_clk_get_div_table(struct
device_node *node)
}
for (i = 0; i < table_size; i++) {
- if (!of_property_read_u32_array(node, "table", pair,
ARRAY_SIZE(pair))) {
- table[i].val = pair[0];
- table[i].div = pair[1];
- }
+ of_property_read_u32_index(node, "table", i * 2, &val);
+ table[i].div = val;
+ of_property_read_u32_index(node, "table", i * 2 + 1, &val);
+ table[i].val = val;
}
return table;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 08/11] CLK: omap: add autoidle support
OMAP clk driver now routes some of the basic clocks through own
registration routine to allow autoidle support. This routine just
checks a couple of device node properties and adds autoidle support
if required, and just passes the registration forward to basic clocks.
Signed-off-by: Tero Kristo
---
arch/arm/mach-omap2/clock.c |6 ++
drivers/clk/omap/Makefile |2 +-
drivers/clk/omap/autoidle.c | 130 +++
drivers/clk/omap/clk.c |4 +-
include/linux/clk/omap.h|4 ++
5 files changed, 143 insertions(+), 3 deletions(-)
create mode 100644 drivers/clk/omap/autoidle.c
diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
index 6fe14b5..9bd66b4 100644
--- a/arch/arm/mach-omap2/clock.c
+++ b/arch/arm/mach-omap2/clock.c
@@ -520,6 +520,9 @@ int omap2_clk_enable_autoidle_all(void)
list_for_each_entry(c, &clk_hw_omap_clocks, node)
if (c->ops && c->ops->allow_idle)
c->ops->allow_idle(c);
+
+ of_omap_clk_allow_autoidle_all();
+
return 0;
}
@@ -539,6 +542,9 @@ int omap2_clk_disable_autoidle_all(void)
list_for_each_entry(c, &clk_hw_omap_clocks, node)
if (c->ops && c->ops->deny_idle)
c->ops->deny_idle(c);
+
+ of_omap_clk_deny_autoidle_all();
+
return 0;
}
diff --git a/drivers/clk/omap/Makefile b/drivers/clk/omap/Makefile
index 4cad480..ca56700 100644
--- a/drivers/clk/omap/Makefile
+++ b/drivers/clk/omap/Makefile
@@ -1 +1 @@
-obj-y += clk.o dpll.o
+obj-y += clk.o dpll.o autoidle.o
diff --git a/drivers/clk/omap/autoidle.c b/drivers/clk/omap/autoidle.c
new file mode 100644
index 000..6424cb2
--- /dev/null
+++ b/drivers/clk/omap/autoidle.c
@@ -0,0 +1,130 @@
+/*
+ * OMAP clock autoidle support
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ *
+ * Tero Kristo
+ *
+ * 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 "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#ifdef CONFIG_OF
+struct clk_omap_autoidle {
+ void __iomem*reg;
+ u8 shift;
+ u8 flags;
+ const char *name;
+ struct list_headnode;
+};
+
+#define AUTOIDLE_LOW 0x1
+
+static LIST_HEAD(autoidle_clks);
+
+static void omap_allow_autoidle(struct clk_omap_autoidle *clk)
+{
+ u32 val;
+
+ val = readl(clk->reg);
+
+ if (clk->flags & AUTOIDLE_LOW)
+ val &= ~(1 << clk->shift);
+ else
+ val |= (1 << clk->shift);
+
+ writel(val, clk->reg);
+}
+
+static void omap_deny_autoidle(struct clk_omap_autoidle *clk)
+{
+ u32 val;
+
+ val = readl(clk->reg);
+
+ if (clk->flags & AUTOIDLE_LOW)
+ val |= (1 << clk->shift);
+ else
+ val &= ~(1 << clk->shift);
+
+ writel(val, clk->reg);
+}
+
+void of_omap_clk_allow_autoidle_all(void)
+{
+ struct clk_omap_autoidle *c;
+
+ list_for_each_entry(c, &autoidle_clks, node)
+ omap_allow_autoidle(c);
+}
+
+void of_omap_clk_deny_autoidle_all(void)
+{
+ struct clk_omap_autoidle *c;
+
+ list_for_each_entry(c, &autoidle_clks, node)
+ omap_deny_autoidle(c);
+}
+
+static __init void of_omap_autoidle_setup(struct device_node *node)
+{
+ u32 shift;
+ void __iomem *reg;
+ struct clk_omap_autoidle *clk;
+
+ if (of_property_read_u32(node, "ti,autoidle-shift", &shift))
+ return;
+
+ reg = of_iomap(node, 0);
+
+ clk = kzalloc(sizeof(struct clk_omap_autoidle), GFP_KERNEL);
+
+ if (!clk) {
+ pr_err("%s: kzalloc failed\n", __func__);
+ return;
+ }
+
+ clk->shift = shift;
+ clk->name = node->name;
+ clk->reg = reg;
+
+ if (of_property_read_bool(node, "ti,autoidle-low"))
+ clk->flags |= AUTOIDLE_LOW;
+
+ list_add(&clk->node, &autoidle_clks);
+}
+
+void __init of_omap_divider_setup(struct device_node *node)
+{
+ of_divider_clk_setup(node);
+ of_omap_autoidle_setup(node);
+}
+EXPORT_SYMBOL_GPL(of_omap_divider_setup);
+CLK_OF_DECLARE(omap_autoidle_clock, "divider-clock", of_omap_divider_setup);
+
+void __init of_omap_fixed_factor_setup(struct device_node *node)
+{
+ of_fixed_factor_clk_setup(node);
+ of_omap_autoidle_setup(node);
+}
+EXPORT_SYMBOL_GPL(of_omap_fixed_factor_setup);
+CLK_OF_DECLARE(omap_fixed
[PATCHv2 05/11] CLK: OMAP4: Add DPLL clock support
The OMAP clock driver now supports DPLL clock type. This patch also
adds support for DT DPLL nodes.
Signed-off-by: Tero Kristo
---
drivers/clk/omap/Makefile |2 +-
drivers/clk/omap/clk.c|1 +
drivers/clk/omap/dpll.c | 307 +
3 files changed, 309 insertions(+), 1 deletion(-)
create mode 100644 drivers/clk/omap/dpll.c
diff --git a/drivers/clk/omap/Makefile b/drivers/clk/omap/Makefile
index 8195931..4cad480 100644
--- a/drivers/clk/omap/Makefile
+++ b/drivers/clk/omap/Makefile
@@ -1 +1 @@
-obj-y += clk.o
+obj-y += clk.o dpll.o
diff --git a/drivers/clk/omap/clk.c b/drivers/clk/omap/clk.c
index b4533ed..c2a3f8f 100644
--- a/drivers/clk/omap/clk.c
+++ b/drivers/clk/omap/clk.c
@@ -29,6 +29,7 @@ static const struct of_device_id clk_match[] = {
.data = of_fixed_factor_clk_setup, },
{.compatible = "divider-clock", .data = of_divider_clk_setup, },
{.compatible = "gate-clock", .data = of_gate_clk_setup, },
+ {.compatible = "ti,omap4-dpll-clock", .data = of_omap4_dpll_setup, },
{},
};
diff --git a/drivers/clk/omap/dpll.c b/drivers/clk/omap/dpll.c
new file mode 100644
index 000..183ec60
--- /dev/null
+++ b/drivers/clk/omap/dpll.c
@@ -0,0 +1,307 @@
+/*
+ * OMAP DPLL clock support
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ *
+ * Tero Kristo
+ *
+ * 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 "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/*
+ * DOC: basic adjustable divider clock that cannot gate
+ *
+ * Traits of this clock:
+ * prepare - clk_prepare only ensures that parents are prepared
+ * enable - clk_enable only ensures that parents are enabled
+ * rate - rate is adjustable. clk->rate = parent->rate / divisor
+ * parent - fixed parent. No clk_set_parent support
+ */
+
+#define to_clk_divider(_hw) container_of(_hw, struct clk_divider, hw)
+
+#define div_mask(d)((1 << ((d)->width)) - 1)
+
+static const struct clk_ops dpll_m4xen_ck_ops = {
+ .enable = &omap3_noncore_dpll_enable,
+ .disable= &omap3_noncore_dpll_disable,
+ .recalc_rate= &omap4_dpll_regm4xen_recalc,
+ .round_rate = &omap4_dpll_regm4xen_round_rate,
+ .set_rate = &omap3_noncore_dpll_set_rate,
+ .get_parent = &omap2_init_dpll_parent,
+};
+
+static const struct clk_ops dpll_core_ck_ops = {
+ .recalc_rate= &omap3_dpll_recalc,
+ .get_parent = &omap2_init_dpll_parent,
+};
+
+static const struct clk_ops dpll_ck_ops = {
+ .enable = &omap3_noncore_dpll_enable,
+ .disable= &omap3_noncore_dpll_disable,
+ .recalc_rate= &omap3_dpll_recalc,
+ .round_rate = &omap2_dpll_round_rate,
+ .set_rate = &omap3_noncore_dpll_set_rate,
+ .get_parent = &omap2_init_dpll_parent,
+ .init = &omap2_init_clk_clkdm,
+};
+
+static const struct clk_ops dpll_x2_ck_ops = {
+ .recalc_rate= &omap3_clkoutx2_recalc,
+};
+
+struct clk *omap_clk_register_dpll(struct device *dev, const char *name,
+ const char **parent_names, int num_parents, unsigned long flags,
+ struct dpll_data *dpll_data, const char *clkdm_name,
+ const struct clk_ops *ops)
+{
+ struct clk *clk;
+ struct clk_init_data init;
+ struct clk_hw_omap *clk_hw;
+
+ /* allocate the divider */
+ clk_hw = kzalloc(sizeof(struct clk_hw_omap), GFP_KERNEL);
+ if (!clk_hw) {
+ pr_err("%s: could not allocate clk_hw_omap\n", __func__);
+ return ERR_PTR(-ENOMEM);
+ }
+
+ clk_hw->dpll_data = dpll_data;
+ clk_hw->ops = &clkhwops_omap3_dpll;
+ clk_hw->clkdm_name = clkdm_name;
+ clk_hw->hw.init = &init;
+
+ init.name = name;
+ init.ops = ops;
+ init.flags = flags;
+ init.parent_names = parent_names;
+ init.num_parents = num_parents;
+
+ /* register the clock */
+ clk = clk_register(dev, &clk_hw->hw);
+
+ if (IS_ERR(clk))
+ kfree(clk_hw);
+ else
+ omap2_init_clk_hw_omap_clocks(clk);
+
+ return clk;
+}
+
+struct clk *omap_clk_register_dpll_x2(struct device *dev, const char *name,
+ const char *parent_name, void __iomem *reg,
+ const struct clk_ops *ops)
+{
+ struct clk *clk;
+ struct clk_init_data init;
+ struct clk_hw_omap *clk_hw;
+
+
[PATCHv2 04/11] clk: omap: introduce clock driver
Parses OMAP clock data from DT and registers those clocks with the clock
framework. dt_omap_clk_init must be called early during boot for timer
initialization so it is exported and called from the existing clock code
instead of probing like a real driver. Based on initial work done by
Mike Turquette.
Signed-off-by: Tero Kristo
Cc: Mike Turquette
---
drivers/clk/Makefile |1 +
drivers/clk/omap/Makefile |1 +
drivers/clk/omap/clk.c| 44
include/linux/clk/omap.h | 24
4 files changed, 70 insertions(+)
create mode 100644 drivers/clk/omap/Makefile
create mode 100644 drivers/clk/omap/clk.c
create mode 100644 include/linux/clk/omap.h
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 137d3e7..1d5a2ec 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -30,6 +30,7 @@ obj-$(CONFIG_ARCH_VT8500) += clk-vt8500.o
obj-$(CONFIG_ARCH_ZYNQ)+= clk-zynq.o
obj-$(CONFIG_ARCH_TEGRA) += tegra/
obj-$(CONFIG_PLAT_SAMSUNG) += samsung/
+obj-$(CONFIG_ARCH_OMAP)+= omap/
obj-$(CONFIG_X86) += x86/
diff --git a/drivers/clk/omap/Makefile b/drivers/clk/omap/Makefile
new file mode 100644
index 000..8195931
--- /dev/null
+++ b/drivers/clk/omap/Makefile
@@ -0,0 +1 @@
+obj-y += clk.o
diff --git a/drivers/clk/omap/clk.c b/drivers/clk/omap/clk.c
new file mode 100644
index 000..b4533ed
--- /dev/null
+++ b/drivers/clk/omap/clk.c
@@ -0,0 +1,44 @@
+/*
+ * OMAP PRCM clock driver
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ * Tero Kristo
+ *
+ * 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 "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* FIXME - should the OMAP PRCM clock driver match generic types? */
+static const struct of_device_id clk_match[] = {
+ {.compatible = "fixed-clock", .data = of_fixed_clk_setup, },
+ {.compatible = "mux-clock", .data = of_mux_clk_setup, },
+ {.compatible = "fixed-factor-clock",
+ .data = of_fixed_factor_clk_setup, },
+ {.compatible = "divider-clock", .data = of_divider_clk_setup, },
+ {.compatible = "gate-clock", .data = of_gate_clk_setup, },
+ {},
+};
+
+/* FIXME - need to initialize early; skip real driver registration & probe */
+int __init dt_omap_clk_init(void)
+{
+ of_clk_init(clk_match);
+ return 0;
+}
+
+MODULE_DESCRIPTION("OMAP Clock driver");
+MODULE_AUTHOR("Texas Instruments Inc.");
+MODULE_LICENSE("GPL v2");
diff --git a/include/linux/clk/omap.h b/include/linux/clk/omap.h
new file mode 100644
index 000..504e838
--- /dev/null
+++ b/include/linux/clk/omap.h
@@ -0,0 +1,24 @@
+/*
+ * Copyright (C) 2010 Broadcom
+ *
+ * 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., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#ifndef __LINUX_CLK_OMAP_H_
+#define __LINUX_CLK_OMAP_H_
+
+int __init dt_omap_clk_init(void);
+
+#endif
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 10/11] ARM: dts: omap4 clock data
This patch creates a unique node for each clock in the OMAP4 power,
reset and clock manager (PRCM).
Signed-off-by: Tero Kristo
---
arch/arm/boot/dts/omap4-clocks.dtsi | 1704 +++
arch/arm/boot/dts/omap4.dtsi|2 +
2 files changed, 1706 insertions(+)
create mode 100644 arch/arm/boot/dts/omap4-clocks.dtsi
diff --git a/arch/arm/boot/dts/omap4-clocks.dtsi
b/arch/arm/boot/dts/omap4-clocks.dtsi
new file mode 100644
index 000..b420d8a
--- /dev/null
+++ b/arch/arm/boot/dts/omap4-clocks.dtsi
@@ -0,0 +1,1704 @@
+/*
+ * Device Tree Source for OMAP4 clock data
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ *
+ * 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.
+ */
+
+/* Root clocks */
+extalt_clkin_ck: extalt_clkin_ck {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <5900>;
+};
+
+pad_clks_src_ck: pad_clks_src_ck {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <1200>;
+};
+
+pad_clks_ck: pad_clks_ck@4a004108 {
+ compatible = "gate-clock";
+ reg = <0x4a004108 0x4>;
+ bit-shift = <8>;
+ clocks = <&pad_clks_src_ck>;
+ #clock-cells = <0>;
+};
+
+pad_slimbus_core_clks_ck: pad_slimbus_core_clks_ck {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <1200>;
+};
+
+secure_32k_clk_src_ck: secure_32k_clk_src_ck {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <32768>;
+};
+
+slimbus_src_clk: slimbus_src_clk {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <1200>;
+};
+
+slimbus_clk: slimbus_clk@4a004108 {
+ compatible = "gate-clock";
+ reg = <0x4a004108 0x4>;
+ bit-shift = <10>;
+ clocks = <&slimbus_src_clk>;
+ #clock-cells = <0>;
+};
+
+sys_32k_ck: sys_32k_ck {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <32768>;
+};
+
+virt_1200_ck: virt_1200_ck {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <1200>;
+};
+
+virt_1300_ck: virt_1300_ck {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <1300>;
+};
+
+virt_1680_ck: virt_1680_ck {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <1680>;
+};
+
+virt_1920_ck: virt_1920_ck {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <1920>;
+};
+
+virt_2600_ck: virt_2600_ck {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <2600>;
+};
+
+virt_2700_ck: virt_2700_ck {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <2700>;
+};
+
+virt_3840_ck: virt_3840_ck {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <3840>;
+};
+
+sys_clkin_ck: sys_clkin_ck@4a306110 {
+ compatible = "mux-clock";
+ clocks = <&virt_1200_ck>, <&virt_1300_ck>, <&virt_1680_ck>,
<&virt_1920_ck>, <&virt_2600_ck>, <&virt_2700_ck>,
<&virt_3840_ck>;
+ #clock-cells = <0>;
+ reg = <0x4a306110 0x4>;
+ bit-mask = <0x7>;
+ index-starts-at-one;
+};
+
+tie_low_clock_ck: tie_low_clock_ck {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <0>;
+};
+
+utmi_phy_clkout_ck: utmi_phy_clkout_ck {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <6000>;
+};
+
+xclk60mhsp1_ck: xclk60mhsp1_ck {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <6000>;
+};
+
+xclk60mhsp2_ck: xclk60mhsp2_ck {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <6000>;
+};
+
+xclk60motg_ck: xclk60motg_ck {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <6000>;
+};
+
+/* Module clocks and DPLL outputs */
+abe_dpll_bypass_clk_mux_ck: abe_dpll_bypass_clk_mux_ck@4a306108 {
+ compatible = "mux-clock";
+ clocks = <&sys_clkin_ck>, <&sys_32k_ck>;
+ #clock-cells = <0>;
+ reg = <0x4a306108 0x4>;
+ bit-mask = <0x1>;
+ bit-shift = <24>;
+};
+
+abe_dpll_refclk_mux_ck: abe_dpll_refclk_mux_ck@4a30610c {
+ compatible = "mux-clock";
+ clocks = <&sys_clkin_ck>, <&sys_32k_ck>;
+ #clock-cells = <0>;
+ reg = <0x4a30610c 0x4>;
+ bit-mask = <0x1>;
+};
+
+/* DPLL_ABE */
+dpll_abe_ck: dpll_abe_ck {
+ clocks = <&abe_dpll_refclk_mux_ck>;
+ #clock-cells = <0>;
+ reg = <0x4a0041e0 0x4>, <0x4a0041e4 0x4>, <0x4a0041e8 0x4>, <0x4a0041ec
0x4>;
+
[PATCHv2 06/11] CLK: omap: move part of the machine specific clock header contents to driver
Some of the clock.h contents are needed by the new OMAP clock driver,
including dpll_data and clk_hw_omap. Thus, move these to the generic
omap header file which can be accessed by the driver.
Signed-off-by: Tero Kristo
---
arch/arm/mach-omap2/clock.h | 150 +
include/linux/clk/omap.h| 155 ++-
2 files changed, 155 insertions(+), 150 deletions(-)
diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h
index 7aa32cd..3238c57 100644
--- a/arch/arm/mach-omap2/clock.h
+++ b/arch/arm/mach-omap2/clock.h
@@ -21,6 +21,7 @@
#include
#include
+#include
struct omap_clk {
u16 cpu;
@@ -178,83 +179,6 @@ struct clksel {
const struct clksel_rate *rates;
};
-/**
- * struct dpll_data - DPLL registers and integration data
- * @mult_div1_reg: register containing the DPLL M and N bitfields
- * @mult_mask: mask of the DPLL M bitfield in @mult_div1_reg
- * @div1_mask: mask of the DPLL N bitfield in @mult_div1_reg
- * @clk_bypass: struct clk pointer to the clock's bypass clock input
- * @clk_ref: struct clk pointer to the clock's reference clock input
- * @control_reg: register containing the DPLL mode bitfield
- * @enable_mask: mask of the DPLL mode bitfield in @control_reg
- * @last_rounded_rate: cache of the last rate result of omap2_dpll_round_rate()
- * @last_rounded_m: cache of the last M result of omap2_dpll_round_rate()
- * @last_rounded_m4xen: cache of the last M4X result of
- * omap4_dpll_regm4xen_round_rate()
- * @last_rounded_lpmode: cache of the last lpmode result of
- * omap4_dpll_lpmode_recalc()
- * @max_multiplier: maximum valid non-bypass multiplier value (actual)
- * @last_rounded_n: cache of the last N result of omap2_dpll_round_rate()
- * @min_divider: minimum valid non-bypass divider value (actual)
- * @max_divider: maximum valid non-bypass divider value (actual)
- * @modes: possible values of @enable_mask
- * @autoidle_reg: register containing the DPLL autoidle mode bitfield
- * @idlest_reg: register containing the DPLL idle status bitfield
- * @autoidle_mask: mask of the DPLL autoidle mode bitfield in @autoidle_reg
- * @freqsel_mask: mask of the DPLL jitter correction bitfield in @control_reg
- * @idlest_mask: mask of the DPLL idle status bitfield in @idlest_reg
- * @lpmode_mask: mask of the DPLL low-power mode bitfield in @control_reg
- * @m4xen_mask: mask of the DPLL M4X multiplier bitfield in @control_reg
- * @auto_recal_bit: bitshift of the driftguard enable bit in @control_reg
- * @recal_en_bit: bitshift of the PRM_IRQENABLE_* bit for recalibration IRQs
- * @recal_st_bit: bitshift of the PRM_IRQSTATUS_* bit for recalibration IRQs
- * @flags: DPLL type/features (see below)
- *
- * Possible values for @flags:
- * DPLL_J_TYPE: "J-type DPLL" (only some 36xx, 4xxx DPLLs)
- *
- * @freqsel_mask is only used on the OMAP34xx family and AM35xx.
- *
- * XXX Some DPLLs have multiple bypass inputs, so it's not technically
- * correct to only have one @clk_bypass pointer.
- *
- * XXX The runtime-variable fields (@last_rounded_rate, @last_rounded_m,
- * @last_rounded_n) should be separated from the runtime-fixed fields
- * and placed into a different structure, so that the runtime-fixed data
- * can be placed into read-only space.
- */
-struct dpll_data {
- void __iomem*mult_div1_reg;
- u32 mult_mask;
- u32 div1_mask;
- struct clk *clk_bypass;
- struct clk *clk_ref;
- void __iomem*control_reg;
- u32 enable_mask;
- unsigned long last_rounded_rate;
- u16 last_rounded_m;
- u8 last_rounded_m4xen;
- u8 last_rounded_lpmode;
- u16 max_multiplier;
- u8 last_rounded_n;
- u8 min_divider;
- u16 max_divider;
- u8 modes;
- void __iomem*autoidle_reg;
- void __iomem*idlest_reg;
- u32 autoidle_mask;
- u32 freqsel_mask;
- u32 idlest_mask;
- u32 dco_mask;
- u32 sddiv_mask;
- u32 lpmode_mask;
- u32 m4xen_mask;
- u8 auto_recal_bit;
- u8 recal_en_bit;
- u8 recal_st_bit;
- u8 flags;
-};
-
/*
* struct clk.flags possibilities
*
@@ -274,56 +198,6 @@ struct dpll_data {
#define INVERT_ENABLE (1 << 4)/* 0 enables, 1 disables */
#define CLOCK_CLKOUTX2 (1 << 5)
-/**
- * struct clk_hw_omap - OMAP struct clk
- * @node: lis
[PATCHv2 09/11] CLK: omap: add support for OMAP gate clock
This node adds support for a clock node which allows control to the
clockdomain enable / disable.
Signed-off-by: Tero Kristo
---
drivers/clk/omap/Makefile |2 +-
drivers/clk/omap/clk.c|1 +
drivers/clk/omap/gate.c | 88 +
include/linux/clk/omap.h |1 +
4 files changed, 91 insertions(+), 1 deletion(-)
create mode 100644 drivers/clk/omap/gate.c
diff --git a/drivers/clk/omap/Makefile b/drivers/clk/omap/Makefile
index ca56700..3d3ca30f 100644
--- a/drivers/clk/omap/Makefile
+++ b/drivers/clk/omap/Makefile
@@ -1 +1 @@
-obj-y += clk.o dpll.o autoidle.o
+obj-y += clk.o dpll.o autoidle.o gate.o
diff --git a/drivers/clk/omap/clk.c b/drivers/clk/omap/clk.c
index 181795f..20643a2 100644
--- a/drivers/clk/omap/clk.c
+++ b/drivers/clk/omap/clk.c
@@ -30,6 +30,7 @@ static const struct of_device_id clk_match[] = {
{.compatible = "divider-clock", .data = of_omap_divider_setup, },
{.compatible = "gate-clock", .data = of_gate_clk_setup, },
{.compatible = "ti,omap4-dpll-clock", .data = of_omap4_dpll_setup, },
+ {.compatible = "ti,gate-clock", .data = of_omap_gate_clk_setup, },
{},
};
diff --git a/drivers/clk/omap/gate.c b/drivers/clk/omap/gate.c
new file mode 100644
index 000..7186bb2
--- /dev/null
+++ b/drivers/clk/omap/gate.c
@@ -0,0 +1,88 @@
+/*
+ * OMAP gate clock support
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ *
+ * Tero Kristo
+ *
+ * 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 "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#ifdef CONFIG_OF
+
+static const struct clk_ops omap_gate_clk_ops = {
+ .init = &omap2_init_clk_clkdm,
+ .enable = &omap2_clkops_enable_clkdm,
+ .disable= &omap2_clkops_disable_clkdm,
+};
+
+void __init of_omap_gate_clk_setup(struct device_node *node)
+{
+ struct clk *clk;
+ struct clk_init_data init;
+ struct clk_hw_omap *clk_hw;
+ const char *clk_name = node->name;
+ int num_parents;
+ const char **parent_names;
+ int i;
+
+ clk_hw = kzalloc(sizeof(struct clk_hw_omap), GFP_KERNEL);
+ if (!clk_hw) {
+ pr_err("%s: could not allocate clk_hw_omap\n", __func__);
+ return;
+ }
+
+ clk_hw->hw.init = &init;
+
+ of_property_read_string(node, "clock-output-names", &clk_name);
+ of_property_read_string(node, "ti,clkdm-name", &clk_hw->clkdm_name);
+
+ init.name = clk_name;
+ init.ops = &omap_gate_clk_ops;
+
+ num_parents = of_clk_get_parent_count(node);
+ if (num_parents < 1) {
+ pr_err("%s: omap trace_clk %s must have parent(s)\n",
+ __func__, node->name);
+ goto cleanup;
+ }
+
+ parent_names = kzalloc(sizeof(char *) * num_parents, GFP_KERNEL);
+
+ for (i = 0; i < num_parents; i++)
+ parent_names[i] = of_clk_get_parent_name(node, i);
+
+ init.num_parents = num_parents;
+ init.parent_names = parent_names;
+
+ clk = clk_register(NULL, &clk_hw->hw);
+
+ if (!IS_ERR(clk)) {
+ of_clk_add_provider(node, of_clk_src_simple_get, clk);
+ return;
+ }
+
+cleanup:
+ kfree(clk_hw);
+}
+EXPORT_SYMBOL(of_omap_gate_clk_setup);
+CLK_OF_DECLARE(omap_gate_clk, "ti,omap-gate-clock", of_omap_gate_clk_setup);
+#endif
diff --git a/include/linux/clk/omap.h b/include/linux/clk/omap.h
index 003e374..17757d3 100644
--- a/include/linux/clk/omap.h
+++ b/include/linux/clk/omap.h
@@ -175,6 +175,7 @@ int dt_omap_clk_init(void);
void of_omap4_dpll_setup(struct device_node *node);
void of_omap_fixed_factor_setup(struct device_node *node);
void of_omap_divider_setup(struct device_node *node);
+void of_omap_gate_clk_setup(struct device_node *node);
void of_omap_clk_allow_autoidle_all(void);
void of_omap_clk_deny_autoidle_all(void);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 07/11] ARM: OMAP: clock: add DT duplicate clock registration mechanism
Some devices require their clocks to be available with a specific
dev-id con-id mapping. With DT, the clocks can be found by default
only with their name, or alternatively through the device node of
the consumer. With drivers, that don't support DT fully yet, add
mechanism to register specific clock names.
Signed-off-by: Tero Kristo
---
arch/arm/mach-omap2/clock.c | 39 +++
arch/arm/mach-omap2/clock.h | 16
2 files changed, 55 insertions(+)
diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
index 0c38ca9..6fe14b5 100644
--- a/arch/arm/mach-omap2/clock.c
+++ b/arch/arm/mach-omap2/clock.c
@@ -584,6 +584,45 @@ void __init omap_clocks_register(struct omap_clk oclks[],
int cnt)
}
/**
+ * omap_dt_clocks_register - register DT duplicate clocks during boot
+ * @oclks: list of clocks to register
+ * @cnt: number of clocks
+ *
+ * Register duplicate or non-standard DT clock entries during boot. By
+ * default, DT clocks are found based on their node name. If any
+ * additional con-id / dev-id -> clock mapping is required, use this
+ * function to list these.
+ */
+void __init omap_dt_clocks_register(struct omap_dt_clk oclks[], int cnt)
+{
+ struct omap_dt_clk *c;
+ struct device_node *n;
+ struct clk *clk;
+ struct of_phandle_args clkspec;
+
+ for (c = oclks; c < oclks + cnt; c++) {
+ n = of_find_node_by_name(NULL, c->node_name);
+
+ if (!n) {
+ pr_err("%s: %s not found!\n", __func__, c->node_name);
+ continue;
+ }
+
+ clkspec.np = n;
+
+ clk = of_clk_get_from_provider(&clkspec);
+
+ if (!clk) {
+ pr_err("%s: %s has no clock!\n", __func__,
+ c->node_name);
+ continue;
+ }
+ c->lk.clk = clk;
+ clkdev_add(&c->lk);
+ }
+}
+
+/**
* omap2_clk_switch_mpurate_at_boot - switch ARM MPU rate by boot-time argument
* @mpurate_ck_name: clk name of the clock to change rate
*
diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h
index 3238c57..1c1fbe4 100644
--- a/arch/arm/mach-omap2/clock.h
+++ b/arch/arm/mach-omap2/clock.h
@@ -37,6 +37,21 @@ struct omap_clk {
}, \
}
+struct omap_dt_clk {
+ u16 cpu;
+ struct clk_lookup lk;
+ const char *node_name;
+};
+
+#define DT_CLK(dev, con, name) \
+ { \
+ .lk = { \
+ .dev_id = dev, \
+ .con_id = con, \
+ }, \
+ .node_name = name, \
+ }
+
struct clockdomain;
#define to_clk_hw_omap(_hw) container_of(_hw, struct clk_hw_omap, hw)
@@ -316,4 +331,5 @@ extern const struct clksel_rate div31_1to31_rates[];
extern int am33xx_clk_init(void);
extern void omap_clocks_register(struct omap_clk *oclks, int cnt);
+extern void omap_dt_clocks_register(struct omap_dt_clk *oclks, int cnt);
#endif
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 00/11] ARM: OMAP4 clock data conversion to DT
Hi, This set converts the OMAP4 clock data to device tree format. This set also fixes a couple of problems detected in the basic clock devicetree code (patches 2 & 3), and adds some generic support functions for the transition phase when all the drivers are not fully devicetree compliant (see patches 1 & 7.) OMAP4 clock data was converted from cclock44xx_data.c file with a custom perl script, which can probably be applied for other SoCs with some modifications also. Version one for this work was done by Mike Turquette: http://comments.gmane.org/gmane.linux.ports.arm.omap/98741 This set needs the basic devicetree support code from Mike: http://comments.gmane.org/gmane.linux.kernel/1509300 Testing done with omap4-panda board, booted up to console and tested that suspend / resume works with 3.10-rc6. I have also provided a working branch here: git://gitorious.org/~kristo/omap-pm/omap-pm-work.git branch: mainline-3.10-rc6-omap4-dt-clks-v2 This branch contains the pre-req set from Mike, and a couple of additional hacks you can ignore. Any comments / testing feedback welcome. -Tero -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 02/11] CLK: use of_property_read_u32 instead of read_u8
of_property_read_u8 does not work properly because of endianess problem
with its current implementation, and this causes it to always return
0 with little endian architectures. Instead, use property_read_u32
until this is fixed.
Signed-off-by: Tero Kristo
---
drivers/clk/clk-divider.c |4 ++--
drivers/clk/clk-gate.c|4 ++--
drivers/clk/clk-mux.c |4 ++--
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
index 17ea475..3413602 100644
--- a/drivers/clk/clk-divider.c
+++ b/drivers/clk/clk-divider.c
@@ -361,7 +361,7 @@ void of_divider_clk_setup(struct device_node *node)
const char *parent_name;
u8 clk_divider_flags = 0;
u32 mask = 0;
- u8 shift = 0;
+ u32 shift = 0;
struct clk_div_table *table;
of_property_read_string(node, "clock-output-names", &clk_name);
@@ -375,7 +375,7 @@ void of_divider_clk_setup(struct device_node *node)
return;
}
- if (of_property_read_u8(node, "bit-shift", &shift)) {
+ if (of_property_read_u32(node, "bit-shift", &shift)) {
shift = __ffs(mask);
pr_debug("%s: bit-shift property defaults to 0x%x for %s\n",
__func__, shift, node->name);
diff --git a/drivers/clk/clk-gate.c b/drivers/clk/clk-gate.c
index 72cf99d..61b4dc1 100644
--- a/drivers/clk/clk-gate.c
+++ b/drivers/clk/clk-gate.c
@@ -162,7 +162,7 @@ void of_gate_clk_setup(struct device_node *node)
void __iomem *reg;
const char *parent_name;
u8 clk_gate_flags = 0;
- u8 bit_idx = 0;
+ u32 bit_idx = 0;
of_property_read_string(node, "clock-output-names", &clk_name);
@@ -170,7 +170,7 @@ void of_gate_clk_setup(struct device_node *node)
reg = of_iomap(node, 0);
- if (of_property_read_u8(node, "bit-shift", &bit_idx)) {
+ if (of_property_read_u32(node, "bit-shift", &bit_idx)) {
pr_err("%s: missing bit-shift property for %s\n",
__func__, node->name);
return;
diff --git a/drivers/clk/clk-mux.c b/drivers/clk/clk-mux.c
index c9f9f32..e63dd1b 100644
--- a/drivers/clk/clk-mux.c
+++ b/drivers/clk/clk-mux.c
@@ -170,7 +170,7 @@ void of_mux_clk_setup(struct device_node *node)
int i;
u8 clk_mux_flags = 0;
u32 mask = 0;
- u8 shift = 0;
+ u32 shift = 0;
of_property_read_string(node, "clock-output-names", &clk_name);
@@ -194,7 +194,7 @@ void of_mux_clk_setup(struct device_node *node)
return;
}
- if (of_property_read_u8(node, "bit-shift", &shift)) {
+ if (of_property_read_u32(node, "bit-shift", &shift)) {
shift = __ffs(mask);
pr_debug("%s: bit-shift property defaults to 0x%x for %s\n",
__func__, shift, node->name);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 01/11] CLK: clkdev: add support for looking up clocks from DT
clk_get_sys / clk_get can now find clocks from device-tree. If a DT clock
is found, an entry is added to the clk_lookup list also for subsequent
searches.
Signed-off-by: Tero Kristo
---
drivers/clk/clkdev.c | 32
1 file changed, 32 insertions(+)
diff --git a/drivers/clk/clkdev.c b/drivers/clk/clkdev.c
index 442a313..e39f082 100644
--- a/drivers/clk/clkdev.c
+++ b/drivers/clk/clkdev.c
@@ -93,6 +93,18 @@ struct clk *of_clk_get_by_name(struct device_node *np, const
char *name)
EXPORT_SYMBOL(of_clk_get_by_name);
#endif
+/**
+ * clkdev_add_nolock - add lookup entry for a clock
+ * @cl: pointer to new clock lookup entry
+ *
+ * Non-locking version, used internally by clk_find() to add DT based
+ * clock lookup entries.
+ */
+static void clkdev_add_nolock(struct clk_lookup *cl)
+{
+ list_add_tail(&cl->node, &clocks);
+}
+
/*
* Find the correct struct clk for the device and connection ID.
* We do slightly fuzzy matching here:
@@ -106,6 +118,9 @@ static struct clk_lookup *clk_find(const char *dev_id,
const char *con_id)
{
struct clk_lookup *p, *cl = NULL;
int match, best_found = 0, best_possible = 0;
+ struct device_node *node;
+ struct clk *clk;
+ struct of_phandle_args clkspec;
if (dev_id)
best_possible += 2;
@@ -133,6 +148,23 @@ static struct clk_lookup *clk_find(const char *dev_id,
const char *con_id)
break;
}
}
+
+ if (cl)
+ return cl;
+
+ /* If clock was not found, attempt to look-up from DT */
+ node = of_find_node_by_name(NULL, con_id);
+
+ clkspec.np = node;
+
+ clk = of_clk_get_from_provider(&clkspec);
+
+ if (!IS_ERR(clk)) {
+ /* We found a clock, add node to clkdev */
+ cl = clkdev_alloc(clk, con_id, dev_id);
+ clkdev_add_nolock(cl);
+ }
+
return cl;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/4] ARM: dts: omap4-panda: Add USB Host support
* Benoit Cousson [130619 05:41]: > Hi Tony, > > On 06/19/2013 07:27 AM, Tony Lindgren wrote: > >* Benoit Cousson [130619 03:17]: > >>On 06/19/2013 02:46 AM, Tony Lindgren wrote: > >>> > >>>We have a similar issue with the MMC1 PBIAS. I think in the long run we > >>>should expand regulator (and possibly pinctrl) framework(s) to handle > >>>comparators. We could just assume that a comparatator is a regulator, > >>>and have a comparator binding that just uses the regulator code. > >> > >>In the case of pbias, the pinctrl seems to be a much better fit for > >>my point of view. pinctrl can handle pin configuration and this is > >>what the pbias is in the case of MMC pins. > > > >Well just recently Linus W specifically wanted us to use regulator > >framework for the MMC1 PBIAS rather than pinctrl. That's because > >from consumer driver point of view, it changes voltage and there's > >a delay involved. So I guess no conclusion yet, and it's best to > >do stand alone drivers to deal with those that use pinctrl for the > >pinctrl specific parts and export it as a regulator for the consumer > >devices. > > In the case of pbias, the boundary is not that clear, and it is true > that writing a complete pinctrl driver is really overkill. > I've tried in the past, and gave up due to the complexity of fmwk > and the lack of time. I still think, it is a much better fmwk to > handle pin configuration than the regulator fmwk. For omaps, these kind of registers can already be handled by pinctrl-single,bits. What's missing is the capability to create a regulator out of the voltage mux + comparator bits. > >That's pretty much along the lines what Roger has done, > >except the transceiver could use the pinctrl-single,bits for the > >muxing and pinconf. > > Well, in that case, this is a reset line, so it does not have > anything to do with voltage :-) > > Anyway, thanks to Florian, we know that there is a real solution to > that problem. It is just not merged now :-( Right. Meanwhile, sounds like the transceiver driver needs to deal with the GPIO directly. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/4] ARM: dts: omap4-panda: Add USB Host support
Hi Tony, On 06/19/2013 07:27 AM, Tony Lindgren wrote: * Benoit Cousson [130619 03:17]: On 06/19/2013 02:46 AM, Tony Lindgren wrote: We have a similar issue with the MMC1 PBIAS. I think in the long run we should expand regulator (and possibly pinctrl) framework(s) to handle comparators. We could just assume that a comparatator is a regulator, and have a comparator binding that just uses the regulator code. In the case of pbias, the pinctrl seems to be a much better fit for my point of view. pinctrl can handle pin configuration and this is what the pbias is in the case of MMC pins. Well just recently Linus W specifically wanted us to use regulator framework for the MMC1 PBIAS rather than pinctrl. That's because from consumer driver point of view, it changes voltage and there's a delay involved. So I guess no conclusion yet, and it's best to do stand alone drivers to deal with those that use pinctrl for the pinctrl specific parts and export it as a regulator for the consumer devices. In the case of pbias, the boundary is not that clear, and it is true that writing a complete pinctrl driver is really overkill. I've tried in the past, and gave up due to the complexity of fmwk and the lack of time. I still think, it is a much better fmwk to handle pin configuration than the regulator fmwk. That's pretty much along the lines what Roger has done, except the transceiver could use the pinctrl-single,bits for the muxing and pinconf. Well, in that case, this is a reset line, so it does not have anything to do with voltage :-) Anyway, thanks to Florian, we know that there is a real solution to that problem. It is just not merged now :-( Regards, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/4] ARM: dts: omap4-panda: Add USB Host support
* Benoit Cousson [130619 05:30]:
> On 06/19/2013 07:05 AM, Florian Vaussard wrote:
> >>>+
> >>>+/* HS USB Port 1 RESET */
> >>>+hsusb1_reset: hsusb1_reset_reg {
> >>>+compatible = "regulator-fixed";
> >>>+regulator-name = "hsusb1_reset";
> >>>+regulator-min-microvolt = <330>;
> >>>+regulator-max-microvolt = <330>;
> >>>+gpio = <&gpio2 30 0>;/* gpio_62 */
> >>>+startup-delay-us = <7>;
> >>>+enable-active-high;
> >>>+};
> >>
> >>Is this really a regulator? Or just a GPIO line used to reset the
> >>USB PHY?
> >
> >It is in fact a GPIO line used as reset.
> >>
> >>If this is the case, I don't think it should be represented as a
> >>regulator.
> >
> >Why not? I think it fits very well in the regulator device model.
> >>>
> >>>I'm not sure fitting very well is the correct term.
> >>>It works, for sure, but it is no different than when we were trying
> >>>to abuse the regulator fmwk to enable the 32k clock in phoenix.
> >>>It is just a hack.
If it's a reset, then yeah it's not a regulator. If the GPIO line is
really used to control the regulator in the external device, then it
makes sense to set it up as a regulator.
> >>The only difference is there is a dedicated framework for clocks.
> >>Since there is nothing specific to
> >>handle reset lines it is left to the driver writer how he wants to
> >>manage it.
> >>
> >
> >There is a proposed binding for gpio-controlled reset lines, but it is
> >not yet merged [1].
> >I guess it can fit most usage patterns, and it can be an interesting
> >move in the future.
>
> I'm glad to see that I was not the only one thinking that the
> regulator was not the right fmwk to do that :-)
>
> Thanks for the pointer Florian.
Good to hear about the gpio-controlled reset lines :)
> I guess that series should be merged for 3.11? Based on the thread,
> it should to through arm-soc.
>
> Roger,
>
> It might be tricky to have dependency on that series, but if this is
> possible, you should try. Otherwise, just keep the existing one,
> adding that a new solution will be available soon as a disclaimer.
We need some solution for v3.11 for omap4 USB on panda so people can
use it with DT.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/4] ARM: dts: omap4-panda: Add USB Host support
* Benoit Cousson [130619 03:17]: > On 06/19/2013 02:46 AM, Tony Lindgren wrote: > > > >We have a similar issue with the MMC1 PBIAS. I think in the long run we > >should expand regulator (and possibly pinctrl) framework(s) to handle > >comparators. We could just assume that a comparatator is a regulator, > >and have a comparator binding that just uses the regulator code. > > In the case of pbias, the pinctrl seems to be a much better fit for > my point of view. pinctrl can handle pin configuration and this is > what the pbias is in the case of MMC pins. Well just recently Linus W specifically wanted us to use regulator framework for the MMC1 PBIAS rather than pinctrl. That's because from consumer driver point of view, it changes voltage and there's a delay involved. So I guess no conclusion yet, and it's best to do stand alone drivers to deal with those that use pinctrl for the pinctrl specific parts and export it as a regulator for the consumer devices. That's pretty much along the lines what Roger has done, except the transceiver could use the pinctrl-single,bits for the muxing and pinconf. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] MFD: Change TWL6025 references to TWL6032
From: Graeme Gregory
The TWL6025 was never released beyond sample form and was replaced by
the PhoenixLite range of chips - TWL6032. Change the references to
reference the TWL6032 class and name the registers to twl6032 in line with
an actual released chip name to avoid confusion.
Currently there are no users of TWL6025 in the code.
Signed-off-by: Graeme Gregory
Signed-off-by: Oleksandr Kozaruk
Acked-by: Lee Jones
---
There are non-mainline branches that use twl6032 by its name (for example
git://git.omapzoom.org/kernel/omap.git). There is intention to add support
of twl6032 device in mainline, but we'd like to know if we can use twl6032
instead of twl6025 in our new patches, that we are going to provide.
Related discussion: https://patchwork.kernel.org/patch/2686331/
.../bindings/regulator/twl-regulator.txt | 26 +++
.../devicetree/bindings/usb/twl-usb.txt|2 +-
drivers/mfd/twl-core.c | 46 ++--
drivers/regulator/twl-regulator.c | 76 ++--
drivers/usb/phy/phy-twl6030-usb.c |2 +-
include/linux/i2c/twl.h| 30
6 files changed, 91 insertions(+), 91 deletions(-)
diff --git a/Documentation/devicetree/bindings/regulator/twl-regulator.txt
b/Documentation/devicetree/bindings/regulator/twl-regulator.txt
index 658749b..75b0c16 100644
--- a/Documentation/devicetree/bindings/regulator/twl-regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/twl-regulator.txt
@@ -18,20 +18,20 @@ For twl6030 regulators/LDOs
- "ti,twl6030-vdd1" for VDD1 SMPS
- "ti,twl6030-vdd2" for VDD2 SMPS
- "ti,twl6030-vdd3" for VDD3 SMPS
-For twl6025 regulators/LDOs
+For twl6032 regulators/LDOs
- compatible:
- - "ti,twl6025-ldo1" for LDO1 LDO
- - "ti,twl6025-ldo2" for LDO2 LDO
- - "ti,twl6025-ldo3" for LDO3 LDO
- - "ti,twl6025-ldo4" for LDO4 LDO
- - "ti,twl6025-ldo5" for LDO5 LDO
- - "ti,twl6025-ldo6" for LDO6 LDO
- - "ti,twl6025-ldo7" for LDO7 LDO
- - "ti,twl6025-ldoln" for LDOLN LDO
- - "ti,twl6025-ldousb" for LDOUSB LDO
- - "ti,twl6025-smps3" for SMPS3 SMPS
- - "ti,twl6025-smps4" for SMPS4 SMPS
- - "ti,twl6025-vio" for VIO SMPS
+ - "ti,twl6032-ldo1" for LDO1 LDO
+ - "ti,twl6032-ldo2" for LDO2 LDO
+ - "ti,twl6032-ldo3" for LDO3 LDO
+ - "ti,twl6032-ldo4" for LDO4 LDO
+ - "ti,twl6032-ldo5" for LDO5 LDO
+ - "ti,twl6032-ldo6" for LDO6 LDO
+ - "ti,twl6032-ldo7" for LDO7 LDO
+ - "ti,twl6032-ldoln" for LDOLN LDO
+ - "ti,twl6032-ldousb" for LDOUSB LDO
+ - "ti,twl6032-smps3" for SMPS3 SMPS
+ - "ti,twl6032-smps4" for SMPS4 SMPS
+ - "ti,twl6032-vio" for VIO SMPS
For twl4030 regulators/LDOs
- compatible:
- "ti,twl4030-vaux1" for VAUX1 LDO
diff --git a/Documentation/devicetree/bindings/usb/twl-usb.txt
b/Documentation/devicetree/bindings/usb/twl-usb.txt
index 36b9aed..0aee0ad 100644
--- a/Documentation/devicetree/bindings/usb/twl-usb.txt
+++ b/Documentation/devicetree/bindings/usb/twl-usb.txt
@@ -8,7 +8,7 @@ TWL6030 USB COMPARATOR
usb interrupt number that raises VBUS interrupts when the controller has to
act as device
- usb-supply : phandle to the regulator device tree node. It should be vusb
- if it is twl6030 or ldousb if it is twl6025 subclass.
+ if it is twl6030 or ldousb if it is twl6032 subclass.
twl6030-usb {
compatible = "ti,twl6030-usb";
diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
index 89ab4d9..f39bceb 100644
--- a/drivers/mfd/twl-core.c
+++ b/drivers/mfd/twl-core.c
@@ -118,7 +118,7 @@
#define TWL6030_BASEADD_GASGAUGE 0x00C0
#define TWL6030_BASEADD_PIH0x00D0
#define TWL6030_BASEADD_CHARGER0x00E0
-#define TWL6025_BASEADD_CHARGER0x00DA
+#define TWL6032_BASEADD_CHARGER0x00DA
#define TWL6030_BASEADD_LED0x00F4
/* subchip/slave 2 0x4A - DFT */
@@ -718,9 +718,9 @@ add_children(struct twl4030_platform_data *pdata, unsigned
irq_base,
| REGULATOR_CHANGE_STATUS,
};
- if (features & TWL6025_SUBCLASS) {
+ if (features & TWL6032_SUBCLASS) {
usb3v3.supply = "ldousb";
- regulator = TWL6025_REG_LDOUSB;
+ regulator = TWL6032_REG_LDOUSB;
} else {
usb3v3.supply = "vusb";
regulator = TWL6030_REG_VUSB;
@@ -747,8 +747,8 @@ add_children(struct twl4030_platform_data *pdata, unsigned
irq_base,
usb3v3.dev_name = dev_name(child);
} else if (IS_ENABLED(CONFIG_REGULATOR_TWL4030) &&
twl_class_is_6030()) {
- if (features & TWL6025_SUBCLASS)
- child = add_regulator(TWL6025_REG_LDOUSB,
+ if (features & TWL6032_SUBCLASS)
+
Re: [PATCH v2 1/4] ARM: dts: omap4-panda: Add USB Host support
On 06/19/2013 07:05 AM, Florian Vaussard wrote:
Hello,
On 06/19/2013 01:03 PM, Roger Quadros wrote:
On 06/19/2013 01:10 PM, Benoit Cousson wrote:
On 06/19/2013 02:46 AM, Tony Lindgren wrote:
* Roger Quadros [130619 00:42]:
Hi Benoit,
On 06/19/2013 04:17 AM, Benoit Cousson wrote:
Hi Roger,
On 06/18/2013 11:04 AM, Roger Quadros wrote:
Provide the RESET and Power regulators for the USB PHY,
the USB Host port mode and the PHY device.
Also provide pin multiplexer information for the USB host
pins.
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 62
+
1 files changed, 62 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 00cbaa5..7a21e8e 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -59,6 +59,42 @@
"AFML", "Line In",
"AFMR", "Line In";
};
+
+/* HS USB Port 1 RESET */
+hsusb1_reset: hsusb1_reset_reg {
+compatible = "regulator-fixed";
+regulator-name = "hsusb1_reset";
+regulator-min-microvolt = <330>;
+regulator-max-microvolt = <330>;
+gpio = <&gpio2 30 0>;/* gpio_62 */
+startup-delay-us = <7>;
+enable-active-high;
+};
Is this really a regulator? Or just a GPIO line used to reset the
USB PHY?
It is in fact a GPIO line used as reset.
If this is the case, I don't think it should be represented as a
regulator.
Why not? I think it fits very well in the regulator device model.
I'm not sure fitting very well is the correct term.
It works, for sure, but it is no different than when we were trying
to abuse the regulator fmwk to enable the 32k clock in phoenix.
It is just a hack.
The only difference is there is a dedicated framework for clocks.
Since there is nothing specific to
handle reset lines it is left to the driver writer how he wants to
manage it.
There is a proposed binding for gpio-controlled reset lines, but it is
not yet merged [1].
I guess it can fit most usage patterns, and it can be an interesting
move in the future.
I'm glad to see that I was not the only one thinking that the regulator
was not the right fmwk to do that :-)
Thanks for the pointer Florian.
I guess that series should be merged for 3.11? Based on the thread, it
should to through arm-soc.
Roger,
It might be tricky to have dependency on that series, but if this is
possible, you should try. Otherwise, just keep the existing one, adding
that a new solution will be available soon as a disclaimer.
Regards,
Benoit
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] arm: add bandgap DT entry for OMAP5
On 19-06-2013 06:36, Benoit Cousson wrote:
> Hi Eduardo,
>
> On 06/18/2013 09:36 PM, Eduardo Valentin wrote:
>> Add bandgap device DT entry for OMAP5 dtsi.
>>
>> Cc: "Benoît Cousson"
>> Cc: Tony Lindgren
>> Cc: Russell King
>> Cc: linux-omap@vger.kernel.org
>> Cc: devicetree-disc...@lists.ozlabs.org
>> Cc: linux-arm-ker...@lists.infradead.org
>> Cc: linux-ker...@vger.kernel.org
>> Signed-off-by: Eduardo Valentin
>> Signed-off-by: J Keerthy
>> ---
>> arch/arm/boot/dts/omap5.dtsi | 8
>> 1 file changed, 8 insertions(+)
>> ---
>>
>> Benoit,
>>
>> Sorry for this very late request, but can you please consider
>> these patches for 3.11 still?
>>
>> I completely forgot to send these on my "Enable TI SoC thermal driver"
>> series.
>>
>> All best,
>>
>> Eduardo
>>
>> diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
>> index 2ad63c4..5ede6e1 100644
>> --- a/arch/arm/boot/dts/omap5.dtsi
>> +++ b/arch/arm/boot/dts/omap5.dtsi
>> @@ -615,5 +615,13 @@
>> interrupts = <0 80 0x4>;
>> ti,hwmods = "wd_timer2";
>> };
>
> missing blank line
>
>> +bandgap {
>
> You must use the first address in that case. Otherwise DT will affect a
> random number and provide a non-standard device name. That does not really
> matter in theory, but it will looks ugly in the /sys/devices list.
>
>> +reg = <0x4a0021e0 0xc
>> +0x4a00232c 0xc
>> +0x4a002380 0x2c
>> +0x4a0023C0 0x3c>;
>> +interrupts = <0 126 4>; /* talert */
>
> Not well aligned and should use the macros.
>
>> +compatible = "ti,omap5430-bandgap";
>> +};
>> };
>> };
>>
>
> I did the update for you :-)
>
> Here is the version I've just applied.
>
> Benoit
>
>
>>From f0160bb93467e22f2f8bc77591dcd7e35cdee999 Mon Sep 17 00:00:00 2001
> From: Eduardo Valentin
> Date: Tue, 18 Jun 2013 22:36:38 -0400
> Subject: [PATCH] ARM: dts: Add bandgap DT entry for OMAP5
>
> Add bandgap device DT entry for OMAP5 dtsi.
>
> Cc: Tony Lindgren
> Cc: Russell King
> Signed-off-by: Eduardo Valentin
> Signed-off-by: J Keerthy
> Signed-off-by: Benoit Cousson
> ---
> arch/arm/boot/dts/omap5.dtsi |9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
> index accab62..47693c9 100644
> --- a/arch/arm/boot/dts/omap5.dtsi
> +++ b/arch/arm/boot/dts/omap5.dtsi
> @@ -696,5 +696,14 @@
> interrupts = ;
> };
> };
> +
> + bandgap@4a0021e0 {
> + reg = <0x4a0021e0 0xc
> +0x4a00232c 0xc
> +0x4a002380 0x2c
> +0x4a0023C0 0x3c>;
> + interrupts = ;
> + compatible = "ti,omap5430-bandgap";
> + };
> };
> };
>
Looks good to me.
Tks Benoit!
--
You have got to be excited about what you are doing. (L. Lamport)
Eduardo Valentin
signature.asc
Description: OpenPGP digital signature
Re: [PATCH v2 1/4] ARM: dts: omap4-panda: Add USB Host support
Hello,
On 06/19/2013 01:03 PM, Roger Quadros wrote:
On 06/19/2013 01:10 PM, Benoit Cousson wrote:
On 06/19/2013 02:46 AM, Tony Lindgren wrote:
* Roger Quadros [130619 00:42]:
Hi Benoit,
On 06/19/2013 04:17 AM, Benoit Cousson wrote:
Hi Roger,
On 06/18/2013 11:04 AM, Roger Quadros wrote:
Provide the RESET and Power regulators for the USB PHY,
the USB Host port mode and the PHY device.
Also provide pin multiplexer information for the USB host
pins.
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 62
+
1 files changed, 62 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 00cbaa5..7a21e8e 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -59,6 +59,42 @@
"AFML", "Line In",
"AFMR", "Line In";
};
+
+/* HS USB Port 1 RESET */
+hsusb1_reset: hsusb1_reset_reg {
+compatible = "regulator-fixed";
+regulator-name = "hsusb1_reset";
+regulator-min-microvolt = <330>;
+regulator-max-microvolt = <330>;
+gpio = <&gpio2 30 0>;/* gpio_62 */
+startup-delay-us = <7>;
+enable-active-high;
+};
Is this really a regulator? Or just a GPIO line used to reset the USB PHY?
It is in fact a GPIO line used as reset.
If this is the case, I don't think it should be represented as a regulator.
Why not? I think it fits very well in the regulator device model.
I'm not sure fitting very well is the correct term.
It works, for sure, but it is no different than when we were trying to abuse
the regulator fmwk to enable the 32k clock in phoenix.
It is just a hack.
The only difference is there is a dedicated framework for clocks. Since there
is nothing specific to
handle reset lines it is left to the driver writer how he wants to manage it.
There is a proposed binding for gpio-controlled reset lines, but it is
not yet merged [1].
I guess it can fit most usage patterns, and it can be an interesting
move in the future.
Regards,
Florian
[1] http://thread.gmane.org/gmane.linux.drivers.devicetree/36830
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/4] ARM: dts: omap4-panda: Add USB Host support
On 06/19/2013 06:03 AM, Roger Quadros wrote:
On 06/19/2013 01:10 PM, Benoit Cousson wrote:
On 06/19/2013 02:46 AM, Tony Lindgren wrote:
* Roger Quadros [130619 00:42]:
Hi Benoit,
On 06/19/2013 04:17 AM, Benoit Cousson wrote:
Hi Roger,
On 06/18/2013 11:04 AM, Roger Quadros wrote:
Provide the RESET and Power regulators for the USB PHY,
the USB Host port mode and the PHY device.
Also provide pin multiplexer information for the USB host
pins.
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 62
+
1 files changed, 62 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 00cbaa5..7a21e8e 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -59,6 +59,42 @@
"AFML", "Line In",
"AFMR", "Line In";
};
+
+/* HS USB Port 1 RESET */
+hsusb1_reset: hsusb1_reset_reg {
+compatible = "regulator-fixed";
+regulator-name = "hsusb1_reset";
+regulator-min-microvolt = <330>;
+regulator-max-microvolt = <330>;
+gpio = <&gpio2 30 0>;/* gpio_62 */
+startup-delay-us = <7>;
+enable-active-high;
+};
Is this really a regulator? Or just a GPIO line used to reset the USB PHY?
It is in fact a GPIO line used as reset.
If this is the case, I don't think it should be represented as a regulator.
Why not? I think it fits very well in the regulator device model.
I'm not sure fitting very well is the correct term.
It works, for sure, but it is no different than when we were trying to abuse
the regulator fmwk to enable the 32k clock in phoenix.
It is just a hack.
The only difference is there is a dedicated framework for clocks. Since there
is nothing specific to
handle reset lines it is left to the driver writer how he wants to manage it.
Well, at that time, it was not available either. The point is still that
using a existing fmwk that has nothing to do with the signal you need to
handle just because it works is not a very good justification.
I couldn't find a better
way to represent this. It gives us a way to specify not only the GPIO line but
also
the polarity. I know mostly reset is active low but still there is flexibility
as you never
know for sure.
Mmm, and what about just controlling the gpio from the driver?
Yes gpio is possible. But then you need to add additional code in the driver to
parse GPIO number and polarity.
Using regulator_get() was plain simple for me.
Maybe, but it is not the right thing to do.
Can you explain me the commonality between a reset line and a regulator???
I think it's really a mux + a comparator. But from Linux driver point of view
a regulator fits well as we don't have anything better. After all, the pin
voltage changes, and then something can be done based on the comparator
value.
Do you have any better ideas?
We have a similar issue with the MMC1 PBIAS. I think in the long run we
should expand regulator (and possibly pinctrl) framework(s) to handle
comparators. We could just assume that a comparatator is a regulator,
and have a comparator binding that just uses the regulator code.
In the case of pbias, the pinctrl seems to be a much better fit for my point of
view. pinctrl can handle pin configuration and this is what the pbias is in the
case of MMC pins.
FYI. The USB PHY driver is already treating reset as a regulator and is into
3.10. Reworking that
will take some time. Not getting these in will prevent USB host/ethernet
support on panda.
That's not because we did some mistake in the past that we have to keep doing
that :-)
I had actually thought it well and don't consider it as a mistake. It is just a
difference in opinion.
Well, I don't think so. Again, you are abusing the regulator fmwk to
enable at boot time a GPIO line that should reset the IP. I doubt the
regulator fmwk was done for that. Otherwise Mark would have named it
"miscellaneous fmwk" or "regulator & reset" fmwk.
Yes and we need to have some solution for v3.11 as we've dropped the
legacy data for omap4. Otherwise things won't work properly.
I'm fine taking it as soon as big disclaimer is added to avoid mis-using the
regulator in the future for controlling a gpio line.
I can re-work the phy driver. No problem. But I'm still not convinced
what it will improve. IMHO it just adds more code in the phy driver without any
benefits.
Yes, it will. It will give explicitly the reset control to the driver
that knows and needs it. Moreover, it will avoid abusing a fmwk that was
not done for that purpose.
Regards,
Benoit
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/4] ARM: dts: omap4-panda: Add USB Host support
On 06/19/2013 01:10 PM, Benoit Cousson wrote:
> On 06/19/2013 02:46 AM, Tony Lindgren wrote:
>> * Roger Quadros [130619 00:42]:
>>> Hi Benoit,
>>>
>>> On 06/19/2013 04:17 AM, Benoit Cousson wrote:
Hi Roger,
On 06/18/2013 11:04 AM, Roger Quadros wrote:
> Provide the RESET and Power regulators for the USB PHY,
> the USB Host port mode and the PHY device.
>
> Also provide pin multiplexer information for the USB host
> pins.
>
> Signed-off-by: Roger Quadros
> ---
>arch/arm/boot/dts/omap4-panda-common.dtsi | 62
> +
>1 files changed, 62 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
> b/arch/arm/boot/dts/omap4-panda-common.dtsi
> index 00cbaa5..7a21e8e 100644
> --- a/arch/arm/boot/dts/omap4-panda-common.dtsi
> +++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
> @@ -59,6 +59,42 @@
>"AFML", "Line In",
>"AFMR", "Line In";
>};
> +
> +/* HS USB Port 1 RESET */
> +hsusb1_reset: hsusb1_reset_reg {
> +compatible = "regulator-fixed";
> +regulator-name = "hsusb1_reset";
> +regulator-min-microvolt = <330>;
> +regulator-max-microvolt = <330>;
> +gpio = <&gpio2 30 0>;/* gpio_62 */
> +startup-delay-us = <7>;
> +enable-active-high;
> +};
Is this really a regulator? Or just a GPIO line used to reset the USB PHY?
>>>
>>> It is in fact a GPIO line used as reset.
If this is the case, I don't think it should be represented as a regulator.
>>>
>>> Why not? I think it fits very well in the regulator device model.
>
> I'm not sure fitting very well is the correct term.
> It works, for sure, but it is no different than when we were trying to abuse
> the regulator fmwk to enable the 32k clock in phoenix.
> It is just a hack.
>
The only difference is there is a dedicated framework for clocks. Since there
is nothing specific to
handle reset lines it is left to the driver writer how he wants to manage it.
>>> I couldn't find a better
>>> way to represent this. It gives us a way to specify not only the GPIO line
>>> but also
>>> the polarity. I know mostly reset is active low but still there is
>>> flexibility as you never
>>> know for sure.
>
> Mmm, and what about just controlling the gpio from the driver?
Yes gpio is possible. But then you need to add additional code in the driver to
parse GPIO number and polarity.
Using regulator_get() was plain simple for me.
>
>> I think it's really a mux + a comparator. But from Linux driver point of view
>> a regulator fits well as we don't have anything better. After all, the pin
>> voltage changes, and then something can be done based on the comparator
>> value.
>>
>>> Do you have any better ideas?
>>
>> We have a similar issue with the MMC1 PBIAS. I think in the long run we
>> should expand regulator (and possibly pinctrl) framework(s) to handle
>> comparators. We could just assume that a comparatator is a regulator,
>> and have a comparator binding that just uses the regulator code.
>
> In the case of pbias, the pinctrl seems to be a much better fit for my point
> of view. pinctrl can handle pin configuration and this is what the pbias is
> in the case of MMC pins.
>
>>> FYI. The USB PHY driver is already treating reset as a regulator and is
>>> into 3.10. Reworking that
>>> will take some time. Not getting these in will prevent USB host/ethernet
>>> support on panda.
>
> That's not because we did some mistake in the past that we have to keep doing
> that :-)
>
I had actually thought it well and don't consider it as a mistake. It is just a
difference in opinion.
>> Yes and we need to have some solution for v3.11 as we've dropped the
>> legacy data for omap4. Otherwise things won't work properly.
>
> I'm fine taking it as soon as big disclaimer is added to avoid mis-using the
> regulator in the future for controlling a gpio line.
>
I can re-work the phy driver. No problem. But I'm still not convinced
what it will improve. IMHO it just adds more code in the phy driver without any
benefits.
cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: dts: AM33XX: Add support for IGEP COM AQUILA
Hi Enric,
On 06/19/2013 03:27 AM, Enric Balletbo i Serra wrote:
The IGEP COM AQUILA is industrial processors SODIMM module with
following highlights:
o AM3352/AM3354/AM3358/AM3359 Texas Instruments processor
o Cortex-A8 ARM CPU
o 3.3 volts Inputs / Outputs use industrial
o 256 MB DDR3 SDRAM / 128 Megabytes FLASH
o MicroSD card reader on-board
o Ethernet controller on-board
o JTAG debug connector available
o Designed for industrial range purposes
Signed-off-by: Enric Balletbo i Serra
---
arch/arm/boot/dts/am335x-igep0033.dtsi | 269 +
1 file changed, 269 insertions(+)
create mode 100644 arch/arm/boot/dts/am335x-igep0033.dtsi
diff --git a/arch/arm/boot/dts/am335x-igep0033.dtsi
b/arch/arm/boot/dts/am335x-igep0033.dtsi
new file mode 100644
index 000..1d70141
--- /dev/null
+++ b/arch/arm/boot/dts/am335x-igep0033.dtsi
@@ -0,0 +1,269 @@
+/*
+ * Copyright (C) 2013 ISEE 2007 SL - http://www.isee.biz/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/dts-v1/;
+
+#include "am33xx.dtsi"
+
+/ {
+ cpus {
+ cpu@0 {
+ cpu0-supply = <&vdd1_reg>;
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x8000 0x1000>; /* 256 MB */
+ };
+
+ am33xx_pinmux: pinmux@44e10800 {
That node should be inside the ocp one since the control module is a
regular IP connected to the OCP interconnect.
+ pinctrl-names = "default";
+
+ i2c0_pins: pinmux_i2c0_pins {
+ pinctrl-single,pins = <
+ 0x188 (PIN_INPUT_PULLUP | MUX_MODE0)/*
i2c0_sda.i2c0_sda */
+ 0x18c (PIN_INPUT_PULLUP | MUX_MODE0)/*
i2c0_scl.i2c0_scl */
+ >;
+ };
+
+ nandflash_pins: pinmux_nandflash_pins {
+ pinctrl-single,pins = <
+ 0x0 (PIN_INPUT_PULLUP | MUX_MODE0) /*
gpmc_ad0.gpmc_ad0 */
+ 0x4 (PIN_INPUT_PULLUP | MUX_MODE0) /*
gpmc_ad1.gpmc_ad1 */
+ 0x8 (PIN_INPUT_PULLUP | MUX_MODE0) /*
gpmc_ad2.gpmc_ad2 */
+ 0xc (PIN_INPUT_PULLUP | MUX_MODE0) /*
gpmc_ad3.gpmc_ad3 */
+ 0x10 (PIN_INPUT_PULLUP | MUX_MODE0) /*
gpmc_ad4.gpmc_ad4 */
+ 0x14 (PIN_INPUT_PULLUP | MUX_MODE0) /*
gpmc_ad5.gpmc_ad5 */
+ 0x18 (PIN_INPUT_PULLUP | MUX_MODE0) /*
gpmc_ad6.gpmc_ad6 */
+ 0x1c (PIN_INPUT_PULLUP | MUX_MODE0) /*
gpmc_ad7.gpmc_ad7 */
+ 0x70 (PIN_INPUT_PULLUP | MUX_MODE0) /*
gpmc_wait0.gpmc_wait0 */
+ 0x74 (PIN_INPUT_PULLUP | MUX_MODE7) /*
gpmc_wpn.gpio0_30 */
+ 0x7c (PIN_OUTPUT | MUX_MODE0) /*
gpmc_csn0.gpmc_csn0 */
+ 0x90 (PIN_OUTPUT | MUX_MODE0) /*
gpmc_advn_ale.gpmc_advn_ale */
+ 0x94 (PIN_OUTPUT | MUX_MODE0) /*
gpmc_oen_ren.gpmc_oen_ren */
+ 0x98 (PIN_OUTPUT | MUX_MODE0) /*
gpmc_wen.gpmc_wen */
+ 0x9c (PIN_OUTPUT | MUX_MODE0) /*
gpmc_be0n_cle.gpmc_be0n_cle */
+ >;
+ };
+
+ uart0_pins: pinmux_uart0_pins {
+ pinctrl-single,pins = <
+ 0x170 (PIN_INPUT_PULLUP | MUX_MODE0)/*
uart0_rxd.uart0_rxd */
+ 0x174 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /*
uart0_txd.uart0_txd */
+ >;
+ };
+
+ user_leds: pinmux_user_leds_pins {
+ pinctrl-single,pins = <
+ 0x5c (PIN_OUTPUT_PULLDOWN | MUX_MODE7) /*
gpmc_a7.gpio1_23 */
+ >;
+ };
+
+ };
+
+ ocp {
+ uart0: serial@44e09000 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_pins>;
+ status = "okay";
+ };
+
+ i2c0: i2c@44e0b000 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c0_pins>;
+
+ status = "okay";
+ clock-frequency = <40>;
+
+ tps: tps@2d {
+ reg = <0x2d>;
+ };
+ };
+
+ elm: elm@4808 {
+ status = "okay";
+ };
+
+ gpmc: gpmc@5000 {
+
Re: [PATCH] ARM: dts: AM43x EPOS EVM support
Hi Afzal,
On 06/14/2013 09:03 AM, Afzal Mohammed wrote:
Add AM43x ePOS EVM minimal DT source - this is a minimal one to get
it booting. Also include it in omap2plus dtbs and document bindings.
The hardware is under development.
Signed-off-by: Afzal Mohammed
---
Hi Benoit,
This is based on your for_3.11/dts branch.
Ideally I wanted to split this into 3 patches - first doc, second dts
and last adding build support. As changes in total is trivial, it was
made a single one.
That's fine for me. I've just applied it.
Thanks,
Benoit
Regards
Afzal
Documentation/devicetree/bindings/arm/omap/omap.txt | 3 +++
arch/arm/boot/dts/Makefile | 3 ++-
arch/arm/boot/dts/am43x-epos-evm.dts| 18 ++
3 files changed, 23 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/am43x-epos-evm.dts
diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt
b/Documentation/devicetree/bindings/arm/omap/omap.txt
index f8288ea..6d498c7 100644
--- a/Documentation/devicetree/bindings/arm/omap/omap.txt
+++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
@@ -56,3 +56,6 @@ Boards:
- OMAP5 EVM : Evaluation Module
compatible = "ti,omap5-evm", "ti,omap5"
+
+- AM43x EPOS EVM
+ compatible = "ti,am43x-epos-evm", "ti,am4372", "ti,am43"
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 8e50761..05da469 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -155,7 +155,8 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
am335x-evmsk.dtb \
am335x-bone.dtb \
am3517-evm.dtb \
- am3517_mt_ventoux.dtb
+ am3517_mt_ventoux.dtb \
+ am43x-epos-evm.dtb
dtb-$(CONFIG_ARCH_ORION5X) += orion5x-lacie-ethernet-disk-mini-v2.dtb
dtb-$(CONFIG_ARCH_PRIMA2) += prima2-evb.dtb
dtb-$(CONFIG_ARCH_U8500) += snowball.dtb \
diff --git a/arch/arm/boot/dts/am43x-epos-evm.dts
b/arch/arm/boot/dts/am43x-epos-evm.dts
new file mode 100644
index 000..74174d4
--- /dev/null
+++ b/arch/arm/boot/dts/am43x-epos-evm.dts
@@ -0,0 +1,18 @@
+/*
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.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.
+ */
+
+/* AM43x EPOS EVM */
+
+/dts-v1/;
+
+#include "am4372.dtsi"
+
+/ {
+ model = "TI AM43x EPOS EVM";
+ compatible = "ti,am43x-epos-evm","ti,am4372","ti,am43";
+};
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] arm: add bandgap DT entry for OMAP5
Hi Eduardo,
On 06/18/2013 09:36 PM, Eduardo Valentin wrote:
> Add bandgap device DT entry for OMAP5 dtsi.
>
> Cc: "Benoît Cousson"
> Cc: Tony Lindgren
> Cc: Russell King
> Cc: linux-omap@vger.kernel.org
> Cc: devicetree-disc...@lists.ozlabs.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-ker...@vger.kernel.org
> Signed-off-by: Eduardo Valentin
> Signed-off-by: J Keerthy
> ---
> arch/arm/boot/dts/omap5.dtsi | 8
> 1 file changed, 8 insertions(+)
> ---
>
> Benoit,
>
> Sorry for this very late request, but can you please consider
> these patches for 3.11 still?
>
> I completely forgot to send these on my "Enable TI SoC thermal driver" series.
>
> All best,
>
> Eduardo
>
> diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
> index 2ad63c4..5ede6e1 100644
> --- a/arch/arm/boot/dts/omap5.dtsi
> +++ b/arch/arm/boot/dts/omap5.dtsi
> @@ -615,5 +615,13 @@
> interrupts = <0 80 0x4>;
> ti,hwmods = "wd_timer2";
> };
missing blank line
> + bandgap {
You must use the first address in that case. Otherwise DT will affect a random
number and provide a non-standard device name. That does not really matter in
theory, but it will looks ugly in the /sys/devices list.
> + reg = <0x4a0021e0 0xc
> + 0x4a00232c 0xc
> + 0x4a002380 0x2c
> + 0x4a0023C0 0x3c>;
> + interrupts = <0 126 4>; /* talert */
Not well aligned and should use the macros.
> + compatible = "ti,omap5430-bandgap";
> + };
> };
> };
>
I did the update for you :-)
Here is the version I've just applied.
Benoit
>From f0160bb93467e22f2f8bc77591dcd7e35cdee999 Mon Sep 17 00:00:00 2001
From: Eduardo Valentin
Date: Tue, 18 Jun 2013 22:36:38 -0400
Subject: [PATCH] ARM: dts: Add bandgap DT entry for OMAP5
Add bandgap device DT entry for OMAP5 dtsi.
Cc: Tony Lindgren
Cc: Russell King
Signed-off-by: Eduardo Valentin
Signed-off-by: J Keerthy
Signed-off-by: Benoit Cousson
---
arch/arm/boot/dts/omap5.dtsi |9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index accab62..47693c9 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -696,5 +696,14 @@
interrupts = ;
};
};
+
+ bandgap@4a0021e0 {
+ reg = <0x4a0021e0 0xc
+ 0x4a00232c 0xc
+ 0x4a002380 0x2c
+ 0x4a0023C0 0x3c>;
+ interrupts = ;
+ compatible = "ti,omap5430-bandgap";
+ };
};
};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] i2c: add deprecation warning for class based instantiation
On Fri, Jun 07, 2013 at 11:09:26AM +0200, Wolfram Sang wrote: > Class based instantiation can cause huge delays when booting. This > mechanism was used when it was not possible to describe slaves on I2C > busses. We now have other mechanisms, so most embedded I2C will not need > classes and it was explicitly not recommended to use them. Add a > deprecation warning for drivers who want to disable class based in the > near future to gain boot-up time, so users relying on this technique can > switch to something better. They really should. > > Signed-off-by: Wolfram Sang No reactions on this, pity. Deferring. signature.asc Description: Digital signature
Re: [PATCH v2 1/4] ARM: dts: omap4-panda: Add USB Host support
On 06/19/2013 02:46 AM, Tony Lindgren wrote:
* Roger Quadros [130619 00:42]:
Hi Benoit,
On 06/19/2013 04:17 AM, Benoit Cousson wrote:
Hi Roger,
On 06/18/2013 11:04 AM, Roger Quadros wrote:
Provide the RESET and Power regulators for the USB PHY,
the USB Host port mode and the PHY device.
Also provide pin multiplexer information for the USB host
pins.
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 62
+
1 files changed, 62 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 00cbaa5..7a21e8e 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -59,6 +59,42 @@
"AFML", "Line In",
"AFMR", "Line In";
};
+
+/* HS USB Port 1 RESET */
+hsusb1_reset: hsusb1_reset_reg {
+compatible = "regulator-fixed";
+regulator-name = "hsusb1_reset";
+regulator-min-microvolt = <330>;
+regulator-max-microvolt = <330>;
+gpio = <&gpio2 30 0>;/* gpio_62 */
+startup-delay-us = <7>;
+enable-active-high;
+};
Is this really a regulator? Or just a GPIO line used to reset the USB PHY?
It is in fact a GPIO line used as reset.
If this is the case, I don't think it should be represented as a regulator.
Why not? I think it fits very well in the regulator device model.
I'm not sure fitting very well is the correct term.
It works, for sure, but it is no different than when we were trying to
abuse the regulator fmwk to enable the 32k clock in phoenix.
It is just a hack.
I couldn't find a better
way to represent this. It gives us a way to specify not only the GPIO line but
also
the polarity. I know mostly reset is active low but still there is flexibility
as you never
know for sure.
Mmm, and what about just controlling the gpio from the driver?
I think it's really a mux + a comparator. But from Linux driver point of view
a regulator fits well as we don't have anything better. After all, the pin
voltage changes, and then something can be done based on the comparator
value.
Do you have any better ideas?
We have a similar issue with the MMC1 PBIAS. I think in the long run we
should expand regulator (and possibly pinctrl) framework(s) to handle
comparators. We could just assume that a comparatator is a regulator,
and have a comparator binding that just uses the regulator code.
In the case of pbias, the pinctrl seems to be a much better fit for my
point of view. pinctrl can handle pin configuration and this is what the
pbias is in the case of MMC pins.
FYI. The USB PHY driver is already treating reset as a regulator and is into
3.10. Reworking that
will take some time. Not getting these in will prevent USB host/ethernet
support on panda.
That's not because we did some mistake in the past that we have to keep
doing that :-)
Yes and we need to have some solution for v3.11 as we've dropped the
legacy data for omap4. Otherwise things won't work properly.
I'm fine taking it as soon as big disclaimer is added to avoid mis-using
the regulator in the future for controlling a gpio line.
Regards,
Benoit
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5] i2c: omap: correct usage of the interrupt enable register
On Mon, Jun 03, 2013 at 10:37:20AM +0300, Oleksandr Dmytryshyn wrote: > We've been lucky not to have any interrupts fire during the suspend > path, otherwise we would have unpredictable behaviour in the kernel. > > Based on the logic of the kernel code interrupts from i2c should be > prohibited during suspend. Kernel writes 0 to the I2C_IE register in > the omap_i2c_runtime_suspend() function. In the other side kernel > writes saved interrupt flags to the I2C_IE register in > omap_i2c_runtime_resume() function. I.e. interrupts should be disabled > during suspend. > > This works for chips with version1 registers scheme. Interrupts are > disabled during suspend. For chips with version2 scheme registers > writting 0 to the I2C_IE register does nothing (because now the > I2C_IRQENABLE_SET register is located at this address). This register > is used to enable interrupts. For disabling interrupts > I2C_IRQENABLE_CLR register should be used. > > Because the registers I2C_IRQENABLE_SET and I2C_IE have the same > addresses, the interrupt enabling procedure is unchanged. > > I've checked that interrupts in the i2c controller are still enabled > after writting 0 to the I2C_IRQENABLE_SET register. With this patch > interrupts are disabled in the omap_i2c_runtime_suspend() function. > > Patch is based on: > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > tag: v3.10-rc2 Last paragraph should be below "---". > > Verified on OMAP4430. > > Signed-off-by: Oleksandr Dmytryshyn Applied to for-next, thanks! signature.asc Description: Digital signature
Re: [PATCH 2/6] ARM: OMAP2+: Remove board-omap4panda.c
* Arnaud Patard [130619 02:52]: > Tony Lindgren writes: > > Hi, > > > * Tony Lindgren [130617 03:32]: > >> * Arnaud Patard [130617 02:52]: > >> > Tony Lindgren writes: > >> > > >> > I understand your concerns but, please, cope with reality: the clock > >> > work is not in -next so this tends to make me think it won't reach > >> > 3.11. We're at -rc6 after all. Telling users that their system doesn't > >> > have any network because it was easier to maintain, is not something > >> > they will understand imho. > >> > >> Right, like I said: the idea is to have it usable with DT. And USB and > >> Ethernet certainly are part of what I call usable. So is MMC, WLAN and > >> DSS. I've certainly spent quite a bit of time on making sure panda works > >> with DT, and I can assure you that fixing the USB extclock is easier than > >> supporting the legacy boot with DT :) > >> > >> This issue can also be fixed with a clock alias if we don't have DT > >> defined clocks ready for v3.11. It may take a few days for us to have > >> the solution. But get getting a clock to a driver certainly is not a > >> showstopper here. After all, that's what all drivers already do. > > > > Care to test the last patch just posted by Roger in thread > > " [PATCH 0/4] ARM: OMAP4: Panda USB Host support and DVI EDID fix"? > > I tried to test them but they don't apply on linux-next due to some > pinctrl changes probably missing: > Error: arch/arm/boot/dts/omap4-panda-common.dtsi:177.14-15 syntax error > > which corresponds to : > 0x82 (PIN_INPUT_PULLDOWN | MUX_MODE4) Oops, right, that's in Benoit's branch too for the .dts preprocessing. Until it is merged, maybe try with Roger's earlier version of that patch that did not yet use the macros? > Also, the patch 3 (ARM: dts: omap5-uevm: Provide USB Host PHY clock) > doesn't apply as the omap5-uevm.dts doesn't exist. OK that's in Benoit's branch. But you won't need that one. > Which tree should I use to test the patches if it's not linux-next ? > > Also, you might want to know that drivers/usb/musb/omap2430.c doesn't > build due to some typos (musb_resources vs musb_resouces). Thanks, I think Felipe is already aware of that. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] Add pinmux DT nodes to CPSW for AM335x
On 06/19/2013 12:53 AM, Mugunthan V N wrote: On 6/7/2013 5:02 PM, Mugunthan V N wrote: Add pinmux DT nodes to CPSW for the following AM335x boards * AM335x Beaglebone * AM335x EVM * AM335x EVMsk default state contains the pinmux required for active mode and sleep mode contains pinmux reset values for energy saving. Mugunthan V N (3): ARM: dts: AM33XX: Add pinmux configuration for CPSW to beaglebone ARM: dts: AM33XX: Add pinmux configuration for CPSW to EVMsk ARM: dts: AM33XX: Add pinmux configuration for CPSW to am335x EVM arch/arm/boot/dts/am335x-bone.dts | 67 ++ arch/arm/boot/dts/am335x-evm.dts | 64 + arch/arm/boot/dts/am335x-evmsk.dts | 92 3 files changed, 223 insertions(+) Benoit Do you have any comments on this patch series, if not can you queue it for v3.11 The series looks good to me. I've just applied it. Thanks, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mfd: Palmas: Remove code which is not necessary for a device tree boot
On Wed, 19 Jun 2013, Samuel Ortiz wrote: > Hi Lee, > > On Wed, Jun 19, 2013 at 09:26:33AM +0100, Lee Jones wrote: > > On Mon, 17 Jun 2013, J Keerthy wrote: > > > > > Remove code which is not necessary for a device tree boot. > > > > So we're exclusively DT now right? > > > > > Boot tested on OMAP5-UEVM board. > > > > > > Signed-off-by: J Keerthy > > > --- > > > drivers/mfd/palmas.c | 106 > > > -- > > > 1 files changed, 0 insertions(+), 106 deletions(-) > > > > If that's the case, applied with all Acks, thanks. > It's already in mfd-next. I noticed. Odd that I didn't receive you applied message. -- Lee Jones Linaro ST-Ericsson Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/6] ARM: OMAP2+: Remove board-omap4panda.c
Tony Lindgren writes: Hi, > * Tony Lindgren [130617 03:32]: >> * Arnaud Patard [130617 02:52]: >> > Tony Lindgren writes: >> > >> > I understand your concerns but, please, cope with reality: the clock >> > work is not in -next so this tends to make me think it won't reach >> > 3.11. We're at -rc6 after all. Telling users that their system doesn't >> > have any network because it was easier to maintain, is not something >> > they will understand imho. >> >> Right, like I said: the idea is to have it usable with DT. And USB and >> Ethernet certainly are part of what I call usable. So is MMC, WLAN and >> DSS. I've certainly spent quite a bit of time on making sure panda works >> with DT, and I can assure you that fixing the USB extclock is easier than >> supporting the legacy boot with DT :) >> >> This issue can also be fixed with a clock alias if we don't have DT >> defined clocks ready for v3.11. It may take a few days for us to have >> the solution. But get getting a clock to a driver certainly is not a >> showstopper here. After all, that's what all drivers already do. > > Care to test the last patch just posted by Roger in thread > " [PATCH 0/4] ARM: OMAP4: Panda USB Host support and DVI EDID fix"? I tried to test them but they don't apply on linux-next due to some pinctrl changes probably missing: Error: arch/arm/boot/dts/omap4-panda-common.dtsi:177.14-15 syntax error which corresponds to : 0x82 (PIN_INPUT_PULLDOWN | MUX_MODE4) Also, the patch 3 (ARM: dts: omap5-uevm: Provide USB Host PHY clock) doesn't apply as the omap5-uevm.dts doesn't exist. Which tree should I use to test the patches if it's not linux-next ? Also, you might want to know that drivers/usb/musb/omap2430.c doesn't build due to some typos (musb_resources vs musb_resouces). Arnaud -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] ARM: dts: OMAP3: Updates for Overo
On 06/19/2013 04:29 AM, Florian Vaussard wrote: Hello Benoit, Any comments on this series? That series looks good to me. I've just applied it. Thanks, Benoit Regards, Florian On 06/11/2013 04:49 PM, Florian Vaussard wrote: Hello, This series performs several updates to omap3-overo and omap3-tobi. Patch 1 is necessary to patch 2 for the IRQ constant. The SMSC911X is largely taken from omap3-igep. Regards, Florian Florian Vaussard (4): ARM: dts: OMAP3: Include IRQ header ARM: dts: omap3-tobi: Add SMSC911X node ARM: dts: omap3-tobi: Correct polarity for GPIO LED ARM: dts: omap3-overo: Add default trigger for TWL4030 LED arch/arm/boot/dts/omap3-overo.dtsi |1 + arch/arm/boot/dts/omap3-tobi.dts | 50 +++- arch/arm/boot/dts/omap3.dtsi |1 + 3 files changed, 51 insertions(+), 1 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: Protect pinctrl headers against multiple inclusions
Hi Florian, On 06/19/2013 04:28 AM, Florian Vaussard wrote: Hello Benoit, On 06/12/2013 06:18 PM, Cousson, Benoit wrote: Hi Florian, On 6/12/2013 8:42 AM, Florian Vaussard wrote: Hello Grant, On 06/11/2013 11:57 PM, Grant Likely wrote: On Tue, 11 Jun 2013 16:50:50 +0200, Florian Vaussard wrote: Pinctrl headers were not protected with #ifndef. Signed-off-by: Florian Vaussard Obviously this needs to go in via whatever tree added the modified header files. I authored these files, sorry for this stupid omission. Benoit, can you take this patch? Yes, sure, I'll take it with Grant's ack. I think that you missed this one. In was in the pipe but not pushed yet. That will be done soon. Thanks, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] ARM: dts: OMAP3: Updates for Overo
Hello Benoit, Any comments on this series? Regards, Florian On 06/11/2013 04:49 PM, Florian Vaussard wrote: Hello, This series performs several updates to omap3-overo and omap3-tobi. Patch 1 is necessary to patch 2 for the IRQ constant. The SMSC911X is largely taken from omap3-igep. Regards, Florian Florian Vaussard (4): ARM: dts: OMAP3: Include IRQ header ARM: dts: omap3-tobi: Add SMSC911X node ARM: dts: omap3-tobi: Correct polarity for GPIO LED ARM: dts: omap3-overo: Add default trigger for TWL4030 LED arch/arm/boot/dts/omap3-overo.dtsi |1 + arch/arm/boot/dts/omap3-tobi.dts | 50 +++- arch/arm/boot/dts/omap3.dtsi |1 + 3 files changed, 51 insertions(+), 1 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: Protect pinctrl headers against multiple inclusions
Hello Benoit, On 06/12/2013 06:18 PM, Cousson, Benoit wrote: Hi Florian, On 6/12/2013 8:42 AM, Florian Vaussard wrote: Hello Grant, On 06/11/2013 11:57 PM, Grant Likely wrote: On Tue, 11 Jun 2013 16:50:50 +0200, Florian Vaussard wrote: Pinctrl headers were not protected with #ifndef. Signed-off-by: Florian Vaussard Obviously this needs to go in via whatever tree added the modified header files. I authored these files, sorry for this stupid omission. Benoit, can you take this patch? Yes, sure, I'll take it with Grant's ack. I think that you missed this one. Regards, Florian -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ARM: dts: Add headers with constants for MTD partitions
Hello,
Thank you for the review.
On 06/12/2013 03:05 PM, Grant Likely wrote:
On Tue, 11 Jun 2013 16:48:56 +0200, Florian Vaussard
wrote:
These constants can be used to easily declare MTD partitions inside
DTS.
The constants MTDPART_OFS_* are purposely not included. Indeed,
parse_ofpart_partitions() is expecting u64, but a DT cell is u32.
Negative constants, as defined by MTDPART_OFS_*, would be wrongly
The DT binding uses the number of cells defined by #address-cells. It is
not fixed to a u32 or a u64
The message was ill-formatted, sorry. As an address cell is u32, and as
parse_ofpart_partitions() is storing the value inside u64 without checking
for sign extension (as one assumes to have only positive offsets),
passing a negative value would require 2 address cells, making it more
difficult
for the DT user. But as Stephen Warren noticed, it is probably desirable
to specify sizes >= 4GB, thus I will think about a way to easily handle
such case.
Anyway, MTDPART_OFS_* would probably face the same objection raised by
you for
MTDPART_SIZ_FULL.
interpreted by parse_ofpart_partitions(). Two cells should be
used to correctly encode the negative constants, but this breaks
current usage.
The binding doesn't even allow for shortcuts like MTDPART_SIZ_FULL. If a
partition fills the whole device, then the reg property should include
the actual size. If the code is allowing '0' to be used to mean
MTDPART_SIZ_FULL, then that is a bug that needs to be fixed.
The root problem is that many System on Module, like the Gumstix Overo, are
shipped with various NAND sizes depending on the version or even the
manufacturing
period. Supporting such a diversity would painfully duplicates lots of DT
code and clutter the arch/arm/boot/dts/ directory with dozens of slightly-
different versions. I believe that determining the NAND size is better done
at probe time, and this is what is currently done in legacy board files:
static struct mtd_partition overo_nand_partitions[] = {
{
.name = "xloader",
.offset = 0,/* Offset =
0x0 */
.size = 4 * NAND_BLOCK_SIZE,
.mask_flags = MTD_WRITEABLE
},
{
.name = "rootfs",
.offset = MTDPART_OFS_APPEND, /* Offset =
0x68 */
.size = MTDPART_SIZ_FULL,
},
};
Moreover, I do not see such strict restriction in the OF norm. If I
refer to IEEE
1275-1994 page 174, for the definition of the "reg" property, it is written:
"The interpretation of the size entries is dependent on the parent bus."
Nevertheless, if such an approach is not acceptable, could we think about an
alternative solution? Like a boolean property "mtd,append-and-fill" that
would
replace the "reg" property and tell the MTD core to compute the
partition size
at probe time, like what is currently done with board files?
Best regards,
Florian
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
