Re: [PATCH v2] ARM: DTS: OMAP4: Add OMAP4 Blaze Tablet support
* Dan Murphy [130625 07:13]: > On 06/25/2013 06:32 AM, Ruslan Bilovol wrote: > >The OMAP4 Blaze Tablet is TI OMAP4 processor-based > >development platform in a tablet formfactor. > >The platform contains many of the features found in > >present-day handsets (such as audio, video, wireless > >functions and user interfaces) and in addition > >contains features for software development and test. > Why do we want to send this upstream? > What is the advantage to having this supported? > > I don't believe we need to add another community board. We have a > SDP and Panda. Why not? Just the .dts file is needed nowadays and it may make it easier to support various other omap4 based tablets that have similar features. 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] Documentation: dt: bindings: TI WiLink modules
* Luciano Coelho [130625 12:43]: > (oh crap, now *really* fixed the ARM mailing list address) > > On Tue, 2013-06-25 at 11:35 +0300, Luciano Coelho wrote: > > Add device tree bindings documentation for the TI WiLink modules. > > Currently only the WLAN part of the WiLink6, WiLink7 and WiLink8 > > modules is supported. > > > > Signed-off-by: Luciano Coelho > > --- > > > > I created a new directory under net to contain wireless bindings > > documentation. > > > > The actual implementation in the driver will follow separately. > > > > .../devicetree/bindings/net/wireless/ti-wilink.txt | 46 > > > > 1 file changed, 46 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/net/wireless/ti-wilink.txt > > > > diff --git a/Documentation/devicetree/bindings/net/wireless/ti-wilink.txt > > b/Documentation/devicetree/bindings/net/wireless/ti-wilink.txt > > new file mode 100644 > > index 000..d8e8bfbb > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/net/wireless/ti-wilink.txt > > @@ -0,0 +1,46 @@ > > +TI WiLink Wireless Modules Device Tree Bindings > > +=== > > + > > +The WiLink modules provide wireless connectivity, such as WLAN, > > +Bluetooth, FM and NFC. > > + > > +There are several different modules available, which can be grouped by > > +their generation: WiLink6, WiLink7 and WiLink8. WiLink4 is not > > +currently supported with device tree. > > + > > +Currently, only the WLAN portion of the modules is supported with > > +device tree. > > + > > +Required properties: > > + > > + > > +- compatible: should be "ti,wilink6", "ti,wilink7" or "ti,wilink8" > > +- interrupt-parent: the interrupt controller > > +- interrupts: out-of-band WLAN interrupt > > + See the interrupt controller's bindings documentation for > > + detailed definition. > > + > > +Optional properties: > > + > > + > > +- refclock: the internal WLAN reference clock frequency (required for > > + WiLink6 and WiLink7; not used for WiLink8). Must be one of the > > + following: > > + 0 = 19.2 MHz > > + 1 = 26.0 MHz > > + 2 = 38.4 MHz > > + 3 = 52.0 MHz > > + 4 = 38.4 MHz, XTAL > > + 5 = 26.0 MHz, XTAL This is just the omap refclock, right? If so, you can just pass the standard clock phandle. I know we don't yet have the DT clocks merged, but Tero just posted another revision of those. > > +- tcxoclock: the internal WLAN TCXO clock frequency (required for > > + WiLink7 not used for WiLink6 and WiLink8). Must be one of the > > + following: > > + 0 = 19.200 MHz > > + 1 = 26.000 MHz > > + 2 = 38.400 MHz > > + 3 = 52.000 MHz > > + 4 = 16.368 MHz > > + 5 = 32.736 MHz > > + 6 = 16.800 MHz > > + 7 = 33.600 MHz Where does this clock come from? Maybe this can be set based on the compatible value if it's completely internal? > If this is okay for everyone, can I push this via my tree (which goes to > linux-wireless->net->linus)? I think it makes more sense to send the > documentation together with the patch that actually implements the DT > node parsing in the driver. If we can use the standard bindings, it might be worth waiting until we have the DT clocks available as we have the pdata workaround merged anyways. That's because then we don't need to support the custom binding later on ;) 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 baseline test results for v3.10-rc6
> -Original Message- > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > ow...@vger.kernel.org] On Behalf Of Paul Walmsley > Sent: Tuesday, June 25, 2013 11:51 PM > To: Balbi, Felipe > Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org; > Rini, Tom; Hiremath, Vaibhav; khil...@ti.com > Subject: Re: OMAP baseline test results for v3.10-rc6 > > + Vaibhav and Kevin > > Hi, > > On Tue, 25 Jun 2013, Felipe Balbi wrote: > > > On Mon, Jun 17, 2013 at 05:23:17AM +, Paul Walmsley wrote: > > > Boot to userspace: > > > FAIL ( 3/12): 37xxevm, am335xbone, am335xbonelt > > > > Paul, we have at least 2 different folks who can't reproduce your > bone > > and bone black boot to userspace failures. I wonder how you're trying > to > > boot them. > > > > Care to share your test scripts ? > > Sure... the methodology is completely open and has been posted in the > online logs since the first test cycle. (For some reason, almost no > one > clicks through the test directory trees that I post online. Is this a > documentation issue? What can we do to make it easier for people to > explore this?) > That’s not quite true, I remember going through your log in detail multiple Times. The issue is, for appended DTB you must enable 2 config options, CONFIG_ARM_APPENDED_DTB = y CONFIG_ARM_ATAG_DTB_COMPAT = y OR If you don’t want to change/modify default config (omap2plus_defconfig), Use separate DTB and zImage, which is standard way of booting kernel. Same applies to BeagleBone Black. Infact same DTB and zImage boots up fine On both boards without any issues. Thanks, Vaibhav -- 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 baseline test results for v3.10-rc6
> -Original Message- > From: linux-arm-kernel [mailto:linux-arm-kernel- > boun...@lists.infradead.org] On Behalf Of Kevin Hilman > Sent: Wednesday, June 26, 2013 1:28 AM > To: Rini, Tom > Cc: Paul Walmsley; linux-omap@vger.kernel.org; linux-arm- > ker...@lists.infradead.org; Balbi, Felipe; Hiremath, Vaibhav > Subject: Re: OMAP baseline test results for v3.10-rc6 > > Tom Rini writes: > > > On 06/25/2013 02:20 PM, Paul Walmsley wrote: > >> + Vaibhav and Kevin > >> > >> Hi, > >> > >> On Tue, 25 Jun 2013, Felipe Balbi wrote: > >> > >>> On Mon, Jun 17, 2013 at 05:23:17AM +, Paul Walmsley wrote: > Boot to userspace: > FAIL ( 3/12): 37xxevm, am335xbone, am335xbonelt > >>> > >>> Paul, we have at least 2 different folks who can't reproduce your > bone > >>> and bone black boot to userspace failures. I wonder how you're > trying to > >>> boot them. > >>> > >>> Care to share your test scripts ? > >> > >> Sure... the methodology is completely open and has been posted in > the > >> online logs since the first test cycle. (For some reason, almost no > one > >> clicks through the test directory trees that I post online. Is this > a > >> documentation issue? What can we do to make it easier for people to > >> explore this?) > > > > Well, another link never hurts the search results :) > > > > [snip] > >> Am certainly open to the idea that there's something wrong with the > way > >> that I'm booting either of these. But AFAIK no one's been able to > >> identify exactly what it could be. I haven't had the time recently > to > >> spend hours going through the various permutations, given all the > other > >> breakage :-( BeagleBone-white has the additional complication that > it is > >> not easy to automate, due to the way that power is delivered to the > board, > >> so there is an extra dimension of difficulty there. > > > > Ah-ha, I reproduced your failure. If I make up a concat uImage + > DTB, > > rather than pass them separately, it fails to boot. If you switch to > > mainline U-Boot (v2012.10 or later) you get support for separate > image + > > dtb (v2013.04 gives you bootz and zImage support). v2013.04 will > also > > work out of the box for BeagleBone-Black. > > Just to confirm, my problems with mainline were with appended DTB also. > Separate DTB and zImage work fine (at least using u-boot v2013.04.) > > That being said, appended DTB should still work, so there's a bug > hiding > someplace that needs to be found fixed. > > Can you guys update your tests to test appended DTB also? > What is missing here is, CONFIG_ARM_APPENDED_DTB = y CONFIG_ARM_ATAG_DTB_COMPAT = y And for the code which is required in case of appended DTB, please refer to the code "arch/arm/boot/compressed/head.S" Please __NOTE__ that these options are not enabled in default omap2plus_defconfig. Thanks, Vaibhav -- 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/5] mmc: omap_hsmmc: Add reg-offset to bindings documentation
On Wed, Jun 26, 2013 at 06:55:01, Fernandes, Joel wrote: > From: Joel A Fernandes > > A new reg-offset property was added to account for register offsets > in some omap-hsmmc's. Document the new property. > Small nitpick I usually get feedback that any driver DT changes and the associated Binding doc update should come in one single patch for better readability. In this case, I believe it would be patch 1/5 & 5/5 Regards, Gururaja > Signed-off-by: Joel A Fernandes > --- > .../devicetree/bindings/mmc/ti-omap-hsmmc.txt |3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt > b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt > index 8c8908a..33f4b1e 100644 > --- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt > +++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt > @@ -20,6 +20,9 @@ ti,dual-volt: boolean, supports dual voltage cards > ti,non-removable: non-removable slot (like eMMC) > ti,needs-special-reset: Requires a special softreset sequence > ti,needs-special-hs-handling: HSMMC IP needs special setting for handling > High Speed > +reg-offset: Supplementing the common reg property (described in > bindings/mmc/mmc.txt), > +some omap-hsmmc's can start an offset from reg but are otherwise identical > to others. > +The registers between start to offset are considered reserved. > dmas: List of DMA specifiers with the controller specific format > as described in the generic DMA client binding. A tx and rx > specifier is required. > -- > 1.7.9.5 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- 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 0/2] EDMA config and comments
From: Joel A Fernandes Minor patches remaining after EDMA series has been merged: First patch adds the TI_EDMA option which people can forget to add and can result in failure without any informative errors of why DMA is not working. Second patch adds comments to the EDMA code for the calculations in the A-sync case. From my experience, this code is not-so-obvious. Hopefully this makes the life of readers of the code a little better. Joel A Fernandes (2): ARM: configs: Enable TI_EDMA in omap2plus_defconfig DMA: EDMA: Add comments for A-sync case calculations arch/arm/configs/omap2plus_defconfig |1 + drivers/dma/edma.c | 22 ++ 2 files changed, 23 insertions(+) -- Resending as first attempt didn't work. 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] DMA: EDMA: Add comments for A-sync case calculations
From: Joel A Fernandes
A-sync case in EDMA driver is tricky and not so obvious.
Document the reasons for the calculations and the scenarious
they are used.
Signed-off-by: Joel A Fernandes
---
drivers/dma/edma.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index e008ed2..a1d9f3785 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -284,8 +284,24 @@ static struct dma_async_tx_descriptor *edma_prep_slave_sg(
*/
if (burst == 1) {
edesc->absync = false;
+ /*
+* For the A-sync case, bcnt and ccnt are the remainder
+* and quotient respectively of the division of:
+* (sg_dma_len(sg) / acnt) by (SZ_64K -1). This is so
+* that in case bcnt over flows, we have ccnt to use.
+* Note: In A-sync tranfer only, bcntrld is used, but it
+* only applies for sg_dma_len(sg) >= SZ_64K.
+* In this case, the best way adopted is- bccnt for the
+* first frame will be the remainder below. Then for
+* every successive frame, bcnt will be SZ_64K-1. This
+* is assured as bcntrld = 0x in end of function.
+*/
ccnt = sg_dma_len(sg) / acnt / (SZ_64K - 1);
bcnt = sg_dma_len(sg) / acnt - ccnt * (SZ_64K - 1);
+ /*
+* If bcnt is non-zero, we have a remainder and hence an
+* extra frame to transfer, so increment ccnt.
+*/
if (bcnt)
ccnt++;
else
@@ -343,6 +359,12 @@ static struct dma_async_tx_descriptor *edma_prep_slave_sg(
edesc->pset[i].a_b_cnt = bcnt << 16 | acnt;
edesc->pset[i].ccnt = ccnt;
+ /*
+* Only time when (bcntrld) auto reload is required is for
+* A-sync case, and in this case, a requirement of reload value
+* of SZ_64K-1 only is assured. 'link' is initially set to NULL
+* and then later will be populated by edma_execute.
+*/
edesc->pset[i].link_bcntrld = 0x;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] ARM: configs: Enable TI_EDMA in omap2plus_defconfig
From: Joel A Fernandes Build EDMA in my default to avoid fewer people stepping on their toes with broken DMA on drivers needing EDMA. Signed-off-by: Joel A Fernandes --- arch/arm/configs/omap2plus_defconfig |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index abbe319..7e00deb 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -236,6 +236,7 @@ CONFIG_RTC_DRV_TWL92330=y CONFIG_RTC_DRV_TWL4030=y CONFIG_RTC_DRV_OMAP=y CONFIG_DMADEVICES=y +CONFIG_TI_EDMA=y CONFIG_DMA_OMAP=y CONFIG_EXT2_FS=y CONFIG_EXT3_FS=y -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/5] mmc: omap_hsmmc: Add reg-offset to bindings documentation
From: Joel A Fernandes A new reg-offset property was added to account for register offsets in some omap-hsmmc's. Document the new property. Signed-off-by: Joel A Fernandes --- .../devicetree/bindings/mmc/ti-omap-hsmmc.txt |3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt index 8c8908a..33f4b1e 100644 --- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt +++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt @@ -20,6 +20,9 @@ ti,dual-volt: boolean, supports dual voltage cards ti,non-removable: non-removable slot (like eMMC) ti,needs-special-reset: Requires a special softreset sequence ti,needs-special-hs-handling: HSMMC IP needs special setting for handling High Speed +reg-offset: Supplementing the common reg property (described in bindings/mmc/mmc.txt), +some omap-hsmmc's can start an offset from reg but are otherwise identical to others. +The registers between start to offset are considered reserved. dmas: List of DMA specifiers with the controller specific format as described in the generic DMA client binding. A tx and rx specifier is required. -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/5] MMC: omap_hsmmc: Add reg_offset to DT bindings
From: Joel A Fernandes
Some omap_hsmmc's need to start from a particular offset but
otherwise are same and can be reused. Let the DT tell us about
the HW difference, check for the reg-offset property and use
the same in the driver.
Signed-off-by: Joel A Fernandes
---
drivers/mmc/host/omap_hsmmc.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 5af62c6..aae0994 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1717,6 +1717,7 @@ static struct omap_mmc_platform_data
*of_get_hsmmc_pdata(struct device *dev)
struct omap_mmc_platform_data *pdata;
struct device_node *np = dev->of_node;
u32 bus_width, max_freq;
+ u32 reg_offset;
int cd_gpio, wp_gpio;
cd_gpio = of_get_named_gpio(np, "cd-gpios", 0);
@@ -1755,6 +1756,9 @@ static struct omap_mmc_platform_data
*of_get_hsmmc_pdata(struct device *dev)
if (of_find_property(np, "ti,needs-special-hs-handling", NULL))
pdata->slots[0].features |= HSMMC_HAS_HSPE_SUPPORT;
+ if (!of_property_read_u32(np, "reg-offset", ®_offset))
+ pdata->reg_offset = reg_offset;
+
return pdata;
}
#else
@@ -1785,7 +1789,8 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
if (IS_ERR(pdata))
return PTR_ERR(pdata);
- if (match->data) {
+ /* Provide reg_offset from match->data unless specified in DT */
+ if (match->data && !pdata->reg_offset) {
const u16 *offsetp = match->data;
pdata->reg_offset = *offsetp;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/5] ARM: dts: add AM33XX MMC support
From: Matt Porter
Adds AM33XX MMC support for am335x-bone, am335x-evm, and
am335x-evmsk.
Signed-off-by: Matt Porter
Acked-by: Tony Lindgren
---
arch/arm/boot/dts/am335x-bone.dts |7 +++
arch/arm/boot/dts/am335x-evm.dts |7 +++
arch/arm/boot/dts/am335x-evmsk.dts |7 +++
arch/arm/boot/dts/am33xx.dtsi | 28
4 files changed, 49 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index 5302f79..80bff9c 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -120,6 +120,8 @@
};
ldo3_reg: regulator@5 {
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <330>;
regulator-always-on;
};
@@ -136,3 +138,8 @@
&cpsw_emac1 {
phy_id = <&davinci_mdio>, <1>;
};
+
+&mmc1 {
+ status = "okay";
+ vmmc-supply = <&ldo3_reg>;
+};
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 0423298..62af561 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -232,6 +232,8 @@
};
vmmc_reg: regulator@12 {
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <330>;
regulator-always-on;
};
};
@@ -244,3 +246,8 @@
&cpsw_emac1 {
phy_id = <&davinci_mdio>, <1>;
};
+
+&mmc1 {
+ status = "okay";
+ vmmc-supply = <&vmmc_reg>;
+};
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts
b/arch/arm/boot/dts/am335x-evmsk.dts
index f67c360..8904b88 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -244,7 +244,14 @@
};
vmmc_reg: regulator@12 {
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <330>;
regulator-always-on;
};
};
};
+
+&mmc1 {
+ status = "okay";
+ vmmc-supply = <&vmmc_reg>;
+};
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index b4fda12..119f8a9 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -229,6 +229,34 @@
status = "disabled";
};
+ mmc1: mmc@4806 {
+ compatible = "ti,omap3-hsmmc";
+ ti,hwmods = "mmc1";
+ ti,dual-volt;
+ ti,needs-special-reset;
+ dmas = <&edma 24
+ &edma 25>;
+ dma-names = "tx", "rx";
+ status = "disabled";
+ };
+
+ mmc2: mmc@481d8000 {
+ compatible = "ti,omap3-hsmmc";
+ ti,hwmods = "mmc2";
+ ti,needs-special-reset;
+ dmas = <&edma 2
+ &edma 3>;
+ dma-names = "tx", "rx";
+ status = "disabled";
+ };
+
+ mmc3: mmc@4781 {
+ compatible = "ti,omap3-hsmmc";
+ ti,hwmods = "mmc3";
+ ti,needs-special-reset;
+ status = "disabled";
+ };
+
wdt2: wdt@44e35000 {
compatible = "ti,omap3-wdt";
ti,hwmods = "wd_timer2";
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/5] mmc: omap_hsmmc: add generic DMA request support to the DT binding
From: Matt Porter
The binding definition is based on the generic DMA request binding.
Signed-off-by: Matt Porter
Acked-by: Tony Lindgren
Acked-by: Arnd Bergmann
---
.../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 26 +++-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
index ed271fc..8c8908a 100644
--- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -20,8 +20,29 @@ ti,dual-volt: boolean, supports dual voltage cards
ti,non-removable: non-removable slot (like eMMC)
ti,needs-special-reset: Requires a special softreset sequence
ti,needs-special-hs-handling: HSMMC IP needs special setting for handling High
Speed
+dmas: List of DMA specifiers with the controller specific format
+as described in the generic DMA client binding. A tx and rx
+specifier is required.
+dma-names: List of DMA request names. These strings correspond
+1:1 with the DMA specifiers listed in dmas. The string naming is
+to be "rx" and "tx" for RX and TX DMA requests, respectively.
+
+Examples:
+
+[hwmod populated DMA resources]
+
+ mmc1: mmc@0x4809c000 {
+ compatible = "ti,omap4-hsmmc";
+ reg = <0x4809c000 0x400>;
+ ti,hwmods = "mmc1";
+ ti,dual-volt;
+ bus-width = <4>;
+ vmmc-supply = <&vmmc>; /* phandle to regulator node */
+ ti,non-removable;
+ };
+
+[generic DMA request binding]
-Example:
mmc1: mmc@0x4809c000 {
compatible = "ti,omap4-hsmmc";
reg = <0x4809c000 0x400>;
@@ -30,4 +51,7 @@ Example:
bus-width = <4>;
vmmc-supply = <&vmmc>; /* phandle to regulator node */
ti,non-removable;
+ dmas = <&edma 24
+ &edma 25>;
+ dma-names = "tx", "rx";
};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/5] ARM: dts: am33xx: Add interrupts and memory resources for MMC
From: Joel A Fernandes HWMOD irq entries for MMC were removed. We provide the same from DT for MMC. This fixes issue where memory resource could not be found during probe. Also, added the reg-offset property to account for the offset from start. Signed-off-by: Joel A Fernandes --- arch/arm/boot/dts/am33xx.dtsi | 12 1 file changed, 12 insertions(+) diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi index 119f8a9..e0a5741 100644 --- a/arch/arm/boot/dts/am33xx.dtsi +++ b/arch/arm/boot/dts/am33xx.dtsi @@ -237,6 +237,10 @@ dmas = <&edma 24 &edma 25>; dma-names = "tx", "rx"; + interrupts = <64>; + interrupt-parent = <&intc>; + reg = <0x4806 0x1000>; + reg-offset = <0x100>; status = "disabled"; }; @@ -247,6 +251,10 @@ dmas = <&edma 2 &edma 3>; dma-names = "tx", "rx"; + interrupts = <24>; + interrupt-parent = <&intc>; + reg = <0x481d8000 0x1000>; + reg-offset = <0x100>; status = "disabled"; }; @@ -254,6 +262,10 @@ compatible = "ti,omap3-hsmmc"; ti,hwmods = "mmc3"; ti,needs-special-reset; + interrupts = <25>; + interrupt-parent = <&intc>; + reg = <0x4781 0x1000>; + reg-offset = <0x100>; status = "disabled"; }; -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/5] AM33xx: MMC resources from DT without HWMOD data
From: Joel A Fernandes This series is fixes to get MMC working on AM33XX without HWMOD data. On removal of HWMOD data, interrupt and register properties need to be provided for the driver to function correctly. Also instead of specifying offset in match->data, I've added bindings for the same and specify it directly from DT as this is a hardware description. Reposting Matt's remaining 2 patches on the bindings and dts. Joel A Fernandes (3): MMC: omap_hsmmc: Add reg_offset to DT bindings ARM: dts: am33xx: Add interrupts and memory resources for MMC mmc: omap_hsmmc: Add reg-offset to bindings documentation Matt Porter (2): ARM: dts: add AM33XX MMC support mmc: omap_hsmmc: add generic DMA request support to the DT binding .../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 29 +- arch/arm/boot/dts/am335x-bone.dts |7 arch/arm/boot/dts/am335x-evm.dts |7 arch/arm/boot/dts/am335x-evmsk.dts |7 arch/arm/boot/dts/am33xx.dtsi | 40 drivers/mmc/host/omap_hsmmc.c |7 +++- 6 files changed, 95 insertions(+), 2 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] EDMA config and comments
From: Joel A Fernandes Minor patches remaining after EDMA series has been merged: First patch adds the TI_EDMA option which people can forget to add and can result in failure without any informative errors of why DMA is not working. Second patch adds comments to the EDMA code for the calculations in the A-sync case. From my experience, this code is not-so-obvious. Hopefully this makes the life of readers of the code a little better. Joel A Fernandes (2): ARM: configs: Enable TI_EDMA in omap2plus_defconfig DMA: EDMA: Add comments for A-sync case calculations arch/arm/configs/omap2plus_defconfig |1 + drivers/dma/edma.c | 22 ++ 2 files changed, 23 insertions(+) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP5: voltagedomain data: remove temporary OMAP4 voltage data
Nishanth Menon writes: > commit 20d49e9ccfece526db755940721aa13e331936d4 > (ARM: OMAP5: voltagedomain data: Add OMAP5 voltage domain data) > > Introduced dummy volt data for OMAP5 with OMAP4460 voltage information. > > However with the fixes introduced in later patches > > commit cd8abed1da91a3250aa4b3857479613a2b446f84 > (ARM: OMAP2+: Powerdomain: Remove the need to always have a voltdm > associated to a pwrdm) > > We are no longer restricted in that respect. Further, OPP voltage > information is supposed to be provided by dts information. This needs > to be added in future patches as various voltage modules are converted > to dts. > > This also fixes the build breakage for voltagedomains54xx_data.c when just > OMAP5 SoC is enabled: https://patchwork.kernel.org/patch/2764191/ > > Reported-by: Arnd Bergmann > Signed-off-by: Nishanth Menon > Cc: Kevin Hilman > Cc: Benoit Cousson > Cc: Santosh Shilimkar > Cc: Paul Walmsley > Cc: Tony Lindgren > Cc: linux-omap@vger.kernel.org Acked-by: Kevin Hilman Arnd, to make it easy, below is a pull request for this fix on top of arm-soc/omap/omap5. Kevin The following changes since commit 6503a8e109a639760408f874c1251060d563942e: ARM: OMAP5: Remove unused include for ocp2scp (2013-06-09 21:17:15 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git tags/omap-pm-v3.11/fixes/omap5-voltdm for you to fetch changes up to 2ac524f151dbecb862c95b8f433267772caa800e: ARM: OMAP5: voltagedomain data: remove temporary OMAP4 voltage data (2013-06-25 17:11:06 -0700) OMAP5: PM: fix boot by removing unneeded dummy voltage domain data Nishanth Menon (1): ARM: OMAP5: voltagedomain data: remove temporary OMAP4 voltage data arch/arm/mach-omap2/voltagedomains54xx_data.c | 10 -- 1 file changed, 10 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP5: voltagedomain data: remove temporary OMAP4 voltage data
On Tuesday 25 June 2013 07:56 PM, Nishanth Menon wrote: > commit 20d49e9ccfece526db755940721aa13e331936d4 > (ARM: OMAP5: voltagedomain data: Add OMAP5 voltage domain data) > > Introduced dummy volt data for OMAP5 with OMAP4460 voltage information. > > However with the fixes introduced in later patches > > commit cd8abed1da91a3250aa4b3857479613a2b446f84 > (ARM: OMAP2+: Powerdomain: Remove the need to always have a voltdm > associated to a pwrdm) > > We are no longer restricted in that respect. Further, OPP voltage > information is supposed to be provided by dts information. This needs > to be added in future patches as various voltage modules are converted > to dts. > > This also fixes the build breakage for voltagedomains54xx_data.c when just > OMAP5 SoC is enabled: https://patchwork.kernel.org/patch/2764191/ > > Reported-by: Arnd Bergmann > Signed-off-by: Nishanth Menon > Cc: Kevin Hilman > Cc: Benoit Cousson > Cc: Santosh Shilimkar > Cc: Paul Walmsley > Cc: Tony Lindgren > Cc: linux-omap@vger.kernel.org > --- > Thanks Nishant for the patch. Acked-by: Santosh Shilimkar -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP5: voltagedomain data: remove temporary OMAP4 voltage data
commit 20d49e9ccfece526db755940721aa13e331936d4 (ARM: OMAP5: voltagedomain data: Add OMAP5 voltage domain data) Introduced dummy volt data for OMAP5 with OMAP4460 voltage information. However with the fixes introduced in later patches commit cd8abed1da91a3250aa4b3857479613a2b446f84 (ARM: OMAP2+: Powerdomain: Remove the need to always have a voltdm associated to a pwrdm) We are no longer restricted in that respect. Further, OPP voltage information is supposed to be provided by dts information. This needs to be added in future patches as various voltage modules are converted to dts. This also fixes the build breakage for voltagedomains54xx_data.c when just OMAP5 SoC is enabled: https://patchwork.kernel.org/patch/2764191/ Reported-by: Arnd Bergmann Signed-off-by: Nishanth Menon Cc: Kevin Hilman Cc: Benoit Cousson Cc: Santosh Shilimkar Cc: Paul Walmsley Cc: Tony Lindgren Cc: linux-omap@vger.kernel.org --- Discussed in thread: http://marc.info/?t=13718466442&r=1&w=2 Tested against linux-next-20130625 + git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux.git for_3.11/out_of_tree/omap5_clk_data with omap2plus_defconfig on OMAP5432 uEVM. NOTE: we still have the issue reported in https://patchwork.kernel.org/patch/2568091/ and "ARM: OMAP2+: AM43x: resolve SMP related build error" does not help solve the problem either for OMAP5. arch/arm/mach-omap2/voltagedomains54xx_data.c | 10 -- 1 file changed, 10 deletions(-) diff --git a/arch/arm/mach-omap2/voltagedomains54xx_data.c b/arch/arm/mach-omap2/voltagedomains54xx_data.c index 72b8971..33d22b8 100644 --- a/arch/arm/mach-omap2/voltagedomains54xx_data.c +++ b/arch/arm/mach-omap2/voltagedomains54xx_data.c @@ -85,16 +85,6 @@ void __init omap54xx_voltagedomains_init(void) struct voltagedomain *voltdm; int i; - /* -* XXX Will depend on the process, validation, and binning -* for the currently-running IC. Use OMAP4 data for time being. -*/ -#ifdef CONFIG_PM_OPP - omap5_voltdm_mpu.volt_data = omap446x_vdd_mpu_volt_data; - omap5_voltdm_mm.volt_data = omap446x_vdd_iva_volt_data; - omap5_voltdm_core.volt_data = omap446x_vdd_core_volt_data; -#endif - for (i = 0; voltdm = voltagedomains_omap5[i], voltdm; i++) voltdm->sys_clk.name = sys_clk_name; -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: omap5: build opp4xxx_data.c
On Tuesday 25 June 2013 07:02 PM, Nishanth Menon wrote: > On 18:43-20130625, Santosh Shilimkar wrote: >> On Tuesday 25 June 2013 06:36 PM, Nishanth Menon wrote: >>> On 16:59-20130625, Santosh Shilimkar wrote: >>>> On Tuesday 25 June 2013 04:56 PM, Kevin Hilman wrote: >>>>> Santosh Shilimkar writes: >>>>> >>>>>> On Tuesday 25 June 2013 04:17 PM, Nishanth Menon wrote: >>>>>>> On Tue, Jun 25, 2013 at 3:12 PM, Santosh Shilimkar >>>>>>> wrote: >>>>>>>> >>>>>>>> Well having voltage data in voltage domain was not my decision ;-) >>>>>>>> Instead of creating another set of dummy data, I just used what >>>>>>>> is out there(OMAP4) with clear comment that data needs to be updated. >>>>>>>> I don't see any problem in this considering we have devices booting >>>>>>>> and working nicely for OMAP5 >>>>>>> I really wish the OMAP5 devices(the latest ones from Fab) I have would >>>>>>> like to function at OMAP4 configurations! Unfortunately the devices >>>>>>> tend to follow the data manual for OMAP5. >>>>>>> *if* there is no need for it to boot, I suggest removing it. >>>>>>> >>>>>> I don't understand you. For OMAP5, that data without voltage >>>>>> controller support doesn't do anything bad. Since there was some >>>>>> dependency of voltage domain association whit PD's, I have to keep >>>>>> that. I never claimed that OMAP4 settings would work for OMAP5 >>>>>> in absolute terms. >>>>>> >>>>>> Feel free to post a patch with right data which you seems to have. >>>>>> I don't mind you removing that data as long as the device >>>>>> continues to boot. Patch welcome. >>>>> >>>>> Thanks to Rajendra's cleanup, I don't think we need dummy data anymore: >>>>> >>>>>http://marc.info/?l=linux-omap&m=137147503827947&w=2 >>>>> >>>>> That series is queued for v3.11. >>>>> >>>> I knew the series but wasn't sure about it getting queued up >>>> for 3.11. Nice to see the dependency is getting removed. >>> >>> Anyways, I tried booting up a kernel built on linux-next-20130625 >>> with omap2plus_defconfig and [1] on OMAP5uEVM and all I see is: >>> Importing environment from mmc0 ... >>> reading //zImage >>> 4030024 bytes read in 198 ms (19.4 MiB/s) >>> reading //omap5-uevm.dtb >>> 17729 bytes read in 16 ms (1.1 MiB/s) >>> [..] >>> ## Flattened Device Tree blob at 80f8 >>> Booting using the fdt blob at 0x80f8 >>> Using Device Tree in place at 80f8, end 80f87540 >>> >>> Starting kernel ... >>> >>> If someone can point me to a functional base, it'd be nice, or if there >>> is a known pending fix, it'd be better.. >>> Taking http://marc.info/?l=linux-omap&m=136984555408516&w=2 and rebasing >>> on linux next tag resulted practically in NOP. >>> >> As mentioned in the cover-letter, you are probably missing the clock data. >> >> That means for the boot, one clock data patch needs to be applied. >> It is available on my git tree in 'out_of_tree/omap5_clk_data' branch. >> --- > Thanks on the hint, I had missed it. I merged the > for_3.11/out_of_tree/omap5_clk_data from > git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux.git > to linux-next-20130625 with a minor conflict in arch/arm/mach-omap2/io.c > > omap2plus_defconfig: http://pastebin.com/rTuEn0H6 > Then applied: > diff --git a/arch/arm/mach-omap2/voltagedomains54xx_data.c > b/arch/arm/mach-omap2/voltagedomains54xx_data.c > index 72b8971..89a5589f 100644 > --- a/arch/arm/mach-omap2/voltagedomains54xx_data.c > +++ b/arch/arm/mach-omap2/voltagedomains54xx_data.c > @@ -89,11 +89,6 @@ void __init omap54xx_voltagedomains_init(void) >* XXX Will depend on the process, validation, and binning >* for the currently-running IC. Use OMAP4 data for time being. >*/ > -#ifdef CONFIG_PM_OPP > - omap5_voltdm_mpu.volt_data = omap446x_vdd_mpu_volt_data; > - omap5_voltdm_mm.volt_data = omap446x_vdd_iva_volt_data; > - omap5_voltdm_core.volt_data = omap446x_vdd_core_volt_data; > -#endif > > for (i = 0; voltdm = voltagedomains_omap5[i], voltdm; i++) > voltdm->sys_clk.name = sys_clk_name; > Result: http://pastebin.com/t8cdd7uj > > As kevin mentioned, we can boot without registering wrong voltage data. > With Rajendra's series included now, Yes. Can you send an updated patch with description for Paul to pick it up ? Regards, Santosh -- 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: omap5: build opp4xxx_data.c
On 18:43-20130625, Santosh Shilimkar wrote: > On Tuesday 25 June 2013 06:36 PM, Nishanth Menon wrote: > > On 16:59-20130625, Santosh Shilimkar wrote: > >> On Tuesday 25 June 2013 04:56 PM, Kevin Hilman wrote: > >>> Santosh Shilimkar writes: > >>> > >>>> On Tuesday 25 June 2013 04:17 PM, Nishanth Menon wrote: > >>>>> On Tue, Jun 25, 2013 at 3:12 PM, Santosh Shilimkar > >>>>> wrote: > >>>>>> > >>>>>> Well having voltage data in voltage domain was not my decision ;-) > >>>>>> Instead of creating another set of dummy data, I just used what > >>>>>> is out there(OMAP4) with clear comment that data needs to be updated. > >>>>>> I don't see any problem in this considering we have devices booting > >>>>>> and working nicely for OMAP5 > >>>>> I really wish the OMAP5 devices(the latest ones from Fab) I have would > >>>>> like to function at OMAP4 configurations! Unfortunately the devices > >>>>> tend to follow the data manual for OMAP5. > >>>>> *if* there is no need for it to boot, I suggest removing it. > >>>>> > >>>> I don't understand you. For OMAP5, that data without voltage > >>>> controller support doesn't do anything bad. Since there was some > >>>> dependency of voltage domain association whit PD's, I have to keep > >>>> that. I never claimed that OMAP4 settings would work for OMAP5 > >>>> in absolute terms. > >>>> > >>>> Feel free to post a patch with right data which you seems to have. > >>>> I don't mind you removing that data as long as the device > >>>> continues to boot. Patch welcome. > >>> > >>> Thanks to Rajendra's cleanup, I don't think we need dummy data anymore: > >>> > >>>http://marc.info/?l=linux-omap&m=137147503827947&w=2 > >>> > >>> That series is queued for v3.11. > >>> > >> I knew the series but wasn't sure about it getting queued up > >> for 3.11. Nice to see the dependency is getting removed. > > > > Anyways, I tried booting up a kernel built on linux-next-20130625 > > with omap2plus_defconfig and [1] on OMAP5uEVM and all I see is: > > Importing environment from mmc0 ... > > reading //zImage > > 4030024 bytes read in 198 ms (19.4 MiB/s) > > reading //omap5-uevm.dtb > > 17729 bytes read in 16 ms (1.1 MiB/s) > > [..] > > ## Flattened Device Tree blob at 80f8 > > Booting using the fdt blob at 0x80f8 > > Using Device Tree in place at 80f8, end 80f87540 > > > > Starting kernel ... > > > > If someone can point me to a functional base, it'd be nice, or if there > > is a known pending fix, it'd be better.. > > Taking http://marc.info/?l=linux-omap&m=136984555408516&w=2 and rebasing > > on linux next tag resulted practically in NOP. > > > As mentioned in the cover-letter, you are probably missing the clock data. > > That means for the boot, one clock data patch needs to be applied. > It is available on my git tree in 'out_of_tree/omap5_clk_data' branch. > --- Thanks on the hint, I had missed it. I merged the for_3.11/out_of_tree/omap5_clk_data from git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux.git to linux-next-20130625 with a minor conflict in arch/arm/mach-omap2/io.c omap2plus_defconfig: http://pastebin.com/rTuEn0H6 Then applied: diff --git a/arch/arm/mach-omap2/voltagedomains54xx_data.c b/arch/arm/mach-omap2/voltagedomains54xx_data.c index 72b8971..89a5589f 100644 --- a/arch/arm/mach-omap2/voltagedomains54xx_data.c +++ b/arch/arm/mach-omap2/voltagedomains54xx_data.c @@ -89,11 +89,6 @@ void __init omap54xx_voltagedomains_init(void) * XXX Will depend on the process, validation, and binning * for the currently-running IC. Use OMAP4 data for time being. */ -#ifdef CONFIG_PM_OPP - omap5_voltdm_mpu.volt_data = omap446x_vdd_mpu_volt_data; - omap5_voltdm_mm.volt_data = omap446x_vdd_iva_volt_data; - omap5_voltdm_core.volt_data = omap446x_vdd_core_volt_data; -#endif for (i = 0; voltdm = voltagedomains_omap5[i], voltdm; i++) voltdm->sys_clk.name = sys_clk_name; Result: http://pastebin.com/t8cdd7uj As kevin mentioned, we can boot without registering wrong voltage data. -- 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] ARM: omap5: build opp4xxx_data.c
On Tuesday 25 June 2013 06:36 PM, Nishanth Menon wrote: > On 16:59-20130625, Santosh Shilimkar wrote: >> On Tuesday 25 June 2013 04:56 PM, Kevin Hilman wrote: >>> Santosh Shilimkar writes: >>> >>>> On Tuesday 25 June 2013 04:17 PM, Nishanth Menon wrote: >>>>> On Tue, Jun 25, 2013 at 3:12 PM, Santosh Shilimkar >>>>> wrote: >>>>>> >>>>>> Well having voltage data in voltage domain was not my decision ;-) >>>>>> Instead of creating another set of dummy data, I just used what >>>>>> is out there(OMAP4) with clear comment that data needs to be updated. >>>>>> I don't see any problem in this considering we have devices booting >>>>>> and working nicely for OMAP5 >>>>> I really wish the OMAP5 devices(the latest ones from Fab) I have would >>>>> like to function at OMAP4 configurations! Unfortunately the devices >>>>> tend to follow the data manual for OMAP5. >>>>> *if* there is no need for it to boot, I suggest removing it. >>>>> >>>> I don't understand you. For OMAP5, that data without voltage >>>> controller support doesn't do anything bad. Since there was some >>>> dependency of voltage domain association whit PD's, I have to keep >>>> that. I never claimed that OMAP4 settings would work for OMAP5 >>>> in absolute terms. >>>> >>>> Feel free to post a patch with right data which you seems to have. >>>> I don't mind you removing that data as long as the device >>>> continues to boot. Patch welcome. >>> >>> Thanks to Rajendra's cleanup, I don't think we need dummy data anymore: >>> >>>http://marc.info/?l=linux-omap&m=137147503827947&w=2 >>> >>> That series is queued for v3.11. >>> >> I knew the series but wasn't sure about it getting queued up >> for 3.11. Nice to see the dependency is getting removed. > > Anyways, I tried booting up a kernel built on linux-next-20130625 > with omap2plus_defconfig and [1] on OMAP5uEVM and all I see is: > Importing environment from mmc0 ... > reading //zImage > 4030024 bytes read in 198 ms (19.4 MiB/s) > reading //omap5-uevm.dtb > 17729 bytes read in 16 ms (1.1 MiB/s) > [..] > ## Flattened Device Tree blob at 80f8 > Booting using the fdt blob at 0x80f8 > Using Device Tree in place at 80f8, end 80f87540 > > Starting kernel ... > > If someone can point me to a functional base, it'd be nice, or if there > is a known pending fix, it'd be better.. > Taking http://marc.info/?l=linux-omap&m=136984555408516&w=2 and rebasing > on linux next tag resulted practically in NOP. > As mentioned in the cover-letter, you are probably missing the clock data. That means for the boot, one clock data patch needs to be applied. It is available on my git tree in 'out_of_tree/omap5_clk_data' branch. --- Regards, Santosh -- 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: omap5: build opp4xxx_data.c
On 16:59-20130625, Santosh Shilimkar wrote: > On Tuesday 25 June 2013 04:56 PM, Kevin Hilman wrote: > > Santosh Shilimkar writes: > > > >> On Tuesday 25 June 2013 04:17 PM, Nishanth Menon wrote: > >>> On Tue, Jun 25, 2013 at 3:12 PM, Santosh Shilimkar > >>> wrote: > >>>> > >>>> Well having voltage data in voltage domain was not my decision ;-) > >>>> Instead of creating another set of dummy data, I just used what > >>>> is out there(OMAP4) with clear comment that data needs to be updated. > >>>> I don't see any problem in this considering we have devices booting > >>>> and working nicely for OMAP5 > >>> I really wish the OMAP5 devices(the latest ones from Fab) I have would > >>> like to function at OMAP4 configurations! Unfortunately the devices > >>> tend to follow the data manual for OMAP5. > >>> *if* there is no need for it to boot, I suggest removing it. > >>> > >> I don't understand you. For OMAP5, that data without voltage > >> controller support doesn't do anything bad. Since there was some > >> dependency of voltage domain association whit PD's, I have to keep > >> that. I never claimed that OMAP4 settings would work for OMAP5 > >> in absolute terms. > >> > >> Feel free to post a patch with right data which you seems to have. > >> I don't mind you removing that data as long as the device > >> continues to boot. Patch welcome. > > > > Thanks to Rajendra's cleanup, I don't think we need dummy data anymore: > > > >http://marc.info/?l=linux-omap&m=137147503827947&w=2 > > > > That series is queued for v3.11. > > > I knew the series but wasn't sure about it getting queued up > for 3.11. Nice to see the dependency is getting removed. Anyways, I tried booting up a kernel built on linux-next-20130625 with omap2plus_defconfig and [1] on OMAP5uEVM and all I see is: Importing environment from mmc0 ... reading //zImage 4030024 bytes read in 198 ms (19.4 MiB/s) reading //omap5-uevm.dtb 17729 bytes read in 16 ms (1.1 MiB/s) [..] ## Flattened Device Tree blob at 80f8 Booting using the fdt blob at 0x80f8 Using Device Tree in place at 80f8, end 80f87540 Starting kernel ... If someone can point me to a functional base, it'd be nice, or if there is a known pending fix, it'd be better.. Taking http://marc.info/?l=linux-omap&m=136984555408516&w=2 and rebasing on linux next tag resulted practically in NOP. [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2013-June/178209.html -- 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: linux-next: panda build failed at arch/arm/mach-omap2/omap4-restart.c
Naresh Kamboju writes:
> ping
This is a known issue[1] and already has some proposed fixes, they are just
not merged yet.
Kevin
[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2013-June/178209.html
> On 23 June 2013 13:53, Naresh Kamboju wrote:
>> Hi,
>>
>> panda build broken on linux-next branch
>>
>> kernel_config=omap2plus_defconfig
>> KERNEL_VERSION=3.10.0-rc6
>> KERNEL_GIT=git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
>> KERNEL_COMMIT=e1a86578747376f08985627c84df088a5d0d1e92
>>
>> Build error log :
>> ---
>> 04:43:18 CC arch/arm/mach-omap2/omap4-restart.o
>> 04:43:18
>> /mnt/ci_build/workspace/linux-next/hwpack/panda/label/kernel_cloud/arch/arm/mach-omap2/omap4-restart.c:21:28:
>> warning: ‘enum reboot_mode’ declared inside parameter list [enabled by
>> default]
>> 04:43:18 void omap44xx_restart(enum reboot_mode mode, const char *cmd)
>> 04:43:18 ^
>> 04:43:18
>> /mnt/ci_build/workspace/linux-next/hwpack/panda/label/kernel_cloud/arch/arm/mach-omap2/omap4-restart.c:21:28:
>> warning: its scope is only this definition or declaration, which is
>> probably not what you want [enabled by default]
>> 04:43:18
>> /mnt/ci_build/workspace/linux-next/hwpack/panda/label/kernel_cloud/arch/arm/mach-omap2/omap4-restart.c:21:40:
>> error: parameter 1 (‘mode’) has incomplete type
>> 04:43:18 void omap44xx_restart(enum reboot_mode mode, const char *cmd)
>> 04:43:18 ^
>> 04:43:18
>> /mnt/ci_build/workspace/linux-next/hwpack/panda/label/kernel_cloud/arch/arm/mach-omap2/omap4-restart.c:21:6:
>> warning: function declaration isn’t a prototype [-Wstrict-prototypes]
>> 04:43:18 void omap44xx_restart(enum reboot_mode mode, const char *cmd)
>> 04:43:18 ^
>> 04:43:18 make[2]: *** [arch/arm/mach-omap2/omap4-restart.o] Error 1
>> 04:43:18 make[1]: *** [arch/arm/mach-omap2] Error 2
>>
>> Full build log:
>> --
>> https://ci.linaro.org/jenkins/job/linux-next/hwpack=panda,label=kernel_cloud/lastBuild/console
>>
>> Suspecting patch which caused build failed:
>>
>> commit b61cdf2aebc5cd2f4efc4e0cbebeb8a91884a43e
>> Author: Robin Holt
>> Date: Wed Jun 19 10:08:43 2013 +1000
>>
>> reboot: arm: change reboot_mode to use enum reboot_mode
>>
>> Preparing to move the parsing of reboot= to generic kernel code forces the
>> change in reboot_mode handling to use the enum.
>>
>> Signed-off-by: Robin Holt
>>
>> ...
>> diff --git a/arch/arm/mach-omap2/omap4-restart.c
>> b/arch/arm/mach-omap2/omap4-restart.c
>> index f90e02e..652adde 100644
>> --- a/arch/arm/mach-omap2/omap4-restart.c
>> +++ b/arch/arm/mach-omap2/omap4-restart.c
>> @@ -18,7 +18,7 @@
>> * Resets the SoC. For @cmd, see the 'reboot' syscall in
>> * kernel/sys.c. No return value.
>> */
>> -void omap44xx_restart(char mode, const char *cmd)
>> +void omap44xx_restart(enum reboot_mode mode, const char *cmd)
>> {
>> /* XXX Should save 'cmd' into scratchpad for use after reboot */
>> omap4_prminst_global_warm_sw_reset(); /* never returns */
>> ...
>>
>> Best regards
>> Naresh Kamboju
> --
> 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: omap5: build opp4xxx_data.c
On Tuesday 25 June 2013 04:56 PM, Kevin Hilman wrote: > Santosh Shilimkar writes: > >> On Tuesday 25 June 2013 04:17 PM, Nishanth Menon wrote: >>> On Tue, Jun 25, 2013 at 3:12 PM, Santosh Shilimkar >>> wrote: Well having voltage data in voltage domain was not my decision ;-) Instead of creating another set of dummy data, I just used what is out there(OMAP4) with clear comment that data needs to be updated. I don't see any problem in this considering we have devices booting and working nicely for OMAP5 >>> I really wish the OMAP5 devices(the latest ones from Fab) I have would >>> like to function at OMAP4 configurations! Unfortunately the devices >>> tend to follow the data manual for OMAP5. >>> *if* there is no need for it to boot, I suggest removing it. >>> >> I don't understand you. For OMAP5, that data without voltage >> controller support doesn't do anything bad. Since there was some >> dependency of voltage domain association whit PD's, I have to keep >> that. I never claimed that OMAP4 settings would work for OMAP5 >> in absolute terms. >> >> Feel free to post a patch with right data which you seems to have. >> I don't mind you removing that data as long as the device >> continues to boot. Patch welcome. > > Thanks to Rajendra's cleanup, I don't think we need dummy data anymore: > >http://marc.info/?l=linux-omap&m=137147503827947&w=2 > > That series is queued for v3.11. > I knew the series but wasn't sure about it getting queued up for 3.11. Nice to see the dependency is getting removed. Regards, Santosh -- 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: omap5: build opp4xxx_data.c
Santosh Shilimkar writes: > On Tuesday 25 June 2013 04:17 PM, Nishanth Menon wrote: >> On Tue, Jun 25, 2013 at 3:12 PM, Santosh Shilimkar >> wrote: >>> >>> Well having voltage data in voltage domain was not my decision ;-) >>> Instead of creating another set of dummy data, I just used what >>> is out there(OMAP4) with clear comment that data needs to be updated. >>> I don't see any problem in this considering we have devices booting >>> and working nicely for OMAP5 >> I really wish the OMAP5 devices(the latest ones from Fab) I have would >> like to function at OMAP4 configurations! Unfortunately the devices >> tend to follow the data manual for OMAP5. >> *if* there is no need for it to boot, I suggest removing it. >> > I don't understand you. For OMAP5, that data without voltage > controller support doesn't do anything bad. Since there was some > dependency of voltage domain association whit PD's, I have to keep > that. I never claimed that OMAP4 settings would work for OMAP5 > in absolute terms. > > Feel free to post a patch with right data which you seems to have. > I don't mind you removing that data as long as the device > continues to boot. Patch welcome. Thanks to Rajendra's cleanup, I don't think we need dummy data anymore: http://marc.info/?l=linux-omap&m=137147503827947&w=2 That series is queued 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: OMAP baseline test results for v3.10-rc6
Hi, On Tue, Jun 25, 2013 at 06:20:51PM +, Paul Walmsley wrote: > Am certainly open to the idea that there's something wrong with the way > that I'm booting either of these. But AFAIK no one's been able to > identify exactly what it could be. I haven't had the time recently to > spend hours going through the various permutations, given all the other > breakage :-( BeagleBone-white has the additional complication that it is > not easy to automate, due to the way that power is delivered to the board, > so there is an extra dimension of difficulty there. oh yeah, you can use something like [1] for that [1] http://www.cleware-shop.de/epages/63698188.sf/en_US/?ObjectPath=/Shops/63698188/Products/01 -- balbi signature.asc Description: Digital signature
Re: [PATCH] ARM: omap5: build opp4xxx_data.c
On Tuesday 25 June 2013 04:17 PM, Nishanth Menon wrote: > On Tue, Jun 25, 2013 at 3:12 PM, Santosh Shilimkar > wrote: >> >> Well having voltage data in voltage domain was not my decision ;-) >> Instead of creating another set of dummy data, I just used what >> is out there(OMAP4) with clear comment that data needs to be updated. >> I don't see any problem in this considering we have devices booting >> and working nicely for OMAP5 > I really wish the OMAP5 devices(the latest ones from Fab) I have would > like to function at OMAP4 configurations! Unfortunately the devices > tend to follow the data manual for OMAP5. > *if* there is no need for it to boot, I suggest removing it. > I don't understand you. For OMAP5, that data without voltage controller support doesn't do anything bad. Since there was some dependency of voltage domain association whit PD's, I have to keep that. I never claimed that OMAP4 settings would work for OMAP5 in absolute terms. Feel free to post a patch with right data which you seems to have. I don't mind you removing that data as long as the device continues to boot. Patch welcome. Thanks !! Regards, Santosh -- 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 baseline test results for v3.10-rc6
On 06/25/2013 03:57 PM, Kevin Hilman wrote: > Tom Rini writes: > >> On 06/25/2013 02:20 PM, Paul Walmsley wrote: >>> + Vaibhav and Kevin >>> >>> Hi, >>> >>> On Tue, 25 Jun 2013, Felipe Balbi wrote: >>> On Mon, Jun 17, 2013 at 05:23:17AM +, Paul Walmsley wrote: > Boot to userspace: > FAIL ( 3/12): 37xxevm, am335xbone, am335xbonelt Paul, we have at least 2 different folks who can't reproduce your bone and bone black boot to userspace failures. I wonder how you're trying to boot them. Care to share your test scripts ? >>> >>> Sure... the methodology is completely open and has been posted in the >>> online logs since the first test cycle. (For some reason, almost no one >>> clicks through the test directory trees that I post online. Is this a >>> documentation issue? What can we do to make it easier for people to >>> explore this?) >> >> Well, another link never hurts the search results :) >> >> [snip] >>> Am certainly open to the idea that there's something wrong with the way >>> that I'm booting either of these. But AFAIK no one's been able to >>> identify exactly what it could be. I haven't had the time recently to >>> spend hours going through the various permutations, given all the other >>> breakage :-( BeagleBone-white has the additional complication that it is >>> not easy to automate, due to the way that power is delivered to the board, >>> so there is an extra dimension of difficulty there. >> >> Ah-ha, I reproduced your failure. If I make up a concat uImage + DTB, >> rather than pass them separately, it fails to boot. If you switch to >> mainline U-Boot (v2012.10 or later) you get support for separate image + >> dtb (v2013.04 gives you bootz and zImage support). v2013.04 will also >> work out of the box for BeagleBone-Black. > > Just to confirm, my problems with mainline were with appended DTB also. > Separate DTB and zImage work fine (at least using u-boot v2013.04.) > > That being said, appended DTB should still work, so there's a bug hiding > someplace that needs to be found fixed. Since we've narrowed down what the problem is, someone can bisect it now, yeah. > Can you guys update your tests to test appended DTB also? What is the official position on appending DTBs? -- Tom -- 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: omap5: build opp4xxx_data.c
On Tue, Jun 25, 2013 at 3:12 PM, Santosh Shilimkar wrote: > > Well having voltage data in voltage domain was not my decision ;-) > Instead of creating another set of dummy data, I just used what > is out there(OMAP4) with clear comment that data needs to be updated. > I don't see any problem in this considering we have devices booting > and working nicely for OMAP5 I really wish the OMAP5 devices(the latest ones from Fab) I have would like to function at OMAP4 configurations! Unfortunately the devices tend to follow the data manual for OMAP5. *if* there is no need for it to boot, I suggest removing it. 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] ARM: omap5: build opp4xxx_data.c
On Tuesday 25 June 2013 03:57 PM, Nishanth Menon wrote: > On 15:55-20130625, Santosh Shilimkar wrote: >> On Tuesday 25 June 2013 03:20 PM, Paul Walmsley wrote: >>> Santosh, >>> >>> On Fri, 21 Jun 2013, Nishanth Menon wrote: >>> >>>>/* >>>> * XXX Will depend on the process, validation, and binning >>>> * for the currently-running IC. Use OMAP4 data for time being. >>>> */ >>>> #ifdef CONFIG_PM_OPP >>>>omap5_voltdm_mpu.volt_data = omap446x_vdd_mpu_volt_data; >>>>omap5_voltdm_mm.volt_data = omap446x_vdd_iva_volt_data; >>>>omap5_voltdm_core.volt_data = omap446x_vdd_core_volt_data; >>>> #endif >>>> >>>> Should we just remove this instead? these are obviously wrong. >>> >>> Are the OMAP4460 values expected to work and be safe for OMAP5, or not? >>> If the latter, please send a patch to remove them. >>> >> The plan was to update the data along with and VC OPP update >> for OMAP5 which Keerthy is working on. As such without VC code, >> this data is not doing anything so it is safe. > opp data in mach-omap2 is no longer used. everything is moving to dts > and OMAP5 is dts only. *IF* this is preventing boot, then we can hack > something in while we continue to debate on what we RFCs we have posted > so far. > The boot is just fine as I said, the setting doesn't have any effect without the code which is going to use that data. > Further, OPPs are NOT for Voltage Controller (VC). It is meant for > specific domains like MPU, SGX etc.. Having that data here, especially > wrong data is just plain wrong IMHO. > Well having voltage data in voltage domain was not my decision ;-) Instead of creating another set of dummy data, I just used what is out there(OMAP4) with clear comment that data needs to be updated. I don't see any problem in this considering we have devices booting and working nicely for OMAP5 Regards, Santosh -- 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: omap5: build opp4xxx_data.c
On 15:55-20130625, Santosh Shilimkar wrote: > On Tuesday 25 June 2013 03:20 PM, Paul Walmsley wrote: > > Santosh, > > > > On Fri, 21 Jun 2013, Nishanth Menon wrote: > > > >>/* > >> * XXX Will depend on the process, validation, and binning > >> * for the currently-running IC. Use OMAP4 data for time being. > >> */ > >> #ifdef CONFIG_PM_OPP > >>omap5_voltdm_mpu.volt_data = omap446x_vdd_mpu_volt_data; > >>omap5_voltdm_mm.volt_data = omap446x_vdd_iva_volt_data; > >>omap5_voltdm_core.volt_data = omap446x_vdd_core_volt_data; > >> #endif > >> > >> Should we just remove this instead? these are obviously wrong. > > > > Are the OMAP4460 values expected to work and be safe for OMAP5, or not? > > If the latter, please send a patch to remove them. > > > The plan was to update the data along with and VC OPP update > for OMAP5 which Keerthy is working on. As such without VC code, > this data is not doing anything so it is safe. opp data in mach-omap2 is no longer used. everything is moving to dts and OMAP5 is dts only. *IF* this is preventing boot, then we can hack something in while we continue to debate on what we RFCs we have posted so far. Further, OPPs are NOT for Voltage Controller (VC). It is meant for specific domains like MPU, SGX etc.. Having that data here, especially wrong data is just plain wrong IMHO. -- 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: OMAP baseline test results for v3.10-rc6
Tom Rini writes: > On 06/25/2013 02:20 PM, Paul Walmsley wrote: >> + Vaibhav and Kevin >> >> Hi, >> >> On Tue, 25 Jun 2013, Felipe Balbi wrote: >> >>> On Mon, Jun 17, 2013 at 05:23:17AM +, Paul Walmsley wrote: Boot to userspace: FAIL ( 3/12): 37xxevm, am335xbone, am335xbonelt >>> >>> Paul, we have at least 2 different folks who can't reproduce your bone >>> and bone black boot to userspace failures. I wonder how you're trying to >>> boot them. >>> >>> Care to share your test scripts ? >> >> Sure... the methodology is completely open and has been posted in the >> online logs since the first test cycle. (For some reason, almost no one >> clicks through the test directory trees that I post online. Is this a >> documentation issue? What can we do to make it easier for people to >> explore this?) > > Well, another link never hurts the search results :) > > [snip] >> Am certainly open to the idea that there's something wrong with the way >> that I'm booting either of these. But AFAIK no one's been able to >> identify exactly what it could be. I haven't had the time recently to >> spend hours going through the various permutations, given all the other >> breakage :-( BeagleBone-white has the additional complication that it is >> not easy to automate, due to the way that power is delivered to the board, >> so there is an extra dimension of difficulty there. > > Ah-ha, I reproduced your failure. If I make up a concat uImage + DTB, > rather than pass them separately, it fails to boot. If you switch to > mainline U-Boot (v2012.10 or later) you get support for separate image + > dtb (v2013.04 gives you bootz and zImage support). v2013.04 will also > work out of the box for BeagleBone-Black. Just to confirm, my problems with mainline were with appended DTB also. Separate DTB and zImage work fine (at least using u-boot v2013.04.) That being said, appended DTB should still work, so there's a bug hiding someplace that needs to be found fixed. Can you guys update your tests to test appended DTB also? 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] ARM: omap5: build opp4xxx_data.c
On Tuesday 25 June 2013 03:20 PM, Paul Walmsley wrote: > Santosh, > > On Fri, 21 Jun 2013, Nishanth Menon wrote: > >> /* >> * XXX Will depend on the process, validation, and binning >> * for the currently-running IC. Use OMAP4 data for time being. >> */ >> #ifdef CONFIG_PM_OPP >> omap5_voltdm_mpu.volt_data = omap446x_vdd_mpu_volt_data; >> omap5_voltdm_mm.volt_data = omap446x_vdd_iva_volt_data; >> omap5_voltdm_core.volt_data = omap446x_vdd_core_volt_data; >> #endif >> >> Should we just remove this instead? these are obviously wrong. > > Are the OMAP4460 values expected to work and be safe for OMAP5, or not? > If the latter, please send a patch to remove them. > The plan was to update the data along with and VC OPP update for OMAP5 which Keerthy is working on. As such without VC code, this data is not doing anything so it is safe. Regards, Santosh -- 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] Documentation: dt: bindings: TI WiLink modules
(oh crap, now *really* fixed the ARM mailing list address) On Tue, 2013-06-25 at 11:35 +0300, Luciano Coelho wrote: > Add device tree bindings documentation for the TI WiLink modules. > Currently only the WLAN part of the WiLink6, WiLink7 and WiLink8 > modules is supported. > > Signed-off-by: Luciano Coelho > --- > > I created a new directory under net to contain wireless bindings > documentation. > > The actual implementation in the driver will follow separately. > > .../devicetree/bindings/net/wireless/ti-wilink.txt | 46 > > 1 file changed, 46 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/net/wireless/ti-wilink.txt > > diff --git a/Documentation/devicetree/bindings/net/wireless/ti-wilink.txt > b/Documentation/devicetree/bindings/net/wireless/ti-wilink.txt > new file mode 100644 > index 000..d8e8bfbb > --- /dev/null > +++ b/Documentation/devicetree/bindings/net/wireless/ti-wilink.txt > @@ -0,0 +1,46 @@ > +TI WiLink Wireless Modules Device Tree Bindings > +=== > + > +The WiLink modules provide wireless connectivity, such as WLAN, > +Bluetooth, FM and NFC. > + > +There are several different modules available, which can be grouped by > +their generation: WiLink6, WiLink7 and WiLink8. WiLink4 is not > +currently supported with device tree. > + > +Currently, only the WLAN portion of the modules is supported with > +device tree. > + > +Required properties: > + > + > +- compatible: should be "ti,wilink6", "ti,wilink7" or "ti,wilink8" > +- interrupt-parent: the interrupt controller > +- interrupts: out-of-band WLAN interrupt > + See the interrupt controller's bindings documentation for > + detailed definition. > + > +Optional properties: > + > + > +- refclock: the internal WLAN reference clock frequency (required for > + WiLink6 and WiLink7; not used for WiLink8). Must be one of the > + following: > + 0 = 19.2 MHz > + 1 = 26.0 MHz > + 2 = 38.4 MHz > + 3 = 52.0 MHz > + 4 = 38.4 MHz, XTAL > + 5 = 26.0 MHz, XTAL > + > +- tcxoclock: the internal WLAN TCXO clock frequency (required for > + WiLink7 not used for WiLink6 and WiLink8). Must be one of the > + following: > + 0 = 19.200 MHz > + 1 = 26.000 MHz > + 2 = 38.400 MHz > + 3 = 52.000 MHz > + 4 = 16.368 MHz > + 5 = 32.736 MHz > + 6 = 16.800 MHz > + 7 = 33.600 MHz If this is okay for everyone, can I push this via my tree (which goes to linux-wireless->net->linus)? I think it makes more sense to send the documentation together with the patch that actually implements the DT node parsing in the driver. -- Luca. -- 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] Documentation: dt: bindings: TI WiLink modules
(fixed the ARM mailing list address) On Tue, 2013-06-25 at 11:35 +0300, Luciano Coelho wrote: > Add device tree bindings documentation for the TI WiLink modules. > Currently only the WLAN part of the WiLink6, WiLink7 and WiLink8 > modules is supported. > > Signed-off-by: Luciano Coelho > --- > > I created a new directory under net to contain wireless bindings > documentation. > > The actual implementation in the driver will follow separately. > > .../devicetree/bindings/net/wireless/ti-wilink.txt | 46 > > 1 file changed, 46 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/net/wireless/ti-wilink.txt > > diff --git a/Documentation/devicetree/bindings/net/wireless/ti-wilink.txt > b/Documentation/devicetree/bindings/net/wireless/ti-wilink.txt > new file mode 100644 > index 000..d8e8bfbb > --- /dev/null > +++ b/Documentation/devicetree/bindings/net/wireless/ti-wilink.txt > @@ -0,0 +1,46 @@ > +TI WiLink Wireless Modules Device Tree Bindings > +=== > + > +The WiLink modules provide wireless connectivity, such as WLAN, > +Bluetooth, FM and NFC. > + > +There are several different modules available, which can be grouped by > +their generation: WiLink6, WiLink7 and WiLink8. WiLink4 is not > +currently supported with device tree. > + > +Currently, only the WLAN portion of the modules is supported with > +device tree. > + > +Required properties: > + > + > +- compatible: should be "ti,wilink6", "ti,wilink7" or "ti,wilink8" > +- interrupt-parent: the interrupt controller > +- interrupts: out-of-band WLAN interrupt > + See the interrupt controller's bindings documentation for > + detailed definition. > + > +Optional properties: > + > + > +- refclock: the internal WLAN reference clock frequency (required for > + WiLink6 and WiLink7; not used for WiLink8). Must be one of the > + following: > + 0 = 19.2 MHz > + 1 = 26.0 MHz > + 2 = 38.4 MHz > + 3 = 52.0 MHz > + 4 = 38.4 MHz, XTAL > + 5 = 26.0 MHz, XTAL > + > +- tcxoclock: the internal WLAN TCXO clock frequency (required for > + WiLink7 not used for WiLink6 and WiLink8). Must be one of the > + following: > + 0 = 19.200 MHz > + 1 = 26.000 MHz > + 2 = 38.400 MHz > + 3 = 52.000 MHz > + 4 = 16.368 MHz > + 5 = 32.736 MHz > + 6 = 16.800 MHz > + 7 = 33.600 MHz If this is okay for everyone, can I push this via my tree (which goes to linux-wireless->net->linus)? I think it makes more sense to send the documentation together with the patch that actually implements the DT node parsing in the driver. -- Luca. -- 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 baseline test results for v3.10-rc6
On 06/25/2013 02:20 PM, Paul Walmsley wrote: > + Vaibhav and Kevin > > Hi, > > On Tue, 25 Jun 2013, Felipe Balbi wrote: > >> On Mon, Jun 17, 2013 at 05:23:17AM +, Paul Walmsley wrote: >>> Boot to userspace: >>> FAIL ( 3/12): 37xxevm, am335xbone, am335xbonelt >> >> Paul, we have at least 2 different folks who can't reproduce your bone >> and bone black boot to userspace failures. I wonder how you're trying to >> boot them. >> >> Care to share your test scripts ? > > Sure... the methodology is completely open and has been posted in the > online logs since the first test cycle. (For some reason, almost no one > clicks through the test directory trees that I post online. Is this a > documentation issue? What can we do to make it easier for people to > explore this?) Well, another link never hurts the search results :) [snip] > Am certainly open to the idea that there's something wrong with the way > that I'm booting either of these. But AFAIK no one's been able to > identify exactly what it could be. I haven't had the time recently to > spend hours going through the various permutations, given all the other > breakage :-( BeagleBone-white has the additional complication that it is > not easy to automate, due to the way that power is delivered to the board, > so there is an extra dimension of difficulty there. Ah-ha, I reproduced your failure. If I make up a concat uImage + DTB, rather than pass them separately, it fails to boot. If you switch to mainline U-Boot (v2012.10 or later) you get support for separate image + dtb (v2013.04 gives you bootz and zImage support). v2013.04 will also work out of the box for BeagleBone-Black. And yeah, I feel your pain about power cycling BeagleBone-White. The QA folks here sent me one of the relay controllers they use, and I think Felipe is partial to one from phidgets. >> Also, if you could share the entire thing, we will add your scripts to >> our nightly tests as to try and avoid future regressions. > > It would be great to have TI folks running those tests, or something > similar to them! An early version of the test system has been shared with > a handful of folks, but it needs to be cleaned up further before broader > release. We've got "something similar", at least wrt boot tests. But since we use separate kernel + DT, we hadn't seen this problem. -- Tom -- 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: omap5: build opp4xxx_data.c
Santosh, On Fri, 21 Jun 2013, Nishanth Menon wrote: > /* >* XXX Will depend on the process, validation, and binning >* for the currently-running IC. Use OMAP4 data for time being. >*/ > #ifdef CONFIG_PM_OPP > omap5_voltdm_mpu.volt_data = omap446x_vdd_mpu_volt_data; > omap5_voltdm_mm.volt_data = omap446x_vdd_iva_volt_data; > omap5_voltdm_core.volt_data = omap446x_vdd_core_volt_data; > #endif > > Should we just remove this instead? these are obviously wrong. Are the OMAP4460 values expected to work and be safe for OMAP5, or not? If the latter, please send a patch to remove them. thanks - 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] usb: host: xhci-plat: release mem region while removing module
On Mon, Jun 24, 2013 at 05:22:24PM +0300, Felipe Balbi wrote: > On Fri, Jun 21, 2013 at 01:59:08PM +0530, George Cherian wrote: > > Do a release_mem_region of the hcd resource. Without this the > > subsequent insertion of module fails in request_mem_region. > > > > Signed-off-by: George Cherian > > very nice catch. > > Acked-by: Felipe Balbi > > You need to resend with: > > Cc: # v3.4+ > > Not sure if Sarah wants to take care of the stable tagging, though. I'll take care of the stable tagging. Sarah Sharp -- 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 baseline test results for v3.10-rc6
+ Vaibhav and Kevin Hi, On Tue, 25 Jun 2013, Felipe Balbi wrote: > On Mon, Jun 17, 2013 at 05:23:17AM +, Paul Walmsley wrote: > > Boot to userspace: > > FAIL ( 3/12): 37xxevm, am335xbone, am335xbonelt > > Paul, we have at least 2 different folks who can't reproduce your bone > and bone black boot to userspace failures. I wonder how you're trying to > boot them. > > Care to share your test scripts ? Sure... the methodology is completely open and has been posted in the online logs since the first test cycle. (For some reason, almost no one clicks through the test directory trees that I post online. Is this a documentation issue? What can we do to make it easier for people to explore this?) Anyway, for BeagleBone white, here's the last working test log, from 3.7: http://www.pwsan.com/omap/testlogs/test_v3.7/20121211094536/boot/am335xbone/am335xbone_log.txt The concatenated kernel and DTB, along with the Kconfig used to build, are here: http://www.pwsan.com/omap/testlogs/test_v3.7/20121211094536/build/am33xx_only/ The boot broke immediately afterwards with v3.8-rc1 and has never worked since: http://www.pwsan.com/omap/testlogs/test_v3.8-rc1/20121228031713/boot/am335xbone/ You can find all of the archived testlogs here: http://www.pwsan.com/omap/testlogs/ You'll probably only be interested in the ones that start with "test_v3.". ... As for BeagleBone Black, here's the latest non-booting log: http://www.pwsan.com/omap/testlogs/test_v3.10-rc6/20130616211951/boot/am335xbonelt/am335x-bone/am335xbonelt_log.txt This has never booted on mainline for me. The closest I got was with the ti-linux-3.8.y tree on Vaibhav's github account, which booted with the 'am335x-boneblack.dtb' built from the same tree. Mainline didn't boot with either the am335x-bone.dtb or Vaibhav's am335x-boneblack.dtb, but since it booted on 3.8.y with am335x-boneblack.dtb, I've kept that around for the mainline boot tests (as you can see from the logs). There's nothing exotic about the kernel used here, it's a pure omap2plus_defconfig zImage. The bootloader and DTB used are here (booted via serial from the boot ROM): http://www.pwsan.com/tmp/boneblack-20130625/ Please let me know if you need more binaries shared from the test runs! ... Am certainly open to the idea that there's something wrong with the way that I'm booting either of these. But AFAIK no one's been able to identify exactly what it could be. I haven't had the time recently to spend hours going through the various permutations, given all the other breakage :-( BeagleBone-white has the additional complication that it is not easy to automate, due to the way that power is delivered to the board, so there is an extra dimension of difficulty there. > Also, if you could share the entire thing, we will add your scripts to > our nightly tests as to try and avoid future regressions. It would be great to have TI folks running those tests, or something similar to them! An early version of the test system has been shared with a handful of folks, but it needs to be cleaned up further before broader release. - 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: [BISECTED] 3.10-rc1 OMAP1 GPIO IRQ regression
On Mon, Jun 24, 2013 at 05:35:18PM +0200, Javier Martinez Canillas wrote:
> Ok, so something like the following patch should do it (tested on an
> OMAP3 board):
>
> From b9e262c688fb7f3ad733f140b55dddbc8e4716e6 Mon Sep 17 00:00:00 2001
> From: Javier Martinez Canillas
> Date: Mon, 24 Jun 2013 17:13:23 +0200
> Subject: [PATCH 1/1] gpio/omap: don't use linear domain mapping for OMAP1
>
> commit ede4d7a5 ("gpio/omap: convert gpio irq domain to linear mapping")
> converted the OMAP GPIO driver to use a linear mapping for the GPIO IRQ
> domain instead of using a legacy mapping. Not using a legacy mapping has
> a number of benefits but it requires the platform to support SPARSE_IRQ
> which currently is not supported on OMAP1.
>
> So this change caused a regression on OMAP1 platforms [1].
>
> Since this issue is not present on all OMAP2+ platforms, there is no need to
> revert the driver to use legacy domain mapping for all the platforms.
>
> [1]: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg89005.html
>
> Signed-off-by: Javier Martinez Canillas
I tested this on OMAP1 / 770, and it's fine.
Tested-by: Aaro Koskinen
Thanks,
A.
> ---
> drivers/gpio/gpio-omap.c | 22 +-
> 1 files changed, 21 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
> index d3f7d2d..4a43036 100644
> --- a/drivers/gpio/gpio-omap.c
> +++ b/drivers/gpio/gpio-omap.c
> @@ -1094,6 +1094,9 @@ static int omap_gpio_probe(struct platform_device *pdev)
> const struct omap_gpio_platform_data *pdata;
> struct resource *res;
> struct gpio_bank *bank;
> +#ifdef CONFIG_ARCH_OMAP1
> + int irq_base;
> +#endif
>
> match = of_match_device(of_match_ptr(omap_gpio_match), dev);
>
> @@ -1135,11 +1138,28 @@ static int omap_gpio_probe(struct platform_device
> *pdev)
> pdata->get_context_loss_count;
> }
>
> +#ifdef CONFIG_ARCH_OMAP1
> + /*
> + * REVISIT: Once we have OMAP1 supporting SPARSE_IRQ, we can drop
> + * irq_alloc_descs() and irq_domain_add_legacy() and just use a
> + * linear IRQ domain mapping for all OMAP platforms.
> + */
> + irq_base = irq_alloc_descs(-1, 0, bank->width, 0);
> + if (irq_base < 0) {
> + dev_err(dev, "Couldn't allocate IRQ numbers\n");
> + return -ENODEV;
> + }
>
> + bank->domain = irq_domain_add_legacy(node, bank->width, irq_base,
> + 0, &irq_domain_simple_ops, NULL);
> +#else
> bank->domain = irq_domain_add_linear(node, bank->width,
>&irq_domain_simple_ops, NULL);
> - if (!bank->domain)
> +#endif
> + if (!bank->domain) {
> + dev_err(dev, "Couldn't register an IRQ domain\n");
> return -ENODEV;
> + }
>
> if (bank->regs->set_dataout && bank->regs->clr_dataout)
> bank->set_dataout = _set_gpio_dataout_reg;
> --
> 1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 4/6] USB: ehci-omap: Suspend the controller during bus suspend
On Tue, 25 Jun 2013, Roger Quadros wrote:
> On 06/24/2013 10:34 PM, Alan Stern wrote:
> > On Mon, 24 Jun 2013, Roger Quadros wrote:
> >
> >> OK I've tried to handle all this in an alternate way. Now the controller
> >> suspend/resume
> >> and runtime suspend/resume is independent of bus suspend.
> >>
> >> The controller now runtime suspends when all devices on the bus have
> >> suspended and
> >> the hub auto suspends. NOTE: HW_ACCESSIBLE is still set on runtime_suspend.
> >> The challenge here is to process the interrupt in this state.
> >
> > The situation is a little peculiar. Does the hardware really use the
> > same IRQ for reporting wakeup events when the controller is suspended
> > and for reporting normal I/O events?
>
> No and yes :). Actually the Pad wakeup comes as a separate IRQ from hardware.
> The omap pinctrl driver captures that, determines which pad caused the wakeup
> and
> routes it to the appropriate interrupt based on the mapping provided in the
> device tree.
> In the ehci-omap case we provide the EHCI IRQ number in the mapping for the
> USB host pads.
Could the mapping be changed so that a different interrupt vector was
used for wakeups and normal I/O? That would make this a little easier,
although it wouldn't solve the general problem.
> >>if (unlikely(HCD_DEAD(hcd) || !HCD_HW_ACCESSIBLE(hcd)))
> >>rc = IRQ_NONE;
> >> + else if (pm_runtime_status_suspended(hcd->self.controller)) {
> >> + /*
> >> + * We can't handle it yet so disable IRQ, make note of it
> >> + * and resume root hub (i.e. controller as well)
> >> + */
> >> + disable_irq_nosync(hcd->irq);
> >> + set_bit(HCD_FLAG_IRQ_DISABLED, &hcd->flags);
> >> + usb_hcd_resume_root_hub(hcd);
> >> + rc = IRQ_HANDLED;
> >> + }
> >
> > This part will have to be different.
> >
> > Certainly if HCD_DEAD(hcd) then we want to return IRQ_NONE. Likewise
> > if (!HCD_HW_ACCESSIBLE(hcd) && !hcd->has_wakeup_interrupts). In all
> > other cases we have to call the HCD's interrupt handler.
There's still a race problem. Suppose a normal wakeup interrupt occurs
just before or as the controller gets suspended. By the time the code
here runs, HCD_HW_ACCESSIBLE may have been cleared by the suspend
routine. The interrupt would be lost. Depending on the design of the
controller, the entire wakeup signal could end up getting lost as well.
Do you know how the OMAP EHCI controller behaves? Under what
conditions does it send the wakeup IRQ? How do you tell it to turn off
the wakeup IRQ?
> Looks good to me. Below is the implementation on these lines.
> I've added a flag "has_wakeup_irq:1" in struct hcd to indicate the special
> case where the interrupt can come even if controller is suspended.
>
> I've modified the ehci-omap driver to call ehci_suspend/resume() on system
> suspend/resume. For runtime suspend/resume I just toggle the HCD_HW_ACCESSIBLE
> flag to indicate that controller cannot be accessed when runtime suspended.
You're going to change that, right? ehci_suspend/resume should be
called whenever the controller's power state changes, regardless of
whether it is for runtime PM or system PM.
> The cutting of clocks is done in the parent driver (i.e.
> drivers/mfd/omap-usb-host.c)
>
> Patch is below. If it looks OK. I'll re-post the entire series. Thanks.
>
> diff --git a/include/linux/usb/hcd.h b/include/linux/usb/hcd.h
> index f5f5c7d..51c2d59 100644
> --- a/include/linux/usb/hcd.h
> +++ b/include/linux/usb/hcd.h
> @@ -110,6 +110,7 @@ struct usb_hcd {
> #define HCD_FLAG_WAKEUP_PENDING 4 /* root hub is
> resuming? */
> #define HCD_FLAG_RH_RUNNING 5 /* root hub is running? */
> #define HCD_FLAG_DEAD6 /* controller has died?
> */
> +#define HCD_FLAG_IRQ_DISABLED7 /* Interrupt was
> disabled */
>
> /* The flags can be tested using these macros; they are likely to
>* be slightly faster than test_bit().
> @@ -120,6 +121,7 @@ struct usb_hcd {
> #define HCD_WAKEUP_PENDING(hcd) ((hcd)->flags & (1U <<
> HCD_FLAG_WAKEUP_PENDING))
> #define HCD_RH_RUNNING(hcd) ((hcd)->flags & (1U << HCD_FLAG_RH_RUNNING))
> #define HCD_DEAD(hcd)((hcd)->flags & (1U << HCD_FLAG_DEAD))
> +#define HCD_IRQ_DISABLED(hcd)((hcd)->flags & (1U <<
> HCD_FLAG_IRQ_DISABLED))
>
> /* Flags that get set only during HCD registration or removal. */
> unsignedrh_registered:1;/* is root hub registered? */
> @@ -132,6 +134,7 @@ struct usb_hcd {
> unsignedwireless:1; /* Wireless USB HCD */
> unsignedauthorized_default:1;
> unsignedhas_tt:1; /* Integrated TT in root hub */
> + unsignedhas_wakeup_irq:1; /* Can generate IRQ when
> suspended */
>
> unsigned intirq;/* irq allocated
Re: linux-next: panda build failed at arch/arm/mach-omap2/omap4-restart.c
ping
On 23 June 2013 13:53, Naresh Kamboju wrote:
> Hi,
>
> panda build broken on linux-next branch
>
> kernel_config=omap2plus_defconfig
> KERNEL_VERSION=3.10.0-rc6
> KERNEL_GIT=git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> KERNEL_COMMIT=e1a86578747376f08985627c84df088a5d0d1e92
>
> Build error log :
> ---
> 04:43:18 CC arch/arm/mach-omap2/omap4-restart.o
> 04:43:18
> /mnt/ci_build/workspace/linux-next/hwpack/panda/label/kernel_cloud/arch/arm/mach-omap2/omap4-restart.c:21:28:
> warning: ‘enum reboot_mode’ declared inside parameter list [enabled by
> default]
> 04:43:18 void omap44xx_restart(enum reboot_mode mode, const char *cmd)
> 04:43:18 ^
> 04:43:18
> /mnt/ci_build/workspace/linux-next/hwpack/panda/label/kernel_cloud/arch/arm/mach-omap2/omap4-restart.c:21:28:
> warning: its scope is only this definition or declaration, which is
> probably not what you want [enabled by default]
> 04:43:18
> /mnt/ci_build/workspace/linux-next/hwpack/panda/label/kernel_cloud/arch/arm/mach-omap2/omap4-restart.c:21:40:
> error: parameter 1 (‘mode’) has incomplete type
> 04:43:18 void omap44xx_restart(enum reboot_mode mode, const char *cmd)
> 04:43:18 ^
> 04:43:18
> /mnt/ci_build/workspace/linux-next/hwpack/panda/label/kernel_cloud/arch/arm/mach-omap2/omap4-restart.c:21:6:
> warning: function declaration isn’t a prototype [-Wstrict-prototypes]
> 04:43:18 void omap44xx_restart(enum reboot_mode mode, const char *cmd)
> 04:43:18 ^
> 04:43:18 make[2]: *** [arch/arm/mach-omap2/omap4-restart.o] Error 1
> 04:43:18 make[1]: *** [arch/arm/mach-omap2] Error 2
>
> Full build log:
> --
> https://ci.linaro.org/jenkins/job/linux-next/hwpack=panda,label=kernel_cloud/lastBuild/console
>
> Suspecting patch which caused build failed:
>
> commit b61cdf2aebc5cd2f4efc4e0cbebeb8a91884a43e
> Author: Robin Holt
> Date: Wed Jun 19 10:08:43 2013 +1000
>
> reboot: arm: change reboot_mode to use enum reboot_mode
>
> Preparing to move the parsing of reboot= to generic kernel code forces the
> change in reboot_mode handling to use the enum.
>
> Signed-off-by: Robin Holt
>
> ...
> diff --git a/arch/arm/mach-omap2/omap4-restart.c
> b/arch/arm/mach-omap2/omap4-restart.c
> index f90e02e..652adde 100644
> --- a/arch/arm/mach-omap2/omap4-restart.c
> +++ b/arch/arm/mach-omap2/omap4-restart.c
> @@ -18,7 +18,7 @@
> * Resets the SoC. For @cmd, see the 'reboot' syscall in
> * kernel/sys.c. No return value.
> */
> -void omap44xx_restart(char mode, const char *cmd)
> +void omap44xx_restart(enum reboot_mode mode, const char *cmd)
> {
> /* XXX Should save 'cmd' into scratchpad for use after reboot */
> omap4_prminst_global_warm_sw_reset(); /* never returns */
> ...
>
> Best regards
> Naresh Kamboju
--
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 baseline test results for v3.10-rc6
Hi, On Mon, Jun 17, 2013 at 05:23:17AM +, Paul Walmsley wrote: > Boot to userspace: > FAIL ( 3/12): 37xxevm, am335xbone, am335xbonelt Paul, we have at least 2 different folks who can't reproduce your bone and bone black boot to userspace failures. I wonder how you're trying to boot them. Care to share your test scripts ? Also, if you could share the entire thing, we will add your scripts to our nightly tests as to try and avoid future regressions. -- balbi signature.asc Description: Digital signature
Re: [PATCH v8 8/8] usb: phy: twl4030-usb: remove *set_suspend* and *phy_init* ops
On Tue, Jun 25, 2013 at 11:28:46AM +0530, Kishon Vijay Abraham I wrote: > Now that twl4030-usb is adapted to the new generic PHY framework, > *set_suspend* and *phy_init* ops can be removed from twl4030-usb driver. > > Signed-off-by: Kishon Vijay Abraham I > Reviewed-by: Felipe Balbi Acked-by: Felipe Balbi -- balbi signature.asc Description: Digital signature
Re: [PATCH v8 7/8] usb: phy: omap-usb2: remove *set_suspend* callback from omap-usb2
On Tue, Jun 25, 2013 at 11:28:45AM +0530, Kishon Vijay Abraham I wrote: > Now that omap-usb2 is adapted to the new generic PHY framework, > *set_suspend* ops can be removed from omap-usb2 driver. > > Signed-off-by: Kishon Vijay Abraham I > Reviewed-by: Felipe Balbi Acked-by: Felipe Balbi -- balbi signature.asc Description: Digital signature
Re: [PATCH v8 6/8] usb: musb: omap2430: use the new generic PHY framework
On Tue, Jun 25, 2013 at 11:28:44AM +0530, Kishon Vijay Abraham I wrote: > Use the generic PHY framework API to get the PHY. The usb_phy_set_resume > and usb_phy_set_suspend is replaced with power_on and > power_off to align with the new PHY framework. > > musb->xceiv can't be removed as of now because musb core uses xceiv.state and > xceiv.otg. Once there is a separate state machine to handle otg, these can be > moved out of xceiv and then we can start using the generic PHY framework. > > Signed-off-by: Kishon Vijay Abraham I > Reviewed-by: Sylwester Nawrocki Acked-by: Felipe Balbi -- balbi signature.asc Description: Digital signature
Re: [PATCH v8 2/8] usb: phy: omap-usb2: use the new generic PHY framework
On Tue, Jun 25, 2013 at 11:28:40AM +0530, Kishon Vijay Abraham I wrote: > Used the generic PHY framework API to create the PHY. Now the power off and > power on are done in omap_usb_power_off and omap_usb_power_on respectively. > > However using the old USB PHY library cannot be completely removed > because OTG is intertwined with PHY and moving to the new framework > will break OTG. Once we have a separate OTG state machine, we > can get rid of the USB PHY library. > > Signed-off-by: Kishon Vijay Abraham I > Reviewed-by: Sylwester Nawrocki Acked-by: Felipe Balbi -- balbi signature.asc Description: Digital signature
Re: [PATCH v8 5/8] ARM: dts: omap: update usb_otg_hs data
On Tue, Jun 25, 2013 at 11:28:43AM +0530, Kishon Vijay Abraham I wrote: > Updated the usb_otg_hs dt data to include the *phy* and *phy-names* > binding in order for the driver to use the new generic PHY framework. > Also updated the Documentation to include the binding information. > The PHY binding information can be found at > Documentation/devicetree/bindings/phy/phy-bindings.txt > > Signed-off-by: Kishon Vijay Abraham I > Reviewed-by: Felipe Balbi Acked-by: Felipe Balbi -- balbi signature.asc Description: Digital signature
Re: [PATCH v8 3/8] usb: phy: twl4030: use the new generic PHY framework
On Tue, Jun 25, 2013 at 11:28:41AM +0530, Kishon Vijay Abraham I wrote: > Used the generic PHY framework API to create the PHY. For powering on > and powering off the PHY, power_on and power_off ops are used. Once the > MUSB OMAP glue is adapted to the new framework, the suspend and resume > ops of usb phy library will be removed. > > However using the old usb phy library cannot be completely removed > because otg is intertwined with phy and moving to the new > framework completely will break otg. Once we have a separate otg state > machine, > we can get rid of the usb phy library. > > Signed-off-by: Kishon Vijay Abraham I > Reviewed-by: Felipe Balbi I'll add an Acked-by here: Acked-by: Felipe Balbi -- balbi signature.asc Description: Digital signature
Re: [PATCH v8 4/8] ARM: OMAP: USB: Add phy binding information
On Tue, Jun 25, 2013 at 11:28:42AM +0530, Kishon Vijay Abraham I wrote: > In order for controllers to get PHY in case of non dt boot, the phy > binding information (phy device name) should be added in the platform > data of the controller. > > Signed-off-by: Kishon Vijay Abraham I > Reviewed-by: Sylwester Nawrocki Acked-by: Felipe Balbi -- balbi signature.asc Description: Digital signature
Re: [PATCH v8 1/8] drivers: phy: add generic PHY framework
Hi, On Tue, Jun 25, 2013 at 11:28:39AM +0530, Kishon Vijay Abraham I wrote: > diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h > new file mode 100644 > index 000..7abf573 > --- /dev/null > +++ b/include/linux/phy/phy.h on this header, how about adding phy_set_drvdata() and phy_get_drvdata() helpers ? cheers -- balbi signature.asc Description: Digital signature
Re: [PATCHv3 0/9] ARM: OMAP4 clock data conversion to DT
Hi, On 06/25/2013 02:38 PM, Tero Kristo wrote: > Hi, > > Changes compared to previous version: > > PATCH 2 - removed some unnecessary headers + module defs > - added Mike under copyright > PATCH 4 - fixed the copyright in the header file > PATCH 8 - removed a few incorrect comments from the data file > - moved /include/ for the clock DT file under omap4 root from > soc -> should save some memory based on comments to previous rev > > This set is also rebased on top of Mike's latest clk binding patches (V3.) > > Boot + suspend tested with OMAP4 panda board. > > I also have OMAP5 + DRA7 clock data in the same format, these have been > tested with trees that have support for these SoCs. I will publish these > once this set moves forward, or alternatively with next rev of this set > if requested. > > Test branch also still available (with O4 support only): >git://gitorious.org/~kristo/omap-pm/omap-pm-work.git >branch: mainline-3.10-rc6-omap4-dt-clks-v3 I have tested this branch on PandaBoardES. Audio works as it worked before. To all: Tested-by: Peter Ujfalusi -- 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 v12 00/11] DMA Engine support for AM33XX
On Tuesday 25 June 2013 10:16 AM, Sekhar Nori wrote: > On 6/25/2013 12:24 PM, Tony Lindgren wrote: >> * Benoit Cousson [130624 07:42]: >>> Hi Tony, >>> >>> On 06/24/2013 12:19 PM, Tony Lindgren wrote: Hi, For merging this series, I suggest the following sets: * Joel A Fernandes [130620 14:13]: > > Joel A Fernandes (3): > edma: config: Enable config options for EDMA > da8xx: config: Enable MMC and FS options > ARM: davinci: Fix compiler warnings in devices-da8xx > > Matt Porter (8): > dmaengine: edma: Add TI EDMA device tree binding > ARM: edma: Add DT and runtime PM support to the private EDMA API > ARM: edma: Add EDMA crossbar event mux support > dmaengine: edma: enable build for AM33XX Sekhar should queue the above patches, I've acked the mach-omap2/Kconfig change. > spi: omap2-mcspi: add generic DMA request support to the DT binding > spi: omap2-mcspi: convert to dma_request_slave_channel_compat() The spi changes should get merged via the driver list. > ARM: dts: add AM33XX EDMA support > ARM: dts: add AM33XX SPI DMA support Benoit should queue the .dts changes. >>> >>> I'll do that, but do you consider them for 3.11? >> >> Yes right after -rc1 if it makes the DMA work. We almost >> certainly need to send few branches of fixes after -rc1 once >> we find out what might have broken by the removal of the >> hwmod data.. > > The DMA related changes went into arm-soc yesterday. So it should be > safe to send the DT patches in before the merge window opens. If Tony is > done with sending his pull requests may be Benoit can send to arm-soc > directly? > I was just typing the same thing. Even if Tony send them during rc's, thats fine. Regards, Santosh -- 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 v12 00/11] DMA Engine support for AM33XX
On 6/25/2013 12:24 PM, Tony Lindgren wrote: > * Benoit Cousson [130624 07:42]: >> Hi Tony, >> >> On 06/24/2013 12:19 PM, Tony Lindgren wrote: >>> Hi, >>> >>> For merging this series, I suggest the following sets: >>> >>> * Joel A Fernandes [130620 14:13]: Joel A Fernandes (3): edma: config: Enable config options for EDMA da8xx: config: Enable MMC and FS options ARM: davinci: Fix compiler warnings in devices-da8xx Matt Porter (8): dmaengine: edma: Add TI EDMA device tree binding ARM: edma: Add DT and runtime PM support to the private EDMA API ARM: edma: Add EDMA crossbar event mux support dmaengine: edma: enable build for AM33XX >>> >>> Sekhar should queue the above patches, I've acked the >>> mach-omap2/Kconfig change. >>> spi: omap2-mcspi: add generic DMA request support to the DT binding spi: omap2-mcspi: convert to dma_request_slave_channel_compat() >>> >>> >>> The spi changes should get merged via the driver list. >>> ARM: dts: add AM33XX EDMA support ARM: dts: add AM33XX SPI DMA support >>> >>> Benoit should queue the .dts changes. >> >> I'll do that, but do you consider them for 3.11? > > Yes right after -rc1 if it makes the DMA work. We almost > certainly need to send few branches of fixes after -rc1 once > we find out what might have broken by the removal of the > hwmod data.. The DMA related changes went into arm-soc yesterday. So it should be safe to send the DT patches in before the merge window opens. If Tony is done with sending his pull requests may be Benoit can send to arm-soc directly? Thanks, Sekhar -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ARM: DTS: OMAP4: Add OMAP4 Blaze Tablet support
On 06/25/2013 06:32 AM, Ruslan Bilovol wrote: The OMAP4 Blaze Tablet is TI OMAP4 processor-based development platform in a tablet formfactor. The platform contains many of the features found in present-day handsets (such as audio, video, wireless functions and user interfaces) and in addition contains features for software development and test. Why do we want to send this upstream? What is the advantage to having this supported? I don't believe we need to add another community board. We have a SDP and Panda. Dan -- -- Dan Murphy -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 4/6] USB: ehci-omap: Suspend the controller during bus suspend
On 06/24/2013 10:34 PM, Alan Stern wrote:
> On Mon, 24 Jun 2013, Roger Quadros wrote:
>
>> OK I've tried to handle all this in an alternate way. Now the controller
>> suspend/resume
>> and runtime suspend/resume is independent of bus suspend.
>>
>> The controller now runtime suspends when all devices on the bus have
>> suspended and
>> the hub auto suspends. NOTE: HW_ACCESSIBLE is still set on runtime_suspend.
>> The challenge here is to process the interrupt in this state.
>
> The situation is a little peculiar. Does the hardware really use the
> same IRQ for reporting wakeup events when the controller is suspended
> and for reporting normal I/O events?
No and yes :). Actually the Pad wakeup comes as a separate IRQ from hardware.
The omap pinctrl driver captures that, determines which pad caused the wakeup
and
routes it to the appropriate interrupt based on the mapping provided in the
device tree.
In the ehci-omap case we provide the EHCI IRQ number in the mapping for the USB
host pads.
>
> In principle, HW_ACCESSIBLE should not be set when the controller is
> suspended, because you can't access the hardware then (since the clocks
> are off, right?). But I can see how this would cause a problem if it
> leads to wakeup interrupts being ignored.
>
> Also, note that one of the things ehci_suspend() does is turn off the
> Interrupt-Enable register, which means the wakeup interrupt would never
> be issued in the first place. I guess ehci_hcd_omap_suspend() will
> have to turn on the proper enable bit before stopping the clocks.
For us, in runtime_suspend, we do not call ehci_suspend(), we just cut the
clocks.
So HW_ACCESSIBLE is still set, which is kind of wrong, I agree. I'll update
this in
the next patch.
>
>> I've tried to handle this state. (i.e. interrupt while controller is runtime
>> suspended),
>> by disabling the interrupt till we are ready and calling
>> usb_hcd_resume_root_hub().
>> We mark a flag (HW_IRQ_DISABLED) stating that the interrupt was disabled and
>> based on
>> that enable the IRQ and clear the flag in hcd_resume_work().
>>
>> Do let me know what you think of this approach.
>
> This is a very tricky problem. Right now, usbcore assumes that when
> HW_ACCESSIBLE is clear, the hardware can't generate interrupt requests
> and therefore any interrupt must come from some other device sharing
> the same IRQ line. For the systems you're working on, this is wrong in
> both respects (the hardware _can_ generate interrupt requests and IRQ
> lines aren't shared).
Right.
>
> I think we will have to add a new flag to describe your situation.
> Let's call it hcd->has_wakeup_interrupts. Presumably there will never
> be a system that uses interrupts for wakeup signals _and_ has shared
> IRQ lines? That would be a bad combination...
Sounds good.
>
>> diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
>> index d53547d..8879cd2 100644
>> --- a/drivers/usb/core/hcd.c
>> +++ b/drivers/usb/core/hcd.c
>> @@ -2136,6 +2136,11 @@ static void hcd_resume_work(struct work_struct *work)
>> usb_lock_device(udev);
>> usb_remote_wakeup(udev);
>> usb_unlock_device(udev);
>> +if (HCD_IRQ_DISABLED(hcd)) {
>> +/* Interrupt was disabled */
>> +clear_bit(HCD_FLAG_IRQ_DISABLED, &hcd->flags);
>> +enable_irq(hcd->irq);
>> +}
>> }
>
> This part is okay.
>
>> @@ -2225,6 +2230,16 @@ irqreturn_t usb_hcd_irq (int irq, void *__hcd)
>>
>> if (unlikely(HCD_DEAD(hcd) || !HCD_HW_ACCESSIBLE(hcd)))
>> rc = IRQ_NONE;
>> +else if (pm_runtime_status_suspended(hcd->self.controller)) {
>> +/*
>> + * We can't handle it yet so disable IRQ, make note of it
>> + * and resume root hub (i.e. controller as well)
>> + */
>> +disable_irq_nosync(hcd->irq);
>> +set_bit(HCD_FLAG_IRQ_DISABLED, &hcd->flags);
>> +usb_hcd_resume_root_hub(hcd);
>> +rc = IRQ_HANDLED;
>> +}
>
> This part will have to be different.
>
> Certainly if HCD_DEAD(hcd) then we want to return IRQ_NONE. Likewise
> if (!HCD_HW_ACCESSIBLE(hcd) && !hcd->has_wakeup_interrupts). In all
> other cases we have to call the HCD's interrupt handler.
>
> The rest of the work will have to be done in the HCD, while holding the
> private lock. In ehci_irq(), after the spin_lock() call, you'll have
> to add something like this:
>
> if (unlikely(!HCD_HW_ACCESSIBLE(hcd))) {
> /*
>* We got a wakeup interrupt while the controller was
>* suspending or suspended. We can't handle it now, so
>* disable the IRQ and resume the root hub (and hence
>* the controller too).
>*/
> disable_irq_nosync(hcd->irq);
> set_bit(HCD_FLAG_IRQ_DISABLED, &hcd->flags);
> spin_unlock(&ehci->lock);
>
> usb_hcd_resume_root_hub(hcd);
>
Re: MMC breakage on 3.11/cleanup
On Tue, Jun 25, 2013 at 5:40 AM, Felipe Balbi wrote:
> On Mon, Jun 24, 2013 at 11:49:44PM -0700, Tony Lindgren wrote:
>> * Joel A Fernandes [130624 15:33]:
>> > Hi Tony,
>> >
>> > Following branch breaks MMC for me on am33xx (beaglebone):
>> > http://git.kernel.org/cgit/linux/kernel/git/tmlind/linux-omap.git/log/?h=omap-for-v3.11/cleanup
>> >
>> > I tried to work around it by specifying interrupt and reg property in DT:
>> > mmc1: mmc@4806 {
>> > compatible = "ti,omap3-hsmmc";
>> > ti,hwmods = "mmc1";
>> > ti,dual-volt;
>> > ti,needs-special-reset;
>> > dmas = <&edma 24
>> > &edma 25>;
>> > dma-names = "tx", "rx";
>> > interrupts = <64>;
>> > interrupt-parent = <&intc>;
>> > reg = <0x4806 0x1000>;
>> > status = "disabled";
>> > };
>> >
>> > The probe succeeds but I still get a "Waiting for root device
>> > /dev/mmcblk0p2" when booting over MMC.
>> >
>> > If you're planning to push the cleanup branch, can we temporarily add
>> > the hwmod data back while we work on this issue so that upstream MMC
>> > is kept working.
>>
>> Yes the cleanup branch is queued up. Can you please send a patch
>> reverting the MMC parts of the hwmod change for am33xx for now,
>> then try to find the real cause for the breakage?
>
> I had mentioned that Joel should *not* depend on hwmod data and if
> adding interrupts to DTS caused issues, that issue should be resolved.
>
> http://marc.info/?l=linux-omap&m=137124891908957&w=2
Ofcourse, that is what we are talking about too. hwmod data is being
added only as a temporary fix to keep upstream working while we work
on a resolution.
Maybe you missed the "add the hwmod data back while we work on this
issue so that upstream MMC is kept working." in my post?
Please read,
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg91130.html
Thanks,
-Joel
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Documentation: dt: bindings: TI WiLink modules
On Tue, Jun 25, 2013 at 02:56:10PM +0300, Luciano Coelho wrote: > On Tue, 2013-06-25 at 14:12 +0300, Felipe Balbi wrote: > > On Tue, Jun 25, 2013 at 11:35:30AM +0300, Luciano Coelho wrote: > > > +- tcxoclock: the internal WLAN TCXO clock frequency (required for > > > + WiLink7 not used for WiLink6 and WiLink8). Must be one of the > > > + following: > > > + 0 = 19.200 MHz > > > + 1 = 26.000 MHz > > > + 2 = 38.400 MHz > > > + 3 = 52.000 MHz > > > + 4 = 16.368 MHz > > > + 5 = 32.736 MHz > > > + 6 = 16.800 MHz > > > + 7 = 33.600 MHz > > > > DTS files are pre-processed, so you could add defines in a header and > > share the header between DTS and driver. Could help you having: > > > > tcxoclock = WILINK_19_200MHz; > > > > instead of > > > > tcxoclock = 0; > > I don't see any .dts file really doing this. There are some imx*.dtsi > files that include imx*.h files, but I don't see these headers being > included in any source code file. > > In fact, we already have all these values defined in > include/linux/wl12xx.h, so it could be nice to reuse. But the > cross-directory includes would look "funny". And I think it's a bit > overkill. > > These values are actually used by the firmware itself, not only the > driver, so they are also platform independent and not related to the OS. fair enough, then there's no chance they'll change all of a sudden. -- balbi signature.asc Description: Digital signature
Re: [PATCH v2] ARM: DTS: OMAP4: Add OMAP4 Blaze Tablet support
On 06/25/2013 07:01 AM, Nishanth Menon wrote:
On 06/25/2013 06:32 AM, Ruslan Bilovol wrote:
The OMAP4 Blaze Tablet is TI OMAP4 processor-based
development platform in a tablet formfactor.
The platform contains many of the features found in
present-day handsets (such as audio, video, wireless
functions and user interfaces) and in addition
contains features for software development and test.
This patch adds initial support for the OMAP4 Blaze
Tablet development platform. Additional functionality
depends on different drivers and code modifications that
are not upstreamed yet or do not support DT yet, so will
be added later.
http://svtronics.com/omap/sevm4460,blaze,omap might help too :)
[...]
+
+#include "twl6030.dtsi"
+
Might be good to see the TWL interrupt pin information made available as
well?
Allow me to rephrase a comment a little bit more :)
Similar to twl4030_omap3.dtsi, we could introduce twl6030_omap4.dtsi.
this could contain the common pins used for 6030.
&omap4_pmx_wkup {
pinctrl-names = "default";
pinctrl-0 = <
&twl6030_wkup_pins
>;
twl6030_wkup_pins: pinmux_twl6030_wkup_pins {
pinctrl-single,pins = <
0x14 (PIN_OUTPUT | MUX_MODE2)
>;
};
};
twl6030_pins: pinmux_twl6030_pins {
pinctrl-single,pins = <
0x15e (WAKEUP_EN | PIN_INPUT_PULLUP | MUX_MODE0) /*
sys_nirq1.sys_nirq1 */
>;
};
which is now already duplicated in 2 places (SDP and Panda), and in this
patch duplicated again.
just my 2 cents :(
---
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
[PATCHv3 5/9] ARM: OMAP: clock: add DT duplicate clock registration mechanism
Some devices require their clocks to be available with a specific
dev-id con-id mapping. With DT, the clocks can be found by default
only with their name, or alternatively through the device node of
the consumer. With drivers, that don't support DT fully yet, add
mechanism to register specific clock names.
Signed-off-by: Tero Kristo
---
arch/arm/mach-omap2/clock.c | 39 +++
arch/arm/mach-omap2/clock.h | 16
2 files changed, 55 insertions(+)
diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
index 0c38ca9..6fe14b5 100644
--- a/arch/arm/mach-omap2/clock.c
+++ b/arch/arm/mach-omap2/clock.c
@@ -584,6 +584,45 @@ void __init omap_clocks_register(struct omap_clk oclks[],
int cnt)
}
/**
+ * omap_dt_clocks_register - register DT duplicate clocks during boot
+ * @oclks: list of clocks to register
+ * @cnt: number of clocks
+ *
+ * Register duplicate or non-standard DT clock entries during boot. By
+ * default, DT clocks are found based on their node name. If any
+ * additional con-id / dev-id -> clock mapping is required, use this
+ * function to list these.
+ */
+void __init omap_dt_clocks_register(struct omap_dt_clk oclks[], int cnt)
+{
+ struct omap_dt_clk *c;
+ struct device_node *n;
+ struct clk *clk;
+ struct of_phandle_args clkspec;
+
+ for (c = oclks; c < oclks + cnt; c++) {
+ n = of_find_node_by_name(NULL, c->node_name);
+
+ if (!n) {
+ pr_err("%s: %s not found!\n", __func__, c->node_name);
+ continue;
+ }
+
+ clkspec.np = n;
+
+ clk = of_clk_get_from_provider(&clkspec);
+
+ if (!clk) {
+ pr_err("%s: %s has no clock!\n", __func__,
+ c->node_name);
+ continue;
+ }
+ c->lk.clk = clk;
+ clkdev_add(&c->lk);
+ }
+}
+
+/**
* omap2_clk_switch_mpurate_at_boot - switch ARM MPU rate by boot-time argument
* @mpurate_ck_name: clk name of the clock to change rate
*
diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h
index 3238c57..1c1fbe4 100644
--- a/arch/arm/mach-omap2/clock.h
+++ b/arch/arm/mach-omap2/clock.h
@@ -37,6 +37,21 @@ struct omap_clk {
}, \
}
+struct omap_dt_clk {
+ u16 cpu;
+ struct clk_lookup lk;
+ const char *node_name;
+};
+
+#define DT_CLK(dev, con, name) \
+ { \
+ .lk = { \
+ .dev_id = dev, \
+ .con_id = con, \
+ }, \
+ .node_name = name, \
+ }
+
struct clockdomain;
#define to_clk_hw_omap(_hw) container_of(_hw, struct clk_hw_omap, hw)
@@ -316,4 +331,5 @@ extern const struct clksel_rate div31_1to31_rates[];
extern int am33xx_clk_init(void);
extern void omap_clocks_register(struct omap_clk *oclks, int cnt);
+extern void omap_dt_clocks_register(struct omap_dt_clk *oclks, int cnt);
#endif
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3 7/9] CLK: omap: add support for OMAP gate clock
This node adds support for a clock node which allows control to the
clockdomain enable / disable.
Signed-off-by: Tero Kristo
---
drivers/clk/omap/Makefile |2 +-
drivers/clk/omap/clk.c|1 +
drivers/clk/omap/gate.c | 88 +
include/linux/clk/omap.h |1 +
4 files changed, 91 insertions(+), 1 deletion(-)
create mode 100644 drivers/clk/omap/gate.c
diff --git a/drivers/clk/omap/Makefile b/drivers/clk/omap/Makefile
index ca56700..3d3ca30f 100644
--- a/drivers/clk/omap/Makefile
+++ b/drivers/clk/omap/Makefile
@@ -1 +1 @@
-obj-y += clk.o dpll.o autoidle.o
+obj-y += clk.o dpll.o autoidle.o gate.o
diff --git a/drivers/clk/omap/clk.c b/drivers/clk/omap/clk.c
index 6be62ee..6dfa4c8 100644
--- a/drivers/clk/omap/clk.c
+++ b/drivers/clk/omap/clk.c
@@ -29,6 +29,7 @@ static const struct of_device_id clk_match[] = {
{.compatible = "divider-clock", .data = of_omap_divider_setup, },
{.compatible = "gate-clock", .data = of_gate_clk_setup, },
{.compatible = "ti,omap4-dpll-clock", .data = of_omap4_dpll_setup, },
+ {.compatible = "ti,gate-clock", .data = of_omap_gate_clk_setup, },
{},
};
diff --git a/drivers/clk/omap/gate.c b/drivers/clk/omap/gate.c
new file mode 100644
index 000..7186bb2
--- /dev/null
+++ b/drivers/clk/omap/gate.c
@@ -0,0 +1,88 @@
+/*
+ * OMAP gate clock support
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ *
+ * Tero Kristo
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#ifdef CONFIG_OF
+
+static const struct clk_ops omap_gate_clk_ops = {
+ .init = &omap2_init_clk_clkdm,
+ .enable = &omap2_clkops_enable_clkdm,
+ .disable= &omap2_clkops_disable_clkdm,
+};
+
+void __init of_omap_gate_clk_setup(struct device_node *node)
+{
+ struct clk *clk;
+ struct clk_init_data init;
+ struct clk_hw_omap *clk_hw;
+ const char *clk_name = node->name;
+ int num_parents;
+ const char **parent_names;
+ int i;
+
+ clk_hw = kzalloc(sizeof(struct clk_hw_omap), GFP_KERNEL);
+ if (!clk_hw) {
+ pr_err("%s: could not allocate clk_hw_omap\n", __func__);
+ return;
+ }
+
+ clk_hw->hw.init = &init;
+
+ of_property_read_string(node, "clock-output-names", &clk_name);
+ of_property_read_string(node, "ti,clkdm-name", &clk_hw->clkdm_name);
+
+ init.name = clk_name;
+ init.ops = &omap_gate_clk_ops;
+
+ num_parents = of_clk_get_parent_count(node);
+ if (num_parents < 1) {
+ pr_err("%s: omap trace_clk %s must have parent(s)\n",
+ __func__, node->name);
+ goto cleanup;
+ }
+
+ parent_names = kzalloc(sizeof(char *) * num_parents, GFP_KERNEL);
+
+ for (i = 0; i < num_parents; i++)
+ parent_names[i] = of_clk_get_parent_name(node, i);
+
+ init.num_parents = num_parents;
+ init.parent_names = parent_names;
+
+ clk = clk_register(NULL, &clk_hw->hw);
+
+ if (!IS_ERR(clk)) {
+ of_clk_add_provider(node, of_clk_src_simple_get, clk);
+ return;
+ }
+
+cleanup:
+ kfree(clk_hw);
+}
+EXPORT_SYMBOL(of_omap_gate_clk_setup);
+CLK_OF_DECLARE(omap_gate_clk, "ti,omap-gate-clock", of_omap_gate_clk_setup);
+#endif
diff --git a/include/linux/clk/omap.h b/include/linux/clk/omap.h
index f2a83a1..ef09301 100644
--- a/include/linux/clk/omap.h
+++ b/include/linux/clk/omap.h
@@ -175,6 +175,7 @@ int dt_omap_clk_init(void);
void of_omap4_dpll_setup(struct device_node *node);
void of_omap_fixed_factor_setup(struct device_node *node);
void of_omap_divider_setup(struct device_node *node);
+void of_omap_gate_clk_setup(struct device_node *node);
void of_omap_clk_allow_autoidle_all(void);
void of_omap_clk_deny_autoidle_all(void);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3 1/9] CLK: clkdev: add support for looking up clocks from DT
clk_get_sys / clk_get can now find clocks from device-tree. If a DT clock
is found, an entry is added to the clk_lookup list also for subsequent
searches.
Signed-off-by: Tero Kristo
Cc: Russell King
---
drivers/clk/clkdev.c | 32
1 file changed, 32 insertions(+)
diff --git a/drivers/clk/clkdev.c b/drivers/clk/clkdev.c
index 442a313..e39f082 100644
--- a/drivers/clk/clkdev.c
+++ b/drivers/clk/clkdev.c
@@ -93,6 +93,18 @@ struct clk *of_clk_get_by_name(struct device_node *np, const
char *name)
EXPORT_SYMBOL(of_clk_get_by_name);
#endif
+/**
+ * clkdev_add_nolock - add lookup entry for a clock
+ * @cl: pointer to new clock lookup entry
+ *
+ * Non-locking version, used internally by clk_find() to add DT based
+ * clock lookup entries.
+ */
+static void clkdev_add_nolock(struct clk_lookup *cl)
+{
+ list_add_tail(&cl->node, &clocks);
+}
+
/*
* Find the correct struct clk for the device and connection ID.
* We do slightly fuzzy matching here:
@@ -106,6 +118,9 @@ static struct clk_lookup *clk_find(const char *dev_id,
const char *con_id)
{
struct clk_lookup *p, *cl = NULL;
int match, best_found = 0, best_possible = 0;
+ struct device_node *node;
+ struct clk *clk;
+ struct of_phandle_args clkspec;
if (dev_id)
best_possible += 2;
@@ -133,6 +148,23 @@ static struct clk_lookup *clk_find(const char *dev_id,
const char *con_id)
break;
}
}
+
+ if (cl)
+ return cl;
+
+ /* If clock was not found, attempt to look-up from DT */
+ node = of_find_node_by_name(NULL, con_id);
+
+ clkspec.np = node;
+
+ clk = of_clk_get_from_provider(&clkspec);
+
+ if (!IS_ERR(clk)) {
+ /* We found a clock, add node to clkdev */
+ cl = clkdev_alloc(clk, con_id, dev_id);
+ clkdev_add_nolock(cl);
+ }
+
return cl;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3 6/9] CLK: omap: add autoidle support
OMAP clk driver now routes some of the basic clocks through own
registration routine to allow autoidle support. This routine just
checks a couple of device node properties and adds autoidle support
if required, and just passes the registration forward to basic clocks.
Signed-off-by: Tero Kristo
---
arch/arm/mach-omap2/clock.c |6 ++
drivers/clk/omap/Makefile |2 +-
drivers/clk/omap/autoidle.c | 130 +++
drivers/clk/omap/clk.c |4 +-
include/linux/clk/omap.h|4 ++
5 files changed, 143 insertions(+), 3 deletions(-)
create mode 100644 drivers/clk/omap/autoidle.c
diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
index 6fe14b5..9bd66b4 100644
--- a/arch/arm/mach-omap2/clock.c
+++ b/arch/arm/mach-omap2/clock.c
@@ -520,6 +520,9 @@ int omap2_clk_enable_autoidle_all(void)
list_for_each_entry(c, &clk_hw_omap_clocks, node)
if (c->ops && c->ops->allow_idle)
c->ops->allow_idle(c);
+
+ of_omap_clk_allow_autoidle_all();
+
return 0;
}
@@ -539,6 +542,9 @@ int omap2_clk_disable_autoidle_all(void)
list_for_each_entry(c, &clk_hw_omap_clocks, node)
if (c->ops && c->ops->deny_idle)
c->ops->deny_idle(c);
+
+ of_omap_clk_deny_autoidle_all();
+
return 0;
}
diff --git a/drivers/clk/omap/Makefile b/drivers/clk/omap/Makefile
index 4cad480..ca56700 100644
--- a/drivers/clk/omap/Makefile
+++ b/drivers/clk/omap/Makefile
@@ -1 +1 @@
-obj-y += clk.o dpll.o
+obj-y += clk.o dpll.o autoidle.o
diff --git a/drivers/clk/omap/autoidle.c b/drivers/clk/omap/autoidle.c
new file mode 100644
index 000..6424cb2
--- /dev/null
+++ b/drivers/clk/omap/autoidle.c
@@ -0,0 +1,130 @@
+/*
+ * OMAP clock autoidle support
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ *
+ * Tero Kristo
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#ifdef CONFIG_OF
+struct clk_omap_autoidle {
+ void __iomem*reg;
+ u8 shift;
+ u8 flags;
+ const char *name;
+ struct list_headnode;
+};
+
+#define AUTOIDLE_LOW 0x1
+
+static LIST_HEAD(autoidle_clks);
+
+static void omap_allow_autoidle(struct clk_omap_autoidle *clk)
+{
+ u32 val;
+
+ val = readl(clk->reg);
+
+ if (clk->flags & AUTOIDLE_LOW)
+ val &= ~(1 << clk->shift);
+ else
+ val |= (1 << clk->shift);
+
+ writel(val, clk->reg);
+}
+
+static void omap_deny_autoidle(struct clk_omap_autoidle *clk)
+{
+ u32 val;
+
+ val = readl(clk->reg);
+
+ if (clk->flags & AUTOIDLE_LOW)
+ val |= (1 << clk->shift);
+ else
+ val &= ~(1 << clk->shift);
+
+ writel(val, clk->reg);
+}
+
+void of_omap_clk_allow_autoidle_all(void)
+{
+ struct clk_omap_autoidle *c;
+
+ list_for_each_entry(c, &autoidle_clks, node)
+ omap_allow_autoidle(c);
+}
+
+void of_omap_clk_deny_autoidle_all(void)
+{
+ struct clk_omap_autoidle *c;
+
+ list_for_each_entry(c, &autoidle_clks, node)
+ omap_deny_autoidle(c);
+}
+
+static __init void of_omap_autoidle_setup(struct device_node *node)
+{
+ u32 shift;
+ void __iomem *reg;
+ struct clk_omap_autoidle *clk;
+
+ if (of_property_read_u32(node, "ti,autoidle-shift", &shift))
+ return;
+
+ reg = of_iomap(node, 0);
+
+ clk = kzalloc(sizeof(struct clk_omap_autoidle), GFP_KERNEL);
+
+ if (!clk) {
+ pr_err("%s: kzalloc failed\n", __func__);
+ return;
+ }
+
+ clk->shift = shift;
+ clk->name = node->name;
+ clk->reg = reg;
+
+ if (of_property_read_bool(node, "ti,autoidle-low"))
+ clk->flags |= AUTOIDLE_LOW;
+
+ list_add(&clk->node, &autoidle_clks);
+}
+
+void __init of_omap_divider_setup(struct device_node *node)
+{
+ of_divider_clk_setup(node);
+ of_omap_autoidle_setup(node);
+}
+EXPORT_SYMBOL_GPL(of_omap_divider_setup);
+CLK_OF_DECLARE(omap_autoidle_clock, "divider-clock", of_omap_divider_setup);
+
+void __init of_omap_fixed_factor_setup(struct device_node *node)
+{
+ of_fixed_factor_clk_setup(node);
+ of_omap_autoidle_setup(node);
+}
+EXPORT_SYMBOL_GPL(of_omap_fixed_factor_setup);
+CLK_OF_DECLARE(omap_fixed
[PATCHv3 2/9] clk: omap: introduce clock driver
Parses OMAP clock data from DT and registers those clocks with the clock
framework. dt_omap_clk_init must be called early during boot for timer
initialization so it is exported and called from the existing clock code
instead of probing like a real driver. Based on initial work done by
Mike Turquette.
Signed-off-by: Tero Kristo
Cc: Mike Turquette
---
drivers/clk/Makefile |1 +
drivers/clk/omap/Makefile |1 +
drivers/clk/omap/clk.c| 39 +++
include/linux/clk/omap.h | 24
4 files changed, 65 insertions(+)
create mode 100644 drivers/clk/omap/Makefile
create mode 100644 drivers/clk/omap/clk.c
create mode 100644 include/linux/clk/omap.h
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 137d3e7..1d5a2ec 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -30,6 +30,7 @@ obj-$(CONFIG_ARCH_VT8500) += clk-vt8500.o
obj-$(CONFIG_ARCH_ZYNQ)+= clk-zynq.o
obj-$(CONFIG_ARCH_TEGRA) += tegra/
obj-$(CONFIG_PLAT_SAMSUNG) += samsung/
+obj-$(CONFIG_ARCH_OMAP)+= omap/
obj-$(CONFIG_X86) += x86/
diff --git a/drivers/clk/omap/Makefile b/drivers/clk/omap/Makefile
new file mode 100644
index 000..8195931
--- /dev/null
+++ b/drivers/clk/omap/Makefile
@@ -0,0 +1 @@
+obj-y += clk.o
diff --git a/drivers/clk/omap/clk.c b/drivers/clk/omap/clk.c
new file mode 100644
index 000..4bf1929
--- /dev/null
+++ b/drivers/clk/omap/clk.c
@@ -0,0 +1,39 @@
+/*
+ * OMAP PRCM clock driver
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ * Tero Kristo
+ * Mike Turquette
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+
+/* FIXME - should the OMAP PRCM clock driver match generic types? */
+static const struct of_device_id clk_match[] = {
+ {.compatible = "fixed-clock", .data = of_fixed_clk_setup, },
+ {.compatible = "mux-clock", .data = of_mux_clk_setup, },
+ {.compatible = "fixed-factor-clock",
+ .data = of_fixed_factor_clk_setup, },
+ {.compatible = "divider-clock", .data = of_divider_clk_setup, },
+ {.compatible = "gate-clock", .data = of_gate_clk_setup, },
+ {},
+};
+
+/* FIXME - need to initialize early; skip real driver registration & probe */
+int __init dt_omap_clk_init(void)
+{
+ of_clk_init(clk_match);
+ return 0;
+}
diff --git a/include/linux/clk/omap.h b/include/linux/clk/omap.h
new file mode 100644
index 000..647f02f
--- /dev/null
+++ b/include/linux/clk/omap.h
@@ -0,0 +1,24 @@
+/*
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#ifndef __LINUX_CLK_OMAP_H_
+#define __LINUX_CLK_OMAP_H_
+
+int __init dt_omap_clk_init(void);
+
+#endif
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3 3/9] CLK: OMAP4: Add DPLL clock support
The OMAP clock driver now supports DPLL clock type. This patch also
adds support for DT DPLL nodes.
Signed-off-by: Tero Kristo
---
drivers/clk/omap/Makefile |2 +-
drivers/clk/omap/clk.c|1 +
drivers/clk/omap/dpll.c | 307 +
3 files changed, 309 insertions(+), 1 deletion(-)
create mode 100644 drivers/clk/omap/dpll.c
diff --git a/drivers/clk/omap/Makefile b/drivers/clk/omap/Makefile
index 8195931..4cad480 100644
--- a/drivers/clk/omap/Makefile
+++ b/drivers/clk/omap/Makefile
@@ -1 +1 @@
-obj-y += clk.o
+obj-y += clk.o dpll.o
diff --git a/drivers/clk/omap/clk.c b/drivers/clk/omap/clk.c
index 4bf1929..1dafdaa 100644
--- a/drivers/clk/omap/clk.c
+++ b/drivers/clk/omap/clk.c
@@ -28,6 +28,7 @@ static const struct of_device_id clk_match[] = {
.data = of_fixed_factor_clk_setup, },
{.compatible = "divider-clock", .data = of_divider_clk_setup, },
{.compatible = "gate-clock", .data = of_gate_clk_setup, },
+ {.compatible = "ti,omap4-dpll-clock", .data = of_omap4_dpll_setup, },
{},
};
diff --git a/drivers/clk/omap/dpll.c b/drivers/clk/omap/dpll.c
new file mode 100644
index 000..183ec60
--- /dev/null
+++ b/drivers/clk/omap/dpll.c
@@ -0,0 +1,307 @@
+/*
+ * OMAP DPLL clock support
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ *
+ * Tero Kristo
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/*
+ * DOC: basic adjustable divider clock that cannot gate
+ *
+ * Traits of this clock:
+ * prepare - clk_prepare only ensures that parents are prepared
+ * enable - clk_enable only ensures that parents are enabled
+ * rate - rate is adjustable. clk->rate = parent->rate / divisor
+ * parent - fixed parent. No clk_set_parent support
+ */
+
+#define to_clk_divider(_hw) container_of(_hw, struct clk_divider, hw)
+
+#define div_mask(d)((1 << ((d)->width)) - 1)
+
+static const struct clk_ops dpll_m4xen_ck_ops = {
+ .enable = &omap3_noncore_dpll_enable,
+ .disable= &omap3_noncore_dpll_disable,
+ .recalc_rate= &omap4_dpll_regm4xen_recalc,
+ .round_rate = &omap4_dpll_regm4xen_round_rate,
+ .set_rate = &omap3_noncore_dpll_set_rate,
+ .get_parent = &omap2_init_dpll_parent,
+};
+
+static const struct clk_ops dpll_core_ck_ops = {
+ .recalc_rate= &omap3_dpll_recalc,
+ .get_parent = &omap2_init_dpll_parent,
+};
+
+static const struct clk_ops dpll_ck_ops = {
+ .enable = &omap3_noncore_dpll_enable,
+ .disable= &omap3_noncore_dpll_disable,
+ .recalc_rate= &omap3_dpll_recalc,
+ .round_rate = &omap2_dpll_round_rate,
+ .set_rate = &omap3_noncore_dpll_set_rate,
+ .get_parent = &omap2_init_dpll_parent,
+ .init = &omap2_init_clk_clkdm,
+};
+
+static const struct clk_ops dpll_x2_ck_ops = {
+ .recalc_rate= &omap3_clkoutx2_recalc,
+};
+
+struct clk *omap_clk_register_dpll(struct device *dev, const char *name,
+ const char **parent_names, int num_parents, unsigned long flags,
+ struct dpll_data *dpll_data, const char *clkdm_name,
+ const struct clk_ops *ops)
+{
+ struct clk *clk;
+ struct clk_init_data init;
+ struct clk_hw_omap *clk_hw;
+
+ /* allocate the divider */
+ clk_hw = kzalloc(sizeof(struct clk_hw_omap), GFP_KERNEL);
+ if (!clk_hw) {
+ pr_err("%s: could not allocate clk_hw_omap\n", __func__);
+ return ERR_PTR(-ENOMEM);
+ }
+
+ clk_hw->dpll_data = dpll_data;
+ clk_hw->ops = &clkhwops_omap3_dpll;
+ clk_hw->clkdm_name = clkdm_name;
+ clk_hw->hw.init = &init;
+
+ init.name = name;
+ init.ops = ops;
+ init.flags = flags;
+ init.parent_names = parent_names;
+ init.num_parents = num_parents;
+
+ /* register the clock */
+ clk = clk_register(dev, &clk_hw->hw);
+
+ if (IS_ERR(clk))
+ kfree(clk_hw);
+ else
+ omap2_init_clk_hw_omap_clocks(clk);
+
+ return clk;
+}
+
+struct clk *omap_clk_register_dpll_x2(struct device *dev, const char *name,
+ const char *parent_name, void __iomem *reg,
+ const struct clk_ops *ops)
+{
+ struct clk *clk;
+ struct clk_init_data init;
+ struct clk_hw_omap *clk_hw;
+
+
[PATCHv3 0/9] ARM: OMAP4 clock data conversion to DT
Hi, Changes compared to previous version: PATCH 2 - removed some unnecessary headers + module defs - added Mike under copyright PATCH 4 - fixed the copyright in the header file PATCH 8 - removed a few incorrect comments from the data file - moved /include/ for the clock DT file under omap4 root from soc -> should save some memory based on comments to previous rev This set is also rebased on top of Mike's latest clk binding patches (V3.) Boot + suspend tested with OMAP4 panda board. I also have OMAP5 + DRA7 clock data in the same format, these have been tested with trees that have support for these SoCs. I will publish these once this set moves forward, or alternatively with next rev of this set if requested. Test branch also still available (with O4 support only): git://gitorious.org/~kristo/omap-pm/omap-pm-work.git branch: mainline-3.10-rc6-omap4-dt-clks-v3 -Tero -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3 4/9] CLK: omap: move part of the machine specific clock header contents to driver
Some of the clock.h contents are needed by the new OMAP clock driver,
including dpll_data and clk_hw_omap. Thus, move these to the generic
omap header file which can be accessed by the driver.
Signed-off-by: Tero Kristo
---
arch/arm/mach-omap2/clock.h | 150 +
include/linux/clk/omap.h| 155 ++-
2 files changed, 155 insertions(+), 150 deletions(-)
diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h
index 7aa32cd..3238c57 100644
--- a/arch/arm/mach-omap2/clock.h
+++ b/arch/arm/mach-omap2/clock.h
@@ -21,6 +21,7 @@
#include
#include
+#include
struct omap_clk {
u16 cpu;
@@ -178,83 +179,6 @@ struct clksel {
const struct clksel_rate *rates;
};
-/**
- * struct dpll_data - DPLL registers and integration data
- * @mult_div1_reg: register containing the DPLL M and N bitfields
- * @mult_mask: mask of the DPLL M bitfield in @mult_div1_reg
- * @div1_mask: mask of the DPLL N bitfield in @mult_div1_reg
- * @clk_bypass: struct clk pointer to the clock's bypass clock input
- * @clk_ref: struct clk pointer to the clock's reference clock input
- * @control_reg: register containing the DPLL mode bitfield
- * @enable_mask: mask of the DPLL mode bitfield in @control_reg
- * @last_rounded_rate: cache of the last rate result of omap2_dpll_round_rate()
- * @last_rounded_m: cache of the last M result of omap2_dpll_round_rate()
- * @last_rounded_m4xen: cache of the last M4X result of
- * omap4_dpll_regm4xen_round_rate()
- * @last_rounded_lpmode: cache of the last lpmode result of
- * omap4_dpll_lpmode_recalc()
- * @max_multiplier: maximum valid non-bypass multiplier value (actual)
- * @last_rounded_n: cache of the last N result of omap2_dpll_round_rate()
- * @min_divider: minimum valid non-bypass divider value (actual)
- * @max_divider: maximum valid non-bypass divider value (actual)
- * @modes: possible values of @enable_mask
- * @autoidle_reg: register containing the DPLL autoidle mode bitfield
- * @idlest_reg: register containing the DPLL idle status bitfield
- * @autoidle_mask: mask of the DPLL autoidle mode bitfield in @autoidle_reg
- * @freqsel_mask: mask of the DPLL jitter correction bitfield in @control_reg
- * @idlest_mask: mask of the DPLL idle status bitfield in @idlest_reg
- * @lpmode_mask: mask of the DPLL low-power mode bitfield in @control_reg
- * @m4xen_mask: mask of the DPLL M4X multiplier bitfield in @control_reg
- * @auto_recal_bit: bitshift of the driftguard enable bit in @control_reg
- * @recal_en_bit: bitshift of the PRM_IRQENABLE_* bit for recalibration IRQs
- * @recal_st_bit: bitshift of the PRM_IRQSTATUS_* bit for recalibration IRQs
- * @flags: DPLL type/features (see below)
- *
- * Possible values for @flags:
- * DPLL_J_TYPE: "J-type DPLL" (only some 36xx, 4xxx DPLLs)
- *
- * @freqsel_mask is only used on the OMAP34xx family and AM35xx.
- *
- * XXX Some DPLLs have multiple bypass inputs, so it's not technically
- * correct to only have one @clk_bypass pointer.
- *
- * XXX The runtime-variable fields (@last_rounded_rate, @last_rounded_m,
- * @last_rounded_n) should be separated from the runtime-fixed fields
- * and placed into a different structure, so that the runtime-fixed data
- * can be placed into read-only space.
- */
-struct dpll_data {
- void __iomem*mult_div1_reg;
- u32 mult_mask;
- u32 div1_mask;
- struct clk *clk_bypass;
- struct clk *clk_ref;
- void __iomem*control_reg;
- u32 enable_mask;
- unsigned long last_rounded_rate;
- u16 last_rounded_m;
- u8 last_rounded_m4xen;
- u8 last_rounded_lpmode;
- u16 max_multiplier;
- u8 last_rounded_n;
- u8 min_divider;
- u16 max_divider;
- u8 modes;
- void __iomem*autoidle_reg;
- void __iomem*idlest_reg;
- u32 autoidle_mask;
- u32 freqsel_mask;
- u32 idlest_mask;
- u32 dco_mask;
- u32 sddiv_mask;
- u32 lpmode_mask;
- u32 m4xen_mask;
- u8 auto_recal_bit;
- u8 recal_en_bit;
- u8 recal_st_bit;
- u8 flags;
-};
-
/*
* struct clk.flags possibilities
*
@@ -274,56 +198,6 @@ struct dpll_data {
#define INVERT_ENABLE (1 << 4)/* 0 enables, 1 disables */
#define CLOCK_CLKOUTX2 (1 << 5)
-/**
- * struct clk_hw_omap - OMAP struct clk
- * @node: lis
[PATCHv3 8/9] ARM: dts: omap4 clock data
This patch creates a unique node for each clock in the OMAP4 power,
reset and clock manager (PRCM).
Signed-off-by: Tero Kristo
---
arch/arm/boot/dts/omap4-clocks.dtsi | 1692 +++
arch/arm/boot/dts/omap4.dtsi|2 +
2 files changed, 1694 insertions(+)
create mode 100644 arch/arm/boot/dts/omap4-clocks.dtsi
diff --git a/arch/arm/boot/dts/omap4-clocks.dtsi
b/arch/arm/boot/dts/omap4-clocks.dtsi
new file mode 100644
index 000..2ece8b0
--- /dev/null
+++ b/arch/arm/boot/dts/omap4-clocks.dtsi
@@ -0,0 +1,1692 @@
+/*
+ * Device Tree Source for OMAP4 clock data
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/* Root clocks */
+extalt_clkin_ck: extalt_clkin_ck {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <5900>;
+};
+
+pad_clks_src_ck: pad_clks_src_ck {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <1200>;
+};
+
+pad_clks_ck: pad_clks_ck@4a004108 {
+ compatible = "gate-clock";
+ reg = <0x4a004108 0x4>;
+ bit-shift = <8>;
+ clocks = <&pad_clks_src_ck>;
+ #clock-cells = <0>;
+};
+
+pad_slimbus_core_clks_ck: pad_slimbus_core_clks_ck {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <1200>;
+};
+
+secure_32k_clk_src_ck: secure_32k_clk_src_ck {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <32768>;
+};
+
+slimbus_src_clk: slimbus_src_clk {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <1200>;
+};
+
+slimbus_clk: slimbus_clk@4a004108 {
+ compatible = "gate-clock";
+ reg = <0x4a004108 0x4>;
+ bit-shift = <10>;
+ clocks = <&slimbus_src_clk>;
+ #clock-cells = <0>;
+};
+
+sys_32k_ck: sys_32k_ck {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <32768>;
+};
+
+virt_1200_ck: virt_1200_ck {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <1200>;
+};
+
+virt_1300_ck: virt_1300_ck {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <1300>;
+};
+
+virt_1680_ck: virt_1680_ck {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <1680>;
+};
+
+virt_1920_ck: virt_1920_ck {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <1920>;
+};
+
+virt_2600_ck: virt_2600_ck {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <2600>;
+};
+
+virt_2700_ck: virt_2700_ck {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <2700>;
+};
+
+virt_3840_ck: virt_3840_ck {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <3840>;
+};
+
+sys_clkin_ck: sys_clkin_ck@4a306110 {
+ compatible = "mux-clock";
+ clocks = <&virt_1200_ck>, <&virt_1300_ck>, <&virt_1680_ck>,
<&virt_1920_ck>, <&virt_2600_ck>, <&virt_2700_ck>,
<&virt_3840_ck>;
+ #clock-cells = <0>;
+ reg = <0x4a306110 0x4>;
+ bit-mask = <0x7>;
+ index-starts-at-one;
+};
+
+tie_low_clock_ck: tie_low_clock_ck {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <0>;
+};
+
+utmi_phy_clkout_ck: utmi_phy_clkout_ck {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <6000>;
+};
+
+xclk60mhsp1_ck: xclk60mhsp1_ck {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <6000>;
+};
+
+xclk60mhsp2_ck: xclk60mhsp2_ck {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <6000>;
+};
+
+xclk60motg_ck: xclk60motg_ck {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <6000>;
+};
+
+/* Module clocks and DPLL outputs */
+abe_dpll_bypass_clk_mux_ck: abe_dpll_bypass_clk_mux_ck@4a306108 {
+ compatible = "mux-clock";
+ clocks = <&sys_clkin_ck>, <&sys_32k_ck>;
+ #clock-cells = <0>;
+ reg = <0x4a306108 0x4>;
+ bit-mask = <0x1>;
+ bit-shift = <24>;
+};
+
+abe_dpll_refclk_mux_ck: abe_dpll_refclk_mux_ck@4a30610c {
+ compatible = "mux-clock";
+ clocks = <&sys_clkin_ck>, <&sys_32k_ck>;
+ #clock-cells = <0>;
+ reg = <0x4a30610c 0x4>;
+ bit-mask = <0x1>;
+};
+
+/* DPLL_ABE */
+dpll_abe_ck: dpll_abe_ck {
+ clocks = <&abe_dpll_refclk_mux_ck>;
+ #clock-cells = <0>;
+ reg = <0x4a0041e0 0x4>, <0x4a0041e4 0x4>, <0x4a0041e8 0x4>, <0x4a0041ec
0x4>;
+
Re: [PATCH v2] ARM: DTS: OMAP4: Add OMAP4 Blaze Tablet support
On 06/25/2013 06:32 AM, Ruslan Bilovol wrote: The OMAP4 Blaze Tablet is TI OMAP4 processor-based development platform in a tablet formfactor. The platform contains many of the features found in present-day handsets (such as audio, video, wireless functions and user interfaces) and in addition contains features for software development and test. This patch adds initial support for the OMAP4 Blaze Tablet development platform. Additional functionality depends on different drivers and code modifications that are not upstreamed yet or do not support DT yet, so will be added later. http://svtronics.com/omap/sevm4460,blaze,omap might help too :) [...] + +#include "twl6030.dtsi" + Might be good to see the TWL interrupt pin information made available as well? [...] 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] Documentation: dt: bindings: TI WiLink modules
On Tue, 2013-06-25 at 14:12 +0300, Felipe Balbi wrote: > On Tue, Jun 25, 2013 at 11:35:30AM +0300, Luciano Coelho wrote: > > +- tcxoclock: the internal WLAN TCXO clock frequency (required for > > + WiLink7 not used for WiLink6 and WiLink8). Must be one of the > > + following: > > + 0 = 19.200 MHz > > + 1 = 26.000 MHz > > + 2 = 38.400 MHz > > + 3 = 52.000 MHz > > + 4 = 16.368 MHz > > + 5 = 32.736 MHz > > + 6 = 16.800 MHz > > + 7 = 33.600 MHz > > DTS files are pre-processed, so you could add defines in a header and > share the header between DTS and driver. Could help you having: > > tcxoclock = WILINK_19_200MHz; > > instead of > > tcxoclock = 0; I don't see any .dts file really doing this. There are some imx*.dtsi files that include imx*.h files, but I don't see these headers being included in any source code file. In fact, we already have all these values defined in include/linux/wl12xx.h, so it could be nice to reuse. But the cross-directory includes would look "funny". And I think it's a bit overkill. These values are actually used by the firmware itself, not only the driver, so they are also platform independent and not related to the OS. -- Luca. -- 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: [BISECTED] 3.10-rc1 OMAP1 GPIO IRQ regression
On Tue, Jun 25, 2013 at 8:04 AM, Tony Lindgren wrote: > * Grant Likely [130624 09:00]: >> On Mon, Jun 24, 2013 at 8:21 AM, Tony Lindgren wrote: >> > * Javier Martinez Canillas [130623 18:08]: >> >> On Mon, Jun 24, 2013 at 1:43 AM, Aaro Koskinen >> >> wrote: >> >> > Hi, >> >> > >> >> > On Mon, Jun 24, 2013 at 01:06:37AM +0200, Javier Martinez Canillas >> >> > wrote: >> >> >> On Mon, Jun 24, 2013 at 12:16 AM, Aaro Koskinen >> >> >> wrote: >> >> >> > What is the status of this patch? We're already at 3.10-rc7 and GPIO >> >> >> > IRQs are still broken on OMAP1. >> >> > >> >> > [...] >> >> > >> >> >> There is a problem with this patch. >> >> > >> >> > [...] >> >> > >> >> >> So I think that the correct solution is to add SPARSE_IRQ support to >> >> >> omap1 and not reverting Jon's patch. Of course this may not be >> >> >> possible since we are so close to 3.10 and most OMAP patches already >> >> >> merged for 3.11 but we should definitely try to have this at least for >> >> >> 3.12. Otherwise we won't be able to move to DT-only booting for >> >> >> OMAP2+. >> >> > >> >> > OMAP1 does not use DT. So we could put this code under #ifdef >> >> > CONFIG_ARCH_OMAP1 or similar. It's just a few lines of code. OMAP2+ >> >> > work should not regress OMAP1. >> >> > >> >> > Demanding SPARSE_IRQ support for OMAP1 should have been discussed before >> >> > these changes were made. It's not reasonable to assume such things can >> >> > be made during rc-cycle. Also, now, I don't think it's reasonable to >> >> > wait for that to be done, as it would take until 3.12 or even later to >> >> > get OMAP1 functional again. >> >> > >> >> > A. >> >> >> >> Hi, >> >> >> >> Yes, since we are so late in the -rc cycle and OMAP1 is currently >> >> broken I agree that the only sensible solution is to revert the patch >> >> for now. >> > >> > Agreed. >> > >> >> I just wanted to point out the issue that keeping the OMAP GPIO driver >> >> using legacy mapping domain represents a blocker to have GPIO-IRQ >> >> working with Device Tree for OMAP2+ >> > >> > Yes. We can do the ifdef Aaro suggested, and let's also plan on >> > converting omap1 to use SPARSE_IRQ. But with the ifdef we can cut >> > away the dependency between these two. >> >> Alright. Sorry I dropped the ball on this one. I've lost track of >> which patch needs to get applied, but given that it is so late in the >> cycle, it would be better for someone else to apply the change, test >> and send a pull request to Linus. I'm okay with it going through the >> OMAP tree if that is the most expedient. Alternately, send me the pull >> request and I'll pass it on to Linus. > > OK, I'll wait for Aaro's ack on Javier's patch and then put it into a > branch for you. Thanks Tony. g. -- 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] ARM: DTS: OMAP4: Add OMAP4 Blaze Tablet support
The OMAP4 Blaze Tablet is TI OMAP4 processor-based
development platform in a tablet formfactor.
The platform contains many of the features found in
present-day handsets (such as audio, video, wireless
functions and user interfaces) and in addition
contains features for software development and test.
This patch adds initial support for the OMAP4 Blaze
Tablet development platform. Additional functionality
depends on different drivers and code modifications that
are not upstreamed yet or do not support DT yet, so will
be added later.
Signed-off-by: Ruslan Bilovol
---
v2:
- Rebased onto 'for_3.11/dts' branch of bcousson/linux-omap-dt tree
- Bound more hardware and picked up updates from omap4-sdp
arch/arm/boot/dts/Makefile |1 +
arch/arm/boot/dts/omap4-blazetablet.dts | 483 +++
2 files changed, 484 insertions(+)
create mode 100644 arch/arm/boot/dts/omap4-blazetablet.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 05da469..4fafde1 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -150,6 +150,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
omap4-var-som.dtb \
omap4-sdp.dtb \
omap4-sdp-es23plus.dtb \
+ omap4-blazetablet.dtb \
omap5-uevm.dtb \
am335x-evm.dtb \
am335x-evmsk.dtb \
diff --git a/arch/arm/boot/dts/omap4-blazetablet.dts
b/arch/arm/boot/dts/omap4-blazetablet.dts
new file mode 100644
index 000..07f40b6
--- /dev/null
+++ b/arch/arm/boot/dts/omap4-blazetablet.dts
@@ -0,0 +1,483 @@
+/*
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * Author: Ruslan Bilovol
+ *
+ * based on omap4-sdp.dts
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+/dts-v1/;
+
+#include "omap443x.dtsi"
+#include "elpida_ecb240abacn.dtsi"
+
+/ {
+ model = "TI OMAP4 Blaze Tablet";
+ compatible = "ti,omap4-blazetablet", "ti,omap4430", "ti,omap4";
+
+ memory {
+ device_type = "memory";
+ reg = <0x8000 0x4000>; /* 1 GB */
+ };
+
+ vdd_eth: fixedregulator-vdd-eth {
+ compatible = "regulator-fixed";
+ regulator-name = "VDD_ETH";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ gpio = <&gpio2 16 0>; /* gpio line 48 */
+ enable-active-high;
+ regulator-boot-on;
+ };
+
+ vbat: fixedregulator-vbat {
+ compatible = "regulator-fixed";
+ regulator-name = "VBAT";
+ regulator-min-microvolt = <375>;
+ regulator-max-microvolt = <375>;
+ regulator-boot-on;
+ };
+
+ gpio_keys {
+ compatible = "gpio-keys";
+
+ volume_up {
+ label = "volume-up";
+ linux,code = <115>; /* KEY_VOLUMEUP */
+ gpios = <&gpio2 11 GPIO_ACTIVE_HIGH>; /* 43 */
+ gpio-key,wakeup;
+ };
+
+ home {
+ label = "home";
+ linux,code = <102>; /* KEY_HOME */
+ gpios = <&gpio2 14 GPIO_ACTIVE_HIGH>; /* 46 */
+ gpio-key,wakeup;
+ };
+
+ volume_down {
+ label = "volume-down";
+ linux,code = <114>; /* KEY_VOLUMEDOWN */
+ gpios = <&gpio2 15 GPIO_ACTIVE_HIGH>; /* 47 */
+ gpio-key,wakeup;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ debug2 {
+ label = "omap4:green:debug2";
+ gpios = <&gpio6 13 GPIO_ACTIVE_HIGH>; /* 173 */
+ };
+
+ debug4 {
+ label = "omap4:green:debug4";
+ gpios = <&gpio2 18 GPIO_ACTIVE_HIGH>; /* 50 */
+ };
+
+ user1 {
+ label = "omap4:blue:user";
+ gpios = <&gpio6 9 GPIO_ACTIVE_HIGH>; /* 169 */
+ };
+
+ user2 {
+ label = "omap4:red:user";
+ gpios = <&gpio6 10 GPIO_ACTIVE_HIGH>; /* 170 */
+ };
+
+ user3 {
+ label = "omap4:green:user";
+ gpios = <&gpio6 14 GPIO_ACTIVE_HIGH>; /* 174 */
+ };
+ };
+
+ sound {
+ compatible = "ti,abe-twl6040";
+ ti,model = "BlazeTablet";
+
+ ti,jack-detection = <1>;
+ ti,mclk-freq = <3840>;
+
+ ti,mcpdm = <&mcpdm>;
+ ti,dmic = <&dmic>;
+
+
Re: [PATCH] Documentation: dt: bindings: TI WiLink modules
Hi, On Tue, Jun 25, 2013 at 11:35:30AM +0300, Luciano Coelho wrote: > Add device tree bindings documentation for the TI WiLink modules. > Currently only the WLAN part of the WiLink6, WiLink7 and WiLink8 > modules is supported. > > Signed-off-by: Luciano Coelho > --- > > I created a new directory under net to contain wireless bindings > documentation. > > The actual implementation in the driver will follow separately. > > .../devicetree/bindings/net/wireless/ti-wilink.txt | 46 > > 1 file changed, 46 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/net/wireless/ti-wilink.txt > > diff --git a/Documentation/devicetree/bindings/net/wireless/ti-wilink.txt > b/Documentation/devicetree/bindings/net/wireless/ti-wilink.txt > new file mode 100644 > index 000..d8e8bfbb > --- /dev/null > +++ b/Documentation/devicetree/bindings/net/wireless/ti-wilink.txt > @@ -0,0 +1,46 @@ > +TI WiLink Wireless Modules Device Tree Bindings > +=== > + > +The WiLink modules provide wireless connectivity, such as WLAN, > +Bluetooth, FM and NFC. > + > +There are several different modules available, which can be grouped by > +their generation: WiLink6, WiLink7 and WiLink8. WiLink4 is not > +currently supported with device tree. > + > +Currently, only the WLAN portion of the modules is supported with > +device tree. > + > +Required properties: > + > + > +- compatible: should be "ti,wilink6", "ti,wilink7" or "ti,wilink8" > +- interrupt-parent: the interrupt controller > +- interrupts: out-of-band WLAN interrupt > + See the interrupt controller's bindings documentation for > + detailed definition. > + > +Optional properties: > + > + > +- refclock: the internal WLAN reference clock frequency (required for > + WiLink6 and WiLink7; not used for WiLink8). Must be one of the > + following: > + 0 = 19.2 MHz > + 1 = 26.0 MHz > + 2 = 38.4 MHz > + 3 = 52.0 MHz > + 4 = 38.4 MHz, XTAL > + 5 = 26.0 MHz, XTAL > + > +- tcxoclock: the internal WLAN TCXO clock frequency (required for > + WiLink7 not used for WiLink6 and WiLink8). Must be one of the > + following: > + 0 = 19.200 MHz > + 1 = 26.000 MHz > + 2 = 38.400 MHz > + 3 = 52.000 MHz > + 4 = 16.368 MHz > + 5 = 32.736 MHz > + 6 = 16.800 MHz > + 7 = 33.600 MHz DTS files are pre-processed, so you could add defines in a header and share the header between DTS and driver. Could help you having: tcxoclock = WILINK_19_200MHz; instead of tcxoclock = 0; -- balbi signature.asc Description: Digital signature
Re: MMC breakage on 3.11/cleanup
On Mon, Jun 24, 2013 at 11:49:44PM -0700, Tony Lindgren wrote:
> * Joel A Fernandes [130624 15:33]:
> > Hi Tony,
> >
> > Following branch breaks MMC for me on am33xx (beaglebone):
> > http://git.kernel.org/cgit/linux/kernel/git/tmlind/linux-omap.git/log/?h=omap-for-v3.11/cleanup
> >
> > I tried to work around it by specifying interrupt and reg property in DT:
> > mmc1: mmc@4806 {
> > compatible = "ti,omap3-hsmmc";
> > ti,hwmods = "mmc1";
> > ti,dual-volt;
> > ti,needs-special-reset;
> > dmas = <&edma 24
> > &edma 25>;
> > dma-names = "tx", "rx";
> > interrupts = <64>;
> > interrupt-parent = <&intc>;
> > reg = <0x4806 0x1000>;
> > status = "disabled";
> > };
> >
> > The probe succeeds but I still get a "Waiting for root device
> > /dev/mmcblk0p2" when booting over MMC.
> >
> > If you're planning to push the cleanup branch, can we temporarily add
> > the hwmod data back while we work on this issue so that upstream MMC
> > is kept working.
>
> Yes the cleanup branch is queued up. Can you please send a patch
> reverting the MMC parts of the hwmod change for am33xx for now,
> then try to find the real cause for the breakage?
I had mentioned that Joel should *not* depend on hwmod data and if
adding interrupts to DTS caused issues, that issue should be resolved.
http://marc.info/?l=linux-omap&m=137124891908957&w=2
--
balbi
signature.asc
Description: Digital signature
RE: [PATCH 4/4] regulator: Palmas: Add TPS659038 support
Hi Samuel,
> -Original Message-
> From: J, KEERTHY
> Sent: Friday, June 21, 2013 2:38 PM
> To: sa...@linux.intel.com
> Cc: broo...@kernel.org; ldewan...@nvidia.com;
> grant.lik...@secretlab.ca; swar...@nvidia.com; linux-
> ker...@vger.kernel.org; linux-...@vger.kernel.org; g...@slimlogic.co.uk;
> linux-omap@vger.kernel.org
> Subject: RE: [PATCH 4/4] regulator: Palmas: Add TPS659038 support
>
> Hi Samuel,
>
> > -Original Message-
> > From: J, KEERTHY
> > Sent: Thursday, June 20, 2013 4:32 PM
> > To: linux-omap@vger.kernel.org; sa...@linux.intel.com
> > Cc: broo...@kernel.org; J, KEERTHY; ldewan...@nvidia.com;
> > grant.lik...@secretlab.ca; swar...@nvidia.com; linux-
> > ker...@vger.kernel.org; linux-...@vger.kernel.org; g...@slimlogic.co.uk
> > Subject: [PATCH 4/4] regulator: Palmas: Add TPS659038 support
> >
> > Add TPS659038 support.
> >
>
> Could you pull this one too?
A gentle ping on this.
>
> > Signed-off-by: J Keerthy
> > Acked-by: Mark Brown
> > ---
> > drivers/regulator/palmas-regulator.c |1 +
> > 1 files changed, 1 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/regulator/palmas-regulator.c
> > b/drivers/regulator/palmas-regulator.c
> > index 1ae1e83..d0c8785 100644
> > --- a/drivers/regulator/palmas-regulator.c
> > +++ b/drivers/regulator/palmas-regulator.c
> > @@ -1054,6 +1054,7 @@ static struct of_device_id
> of_palmas_match_tbl[]
> > = {
> > { .compatible = "ti,tps65913-pmic", },
> > { .compatible = "ti,tps65914-pmic", },
> > { .compatible = "ti,tps80036-pmic", },
> > + { .compatible = "ti,tps659038-pmic", },
> > { /* end */ }
> > };
> >
> > --
> > 1.7.5.4
>
> Regards,
> Keerthy
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: [RFC 0/4] Cleanup PRM and CM regbit headers
On Tuesday 25 June 2013 12:44 PM, Tony Lindgren wrote: >> Rajendra Nayak (4): >> > ARM: OMAP2: PRM/CM: Cleanup unused header contents >> > ARM: OMAP3: PRM/CM: Cleanup unused header contents >> > ARM: OMAP4: PRM/CM: Cleanup unused header contents >> > ARM: OMAP5: PRM/CM: Cleanup unused header contents >> > >> > arch/arm/mach-omap2/cm-regbits-24xx.h | 317 >> > arch/arm/mach-omap2/cm-regbits-33xx.h | 758 - >> > arch/arm/mach-omap2/cm-regbits-34xx.h | 631 >> > arch/arm/mach-omap2/cm-regbits-44xx.h | 1557 --- >> > arch/arm/mach-omap2/cm-regbits-54xx.h | 1632 --- >> > arch/arm/mach-omap2/prm-regbits-24xx.h | 246 --- >> > arch/arm/mach-omap2/prm-regbits-33xx.h | 305 >> > arch/arm/mach-omap2/prm-regbits-34xx.h | 480 -- >> > arch/arm/mach-omap2/prm-regbits-44xx.h | 2225 -- >> > arch/arm/mach-omap2/prm-regbits-54xx.h | 2677 >> > >> > 10 files changed, 10828 deletions(-) > If things build and work after applying this, I suggest we send them > as a clean-up branch right after -rc1. They build fine, and I boot tested on the omap4/5 boards that I have too. (I had the out of tree clock data pulled in for omap5 before I did this cleanup). > > It seems that build testing and then randconfig testing > should be enough for these if they are unused and only > removal. Right, I'll do more testing and even though they should just boot fine on the omap2/3 boards too since all thats removed is anyway unused, I will still do more sanity test before posting them on -rc1. regards, Rajendra -- 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] Documentation: dt: bindings: TI WiLink modules
Add device tree bindings documentation for the TI WiLink modules. Currently only the WLAN part of the WiLink6, WiLink7 and WiLink8 modules is supported. Signed-off-by: Luciano Coelho --- I created a new directory under net to contain wireless bindings documentation. The actual implementation in the driver will follow separately. .../devicetree/bindings/net/wireless/ti-wilink.txt | 46 1 file changed, 46 insertions(+) create mode 100644 Documentation/devicetree/bindings/net/wireless/ti-wilink.txt diff --git a/Documentation/devicetree/bindings/net/wireless/ti-wilink.txt b/Documentation/devicetree/bindings/net/wireless/ti-wilink.txt new file mode 100644 index 000..d8e8bfbb --- /dev/null +++ b/Documentation/devicetree/bindings/net/wireless/ti-wilink.txt @@ -0,0 +1,46 @@ +TI WiLink Wireless Modules Device Tree Bindings +=== + +The WiLink modules provide wireless connectivity, such as WLAN, +Bluetooth, FM and NFC. + +There are several different modules available, which can be grouped by +their generation: WiLink6, WiLink7 and WiLink8. WiLink4 is not +currently supported with device tree. + +Currently, only the WLAN portion of the modules is supported with +device tree. + +Required properties: + + +- compatible: should be "ti,wilink6", "ti,wilink7" or "ti,wilink8" +- interrupt-parent: the interrupt controller +- interrupts: out-of-band WLAN interrupt + See the interrupt controller's bindings documentation for + detailed definition. + +Optional properties: + + +- refclock: the internal WLAN reference clock frequency (required for + WiLink6 and WiLink7; not used for WiLink8). Must be one of the + following: + 0 = 19.2 MHz + 1 = 26.0 MHz + 2 = 38.4 MHz + 3 = 52.0 MHz + 4 = 38.4 MHz, XTAL + 5 = 26.0 MHz, XTAL + +- tcxoclock: the internal WLAN TCXO clock frequency (required for + WiLink7 not used for WiLink6 and WiLink8). Must be one of the + following: + 0 = 19.200 MHz + 1 = 26.000 MHz + 2 = 38.400 MHz + 3 = 52.000 MHz + 4 = 16.368 MHz + 5 = 32.736 MHz + 6 = 16.800 MHz + 7 = 33.600 MHz -- 1.7.10.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: [PATCHv2] ARM: OMAP: build mach-omap code only if needed
* Arnd Bergmann [130624 07:25]: > If we build a kernel with CONFIG_ARCH_OMAP2PLUS enabled but all of the > individual SoCs disabled, we run into a large number of link errors > because if incorrect dependencies: > > arch/arm/mach-omap2/built-in.o: In function `_add_initiator_dep': > arch/arm/mach-omap2/omap_hwmod.c:691: undefined reference to > `clkdm_add_sleepdep' arch/arm/mach-omap2/built-in.o: In function > `_del_initiator_dep': > arch/arm/mach-omap2/omap_hwmod.c:720: undefined reference to > `clkdm_del_sleepdep' arch/arm/mach-omap2/built-in.o: In function `_enable': > arch/arm/mach-omap2/omap_hwmod.c:2145: undefined reference to `clkdm_in_hwsup' > arch/arm/mach-omap2/omap_hwmod.c:2147: undefined reference to > `clkdm_hwmod_enable' > arch/arm/mach-omap2/omap_hwmod.c:2191: undefined reference to > `clkdm_hwmod_disable' > arch/arm/mach-omap2/omap_hwmod.c:2146: undefined reference to > `clkdm_missing_idle_reporting' arch/arm/mach-omap2/built-in.o: In function > `_idle': > arch/arm/mach-omap2/omap_hwmod.c:2235: undefined reference to > `clkdm_hwmod_disable' arch/arm/mach-omap2/built-in.o: In function `_shutdown': > arch/arm/mach-omap2/omap_hwmod.c:2338: undefined reference to > `clkdm_hwmod_disable' arch/arm/mach-omap2/built-in.o: In function > `omap_hwmod_get_context_loss_count': > arch/arm/mach-omap2/omap_hwmod.c:4071: undefined reference to > `pwrdm_get_context_loss_count' arch/arm/mach-omap2/built-in.o: In function > `omap_pm_clkdms_setup': > arch/arm/mach-omap2/pm.c:114: undefined reference to `clkdm_allow_idle' > arch/arm/mach-omap2/pm.c:117: undefined reference to `clkdm_sleep' > arch/arm/mach-omap2/built-in.o: In function `omap2_common_pm_late_init': > arch/arm/mach-omap2/pm.c:294: undefined reference to `omap_voltage_late_init' > arch/arm/mach-omap2/built-in.o: In function `omap2_gpio_dev_init': > arch/arm/mach-omap2/gpio.c:133: undefined reference to > `pwrdm_can_ever_lose_context' > > We can avoid this if we make CONFIG_ARCH_OMAP2PLUS a silent option that > gets enabled any time that one of the SoC versions is enabled. /me hopes this does the trick finally ;) I could not apply this to anything I tried though.. Which branch is this against? Regards, Tony > Signed-off-by: Arnd Bergmann > Cc: Tony Lindgren > > diff --git a/arch/arm/configs/omap2plus_defconfig > b/arch/arm/configs/omap2plus_defconfig > index abbe319..197a0bb 100644 > --- a/arch/arm/configs/omap2plus_defconfig > +++ b/arch/arm/configs/omap2plus_defconfig > @@ -22,6 +22,10 @@ CONFIG_MODULE_SRCVERSION_ALL=y > # CONFIG_BLK_DEV_BSG is not set > CONFIG_ARCH_MULTI_V6=y > CONFIG_ARCH_OMAP2PLUS=y > +CONFIG_ARCH_OMAP2=y > +CONFIG_ARCH_OMAP3=y > +CONFIG_ARCH_OMAP4=y > +CONFIG_SOC_AM33XX=y > CONFIG_OMAP_RESET_CLOCKS=y > CONFIG_OMAP_MUX_DEBUG=y > CONFIG_ARCH_VEXPRESS_CA9X4=y > diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig > index 1bfe9ee..a07cdc9 100644 > --- a/arch/arm/mach-omap2/Kconfig > +++ b/arch/arm/mach-omap2/Kconfig > @@ -1,61 +1,10 @@ > config ARCH_OMAP > bool > > -config ARCH_OMAP2PLUS > - bool "TI OMAP2/3/4/5 SoCs with device tree support" if (ARCH_MULTI_V6 > || ARCH_MULTI_V7) > - select ARCH_HAS_CPUFREQ > - select ARCH_HAS_HOLES_MEMORYMODEL > - select ARCH_OMAP > - select ARCH_REQUIRE_GPIOLIB > - select CLKDEV_LOOKUP > - select CLKSRC_MMIO > - select GENERIC_CLOCKEVENTS > - select GENERIC_IRQ_CHIP > - select HAVE_CLK > - select OMAP_DM_TIMER > - select PINCTRL > - select PROC_DEVICETREE if PROC_FS > - select SOC_BUS > - select SPARSE_IRQ > - select USE_OF > - help > - Systems based on OMAP2, OMAP3, OMAP4 or OMAP5 > - > - > -if ARCH_OMAP2PLUS > - > -menu "TI OMAP2/3/4 Specific Features" > - > -config ARCH_OMAP2PLUS_TYPICAL > - bool "Typical OMAP configuration" > - default y > - select AEABI > - select HIGHMEM > - select I2C > - select I2C_OMAP > - select MENELAUS if ARCH_OMAP2 > - select NEON if ARCH_OMAP3 || ARCH_OMAP4 || SOC_OMAP5 > - select PM_RUNTIME > - select REGULATOR > - select TWL4030_CORE if ARCH_OMAP3 || ARCH_OMAP4 > - select TWL4030_POWER if ARCH_OMAP3 || ARCH_OMAP4 > - select VFP > - help > - Compile a kernel suitable for booting most boards > - > -config SOC_HAS_OMAP2_SDRC > - bool "OMAP2 SDRAM Controller support" > - > -config SOC_HAS_REALTIME_COUNTER > - bool "Real time free running counter" > - depends on SOC_OMAP5 > - default y > - > config ARCH_OMAP2 > bool "TI OMAP2" > - depends on ARCH_OMAP2PLUS > depends on ARCH_MULTI_V6 > - default y > + select ARCH_OMAP2PLUS > select CPU_V6 > select MULTI_IRQ_HANDLER > select SOC_HAS_OMAP2_SDRC > @@ -63,9 +12,8 @@ config ARCH_OMAP2 > > config ARCH_OMAP3 > bool "TI OMAP3" > - depends on ARCH_OMAP2PLUS > depends on ARCH_MULTI_V7 > - default y > + select ARCH_OMAP2PLUS > select ARCH_HAS_OP
Re: [RFC 0/4] Cleanup PRM and CM regbit headers
* Rajendra Nayak [130624 05:24]: > Hi, > > Over the years the PRM and CM headers for OMAP have been growing largely > due to autogeneration which creates headers for complete PRM and > CM register space, regardless of the actual usage of these registers in > software. Thanks for working on this. Yes most of this should no longer be needed. > The latest master on linux-omap (which also happens to have the OMAP5 data) > show these stats for the prm-regbits-*.h and cm-regbits-*.h alone. Not to > mention > there are other PRM/CM related headers which I am yet to look at. > > a0131687@ula0131687:~/oldhome/repos/github/linux$ cat > arch/arm/mach-omap2/prm-regbits-*.h | wc -l > 6285 > a0131687@ula0131687:~/oldhome/repos/github/linux$ cat > arch/arm/mach-omap2/cm-regbits-*.h | wc -l > 5556 > > Using some simple awk/grep scripting I cleaned these headers to retain only > the defines that > are currently used and that changes the stats to this below. > > a0131687@ula0131687:~/oldhome/repos/github/linux$ cat > arch/arm/mach-omap2/prm-regbits-*.h | wc -l > 352 > a0131687@ula0131687:~/oldhome/repos/github/linux$ cat > arch/arm/mach-omap2/cm-regbits-*.h | wc -l > 661 > > I am sharing this RFC just to take the discussion forward on how to handle > these files, and many > others which are also autogenerated, given we have newer SoCs coming up for > which the autogen output > ends up creating even larger files. Yes we should get to the point where adding new SoCs is just few hundred lines of code plus the new device drivers. > Rajendra Nayak (4): > ARM: OMAP2: PRM/CM: Cleanup unused header contents > ARM: OMAP3: PRM/CM: Cleanup unused header contents > ARM: OMAP4: PRM/CM: Cleanup unused header contents > ARM: OMAP5: PRM/CM: Cleanup unused header contents > > arch/arm/mach-omap2/cm-regbits-24xx.h | 317 > arch/arm/mach-omap2/cm-regbits-33xx.h | 758 - > arch/arm/mach-omap2/cm-regbits-34xx.h | 631 > arch/arm/mach-omap2/cm-regbits-44xx.h | 1557 --- > arch/arm/mach-omap2/cm-regbits-54xx.h | 1632 --- > arch/arm/mach-omap2/prm-regbits-24xx.h | 246 --- > arch/arm/mach-omap2/prm-regbits-33xx.h | 305 > arch/arm/mach-omap2/prm-regbits-34xx.h | 480 -- > arch/arm/mach-omap2/prm-regbits-44xx.h | 2225 -- > arch/arm/mach-omap2/prm-regbits-54xx.h | 2677 > > 10 files changed, 10828 deletions(-) If things build and work after applying this, I suggest we send them as a clean-up branch right after -rc1. It seems that build testing and then randconfig testing should be enough for these if they are unused and only removal. 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: [BISECTED] 3.10-rc1 OMAP1 GPIO IRQ regression
* Grant Likely [130624 09:00]: > On Mon, Jun 24, 2013 at 8:21 AM, Tony Lindgren wrote: > > * Javier Martinez Canillas [130623 18:08]: > >> On Mon, Jun 24, 2013 at 1:43 AM, Aaro Koskinen > >> wrote: > >> > Hi, > >> > > >> > On Mon, Jun 24, 2013 at 01:06:37AM +0200, Javier Martinez Canillas wrote: > >> >> On Mon, Jun 24, 2013 at 12:16 AM, Aaro Koskinen > >> >> wrote: > >> >> > What is the status of this patch? We're already at 3.10-rc7 and GPIO > >> >> > IRQs are still broken on OMAP1. > >> > > >> > [...] > >> > > >> >> There is a problem with this patch. > >> > > >> > [...] > >> > > >> >> So I think that the correct solution is to add SPARSE_IRQ support to > >> >> omap1 and not reverting Jon's patch. Of course this may not be > >> >> possible since we are so close to 3.10 and most OMAP patches already > >> >> merged for 3.11 but we should definitely try to have this at least for > >> >> 3.12. Otherwise we won't be able to move to DT-only booting for > >> >> OMAP2+. > >> > > >> > OMAP1 does not use DT. So we could put this code under #ifdef > >> > CONFIG_ARCH_OMAP1 or similar. It's just a few lines of code. OMAP2+ > >> > work should not regress OMAP1. > >> > > >> > Demanding SPARSE_IRQ support for OMAP1 should have been discussed before > >> > these changes were made. It's not reasonable to assume such things can > >> > be made during rc-cycle. Also, now, I don't think it's reasonable to > >> > wait for that to be done, as it would take until 3.12 or even later to > >> > get OMAP1 functional again. > >> > > >> > A. > >> > >> Hi, > >> > >> Yes, since we are so late in the -rc cycle and OMAP1 is currently > >> broken I agree that the only sensible solution is to revert the patch > >> for now. > > > > Agreed. > > > >> I just wanted to point out the issue that keeping the OMAP GPIO driver > >> using legacy mapping domain represents a blocker to have GPIO-IRQ > >> working with Device Tree for OMAP2+ > > > > Yes. We can do the ifdef Aaro suggested, and let's also plan on > > converting omap1 to use SPARSE_IRQ. But with the ifdef we can cut > > away the dependency between these two. > > Alright. Sorry I dropped the ball on this one. I've lost track of > which patch needs to get applied, but given that it is so late in the > cycle, it would be better for someone else to apply the change, test > and send a pull request to Linus. I'm okay with it going through the > OMAP tree if that is the most expedient. Alternately, send me the pull > request and I'll pass it on to Linus. OK, I'll wait for Aaro's ack on Javier's patch and then put it into a branch for you. 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: multi_v7: Add OMAP with ramdisk config bits
* Sricharan R [130624 07:39]: > Hi, > On Tuesday 18 June 2013 08:14 PM, Santosh Shilimkar wrote: > > On Tuesday 18 June 2013 04:24 AM, Tony Lindgren wrote: > >> * Santosh Shilimkar [130612 14:14]: > >>> Add ramdisk fileystem related options which lets OMAP5 and Keystone > >>> SOCs to boot till shell with multi_v7_config. > >> Please add also other v7 omaps. > >> > > Should have done first place. Sorry. > > Will update other machines and after testing, repost it. > > > > Regards, > > Santosh > > > Since CONFIG_ARCH_OMAP2PLUS=y is set in the patch, > OMAP3, OMAP4 are getting enabled by default. > > I tested OMAP4 PANDA on mainline + multi_v7_config + above patch > and it booted up fine. OK thanks for testing. Those default y things will be going away, but we can update both defconfigs after that. Acked-by: Tony Lindgren -- 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
