Re: [PATCH 0/5 V2 RESEND] ARM: OMAP: TLL driver implementation for USB host driver
On Mon, Jul 2, 2012 at 8:01 PM, Samuel Ortiz sa...@linux.intel.com wrote: Hi Keshava, On Tue, Jun 26, 2012 at 04:56:02PM +0530, Keshava Munegowda wrote: The TLL configuration is removed from the UHH driver and implemented as a seperate platform driver. Now, the UHH driver configures the TLL through API's exported by the TLL platform driver. The TLL is an has independent hardware mod structure for in OMAP3 and later chips, hence an dedicated platform driver is created. I'm sort of ok with that split although the new driver is definitely not an MFD one, but I guess there's no better place for it. Now, a few comments before applying it: - I'd appreciate to get ACKs from e.g. Tony for the OMAP parts. - Patch #3 doesn't apply on top of my for-next branch. Would you mind rebasing it properly ? - Fix the coypright years to 2012. Cheers, Samuel. Hi samuel just now I have posted v3 of this series. This series is on top of Rus dill patch : http://permalink.gmane.org/gmane.linux.usb.general/65988 and my patch : ttp://permalink.gmane.org/gmane.linux.usb.general/66239 you need these patches before applying this series. regards keshava -- 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 07/29] mfd: omap-usb: use clk_prepare_enable and clk_disable_unprepare
Hi Rajendra, On Mon, Jul 02, 2012 at 04:46:21PM +0530, Rajendra Nayak wrote: Hi Samuel, On Monday 02 July 2012 04:48 PM, Samuel Ortiz wrote: Hi Rajendra, On Thu, Jun 14, 2012 at 06:16:56PM +0530, Rajendra Nayak wrote: As we move to Common clk framework use clk_prepare_enable() instead of clk_enable() and similarly clk_disable_unprepare() instead of clk_disable() Signed-off-by: Rajendra Nayakrna...@ti.com Cc: Samuel Ortizsa...@linux.intel.com --- drivers/mfd/omap-usb-host.c | 28 ++-- 1 files changed, 14 insertions(+), 14 deletions(-) Patch applied, many thanks. Sorry, I was asked to base these changes on top of work done by Keshava [1], to split the driver, which is still under review/not pulled. I am waiting for those to settle to repost these changes. Can you please drop this one for now? I just did, although I think Keshava could have based his work on top of yours, as he's rebasing his patchset at the moment. Anyway, patch is removed now. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- 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] remoteproc: block premature rproc booting
Hi Ohad, Sjur, Ludovic, Loic - what remoteproc API are you using today? We'd like to get rid of the existing get/put interface and instead have everyone use the boot/shutdown one, just like rpmsg is doing today. Are you ok with this change? Yes, I'm ok with this, but I cannot answer for Loic and Ludovic. Regards, Sjur -- 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] remoteproc: block premature rproc booting
On Mon, Jul 2, 2012 at 6:15 PM, Sjur BRENDELAND sjur.brandel...@stericsson.com wrote: Sjur, Ludovic, Loic - what remoteproc API are you using today? We'd like to get rid of the existing get/put interface and instead have everyone use the boot/shutdown one, just like rpmsg is doing today. Are you ok with this change? Yes, I'm ok with this, but I cannot answer for Loic and Ludovic. Thanks, Sjur. I think Ludovic and Loic should be ok with this because their use cases are very much like OMAP's (mostly rpmsg drivers). Ohad. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: hwmod data: Fix wrong McBSP clock alias on OMAP4
Hi Paul, On 06/18/2012 05:57 PM, Paul Walmsley wrote: On Mon, 18 Jun 2012, Cousson, Benoit wrote: The commit 503d0ea24d1d3dd3db95e5e0edd693da7a2a23eb ARM: OMAP4: hwmod data: Add aliases for McBSP fclk clocks added a wrong prcm_clk alias for PRCM clock whereas the McBSP driver and previous OMAPs are using prcm_fck. It thus lead to the following warning. [ 47.409729] omap-mcbsp: clks: could not clk_get() prcm_fck Fix that by changing the opt_clk role to prcm_fck. Reported-by: Misael Lopez Cruz misael.lo...@ti.com Signed-off-by: Benoit Cousson b-cous...@ti.com Cc: Peter Ujfalusi peter.ujfal...@ti.com Tested-by: Sebastien Guiriec s-guir...@ti.com Thanks, will queue this as part of the next 3.5-rc series. I might be wrong but it seems that this one is not yet in 3.5-rc5. Thanks, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2 2/4] net ethernet introduce mac_la_ap helper
On Monday 02 July 2012, Andy Green wrote:
From: Andy Green a...@warmcat.com
This introduces a small helper in net/ethernet, which registers a
network notifier on init, and accepts registrations of expected
asynchronously-
probed network device paths (like, usb1/1-1/1-1.1/1-1.1:1.0) and the MAC
that is needed to be assigned to the device when it appears.
This allows platform code to enforce valid, consistent MAC addresses on to
devices that have not been probed at boot-time, but due to being wired on the
board are always present at the same interface. It has been tested with USB
and SDIO probed devices.
To make use of this safely you also need to make sure that any drivers that
may compete for the bus ordinal you are using (eg, mUSB and ehci in Panda
case) are loaded in a deterministic order.
At registration it makes a copy of the incoming data, so the data may be
__initdata or otherwise transitory. Registration can be called multiple times
so registrations from Device Tree and platform may be mixed.
Since it needs to be called quite early in boot and there is no lifecycle for
what it does, it could not be modular and is not a driver.
Via suggestions from Arnd Bergmann and Tony Lindgren.
Signed-off-by: Andy Green andy.gr...@linaro.org
Yes, looks good to me in principle. It needs to get sent to the linux-kernel
and netdev mailing lists for review though. A few small comments.
include/net/mac-la-ap.h | 28
net/Kconfig | 14
net/ethernet/Makefile|2 +
net/ethernet/mac-la-ap.c | 165
++
4 files changed, 209 insertions(+)
create mode 100644 include/net/mac-la-ap.h
create mode 100644 net/ethernet/mac-la-ap.c
diff --git a/include/net/mac-la-ap.h b/include/net/mac-la-ap.h
new file mode 100644
index 000..d5189b5
--- /dev/null
+++ b/include/net/mac-la-ap.h
@@ -0,0 +1,28 @@
+/*
+ * mac-la-ap.h: Locally Administered MAC address for Async probed devices
+ */
I find the name a bit non-obvious, not sure if we can come up with the
perfect one.
How about mac-platform?
+/**
+ * mac_la_ap_register_device_macs - add an array of device path to monitor
+ * and MAC to apply when the network device
+ * at the device path appears
+ * @macs: array of struct mac_la_ap terminated by entry with NULL device_path
+ */
+int mac_la_ap_register_device_macs(const struct mac_la_ap *macs);
+
diff --git a/net/Kconfig b/net/Kconfig
index 245831b..76ba70e 100644
--- a/net/Kconfig
+++ b/net/Kconfig
@@ -335,6 +335,20 @@ source net/caif/Kconfig
source net/ceph/Kconfig
source net/nfc/Kconfig
+config MAC_LA_AP
+ bool Locally Administered MAC for Aysnchronously Probed devices
+ ---help---
+ This helper allows platforms to mandate a locally-administered
+ sythesized MAC address for network devices that are on asynchronously-
+ probed buses like USB or SDIO. This is necessary when the board has
+ these network assets but no arrangements for storing or setting the
+ MAC address of the network asset (nor any official MAC address
+ reserved for the device). In that case, seen in Panda and other
+ boards, the platform can synthesize a constant locally-administered
+ MAC address from SoC UID bits that has a good probability of differing
+ between boards but will be constant on any give board. This helper
+ will take care of watching for the network devices to appear and
+ force the MAC to the synthesized one when they do.
endif # if NET
This one needs to be either a silent option (only selected by the
platforms that want it) or the header file has to provide a
static-inline fallback that does nothing, so we don't get
a build failure on platforms that need it if the option gets
disabled.
I'd prefer making it a silent option because then we don't bloat
the kernel if someone accidentally enables it on a platform that
does not use it.
+static struct mac_la_ap mac_la_ap_list;
The normal way to do this is to have just a list head that the
entries get added to:
static LIST_HEAD(mac_la_ap_list);
That also takes care of the initialization.
+DEFINE_MUTEX(mac_la_ap_mutex);
+bool mac_la_ap_started;
These should all be static.
+static int mac_la_ap_init(void)
+{
+ int ret;
+
+ INIT_LIST_HEAD(mac_la_ap_list.list);
+ mutex_init(mac_la_ap_mutex);
+ ret = register_netdevice_notifier(mac_la_ap_netdev_notifier);
+ if (!ret)
+ mac_la_ap_started = 1;
+ else
+ pr_err(mac_la_ap_init: Notifier registration failed\n);
+
+ return ret;
+}
The mutex is already initialized, and the list head too if you do the
change above.
I think it would be simpler to register the notifier from an
initcall and drop the mac_la_ap_started variable.
+int mac_la_ap_register_device_macs(const struct mac_la_ap *macs)
Re: [PATCH RESEND] ARM: OMAP2+: Fix Wake-up power domain power status
On 06/29/2012 11:27 PM, Shilimkar, Santosh wrote:
+ Paul, Rajendra,
On Sat, Jun 30, 2012 at 2:34 AM, Jon Hunter jon-hun...@ti.com wrote:
Note: Re-sending with updated kernel doc.
The wake-up power domain is an alway-on power domain and so this power domain
does not have a power state status (PM_PWSTST_xxx) register that indicates
the
current state. However, during the registering of the wake-up power domain
the
state of the domain is queried by calling pwrdm_read_pwrst(). This actually
tries to read a register that does not exist and returns a value of 0 that
indicates that the current state is OFF. The OFF state count of the wake-up
power domain is then set to 1 and the current state to OFF. Both of which are
incorrect.
To fix this, if a power domain only supports the ON state, do not attempt to
read the power state status register and simply return ON as the current
power
state.
This is based upon Tony's current linux-omap master branch.
Testing:
- Boot tested on OMAP4460 panda.
- Boot tested on OMAP3430 beagle and validated CORE RET still working (using
Paul's 32k timer patch [1]).
[1] http://marc.info/?l=linux-omapm=13453229888w=2
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/powerdomain.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index eefe179..69b36e1 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -526,7 +526,8 @@ int pwrdm_read_next_pwrst(struct powerdomain *pwrdm)
*
* Return the powerdomain @pwrdm's current power state.Returns
-EINVAL
* if the powerdomain pointer is null or returns the current power state
- * upon success.
+ * upon success. Note that if the power domain only supports the ON state
+ * then just return ON as the current state.
*/
int pwrdm_read_pwrst(struct powerdomain *pwrdm)
{
@@ -535,6 +536,9 @@ int pwrdm_read_pwrst(struct powerdomain *pwrdm)
if (!pwrdm)
return -EINVAL;
+ if (pwrdm-pwrsts == PWRSTS_ON)
+ return PWRDM_POWER_ON;
+
The patch as such is correct but just wondering whether we should
have some flag rather than above check.
I was wondering that too. I opted not to add a flag because there is
only one such power domain that needs it. However, I can add a flag if
it is preferred.
Cheers
Jon
--
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] OMAP4: Clock: Correct OTG clock to use otg_60m_gfclk.
Thanks Benoit for the explanation. It seems you are right.
+ Wenbiao who is the original patch author that may have another point
of view and some additional explanations.
--
Best regards,
Ruslan Bilovol
On Mon, Jul 2, 2012 at 3:43 PM, Benoit Cousson b-cous...@ti.com wrote:
On 06/29/2012 10:35 PM, Paul Walmsley wrote:
+ Benoît who is the maintainer of this file
+ the linux-arm-kernel mailing list, which should be cc'ed on all OMAP
patches
On Fri, 29 Jun 2012, Ruslan Bilovol wrote:
From: Wenbiao Wang ww...@ti.com
OTG clock usb_otg_hs_ick used a incorrect parent l3_div_ck.
Correct it to use the right colck otg_60m_gfclk as its
parent.
Mmm, that does not seems to be correct.
otg_60m_gfclk is an optional clock. The interface clock is the main clock
of that module. That's why this is the parent of the fake MODULEMODE clock
node.
Moreover you are changing as well the utmi_phy_clkout_ck. That's not
mentioned at all in the changelog.
I know that there are some non standard stuff in this clock scheme.
The main reason being the utmi_phy_clkout_ck source is generated from the
usb_phy module. Unfortunately the clock fmwk cannot handle module as a clock
node.
So, as of today, this only way to get the OTG_60M_FCLK clock available is
to ensure that the usb_phy module is enabled before the usb_otg_hs module.
Regards,
Benoit
Signed-off-by: Wenbiao Wang ww...@ti.com
Signed-off-by: Ruslan Bilovol ruslan.bilo...@ti.com
---
arch/arm/mach-omap2/clock44xx_data.c | 15 ---
1 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index b825049..fd43214 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -199,12 +199,6 @@ static struct clk tie_low_clock_ck = {
.ops= clkops_null,
};
-static struct clk utmi_phy_clkout_ck = {
- .name = utmi_phy_clkout_ck,
- .rate = 6000,
- .ops= clkops_null,
-};
-
static struct clk xclk60mhsp1_ck = {
.name = xclk60mhsp1_ck,
.rate = 6000,
@@ -992,6 +986,13 @@ static struct clk dpll_usb_clkdcoldo_ck = {
.recalc = followparent_recalc,
};
+static struct clk utmi_phy_clkout_ck = {
+ .name = utmi_phy_clkout_ck,
+ .ops= clkops_null,
+ .parent = dpll_usb_clkdcoldo_ck,
+ .recalc = followparent_recalc,
+};
+
static const struct clksel dpll_usb_m2_div[] = {
{ .parent = dpll_usb_ck, .rates = div31_1to31_rates },
{ .parent = NULL },
@@ -2685,7 +2686,7 @@ static struct clk usb_otg_hs_ick = {
.enable_reg = OMAP4430_CM_L3INIT_USB_OTG_CLKCTRL,
.enable_bit = OMAP4430_MODULEMODE_HWCTRL,
.clkdm_name = l3_init_clkdm,
- .parent = l3_div_ck,
+ .parent = otg_60m_gfclk,
.recalc = followparent_recalc,
};
Benoît should have a look at this one, I think.
- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2 2/4] net ethernet introduce mac_la_ap helper
On Mon, 2012-07-02 at 16:12 +, Arnd Bergmann wrote: include/net/mac-la-ap.h | 28 net/Kconfig | 14 net/ethernet/Makefile|2 + net/ethernet/mac-la-ap.c | 165 ++ 4 files changed, 209 insertions(+) create mode 100644 include/net/mac-la-ap.h create mode 100644 net/ethernet/mac-la-ap.c diff --git a/include/net/mac-la-ap.h b/include/net/mac-la-ap.h new file mode 100644 index 000..d5189b5 --- /dev/null +++ b/include/net/mac-la-ap.h @@ -0,0 +1,28 @@ +/* + * mac-la-ap.h: Locally Administered MAC address for Async probed devices + */ I find the name a bit non-obvious, not sure if we can come up with the perfect one. How about mac-platform? I really find it unfortunate that 'mac' for ethernet has the same name as the Apple box as well. 'mac' in other contexts can usually differentiate these two, but saying 'mac-platform' just screams of forbidden fruit. mac-probe.h ? -- Steve -- 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 01/10] ARM: PMU: Add runtime PM Support
Hi Will, On 07/02/2012 04:55 AM, Will Deacon wrote: Hi Jon, Did you have any luck getting to the bottom of this? I am still waiting for feedback from design. They were trying to confirm my observations. Unfortunately, it is taking some time. I will ping them again. It would be good to take your PMU suspend/resume patches once we know that they will get used. Yes that would be good. I could drop the 4460 specific changes for now and make 4460 work in the same way as 4430 (using CTI) for the time being and see if we can get these in. However, I recall that was not working for you, but it was working fine for me. On Tue, Jun 12, 2012 at 11:41:27PM +0100, Jon Hunter wrote: On 06/12/2012 04:31 PM, Will Deacon wrote: That's understandable -- one of the CPUs is likely more loaded than the other. However, I'd like to confirm whether or not you see what I see. With the 4430_init hack on a 4460, if I run: # taskset 0x2 perf top then I get no samples. If I do: # taskset 0x1 perf top then I *do* get samples and from *both* CPUs. So it smells more like an issue poking some configuration registers from CPU1 rather than the IRQ path being broken. As I said before, if I don't do the extra init hack then I don't get this problem (but event counters don't tick). In both cases, I see interrupts on both CPUs. However, typically more on the CPU that perf is running on (which is probably to be expected). And I confirm that the only change I made was ... [...] When you boot the kernel what 4460 rev does it show (very early in the kernel boot log)? Mine shows ... [0.00] OMAP4460 ES1.1 Snap: [0.00] OMAP4460 ES1.1 Ok. However, the A9 version has not changed between ES1.0 and ES1.1. Both should be r2p10. Yup, that's what /proc/cpuinfo says. Hmmm ... so that does not explain the observation that you made with 4460. Cheers Jon -- 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] OMAP: USB : Fix the EHCI enumeration and core retention issue
Felipe, Keshava, Kevin Hilman khil...@ti.com writes: Felipe Balbi ba...@ti.com writes: [...] Keshava is reverting a fix for a HW errata. I can't accept it as it will cause regressions. Granted, regression by regression, there's no change, but I simply can't knowingly cause a regression to the driver just to have PM working. We need a real fix for this issue. Sure, as long as there is a fix in this -rc cycle. This driver intoduced changes in v3.5 that break PM for the whole SoC (by preventing CORE retention.) These changes were clearly not tested with PM. If you cannot fix this during the -rc cycle, then you need to revert the driver PM changes that broke PM for the *whole* SoC. What's the status of this regression? This is still broken in v3.5-rc and is preventing CORE retention for the *whole* SoC. Please fix this, either with a proper fix, or a revert for 3.5-rc. 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] OMAP: USB : Fix the EHCI enumeration and core retention issue
On Mon, Jul 2, 2012 at 9:54 AM, Kevin Hilman khil...@ti.com wrote: Felipe, Keshava, Kevin Hilman khil...@ti.com writes: Felipe Balbi ba...@ti.com writes: [...] Keshava is reverting a fix for a HW errata. I can't accept it as it will cause regressions. Granted, regression by regression, there's no change, but I simply can't knowingly cause a regression to the driver just to have PM working. We need a real fix for this issue. Sure, as long as there is a fix in this -rc cycle. This driver intoduced changes in v3.5 that break PM for the whole SoC (by preventing CORE retention.) These changes were clearly not tested with PM. If you cannot fix this during the -rc cycle, then you need to revert the driver PM changes that broke PM for the *whole* SoC. What's the status of this regression? This is still broken in v3.5-rc and is preventing CORE retention for the *whole* SoC. Please fix this, either with a proper fix, or a revert for 3.5-rc. Were you able to merge my patches that at least fix the oops on boot and get EHCI working again on omap-3xxx? -- 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 RESEND] usb: otg: OMAP4: Fix the omap4430_phy_set_clk function
Hi,
On Mon, Jul 2, 2012 at 11:13 AM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Tue, Jun 12, 2012 at 08:36:21PM +0300, Ruslan Bilovol wrote:
If the clocks are enabled and we want to enable them again
omap4430_phy_set_clk disables them.
Fix this - so now if we try to enable already enabled clocks
it works correctly.
Signed-off-by: Ruslan Bilovol ruslan.bilo...@ti.com
---
arch/arm/mach-omap2/omap_phy_internal.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_phy_internal.c
b/arch/arm/mach-omap2/omap_phy_internal.c
index 4c90477..0196683 100644
--- a/arch/arm/mach-omap2/omap_phy_internal.c
+++ b/arch/arm/mach-omap2/omap_phy_internal.c
@@ -97,7 +97,7 @@ int omap4430_phy_set_clk(struct device *dev, int on)
clk_enable(clk48m);
clk_enable(clk32k);
state = 1;
- } else if (state) {
+ } else if (!on state) {
why don't you let clocks be enabled twice then ? That would cut down the
churn.
Currently we have unbalanced call of this function.
I meet first during musb initialization - it tries to disable the phy
that leads to disabling already disabled clocks.
Next goal is to use internal clocks counter and to throw static
variable 'state'.
But since this is not investigated fully and work is not finished -
simple and obvious fix is pushed.
--
Best regards,
Ruslan Bilovol
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 3/3] ARM: OMAP2+: onenand: prepare for gpmc driver migration
On 07/02/2012 01:36 AM, Tony Lindgren wrote: * Jon Hunter jon-hun...@ti.com [120628 09:48]: [2.792510] OneNAND driver initializing [2.797576] omap2-onenand omap2-onenand: initializing on CS2, phys base 0x2000, virtual base c88c, freq 0 MHz [2.808929] OneNAND Manufacturer: Samsung (0xec) [2.808990] Muxed OneNAND 256MB 1.8V 16-bit (0x40) [2.814208] OneNAND version = 0x002c The above change seems to imply that Tony's n900 is dependent on the bootloader settings and not those being set by the kernel. Ideally, we should not need to set the async mode in the onenand before we set the onenand timings in the gpmc (per Afzal's changelog comment). This appears backwards. That should not be the case, I'm more likely to believe in Afzal's explanation. Right I agree with Afzal's explanation now too. The other thing to note is that the 3430sdp has samsung onenand where as the n900 has Numonyx. The gpmc-onenand.c only has one set of settings that it is using for all devices. However, it would appear that at least the async settings are not working for the Numonyx. Therefore, may be we need to get a dump of Tony's n900 settings and make sure the right settings are being used for the appropriate board. Hmm I would assume the n900 onenand settings are the most tested settings we have. And AFAIK have also been tested with L3 frequency scaling. So let's assume they're mostly right. These onenand settings are really killing us. I don't want us to have to spend alot of time re-calculating this stuff but the way it has been written to begin with is not driver friendly. I really wonder if we need to have some sort of callback for the onenand timings from the driver. It is ugly, but the alternative is that someone needs to sit down and re-calculate all the timings again to get them into a driver friendly format. Furthermore, it seems that onenand is no longer available from the likes of samsung and numonyx (micron) so it is hard to justify re-calculating everything again. I am not even sure if we have all the datasheets! Let me know your thoughts. I don't think we should spend much time working on the recalculations. Let's rather use these known working cases as examples. If they don't work, it's likely that adding any new devices won't work either. For the timings, we should allow specifying either cycles or time values in the data struct. And always just use the cycle value directly if specified, and othewise use the time value. We may be able to limit the registers where we need to allow either cycle or time value depending on the device futher. In general, I doubt that we can come up with better calculations. The existing code pretty well already follows the device spec timings. And using cycle values for some registers is the right thing to do according to the connected device specs no matter what the frequency is. In those cases converting from time values to cycles does not make sense. Ok agree, but the problem here is how to provide the timings to the driver. The onenand code is doing a lot of rounding based upon the gpmc clock before it presents the timings (in nano-seconds) to the gpmc function to calculate the final timings and program the gpmc chip-select. So therefore I think that we have the following options ... 1. The simplest is to continue using a global variable for storing the gpmc f-clk handle and have the OneNAND timings calculated prior to probing the gpmc driver. 2. Provide some sort of retime callback that the gpmc driver can call at probe time to calculate the timings. Cheers Jon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 3/3] ARM: OMAP2+: onenand: prepare for gpmc driver migration
On 07/02/2012 04:43 AM, Mohammed, Afzal wrote:
Hi Tony,
On Mon, Jul 02, 2012 at 12:06:51, Tony Lindgren wrote:
* Jon Hunter jon-hun...@ti.com [120628 09:48]:
The above change seems to imply that Tony's n900 is dependent on the
bootloader settings
and not those being set by the kernel. Ideally, we should not need to set
the async mode
in the onenand before we set the onenand timings in the gpmc (per Afzal's
changelog
comment). This appears backwards.
That should not be the case, I'm more likely to believe in Afzal's
explanation.
Not sure whether you are fine with fixing up this patch with added diff
Assuming inferences so far is not wrong, right now this patch with the added
diff
would be perfectly fine.
Problem would happen when we are at a stage to do gpmc reset using hwmod
[seems
miles to go before I sleep {or read gpmc hwmod reset} ;)]. If bootloader left
onenand configured in sync mode, to switch onenand to async mode, first
configuring
gpmc to sync mode would be required for that we need frequency information
from onenand and to get that information from onenand, gpmc has to be
configured
for sync mode and to configure gpmc to sync mode
You are concerned about hwmod performing a reset of the gpmc during
boot? We should be able to use the HWMOD_INIT_NO_RESET flag to prevent
this. Would that work?
Cheers
Jon
--
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: [GIT PULL] gpio/omap: cleanups for v3.5
DebBarma, Tarun Kanti tarun.ka...@ti.com writes:
On Mon, Jun 25, 2012 at 11:48 AM, NeilBrown ne...@suse.de wrote:
On Thu, 21 Jun 2012 12:04:26 +0530 DebBarma, Tarun Kanti
tarun.ka...@ti.com wrote:
On Thu, Jun 21, 2012 at 8:46 AM, NeilBrown ne...@suse.de wrote:
On Thu, 14 Jun 2012 23:24:10 +0530 DebBarma, Tarun Kanti
tarun.ka...@ti.com wrote:
On Thu, Jun 14, 2012 at 5:45 AM, NeilBrown ne...@suse.de wrote:
On Fri, 11 May 2012 17:30:48 -0700 Kevin Hilman khil...@ti.com wrote:
Hi Grant,
Here's the final round of GPIO cleanups for v3.5. This branch is
based
on my for_3.5/fixes/gpio branch you just pulled.
Kevin
Hi.
I'm not sure if it was this series or the following cleanups which
broke
things for me, but I've been trying 3.5-rc2 on my GTA04 and the serial
console (ttyO2) dies as soon as the omap-gpio driver initialises.
After some digging I came up with this patch to gpio-omap.c
@@ -1124,6 +1124,9 @@ static int __devinit omap_gpio_probe(struct
platform_device *pdev)
platform_set_drvdata(pdev, bank);
+ if (bank-get_context_loss_count)
+ bank-context_loss_count =
+
bank-get_context_loss_count(bank-dev);
pm_runtime_enable(bank-dev);
pm_runtime_irq_safe(bank-dev);
pm_runtime_get_sync(bank-dev);
which fixes it.
What was happening was that when omap_gpio_probe calls
pm_runtime_get_sync,
it calls
_od_runtime_resume - pm_generic_runtime_resume -
omap_gpio_runtime_resume
- omap_gpio_restore_context
and then the serial port stops.
I reasoned that the context probably hadn't been set up yet, so
restoring
from it broke things.
Initialising bank-context_loss_count seems sensible and would ensure
that
we didn't try to restore the context until it has actually been lost.
I thought the following code exactly does that. That is
context_lost_cnt_after
would be zero until there is context loss. The bank-context_loss_count
is zero
at the beginning. So, (context_lost_cnt_after !=
bank-context_loss_count) would
be false and hence context restore should NOT happen? Not sure if I am
over looking
anything here
omap_gpio_runtime_resume(...)
{
...
if (bank-get_context_loss_count) {
context_lost_cnt_after =
bank-get_context_loss_count(bank-dev);
if (context_lost_cnt_after != bank-context_loss_count) {
omap_gpio_restore_context(bank);
} else {
spin_unlock_irqrestore(bank-lock, flags);
return 0;
}
}
...
}
Hi,
I've looked more closely at this now.
The problem is that the initial context loss count is *not* zero. Not
always.
The context loss count is the sum of
count = pwrdm-state_counter[PWRDM_POWER_OFF];
count += pwrdm-ret_logic_off_counter;
for (i = 0; i pwrdm-banks; i++)
count += pwrdm-ret_mem_off_counter[i];
(from pwrdm_get_context_loss_count()).
These are initlialised in _pwrdm_register
/* Initialize the powerdomain's state counter */
for (i = 0; i PWRDM_MAX_PWRSTS; i++)
pwrdm-state_counter[i] = 0;
pwrdm-ret_logic_off_counter = 0;
for (i = 0; i pwrdm-banks; i++)
pwrdm-ret_mem_off_counter[i] = 0;
pwrdm_wait_transition(pwrdm);
pwrdm-state = pwrdm_read_pwrst(pwrdm);
pwrdm-state_counter[pwrdm-state] = 1;
What I'm seeing is that for wkup_pwrdm and dpll{3,4,5}_pwrdm,
the state that pwrdm_read_pwrst returns is PWRDM_POWER_OFF.
So that state_counter gets initialised to '1', and so the initial
context_loss_count, which includes that counter, is also '1'.
I think it is the wkup_pwrdm that covers the GPIOs that are causing
problems
for me.
I just put a log in omap_gpio_probe() to see the value of
context_loss_count.
GPIO Bank 0 (WKUP Domain) always shows the count as '1'.
[ 0.169494] omap_gpio omap_gpio.0: context_loss_count=1
[ 0.170227] gpiochip_add: registered GPIOs 0 to 31 on device: gpio
[ 0.170471] OMAP GPIO hardware version 0.1
[ 0.170623] omap_gpio omap_gpio.1: context_loss_count=0
[ 0.170928] gpiochip_add: registered GPIOs 32 to 63 on device: gpio
[ 0.171295] omap_gpio omap_gpio.2: context_loss_count=0
[ 0.171600] gpiochip_add: registered GPIOs 64 to 95 on device: gpio
[ 0.171936] omap_gpio omap_gpio.3: context_loss_count=0
[ 0.172241] gpiochip_add: registered GPIOs 96 to 127 on device: gpio
[ 0.172576] omap_gpio omap_gpio.4: context_loss_count=0
[ 0.172882] gpiochip_add: registered GPIOs 128 to 159 on device: gpio
[ 0.173217] omap_gpio omap_gpio.5: context_loss_count=0
[ 0.173522] gpiochip_add: registered
Re: [PATCH] ARM: OMAP AM35x: clockdomain data: fix resolving dependency problem
On Mon, Jul 02, 2012 at 05:54:57AM +, Kim, Milo wrote:
In am35x board , iva2 clock domain doesn't be used.
So mpu_am35x_clkdm should be used rather than mpu_3xxx_clkdm.
OMAP3430 : mpu_3xxx_clkdm (with iva2 clkdm)
AM35x: mpu_am35x_clkdm (without iva2 clkdm)
For the compatibility with omap3430, this patch has no conflict because
mpu_3xxx_clkdm was already defined in clock domains for omap3430.
So this can be removed from common clock domain.
Below error can be fixed with this patch.
[0.00] AM3517 ES1.1 (l2cache sgx neon )
[0.00] [ cut here ]
[0.00] WARNING: at arch/arm/mach-omap2/clockdomain.c:237
_resolve_clkdm_deps+0x68/0x108()
[0.00] clockdomain: mpu_clkdm: could not find clkdm iva2_clkdm while
resolving dependencies - should never happen
[0.00] Modules linked in:
[0.00] [c001bd3c] (unwind_backtrace+0x0/0xf4) from [c0040c2c]
(warn_slowpath_common+0x4c/0x64)
[0.00] [c0040c2c] (warn_slowpath_common+0x4c/0x64) from
[c0040cd8] (warn_slowpath_fmt+0x30/0x40)
[0.00] [c0040cd8] (warn_slowpath_fmt+0x30/0x40) from [c003256c]
(_resolve_clkdm_deps+0x68/0x108)
[0.00] [c003256c] (_resolve_clkdm_deps+0x68/0x108) from
[c0032640] (clkdm_complete_init+0x34/0x90)
[0.00] [c0032640] (clkdm_complete_init+0x34/0x90) from [c06d7600]
(omap3_init_early+0x20/0x30)
[0.00] [c06d7600] (omap3_init_early+0x20/0x30) from [c06d3230]
(setup_arch+0x834/0x94c)
[0.00] [c06d3230] (setup_arch+0x834/0x94c) from [c06cf6b0]
(start_kernel+0x88/0x2fc)
[0.00] [c06cf6b0] (start_kernel+0x88/0x2fc) from [80008044]
(0x80008044)
Signed-off-by: Milo(Woogyom) Kim milo@ti.com
---
arch/arm/mach-omap2/clockdomains3xxx_data.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/clockdomains3xxx_data.c
b/arch/arm/mach-omap2/clockdomains3xxx_data.c
index d625844..56089c4 100644
--- a/arch/arm/mach-omap2/clockdomains3xxx_data.c
+++ b/arch/arm/mach-omap2/clockdomains3xxx_data.c
@@ -454,7 +454,6 @@ static struct clkdm_autodep clkdm_am35x_autodeps[] = {
static struct clockdomain *clockdomains_common[] __initdata = {
wkup_common_clkdm,
- mpu_3xxx_clkdm,
neon_clkdm,
core_l3_3xxx_clkdm,
core_l4_3xxx_clkdm,
--
1.7.2.5
Hi Milo.
Thanks for the patch but this issue should already be fixed in a patch
that Tony just made a pull request for
(http://www.spinics.net/lists/linux-omap/msg73080.html).
From that email (and branch in the email), look for this patch:
Mark A. Greer (4):
ARM: OMAP AM35x: clockdomain data: Fix clockdomain dependencies
Please take a look as another set of eyes never hurts. :)
Mark
--
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] gpio/omap: cleanups for v3.5
On 07/02/2012 10:37 AM, Kevin Hilman wrote:
DebBarma, Tarun Kanti tarun.ka...@ti.com writes:
On Mon, Jun 25, 2012 at 11:48 AM, NeilBrown ne...@suse.de wrote:
On Thu, 21 Jun 2012 12:04:26 +0530 DebBarma, Tarun Kanti
tarun.ka...@ti.com wrote:
On Thu, Jun 21, 2012 at 8:46 AM, NeilBrown ne...@suse.de wrote:
On Thu, 14 Jun 2012 23:24:10 +0530 DebBarma, Tarun Kanti
tarun.ka...@ti.com wrote:
On Thu, Jun 14, 2012 at 5:45 AM, NeilBrown ne...@suse.de wrote:
On Fri, 11 May 2012 17:30:48 -0700 Kevin Hilman khil...@ti.com wrote:
Hi Grant,
Here's the final round of GPIO cleanups for v3.5. This branch is based
on my for_3.5/fixes/gpio branch you just pulled.
Kevin
Hi.
I'm not sure if it was this series or the following cleanups which broke
things for me, but I've been trying 3.5-rc2 on my GTA04 and the serial
console (ttyO2) dies as soon as the omap-gpio driver initialises.
After some digging I came up with this patch to gpio-omap.c
@@ -1124,6 +1124,9 @@ static int __devinit omap_gpio_probe(struct
platform_device *pdev)
platform_set_drvdata(pdev, bank);
+ if (bank-get_context_loss_count)
+ bank-context_loss_count =
+ bank-get_context_loss_count(bank-dev);
pm_runtime_enable(bank-dev);
pm_runtime_irq_safe(bank-dev);
pm_runtime_get_sync(bank-dev);
which fixes it.
What was happening was that when omap_gpio_probe calls pm_runtime_get_sync,
it calls
_od_runtime_resume - pm_generic_runtime_resume - omap_gpio_runtime_resume
- omap_gpio_restore_context
and then the serial port stops.
I reasoned that the context probably hadn't been set up yet, so restoring
from it broke things.
Initialising bank-context_loss_count seems sensible and would ensure that
we didn't try to restore the context until it has actually been lost.
I thought the following code exactly does that. That is context_lost_cnt_after
would be zero until there is context loss. The bank-context_loss_count is zero
at the beginning. So, (context_lost_cnt_after != bank-context_loss_count) would
be false and hence context restore should NOT happen? Not sure if I am
over looking
anything here
omap_gpio_runtime_resume(...)
{
...
if (bank-get_context_loss_count) {
context_lost_cnt_after =
bank-get_context_loss_count(bank-dev);
if (context_lost_cnt_after != bank-context_loss_count) {
omap_gpio_restore_context(bank);
} else {
spin_unlock_irqrestore(bank-lock, flags);
return 0;
}
}
...
}
Hi,
I've looked more closely at this now.
The problem is that the initial context loss count is *not* zero. Not always.
The context loss count is the sum of
count = pwrdm-state_counter[PWRDM_POWER_OFF];
count += pwrdm-ret_logic_off_counter;
for (i = 0; i pwrdm-banks; i++)
count += pwrdm-ret_mem_off_counter[i];
(from pwrdm_get_context_loss_count()).
These are initlialised in _pwrdm_register
/* Initialize the powerdomain's state counter */
for (i = 0; i PWRDM_MAX_PWRSTS; i++)
pwrdm-state_counter[i] = 0;
pwrdm-ret_logic_off_counter = 0;
for (i = 0; i pwrdm-banks; i++)
pwrdm-ret_mem_off_counter[i] = 0;
pwrdm_wait_transition(pwrdm);
pwrdm-state = pwrdm_read_pwrst(pwrdm);
pwrdm-state_counter[pwrdm-state] = 1;
What I'm seeing is that for wkup_pwrdm and dpll{3,4,5}_pwrdm,
the state that pwrdm_read_pwrst returns is PWRDM_POWER_OFF.
So that state_counter gets initialised to '1', and so the initial
context_loss_count, which includes that counter, is also '1'.
I think it is the wkup_pwrdm that covers the GPIOs that are causing problems
for me.
I just put a log in omap_gpio_probe() to see the value of context_loss_count.
GPIO Bank 0 (WKUP Domain) always shows the count as '1'.
[0.169494] omap_gpio omap_gpio.0: context_loss_count=1
[0.170227] gpiochip_add: registered GPIOs 0 to 31 on device: gpio
[0.170471] OMAP GPIO hardware version 0.1
[0.170623] omap_gpio omap_gpio.1: context_loss_count=0
[0.170928] gpiochip_add: registered GPIOs 32 to 63 on device: gpio
[0.171295] omap_gpio omap_gpio.2: context_loss_count=0
[0.171600] gpiochip_add: registered GPIOs 64 to 95 on device: gpio
[0.171936] omap_gpio omap_gpio.3: context_loss_count=0
[0.172241] gpiochip_add: registered GPIOs 96 to 127 on device: gpio
[0.172576] omap_gpio omap_gpio.4: context_loss_count=0
[0.172882] gpiochip_add: registered GPIOs 128 to 159 on device: gpio
[0.173217] omap_gpio omap_gpio.5: context_loss_count=0
[0.173522] gpiochip_add: registered GPIOs 160 to 191 on device: gpio
That's consistent with what I see, and confirm that initialising the
context_lost_count to zero isn't always correct.
I am just wondering if the
Re: [PATCH RESEND] ARM: OMAP2+: Fix Wake-up power domain power status
Jon Hunter jon-hun...@ti.com writes:
Note: Re-sending with updated kernel doc.
The wake-up power domain is an alway-on power domain and so this power domain
does not have a power state status (PM_PWSTST_xxx) register that indicates the
current state. However, during the registering of the wake-up power domain the
state of the domain is queried by calling pwrdm_read_pwrst(). This actually
tries to read a register that does not exist and returns a value of 0 that
indicates that the current state is OFF. The OFF state count of the wake-up
power domain is then set to 1 and the current state to OFF. Both of which are
incorrect.
To fix this, if a power domain only supports the ON state, do not attempt to
read the power state status register and simply return ON as the current power
state.
This is based upon Tony's current linux-omap master branch.
Testing:
- Boot tested on OMAP4460 panda.
- Boot tested on OMAP3430 beagle and validated CORE RET still working (using
Paul's 32k timer patch [1]).
[1] http://marc.info/?l=linux-omapm=13453229888w=2
Signed-off-by: Jon Hunter jon-hun...@ti.com
Acked-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/powerdomain.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index eefe179..69b36e1 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -526,7 +526,8 @@ int pwrdm_read_next_pwrst(struct powerdomain *pwrdm)
*
* Return the powerdomain @pwrdm's current power state. Returns -EINVAL
* if the powerdomain pointer is null or returns the current power state
- * upon success.
+ * upon success. Note that if the power domain only supports the ON state
+ * then just return ON as the current state.
*/
int pwrdm_read_pwrst(struct powerdomain *pwrdm)
{
@@ -535,6 +536,9 @@ int pwrdm_read_pwrst(struct powerdomain *pwrdm)
if (!pwrdm)
return -EINVAL;
+ if (pwrdm-pwrsts == PWRSTS_ON)
+ return PWRDM_POWER_ON;
+
if (arch_pwrdm arch_pwrdm-pwrdm_read_pwrst)
ret = arch_pwrdm-pwrdm_read_pwrst(pwrdm);
--
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] OMAP: USB : Fix the EHCI enumeration and core retention issue
Russ Dill russ.d...@gmail.com writes: On Mon, Jul 2, 2012 at 9:54 AM, Kevin Hilman khil...@ti.com wrote: Felipe, Keshava, Kevin Hilman khil...@ti.com writes: Felipe Balbi ba...@ti.com writes: [...] Keshava is reverting a fix for a HW errata. I can't accept it as it will cause regressions. Granted, regression by regression, there's no change, but I simply can't knowingly cause a regression to the driver just to have PM working. We need a real fix for this issue. Sure, as long as there is a fix in this -rc cycle. This driver intoduced changes in v3.5 that break PM for the whole SoC (by preventing CORE retention.) These changes were clearly not tested with PM. If you cannot fix this during the -rc cycle, then you need to revert the driver PM changes that broke PM for the *whole* SoC. What's the status of this regression? This is still broken in v3.5-rc and is preventing CORE retention for the *whole* SoC. Please fix this, either with a proper fix, or a revert for 3.5-rc. Were you able to merge my patches that at least fix the oops on boot and get EHCI working again on omap-3xxx? I didn't try your patches specifically, but those are not the problems I'm most worried about. I'm mostly worried about the fact that when EHCI is enabled (and working), it prevents the CORE powerdomain from hitting retention in idle, and thus prevents the whole chip from hitting retention in idle. I'm also worried that the owners of this code are running out of time to fix these several serious regresions for v3.5. 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] OMAP: USB : Fix the EHCI enumeration and core retention issue
Hi Kevin, On Mon, Jul 02, 2012 at 10:55:39AM -0700, Kevin Hilman wrote: I'm also worried that the owners of this code are running out of time to fix these several serious regresions for v3.5. FYI, I only have one omap-usb fix queued for 3.5 in my for-linus branch, see http://git.kernel.org/?p=linux/kernel/git/sameo/mfd-2.6.git;a=shortlog;h=refs/heads/for-linus Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- 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] gpio/omap: fix invalid context restore of gpio bank-0
+ Neil Brown Hi Jon, Jon Hunter jon-hun...@ti.com writes: Currently the gpio _runtime_resume/suspend functions are calling the get_context_loss_count() platform function if the function is populated for a gpio bank. This function is used to determine if the gpio bank logic state needs to be restored due to a power transition. This function will be populated for all banks, but it should only be called for banks that have the loses_context variable set. It is pointless to call this if loses_context is false as we know the context will never be lost and will not need restoring. For all OMAP2+ devices gpio bank-0 is in an always-on power domain and so will never lose context. We found that the get_context_loss_count() was being called for bank-0 during the probe and returning 1 instead of 0 indicating that the context had been lost. This was causing the context restore function to be called at probe time for this bank and because the context had never been saved, was restoring an invalid state. This ultimately resulted in a crash [1]. There are multiple bugs here that need to be addressed ... 1. Why the always-on power domain returns a context loss count of 1? This needs to be fixed in the power domain code. However, the gpio driver should not assume the loss count is 0 to begin with. 2. The omap gpio driver should never be calling get_context_loss_count for a gpio bank in a always-on domain. This is pointless and adds unneccessary overhead. 3. The OMAP gpio driver assumes that the initial power domain context loss count will be 0 at the time the gpio driver is probed. However, it could be possible that this is not the case and an invalid context restore could be performed during the probe. To avoid this otherwise only populated the The 'To avoid this...' sentence here doesn't read well. Looks like you need to: s/otherwise// s/populated/populate/ ? get_context_loss_count() function pointer after the initial call to pm_runtime_get() has occurred. This will ensure that the first pm_runtime_put() initialised the loss count correctly. This patch addresses issues 2 and 3 above. [1] http://marc.info/?l=linux-omapm=134065775323775w=2 Cc: Grant Likely grant.lik...@secretlab.ca Cc: Linus Walleij linus.wall...@stericsson.com Cc: Kevin Hilman khil...@ti.com Cc: Tarun Kanti DebBarma tarun.ka...@ti.com Cc: Franky Lin fran...@broadcom.com Reported-by: Franky Lin fran...@broadcom.com Signed-off-by: Jon Hunter jon-hun...@ti.com Thanks for digging inot this bug Jon. The same bug was brought up by Neil Brown (Cc'd) in a different thread. Neil, it looks to me that this fix will address the problems you were seeing as well. Care to test, and respond with your ack/tested-by if it works for you? Thanks. Kevin --- drivers/gpio/gpio-omap.c |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c index c4ed172..f13fc9c 100644 --- a/drivers/gpio/gpio-omap.c +++ b/drivers/gpio/gpio-omap.c @@ -1081,7 +1081,6 @@ static int __devinit omap_gpio_probe(struct platform_device *pdev) bank-is_mpuio = pdata-is_mpuio; bank-non_wakeup_gpios = pdata-non_wakeup_gpios; bank-loses_context = pdata-loses_context; - bank-get_context_loss_count = pdata-get_context_loss_count; bank-regs = pdata-regs; #ifdef CONFIG_OF_GPIO bank-chip.of_node = of_node_get(node); @@ -1135,6 +1134,9 @@ static int __devinit omap_gpio_probe(struct platform_device *pdev) omap_gpio_chip_init(bank); omap_gpio_show_rev(bank); + if (bank-loses_context) + bank-get_context_loss_count = pdata-get_context_loss_count; + pm_runtime_put(bank-dev); list_add_tail(bank-node, omap_gpio_list); -- 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] gpio/omap: fix invalid context restore of gpio bank-0
On 07/01/2012 03:45 AM, Tony Lindgren wrote: * Shilimkar, Santosh santosh.shilim...@ti.com [120629 21:23]: On Fri, Jun 29, 2012 at 10:52 PM, Jon Hunter jon-hun...@ti.com wrote: Currently the gpio _runtime_resume/suspend functions are calling the get_context_loss_count() platform function if the function is populated for a gpio bank. This function is used to determine if the gpio bank logic state needs to be restored due to a power transition. This function will be populated for all banks, but it should only be called for banks that have the loses_context variable set. It is pointless to call this if loses_context is false as we know the context will never be lost and will not need restoring. For all OMAP2+ devices gpio bank-0 is in an always-on power domain and so will never lose context. We found that the get_context_loss_count() was being called for bank-0 during the probe and returning 1 instead of 0 indicating that the context had been lost. This was causing the context restore function to be called at probe time for this bank and because the context had never been saved, was restoring an invalid state. This ultimately resulted in a crash [1]. There are multiple bugs here that need to be addressed ... 1. Why the always-on power domain returns a context loss count of 1? This needs to be fixed in the power domain code. However, the gpio driver should not assume the loss count is 0 to begin with. Indeed. GPIO driver should not assume the value. 2. The omap gpio driver should never be calling get_context_loss_count for a gpio bank in a always-on domain. This is pointless and adds unneccessary overhead. Make sense too. 3. The OMAP gpio driver assumes that the initial power domain context loss count will be 0 at the time the gpio driver is probed. However, it could be possible that this is not the case and an invalid context restore could be performed during the probe. To avoid this otherwise only populated the get_context_loss_count() function pointer after the initial call to pm_runtime_get() has occurred. This will ensure that the first pm_runtime_put() initialised the loss count correctly. This patch addresses issues 2 and 3 above. Should this one be Cc: stable? If this is a regression, then the regression causing commit should be mentioned. So that raises a good point. Looking at the stable branch (3.4.4) it is missing 3 other fixes too [1][2][3]. So this particular problem would not have been exposed, however, I am wondering if there are other problems lingering there. This is a regression is exposed by [2]. I should add that to the changelog. Cheers Jon [1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b3c64bc30af67ed328a8d919e41160942b870451 [2] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1b1287032df3a69d3ef9a486b444f4ffcca50d01 [3] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=22770de11cb13e7120f973bca6c800de371a6717 -- 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] gpio/omap: fix invalid context restore of gpio bank-0
On 07/02/2012 01:07 PM, Kevin Hilman wrote: + Neil Brown Hi Jon, Jon Hunter jon-hun...@ti.com writes: Currently the gpio _runtime_resume/suspend functions are calling the get_context_loss_count() platform function if the function is populated for a gpio bank. This function is used to determine if the gpio bank logic state needs to be restored due to a power transition. This function will be populated for all banks, but it should only be called for banks that have the loses_context variable set. It is pointless to call this if loses_context is false as we know the context will never be lost and will not need restoring. For all OMAP2+ devices gpio bank-0 is in an always-on power domain and so will never lose context. We found that the get_context_loss_count() was being called for bank-0 during the probe and returning 1 instead of 0 indicating that the context had been lost. This was causing the context restore function to be called at probe time for this bank and because the context had never been saved, was restoring an invalid state. This ultimately resulted in a crash [1]. There are multiple bugs here that need to be addressed ... 1. Why the always-on power domain returns a context loss count of 1? This needs to be fixed in the power domain code. However, the gpio driver should not assume the loss count is 0 to begin with. 2. The omap gpio driver should never be calling get_context_loss_count for a gpio bank in a always-on domain. This is pointless and adds unneccessary overhead. 3. The OMAP gpio driver assumes that the initial power domain context loss count will be 0 at the time the gpio driver is probed. However, it could be possible that this is not the case and an invalid context restore could be performed during the probe. To avoid this otherwise only populated the The 'To avoid this...' sentence here doesn't read well. Looks like you need to: s/otherwise// Yes, I meant to have dropped otherwise here. Thanks! s/populated/populate/ Yes that too! I must have re-worded and screwed it up royally :-( ? get_context_loss_count() function pointer after the initial call to pm_runtime_get() has occurred. This will ensure that the first pm_runtime_put() initialised the loss count correctly. This patch addresses issues 2 and 3 above. [1] http://marc.info/?l=linux-omapm=134065775323775w=2 Cc: Grant Likely grant.lik...@secretlab.ca Cc: Linus Walleij linus.wall...@stericsson.com Cc: Kevin Hilman khil...@ti.com Cc: Tarun Kanti DebBarma tarun.ka...@ti.com Cc: Franky Lin fran...@broadcom.com Reported-by: Franky Lin fran...@broadcom.com Signed-off-by: Jon Hunter jon-hun...@ti.com Thanks for digging inot this bug Jon. The same bug was brought up by Neil Brown (Cc'd) in a different thread. Neil, it looks to me that this fix will address the problems you were seeing as well. Care to test, and respond with your ack/tested-by if it works for you? Thanks. Neil let me know your thoughts and if you are ok, I can clean-up the changelog and re-send. Cheers Jon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] remoteproc: maintain a generic child device for each rproc
On 06/29/12 01:13, Ohad Ben-Cohen wrote: On Wed, May 30, 2012 at 3:16 PM, Ohad Ben-Cohen o...@wizery.com wrote: In this case, I was more wondering between using a class to a device type. I recall seeing a thread where someone said classes were on the way out and shouldn't be used but I can't find it anymore. I also remembered a similar discussion at a plumbers mini-conf about 2-3 years ago too, so I looked at device_type as an alternative to class. The former looks somewhat simpler, but I couldn't find any major advantage for using one over the other, and both seem to be in use by many subsystems. Moving to device_type is so trivial that I gave it a spin (and moved to IDA too while at it): Great! It looks like device_type doesn't have any list iteration support though. Is that requirement gone? If that requirement is still there I would think we need something like a class or bus still. Will you resend this as part of a series? It will be easier to review then. -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] remoteproc: maintain a generic child device for each rproc
On Mon, Jul 2, 2012 at 10:06 PM, Stephen Boyd sb...@codeaurora.org wrote: Great! It looks like device_type doesn't have any list iteration support though. Is that requirement gone? Pretty much, yeah. I'll soon post a separate patch which removes the get_by_name functionality (together with its related klist). Will you resend this as part of a series? It will be easier to review then. Not sure. There's a collection of discrete patches that I've been posting, but they really aren't an organic series: as long as the dependencies are met, each and every one of them is applicable even if applied alone. So I'd prefer (when possible) to treat patches in a discrete fashion so we can start applying them and unblock others who depend on them (e.g. Fernando's runtime PM work depends on this one). But if you prefer me to send this one patch differently to make it easier to review, let me know! Thanks, Ohad. -- 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] remoteproc: remove the get_by_name/put API
Remove rproc_get_by_name() and rproc_put(), and the associated
remoteproc infrastructure that supports it (i.e. klist and friends),
because:
1. No one uses them
2. Using them is highly discouraged, and any potential user
will be deeply scrutinized and encouraged to move.
If a user, that absolutely can't live with the direct boot/shutdown
model, does show up one day, then bringing this functionality back
is going to be trivial.
At this point though, keeping this functionality around is way too
much of a maintenance burden.
Cc: Stephen Boyd sb...@codeaurora.org
Cc: Sjur Brændeland sjur.brandel...@stericsson.com
Cc: Loic Pallardy loic.palla...@stericsson.com
Cc: Ludovic BARRE ludovic.ba...@stericsson.com
Cc: Michal Simek mon...@monstr.eu
Cc: Fernando Guzman Lugo fernando.l...@ti.com
Cc: Suman Anna s-a...@ti.com
Cc: Mark Grosen mgro...@ti.com
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
Documentation/remoteproc.txt | 20 --
drivers/remoteproc/remoteproc_core.c | 126 ---
2 files changed, 146 deletions(-)
diff --git a/Documentation/remoteproc.txt b/Documentation/remoteproc.txt
index ad6ded4..f606854 100644
--- a/Documentation/remoteproc.txt
+++ b/Documentation/remoteproc.txt
@@ -56,26 +56,6 @@ cost.
To decrement the refcount of @rproc, use rproc_put() (but _only_ if
you acquired @rproc using rproc_get_by_name()).
- struct rproc *rproc_get_by_name(const char *name)
-- Find an rproc handle using the remote processor's name, and then
- boot it. If it's already powered on, then just immediately return
- (successfully). Returns the rproc handle on success, and NULL on failure.
- This function increments the remote processor's refcount, so always
- use rproc_put() to decrement it back once rproc isn't needed anymore.
- Note: currently rproc_get_by_name() and rproc_put() are not used anymore
- by the rpmsg bus and its drivers. We need to scrutinize the use cases
- that still need them, and see if we can migrate them to use the non
- name-based boot/shutdown interface.
-
- void rproc_put(struct rproc *rproc)
-- Decrement @rproc's power refcount and shut it down if it reaches zero
- (essentially by just calling rproc_shutdown), and then decrement @rproc's
- validity refcount too.
- After this function returns, @rproc may _not_ be used anymore, and its
- handle should be considered invalid.
- This function should be called _iff_ the @rproc handle was grabbed by
- calling rproc_get_by_name().
-
3. Typical usage
#include linux/remoteproc.h
diff --git a/drivers/remoteproc/remoteproc_core.c
b/drivers/remoteproc/remoteproc_core.c
index 7c560846..283dc1e 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -36,7 +36,6 @@
#include linux/remoteproc.h
#include linux/iommu.h
#include linux/idr.h
-#include linux/klist.h
#include linux/elf.h
#include linux/virtio_ids.h
#include linux/virtio_ring.h
@@ -44,25 +43,6 @@
#include remoteproc_internal.h
-static void klist_rproc_get(struct klist_node *n);
-static void klist_rproc_put(struct klist_node *n);
-
-/*
- * klist of the available remote processors.
- *
- * We need this in order to support name-based lookups (needed by the
- * rproc_get_by_name()).
- *
- * That said, we don't use rproc_get_by_name() at this point.
- * The use cases that do require its existence should be
- * scrutinized, and hopefully migrated to rproc_boot() using device-based
- * binding.
- *
- * If/when this materializes, we could drop the klist (and the by_name
- * API).
- */
-static DEFINE_KLIST(rprocs, klist_rproc_get, klist_rproc_put);
-
typedef int (*rproc_handle_resources_t)(struct rproc *rproc,
struct resource_table *table, int len);
typedef int (*rproc_handle_resource_t)(struct rproc *rproc, void *, int avail);
@@ -1274,105 +1254,6 @@ out:
}
EXPORT_SYMBOL(rproc_shutdown);
-/* will be called when an rproc is added to the rprocs klist */
-static void klist_rproc_get(struct klist_node *n)
-{
- struct rproc *rproc = container_of(n, struct rproc, node);
-
- get_device(rproc-dev);
-}
-
-/* will be called when an rproc is removed from the rprocs klist */
-static void klist_rproc_put(struct klist_node *n)
-{
- struct rproc *rproc = container_of(n, struct rproc, node);
-
- put_device(rproc-dev);
-}
-
-static struct rproc *next_rproc(struct klist_iter *i)
-{
- struct klist_node *n;
-
- n = klist_next(i);
- if (!n)
- return NULL;
-
- return container_of(n, struct rproc, node);
-}
-
-/**
- * rproc_get_by_name() - find a remote processor by name and boot it
- * @name: name of the remote processor
- *
- * Finds an rproc handle using the remote processor's name, and then
- * boot it. If it's already powered on, then just immediately return
- * (successfully).
- *
- * Returns the rproc handle on success, and
Re: 3.5-rc3: vdd_mpu_iva warnings
Joe Woodward j...@terrafix.co.uk writes: I have a GUMSTIX Overo AirSTORM module (AM3703-based). When booting the kernel the following features are listed: OMAP3630 ES1.2 (l2cache neon isp 192mhz_clk ) After booting I get the following (repeating every few seconds): [ 81.122558] voltdm_scale: No voltage scale API registered for vdd_mpu_iva [ 81.130340] platform mpu.0: omap_target: unable to scale voltage up. Do you have CPUfreq enabled? I suspect so. With CPUfreq enabled, this seems to be happening once on boot, even on platforms with an IVA (like my Overo FireSTORM). But I'm very curious how it is happening every few seconds on your platform. Do you have the CPUfreq ondemand governor running with an active load? The boot-time warning seems to be an init ordering problem. The CPUfreq driver (upon registration) seems to try to set the frequency (and voltage), and this is happening before the voltage layer is fully initialized. I'm looking into this one. Why it would continue to happen after boot though is a bit of a mystery. I'm looking into that now. I have SmartReflex enabled, and the same defconfig used to work on 3.4. CONFIG_OMAP_SMARTREFLEX=y CONFIG_OMAP_SMARTREFLEX_CLASS3=y I'm assuming this is because of changes to twl-common.c to add the IVA voltage domain, but on the OMAP I have there is no IVA - hence the warnings? I don't think it's related to IVA. The voltage domain contains both the MPU and the IVA (if present), so that voltage domain will be present on all SoCs in this family. Is there a known fix for this (disabling SmartReflex seems to make no difference)? I don't think it's related to SmartReflex either. 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: 3.5-rc3: vdd_mpu_iva warnings
Joe Woodward j...@terrafix.co.uk writes:
I have a GUMSTIX Overo AirSTORM module (AM3703-based).
When booting the kernel the following features are listed:
OMAP3630 ES1.2 (l2cache neon isp 192mhz_clk )
After booting I get the following (repeating every few seconds):
[ 81.122558] voltdm_scale: No voltage scale API registered for vdd_mpu_iva
[ 81.130340] platform mpu.0: omap_target: unable to scale voltage up.
BTW, after boot, can you run the shell snippet below. This should run
the board through MPU DVFS for all the available OPPs:
Thanks,
Kevin
cd /sys/devices/system/cpu/cpu0/cpufreq
cat scaling_available_frequencies
cat scaling_cur_freq
echo userspace scaling_governor
mpu_reg=regulator.3
for freq in `cat scaling_available_frequencies`; do
echo ${freq} scaling_setspeed
echo -n current freq:
cat scaling_cur_freq
echo -n current voltage:
cat /sys/class/regulator/${mpu_reg}/microvolts
sleep 2
done
--
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 01/10] ARM: PMU: Add runtime PM Support
On Mon, Jul 02, 2012 at 05:50:38PM +0100, Jon Hunter wrote: On 07/02/2012 04:55 AM, Will Deacon wrote: Did you have any luck getting to the bottom of this? I am still waiting for feedback from design. They were trying to confirm my observations. Unfortunately, it is taking some time. I will ping them again. Ok, thanks. If pinging doesn't work, bribery can be quite effective with hardware guys :) It would be good to take your PMU suspend/resume patches once we know that they will get used. Yes that would be good. I could drop the 4460 specific changes for now and make 4460 work in the same way as 4430 (using CTI) for the time being and see if we can get these in. However, I recall that was not working for you, but it was working fine for me. Indeed, that hack didn't help me and I'd rather not commit it if it only partially fixes the problem. A better bet might just be to go with your original approach and see how many bug reports we receive. That might also help us narrow down the problem, but it's your call. In the meantime, I pushed what I think is the latest drop of your series to a new branch on kernel.org: git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git perf/omap4-dev Will -- 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
[FYI/RFC] usb: musb: DMA doesn't work with nop PHYs
[The reason I'm sending this is that there is an issue but I probably
won't be able to spend much time on it for a while. So, I'm sending
it in case a) it helps someone else who bumps into it and b) someone
else picks up and completes the fix.]
Hello.
In testing USB OTG Gadget on the am37x EVM with the mainline kernel
I discovered that DMA doesn't work (but PIO does). When I tested
the same kernel on the BeagleBoard-xM (BBxM), which has essentially
the same SoC, it worked fine. They do have different OTG PHYs, though.
The am37x EVM uses an ISP 1507 and the BBxM uses the PHY on the
TPS65950 (twl4030). The different PHYs means that they use different
drivers in drivers/usb/otg. The am37x EVM uses nop-usb-xceiv.c and
the BBxM uses twl4030-usb.c.
After a little digging, the issue appears to be that the generic musb
code, which uses pm_runtime calls to shut things off when its not busy,
assumes that PHY code will turn things back on when there is activity.
For example, on the BBxM (twl4030-usb.c) there is a PHY interrupt that
is handled by twl4030_usb_irq() which notifies the generic code and
eventually calls the appropriate pm_runtime call to turn things on again.
There isn't interrupt support like that in nop-usb-xceiv.c so the IP
stays off when DMA should be happening.
There are at least a couple options for fixing this (that I can think of):
a) Enhance ulip.c to support interrupt generation from the PHY. IIUC, this
will cause a non-dma interrupt so there would be some hacking in the
generic musb code required to handle this.
b) Add pm_runtime hooks to musbhsdma.c since its the DMA driver being used
and it probably makes sense for it to be pm_runtime-ized anyway.
I went down the path of b) and added pm_runtime calls to the channel_alloc()
and channel_release() DMA driver hooks. The patch is here:
PATCH
diff --git a/drivers/usb/musb/musbhsdma.c b/drivers/usb/musb/musbhsdma.c
index 57a6085..8eb13c7 100644
--- a/drivers/usb/musb/musbhsdma.c
+++ b/drivers/usb/musb/musbhsdma.c
@@ -76,10 +76,17 @@ static struct dma_channel *dma_channel_allocate(struct
dma_controller *c,
{
struct musb_dma_controller *controller = container_of(c,
struct musb_dma_controller, controller);
+ struct musb *musb = controller-private_data;
struct musb_dma_channel *musb_channel = NULL;
struct dma_channel *channel = NULL;
u8 bit;
+ if (!controller-used_channels) {
+ spin_unlock(musb-lock);
+ pm_runtime_get_sync(musb-controller);
+ spin_lock(musb-lock);
+ }
+
for (bit = 0; bit MUSB_HSDMA_CHANNELS; bit++) {
if (!(controller-used_channels (1 bit))) {
controller-used_channels |= (1 bit);
@@ -105,15 +112,25 @@ static struct dma_channel *dma_channel_allocate(struct
dma_controller *c,
static void dma_channel_release(struct dma_channel *channel)
{
struct musb_dma_channel *musb_channel = channel-private_data;
+ struct musb_dma_controller *controller = musb_channel-controller;
+ struct musb *musb = controller-private_data;
+ u8 prev_used_channels;
channel-actual_len = 0;
musb_channel-start_addr = 0;
musb_channel-len = 0;
- musb_channel-controller-used_channels =
- ~(1 musb_channel-idx);
+ prev_used_channels = controller-used_channels;
+ controller-used_channels = ~(1 musb_channel-idx);
channel-status = MUSB_DMA_STATUS_UNKNOWN;
+
+ /* Only _put() when going from 1 channel to 0 channels */
+ if (prev_used_channels !controller-used_channels) {
+ spin_unlock(musb-lock);
+ pm_runtime_put(musb-controller);
+ spin_lock(musb-lock);
+ }
}
static void configure_channel(struct dma_channel *channel,
/PATCH
I also have a simpler version that calls pm_runtime every time those
routines are called. Either way, the gadget code resets the device
and it doesn't work. I don't understand the code well enough to know
why and I don't have time to pursue it right now.
In the meantime, if pm_runtime calls are added to the start() and stop()
hooks of the DMA driver, it will work fine. The problem with putting the
pm_runtime calls there is that it will stay powered on even when DMA isn't
being used. This patch works for me on the am37x EVM:
PATCH
diff --git a/drivers/usb/musb/musbhsdma.c b/drivers/usb/musb/musbhsdma.c
index 57a6085..b69e1e1 100644
--- a/drivers/usb/musb/musbhsdma.c
+++ b/drivers/usb/musb/musbhsdma.c
@@ -39,7 +39,12 @@
static int dma_controller_start(struct dma_controller *c)
{
- /* nothing to do */
+ struct musb_dma_controller *controller = container_of(c,
+ struct musb_dma_controller, controller);
+ struct musb *musb = controller-private_data;
+
+ pm_runtime_get_sync(musb-controller);
+
return 0;
}
@@ -68,6 +73,8 @@ static int
Re: [PATCH] gpio/omap: fix invalid context restore of gpio bank-0
On Mon, 2 Jul 2012 13:26:38 -0500 Jon Hunter jon-hun...@ti.com wrote: On 07/02/2012 01:07 PM, Kevin Hilman wrote: + Neil Brown Hi Jon, Jon Hunter jon-hun...@ti.com writes: Currently the gpio _runtime_resume/suspend functions are calling the get_context_loss_count() platform function if the function is populated for a gpio bank. This function is used to determine if the gpio bank logic state needs to be restored due to a power transition. This function will be populated for all banks, but it should only be called for banks that have the loses_context variable set. It is pointless to call this if loses_context is false as we know the context will never be lost and will not need restoring. For all OMAP2+ devices gpio bank-0 is in an always-on power domain and so will never lose context. We found that the get_context_loss_count() was being called for bank-0 during the probe and returning 1 instead of 0 indicating that the context had been lost. This was causing the context restore function to be called at probe time for this bank and because the context had never been saved, was restoring an invalid state. This ultimately resulted in a crash [1]. There are multiple bugs here that need to be addressed ... 1. Why the always-on power domain returns a context loss count of 1? This needs to be fixed in the power domain code. However, the gpio driver should not assume the loss count is 0 to begin with. 2. The omap gpio driver should never be calling get_context_loss_count for a gpio bank in a always-on domain. This is pointless and adds unneccessary overhead. 3. The OMAP gpio driver assumes that the initial power domain context loss count will be 0 at the time the gpio driver is probed. However, it could be possible that this is not the case and an invalid context restore could be performed during the probe. To avoid this otherwise only populated the The 'To avoid this...' sentence here doesn't read well. Looks like you need to: s/otherwise// Yes, I meant to have dropped otherwise here. Thanks! s/populated/populate/ Yes that too! I must have re-worded and screwed it up royally :-( ? get_context_loss_count() function pointer after the initial call to pm_runtime_get() has occurred. This will ensure that the first pm_runtime_put() initialised the loss count correctly. This patch addresses issues 2 and 3 above. [1] http://marc.info/?l=linux-omapm=134065775323775w=2 Cc: Grant Likely grant.lik...@secretlab.ca Cc: Linus Walleij linus.wall...@stericsson.com Cc: Kevin Hilman khil...@ti.com Cc: Tarun Kanti DebBarma tarun.ka...@ti.com Cc: Franky Lin fran...@broadcom.com Reported-by: Franky Lin fran...@broadcom.com Signed-off-by: Jon Hunter jon-hun...@ti.com Thanks for digging inot this bug Jon. The same bug was brought up by Neil Brown (Cc'd) in a different thread. Neil, it looks to me that this fix will address the problems you were seeing as well. Care to test, and respond with your ack/tested-by if it works for you? Thanks. Neil let me know your thoughts and if you are ok, I can clean-up the changelog and re-send. Yes, works for me and looks sensible. Tested-by: NeilBrown ne...@suse.de Thanks, NeilBrown signature.asc Description: PGP signature
Re: [PATCH] gpio/omap: fix invalid context restore of gpio bank-0
NeilBrown ne...@suse.de writes: On Mon, 2 Jul 2012 13:26:38 -0500 Jon Hunter jon-hun...@ti.com wrote: On 07/02/2012 01:07 PM, Kevin Hilman wrote: + Neil Brown Hi Jon, Jon Hunter jon-hun...@ti.com writes: Currently the gpio _runtime_resume/suspend functions are calling the get_context_loss_count() platform function if the function is populated for a gpio bank. This function is used to determine if the gpio bank logic state needs to be restored due to a power transition. This function will be populated for all banks, but it should only be called for banks that have the loses_context variable set. It is pointless to call this if loses_context is false as we know the context will never be lost and will not need restoring. For all OMAP2+ devices gpio bank-0 is in an always-on power domain and so will never lose context. We found that the get_context_loss_count() was being called for bank-0 during the probe and returning 1 instead of 0 indicating that the context had been lost. This was causing the context restore function to be called at probe time for this bank and because the context had never been saved, was restoring an invalid state. This ultimately resulted in a crash [1]. There are multiple bugs here that need to be addressed ... 1. Why the always-on power domain returns a context loss count of 1? This needs to be fixed in the power domain code. However, the gpio driver should not assume the loss count is 0 to begin with. 2. The omap gpio driver should never be calling get_context_loss_count for a gpio bank in a always-on domain. This is pointless and adds unneccessary overhead. 3. The OMAP gpio driver assumes that the initial power domain context loss count will be 0 at the time the gpio driver is probed. However, it could be possible that this is not the case and an invalid context restore could be performed during the probe. To avoid this otherwise only populated the The 'To avoid this...' sentence here doesn't read well. Looks like you need to: s/otherwise// Yes, I meant to have dropped otherwise here. Thanks! s/populated/populate/ Yes that too! I must have re-worded and screwed it up royally :-( ? get_context_loss_count() function pointer after the initial call to pm_runtime_get() has occurred. This will ensure that the first pm_runtime_put() initialised the loss count correctly. This patch addresses issues 2 and 3 above. [1] http://marc.info/?l=linux-omapm=134065775323775w=2 Cc: Grant Likely grant.lik...@secretlab.ca Cc: Linus Walleij linus.wall...@stericsson.com Cc: Kevin Hilman khil...@ti.com Cc: Tarun Kanti DebBarma tarun.ka...@ti.com Cc: Franky Lin fran...@broadcom.com Reported-by: Franky Lin fran...@broadcom.com Signed-off-by: Jon Hunter jon-hun...@ti.com Thanks for digging inot this bug Jon. The same bug was brought up by Neil Brown (Cc'd) in a different thread. Neil, it looks to me that this fix will address the problems you were seeing as well. Care to test, and respond with your ack/tested-by if it works for you? Thanks. Neil let me know your thoughts and if you are ok, I can clean-up the changelog and re-send. Yes, works for me and looks sensible. Tested-by: NeilBrown ne...@suse.de Great! Thanks for testing. Jon, please make the minor changelog edits, collect the reviewed-by and tested-by tags and repost. I'll then queue this up for Grant. Based on your earlier comments, this only affects v3.5, so no need to push it into stable, correct? 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] OMAP: USB : Fix the EHCI enumeration and core retention issue
Kevin Hilman khil...@ti.com writes: Felipe, Keshava, Kevin Hilman khil...@ti.com writes: Felipe Balbi ba...@ti.com writes: [...] Keshava is reverting a fix for a HW errata. I can't accept it as it will cause regressions. Granted, regression by regression, there's no change, but I simply can't knowingly cause a regression to the driver just to have PM working. We need a real fix for this issue. Sure, as long as there is a fix in this -rc cycle. This driver intoduced changes in v3.5 that break PM for the whole SoC (by preventing CORE retention.) These changes were clearly not tested with PM. If you cannot fix this during the -rc cycle, then you need to revert the driver PM changes that broke PM for the *whole* SoC. What's the status of this regression? This is still broken in v3.5-rc and is preventing CORE retention for the *whole* SoC. Please fix this, either with a proper fix, or a revert for 3.5-rc. BTW, a related issue with this driver (but not sure it's a regression) is that USB ethernet does not seem to survive a suspend/resume. If I'm using a NFS rootfs, after suspend/resume, the NFS servers stops responding, and I get these errors: nfs: server X.X.X.X not responding, still trying The result is that I have to use an initramfs on BB-xM in order to do suspend/resume testing. 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] gpio/omap: fix invalid context restore of gpio bank-0
On 07/02/2012 07:05 PM, Kevin Hilman wrote: NeilBrown ne...@suse.de writes: On Mon, 2 Jul 2012 13:26:38 -0500 Jon Hunter jon-hun...@ti.com wrote: On 07/02/2012 01:07 PM, Kevin Hilman wrote: + Neil Brown Hi Jon, Jon Hunter jon-hun...@ti.com writes: Currently the gpio _runtime_resume/suspend functions are calling the get_context_loss_count() platform function if the function is populated for a gpio bank. This function is used to determine if the gpio bank logic state needs to be restored due to a power transition. This function will be populated for all banks, but it should only be called for banks that have the loses_context variable set. It is pointless to call this if loses_context is false as we know the context will never be lost and will not need restoring. For all OMAP2+ devices gpio bank-0 is in an always-on power domain and so will never lose context. We found that the get_context_loss_count() was being called for bank-0 during the probe and returning 1 instead of 0 indicating that the context had been lost. This was causing the context restore function to be called at probe time for this bank and because the context had never been saved, was restoring an invalid state. This ultimately resulted in a crash [1]. There are multiple bugs here that need to be addressed ... 1. Why the always-on power domain returns a context loss count of 1? This needs to be fixed in the power domain code. However, the gpio driver should not assume the loss count is 0 to begin with. 2. The omap gpio driver should never be calling get_context_loss_count for a gpio bank in a always-on domain. This is pointless and adds unneccessary overhead. 3. The OMAP gpio driver assumes that the initial power domain context loss count will be 0 at the time the gpio driver is probed. However, it could be possible that this is not the case and an invalid context restore could be performed during the probe. To avoid this otherwise only populated the The 'To avoid this...' sentence here doesn't read well. Looks like you need to: s/otherwise// Yes, I meant to have dropped otherwise here. Thanks! s/populated/populate/ Yes that too! I must have re-worded and screwed it up royally :-( ? get_context_loss_count() function pointer after the initial call to pm_runtime_get() has occurred. This will ensure that the first pm_runtime_put() initialised the loss count correctly. This patch addresses issues 2 and 3 above. [1] http://marc.info/?l=linux-omapm=134065775323775w=2 Cc: Grant Likely grant.lik...@secretlab.ca Cc: Linus Walleij linus.wall...@stericsson.com Cc: Kevin Hilman khil...@ti.com Cc: Tarun Kanti DebBarma tarun.ka...@ti.com Cc: Franky Lin fran...@broadcom.com Reported-by: Franky Lin fran...@broadcom.com Signed-off-by: Jon Hunter jon-hun...@ti.com Thanks for digging inot this bug Jon. The same bug was brought up by Neil Brown (Cc'd) in a different thread. Neil, it looks to me that this fix will address the problems you were seeing as well. Care to test, and respond with your ack/tested-by if it works for you? Thanks. Neil let me know your thoughts and if you are ok, I can clean-up the changelog and re-send. Yes, works for me and looks sensible. Tested-by: NeilBrown ne...@suse.de Great! Thanks for testing. Jon, please make the minor changelog edits, collect the reviewed-by and tested-by tags and repost. I'll then queue this up for Grant. Ok, will do that tomorrow. Based on your earlier comments, this only affects v3.5, so no need to push it into stable, correct? As far as I can tell. However, not sure if any of the other fixes should be back ported. Cheers Jon -- 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 0/4] Add ability to set defaultless network device MAC addresses to deterministic computed locally administered values
The following series adds some code to generate legal, locally administered MAC addresses from OMAP4 CPU Die ID fuse data, and then adds a helper at net/ethernet taking care of accepting device path / MAC mapping registrations and running a notifier to enforce the requested MAC when the matching network device turns up. On PandaBoard / ES, two devices have no board-level MAC either assigned by the manufacturer or stored on the board, the last patch in the series adds these device paths and gets them set when the network device is registered. Lastly for convenient testing, there's a little patch on omap2plus_defconfig that will get Ethernet and WLAN up on Pandaboard. The patches are against today's linux-omap. Thanks to Tony Lindgren and Arnd Bergmann for comments leading to the helper in net/ethernet. --- Andy Green (4): OMAP: add cpu id register to MAC address helper NET ethernet introduce mac_platform helper OMAP4 PANDA register ethernet and wlan for automatic mac allocation config test config extending omap2plus with wl12xx etc arch/arm/configs/omap2plus_defconfig | 35 +++ arch/arm/mach-omap2/Kconfig|1 arch/arm/mach-omap2/board-omap4panda.c | 30 ++ arch/arm/mach-omap2/id.c | 39 arch/arm/mach-omap2/include/mach/id.h |1 include/net/mac-platform.h | 39 net/Kconfig|5 + net/ethernet/Makefile |3 + net/ethernet/mac-platform.c| 151 9 files changed, 282 insertions(+), 22 deletions(-) create mode 100644 include/net/mac-platform.h create mode 100644 net/ethernet/mac-platform.c -- 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 1/4] OMAP: add cpu id register to MAC address helper
From: Andy Green a...@warmcat.com
Introduce a generic helper function that can generate a valid MAC
address using data from the OMAP unique CPU ID register.
For comparison purposes this produces a MAC address of
2e:20:3c:ea:46:01
for the ethernet device on my PandaBoard ES.
The MAC address space has space set aside for these kind of locally
administered MAC addresses, analogous to IPv4 10.x.x.x range, and this
patch marks the generated MAC addresses as such.
The patch leaves two bits allowing elaborating 4 different MACs from the
generated data.
Signed-off-by: Andy Green andy.gr...@linaro.org
Acked-by: Arnd Bergmann a...@arndb.de
Signed-off-by: Nicolas Pitre nicolas.pi...@linaro.org
Tested-by: Steven Rostedt rost...@goodmis.org
---
arch/arm/mach-omap2/id.c | 39 +
arch/arm/mach-omap2/include/mach/id.h |1 +
2 files changed, 40 insertions(+)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 00486a8..faff686 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -530,3 +530,42 @@ void __init omap2_set_globals_tap(struct omap_globals
*omap2_globals)
else
tap_prod_id = 0x0208;
}
+
+/*
+ * this uses the unique per-cpu info from the cpu fuses set at factory to
+ * generate a 6-byte MAC address. Two bits in the generated code are used
+ * to elaborate the generated address into four, so it can be used on multiple
+ * network interfaces.
+ */
+
+void omap_die_id_to_ethernet_mac(u8 *mac, int subtype)
+{
+ struct omap_die_id odi;
+ u32 tap = read_tap_reg(OMAP_TAP_IDCODE);
+
+ omap_get_die_id(odi);
+
+ mac[0] = odi.id_2;
+ mac[1] = odi.id_2 8;
+ mac[2] = odi.id_1;
+ mac[3] = odi.id_1 8;
+ mac[4] = odi.id_1 16;
+ mac[5] = odi.id_1 24;
+
+ /* XOR other chip-specific data with ID */
+
+ tap ^= odi.id_3;
+
+ mac[0] ^= tap;
+ mac[1] ^= tap 8;
+ mac[2] ^= tap 16;
+ mac[3] ^= tap 24;
+
+ /* allow four MACs from this same basic data */
+
+ mac[1] = (mac[1] ~0xc0) | ((subtype 3) 6);
+
+ /* mark it as not multicast, and outside official 80211 MAC namespace */
+
+ mac[0] = (mac[0] ~1) | 2;
+}
diff --git a/arch/arm/mach-omap2/include/mach/id.h
b/arch/arm/mach-omap2/include/mach/id.h
index 02ed3aa..d6c8d63 100644
--- a/arch/arm/mach-omap2/include/mach/id.h
+++ b/arch/arm/mach-omap2/include/mach/id.h
@@ -18,5 +18,6 @@ struct omap_die_id {
};
void omap_get_die_id(struct omap_die_id *odi);
+void omap_die_id_to_ethernet_mac(u8 *mac, int subtype);
#endif
--
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 2/4] NET ethernet introduce mac_platform helper
From: Andy Green a...@warmcat.com
This introduces a small helper in net/ethernet, which registers a network
notifier at core_initcall time, and accepts registrations mapping expected
asynchronously-probed network device paths (like, usb1/1-1/1-1.1/1-1.1:1.0)
and the MAC that is needed to be assigned to the device when it appears.
This allows platform code to enforce valid, consistent MAC addresses on to
devices that have not been probed at boot-time, but due to being wired on the
board are always present at the same interface. It has been tested with USB
and SDIO probed devices.
Other parts of this series provide an OMAP API that computes a valid
locally administered MAC address from CPU ID bits that are unique for each
physical SoC, and register those against devices wired to the board.
This solves a longstanding problem in at least Panda case that there are no
reserved MACs for either onboard Ethernet nor onboard WLAN module, and without
this patch a randomized MAC is assigned to Ethernet and 00:00:00:00:00:00 or
0xdeadbeef is assigned as the WLAN MAC address. The series provides sane,
constant locally-administered MAC addresses that have a high probability of
differing between boards.
To make use of this safely you also need to make sure that any drivers that
may compete for the bus ordinal you are using (eg, mUSB and ehci in Panda
case) are loaded in a deterministic order.
At registration it makes a copy of the incoming data, so the data may be
__initdata or otherwise transitory. Registration can be called multiple times
so registrations from Device Tree and platform may be mixed.
Since it needs to be called quite early in boot and there is no lifecycle for
what it does, it could not be modular and is not a driver.
Via suggestions from Arnd Bergmann and Tony Lindgren (and Alan Cox for the
network notifier concept).
Cc: net...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Andy Green andy.gr...@linaro.org
---
include/net/mac-platform.h | 39 +++
net/Kconfig |5 +
net/ethernet/Makefile |3 +
net/ethernet/mac-platform.c | 151 +++
4 files changed, 197 insertions(+), 1 deletion(-)
create mode 100644 include/net/mac-platform.h
create mode 100644 net/ethernet/mac-platform.c
diff --git a/include/net/mac-platform.h b/include/net/mac-platform.h
new file mode 100644
index 000..3a59098
--- /dev/null
+++ b/include/net/mac-platform.h
@@ -0,0 +1,39 @@
+/*
+ * mac-platform.h: Enforces platform-defined MAC for Async probed devices
+ */
+
+#ifndef __NET_MAC_PLATFORM_H__
+#define __NET_MAC_PLATFORM_H__
+
+#include linux/if_ether.h
+
+/**
+ * struct mac_platform - associates asynchronously probed device path with
+ * MAC address to be assigned to the device when it
+ * is created
+ *
+ * @device_path: device path name of network device
+ * @mac: MAC address to assign to network device matching device path
+ * @list: can be left uninitialized when passing from platform
+ */
+
+struct mac_platform {
+ char *device_path;
+ u8 mac[ETH_ALEN];
+ struct list_head list; /* unused in platform data usage */
+};
+
+#ifdef CONFIG_NET
+/**
+ * mac_platform_register_device_macs - add an array of device path to monitor
+ * and MAC to apply when the network device
+ * at the device path appears
+ * @macs: array of struct mac_platform terminated by entry with
+ * NULL device_path
+ */
+int mac_platform_register_device_macs(const struct mac_platform *macs);
+#else
+static inline int mac_platform_register_device_macs(macs) { return 0; }
+#endif /* !CONFIG_NET */
+
+#endif /* __NET_MAC_PLATFORM_H__ */
diff --git a/net/Kconfig b/net/Kconfig
index 245831b..487c9e6 100644
--- a/net/Kconfig
+++ b/net/Kconfig
@@ -335,9 +335,12 @@ source net/caif/Kconfig
source net/ceph/Kconfig
source net/nfc/Kconfig
-
endif # if NET
+# used by board / dt platform to enforce MACs for Async-probed devices
+config MAC_PLATFORM
+ bool
+
# Used by archs to tell that they support BPF_JIT
config HAVE_BPF_JIT
bool
diff --git a/net/ethernet/Makefile b/net/ethernet/Makefile
index 7cef1d8..475db2b 100644
--- a/net/ethernet/Makefile
+++ b/net/ethernet/Makefile
@@ -5,3 +5,6 @@
obj-y += eth.o
obj-$(subst m,y,$(CONFIG_IPX)) += pe2.o
obj-$(subst m,y,$(CONFIG_ATALK)) += pe2.o
+ifneq ($(CONFIG_NET),)
+obj-$(CONFIG_MAC_PLATFORM) += mac-platform.o
+endif
diff --git a/net/ethernet/mac-platform.c b/net/ethernet/mac-platform.c
new file mode 100644
index 000..88e50ce
--- /dev/null
+++ b/net/ethernet/mac-platform.c
@@ -0,0 +1,151 @@
+/*
+ * Helper to allow platform code to enforce association of a locally-
+ * administered MAC address automatically on asynchronously probed devices,
+ * such as SDIO and USB based devices.
+ *
+ * Because the device
[PATCH 3 3/4] OMAP4 PANDA register ethernet and wlan for automatic mac allocation
From: Andy Green a...@warmcat.com
This provides the board-specific device paths needed to get
the panda boardfile working with the mac-platform api.
On Pandaboard / ES, neither the onboard Ethernet or onboard WLAN
module have onboard arrangements for MAC storage, without this
series yielding randomized MAC per-boot and consequent DHCP problems,
or in the case of wlan0 a MAC set by a firmware file in the rootfs
which unless customized yields a MAC of 00:00:00:00:00:00. No
official MAC is reserved for either network device even if you do
take the approach to customize the firmware file.
This gets sane, consistent MAC addresses on both devices which
should stand a good probability of differing between PandaBoards.
Signed-off-by: Andy Green andy.gr...@linaro.org
---
arch/arm/mach-omap2/Kconfig|1 +
arch/arm/mach-omap2/board-omap4panda.c | 30 ++
2 files changed, 31 insertions(+)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 5e95aa6..e17eed1 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -348,6 +348,7 @@ config MACH_OMAP4_PANDA
select OMAP_PACKAGE_CBL
select OMAP_PACKAGE_CBS
select REGULATOR_FIXED_VOLTAGE if REGULATOR
+ select MAC_PLATFORM
config MACH_PCM049
bool OMAP4 based phyCORE OMAP4
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index 982fb26..b028141 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -32,7 +32,10 @@
#include linux/wl12xx.h
#include linux/platform_data/omap-abe-twl6040.h
+#include net/mac-platform.h
+
#include mach/hardware.h
+#include mach/id.h
#include asm/hardware/gic.h
#include asm/mach-types.h
#include asm/mach/arch.h
@@ -486,16 +489,43 @@ static void omap4_panda_init_rev(void)
}
}
+/*
+ * These device paths represent onboard network devices which have
+ * no MAC address set at boot, and need synthetic ones assigning
+ */
+static __initdata struct mac_platform panda_mac_platform[] = {
+
+ { /* smsc USB - Ethernet bridge */
+ .device_path = usb1/1-1/1-1.1/1-1.1:1.0,
+ },
+ { /* wlan0 module */
+ .device_path = wl12xx,
+ },
+ { /* terminator */
+ }
+};
+
static void __init omap4_panda_init(void)
{
int package = OMAP_PACKAGE_CBS;
int ret;
+ int n;
if (omap_rev() == OMAP4430_REV_ES1_0)
package = OMAP_PACKAGE_CBL;
omap4_mux_init(board_mux, NULL, package);
omap_panda_wlan_data.irq = gpio_to_irq(GPIO_WIFI_IRQ);
+
+ /*
+* provide MAC addresses computed from device ID for network
+* devices that have no MAC address otherwise on Panda
+*/
+ for (n = 0; n ARRAY_SIZE(panda_mac_platform) - 1; n++)
+ omap_die_id_to_ethernet_mac(panda_mac_platform[n].mac, n);
+ if (mac_platform_register_device_macs(panda_mac_platform))
+ pr_err(Unable to register mac_platform devices\n);
+
ret = wl12xx_set_platform_data(omap_panda_wlan_data);
if (ret)
pr_err(error setting wl12xx data: %d\n, ret);
--
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 4/4] config test config extending omap2plus with wl12xx etc
From: Andy Green a...@warmcat.com This is just provided for testing convenience, it has enough config options to get Ethernet and WL12xx driver on PandaBoard / ES up You should be able to reproduce something like this, with different MAC addresses. # ifconfig -a eth0 Link encap:Ethernet HWaddr 2e:20:3c:ea:46:01 inet addr:10.42.0.98 Bcast:10.42.0.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:13 errors:0 dropped:0 overruns:0 frame:0 TX packets:31 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1647 (1.6 KB) TX bytes:5534 (5.5 KB) loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:2 errors:0 dropped:0 overruns:0 frame:0 TX packets:2 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:100 (100.0 B) TX bytes:100 (100.0 B) wlan0 Link encap:Ethernet HWaddr 2e:60:3c:ea:46:01 BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) Signed-off-by: Andy Green andy.gr...@linaro.org --- arch/arm/configs/omap2plus_defconfig | 35 ++ 1 file changed, 14 insertions(+), 21 deletions(-) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index f3087cb..7dcd384 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -2,13 +2,13 @@ CONFIG_EXPERIMENTAL=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y +CONFIG_NO_HZ=y +CONFIG_HIGH_RES_TIMERS=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=16 CONFIG_BLK_DEV_INITRD=y CONFIG_EXPERT=y -# CONFIG_SYSCTL_SYSCALL is not set -CONFIG_KALLSYMS_EXTRA_PASS=y CONFIG_SLAB=y CONFIG_PROFILING=y CONFIG_OPROFILE=y @@ -20,13 +20,12 @@ CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y # CONFIG_BLK_DEV_BSG is not set +CONFIG_PARTITION_ADVANCED=y CONFIG_ARCH_OMAP=y CONFIG_OMAP_RESET_CLOCKS=y CONFIG_OMAP_MUX_DEBUG=y CONFIG_ARM_THUMBEE=y CONFIG_ARM_ERRATA_411920=y -CONFIG_NO_HZ=y -CONFIG_HIGH_RES_TIMERS=y CONFIG_SMP=y CONFIG_NR_CPUS=2 CONFIG_LEDS=y @@ -60,6 +59,7 @@ CONFIG_BT_HCIUART_LL=y CONFIG_BT_HCIBCM203X=m CONFIG_BT_HCIBPA10X=m CONFIG_CFG80211=m +CONFIG_LIB80211=m CONFIG_MAC80211=m CONFIG_MAC80211_RC_PID=y CONFIG_MAC80211_RC_DEFAULT_PID=y @@ -87,22 +87,20 @@ CONFIG_SCSI_MULTI_LUN=y CONFIG_SCSI_SCAN_ASYNC=y CONFIG_MD=y CONFIG_NETDEVICES=y -CONFIG_SMSC_PHY=y -CONFIG_NET_ETHERNET=y -CONFIG_SMC91X=y -CONFIG_SMSC911X=y CONFIG_KS8851=y CONFIG_KS8851_MLL=y -CONFIG_LIBERTAS=m -CONFIG_LIBERTAS_USB=m -CONFIG_LIBERTAS_SDIO=m -CONFIG_LIBERTAS_DEBUG=y +CONFIG_SMC91X=y +CONFIG_SMSC911X=y +CONFIG_SMSC_PHY=y CONFIG_USB_USBNET=y CONFIG_USB_NET_SMSC95XX=y CONFIG_USB_ALI_M5632=y CONFIG_USB_AN2720=y CONFIG_USB_EPSON2888=y CONFIG_USB_KC2190=y +CONFIG_WL_TI=y +CONFIG_WL12XX=m +CONFIG_WLCORE_SDIO=m CONFIG_INPUT_JOYDEV=y CONFIG_INPUT_EVDEV=y CONFIG_KEYBOARD_GPIO=y @@ -131,14 +129,14 @@ CONFIG_POWER_SUPPLY=y CONFIG_WATCHDOG=y CONFIG_OMAP_WATCHDOG=y CONFIG_TWL4030_WATCHDOG=y -CONFIG_REGULATOR_TWL4030=y +CONFIG_MFD_WL1273_CORE=y CONFIG_REGULATOR_TPS65023=y CONFIG_REGULATOR_TPS6507X=y +CONFIG_REGULATOR_TWL4030=y CONFIG_FB=y CONFIG_FIRMWARE_EDID=y CONFIG_FB_MODE_HELPERS=y CONFIG_FB_TILEBLITTING=y -CONFIG_FB_OMAP_LCD_VGA=y CONFIG_OMAP2_DSS=m CONFIG_OMAP2_DSS_RFBI=y CONFIG_OMAP2_DSS_SDI=y @@ -153,7 +151,6 @@ CONFIG_PANEL_ACX565AKM=m CONFIG_BACKLIGHT_LCD_SUPPORT=y CONFIG_LCD_CLASS_DEVICE=y CONFIG_LCD_PLATFORM=y -CONFIG_DISPLAY_SUPPORT=y CONFIG_FRAMEBUFFER_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y CONFIG_FONTS=y @@ -173,7 +170,6 @@ CONFIG_SND_OMAP_SOC_OMAP3_PANDORA=m CONFIG_USB=y CONFIG_USB_DEBUG=y CONFIG_USB_ANNOUNCE_NEW_DEVICES=y -CONFIG_USB_DEVICEFS=y CONFIG_USB_SUSPEND=y CONFIG_USB_MON=y CONFIG_USB_EHCI_HCD=y @@ -212,23 +208,20 @@ CONFIG_JFFS2_RUBIN=y CONFIG_UBIFS_FS=y CONFIG_CRAMFS=y CONFIG_NFS_FS=y -CONFIG_NFS_V3=y CONFIG_NFS_V3_ACL=y CONFIG_NFS_V4=y CONFIG_ROOT_NFS=y -CONFIG_PARTITION_ADVANCED=y CONFIG_NLS_CODEPAGE_437=y CONFIG_NLS_ISO8859_1=y CONFIG_PRINTK_TIME=y CONFIG_MAGIC_SYSRQ=y -CONFIG_DEBUG_KERNEL=y CONFIG_SCHEDSTATS=y CONFIG_TIMER_STATS=y CONFIG_PROVE_LOCKING=y -CONFIG_DEBUG_SPINLOCK_SLEEP=y # CONFIG_DEBUG_BUGVERBOSE is not set CONFIG_DEBUG_INFO=y -# CONFIG_RCU_CPU_STALL_DETECTOR is not set +CONFIG_DEBUG_LL=y +CONFIG_EARLY_PRINTK=y CONFIG_SECURITY=y CONFIG_CRYPTO_MICHAEL_MIC=y # CONFIG_CRYPTO_ANSI_CPRNG is not set -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More
RE: [PATCH v5 3/3] ARM: OMAP2+: onenand: prepare for gpmc driver migration
Hi Jon,
On Mon, Jul 02, 2012 at 22:59:03, Hunter, Jon wrote:
On 07/02/2012 04:43 AM, Mohammed, Afzal wrote:
Not sure whether you are fine with fixing up this patch with added diff
Assuming inferences so far is not wrong, right now this patch with the
added diff
would be perfectly fine.
Problem would happen when we are at a stage to do gpmc reset using hwmod
[seems
miles to go before I sleep {or read gpmc hwmod reset} ;)]. If bootloader
left
onenand configured in sync mode, to switch onenand to async mode, first
configuring
gpmc to sync mode would be required for that we need frequency information
from onenand and to get that information from onenand, gpmc has to be
configured
for sync mode and to configure gpmc to sync mode
You are concerned about hwmod performing a reset of the gpmc during
boot? We should be able to use the HWMOD_INIT_NO_RESET flag to prevent
this. Would that work?
Yes that will work in the short term, the reason I am trying to avoid no
reset flag in the long term is to prevent this board support being broken,
please refer Paul's requirement [1] in accepting gpmc hwmod patch
Regards
Afzal
[1] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69041.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2 2/4] net ethernet introduce mac_la_ap helper
On 07/03/12 00:12, the mail apparently from Arnd Bergmann included:
On Monday 02 July 2012, Andy Green wrote:
From: Andy Green a...@warmcat.com
This introduces a small helper in net/ethernet, which registers a
network notifier on init, and accepts registrations of expected asynchronously-
Yes, looks good to me in principle. It needs to get sent to the linux-kernel
and netdev mailing lists for review though. A few small comments.
I wanted to hear that it had actually converged with what was being
talked about first. I just sent out a v3 with the relevant patch also
cc-d to those lists but stg mail didn't seem to send it to them. I'll
wait for any further comments here and resend the whole thing including
those lists.
I find the name a bit non-obvious, not sure if we can come up with the
perfect one.
How about mac-platform?
Done.
endif # if NET
This one needs to be either a silent option (only selected by the
platforms that want it) or the header file has to provide a
static-inline fallback that does nothing, so we don't get
a build failure on platforms that need it if the option gets
disabled.
I'd prefer making it a silent option because then we don't bloat
the kernel if someone accidentally enables it on a platform that
does not use it.
Done. It's already added as a select on the Panda board config.
I also moved it out of the if NET clause and took care about the case
that CONFIG_NET is off but we still have mac-platform references.
+static struct mac_la_ap mac_la_ap_list;
The normal way to do this is to have just a list head that the
entries get added to:
static LIST_HEAD(mac_la_ap_list);
That also takes care of the initialization.
Thanks for normalizing it, done.
+DEFINE_MUTEX(mac_la_ap_mutex);
+bool mac_la_ap_started;
These should all be static.
Right, done.
I think it would be simpler to register the notifier from an
initcall and drop the mac_la_ap_started variable.
That was my first approach, to structure it as a real driver. I had
tried a few likely-looking initcall levels but the init of the helper
was coming after the init of the network code.
I found this time that core_initcall works, so I used that, dropped the
flag. But isn't it a bit tricky with these to know if the prerequisite
you're trying to ensure is already initialized might not actually be at
the same initcall level and you're working by accident?
+int mac_la_ap_register_device_macs(const struct mac_la_ap *macs)
+{
+}
+EXPORT_SYMBOL_GPL(mac_la_ap_register_device_macs);
I'm not sure if there is any point in exporting this function, my feeling
is that it would only ever be called from built-in code. If we can call it
from a module, we should probably also allow this file to be a loadable
module as well.
Being a modular API for platform code to call doesn't make sense, I got
rid of the export.
-Andy
--
Andy Green | TI Landing Team Leader
Linaro.org │ Open source software for ARM SoCs | Follow Linaro
http://facebook.com/pages/Linaro/155974581091106 -
http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 3/3] ARM: OMAP2+: onenand: prepare for gpmc driver migration
* Jon Hunter jon-hun...@ti.com [120628 12:05]: Tony, have you tried using any of the mtd kernel tests to verify OneNAND read/write is working on your n900? For example ... # insmod mtd_pagetest.ko dev=mtd-part-num _NOTE_ that above test erases the OneNAND! ;-) Ehh not thanks. 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 v3] ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset fix issues.
On Fri, Jun 29, 2012 at 9:03 PM, Alan Stern st...@rowland.harvard.edu wrote: On Wed, 27 Jun 2012, Russ Dill wrote: From: Russ Dill russ.d...@gmail.com 'ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue' (1fcb57d0) fixes an issue where the ULPI PHYs were not held in reset while initializing the EHCI controller. However, it also changes behavior in omap-usb-host.c omap_usbhs_init by releasing reset while the configuration in that function was done. This change caused a regression on BB-xM where USB would not function if 'usb start' had been run from u-boot before booting. A change was made to release reset a little bit earlier which fixed the issue on BB-xM and did not cause any regressions on 3430 sdp, the board for which the fix was originally made. This new fix, 'USB: EHCI: OMAP: Finish ehci omap phy reset cycle before adding hcd.', (3aa2ae74) caused a regression on OMAP5. The original fix to hold the EHCI controller in reset during initialization was correct, however it appears that changing omap_usbhs_init to not hold the PHYs in reset during it's configuration was incorrect. This patch first reverts both fixes, and then changes ehci_hcd_omap_probe in ehci-omap.c to hold the PHYs in reset as the original patch had done. It also is sure to incorporate the _cansleep change that has been made in the meantime. Tested on Beagleboard xM. Looking at the result of this patch, there seem to be a few mistakes remaining in the probe routine. If the regulator_get() call fails, the failure is logged but ignored. Is that really the right thing to do? The pm_runtime_get_sync() call occurs before the probe is finished. This means that ehci-hcd's resume routine will try to power-up the device before its data structures have been initialized. That can't be right. The get clocks section occurs after the call to usb_add_hcd(). This means the controller will start running before the clock references are acquired -- so the clocks might still be turned off. That can't be right either. If the clk_get(dev, utmi_p1_gfclk) call fails, the error path never calls usb_remove_hcd(). The err_add_hcd pathway never calls usb_put_hcd(). I'm going to resubmit my most recent patch based the current ehci-omap.c, but you or someone else will still have to fix these problems. Alan Stern Hi Rus Dill, once Alan post his changes on ehci-omap.c, please re-base this patch on top of it. so that, I will rebase UHH-TLL split series on top your patch. regards keshava -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 3/3] ARM: OMAP2+: onenand: prepare for gpmc driver migration
* Jon Hunter jon-hun...@ti.com [120628 09:48]: [2.792510] OneNAND driver initializing [2.797576] omap2-onenand omap2-onenand: initializing on CS2, phys base 0x2000, virtual base c88c, freq 0 MHz [2.808929] OneNAND Manufacturer: Samsung (0xec) [2.808990] Muxed OneNAND 256MB 1.8V 16-bit (0x40) [2.814208] OneNAND version = 0x002c The above change seems to imply that Tony's n900 is dependent on the bootloader settings and not those being set by the kernel. Ideally, we should not need to set the async mode in the onenand before we set the onenand timings in the gpmc (per Afzal's changelog comment). This appears backwards. That should not be the case, I'm more likely to believe in Afzal's explanation. The other thing to note is that the 3430sdp has samsung onenand where as the n900 has Numonyx. The gpmc-onenand.c only has one set of settings that it is using for all devices. However, it would appear that at least the async settings are not working for the Numonyx. Therefore, may be we need to get a dump of Tony's n900 settings and make sure the right settings are being used for the appropriate board. Hmm I would assume the n900 onenand settings are the most tested settings we have. And AFAIK have also been tested with L3 frequency scaling. So let's assume they're mostly right. These onenand settings are really killing us. I don't want us to have to spend alot of time re-calculating this stuff but the way it has been written to begin with is not driver friendly. I really wonder if we need to have some sort of callback for the onenand timings from the driver. It is ugly, but the alternative is that someone needs to sit down and re-calculate all the timings again to get them into a driver friendly format. Furthermore, it seems that onenand is no longer available from the likes of samsung and numonyx (micron) so it is hard to justify re-calculating everything again. I am not even sure if we have all the datasheets! Let me know your thoughts. I don't think we should spend much time working on the recalculations. Let's rather use these known working cases as examples. If they don't work, it's likely that adding any new devices won't work either. For the timings, we should allow specifying either cycles or time values in the data struct. And always just use the cycle value directly if specified, and othewise use the time value. We may be able to limit the registers where we need to allow either cycle or time value depending on the device futher. In general, I doubt that we can come up with better calculations. The existing code pretty well already follows the device spec timings. And using cycle values for some registers is the right thing to do according to the connected device specs no matter what the frequency is. In those cases converting from time values to cycles does not make sense. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2 0/4] Add ability to set defaultless network device MAC addresses to deterministic computed locally administered values
The following series adds some code to generate legal, locally administered MAC addresses from OMAP4 CPU Die ID fuse data, and then adds a helper at net/ethernet taking care of accepting device path / MAC mapping registrations and running a notifier to enforce the requested MAC when the matching network device turns up. On PandaBoard / ES, two devices have no board-level MAC either assigned by the manufacturer or stored on the board, the last patch in the series adds these device paths and gets them set when the network device is registered. Lastly for convenient testing, there's a little patch on omap2plus_defconfig that will get Ethernet and WLAN up on Pandaboard. The patches are against today's linux-omap. Thanks to Tony Lindgren and Arnd Bergmann for comments leading to the helper in net/ethernet. --- Andy Green (4): OMAP2+: add cpu id register to MAC address helper net ethernet introduce mac_la_ap helper OMAP4 PANDA register ethernet and wlan for automatic mac allocation config test config extending omap2plus with wl12xx etc arch/arm/configs/omap2plus_defconfig | 35 +++ arch/arm/mach-omap2/Kconfig|1 arch/arm/mach-omap2/board-omap4panda.c | 30 ++ arch/arm/mach-omap2/id.c | 39 arch/arm/mach-omap2/include/mach/id.h |1 include/net/mac-la-ap.h| 28 + net/Kconfig| 14 +++ net/ethernet/Makefile |2 net/ethernet/mac-la-ap.c | 165 9 files changed, 294 insertions(+), 21 deletions(-) create mode 100644 include/net/mac-la-ap.h create mode 100644 net/ethernet/mac-la-ap.c -- 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 1/4] OMAP2+: add cpu id register to MAC address helper
From: Andy Green a...@warmcat.com
Introduce a generic helper function that can generate a valid MAC
address using data from the OMAP unique CPU ID register.
For comparison purposes this produces a MAC address of
2e:20:3c:ea:46:01
for the ethernet device on my PandaBoard ES.
The MAC address space has space set aside for these kind of locally
administered MAC addresses, analogous to IPv4 10.x.x.x range, and this
patch marks the generated MAC addresses as such.
The patch leaves two bits allowing elaborating 4 different MACs from the
generated data.
Signed-off-by: Andy Green andy.gr...@linaro.org
Acked-by: Arnd Bergmann a...@arndb.de
Signed-off-by: Nicolas Pitre nicolas.pi...@linaro.org
Tested-by: Steven Rostedt rost...@goodmis.org
---
arch/arm/mach-omap2/id.c | 39 +
arch/arm/mach-omap2/include/mach/id.h |1 +
2 files changed, 40 insertions(+)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 00486a8..2a44c42 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -530,3 +530,42 @@ void __init omap2_set_globals_tap(struct omap_globals
*omap2_globals)
else
tap_prod_id = 0x0208;
}
+
+/*
+ * this uses the unique per-cpu info from the cpu fuses set at factory to
+ * generate a 6-byte MAC address. Two bits in the generated code are used
+ * to elaborate the generated address into four, so it can be used on multiple
+ * network interfaces.
+ */
+
+void omap2_die_id_to_ethernet_mac(u8 *mac, int subtype)
+{
+ struct omap_die_id odi;
+ u32 tap = read_tap_reg(OMAP_TAP_IDCODE);
+
+ omap_get_die_id(odi);
+
+ mac[0] = odi.id_2;
+ mac[1] = odi.id_2 8;
+ mac[2] = odi.id_1;
+ mac[3] = odi.id_1 8;
+ mac[4] = odi.id_1 16;
+ mac[5] = odi.id_1 24;
+
+ /* XOR other chip-specific data with ID */
+
+ tap ^= odi.id_3;
+
+ mac[0] ^= tap;
+ mac[1] ^= tap 8;
+ mac[2] ^= tap 16;
+ mac[3] ^= tap 24;
+
+ /* allow four MACs from this same basic data */
+
+ mac[1] = (mac[1] ~0xc0) | ((subtype 3) 6);
+
+ /* mark it as not multicast, and outside official 80211 MAC namespace */
+
+ mac[0] = (mac[0] ~1) | 2;
+}
diff --git a/arch/arm/mach-omap2/include/mach/id.h
b/arch/arm/mach-omap2/include/mach/id.h
index 02ed3aa..373313a 100644
--- a/arch/arm/mach-omap2/include/mach/id.h
+++ b/arch/arm/mach-omap2/include/mach/id.h
@@ -18,5 +18,6 @@ struct omap_die_id {
};
void omap_get_die_id(struct omap_die_id *odi);
+void omap2_die_id_to_ethernet_mac(u8 *mac, int subtype);
#endif
--
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/4] net ethernet introduce mac_la_ap helper
From: Andy Green a...@warmcat.com
This introduces a small helper in net/ethernet, which registers a
network notifier on init, and accepts registrations of expected asynchronously-
probed network device paths (like, usb1/1-1/1-1.1/1-1.1:1.0) and the MAC
that is needed to be assigned to the device when it appears.
This allows platform code to enforce valid, consistent MAC addresses on to
devices that have not been probed at boot-time, but due to being wired on the
board are always present at the same interface. It has been tested with USB
and SDIO probed devices.
To make use of this safely you also need to make sure that any drivers that
may compete for the bus ordinal you are using (eg, mUSB and ehci in Panda
case) are loaded in a deterministic order.
At registration it makes a copy of the incoming data, so the data may be
__initdata or otherwise transitory. Registration can be called multiple times
so registrations from Device Tree and platform may be mixed.
Since it needs to be called quite early in boot and there is no lifecycle for
what it does, it could not be modular and is not a driver.
Via suggestions from Arnd Bergmann and Tony Lindgren.
Signed-off-by: Andy Green andy.gr...@linaro.org
---
include/net/mac-la-ap.h | 28
net/Kconfig | 14
net/ethernet/Makefile|2 +
net/ethernet/mac-la-ap.c | 165 ++
4 files changed, 209 insertions(+)
create mode 100644 include/net/mac-la-ap.h
create mode 100644 net/ethernet/mac-la-ap.c
diff --git a/include/net/mac-la-ap.h b/include/net/mac-la-ap.h
new file mode 100644
index 000..d5189b5
--- /dev/null
+++ b/include/net/mac-la-ap.h
@@ -0,0 +1,28 @@
+/*
+ * mac-la-ap.h: Locally Administered MAC address for Async probed devices
+ */
+
+/**
+ * struct mac_la_ap - associates asynchronously probed device path with
+ * MAC address to be assigned to the device when it
+ * is created
+ *
+ * @device_path: device path name of network device
+ * @mac: MAC address to assign to network device matching device path
+ * @list: can be left uninitialized when passing from platform
+ */
+
+struct mac_la_ap {
+ char *device_path;
+ u8 mac[6];
+ struct list_head list; /* unused in platform data usage */
+};
+
+/**
+ * mac_la_ap_register_device_macs - add an array of device path to monitor
+ * and MAC to apply when the network device
+ * at the device path appears
+ * @macs: array of struct mac_la_ap terminated by entry with NULL device_path
+ */
+int mac_la_ap_register_device_macs(const struct mac_la_ap *macs);
+
diff --git a/net/Kconfig b/net/Kconfig
index 245831b..76ba70e 100644
--- a/net/Kconfig
+++ b/net/Kconfig
@@ -335,6 +335,20 @@ source net/caif/Kconfig
source net/ceph/Kconfig
source net/nfc/Kconfig
+config MAC_LA_AP
+ bool Locally Administered MAC for Aysnchronously Probed devices
+ ---help---
+ This helper allows platforms to mandate a locally-administered
+ sythesized MAC address for network devices that are on asynchronously-
+ probed buses like USB or SDIO. This is necessary when the board has
+ these network assets but no arrangements for storing or setting the
+ MAC address of the network asset (nor any official MAC address
+ reserved for the device). In that case, seen in Panda and other
+ boards, the platform can synthesize a constant locally-administered
+ MAC address from SoC UID bits that has a good probability of differing
+ between boards but will be constant on any give board. This helper
+ will take care of watching for the network devices to appear and
+ force the MAC to the synthesized one when they do.
endif # if NET
diff --git a/net/ethernet/Makefile b/net/ethernet/Makefile
index 7cef1d8..94ee883 100644
--- a/net/ethernet/Makefile
+++ b/net/ethernet/Makefile
@@ -5,3 +5,5 @@
obj-y += eth.o
obj-$(subst m,y,$(CONFIG_IPX)) += pe2.o
obj-$(subst m,y,$(CONFIG_ATALK)) += pe2.o
+obj-$(CONFIG_MAC_LA_AP)+= mac-la-ap.o
+
diff --git a/net/ethernet/mac-la-ap.c b/net/ethernet/mac-la-ap.c
new file mode 100644
index 000..4216c41
--- /dev/null
+++ b/net/ethernet/mac-la-ap.c
@@ -0,0 +1,165 @@
+/*
+ * Helper to allow setting locally-administered MAC addresses automatically on
+ * asynchronously probed devices, such as SDIO and USB based devices.
+ *
+ * Because the device path is used for matching, this is only useful for
+ * network assets physcally wired on the board, and also requires any
+ * different drivers that can compete for bus ordinals (eg mUSB vs ehci) to
+ * have fixed initialization ordering, eg, by having ehci in monolithic
+ * kernel
+ *
+ * Neither a driver nor a module as needs to be callable from machine file
+ * before the network devices are registered.
+ *
+ * (c) 2012 Andy
[PATCH 2 3/4] OMAP4 PANDA register ethernet and wlan for automatic mac allocation
From: Andy Green a...@warmcat.com
This provides the board-specific device paths needed to get
the panda boardfile working with the mac-la-ap api.
On Pandaboard / ES, neither the onboard Ethernet or onboard WLAN
module have onboard arrangements for MAC storage, without this
series yielding randomized MAC per-boot and consequent DHCP problems,
or in the case of wlan0 a MAC set by a firmware file in the rootfs
which unless customized yields a MAC of 00:00:00:00:00:00. No
official MAC is reserved for either network device even if you do
take the approach to customize the firmware file.
This gets sane, consistent MAC addresses on both devices which
should stand a good probability of differing between PandaBoards.
Signed-off-by: Andy Green andy.gr...@linaro.org
---
arch/arm/mach-omap2/Kconfig|1 +
arch/arm/mach-omap2/board-omap4panda.c | 30 ++
2 files changed, 31 insertions(+)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 5e95aa6..d968e7f 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -348,6 +348,7 @@ config MACH_OMAP4_PANDA
select OMAP_PACKAGE_CBL
select OMAP_PACKAGE_CBS
select REGULATOR_FIXED_VOLTAGE if REGULATOR
+ select MAC_LA_AP
config MACH_PCM049
bool OMAP4 based phyCORE OMAP4
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index 982fb26..8f4984b 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -32,7 +32,10 @@
#include linux/wl12xx.h
#include linux/platform_data/omap-abe-twl6040.h
+#include net/mac-la-ap.h
+
#include mach/hardware.h
+#include mach/id.h
#include asm/hardware/gic.h
#include asm/mach-types.h
#include asm/mach/arch.h
@@ -486,16 +489,43 @@ static void omap4_panda_init_rev(void)
}
}
+/*
+ * These device paths represent onboard network devices which have
+ * no MAC address set at boot, and need synthetic ones assigning
+ */
+static __initdata struct mac_la_ap panda_mac_la_ap[] = {
+
+ { /* smsc USB - Ethernet bridge */
+ .device_path = usb1/1-1/1-1.1/1-1.1:1.0,
+ },
+ { /* wlan0 module */
+ .device_path = wl12xx,
+ },
+ { /* terminator */
+ }
+};
+
static void __init omap4_panda_init(void)
{
int package = OMAP_PACKAGE_CBS;
int ret;
+ int n;
if (omap_rev() == OMAP4430_REV_ES1_0)
package = OMAP_PACKAGE_CBL;
omap4_mux_init(board_mux, NULL, package);
omap_panda_wlan_data.irq = gpio_to_irq(GPIO_WIFI_IRQ);
+
+ /*
+* provide MAC addresses computed from device ID for network
+* devices that have no MAC address otherwise on Panda
+*/
+ for (n = 0; n ARRAY_SIZE(panda_mac_la_ap) - 1; n++)
+ omap2_die_id_to_ethernet_mac(panda_mac_la_ap[n].mac, n);
+ if (mac_la_ap_register_device_macs(panda_mac_la_ap))
+ pr_err(Unable to register mac_la_ap devices\n);
+
ret = wl12xx_set_platform_data(omap_panda_wlan_data);
if (ret)
pr_err(error setting wl12xx data: %d\n, ret);
--
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 4/4] config test config extending omap2plus with wl12xx etc
From: Andy Green a...@warmcat.com This is just provided for testing convenience, it has enough config options to get Ethernet and WL12xx driver on PandaBoard / ES up You should be able to reproduce something like this, with different MAC addresses. # ifconfig -a eth0 Link encap:Ethernet HWaddr 2e:20:3c:ea:46:01 inet addr:10.42.0.98 Bcast:10.42.0.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:13 errors:0 dropped:0 overruns:0 frame:0 TX packets:31 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1647 (1.6 KB) TX bytes:5534 (5.5 KB) loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:2 errors:0 dropped:0 overruns:0 frame:0 TX packets:2 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:100 (100.0 B) TX bytes:100 (100.0 B) wlan0 Link encap:Ethernet HWaddr 2e:60:3c:ea:46:01 BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) Signed-off-by: Andy Green andy.gr...@linaro.org --- arch/arm/configs/omap2plus_defconfig | 35 ++ 1 file changed, 14 insertions(+), 21 deletions(-) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index f3087cb..7dcd384 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -2,13 +2,13 @@ CONFIG_EXPERIMENTAL=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y +CONFIG_NO_HZ=y +CONFIG_HIGH_RES_TIMERS=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=16 CONFIG_BLK_DEV_INITRD=y CONFIG_EXPERT=y -# CONFIG_SYSCTL_SYSCALL is not set -CONFIG_KALLSYMS_EXTRA_PASS=y CONFIG_SLAB=y CONFIG_PROFILING=y CONFIG_OPROFILE=y @@ -20,13 +20,12 @@ CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y # CONFIG_BLK_DEV_BSG is not set +CONFIG_PARTITION_ADVANCED=y CONFIG_ARCH_OMAP=y CONFIG_OMAP_RESET_CLOCKS=y CONFIG_OMAP_MUX_DEBUG=y CONFIG_ARM_THUMBEE=y CONFIG_ARM_ERRATA_411920=y -CONFIG_NO_HZ=y -CONFIG_HIGH_RES_TIMERS=y CONFIG_SMP=y CONFIG_NR_CPUS=2 CONFIG_LEDS=y @@ -60,6 +59,7 @@ CONFIG_BT_HCIUART_LL=y CONFIG_BT_HCIBCM203X=m CONFIG_BT_HCIBPA10X=m CONFIG_CFG80211=m +CONFIG_LIB80211=m CONFIG_MAC80211=m CONFIG_MAC80211_RC_PID=y CONFIG_MAC80211_RC_DEFAULT_PID=y @@ -87,22 +87,20 @@ CONFIG_SCSI_MULTI_LUN=y CONFIG_SCSI_SCAN_ASYNC=y CONFIG_MD=y CONFIG_NETDEVICES=y -CONFIG_SMSC_PHY=y -CONFIG_NET_ETHERNET=y -CONFIG_SMC91X=y -CONFIG_SMSC911X=y CONFIG_KS8851=y CONFIG_KS8851_MLL=y -CONFIG_LIBERTAS=m -CONFIG_LIBERTAS_USB=m -CONFIG_LIBERTAS_SDIO=m -CONFIG_LIBERTAS_DEBUG=y +CONFIG_SMC91X=y +CONFIG_SMSC911X=y +CONFIG_SMSC_PHY=y CONFIG_USB_USBNET=y CONFIG_USB_NET_SMSC95XX=y CONFIG_USB_ALI_M5632=y CONFIG_USB_AN2720=y CONFIG_USB_EPSON2888=y CONFIG_USB_KC2190=y +CONFIG_WL_TI=y +CONFIG_WL12XX=m +CONFIG_WLCORE_SDIO=m CONFIG_INPUT_JOYDEV=y CONFIG_INPUT_EVDEV=y CONFIG_KEYBOARD_GPIO=y @@ -131,14 +129,14 @@ CONFIG_POWER_SUPPLY=y CONFIG_WATCHDOG=y CONFIG_OMAP_WATCHDOG=y CONFIG_TWL4030_WATCHDOG=y -CONFIG_REGULATOR_TWL4030=y +CONFIG_MFD_WL1273_CORE=y CONFIG_REGULATOR_TPS65023=y CONFIG_REGULATOR_TPS6507X=y +CONFIG_REGULATOR_TWL4030=y CONFIG_FB=y CONFIG_FIRMWARE_EDID=y CONFIG_FB_MODE_HELPERS=y CONFIG_FB_TILEBLITTING=y -CONFIG_FB_OMAP_LCD_VGA=y CONFIG_OMAP2_DSS=m CONFIG_OMAP2_DSS_RFBI=y CONFIG_OMAP2_DSS_SDI=y @@ -153,7 +151,6 @@ CONFIG_PANEL_ACX565AKM=m CONFIG_BACKLIGHT_LCD_SUPPORT=y CONFIG_LCD_CLASS_DEVICE=y CONFIG_LCD_PLATFORM=y -CONFIG_DISPLAY_SUPPORT=y CONFIG_FRAMEBUFFER_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y CONFIG_FONTS=y @@ -173,7 +170,6 @@ CONFIG_SND_OMAP_SOC_OMAP3_PANDORA=m CONFIG_USB=y CONFIG_USB_DEBUG=y CONFIG_USB_ANNOUNCE_NEW_DEVICES=y -CONFIG_USB_DEVICEFS=y CONFIG_USB_SUSPEND=y CONFIG_USB_MON=y CONFIG_USB_EHCI_HCD=y @@ -212,23 +208,20 @@ CONFIG_JFFS2_RUBIN=y CONFIG_UBIFS_FS=y CONFIG_CRAMFS=y CONFIG_NFS_FS=y -CONFIG_NFS_V3=y CONFIG_NFS_V3_ACL=y CONFIG_NFS_V4=y CONFIG_ROOT_NFS=y -CONFIG_PARTITION_ADVANCED=y CONFIG_NLS_CODEPAGE_437=y CONFIG_NLS_ISO8859_1=y CONFIG_PRINTK_TIME=y CONFIG_MAGIC_SYSRQ=y -CONFIG_DEBUG_KERNEL=y CONFIG_SCHEDSTATS=y CONFIG_TIMER_STATS=y CONFIG_PROVE_LOCKING=y -CONFIG_DEBUG_SPINLOCK_SLEEP=y # CONFIG_DEBUG_BUGVERBOSE is not set CONFIG_DEBUG_INFO=y -# CONFIG_RCU_CPU_STALL_DETECTOR is not set +CONFIG_DEBUG_LL=y +CONFIG_EARLY_PRINTK=y CONFIG_SECURITY=y CONFIG_CRYPTO_MICHAEL_MIC=y # CONFIG_CRYPTO_ANSI_CPRNG is not set -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More
[PATCH] da8xx-fb: add missing FB_BLANK operations
From: Yegor Yefremov yegorsli...@googlemail.com add FB_BLANK_NORMAL, FB_BLANK_VSYNC_SUSPEND and FB_BLANK_HSYNC_SUSPEND modes (copy drivers/video/omap2/omapfb/omapfb-main.c implementation). Otherwise X-server will complain about invalid parameter. Signed-off-by: Yegor Yefremov yegorsli...@googlemail.com --- drivers/video/da8xx-fb.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c index 29577bf..9879edc 100644 --- a/drivers/video/da8xx-fb.c +++ b/drivers/video/da8xx-fb.c @@ -987,6 +987,9 @@ static int cfb_blank(int blank, struct fb_info *info) lcd_enable_raster(); break; + case FB_BLANK_NORMAL: + case FB_BLANK_VSYNC_SUSPEND: + case FB_BLANK_HSYNC_SUSPEND: case FB_BLANK_POWERDOWN: if (par-panel_power_ctrl) par-panel_power_ctrl(0); -- 1.7.7 -- 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: how to specify dma_mask and coherent_dma_mask in hwmod
Hi Paul, -Original Message- From: Bedia, Vaibhav Sent: Friday, June 29, 2012 4:54 PM To: Paul Walmsley Cc: N, Mugunthan V; linux-omap@vger.kernel.org; linux-arm- ker...@lists.infradead.org; Cousson, Benoit; Hilman, Kevin Subject: RE: how to specify dma_mask and coherent_dma_mask in hwmod Hi Paul, On Thu, Jun 28, 2012 at 22:02:46, Paul Walmsley wrote: On Thu, 28 Jun 2012, Bedia, Vaibhav wrote: On Thu, Jun 28, 2012 at 21:22:54, Paul Walmsley wrote: [...] dma_mask and coherent_dma_mask can be specified during device creation. See usb_musb_init() in arch/arm/mach-omap2/usb- musb.c for an example. Thanks for pointing this out. Should omap_device_build() start handling this or would that be an overkill? If both dma_mask and coherent_dma_mask are always 0x on all OMAPs and we can set that safely even for devices that don't use it, then yeah it sounds like we should set it. Care to send a patch? I just grepped for the any other user of this under mach-omap2 and plat- omap and there are a few other places where it's getting used. All of them are setting it to 0x and same is the case with the CPSW driver. I don't know much about the dma stuff so I am bit reluctant in setting this unconditionally. I looked at setting the mask based on a flag during omap_device_build() but an additional flag in the API will cause all the users to be changed. We could perhaps extend the omap_hwmod structure for passing on this information. Or for CPSW we could stick with approach that's been adopted in usb_musb_init(). Which approach sounds better to you? Regards, Vaibhav B. Extending omap_device_build() to accommodate dma masks will endup with lot of code changes in other modules, so will follow the same from usb_musd_init(). Regards, Mugunthan V N. -- 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 00/10] Prepare for GPMC driver conversion (w.r.t MTD)
* Artem Bityutskiy artem.bityuts...@linux.intel.com [120627 02:36]: On Wed, 2012-06-13 at 17:02 +0530, Afzal Mohammed wrote: Hi, This series cleans up gpmc mtd interactions so that GPMC driver conversion which is going to happen shortly would happen smoothly by not creating much disturbance outside of arch/arm/*omap*/ Dunno if Tony picked this, but the MTD changes look good an the quick glance. Feel free to add Acked-by: Artem Bityutskiy artem.bityuts...@linux.intel.com Thanks will add to the drivers/mtd touching patches in this series. 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] da8xx-fb: add missing FB_BLANK operations
On Mon, Jul 02, 2012 at 12:41:13, yegorsli...@googlemail.com wrote: From: Yegor Yefremov yegorsli...@googlemail.com add FB_BLANK_NORMAL, FB_BLANK_VSYNC_SUSPEND and FB_BLANK_HSYNC_SUSPEND modes (copy drivers/video/omap2/omapfb/omapfb-main.c implementation). Otherwise X-server will complain about invalid parameter. Signed-off-by: Yegor Yefremov yegorsli...@googlemail.com --- drivers/video/da8xx-fb.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c index 29577bf..9879edc 100644 --- a/drivers/video/da8xx-fb.c +++ b/drivers/video/da8xx-fb.c @@ -987,6 +987,9 @@ static int cfb_blank(int blank, struct fb_info *info) lcd_enable_raster(); break; + case FB_BLANK_NORMAL: + case FB_BLANK_VSYNC_SUSPEND: + case FB_BLANK_HSYNC_SUSPEND: case FB_BLANK_POWERDOWN: if (par-panel_power_ctrl) par-panel_power_ctrl(0); + linux-fbdev Florian You should always send Fbdev patches to linux-fbdev list. 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] arm/dts: OMAP4: Add Variscite OMAP4 System-On-Modeule support
* Uri Yosef ur...@variscite.com [120606 05:13]: CCed devicetree-disc...@lists.ozlabs.org. On Wed, Jun 6, 2012 at 12:09 PM, Tony Lindgren t...@atomide.com wrote: Hi, * Uri Yosef ur...@variscite.com [120517 05:34]: Hi Tony, This is the updated DTS patch for Vatiscite OMAP4 SOM support Looks OK to me, but can you please repost one more time with devicetree-disc...@lists.ozlabs.org in Cc so people have a chance to ack this patch there? Applying into dt branch with disable updated to disabled as was done in for other boards. 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: Current state of AM33xx patches
On 29/06/12 18:56, Hiremath, Vaibhav wrote: On Fri, Jun 29, 2012 at 19:50:45, Mark Jackson wrote: This does appear to work using the ramdisk, but there seems to be no support for booting off MMC. This is known thing and clearly mentioned/highlighted above. Use the ramdisk image to boot kernel, since we do not have support for any storage devices in the mainline. Oops ... missed that, sorry !! snip All in all, the AM335x code does seem to be very fragmented. Is that just because these are non-trivial changes going in ? Not really true. The answer is simple, if you are looking for production quality code then certainly you should use something based on PSP release (SDK) and if you want to stay close to Mainline and would like to contribute towards it, you have to understand the process, dependencies, development and discussions happening on the list. Okay. Thanks for explaining. Mark -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND] usb: otg: OMAP4: Fix the omap4430_phy_set_clk function
* Ruslan Bilovol ruslan.bilo...@ti.com [120629 14:55]:
On Wed, Jun 20, 2012 at 4:31 PM, Tony Lindgren t...@atomide.com wrote:
* Ruslan Bilovol ruslan.bilo...@ti.com [120612 10:42]:
If the clocks are enabled and we want to enable them again
omap4430_phy_set_clk disables them.
Fix this - so now if we try to enable already enabled clocks
it works correctly.
Sounds like Felipe is on vacation. Trying to figure out if this
is something for the fixes branch:
What happens if this not fixed, do you get some error?
The function is designed for simple clocks on-off:
if zero on parameter is passed - switch the clocks off,
if non-zero on parameter passed - switch the clocks on.
But due to error in implementation, it works wrong if called twice or more
times with non-zero on parameter.
For example, assuming that clocks are disabled:
omap4430_phy_set_clk(dev, 1); === enables clocks
omap4430_phy_set_clk(dev, 1); === suddenly disables clocks,
when we expect enabling.
omap4430_phy_set_clk(dev, 1); === enables clocks again
It seems impact of this wrong behavior is not observed on current code
base, but we see
crashes caused by access to non-clocked registers when heavy use this function
in the charger detection or after implementing otg EYE improvement.
Yes thanks for explaining. Can you please update the commit message a bit
with the explanation above?
Was this caused by some recent commit?
No, we have this wrong behavior since the omap_phy_internal.c file
creation (c33fad0c37)
OK. It's probably safest to wait for Felipe to take a look at this
patch then and queue it for v3.6 -rc cycle.
Regards,
Tony
Signed-off-by: Ruslan Bilovol ruslan.bilo...@ti.com
---
arch/arm/mach-omap2/omap_phy_internal.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_phy_internal.c
b/arch/arm/mach-omap2/omap_phy_internal.c
index 4c90477..0196683 100644
--- a/arch/arm/mach-omap2/omap_phy_internal.c
+++ b/arch/arm/mach-omap2/omap_phy_internal.c
@@ -97,7 +97,7 @@ int omap4430_phy_set_clk(struct device *dev, int on)
clk_enable(clk48m);
clk_enable(clk32k);
state = 1;
- } else if (state) {
+ } else if (!on state) {
/* Disable the phy clocks */
clk_disable(phyclk);
clk_disable(clk48m);
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH V3 1/2] arm/dts: OMAP2: Add support for OMAP2420H4 Board
* Jon Hunter jon-hun...@ti.com [120612 17:45]:
Simple DTS file for OMAP2420H4 board adding memory information to allow
device-tree testing on an OMAP2420. OMAP2420H4 board has 64MB of RAM.
Verified that kernel boots with DT using a simple RAMDISK file-system on
OMAP2420H4.
Thanks, applying into dt branch.
Tony
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/boot/dts/omap2420-h4.dts | 20
1 file changed, 20 insertions(+)
create mode 100644 arch/arm/boot/dts/omap2420-h4.dts
diff --git a/arch/arm/boot/dts/omap2420-h4.dts
b/arch/arm/boot/dts/omap2420-h4.dts
new file mode 100644
index 000..25b50b7
--- /dev/null
+++ b/arch/arm/boot/dts/omap2420-h4.dts
@@ -0,0 +1,20 @@
+/*
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+/dts-v1/;
+
+/include/ omap2.dtsi
+
+/ {
+ model = TI OMAP2420 H4 board;
+ compatible = ti,omap2420-h4, ti,omap2420, ti,omap2;
+
+ memory {
+ device_type = memory;
+ reg = 0x8000 0x8400; /* 64 MB */
+ };
+};
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: OMAP3: cm-t35: add mt9t001 camera sensor support
* Dmitry Lifshitz lifsh...@compulab.co.il [120613 06:00]: Setup pinmux for CPI and register the mt9t001 camera sensor in ISP subsystem. Applying both into devel-board branch. Note that we are phasing out the board-*.c files with device tree support, so only minimal changes will be applied to the board-*.c files at this point. 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 RESEND] usb: otg: OMAP4: Fix the omap4430_phy_set_clk function
Hi,
On Tue, Jun 12, 2012 at 08:36:21PM +0300, Ruslan Bilovol wrote:
If the clocks are enabled and we want to enable them again
omap4430_phy_set_clk disables them.
Fix this - so now if we try to enable already enabled clocks
it works correctly.
Signed-off-by: Ruslan Bilovol ruslan.bilo...@ti.com
---
arch/arm/mach-omap2/omap_phy_internal.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_phy_internal.c
b/arch/arm/mach-omap2/omap_phy_internal.c
index 4c90477..0196683 100644
--- a/arch/arm/mach-omap2/omap_phy_internal.c
+++ b/arch/arm/mach-omap2/omap_phy_internal.c
@@ -97,7 +97,7 @@ int omap4430_phy_set_clk(struct device *dev, int on)
clk_enable(clk48m);
clk_enable(clk32k);
state = 1;
- } else if (state) {
+ } else if (!on state) {
why don't you let clocks be enabled twice then ? That would cut down the
churn.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 1/4] Revert arm/dts: Add support for TI AM335x EVM board
* AnilKumar Ch anilku...@ti.com [120622 02:45]: This reverts commit 6c54bbb42678c99685c8e7fd09267e1cb8c2ae40. As that has not been merged yet, I'll just drop it and set up a new devel-dt branch. Applying the reset into devel-dt. 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 1/4] Revert arm/dts: Add support for TI AM335x EVM board
On 7/2/2012 2:10 PM, Tony Lindgren wrote: * AnilKumar Ch anilku...@ti.com [120622 02:45]: This reverts commit 6c54bbb42678c99685c8e7fd09267e1cb8c2ae40. As that has not been merged yet, I'll just drop it and set up a new devel-dt branch. Applying the reset into devel-dt. Yeah, that's better. Care to include it into you next pull request. 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 2/2] remoteproc: remove the now-redundant kref
On Tue, Jun 5, 2012 at 12:22 AM, Stephen Boyd sb...@codeaurora.org wrote:
On 05/30/12 05:38, Ohad Ben-Cohen wrote:
On Wed, May 30, 2012 at 11:42 AM, Stephen Boyd sb...@codeaurora.org wrote:
- /* the rproc will only be released after its refcount drops to zero
*/
- kref_put(rproc-refcount, rproc_release);
+ /* unroll rproc_alloc. TODO: we may want to let the users do that */
+ put_device(rproc-dev);
Yes I think we want rproc_free() to actually call put_device() the last
time and free the resources.
Yeah that was one of the options I considered.
In general, we have three options here:
1. Remove this last put_device invocation, and require users to call
rproc_free() even after they call rproc_unregister().
2. Let rproc_unregister() still do this, by calling rproc_free().
3. Let rproc_unregister() still do this, by invoking put_device().
I think that (1) looks better since it makes the interface symmetric
and straight forward.
(2) and (3) may be simper because users only need to call
rproc_unregister and that's it.
I eventually decided against (1) because I was concerned it will only
confuse users at this point.
But if you think that (1) is nicer too then maybe we should go ahead
and do that change.
Option 1 is nicer and it also follows the model other subsystems have
put forth such as the input subsystem.
From 0fbf3004c1a52ae4c0554366409a2bfe401801ef Mon Sep 17 00:00:00 2001
From: Ohad Ben-Cohen o...@wizery.com
Date: Mon, 2 Jul 2012 11:41:16 +0300
Subject: [PATCH] remoteproc: simplify unregister/free interfaces
Simplify the unregister/free interfaces, and make them easier
to understand and use, by moving to a symmetric and consistent
alloc() - register() - unregister() - free() flow.
To create and register an rproc instance, one needed to invoke
rproc_alloc() followed by rproc_register().
To unregister and free an rproc instance, one now needs to invoke
rproc_unregister() followed by rproc_free().
Cc: Stephen Boyd sb...@codeaurora.org
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
Documentation/remoteproc.txt | 21 -
drivers/remoteproc/omap_remoteproc.c | 5 -
drivers/remoteproc/remoteproc_core.c | 25 -
3 files changed, 20 insertions(+), 31 deletions(-)
diff --git a/Documentation/remoteproc.txt b/Documentation/remoteproc.txt
index 70a048c..ad6ded4 100644
--- a/Documentation/remoteproc.txt
+++ b/Documentation/remoteproc.txt
@@ -120,14 +120,14 @@ int dummy_rproc_example(struct rproc *my_rproc)
On success, the new rproc is returned, and on failure, NULL.
Note: _never_ directly deallocate @rproc, even if it was not registered
- yet. Instead, if you just need to unroll rproc_alloc(), use rproc_free().
+ yet. Instead, when you need to unroll rproc_alloc(), use rproc_free().
void rproc_free(struct rproc *rproc)
- Free an rproc handle that was allocated by rproc_alloc.
- This function should _only_ be used if @rproc was only allocated,
- but not registered yet.
- If @rproc was already successfully registered (by calling
- rproc_register()), then use rproc_unregister() instead.
+ This function essentially unrolls rproc_alloc(), by decrementing the
+ rproc's refcount. It doesn't directly free rproc; that would happen
+ only if there are no other references to rproc and its refcount now
+ dropped to zero.
int rproc_register(struct rproc *rproc)
- Register @rproc with the remoteproc framework, after it has been
@@ -143,19 +143,14 @@ int dummy_rproc_example(struct rproc *my_rproc)
probed.
int rproc_unregister(struct rproc *rproc)
-- Unregister a remote processor, and decrement its refcount.
- If its refcount drops to zero, then @rproc will be freed. If not,
- it will be freed later once the last reference is dropped.
-
+- Unroll rproc_register().
This function should be called when the platform specific rproc
implementation decides to remove the rproc device. it should
_only_ be called if a previous invocation of rproc_register()
has completed successfully.
- After rproc_unregister() returns, @rproc is _not_ valid anymore and
- it shouldn't be used. More specifically, don't call rproc_free()
- or try to directly free @rproc after rproc_unregister() returns;
- none of these are needed, and calling them is a bug.
+ After rproc_unregister() returns, @rproc is still valid, and its
+ last refcount should be decremented by calling rproc_free().
Returns 0 on success and -EINVAL if @rproc isn't valid.
diff --git a/drivers/remoteproc/omap_remoteproc.c
b/drivers/remoteproc/omap_remoteproc.c
index f45230c..0f1afc9 100644
--- a/drivers/remoteproc/omap_remoteproc.c
+++ b/drivers/remoteproc/omap_remoteproc.c
@@ -214,7 +214,10 @@ static int __devexit omap_rproc_remove(struct
platform_device *pdev)
{
struct rproc *rproc =
[PATCH] arm: omap: hwmod: make *phy_48m* as the main_clk of ocp2scp
Made *ocp2scp_usb_phy_phy_48m* as the main_clk for ocp2scp.
Since this ocp2scp module does not have any fck but does have a
single opt_clock, it is added as the main_clk for ocp2scp. Also
removed phy_48m as the optional clock since it is now made as the
main clock.
Cc: Benoît Cousson b-cous...@ti.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Changes from [RFC PATCH 1/5] arm: omap: hwmod: make *phy_48m* as the main_clk
of ocp2scp:
* Removed *ocp2scp_usb_phy_phy_48m* as the optional functional clock
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |7 +--
1 files changed, 1 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index f30e861..17cf933 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -2504,14 +2504,11 @@ static struct omap_hwmod_class
omap44xx_ocp2scp_hwmod_class = {
};
/* ocp2scp_usb_phy */
-static struct omap_hwmod_opt_clk ocp2scp_usb_phy_opt_clks[] = {
- { .role = phy_48m, .clk = ocp2scp_usb_phy_phy_48m },
-};
-
static struct omap_hwmod omap44xx_ocp2scp_usb_phy_hwmod = {
.name = ocp2scp_usb_phy,
.class = omap44xx_ocp2scp_hwmod_class,
.clkdm_name = l3_init_clkdm,
+ .main_clk = ocp2scp_usb_phy_phy_48m,
.prcm = {
.omap4 = {
.clkctrl_offs =
OMAP4_CM_L3INIT_USBPHYOCP2SCP_CLKCTRL_OFFSET,
@@ -2519,8 +2516,6 @@ static struct omap_hwmod omap44xx_ocp2scp_usb_phy_hwmod =
{
.modulemode = MODULEMODE_HWCTRL,
},
},
- .opt_clks = ocp2scp_usb_phy_opt_clks,
- .opt_clks_cnt = ARRAY_SIZE(ocp2scp_usb_phy_opt_clks),
};
/*
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] remoteproc: remove the now-redundant kref
On Mon, Jul 02, 2012 at 11:52:27AM +0300, Ohad Ben-Cohen wrote: Simplify the unregister/free interfaces, and make them easier to understand and use, by moving to a symmetric and consistent alloc() - register() - unregister() - free() flow. The naming in the driver model is: alloc() - add() - del() - put() where alloc() is an allocation + initialization, and register() - unregister() where register() is initialization + add() and unregister() is del() + put(). -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] remoteproc: remove the now-redundant kref
On Mon, Jul 2, 2012 at 11:59 AM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Mon, Jul 02, 2012 at 11:52:27AM +0300, Ohad Ben-Cohen wrote: Simplify the unregister/free interfaces, and make them easier to understand and use, by moving to a symmetric and consistent alloc() - register() - unregister() - free() flow. The naming in the driver model is: alloc() - add() - del() - put() where alloc() is an allocation + initialization, and register() - unregister() where register() is initialization + add() and unregister() is del() + put(). I wasn't sure if it'd help to adopt the driver model's naming, but I guess it just might do, so I'll do that. Thanks! -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v5 3/3] ARM: OMAP2+: onenand: prepare for gpmc driver migration
Hi Tony,
On Mon, Jul 02, 2012 at 12:06:51, Tony Lindgren wrote:
* Jon Hunter jon-hun...@ti.com [120628 09:48]:
The above change seems to imply that Tony's n900 is dependent on the
bootloader settings
and not those being set by the kernel. Ideally, we should not need to set
the async mode
in the onenand before we set the onenand timings in the gpmc (per Afzal's
changelog
comment). This appears backwards.
That should not be the case, I'm more likely to believe in Afzal's
explanation.
Not sure whether you are fine with fixing up this patch with added diff
Assuming inferences so far is not wrong, right now this patch with the added
diff
would be perfectly fine.
Problem would happen when we are at a stage to do gpmc reset using hwmod [seems
miles to go before I sleep {or read gpmc hwmod reset} ;)]. If bootloader left
onenand configured in sync mode, to switch onenand to async mode, first
configuring
gpmc to sync mode would be required for that we need frequency information
from onenand and to get that information from onenand, gpmc has to be configured
for sync mode and to configure gpmc to sync mode
Seems like chicken and egg problem.
N900, I believe is board-rx51, could not get proper schematic for onenand
connections, nor do I have the Numonyx datsheet, or the board, hence not
sure whether resetting onenand may resolve the issue. But if you feel that
it is the right solution it would resolve the issue, and if you can let
me know gpio connected (if any) to onenand reset or else some pointers to
achieving it, I can try making a patch to do onenand reset
Regards
Afzal
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] ARM: omap: clk: add clk_prepare and clk_unprepare
On Saturday 30 June 2012 01:49 AM, Paul Walmsley wrote: Hi On Wed, 27 Jun 2012, Rajendra Nayak wrote: As part of Common Clk Framework (CCF) the clk_enable() operation was split into a clk_prepare() which could sleep, and a clk_enable() which should never sleep. Similarly the clk_disable() was split into clk_disable() and clk_unprepare(). This was needed to handle complex cases where in a clk gate/ungate would require a slow and a fast part to be implemented. None of the clocks below seem to be in the 'complex' clocks category and are just simple clocks which are enabled/disabled through simple register writes. Most of the instances also seem to be called in non-atomic context which means its safe to move all of those from using a clk_enable() to clk_prepare_enable() and clk_disable() to clk_disable_unprepare(). For a few others where there is a possibility they get called from an interrupt or atomic context, there is an additonal clk_prepare() done before a clk_enable() and a clk_unprepare() after a clk_disable(). This is in preparation of OMAP moving to CCF. Based on initial changes from Mike turquette. Signed-off-by: Rajendra Nayakrna...@ti.com This patch generates quite a few checkpatch warnings: WARNING: please, no space before tabs #294: FILE: arch/arm/mach-omap2/clock3xxx_data.c:3479: +^ICLK(NULL, ^Imcbsp4_ick,^Imcbsp2_ick,^ICK_3XXX),$ etc. Please fix these. The 80 column warnings from checkpatch on the CLK(... lines can be ignored. Sorry, I seemed to have overlooked these thinking all to be 80 column warnings. Will fix all the non 80 column warnings and repost. regards, Rajendra - 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 V2 01/10] ARM: PMU: Add runtime PM Support
Hi Jon, Did you have any luck getting to the bottom of this? It would be good to take your PMU suspend/resume patches once we know that they will get used. On Tue, Jun 12, 2012 at 11:41:27PM +0100, Jon Hunter wrote: On 06/12/2012 04:31 PM, Will Deacon wrote: That's understandable -- one of the CPUs is likely more loaded than the other. However, I'd like to confirm whether or not you see what I see. With the 4430_init hack on a 4460, if I run: # taskset 0x2 perf top then I get no samples. If I do: # taskset 0x1 perf top then I *do* get samples and from *both* CPUs. So it smells more like an issue poking some configuration registers from CPU1 rather than the IRQ path being broken. As I said before, if I don't do the extra init hack then I don't get this problem (but event counters don't tick). In both cases, I see interrupts on both CPUs. However, typically more on the CPU that perf is running on (which is probably to be expected). And I confirm that the only change I made was ... [...] When you boot the kernel what 4460 rev does it show (very early in the kernel boot log)? Mine shows ... [0.00] OMAP4460 ES1.1 Snap: [0.00] OMAP4460 ES1.1 However, the A9 version has not changed between ES1.0 and ES1.1. Both should be r2p10. Yup, that's what /proc/cpuinfo says. Will -- 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 3/3] ARM: omap: clk: Remove all direct dereferencing of struct clk
On Saturday 30 June 2012 01:53 AM, Paul Walmsley wrote:
Hi
On Wed, 27 Jun 2012, Rajendra Nayak wrote:
While we move to Common Clk Framework (CCF), direct deferencing of struct
clk wouldn't be possible anymore. Hence get rid of all such instances
in the current clock code and use macros/helpers similar to the ones that
are provided by CCF.
Signed-off-by: Rajendra Nayakrna...@ti.com
This patch generates checkpatch warnings. Here's a sample:
WARNING: quoted string split across lines
#479: FILE: arch/arm/mach-omap2/clock.c:109:
pr_debug(clock: could not associate clk %s to
+clkdm %s\n, clk_name, clk-clkdm_name);
CHECK: Alignment should match open parenthesis
#594: FILE: arch/arm/mach-omap2/dpll3xxx.c:455:
+ if (__clk_get_rate(dd-clk_bypass) == rate
(clk-dpll_data-modes (1 DPLL_LOW_POWER_BYPASS))) {
ERROR: Macros with complex values should be enclosed in parenthesis
#706: FILE: arch/arm/plat-omap/include/plat/clock.h:22:
+#define __clk_get_name(clk) clk-name
In the case of the quoted string warnings, please go ahead and
concatenate those strings while you are there. That needs to be done
anyway.
Ok, will do. I was able to fix all but one hard to fix CHECK for this
patch..
---
CHECK: Alignment should match open parenthesis
#608: FILE: arch/arm/mach-omap2/dpll3xxx.c:455:
+ if (__clk_get_rate(dd-clk_bypass) == rate
(clk-dpll_data-modes (1 DPLL_LOW_POWER_BYPASS))) {
total: 0 errors, 0 warnings, 1 checks, 608 lines checked
0003-ARM-omap-clk-Remove-all-direct-dereferencing-of-stru.patch has
style problems, please review.
If any of these errors are false positives, please report
---
I could not find anything wrong with the alignment, but checkpatch
keeps complaining. It complains for the original code too.
Might be a checkpatch bug? Or do you really see anything wrong in
the alignment?
- 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 v5 3/3] ARM: OMAP2+: onenand: prepare for gpmc driver migration
Hi Jon, On Fri, Jun 29, 2012 at 19:45:37, Hunter, Jon wrote: On 06/29/2012 01:15 AM, Mohammed, Afzal wrote: I have a different opinion, even with the existing code, with the default timings for onenand, Numonyx is working in async mode, reason being that frequency is being obtained with read operation executed in async mode (later based on this frequency, code calculates sync timings then set to sync mode) I don't follow frequency is being obtained with read operation executed in async mode. Can you give a code reference? In the present code, for sync mode, omap2_onenand_set_sync_mode() invokes omap2_onenand_set_async_mode() initially, to set onenand gpmc to async mode, then invokes omap2_onenand_get_freq() to get frequency, here finding out frequency from onenand is done by reading relevant onenand register in async mode. Regards Afzal -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] OMAP2+ devices add mac address allocation register api
On Sunday 01 July 2012, Tony Lindgren wrote: 2. Pass the Panda mac information as platform data to this driver for now with a comment on the usb path naming being potentially wrong in the loadable modules case. IMHO code outside of the platform driver world would be more appropriate here. It's not actually a platform device because it's more of an abstract concept to define a mac address than physical hardware. Well we still need to also pass the mac address generated by the SoC specific kernel init code. It seems that platform data would be the obvious way to pass that. Or do you have some other way in mind for that? My point is that for platform data you need a platform device of some sort, but this new piece of infrastructure does not look like it should be a device. I think a reasonable interface would be something as simple as void register_eth_mac_fixup(const char *path, const u8 *mac); Instead of registering a device from the platform, we just call this function, and leave the code built-in. Arnd -- 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: v3.5-rc4 doesn't wake from dynamic idle on 3530ES3 Beagle
On Thursday 28 June 2012 11:45 AM, Shilimkar, Santosh wrote: + Shubro, Felipe, On Thu, Jun 28, 2012 at 12:57 AM, Paul Walmsley p...@pwsan.com wrote: On Wed, 27 Jun 2012, Paul Walmsley wrote: Looks like something broke between v3.5-rc3 and v3.5-rc4 with dynamic idle on 3530ES3 Beagle. 37xx EVM doesn't seem to be affected. Taking a closer look now. Reverting commit 91930652a23de0873a157aa1d9962cb878d64451 (OMAP2+: UART: Add mechanism to probe uart pins and configure rx wakeup) makes wakeup from dynamic retention idle work again. I suspected this. This could be because, all the board are now expected to setup the pin configurations. I do not have access to a 3530 Beagle Just tried on 3630 beagle that seems to be fine. let me see if I can reproduce in other onap3 boards that I have. Hi Paul, On my beaglexm 3630 This is with the following steps: 1. merge your 32k timer fix branch 2. disable USB host: set CONFIG_MFD_OMAP_USB_HOST=n Let me know if I missed anything. # echo 3000 /sys/devices/platform/omap_uart.0/power/autosuspend_delay_ms # echo 3000 /sys/devices/platform/omap_uart.1/power/autosuspend_delay_ms # echo 3000 /sys/devices/platform/omap_uart.2/power/autosuspend_delay_ms # # mount -t debugfs debugfs /debug/ # cat /debug/pm_debug/count | grep per_pwrdm per_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 per_clkdm-per_pwrdm (17) # echo 1 /debug/pm_debug/enable_off_mode # echo enabled /sys/devices/platform/omap_uart.2/tty/ttyO2/power/wakeup # echo mem /sys/power/state [ 12.404083] PM: Syncing filesystems ... done. [ 12.426055] Freezing user space processes ... (elapsed 0.01 seconds) done. [ 12.452728] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done. [ 12.483795] Suspending console(s) (use no_console_suspend to debug) [ 12.609039] PM: suspend of devices complete after 115.564 msecs [ 12.611511] PM: late suspend of devices complete after 2.471 msecs [ 12.615966] PM: noirq suspend of devices complete after 4.424 msecs [ 12.616027] Disabling non-boot CPUs ... [ 13.203704] Successfully put all powerdomains to target state [ 13.206115] PM: noirq resume of devices complete after 2.135 msecs [ 13.209228] PM: early resume of devices complete after 1.708 msecs [ 13.585815] PM: resume of devices complete after 376.464 msecs [ 13.637603] Restarting tasks ... done. # # cat /debug/pm_debug/count | grep per_pwrdm per_pwrdm (ON),OFF:1,RET:0,INA:0,ON:2,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 per_clkdm-per_pwrdm (17) # 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 v2 3/3] ARM: omap: clk: Remove all direct dereferencing of struct clk
In the case of the quoted string warnings, please go ahead and
concatenate those strings while you are there. That needs to be done
anyway.
Ok, will do. I was able to fix all but one hard to fix CHECK for this
patch..
---
CHECK: Alignment should match open parenthesis
#608: FILE: arch/arm/mach-omap2/dpll3xxx.c:455:
+ if (__clk_get_rate(dd-clk_bypass) == rate
(clk-dpll_data-modes (1 DPLL_LOW_POWER_BYPASS))) {
total: 0 errors, 0 warnings, 1 checks, 608 lines checked
0003-ARM-omap-clk-Remove-all-direct-dereferencing-of-stru.patch has
style problems, please review.
If any of these errors are false positives, please report
---
I could not find anything wrong with the alignment, but checkpatch
keeps complaining. It complains for the original code too.
Might be a checkpatch bug? Or do you really see anything wrong in
the alignment?
Does seem like a checkpatch issue to me, checkpatch -f on the file
after applying the patch does not throw me the 'CHECK' anymore.
Will ignore this for now and respin my v3 and report this to the
checkpatch folks.
--
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 v3 0/3] Prepare for OMAP2+ movement to Common Clk
Changes in v3: * Fixed various checkpatch warning/errors as reported by Paul W. Changes in v2: * Dropped all driver clk_prepare/clk_unprepare changes, will be sent seperately to respective lists This is a preparatory series for the OMAP Common Clk conversion. They mostly add clk_prepare/clk_unprepare in OMAP platform code. Also gets rid of omap_clk_get_by_name and uses clk_get, and removes all direct 'struct clk' dereferrencing and uses helpers similar to what is provided by Common Clk. Patches are boot tested on OMAP2430sdp, 3630 Beagle-Xm and 4430/4460 Panda and suspend tested on 3630 Beagle-Xm and 4430 Panda. Patches apply on 3.5-rc5. Rajendra Nayak (3): ARM: omap: clk: add clk_prepare and clk_unprepare ARM: omap: hwmod: get rid of all omap_clk_get_by_name usage ARM: omap: clk: Remove all direct dereferencing of struct clk arch/arm/mach-omap2/board-apollon.c |4 +- arch/arm/mach-omap2/board-h4.c |6 +- arch/arm/mach-omap2/board-omap4panda.c |2 +- arch/arm/mach-omap2/clkt2xxx_apll.c |2 +- arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c |4 +- arch/arm/mach-omap2/clkt34xx_dpll3m2.c | 20 +++--- arch/arm/mach-omap2/clkt_clksel.c| 89 - arch/arm/mach-omap2/clkt_dpll.c | 26 --- arch/arm/mach-omap2/clock.c | 11 ++- arch/arm/mach-omap2/clock2420_data.c | 17 + arch/arm/mach-omap2/clock2430_data.c | 21 ++ arch/arm/mach-omap2/clock3xxx.c |8 +- arch/arm/mach-omap2/clock3xxx_data.c | 24 +++ arch/arm/mach-omap2/clock44xx_data.c | 17 + arch/arm/mach-omap2/display.c|4 +- arch/arm/mach-omap2/dpll3xxx.c | 45 -- arch/arm/mach-omap2/gpmc.c |2 +- arch/arm/mach-omap2/omap_hwmod.c | 21 --- arch/arm/mach-omap2/pm.c |2 +- arch/arm/mach-omap2/pm24xx.c |2 + arch/arm/mach-omap2/usb-fs.c |4 +- arch/arm/plat-omap/include/plat/clock.h |4 + arch/arm/plat-omap/omap_device.c |6 +- 23 files changed, 235 insertions(+), 106 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
[PATCH v3 3/3] ARM: omap: clk: Remove all direct dereferencing of struct clk
While we move to Common Clk Framework (CCF), direct deferencing of struct
clk wouldn't be possible anymore. Hence get rid of all such instances
in the current clock code and use macros/helpers similar to the ones that
are provided by CCF.
While here also concatenate some strings split across multiple lines
which seem to be needed anyway.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/clkt2xxx_apll.c |2 +-
arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c |4 +-
arch/arm/mach-omap2/clkt34xx_dpll3m2.c | 20 +++---
arch/arm/mach-omap2/clkt_clksel.c| 89 -
arch/arm/mach-omap2/clkt_dpll.c | 26 ---
arch/arm/mach-omap2/clock.c | 11 ++-
arch/arm/mach-omap2/dpll3xxx.c | 45 --
arch/arm/mach-omap2/omap_hwmod.c |6 +-
arch/arm/mach-omap2/pm.c |2 +-
arch/arm/plat-omap/include/plat/clock.h |4 +
10 files changed, 127 insertions(+), 82 deletions(-)
diff --git a/arch/arm/mach-omap2/clkt2xxx_apll.c
b/arch/arm/mach-omap2/clkt2xxx_apll.c
index b19a1f7..c2d1521 100644
--- a/arch/arm/mach-omap2/clkt2xxx_apll.c
+++ b/arch/arm/mach-omap2/clkt2xxx_apll.c
@@ -59,7 +59,7 @@ static int omap2_clk_apll_enable(struct clk *clk, u32
status_mask)
omap2_cm_write_mod_reg(cval, PLL_MOD, CM_CLKEN);
omap2_cm_wait_idlest(cm_idlest_pll, status_mask,
-OMAP24XX_CM_IDLEST_VAL, clk-name);
+OMAP24XX_CM_IDLEST_VAL, __clk_get_name(clk));
/*
* REVISIT: Should we return an error code if omap2_wait_clock_ready()
diff --git a/arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c
b/arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c
index 3d9d746..3a27426 100644
--- a/arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c
+++ b/arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c
@@ -75,7 +75,7 @@ long omap2_round_to_table_rate(struct clk *clk, unsigned long
rate)
for (ptr = rate_table; ptr-mpu_speed; ptr++) {
if (!(ptr-flags cpu_mask))
continue;
- if (ptr-xtal_speed != sclk-rate)
+ if (ptr-xtal_speed != __clk_get_rate(sclk))
continue;
highest_rate = ptr-mpu_speed;
@@ -99,7 +99,7 @@ int omap2_select_table_rate(struct clk *clk, unsigned long
rate)
if (!(prcm-flags cpu_mask))
continue;
- if (prcm-xtal_speed != sclk-rate)
+ if (prcm-xtal_speed != __clk_get_rate(sclk))
continue;
if (prcm-mpu_speed = rate) {
diff --git a/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
b/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
index d6e34dd..0fd8b70 100644
--- a/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
+++ b/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
@@ -56,6 +56,7 @@ int omap3_core_dpll_m2_set_rate(struct clk *clk, unsigned
long rate)
struct omap_sdrc_params *sdrc_cs0;
struct omap_sdrc_params *sdrc_cs1;
int ret;
+ unsigned long clkrate;
if (!clk || !rate)
return -EINVAL;
@@ -64,11 +65,12 @@ int omap3_core_dpll_m2_set_rate(struct clk *clk, unsigned
long rate)
if (validrate != rate)
return -EINVAL;
- sdrcrate = sdrc_ick_p-rate;
- if (rate clk-rate)
- sdrcrate = ((rate / clk-rate) 1);
+ sdrcrate = __clk_get_rate(sdrc_ick_p);
+ clkrate = __clk_get_rate(clk);
+ if (rate clkrate)
+ sdrcrate = ((rate / clkrate) 1);
else
- sdrcrate = ((clk-rate / rate) 1);
+ sdrcrate = ((clkrate / rate) 1);
ret = omap2_sdrc_get_params(sdrcrate, sdrc_cs0, sdrc_cs1);
if (ret)
@@ -82,7 +84,7 @@ int omap3_core_dpll_m2_set_rate(struct clk *clk, unsigned
long rate)
/*
* XXX This only needs to be done when the CPU frequency changes
*/
- _mpurate = arm_fck_p-rate / CYCLES_PER_MHZ;
+ _mpurate = __clk_get_rate(arm_fck_p) / CYCLES_PER_MHZ;
c = (_mpurate SDRC_MPURATE_SCALE) SDRC_MPURATE_BASE_SHIFT;
c += 1; /* for safety */
c *= SDRC_MPURATE_LOOPS;
@@ -90,8 +92,8 @@ int omap3_core_dpll_m2_set_rate(struct clk *clk, unsigned
long rate)
if (c == 0)
c = 1;
- pr_debug(clock: changing CORE DPLL rate from %lu to %lu\n, clk-rate,
-validrate);
+ pr_debug(clock: changing CORE DPLL rate from %lu to %lu\n,
+clkrate, validrate);
pr_debug(clock: SDRC CS0 timing params used:
RFR %08x CTRLA %08x CTRLB %08x MR %08x\n,
sdrc_cs0-rfr_ctrl, sdrc_cs0-actim_ctrla,
@@ -104,14 +106,14 @@ int omap3_core_dpll_m2_set_rate(struct clk *clk, unsigned
long rate)
if (sdrc_cs1)
omap3_configure_core_dpll(
- new_div, unlock_dll, c, rate
[PATCH v3 1/3] ARM: omap: clk: add clk_prepare and clk_unprepare
As part of Common Clk Framework (CCF) the clk_enable() operation was split into a clk_prepare() which could sleep, and a clk_enable() which should never sleep. Similarly the clk_disable() was split into clk_disable() and clk_unprepare(). This was needed to handle complex cases where in a clk gate/ungate would require a slow and a fast part to be implemented. None of the clocks below seem to be in the 'complex' clocks category and are just simple clocks which are enabled/disabled through simple register writes. Most of the instances also seem to be called in non-atomic context which means its safe to move all of those from using a clk_enable() to clk_prepare_enable() and clk_disable() to clk_disable_unprepare(). For a few others where there is a possibility they get called from an interrupt or atomic context, there is an additonal clk_prepare() done before a clk_enable() and a clk_unprepare() after a clk_disable(). This is in preparation of OMAP moving to CCF. Based on initial changes from Mike turquette. Signed-off-by: Rajendra Nayak rna...@ti.com --- arch/arm/mach-omap2/board-apollon.c|4 ++-- arch/arm/mach-omap2/board-h4.c |6 +++--- arch/arm/mach-omap2/board-omap4panda.c |2 +- arch/arm/mach-omap2/clock3xxx.c|8 arch/arm/mach-omap2/display.c |4 ++-- arch/arm/mach-omap2/gpmc.c |2 +- arch/arm/mach-omap2/omap_hwmod.c |3 +++ arch/arm/mach-omap2/pm24xx.c |2 ++ arch/arm/mach-omap2/usb-fs.c |4 ++-- 9 files changed, 20 insertions(+), 15 deletions(-) diff --git a/arch/arm/mach-omap2/board-apollon.c b/arch/arm/mach-omap2/board-apollon.c index 502c31e..1d8c693 100644 --- a/arch/arm/mach-omap2/board-apollon.c +++ b/arch/arm/mach-omap2/board-apollon.c @@ -205,7 +205,7 @@ static inline void __init apollon_init_smc91x(void) return; } - clk_enable(gpmc_fck); + clk_prepare_enable(gpmc_fck); rate = clk_get_rate(gpmc_fck); eth_cs = APOLLON_ETH_CS; @@ -249,7 +249,7 @@ static inline void __init apollon_init_smc91x(void) gpmc_cs_free(APOLLON_ETH_CS); } out: - clk_disable(gpmc_fck); + clk_disable_unprepare(gpmc_fck); clk_put(gpmc_fck); } diff --git a/arch/arm/mach-omap2/board-h4.c b/arch/arm/mach-omap2/board-h4.c index 876becf..a273af0 100644 --- a/arch/arm/mach-omap2/board-h4.c +++ b/arch/arm/mach-omap2/board-h4.c @@ -267,9 +267,9 @@ static inline void __init h4_init_debug(void) return; } - clk_enable(gpmc_fck); + clk_prepare_enable(gpmc_fck); rate = clk_get_rate(gpmc_fck); - clk_disable(gpmc_fck); + clk_disable_unprepare(gpmc_fck); clk_put(gpmc_fck); if (is_gpmc_muxed()) @@ -313,7 +313,7 @@ static inline void __init h4_init_debug(void) gpmc_cs_free(eth_cs); out: - clk_disable(gpmc_fck); + clk_disable_unprepare(gpmc_fck); clk_put(gpmc_fck); } diff --git a/arch/arm/mach-omap2/board-omap4panda.c b/arch/arm/mach-omap2/board-omap4panda.c index 982fb26..f0ea558 100644 --- a/arch/arm/mach-omap2/board-omap4panda.c +++ b/arch/arm/mach-omap2/board-omap4panda.c @@ -172,7 +172,7 @@ static void __init omap4_ehci_init(void) return; } clk_set_rate(phy_ref_clk, 1920); - clk_enable(phy_ref_clk); + clk_prepare_enable(phy_ref_clk); /* disable the power to the usb hub prior to init and reset phy+hub */ ret = gpio_request_array(panda_ehci_gpios, diff --git a/arch/arm/mach-omap2/clock3xxx.c b/arch/arm/mach-omap2/clock3xxx.c index 794d827..4c1591a 100644 --- a/arch/arm/mach-omap2/clock3xxx.c +++ b/arch/arm/mach-omap2/clock3xxx.c @@ -64,15 +64,15 @@ void __init omap3_clk_lock_dpll5(void) dpll5_clk = clk_get(NULL, dpll5_ck); clk_set_rate(dpll5_clk, DPLL5_FREQ_FOR_USBHOST); - clk_enable(dpll5_clk); + clk_prepare_enable(dpll5_clk); /* Program dpll5_m2_clk divider for no division */ dpll5_m2_clk = clk_get(NULL, dpll5_m2_ck); - clk_enable(dpll5_m2_clk); + clk_prepare_enable(dpll5_m2_clk); clk_set_rate(dpll5_m2_clk, DPLL5_FREQ_FOR_USBHOST); - clk_disable(dpll5_m2_clk); - clk_disable(dpll5_clk); + clk_disable_unprepare(dpll5_m2_clk); + clk_disable_unprepare(dpll5_clk); return; } diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c index 5fb47a1..e5f8e48 100644 --- a/arch/arm/mach-omap2/display.c +++ b/arch/arm/mach-omap2/display.c @@ -471,7 +471,7 @@ int omap_dss_reset(struct omap_hwmod *oh) for (i = oh-opt_clks_cnt, oc = oh-opt_clks; i 0; i--, oc++) if (oc-_clk) - clk_enable(oc-_clk); + clk_prepare_enable(oc-_clk); dispc_disable_outputs(); @@ -498,7 +498,7 @@ int omap_dss_reset(struct omap_hwmod *oh) for (i = oh-opt_clks_cnt, oc =
[PATCH v3 2/3] ARM: omap: hwmod: get rid of all omap_clk_get_by_name usage
Moving to Common clk framework for OMAP would mean we no longer use
internal lookup mechanism like omap_clk_get_by_name().
get rid of all its usage mostly from hwmod and omap_device
code.
Also use IS_ERR_OR_NULL() for error checking.
Moving to clk_get() also means the respective platforms
need the clkdev tables updated with an entry for all clocks
used by hwmod to have clock name same as the alias.
Based on original changes from Mike Turquette.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/clock2420_data.c | 17 +
arch/arm/mach-omap2/clock2430_data.c | 21 +
arch/arm/mach-omap2/clock3xxx_data.c | 24
arch/arm/mach-omap2/clock44xx_data.c | 17 +
arch/arm/mach-omap2/omap_hwmod.c | 12 ++--
arch/arm/plat-omap/omap_device.c |6 +++---
6 files changed, 88 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/clock2420_data.c
b/arch/arm/mach-omap2/clock2420_data.c
index bace930..b3a659b 100644
--- a/arch/arm/mach-omap2/clock2420_data.c
+++ b/arch/arm/mach-omap2/clock2420_data.c
@@ -1808,6 +1808,7 @@ static struct omap_clk omap2420_clks[] = {
CLK(NULL, gfx_ick, gfx_ick, CK_242X),
/* DSS domain clocks */
CLK(omapdss_dss, ick, dss_ick, CK_242X),
+ CLK(NULL, dss_ick, dss_ick, CK_242X),
CLK(NULL, dss1_fck, dss1_fck, CK_242X),
CLK(NULL, dss2_fck, dss2_fck, CK_242X),
CLK(NULL, dss_54m_fck, dss_54m_fck, CK_242X),
@@ -1847,12 +1848,16 @@ static struct omap_clk omap2420_clks[] = {
CLK(NULL, gpt12_ick,gpt12_ick, CK_242X),
CLK(NULL, gpt12_fck,gpt12_fck, CK_242X),
CLK(omap-mcbsp.1, ick, mcbsp1_ick,CK_242X),
+ CLK(NULL, mcbsp1_ick, mcbsp1_ick,CK_242X),
CLK(NULL, mcbsp1_fck, mcbsp1_fck,CK_242X),
CLK(omap-mcbsp.2, ick, mcbsp2_ick,CK_242X),
+ CLK(NULL, mcbsp2_ick, mcbsp2_ick,CK_242X),
CLK(NULL, mcbsp2_fck, mcbsp2_fck,CK_242X),
CLK(omap2_mcspi.1, ick, mcspi1_ick,CK_242X),
+ CLK(NULL, mcspi1_ick, mcspi1_ick,CK_242X),
CLK(NULL, mcspi1_fck, mcspi1_fck,CK_242X),
CLK(omap2_mcspi.2, ick, mcspi2_ick,CK_242X),
+ CLK(NULL, mcspi2_ick, mcspi2_ick,CK_242X),
CLK(NULL, mcspi2_fck, mcspi2_fck,CK_242X),
CLK(NULL, uart1_ick,uart1_ick, CK_242X),
CLK(NULL, uart1_fck,uart1_fck, CK_242X),
@@ -1863,12 +1868,15 @@ static struct omap_clk omap2420_clks[] = {
CLK(NULL, gpios_ick,gpios_ick, CK_242X),
CLK(NULL, gpios_fck,gpios_fck, CK_242X),
CLK(omap_wdt, ick, mpu_wdt_ick, CK_242X),
+ CLK(NULL, mpu_wdt_ick, mpu_wdt_ick, CK_242X),
CLK(NULL, mpu_wdt_fck, mpu_wdt_fck, CK_242X),
CLK(NULL, sync_32k_ick, sync_32k_ick, CK_242X),
CLK(NULL, wdt1_ick, wdt1_ick, CK_242X),
CLK(NULL, omapctrl_ick, omapctrl_ick, CK_242X),
CLK(omap24xxcam, fck, cam_fck, CK_242X),
+ CLK(NULL, cam_fck, cam_fck, CK_242X),
CLK(omap24xxcam, ick, cam_ick, CK_242X),
+ CLK(NULL, cam_ick, cam_ick, CK_242X),
CLK(NULL, mailboxes_ick, mailboxes_ick,CK_242X),
CLK(NULL, wdt4_ick, wdt4_ick, CK_242X),
CLK(NULL, wdt4_fck, wdt4_fck, CK_242X),
@@ -1877,16 +1885,22 @@ static struct omap_clk omap2420_clks[] = {
CLK(NULL, mspro_ick,mspro_ick, CK_242X),
CLK(NULL, mspro_fck,mspro_fck, CK_242X),
CLK(mmci-omap.0, ick, mmc_ick, CK_242X),
+ CLK(NULL, mmc_ick, mmc_ick, CK_242X),
CLK(mmci-omap.0, fck, mmc_fck, CK_242X),
+ CLK(NULL, mmc_fck, mmc_fck, CK_242X),
CLK(NULL, fac_ick, fac_ick, CK_242X),
CLK(NULL, fac_fck, fac_fck, CK_242X),
CLK(NULL, eac_ick, eac_ick, CK_242X),
CLK(NULL, eac_fck, eac_fck, CK_242X),
CLK(omap_hdq.0, ick,hdq_ick, CK_242X),
+ CLK(NULL, hdq_ick, hdq_ick, CK_242X),
CLK(omap_hdq.0, fck,hdq_fck, CK_242X),
+ CLK(NULL, hdq_fck, hdq_fck, CK_242X),
CLK(omap_i2c.1, ick,i2c1_ick, CK_242X),
+ CLK(NULL, i2c1_ick, i2c1_ick, CK_242X),
CLK(NULL, i2c1_fck, i2c1_fck, CK_242X),
CLK(omap_i2c.2, ick,i2c2_ick, CK_242X),
+ CLK(NULL, i2c2_ick, i2c2_ick, CK_242X),
CLK(NULL,
Re: [PATCH 2/3] OMAP2+ devices add mac address allocation register api
* Arnd Bergmann a...@arndb.de [120702 03:24]: On Sunday 01 July 2012, Tony Lindgren wrote: 2. Pass the Panda mac information as platform data to this driver for now with a comment on the usb path naming being potentially wrong in the loadable modules case. IMHO code outside of the platform driver world would be more appropriate here. It's not actually a platform device because it's more of an abstract concept to define a mac address than physical hardware. Well we still need to also pass the mac address generated by the SoC specific kernel init code. It seems that platform data would be the obvious way to pass that. Or do you have some other way in mind for that? My point is that for platform data you need a platform device of some sort, but this new piece of infrastructure does not look like it should be a device. OK I think a reasonable interface would be something as simple as void register_eth_mac_fixup(const char *path, const u8 *mac); Instead of registering a device from the platform, we just call this function, and leave the code built-in. Sounds good to me. 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 07/29] mfd: omap-usb: use clk_prepare_enable and clk_disable_unprepare
Hi Rajendra, On Thu, Jun 14, 2012 at 06:16:56PM +0530, Rajendra Nayak wrote: As we move to Common clk framework use clk_prepare_enable() instead of clk_enable() and similarly clk_disable_unprepare() instead of clk_disable() Signed-off-by: Rajendra Nayak rna...@ti.com Cc: Samuel Ortiz sa...@linux.intel.com --- drivers/mfd/omap-usb-host.c | 28 ++-- 1 files changed, 14 insertions(+), 14 deletions(-) Patch applied, many thanks. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset fix issues.
Hi Russ, On Thu, Jun 14, 2012 at 09:24:21AM -0700, Russ Dill wrote: From: Russ Dill russ.d...@gmail.com 'ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue' (1fcb57d0) fixes an issue where the ULPI PHYs were not held in reset while initializing the EHCI controller. However, it also changes behavior in omap-usb-host.c omap_usbhs_init by releasing reset while the configuration in that function was done. This change caused a regression on BB-xM where USB would not function if 'usb start' had been run from u-boot before booting. A change was made to release reset a little bit earlier which fixed the issue on BB-xM and did not cause any regressions on 3430 sdp, the board for which the fix was originally made. This new fix, 'USB: EHCI: OMAP: Finish ehci omap phy reset cycle before adding hcd.', (3aa2ae74) caused a regression on OMAP5. The original fix to hold the EHCI controller in reset during initialization was correct, however it appears that changing omap_usbhs_init to not hold the PHYs in reset during it's configuration was incorrect. This patch first reverts both fixes, and then changes ehci_hcd_omap_probe in ehci-omap.c to hold the PHYs in reset as the original patch had done. It also is sure to incorporate the _cansleep change that has been made in the meantime. I've tested this on Beagleboard xM, I'd really like to get an ack from the 3430 sdp and OMAP5 guys before getting this merged. v3 - Brown paper bag its too early in the morning actually run git commit amend fix v2 - Put cansleep gpiolib call outside of spinlock Signed-off-by: Russ Dill russ.d...@gmail.com --- drivers/mfd/omap-usb-host.c | 48 +- drivers/usb/host/ehci-omap.c | 18 +++- 2 files changed, 55 insertions(+), 11 deletions(-) I applied this one to my for-linus branch, it will be part of my next 3.5 pull request to Linus. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- 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 07/29] mfd: omap-usb: use clk_prepare_enable and clk_disable_unprepare
Hi Samuel, On Monday 02 July 2012 04:48 PM, Samuel Ortiz wrote: Hi Rajendra, On Thu, Jun 14, 2012 at 06:16:56PM +0530, Rajendra Nayak wrote: As we move to Common clk framework use clk_prepare_enable() instead of clk_enable() and similarly clk_disable_unprepare() instead of clk_disable() Signed-off-by: Rajendra Nayakrna...@ti.com Cc: Samuel Ortizsa...@linux.intel.com --- drivers/mfd/omap-usb-host.c | 28 ++-- 1 files changed, 14 insertions(+), 14 deletions(-) Patch applied, many thanks. Sorry, I was asked to base these changes on top of work done by Keshava [1], to split the driver, which is still under review/not pulled. I am waiting for those to settle to repost these changes. Can you please drop this one for now? Sorry for the confusion. regards, Rajendra [1] http://permalink.gmane.org/gmane.linux.ports.arm.omap/79306 Cheers, Samuel. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset fix issues.
On Mon, Jul 2, 2012 at 4:52 PM, Samuel Ortiz sa...@linux.intel.com wrote: Hi Russ, On Thu, Jun 14, 2012 at 09:24:21AM -0700, Russ Dill wrote: From: Russ Dill russ.d...@gmail.com 'ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue' (1fcb57d0) fixes an issue where the ULPI PHYs were not held in reset while initializing the EHCI controller. However, it also changes behavior in omap-usb-host.c omap_usbhs_init by releasing reset while the configuration in that function was done. This change caused a regression on BB-xM where USB would not function if 'usb start' had been run from u-boot before booting. A change was made to release reset a little bit earlier which fixed the issue on BB-xM and did not cause any regressions on 3430 sdp, the board for which the fix was originally made. This new fix, 'USB: EHCI: OMAP: Finish ehci omap phy reset cycle before adding hcd.', (3aa2ae74) caused a regression on OMAP5. The original fix to hold the EHCI controller in reset during initialization was correct, however it appears that changing omap_usbhs_init to not hold the PHYs in reset during it's configuration was incorrect. This patch first reverts both fixes, and then changes ehci_hcd_omap_probe in ehci-omap.c to hold the PHYs in reset as the original patch had done. It also is sure to incorporate the _cansleep change that has been made in the meantime. I've tested this on Beagleboard xM, I'd really like to get an ack from the 3430 sdp and OMAP5 guys before getting this merged. v3 - Brown paper bag its too early in the morning actually run git commit amend fix v2 - Put cansleep gpiolib call outside of spinlock Signed-off-by: Russ Dill russ.d...@gmail.com --- drivers/mfd/omap-usb-host.c | 48 +- drivers/usb/host/ehci-omap.c | 18 +++- 2 files changed, 55 insertions(+), 11 deletions(-) I applied this one to my for-linus branch, it will be part of my next 3.5 pull request to Linus. Cheers, Samuel. Hi Samuel please drop this patch for now , since Alan stern has mentioned improvements for this patch and we need to wait for Alan's new patch on ehci-omap.c and then Rus dill patch and my usbhs tll patch series need to be rebased. regards keshava -- 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 05/17] i2c: omap: split out [XR]DR and [XR]RDY
On Tue, Jun 26, 2012 at 04:11:30PM +0530, Shubhrajyoti wrote:
Hi Felipe,
On Thursday 14 June 2012 09:54 PM, Felipe Balbi wrote:
return IRQ_HANDLED;
}
- if (stat (OMAP_I2C_STAT_RRDY | OMAP_I2C_STAT_RDR)) {
+ if (stat OMAP_I2C_STAT_RDR) {
u8 num_bytes = 1;
+ if (dev-fifo_size)
+ num_bytes = dev-fifo_size;
In case of a draining interrupt. The byte count may not be the fifo size.
Do you agree?
hmm... indeed, that should be dev-buf_len... can you fix that up or
want me to resend ?
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v2 00/17] Big OMAP I2C Cleanup
Hi, On Tue, Jun 26, 2012 at 04:21:30PM +0530, Shubhrajyoti wrote: On Thursday 14 June 2012 11:29 PM, Wolfram Sang wrote: - removed dev_err() which was introduced on patch 09/17 To prevent the list being flooded, I would appreciate if you could wait a few days to collect reviews before resending. It will take some time until I pick this series anyhow, because I want people to have time to donate Tested-by tags. Felipe thats a good cleanup. The series look good to me. Also draining interrupt I had some queries. Looks good to me. I have tested it after rebasing. rebasing on top of what ? You should resend the series so that I know what changes you have made to my original patchset. Make sure to list on the commit log what where the changes you made, so that it looks something like this commit below where I changed commit log a bit: | commit 3daf74d78dfcd552445c35f1b82a271ca305ceb9 | Author: Pratyush Anand pratyush.an...@st.com | Date: Sat Jun 23 02:23:08 2012 +0530 | | usb: dwc3: remove WARN_ON from dwc_stop_active_transfer | | Now we are sure that, if res_trans_idx is zero, then endpoint has been | stopped. So it's safe to just return if endpoint is already stopped. No | need to generate warning anymore. | | While doing so, it's better to return when res_trans_idx is zero and | decrease one level of indentation. | | Signed-off-by: Pratyush Anand pratyush.an...@st.com | | [ ba...@ti.com: slightly changed commit log ] | | Signed-off-by: Felipe Balbi ba...@ti.com Tested-by : Shubhrajyoti shubhrajy...@ti.com since you will send, you should, probably, add your Signed-off-by, instead of Tested-by. dunno. -- balbi signature.asc Description: Digital signature
Re: [PATCH v2 05/17] i2c: omap: split out [XR]DR and [XR]RDY
On Monday 02 July 2012 05:03 PM, Felipe Balbi wrote: + num_bytes = dev-fifo_size; In case of a draining interrupt. The byte count may not be the fifo size. Do you agree? hmm... indeed, that should be dev-buf_len... can you fix that up or want me to resend ? Nope I can fix that up. Thanks, -- 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 00/17] Big OMAP I2C Cleanup
On Monday 02 July 2012 05:07 PM, Felipe Balbi wrote: Hi, On Tue, Jun 26, 2012 at 04:21:30PM +0530, Shubhrajyoti wrote: On Thursday 14 June 2012 11:29 PM, Wolfram Sang wrote: - removed dev_err() which was introduced on patch 09/17 To prevent the list being flooded, I would appreciate if you could wait a few days to collect reviews before resending. It will take some time until I pick this series anyhow, because I want people to have time to donate Tested-by tags. Felipe thats a good cleanup. The series look good to me. Also draining interrupt I had some queries. Looks good to me. I have tested it after rebasing. rebasing on top of what ? On top of embedded i2c branch of Wolfram. You should resend the series so that I know what changes you have made to my original patchset. Make sure to list on the commit log what where the changes you made, so that it looks something like this commit below where I changed commit log a bit: Will do that. Thanks, | commit 3daf74d78dfcd552445c35f1b82a271ca305ceb9 | Author: Pratyush Anand pratyush.an...@st.com | Date: Sat Jun 23 02:23:08 2012 +0530 | | usb: dwc3: remove WARN_ON from dwc_stop_active_transfer | | Now we are sure that, if res_trans_idx is zero, then endpoint has been | stopped. So it's safe to just return if endpoint is already stopped. No | need to generate warning anymore. | | While doing so, it's better to return when res_trans_idx is zero and | decrease one level of indentation. | | Signed-off-by: Pratyush Anand pratyush.an...@st.com | | [ ba...@ti.com: slightly changed commit log ] | | Signed-off-by: Felipe Balbi ba...@ti.com Tested-by : Shubhrajyoti shubhrajy...@ti.com since you will send, you should, probably, add your Signed-off-by, instead of Tested-by. dunno. -- 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 3/3] i2c: inititalise the actual transferred to zero
Hi, On Fri, Jun 29, 2012 at 03:18:32PM +0200, Jean Delvare wrote: On Fri, 29 Jun 2012 18:42:08 +0530, Shubhrajyoti wrote: On Friday 29 June 2012 06:27 PM, Jean Delvare wrote: drivers/gpu/drm/nouveau/nouveau_bios.c:3535:3: warning: (near initialization for ‘msg[1].actual’) [enabled by default] This needs to be all fixed (converted to C99-style struct initialization) before your patch is considered for inclusion. And there may be more that my config did not spot. Yes,agree. The idea of this patch was if the idea is agreed upon then. then fixing all the callers could be worked on. This is worth fixing anyway, C99-style initialization is always good to move to. However do you agree with this approach? Well you've seen the caveats I mentioned, this will be no easy ride. If you are willing to take the risk, spend the time documenting the change, and help people if there are issues, then I'm OK. At least as long as someone else doesn't come saying it's a very bad idea ;) This approach is a hard-requirement for devices which will pose any interface/feedback with user. We have been working with a piezo driver from TI (drv2665) and it will be used (in most cases at least) to give the user a feedback based on e.g. touchscreen event. Imagine drv2665 responds with a NAK while we're in the middle of driving a wave through it (keep in mind a wave could take seconds to finish, depending on the usecase), if we don't have a way to tell users that we have writen X bytes, how should we make sure to continue driving the wave from the exact byte where we got a NAK ? If can't make sure that detail is true, then such usecases (as piezo drivers) will never work. Another approach would be to not add any field to struct i2c_msg but instead return either the amount of bytes transferred, or an error case. This would mean a series that would: 1) fix all users of struct i2c_master_send() and the like to check for errors as if (ret 0) instead of if (ret); 2) fix all i2c buses to return the amount of bytes written instead of zero or error case 3) fix Documentation to state that we're now returning the amount of bytes, instead of zero or errno. I'm not sure what will have minimum impact to userland, though. What do you say Jean ? What would you prefer ? -- balbi signature.asc Description: Digital signature
Re: [PATCHv3 06/17] i2c: omap: split out [XR]DR and [XR]RDY
Hi,
On Fri, Jun 29, 2012 at 03:43:26PM +0530, Shubhrajyoti D wrote:
From: Felipe Balbi ba...@ti.com
While they do pretty much the same thing, there
are a few peculiarities. Specially WRT erratas,
it's best to split those out and re-factor the
read/write loop to another function which both
cases call.
This last part will be done on another patch.
While at that, also avoid an unncessary register
read since dev-fifo_len will always contain the
correct amount of data to be transferred.
this statement isn't valid anymore, but I'd like it to be. See below
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 126 ++--
1 files changed, 94 insertions(+), 32 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 359ee08..45bd731 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -820,36 +820,64 @@ complete:
return IRQ_HANDLED;
}
- if (stat (OMAP_I2C_STAT_RRDY | OMAP_I2C_STAT_RDR)) {
+ if (stat OMAP_I2C_STAT_RDR) {
u8 num_bytes = 1;
+ if (dev-fifo_size)
+ num_bytes = (omap_i2c_read_reg(dev,
+ OMAP_I2C_BUFSTAT_REG) 8)
+ 0x3F;
I wanted to avoid reading registers if we don't have to. This value will
be sitting in dev-buf_len.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCHv3 06/17] i2c: omap: split out [XR]DR and [XR]RDY
On Mon, Jul 2, 2012 at 5:26 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Fri, Jun 29, 2012 at 03:43:26PM +0530, Shubhrajyoti D wrote:
From: Felipe Balbi ba...@ti.com
While they do pretty much the same thing, there
are a few peculiarities. Specially WRT erratas,
it's best to split those out and re-factor the
read/write loop to another function which both
cases call.
This last part will be done on another patch.
While at that, also avoid an unncessary register
read since dev-fifo_len will always contain the
correct amount of data to be transferred.
this statement isn't valid anymore, but I'd like it to be. See below
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 126
++--
1 files changed, 94 insertions(+), 32 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 359ee08..45bd731 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -820,36 +820,64 @@ complete:
return IRQ_HANDLED;
}
- if (stat (OMAP_I2C_STAT_RRDY | OMAP_I2C_STAT_RDR)) {
+ if (stat OMAP_I2C_STAT_RDR) {
u8 num_bytes = 1;
+ if (dev-fifo_size)
+ num_bytes = (omap_i2c_read_reg(dev,
+ OMAP_I2C_BUFSTAT_REG) 8)
+ 0x3F;
I wanted to avoid reading registers if we don't have to. This value will
be sitting in dev-buf_len.
Yes will fix this and resend.
--
balbi
--
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: [PATCHv3 17/17] i2c: omap: get rid of the complete label
Hi, On Fri, Jun 29, 2012 at 03:43:37PM +0530, Shubhrajyoti D wrote: @@ -962,7 +972,7 @@ complete: ret = omap_i2c_transmit_data(dev, num_bytes, true); stat = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG); this isn't needed anymore. please remove. if (ret 0) - goto complete; + goto out; omap_i2c_ack_stat(dev, OMAP_I2C_STAT_XDR); continue; @@ -978,7 +988,7 @@ complete: ret = omap_i2c_transmit_data(dev, num_bytes, false); stat = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG); this isn't needed anymore. please remove. -- balbi signature.asc Description: Digital signature
Re: [PATCH 0/2] ARM: OMAP: few more PM fixes for v3.5-rc
* Kevin Hilman khil...@ti.com [120628 10:06]: Tony, here are hopefully the last couple PM-related fixes for v3.5-rc. Both of these fix suspend/resume/wakeup problems on OMAP3 or OMAP4. Thanks applying into fixes. 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] remoteproc: block premature rproc booting
+ Sjur, Ludovic, Loic On Tue, Jun 5, 2012 at 1:57 PM, Ohad Ben-Cohen o...@wizery.com wrote: On Tue, Jun 5, 2012 at 12:23 AM, Stephen Boyd sb...@codeaurora.org wrote: I thought we wanted to allow both calls to proceed in parallel? If we don't care about that Yeah, I don't think we do. then announcing it once the firmware is found the first time sounds correct. I agree. Though this patch may be moot very soon due to: The main reason we kept the get/put interface was to make it easier for you guys to adopt it, but I've been re-thinking lately whether we really want that interface. It's a problematic interface with non-negligible maintenance burden, and the code will be greatly simplified without it. If nobody in the kernel is using it why keep it? I was concerned that the non get/put interface might not suit everyone, and I planned to wait for another user or two to show up before I remove that interface. Since MSM's PIL is based on a get/put interface, I actually hoped to see if you guys can adopt the new interface before we ditch the get/put one. If MSM needs we can add it back when we move to rproc. Thanks - that's the kind of feedback I wanted to get. Sjur, Ludovic, Loic - what remoteproc API are you using today? We'd like to get rid of the existing get/put interface and instead have everyone use the boot/shutdown one, just like rpmsg is doing today. Are you ok with this change? Thanks, Ohad. -- 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] OMAP4: Clock: Correct OTG clock to use otg_60m_gfclk.
On 06/29/2012 10:35 PM, Paul Walmsley wrote:
+ Benoît who is the maintainer of this file
+ the linux-arm-kernel mailing list, which should be cc'ed on all OMAP
patches
On Fri, 29 Jun 2012, Ruslan Bilovol wrote:
From: Wenbiao Wang ww...@ti.com
OTG clock usb_otg_hs_ick used a incorrect parent l3_div_ck.
Correct it to use the right colck otg_60m_gfclk as its
parent.
Mmm, that does not seems to be correct.
otg_60m_gfclk is an optional clock. The interface clock is the main
clock of that module. That's why this is the parent of the fake
MODULEMODE clock node.
Moreover you are changing as well the utmi_phy_clkout_ck. That's not
mentioned at all in the changelog.
I know that there are some non standard stuff in this clock scheme.
The main reason being the utmi_phy_clkout_ck source is generated from
the usb_phy module. Unfortunately the clock fmwk cannot handle module as
a clock node.
So, as of today, this only way to get the OTG_60M_FCLK clock available
is to ensure that the usb_phy module is enabled before the usb_otg_hs
module.
Regards,
Benoit
Signed-off-by: Wenbiao Wang ww...@ti.com
Signed-off-by: Ruslan Bilovol ruslan.bilo...@ti.com
---
arch/arm/mach-omap2/clock44xx_data.c | 15 ---
1 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index b825049..fd43214 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -199,12 +199,6 @@ static struct clk tie_low_clock_ck = {
.ops= clkops_null,
};
-static struct clk utmi_phy_clkout_ck = {
- .name = utmi_phy_clkout_ck,
- .rate = 6000,
- .ops= clkops_null,
-};
-
static struct clk xclk60mhsp1_ck = {
.name = xclk60mhsp1_ck,
.rate = 6000,
@@ -992,6 +986,13 @@ static struct clk dpll_usb_clkdcoldo_ck = {
.recalc = followparent_recalc,
};
+static struct clk utmi_phy_clkout_ck = {
+ .name = utmi_phy_clkout_ck,
+ .ops= clkops_null,
+ .parent = dpll_usb_clkdcoldo_ck,
+ .recalc = followparent_recalc,
+};
+
static const struct clksel dpll_usb_m2_div[] = {
{ .parent = dpll_usb_ck, .rates = div31_1to31_rates },
{ .parent = NULL },
@@ -2685,7 +2686,7 @@ static struct clk usb_otg_hs_ick = {
.enable_reg = OMAP4430_CM_L3INIT_USB_OTG_CLKCTRL,
.enable_bit = OMAP4430_MODULEMODE_HWCTRL,
.clkdm_name = l3_init_clkdm,
- .parent = l3_div_ck,
+ .parent = otg_60m_gfclk,
.recalc = followparent_recalc,
};
Benoît should have a look at this one, I think.
- 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: Current state of AM33xx patches
Am 29.06.2012 19:43, schrieb Hiremath, Vaibhav: On Fri, Jun 29, 2012 at 19:24:04, Yegor Yefremov wrote: Am 28.06.2012 17:09, schrieb Daniel Mack: On 27.06.2012 14:13, Hiremath, Vaibhav wrote: Just to clarify from AM335x perspective, In case of AM335x, since the patches and complete BasePort support is still not present in the Mainline (neither in Linus's tree not in linux-omap), you need to use my Repo (https://github.com/hvaibhav: Closely follows linux- omap/master) in order to test something on BeagleBone platform. Great, that is the information I've been looking for. Your am335x-upstream-staging branch works for me on a custom AM335x based board using a custom DT config. I'll dig through the sources and come back once I know which parts are missing. Do you have LCD screen attached? I need a functioning framebuffer driver. So far if I start x-server I get various errors: (EE) FBDEV(0): internal error: miCreateDefColormap failed in FBDevScreenInit() Did you get a chance to dig on this? Do you have further level of details from driver perspective? Which IOCTL is failing here? What is return value? Sorry for the noise. The driver is working now. It was a software issue introduced by the latest Buildroot version. But the FB_BLANK patch is still valid, it removes nasty warnings. Best regards, Yegor -- 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 v4 4/4] memory: emif: add device tree support to emif driver
On Sat, Jun 30, 2012 at 10:12 AM, Shilimkar, Santosh
santosh.shilim...@ti.com wrote:
On Sat, Jun 30, 2012 at 9:53 AM, Greg KH gre...@linuxfoundation.org wrote:
On Sat, Jun 30, 2012 at 09:38:41AM +0530, Shilimkar, Santosh wrote:
(+ Greg, By mistake the your name got dropped cc from list)
On Fri, Jun 29, 2012 at 7:13 PM, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
From: Aneesh V ane...@ti.com
Device tree support for the EMIF driver.
Reviewed-by: Benoit Cousson b-cous...@ti.com
Reviewed-by: Grant Likely grant.lik...@secretlab.ca
Tested-by: Lokesh Vutla lokeshvu...@ti.com
Signed-off-by: Aneesh V ane...@ti.com
[santosh.shilim...@ti.com: Rebased against 3.5-rc]
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
drivers/memory/emif.c | 291
-
1 file changed, 290 insertions(+), 1 deletion(-)
Wouldn't this just be better off as a separate file that only gets build
if CONFIG_OF is set, as I'm sure that other systems are going to want
access to these read the device tree values functions, right?
Probably yes. At least separate the LPDDR2 memory
generic parameter DT read code. There are parameters like phy
type which is specific to OMAP controllers so that still need to kept
inside EMIF driver. So there in driver, few lines of code will be there
under CONFIG_OF.
I can extract those functions which can be commonly used and put them
in another file under drivers/memory/
Is that fine with you ?
To elaborate more, I have created below patch.
Let me know what do you think ?
--
From 42abb2b29136efb9983abdd203fe1e6bce784715 Mon Sep 17 00:00:00 2001
From: Aneesh V ane...@ti.com
Date: Mon, 30 Jan 2012 20:06:30 +0530
Subject: [PATCH] memory: emif: add device tree support to emif driver
Device tree support for the EMIF driver. LPDDR2 generic timings
extraction from device is managed using couple of helper
functions which can be used by other memory controller
drivers.
Reviewed-by: Benoit Cousson b-cous...@ti.com
Reviewed-by: Grant Likely grant.lik...@secretlab.ca
Tested-by: Lokesh Vutla lokeshvu...@ti.com
Signed-off-by: Aneesh V ane...@ti.com
[santosh.shilim...@ti.com: Rebased against 3.5-rc]
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
---
From last version, the only change is to the lpddr2 dt timings generic
functions moved to separate file(of_memory.c) and build it only for
CONFIG_OF.
drivers/memory/Makefile|1 +
drivers/memory/emif.c | 182 +++-
drivers/memory/of_memory.c | 153 +
drivers/memory/of_memory.h | 36 +
4 files changed, 371 insertions(+), 1 deletions(-)
create mode 100644 drivers/memory/of_memory.c
create mode 100644 drivers/memory/of_memory.h
diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile
index 42b3ce9..cd8486b 100644
--- a/drivers/memory/Makefile
+++ b/drivers/memory/Makefile
@@ -2,6 +2,7 @@
# Makefile for memory devices
#
+obj-$(CONFIG_OF) += of_memory.o
obj-$(CONFIG_TI_EMIF) += emif.o
obj-$(CONFIG_TEGRA20_MC) += tegra20-mc.o
obj-$(CONFIG_TEGRA30_MC) += tegra30-mc.o
diff --git a/drivers/memory/emif.c b/drivers/memory/emif.c
index 33a4396..06b4eb7 100644
--- a/drivers/memory/emif.c
+++ b/drivers/memory/emif.c
@@ -18,6 +18,7 @@
#include linux/platform_device.h
#include linux/interrupt.h
#include linux/slab.h
+#include linux/of.h
#include linux/debugfs.h
#include linux/seq_file.h
#include linux/module.h
@@ -25,6 +26,7 @@
#include linux/spinlock.h
#include memory/jedec_ddr.h
#include emif.h
+#include of_memory.h
/**
* struct emif_data - Per device static data for driver's use
@@ -49,6 +51,7 @@
* frequency in effect at the moment)
* @plat_data: Pointer to saved platform data.
* @debugfs_root: dentry to the root folder for EMIF in debugfs
+ * @np_ddr:Pointer to ddr device tree node
*/
struct emif_data {
u8 duplicate;
@@ -63,6 +66,7 @@ struct emif_data {
struct emif_regs*curr_regs;
struct emif_platform_data *plat_data;
struct dentry *debugfs_root;
+ struct device_node *np_ddr;
};
static struct emif_data *emif1;
@@ -1148,6 +1152,168 @@ static int is_custom_config_valid(struct
emif_custom_configs *cust_cfgs,
return valid;
}
+#if defined(CONFIG_OF)
+static void __init_or_module of_get_custom_configs(struct device_node *np_emif,
+ struct emif_data *emif)
+{
+ struct emif_custom_configs *cust_cfgs = NULL;
+ int len;
+ const int *lpmode, *poll_intvl;
+
+ lpmode = of_get_property(np_emif, low-power-mode, len);
+ poll_intvl = of_get_property(np_emif,
Re: [RFC PATCH 3/3] i2c: inititalise the actual transferred to zero
Hi Felipe, On Mon, 2 Jul 2012 14:54:23 +0300, Felipe Balbi wrote: On Fri, Jun 29, 2012 at 03:18:32PM +0200, Jean Delvare wrote: Well you've seen the caveats I mentioned, this will be no easy ride. If you are willing to take the risk, spend the time documenting the change, and help people if there are issues, then I'm OK. At least as long as someone else doesn't come saying it's a very bad idea ;) This approach is a hard-requirement for devices which will pose any interface/feedback with user. We have been working with a piezo driver from TI (drv2665) and it will be used (in most cases at least) to give the user a feedback based on e.g. touchscreen event. Imagine drv2665 responds with a NAK while we're in the middle of driving a wave through it (keep in mind a wave could take seconds to finish, depending on the usecase), if we don't have a way to tell users that we have writen X bytes, how should we make sure to continue driving the wave from the exact byte where we got a NAK ? If can't make sure that detail is true, then such usecases (as piezo drivers) will never work. Another approach would be to not add any field to struct i2c_msg but instead return either the amount of bytes transferred, or an error case. This would mean a series that would: 1) fix all users of struct i2c_master_send() and the like to check for errors as if (ret 0) instead of if (ret); You confuse me here. i2c_master_send is a function, not a structure. Have you checked the code as it currently exists? i2c_master_send() already returns a positive number on success, not 0. I'm not claiming this number is necessarily very useful with the current implementation, but it's not 0. The API looks sane at least, and with Shubhrajyoti's proposed change, we could finally implement it properly. And its backend i2c_transfer() also doesn't return 0 on success, but the number of transferred messages. The problem at the moment is that it's not clear what the bus driver should return in case of partial success : a negative error code, or the number of messages successfully processed. I suspect implementations are mixed. Plus, as you and Shubhrajyoti found out, the caller doesn't know where in the last message the problem occurred. Are you really suggesting that we could change the meaning of the value returned by i2c_transfer from number of messages processed to number of bytes processed? This would be a real API change. I'm not claiming the current API is very useful, but callers expect it that way, and I mean in-tree kernel drivers, out-of-tree kernel drivers, and user-space alike. Changing it has a huge risk of breakage (with lots of people mad at you.) 2) fix all i2c buses to return the amount of bytes written instead of zero or error case adap-algo-master_xfer is not returning 0 on success today, so your proposal makes little sense to me. 3) fix Documentation to state that we're now returning the amount of bytes, instead of zero or errno. I'm not sure what will have minimum impact to userland, though. What do you say Jean ? What would you prefer ? Shubhrajyoti's proposal (which is much in line with what David Brownell proposed 4 years ago) seems at least possible to implement, while so far your own proposal is fuzzy at best (an actual patch may make your intents clearer.) What I like about Shubhrajyoti's proposal is that it adds optional information for the caller. It isn't changing the values returned, so the risk of breaking current driver code is quite low. Actually I think the only issue is with i2c_msg structures not being initialized using the C99 style. Other than this, it should be pretty safe. -- Jean Delvare -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/3] i2c: add 'actual' field to struct i2c_msg
On Fri, 29 Jun 2012 16:35:25 +0530, Shubhrajyoti D wrote:
In case of a NACK, it's wise to tell our clients
drivers about how many bytes were actually transferred.
Support this by adding an extra field to the struct
i2c_msg which gets incremented the amount of bytes
actually transferred.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
---
include/linux/i2c.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/linux/i2c.h b/include/linux/i2c.h
index ddfa041..0cb6b83 100644
--- a/include/linux/i2c.h
+++ b/include/linux/i2c.h
@@ -547,6 +547,7 @@ struct i2c_msg {
#define I2C_M_NO_RD_ACK 0x0800 /* if
I2C_FUNC_PROTOCOL_MANGLING */
#define I2C_M_RECV_LEN 0x0400 /* length will be first
received byte */
__u16 len; /* msg length */
+ __u16 actual; /* actual bytes transferred */
__u8 *buf; /* pointer to msg data */
};
Oh, as a side note: I don't much like the name actual. It's not
really clear what it means. I don't have a perfect name to propose as a
replacement, but maybe transferred or even just done would do.
--
Jean Delvare
--
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] staging: drm/omap: add rotation properties
On Fri, Jun 29, 2012 at 07:17:23AM -0500, Rob Clark wrote: On Fri, Jun 29, 2012 at 5:46 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Wed, 2012-06-27 at 09:06 -0500, Rob Clark wrote: From: Rob Clark r...@ti.com Use tiled buffers for rotated/reflected scanout, with CRTC and plane properties as the interface for userspace to configure rotation. Signed-off-by: Rob Clark r...@ti.com +/* this should probably be in drm-core to standardize amongst drivers */ +#define DRM_ROTATE_0 0 +#define DRM_ROTATE_90 1 +#define DRM_ROTATE_180 2 +#define DRM_ROTATE_270 3 +#define DRM_REFLECT_X 4 +#define DRM_REFLECT_Y 5 Are both reflect X and Y needed? You can get all the possible orientations with just one of the reflects. And I think the word mirror represents nicely what the reflect does, i.e. if you look at the mirror, the image you see is flipped horizontally. fwiw these values are aligned with what is used in userspace xrandr.. an earlier version of this patch used just 3 bits, which where aligned with what the omap hw uses and can describe all possible combinations of mirroring and isomorphic rotation (x-invert, y-invert, and xy-flip). But the advantage of the xrandr approach is you can more easily leave out bits for rotation/mirroring modes that your hw does not support.. for example if some hw supports only certain rotations or does not support mirror/reflect. When I hear mirror I always think of it as the happening after rotation, but that's not how xrandr does things. I suppose reflection has more or less the same connotation for me, but since it's already used by xrandr, I know I have to do the necessary mental gymnastics. If you think about it in terms of matrix multiplication, xrandr does things like this: x' = Rot * Ref * x, whereas for me the more natural order (for whatever reason) would be x' = Ref * Rot * x, where x is the source coordinates, and x' the destination coordinates. IIRC in dss mirroring was specified in the post-rotation way, and the direction of the rotation was also opposite to xrandr (cw in dss, ccw in xrandr). So FWIW, my vote goes to reflect if we want to match xrandr semantics. Also I agree on the number of bits, six is better than three since it allows you to describe the hw capabilities. -- Ville Syrjälä Intel OTC -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset fix issues.
On Mon, 2 Jul 2012, Munegowda, Keshava wrote: Hi Samuel please drop this patch for now , since Alan stern has mentioned improvements for this patch and we need to wait for Alan's new patch on ehci-omap.c and then Rus dill patch and my usbhs tll patch series need to be rebased. No, that's okay. I rebased my patch on top of Russ's; see http://marc.info/?l=linux-usbm=134098478928668w=2 so Russ's patch should be kept. My patch needed other changes also, so this wasn't a big deal. The extra problems I mentioned in an earlier email will still need to be fixed after both Russ's patch and my own are merged. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
