I have been looking more into the issue I am having and it looks like the
system isnt even entering a fully suspended state;
Tracing through the suspend sequence it looks like it is having trouble with
void omap_sram_idle(void)
The return from pwrm_read_next is 3 (PWRDM_POWER_ON) surely the next
* Grant [140203 20:44]:
> > omapfb segfaults on my Pandaboard ES across several different kernel
> > versions including 3.13.1. I've tried everything I can think of. Any
> > ideas?
> >
> > - Grant
>
> This was fixed with the patches here:
>
> https://github.com/archlinuxarm/PKGBUILDs/tree/mast
On Mon, 3 Feb 2014, Sricharan R wrote:
> > I already have your reviewed-by tag for the first patch in this series.
> >
> > Kevin was pointing out that irqchip maintainer tag is needed for this patch
> > as well
> > to be merged. We are planning to take this series through arm-soc tree.
> >
> > C
On 01/29/2014 01:21 PM, Christoph Fritz wrote:
On Tue, 2014-01-28 at 18:02 +0100, Christoph Fritz wrote:
On Tue, 2014-01-28 at 15:40 +0200, Tero Kristo wrote:
Due to a regression since next-20140122 the following errors are present:
- pin sys_clkout2, which gets configured to 24 Mhz by th
On Tue, Feb 04, 2014 at 03:25:47PM +0200, Roger Quadros wrote:
> Hi Greg,
>
> Patch 1 fixes SuperSpeed hub enumeration on beaglebone.
> Patch 2 fixes remote-wakeup resume on beaglebone.
>
> Felipe has Acked the 1st patch but still needs to Ack the 2nd one.
>
> Patches are based on 3.14-rc1
Why
On 02/04/2014 05:27 PM, Greg KH wrote:
> On Tue, Feb 04, 2014 at 03:25:47PM +0200, Roger Quadros wrote:
>> Hi Greg,
>>
>> Patch 1 fixes SuperSpeed hub enumeration on beaglebone.
>> Patch 2 fixes remote-wakeup resume on beaglebone.
>>
>> Felipe has Acked the 1st patch but still needs to Ack the 2nd
On 02/04/2014 06:46 AM, Balaji T K wrote:
> On Tuesday 21 January 2014 05:04 AM, Nishanth Menon wrote:
>> MMC1 is the only MMC interface available on the platform. Further,
>> since the platform is based on older revision of SoC which is not
>> capable of doing multi-block writes, mark it so and ad
On 02/04/2014 06:44 AM, Balaji T K wrote:
> On Tuesday 21 January 2014 04:59 AM, Nishanth Menon wrote:
>> When device is booted using devicetree, platforms impacted by
>> Erratum 2.1.1.128 is not detected easily in the mmc driver. This erratum
>> indicates that the module cannot do multi-block tran
During resume don't touch SUSPENDM/RESUME bits of POWER register
while restoring controller context. These bits might be changed
by the controller during resume operation and so will be different
than what they were during suspend.
e.g. SUSPENDM bit is set by software during USB global suspend but
Hi Greg,
Patch 1 fixes SuperSpeed hub enumeration on beaglebone.
Patch 2 fixes remote-wakeup resume on beaglebone.
Felipe has Acked the 1st patch but still needs to Ack the 2nd one.
Patches are based on 3.14-rc1
cheers,
-roger
Ajay Kumar Gupta (1):
usb: musb: host: Fix SuperSpeed hub enumera
From: Ajay Kumar Gupta
Disables PING on status phase of control transfer.
PING token is not mandatory in status phase of control transfer
and so some high speed USB devices don't support it. If such devices
are connected to MUSB then they would not respond to PING token
causing delayed or failed
Hi Satish,
On 01/20/2014 06:33 AM, Satish Patel wrote:
> TI-USIM driver is a platform driver that provides a character
> driver interface to user applications.
>
> It allows user applications to call IOCTL's to
> perform smart card operations.
>
> Driver currently supports
> - ATR
> - T=0 & T=1
On Tuesday 21 January 2014 05:04 AM, Nishanth Menon wrote:
MMC1 is the only MMC interface available on the platform. Further,
since the platform is based on older revision of SoC which is not
capable of doing multi-block writes, mark it so and add pinmux
s/writes/read
Thanks and Regards,
Balaj
On Tuesday 21 January 2014 04:59 AM, Nishanth Menon wrote:
When device is booted using devicetree, platforms impacted by
Erratum 2.1.1.128 is not detected easily in the mmc driver. This erratum
indicates that the module cannot do multi-block transfers.
Handle this by providing a boolean flag to
On Friday 24 January 2014 10:21 PM, Balaji T K wrote:
To Resolve build failure seen with sh-allmodconfig:
include/linux/omap-dma.h:171:8: error: expected identifier before numeric
constant
make[4]: *** [drivers/mmc/host/omap_hsmmc.o] Error 1
due to CCR redefinition, move dmaengine cons
Hi!
> --- a/drivers/power/Kconfig
> +++ b/drivers/power/Kconfig
> @@ -22,6 +22,19 @@ config POWER_SUPPLY_CHARGER
> drivers to keep the charging logic outside and the charger driver
> just need to abstract the charger hardware.
>
> +config POWER_SUPPLY_CHARGING_ALGO_PSE
> + bo
Hi!
> +#define DEV_MANUFACTURER "TI"
> +#define DEV_MANUFACTURER_NAME_SIZE 4
This is unneccessarily complicated for no reason. You copy "TI" to
struct, just so that ou can return pointer to the field on
get_property.
What about simply returning "TI" from get_property, without defines
and copyin
Hi!
> +Throttling configuration example:
> +
> +struct psy_throttle_state my_throttle_states[] = {
> +
> + /* Level 0: Limit charge current to 1500mA. Normal Level */
> + {
> + .throttle_action = PSY_THROTTLE_CC_LIMIT,
> + .throttle_val = 1500,
> + },
> +
> +
Hi Brian,
>From: Gupta, Pekon
>>I'm preparing a 3.14 pull request soon, and since you seem committed to
>>fixing and properly testing a known regression here, I'd like to see
>>this go in. But given the late timing and the unanswered questions, I
>>think it's unlikely to go in -rc1. Perhaps I can
On Monday 13 January 2014 09:06 PM, Balaji T K wrote:
Few cleanups to reduce code indent,
Add pbias_regulator support and adapt omap_hsmmc to use pbias regulator
to configure required voltage on mmc1 pad(SD card) i/o rails on OMAP SoCs.
Hi Tony,
Considering the dependencies with regulator, de
20 matches
Mail list logo