Hi,
On 02/06/2013 02:30 PM, Benoit Cousson wrote:
>> So a patch is being merged to handle triggers in the case of pwm leds [1].
>> When done, we will be able to add back the default trigger. Do you want
>> to wait on it to merge this series?
>
> What kind of dependency do we have between these tw
Hi,
On Thursday 07 February 2013 11:51 AM, Rajendra Nayak wrote:
[]...
diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
b/Documentation/devicetree/bindings/usb/omap-usb.txt
index 29a043e..4688265 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentatio
[]...
diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
b/Documentation/devicetree/bindings/usb/omap-usb.txt
index 29a043e..4688265 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -15,6 +15,7 @@ OMAP MUSB
On Mon, 4 Feb 2013, Rajendra Nayak wrote:
> OMAP4 CHIP level PM works only with newer bootloaders. The
> dependency on the bootloader comes from the fact that the
> kernel is missing reset and initialization code for some
> devices.
>
> While the right thing to do is to add reset and init code in
Here are some basic OMAP test results for Linux v3.8-rc6.
Logs and other details at:
http://www.pwsan.com/omap/testlogs/test_v3.8-rc6/20130206155004/
Test summary
Boot to userspace:
Pass ( 9/11): 2420n800, 2430sdp, 3517evm, 3530es3beagle,
3730beaglexm, 37
Hi Matthieu,
On Tue, 22 Jan 2013, Paul Walmsley wrote:
> Any progress on updating and resending your "omap3 nand : use
> NAND_BUSWIDTH_AUTO" patch? We're in danger of missing the 3.9 merge
> window if it takes too much longer.
Could you let us know if you're planning to update and repost this
On Sat, 26 Jan 2013, Felipe Balbi wrote:
> Hi,
>
> On Sat, Jan 26, 2013 at 08:40:07AM +, Paul Walmsley wrote:
> > Boot tests:
> >
> > * am335xbone: hangs after "Starting kernel"
> > - Cause unknown; may be due to CONFIG_EARLY_PRINTK=y?
> > - http://www.mail-archive.com/linux-omap@vger.ke
Hi Wim,
On Mon, 28 Jan 2013, Aaro Koskinen wrote:
> On Thu, Dec 27, 2012 at 10:58:29PM +0200, Aaro Koskinen wrote:
> > Introduce Retu watchdog driver.
>
> Wim, any comments about this driver? Do you think it could be queued
> for 3.9?
It'd be really great if this could go in for v3.9. Without
This is a long story where for each new generation of
OMAP we used different approaches for creating
strings for SoCs names and revisions that this patch
fixes. It makes future exporting of this information
to SoC infrastructure easier.
Signed-off-by: Ruslan Bilovol
---
arch/arm/mach-omap2/id.c
In some situations it is useful for userspace to
know some SoC-specific information. For example,
this may be used for deciding what kernel module to
use or how to better configure some settings etc.
This patch exports OMAP SoC information to userspace
using existing in Linux kernel SoC infrastruct
Hi,
This patch series is an attempt to export some OMAP SoC
information (like name, revision etc.) to userspace.
The first patch does some unification of OMAP SoC
information representation in current sources.
Second patch adds exactly needed changes using
exists in Linux kernel SoC infrastructure
I needed this when compiling for pandaboard at commit:
0944c0a03465718909ba8e800a5230528aeabafb
Signed-off-by: André Hentschel From:
=?UTF-8?q?Andr=C3=A9=20Hentschel?=
From: =?UTF-8?q?Andr=C3=A9=20Hentschel?=
Date: Wed, 6 Feb 2013 23:16:20 +0100
Subject: [PATCH] arm: Include soc.h to fix compi
On Wed, 30 Jan 2013 01:23:48 +0100
Laurent Pinchart wrote:
> Hi Antonio,
>
Sorry for the delay Laurent and thanks for your reply, some more
questions below.
> On Monday 28 January 2013 13:22:10 Antonio Ospite wrote:
> > Hi,
> >
> > looking at the MIPI Alliance Specification for Camera Serial I
On Wed, 6 Feb 2013, Paul Walmsley wrote:
> Setting CONFIG_EARLY_PRINTK=n doesn't fix the problem I'm seeing.
And just tried this with u-boot v2013.01 on a BeagleBoard A6a, does not
fix it.
> > If you still have issues booting can you update your U-Boot to v2013.01
> > since things
> > seem to
On Wed, Feb 6, 2013 at 9:19 PM, Tony Lindgren wrote:
> Hi,
>
> * Ruslan Bilovol [130206 11:03]:
>> This is a long story where for each new generation of
>> OMAP we used different approaches for creating
>> strings for SoCs names and revisions that this patch
>> fixes. It makes future exporting of
Hi Vaibhav,
On Thu, 24 Jan 2013, Bedia, Vaibhav wrote:
> I could not track down U-Boot that you were using
It's posted now at:
http://www.pwsan.com/omap/bootloaders/beaglebone/u-boot/2011.09-9-gcf6e04d__20120803171543/
Care to try it?
> However, using your build configs for v3.7 and v3.8-
On Sun, 30 Dec 2012, Paul Walmsley wrote:
> There shouldn't be any need to jump to SRAM code if the OMAP CORE
> clockdomain (and consequently the SDRAM controller and CORE PLL) stays
> active during MPU WFI. The SRAM code should only be needed when the RAM
> enters self-refresh. So in the case w
On 02/06/2013 03:03 PM, Jon Hunter wrote:
> If the device-tree blob is present during boot, then register the SDMA
> controller with the device-tree DMA driver so that we can use device-tree
> to look-up DMA client information.
>
> Signed-off-by: Jon Hunter
> ---
> drivers/dma/omap-dma.c | 31
If the device-tree blob is present during boot, then register the SDMA
controller with the device-tree DMA driver so that we can use device-tree
to look-up DMA client information.
Signed-off-by: Jon Hunter
---
drivers/dma/omap-dma.c | 31 ++-
1 file changed, 30 inse
Add SDMA controller binding for OMAP2+ devices and populate DMA client
information for SPI and MMC periperhal on OMAP3+ devices. Please note
that OMAP24xx devices do not have SPI and MMC bindings available yet and
so DMA client information is not populated.
Signed-off-by: Jon Hunter
---
.../devi
Adds device-tree bindings from SDMA on OMAP2+ devices. DMA client
bindings are also added for devices that have SPI and MMC bindings
populated. Client binding data is based upon existing HWMOD data for
OMAP and has been checked against OMAP documentation.
Testing includes ...
1. Boot tested on OMA
From: Mugunthan V N
Date: Tue, 5 Feb 2013 23:56:46 +0530
> CPSW is capable of filtering VLAN packets in hardware. This patch series
> implements VLAN support to CPSW driver.
> This patch series is tested on net-next with AM335x EVM with ping test.
Series applied.
--
To unsubscribe from this list
Hi,
* Ruslan Bilovol [130206 11:03]:
> This is a long story where for each new generation of
> OMAP we used different approaches for creating
> strings for SoCs names and revisions that this patch
> fixes. It makes future exporting of this information
> to SoC infrastructure easier.
>
> Signed-o
This is a long story where for each new generation of
OMAP we used different approaches for creating
strings for SoCs names and revisions that this patch
fixes. It makes future exporting of this information
to SoC infrastructure easier.
Signed-off-by: Ruslan Bilovol
---
arch/arm/mach-omap2/id.c
In some situations it is useful for userspace to
know some SoC-specific information. For example,
this may be used for deciding what kernel module to
use or how to better configure some settings etc.
This patch exports OMAP SoC information to userspace
using existing in Linux kernel SoC infrastruct
Hi,
This patch series is an attempt to export some OMAP SoC
information (like name, revision etc.) to userspace.
The first patch does some unification of OMAP SoC
information representation in current sources.
Second patch adds exactly needed changes using
exists in Linux kernel SoC infrastructure
* Jon Hunter [130205 16:26]:
>
> Actually, let me look into this a bit more. It appears that for all
> omap2+ devices NOR should be mapped to CS0 at 0x0800. So I am
> wondering if the boot-loader is re-mapping the CS0 space. If it is then
> may be we can avoid having such hacks in the kernel
The following changes since commit 949db153b6466c6f7cad5a427ecea94985927311:
Linux 3.8-rc5 (2013-01-25 11:57:28 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap
tags/omap-for-v3.9/twl-signed-v2
for you to fetch changes up to 668
* Peter Ujfalusi [130205 23:25]:
> On 02/05/2013 07:40 PM, Tony Lindgren wrote:
> >> For some reason the CONFIG_DEBUG_SECTION_MISMATCH got disabled in my
> >> rolling
> >> kernel config...
> >
> > At least gcc version 4.3.5 (Debian 4.3.5-4) shows them. What's
> > the compiler you have?
>
> It
On Wed, 6 Feb 2013, Felipe Balbi wrote:
> Hi,
>
> On Wed, Feb 06, 2013 at 05:27:52PM +0530, Vivek Gautam wrote:
> > Hi Tony,
> >
> >
> > On Fri, Oct 5, 2012 at 9:57 PM, Tony Lindgren wrote:
> > > * Tony Lindgren [121004 18:41]:
> > >> >
> > >> > > Also on the EHCI port, I've seen issues where
On Wed, 6 Feb 2013, Felipe Balbi wrote:
> > I can't reproduce the problem on Panda, but I can on Beagle with a slightly
> > different behaviour.
> >
> > 1) connecting/disconnecting device directly to the beagleboard's USB port
> > works fine.
> >
> > 2) If I connect a USB Hub to the port and co
Hi,
On Wed, Feb 06, 2013 at 05:03:36PM +0200, Roger Quadros wrote:
> On 02/06/2013 03:51 PM, Felipe Balbi wrote:
> > Hi,
> >
> > On Wed, Feb 06, 2013 at 05:27:52PM +0530, Vivek Gautam wrote:
> >> Hi Tony,
> >>
> >>
> >> On Fri, Oct 5, 2012 at 9:57 PM, Tony Lindgren wrote:
> >>> * Tony Lindgren
On Wed, Feb 6, 2013 at 1:56 AM, Tony Lindgren wrote:
> * Ruslan Bilovol [130131 11:28]:
>> This is a long story where for each new generation of
>> OMAP we used different approaches for creating
>> strings for SoCs names and revisions that this patch
>> fixes. It makes future exporting of this in
On 02/06/2013 03:51 PM, Felipe Balbi wrote:
> Hi,
>
> On Wed, Feb 06, 2013 at 05:27:52PM +0530, Vivek Gautam wrote:
>> Hi Tony,
>>
>>
>> On Fri, Oct 5, 2012 at 9:57 PM, Tony Lindgren wrote:
>>> * Tony Lindgren [121004 18:41]:
>
>> Also on the EHCI port, I've seen issues where unplugging
Add omap control usb data in omap5 device tree file. This will have the
register address of registers to power on the USB2 PHY and USB3 PHY. The
information for the node added here is available in
Documentation/devicetree/bindings/usb/omap-usb.txt
Signed-off-by: Kishon Vijay Abraham I
---
arch/a
Hi Benoit,
Here are the dt data patches to get usb device functional in OMAP platforms.
This series applies cleanly in both for_3.9/dts and 3.8-rc6.
All the patches deal with modifying arch/arm/boot except one which modifies
Documentation/../usb/omap-usb.txt
Kishon Vijay Abraham I (8):
ARM: dt
Add usb otg data node in omap4/omap3 device tree file. Also update
the node with board specific setting in omapx-.dts file.
The dt data specifies among others the interface type (ULPI or UTMI), mode
which is mostly OTG, power that specifies the amount of power this can supply
when in host mode.
The
Add omap-usb3 and omap-usb2 data node in omap5 device tree file.
The information for the node added here is available @
Documentation/devicetree/bindings/usb/usb-phy.txt
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/boot/dts/omap5.dtsi | 14 ++
1 file changed, 14 insertions(+)
Add omap-usb2 data node in omap4 device tree file. Since omap-usb2 is
connected to ocp2scp, omap-usb2 dt data is added as a child node
of ocp2scp. The information about this data node is availabe @
Documentation/devicetree/bindings/usb/usb-phy.txt
Acked-by: Felipe Balbi
Signed-off-by: Kishon Vija
Add omap control usb data in omap4 device tree file. This will have the
register address of registers to power on the PHY and to write to
mailbox. The information about this data node is available @
Documentation/devicetree/bindings/usb/omap-usb.txt
Signed-off-by: Kishon Vijay Abraham I
---
arch
Add dwc3 omap glue data to the omap5 dt data file. The information about
the dt node added here is available @
Documentation/devicetree/bindings/usb/omap-usb.txt
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/boot/dts/omap5.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --gi
Add dwc3 core dt data as a subnode to dwc3 omap glue data in omap5 dt
data file. The information for the entered data node is available @
Documentation/devicetree/bindings/usb/dwc3.txt
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/boot/dts/omap5.dtsi |7 +++
1 file changed, 7 insert
Add ocp2scp data node in omap5 device tree file. The information for
the node added here can be found @
Documentation/devicetree/bindings/bus/omap-ocp2scp.txt
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/boot/dts/omap5.dtsi |8
1 file changed, 8 insertions(+)
diff --git a/arc
On 02/06/2013 08:15 AM, Mark Jackson wrote:
> When setting the GPMC device type, make sure any previous
> bits are cleared down, before applying the new setting.
>
> Signed-off-by: Mark Jackson
> ---
> arch/arm/mach-omap2/gpmc.c |4
> 1 file changed, 4 insertions(+)
>
> diff --git a/a
Update Maintainer email for omap_hsmmc,
as Venkatraman will no longer be able to maintain omap_hsmmc driver.
Signed-off-by: Balaji T K
Acked-by: Venkatraman S
---
MAINTAINERS |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 92e726c..f3192
Hi all !
Le 06/02/2013 14:30, Benoit Cousson a écrit :
Salut Florian,
On 02/04/2013 10:14 AM, Florian Vaussard wrote:
Hello Benoit,
On 01/24/2013 01:21 PM, Benoit Cousson wrote:
+ Peter who did the original PWM
Hi Florian,
On 01/23/2013 06:56 PM, Florian Vaussard wrote:
Hello Benoit,
Thi
On Wed, Feb 06, 2013 at 02:15:34PM +, Mark Jackson wrote:
> When setting the GPMC device type, make sure any previous
> bits are cleared down, before applying the new setting.
>
> Signed-off-by: Mark Jackson
looks alright:
Reviewed-of-by: Felipe Balbi
--
balbi
signature.asc
Description
When setting the GPMC device type, make sure any previous
bits are cleared down, before applying the new setting.
Signed-off-by: Mark Jackson
---
arch/arm/mach-omap2/gpmc.c |4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 1a
Hi,
On Wed, Feb 06, 2013 at 05:27:52PM +0530, Vivek Gautam wrote:
> Hi Tony,
>
>
> On Fri, Oct 5, 2012 at 9:57 PM, Tony Lindgren wrote:
> > * Tony Lindgren [121004 18:41]:
> >> >
> >> > > Also on the EHCI port, I've seen issues where unplugging
> >> > > the cable hangs kernel with an infinite
On Friday 01 February 2013, Matt Porter wrote:
>
> This series adds DT DMA Engine Client support to the omap_hsmmc.
> It leverages the generic DMA OF helpers in -next and the
> dma_request_slave_channel_compat() wrapper introduced in the
> AM33XX DMA Engine series to support DMA in omap_hsmmc on p
Salut Florian,
On 02/04/2013 10:14 AM, Florian Vaussard wrote:
> Hello Benoit,
>
> On 01/24/2013 01:21 PM, Benoit Cousson wrote:
>> + Peter who did the original PWM
>>
>> Hi Florian,
>>
>> On 01/23/2013 06:56 PM, Florian Vaussard wrote:
>>> Hello Benoit,
>>>
>>> This patchset adds some new DT sup
Hi Greg,
Here is the patch series that includes the arch/arm part to get MUSB
working in OMAP platforms. As discussed in the other mail thread with
Tony, this patch series should go into usb-next.
This patch series also contains a patch by Felipe to fix compilation
warning in usb-next when CONFIG
This is w.r.t the changes in PHY library to support adding and getting
multiple PHYs of the same type. In the new design, the
binding information between the PHY and the USB controller should be
specified in the platform specific initialization code. So it's been
done here for OMAP platforms.
Sign
Added has_mailbox to the musb platform data to specify that omap uses
an external mailbox (in control module) to communicate with the musb
core during device connect and disconnect.
Signed-off-by: Kishon Vijay Abraham I
Acked-by: Tony Lindgren
---
arch/arm/mach-omap2/usb-musb.c |3 +++
incl
A seperate driver has been added to handle the usb part of control
module. A device for the above driver is created here, using the register
address information to be used by the driver for powering on the PHY and
for writing to the mailbox.
Signed-off-by: Kishon Vijay Abraham I
Acked-by: Tony Li
From: Felipe Balbi
When CONFIG_OMAP_CONTROL_USB isn't enabled,
there's a compile warning stating that a
particular function isn't a prototype.
Fix it.
Signed-off-by: Felipe Balbi
Signed-off-by: Kishon Vijay Abraham I
---
include/linux/usb/omap_control_usb.h |2 +-
1 file changed, 1 inser
Now that we have a separate driver for the control module,
stop populating the control module device data in other modules
(PHY and OTG) device info.
Signed-off-by: Kishon Vijay Abraham I
Acked-by: Tony Lindgren
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 13 -
1 file changed
On Wed, Feb 06, 2013 at 01:41:06PM +0100, Lars Poeschel wrote:
> Hi Matt!
>
> At first thanks for you efforts on DMA Engine on AM33XX.
>
> On Friday 01 February 2013 at 22:01:17, Matt Porter wrote:
> > This series adds DT DMA Engine Client support to the omap_hsmmc.
> > It leverages the generic D
Hello.
On 06-02-2013 9:58, Kishon Vijay Abraham I wrote:
A seperate driver has been added to handle the usb part of control
module. A device for the above driver is created here, using the register
address information to be used by the driver for powering on the PHY and
for writing to the mailb
Hi Matt!
At first thanks for you efforts on DMA Engine on AM33XX.
On Friday 01 February 2013 at 22:01:17, Matt Porter wrote:
> This series adds DT DMA Engine Client support to the omap_hsmmc.
> It leverages the generic DMA OF helpers in -next and the
> dma_request_slave_channel_compat() wrapper i
Hi Tony,
On Fri, Oct 5, 2012 at 9:57 PM, Tony Lindgren wrote:
> * Tony Lindgren [121004 18:41]:
>> >
>> > > Also on the EHCI port, I've seen issues where unplugging
>> > > the cable hangs kernel with an infinite loop. But that happens
>> > > only occasionally, sorry does not seem to happen righ
On Wed, Feb 06, 2013 at 01:22:31PM +0200, Felipe Balbi wrote:
> there's a little more to it. When running allmodconfig,
> CONFIG_ARCH_MULTIPLATFORM is set but none of the other ARCHes
> (ARCH_OMAP, ARCH_AT91, ARCH_VERSATILE, etc) are set, so it turned out
> that the driver wasn't even included on m
On Sat, Feb 02, 2013 at 03:35:10, Tony Lindgren wrote:
> * Philip Avinash [130123 01:28]:
> > With recent GPMC driver conversion, usage of gpmc_save/restore_context
> > can done from gpmc driver itself. Hence removes the usage from pm34xx.c.
> > Also removes the conditional compilation primitives
Hi Paul,
OMAP4 TRM has a mention in CM_ABE_DSS_SYS_CLKSEL's description:
"Select SYS_CLK divided by 2. Must be used for
SYS_CLK > 26 MHz"
This doesn't seem to be enforced with the current kernel. OMAP4 blaze
has 38.4MHz sys clk, but above mentioned divider is 1.
I made a quick test with omapdss
Hi again,
On Wed, Feb 06, 2013 at 01:03:55PM +0200, Felipe Balbi wrote:
> Hi,
>
> On Wed, Feb 06, 2013 at 10:57:13AM +, Russell King - ARM Linux wrote:
> > On Wed, Feb 06, 2013 at 11:28:11AM +0530, Kishon Vijay Abraham I wrote:
> > > Added has_mailbox to the musb platform data to specify that
Hi Koen,
>
> > > > Since AM335x is DT only, why is there a platform data codepath and why
> > > > is it the first branch it tries? And I guess the next question is
> > > > related to the first: why doesn't it work when used with DT? When I
> > > > copy over the nodes from the evm.dts to my boa
Hi,
On Wed, Feb 06, 2013 at 10:57:13AM +, Russell King - ARM Linux wrote:
> On Wed, Feb 06, 2013 at 11:28:11AM +0530, Kishon Vijay Abraham I wrote:
> > Added has_mailbox to the musb platform data to specify that omap uses
> > an external mailbox (in control module) to communicate with the musb
On Wed, Feb 06, 2013 at 11:28:11AM +0530, Kishon Vijay Abraham I wrote:
> Added has_mailbox to the musb platform data to specify that omap uses
> an external mailbox (in control module) to communicate with the musb
> core during device connect and disconnect.
So, I've been through your five patche
On Wednesday 06 February 2013 04:14 PM, Chen Gang wrote:
'const static ' is not a common order, better to use 'static const' instead.
building:
make EXTRA_CFLAGS=-W ARCH=arm
drivers/gpio/gpio-omap.c:1479:
warning: 'static' is not at beginning of declaration
drivers/gpio/gpio-o
'const static ' is not a common order, better to use 'static const' instead.
building:
make EXTRA_CFLAGS=-W ARCH=arm
drivers/gpio/gpio-omap.c:1479:
warning: 'static' is not at beginning of declaration
drivers/gpio/gpio-omap.c:1485:
warning: 'static' is not at beginning of declara
On Wednesday 06 February 2013 04:08 PM, Chen Gang wrote:
于 2013年02月06日 17:36, Santosh Shilimkar 写道:
On Wednesday 06 February 2013 02:54 PM, Chen Gang wrote:
'const static ' is not a common order, better to use 'const static' instead.
You mean " use static const instead ", right ?
On 02/06/2013 12:21 PM, Rajendra Nayak wrote:
> On Tuesday 05 February 2013 08:22 PM, Roger Quadros wrote:
>> Doesn't look very elegant to me, but I wouldn't mind if there is no better
>> option.
>> Even then, we can't rely on the device name as its index can change based on
>> where it is
>
> W
于 2013年02月06日 17:36, Santosh Shilimkar 写道:
> On Wednesday 06 February 2013 02:54 PM, Chen Gang wrote:
>> >
>> >'const static ' is not a common order, better to use 'const static'
>> > instead.
> You mean " use static const instead ", right ?
>
oh, yes. it is my miswritten.
if necess
On Tuesday 05 February 2013 08:22 PM, Roger Quadros wrote:
Doesn't look very elegant to me, but I wouldn't mind if there is no better
option.
Even then, we can't rely on the device name as its index can change based on
where it is
Well, thats what I said in the first mail, that *if* you are a
Hi,
On 2013-02-05 23:38, Felipe Balbi wrote:
> Hi Tomi,
>
> DSS doesn't build with allyesconfig:
>
> drivers/video/omap2/dss/dss.c: In function 'dss_calc_clock_div':
> drivers/video/omap2/dss/dss.c:572:20: error:
> 'CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK' undeclared (first use in this function)
> dri
On Wednesday 06 February 2013 02:54 PM, Chen Gang wrote:
>
>'const static ' is not a common order, better to use 'const static'
> instead.
You mean " use static const instead ", right ?
> building:
>make EXTRA_CFLAGS=-W ARCH=arm
>
>drivers/gpio/gpio-omap.c:1479:
> warning: 's
'const static ' is not a common order, better to use 'const static' instead.
building:
make EXTRA_CFLAGS=-W ARCH=arm
drivers/gpio/gpio-omap.c:1479:
warning: 'static' is not at beginning of declaration
drivers/gpio/gpio-omap.c:1485:
warning: 'static' is not at beginning of declara
On 02/05/2013 06:11 PM, Mark Rutland wrote:
> [...]
>
+
+- single_ulpi_bypass: Must be present if the controller contains a single
+ ULPI bypass control bit. e.g. OMAP3 silicon <= ES2.1
>>>
>>> Again it would be nicer to have '-' rather than '_' here. It might be worth
>>> prefixin
78 matches
Mail list logo
