On Thu, Jan 06, 2011 at 07:04:50PM -0800, Tony Lindgren wrote:
> * Felipe Balbi [110104 22:37]:
> > Hi,
> >
> > On Tue, Jan 04, 2011 at 11:14:00AM -0800, Tony Lindgren wrote:
> > > I think there's been some patches related to this to get rid
> > > of NR_IRQS? Might be worth taking a look at those
Hello Jean,
On Wed, Jan 05, 2011 at 07:49:02PM +0100, ext jean.pi...@newoldbits.com wrote:
> From: Jean Pihet
>
> Provides documentation for the following:
> - the new power trace API,
> - the old (legacy) power trace API,
> - the DEPRECATED Kconfig option usage.
>
> Signed-off-by: Jean Pihet
* Russell King - ARM Linux [110106 15:51]:
> On Thu, Jan 06, 2011 at 08:51:07PM +, Russell King - ARM Linux wrote:
> >
> > OMAP44XX SDP # setenv bootargs 'root=/dev/mmcblk0p2 rw mem=512M vmalloc=1G
> > console=ttyO2,115200n8 rootdelay=2'
> > OMAP44XX SDP # mmcinit 0
> > OMAP44XX SDP # fatloa
From: Senthilvadivu Guruswamy
DSS IRQ number can be obtained from platform_get_irq(). This API in turn
picks the right IRQ number belonging to HW IP from the hwmod database.
So hardcoding of IRQ number could be removed.
Signed-off-by: Senthilvadivu Guruswamy
---
drivers/video/omap2/dss/dss.c
From: Senthilvadivu Guruswamy
Hwmod adaptation design requires each of the DSS HW IP to be a platform driver.
So a platform_driver for DSI is created and init exit methods are moved from
core.c
to its driver probe,remove. pdev member has to be maintained by its own drivers.
Also, vdds_dsi regul
This patch replaces printk's in the init/probe functions to dev_dbg
for boot time optimization.
Signed-off-by: Sumit Semwal
---
drivers/video/omap2/dss/dispc.c |2 +-
drivers/video/omap2/dss/dsi.c |2 +-
drivers/video/omap2/dss/rfbi.c |2 +-
drivers/video/omap2/dss/venc.c |2
From: Senthilvadivu Guruswamy
DSS, DISPC, DSI, RFBI, VENC baseaddr can be obtained from
platform_get_resource().
This API in turn picks the right silicon baseaddr from the hwmod database.
So hardcoding of base addr could be removed.
Signed-off-by: Senthilvadivu Guruswamy
---
drivers/video/oma
From: Senthilvadivu Guruswamy
Hwmod adaptation design requires each of the DSS HW IP to be a platform driver.
So a platform_driver for VENC is created and init exit methods are moved from
core.c
to its driver probe,remove. pdev member has to be maintained by its own drivers.
Also, venc_vdda_dac
From: Senthilvadivu Guruswamy
All clock management is moved to dss platform driver. clk_get/put APIs use
dss device instead of core platform device.
Hwmod adaptation design requires each of the DSS HW IP to be a platform driver.
So the device name is changed from omap_display to omap_dss in 2420
From: Senthilvadivu Guruswamy
Hwmod adaptation design requires each of the DSS HW IP to be a platform driver.
So a platform_driver for RFBI is created and init exit methods are moved from
core.c
to its driver probe,remove. pdev member has to be maintained by its own drivers.
RFBI platform drive
From: Senthilvadivu Guruswamy
Hwmod adaptation design requires each of the DSS HW IP to be a platform driver.
So a platform_driver for DISPC is created and init exit methods are moved from
core.c
to its driver probe,remove. pdev member has to be maintained by its own drivers.
DISPC platform dri
From: Senthilvadivu Guruswamy
This patch updated board files to replace platform_device_register or
platform_add_devices of DSS with omap_display_init(). This moves away
registration of DSS from board files into a common place.
Signed-off-by: Senthilvadivu Guruswamy
Signed-off-by: Sumit Semwal
From: Senthilvadivu Guruswamy
Looks up the hwmod database for each of the given DSS HW IP and builds
omap_device which inturn does the platform device register for each of DSS HW IP
Signed-off-by: Senthilvadivu Guruswamy
Signed-off-by: Sumit Semwal
---
arch/arm/mach-omap2/display.c
From: Senthilvadivu Guruswamy
Hwmod adaptation design requires each of the DSS HW IP to be a platform driver.
So a platform_driver of DSS is created and init exit methods are moved from
core.c
to its driver probe,remove. pdev member has to be maintained by its own drivers.
DSS platform driver i
From: Senthilvadivu Guruswamy
Use driver name in regulator inits needed for display instead of using device
structure name.
Signed-off-by: Senthilvadivu Guruswamy
---
arch/arm/mach-omap2/board-3430sdp.c | 11 +++
arch/arm/mach-omap2/board-cm-t35.c | 12
arch
A new file display.c is introduced for display driver init, which adds a
function
omap_display_init to do the DSS driver registration. This is the first step in
moving
away registration of DSS from board files into a common place.
Signed-off-by: Senthilvadivu Guruswamy
Signed-off-by: Sumit Semw
From: Senthilvadivu Guruswamy
Hwmod needs database of all IPs in a system. This patch generates the hwmod
database for Display Sub System applicable for OMAP3430-ES2 onwards and
OMAP36xx. DSS is also considered as an IP as DISPC, RFBI and named as dss_dss.
For all the IP modules in DSS, same clo
From: Senthilvadivu Guruswamy
Change the driver name from omapdss to omap_display as the driver takes care of
the display devices ie number of panels, type of panels available in the
platform. Change the device name in the board files and 2420,2430,3xxx clock
files from omapdss to omap_display t
From: Senthilvadivu Guruswamy
Hwmod needs database of all IPs in a system. This patch generates the hwmod
database for OMAP2430 Display Sub System. Since DSS is also considered as an
IP as DISPC, RFBI, name it as dss_dss.
Signed-off-by: Senthilvadivu Guruswamy
Acked-by: Benoit Cousson
---
arc
v4 of the DSS hwmod patch series focusses on fixing the review comments. OMAP4
hwmod support will be posted after the acceptance of this basic change in
the dss2 design.
This patch series decouples the "Clocks for DSS in hwmod adaptation" changes
from this series. Another series would be posted
From: Senthilvadivu Guruswamy
Hwmod needs database of all IPs in a system. This patch generates the hwmod
database for OMAP2420 Display Sub System,. Since DSS is also considered as an
IP as DISPC, RFBI, name it as dss_dss.
Signed-off-by: Senthilvadivu Guruswamy
Acked-by: Benoit Cousson
---
ar
* Felipe Balbi [110104 22:37]:
> Hi,
>
> On Tue, Jan 04, 2011 at 11:14:00AM -0800, Tony Lindgren wrote:
> > I think there's been some patches related to this to get rid
> > of NR_IRQS? Might be worth taking a look at those first as it's
> > a generic solution.
>
> Yeah, one way would be to use S
* Pedanekar, Hemant [110105 15:59]:
> linux-omap-ow...@vger.kernel.org wrote on :
>
> > Tony Lindgren wrote on Wednesday, January 05, 2011 4:56 AM:
> >
> >> * Paul Walmsley [110104 09:48]:
> >>> On Tue, 4 Jan 2011, Pedanekar, Hemant wrote:
> >>>
> Looking at above, it seems another config
Hi Linus,
Please pull omap changes from:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git
omap-for-linus
The interesting changes for this merge window are:
- Start using common code for omap hardware modules (hwmod) for resetting,
enabling, and idling the hardare modul
* Thara Gopinath [110105 08:23]:
> +#define OMAP1_MPU_CLK"mpu"
> +#define OMAP2_MPU_CLK"virt_prcm_set"
> +#define OMAP3_MPU_CLK"dpll1_ck"
...
> static int __init omap_cpufreq_init(void)
> {
> + if (cpu_class_is_omap1()) {
> + mpu
On Thu, Jan 06, 2011 at 08:51:07PM +, Russell King - ARM Linux wrote:
> On Thu, Jan 06, 2011 at 12:34:32PM -0800, Tony Lindgren wrote:
> > * Tony Lindgren [110106 11:52]:
> > > --- a/arch/arm/boot/compressed/head.S
> > > +++ b/arch/arm/boot/compressed/head.S
> > > @@ -71,6 +71,23 @@ wait:
* Kevin Hilman [110104 16:39]:
> Nishanth Menon writes:
>
> > omap_pm_runtime_suspend and omap_pm_runtime_resume are used
> > as function pointers and does not really need to be exposed
> > to the world.
> >
> > Fixes sparse warnings:
> > arch/arm/mach-omap2/pm_bus.c:23:5: warning: symbol
> > '
David Lambert writes:
> Adds HWMOD entries for the OMAP DMIC driver and creates
> a platform device. The HWMOD entires define the system
> resource requirements for the drvier such as DMA addresses, channels,
> and IRQ's. Placing this information in the HWMOD database allows
> for more generic
Kevin Hilman writes:
> writes:
>
>> Hi,
>>
>> Kevin Hilman [khil...@ti.com]:
>>> Aaro Koskinen writes:
>>>
>>> > Make !CONFIG_SUSPEND init declarations identical on all OMAPs and
>>> > eliminate some ifdefs.
>>> >
>>> > Signed-off-by: Aaro Koskinen
>>>
>>> I like this solution, but it introduc
On Thu, Jan 06, 2011 at 08:00:39AM -0600, David Lambert wrote:
> This creates the DMIC codec platform devices.
>
> The platform devices create an instance of the driver during boot up.
>
> Signed-off-by: David Lambert
Acked-by: Mark Brown
though:
> +static struct platform_device codec_dmic0
On Thu, Jan 06, 2011 at 08:00:38AM -0600, David Lambert wrote:
> Adds HWMOD entries for the OMAP DMIC driver and creates
> a platform device. The HWMOD entires define the system
> resource requirements for the drvier such as DMA addresses, channels,
> and IRQ's. Placing this information in the HW
On Thu, Jan 06, 2011 at 08:00:36AM -0600, David Lambert wrote:
> @@ -103,6 +106,7 @@ config SND_OMAP_SOC_SDP4430
> depends on TWL4030_CORE && SND_OMAP_SOC && MACH_OMAP_4430SDP
> select SND_OMAP_SOC_MCPDM
> select SND_SOC_TWL6040
> + select SND_SOC_DMIC
> help
>
Nishanth Menon writes:
> Hi,
> As discussed in the threads:
> http://thread.gmane.org/gmane.linux.ports.arm.omap/47807/
> http://marc.info/?t=12154003084&r=1&w=2
>
> here is the split up series with commit message after discussion:
> http://www.beagleboard.org/irclogs/index.php?date=2011-01-0
* Aaro Koskinen [110105 08:39]:
> memcpy() copies 8 bytes too much (omap_mux_entry vs. omap_mux). Correct
> by replacing memcpy() with struct assignment, which is safer.
Thanks will queue as a fix after the merge window.
Tony
> Signed-off-by: Aaro Koskinen
> ---
> arch/arm/mach-omap2/mux.c |
On Thu, 2011-01-06 at 15:21 -0500, Mark Brown wrote:
> On Thu, Jan 06, 2011 at 07:04:30AM -0800, Guenter Roeck wrote:
> > On Thu, Jan 06, 2011 at 07:07:13AM -0500, Mark Brown wrote:
>
> > > Why? It's not like hwmon has an unreasonably large core or similar.
>
> > Because it creates an unnecessar
Nishanth Menon writes:
> Kevin Hilman had written, on 01/06/2011 12:38 PM, the following:
> [..]
>> Feel free to break it up if you prefer, but IMO it would be mergable as
> just for the record, posted the same here:
> http://marc.info/?l=linux-omap&m=129434370207879&w=2
Thanks, and this is even
On 01/06/11 13:16, Andrew Morton wrote:
> On Thu, 6 Jan 2011 13:08:56 -0800
> Randy Dunlap wrote:
>
>> On Thu, 6 Jan 2011 13:04:40 -0800 Andrew Morton wrote:
>>
>>> On Thu, 9 Dec 2010 14:41:50 +0100
>>> Janusz Krzysztofik wrote:
>>>
+static DEVICE_ATTR(invert, 0644, bl_trig_invert_show,
>>
On Thu, 6 Jan 2011 13:08:56 -0800
Randy Dunlap wrote:
> On Thu, 6 Jan 2011 13:04:40 -0800 Andrew Morton wrote:
>
> > On Thu, 9 Dec 2010 14:41:50 +0100
> > Janusz Krzysztofik wrote:
> >
> > > +static DEVICE_ATTR(invert, 0644, bl_trig_invert_show,
> > > bl_trig_invert_store);
> >
> > This new
On Thu, 6 Jan 2011 13:04:40 -0800 Andrew Morton wrote:
> On Thu, 9 Dec 2010 14:41:50 +0100
> Janusz Krzysztofik wrote:
>
> > +static DEVICE_ATTR(invert, 0644, bl_trig_invert_show,
> > bl_trig_invert_store);
>
> This new sysfs file should be documented. Where would be an
> appropriate place fo
On Thu, Jan 06, 2011 at 08:51:07PM +, Russell King - ARM Linux wrote:
> We _really_ need a _decent_ boot loader on these boards, one which can
> do network booting _and_ can be configured to do so from bootup. SD
> cards just don't hack it for kernel development. It's a far too long-
> winded
On Thu, 9 Dec 2010 14:41:50 +0100
Janusz Krzysztofik wrote:
> This patch extends the LED backlight tirgger driver with an option that
> allows
> for inverting the trigger output polarity.
>
> With the invertion option provided, I (ab)use the backlight trigger for
> driving a LED that indicate
On Thu, Jan 06, 2011 at 12:34:32PM -0800, Tony Lindgren wrote:
> * Tony Lindgren [110106 11:52]:
> > --- a/arch/arm/boot/compressed/head.S
> > +++ b/arch/arm/boot/compressed/head.S
> > @@ -71,6 +71,23 @@ wait:mrc p14, 0, pc, c0, c1, 0
> > mov \rb, #0x5000
> >
* Russell King - ARM Linux [110106 12:32]:
> On Thu, Jan 06, 2011 at 10:20:23AM -0800, Tony Lindgren wrote:
> > * Russell King - ARM Linux [110106 10:00]:
> > > can't be in the BSS section?
> >
> > BSS works too, got a patch for that?
>
> Yes.
>
> sed -i '/\.pushsection \.data/,/\.popsection/
* Tony Lindgren [110106 11:52]:
> --- a/arch/arm/boot/compressed/head.S
> +++ b/arch/arm/boot/compressed/head.S
> @@ -71,6 +71,23 @@ wait: mrc p14, 0, pc, c0, c1, 0
> mov \rb, #0x5000
> add \rb, \rb, #0x4000 * CONFIG_S3C_LOWLEVEL_UART_PORT
>
On Thu, Jan 06, 2011 at 10:20:23AM -0800, Tony Lindgren wrote:
> * Russell King - ARM Linux [110106 10:00]:
> > On Thu, Jan 06, 2011 at 05:08:05PM +, Russell King - ARM Linux wrote:
> > > This looks like something's rather broken on OMAP4 too - even with the
> > > DEBUG_LL stuff enabled and my
Kevin Hilman had written, on 01/06/2011 12:38 PM, the following:
[..]
Feel free to break it up if you prefer, but IMO it would be mergable as
just for the record, posted the same here:
http://marc.info/?l=linux-omap&m=129434370207879&w=2
[..]
--
Regards,
Nishanth Menon
--
To unsubscribe from t
On Thu, Jan 06, 2011 at 07:04:30AM -0800, Guenter Roeck wrote:
> On Thu, Jan 06, 2011 at 07:07:13AM -0500, Mark Brown wrote:
> > Why? It's not like hwmon has an unreasonably large core or similar.
> Because it creates an unnecessary dependency, and because it is not hwmon's
> responsibility to
Thanks for splitting it up! Now I can work on the patches for xM rev C where
the pins changed again :)
Op 6 jan 2011, om 20:54 heeft Nishanth Menon het volgende geschreven:
> Hi,
> As discussed in the threads:
> http://thread.gmane.org/gmane.linux.ports.arm.omap/47807/
> http://marc.info/?t=1215
From: Koen Kooi
TFP410 DVI chip is used to provide display out.
this chip is controlled by 2 lines:
LDO which supplies the power is controlled over gpio + 2
and the enable of the chip itself is done over gpio + 1
NOTE: the LDO is necessary for LED, serial blocks as well.
GPIO + 1 was used to sen
Hi,
As discussed in the threads:
http://thread.gmane.org/gmane.linux.ports.arm.omap/47807/
http://marc.info/?t=12154003084&r=1&w=2
here is the split up series with commit message after discussion:
http://www.beagleboard.org/irclogs/index.php?date=2011-01-06#T19:12:21
Koen Kooi (3):
omap3: b
From: Koen Kooi
GPIO reset line for Beagle XM is different from vanilla beagle
so we populate it as part of gpio update routine.
Signed-off-by: Nishanth Menon
Signed-off-by: Koen Kooi
---
arch/arm/mach-omap2/board-omap3beagle.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
From: Koen Kooi
EHCI enable power pin is inverted (active high) in comparison
to vanilla beagle which is active low. Handle this case conditionally.
[...@ti.com: helped split up]
Signed-off-by: Nishanth Menon
Signed-off-by: Koen Kooi
---
arch/arm/mach-omap2/board-omap3beagle.c |9
You are correct. On the -xM over current is from the USB HUB driver as there
are four ports. So that gets detected by the USB hub device and reported back.
Gerald
-Original Message-
From: Koen Kooi [mailto:k...@dominion.thruhere.net]
Sent: Thursday, January 06, 2011 12:33 PM
To: Menon,
* Tony Lindgren [110106 10:20]:
> * Russell King - ARM Linux [110106 10:00]:
> > On Thu, Jan 06, 2011 at 05:08:05PM +, Russell King - ARM Linux wrote:
> >
> > And another thing: turning on DEBUG in the decompressor breaks the build
> > on OMAP:
> >
> > `.data' referenced in section `.text'
On Wed, 2011-01-05 at 16:22 -0800, Kevin Hilman wrote:
> checkpatch warns that pointers for certain structs should be const,
> and platform_suspend_ops is one of those structs. If you follow this
> suggestion you trade a checkpatch warning for a compiler warning of
> the form:
>
>warning: pas
Nishanth Menon writes:
> Kevin Hilman had written, on 01/06/2011 12:15 PM, the following:
>> Koen Kooi writes:
>>
>>> Op 6 jan 2011, om 16:43 heeft Brad Parker het volgende geschreven:
>>>
It's probably expected, but I can't get the EHCI USB port to work
on a beagle board XM (36xx) us
Op 6 jan 2011, om 19:29 heeft Nishanth Menon het volgende geschreven:
> Koen,
> Apologies on a late response.
>
> Koen Kooi had written, on 12/19/2010 08:42 AM, the following:
> [...]
>> diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
>> b/arch/arm/mach-omap2/board-omap3beagle.c
>> index f
Mika Westerberg writes:
> Hi Kevin,
>
> On Wed, Jan 05, 2011 at 08:54:48AM -0800, Kevin Hilman wrote:
>>
>> I had assumed it was recent changes since the patch didn't apply
>> cleanly, but am glad to be wrong. :)
>
> The patch should apply cleanly on the latest mainline. Do you want me to
> reba
Koen,
Apologies on a late response.
Koen Kooi had written, on 12/19/2010 08:42 AM, the following:
[...]
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index f1a8ede..4756ac7 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-
On Thu, 6 Jan 2011, Kevin Hilman wrote:
> Koen Kooi writes:
>
> > Op 6 jan 2011, om 16:43 heeft Brad Parker het volgende geschreven:
> >
> >> It's probably expected, but I can't get the EHCI USB port to work
> >> on a beagle board XM (36xx) using the current omap tree.
> >>
> >> It this most l
Paul Walmsley writes:
> On Wed, 5 Jan 2011, Kevin Hilman wrote:
>
>> Santosh Shilimkar writes:
>>
>> > struct clockdomain member clktrctrl_mask is available for only for OMAP2
>> > and OMAP3 architectures. Technially it is also used only for these archs
>> > but this breaks the build with custo
* Russell King - ARM Linux [110106 10:17]:
> On Thu, Jan 06, 2011 at 06:00:30PM +, Russell King - ARM Linux wrote:
> > Therefore, I believe the debugging address calculation stuff in
> > arch/arm/mach-omap2/include/mach/debug-macros.S to be rather broken,
> > causing an abort when it tries to
Hi Santosh,
On Wed, 5 Jan 2011, Santosh Shilimkar wrote:
> Commit ff2516fb 'wd_timer: disable on boot via hwmod postsetup mechanism'
> introduced watchdog timer state state management using postsetup_state.
> This was done to allow some board files to support watchdog coverage
> throughout kernel
Kevin Hilman had written, on 01/06/2011 12:15 PM, the following:
Koen Kooi writes:
Op 6 jan 2011, om 16:43 heeft Brad Parker het volgende geschreven:
It's probably expected, but I can't get the EHCI USB port to work
on a beagle board XM (36xx) using the current omap tree.
It this most like
* Russell King - ARM Linux [110106 10:00]:
> On Thu, Jan 06, 2011 at 05:08:05PM +, Russell King - ARM Linux wrote:
> > This looks like something's rather broken on OMAP4 too - even with the
> > DEBUG_LL stuff enabled and my printk hack, I get nothing more, same with
> > vanilla 2.6.37. So, no
On Thu, Jan 06, 2011 at 06:00:30PM +, Russell King - ARM Linux wrote:
> Therefore, I believe the debugging address calculation stuff in
> arch/arm/mach-omap2/include/mach/debug-macros.S to be rather broken,
> causing an abort when it tries to access the serial port.
I'm sorry, I think this cra
Koen Kooi writes:
> Op 6 jan 2011, om 16:43 heeft Brad Parker het volgende geschreven:
>
>> It's probably expected, but I can't get the EHCI USB port to work
>> on a beagle board XM (36xx) using the current omap tree.
>>
>> It this most likely due to these clock issues?
>
> You need this patch:
Hi Kevin,
On Wed, Jan 05, 2011 at 08:54:48AM -0800, Kevin Hilman wrote:
>
> I had assumed it was recent changes since the patch didn't apply
> cleanly, but am glad to be wrong. :)
The patch should apply cleanly on the latest mainline. Do you want me to
rebase it against some other tree and resen
Santosh Shilimkar writes:
>> -Original Message-
>> From: Premi, Sanjeev [mailto:pr...@ti.com]
>> Sent: Thursday, January 06, 2011 8:03 PM
>> To: Shilimkar, Santosh; linux-omap@vger.kernel.org
>> Cc: Hilman, Kevin; t...@atomide.com; linux-arm-
>> ker...@lists.infradead.org; Shilimkar, Sant
On Thu, Jan 06, 2011 at 09:49:51AM -0800, Tony Lindgren wrote:
> * Russell King - ARM Linux [110106 09:09]:
> > On Thu, Jan 06, 2011 at 09:05:15AM -0800, Kevin Hilman wrote:
> > > Hi Russell,
> > >
> > > Russell King - ARM Linux writes:
> > >
> > > > I've observed the following issues while bui
On Wed, 5 Jan 2011, Kevin Hilman wrote:
> Santosh Shilimkar writes:
>
> > struct clockdomain member clktrctrl_mask is available for only for OMAP2
> > and OMAP3 architectures. Technially it is also used only for these archs
> > but this breaks the build with custom OMAP4 configuration.
>
> I'll
On Thu, Jan 06, 2011 at 05:08:05PM +, Russell King - ARM Linux wrote:
> This looks like something's rather broken on OMAP4 too - even with the
> DEBUG_LL stuff enabled and my printk hack, I get nothing more, same with
> vanilla 2.6.37. So, no OMAP platform I have seems to be usable with
> 2.6.
Eduardo Valentin writes:
> On Wed, Jan 05, 2011 at 03:22:51PM -0800, ext Kevin Hilman wrote:
>> Eduardo Valentin writes:
>>
>> > Hello Russell,
>> >
>> > On Wed, Jan 05, 2011 at 06:19:18PM +, Russell King wrote:
>> >> On Wed, Jan 05, 2011 at 07:58:03PM +0200, Eduardo Valentin wrote:
>> >> >
On Wed, 5 Jan 2011, Santosh Shilimkar wrote:
> struct clockdomain member clktrctrl_mask is available for only for OMAP2
> and OMAP3 architectures. Technially it is also used only for these archs
> but this breaks the build with custom OMAP4 configuration.
...
> Fix the build break by dropping th
Hi Santosh
On Wed, 5 Jan 2011, Santosh Shilimkar wrote:
> omap2plus_defocnfig build breaks when customised with only ARCH_OMAP4
> selected. This is because common files make references to the functions
> which are defined only for omap2xxx and omap3xxx.
...
>
> This patch adds stubs for these
Koen Kooi had written, on 01/06/2011 10:59 AM, the following:
Op 6 jan 2011, om 16:43 heeft Brad Parker het volgende geschreven:
It's probably expected, but I can't get the EHCI USB port to work
on a beagle board XM (36xx) using the current omap tree.
It this most likely due to these clock is
* Russell King - ARM Linux [110106 09:09]:
> On Thu, Jan 06, 2011 at 09:05:15AM -0800, Kevin Hilman wrote:
> > Hi Russell,
> >
> > Russell King - ARM Linux writes:
> >
> > > I've observed the following issues while building 2.6.37 + my devel
> > > branch. I don't believe any of them to be due
Sorry if this is off topic on a Linux mailing list, but maybe it's of
some interest here, too:
Windows on OMAP presented at Microsoft's CES keynote yesterday:
http://www.youtube.com/watch?v=xKc_XGuvNIk#t=1m53s
Best regards
Dirk
Btw.: Is anybody able to identify the OMAP board used there? A
Russell King - ARM Linux had written, on 01/06/2011 11:08 AM, the following:
[..]
For TI folk: it may be an idea to make X-loader say why it's hanging so
that we know what is going on.
[..]
1843088 bytes read
OMAP44XX SDP # bootm 8030
## Booting image at 8030 ...
Image Name: Linux
On Thu, Jan 06, 2011 at 09:05:15AM -0800, Kevin Hilman wrote:
> Hi Russell,
>
> Russell King - ARM Linux writes:
>
> > I've observed the following issues while building 2.6.37 + my devel
> > branch. I don't believe any of them to be due to anything in my tree,
> > so would be in 2.6.37 as well.
This looks like something's rather broken on OMAP4 too - even with the
DEBUG_LL stuff enabled and my printk hack, I get nothing more, same with
vanilla 2.6.37. So, no OMAP platform I have seems to be usable with
2.6.37...
It's worth noting that the kernel which was originally supplied with the
bo
Hi Russell,
Russell King - ARM Linux writes:
> I've observed the following issues while building 2.6.37 + my devel
> branch. I don't believe any of them to be due to anything in my tree,
> so would be in 2.6.37 as well.
What defconfig are you using for these builds?
Kevin
--
To unsubscribe f
writes:
> Hi,
>
> Kevin Hilman [khil...@ti.com]:
>> Aaro Koskinen writes:
>>
>> > Make !CONFIG_SUSPEND init declarations identical on all OMAPs and
>> > eliminate some ifdefs.
>> >
>> > Signed-off-by: Aaro Koskinen
>>
>> I like this solution, but it introduces compiler warnings:
>>
>> [...]
>>
Op 6 jan 2011, om 16:43 heeft Brad Parker het volgende geschreven:
> It's probably expected, but I can't get the EHCI USB port to work
> on a beagle board XM (36xx) using the current omap tree.
>
> It this most likely due to these clock issues?
You need this patch: http://thread.gmane.org/gman
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Russell King - ARM Linux
> Sent: Thursday, January 06, 2011 9:07 PM
> To: linux-omap@vger.kernel.org
> Subject: More LDP stuff
>
> During boot, apart from the watchdog iss
> -Original Message-
> From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
> Sent: Thursday, January 06, 2011 8:57 PM
> To: Santosh Shilimkar
> Cc: linux-omap@vger.kernel.org; Paul Walmsley; linux-arm-
> ker...@lists.infradead.org
> Subject: Re: [PATCH] omap: wd_timer: Fix crash
Hi Tarun,
"DebBarma, Tarun Kanti" writes:
>> >
>> > Also, testing with PM on 34xx/n900, I noticed that this series prevents
>> > PER and CORE from hitting retention during suspend. I haven't debugged
>> > why yet.
>> I have not done power testing. I will try this out right away and confirm.
>>
Hi Tarun,
"DebBarma, Tarun Kanti" writes:
>> Tarun Kanti DebBarma writes:
>>
>> > dmtimer adaptation to platform_driver.
>> >
>> > This patch series is adaptation of dmtimer code to platform driver
>> > using omap_device and omap_hwmod abstraction.
>> >
>> > Tested on following platforms:
>> >
It's probably expected, but I can't get the EHCI USB port to work
on a beagle board XM (36xx) using the current omap tree.
It this most likely due to these clock issues?
the (very old) angstrom 2.6.32 kernel works fine, as a comparison.
-brad
--
To unsubscribe from this list: send the line "u
h is
needed to make it working.
But the ehci on panda(omap4430) still does not work with
2.6.37-next-20110106+, and follows the failure messages:
[ 46.572601] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[ 46.580017] ehci_hcd: block sizes: qh 60 qtd 96 itd 160 sitd
Gopinath, Thara had written, on 01/06/2011 09:26 AM, the following:
-Original Message-
From: Menon, Nishanth
Sent: Thursday, January 06, 2011 8:49 PM
To: Gopinath, Thara
Cc: Gulati, Shweta; l-o
Subject: Re: [PATCH] OMAP4 PM: To correct voltages in MPU OPP Table
Gopinath, Thara had writ
During boot, apart from the watchdog issue, I'm also seeing:
Clocking rate (Crystal/Core/MPU): 26.0/266/500 MHz
Reprogramming SDRC clock to 26600 Hz
dpll3_m2_clk rate change failed: -22
Is that something to be concerned about?
ads7846 spi1.0: unable to get regulator: -19
Is something missin
Hi,
I am trying to setup an OMAP3530 based system for RFBI video output using
external triggering. Looking at the omap dss2 source code (and also
searching around) I cannot find any worked example of how to use the rfbi
driver. I know that RFBI has worked in the past for a Nokia N800 device.
Can y
On Thu, Jan 06, 2011 at 09:27:32AM +0530, Santosh Shilimkar wrote:
> > -Original Message-
> > From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
> > Sent: Thursday, January 06, 2011 3:49 AM
> > To: Santosh Shilimkar
> > Cc: linux-omap@vger.kernel.org; Paul Walmsley; linux-arm-
>
>>-Original Message-
>>From: Menon, Nishanth
>>Sent: Thursday, January 06, 2011 8:49 PM
>>To: Gopinath, Thara
>>Cc: Gulati, Shweta; l-o
>>Subject: Re: [PATCH] OMAP4 PM: To correct voltages in MPU OPP Table
>>
>>Gopinath, Thara had written, on 01/06/2011 09:09 AM, the following:
>>[..]
>>>
Hi,
2011/1/6 Anand Gadiyar :
> I'll take a look in a short while. I don't have an XM to
> test, so you'll have to help me out here.
No problem for me, :-)
thanks,
--
Lei Ming
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.ker
Gopinath, Thara had written, on 01/06/2011 09:09 AM, the following:
[..]
Actually no. The latest voltage layer pushed uses these voltages. Also
Arrgh... another reason to avoid messy duplicate tables!!
Oh there is a patch in my bag where we use a single macro for each voltage
across the voltag
>>-Original Message-
>>From: Menon, Nishanth
>>Sent: Thursday, January 06, 2011 8:29 PM
>>To: Gopinath, Thara
>>Cc: Gulati, Shweta; l-o
>>Subject: Re: [PATCH] OMAP4 PM: To correct voltages in MPU OPP Table
>>
>>Gopinath, Thara had written, on 01/06/2011 08:52 AM, the following:
>>>
>
e.
> >>
> >> I did a quick fix (which may be completely wrong - see below).
> >
> > I'm not sure these 3 nodes should be removed. AFAIR, they
> were just slightly moved in lo branch.
>
> Even with the fixes above, ehci on my beagle xM/Panda still
&g
On Thu, Jan 06, 2011 at 07:07:13AM -0500, Mark Brown wrote:
> On Wed, Jan 05, 2011 at 09:33:28PM -0800, Guenter Roeck wrote:
>
> > [...]
> > > +EXPORT_SYMBOL_GPL(twl4030_madc_conversion);
> > [...]
> > > +EXPORT_SYMBOL_GPL(twl4030_get_madc_conversion);
>
> > No symbol export from hwmon drivers. O
1 - 100 of 137 matches
Mail list logo
