On 08/04/14 23:51, Sebastian Reichel wrote:
Do not try to initialize display for DT boot, since omapdss
is now initialized via Device Tree. Without this patch the
display subsystem does not properly come up.
Signed-off-by: Sebastian Reichel s...@kernel.org
---
Hi,
This patch should be
On Tuesday 08 April 2014 08:47 PM, Santosh Shilimkar wrote:
On Tuesday 08 April 2014 10:53 AM, Sekhar Nori wrote:
On Friday 04 April 2014 03:48 PM, Russell King - ARM Linux wrote:
On Fri, Apr 04, 2014 at 03:40:29PM +0530, Sekhar Nori wrote:
diff --git a/arch/arm/mach-omap2/omap4-common.c
I2c core supports defualt probing functionality for devices not registered
through
dt/board files. If there are any client driver registered, i2c core will try to
check if there is any device present corresponding to the address supplied by
the client driver. If the device is actually present and
I2c core supports defualt probing functionality for devices not registered
through
dt/board files. If there are any client driver registered, i2c core will try to
check if there is any device present corresponding to the address supplied by
the client driver. If the device is actually present and
) in next-20140409
if you are dropping HWMON
adap-class = I2C_CLASS_HWMON | I2C_CLASS_DEPRECATED;
this might be a good time to explain why.
Also drop the following testing information down into diffstat
section, there is no need to retain that information in git history.
Tested i2c enumeration
On Wed, Apr 09, 2014 at 04:06:48PM +0530, Sourav Poddar wrote:
I2c core supports defualt probing functionality for devices not registered
through
dt/board files. If there are any client driver registered, i2c core will try
to
check if there is any device present corresponding to the address
Hi,
http://slexy.org/raw/s2pkLsiFBX
I noticed the following sets of warnings with omap2plus_defconfig on
next-20140409. As per older logs, next-20140401 had it and v3.14 tag
also had it (I have'nt retained older logs).
[0.226189] [ cut here ]
[0.226258] WARNING
PM, Nishanth Menon wrote:
Hi,
http://slexy.org/raw/s2pkLsiFBX
I noticed the following sets of warnings with omap2plus_defconfig on
next-20140409. As per older logs, next-20140401 had it and v3.14 tag
also had it (I have'nt retained older logs).
[0.226189] [ cut here
03:41 PM, Nishanth Menon wrote:
Hi,
http://slexy.org/raw/s2pkLsiFBX
I noticed the following sets of warnings with omap2plus_defconfig on
next-20140409. As per older logs, next-20140401 had it and v3.14 tag
also had it (I have'nt retained older logs).
[0.226189] [ cut here
On 04/09/2014 07:41 AM, Nishanth Menon wrote:
Hi,
http://slexy.org/raw/s2pkLsiFBX
I noticed the following sets of warnings with omap2plus_defconfig on
next-20140409. As per older logs, next-20140401 had it and v3.14 tag
also had it (I have'nt retained older logs).
Here is a quick list
Return to the 'phy' field of 'struct usb_hcd' its historic name 'transceiver'.
This is in preparation to adding the generic PHY support.
Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
---
This patch is against the 'usb-next' branch of Greg KH's 'usb.git' repo.
On Tue, Apr 08, 2014 at 05:02:37PM +0200, Laurent Pinchart wrote:
On Tuesday 08 April 2014 15:43:22 Joerg Roedel wrote:
Who is someone in this case?
That's exactly the problem :-) The ARM DMA API implementation doesn't care
who
that someone is. Existing implementations call those
OMAP3 doesn't contain l3_init_clkdm clock domain. Use the
proper clock domains for USB Host and USB TLL modules.
Gets rid of the following warnings during boot
omap_hwmod: usb_host_hs: could not associate to clkdm l3_init_clkdm
omap_hwmod: usb_tll_hs: could not associate to clkdm l3_init_clkdm
On 04/09/2014 10:16 AM, Roger Quadros wrote:
OMAP3 doesn't contain l3_init_clkdm clock domain. Use the
proper clock domains for USB Host and USB TLL modules.
Gets rid of the following warnings during boot
omap_hwmod: usb_host_hs: could not associate to clkdm l3_init_clkdm
omap_hwmod:
On 04/09/2014 07:57 AM, Sergei Shtylyov wrote:
Return to the 'phy' field of 'struct usb_hcd' its historic name
'transceiver'.
This is in preparation to adding the generic PHY support.
Surely if the correct term is transceiver, we should be adding generic
transceiver support not generic PHY
On Tue, Apr 08, 2014 at 08:23:39PM +0530, Sekhar Nori wrote:
On Friday 04 April 2014 03:48 PM, Russell King - ARM Linux wrote:
On Fri, Apr 04, 2014 at 03:40:29PM +0530, Sekhar Nori wrote:
diff --git a/arch/arm/mach-omap2/omap4-common.c
b/arch/arm/mach-omap2/omap4-common.c
index
Hello.
On 04/09/2014 07:31 PM, Stephen Warren wrote:
Return to the 'phy' field of 'struct usb_hcd' its historic name 'transceiver'.
This is in preparation to adding the generic PHY support.
Surely if the correct term is transceiver, we should be adding generic
transceiver support not
On Tue, Apr 08, 2014 at 11:17:17AM -0400, Santosh Shilimkar wrote:
On Tuesday 08 April 2014 10:53 AM, Sekhar Nori wrote:
On Friday 04 April 2014 03:48 PM, Russell King - ARM Linux wrote:
On Fri, Apr 04, 2014 at 03:40:29PM +0530, Sekhar Nori wrote:
diff --git
On 04/09/2014 10:27 AM, Sergei Shtylyov wrote:
Hello.
On 04/09/2014 07:31 PM, Stephen Warren wrote:
Return to the 'phy' field of 'struct usb_hcd' its historic name
'transceiver'.
This is in preparation to adding the generic PHY support.
Surely if the correct term is transceiver, we
On Wednesday 09 April 2014 12:33 PM, Russell King - ARM Linux wrote:
On Tue, Apr 08, 2014 at 11:17:17AM -0400, Santosh Shilimkar wrote:
On Tuesday 08 April 2014 10:53 AM, Sekhar Nori wrote:
On Friday 04 April 2014 03:48 PM, Russell King - ARM Linux wrote:
On Fri, Apr 04, 2014 at 03:40:29PM
On 04/09/2014 08:48 PM, Stephen Warren wrote:
Return to the 'phy' field of 'struct usb_hcd' its historic name
'transceiver'.
This is in preparation to adding the generic PHY support.
Surely if the correct term is transceiver, we should be adding generic
transceiver support not generic PHY
On 04/09/2014 10:53 AM, Sergei Shtylyov wrote:
On 04/09/2014 08:48 PM, Stephen Warren wrote:
Return to the 'phy' field of 'struct usb_hcd' its historic name
'transceiver'.
This is in preparation to adding the generic PHY support.
Surely if the correct term is transceiver, we should be
On 04/09/2014 09:37 PM, Stephen Warren wrote:
Return to the 'phy' field of 'struct usb_hcd' its historic name
'transceiver'.
This is in preparation to adding the generic PHY support.
Surely if the correct term is transceiver, we should be adding generic
transceiver support not generic PHY
On Wed, 9 Apr 2014, Sergei Shtylyov wrote:
Ok, the existing field is being replaced by something? I didn't get that
No, not replaced. I'm adding the support for generic PHY to the existing
USB PHY support. I thought that was clear from the changelog.
from the patch description; I
Adds a period and a polarity member to struct pwm_lookup so that when performing
a lookup using the lookup table instead of device tree, we are able to set the
period and the polarity accordingly like what is done in
of_pwm_xlate_with_flags.
Signed-off-by: Alexandre Belloni
Now that the PWM core is able to set the period and polarity based on
the lookup table, add those to PWM_LOOKUP to ease their usage.
Signed-off-by: Alexandre Belloni alexandre.bell...@free-electrons.com
---
Documentation/pwm.txt | 3 ++-
Hi,
a small patch set as suggested byt Thierry to make lokkup with the lookup table
instead of device tree bahve more like when using device tree.
The first patch adds a period annd a polarity member to the lookup table and use
those to set period and polarity.
The second patch changes
Hello.
On 04/09/2014 09:56 PM, Alan Stern wrote:
Ok, the existing field is being replaced by something? I didn't get that
No, not replaced. I'm adding the support for generic PHY to the existing
USB PHY support. I thought that was clear from the changelog.
from the patch
On 04/09/2014 12:16 PM, Sergei Shtylyov wrote:
Hello.
On 04/09/2014 09:56 PM, Alan Stern wrote:
Ok, the existing field is being replaced by something? I didn't get
that
No, not replaced. I'm adding the support for generic PHY to the
existing
USB PHY support. I thought that was
On 04/09/2014 11:01 PM, Stephen Warren wrote:
Ok, the existing field is being replaced by something? I didn't get
that
No, not replaced. I'm adding the support for generic PHY to the
existing
USB PHY support. I thought that was clear from the changelog.
from the patch description; I
On Wed, Apr 09, 2014 at 08:04:08PM +0200, Alexandre Belloni wrote:
Adds a period and a polarity member to struct pwm_lookup so that when
performing
a lookup using the lookup table instead of device tree, we are able to set the
period and the polarity accordingly like what is done in
On 09/04/2014 at 20:37:06 +0100, Russell King - ARM Linux wrote :
On Wed, Apr 09, 2014 at 08:04:08PM +0200, Alexandre Belloni wrote:
Adds a period and a polarity member to struct pwm_lookup so that when
performing
a lookup using the lookup table instead of device tree, we are able to set
On Wed, Apr 09, 2014 at 08:04:09PM +0200, Alexandre Belloni wrote:
Now that the PWM core is able to set the period and polarity based on
the lookup table, add those to PWM_LOOKUP to ease their usage.
I would prefer if this change was made in a non-atomic manner.
1. Add new infrastructure
2.
33 matches
Mail list logo
