I am trying to setup the device tree to enable a parallel camera
interface as found on the LPD Dev Kit.
The instructions I am using for the basis are:
https://alaganraj.wordpress.com/2015/08/08/beagleboard-xm-camera-li-5m03-mt9p031-support-with-device-tree/
It I get the same results when I compil
From: Russell King - ARM Linux
Add a function to find the start of the SADs in the ELD. This
complements the helper to retrieve the SAD count.
Signed-off-by: Russell King
This should already be coming in from drm-next.
Signed-off-by: Jyri Sarha
---
include/drm/drm_edid.h | 19 +
The MTD_NAND_OMAP_BCH doesn't harm on legacy OMAP platforms
so don't state that it should be disabled for them.
Signed-off-by: Roger Quadros
---
drivers/mtd/nand/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index
audio support for OMAP4"
+ depends on OMAP4_DSS_HDMI
+ depends on SND_OMAP_SOC=y || OMAP2_DSS = SND_OMAP_SOC
+ default y
+ help
+ HDMI audio support for OMAP4 based SoCs. Adds integrated
+ ASoC Digital Audio Interface component driver into OMAPDSS
+
ol
> + bool "HDMI audio support for OMAP4"
> + depends on OMAP4_DSS_HDMI
> + depends on SND_OMAP_SOC=y || OMAP2_DSS = SND_OMAP_SOC
> + default y
> + help
> + HDMI audio support for OMAP4 based SoCs. Adds integrated
> + ASoC Digital Audio Interfa
OMAP_SOC=y || OMAP2_DSS = SND_OMAP_SOC
+ default y
+ help
+ HDMI audio support for OMAP4 based SoCs. Adds integrated
+ ASoC Digital Audio Interface component driver into OMAPDSS
+ module. Select SND_SOC_HDMI_CODEC and SND_SIMPLE_CARD with
+ devicetree descriptio
D_OMAP_SOC
+ default y
+ help
+ HDMI audio support for OMAP5 based SoCs. Adds integrated
+ ASoC Digital Audio Interface component driver into OMAPDSS
+ module. Select SND_SOC_HDMI_CODEC and SND_SIMPLE_CARD with
+ devicetree description for full HDMI aud
y email?
>
> I take it this issue has been resolved already? Probably you
> did not configure u-boot for the dtb? :)
>
Yes, I have helped them. Nice should be test on a newest kernel. It
should work but the
device is in US and I help them remote using teamviewer so not so easy ;)
Mic
* Michael Trimarchi [140325 09:37]:
> Hi
>
> On Tue, Mar 25, 2014 at 5:33 PM, Andrey Utkin
> wrote:
> > 2014-03-25 17:17 GMT+02:00 Michael Trimarchi :
> >> I have already done somenthing like that more then 6 months ago. I was
> >> in a good state, What camera sensors are you using?
> >
> > Hi M
Hi
On Tue, Mar 25, 2014 at 5:33 PM, Andrey Utkin
wrote:
> 2014-03-25 17:17 GMT+02:00 Michael Trimarchi :
>> I have already done somenthing like that more then 6 months ago. I was
>> in a good state, What camera sensors are you using?
>
> Hi Michael, it is JAL-MIPI-OV5640.
>
I think that I have a
2014-03-25 17:17 GMT+02:00 Michael Trimarchi :
> I have already done somenthing like that more then 6 months ago. I was
> in a good state, What camera sensors are you using?
Hi Michael, it is JAL-MIPI-OV5640.
--
Andrey Utkin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap
r-od/55b34ebe3571ae4dd875
> The serial console output with kernel shipped by vendor:
> https://gist.github.com/krieger-od/32481d718e0519dd0bd9
>
> Could anybody share a working config for recent enough kernel for this
> or similar hardware?
> Any comments?
> We appreciate any help
a working config for recent enough kernel for this
or similar hardware?
Any comments?
We appreciate any help. Thanks in advance.
--
Andrey Utkin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo i
On 03/06/2014 01:29 AM, Marc Murphy wrote:
>> -Original Message-
>> From: Felipe Balbi [mailto:ba...@ti.com]
>> Sent: 04 March 2014 23:43
>> To: Marc Murphy
>> Cc: 'ba...@ti.com'; 'Igor Grinberg'; Roger Quadros; linux-
>>
> -Original Message-
> From: Felipe Balbi [mailto:ba...@ti.com]
> Sent: 04 March 2014 23:43
> To: Marc Murphy
> Cc: 'ba...@ti.com'; 'Igor Grinberg'; Roger Quadros; linux-
> o...@vger.kernel.org
> Subject: Re: Help needed USB hub disconnected at
On Tue, Mar 04, 2014 at 11:05:58PM +, Marc Murphy wrote:
> > -Original Message-
> > From: Felipe Balbi [mailto:ba...@ti.com]
> > Sent: 04 March 2014 22:44
> > To: Marc Murphy
> > Cc: 'Igor Grinberg'; Roger Quadros; linux-omap@vger.kernel.
> -Original Message-
> From: Felipe Balbi [mailto:ba...@ti.com]
> Sent: 04 March 2014 22:44
> To: Marc Murphy
> Cc: 'Igor Grinberg'; Roger Quadros; linux-omap@vger.kernel.org
> Subject: Re: Help needed USB hub disconnected at resume
>
> Hi,
>
>
> -Original Message-
> From: Felipe Balbi [mailto:ba...@ti.com]
> Sent: 04 March 2014 22:44
> To: Marc Murphy
> Cc: 'Igor Grinberg'; Roger Quadros; linux-omap@vger.kernel.org
> Subject: Re: Help needed USB hub disconnected at resume
>
> Hi,
>
>
Hi,
On Tue, Mar 04, 2014 at 10:34:56PM +, Marc Murphy wrote:
> static __init void tam3517_ehci_init(void)
> {
> /* Configure GPIO for EHCI port */
> omap_mux_init_gpio(TAM3517_EHCI_RESET, OMAP_PIN_OUTPUT);
>
> gpio_request(TAM3517_EHCI_RESET, "USB_RESET");
> gpio_direction_out
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Igor Grinberg
> Sent: 04 March 2014 06:44
> To: Marc Murphy; Roger Quadros; linux-omap@vger.kernel.org
> Subject: Re: Help needed USB hub disconnected
am its a direct connection.
Regards
Marc
>> Regards
>> Marc
>>
>> From: Igor Grinberg [grinb...@compulab.co.il]
>> Sent: 03 March 2014 12:16
>> To: Roger Quadros; Marc Murphy; linux-omap@vger.kernel.org
> Subject: Re: Help needed USB hub
gt; From: Igor Grinberg [grinb...@compulab.co.il]
> Sent: 03 March 2014 12:16
> To: Roger Quadros; Marc Murphy; linux-omap@vger.kernel.org
> Subject: Re: Help needed USB hub disconnected at resume
>
> On 03/03/14 13:06, Roger Quadros wrote:
>> Hi Marc,
>>
>> On 03/03/2014 12:04
: Roger Quadros; Marc Murphy; linux-omap@vger.kernel.org
Subject: Re: Help needed USB hub disconnected at resume
On 03/03/14 13:06, Roger Quadros wrote:
> Hi Marc,
>
> On 03/03/2014 12:04 PM, Marc Murphy wrote:
>> Hi,
>> I am using the latest stable 3.4.80 kernel with some ch
>> with most of the system working nice and smoothly. I have 1 issue though and
>> need some advice/help to get the system to use the USB hub I have connected
>> to the EHCI controller after a suspend to memory and resume.
>>
>> At boot all is recognised;
>>
>&
e though and
> need some advice/help to get the system to use the USB hub I have connected
> to the EHCI controller after a suspend to memory and resume.
>
> At boot all is recognised;
>
> [1.486816] usbcore: registered new interface driver cdc_ether
> [1.493255]
Hi,
I am using the latest stable 3.4.80 kernel with some changes to get the EMAC
Phy to initialise correctly after a suspend/resume. The platform is AM3517
with most of the system working nice and smoothly. I have 1 issue though and
need some advice/help to get the system to use the USB hub I
On 27/02/14 21:38, Aaro Koskinen wrote:
> Hi,
>
> On Thu, Feb 27, 2014 at 08:19:06AM +, Leigh Brown wrote:
>> Did that driver work on the N810 at that point? If I look at the kernel
>> tree at that point in time would all the components be there? It would
>> make it easier if I had a startin
Hi,
On Thu, Feb 27, 2014 at 08:19:06AM +, Leigh Brown wrote:
> Did that driver work on the N810 at that point? If I look at the kernel
> tree at that point in time would all the components be there? It would
> make it easier if I had a starting point as I don't have any documentation
> so re
On 27/02/14 10:19, Leigh Brown wrote:
> In the following commit it states that you ported the old blizzard
> driver to
> the new omapdss driver:
>
> commit fdcb68884b3b0def9cc410d07adbafe7c3a9e537
> Author: Tomi Valkeinen
> Date: Tue May 10 17:31:20 2011 +0300
>
> OMAPFB: remove old blizz
luck
there =).
I do have N800 and N810 (no serial mods), so I might be able to give
some help there at some point, if I'm able to boot the board with usb
gadget ethernet (which hasn't been working for me for omap3 for some
time).
Hi Tomi,
In the following commit it states that you port
N810 (no serial mods), so I might be able to give
some help there at some point, if I'm able to boot the board with usb
gadget ethernet (which hasn't been working for me for omap3 for some time).
Tomi
signature.asc
Description: OpenPGP digital signature
s trying to get it working at but failed before
the driver got removed. Anyway, this is still on my "backlog" and at some
point I will try to reintroduce the display support. Meanwhile, the OMAP2
has been converted to DT so this is not going to be trivial so any help
in this effort is appre
ed by new ones.
> >
> > I will document the latest state of play with the N810 once I have
> > got things going. All I really want is a text console with working
> > keyboard and wifi, initially.
> >
> > Any help will be gratefully received.
>
> I can'
d when I discovered that a lot of
> the old drivers had been replaced by new ones.
>
> I will document the latest state of play with the N810 once I have
> got things going. All I really want is a text console with working
> keyboard and wifi, initially.
>
> Any help will be gr
System is an ODROID-X.
root@odroid:/1/cuSDR32# uname -a
Linux odroid 3.8.13.14 #1 SMP PREEMPT Sat Dec 21 22:14:31 UTC 2013
armv7l armv7l armv7l GNU/Linux
root@odroid:/1/cuSDR32# cat /etc/os-release
NAME="Ubuntu"
VERSION="13.10, Saucy Salamander"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 13.1
On 12/12/2013 09:05 AM, Denis CIOCCA wrote:
why is mcspi1 your interrupt parent when you did a padconf for GPIO?
you want GPIO136, so you need the right gpio block as the interrupt
parent and map interrupts in the correct map.
see [1] for an example (omap2).
Oh my god! Now I've understand how de
> why is mcspi1 your interrupt parent when you did a padconf for GPIO?
> you want GPIO136, so you need the right gpio block as the interrupt
> parent and map interrupts in the correct map.
> see [1] for an example (omap2).
Oh my god! Now I've understand how device tree works...I'm sorry
Nishanth b
On 12/12/2013 08:27 AM, Denis CIOCCA wrote:
> Maybe, this is more correctly but still doesn't work...
>
>
> From 9f6e524fa86834c3ab9a5f710021620a103019b2 Mon Sep 17 00:00:00 2001
> From: Denis Ciocca
> Date: Thu, 12 Dec 2013 14:52:39 +0100
> Subject: [PATCH] device tree
>
> ---
> arch/arm/bo
gt;;
+interrupts = <&mcspi1 136 IRQ_TYPE_LEVEL_HIGH>;
+interrupt-parent = <&mcspi1>;
+};
+};
+
&leds {
pinctrl-0 = <
&led_gpio_pins
--
1.7.9.5
No one can help me?
Thanks,
Denis
--
To unsubscribe from this list: sen
Hi Nishant,
I've configured the device tree as you told me. Now, my device tree code
is that:
diff --git a/arch/arm/boot/dts/omap4-panda-es.dts
b/arch/arm/boot/dts/omap4-panda-es.dts
index 816d1c9..5644260 100644
--- a/arch/arm/boot/dts/omap4-panda-es.dts
+++ b/arch/arm/boot/dts/omap4-panda-es.
On 12/11/2013 10:25 AM, Denis CIOCCA wrote:
>
> BUT, now I've checked the client->irq in an i2c driver and the value is
> still 0...
I missed this:
>
> and it works, but I don't know how I can set the interrupt using:
> interrupts = ; /* example */
>
> What I have to check?
since your interru
Hi Nishant,
Thank you very much for your suggestions! Now I understand how it
works...(I hope) :D
BUT, now I've checked the client->irq in an i2c driver and the value is
still 0...
What I have to check?
Thanks,
Denis
On 12/11/2013 04:39 PM, menon.nisha...@gmail.com wrote:
> On Wed, Dec 11,
On Wed, Dec 11, 2013 at 8:28 AM, Denis CIOCCA wrote:
> Hi everybody,
>
> I'm trying to configure an IRQ on pandaboard using device tree but I'm
> not able to understand how I can do it.
> I want to configure the the gpio_139 pin and without device tree my
> command was:
>
> OMAP4_MUX(MCSPI1_SIMO,
Hi everybody,
I'm trying to configure an IRQ on pandaboard using device tree but I'm
not able to understand how I can do it.
I want to configure the the gpio_139 pin and without device tree my
command was:
OMAP4_MUX(MCSPI1_SIMO, OMAP_MUX_MODE3 | OMAP_PIN_INPUT_PULLUP),
I need to associate it t
, such as:-
>
> usb@47401000 {
> status = "okay";
> dr_mode = "host";
> ti,force-host; /* force host mode */
> };
>
> Can anyone point me in the right direction as to where to put this extra code
> ?
>
> I see ther
code ?
I see there's a musb_am335x.c file, but that just seems to be a wrapper.
Any help would be greatly apperciated.
Regards
Mark J.
--
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
d to deffer probe. So add a help
>>> function of_dma_check_controller.
>>>
>>> DMA request channel functions can also used to check it, but they
>>> are usually called at open() time.
>>
>> This new function is almost identical to the existing
>
On Fri, Aug 23, 2013 at 04:36:53AM +0800, Stephen Warren wrote:
> On 08/22/2013 12:43 AM, Richard Zhao wrote:
> > DMA client device driver usually needs to know at probe time whether
> > dma controller has been registered to deffer probe. So add a help
> > function of
On 08/22/2013 12:43 AM, Richard Zhao wrote:
> DMA client device driver usually needs to know at probe time whether
> dma controller has been registered to deffer probe. So add a help
> function of_dma_check_controller.
>
> DMA request channel functions can also used to check it,
DMA client device driver usually needs to know at probe time whether
dma controller has been registered to deffer probe. So add a help
function of_dma_check_controller.
DMA request channel functions can also used to check it, but they
are usually called at open() time.
Signed-off-by: Richard
On Sunday 21 July 2013 07:10 AM, Linus Walleij wrote:
> On Sun, Jul 21, 2013 at 6:54 AM, Javier Martinez Canillas
> wrote:
>
>> Linus, are you still planing to send this patches as fixes for the
>> v3.11 -rc cycle or did you decide to wait for v3.12?
>
> It will go into the v3.11 RC:s.
>
Thanks
into the v3.11 RC:s.
>
Great, thanks a lot for your help!
> I've just been slow due to the current heatwave over northern Europe...
>
Haha, yes weather has been even worst here in southern Europe
> Yours,
> Linus Walleij
Best regards,
Javier
--
To unsubscribe from this list: sen
On Sun, Jul 21, 2013 at 6:54 AM, Javier Martinez Canillas
wrote:
> Linus, are you still planing to send this patches as fixes for the
> v3.11 -rc cycle or did you decide to wait for v3.12?
It will go into the v3.11 RC:s.
I've just been slow due to the current heatwave over northern Europe...
Y
Hi Soumya
On Saturday, July 20, 2013, Linus Walleij wrote:
>
> On Fri, Jul 12, 2013 at 4:05 PM, Soumya Sutar wrote:
>
> > Hi Linus,
> >
> > I am facing DT GPIO probing problem same as below link.
> > http://us.generation-nt.com/answer/gpio-crashed-when-not-using-
On Fri, Jul 12, 2013 at 4:05 PM, Soumya Sutar wrote:
> Hi Linus,
>
> I am facing DT GPIO probing problem same as below link.
> http://us.generation-nt.com/answer/gpio-crashed-when-not-using-help-208346861.html
>
> Could you know any patch is available for this issues or stil
On Tuesday 19 February 2013 04:00 PM, Mohammed, Afzal wrote:
Hi Santosh,
On Tue, Feb 19, 2013 at 15:55:59, Shilimkar, Santosh wrote:
With DT, IIRC DEBUGLL is broken. So did you hack debug-macro.S
to get the earlyprintk working ?
No, on linux-next, ll debug works properly.
Indeed. Tony fixe
Hi Santosh,
On Tue, Feb 19, 2013 at 15:55:59, Shilimkar, Santosh wrote:
> With DT, IIRC DEBUGLL is broken. So did you hack debug-macro.S
> to get the earlyprintk working ?
No, on linux-next, ll debug works properly.
Regards
Afzal
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z�
M33XXUART1
bool "AM33XX UART1"
+ help
+ Route low level debug messages to first uart instance
+ for boards based on am335 and am43 family of SoC's
config DEBUG_ZOOM_UART
bool "Zoom2/3 UART"
With
le changed, 3 insertions(+)
diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index aca..b717b78 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -542,6 +542,9 @@ choice
config DEBUG_AM33XXUART1
bool "AM33XX UART1"
le changed, 3 insertions(+)
diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index aca..b717b78 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -542,6 +542,9 @@ choice
config DEBUG_AM33XXUART1
bool "AM33XX UART1"
; don't
> >>>>> exist.
> >>>>> Without off mode, the modem always appears after resume.
> >>>>>
> >>>>> I discovered that the registers set by:
> >>>>>
> >>>>>drivers/mfd/omap-usb-hos
;>>>> disappears.
>>>>> i.e. 'lsusb' doesn't see it any more and the various ttyHSxx devices don't
>>>>> exist.
>>>>> Without off mode, the modem always appears after resume.
>>>>>
>>>>> I discovered that the re
yHSxx devices don't
> >>> exist.
> >>> Without off mode, the modem always appears after resume.
> >>>
> >>> I discovered that the registers set by:
> >>>
> >>>drivers/mfd/omap-usb-host.c
> >>>
> >>>
> I don't know the reason of the off_mode problem :(
> > >>>>
> > >>>> We have the equipment to check this and no - this is not the case.
> > >>>>
> > >>>>>
> > >>>>>> Can you suggest some way
me way I could test the hypothesis?
> >>>>>
> >>>>> I had the same problem on a rugged mobile phone, so it is just
> >>>>> experience
> >>>>> Check the modem power and reset gpio too, but if you don't need to
> >&g
d to
>>>>> unblock it
>>>>> with the pin after resume we know that modem is not the problem
>>>>
>>>> I don't think modem is the problem...
>>>> We have plain USB connector ports that are dead after the resume from
>>&g
s set by:
>>>
>>>drivers/mfd/omap-usb-host.c
>>>
>>> are not maintained across as suspend/resume so I added the following patch
>>> (which I can make a formal submission of if it looks right to others), but
>>> that didn't help (or didn
d across as suspend/resume so I added the following patch
> > (which I can make a formal submission of if it looks right to others), but
> > that didn't help (or didn't help enough).
> >
> > If I
> >
> > echo 1 > /sys/kernel/debug/pm_debug/usbhos
n't need to
> >>> unblock it
> >>> with the pin after resume we know that modem is not the problem
> >>
> >> I don't think modem is the problem...
> >> We have plain USB connector ports that are dead after the resume from
> >> off-mo
lways appears after resume.
>
> I discovered that the registers set by:
>
>drivers/mfd/omap-usb-host.c
>
> are not maintained across as suspend/resume so I added the following patch
> (which I can make a formal submission of if it looks right to others), but
> that didn't help
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/16/13 09:26, NeilBrown wrote:
> On Wed, 09 Jan 2013 14:54:00 +0200 Igor Grinberg
> wrote:
>
>> On 01/09/13 14:08, Michael Trimarchi wrote:
>>> Hi Neil
>>>
>>> I forget to answer to your questions
>>>
>>> On 01/09/2013 12:34 PM, NeilBrown wrote:
On Wed, 09 Jan 2013 12:42:43 +0100 Michael Trimarchi
wrote:
> On 01/09/2013 12:34 PM, NeilBrown wrote:
> > On Wed, 09 Jan 2013 11:24:09 +0100 Michael Trimarchi
> > wrote:
> >
> >> Hi Neil
> >>
> >> On 01/09/2013 11:19 AM, NeilBrown wrote:
> >>> On Wed, 09 Jan 2013 12:00:05 +0200 Igor Grinberg
On Wed, 09 Jan 2013 14:54:00 +0200 Igor Grinberg
wrote:
> On 01/09/13 14:08, Michael Trimarchi wrote:
> > Hi Neil
> >
> > I forget to answer to your questions
> >
> > On 01/09/2013 12:34 PM, NeilBrown wrote:
> >> On Wed, 09 Jan 2013 11:24:09 +0100 Michael Trimarchi
> >> wrote:
> >>
> >>> Hi Ne
On 01/09/13 14:08, Michael Trimarchi wrote:
> Hi Neil
>
> I forget to answer to your questions
>
> On 01/09/2013 12:34 PM, NeilBrown wrote:
>> On Wed, 09 Jan 2013 11:24:09 +0100 Michael Trimarchi
>> wrote:
>>
>>> Hi Neil
>>>
>>> On 01/09/2013 11:19 AM, NeilBrown wrote:
On Wed, 09 Jan 2013 1
Hi Neil
I forget to answer to your questions
On 01/09/2013 12:34 PM, NeilBrown wrote:
> On Wed, 09 Jan 2013 11:24:09 +0100 Michael Trimarchi
> wrote:
>
>> Hi Neil
>>
>> On 01/09/2013 11:19 AM, NeilBrown wrote:
>>> On Wed, 09 Jan 2013 12:00:05 +0200 Igor Grinberg
>>> wrote:
>>>
-BEGIN
On 01/09/2013 12:34 PM, NeilBrown wrote:
> On Wed, 09 Jan 2013 11:24:09 +0100 Michael Trimarchi
> wrote:
>
>> Hi Neil
>>
>> On 01/09/2013 11:19 AM, NeilBrown wrote:
>>> On Wed, 09 Jan 2013 12:00:05 +0200 Igor Grinberg
>>> wrote:
>>>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
>>>
>>>
On Wed, 09 Jan 2013 11:24:09 +0100 Michael Trimarchi
wrote:
> Hi Neil
>
> On 01/09/2013 11:19 AM, NeilBrown wrote:
> > On Wed, 09 Jan 2013 12:00:05 +0200 Igor Grinberg
> > wrote:
> >
> >> -BEGIN PGP SIGNED MESSAGE-
> >> Hash: SHA1
> >
> >> Hi Neil,
> >
> >> On 01/09/13 00:29, NeilBro
bled the GSM module
>>> disappears.
>>> i.e. 'lsusb' doesn't see it any more and the various ttyHSxx devices don't
>>> exist.
>>> Without off mode, the modem always appears after resume.
>>>
>>> I discovered that the regist
gt; >
> > I discovered that the registers set by:
> >
> >drivers/mfd/omap-usb-host.c
> >
> > are not maintained across as suspend/resume so I added the following patch
> > (which I can make a formal submission of if it looks right to others), but
>
rious ttyHSxx devices don't
> exist.
> Without off mode, the modem always appears after resume.
>
> I discovered that the registers set by:
>
>drivers/mfd/omap-usb-host.c
>
> are not maintained across as suspend/resume so I added the following patch
> (which I can
ntained across as suspend/resume so I added the following patch
(which I can make a formal submission of if it looks right to others), but
that didn't help (or didn't help enough).
If I
echo 1 > /sys/kernel/debug/pm_debug/usbhost_pwrdm/suspend
thus keeping just the USBHOST powe
CTRL
> access faults in the same way (i.e. the whole ISP is borked, not just
> the previewer).
>
> At first I thought the clocks were being disabled somehow, but tracking
> them seems to indicate that's not the case. Adding an early return in
> arch/arm/mach/omap2/clock.c omap
).
At first I thought the clocks were being disabled somehow, but tracking
them seems to indicate that's not the case. Adding an early return in
arch/arm/mach/omap2/clock.c omap2_dflt_clk_disable() (i.e. to disable
disabling of clocks) does NOT help.
What else might I be missing? What is nec
Hi,
On 09/28/2012 09:58 AM, Vutla, Lokesh wrote:
> Hi,
> I see a module build failure in linux-next tree.
> Any one else facing this issue or I am missing something.
> Using master branch on
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> Below is the log .
>
> $ make module
Hi Tony,
On 09/27/2012 03:26 PM, Tony Lindgren wrote:
> Please see below a status update on the remaining problem
> plat headers.
>
> Note that all patches should be against current linux next
> in this case.
>
[snip]
>> dmtimer.h
>
> Jon, can you do a patch for dmtimer.h?
Yes, I will look i
Hi Peter,
On Fri, Sep 28, 2012 at 2:24 PM, Peter Ujfalusi wrote:
> On 09/27/2012 12:57 PM, Vutla, Lokesh wrote:
>>> clkdev_omap.h
>>> clock.h
>>> common.h
>>> cpu.h
>>> dma-44xx.h
>>> dma.h
>> As a part of clean up I am looking at dma.h and dma-44xx.h files
>> ll send you patches once cleanup and
On 09/27/2012 12:57 PM, Vutla, Lokesh wrote:
>> clkdev_omap.h
>> clock.h
>> common.h
>> cpu.h
>> dma-44xx.h
>> dma.h
> As a part of clean up I am looking at dma.h and dma-44xx.h files
> ll send you patches once cleanup and testing is done.
One note for the dma.h, dma-44xx.h:
The audio drivers used
+ Peter, Liam in case they haven't seen the issue yet.
On Fri, Sep 28, 2012 at 12:28 PM, Vutla, Lokesh wrote:
> Hi,
> I see a module build failure in linux-next tree.
> Any one else facing this issue or I am missing something.
> Using master branch on
> git://git.kernel.org/pub/scm/linux/kernel/g
Hi,
I see a module build failure in linux-next tree.
Any one else facing this issue or I am missing something.
Using master branch on
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
Below is the log .
$ make modules -j 10
CHK include/linux/version.h
CHK include/genera
Hi Tony,
On Fri, Sep 28, 2012 at 01:56:16, Tony Lindgren wrote:
> Please see below a status update on the remaining problem
> plat headers.
> > gpmc.h
>
> Afzal, can you do a patch for gpmc.h?
Yes, I will do it.
Regards
Afzal
* Shilimkar, Santosh [120927 13:34]:
> On Fri, Sep 28, 2012 at 1:56 AM, Tony Lindgren wrote:
> >
> > Please see below a status update on the remaining problem
> > plat headers.
> >
> > Note that all patches should be against current linux next
> > in this case.
> >
> > * Tony Lindgren [120920 16
On Fri, Sep 28, 2012 at 1:56 AM, Tony Lindgren wrote:
>
> Please see below a status update on the remaining problem
> plat headers.
>
> Note that all patches should be against current linux next
> in this case.
>
> * Tony Lindgren [120920 16:30]:
> >
> > $ ls arch/arm/plat-omap/include/plat/
[..
Missed omap-pm.h and omap-secure.h, see below..
* Tony Lindgren [120927 13:27]:
> Please see below a status update on the remaining problem
> plat headers.
>
> Note that all patches should be against current linux next
> in this case.
>
> * Tony Lindgren [120920 16:30]:
> >
> > $ ls arch/arm/
Please see below a status update on the remaining problem
plat headers.
Note that all patches should be against current linux next
in this case.
* Tony Lindgren [120920 16:30]:
>
> $ ls arch/arm/plat-omap/include/plat/
> clkdev_omap.h
> clock.h
Paul posted patches for the clock headers.
> com
* Vutla, Lokesh [120927 02:59]:
> > dma-44xx.h
> > dma.h
> As a part of clean up I am looking at dma.h and dma-44xx.h files
> ll send you patches once cleanup and testing is done.
OK great that's good to hear.
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the b
* Tomi Valkeinen [120927 03:13]:
> On Thu, 2012-09-20 at 16:29 -0700, Tony Lindgren wrote:
> > Hi all,
> >
> > With the recent pull request I sent for v3.7, we now have pretty
> > much all the mach includes fixed up for omap2+ for single zImage
> > support.
> >
> > We still have quite a few plat
On Thu, 2012-09-20 at 16:29 -0700, Tony Lindgren wrote:
> Hi all,
>
> With the recent pull request I sent for v3.7, we now have pretty
> much all the mach includes fixed up for omap2+ for single zImage
> support.
>
> We still have quite a few plat headers that we need to sort
> out manually.
>
>
merge
> window, but won't be looking much at the driver related
> headers. So some help would be appreciated here :)
>
> Regards,
>
> Tony
>
>
> $ ls arch/arm/plat-omap/include/plat/
> clkdev_omap.h
> clock.h
> common.h
> cpu.h
> dma-44xx.h
> dma.h
As
> > 3. Drivers should not include anything from plat or mach.
> >
> > I'll be looking into getting rid of cpu.h etc for v3.8 merge
> > window, but won't be looking much at the driver related
> > headers. So some help would be appreciated here :)
> >
n
>include/linux/platform_data/*.h
>
> 2. For mach-omap2 specific things, the headers should be
>in arch/arm/mach-omap2.
>
> 3. Drivers should not include anything from plat or mach.
>
> I'll be looking into getting rid of cpu.h etc for v3.8 merge
> window,
1 - 100 of 357 matches
Mail list logo
