Paul,
On Sun, Jan 29, 2012 at 3:38 PM, Paul Walmsley wrote:
>
> Hi Jean
>
> Quick question on the tracing in _pwrdm_state_switch().
>
> That section of the code reads:
>
> state = pwrdm_read_pwrst(pwrdm);
>
> ...
>
> case PWRDM_STATE_PREV:
> prev = pwrdm_read_prev_pwr
On 01/27/2012 08:02 AM, Axel Lin wrote:
> This patch converts the drivers in drivers/video/* to use the
> module_spi_driver() macro which makes the code smaller and a bit simpler.
>
> Signed-off-by: Axel Lin
> Cc: Imre Deak
> Cc: Roger Quadros
> Cc: Steve Sakoman
> Cc: Erik Gilling
> Cc: Graž
The calculation of required DISPC_FCLK for downscaling is done by multplying the
pixel clock with an integer factor. This isn't true for OMAP4 where the required
clock is calculated using the exact ratio of downscaling done.
Fix this calculation for OMAP4. Also, do a minor clean up of calc_fclk().
Hi Tomi,
On 01/26/2012 12:07 PM, Tomi Valkeinen wrote:
> Hi Florian,
>
> Here are two major fixes for OMAP DSS driver.
>
> The first (OMAPDSS: use sync versions...) fixes problem with system
> suspend, which causes omapdss power management to give WARNs and
> generally malfunction on system susp
The number of dss_feat_id members has increased to a large value, the current
way of assigning a subset of these features (for a particular OMAP) as a mask
is no longer feasible.
Maintain the subset of features supported as lists. Make the function
dss_has_feature() traverse through this list.
Si
Hello,
I've been trying to get suspend working with musb compiled in on 3.2.
It seems both patches from this thread are needed, Kevin's patch stops
omap2430_runtime_suspend() from being called at inappropriate time
(when i2c is suspended [1]) and Felipe's patch brings that call back
at better time
On Fri, Jan 27, 2012 at 10:16 AM, Tony Lindgren wrote:
> Hi Arnd & Olof,
>
> Please pull omap fixes from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap fixes
Pulled, thanks!
-Olof
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a me
On Fri, Jan 27, 2012 at 7:39 PM, Steve Sakoman wrote:
> On Tue, Jan 24, 2012 at 6:33 AM, Michael Hunold wrote:
>> Hi,
>>
>> I am experimenting with an SDIO card on the Beagleboard. I have started
>> my experiments with Linux-3.1.4 some time ago and basically everything
>> is working.
>>
>> Except
Hi,
Ok, so I did a few more tests and there is a serious issue when sampling
in frequency mode (the default). I noticed wrong number of samples, so
I investigated this some more and instrumented the perf_event kernel code.
I found some erratic timer ticks causing broken period adjustments.
In fac
I dont have a Lauterbach but your argument seems valid. If: +
device was in retention(CSWR) and the next state was supposed to be
OFF + the device did not hit off + by the time the code shown runs
the device is still in CSWR(say like the abe or ducati that would be
expected not to go to ON r
I dont have a Lauterbach but your argument seems valid. If: +
device was in retention(CSWR) and the next state was supposed to be
OFF + the device did not hit off + by the time the code shown runs
the device is still in CSWR(say like the abe or ducati that would be
expected not to go to ON r
Hi Jean
Quick question on the tracing in _pwrdm_state_switch().
That section of the code reads:
state = pwrdm_read_pwrst(pwrdm);
...
case PWRDM_STATE_PREV:
prev = pwrdm_read_prev_pwrst(pwrdm);
if (pwrdm->state != prev)
pw
12 matches
Mail list logo