[PATCH v3] ARM: dts: OMAP5: Add palmas MFD node and regulator nodes
This patch adds Palmas MFD node and the regulator nodes for OMAP5. The node definitions are based on: https://lkml.org/lkml/2013/6/6/25 Boot tested on omap5-uevm board. Signed-off-by: Graeme Gregory Signed-off-by: J Keerthy --- arch/arm/boot/dts/omap5-uevm.dts | 170 ++ 1 files changed, 170 insertions(+), 0 deletions(-) diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts index 927db1e..6fbe47c 100644 --- a/arch/arm/boot/dts/omap5-uevm.dts +++ b/arch/arm/boot/dts/omap5-uevm.dts @@ -8,6 +8,8 @@ /dts-v1/; #include "omap5.dtsi" +#include +#include / { model = "TI OMAP5 uEVM board"; @@ -254,6 +256,174 @@ pinctrl-0 = <&i2c1_pins>; clock-frequency = <40>; + + palmas: palmas@48 { + reg = <0x48>; + interrupts = ; /* IRQ_SYS_1N */ + interrupt-parent = <&gic>; + }; +}; + +&palmas { + compatible = "ti,palmas"; + interrupt-controller; + #interrupt-cells = <2>; + + palmas_pmic { + compatible = "ti,palmas-pmic"; + interrupt-parent = <&palmas>; + interrupts = <14 IRQ_TYPE_NONE>; + interrupt-name = "short-irq"; + + ti,ldo6-vibrator; + + regulators { + smps123_reg: smps123 { + regulator-name = "smps123"; + regulator-min-microvolt = < 60>; + regulator-max-microvolt = <150>; + regulator-always-on; + regulator-boot-on; + }; + + smps45_reg: smps45 { + regulator-name = "smps45"; + regulator-min-microvolt = < 60>; + regulator-max-microvolt = <131>; + regulator-always-on; + regulator-boot-on; + }; + + smps6_reg: smps6 { + regulator-name = "smps6"; + regulator-min-microvolt = <120>; + regulator-max-microvolt = <120>; + regulator-always-on; + regulator-boot-on; + }; + + smps7_reg: smps7 { + regulator-name = "smps7"; + regulator-min-microvolt = <180>; + regulator-max-microvolt = <180>; + regulator-always-on; + regulator-boot-on; + }; + + smps8_reg: smps8 { + regulator-name = "smps8"; + regulator-min-microvolt = < 60>; + regulator-max-microvolt = <131>; + regulator-always-on; + regulator-boot-on; + }; + + smps9_reg: smps9 { + regulator-name = "smps9"; + regulator-min-microvolt = <210>; + regulator-max-microvolt = <210>; + regulator-always-on; + regulator-boot-on; + ti,smps-range = <0x80>; + }; + + smps10_reg: smps10 { + regulator-name = "smps10"; + regulator-min-microvolt = <500>; + regulator-max-microvolt = <500>; + regulator-always-on; + regulator-boot-on; + }; + + ldo1_reg: ldo1 { + regulator-name = "ldo1"; + regulator-min-microvolt = <280>; + regulator-max-microvolt = <280>; + regulator-always-on; + regulator-boot-on; + }; + + ldo2_reg: ldo2 { + regulator-name = "ldo2"; + regulator-min-microvolt = <290>; + regulator-max-microvolt = <290>; + regulator-always-on; + regulator-boot-on; + }; + + ldo3_reg: ldo3 { + regulator-name = "ldo3"; + regulator-min-microvolt = <300>; + regulator-max-microvolt = <300>; + regula
Re: [PATCH 13/14] ARM: AM33XX: hwmod data: irq, dma and addr info clean up
Hi Kevin, On Monday 10 June 2013 10:33 PM, Kevin Hilman wrote: Hi Lokesh, Lokesh Vutla writes: Hi Kevin, On Friday 07 June 2013 03:57 AM, Kevin Hilman wrote: Paul Walmsley writes: On Wed, 29 May 2013, Santosh Shilimkar wrote: From: Vaibhav Hiremath AM33XX only supports DT boot mode and with addition of extracting module resources like, irq, dma and address space from DT block, so now we can remove duplicate information from hwmod data file. OK, guess I'll take your word for it that it all works. The BeagleBone-white with appended DTB hasn't booted here since v3.7. And the BeagleBone-black with discrete DTB doesn't boot at all with current mainline, only with the TI vendor kernel & DTB... Anyone care to shed light on what's missing for BeagleBone boot with mainline currently? I have tested BeagleBone boot with today's mainline bootloader and kernel. It boots perfectly fine. Can you post git trees + branch names (and/or commit IDs) and also kernel config please? Following are the details: U-Boot: url:git://git.denx.de/u-boot.git branch :master config: am335x_evm Top commit: "842033e pci: introduce CONFIG_PCI_INDIRECT_BRIDGE option" Kernel: url: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git branch: master config: omap2plus_defocnfig dtb file: am335x-bone.dtb Top commit: "317ddd2 Linux 3.10-rc5" (On top of this I have a local patch for appending dtb) You can find the logs here: http://pastebin.com/vcBr0UhM Thanks and regards, Lokesh Thanks, 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 v2 1/2] ARM: dts: add dtsi for palmas
Hi Stephen, > -Original Message- > From: Stephen Warren [mailto:swar...@wwwdotorg.org] > Sent: Monday, June 10, 2013 9:59 PM > To: J, KEERTHY > Cc: Cousson, Benoit; devicetree-disc...@lists.ozlabs.org; linux- > o...@vger.kernel.org; linux-ker...@vger.kernel.org; > ldewan...@nvidia.com; grant.lik...@secretlab.ca; swar...@nvidia.com; > sa...@linux.intel.com; g...@slimlogic.co.uk; lee.jo...@linaro.org > Subject: Re: [PATCH v2 1/2] ARM: dts: add dtsi for palmas > > On 06/10/2013 03:04 AM, J Keerthy wrote: > > Adds palmas mfd and palmas regulator nodes. > > Nits: > > Well, you're really adding files that provide the nodes, not the nodes > themselves. > > Palmas and MFD should be correctly capitalized. Ok. > > > diff --git a/arch/arm/boot/dts/palmas.dtsi > > b/arch/arm/boot/dts/palmas.dtsi > > > +&palmas { > ... > > + palmas_pmic { > ... > > + ti,ldo6-vibrator; > > Isn't that board-specific? I don't know the HW well enough to say, but > I assume that since there's a property, the whole point must be that > some boards want it set and some don't. > Yes. I will make this part of board file. > > + regulators { > > + smps123_reg: smps123 { > > + regulator-name = "smps123"; > > + }; > > So the node labels here duplicate those in omap5-uevm.dts in patch 2/2. > While dtc allows this, I don't think there's much point duplicating the > labels. I'd tend to only put the labels in omap5-uevm.dts and not put > them here. That will completely avoid the possibility of the labels in > this file from conflicting with any other labels in any top-level > board.dts file. > > I also wonder if this file is actually terribly useful. The only thing > that this file provides is the regulator-name property. It seems > simpler just to put that into each board.dts file. The added advantage > of doing that, is that if a board doesn't use a particular regulator, > the node won't appear, and the regulator won't get registered. Ok. I will transfer the entire code to omap5-uevm.dts. Thanks for the review comments. 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 3/7] omap: mailbox: call request_irq after mbox queues are allocated
Russ, On 06/08/2013 01:53 PM, Russ Dill wrote: > On Fri, Jun 7, 2013 at 6:57 PM, Suman Anna wrote: >> The OMAP mailbox startup code is enabling the interrupt even before >> any of the associated mailbox queues are allocated. Any pending >> received mailbox message could cause a kernel panic as soon as >> the interrupt is enabled due to the dereferencing of non-existing >> mailbox queues within the ISR. >> >> Signed-off-by: Fernando Guzman Lugo >> Signed-off-by: Suman Anna >> --- >> arch/arm/plat-omap/mailbox.c | 18 +- >> 1 file changed, 9 insertions(+), 9 deletions(-) >> >> diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c >> index 5fb4027..e1bd333 100644 >> --- a/arch/arm/plat-omap/mailbox.c >> +++ b/arch/arm/plat-omap/mailbox.c >> @@ -261,13 +261,6 @@ static int omap_mbox_startup(struct omap_mbox *mbox) >> } >> >> if (!mbox->use_count++) { >> - ret = request_irq(mbox->irq, mbox_interrupt, IRQF_SHARED, >> - mbox->name, mbox); >> - if (unlikely(ret)) { >> - pr_err("failed to register mailbox interrupt:%d\n", >> - ret); >> - goto fail_request_irq; >> - } >> mq = mbox_queue_alloc(mbox, NULL, mbox_tx_tasklet); >> if (!mq) { >> ret = -ENOMEM; >> @@ -282,17 +275,24 @@ static int omap_mbox_startup(struct omap_mbox *mbox) >> } >> mbox->rxq = mq; >> mq->mbox = mbox; >> + ret = request_irq(mbox->irq, mbox_interrupt, IRQF_SHARED, >> + mbox->name, mbox); >> + if (unlikely(ret)) { >> + pr_err("failed to register mailbox interrupt:%d\n", >> + ret); >> + goto fail_request_irq; >> + } >> >> omap_mbox_enable_irq(mbox, IRQ_RX); > > I can't help but to notice the IRQ unmasking function here. Is there a > reason it isn't working? This patch was based on an internal patch needed before the equivalent of 1d8a0e9 "ARM: OMAP: enable mailbox irq per instance" is merged. I will revise the patch description - this is more of a minor cleanup now rather than a fix, would have been a fix without the above patch. Thanks for pointing it out. regards Suman -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/4] regulator: Introduce OMAP regulator to control PMIC over VC/VP
On Mon, Jun 10, 2013 at 12:51:42PM -0500, Nishanth Menon wrote: > a) Tegra seems to use Lookup Table for sending predefinied voltage > values to PMIC. OMAP has no concept of lookup table. They seem to be doing basically the same thing here, you've got a linear map of selector to voltage too AFAICT. > b) Tegra and OMAP h/w blocks seem to use I2C - that is good. > c) How about the i2c slave and register addresses, slew rates, start, > end voltages, max voltages that SoC can support etc, I am yet to > understand those. > d) OMAP has 3 modules - AVS (SmartReflex), Voltage Processor(VP), > Voltage Controller(VC) - I am not yet sure about the Tegra hardware > blocks involved. This all seems like it's at the implementation detail level - the bit that seems like we should be able to share it is the big picture bit for how we describe how the AP side stuff and PMIC are hooked up without having to have a bunch of completely non-framework stuff for things like describing the PMIC. signature.asc Description: Digital signature
Re: [PATCH v2 2/2] PM / AVS: SmartReflex/class3: Fix order of initialization of SR class and SR driver
Andrii Tseglytskyi writes: > SmartReflex consists of three entities: SR device, SR class and > SR driver. SmartReflex driver depends on SmartReflex class, but > order of their initialization is not clear. They both use > late_initcall(), and order depends on Makefile calls. > Patch moves initialization of SR class to device_initcall(), > and removes redundant call of sr_late_init(). > > This provides predictable order of SmartReflex initcalls: > 1. device_initcall() -> SmartReflex class init > 2. late_initcall() -> SmartReflex driver init > > Signed-off-by: Andrii Tseglytskyi Tony will have to decide on whether he's OK with the initcall changes. I can queue this with the rest of the AVS changes with Tony's ack. Kevin > --- > arch/arm/mach-omap2/smartreflex-class3.c |2 +- > drivers/power/avs/smartreflex.c |9 - > 2 files changed, 1 insertion(+), 10 deletions(-) > > diff --git a/arch/arm/mach-omap2/smartreflex-class3.c > b/arch/arm/mach-omap2/smartreflex-class3.c > index aee3c89..50523b8 100644 > --- a/arch/arm/mach-omap2/smartreflex-class3.c > +++ b/arch/arm/mach-omap2/smartreflex-class3.c > @@ -59,4 +59,4 @@ static int __init sr_class3_init(void) > pr_info("SmartReflex Class3 initialized\n"); > return sr_register_class(&class3_data); > } > -omap_late_initcall(sr_class3_init); > +omap_device_initcall(sr_class3_init); > diff --git a/drivers/power/avs/smartreflex.c b/drivers/power/avs/smartreflex.c > index fd71d5a..42eed34 100644 > --- a/drivers/power/avs/smartreflex.c > +++ b/drivers/power/avs/smartreflex.c > @@ -650,8 +650,6 @@ void sr_disable(struct voltagedomain *voltdm) > */ > int sr_register_class(struct omap_sr_class_data *class_data) > { > - struct omap_sr *sr_info; > - > if (!class_data) { > pr_warning("%s:, Smartreflex class data passed is NULL\n", > __func__); > @@ -666,13 +664,6 @@ int sr_register_class(struct omap_sr_class_data > *class_data) > > sr_class = class_data; > > - /* > - * Call into late init to do intializations that require > - * both sr driver and sr class driver to be initiallized. > - */ > - list_for_each_entry(sr_info, &sr_list, node) > - sr_late_init(sr_info); > - > return 0; > } -- 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 1/4] regulator: Introduce OMAP regulator to control PMIC over VC/VP
On Mon, Jun 10, 2013 at 11:49 AM, Mark Brown wrote: > On Mon, Jun 10, 2013 at 11:16:59AM -0500, Nishanth Menon wrote: >> On Mon, Jun 10, 2013 at 5:31 AM, Mark Brown wrote: >> > On Wed, May 22, 2013 at 01:18:34PM -0500, Nishanth Menon wrote: > >> > So, the biggest problem here has been patch 4 (having to have a hack to >> > deploy this stuff is a bit worrying) plus the general not having a real >> > driver thing. > >> Patch #4 in this series was a hack as it was not properly split up and >> organized as a proper DTS series -it was meant as a proof of concept - >> not entirely meant to indicate the remaining 1-3 patches were hacks >> :). > > The way it reads is that you're building up to a hack - if what you've > done isn't enabling a sensible solution there might be a problem with > the earlier steps. Understood, I should have taken extra steps to split up the patch into it's logical series, but wanted to get a quick feel from community about the approach before spending time on it. I apologize for the confusion caused. > >> I think you mean http://marc.info/?t=13705924913&r=1&w=2 series. I >> will dig into it. if it is possible for Tegra and OMAP to use the same >> framework and strategy to deal with these kind of h/w blocks, all the >> more better. > > Not just better, if each system doing this sort of thing needs to > reinvent the wheel something is going wrong. Fair enough, I did spend a short while digging through the discussion in the series, I need to find Tegra TRM to see if there is commonolity between OMAP and what Tegra does at hardware level. a) Tegra seems to use Lookup Table for sending predefinied voltage values to PMIC. OMAP has no concept of lookup table. b) Tegra and OMAP h/w blocks seem to use I2C - that is good. c) How about the i2c slave and register addresses, slew rates, start, end voltages, max voltages that SoC can support etc, I am yet to understand those. d) OMAP has 3 modules - AVS (SmartReflex), Voltage Processor(VP), Voltage Controller(VC) - I am not yet sure about the Tegra hardware blocks involved. maybe Paul could comment as well, I suppose if we could take a common approach between Tegra and OMAP. Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] PM / AVS: SmartReflex: use devm_* API to initialize SmartReflex
Andrii Tseglytskyi writes: > Use of of devm_* API for resource allocation provides benefits such > as auto handling of resource free. This reduces possibility have > memory leaks in case of wrong error handling. All direct release > calls should be removed to avoid races. > > Reported-by: Grygorii Strashko > Signed-off-by: Andrii Tseglytskyi Thanks, queuing this for v3.11. 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 v1 0/3] PM / AVS: SmartReflex: use omap_sr * for class interfaces
Andrii Tseglytskyi writes: > SmartReflex driver interface is natively divided to two parts: > > - external SmartReflex interface > - interface between SmartReflex driver and SmartReflex Class > > Functions which belong to AVS class interface can use > struct omap_sr* instead of struct voltatedomain*, to provide a > direct connection between SR driver and SR class. This allows > us to optimize and not do additional lookups where none is > required. > > Patches are based on: > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > tag: v3.10-rc2 > > Verified on OMAP4430. Boot - OK. SmartReflex registers debug dump - OK > > Available on GitHub: > https://github.com/andriit/linux-omap-k3.8/commits/avs_sr_driver_std_class_interfaces_v01 > > Andrii Tseglytskyi (3): > PM / AVS: SmartReflex: use omap_sr * for errgen interfaces > PM / AVS: SmartReflex: use omap_sr * for minmax interfaces > PM / AVS: SmartReflex: use omap_sr * for enable/disable interface > > arch/arm/mach-omap2/smartreflex-class3.c |8 ++-- > drivers/power/avs/smartreflex.c | 63 > +++--- > include/linux/power/smartreflex.h| 10 ++--- > 3 files changed, 40 insertions(+), 41 deletions(-) Thanks, queuing this series for v3.11. 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 2/7] omap: mailbox: check for NULL nb in mailbox_put
Russ, On 06/08/2013 01:46 PM, Russ Dill wrote: > On Fri, Jun 7, 2013 at 6:57 PM, Suman Anna wrote: >> The mailbox_put function must check the notifier block for >> NULL before trying to unregister it. > > I'm going to nack this one. Why must it check for NULL? None of the > callers pass a NULL argument and blocking_notifier_chain_unregister > handles a NULL nb argument just fine. Thanks for the review. It should have been done differently, which is to print an error trace if the passed in arguments are NULL. Anyway, I will drop this since I expect this function to go away once this is adapted to the new framework. regards Suman > >> Signed-off-by: Fernando Guzman Lugo >> Signed-off-by: Suman Anna >> --- >> arch/arm/plat-omap/mailbox.c | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c >> index 42377ef..5fb4027 100644 >> --- a/arch/arm/plat-omap/mailbox.c >> +++ b/arch/arm/plat-omap/mailbox.c >> @@ -356,7 +356,8 @@ EXPORT_SYMBOL(omap_mbox_get); >> >> void omap_mbox_put(struct omap_mbox *mbox, struct notifier_block *nb) >> { >> - blocking_notifier_chain_unregister(&mbox->notifier, nb); >> + if (nb) >> + blocking_notifier_chain_unregister(&mbox->notifier, nb); >> omap_mbox_fini(mbox); >> } >> EXPORT_SYMBOL(omap_mbox_put); >> -- >> 1.8.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 -- 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 5/7] ARM: OMAP2+: mbox: remove dependencies with soc.h
Russ, On 06/08/2013 02:16 PM, Russ Dill wrote: > On Fri, Jun 7, 2013 at 6:58 PM, Suman Anna wrote: >> The OMAP mailbox platform driver code has been cleaned up to >> remove the dependencies with soc.h in preparation for moving >> the mailbox code to drivers folder. >> >> The code relied on cpu_is_xxx/soc_is_xxx macros previously to >> pick the the right set of mailbox devices and register with the >> mailbox driver. This data is now represented in a concise format >> and moved to the respective omap_hwmod data files and published >> to the driver through the platform data. > > I have some comments on how the cpu_is_xxx/soc_is_xxx was done. In its > current form, intr_type is just a sub for cpu_is_omap44xx(). I'd like > to see the scope of that parameter reduced a bit and have the changes > match the model of gpio-omap.c a little better (see 4e962e89 for an > example). Comments inline. I have looked up the gpio-omap.c and the usage style is different. The purpose here is similar, the interrupt programming is different between OMAP4+ and OMAP3-. For gpio, all the registers are supplied through platform data (published differently for DT and non-DT). The knowledge of the registers is with the driver for mailbox (in both DT and non-DT), with only the bare minimum data passed through pdata (for non-DT) with this patch. The only variation in mailbox registers is the interrupt type configuration, the number of valid registers are dictated by number of fifos and number of target processors, and I have added these to the platform data in Patch6. The main purpose of this patch is to remove the cpu_is_xxx macro dependencies which are currently used for defining the different mboxes as well as the register programming. I didn't want to separate out the mailbox device creation into a separate file with all the additional data that this patch is removing, we do not want to create a new file in mach-omap2 at this point. The omap_mbox_init will essentially vanish for DT, and so would be the dev_attrs being added to the hwmod data files. > >> Cc: Paul Walmsley >> Signed-off-by: Suman Anna >> --- >> arch/arm/mach-omap2/devices.c | 9 +- >> arch/arm/mach-omap2/mailbox.c | 250 >> ++--- >> arch/arm/mach-omap2/omap_hwmod_2420_data.c | 12 ++ >> arch/arm/mach-omap2/omap_hwmod_2430_data.c | 11 ++ >> arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 11 ++ >> arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 13 ++ >> arch/arm/plat-omap/include/plat/mailbox.h | 2 +- >> include/linux/platform_data/mailbox-omap.h | 53 ++ >> 8 files changed, 198 insertions(+), 163 deletions(-) >> create mode 100644 include/linux/platform_data/mailbox-omap.h >> >> diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c >> index 4269fc1..4c97a86 100644 >> --- a/arch/arm/mach-omap2/devices.c >> +++ b/arch/arm/mach-omap2/devices.c >> @@ -20,6 +20,7 @@ >> #include >> #include >> #include >> +#include >> #include >> >> #include >> @@ -332,14 +333,20 @@ static inline void __init omap_init_mbox(void) >> { >> struct omap_hwmod *oh; >> struct platform_device *pdev; >> + struct omap_mbox_pdata *pdata; >> >> oh = omap_hwmod_lookup("mailbox"); >> if (!oh) { >> pr_err("%s: unable to find hwmod\n", __func__); >> return; >> } >> + if (!oh->dev_attr) { >> + pr_err("%s: hwmod doesn't have valid attrs\n", __func__); >> + return; >> + } >> >> - pdev = omap_device_build("omap-mailbox", -1, oh, NULL, 0); >> + pdata = (struct omap_mbox_pdata *)oh->dev_attr; >> + pdev = omap_device_build("omap-mailbox", -1, oh, pdata, >> sizeof(*pdata)); >> WARN(IS_ERR(pdev), "%s: could not build device, err %ld\n", >> __func__, PTR_ERR(pdev)); >> } >> diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c >> index b01aae6..fcb425c 100644 >> --- a/arch/arm/mach-omap2/mailbox.c >> +++ b/arch/arm/mach-omap2/mailbox.c >> @@ -11,16 +11,16 @@ >> */ >> >> #include >> +#include >> #include >> #include >> #include >> #include >> #include >> +#include >> >> #include >> >> -#include "soc.h" >> - >> #define MAILBOX_REVISION 0x000 >> #define MAILBOX_MESSAGE(m) (0x040 + 4 * (m)) >> #define MAILBOX_FIFOSTATUS(m) (0x080 + 4 * (m)) >> @@ -59,6 +59,7 @@ struct omap_mbox2_priv { >> u32 notfull_bit; >> u32 ctx[OMAP4_MBOX_NR_REGS]; >> unsigned long irqdisable; >> + u32 intr_type; >> }; >> >> static inline unsigned int mbox_read_reg(size_t ofs) >> @@ -136,7 +137,7 @@ static void omap2_mbox_disable_irq(struct omap_mbox >> *mbox, omap_mbox_irq_t irq) >> struct omap_mbox2_priv *p = mbox->priv; >> u32 bit = (irq == IRQ_TX) ? p->notfull_bit : p->newmsg_bit; >> >> - if (!cpu_is_omap44xx()) >> +
Re: [PATCH 13/14] ARM: AM33XX: hwmod data: irq, dma and addr info clean up
Hi Lokesh, Lokesh Vutla writes: > Hi Kevin, > > On Friday 07 June 2013 03:57 AM, Kevin Hilman wrote: >> Paul Walmsley writes: >> >>> On Wed, 29 May 2013, Santosh Shilimkar wrote: >>> From: Vaibhav Hiremath AM33XX only supports DT boot mode and with addition of extracting module resources like, irq, dma and address space from DT block, so now we can remove duplicate information from hwmod data file. >>> >>> OK, guess I'll take your word for it that it all works. The >>> BeagleBone-white with appended DTB hasn't booted here since v3.7. >>> And the BeagleBone-black with discrete DTB doesn't boot at all with >>> current mainline, only with the TI vendor kernel & DTB... >> >> Anyone care to shed light on what's missing for BeagleBone boot with >> mainline currently? > I have tested BeagleBone boot with today's mainline bootloader and > kernel. It boots perfectly fine. Can you post git trees + branch names (and/or commit IDs) and also kernel config please? Thanks, 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 1/4] regulator: Introduce OMAP regulator to control PMIC over VC/VP
On Mon, Jun 10, 2013 at 11:16:59AM -0500, Nishanth Menon wrote: > On Mon, Jun 10, 2013 at 5:31 AM, Mark Brown wrote: > > On Wed, May 22, 2013 at 01:18:34PM -0500, Nishanth Menon wrote: > > So, the biggest problem here has been patch 4 (having to have a hack to > > deploy this stuff is a bit worrying) plus the general not having a real > > driver thing. > Patch #4 in this series was a hack as it was not properly split up and > organized as a proper DTS series -it was meant as a proof of concept - > not entirely meant to indicate the remaining 1-3 patches were hacks > :). The way it reads is that you're building up to a hack - if what you've done isn't enabling a sensible solution there might be a problem with the earlier steps. > I think you mean http://marc.info/?t=13705924913&r=1&w=2 series. I > will dig into it. if it is possible for Tegra and OMAP to use the same > framework and strategy to deal with these kind of h/w blocks, all the > more better. Not just better, if each system doing this sort of thing needs to reinvent the wheel something is going wrong. signature.asc Description: Digital signature
Re: [PATCH v3] ARM: DTS: TWL4030: fix mux and wakeup for SYS_NIRQ line
Benoit Cousson writes: > Hi Kevin, > > On 06/07/2013 09:31 PM, Nishanth Menon wrote: >> On 11:31-20130607, Kevin Hilman wrote: >>> On most OMAP3 platforms, the twl4030 IRQ line is connected to the >>> SYS_NIRQ line on OMAP. Add another DTS include file >>> (twl4030_omap3.dtsi) for boards that hook up the twl4030 this way >>> to include. >>> >>> This allows RTC wake from off-mode to work again on OMAP3-based >>> platforms with twl4030. Tested on 3530/Beagle, 3730/Beagle-xM, >>> 3530/Overo, 3730/Overo-STORM. >>> >>> Special thanks to Florian Vaussard for suggesting use of preprocessor >>> feature. >>> >>> Cc: Florian Vaussard >>> Cc: Benoit Cousson >>> Cc: Nishanth Menon >>> Signed-off-by: Kevin Hilman >> Thanks, >> Reviewed-by: Nishanth Menon > > Thanks, I've just applied it in for_3.11/dts. Thanks, Will you apply the first 2 from the series too? ARM: DTS: OMAP3: beagle/overo: mux console UART, enable wakeup ARM: DTS: OMAP3: beagle: enable user button via gpio_keys, enable wakeup Thanks, 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 v2 1/2] ARM: dts: add dtsi for palmas
On 06/10/2013 03:04 AM, J Keerthy wrote: > Adds palmas mfd and palmas regulator nodes. Nits: Well, you're really adding files that provide the nodes, not the nodes themselves. Palmas and MFD should be correctly capitalized. > diff --git a/arch/arm/boot/dts/palmas.dtsi b/arch/arm/boot/dts/palmas.dtsi > +&palmas { ... > + palmas_pmic { ... > + ti,ldo6-vibrator; Isn't that board-specific? I don't know the HW well enough to say, but I assume that since there's a property, the whole point must be that some boards want it set and some don't. > + regulators { > + smps123_reg: smps123 { > + regulator-name = "smps123"; > + }; So the node labels here duplicate those in omap5-uevm.dts in patch 2/2. While dtc allows this, I don't think there's much point duplicating the labels. I'd tend to only put the labels in omap5-uevm.dts and not put them here. That will completely avoid the possibility of the labels in this file from conflicting with any other labels in any top-level board.dts file. I also wonder if this file is actually terribly useful. The only thing that this file provides is the regulator-name property. It seems simpler just to put that into each board.dts file. The added advantage of doing that, is that if a board doesn't use a particular regulator, the node won't appear, and the regulator won't get registered. -- 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/4] mmc: omap_hsmmc: Remux pins to support SDIO interrupt and PM runtime
* Linus Walleij [130610 09:09]: > > You can use the new infrastructure to make the core select: > > pinctrl_pm_select_default_state(host->dev); > pinctrl_pm_select_idle_state(host->dev); OK great. > What is the semantic difference between "default" and "active"? We only should remux the pins that need remuxing as that's done every time hitting idle. So I think we should have the following default groups: default Static pins that don't change, no need to remux configured in consumer driver probe like we already do active Optional dynamic pins remuxed for runtime, can be configured and selected in consumer driver probe. The consumer driver may also want to select this state in PM runtime resume. idleOptional dynamic pins remuxed for idle. The consumer driver may also want to select this state in PM runtime suspend depending on device_can_wakeup() and driver specific needs. > If this is something very generic that a lot of platforms will want > to have, why not add it to include/linux/pinctrl/pinctrl-state.h > and augment the core to cache and handle this too? Yes we should do that assuming the above grouping makes sense to you. > However in this case I *suspect* that what you really want > to do it to rename the state called "default" to "sleep" > (it appears the default state is sleepy) and then rename > the "active" state to "default" (as this is the defined semantic > meaning of "default" from . The idle state above could also be called sleep instead of idle if you prefer that. > But maybe I'm not quite getting the subtle difference between > "default" and "active" here so enlighten me. I think the confusion is caused by the fact that we need three mux groups, not just two :) The toggling between active and idle is the hotpath as that can potentially happen for multiple drivers every time we enter and exit idle. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: add dtsi for palmas
On 06/09/2013 10:03 PM, J, KEERTHY wrote: > Hi Stephen, > > Thanks for the review comments. Cam you please fix your email client to quote the messages you're replyiing to correctly? In the message you sent, there's no differentiation between what I originally wrote and you quoted, vs. the new text you wrote as a response. That makes the message very confusing to read... -- 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: add dtsi for palmas
On 06/10/2013 03:29 AM, Benoit Cousson wrote: > Hi Keerthy, > > On 06/10/2013 06:03 AM, J, KEERTHY wrote: >> Hi Stephen, >> >> Thanks for the review comments. >> >> >> From: Stephen Warren [swar...@wwwdotorg.org] >> Sent: Saturday, June 08, 2013 1:26 AM >> To: J, KEERTHY >> Cc: Cousson, Benoit; devicetree-disc...@lists.ozlabs.org; >> linux-omap@vger.kernel.org; linux-ker...@vger.kernel.org; >> ldewan...@nvidia.com; grant.lik...@secretlab.ca; swar...@nvidia.com; >> sa...@linux.intel.com; g...@slimlogic.co.uk; lee.jo...@linaro.org >> Subject: Re: [PATCH] ARM: dts: add dtsi for palmas >> >> On 06/07/2013 05:28 AM, J Keerthy wrote: >>> Adds palmas mfd and palmas regulator nodes. This is >>> based on the patch series: >>> >>> http://www.mail-archive.com/linux-omap@vger.kernel.org/msg89957.html >>> >>> The device tree nodes are based on: >>> https://lkml.org/lkml/2013/6/6/25 >> >>> diff --git a/arch/arm/boot/dts/palmas.dtsi b/arch/arm/boot/dts/palmas.dtsi >> >>> +&palmas { >> >> Hmmm. That (i.e. requiring the board file to declare the node, then >> setting up all the content by later including this file) is an >> interesting approach. I guess it's reasonable. The one issue is that it >> makes it a little harder for the board file to override any of the >> properties in this file., although it certainly is possible by including >> those overrides after the include. >> >> Irrespective of that, some comments on this: >> >>> + palmas_pmic { >> >>> + ti,ldo6-vibrator; >> >> For example, what if the board doesn't want to have the property set? >> >>> + >>> + regulators { >>> + smps123_reg: smps123 { >>> + regulator-name = "smps123"; >>> + regulator-min-microvolt = < 60>; >>> + regulator-max-microvolt = <150>; >> >> Or what if the board wants to limit the voltage range of this regulator >> due to what it's used for on the board. >> >>> + regulator-always-on; >>> + regulator-boot-on; >> >> And those two properties are almost certainly board-specific policy. >> >> Totally agree to all the above concerns. So can we have a custom .dtsi file >> for a board+pmic combination? Or have only the required properties over >> ridden >> in the board file? > > Yes, you can do that potentially if most OMAP5 boards will reuse the > same kind of settings. Kevin has just done that for OMAP3 + twl4030. > > In this case, since we do have only one board, I'm not sure it worth the > effort. IIUC, various Tegra boards use this PMIC, so there's more than one board in question here. Or were you talking about e.g.: palmas.dtsi - base Palmas DT node for everything omap-palmas.dtsi - common Palmas settings for all OMAP boards ... where the latter file would only be used by one board? If so, then yes, creating the latter file might not make sense yet. -- 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 1/4] regulator: Introduce OMAP regulator to control PMIC over VC/VP
+Paul. On Mon, Jun 10, 2013 at 5:31 AM, Mark Brown wrote: > On Wed, May 22, 2013 at 01:18:34PM -0500, Nishanth Menon wrote: > > So, the biggest problem here has been patch 4 (having to have a hack to > deploy this stuff is a bit worrying) plus the general not having a real > driver thing. Patch #4 in this series was a hack as it was not properly split up and organized as a proper DTS series -it was meant as a proof of concept - not entirely meant to indicate the remaining 1-3 patches were hacks :). > >> +- ti,i2c-slave-address - I2C slave address of the PMIC >> +- ti,i2c-voltage-register - I2C register address where voltage commands are >> + to be set. >> +- ti,i2c-command-register - I2C register address where commands are to be >> set >> + when OMAP enters low power state. This may be the same as >> + ti,i2c-voltage-register depending on the PMIC. >> +- ti,slew-rate-microvolt - worst case slew rate of rise / fall for voltage >> + transition in microvolts per microseconds (uV/uS) >> +- step-size-micro-volts - Step size in micovolts as to what one step in >> voltage >> + selector increment translates to. See example. >> +- regulator-min-microvolt - Minimum voltage in microvolts which is >> supported by >> + the PMIC in ti,step-size-microvolt increments. See example. >> +- regulator-max-microvolt - Maximum voltage in microvolts which is supported >> + by the PMIC in ti,step-size-microvolt increments. See example. > > The other thing is this whole business of encoding the properties of the > PMIC in the DT like this. Paul Walmsley has started doing some work for > some similiar hardware where instead of doing this the regulator is in > the DT as normal and then the driver for the offloaded voltage scaling > gets the information about the register layout from the regulator > driver. This is a bit neater overall and would cope with determining > which method to use at runtime. I think you mean http://marc.info/?t=13705924913&r=1&w=2 series. I will dig into it. if it is possible for Tegra and OMAP to use the same framework and strategy to deal with these kind of h/w blocks, all the more better. Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] mmc: omap_hsmmc: Remux pins to support SDIO interrupt and PM runtime
On Fri, Jun 7, 2013 at 11:49 PM, Tony Lindgren wrote: > On some omaps we need to remux MMC pins for PM, and for some omaps > we need to remux the SDIO IRQ pin. > > Based on an earlier patch by Andreas Fenkart . (...) > + host->pinctrl = devm_pinctrl_get(host->dev); > + if (IS_ERR(host->pinctrl)) { > + dev_dbg(host->dev, "no pinctrl handle\n"); > + ret = 0; > + goto out; > + } > + > + host->fixed = pinctrl_lookup_state(host->pinctrl, > + PINCTRL_STATE_DEFAULT); > + if (IS_ERR(host->fixed)) { > + dev_dbg(host->dev, > +"pins are not configured from the driver\n"); > + host->fixed = NULL; > + ret = 0; > + goto out; > + } > + > + ret = pinctrl_select_state(host->pinctrl, host->fixed); > + if (ret < 0) > + goto err; > + > + /* For most cases we don't have wake-ups, and exit after this */ > + host->active = pinctrl_lookup_state(host->pinctrl, "active"); > + if (IS_ERR(host->active)) { > + ret = PTR_ERR(host->active); > + host->active = NULL; > + return 0; > + } > + > + host->idle = pinctrl_lookup_state(host->pinctrl, > + PINCTRL_STATE_IDLE); > + if (IS_ERR(host->idle)) { > + ret = PTR_ERR(host->idle); > + host->idle = NULL; > + goto err; > + } You can use the new infrastructure to make the core select: pinctrl_pm_select_default_state(host->dev); pinctrl_pm_select_idle_state(host->dev); What is the semantic difference between "default" and "active"? If this is something very generic that a lot of platforms will want to have, why not add it to include/linux/pinctrl/pinctrl-state.h and augment the core to cache and handle this too? However in this case I *suspect* that what you really want to do it to rename the state called "default" to "sleep" (it appears the default state is sleepy) and then rename the "active" state to "default" (as this is the defined semantic meaning of "default" from . But maybe I'm not quite getting the subtle difference between "default" and "active" here so enlighten me. 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 2/2] drivers: net: davinci_mdio: use pinctrl PM helpers
On Thu, Jun 6, 2013 at 8:15 PM, Mugunthan V N wrote: > This utilize the new pinctrl core PM helpers to transition > the driver to "default" and "sleep" states. > > Signed-off-by: Mugunthan V N This version of the patch applied with DaveM:s ACK. 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/2] drivers: net: cpsw: use pinctrl PM helpers
On Thu, Jun 6, 2013 at 8:15 PM, Mugunthan V N wrote: > This utilize the new pinctrl core PM helpers to transition > the driver to "default" and "sleep" states. > > Signed-off-by: Mugunthan V N This version of the patch applied with DaveM:s ACK. 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: [net-next PATCH v4 1/5] net: cpsw: enhance pinctrl support
On Fri, Jun 7, 2013 at 4:49 PM, Mugunthan V N wrote: >> If you want to merge the direct networking parts of this series into >> another tree, I'm fine with that: >> >> Acked-by: David S. Miller > > David > > Can you the below patch series as i have adopted pinctrl PM api in another > series, > this patch has direct usage of pinctrl_select_state apis > http://marc.info/?l=linux-netdev&m=137054250018667&w=2 > > Linus Walleij > > Please drop this patch series and take my other [atch set mentioned above > with David's Ack. Sure I didn't see David ACK the new versions explicitly but since they're even less intrusive I'll apply them assuming his ACK on these versions too... 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 2/4] pinctrl: single: Add hardware specific hooks for IRQ and GPIO wake-up events
* Haojian Zhuang [130608 21:51]: > > I assume that this patch is used in both v1 & v2 version. Since Manjunathappa > changed the logic of distinguishing bits and pins in blew. > > if (pcs->bits_per_mux) > mask = vals->mask; > else > mask = pcs->fmask > > Would you like to sync with his style? Thanks for catching that, yes that's how it should be now. Updated patch below. Regards, Tony From: Tony Lindgren Date: Sat, 8 Jun 2013 08:40:35 -0700 Subject: [PATCH] pinctrl: single: Add hardware specific hooks for IRQ and GPIO wake-up events At least on omaps, each board typically has at least one device configured as wake-up capable from deeper idle modes. In the deeper idle modes the normal interrupt wake-up path won't work as the logic is powered off and separate wake-up hardware is available either via IO ring or GPIO hardware. The wake-up event can be device specific, or may need to be dynamically remuxed to GPIO input for wake-up events. When the wake-up event happens, it's IRQ need to be called so the device won't lose interrupts. Allow supporting IRQ and GPIO wake-up events if a hardware spefific module is registered for the enable and disable calls. Done in collaboration with Roger Quadros . Cc: Haojian Zhuang Cc: Peter Ujfalusi Cc: devicetree-disc...@lists.ozlabs.org Signed-off-by: Roger Quadros Signed-off-by: Tony Lindgren diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt index 5a02e30..b95fa6c 100644 --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt @@ -69,6 +69,10 @@ Optional properties: The number of parameters is depend on #pinctrl-single,gpio-range-cells property. +- interrrupts : the interrupt that a function may have for a wake-up event + +- gpios: the gpio that a function may have for a wake-up event + /* pin base, nr pins & gpio function */ pinctrl-single,gpio-range = <&range 0 3 0 &range 3 9 1>; @@ -205,6 +209,7 @@ pmx_gpio: pinmux@d401e000 { 0xdc 0x118 0xde 0 >; + interrupts = <74>; }; }; diff --git a/drivers/pinctrl/pinctrl-single.c b/drivers/pinctrl/pinctrl-single.c index e3b1f76..72efc8e 100644 --- a/drivers/pinctrl/pinctrl-single.c +++ b/drivers/pinctrl/pinctrl-single.c @@ -19,6 +19,8 @@ #include #include #include +#include +#include #include #include @@ -95,6 +97,8 @@ struct pcs_conf_type { * @nvals: number of entries in vals array * @pgnames: array of pingroup names the function uses * @npgnames: number of pingroup names the function uses + * @irq: optional irq associated with the function + * @gpio: optional gpio associated with the function * @node: list node */ struct pcs_function { @@ -105,6 +109,8 @@ struct pcs_function { int npgnames; struct pcs_conf_vals *conf; int nconfs; + int irq; + int gpio; struct list_head node; }; @@ -411,6 +417,18 @@ static int pcs_get_function(struct pinctrl_dev *pctldev, unsigned pin, return 0; } +static void pcs_reg_init(struct pcs_reg *p, struct pcs_device *pcs, +struct pcs_function *func, +void __iomem *reg, unsigned val) +{ + p->read = pcs->read; + p->write = pcs->write; + p->irq = func->irq; + p->gpio = func->gpio; + p->reg = reg; + p->val = val; +} + static int pcs_enable(struct pinctrl_dev *pctldev, unsigned fselector, unsigned group) { @@ -444,6 +462,12 @@ static int pcs_enable(struct pinctrl_dev *pctldev, unsigned fselector, val &= ~mask; val |= (vals->val & mask); pcs->write(val, vals->reg); + if ((func->irq || func->gpio) && pcs->soc && pcs->soc->enable) { + struct pcs_reg pcsr; + + pcs_reg_init(&pcsr, pcs, func, vals->reg, val); + pcs->soc->enable(pcs->soc, &pcsr); + } } return 0; @@ -468,18 +492,6 @@ static void pcs_disable(struct pinctrl_dev *pctldev, unsigned fselector, return; } - /* -* Ignore disable if function-off is not specified. Some hardware -* does not have clearly defined disable function. For pin specific -* off modes, you can use alternate named states as described in -* pinctrl-bindings.txt. -*/ - if (pcs->foff == PCS_OFF_DISABLED) { - dev_dbg(pcs->dev, "ignoring disable for %s function%i\n", - func->name, fselector); - return; - } - dev_dbg(pcs->dev, "disabling function%i %s\n", fselector, func->name); @@ -490,8 +502,28 @@ static void pcs_disable(struct pinctrl_dev *pctldev, unsigned
Re: [PATCH 4/4] ARM: OMAP: Move DT wake-up event handling over to use pinctrl-single-omap
* Tony Lindgren [130607 13:58]: > * Tony Lindgren [130607 13:56]: > > Now pinctrl-single-omap can handle the wake-up events for us now > > as long as the events are configured in the .dts files. > > This patch I should queue separately, the rest should go via > the pinctrl tree. Here's this one updated to add stubs for the SoC specific reconfigure_io_chain functions when the SoC is not selected. Regards, Tony From: Tony Lindgren Date: Fri, 7 Jun 2013 11:39:58 -0700 Subject: [PATCH] ARM: OMAP: Move DT wake-up event handling over to use pinctrl-single-omap Now pinctrl-single-omap can handle the wake-up events for us now as long as the events are configured in the .dts files. Done in collaboration with Roger Quadros . Cc: Haojian Zhuang Cc: Peter Ujfalusi Cc: devicetree-disc...@lists.ozlabs.org Signed-off-by: Roger Quadros Signed-off-by: Tony Lindgren diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi index 99ba6e1..847af56 100644 --- a/arch/arm/boot/dts/omap3.dtsi +++ b/arch/arm/boot/dts/omap3.dtsi @@ -94,7 +94,7 @@ }; omap3_pmx_core: pinmux@48002030 { - compatible = "ti,omap3-padconf", "pinctrl-single"; + compatible = "ti,omap3-padconf"; reg = <0x48002030 0x05cc>; #address-cells = <1>; #size-cells = <0>; @@ -103,7 +103,7 @@ }; omap3_pmx_wkup: pinmux@0x48002a00 { - compatible = "ti,omap3-padconf", "pinctrl-single"; + compatible = "ti,omap3-padconf"; reg = <0x48002a00 0x5c>; #address-cells = <1>; #size-cells = <0>; diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi index 2a56428..2a4f099 100644 --- a/arch/arm/boot/dts/omap4.dtsi +++ b/arch/arm/boot/dts/omap4.dtsi @@ -107,7 +107,7 @@ }; omap4_pmx_core: pinmux@4a100040 { - compatible = "ti,omap4-padconf", "pinctrl-single"; + compatible = "ti,omap4-padconf"; reg = <0x4a100040 0x0196>; #address-cells = <1>; #size-cells = <0>; @@ -115,7 +115,7 @@ pinctrl-single,function-mask = <0x7fff>; }; omap4_pmx_wkup: pinmux@4a31e040 { - compatible = "ti,omap4-padconf", "pinctrl-single"; + compatible = "ti,omap4-padconf"; reg = <0x4a31e040 0x0038>; #address-cells = <1>; #size-cells = <0>; diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi index 3dd7ff8..5515d58 100644 --- a/arch/arm/boot/dts/omap5.dtsi +++ b/arch/arm/boot/dts/omap5.dtsi @@ -100,7 +100,7 @@ }; omap5_pmx_core: pinmux@4a002840 { - compatible = "ti,omap4-padconf", "pinctrl-single"; + compatible = "ti,omap4-padconf"; reg = <0x4a002840 0x01b6>; #address-cells = <1>; #size-cells = <0>; @@ -108,7 +108,7 @@ pinctrl-single,function-mask = <0x7fff>; }; omap5_pmx_wkup: pinmux@4ae0c840 { - compatible = "ti,omap4-padconf", "pinctrl-single"; + compatible = "ti,omap4-padconf"; reg = <0x4ae0c840 0x0038>; #address-cells = <1>; #size-cells = <0>; diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c index f82cf87..48094b58 100644 --- a/arch/arm/mach-omap2/mux.c +++ b/arch/arm/mach-omap2/mux.c @@ -811,6 +811,12 @@ int __init omap_mux_late_init(void) } } + omap_mux_dbg_init(); + + /* see pinctrl-single-omap for the wake-up interrupt handling */ + if (of_have_populated_dt()) + return 0; + ret = request_irq(omap_prcm_event_to_irq("io"), omap_hwmod_mux_handle_irq, IRQF_SHARED | IRQF_NO_SUSPEND, "hwmod_io", omap_mux_late_init); @@ -818,8 +824,6 @@ int __init omap_mux_late_init(void) if (ret) pr_warning("mux: Failed to setup hwmod io irq %d\n", ret); - omap_mux_dbg_init(); - return 0; } diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c index c018593..9b19b14 100644 --- a/arch/arm/mach-omap2/pm34xx.c +++ b/arch/arm/mach-omap2/pm34xx.c @@ -172,6 +172,8 @@ static int prcm_clear_mod_irqs(s16 module, u8 regs, u32 ignore_bits) wkst = omap2_prm_read_mod_reg(module, wkst_off); wkst &= ~ignore_bits; c++; + if (c > 10) + break;
Re: [PATCH 3/4] pinctrl: single: omap: Add SoC specific module for wake-up events
* Quadros, Roger [130610 03:09]: > + > +static int __init pcs_omap_init(void) > +{ > + platform_driver_register(&pcs_omap_soc_driver); > + platform_driver_register(&pcs_omap_driver); > + > + return 0; > +} > +module_init(pcs_omap_init); > > It seems this has to be moved to an earlier place (e.g. subsys_initcall) > else the pinctrl core fails to find the pinctrl device at the device creation > time and bails out with -EPROBE_DEFER. Also, that device is never > created again, so -EPROBE_DEFER doesn't seem to work there. Ah here, found your other comment :) That's not needed, the real fix is to make twl-core.c and friends to be regular module_init. There are already patches queued for 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] serial: omap: Fix device tree based PM runtime
In the runtime_suspend function pdata is not being used, and also blocks the function in device tree based booting. Fix it by removing the unused pdata from the runtime_suspend function. Further, context loss count is not being passed in pdata, so let's just reinitialize the port every time for those case. This can be further optimized later on for the device tree case by adding detection for the hardware state and possibly by adding a driver specific autosuspend timeout. And doing this, we can then make the related dev_err into a dev_dbg message instead of an error. In order for the wake-up events to work, we also need to set autosuspend_timeout to -1 if 0, and also device_init_wakeup() as that's not being done by the platform init code for the device tree case. Note that this does not affect legacy booting, and in fact might make it work for the cases where the context loss info is not being passed in pdata. Thanks to Kevin Hilman for debugging and suggesting fixes for the autosuspend_timeout and device_init_wakeup() related initializiation. Reviewed-by: Kevin Hilman Tested-by: Kevin Hilman Signed-off-by: Tony Lindgren --- Here's this one updated against Linux next. --- a/drivers/tty/serial/omap-serial.c +++ b/drivers/tty/serial/omap-serial.c @@ -198,7 +198,7 @@ static int serial_omap_get_context_loss_count(struct uart_omap_port *up) struct omap_uart_port_info *pdata = up->dev->platform_data; if (!pdata || !pdata->get_context_loss_count) - return 0; + return -EINVAL; return pdata->get_context_loss_count(up->dev); } @@ -1502,6 +1502,9 @@ static int serial_omap_probe(struct platform_device *pdev) platform_set_drvdata(pdev, up); pm_runtime_enable(&pdev->dev); + if (omap_up_info->autosuspend_timeout == 0) + omap_up_info->autosuspend_timeout = -1; + device_init_wakeup(up->dev, true); pm_runtime_use_autosuspend(&pdev->dev); pm_runtime_set_autosuspend_delay(&pdev->dev, omap_up_info->autosuspend_timeout); @@ -1611,7 +1614,6 @@ static void serial_omap_restore_context(struct uart_omap_port *up) static int serial_omap_runtime_suspend(struct device *dev) { struct uart_omap_port *up = dev_get_drvdata(dev); - struct omap_uart_port_info *pdata = dev->platform_data; if (!up) return -EINVAL; @@ -1626,9 +1628,6 @@ static int serial_omap_runtime_suspend(struct device *dev) uart_console(&up->port)) return -EBUSY; - if (!pdata) - return 0; - up->context_loss_cnt = serial_omap_get_context_loss_count(up); if (device_may_wakeup(dev)) { @@ -1656,7 +1655,7 @@ static int serial_omap_runtime_resume(struct device *dev) int loss_cnt = serial_omap_get_context_loss_count(up); if (loss_cnt < 0) { - dev_err(dev, "serial_omap_get_context_loss_count failed : %d\n", + dev_dbg(dev, "serial_omap_get_context_loss_count failed : %d\n", loss_cnt); serial_omap_restore_context(up); } else if (up->context_loss_cnt != loss_cnt) { -- 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: i2c issue on Panda with DT boot, v3.10-rc4
* Tomi Valkeinen [130610 02:35]: > On 07/06/13 21:36, Tony Lindgren wrote: > > > Maybe check that the i2c related pins are muxed properly for your board > > with pinctrl-single? > > Reading the bytes individually with i2cget works fine, so I think that > tells us that the pins are configured ok. Yes OK. Maybe there's some i2c driver errata that's not getting configured with the DT based boot? 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 4/4] ARM: OMAP: Move DT wake-up event handling over to use pinctrl-single-omap
* Quadros, Roger [130610 05:37]: > Hi Tony, (sorry, on Outlook web) > > - compatible = "ti,omap4-padconf", "pinctrl-single"; > + compatible = "ti,omap4-padconf"; > > This change is not necessary if we make sure the pinctrl-single-omap driver > gets registered early enough, before the pinctrl devices are probed. > (e.g. subsys_initcall()) I'd rather make everything just module_init, there should not be any need to tinker with the init call ordering any longer with deferred probe. And by making everything into regular device drivers we actually see real error messages without DEBUG_LL and earlyprintk if something goes wrong. Note that there are patches queued to make twl-core.c just regular module_init as well, so that should fix any issues you might be related it probing before pinctrl. > I've commented about this in the other patch. Sorry can you clarify, which other patch? The other message I saw in this thread was empty. Or at least I have not seen it yet. 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 14/14] ARM: OMAP4: hwmod data: Clean up the data file
* Tomi Valkeinen [130610 03:44]: > On 07/06/13 20:50, Tony Lindgren wrote: > > * Tony Lindgren [130607 09:35]: > >> * Paul Walmsley [130607 05:38]: > >>> On Fri, 7 Jun 2013, Sricharan R wrote: > >>> > - The IO resource information like dma request lines, irq number and > ocp address space can be populated via dt blob. So such data is > stripped > from OMAP4 SOC hwmod data file. > > - The devices which are still missing the device tree bindings, > address space entries are not removed yet. When such devices add > the dt bindings, respective address space data can be deleted. > > - Also other unnecessary hwmods like firewalls are removed as a part of > this. > Since emif was getting registered only because of this firewalls links, > the mpu->emif direct link is added now. > > The above update, results in reduction of about ~1650 lines of code. > > Signed-off-by: Santosh Shilimkar > Signed-off-by: Sricharan R > >>> > >>> Acked-by: Paul Walmsley > >>> > >>> Can't test this one since I don't have an OMAP4 DT config set up in the > >>> testbed > >>> yet. Maybe will add that to the testbed after the v3.10 release. > >> > >> OK thanks, applying into omap-for-v3.11/cleanup. > > > > I had to undo the following parts to avoid regressions on omap4sdp. > > Can you please follow up on fixing the related issues so the fixup > > won't be needed? > > > > Seems to work now the same way as earlier for both omap4sdp and blaze > > es, except for DSS, which seems to be a separate issue as posted by > > Tomi. Pushed out now to omap-for-v3.11/cleanup. > > What issue do you refer to? > > DSS does not have DT bindings, and removing DSS from hwmod data will > break DSS for omap4. Ah that's right. Care to post a patch reverting the minimal parts that you need for omap4 against omap-for-v3.11/cleanup? 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: OMAP v3.10-rc regressions that no one's fixed
Hi Paul, On Monday 10 June 2013 12:52 PM, Paul Walmsley wrote: Hi folks -- particularly TIers working on mainline, There are several regressions that started with v3.10-rc that no one's fixed for over a month. Some of them should be quite easy: * 37xx EVM: boot fails - as of v3.10-rc1 - Cause unknown * 2420N800, 2430sdp: failed to get counter_32k resource - "omap2_sync32k_clocksource_init: failed to get counter_32k resource" - Cause unknown * 2430SDP, 3730 Beagle XM, 3530 Beagle, 3517EVM, CM-T3517: {dmic,mcpdm} lookup failure - Cause unknown - These IP blocks don't exist on OMAP3xxx/AM35xx chips * 3730 Beagle XM, am335xbone, CM-T3517: uart4_rx.uart4_rx mux failure Just booted up my BeagleBone. I didn't see any error for uart4_rx in my boot log. Since I don't have other boards, I wanted to reproduce this on my BeagelBone. Please let me know if I am missing something. Thanks and regards, Lokesh - Cause unknown (For more details, see the logs at the link below.) It would be good if people could step up to fix these before v3.10 comes out. - Paul -- Forwarded message -- Date: Mon, 10 Jun 2013 02:00:50 + (UTC) From: Paul Walmsley To: linux-omap@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Subject: OMAP baseline test results for v3.10-rc5 Here are some basic OMAP test results for Linux v3.10-rc5. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v3.10-rc5/20130609031534/ Test summary Build: uImage: Pass (16/16): am33xx_only, n800_multi_omap2xxx, n800_only_a, omap1_defconfig, omap1_defconfig_1510innovator_only, omap1_defconfig_5912osk_only, omap2plus_defconfig, omap2plus_defconfig_2430sdp_only omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm, omap2plus_defconfig_omap2_4_only, omap2plus_defconfig_omap3_4_only, rmk_omap3430_ldp_allnoconfig, rmk_omap3430_ldp_oldconfig, rmk_omap4430_sdp_allnoconfig, rmk_omap4430_sdp_oldconfig Build: zImage: Pass ( 1/ 1): omap2plus_defconfig Boot to userspace: FAIL ( 3/12): 37xxevm, am335xbone, am335xbonelt Pass ( 9/12): 2420n800, 2430sdp, 3517evm, 3530es3beagle, 3730beaglexm, 4430es2panda, 4460pandaes, 5912osk, cmt3517 PM: chip retention via suspend: FAIL ( 3/ 6): 2430sdp, 37xxevm, 4430es2panda Pass ( 3/ 6): 3530es3beagle, 3730beaglexm, 4460pandaes PM: chip retention via dynamic idle: FAIL ( 4/ 6): 2430sdp, 37xxevm, 4430es2panda, 4460pandaes Pass ( 2/ 6): 3530es3beagle, 3730beaglexm PM: chip off except CORE via suspend: Pass ( 1/ 1): 3730beaglexm PM: chip off except CORE via dynamic idle: Pass ( 1/ 1): 3730beaglexm PM: chip off via suspend: FAIL ( 3/ 4): 37xxevm, 4430es2panda, 4460pandaes Pass ( 1/ 4): 3530es3beagle PM: chip off via dynamic idle: FAIL ( 3/ 4): 37xxevm, 4430es2panda, 4460pandaes Pass ( 1/ 4): 3530es3beagle Failing tests: fixed by posted patches -- (none) Failing tests: needing investigation Boot tests: * 3517EVM & CM-T3517: boot hangs with NFS root - Likely some Kconfig, board file, and PM issues with EMAC - Longstanding bug - Not currently part of the automated test suite * 37xx EVM: boot fails - as of v3.10-rc1 - Cause unknown Boot warnings: * 2420N800, 2430sdp: failed to get counter_32k resource - "omap2_sync32k_clocksource_init: failed to get counter_32k resource" - Cause unknown * CM-T3517: L3 in-band error with IPSS during boot - Cause unknown but see http://marc.info/?l=linux-omap&m=134833869730129&w=2 - Longstanding issue; does not occur on the 3517EVM * 2430SDP, 3730 Beagle XM, 3530 Beagle, 3517EVM, CM-T3517: {dmic,mcpdm} lookup failure - Cause unknown - These IP blocks don't exist on OMAP3xxx/AM35xx chips * 3730 Beagle XM, am335xbone, CM-T3517: uart4_rx.uart4_rx mux failure - Cause unknown PM tests: * 2430sdp: power domains not entering retention - Cause unknown * 3730 Beagle XM: does not serial wake from off-idle suspend when console UART doesn't clock-gate ("debug ignore_loglevel") - Cause unknown - Not yet part of the automated test suite - Re-tested at v3.7; still failing: http://www.pwsan.com/omap/transcripts/20121211-3730beaglexm-3.7-pm-offmode-fail-debug.txt * 4430es2panda: pwrdm state mismatch on CAM, DSS * 4430es2panda: CORE, TESLA, IVAHD, L3INIT didn't enter target state - Probably due to lack of reset code for M3, DSP, SL2IF, FSUSB per discussion with Tero Kristo - Likely dependent on the bootloader version - fails with 2012.07-00136-g755de79 - http://marc.info/?l=linux-arm-kernel&m=136432340618226&w=2 * 4430es2panda: MPU, ABE didn't enter target state - New fo
Re: [PATCH 13/14] ARM: AM33XX: hwmod data: irq, dma and addr info clean up
Hi Paul, On Monday 10 June 2013 02:05 PM, Lokesh Vutla wrote: Hi Kevin, On Friday 07 June 2013 03:57 AM, Kevin Hilman wrote: Paul Walmsley writes: On Wed, 29 May 2013, Santosh Shilimkar wrote: From: Vaibhav Hiremath AM33XX only supports DT boot mode and with addition of extracting module resources like, irq, dma and address space from DT block, so now we can remove duplicate information from hwmod data file. OK, guess I'll take your word for it that it all works. The BeagleBone-white with appended DTB hasn't booted here since v3.7. And the BeagleBone-black with discrete DTB doesn't boot at all with current mainline, only with the TI vendor kernel & DTB... Anyone care to shed light on what's missing for BeagleBone boot with mainline currently? I have tested BeagleBone boot with today's mainline bootloader and kernel. It boots perfectly fine. I have taken the boot log for BeagleBone from the folllowing site: http://www.pwsan.com/omap/testlogs/test_v3.10-rc5/20130609031534/boot/am335xbone/ I have reset to your U-Boot commit id and took latest mainline kernel. It boots fine in my setup. You can find the logs here: http://pastebin.com/ggVYs3RG Thanks and regards, Lokesh Thanks and regards, Lokesh I've also not been able to boot a mainline kernel on the BeagleBone for some time. 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 -- 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 -- 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 4/4] ARM: OMAP: Move DT wake-up event handling over to use pinctrl-single-omap
Hi Tony, (sorry, on Outlook web) - compatible = "ti,omap4-padconf", "pinctrl-single"; + compatible = "ti,omap4-padconf"; This change is not necessary if we make sure the pinctrl-single-omap driver gets registered early enough, before the pinctrl devices are probed. (e.g. subsys_initcall()) I've commented about this in the other patch. cheers, -roger Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki From: Tony Lindgren [t...@atomide.com] Sent: Friday, June 07, 2013 11:50 PM To: linus.wall...@linaro.org Cc: devicetree-disc...@lists.ozlabs.org; Haojian Zhuang; Ujfalusi, Peter; linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Quadros, Roger Subject: [PATCH 4/4] ARM: OMAP: Move DT wake-up event handling over to use pinctrl-single-omap Now pinctrl-single-omap can handle the wake-up events for us now as long as the events are configured in the .dts files. Done in collaboration with Roger Quadros . Cc: Haojian Zhuang Cc: Peter Ujfalusi Cc: devicetree-disc...@lists.ozlabs.org Signed-off-by: Roger Quadros Signed-off-by: Tony Lindgren --- arch/arm/boot/dts/omap3.dtsi |4 ++-- arch/arm/boot/dts/omap4.dtsi |4 ++-- arch/arm/boot/dts/omap5.dtsi |4 ++-- arch/arm/mach-omap2/mux.c|8 ++-- arch/arm/mach-omap2/pm34xx.c |2 ++ arch/arm/mach-omap2/prm_common.c | 26 ++ 6 files changed, 40 insertions(+), 8 deletions(-) diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi index 99ba6e1..847af56 100644 --- a/arch/arm/boot/dts/omap3.dtsi +++ b/arch/arm/boot/dts/omap3.dtsi @@ -94,7 +94,7 @@ }; omap3_pmx_core: pinmux@48002030 { - compatible = "ti,omap3-padconf", "pinctrl-single"; + compatible = "ti,omap3-padconf"; reg = <0x48002030 0x05cc>; #address-cells = <1>; #size-cells = <0>; @@ -103,7 +103,7 @@ }; omap3_pmx_wkup: pinmux@0x48002a00 { - compatible = "ti,omap3-padconf", "pinctrl-single"; + compatible = "ti,omap3-padconf"; reg = <0x48002a00 0x5c>; #address-cells = <1>; #size-cells = <0>; diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi index 2a56428..2a4f099 100644 --- a/arch/arm/boot/dts/omap4.dtsi +++ b/arch/arm/boot/dts/omap4.dtsi @@ -107,7 +107,7 @@ }; omap4_pmx_core: pinmux@4a100040 { - compatible = "ti,omap4-padconf", "pinctrl-single"; + compatible = "ti,omap4-padconf"; reg = <0x4a100040 0x0196>; #address-cells = <1>; #size-cells = <0>; @@ -115,7 +115,7 @@ pinctrl-single,function-mask = <0x7fff>; }; omap4_pmx_wkup: pinmux@4a31e040 { - compatible = "ti,omap4-padconf", "pinctrl-single"; + compatible = "ti,omap4-padconf"; reg = <0x4a31e040 0x0038>; #address-cells = <1>; #size-cells = <0>; diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi index 3dd7ff8..5515d58 100644 --- a/arch/arm/boot/dts/omap5.dtsi +++ b/arch/arm/boot/dts/omap5.dtsi @@ -100,7 +100,7 @@ }; omap5_pmx_core: pinmux@4a002840 { - compatible = "ti,omap4-padconf", "pinctrl-single"; + compatible = "ti,omap4-padconf"; reg = <0x4a002840 0x01b6>; #address-cells = <1>; #size-cells = <0>; @@ -108,7 +108,7 @@ pinctrl-single,function-mask = <0x7fff>; }; omap5_pmx_wkup: pinmux@4ae0c840 { - compatible = "ti,omap4-padconf", "pinctrl-single"; + compatible = "ti,omap4-padconf"; reg = <0x4ae0c840 0x0038>; #address-cells = <1>; #size-cells = <0>; diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c index f82cf87..48094b58 100644 --- a/arch/arm/mach-omap2/mux.c +++ b/arch/arm/mach-omap2/mux.c @@ -811,6 +811,12 @@ int __init omap_mux_late_init(void) } } + omap_mux_dbg_init(); + + /* see pinctrl-single-omap for the wake-up interrupt handling */ + if (of_have_populated_dt()) + return 0; + ret = request_irq(omap_prcm_event_to_irq("io"), omap_hwmod_mux_handle_irq, IRQF_SHARED | IRQF_NO_SUSPEND, "hwmod_io", omap_mu
Re: [PATCH V2 14/14] ARM: OMAP4: hwmod data: Clean up the data file
On 07/06/13 20:50, Tony Lindgren wrote: > * Tony Lindgren [130607 09:35]: >> * Paul Walmsley [130607 05:38]: >>> On Fri, 7 Jun 2013, Sricharan R wrote: >>> - The IO resource information like dma request lines, irq number and ocp address space can be populated via dt blob. So such data is stripped from OMAP4 SOC hwmod data file. - The devices which are still missing the device tree bindings, address space entries are not removed yet. When such devices add the dt bindings, respective address space data can be deleted. - Also other unnecessary hwmods like firewalls are removed as a part of this. Since emif was getting registered only because of this firewalls links, the mpu->emif direct link is added now. The above update, results in reduction of about ~1650 lines of code. Signed-off-by: Santosh Shilimkar Signed-off-by: Sricharan R >>> >>> Acked-by: Paul Walmsley >>> >>> Can't test this one since I don't have an OMAP4 DT config set up in the >>> testbed >>> yet. Maybe will add that to the testbed after the v3.10 release. >> >> OK thanks, applying into omap-for-v3.11/cleanup. > > I had to undo the following parts to avoid regressions on omap4sdp. > Can you please follow up on fixing the related issues so the fixup > won't be needed? > > Seems to work now the same way as earlier for both omap4sdp and blaze > es, except for DSS, which seems to be a separate issue as posted by > Tomi. Pushed out now to omap-for-v3.11/cleanup. What issue do you refer to? DSS does not have DT bindings, and removing DSS from hwmod data will break DSS for omap4. Tomi signature.asc Description: OpenPGP digital signature
Re: [RFC PATCH 1/4] regulator: Introduce OMAP regulator to control PMIC over VC/VP
On Wed, May 22, 2013 at 01:18:34PM -0500, Nishanth Menon wrote: So, the biggest problem here has been patch 4 (having to have a hack to deploy this stuff is a bit worrying) plus the general not having a real driver thing. > +- ti,i2c-slave-address - I2C slave address of the PMIC > +- ti,i2c-voltage-register - I2C register address where voltage commands are > + to be set. > +- ti,i2c-command-register - I2C register address where commands are to be set > + when OMAP enters low power state. This may be the same as > + ti,i2c-voltage-register depending on the PMIC. > +- ti,slew-rate-microvolt - worst case slew rate of rise / fall for voltage > + transition in microvolts per microseconds (uV/uS) > +- step-size-micro-volts - Step size in micovolts as to what one step in > voltage > + selector increment translates to. See example. > +- regulator-min-microvolt - Minimum voltage in microvolts which is supported > by > + the PMIC in ti,step-size-microvolt increments. See example. > +- regulator-max-microvolt - Maximum voltage in microvolts which is supported > + by the PMIC in ti,step-size-microvolt increments. See example. The other thing is this whole business of encoding the properties of the PMIC in the DT like this. Paul Walmsley has started doing some work for some similiar hardware where instead of doing this the regulator is in the DT as normal and then the driver for the offloaded voltage scaling gets the information about the register layout from the regulator driver. This is a bit neater overall and would cope with determining which method to use at runtime. signature.asc Description: Digital signature
RE: [PATCH] ARM: dts: add dtsi for palmas
Hi Benoit, > -Original Message- > From: Cousson, Benoit > Sent: Monday, June 10, 2013 3:00 PM > To: J, KEERTHY > Cc: Stephen Warren; devicetree-disc...@lists.ozlabs.org; linux- > o...@vger.kernel.org; linux-ker...@vger.kernel.org; > ldewan...@nvidia.com; grant.lik...@secretlab.ca; swar...@nvidia.com; > sa...@linux.intel.com; g...@slimlogic.co.uk; lee.jo...@linaro.org > Subject: Re: [PATCH] ARM: dts: add dtsi for palmas > > Hi Keerthy, > > On 06/10/2013 06:03 AM, J, KEERTHY wrote: > > Hi Stephen, > > > > Thanks for the review comments. > > > > > > From: Stephen Warren [swar...@wwwdotorg.org] > > Sent: Saturday, June 08, 2013 1:26 AM > > To: J, KEERTHY > > Cc: Cousson, Benoit; devicetree-disc...@lists.ozlabs.org; > > linux-omap@vger.kernel.org; linux-ker...@vger.kernel.org; > > ldewan...@nvidia.com; grant.lik...@secretlab.ca; swar...@nvidia.com; > > sa...@linux.intel.com; g...@slimlogic.co.uk; lee.jo...@linaro.org > > Subject: Re: [PATCH] ARM: dts: add dtsi for palmas > > > > On 06/07/2013 05:28 AM, J Keerthy wrote: > >> Adds palmas mfd and palmas regulator nodes. This is based on the > >> patch series: > >> > >> http://www.mail-archive.com/linux-omap@vger.kernel.org/msg89957.html > >> > >> The device tree nodes are based on: > >> https://lkml.org/lkml/2013/6/6/25 > > > >> diff --git a/arch/arm/boot/dts/palmas.dtsi > >> b/arch/arm/boot/dts/palmas.dtsi > > > >> +&palmas { > > > > Hmmm. That (i.e. requiring the board file to declare the node, then > > setting up all the content by later including this file) is an > > interesting approach. I guess it's reasonable. The one issue is that > > it makes it a little harder for the board file to override any of the > > properties in this file., although it certainly is possible by > > including those overrides after the include. > > > > Irrespective of that, some comments on this: > > > >> + palmas_pmic { > > > >> + ti,ldo6-vibrator; > > > > For example, what if the board doesn't want to have the property set? > > > >> + > >> + regulators { > >> + smps123_reg: smps123 { > >> + regulator-name = "smps123"; > >> + regulator-min-microvolt = < 60>; > >> + regulator-max-microvolt = <150>; > > > > Or what if the board wants to limit the voltage range of this > > regulator due to what it's used for on the board. > > > >> + regulator-always-on; > >> + regulator-boot-on; > > > > And those two properties are almost certainly board-specific policy. > > > > Totally agree to all the above concerns. So can we have a custom > .dtsi > > file for a board+pmic combination? Or have only the required > > properties over ridden in the board file? > > Yes, you can do that potentially if most OMAP5 boards will reuse the > same kind of settings. Kevin has just done that for OMAP3 + twl4030. > > In this case, since we do have only one board, I'm not sure it worth > the effort. I sent a V2 with only the most generic property in palmas.dtsi and the Configurable parameter under the board file. Let me know if that patch set Is fine. > > Regards, > Benoit 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 v2 2/2] ARM: dts: OMAP5: add palmas node and omap specific palmas regulator properties
Hello Lee jones, > -Original Message- > From: Lee Jones [mailto:lee.jo...@linaro.org] > Sent: Monday, June 10, 2013 3:36 PM > To: J, KEERTHY > Cc: Cousson, Benoit; devicetree-disc...@lists.ozlabs.org; linux- > o...@vger.kernel.org; linux-ker...@vger.kernel.org; > ldewan...@nvidia.com; grant.lik...@secretlab.ca; swar...@wwwdotorg.org; > swar...@nvidia.com; sa...@linux.intel.com; g...@slimlogic.co.uk > Subject: Re: [PATCH v2 2/2] ARM: dts: OMAP5: add palmas node and omap > specific palmas regulator properties > > On Mon, 10 Jun 2013, J Keerthy wrote: > > > Add palmas node and omap specific palmas regulator properties. > > > > Signed-off-by: J Keerthy > > --- > > arch/arm/boot/dts/omap5-uevm.dts | 147 > > ++ > > 1 files changed, 147 insertions(+), 0 deletions(-) > > > > diff --git a/arch/arm/boot/dts/omap5-uevm.dts > > b/arch/arm/boot/dts/omap5-uevm.dts > > index 927db1e..ffbcc3f 100644 > > --- a/arch/arm/boot/dts/omap5-uevm.dts > > +++ b/arch/arm/boot/dts/omap5-uevm.dts > > @@ -8,6 +8,8 @@ > > /dts-v1/; > > > > #include "omap5.dtsi" > > +#include > > +#include > > > > / { > > model = "TI OMAP5 uEVM board"; > > @@ -254,6 +256,151 @@ > > pinctrl-0 = <&i2c1_pins>; > > > > clock-frequency = <40>; > > + > > + palmas: palmas@48 { > > + reg = <0x48>; > > + /* SPI = 0, IRQ# = 7, active high level-sensitive */ > > I still think this is superfluous, especially now you're using the > defines which basically say the same thing. I retained the whole comment as it was needed to specify IRQ# as 7 And thought it completely described the below interrupt property. I can knock it off if it is totally unnecessary. If there are no further comments. Can I add a Reviewed-by? > > > + interrupts = ; /* IRQ_SYS_1N > */ > > + interrupt-parent = <&gic>; > > + }; > > + > > +}; > > + > > +#include "palmas.dtsi" > > + > > +&palmas { > > + palmas_pmic { > > + ti,ldo6-vibrator; > > + > > + regulators { > > + smps123_reg: smps123 { > > + regulator-min-microvolt = < 60>; > > + regulator-max-microvolt = <150>; > > + regulator-always-on; > > + regulator-boot-on; > > + }; > > + > > + smps45_reg: smps45 { > > + regulator-min-microvolt = < 60>; > > + regulator-max-microvolt = <131>; > > + regulator-always-on; > > + regulator-boot-on; > > + }; > > + > > + smps6_reg: smps6 { > > + regulator-min-microvolt = <120>; > > + regulator-max-microvolt = <120>; > > + regulator-always-on; > > + regulator-boot-on; > > + }; > > + > > + smps7_reg: smps7 { > > + regulator-min-microvolt = <180>; > > + regulator-max-microvolt = <180>; > > + regulator-always-on; > > + regulator-boot-on; > > + }; > > + > > + smps8_reg: smps8 { > > + regulator-min-microvolt = < 60>; > > + regulator-max-microvolt = <131>; > > + regulator-always-on; > > + regulator-boot-on; > > + }; > > + > > + smps9_reg: smps9 { > > + regulator-min-microvolt = <210>; > > + regulator-max-microvolt = <210>; > > + regulator-always-on; > > + regulator-boot-on; > > + ti,smps-range = <0x80>; > > + }; > > + > > + smps10_reg: smps10 { > > + regulator-min-microvolt = <500>; > > + regulator-max-microvolt = <500>; > > + regulator-always-on; > > + regulator-boot-on; > > + }; > > + > > + ldo1_reg: ldo1 { > > + regulator-min-microvolt = <280>; > > + regulator-max-microvolt = <280>; > > + regulator-always-on; > > + regulator-boot-on; > > + }; > > + > > + ldo2_reg: ldo2 { > > + regulator-min-microvolt = <290>; > > + regulator-max-microvolt = <290>; > > + regulator-always-on; > > + regulator-boot-on; > > + }; > > + > > + ldo3_reg
Re: [PATCH v2 2/2] ARM: dts: OMAP5: add palmas node and omap specific palmas regulator properties
On Mon, 10 Jun 2013, J Keerthy wrote: > Add palmas node and omap specific palmas regulator properties. > > Signed-off-by: J Keerthy > --- > arch/arm/boot/dts/omap5-uevm.dts | 147 > ++ > 1 files changed, 147 insertions(+), 0 deletions(-) > > diff --git a/arch/arm/boot/dts/omap5-uevm.dts > b/arch/arm/boot/dts/omap5-uevm.dts > index 927db1e..ffbcc3f 100644 > --- a/arch/arm/boot/dts/omap5-uevm.dts > +++ b/arch/arm/boot/dts/omap5-uevm.dts > @@ -8,6 +8,8 @@ > /dts-v1/; > > #include "omap5.dtsi" > +#include > +#include > > / { > model = "TI OMAP5 uEVM board"; > @@ -254,6 +256,151 @@ > pinctrl-0 = <&i2c1_pins>; > > clock-frequency = <40>; > + > + palmas: palmas@48 { > + reg = <0x48>; > + /* SPI = 0, IRQ# = 7, active high level-sensitive */ I still think this is superfluous, especially now you're using the defines which basically say the same thing. > + interrupts = ; /* IRQ_SYS_1N */ > + interrupt-parent = <&gic>; > + }; > + > +}; > + > +#include "palmas.dtsi" > + > +&palmas { > + palmas_pmic { > + ti,ldo6-vibrator; > + > + regulators { > + smps123_reg: smps123 { > + regulator-min-microvolt = < 60>; > + regulator-max-microvolt = <150>; > + regulator-always-on; > + regulator-boot-on; > + }; > + > + smps45_reg: smps45 { > + regulator-min-microvolt = < 60>; > + regulator-max-microvolt = <131>; > + regulator-always-on; > + regulator-boot-on; > + }; > + > + smps6_reg: smps6 { > + regulator-min-microvolt = <120>; > + regulator-max-microvolt = <120>; > + regulator-always-on; > + regulator-boot-on; > + }; > + > + smps7_reg: smps7 { > + regulator-min-microvolt = <180>; > + regulator-max-microvolt = <180>; > + regulator-always-on; > + regulator-boot-on; > + }; > + > + smps8_reg: smps8 { > + regulator-min-microvolt = < 60>; > + regulator-max-microvolt = <131>; > + regulator-always-on; > + regulator-boot-on; > + }; > + > + smps9_reg: smps9 { > + regulator-min-microvolt = <210>; > + regulator-max-microvolt = <210>; > + regulator-always-on; > + regulator-boot-on; > + ti,smps-range = <0x80>; > + }; > + > + smps10_reg: smps10 { > + regulator-min-microvolt = <500>; > + regulator-max-microvolt = <500>; > + regulator-always-on; > + regulator-boot-on; > + }; > + > + ldo1_reg: ldo1 { > + regulator-min-microvolt = <280>; > + regulator-max-microvolt = <280>; > + regulator-always-on; > + regulator-boot-on; > + }; > + > + ldo2_reg: ldo2 { > + regulator-min-microvolt = <290>; > + regulator-max-microvolt = <290>; > + regulator-always-on; > + regulator-boot-on; > + }; > + > + ldo3_reg: ldo3 { > + regulator-min-microvolt = <300>; > + regulator-max-microvolt = <300>; > + regulator-always-on; > + regulator-boot-on; > + }; > + > + ldo4_reg: ldo4 { > + regulator-min-microvolt = <220>; > + regulator-max-microvolt = <220>; > + regulator-always-on; > + regulator-boot-on; > + }; > + > + ldo5_reg: ldo5 { > + regulator-min-microvolt = <180>; > + regulator-max-microvolt = <180>; > + regulator-always-on; > +
RE: [PATCH 3/4] pinctrl: single: omap: Add SoC specific module for wake-up events
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki From: Tony Lindgren [t...@atomide.com] Sent: Friday, June 07, 2013 11:50 PM To: linus.wall...@linaro.org Cc: devicetree-disc...@lists.ozlabs.org; Haojian Zhuang; Ujfalusi, Peter; linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Quadros, Roger Subject: [PATCH 3/4] pinctrl: single: omap: Add SoC specific module for wake-up events For wake-up events from deeper idle modes we need to check the configured padconf registers for the wake-up bit and then call the related interrupt handler. Done in collaboration with Roger Quadros . Cc: Haojian Zhuang Cc: Peter Ujfalusi Cc: devicetree-disc...@lists.ozlabs.org Signed-off-by: Roger Quadros Signed-off-by: Tony Lindgren --- drivers/pinctrl/Makefile |3 drivers/pinctrl/pinctrl-single-omap.c | 287 + include/linux/platform_data/pinctrl-single-omap.h |4 3 files changed, 293 insertions(+), 1 deletion(-) create mode 100644 drivers/pinctrl/pinctrl-single-omap.c create mode 100644 include/linux/platform_data/pinctrl-single-omap.h diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile index 9bdaeb8..abf7f01 100644 --- a/drivers/pinctrl/Makefile +++ b/drivers/pinctrl/Makefile @@ -30,7 +30,8 @@ obj-$(CONFIG_PINCTRL_NOMADIK) += pinctrl-nomadik.o obj-$(CONFIG_PINCTRL_STN8815) += pinctrl-nomadik-stn8815.o obj-$(CONFIG_PINCTRL_DB8500) += pinctrl-nomadik-db8500.o obj-$(CONFIG_PINCTRL_DB8540) += pinctrl-nomadik-db8540.o -obj-$(CONFIG_PINCTRL_SINGLE) += pinctrl-single.o +pcs-$(CONFIG_ARCH_OMAP2PLUS) += pinctrl-single-omap.o +obj-$(CONFIG_PINCTRL_SINGLE) += pinctrl-single.o $(pcs-y) obj-$(CONFIG_PINCTRL_SIRF) += pinctrl-sirf.o obj-$(CONFIG_PINCTRL_SUNXI)+= pinctrl-sunxi.o obj-$(CONFIG_PINCTRL_TEGRA)+= pinctrl-tegra.o diff --git a/drivers/pinctrl/pinctrl-single-omap.c b/drivers/pinctrl/pinctrl-single-omap.c new file mode 100644 index 000..680cf81 --- /dev/null +++ b/drivers/pinctrl/pinctrl-single-omap.c @@ -0,0 +1,287 @@ +/* + * pinctrl-single-omap - omap specific wake-up irq handler + * + * 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 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. + * + */ + +static int __init pcs_omap_init(void) +{ + platform_driver_register(&pcs_omap_soc_driver); + platform_driver_register(&pcs_omap_driver); + + return 0; +} +module_init(pcs_omap_init); It seems this has to be moved to an earlier place (e.g. subsys_initcall) else the pinctrl core fails to find the pinctrl device at the device creation time and bails out with -EPROBE_DEFER. Also, that device is never created again, so -EPROBE_DEFER doesn't seem to work there. The code i'm talking about is in dt_to_map_one_config() http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/pinctrl/devicetree.c#n109 + +static void __exit pcs_omap_exit(void) +{ + platform_driver_unregister(&pcs_omap_driver); + platform_driver_unregister(&pcs_omap_soc_driver); +} +module_exit(pcs_omap_exit); + +MODULE_ALIAS("platform: pinctrl-single-omap"); +MODULE_AUTHOR("Texas Instruments Inc."); +MODULE_DESCRIPTION("pinctrl-single-omap driver"); +MODULE_LICENSE("GPL v2"); diff --git a/include/linux/platform_data/pinctrl-single-omap.h b/include/linux/platform_data/pinctrl-single-omap.h new file mode 100644 index 000..bd92efc --- /dev/null +++ b/include/linux/platform_data/pinctrl-single-omap.h @@ -0,0 +1,4 @@ +struct pcs_omap_pdata { + int irq; + void (*reconfigure_io_chain)(void); +}; -- 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: add dtsi for palmas
Hi Keerthy, On 06/10/2013 06:03 AM, J, KEERTHY wrote: > Hi Stephen, > > Thanks for the review comments. > > > From: Stephen Warren [swar...@wwwdotorg.org] > Sent: Saturday, June 08, 2013 1:26 AM > To: J, KEERTHY > Cc: Cousson, Benoit; devicetree-disc...@lists.ozlabs.org; > linux-omap@vger.kernel.org; linux-ker...@vger.kernel.org; > ldewan...@nvidia.com; grant.lik...@secretlab.ca; swar...@nvidia.com; > sa...@linux.intel.com; g...@slimlogic.co.uk; lee.jo...@linaro.org > Subject: Re: [PATCH] ARM: dts: add dtsi for palmas > > On 06/07/2013 05:28 AM, J Keerthy wrote: >> Adds palmas mfd and palmas regulator nodes. This is >> based on the patch series: >> >> http://www.mail-archive.com/linux-omap@vger.kernel.org/msg89957.html >> >> The device tree nodes are based on: >> https://lkml.org/lkml/2013/6/6/25 > >> diff --git a/arch/arm/boot/dts/palmas.dtsi b/arch/arm/boot/dts/palmas.dtsi > >> +&palmas { > > Hmmm. That (i.e. requiring the board file to declare the node, then > setting up all the content by later including this file) is an > interesting approach. I guess it's reasonable. The one issue is that it > makes it a little harder for the board file to override any of the > properties in this file., although it certainly is possible by including > those overrides after the include. > > Irrespective of that, some comments on this: > >> + palmas_pmic { > >> + ti,ldo6-vibrator; > > For example, what if the board doesn't want to have the property set? > >> + >> + regulators { >> + smps123_reg: smps123 { >> + regulator-name = "smps123"; >> + regulator-min-microvolt = < 60>; >> + regulator-max-microvolt = <150>; > > Or what if the board wants to limit the voltage range of this regulator > due to what it's used for on the board. > >> + regulator-always-on; >> + regulator-boot-on; > > And those two properties are almost certainly board-specific policy. > > Totally agree to all the above concerns. So can we have a custom .dtsi file > for a board+pmic combination? Or have only the required properties over ridden > in the board file? Yes, you can do that potentially if most OMAP5 boards will reuse the same kind of settings. Kevin has just done that for OMAP3 + twl4030. In this case, since we do have only one board, I'm not sure it worth the effort. 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: i2c issue on Panda with DT boot, v3.10-rc4
On 07/06/13 21:36, Tony Lindgren wrote: > Maybe check that the i2c related pins are muxed properly for your board > with pinctrl-single? Reading the bytes individually with i2cget works fine, so I think that tells us that the pins are configured ok. Tomi signature.asc Description: OpenPGP digital signature
Re: i2c issue on Panda with DT boot, v3.10-rc4
On 07/06/13 21:39, Felipe Balbi wrote: > sounds like there's something left in FIFO which is not getting read > out, then we end up timing out. > > Can you try the patch below ? It's patch of a bigger patchset which I > still need to clean a few things up, but they should be very close to > being ready. IIRC, one of the patches creates a problem for N900 (only) > which gets fixed later, I just need to combine those two patches into > one to avoid the regression. > > diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c > index aa3b91e..471b434 100644 > --- a/drivers/i2c/busses/i2c-omap.c > +++ b/drivers/i2c/busses/i2c-omap.c > @@ -1022,9 +1022,8 @@ omap_i2c_isr_thread(int this_irq, void *dev_id) > } > } while (stat); > > - omap_i2c_complete_cmd(dev, err); > - > out: > + omap_i2c_complete_cmd(dev, err); > spin_unlock_irqrestore(&dev->lock, flags); > > return IRQ_HANDLED; > With this change the boot becomes unreliable: [3.024322] V2V1: 2100 mV [4.049530] omap_i2c 4807.i2c: timeout waiting for bus ready [5.059417] omap_i2c 4807.i2c: timeout waiting for bus ready [5.059448] twl: Write failed (mod 9, reg 0xe5 count 1) and this continues. I did manage to boot once, and running i2cdump printed each byte very slowly, and with 0xff as the data. Tomi signature.asc Description: OpenPGP digital signature
RE: [PATCH v2 1/2] ARM: dts: add dtsi for palmas
Hi Laxman, > -Original Message- > From: Laxman Dewangan [mailto:ldewan...@nvidia.com] > Sent: Monday, June 10, 2013 2:55 PM > To: J, KEERTHY > Cc: Cousson, Benoit; devicetree-disc...@lists.ozlabs.org; linux- > o...@vger.kernel.org; linux-ker...@vger.kernel.org; > grant.lik...@secretlab.ca; swar...@wwwdotorg.org; Stephen Warren; > sa...@linux.intel.com; g...@slimlogic.co.uk; lee.jo...@linaro.org > Subject: Re: [PATCH v2 1/2] ARM: dts: add dtsi for palmas > > On Monday 10 June 2013 02:34 PM, J Keerthy wrote: > > Adds palmas mfd and palmas regulator nodes. > > > > Signed-off-by: Graeme Gregory > > Signed-off-by: J Keerthy > > --- > > arch/arm/boot/dts/palmas.dtsi | 98 > + > > Hi Keerthy, > Can you please add documentation for dt binding: > Documentation/devicetree/bindings/mfd > https://lkml.org/lkml/2013/6/6/25 It is based on this. > Most of time we refer from this document for dt population. > > Thanks, > Laxman -- 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] ARM: DTS: TWL4030: fix mux and wakeup for SYS_NIRQ line
Hi Kevin, On 06/07/2013 09:31 PM, Nishanth Menon wrote: > On 11:31-20130607, Kevin Hilman wrote: >> On most OMAP3 platforms, the twl4030 IRQ line is connected to the >> SYS_NIRQ line on OMAP. Add another DTS include file >> (twl4030_omap3.dtsi) for boards that hook up the twl4030 this way >> to include. >> >> This allows RTC wake from off-mode to work again on OMAP3-based >> platforms with twl4030. Tested on 3530/Beagle, 3730/Beagle-xM, >> 3530/Overo, 3730/Overo-STORM. >> >> Special thanks to Florian Vaussard for suggesting use of preprocessor >> feature. >> >> Cc: Florian Vaussard >> Cc: Benoit Cousson >> Cc: Nishanth Menon >> Signed-off-by: Kevin Hilman > Thanks, > Reviewed-by: Nishanth Menon Thanks, I've just applied it in for_3.11/dts. 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/2] ARM: dts: add dtsi for palmas
On Monday 10 June 2013 02:34 PM, J Keerthy wrote: Adds palmas mfd and palmas regulator nodes. Signed-off-by: Graeme Gregory Signed-off-by: J Keerthy --- arch/arm/boot/dts/palmas.dtsi | 98 + Hi Keerthy, Can you please add documentation for dt binding: Documentation/devicetree/bindings/mfd Most of time we refer from this document for dt population. Thanks, Laxman -- 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 v2 1/2] ARM: dts: add dtsi for palmas
Adds palmas mfd and palmas regulator nodes. Signed-off-by: Graeme Gregory Signed-off-by: J Keerthy --- arch/arm/boot/dts/palmas.dtsi | 98 + 1 files changed, 98 insertions(+), 0 deletions(-) create mode 100644 arch/arm/boot/dts/palmas.dtsi diff --git a/arch/arm/boot/dts/palmas.dtsi b/arch/arm/boot/dts/palmas.dtsi new file mode 100644 index 000..4c5162f --- /dev/null +++ b/arch/arm/boot/dts/palmas.dtsi @@ -0,0 +1,98 @@ +/* + * 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. + */ + +#include + +&palmas { + compatible = "ti,palmas"; + interrupt-controller; + #interrupt-cells = <2>; + + palmas_pmic { + compatible = "ti,palmas-pmic"; + interrupt-parent = <&palmas>; + interrupts = <14 IRQ_TYPE_NONE>; + interrupt-name = "short-irq"; + + ti,ldo6-vibrator; + + regulators { + smps123_reg: smps123 { + regulator-name = "smps123"; + }; + + smps45_reg: smps45 { + regulator-name = "smps45"; + }; + + smps6_reg: smps6 { + regulator-name = "smps6"; + }; + + smps7_reg: smps7 { + regulator-name = "smps7"; + }; + + smps8_reg: smps8 { + regulator-name = "smps8"; + }; + + smps9_reg: smps9 { + regulator-name = "smps9"; + }; + + smps10_reg: smps10 { + regulator-name = "smps10"; + }; + + ldo1_reg: ldo1 { + regulator-name = "ldo1"; + }; + + ldo2_reg: ldo2 { + regulator-name = "ldo2"; + }; + + ldo3_reg: ldo3 { + regulator-name = "ldo3"; + }; + + ldo4_reg: ldo4 { + regulator-name = "ldo4"; + }; + + ldo5_reg: ldo5 { + regulator-name = "ldo5"; + }; + + ldo6_reg: ldo6 { + regulator-name = "ldo6"; + }; + + ldo7_reg: ldo7 { + regulator-name = "ldo7"; + }; + + ldo8_reg: ldo8 { + regulator-name = "ldo8"; + }; + + ldo9_reg: ldo9 { + regulator-name = "ldo9"; + }; + + ldoln_reg: ldoln { + regulator-name = "ldoln"; + }; + + ldousb_reg: ldousb { + regulator-name = "ldousb"; + }; + }; + }; +}; -- 1.7.5.4 -- 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 v2 2/2] ARM: dts: OMAP5: add palmas node and omap specific palmas regulator properties
Add palmas node and omap specific palmas regulator properties. Signed-off-by: J Keerthy --- arch/arm/boot/dts/omap5-uevm.dts | 147 ++ 1 files changed, 147 insertions(+), 0 deletions(-) diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts index 927db1e..ffbcc3f 100644 --- a/arch/arm/boot/dts/omap5-uevm.dts +++ b/arch/arm/boot/dts/omap5-uevm.dts @@ -8,6 +8,8 @@ /dts-v1/; #include "omap5.dtsi" +#include +#include / { model = "TI OMAP5 uEVM board"; @@ -254,6 +256,151 @@ pinctrl-0 = <&i2c1_pins>; clock-frequency = <40>; + + palmas: palmas@48 { + reg = <0x48>; + /* SPI = 0, IRQ# = 7, active high level-sensitive */ + interrupts = ; /* IRQ_SYS_1N */ + interrupt-parent = <&gic>; + }; + +}; + +#include "palmas.dtsi" + +&palmas { + palmas_pmic { + ti,ldo6-vibrator; + + regulators { + smps123_reg: smps123 { + regulator-min-microvolt = < 60>; + regulator-max-microvolt = <150>; + regulator-always-on; + regulator-boot-on; + }; + + smps45_reg: smps45 { + regulator-min-microvolt = < 60>; + regulator-max-microvolt = <131>; + regulator-always-on; + regulator-boot-on; + }; + + smps6_reg: smps6 { + regulator-min-microvolt = <120>; + regulator-max-microvolt = <120>; + regulator-always-on; + regulator-boot-on; + }; + + smps7_reg: smps7 { + regulator-min-microvolt = <180>; + regulator-max-microvolt = <180>; + regulator-always-on; + regulator-boot-on; + }; + + smps8_reg: smps8 { + regulator-min-microvolt = < 60>; + regulator-max-microvolt = <131>; + regulator-always-on; + regulator-boot-on; + }; + + smps9_reg: smps9 { + regulator-min-microvolt = <210>; + regulator-max-microvolt = <210>; + regulator-always-on; + regulator-boot-on; + ti,smps-range = <0x80>; + }; + + smps10_reg: smps10 { + regulator-min-microvolt = <500>; + regulator-max-microvolt = <500>; + regulator-always-on; + regulator-boot-on; + }; + + ldo1_reg: ldo1 { + regulator-min-microvolt = <280>; + regulator-max-microvolt = <280>; + regulator-always-on; + regulator-boot-on; + }; + + ldo2_reg: ldo2 { + regulator-min-microvolt = <290>; + regulator-max-microvolt = <290>; + regulator-always-on; + regulator-boot-on; + }; + + ldo3_reg: ldo3 { + regulator-min-microvolt = <300>; + regulator-max-microvolt = <300>; + regulator-always-on; + regulator-boot-on; + }; + + ldo4_reg: ldo4 { + regulator-min-microvolt = <220>; + regulator-max-microvolt = <220>; + regulator-always-on; + regulator-boot-on; + }; + + ldo5_reg: ldo5 { + regulator-min-microvolt = <180>; + regulator-max-microvolt = <180>; + regulator-always-on; + regulator-boot-on; + }; + + ldo6_reg: ldo6 { + regulator-min-microvolt = <150>; + regulator-max-microvolt = <150>; +
[PATCH v2 0/2] ARM: dts: Add palmas dtsi
This patch series adds palmas.dtsi and adds the omap5 specific palmas entries in the omap5-uevm board file. This patch series is based on: git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.11/dts Boot tested on omap5-uevm board. J Keerthy (2): ARM: dts: add dtsi for palmas ARM: dts: OMAP5: add palmas node and omap specific palmas regulator properties arch/arm/boot/dts/omap5-uevm.dts | 147 ++ arch/arm/boot/dts/palmas.dtsi| 98 + 2 files changed, 245 insertions(+), 0 deletions(-) create mode 100644 arch/arm/boot/dts/palmas.dtsi -- 1.7.5.4 -- 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 13/14] ARM: AM33XX: hwmod data: irq, dma and addr info clean up
Hi Kevin, On Friday 07 June 2013 03:57 AM, Kevin Hilman wrote: Paul Walmsley writes: On Wed, 29 May 2013, Santosh Shilimkar wrote: From: Vaibhav Hiremath AM33XX only supports DT boot mode and with addition of extracting module resources like, irq, dma and address space from DT block, so now we can remove duplicate information from hwmod data file. OK, guess I'll take your word for it that it all works. The BeagleBone-white with appended DTB hasn't booted here since v3.7. And the BeagleBone-black with discrete DTB doesn't boot at all with current mainline, only with the TI vendor kernel & DTB... Anyone care to shed light on what's missing for BeagleBone boot with mainline currently? I have tested BeagleBone boot with today's mainline bootloader and kernel. It boots perfectly fine. Thanks and regards, Lokesh I've also not been able to boot a mainline kernel on the BeagleBone for some time. 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 -- 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/2] ARM: dts: OMAP5: add palmas node and omap specific palmas regulator properties
Hello Lee Jones, > -Original Message- > From: Lee Jones [mailto:lee.jo...@linaro.org] > Sent: Monday, June 10, 2013 1:42 PM > To: J, KEERTHY > Cc: Cousson, Benoit; devicetree-disc...@lists.ozlabs.org; linux- > o...@vger.kernel.org; linux-ker...@vger.kernel.org; > ldewan...@nvidia.com; grant.lik...@secretlab.ca; swar...@wwwdotorg.org; > swar...@nvidia.com; sa...@linux.intel.com; g...@slimlogic.co.uk > Subject: Re: [PATCH 2/2] ARM: dts: OMAP5: add palmas node and omap > specific palmas regulator properties > > > Add palmas node and omap specific palmas regulator properties. > > > > This patch is based on: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux- > omap-dt.git > > for_3.11/dts > > There's no need for this to be in the commit message. > Ok. I will remove this. > > Boot tested on omap5-uevm board. > > > > Signed-off-by: J Keerthy > > --- > > arch/arm/boot/dts/omap5-uevm.dts | 145 > > ++ > > 1 files changed, 145 insertions(+), 0 deletions(-) > > > > diff --git a/arch/arm/boot/dts/omap5-uevm.dts > > b/arch/arm/boot/dts/omap5-uevm.dts > > index 927db1e..88172db 100644 > > --- a/arch/arm/boot/dts/omap5-uevm.dts > > +++ b/arch/arm/boot/dts/omap5-uevm.dts > > @@ -254,6 +254,151 @@ > > pinctrl-0 = <&i2c1_pins>; > > > > clock-frequency = <40>; > > + > > + palmas: palmas@48 { > > + reg = <0x48>; > > + /* SPI = 0, IRQ# = 7, 4 = active high level-sensitive */ > > The interrupt property is fairly ubiqutous. There's not really any need > to document it in this manor. > > > + interrupts = <0 7 4>; /* IRQ_SYS_1N cascaded to gic */ > > Use the IRQ includes in dt-bindings. Oops Yes I will include. > > > + interrupt-parent = <&gic>; > > + }; > > + > > +}; > > + > > +#include "palmas.dtsi" > > I'm a bit confused by this. Is it now common practice to break out > nodes in this way? I assume to counter mass indentation, but it's a bit > alien to me. > > > +&palmas { > > + palmas_pmic { > > + ti,ldo6-vibrator; > > + > > + regulators { > > + smps123_reg: smps123 { > > + regulator-min-microvolt = < 60>; > > + regulator-max-microvolt = <150>; > > + regulator-always-on; > > + regulator-boot-on; > > + }; > > Are these all board specific, or are they shared with any other > platform? Yes. Hence moved all of them to board file as compared to my Last approach when I had kept all of them under palmas.dtsi. > > > + smps45_reg: smps45 { > > + regulator-min-microvolt = < 60>; > > + regulator-max-microvolt = <131>; > > + regulator-always-on; > > + regulator-boot-on; > > + }; > > + > > + smps6_reg: smps6 { > > + regulator-min-microvolt = <120>; > > + regulator-max-microvolt = <120>; > > + regulator-always-on; > > + regulator-boot-on; > > + }; > > + > > + smps7_reg: smps7 { > > + regulator-min-microvolt = <180>; > > + regulator-max-microvolt = <180>; > > + regulator-always-on; > > + regulator-boot-on; > > + }; > > + > > + smps8_reg: smps8 { > > + regulator-min-microvolt = < 60>; > > + regulator-max-microvolt = <131>; > > + regulator-always-on; > > + regulator-boot-on; > > + }; > > + > > + smps9_reg: smps9 { > > + regulator-min-microvolt = <210>; > > + regulator-max-microvolt = <210>; > > + regulator-always-on; > > + regulator-boot-on; > > + ti,smps-range = <0x80>; > > + }; > > + > > + smps10_reg: smps10 { > > + regulator-min-microvolt = <500>; > > + regulator-max-microvolt = <500>; > > + regulator-always-on; > > + regulator-boot-on; > > + }; > > + > > + ldo1_reg: ldo1 { > > + regulator-min-microvolt = <280>; > > + regulator-max-microvolt = <280>; > > + regulator-always-on; > > + regulator-boot-on; > > + }; > > + > > + ldo2_reg: ldo2 { > > +
Re: [PATCH v2 1/1] ARM : omap3 : fix wrong container_of in clock36xx.c
Hello Jean-Philippe, On Mon, 10 Jun 2013, jean-philippe francois wrote: > I am ok to work on it, however could you explain to me what is the > expected output of your PM tests, and how to reproduce them ? Here is the expected output for my ancient 3730 ES1.0 Beagle-XM: http://www.pwsan.com/omap/testlogs/test_v3.10-rc5/20130609031534/pm/3730beaglexm/3730beaglexm_log.txt When I ran that same test on the second version of your patch, the system froze during the retention dynamic idle test: %% Start retention dynamic idle UART wakeup test echo 3000 > /sys/devices/platform/omap_uart.0/power/autosuspend_delay_ms root@beagleboard:~# root@beagleboard:~# echo 3000 > /sys/devices/platform/omap_uart.1/power/autosuspend_delay_ms root@beagleboard:~# root@beagleboard:~# echo 3000 > /sys/devices/platform/omap_uart.2/power/autosuspend_delay_ms root@beagleboard:~# root@beagleboard:~# echo 3000 > /sys/devices/platform/omap_uart.3/power/autosuspend_delay_ms root@beagleboard:~# root@beagleboard:~# --- That is where the log stopped. Sorry to hear about your board - I can certainly sympathize, regards, - Paul -- 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/2] ARM: dts: OMAP5: add palmas node and omap specific palmas regulator properties
> Add palmas node and omap specific palmas regulator properties. > > This patch is based on: > > git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git > for_3.11/dts There's no need for this to be in the commit message. > Boot tested on omap5-uevm board. > > Signed-off-by: J Keerthy > --- > arch/arm/boot/dts/omap5-uevm.dts | 145 > ++ > 1 files changed, 145 insertions(+), 0 deletions(-) > > diff --git a/arch/arm/boot/dts/omap5-uevm.dts > b/arch/arm/boot/dts/omap5-uevm.dts > index 927db1e..88172db 100644 > --- a/arch/arm/boot/dts/omap5-uevm.dts > +++ b/arch/arm/boot/dts/omap5-uevm.dts > @@ -254,6 +254,151 @@ > pinctrl-0 = <&i2c1_pins>; > > clock-frequency = <40>; > + > + palmas: palmas@48 { > + reg = <0x48>; > + /* SPI = 0, IRQ# = 7, 4 = active high level-sensitive */ The interrupt property is fairly ubiqutous. There's not really any need to document it in this manor. > + interrupts = <0 7 4>; /* IRQ_SYS_1N cascaded to gic */ Use the IRQ includes in dt-bindings. > + interrupt-parent = <&gic>; > + }; > + > +}; > + > +#include "palmas.dtsi" I'm a bit confused by this. Is it now common practice to break out nodes in this way? I assume to counter mass indentation, but it's a bit alien to me. > +&palmas { > + palmas_pmic { > + ti,ldo6-vibrator; > + > + regulators { > + smps123_reg: smps123 { > + regulator-min-microvolt = < 60>; > + regulator-max-microvolt = <150>; > + regulator-always-on; > + regulator-boot-on; > + }; Are these all board specific, or are they shared with any other platform? > + smps45_reg: smps45 { > + regulator-min-microvolt = < 60>; > + regulator-max-microvolt = <131>; > + regulator-always-on; > + regulator-boot-on; > + }; > + > + smps6_reg: smps6 { > + regulator-min-microvolt = <120>; > + regulator-max-microvolt = <120>; > + regulator-always-on; > + regulator-boot-on; > + }; > + > + smps7_reg: smps7 { > + regulator-min-microvolt = <180>; > + regulator-max-microvolt = <180>; > + regulator-always-on; > + regulator-boot-on; > + }; > + > + smps8_reg: smps8 { > + regulator-min-microvolt = < 60>; > + regulator-max-microvolt = <131>; > + regulator-always-on; > + regulator-boot-on; > + }; > + > + smps9_reg: smps9 { > + regulator-min-microvolt = <210>; > + regulator-max-microvolt = <210>; > + regulator-always-on; > + regulator-boot-on; > + ti,smps-range = <0x80>; > + }; > + > + smps10_reg: smps10 { > + regulator-min-microvolt = <500>; > + regulator-max-microvolt = <500>; > + regulator-always-on; > + regulator-boot-on; > + }; > + > + ldo1_reg: ldo1 { > + regulator-min-microvolt = <280>; > + regulator-max-microvolt = <280>; > + regulator-always-on; > + regulator-boot-on; > + }; > + > + ldo2_reg: ldo2 { > + regulator-min-microvolt = <290>; > + regulator-max-microvolt = <290>; > + regulator-always-on; > + regulator-boot-on; > + }; > + > + ldo3_reg: ldo3 { > + regulator-min-microvolt = <300>; > + regulator-max-microvolt = <300>; > + regulator-always-on; > + regulator-boot-on; > + }; > + > + ldo4_reg: ldo4 { > + regulator-min-microvolt = <220>; > + regulator-max-microvolt = <220>; > + regulator-always-on; > +
[PATCH] omap2 dss: omap_display_init: Dont allow more than the maximum number of displays.
Currently the maximum number of display is hardcoded in the array omapfb2_device. Made the number a #define and check it in init routine. Signed-off-by: Andreas Naumann --- Our board supports a lot of panels and we could probably solve this more effectively, but arrays shouldnt silently overflow when using more than 10 displays. Created the patch on 3.1 and tested it there. This one is rebased on todays linux-omap.git arch/arm/mach-omap2/display.c | 5 + drivers/video/omap2/omapfb/omapfb.h | 10 +- include/video/omapdss.h | 2 ++ 3 files changed, 12 insertions(+), 5 deletions(-) diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c index ff37be1..6f1a147 100644 --- a/arch/arm/mach-omap2/display.c +++ b/arch/arm/mach-omap2/display.c @@ -338,6 +338,11 @@ int __init omap_display_init(struct omap_dss_board_info *board_data) return -ENODEV; } + if( board_data->num_devices > OMAPFB_MAX_DISPLAY_NUM ){ + pr_err("Trying to init more displays(%d) than possible.(%d)\n", board_data->num_devices, OMAPFB_MAX_DISPLAY_NUM); + return -ENODEV; + } + board_data->version = ver; board_data->dsi_enable_pads = omap_dsi_enable_pads; board_data->dsi_disable_pads = omap_dsi_disable_pads; diff --git a/drivers/video/omap2/omapfb/omapfb.h b/drivers/video/omap2/omapfb/omapfb.h index 623cd87..00d3fbc 100644 --- a/drivers/video/omap2/omapfb/omapfb.h +++ b/drivers/video/omap2/omapfb/omapfb.h @@ -96,15 +96,15 @@ struct omapfb2_device { int state; unsigned num_fbs; - struct fb_info *fbs[10]; - struct omapfb2_mem_region regions[10]; + struct fb_info *fbs[OMAPFB_MAX_DISPLAY_NUM]; + struct omapfb2_mem_region regions[OMAPFB_MAX_DISPLAY_NUM]; unsigned num_displays; - struct omapfb_display_data displays[10]; + struct omapfb_display_data displays[OMAPFB_MAX_DISPLAY_NUM]; unsigned num_overlays; - struct omap_overlay *overlays[10]; + struct omap_overlay *overlays[OMAPFB_MAX_DISPLAY_NUM]; unsigned num_managers; - struct omap_overlay_manager *managers[10]; + struct omap_overlay_manager *managers[OMAPFB_MAX_DISPLAY_NUM]; struct workqueue_struct *auto_update_wq; }; diff --git a/include/video/omapdss.h b/include/video/omapdss.h index aeb4e9a..dfb054f 100644 --- a/include/video/omapdss.h +++ b/include/video/omapdss.h @@ -54,6 +54,8 @@ #define DISPC_IRQ_ACBIAS_COUNT_STAT3 (1 << 29) #define DISPC_IRQ_FRAMEDONE3 (1 << 30) +#define OMAPFB_MAX_DISPLAY_NUM 10 + struct omap_dss_device; struct omap_overlay_manager; struct dss_lcd_mgr_config; -- 1.8.2.3 -- 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/1] ARM : omap3 : fix wrong container_of in clock36xx.c
2013/6/6 Paul Walmsley : > On Thu, 6 Jun 2013, jean-philippe francois wrote: > >> Does the first version [1] of the patch, that only touch the MSB of >> the divider also trigger the >> bug ? >> >> [1] https://patchwork.kernel.org/patch/2609681/ > > That one passes the PM test here. Will take this one for v3.10-rc fixes > instead, since it fixes a known DSS problem and the original code wasn't > correct. > > Jean, could you work with Mike to come up with a better approach for > v3.11 or v3.12? > Hi, I am ok to work on it, however could you explain to me what is the expected output of your PM tests, and how to reproduce them ? The board I used to test the clock frequency was correct suffered from heavy handed oscilloscope probing and is currently out of order :( Jean-Philippe François. > > - Paul > -- > 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 -- 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: add dtsi for palmas
> Totally agree to all the above concerns. So can we have a custom .dtsi file > for a board+pmic combination? Or have only the required properties over ridden > in the board file? The common approach is to only apply nodes and node properties to the .dtsi files which are appropriate for _all_ platforms which include them. Anything that is only relevant to a sub-set of boards should be in a higher ranking .dtsi file and finally, any settings which are board specific should be in the board's .dts file. -- 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
OMAP v3.10-rc regressions that no one's fixed
Hi folks -- particularly TIers working on mainline, There are several regressions that started with v3.10-rc that no one's fixed for over a month. Some of them should be quite easy: * 37xx EVM: boot fails - as of v3.10-rc1 - Cause unknown * 2420N800, 2430sdp: failed to get counter_32k resource - "omap2_sync32k_clocksource_init: failed to get counter_32k resource" - Cause unknown * 2430SDP, 3730 Beagle XM, 3530 Beagle, 3517EVM, CM-T3517: {dmic,mcpdm} lookup failure - Cause unknown - These IP blocks don't exist on OMAP3xxx/AM35xx chips * 3730 Beagle XM, am335xbone, CM-T3517: uart4_rx.uart4_rx mux failure - Cause unknown (For more details, see the logs at the link below.) It would be good if people could step up to fix these before v3.10 comes out. - Paul -- Forwarded message -- Date: Mon, 10 Jun 2013 02:00:50 + (UTC) From: Paul Walmsley To: linux-omap@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Subject: OMAP baseline test results for v3.10-rc5 Here are some basic OMAP test results for Linux v3.10-rc5. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v3.10-rc5/20130609031534/ Test summary Build: uImage: Pass (16/16): am33xx_only, n800_multi_omap2xxx, n800_only_a, omap1_defconfig, omap1_defconfig_1510innovator_only, omap1_defconfig_5912osk_only, omap2plus_defconfig, omap2plus_defconfig_2430sdp_only omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm, omap2plus_defconfig_omap2_4_only, omap2plus_defconfig_omap3_4_only, rmk_omap3430_ldp_allnoconfig, rmk_omap3430_ldp_oldconfig, rmk_omap4430_sdp_allnoconfig, rmk_omap4430_sdp_oldconfig Build: zImage: Pass ( 1/ 1): omap2plus_defconfig Boot to userspace: FAIL ( 3/12): 37xxevm, am335xbone, am335xbonelt Pass ( 9/12): 2420n800, 2430sdp, 3517evm, 3530es3beagle, 3730beaglexm, 4430es2panda, 4460pandaes, 5912osk, cmt3517 PM: chip retention via suspend: FAIL ( 3/ 6): 2430sdp, 37xxevm, 4430es2panda Pass ( 3/ 6): 3530es3beagle, 3730beaglexm, 4460pandaes PM: chip retention via dynamic idle: FAIL ( 4/ 6): 2430sdp, 37xxevm, 4430es2panda, 4460pandaes Pass ( 2/ 6): 3530es3beagle, 3730beaglexm PM: chip off except CORE via suspend: Pass ( 1/ 1): 3730beaglexm PM: chip off except CORE via dynamic idle: Pass ( 1/ 1): 3730beaglexm PM: chip off via suspend: FAIL ( 3/ 4): 37xxevm, 4430es2panda, 4460pandaes Pass ( 1/ 4): 3530es3beagle PM: chip off via dynamic idle: FAIL ( 3/ 4): 37xxevm, 4430es2panda, 4460pandaes Pass ( 1/ 4): 3530es3beagle Failing tests: fixed by posted patches -- (none) Failing tests: needing investigation Boot tests: * 3517EVM & CM-T3517: boot hangs with NFS root - Likely some Kconfig, board file, and PM issues with EMAC - Longstanding bug - Not currently part of the automated test suite * 37xx EVM: boot fails - as of v3.10-rc1 - Cause unknown Boot warnings: * 2420N800, 2430sdp: failed to get counter_32k resource - "omap2_sync32k_clocksource_init: failed to get counter_32k resource" - Cause unknown * CM-T3517: L3 in-band error with IPSS during boot - Cause unknown but see http://marc.info/?l=linux-omap&m=134833869730129&w=2 - Longstanding issue; does not occur on the 3517EVM * 2430SDP, 3730 Beagle XM, 3530 Beagle, 3517EVM, CM-T3517: {dmic,mcpdm} lookup failure - Cause unknown - These IP blocks don't exist on OMAP3xxx/AM35xx chips * 3730 Beagle XM, am335xbone, CM-T3517: uart4_rx.uart4_rx mux failure - Cause unknown PM tests: * 2430sdp: power domains not entering retention - Cause unknown * 3730 Beagle XM: does not serial wake from off-idle suspend when console UART doesn't clock-gate ("debug ignore_loglevel") - Cause unknown - Not yet part of the automated test suite - Re-tested at v3.7; still failing: http://www.pwsan.com/omap/transcripts/20121211-3730beaglexm-3.7-pm-offmode-fail-debug.txt * 4430es2panda: pwrdm state mismatch on CAM, DSS * 4430es2panda: CORE, TESLA, IVAHD, L3INIT didn't enter target state - Probably due to lack of reset code for M3, DSP, SL2IF, FSUSB per discussion with Tero Kristo - Likely dependent on the bootloader version - fails with 2012.07-00136-g755de79 - http://marc.info/?l=linux-arm-kernel&m=136432340618226&w=2 * 4430es2panda: MPU, ABE didn't enter target state - New for v3.10-rc * 4460pandaes: pwrdm state mismatch on DSS, ABE, IVAHD, TESLA * 4460pandaes: chip not entering retention in dynamic idle - Presumably 4430es2panda also fails this - Suspend-to-RAM enters full chip retention Other: * 4430es2panda: omap_hwmod: l3_instr: _wait_target_disable failed - Unknown cause; could be due to the lack of hierar
Re: Block layer / MMC: Order of segments in SG-list
On Sun, Jun 09 2013, Joel A Fernandes wrote: > Hi, > So I tried dumping addresses of an SG list in omap_hsmmc driver before > it is passed to DMA. > > I found some interesting traces occasionally such as the below SG list > of length 4. > > [6.758716] (0) length=4096, sg virt addr=c1318000, sg phy addr=81318000 > [6.765863] (1) length=4096, sg virt addr=c1317000, sg phy addr=81317000 > [6.773011] (2) length=4096, sg virt addr=c1316000, sg phy addr=81316000 > [6.780087] (3) length=4096, sg virt addr=c1315000, sg phy addr=81315000 > > What is interesting is these chunks are really physically contiguous > but in reverse order in the list. I think a smarter ordering can > actually improve through put considerably and save precious DMA > resources by not having to allocate slots for parts of contiguous > chunk of physical memory. > > Is there any particular reason why this might be the case? I traced to > find that the SG list is actually prepared by mmc_queue_map_sg -> > blk_rq_map_sg mmc or the block layer can't do much about the memory it is handed. The sg mappings just reflect the fact that they happened to be in reverse, so to speak. You are right in that having those pages in the right order and being able to merge the segments is a win. Unless you are heavily SG entry starved or your DMA controller has a high per-sg-entry overhead, it's usually not a big deal. That said, you should investigate WHY they are in that order :-) -- Jens Axboe -- 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