Hi,
On Tue, Jun 19, 2012 at 06:59:42, CF Adad wrote:
> Anyway, we have advanced our kernel to today's latest l-o (3.5-rc2). Though
> we are not considering the GPMC a likely source of the error at this moment,
> I'm considering exploring this patchset. Unfortunately, the NAND is very
> critic
> - Original Message -
> From: Andrea Scian [mailto:r...@dave-tech.it]
> Sent: Monday, June 18, 2012 08:25 PM
> To: linux-omap@vger.kernel.org
> Subject: RFC: PATCH TI81xx fix MUSB software mode setting
>
>
> Dear all,
>
> when configuring our platform (DM8148 based) to work with
> US
On Mon, Jun 18, 2012 at 11:31 PM, Kevin Hilman wrote:
> Tasslehoff Kjappfot writes:
>
>> The support for using a timer to wake from suspend was removed in:
>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=98e182a26bbbf5575457622337684ef61493e864
>>
>> I found an
Hi Jon,
On Mon, Jun 18, 2012 at 21:31:46, Hunter, Jon wrote:
> > @@ -95,10 +89,6 @@ static int omap2_onenand_set_async_mode(int cs, void
> > __iomem *onenand_base)
> > if (err)
> > return err;
> >
> > - /* Ensure sync read and sync write are disabled */
> > - reg = readw(on
On Tuesday 19 June 2012 01:34 AM, Mike Turquette wrote:
On 20120614-18:16, Rajendra Nayak wrote:
diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
index e548c43..e4911ee 100644
--- a/drivers/clk/clk-divider.c
+++ b/drivers/clk/clk-divider.c
@@ -32,30 +32,69 @@
#define div_mask
On Monday 18 June 2012 11:11 PM, Paul Walmsley wrote:
On Thu, 7 Jun 2012, Rajendra Nayak wrote:
On Thursday 07 June 2012 11:43 AM, Paul Walmsley wrote:
Until the OMAP4 code is converted to disable the use of the clock
framework-based clockdomain enable/disable sequence, any clock used as
a hwm
On Mon, Jun 18, 2012 at 2:42 PM, Brian Austin wrote:
> The beagleboard USB Host Port that is used is Port 2. The platform driver
> sets MODE_PHY for port 1 causing pin muxing to override the pins on the
> expansion
> connector P17 when using board_mux[]. Since USBHS Port 1 is not connected
> re
On 20120614-18:16, Rajendra Nayak wrote:
> plat/clock.c which has most of usecounting/locking infrastructure will
> be used only for OMAP1 until that is moved to use COMMON clk.
>
> reuse most of what plat/clock.h has while we move to common clk, and
> move most of what 'struct clk' was as 'struct
Hi Afzal,
I just wanted to follow back up. We are still trying to find this slab bug,
but so far we've not found any smoking guns. Less than stable power is our
current main suspect. As has been the custom however, the error was here 2
weeks ago nearly non-stop, and then as suddenly as it cam
The beagleboard USB Host Port that is used is Port 2. The platform driver sets
MODE_PHY for port 1 causing pin muxing to override the pins on the expansion
connector P17 when using board_mux[]. Since USBHS Port 1 is not connected
remove the case for muxing the USB Port1 pins by default.
Patch is
Hi Paul,
On 6/18/2012 5:45 PM, Paul Walmsley wrote:
Hi
On Mon, 18 Jun 2012, Cousson, Benoit wrote:
I guess that patch need to be revisited based on discussion we had and
the patch you proposed in [1]. Assuming Tony is OK, it should be
probably part of the -rc, because this domain should not h
Hi
On Sat, 16 Jun 2012, Ricardo Neri wrote:
> I would like to revive an old discussion regarding how to use a particular
> idle mode for a specific use-case[1].
>
> As per the OMAP4 documentation, audio over HDMI should be transmitted in
> no-idle mode. This patch adds the HWMOD_SWSUP_SIDLE so t
Hi Jon,
On Thu, 7 Jun 2012, Jon Hunter wrote:
> The problem is that currently none of the clocks are being registered for
> OMAP4470 devices and so on boot-up no clocks can be found and the kernel
> panics.
>
> This fix always the kernel to boot without failure using a simple RAMDISK file
> sys
On Tue, 15 May 2012, Hiremath, Vaibhav wrote:
> Paul,
> Can you please add above statement, when you merge it into your repo?
Added this, and added Santosh's ack, and queued for 3.6.
- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to major
On 20120614-18:16, Rajendra Nayak wrote:
> diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
> index e548c43..e4911ee 100644
> --- a/drivers/clk/clk-divider.c
> +++ b/drivers/clk/clk-divider.c
> @@ -32,30 +32,69 @@
> #define div_mask(d) ((1 << (d->width)) - 1)
> #define is_power
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Tony,
The following changes since commit 08f3098928c991560408e8c71d4af8b1a3ff2d67:
ARM: OMAP2+: am33xx: Add AM335XEVM machine support (2012-06-05 00:52:37 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kern
On Mon, Jun 18, 2012 at 23:58:36, Paul Walmsley wrote:
> On Mon, 18 Jun 2012, Hiremath, Vaibhav wrote:
>
> > I would really recommend you to look at the proposal of getting the clock-
> > tree and hwmod patches to the linux-next until merge window, so that it
> > will
> > get tested for some tim
On Mon, 18 Jun 2012, Hiremath, Vaibhav wrote:
> I would really recommend you to look at the proposal of getting the clock-
> tree and hwmod patches to the linux-next until merge window, so that it will
> get tested for some time.
I've thought about this, but I'm not sure it has much point unless
On Mon, Jun 18, 2012 at 23:36:58, Paul Walmsley wrote:
> Hi Vaibhav,
>
> On Thu, 14 Jun 2012, Hiremath, Vaibhav wrote:
>
> > Leaving HWMOD data patch aside, both the above patches should be
> > considered for acceptance, can you please review the same and if there
> > are no review comments, ca
Hi Vaibhav,
On Thu, 14 Jun 2012, Hiremath, Vaibhav wrote:
> Leaving HWMOD data patch aside, both the above patches should be
> considered for acceptance, can you please review the same and if there
> are no review comments, can it be merged?
I don't quite understand the part about leaving the
Tasslehoff Kjappfot writes:
> The support for using a timer to wake from suspend was removed in:
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=98e182a26bbbf5575457622337684ef61493e864
>
> I found an alternative patch
> (http://www.mail-archive.com/linux-omap@vg
On Thu, 7 Jun 2012, Rajendra Nayak wrote:
> On Thursday 07 June 2012 11:43 AM, Paul Walmsley wrote:
> > Until the OMAP4 code is converted to disable the use of the clock
> > framework-based clockdomain enable/disable sequence, any clock used as
> > a hwmod main_clk must have a clockdomain associat
Hi,
On Fri, 20 Apr 2012, Tarun Kanti DebBarma wrote:
> Add an API to get main clock name associated with a given @oh.
> This will avoid the need to construct fclk names during early
> initialization in order to get fclk handle using clk_get().
>
> Cc: Cousson, Benoit
> Cc: Paul Walmsley
> Cc:
Hi
On Thu, 14 Jun 2012, Peter Ujfalusi wrote:
> To keep the McBSP fck alias handling in sync among OMAP versions.
> Change the legacy implementation for OMAP2/3 regarding to McBSP fck alias.
> OMAP4 (and OMAP5) uses the hwmod data to specify the aliases for the fcks and
> it is also needed for th
Hi Afzal,
Thanks for sending the update.
On 06/16/2012 03:03 AM, Afzal Mohammed wrote:
> Reorganize gpmc-onenand initialization so that changes
> required for gpmc driver migration can be made smooth.
>
> Ensuring sync read/write are disabled in onenand cannot
> be expected to work properly unle
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 t
Hi
On Mon, 18 Jun 2012, Cousson, Benoit wrote:
> I guess that patch need to be revisited based on discussion we had and
> the patch you proposed in [1]. Assuming Tony is OK, it should be
> probably part of the -rc, because this domain should not have been
> introduced in 3.5-rc1 at all for OMA
On Mon, Jun 18, 2012 at 08:00:15PM +0530, Shubhrajyoti D wrote:
>
> The patch series does the following
>
> - I2C register restore only if context if the context is lost
> - Bus busy recovery mechanism.
> - the reset is not done in init.
> - Adds a patch to use devm_* functions
> - Adds a pdata f
On Mon, Jun 18, 2012 at 08:00:28PM +0530, Shubhrajyoti D wrote:
> From: Felipe Balbi
>
> stat & BIT(1) is the same as BIT(1),
Not true. I'd guess you are missing some context in the patch
description.
> so let's
> simplify things a bit by removing "stat &" from
> all omap_i2c_ack_stat() calls.
On Mon, Jun 18, 2012 at 08:00:26PM +0530, Shubhrajyoti D wrote:
> From: Felipe Balbi
>
> trivial patch, no functional changes.
This patch seems to be correct, but it is not trivial. In fact, it is
pretty easy to miss a "!" here which can cause subtle bugs.
>
> Signed-off-by: Felipe Balbi
> Re
On Mon, Jun 18, 2012 at 08:00:25PM +0530, Shubhrajyoti D wrote:
> From: Felipe Balbi
>
> trivial patch, no functional changes
Wrong. This patch does change some behaviour, are you aware of that?
So, please check if the side-effect is affectong the code and adapt the
commit message, if everythin
Hi Mathias,
On Fri, Jun 01, 2012 at 08:06:00PM +0200, Mathias Leblanc wrote:
> * STMicroelectronics version 1.2.0, Copyright (C) 2010
> * STMicroelectronics comes with ABSOLUTELY NO WARRANTY.
> * This is free software, and you are welcome to redistribute it
> * under certain conditions.
>
>
Dear all,
when configuring our platform (DM8148 based) to work with USB0 as device
and USB1 as host I've found some problems.
It was fine if I configure both as device or both as host or enable only
one port, but configure both in different modes lead to a not working
configuration.
After a b
Use INIT_COMPLETION instead of init_completion in transfer.
Signed-off-by: Shubhrajyoti D
---
drivers/i2c/busses/i2c-omap.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 6f8e7d9..e24eb1f 100644
--- a
The omap_i2c_remove function may not be needed after
device exit so the memory could be freed.
Signed-off-by: Shubhrajyoti D
---
drivers/i2c/busses/i2c-omap.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.
From: Felipe Balbi
trivial patch, no functional changes
Signed-off-by: Felipe Balbi
Reviewed-by : Santosh Shilimkar
Signed-off-by: Shubhrajyoti D
---
drivers/i2c/busses/i2c-omap.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/dr
Use SET_RUNTIME_PM_OPS macro to set runtime functions.
Acked-by: Felipe Balbi
Signed-off-by: Shubhrajyoti D
---
drivers/i2c/busses/i2c-omap.c |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 326b9
From: Felipe Balbi
trivial patch, no functional changes.
Signed-off-by: Felipe Balbi
Reviewed-by : Santosh Shilimkar
Signed-off-by: Shubhrajyoti D
---
drivers/i2c/busses/i2c-omap.c | 63 -
1 files changed, 31 insertions(+), 32 deletions(-)
diff --gi
From: Felipe Balbi
stat & BIT(1) is the same as BIT(1), so let's
simplify things a bit by removing "stat &" from
all omap_i2c_ack_stat() calls.
Signed-off-by: Felipe Balbi
Reviewed-by : Santosh Shilimkar
Signed-off-by: Shubhrajyoti D
---
drivers/i2c/busses/i2c-omap.c | 19 ++---
From: Jon Hunter
The OMAP3530 is based upon the same silicon as the OMAP3430 and so the I2C
revision is the same for 3430 and 3530. However, the OMAP3630 device has the
same I2C revision as OMAP4. Correct the revision definition to reflect this.
This patch is based on work done by Jon Hunter
Ch
Currently i2c register restore is done always.
Adding conditional restore.
The i2c register restore is done only if the context is lost
or in case of error to be on the safe side.
Cc: Kevin Hilman
Signed-off-by: Shubhrajyoti D
---
arch/arm/plat-omap/i2c.c |3 +++
drivers/i2c/busses
The patch series does the following
- I2C register restore only if context if the context is lost
- Bus busy recovery mechanism.
- the reset is not done in init.
- Adds a patch to use devm_* functions
- Adds a pdata function pointer to do context save restore
- Split the omap_i2c_isr to increase
From: Felipe Balbi
trivial patch to aid readability. No functional
changes.
Signed-off-by: Felipe Balbi
Signed-off-by: Shubhrajyoti D
---
drivers/i2c/busses/i2c-omap.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/buss
The various devm_* functions allocate memory that is released when a driver
detaches. This patch uses devm_kzalloc, devm_request_and_ioremap for data
that is allocated in the probe function of a platform device and is only
freed in the remove function.
Signed-off-by: Shubhrajyoti D
---
drivers/i
Remove the definition of SYSS_RESETDONE_MASK and use the
one in omap_hwmod.h.
Also fixes the warning
CC drivers/i2c/busses/i2c-omap.o
drivers/i2c/busses/i2c-omap.c:163: warning: "SYSS_RESETDONE_MASK" redefined
Signed-off-by: Shubhrajyoti D
---
drivers/i2c/busses/i2c-omap.c |3 ---
1 f
From: Vikram Pandita
In case a peripheral is driving SDA bus low (ie. a start condition), provide
a constant clock output using the test mode of the OMAP I2C controller to
try and clear the bus. Soft reset I2C controller after attempting the bus clear
to ensure that controller is in a good state.
The reset in the driver at init is not needed anymore as the
following patch has removed the HWMOD_INIT_NO_RESET flag.
6d3c55f [OMAP: hwmod: fix the i2c-reset timeout during bootup]
This patch does the following
-removes the reset from the probe and implements a omap_i2c_reset
function to reset.
On 18 June 2012 18:41, Tomi Valkeinen wrote:
> On Mon, 2012-06-18 at 18:37 +0530, Jassi Brar wrote:
>> On 18 June 2012 17:54, Tomi Valkeinen wrote:
>> > On Mon, 2012-06-18 at 17:16 +0530, Jassi Brar wrote:
>>
>> >> So preferably I would move request_threaded_irq() to after
>> >> hdmi_check_hpd_st
Thanks Keshava.
Regards
Sunil Matange
-Original Message-
From: Munegowda, Keshava [mailto:keshava_mgo...@ti.com]
Sent: Monday, June 18, 2012 1:59 PM
To: Samuel Ortiz
Cc: Dill, Russ; linux-omap@vger.kernel.org;
linux-arm-ker...@lists.infradead.org; Balbi, Felipe; Partha Basak; Igor
Grinbe
On Mon, 2012-06-18 at 18:37 +0530, Jassi Brar wrote:
> On 18 June 2012 17:54, Tomi Valkeinen wrote:
> > On Mon, 2012-06-18 at 17:16 +0530, Jassi Brar wrote:
>
> >> So preferably I would move request_threaded_irq() to after
> >> hdmi_check_hpd_state() in ti_hdmi_4xxx_phy_enable() and convert the
On 18 June 2012 17:54, Tomi Valkeinen wrote:
> On Mon, 2012-06-18 at 17:16 +0530, Jassi Brar wrote:
>> So preferably I would move request_threaded_irq() to after
>> hdmi_check_hpd_state() in ti_hdmi_4xxx_phy_enable() and convert the
>
> No, you can't move the check. If you move it, the HPD state
On Mon, 2012-06-18 at 17:16 +0530, Jassi Brar wrote:
> On 18 June 2012 16:24, Tomi Valkeinen wrote:
> > On Mon, 2012-06-18 at 15:42 +0530, Jassi Brar wrote:
>
> >> BTW, coming to think about it, I am not sure what we need the
> >> spin_lock_irqsave() protection for in hdmi_check_hpd_state() ? It
Hello.
On 18-06-2012 15:32, Konstantin Baydarov wrote:
This patch adds device tree entries on OMAP4 based boards
for System Control Module (SCM).
TODO:
The IOMEM windows of ctrl_module_core, bandgap, usbphy overlap, so
probably only specific registers should be specified in dts for
bandgap a
On 18 June 2012 16:24, Tomi Valkeinen wrote:
> On Mon, 2012-06-18 at 15:42 +0530, Jassi Brar wrote:
>> BTW, coming to think about it, I am not sure what we need the
>> spin_lock_irqsave() protection for in hdmi_check_hpd_state() ? It
>> can't control HPD gpio state change and hdmi_set_phy_pwr()
This patch adds device tree entries on OMAP4 based boards
for System Control Module (SCM).
TODO:
The IOMEM windows of ctrl_module_core, bandgap, usbphy overlap, so
probably only specific registers should be specified in dts for
bandgap and usb phy entries.
Signed-off-by: Konstantin Baydarov
Sign
This patch exposes OMAP4 thermal sensor as a thermal zone
named "cpu". Only thermal creation is done here.
TODO:
- Add cooling bindings
- Add extrapolation rules
Signed-off-by: Eduardo Valentin
---
drivers/thermal/Kconfig | 12 ++
drivers/thermal/Makefile|1
driver
In the System Control Module, OMAP supplies a voltage reference
and a temperature sensor feature that are gathered in the band
gap voltage and temperature sensor (VBGAPTS) module. The band
gap provides current and voltage reference for its internal
circuits and other analog IP blocks. The analog-to
OMAP4460 specific temperature sensor register bit fields are added.
Existing OMAP4 entries are renamed to OMAP4430.
Signed-off-by: Keerthy
Signed-off-by: Eduardo Valentin
---
arch/arm/mach-omap2/include/mach/control.h | 116
1 files changed, 116 insertions(+), 0 de
Created a new platform driver for the platform device created by the
control module mfd core, wrt usb. This driver has API's to power on/off
the phy and the API's to write to musb mailbox.
Changes since previous version:
- Bandgap and usb phy: drivers are now independent from control module driver
OMAP system control module can be probed early, then
omap_type is safe to use its APIs.
TODO: add support for other omap versions
Signed-off-by: Konstantin Baydarov
---
arch/arm/mach-omap2/id.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
Index: linux-2.6/arch/arm/mach-omap2/i
This patch introduces a MFD core device driver for
OMAP system control module.
The control module allows software control of
various static modes supported by the device. It is
composed of two control submodules: general control
module and device (padconfiguration) control
module.
Changes since p
This patch exposes the definitions under control.h to
drivers outside the machine code.
Signed-off-by: Eduardo Valentin
---
arch/arm/mach-omap2/am35xx-emac.c|2 +-
arch/arm/mach-omap2/board-3430sdp.c |2 +-
arch/arm/mach-omap2/board-4430sdp.c |
Hello.
This is a next version of series of patches(based on Eduardo Valentin's patch
set) adding a basic support for system control module, on OMAP4+ context. It is
a working in progress.
Main changes since previous patch set version:
- Bandgap and usb phy: drivers are now independent from
On Monday 18 June 2012 09:57 AM, Paul Walmsley wrote:
On Thu, 14 Jun 2012, Rajendra Nayak wrote:
OMAP3 has suspend broken in mainline, so I tested it on an
older kernel (3.4-rc4 using my RFC series)
Idle and OFF mode however seem to be broken for a long time,
I wasn;t able to get it working eve
On Mon, 2012-06-18 at 15:42 +0530, Jassi Brar wrote:
> On 18 June 2012 13:41, Tomi Valkeinen wrote:
> >>
> >> Explicitly maintaining HDMI phy power state using a flag is prone to
> >> race and un-necessary when we have a zero-cost alternative of checking
> >> the state before trying to set it.
> >
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_mp
On 18 June 2012 13:41, Tomi Valkeinen wrote:
>>
>> Explicitly maintaining HDMI phy power state using a flag is prone to
>> race and un-necessary when we have a zero-cost alternative of checking
>> the state before trying to set it.
>
> Why would reading the value from the register be any less racy
No file includes omap730.h or omap850.h. That's not surprising, as
commit e6684f7132c6e6333e96407b06910bebaa4c1935 ("OMAP7XX: Create
omap7xx.h") created a header that was "intended to replace omap730.h and
omap850.h", while all "values defined [in omap7xx.h] are identical to
those in both the old f
On Mon, Jun 18, 2012 at 2:48 PM, Tasslehoff Kjappfot
wrote:
> The support for using a timer to wake from suspend was removed in:
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=98e182a26bbbf5575457622337684ef61493e864
>
> I found an alternative patch
> (http://www
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:
Hi Paul,
On 6/18/2012 8:16 AM, Paul Walmsley wrote:
> Until the OMAP4 code is converted to disable the use of the clock
> framework-based clockdomain enable/disable sequence, any clock used as
> a hwmod main_clk must have a clockdomain associated with it. This
> patch populates some clock structu
Hi Kevin,
On Tue, Jun 12, 2012 at 10:37 PM, Kevin Hilman wrote:
> "ABRAHAM, KISHON VIJAY" writes:
>
>> Hi Kevin, Benoit, Paul,
>>
>> On Fri, Jun 1, 2012 at 2:16 AM, Arnd Bergmann wrote:
>>> On Thursday 31 May 2012, ABRAHAM, KISHON VIJAY wrote:
> I would mark the multiplexed device compatib
The support for using a timer to wake from suspend was removed in:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=98e182a26bbbf5575457622337684ef61493e864
I found an alternative patch
(http://www.mail-archive.com/linux-omap@vger.kernel.org/msg47836.html)
that cl
On Fri, Jun 15, 2012 at 12:36 AM, Sarashetti, Mantesh wrote:
> 'Acked-by: mant...@ti.com'
> 'Tested-by: mant...@ti.com'
>
> Regards,
> Mantesh
> -Original Message-
> From: Russ Dill [mailto:russ.d...@gmail.com] On Behalf Of Dill, Russ
> Sent: Thursday, June 14, 2012 11:24 AM
> To: linux-om
On Mon, Jun 11, 2012 at 19:21:21, Jason Kridner wrote:
> From: Daniel Mack
> >Hey,
> >
> >can anybody give me a quick wrap-up about the current state of AM33xx
> >based SoCs in mainline? What are the next steps to get things merged?
>
> There is a wiki page [1] that is intended to provide a summa
On Sat, 2012-06-16 at 03:31 +0530, jaswinder.si...@linaro.org wrote:
> From: Jassi Brar
>
> Explicitly maintaining HDMI phy power state using a flag is prone to
> race and un-necessary when we have a zero-cost alternative of checking
> the state before trying to set it.
Why would reading the val
On Fri, Jun 15, 2012 at 7:17 PM, Jean Pihet wrote:
> Hi Keshava,
>
> On Fri, Jun 15, 2012 at 2:04 PM, Munegowda, Keshava
> wrote:
>> On Tue, Jun 12, 2012 at 6:28 PM, Munegowda, Keshava
>> wrote:
>>> hi kevin
>>> now I am using initramfs with kernel linux3.5.rc1,
>>> but the retention is
77 matches
Mail list logo
