Any news on this?
This thread seems to have gone a little quiet...
Cheers,
Joe
-Original Message-
From: Tomi Valkeinen tomi.valkei...@ti.com
To: Paul Walmsley p...@pwsan.com, khil...@ti.com
Cc: Archit Taneja a0393...@ti.com, linux-omap@vger.kernel.org, Joe Woodward
j...@terrafix.co.uk
On 05/14/2012 04:43 PM, mani wrote:
Dear Kim,
I have a query here ..
My point is that it would be better for read to not preempt
write-for-page_reclaim.
And we can identify it by PG_reclaim. You can get the idea.
I think If there is no page available then no read will
On Mon, 2012-05-14 at 08:36 +0100, Joe Woodward wrote:
Any news on this?
This thread seems to have gone a little quiet...
Hi,
I've been doing testing to understand the problem, but so far I don't
have any idea why things go wrong. I haven't found out any logic in
which configuration works
Hi Mark,
Thanks for the great work!
On 05/12/12 00:12, Mark A. Greer wrote:
From: Mark A. Greer mgr...@animalcreek.com
The am35x family of SoCs has a Davinci EMAC ethernet
controller on-chip. Unfortunately, the EMAC is unable
to wake the PRCM when there is network activity which
leads to
On Mon, May 14, 2012 at 10:58:29AM +0900, Graeme Gregory wrote:
drivers/mfd/palmas-irq.c | 241 +
The IRQ support here seems to be following a pretty common pattern for
dense IRQ maps - could we factor it out into regmap-irq? It'd also be
nice if it were using an irq_domain - while it's
The patch series does the following
- Warn fixes if CONFIG_PM_RUNTIME is not selected.
- In case of i2c remove register access was done without any
get_sync fix the same.
- Folds a patch from Tasslehoff to prevent any merge conflicts.
- Prevents the XDUF flag to be set if the underflow
On OMAP4 we were writing 1 to IRQENABLE_CLR which cleared only
the arbitration lost interrupt. The patch intends to fix the same by writing 0
to the IE register clearing all interrupts.
This is based on the work done by Vikram Pandita vikram.pand...@ti.com.
The changes from the original patch
The functions omap_i2c_unidle/idle are called from omap_i2c_runtime_resume
and omap_i2c_runtime_suspend which is compiled for CONFIG_PM_RUNTIME.
This patch removes the omap_i2c_unidle/idle functions and folds them
into the runtime callbacks.
This fixes the below warn when CONFIG_PM_RUNTIME is not
If PM runtime get_sync fails return with the error
so that no further reads/writes goes through the interface.
This will avoid possible abort. Add a error message in case
of failure with the cause of the failure.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
- Correct the error handling.
In omap_i2c_remove we are accessing the I2C_CON register without
enabling the clocks. Fix the same by enabling the clocks and disabling
it.
This fixes the following crash.
[ 154.723022] [ cut here ]
[ 154.725677] WARNING: at
Currently the i2c driver calls the pm_runtime_enable and never
the disable. This causes a warning when pm_runtime_enable
checks for the count match.Fix the same by calling
pm_runtime_disable in the error and the remove path.
Cc: Kevin Hilman khil...@ti.com
Cc: Rajendra Nayak rna...@ti.com
Currently in probe
pm_runtime_put(dev-dev);
...
/* i2c device drivers may be active on return from add_adapter() */
adap-nr = pdev-id;
r = i2c_add_numbered_adapter(adap);
if (r) {
dev_err(dev-dev, failure adding adapter\n);
goto
By definition, wait_for_completion_timeout() returns an unsigned value and
therefore, it is not necessary to check if the return value is less than zero
as this is not possible.
This is based on a patch from Jon Hunter jon-hun...@ti.com
Changes from his patch
- Declare a long as the
The section number in the recent errata document has changed.
Rename the erratum 1p153 to the unique id i462 instead, so that
it is easier to reference. Also change the function name and comments
to reflect the same.
Cc: Jon Hunter jon-hun...@ti.com
Signed-off-by: Shubhrajyoti D
From: Tasslehoff Kjappfot tasskj...@gmail.com
i2c_probe set the dev-errata flag, but omap_i2c_init cleared the flag again.
Prevent the overwrite of the errata flags.Move the errata handling to a unified
place in probe to prevent such errors. Thus preventing the overwrite of erratum
1p153.
Currently in the 1.153 errata handling while waiting for transmitter
underflow if NACK is got the XUDF(Transmit underflow) flag is also set.
The flag is set after wait for the condition is over.
Cc: Alexander Shishkin virtu...@slind.org
Acked-by: Moiz Sonasath m-sonas...@ti.com
Signed-off-by:
On Mon, May 14, 2012 at 10:58:31AM +0900, Graeme Gregory wrote:
Looks good, quite a few of the things below are updates for very
recently introduced APIs.
+static int palmas_smps_read(struct palmas *palmas, unsigned int reg,
+ unsigned int *dest)
+{
+ int slave;
+
On Sat, May 12, 2012 at 03:24:51, Hilman, Kevin wrote:
Hiremath, Vaibhav hvaib...@ti.com writes:
On Fri, May 11, 2012 at 03:09:39, Hilman, Kevin wrote:
Hiremath, Vaibhav hvaib...@ti.com writes:
On Wed, May 09, 2012 at 04:08:09, Hilman, Kevin wrote:
Vaibhav Hiremath hvaib...@ti.com
Hi Tony, Artem,
This series modifies GPMC to provide OMAP onenand nand peripherals
with GPMC allocated address space as resource. This conversion helps
in smooth migration of gpmc code to driver.
This series has been made over [1-3], but is not functionally
dependent on those, only depedency is
Currently omap nand driver uses a field in platform data - phys_base
for passing the address space allocated by gpmc for nand. Use struct
resource instead. With this change omap nand driver has to get
address space from memory resource.
This helps in smooth migration of gpmc to driver.
Currently omap onenand driver invokes gpmc_cs_request, obtains address
space allocated by gpmc to onenand. Remove this, instead use resource
structure; this is now updated with address space for onenand by gpmc
initialization with the help of gpmc_cs_request. And remove usage of
gpmc_cs_request in
gpmc initialization done by platform code now updates struct resource
with the address space alloted for nand. Use this interface to obtain
memory rather than relying on platform data field - phys_base.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/plat-omap/include/plat/nand.h |1
gpmc initialization for onenand done by platform code now provides
onenand address space as memory resource. Hence remove usage of
gpmc_cs_request in onenand driver and obtain memory details from
resource structure.
Signed-off-by: Afzal Mohammed af...@ti.com
---
drivers/mtd/onenand/omap2.c |
Hi,
Changes compared to previous version:
- Patch 6 now adds support for reading prev logic and mem states
instead of tweaking the _update_logic_membank_counters function
directly.
- Some version of [PATCH] OMAP2+: UART: Add mechanism to probe uart
pins and configure rx wakeup from
From: Rajendra Nayak rna...@ti.com
Remove the FIXME's in the suspend sequence since
we now intend to support system level RET support.
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Tero Kristo t-kri...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
---
From: Rajendra Nayak rna...@ti.com
With no driver handling DSP, if brought out of reset, it stays
active and does not assert standby. This leads to IVAHD powerdomain not
transitioning and hence preventing chip retention.
This patch is no longer needed once Paul's powerdomain fixes are merged:
From: Santosh Shilimkar santosh.shilim...@ti.com
GIC distributor control register has changed between CortexA9 r1pX and
r2pX. The Control Register secure banked version is now composed of 2
bits:
bit 0 == Secure Enable
bit 1 == Non-Secure Enable
The Non-Secure banked register has not
From: Rajendra Nayak rna...@ti.com
OMAP4 has module specific context lost registers which makes it now
possible to have module level context loss count, instead of relying
on the powerdomain level context count.
Add 2 private hwmod api's to update/clear the hwmod/module specific
context lost
On OMAP4, there is no support to read previous logic state
or previous memory state achieved when a power domain transitions
to RET. Instead there are module level context registers.
In order to support the powerdomain level logic/mem_off_counters
on OMAP4, instead use the previous power state
This will make it easier to handle next logic states for power domains
during suspend. With this patch, the parameter is also programmed to
retention for every powerdomain, thus all powerdomains enter CSWR
state after this patch.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
From: Rajendra Nayak rna...@ti.com
On OMAP4 most modules/hwmods support module level context status. On
OMAP3 and earlier, we relyed on the power domain level context status.
Identify all such modules using a 'HWMOD_CONTEXT_REG' flag, all such
hwmods already have a valid 'context_offs' populated
PM debug now contains a file that can be used to control OSWR support
enable / disable on OMAP4. Also removed the off_mode_enable file for
the same platform as it is unsupported.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/pm-debug.c | 20
Hi,
Changes compared to previous version:
- generic: dropped a few redundant cpu_is_omapXxxx checks
- generic: changed the ordering of patches a bit to allow new
code + their users to be added in the same patch
- patch 3: removed dpll/cm/sar calls from this patch
- patch 4: added call to dpll
From: Santosh Shilimkar santosh.shilim...@ti.com
L3INIT powerdomain has USB HOST and USB TLL modules which support
hardware save-and-restore (HW SAR) mechanism.
This patch updates the L3INIT power domain to mark them as capable
of doing H/w save and restore and provides functions to do them
Added in preparation for device off mode. SAR ROM contains the mapping
from SAR RAM to IO registers, and this will eventually be parsed during
init time to do the reverse before device off.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/plat-omap/include/plat/omap44xx.h |1 +
1
This patch adds device off support to OMAP4 device type.
OFF mode is disabled by default, however, there are two ways to enable
OFF mode:
a) In the board file, call omap4_pm_off_mode_enable(1)
b) Enable OFF mode using the debugfs entry
echo 1/sys/kernel/debug/pm_debug/enable_off_mode
(conversely
From: Rajendra Nayak rna...@ti.com
SAR/ROM code restores only CORE DPLL to its original state
post wakeup from OFF mode.
The rest of the DPLL's in OMAP4 platform (MPU/IVA/ABE/USB/PER)
are saved and restored here during an OFF transition.
[n...@ti.com: minor cleanups]
Signed-off-by: Nishanth
From: Rajendra Nayak rna...@ti.com
Restore all CM1/2 module registers as they are lost in OFF mode.
[n...@ti.com: minor clean ups]
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Axel
omap_sar_overwrite() now uses offsets detected during init time from
the SAR ROM contents.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/omap-sar.c | 159 +---
1 files changed, 115 insertions(+), 44 deletions(-)
diff --git
From: Santosh Shilimkar santosh.shilim...@ti.com
The SAR RAM is maintained during Device OFF mode. The register layout
is fixed in SAR ROM. SAR is split into 4 banks with different
privilege accesses based on device type
---
Access
Added similar PM errata flag support as omap3 has. A few errata flags
will be added in subsequent patches.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/pm.h |7 +++
arch/arm/mach-omap2/pm44xx.c |1 +
2 files changed, 8 insertions(+), 0 deletions(-)
diff
From: Rajendra Nayak rna...@ti.com
On HS devices on the way out of MPU OSWR and OFF ROM code wrongly
overwrites the CM L3INSTR registers. So to avoid this, save them and
restore on the way out from MPU OSWR/OFF.
This errata applies to all HS/EMU versions of OMAP4.
Signed-off-by: Rajendra Nayak
SAR layout contents are now generated automatically based on SAR ROM
contents during boot.
u32 offset description
-- -
0 pointer to next entry
1 size of DMA transfer in bytes
2 SAR RAM address for save / restore
3
From: Santosh Shilimkar santosh.shilim...@ti.com
The ROM BUG is when MPU Domain OFF wake up sequence that can compromise
IVA and Tesla execution.
At wakeup from MPU OFF on HS device only (not GP device), when
restoring the Secure RAM, the ROM Code reconfigures the clocks the
same way it is done
From: Carlos Leija cile...@ti.com
At wakeup from OFF/OSWR CPU1 will call secure HAL service through a local
secure dispatcher with MMU off, thus ROM will save a PA return address.
Later in the wakeup, when SMC driver calls an RPC through
omap4_secure_dispatcher (MMU is on now), ROM code won't log
From: Axel Haslam axelhas...@gmail.com
ROM code restores part of the GIC context during wakeup from device
off mode from the SAR RAM. If the PPI and SPI interrupts are not
marked as non-secure on GP chips, this crashes the device during
wakeup, thus mark them as non-secure.
Signed-off-by: Axel
save_secure_all needs l3_main_3_ick and l4_secure_clkdm enabled,
otherwise the secure ROM code will crash.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/omap-wakeupgen.c | 20
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git
Without this, CPU0 will crash in the ROM code during wakeup from
device off. This patch also clears the GIC save area, to prevent
ROM code from writing garbage to the GIC registers during wakeup.
The actual GIC restore is done by kernel.
This bug fix applies only to OMAP4460, it is fixed on
If AUX_CORE_BOOT0 does not indicate wakeup request for cpu1, put it back
to off. This is needed during wakeup from device off to prevent cpu1
from being stuck indefinitely in the wakeup loop and also to prevent
wakeup problem on GP chips with device off mode.
Signed-off-by: Tero Kristo
During device off, the off-mode voltage transitions are enabled on reset.
Because the voltage control logic is not still completely functional for
OMAP4, we must disable the voltage transitions for device off for now.
This can only be done by disabling the I2C channel it seems.
This patch does
From: Santosh Shilimkar santosh.shilim...@ti.com
Work around for Errata ID: i632 LPDDR2 Corruption After OFF Mode
Transition When CS1 Is Used On EMIF which impacts OMAP443x silicon
The issue occurs when EMIF_SDRAM_CONFIG is restored first before
EMIF_SDRAM_CONFIG_2 is not yet restored, the
Currently device off does not have any counters / timers of its own
and it is impossible to track the time spent in this state. In device
off, MPU / CORE powerdomains enter OSWR, so normally the RETENTION
state times / counts are increased during device off.
This patch adds a new field to the
On 14/05/12 17:28, Mark Brown wrote:
On Mon, May 14, 2012 at 10:58:29AM +0900, Graeme Gregory wrote:
drivers/mfd/palmas-irq.c | 241 +
The IRQ support here seems to be following a pretty common pattern for
dense IRQ maps - could we factor it out into regmap-irq? It'd also be
nice if
On Mon, May 14, 2012 at 07:26:31PM +0900, Graeme Gregory wrote:
On 14/05/12 17:28, Mark Brown wrote:
On Mon, May 14, 2012 at 10:58:29AM +0900, Graeme Gregory wrote:
drivers/mfd/palmas-irq.c | 241 +
The IRQ support here seems to be following a pretty common pattern for
dense IRQ
Hi All,
On Thu, May 03, 2012 at 14:12:11, Mohammed, Afzal wrote:
Some boards depend on bootloader to update chip select value for NAND.
It is felt that Kernel should not depend on bootloader to get CS, as
for a particular board CS is hardwired and is fixed, hence this can
directly be
On Saturday 12 May 2012 11:40 PM, Wolfram Sang wrote:
Cc: Kevin Hilman khil...@ti.com
Cc: Rajendra Nayak rna...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
I'd really like a comment from the PM experts if each and every driver
has to ensure that the clocks are enabled on remove
to handle kernel NULL pointer dereference at virtual
address 0036
[1.938171] pgd = c0004000
[1.941009] [0036] *pgd=
[1.944763] Internal error: Oops: 5 [#1] SMP ARM
[1.949584] Modules linked in:
[1.952789] CPU: 0Not tainted (3.4.0-rc7-next-20120514-10436
On Mon, 2012-05-14 at 15:15 +0300, Felipe Balbi wrote:
looks like MUSB is probing before transceiver driver... could it be ?
Can you check transceiver has actually probed ? I guess panda's using
twl6030-usb.c
Ah. Perhaps it's then about this?
[0.352905] Skipping twl internal clock init
On Mon, May 14, 2012 at 03:24:11PM +0300, Tomi Valkeinen wrote:
On Mon, 2012-05-14 at 15:15 +0300, Felipe Balbi wrote:
looks like MUSB is probing before transceiver driver... could it be ?
Can you check transceiver has actually probed ? I guess panda's using
twl6030-usb.c
Ah. Perhaps
Hi,
On Mon, May 14, 2012 at 03:29:21PM +0300, Felipe Balbi wrote:
On Mon, May 14, 2012 at 03:24:11PM +0300, Tomi Valkeinen wrote:
On Mon, 2012-05-14 at 15:15 +0300, Felipe Balbi wrote:
looks like MUSB is probing before transceiver driver... could it be ?
Can you check transceiver has
On Sunday 06 of May 2012 18:50:16 Jarkko Nikula wrote:
On 05/04/2012 10:39 PM, Janusz Krzysztofik wrote:
This seems like a nice fix to me. As it affects all omaps, I'd like to
see some tested-by from Janusz/Jarkko/Peter. Can you guys give it a
try
with some audio tests?
OK, I can
On Friday 11 of May 2012 09:53:07 Tony Lindgren wrote:
* Paul Walmsley p...@pwsan.com [120510 15:31]:
Janusz Krzysztofik reported the following build break on OMAP1 builds that
don't include CONFIG_ARCH_OMAP16XX:
LD .tmp_vmlinux1
arch/arm/mach-omap1/built-in.o: In function
Salut Thomas,
Sorry for the delay.
On 5/4/2012 5:59 PM, Thomas Petazzoni wrote:
Hello Benoit,
Le Fri, 23 Sep 2011 22:23:09 +0200,
Benoit Coussonb-cous...@ti.com a écrit :
Add SoC specific map_io function to be used by the generic DT
board file. This is an intermediate step before having
On Mon, May 14, 2012 at 11:20:58AM +0300, Igor Grinberg wrote:
Hi Mark,
Hi Igor.
Thanks for the great work!
On 05/12/12 00:12, Mark A. Greer wrote:
From: Mark A. Greer mgr...@animalcreek.com
The am35x family of SoCs has a Davinci EMAC ethernet
controller on-chip. Unfortunately,
On 5/14/2012 2:47 PM, Felipe Balbi wrote:
Hi,
On Mon, May 14, 2012 at 03:29:21PM +0300, Felipe Balbi wrote:
On Mon, May 14, 2012 at 03:24:11PM +0300, Tomi Valkeinen wrote:
On Mon, 2012-05-14 at 15:15 +0300, Felipe Balbi wrote:
looks like MUSB is probing before transceiver driver... could it
Hi,
On Mon, May 14, 2012 at 07:06:25PM +0200, Cousson, Benoit wrote:
On 5/14/2012 2:47 PM, Felipe Balbi wrote:
Hi,
On Mon, May 14, 2012 at 03:29:21PM +0300, Felipe Balbi wrote:
On Mon, May 14, 2012 at 03:24:11PM +0300, Tomi Valkeinen wrote:
On Mon, 2012-05-14 at 15:15 +0300, Felipe Balbi
On Mon, Apr 30, 2012 at 02:26:48PM -0700, Mark A. Greer wrote:
From: Mark A. Greer mgr...@animalcreek.com
The am35x family of SoCs only support the PWRSTS_ON
state so create a new set of powerdomain structures
that ensure that only the ON state is entered.
Signed-off-by: Mark A. Greer
* Felipe Balbi ba...@ti.com [120514 11:04]:
That whole MMC card detection is also pretty screwed up. Balaji/Venkat,
can you guys look into that ? Probably making something generic using a
threaded IRQ handler ?
I mean, all the MMC core should need is an IRQ number (through GPIOs or
not
* Tony Lindgren t...@atomide.com [120514 11:19]:
* Felipe Balbi ba...@ti.com [120514 11:04]:
That whole MMC card detection is also pretty screwed up. Balaji/Venkat,
can you guys look into that ? Probably making something generic using a
threaded IRQ handler ?
I mean, all the MMC
On 05/12/2012 05:49 PM, Linus Walleij wrote:
On Thu, May 10, 2012 at 7:05 PM, Stephen Warren swar...@wwwdotorg.org wrote:
Also, were you intending pinctrl-simple to actually be the GPIO
controller itself? That'd be another case that one might consider fairly
simple, but then extends to being
On Mon, May 14, 2012 at 11:37:43AM -0700, Tony Lindgren wrote:
* Tony Lindgren t...@atomide.com [120514 11:19]:
* Felipe Balbi ba...@ti.com [120514 11:04]:
That whole MMC card detection is also pretty screwed up. Balaji/Venkat,
can you guys look into that ? Probably making something
On Mon, 14 May 2012, Cousson, Benoit wrote:
Salut Thomas,
Sorry for the delay.
On 5/4/2012 5:59 PM, Thomas Petazzoni wrote:
Hello Benoit,
Le Fri, 23 Sep 2011 22:23:09 +0200,
Benoit Coussonb-cous...@ti.com a écrit :
Add SoC specific map_io function to be used by the generic
Mark A. Greer mgr...@animalcreek.com writes:
On Mon, May 14, 2012 at 11:20:58AM +0300, Igor Grinberg wrote:
Hi Mark,
Hi Igor.
Thanks for the great work!
On 05/12/12 00:12, Mark A. Greer wrote:
From: Mark A. Greer mgr...@animalcreek.com
The am35x family of SoCs has a Davinci EMAC
Vaibhav Hiremath hvaib...@ti.com writes:
From: Kevin Hilman khil...@ti.com
There are certain fields inside 'struct dpll_data' which are
included under ARCH_OMAP3 and ARCH_OMAP4 option, which makes it
difficult to use it for new devices like, am33xx, ti81xx, etc...
So remove the ifdef
Tomi Valkeinen tomi.valkei...@ti.com writes:
On Mon, 2012-05-14 at 08:36 +0100, Joe Woodward wrote:
Any news on this?
This thread seems to have gone a little quiet...
Hi,
I've been doing testing to understand the problem, but so far I don't
have any idea why things go wrong. I haven't
Actually, I was too hasty saying that this worked even with this
error. I can ping out from my board, but any higher level of traffic,
e.g. SSH into the box, falls over
The problems vanish when I disable MUSB DMA.
What gives?
I'm also seeing this on a variety of kernels, from 2.6.34
+Sekhar,
Mark A. Greer mgr...@animalcreek.com writes:
From: Mark A. Greer mgr...@animalcreek.com
Paul, Kevin,
These patches convert the davinci emac support for the am35x SoC
to use hwmod and add enable_hlt()/disable_hlt() calls to the
pm_runtime hooks for that driver.
Great. I didn't
On Mon, 2012-04-23 at 17:04 +0100, Russell King - ARM Linux wrote:
For the full text, please see
http://lists.arm.linux.org.uk/lurker/message/20120418.100954.7fa7acf8.en.html
This version contains updates for some of the comments received from the
previous round, and adds the OMAP1/2 MMC
On Thu, May 10, 2012 at 5:35 AM, Jon Hunter jon-hun...@ti.com wrote:
From: Jon Hunter jon-hun...@ti.com
This patch is based upon Ming Lei's patch to add runtime PM support for OMAP4
[1]. In Ming's original patch the CTI interrupts were being enabled during
runtime when the PMU was used but
Hello.
I develop driver to communicate to some chip via spi. Chip generate
interrupts in which i run workqueue. Inside workqueue's handler i need
to exchange data white chip again. Sometimes i got OOPS in spi_complete
as args == NULL. What can be the reason of this? SPI message .complete
and
On Tue, May 15, 2012 at 03:54:11, Hilman, Kevin wrote:
Vaibhav Hiremath hvaib...@ti.com writes:
From: Kevin Hilman khil...@ti.com
There are certain fields inside 'struct dpll_data' which are
included under ARCH_OMAP3 and ARCH_OMAP4 option, which makes it
difficult to use it for new
On Tue, May 8, 2012 at 5:21 AM, Kevin Hilman khil...@ti.com wrote:
Rafael,
Keerthy j-keer...@ti.com writes:
From: J Keerthy j-keer...@ti.com
AVS(Adaptive Voltage Scaling) is a power management technique which
controls the operating voltage of a device in order to optimize (i.e. reduce)
82 matches
Mail list logo
