from:"Chao Xu"

[RFC/RFT/PATCH V3] gpio: omap: refresh patch be more aggressive with pm_runtime against v3.12-rc5

2013-12-07 Thread Chao Xu

From: Felipe Balbi ba...@ti.com

try to keep gpio block suspended as much as possible.

Tested with pandaboard and a sysfs exported gpio.

Signed-off-by: Felipe Balbi balbi at ti.com

[caesarxuc...@gmail.com : Refreshed against v3.12-rc5, and added
revision check to enable aggressive pm_runtime on OMAP4-only. Because
am33xx_gpio_sysc.idlemodes seems to be wrongly marked as
SIDLE_SMART_WKUP, which might cause missed interrupts with this patch.
Tested on Pandaboard rev A2.]
Signed-off-by: Chao Xu caesarxuc...@gmail.com
---
changes since v2:
*add wrapper function to avoid 'is_aggressive_pm' check everywhere, as
suggested by Santosh Shilimkar 
*fix format issue in commit log

 drivers/gpio/gpio-omap.c|   90 +--
 include/linux/platform_data/gpio-omap.h |1 +
 2 files changed, 74 insertions(+), 17 deletions(-)

diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 89675f8..fc5318b 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -76,6 +76,7 @@ struct gpio_bank {
int context_loss_count;
int power_mode;
bool workaround_enabled;
+   bool is_aggressive_pm;
 
void (*set_dataout)(struct gpio_bank *bank, int gpio, int enable);
int (*get_context_loss_count)(struct device *dev);
@@ -90,6 +91,18 @@ struct gpio_bank {
 #define BANK_USED(bank) (bank-mod_usage || bank-irq_usage)
 #define LINE_USED(line, offset) (line  (1  offset))
 
+static void _aggressive_pm_runtime_get_sync(struct gpio_bank *bank)
+{
+   if (bank-is_aggressive_pm)
+   pm_runtime_get_sync(bank-dev);
+}
+
+static void _aggressive_pm_runtime_put(struct gpio_bank *bank)
+{
+   if (bank-is_aggressive_pm)
+   pm_runtime_put(bank-dev);
+}
+
 static int irq_to_gpio(struct gpio_bank *bank, unsigned int gpio_irq)
 {
return bank-chip.base + gpio_irq;
@@ -473,8 +486,13 @@ static void _disable_gpio_module(struct gpio_bank *bank, 
unsigned offset)
 static int gpio_is_input(struct gpio_bank *bank, int mask)
 {
void __iomem *reg = bank-base + bank-regs-direction;
+   u32 val;
 
-   return __raw_readl(reg)  mask;
+   _aggressive_pm_runtime_get_sync(bank);
+   val = __raw_readl(reg)  mask;
+   _aggressive_pm_runtime_put(bank);
+
+   return val;
 }
 
 static int gpio_irq_type(struct irq_data *d, unsigned type)
@@ -485,7 +503,7 @@ static int gpio_irq_type(struct irq_data *d, unsigned type)
unsigned long flags;
unsigned offset;
 
-   if (!BANK_USED(bank))
+   if (!BANK_USED(bank)  !bank-is_aggressive_pm)
pm_runtime_get_sync(bank-dev);
 
 #ifdef CONFIG_ARCH_OMAP1
@@ -503,6 +521,7 @@ static int gpio_irq_type(struct irq_data *d, unsigned type)
(type  (IRQ_TYPE_LEVEL_LOW|IRQ_TYPE_LEVEL_HIGH)))
return -EINVAL;
 
+   _aggressive_pm_runtime_get_sync(bank);
spin_lock_irqsave(bank-lock, flags);
offset = GPIO_INDEX(bank, gpio);
retval = _set_gpio_triggering(bank, offset, type);
@@ -511,11 +530,13 @@ static int gpio_irq_type(struct irq_data *d, unsigned 
type)
_set_gpio_direction(bank, offset, 1);
} else if (!gpio_is_input(bank, 1  offset)) {
spin_unlock_irqrestore(bank-lock, flags);
+   _aggressive_pm_runtime_put(bank);
return -EINVAL;
}
 
bank-irq_usage |= 1  GPIO_INDEX(bank, gpio);
spin_unlock_irqrestore(bank-lock, flags);
+   _aggressive_pm_runtime_put(bank);
 
if (type  (IRQ_TYPE_LEVEL_LOW | IRQ_TYPE_LEVEL_HIGH))
__irq_set_handler_locked(d-irq, handle_level_irq);
@@ -668,10 +689,11 @@ static int omap_gpio_request(struct gpio_chip *chip, 
unsigned offset)
unsigned long flags;
 
/*
-* If this is the first gpio_request for the bank,
-* enable the bank module.
+* if aggressive runtime pm is supported, enable the bank module
+* for each gpio_request. Otherwise enable the bank module if this
+* is the first gpio_request for the bank.
 */
-   if (!BANK_USED(bank))
+   if (bank-is_aggressive_pm || !BANK_USED(bank))
pm_runtime_get_sync(bank-dev);
 
spin_lock_irqsave(bank-lock, flags);
@@ -685,7 +707,7 @@ static int omap_gpio_request(struct gpio_chip *chip, 
unsigned offset)
}
bank-mod_usage |= 1  offset;
spin_unlock_irqrestore(bank-lock, flags);
-
+   _aggressive_pm_runtime_put(bank);
return 0;
 }
 
@@ -694,6 +716,8 @@ static void omap_gpio_free(struct gpio_chip *chip, unsigned 
offset)
struct gpio_bank *bank = container_of(chip, struct gpio_bank, chip);
unsigned long flags;
 
+   _aggressive_pm_runtime_get_sync(bank);
+
spin_lock_irqsave(bank-lock, flags);
bank-mod_usage = ~(1  offset);
_disable_gpio_module(bank, offset);
@@ -701,10 +725,11 @@ static void omap_gpio_free(struct gpio_chip *chip

Re: [PATCH V2] gpio: omap: refresh patch be more aggressive with pm_runtime against v3.12-rc5

2013-12-02 Thread Chao Xu

Sorry for the late reply.

On Fri, Nov 29, 2013 at 11:04 AM, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
 Adding Kevin's Linaro id, + Nishant,

 On Tuesday 26 November 2013 05:46 PM, Chao Xu wrote:
 From: Felipe Balbi ba...@ti.com

 try to keep gpio block suspended as much as possible.

 Tested with pandaboard and a sysfs exported gpio.

 Signed-off-by: Felipe Balbi balbi at ti.com

 [caesarxuc...@gmail.com : Refreshed against v3.12-rc5, and added revision 
 check to enable aggressive pm_runtime on OMAP4-only. Because 
 am33xx_gpio_sysc.idlemodes seems to be wrongly marked as SIDLE_SMART_WKUP, 
 which might cause missed interrupts with this patch. Tested on Pandaboard 
 rev A2.]

 Please format the text and limit it to 80 char rule.

Sorry. It's my first time submitting a patch. I will fix it and resubmit.
 Signed-off-by: Chao Xu caesarxuc...@gmail.com
 ---
 According to Mr. Felipe Balbi, the original patch was not accepted because 
 interrupts would be missed when GPIO was used as IRQ source. But in my tests 
 with pandaboard, interrupts were not missed. This is because _idle_sysc() 
 sets the idlemode of gpio module to smart-idle-wakeup, and according to 
 OMAP4430 TRM, under this idlemode, the gpio can generate an asynchronous 
 wakeup request to the PRCM. And after GPIO is awake, the wake-up request is 
 reflected into the interrupt status registers.

 A change made on the original patch is only applying the aggressive runtime 
 pm scheme on OMAP4, because I don’t have HW to test OMAP3 or am33xx devices. 
 According to the respective TRMs, their GPIO modules also can generate 
 wake-up request if the idlemode is set to smart-idle or smart-idle-wakeup. 
 So the patch should work for them, too. But I suspect a potential SW bug may 
 cause missed interrupts: the am33xx_gpio_sysc.idlemodes is marked as capable 
 of SIDLE_SMART_WKUP in omap_hwmod_33xx.c. But according to AM335x TRM, 
 _only_ gpio0 is capable of this mode. This may make GPIO stuck in force-idle 
 mode and unable to generate wakeup request. And thus interrupt will be 
 missed. Again, I don’t have the HW to verify whether this is a bug or not :(

 In general I am not against this idea but patch has many assumptions which
 are not entirely correct.

 - SMART_WAKEUP will take care of waking IP etc not always true to power
 domain getting into idle.

I agree that if the power domain goes to idle, SMART_WAKEUP
won't be effective. But, correct me if i'm wrong, even if we don't call
runtime_put(), the power domain can still go to idle. Because the
modulemode of GPIO is set to HW_AUTO in this case, which won't
prevent the power domain goes to retention. So this patch doesn't
make the situation worse.
 - If we want to go on this path then I would like to see we address
 omap2_gpio_[prepare/resumne]_for_idle()

I did a quick google search but didn't find the problem with the two
functions. Could you give me a pointer here?
 - GPIO though sound simple is one of the most notorious IP block
 on PM front so this needs lot of testing. This patch not seems be
 tested at all so I would have much liked it to be in RFC/RFT
 state.
I tested using a gpio pin as interrupt source after applying the patch.
What are the other tests that I should do? Is there a formal way of
reporting test results here?

  drivers/gpio/gpio-omap.c|  103 
 ++-
  include/linux/platform_data/gpio-omap.h |1 +
  2 files changed, 87 insertions(+), 17 deletions(-)

 diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
 index 89675f8..90661f2 100644
 --- a/drivers/gpio/gpio-omap.c
 +++ b/drivers/gpio/gpio-omap.c
 @@ -76,6 +76,7 @@ struct gpio_bank {
   int context_loss_count;
   int power_mode;
   bool workaround_enabled;
 + bool is_aggressive_pm;

   void (*set_dataout)(struct gpio_bank *bank, int gpio, int enable);
   int (*get_context_loss_count)(struct device *dev);
 @@ -473,8 +474,15 @@ static void _disable_gpio_module(struct gpio_bank 
 *bank, unsigned offset)
  static int gpio_is_input(struct gpio_bank *bank, int mask)
  {
   void __iomem *reg = bank-base + bank-regs-direction;
 + u32 val;

 - return __raw_readl(reg)  mask;
 + if (bank-is_aggressive_pm)
 + pm_runtime_get_sync(bank-dev);
 + val = __raw_readl(reg)  mask;
 + if (bank-is_aggressive_pm)
 + pm_runtime_put(bank-dev);
 +
 Move above in some wrapper instead of sprinkling the
 'is_aggressive_pm' check everywhere.

Will do.
 @@ -1585,18 +1651,21 @@ static const struct omap_gpio_platform_data 
 omap2_pdata = {
   .regs = omap2_gpio_regs,
   .bank_width = 32,
   .dbck_flag = false,
 + .is_aggressive_pm = false,
  };

  static const struct omap_gpio_platform_data omap3_pdata = {
   .regs = omap2_gpio_regs,
   .bank_width = 32,
   .dbck_flag = true,
 + .is_aggressive_pm = false,
  };

  static const struct omap_gpio_platform_data omap4_pdata = {
   .regs

Re: [BUG] PandaBoard hangs before starting init while booting v3.12

2013-11-26 Thread Chao Xu

Thanks, Tony. I checked my .config and this option is enabled. FYI, I
raised this issue in u-boot mailing-list, too. It seems to be a bug in
u-boot and only happens to certain version of pandaboard. The name of
the thread is No single character output after update to latest
u-boot on pandaboard

On Tue, Nov 26, 2013 at 12:20 PM, Tony Lindgren t...@atomide.com wrote:
 * Chao Xu caesarxuc...@gmail.com [131122 19:28]:
 I wonder if we also have some dependency to some earlier versions of
 u-boot as u-boot now only muxes the essential pins?
 This is exactly the problem in my case. I added #define
 CONFIG_SYS_ENABLE_PADS_ALL in u-boot/include/configs/omap4_common.h
 and now there is output.

 I guess the reason that the u-boot worked out-of-box for Ben but not
 for me is that I missed some configurations in v3.12 kernel. I image
 there is a config options that tells the kernel to take care of the
 non-essential pins that used to be the responsibility of u-boot. Could
 you confirm my hypothesis? And if so, could you kindly suggest what's
 the name of the config option?

 That would be CONFIG_PINCTRL_SINGLE=y for device tree based omaps.
 But if we have the configuration missing for some driver in the
 board specific .dts file, that won't help naturally. We do have
 PINCTRL_SINGLE enabled in omap2plus_defconfig.

 Regards,

 Tony



-- 
Regards,
Chao Xu
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH V2] gpio: omap: refresh patch be more aggressive with pm_runtime against v3.12-rc5

2013-11-26 Thread Chao Xu

From: Felipe Balbi ba...@ti.com

try to keep gpio block suspended as much as possible.

Tested with pandaboard and a sysfs exported gpio.

Signed-off-by: Felipe Balbi balbi at ti.com

[caesarxuc...@gmail.com : Refreshed against v3.12-rc5, and added revision check 
to enable aggressive pm_runtime on OMAP4-only. Because 
am33xx_gpio_sysc.idlemodes seems to be wrongly marked as SIDLE_SMART_WKUP, 
which might cause missed interrupts with this patch. Tested on Pandaboard rev 
A2.]

Signed-off-by: Chao Xu caesarxuc...@gmail.com
---
According to Mr. Felipe Balbi, the original patch was not accepted because 
interrupts would be missed when GPIO was used as IRQ source. But in my tests 
with pandaboard, interrupts were not missed. This is because _idle_sysc() sets 
the idlemode of gpio module to smart-idle-wakeup, and according to OMAP4430 
TRM, under this idlemode, the gpio can generate an asynchronous wakeup request 
to the PRCM. And after GPIO is awake, the wake-up request is reflected into the 
interrupt status registers. 

A change made on the original patch is only applying the aggressive runtime pm 
scheme on OMAP4, because I don’t have HW to test OMAP3 or am33xx devices. 
According to the respective TRMs, their GPIO modules also can generate wake-up 
request if the idlemode is set to smart-idle or smart-idle-wakeup. So the patch 
should work for them, too. But I suspect a potential SW bug may cause missed 
interrupts: the am33xx_gpio_sysc.idlemodes is marked as capable of 
SIDLE_SMART_WKUP in omap_hwmod_33xx.c. But according to AM335x TRM, _only_ 
gpio0 is capable of this mode. This may make GPIO stuck in force-idle mode and 
unable to generate wakeup request. And thus interrupt will be missed. Again, I 
don’t have the HW to verify whether this is a bug or not :(

 drivers/gpio/gpio-omap.c|  103 ++-
 include/linux/platform_data/gpio-omap.h |1 +
 2 files changed, 87 insertions(+), 17 deletions(-)

diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 89675f8..90661f2 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -76,6 +76,7 @@ struct gpio_bank {
int context_loss_count;
int power_mode;
bool workaround_enabled;
+   bool is_aggressive_pm;
 
void (*set_dataout)(struct gpio_bank *bank, int gpio, int enable);
int (*get_context_loss_count)(struct device *dev);
@@ -473,8 +474,15 @@ static void _disable_gpio_module(struct gpio_bank *bank, 
unsigned offset)
 static int gpio_is_input(struct gpio_bank *bank, int mask)
 {
void __iomem *reg = bank-base + bank-regs-direction;
+   u32 val;
 
-   return __raw_readl(reg)  mask;
+   if (bank-is_aggressive_pm)
+   pm_runtime_get_sync(bank-dev);
+   val = __raw_readl(reg)  mask;
+   if (bank-is_aggressive_pm)
+   pm_runtime_put(bank-dev);
+
+   return val;
 }
 
 static int gpio_irq_type(struct irq_data *d, unsigned type)
@@ -485,7 +493,7 @@ static int gpio_irq_type(struct irq_data *d, unsigned type)
unsigned long flags;
unsigned offset;
 
-   if (!BANK_USED(bank))
+   if (!BANK_USED(bank)  !bank-is_aggressive_pm)
pm_runtime_get_sync(bank-dev);
 
 #ifdef CONFIG_ARCH_OMAP1
@@ -503,6 +511,8 @@ static int gpio_irq_type(struct irq_data *d, unsigned type)
(type  (IRQ_TYPE_LEVEL_LOW|IRQ_TYPE_LEVEL_HIGH)))
return -EINVAL;
 
+   if (bank-is_aggressive_pm)
+   pm_runtime_get_sync(bank-dev);
spin_lock_irqsave(bank-lock, flags);
offset = GPIO_INDEX(bank, gpio);
retval = _set_gpio_triggering(bank, offset, type);
@@ -511,11 +521,16 @@ static int gpio_irq_type(struct irq_data *d, unsigned 
type)
_set_gpio_direction(bank, offset, 1);
} else if (!gpio_is_input(bank, 1  offset)) {
spin_unlock_irqrestore(bank-lock, flags);
+   if (bank-is_aggressive_pm)
+   pm_runtime_put(bank-dev);
+
return -EINVAL;
}
 
bank-irq_usage |= 1  GPIO_INDEX(bank, gpio);
spin_unlock_irqrestore(bank-lock, flags);
+   if (bank-is_aggressive_pm)
+   pm_runtime_put(bank-dev);
 
if (type  (IRQ_TYPE_LEVEL_LOW | IRQ_TYPE_LEVEL_HIGH))
__irq_set_handler_locked(d-irq, handle_level_irq);
@@ -668,10 +683,11 @@ static int omap_gpio_request(struct gpio_chip *chip, 
unsigned offset)
unsigned long flags;
 
/*
-* If this is the first gpio_request for the bank,
-* enable the bank module.
+* if aggressive runtime pm is supported, enable the bank module
+* for each gpio_request. Otherwise enable the bank module if this
+* is the first gpio_request for the bank.
 */
-   if (!BANK_USED(bank))
+   if (bank-is_aggressive_pm || !BANK_USED(bank))
pm_runtime_get_sync(bank-dev);
 
spin_lock_irqsave(bank

[PATCH RFC] gpio: omap: refresh the patch “gpio: omap: be more aggressive with pm_runtime” against v3.12-rc5

2013-11-25 Thread Chao Xu

Refresh the patch “gpio: omap: be more aggressive with pm_runtime” by
Felipe Balbi against v3.12-rc5. Add version checking so that the
aggressive pm_runtime only applies to omap4 devices. Tested with
pandaboard rev a2 through sysfs.
Signed-off-by: Chao Xu chao...@rice.edu
---
According to Mr. Felipe Balbi, the original patch was not accepted
because interrupts would be missed when GPIO was used as IRQ source.
But in my tests with pandaboard, interrupts were not missed. This is
because _idle_sysc() sets the idlemode of gpio module to
smart-idle-wakeup, and according to OMAP4430 TRM, under this idlemode,
the gpio can generate an asynchronous wakeup request to the PRCM. And
after GPIO is awake, the wake-up request is reflected into the
interrupt status registers.

A change I made against the original patch is only using the
aggressive runtime pm scheme on OMAP4 by adding a flag in pdata,
because I don’t have HW to test OMAP3 or am33xx devices. According to
the respective TRMs, their GPIO modules also can generate wake-up
request if the idlemode is set to smart-idle or smart-idle-wakeup. So
the patch should work for them, too. But I suspect a potential SW bug
may cause missed interrupts: the am33xx_gpio_sysc.idlemodes is marked
as capable of SIDLE_SMART_WKUP in omap_hwmod_33xx.c. But according to
AM335x TRM, _only_ gpio0 is capable of this mode. This may make GPIO
stuck in force-idle mode and unable to generate wakeup request. And
thus interrupt will be missed. Again, I don’t have the HW to verify
whether this is a bug or not :(

 drivers/gpio/gpio-omap.c|  103 ++-
 include/linux/platform_data/gpio-omap.h |1 +
 2 files changed, 87 insertions(+), 17 deletions(-)

diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 89675f8..90661f2 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -76,6 +76,7 @@ struct gpio_bank {
  int context_loss_count;
  int power_mode;
  bool workaround_enabled;
+ bool is_aggressive_pm;

  void (*set_dataout)(struct gpio_bank *bank, int gpio, int enable);
  int (*get_context_loss_count)(struct device *dev);
@@ -473,8 +474,15 @@ static void _disable_gpio_module(struct gpio_bank
*bank, unsigned offset)
 static int gpio_is_input(struct gpio_bank *bank, int mask)
 {
  void __iomem *reg = bank-base + bank-regs-direction;
+ u32 val;

- return __raw_readl(reg)  mask;
+ if (bank-is_aggressive_pm)
+ pm_runtime_get_sync(bank-dev);
+ val = __raw_readl(reg)  mask;
+ if (bank-is_aggressive_pm)
+ pm_runtime_put(bank-dev);
+
+ return val;
 }

 static int gpio_irq_type(struct irq_data *d, unsigned type)
@@ -485,7 +493,7 @@ static int gpio_irq_type(struct irq_data *d, unsigned type)
  unsigned long flags;
  unsigned offset;

- if (!BANK_USED(bank))
+ if (!BANK_USED(bank)  !bank-is_aggressive_pm)
  pm_runtime_get_sync(bank-dev);

 #ifdef CONFIG_ARCH_OMAP1
@@ -503,6 +511,8 @@ static int gpio_irq_type(struct irq_data *d, unsigned type)
  (type  (IRQ_TYPE_LEVEL_LOW|IRQ_TYPE_LEVEL_HIGH)))
  return -EINVAL;

+ if (bank-is_aggressive_pm)
+ pm_runtime_get_sync(bank-dev);
  spin_lock_irqsave(bank-lock, flags);
  offset = GPIO_INDEX(bank, gpio);
  retval = _set_gpio_triggering(bank, offset, type);
@@ -511,11 +521,16 @@ static int gpio_irq_type(struct irq_data *d,
unsigned type)
  _set_gpio_direction(bank, offset, 1);
  } else if (!gpio_is_input(bank, 1  offset)) {
  spin_unlock_irqrestore(bank-lock, flags);
+ if (bank-is_aggressive_pm)
+ pm_runtime_put(bank-dev);
+
  return -EINVAL;
  }

  bank-irq_usage |= 1  GPIO_INDEX(bank, gpio);
  spin_unlock_irqrestore(bank-lock, flags);
+ if (bank-is_aggressive_pm)
+ pm_runtime_put(bank-dev);

  if (type  (IRQ_TYPE_LEVEL_LOW | IRQ_TYPE_LEVEL_HIGH))
  __irq_set_handler_locked(d-irq, handle_level_irq);
@@ -668,10 +683,11 @@ static int omap_gpio_request(struct gpio_chip
*chip, unsigned offset)
  unsigned long flags;

  /*
- * If this is the first gpio_request for the bank,
- * enable the bank module.
+ * if aggressive runtime pm is supported, enable the bank module
+ * for each gpio_request. Otherwise enable the bank module if this
+ * is the first gpio_request for the bank.
  */
- if (!BANK_USED(bank))
+ if (bank-is_aggressive_pm || !BANK_USED(bank))
  pm_runtime_get_sync(bank-dev);

  spin_lock_irqsave(bank-lock, flags);
@@ -685,7 +701,8 @@ static int omap_gpio_request(struct gpio_chip
*chip, unsigned offset)
  }
  bank-mod_usage |= 1  offset;
  spin_unlock_irqrestore(bank-lock, flags);
-
+ if (bank-is_aggressive_pm)
+ pm_runtime_put(bank-dev);
  return 0;
 }

@@ -694,6 +711,9 @@ static void omap_gpio_free(struct gpio_chip *chip,
unsigned offset)
  struct gpio_bank *bank = container_of(chip, struct gpio_bank, chip);
  unsigned long flags;

+ if (bank-is_aggressive_pm)
+ pm_runtime_get_sync(bank-dev);
+
  spin_lock_irqsave(bank-lock, flags);
  bank-mod_usage = ~(1  offset);
  _disable_gpio_module(bank, offset);
@@ -701,10 +721,11 @@ static void omap_gpio_free(struct gpio_chip
*chip

Re: [BUG] PandaBoard hangs before starting init while booting v3.12

2013-11-22 Thread Chao Xu

I wonder if we also have some dependency to some earlier versions of
u-boot as u-boot now only muxes the essential pins?
This is exactly the problem in my case. I added #define
CONFIG_SYS_ENABLE_PADS_ALL in u-boot/include/configs/omap4_common.h
and now there is output.

I guess the reason that the u-boot worked out-of-box for Ben but not
for me is that I missed some configurations in v3.12 kernel. I image
there is a config options that tells the kernel to take care of the
non-essential pins that used to be the responsibility of u-boot. Could
you confirm my hypothesis? And if so, could you kindly suggest what's
the name of the config option?

Thank you!

On Wed, Nov 20, 2013 at 12:35 PM, Tony Lindgren t...@atomide.com wrote:
 * Ben Gamari bgamari.f...@gmail.com [131119 19:07]:
 Chao Xu caesarxuc...@gmail.com writes:

  Hi,
 
  I also try to boot v3.12 on my pandaboard rev A2, but it hangs at
  starting kernel. My SD card is originally loaded with a linaro 12.04
  ubuntu-developer image. I have tried with v3.7 and v3.8 uImage and
  both of them work normally, but v3.12 hangs. Is there any trick I
  missed? Do I need to use the new u-boot as used by Ben?
 
 I've written up some of my experiences bringing up 3.12 on the
 PandaBoard here[1]. You may find it helpful. Regardless, I would
 definitely try upgrading u-boot.

 Nice investigative blogging :)

 Care to also update it with the other issues remaining on pandaboard?
 Sounds like we're pretty close to having things working nicely with
 mainline kernel on it, so let's just fix those issues ASAP.

 I'm aware of at least two issues:

 1.  The WLAN not working after a soft reset, or if the interface is
 reset with ifconfig down. This could be a typo somewhere in the
 .dts file for the WLAN regulator or something like that.

 2. Suspend and resume does not wake-up from serial console and spews
a bunch of warnings. The wake-up issue can be fixed with the new
the new interrupts-extended property to use the wake IRQs, I'll
try to update my patches for that today.

  And here is a separate problem with building u-boot. I cloned the
  upstream u-boot repository. The latest commit is
  c2e5e802ecb7ab668ce9911b210ed68c804b349f. Then I did:
  make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- omap4_panda_config
  make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- -j8
  cp MLO u-boot.img /media/boot/
  But when turn on my pandaboard, there is NO output from the serial
  console. I didn't change the other file in the boot partition. They
  are from linaro 12.04 ubuntu-developer image.
 
 I would check that you have earlyprintk enabled (both in the kernel
 configuration as well as on the kernel command line). Moreover, ensure
 that the correct serial devices is selected for low-level debug output
 (in the kernel configuration).

 I wonder if we also have some dependency to some earlier versions of
 u-boot as u-boot now only muxes the essential pins?

 Regards,

 Tony


 [1] 
 http://bgamari.github.io/posts/2013-11-17-running-modern-kernel-on-pandaboard.html





-- 
Regards,
Chao Xu
--
To unsubscribe from this list: send the line unsubscribe 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: [BUG] PandaBoard hangs before starting init while booting v3.12

2013-11-19 Thread Chao Xu

 4a31e040.pinmux: could not add functions for 
 pinmux_wl12xx_pins 56x
 [3.257324] omap-dma-engine 4a056000.dma-controller: allocating channel 
 for 60
 [3.264953] omap-dma-engine 4a056000.dma-controller: allocating channel 
 for 59
 [3.272705] 480d5000.mmc supply vmmc_aux not found, using dummy regulator



-- 
Regards,
Chao Xu
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

what does the number in the pm_debug/count mean for clockdomains?

2013-08-25 Thread Chao Xu

Hi all,

I don't know how to interpret the bottom half of the
/sys/kernel/debug/pm_debug, e.g.l3_dma_clkdm-core_pwrdm (0)
What does the number in the brackets mean? Does it mean how many times
the l3_dma_clkdm has been gated? Also, Thank you!

-- 
Regards,
Chao Xu
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC/RFT/PATCH V3] gpio: omap: refresh patch be more aggressive with pm_runtime against v3.12-rc5

Re: [PATCH V2] gpio: omap: refresh patch be more aggressive with pm_runtime against v3.12-rc5

Re: [BUG] PandaBoard hangs before starting init while booting v3.12

[PATCH V2] gpio: omap: refresh patch be more aggressive with pm_runtime against v3.12-rc5

[PATCH RFC] gpio: omap: refresh the patch “gpio: omap: be more aggressive with pm_runtime” against v3.12-rc5

Re: [BUG] PandaBoard hangs before starting init while booting v3.12

Re: [BUG] PandaBoard hangs before starting init while booting v3.12

what does the number in the pm_debug/count mean for clockdomains?

8 matches

Site Navigation

Mail list logo

Footer information