On Mon, Feb 18, 2013 at 21:41:49, Kevin Hilman wrote:
[...]
By default these IPs don't have MSTANDBY asserted.
When you say by default, I guess you mean after reset (and/or context
loss), right?
Yes
When a low power transition happens, the peripheral power domain loses
context and
OMAP UART IP needs manual idle modes based on functional state of the
IP. Currently this is handled by the driver with function pointers
implemented in platform code.
This however breaks in case of device tree because of missing
idle handling.
The series tries to address the issue and tries to
From: Rajendra Nayak rna...@ti.com
_HWMOD_WAKEUP_ENABLED is currently unused across the hwmod
framework. Just get rid of it, so we have one less flag to
worry about.
Tested-by: Vaibhav Bedia vaibhav.be...@ti.com
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Santosh Shilimkar
From: Rajendra Nayak rna...@ti.com
_enable_wakeup() and _disable_wakeup() are expected to program the
OCP_SYSCONFIG.ENAWAKEUP bit. Get rid of the additional sidle/mstandby
programming in them, as its confusing (this is expected to be handled
elsewhere as part of _enable_sysc()/__idle_sysc()) and
From: Rajendra Nayak rna...@ti.com
Get rid of all complexities around when to enable OCP_SYSCONFIG.ENAWAKEUP.
It should be safe to have this set *always* for all IP blocks which
have this control. It should be a *dont care* when the IP is in
NO/FORCE modes of sidle/mstandby. As for the
From: Rajendra Nayak rna...@ti.com
Some IPs (like UART) need the sidle mode to be controlled in SW only
while they are active. Once they go inactive, they need the IP to be
put back in HW control so they are also wakeup capable.
The flag HWMOD_SWSUP_SIDLE takes care of IPs which need the sidle
OMAP UART IP needs software control for slave idle modes based on functional
state of the IP. i.e The IP slave idle settings should be set to 'noidle' when
being used and then put back to 'smart_idle' when unused. Currently this is
handled by the driver with function pointers implemented in
UART IP slave idle handling now taken care by runtime pm backend(hwmod layer)
so remove the hackery from the driver.
Tested-by: Vaibhav Bedia vaibhav.be...@ti.com
Tested-by: Sourav Poddar sourav.pod...@ti.com
Signed-off-by: Rajendra nayak rna...@ti.com
Signed-off-by: Santosh Shilimkar
UART IP idle handling now taken care by runtime pm backend(hwmod) indirectly
and OMAP serial driver is also cleaned up accordingly.
So remove the un-used slave idle platforms hooks now.
Tested-by: Vaibhav Bedia vaibhav.be...@ti.com
Tested-by: Sourav Poddar sourav.pod...@ti.com
Signed-off-by:
With the OMAP serial driver sysc cleanup patches in this series, we can
now remove the hwmod external apis for sysc fiddling.
While at this, also remove unused sysc auto idle api from hwmod code.
Tested-by: Vaibhav Bedia vaibhav.be...@ti.com
Tested-by: Sourav Poddar sourav.pod...@ti.com
+ Felipe ( Sorry I missed you in CC list)
On Wednesday 20 February 2013 03:27 PM, Santosh Shilimkar wrote:
OMAP UART IP needs manual idle modes based on functional state of the
IP. Currently this is handled by the driver with function pointers
implemented in platform code.
This however breaks
On Wed, Feb 20, 2013 at 03:27:44PM +0530, Santosh Shilimkar wrote:
OMAP UART IP needs manual idle modes based on functional state of the
IP. Currently this is handled by the driver with function pointers
implemented in platform code.
Up until now, the nightly test builds have included a load
On Wednesday 20 February 2013 03:44 PM, Russell King - ARM Linux wrote:
On Wed, Feb 20, 2013 at 03:27:44PM +0530, Santosh Shilimkar wrote:
OMAP UART IP needs manual idle modes based on functional state of the
IP. Currently this is handled by the driver with function pointers
implemented in
On Wed, Feb 20, 2013 at 03:53:22PM +0530, Santosh Shilimkar wrote:
Actually the clean-up will remove the serial driver dependency with
idle handling. Infact DMA support need not care about idle handling
anymore.
How is that so? Looking back at the driver source when it did have full
DMA
On Sat, Feb 16, 2013 at 12:49 PM, Anil Kumar anilk...@gmail.com wrote:
DevKit8000 is a beagle board clone from Timll, sold by
armkits.com. The DevKit8000 has RS232 serial port, LCD, DVI-D,
S-Video, Ethernet, SD/MMC, keyboard, camera, SPI, I2C, USB and
JTAG interface.
This patch adds the
Hi Paul, Tony,
how do you guys want to handle PWM's Time Base clocks which are enabled
via control module ?
They're controlled via offset 0x664 (pwmss_ctrl). Page 793 of AM33xx's
TRM has more information:
Table 9-42. pwmss_ctrl Register Field Descriptions
Bit Field TypeReset
+Avinash
On Wed, Feb 20, 2013 at 18:06:24, Balbi, Felipe wrote:
Hi Paul, Tony,
how do you guys want to handle PWM's Time Base clocks which are enabled
via control module ?
They're controlled via offset 0x664 (pwmss_ctrl). Page 793 of AM33xx's
TRM has more information:
Avinash has
Hi Manish,
On Wed, Feb 20, 2013 at 5:28 PM, Manish Badarkhe
badarkhe.man...@gmail.com wrote:
On Sat, Feb 16, 2013 at 12:49 PM, Anil Kumar anilk...@gmail.com wrote:
DevKit8000 is a beagle board clone from Timll, sold by
armkits.com. The DevKit8000 has RS232 serial port, LCD, DVI-D,
S-Video,
Hi,
On Wed, Feb 20, 2013 at 01:54:46PM +0100, Bedia, Vaibhav wrote:
+Avinash
On Wed, Feb 20, 2013 at 18:06:24, Balbi, Felipe wrote:
Hi Paul, Tony,
how do you guys want to handle PWM's Time Base clocks which are enabled
via control module ?
They're controlled via offset 0x664
On Wednesday 20 February 2013 05:21 PM, Russell King - ARM Linux wrote:
On Wed, Feb 20, 2013 at 03:53:22PM +0530, Santosh Shilimkar wrote:
Actually the clean-up will remove the serial driver dependency with
idle handling. Infact DMA support need not care about idle handling
anymore.
How is
DevKit8000 is a beagle board clone from Timll, sold by
armkits.com. The DevKit8000 has RS232 serial port, LCD, DVI-D,
S-Video, Ethernet, SD/MMC, keyboard, camera, SPI, I2C, USB and
JTAG interface.
This patch adds the basic DT support for devkit8000. At this time, Information
of twl4030 (PMIC),
Bedia, Vaibhav vaibhav.be...@ti.com writes:
[...]
IMO, this would be a much cleaner implementation if you just created a
small driver for the wkup_m3. You're already doing a bunch of
driver-like stuff for it (requesting base/IRQs, mapping regions,
firmware, etc.) I think this should
Hi Anil
On Wed, Feb 20, 2013 at 7:14 PM, Anil Kumar anilk...@gmail.com wrote:
DevKit8000 is a beagle board clone from Timll, sold by
armkits.com. The DevKit8000 has RS232 serial port, LCD, DVI-D,
S-Video, Ethernet, SD/MMC, keyboard, camera, SPI, I2C, USB and
JTAG interface.
This patch adds
This series tries to clean-up the some of the areas like OMAP4 static
deps, FIQ usage in OMAP code, SMP code. The patches are self explanatory
and quite independent but since I had them mantained in a branch, am
sending them together not to loose track of them.
They have been tested on OMAP4 and
From: Tero Kristo t-kri...@ti.com
Simplifies code and also allows the re-use as is on OMAP5 devices.
Signed-off-by: Tero Kristo t-kri...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/omap4-sar-layout.h | 14 +++---
1 file changed, 7
On OMAP platform, FIQ is reserved for secure environment only. If at all
the FIQ needs to be disabled, it involves going through security
API call. Hence the local_fiq_[enable/disable]() in the OMAP code is bogus.
So just get rid of it.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
This was added with intial port where OMAP PM support wasn't existing
and only simple WFI based hooks were used.
This should have been cleaned up while adding the PM support but some
how fall through cracks.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
The smp_wmb() here is out of placed and redundant. So remove it. It is
a left over of the pain_release cleanup mostly.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/omap-smp.c |2 --
1 file changed, 2 deletions(-)
diff --git
UART driver slave idle issue has been taken care by driver using hwmod
framework.
So we can now ger rid off the L4 per clockdomain static dependency with
MPU which was used to wrok around UART wakeup and console sluggishnesh issue
on OMAP4 SOCs.
Cc: Kevin Hilman khil...@deeprootsystems.com
On OMAP platform, FIQ is reserved for secure environment only. If at all
the FIQ needs to be disabled, it involves going through security
API call. Hence the local_fiq_[enable/disable]() in the OMAP code is bogus.
So just get rid of it.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
With commit bfd6d021 {ARM: OMAP3+: Implement timer workaround for errata
i103 and i767}, the sync and gptimer synchronization errata got fixed.
Hence the l4_wakeup static dependency with MPU can can be removed
now. Static dependency was one of the proposed workaround but from
power savings
Move the secondary CPU wakeup prepare code under smp_prepare_cpus(). While at
it drop the un-necessary sev() and barrier which was under prepare code.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/omap-smp.c | 51
1
This was borrowed from ARM versatile code with pen_release mechanism but since
OMAP uses hardware register based synchronisation, pen_release stuff was
dropped. Unfortunately the cacheflush wasn't dropped along with it.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
Santosh Shilimkar santosh.shilim...@ti.com writes:
UART IP slave idle handling now taken care by runtime pm backend(hwmod layer)
so remove the hackery from the driver.
Tested-by: Vaibhav Bedia vaibhav.be...@ti.com
Tested-by: Sourav Poddar sourav.pod...@ti.com
Signed-off-by: Rajendra nayak
Here are few OMAP5 updates discovered during es2.0 silicon validation.
Tested on OMAP5430 and OMAP5432 devices after applying out of tree
datafiles for OMAP5.
Rajendra Nayak (1):
ARM: OMAP5: clock: No Freqsel on OMAP5 devices
Santosh Shilimkar (6):
ARM: OMAP5: Update SOC id detection code
Update OMAP5 ES2 idcode and make ES2 as default detection.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/id.c | 16 +---
arch/arm/mach-omap2/soc.h |2 ++
2 files changed, 15 insertions(+), 3 deletions(-)
diff --git
OMAP5 clockdata has different sys clock clock node name. Fix the timer code
to take care of it.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/timer.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c
From: Tero Kristo t-kri...@ti.com
Make use of 'prm_base' so that prm read_inst/write_inst can work on
OMAP5 devices.
Signed-off-by: Tero Kristo t-kri...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/prm44xx.c |4 ++--
1 file changed, 2
Update SAR RAM base address for OMAP5 based devices.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/omap4-common.c | 10 --
arch/arm/mach-omap2/omap54xx.h |1 +
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git
On OMAP5 es2 WakeupGen SAR register layout offset have changed.
Update the layout accordingly.
Reported-by: Menon, Nishanth n...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/omap4-sar-layout.h | 14 +++---
1 file changed, 7 insertions(+), 7
Errata i688 is also applicable for OMAP5 based devices. Update the
code so that it can be enabled on OMAP5 devices.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/Kconfig |2 +-
arch/arm/mach-omap2/io.c|9 +
2 files changed, 10
Allow prm init to success on OMAP5 SOCs.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/prm44xx.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/prm44xx.c b/arch/arm/mach-omap2/prm44xx.c
index c05a343..1aae198 100644
From: Rajendra Nayak rna...@ti.com
OMAP5 does not have freqsel either, so add the missing
checks for !soc_is_omap54xx()
Reported-by: Archit Taneja arc...@ti.com
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/dpll3xxx.c |6 --
1 file changed, 4 insertions(+), 2
Hi,
On Wed, Feb 20, 2013 at 08:57:07PM +0530, Santosh Shilimkar wrote:
case 0xb998:
switch (rev) {
case 0:
- default:
omap_revision = OMAP5432_REV_ES1_0;
+ break;
+ case 1:
+
On Wed, Feb 20, 2013 at 08:57:09PM +0530, Santosh Shilimkar wrote:
Allow prm init to success on OMAP5 SOCs.
s/success/succeed/
--
balbi
signature.asc
Description: Digital signature
Few updates for OMAP5 found during testing OMAP5 DT builds. Couple
of patches were already posted on the list. The series also contains
a patch which adds DMA request, IRQ lines and IO address space
DT extraction support to hwmod code so that we can get rid of
such information from hwmod data
On OMAP5 to detect invalid/bad memory accesses, 16MB of DDR is used as a trap.
Hence available memory for linux OS is 2032 MB on boards popullated with 2 GB
memory.
Cc: Benoit Cousson b-cous...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/boot/dts/omap5-evm.dts
Add missing OMAP keypad reg property information.
Cc: Benoit Cousson b-cous...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/boot/dts/omap5.dtsi |1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
GIC is not part of OCP space so move the gic dt node out of ocp
dt address space.
Cc: Marc Zyngier marc.zyng...@arm.com
Cc: Benoit Cousson b-cous...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/boot/dts/omap5.dtsi | 19 +++
1 file changed, 11
It has been decided to not duplicate banked modules dt nodes and that is
how the current arch timer dt extraction code is.
Update the OMAP5 dt file accordingly.
Cc: Marc Zyngier marc.zyng...@arm.com
Cc: Benoit Cousson b-cous...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
To be able to run kernel in HYP mode, virtual timer and gic node information
needs to be popullated.
Cc: Marc Zyngier marc.zyng...@arm.com
Cc: Benoit Cousson b-cous...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/boot/dts/omap5.dtsi |8 ++--
1 file
Patch adds the code for extracting the module ocp address space from device
tree blob in case the hwmod address space look up fails.
The idea is to remove the address space data from hwmod and extract it from
DT blob.
Cc: Benoit Cousson b-cous...@ti.com
Signed-off-by: Rajendra Nayak
From: Rajendra Nayak rna...@ti.com
Specify both secure as well as nonsecure PPI IRQ for arch
timer. This fixes the following errors seen on DT OMAP5 boot..
[0.00] arch_timer: No interrupt available, giving up
Cc: Marc Zyngier marc.zyng...@arm.com
Cc: Benoit Cousson b-cous...@ti.com
Patch adds the OCP address space for all missing hwmod from existing
DT file. Note that the compatible isn't added by purpose to ensure that for
these hwmod, devices are not getting created.
Cc: Benoit Cousson b-cous...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
Hi,
On Wed, Feb 20, 2013 at 09:08:54PM +0530, Santosh Shilimkar wrote:
Patch adds the code for extracting the module ocp address space from device
tree blob in case the hwmod address space look up fails.
IMHO you should lookup on DT first and if that fails try hwmod ;-)
--
balbi
On Wednesday 20 February 2013 08:54 PM, Kevin Hilman wrote:
Santosh Shilimkar santosh.shilim...@ti.com writes:
UART IP slave idle handling now taken care by runtime pm backend(hwmod layer)
so remove the hackery from the driver.
Tested-by: Vaibhav Bedia vaibhav.be...@ti.com
Tested-by: Sourav
On Wednesday 20 February 2013 09:12 PM, Felipe Balbi wrote:
Hi,
On Wed, Feb 20, 2013 at 09:08:54PM +0530, Santosh Shilimkar wrote:
Patch adds the code for extracting the module ocp address space from device
tree blob in case the hwmod address space look up fails.
IMHO you should lookup on DT
On 02/19/2013 06:36 PM, Ezequiel Garcia wrote:
Hi Jon,
On Fri, Feb 15, 2013 at 02:08:08PM -0600, Jon Hunter wrote:
On 02/15/2013 01:53 PM, Paul Walmsley wrote:
Hi,
On Fri, 15 Feb 2013, Ezequiel Garcia wrote:
I imagine one of the biggest issues is GPMC's dependency on
hwmod code. Can
On Wednesday 20 February 2013 08:59 PM, Felipe Balbi wrote:
Hi,
On Wed, Feb 20, 2013 at 08:57:07PM +0530, Santosh Shilimkar wrote:
case 0xb998:
switch (rev) {
case 0:
- default:
omap_revision = OMAP5432_REV_ES1_0;
+
Hi,
* Santosh Shilimkar santosh.shilim...@ti.com [130220 07:21]:
On OMAP platform, FIQ is reserved for secure environment only. If at all
the FIQ needs to be disabled, it involves going through security
API call. Hence the local_fiq_[enable/disable]() in the OMAP code is bogus.
So just get
On Wednesday 20 February 2013 09:39 PM, Tony Lindgren wrote:
Hi,
* Santosh Shilimkar santosh.shilim...@ti.com [130220 07:21]:
On OMAP platform, FIQ is reserved for secure environment only. If at all
the FIQ needs to be disabled, it involves going through security
API call. Hence the
Hi,
On Wed, Feb 20, 2013 at 09:33:32PM +0530, Santosh Shilimkar wrote:
default:
/* Unknown default to latest silicon rev as default*/
- omap_revision = OMAP5430_REV_ES1_0;
+ omap_revision = OMAP5430_REV_ES2_0;
how about we default to 0x ? That's
On Wednesday 20 February 2013 09:57 PM, Felipe Balbi wrote:
Hi,
On Wed, Feb 20, 2013 at 09:33:32PM +0530, Santosh Shilimkar wrote:
default:
/* Unknown default to latest silicon rev as default*/
- omap_revision = OMAP5430_REV_ES1_0;
+
On Wed, Feb 20, 2013 at 10:01:15PM +0530, Santosh Shilimkar wrote:
On Wednesday 20 February 2013 09:57 PM, Felipe Balbi wrote:
Hi,
On Wed, Feb 20, 2013 at 09:33:32PM +0530, Santosh Shilimkar wrote:
default:
/* Unknown default to latest silicon rev as default*/
-
MMC looks sick - not sure what's going on with it though. mmc0 I believe
is the onboard eMMC, mmc1 is the external SD card with the rootfs. Any
ideas?
[0.00] Linux version 3.8.0-rc7+ (r...@rmk-pc.arm.linux.org.uk) (gcc
version 4.5.4 (GCC) ) #468 SMP Wed Feb 20 16:44:50 GMT 2013
[
Hi,
On Wed, Feb 20 2013, Russell King - ARM Linux wrote:
MMC looks sick - not sure what's going on with it though. mmc0 I believe
is the onboard eMMC, mmc1 is the external SD card with the rootfs. Any
ideas?
Is this with 3.8 final, or mmc-next?
[1.253265] mmc0: new high speed MMC card
On Thu, 2013-02-21 at 00:39 +0800, buyitian wrote:
i am confused about my test. in one device driver,
i put below code:
printk(start to test test jiffies\n);
local_irq_save(flags);
jf1 = jiffies; // read jiffies first time
// hold cpu for about 2 seconds(do some
On Wed, Feb 20, 2013 at 10:54:41PM +0530, anish kumar wrote:
On Thu, 2013-02-21 at 00:39 +0800, buyitian wrote:
i am confused about my test. in one device driver,
i put below code:
printk(start to test test jiffies\n);
local_irq_save(flags);
jf1 = jiffies; // read
Hi,
I think Vaibhav has covered most of the ground here, but just a few
comments:
On Fri, 15 Feb 2013, Felipe Balbi wrote:
On Thu, Feb 14, 2013 at 08:47:53PM +, Paul Walmsley wrote:
Drivers shouldn't touch their IP block's SYSCONFIG registers. They don't
why not ? It's part of the
On Wed, 2013-02-20 at 17:30 +, Russell King - ARM Linux wrote:
On Wed, Feb 20, 2013 at 10:54:41PM +0530, anish kumar wrote:
On Thu, 2013-02-21 at 00:39 +0800, buyitian wrote:
i am confused about my test. in one device driver,
i put below code:
printk(start to test test
Hi,
On Wed, Feb 20, 2013 at 05:38:49PM +, Paul Walmsley wrote:
Drivers shouldn't touch their IP block's SYSCONFIG registers. They don't
just now I noticed this fun fact:
driver's should touch *their* SYSCONFIG registers
You're stating yourself that SYSCONFIG belongs to the IP and the
Hi,
On Wed, 20 Feb 2013, Felipe Balbi wrote:
On Wed, Feb 20, 2013 at 05:38:49PM +, Paul Walmsley wrote:
Drivers shouldn't touch their IP block's SYSCONFIG registers. They
don't
just now I noticed this fun fact:
driver's should touch *their* SYSCONFIG registers
You're
On Wed, Feb 20, 2013 at 09:16:38PM +0200, Felipe Balbi wrote:
Also, IMHO reset should always be done during probe() so driver can be
dead sure that we're starting from a known state. This is even more
important for the complex IPs which are licensed from RTL vendors and
are used in different
On Wed, Feb 20, 2013 at 12:15:51PM -0500, Chris Ball wrote:
Hi,
On Wed, Feb 20 2013, Russell King - ARM Linux wrote:
MMC looks sick - not sure what's going on with it though. mmc0 I believe
is the onboard eMMC, mmc1 is the external SD card with the rootfs. Any
ideas?
Is this with
Hello,
I've been spinning some work-in-progress patches for FIT build support
in the kernel.
With the move to multiplatform support on OMAP, I feel it is a good
time to add FIT support, also looking at the proliferating number of
dtbs, as it is a nice way
Currently the following is what I
On 02/20/2013 06:37 PM, Joel A Fernandes wrote:
Hello,
I've been spinning some work-in-progress patches for FIT build support
in the kernel.
With the move to multiplatform support on OMAP, I feel it is a good
time to add FIT support, also looking at the proliferating number of
dtbs, as it
On Wed, Feb 20, 2013 at 10:54 PM, anish kumar
anish198519851...@gmail.com wrote:
On Thu, 2013-02-21 at 00:39 +0800, buyitian wrote:
i am confused about my test. in one device driver,
i put below code:
printk(start to test test jiffies\n);
local_irq_save(flags);
jf1 = jiffies;
On Wed, Feb 20, 2013 at 10:26 PM, Stephen Warren swar...@wwwdotorg.org wrote:
On 02/20/2013 06:37 PM, Joel A Fernandes wrote:
Hello,
I've been spinning some work-in-progress patches for FIT build support
in the kernel.
With the move to multiplatform support on OMAP, I feel it is a good
time
78 matches
Mail list logo
