On Thu, Nov 29, 2012 at 6:31 AM, Tomi Valkeinen wrote:
>> It is stock Linux 3.6 (i.e. commit a0d271cbfed1dd50278c6b06bead3d00ba0a88f9)
>
> Still can't reproduce. So does the null pointer deref happen at boot
> time? What display related kernel boot options do you have? This looks
> funny, conside
On Thu, Nov 29, 2012 at 3:33 AM, Enric Balletbo Serra
wrote:
> Sorry for the delay, I also can't reproduce the issue, I think is
> related due I upgrated the X server to a newer version. I would
> recover my old rootfs to try to reproduce the issue...
I am using xorg-server-1.11.2, which version
On Thu, Nov 29, 2012 at 3:22 AM, Tomi Valkeinen wrote:
> On 2012-11-27 21:15, Steve Sakoman wrote:
>> It seems that dss_mgr_check_timings is being called with a null
>> dssdev->manager.
>>
>> Other than the fact that there should be a null pointer check in the
&g
On Tue, Nov 27, 2012 at 3:32 AM, Tomi Valkeinen wrote:
> Ok. So X is configuring video2 overlay for some reason. XVideo, perhaps?
That was my guess too, and after some digging I am fairly certain this
is the case.
> Anyway, I guess it's a valid thing to configure the overlay with
> paddr == 0 w
On Fri, Nov 23, 2012 at 12:46 AM, Tomi Valkeinen wrote:
> Ok, so hmm... So the overlay is disabled, and the paddr is zero. Can you
> put a printk at dss/apply.c:dss_olv_set_info, and print ovl->id and
> info->paddr? And perhaps also to omapfb-main.c:omapfb_setup_overlay, at
> the point where it
On Thu, Nov 22, 2012 at 12:47 AM, Tomi Valkeinen wrote:
>> I'll add the printk's to omapfb_setup_plane() that were requested by
>> Tomi and report back.
Today was a holiday, so family obligations didn't allow much time to
look at this.
I did however do a quick build with some printk's in
omapfb
On Thu, Oct 11, 2012 at 8:58 AM, Enric Balletbo Serra
wrote:
> I see that commit dac8eb5f (OMAPDSS: TFP410: rename dvi files to
> tfp410) and commit 2e6f2ee7 (OMAPDSS: TFP410: rename dvi -> tfp410)
> changes the panel driver used on some boards. I tested current
> linux-next-20101011 kernel with
On Fri, Sep 14, 2012 at 12:20 PM, Andrew Morton
wrote:
> Given the tested-by's that are rolling in, I will assume that people
> are hitting this problem in 3.5 and perhaps earlier kernels, so I
> scheduled the fix for 3.6, with a -stable backport.
Yes, I just checked an Overo setup here that is
I2C driver
> itself.
>
> Special thanks to Steve Sakoman for helping track down the source of
> the continuous RTC interrups on the Overo boards.
>
> Cc: Felipe Balbi
> Cc: Steve Sakoman
> Signed-off-by: Kevin Hilman
Tested on Overo/Tobi, and I no longer see the 1/second
On Wed, Aug 29, 2012 at 2:39 AM, Florian Vaussard
wrote:
> Before doing the work twice, is someone working on the arm/dts for the overo
> board? I found a first support in the linaro tree [1], but is there any
> active
> work to complete this support and push it upstream? I am preparing a
> daugh
t does
> not actually have the module present.
>
> So, reduce the severity of the print to a debug statement and skip
> registering that specific OPP, but continue down the list.
>
> Reported-by: Steve Sakoman
> Reported-by: Maximilian Schwerin
> Signed-off-by: Nishanth Meno
On Sun, Jan 29, 2012 at 9:37 AM, S, Venkatraman wrote:
> A few folks in my group are working on this (CC'ed). I'd hazard a guess to say
> that the patches can be validated and sent out in another 1-2 weeks - Sourav ?
Any update on the status of the above-mentioned patch for SDIO
interrupt suppor
On Tue, Jan 24, 2012 at 6:33 AM, Michael Hunold wrote:
> Hi,
>
> I am experimenting with an SDIO card on the Beagleboard. I have started
> my experiments with Linux-3.1.4 some time ago and basically everything
> is working.
>
> Except the fact that currently no native SDIO interrupts are used, but
On Wed, Dec 28, 2011 at 9:19 AM, Andre Puschmann
wrote:
> Nope, doesn't work either. The funny thing is that it works for the
> omap3-pm branch which has the 720MHz thing included, too. So maybe the
> workaround is just hiding something else?
OK, I'll try to reproduce that.
Could you send me th
On Wed, Dec 28, 2011 at 7:26 AM, Andre Puschmann
wrote:
> Hi list,
>
> a couple of days ago I was posting a similar issue where Linux wouldn't
> start after u-boot. I am trying to boot a recent kernel using Steve's
> omap-3.2 branch on an Overo Tide based board.
>
> A recent checkout doesn't boot
On Fri, Dec 16, 2011 at 12:04 AM, Paul Walmsley wrote:
>
> The HSMMC1/HSMMC2 host controllers on OMAP34xx and
> OMAP3503/3515/3525/3530 chips at ES levels prior to 3.0 can't do multiple
> block reads[1]. Mark the hwmod data appropriately.
>
> Reported by Dave Hyl
On Fri, Dec 9, 2011 at 6:12 AM, Steve Sakoman wrote:
> Specifying TWL_COMMON_PDATA_MADC is adequate, don't also add
> platform device
>
> Otherwise:
>
> [ cut here ]
> WARNING: at fs/sysfs/dir.c:481 sysfs_add_one+0x6c/0x8c()
> sysfs: can
d twl4030_madc_hwmon dev
Signed-off-by: Steve Sakoman
---
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index d47470e..91c1a7c 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -634,15 +63
Currently the driver does not explicitly set the TWL4030_USB_SEL_MADC_MCPC
bit to enable madc input channels 3 through 6. This results in readings near
zero for these channels since the inputs are grounded if this bit is not set.
Signed-off-by: Steve Sakoman
---
diff --git a/drivers/mfd
On Thu, Dec 8, 2011 at 2:51 PM, Paul Walmsley wrote:
> Thanks for the reminder - I would have forgotten it otherwise.
>
>> Without it 35XXES2.1 systems have broken mmc. Too late as a bug fix for
>> 3.2?
>
> This never worked correctly in previous Linux releases, right?
I seem to recall that it
On Thu, Oct 6, 2011 at 1:56 PM, Paul Walmsley wrote:
>
> The HSMMC1/HSMMC2 host controllers on OMAP34xx and
> OMAP3503/3515/3525/3530 chips at ES levels prior to 3.0 can't do multiple
> block reads[1]. Mark the hwmod data appropriately.
>
> Reported by Dave Hylands and
On Thu, Dec 8, 2011 at 11:33 AM, Enrico wrote:
> On Wed, Dec 7, 2011 at 9:58 PM, Steve Sakoman wrote:
>> I just began working with 3.2-rc4 on Overo and Beagleboard xM.
>>
>> On both machines I see the driver init, but no alsa device created.
>> For example on Overo:
I just began working with 3.2-rc4 on Overo and Beagleboard xM.
On both machines I see the driver init, but no alsa device created.
For example on Overo:
Advanced Linux Sound Architecture Driver Version 1.0.24.
overo SoC init
ALSA device list:
No soundcards found.
Has anyone else seen this? J
sted these patches with my own version of the above mentioned
hwmod patch on:
3503 - ES2.1 and ES3.1
3530 - ES3.1
3703 - ES1.2
3730 - ES1.0
All worked successfully.
Tested-by: Steve Sakoman
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a mes
ry
> delays, and console messages on kernels running on those chips:
>
> http://www.spinics.net/lists/linux-omap/msg58735.html
>
> Convert this test to a feature test with a chip-by-chip whitelist.
>
> Thanks to Dave Hylands for reporting this problem
> and doing some testi
g to help isolate the cause.
Thanks for doing this patch so quickly!
> Signed-off-by: Paul Walmsley
> Cc: Kevin Hilman
> Cc: Dave Hylands
> Cc: Steve Sakoman
> ---
> arch/arm/mach-omap2/id.c | 6 +++-
> arch/arm/mach-omap2/pm34xx.c | 44
On Wed, Oct 5, 2011 at 11:09 AM, Paul Walmsley wrote:
> Looking at the 2.6.39 kernel sources, those messages are coming from
> mach-omap2/pm34xx.c:omap3_enable_io_chain(). That means that something is
> seriously wrong since that code should only be executing on ES3.1 chips
> and higher.
>
> Cou
On Wed, Oct 5, 2011 at 11:10 AM, Kevin Hilman wrote:
> The need to comment this out suggests that omap3_has_io_wakeup() is
> returning true for this SoC but should not.
>
> Looking at mach-omap2/io.c, that feature flag is not set on the 3505 and
> 3517, but is set on the 3503:
>
> if (!cpu
On Wed, Oct 5, 2011 at 9:26 AM, Tony Lindgren wrote:
> * Dave Hylands [111004 23:41]:
>> I then also had to modify drivers/mmc/card/block.c and initializing
>> disable_multi to 1 in the mmc_blk_issue_rw_rq function to get rid of
>> the following messages for every I/O request.
>>
>> mmcblk0: ret
On Tue, Mar 29, 2011 at 8:32 AM, Laurent Pinchart
wrote:
> I think that Sakari's patches correcty fix the problems he noticed. However,
> they won't fix one basic issue, which is that the iommu2 module won't be
> automatically pulled in when the omap3isp module is loaded. The omap3isp
> driver wi
I've used the omap watchdog timer (CONFIG_OMAP_WATCHDOG=y &
CONFIG_WATCHDOG_NOWAYOUT=y) with good results on 35XX based systems.
Recently I attempted to use the the same technique with 37XX and
discovered that my systems hangs instead of rebooting.
The simplest method to test is to do:
# echo 1
On Thu, Jun 2, 2011 at 8:36 AM, Steve Sakoman wrote:
> On Fri, May 6, 2011 at 6:17 AM, Lesly A M wrote:
>> Patch series for TWL4030 power scripts for OMAP3 boards and
>> workaround for TWL erratum 27.
>>
>> Changes for implementing TWL4030 power scripts r
On Fri, May 6, 2011 at 6:17 AM, Lesly A M wrote:
> Patch series for TWL4030 power scripts for OMAP3 boards and
> workaround for TWL erratum 27.
>
> Changes for implementing TWL4030 power scripts recommended by hardware team.
> Introduced a new TWL4030 power script file, which can be used by differ
On Tue, May 3, 2011 at 9:23 PM, J, KEERTHY wrote:
> On Wed, May 4, 2011 at 9:41 AM, Steve Sakoman wrote:
>> On Tue, May 3, 2011 at 12:49 PM, J, KEERTHY wrote:
>>> Hello Steve,
>>>
>>> Can you try adding this patch?
>>
>> Thanks!
>>
>
On Wed, May 4, 2011 at 5:27 AM, Tomi Valkeinen wrote:
> drivers/video/omap/ contains some lcd drivers which are not used by any
> board. They can be removed.
>
> Signed-off-by: Tomi Valkeinen
> Cc: Arun C
> Cc: Koen Kooi
> Cc: Steve Sakoman
> ---
> drivers/video/om
On Tue, May 3, 2011 at 12:49 PM, J, KEERTHY wrote:
> Hello Steve,
>
> Can you try adding this patch?
Thanks!
I tried the patch and it did indeed fix the issue. We should try to
get this in mainline since the hwmon driver won't work without it.
Steve
--
To unsubscribe from this list: send the l
On Wed, Mar 2, 2011 at 2:15 AM, Samuel Ortiz wrote:
> Hi Keerthy,
>
> On Tue, Mar 01, 2011 at 07:12:06PM +0530, Keerthy wrote:
>> MADC(Monitoring ADC) driver enables monitoring analog signals using
>> analog-to-digital conversion (ADC) on the input source.
>> The previous discussion concluded in k
On Sat, Apr 30, 2011 at 1:21 AM, Elvis Dowson wrote:
> Hi,
> I'm using a Gumstix Overo Fire COM module (TI OMAP 3530 ES2.1) with
> Chestnut43 expansion board.
>
> I built the linux kernel using the omap-2.6.38 branch located here:
>
> http://www.sakoman.com/cgi-bin/gitweb.cgi?p=linux-omap-2
On Mon, Apr 25, 2011 at 7:11 AM, Alan Ott wrote:
> On 04/24/2011 02:37 AM, Keshava Munegowda wrote:
>>> -Original Message-
>>> From: Alan Ott [mailto:a...@signal11.us]
>>> Sent: Friday, April 22, 2011 6:41 AM
>>> To: Keshava Munegowda
>>> C
ier issue of no video output on 37XX boards.
Tested-by: Steve Sakoman
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
ity used to reset the
>> external USB phy changed and USB host doesn't recognize
>> any devices.
>>
>> Signed-off-by: Juergen Kilb
>
> Judging by how ehci-omap.c was before moving the code:
>
> Acked-by: Felipe Balbi
This fixes the issue on Overo:
Tes
On Mon, Apr 11, 2011 at 10:06 AM, Steve Calfee wrote:
> On 04/11/11 02:32, Dmitry Artamonow wrote:
>> Hi, guys!
>>
>> Can anyone explain why regulator support has been removed from ehci-omap
>> driver in commit 19403165 ("usb: host: omap: ehci and ohci
>> simplification")[1]?
>> In 2.6.37/2.6.38
Overo COMs and expansion boards have three LEDS and 2 push button switches
connected to GPIO pins. This patch series adds support for utilizing
them with gpio-keys and gpio-leds.
Changes from version 1: Guard gpio_leds assignment with CONFIG_LEDS_GPIO check
Steve Sakoman (2):
OMAP: Add gpio
This patch adds support for the standard push buttons available on
Overo expansion boards.
Signed-off-by: Steve Sakoman
---
arch/arm/mach-omap2/board-overo.c | 42 +
1 files changed, 42 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board
This patch adds support for the standard LEDs on the Overo COM and expansion
boards
Signed-off-by: Steve Sakoman
---
arch/arm/mach-omap2/board-overo.c | 53 +
1 files changed, 53 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-overo.c
On Wed, Mar 9, 2011 at 11:18 AM, Tony Lindgren wrote:
> * Steve Sakoman [110308 16:13]:
>>
>> Tony: I have a couple more patches queued up to add gpio-led and
>> gpio-keys support to Overo. I've been holding off submitting because
>> I haven't been quit
This patch adds support for the standard push buttons available on
Overo expansion boards.
Signed-off-by: Steve Sakoman
---
arch/arm/mach-omap2/board-overo.c | 42 +
1 files changed, 42 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board
This patch adds support for the standard LEDs on the Overo COM and expansion
boards
Signed-off-by: Steve Sakoman
---
arch/arm/mach-omap2/board-overo.c | 51 +
1 files changed, 51 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-overo.c
Overo COMs and expansion boards have three LEDS and 2 push button switches
connected to GPIO pins. This patch series adds support for utilizing
them with gpio-keys and gpio-leds.
Steve Sakoman (2):
OMAP: Add gpio-leds support for Overo
OMAP: Add gpio-keys support for Overo
arch/arm/mach
On Tue, Mar 8, 2011 at 3:16 PM, Tony Lindgren wrote:
> * Steve Sakoman [110305 08:10]:
>> The ads7846 driver now requires a regulator. This patch adds the
>> necessary regulator to the overo board file. Without it, the
>> following error occurs (and the touchscr
On Sun, Mar 6, 2011 at 11:37 PM, Felipe Balbi wrote:
> On Sun, Mar 06, 2011 at 08:58:47PM -0800, Steve Sakoman wrote:
>> I began working with mainline 2.6.38-rc7 on Overo this past week in an
>> attempt to get a few patches submitted in time for the 2.6.39 merge
>> window.
I began working with mainline 2.6.38-rc7 on Overo this past week in an
attempt to get a few patches submitted in time for the 2.6.39 merge
window.
One thing I've noticed is that neither musb nor ehci USB support are
working for me. I'm using the same config options as I did for
2.6.37.
Have ther
The ads7846 driver now requires a regulator. This patch adds the
necessary regulator to the overo board file. Without it, the
following error occurs (and the touchscreen will not function):
ads7846 spi1.0: unable to get regulator: -19
Signed-off-by: Steve Sakoman
---
Note: this patch should
This patch adds DSS2 support for DVI, S-video, the 480x272 Samsung
LTE430WQ-F0C panel, and the 320x240 LG.Philips LB035Q02 panel.
Signed-off-by: Steve Sakoman
---
arch/arm/mach-omap2/board-overo.c | 239 +++--
1 files changed, 202 insertions(+), 37 deletions
This patch adds support for the Gumstix Palo35 expansion board
which utilizes the 320 x 240 pixel LG.Philips LB035Q02 LCD Panel
Signed-off-by: Steve Sakoman
---
drivers/video/omap2/displays/Kconfig |6 +
drivers/video/omap2/displays/Makefile |1 +
.../omap2
version 1: adds mutex locking to the lgphilips-lb035q02
panel enable/disable and suspend/resume functions.
Changes from version 2: add missing semicolon to lb035q02_data definition
Steve Sakoman (2):
OMAP: DSS2: Add support for LG Philips LB035Q02 panel
OMAP: DSS2: Add DSS2 support for Overo
On Sat, Mar 5, 2011 at 1:18 AM, Tomi Valkeinen wrote:
> Hi,
>
> On Fri, 2011-03-04 at 14:52 -0600, Steve Sakoman wrote:
>> This patch adds support for the Gumstix Palo35 expansion board
>> which utilizes the 320 x 240 pixel LG.Philips LB035Q02 LCD Panel
>>
>
version 1: adds mutex locking to the lgphilips-lb035q02
panel enable/disable and suspend/resume functions.
Steve Sakoman (2):
OMAP: DSS2: Add support for LG Philips LB035Q02 panel
OMAP: DSS2: Add DSS2 support for Overo
arch/arm/mach-omap2/board-overo.c | 239
This patch adds DSS2 support for DVI, S-video, the 480x272 Samsung
LTE430WQ-F0C panel, and the 320x240 LG.Philips LB035Q02 panel.
Signed-off-by: Steve Sakoman
---
arch/arm/mach-omap2/board-overo.c | 239 +++--
1 files changed, 202 insertions(+), 37 deletions
This patch adds support for the Gumstix Palo35 expansion board
which utilizes the 320 x 240 pixel LG.Philips LB035Q02 LCD Panel
Signed-off-by: Steve Sakoman
---
drivers/video/omap2/displays/Kconfig |6 +
drivers/video/omap2/displays/Makefile |1 +
.../omap2
On Fri, Mar 4, 2011 at 7:41 AM, Tomi Valkeinen wrote:
> On Fri, 2011-03-04 at 09:29 -0600, Steve Sakoman wrote:
>> Do you want me to try to address this in this initial submission, or
>> is it something we can revisit in a subsequent "fix-it" patch for all
>> panels
On Thu, Mar 3, 2011 at 11:55 PM, Tomi Valkeinen wrote:
> Hi,
>
> On Thu, 2011-03-03 at 17:46 -0600, Steve Sakoman wrote:
>> This patch adds support for the Gumstix Palo35 expansion board
>> which utilizes the 320 x 240 pixel LG.Philips LB035Q02 LCD Panel
>>
>
On Fri, Mar 4, 2011 at 12:00 AM, Tomi Valkeinen wrote:
> Why check for CONFIG_PANEL_LGPHILIPS_LB035Q02, but not for the lcd43?
>
> And is that even necessary? Of course it would make the kernel very
> slightly smaller if you leave some code out, but otherwise does that
> help? If you have the dev
This patch adds DSS2 support for DVI, S-video, the 480x272 Samsung
LTE430WQ-F0C panel, and the 320x240 LG.Philips LB035Q02 panel.
Signed-off-by: Steve Sakoman
---
arch/arm/mach-omap2/board-overo.c | 239 +++--
1 files changed, 202 insertions(+), 37 deletions
This patch adds support for the Gumstix Palo35 expansion board
which utilizes the 320 x 240 pixel LG.Philips LB035Q02 LCD Panel
Signed-off-by: Steve Sakoman
---
drivers/video/omap2/displays/Kconfig |6 +
drivers/video/omap2/displays/Makefile |1 +
.../omap2
This patch series adds support for the set of display devices available
for the Overo COM products: DVI, S-Video, the Samsung LTE430WQ-F0C LCD
panel, and the LG.Philips LB035Q02 panel.
Tested with applicable expansion boards for each option: Tobi, Palo43,
Chestnut43, and Palo35.
Steve Sakoman (2
On Wed, Jan 12, 2011 at 8:30 PM, Steve Sakoman wrote:
> On Wed, Jan 12, 2011 at 9:48 AM, Steve Sakoman wrote:
>> On Tue, Jan 11, 2011 at 10:17 PM, Ghorai, Sukumar wrote:
>>
>>> [Ghorai]
>>> We also experienced the same issue using 32GB SD card for omap3 and omap
On Wed, Jan 12, 2011 at 9:48 AM, Steve Sakoman wrote:
> On Tue, Jan 11, 2011 at 10:17 PM, Ghorai, Sukumar wrote:
>
>> [Ghorai]
>> We also experienced the same issue using 32GB SD card for omap3 and omap4.
>> And the problem is seen is that DTO value (in SYSCTL) is not
On Tue, Jan 11, 2011 at 10:17 PM, Ghorai, Sukumar wrote:
> [Ghorai]
> We also experienced the same issue using 32GB SD card for omap3 and omap4.
> And the problem is seen is that DTO value (in SYSCTL) is not current
> in following function.
>
> So add the following modification and please update
On Sat, Jan 8, 2011 at 10:04 PM, Steve Sakoman wrote:
> I've recently been testing memory card performance to identify the
> best performing brands/models.
>
> As expected, I found a huge difference in performance between brands.
> What I didn't expect to find, however,
On Sun, Jan 9, 2011 at 9:07 AM, Elvis Dowson wrote:
> Hi Steve,
>
> On Jan 9, 2011, at 9:00 PM, Steve Sakoman wrote:
>
>>> mmcblk0: error -110 sending read/write command, response 0x900, card
>>> status 0xe00
>
> Error -110 is ETIMEOUT.
>
> The card mig
FWIW, I am seeing this same behavior with a brand new SanDisk 4GB
Class 4 microSD card.
Steve
On Sat, Jan 8, 2011 at 10:04 PM, Steve Sakoman wrote:
> I've recently been testing memory card performance to identify the
> best performing brands/models.
>
> As expected, I found a h
I've recently been testing memory card performance to identify the
best performing brands/models.
As expected, I found a huge difference in performance between brands.
What I didn't expect to find, however, was a brand (ADATA) that
doesn't seem to play well with the 2.6.36 kernel on OMAP3 hardware
On Wed, Oct 20, 2010 at 6:02 AM, Robert Nelson wrote:
> On Wed, Oct 20, 2010 at 7:44 AM, Steve Sakoman wrote:
>> On Tue, Oct 19, 2010 at 9:42 PM, Taneja, Archit wrote:
>>> Hi,
>>>
>>> linux-omap-ow...@vger.kernel.org wrote:
>>>> I'
On Tue, Oct 19, 2010 at 9:42 PM, Taneja, Archit wrote:
> Hi,
>
> linux-omap-ow...@vger.kernel.org wrote:
>> I'm using a 2.6.35 kernel, and the generic panel driver.
>>
>> I see this crash about 25% of the time, so I suspect a race condition.
>>
>> Is anyone else encountering this?
>>
>> Steve
>>
>
I'm using a 2.6.35 kernel, and the generic panel driver.
I see this crash about 25% of the time, so I suspect a race condition.
Is anyone else encountering this?
Steve
Unmounting local filesystems...
Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa050040
Internal error: : 1028
On Thu, Oct 7, 2010 at 9:52 AM, Madhusudhan wrote:
>
>> -Original Message-
>> From: Steve Sakoman [mailto:sako...@gmail.com]
>> Sent: Thursday, October 07, 2010 8:57 AM
>> To: Mike Rapoport
>> Cc: Madhusudhan Chikkature; David Vrabel; Chris Ball; linux-
&g
On Thu, Oct 7, 2010 at 12:15 AM, Mike Rapoport wrote:
> Hi Madhu,
>
> Madhusudhan Chikkature wrote:
>>
>>
>>
>>> You are correct! The version of the patch in the repo indeed has
>>> 'out' in the wrong place and generates a compile error.
>>>
>>> Could you post the patch you are using and I will
On Wed, Oct 6, 2010 at 6:45 AM, Mike Rapoport wrote:
> Hi Steve,
> Steve Sakoman wrote:
>>
>> On Tue, Oct 5, 2010 at 11:17 PM, Mike Rapoport
>> wrote:
>>
>>> I've tried to update the patches on top of 2.6.36-rc3 and I've got stuck.
>>> Th
On Tue, Oct 5, 2010 at 11:17 PM, Mike Rapoport wrote:
> I've tried to update the patches on top of 2.6.36-rc3 and I've got stuck.
> The changes Adrian has made to the interrupt synchronization affect the way
> the
> SDIO irq should be implemented and I haven't found a way to resolve it :-(
I tr
On Mon, Oct 4, 2010 at 10:33 AM, Madhusudhan wrote:
>
>
>> -Original Message-----
>> From: Steve Sakoman [mailto:sako...@gmail.com]
>> Sent: Monday, October 04, 2010 11:57 AM
>> To: Madhusudhan
>> Cc: Mike Rapoport; David Vrabel; Chris Ball; linu
On Mon, Oct 4, 2010 at 9:45 AM, Madhusudhan wrote:
>
>
>> -Original Message-----
>> From: Steve Sakoman [mailto:sako...@gmail.com]
>> Sent: Monday, October 04, 2010 11:32 AM
>> To: Mike Rapoport
>> Cc: David Vrabel; Chris Ball; linux-...@vger.kernel.org; l
On Wed, Sep 1, 2010 at 11:02 PM, Mike Rapoport wrote:
> David Vrabel wrote:
>>
>> On 27/08/2010 20:22, Chris Ball wrote:
>>>
>>> Hi David,
>>>
>>> On Mon, Feb 22, 2010 at 02:24:17PM +, David Vrabel wrote:
These patches add support for SDIO cards to the omap_hsmmc driver.
Power m
On Thu, Sep 16, 2010 at 10:40 AM, Tony Lindgren wrote:
> * Steve Sakoman [100916 05:48]:
>>
>> Agreed. Gumstix doesn't provide an easy way of determining the layout
>> revision via software (the boards are marked with the rev number, but
>> that doesn't d
On Wed, Sep 15, 2010 at 11:07 PM, Felipe Balbi wrote:
> On Wed, Sep 15, 2010 at 04:28:57PM -0500, Steve Sakoman wrote:
>>
>> On Wed, Sep 15, 2010 at 9:29 AM, Anti Sullin
>> wrote:
>>>
>>> I was not getting OTG USB vbus/id pin change interrupts on Gum
On Wed, Sep 15, 2010 at 9:29 AM, Anti Sullin wrote:
> I was not getting OTG USB vbus/id pin change interrupts on Gumstix Overo
> and the reason was a mis-configured irq. I added some more checks to avoid
> having a non-bootable kernel on boards with bootloaders that have wrong
> pinmux.
> The cha
On Tue, May 25, 2010 at 8:54 AM, Mickael Chazaux
wrote:
> Hi,
>
> I am working on adding the support of an omap3 based board in the
> kernel. This board uses an ADS7843 touchscreen controller, on the SPI
> bus. The in-kernel driver (drivers/input/touchscreen/ads7646.c) works
> fine with the 2.6.33
On Thu, May 20, 2010 at 8:48 AM, David Brownell wrote:
>
>> +#ifdef CONFIG_USB_MUSB_OTG
>> + .mode
>> = MUSB_OTG,
>> +#elif defined(CONFIG_USB_MUSB_HDRC_HCD)
>> + .mode
>> = MUSB_HOST,
>> +#elif defined(CONFIG_USB_GADGET_MUSB_HDRC)
>> .mode
>> = MUSB_PERIPHERAL,
Previous patch was truncated by patchwork, this patch supplies the
missing chunks
Signed-off-by: Steve Sakoman
---
diff --git a/arch/arm/mach-omap2/board-overo.c
b/arch/arm/mach-omap2/board-overo.c
index 24b32d7..035eb35 100644
--- a/arch/arm/mach-omap2/board-overo.c
+++ b/arch/arm/mach-omap2
I did a quick test build of the current linux-omap head and get a
failure very early on in the boot process in
drivers/video/omap2/vram.c code:
Illegal SDRAM size for VRAM
It is generated by the following code:
bdata = NODE_DATA(0)->bdata;
sdram_start = bdata->node_min_pf
On Wed, May 5, 2010 at 12:33 PM, Tony Lindgren wrote:
> From: Steve Sakoman
>
> Some Overo add-on boards include a second ethernet port. This patch
> adds support for that second port.
>
> Signed-off-by: Steve Sakoman
> Signed-off-by: Tony Lindgren
> ---
> arch/a
On Mon, May 10, 2010 at 10:26 AM, Hiremath, Vaibhav wrote:
>> Obviously this patch needs to be updated for the current tree. Does
>> TI intend to re-base and submit the patches in the arago repo to this
>> list?
>>
> [Hiremath, Vaibhav] We are submitting all the patches to the linux-omap, we
>
On Mon, May 10, 2010 at 9:24 AM, Hiremath, Vaibhav wrote:
>> The image works as expected on a 35xx based Beagle, but when run on
>> the Beagle xM results in a "HDMI: Out of Range" error from my monitor.
>> Sadly the monitor won't give me the erroneous timing parameters.
>>
> [Hiremath, Vaibhav]
Has anyone had success with DSS2 on a 36xx platform using the current
l-o top of tree?
I've been working with a Beagle xM prototype and have applied the
"OMAP3630: DSS2: Updating MAX divider value" patch from Tomi's repo as
well as Koen's Beagle DSS2 support patch.
The image works as expected on
On Sat, Feb 13, 2010 at 9:31 AM, Grazvydas Ignotas wrote:
> The ADS7846/TSC2046 touchscreen controllers can (and usually are)
> connected to various regulators for power, so add regulator support.
>
> Valid regulator will now be required, so boards without complete
> regulator setup should either
sting them on Overo and Beagle and they do indeed solve
the prefetch issue. So if they are queued waiting an ack:
Acked-by: Steve Sakoman
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Steve Sakoman
Many Beagle users prefer to update their NAND using linux tools rather
than u-boot. This patch makes the u-boot partition writable so that
updates are possible.
Signed-off-by: Steve Sakoman
--
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2
From: Steve Sakoman
Some Overo add-on boards include a second ethernet port. This patch
adds support for that second port.
Signed-off-by: Steve Sakoman
---
diff --git a/arch/arm/mach-omap2/board-overo.c
b/arch/arm/mach-omap2/board-overo.c
index 8848c7c..4ceeb56 100644
--- a/arch/arm/mach
From: Steve Sakoman
A new GPMC NAND infrastructure was added by commit
2f70a1e93657bea0baa7d449aa49e44a08582dc8. This patch updates Beagle
NAND functionally to work with those changes.
Signed-off-by: Steve Sakoman
---
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2
From: Steve Sakoman
A new GPMC NAND infrastructure was added by commit
2f70a1e93657bea0baa7d449aa49e44a08582dc8. This patch updates Overo
NAND functionally to work with those changes.
Signed-off-by: Steve Sakoman
---
diff --git a/arch/arm/mach-omap2/board-overo.c
b/arch/arm/mach-omap2/board
1 - 100 of 319 matches
Mail list logo
