Hi,
On Thursday 01 November 2012 04:56 AM, Tony Lindgren wrote:
* Lokesh Vutla lokeshvu...@ti.com [121029 00:03]:
Is the above discussion fine for you ?
Will you pick this patch or
you want any more modifications ?
Let's see what Arnd says.
Gentle ping on this...
Thanks
Lokesh
Regards,
Hi Grant, Lars, Thierry,
On 11/26/2012 04:46 PM, Grant Likely wrote:
You're effectively asking the pwm layer to behave like a gpio (which
is completely reasonable). Having a completely separate translation node
really doesn't make sense because it is entirely a software construct.
In fact,
On 11/28/2012 7:45 AM, Jon Hunter wrote:
When compiling the kernel with configuration options ...
# CONFIG_ARCH_OMAP2 is not set
# CONFIG_ARCH_OMAP3 is not set
# CONFIG_ARCH_OMAP4 is not set
# CONFIG_SOC_OMAP5 is not set
CONFIG_SOC_AM33XX=y
... the following build warning is
On Mon, Nov 26, 2012 at 03:25:11PM +0530, Shubhrajyoti D wrote:
The OMAP_I2C_FLAG_RESET_REGS_POSTIDLE is not used anymore
in the i2c driver. Remove the flag.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
Trivial enough to still go into 3.8. Applied to -next, thanks!
--
Pengutronix e.K.
On Tuesday 27 November 2012 06:01 PM, Tero Kristo wrote:
On Tue, 2012-11-27 at 14:21 +0200, Tomi Valkeinen wrote:
On 2012-11-27 13:56, Archit Taneja wrote:
On Tuesday 27 November 2012 04:53 PM, Tomi Valkeinen wrote:
Hmm, well this feels like a hack. DISPC driver doesn't know how the DSS
Hi everyone,
this patch series aims at cleaning up of dss_features.c by moving features to
respective submodule drivers.
The 1st patch
* moved struct omap_dss_features members burst_size_unit and buffer_size_unit
to dispc_features
The 2nd patch
* added definition of struct register_field
*
The burst_size and buffer_size being local data to DISPC are moved to
dispc_features and so removed from struct omap_dss_features. The functions
referring to burst and buffer size are also removed from dss_features.c as they
are now accessed locally in dispc.c.
Signed-off-by: Chandrabhanu
The register fields in dss_reg_fields specific to DISPC are moved from struct
omap_dss_features to corresponding dispc_reg_fields, initialized in struct
dispc_features, thereby enabling local access.
Signed-off-by: Chandrabhanu Mahapatra cmahapa...@ti.com
---
drivers/video/omap2/dss/dispc.c
The DISPC specific dss_param_range are moved from struct omap_dss_features to
corresponding DSS version specific dispc_param_range struct, initialized in
dispc_features thereby enabling local access. The mgr_width_max and
mgr_height_max, members of dispc_features, are also moved to
The DSI specific dss_reg_fields are moved to corresponding dsi_reg_fields
initialized in dsi_feats. The dsi_feats structure is initialized as per
corresponding DSS version in dsi_init_features().
Signed-off-by: Chandrabhanu Mahapatra cmahapa...@ti.com
---
drivers/video/omap2/dss/dsi.c |
The DSI specific dss_param_range are moved from struct omap_dss_features to
corresponding struct dsi_param_range, which is initialized in struct dsi_feats
thereby enabling local access.
Signed-off-by: Chandrabhanu Mahapatra cmahapa...@ti.com
---
drivers/video/omap2/dss/dsi.c | 70
The members fld_dispc_clk_switch and dss_fck_max are added to struct
dss_features and are initialized in corresponding dss_feats structure as per DSS
version. The reg_fields and num_reg_fields entries are removed from struct
omap_dss_features as they are no longer referenced.
Signed-off-by:
The FEAT_PARAM_DSS_FCK is added and initialized in corresponding DSS Version
specific struct dsi_param_range. As, the struct dss_param_range is no longer
used all its references are thereby removed from omap_dss_features.
Signed-off-by: Chandrabhanu Mahapatra cmahapa...@ti.com
---
On Tue, Nov 27, 2012 at 03:42:39PM -0800, Andrew Morton wrote:
+ /* Do not allow to execute any other task */
+ spin_lock_irqsave(lock, flags);
+ while (1);
I suspect this doesn't do what you want it to do.
Firstly, please provide adequate code comments here so that code
readers
On 11/27/2012 09:22 PM, Andy Green wrote:
On 11/28/2012 02:09 AM, the mail apparently from Alan Stern included:
On Wed, 28 Nov 2012, Andy Green wrote:
Greg's advice was simply not to rely on pathnames in sysfs because they
aren't fixed in stone. That leaves plenty of other ways to approach
When enabling a hwmod, omap_hwmod refers to the register mentioned in the
hwmod struct's member 'prcm.omap4.context_offs' to see whether context was
lost or not. It increments the context lost count for the hwmod and then clears
the register.
All the DSS hwmods have the same
On 11/28/2012 07:13 PM, the mail apparently from Roger Quadros included:
On 11/27/2012 09:22 PM, Andy Green wrote:
On 11/28/2012 02:09 AM, the mail apparently from Alan Stern included:
On Wed, 28 Nov 2012, Andy Green wrote:
Greg's advice was simply not to rely on pathnames in sysfs because
On Wednesday 28 November 2012 05:01 PM, Archit Taneja wrote:
When enabling a hwmod, omap_hwmod refers to the register mentioned in the
hwmod struct's member 'prcm.omap4.context_offs' to see whether context was
lost or not. It increments the context lost count for the hwmod and then clears
the
On 11/28/2012 01:47 PM, Andy Green wrote:
On 11/28/2012 07:13 PM, the mail apparently from Roger Quadros included:
On 11/27/2012 09:22 PM, Andy Green wrote:
On 11/28/2012 02:09 AM, the mail apparently from Alan Stern included:
On Wed, 28 Nov 2012, Andy Green wrote:
Greg's advice was simply
The following series implements the device_asset addition to
struct device that has been discussed on the usb and omap lists
with Alan Stern and GKH. Several of the ideas here are from Alan
Stern.
First we add the new struct to linux/device.h and cause it to be
used just before device probe with
This patch adds support for a new struct device member assets
which may point to an array of struct assets.
The array is terminated by one with a NULL pre_probe callback.
These assets consist of named (in .name) or anonymous object
pointers (.data) operated on by specified callbacks. A void *
This adds default device_asset handlers for struct regulator. If you
want an associated regulator asset of a device to be powered before
probe, and depowered after removal, these callbacks will take care of
everything including get and put.
By defining them here in regulator core, code
This adds default device_asset handlers for struct clk. If you
want an associated clk asset of a device to be optionally set, and
enabled before probe, and disabled after removal, these callbacks
will take care of everything including get and put.
By defining them here in regulator core, code
This series migrates it to be assets of the logical ehci-omap.0
device object.
Signed-off-by: Andy Green andy.gr...@linaro.org
---
arch/arm/mach-omap2/usb-host.c|1 -
arch/arm/plat-omap/include/plat/usb.h |7 --
drivers/usb/host/ehci-omap.c | 37
This adds regulators which are controlled by the OMAP4 PandaBoard (ES)'s
EHCI logical root hub existing.
The regulators are made a device_asset of the EHCI logical root hub by
passing them through the hsusb - mfd path. Although the ehci-related
platform_device is created at boot time, it is not
This patch makes the ULPI PHY clock control also be a device_asset
of the ehci-omap.0 device, along with the [HUB + ETH] smsc95xx chip
power regulator.
Without clock control, the PHY clock is running all the time from
boot whether USB is in use or not, and during suspend distorting
power
omap2plus seems to have rotted a bit, this is the delta that appears
if we enable modular build for ehci-hcd and smsc95xx.
Signed-off-by: Andy Green andy.gr...@linaro.org
---
arch/arm/configs/omap2plus_defconfig | 42 ++
1 file changed, 17 insertions(+), 25
Tony, Russell,
On 20-11-2012 13:57, Tony Lindgren wrote:
* Russell King - ARM Linux li...@arm.linux.org.uk [121117 01:35]:
On Wed, Nov 14, 2012 at 09:26:43AM +, Russell King - ARM Linux wrote:
OMAP* allnoconfig fails:
arch/arm/mach-omap2/built-in.o: In function
On Tue, Nov 27, 2012 at 11:09:56AM +0100, Peter Ujfalusi wrote:
Hello,
Changes since v3:
- pwm-twl-led driver's comment fix patch squashed to the original patch
- Documentation for the DT bindings of the PWM drivers
Comments from Thierry Reding addressed:
- pwm-twl6030 has been removed in
On Tue, Nov 27, 2012 at 02:18:05PM +0530, Philip, Avinash wrote:
In AM33xx PWM sub modules like ECAP, EHRPWM EQEP are integrated to
PWM subsystem. All these submodules shares the resources (clock) has
a clock gating register in PWM Subsystem. This patch series creates a
parent PWM Subsystem
Pass an optional device_node pointer in the platform data, which in turn
will be put into a mtd_part_parser_data. This way, code that sets up the
platform devices can pass along the node from DT so that the partitions
can be parsed.
For non-DT boards, this change has no effect.
Signed-off-by:
gpmc_nand_init() will be called from another driver's probe() function,
so the easiest way to prevent section mismatches is to drop the
annotation here.
Signed-off-by: Daniel Mack zon...@gmail.com
---
arch/arm/mach-omap2/gpmc-nand.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Signed-off-by: Daniel Mack zon...@gmail.com
---
arch/arm/mach-omap2/gpmc-nand.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index f9f23a2..c8a72ba 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++
This is a series of patches to support GPMC peripherals on OMAP boards.
Depends on Linus' master +
omap-next (branch omap-for-v3.8/cleanup-headers-gpmc)
The only supported peripheral for now is NAND, but other types would be
easy to add.
Version 2 addresses details pointed out by Jon Hunter,
This patch adds basic DT bindings for OMAP GPMC.
The actual peripherals are instantiated from child nodes within the GPMC
node, and the only type of device that is currently supported is NAND.
Code was added to parse the generic GPMC timing parameters and some
documentation with examples on how
Hi,
This patchset addresses the following
- Avoid addressing clocks one by one by name and use a for loop + bunch
of cleanups.
- Get number of channels/ports dynamically either from revision register
or from platform data. Avoids getting clocks that are not present.
- Add OMAP5 and HSIC mode
Just a pointer to the platform data should suffice.
Signed-off-by: Roger Quadros rog...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
---
drivers/mfd/omap-usb-tll.c |9 -
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/mfd/omap-usb-tll.c
Fix channel count detecion for REV2. Also, don't give up
if we don't recognize the IP Revision. We assume the default
number of channels (i.e. 3) for unrecognized IPs.
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/mfd/omap-usb-tll.c | 20 +++-
1 files changed, 11
Use devm_ variants of kzalloc() and ioremap(). Simplify the error path.
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/mfd/omap-usb-tll.c | 37 +++--
1 files changed, 11 insertions(+), 26 deletions(-)
diff --git a/drivers/mfd/omap-usb-tll.c
This is a handy macro to check if the port requires the
USB TLL module or not. Use it to Enable the TLL module and manage
the clocks.
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/mfd/omap-usb-tll.c | 20
1 files changed, 12 insertions(+), 8 deletions(-)
diff
No need to check for missing platform data in runtime_suspend/resume
as it makes more sense to do it in the probe function.
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/mfd/omap-usb-tll.c | 15 +--
1 files changed, 5 insertions(+), 10 deletions(-)
diff --git
omap_enable/disable_tll() can fail if TLL device is not
initialized. It could be due to multiple reasons and not only
due to missing platform data.
Also make local variables static and use 'struct device *'
instead of 'struct platform_device *' for global reference.
Signed-off-by: Roger Quadros
Every channel has a functional clock that is similarly named.
It makes sense to use a for loop to manage these clocks as OMAPs
can come with up to 3 channels.
Dynamically allocate and get channel clocks depending on the
number of clocks avaiable on the platform.
Signed-off-by: Roger Quadros
The TLL module on OMAP5 has 3 channels.
HSIC mode requires the TLL channel to be in Transparent UTMI mode.
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/mfd/omap-usb-tll.c | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/drivers/mfd/omap-usb-tll.c
Use devm_ variants of kzalloc and ioremap. Also clean up error path.
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/mfd/omap-usb-host.c | 36 +---
1 files changed, 9 insertions(+), 27 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c
Both OMAP4 and 5 exhibit the same revision ID in the REVISION register
but they have different number of ports i.e. 2 and 3 respectively.
So we can't rely on REVISION register for number of ports on OMAP5
and depend on platform data (or device tree) instead.
Signed-off-by: Roger Quadros
All ports have similarly named port clocks so we can
bunch them into a port data structure and use for loop
to enable/disable the clocks.
Dynamically allocate and get clocks based on number of ports
available on the platform
Signed-off-by: Roger Quadros rog...@ti.com
---
Enable the optional HSIC clocks (60MHz and 480MHz) for the ports
that are configured in HSIC mode.
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/mfd/omap-usb-host.c | 77 +++---
1 files changed, 71 insertions(+), 6 deletions(-)
diff --git
There is no such clock as utmi_p1_gfclk. It is only a clock selector
bit to select th the parent of usb_host_hs_utmi_p1_clk.
So we get rid of utmi_p1_gfclk and utmi_p2_gfclk by merging them into
usb_host_hs_utmi_p1_clk and usb_host_hs_utmi_p2_clk respectively.
CC: Benoit Cousson b-cous...@ti.com
Instead of using cpu_is_omap..() macros in the device driver we
rely on information provided in the platform data.
The only information we need is whether the USB Host module has
a single ULPI bypass control bit for all ports or individual bypass
control bits for each port. OMAP3 REV2.1 and
The driver does not have an interrupt handler and
we don't really need a spinlock, so get rid of it.
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/mfd/omap-usb-host.c | 16
1 files changed, 0 insertions(+), 16 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c
We split initializing revision 1 and revision 2 into different
functions. Initialization is now done dynamically so that only
the number of ports available on the system are initialized.
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/mfd/omap-usb-host.c | 122
We don't need multiple aliases for the OMAP USB host clocks so remove them.
Also use NULL dev_id for 'usb_tll_hs_usb_ch0_clk' and 'usb_tll_hs_usb_ch1_clk'
Signed-off-by: Roger Quadros rog...@ti.com
CC: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/clock3xxx_data.c | 11 ---
1
clk_set_parent is expected to fail on OMAP3 platforms. We don't
consider that as fatal so don't spam console.
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/mfd/omap-usb-host.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c
This driver does not request any gpios so don't free them.
Fixes L3 bus error on multiple modprobe/rmmod of ehci_hcd
with ehci-omap in use.
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/usb/host/ehci-omap.c |8
1 files changed, 0 insertions(+), 8 deletions(-)
diff --git
The revision register should tell us how many ports are present.
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/mfd/omap-usb-host.c | 32 +++-
1 files changed, 27 insertions(+), 5 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c
We can just hold the pointer to the platform data instead
of creating a copy of it.
Also get rid of the unnecessary missing platform data checks
in runtime_suspend/resume. We are already checking for missing
platform data in probe.
Signed-off-by: Roger Quadros rog...@ti.com
Acked-by: Felipe
Get rid of the unnecessary spin_lock_irqsave/restore() as there is
no interrupt handler for this driver. Instead we serialize access
to tll_dev using a global spinlock.
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/mfd/omap-usb-tll.c | 53 ++-
1
On 11/28/2012 02:59 PM, Andy Green wrote:
This adds regulators which are controlled by the OMAP4 PandaBoard (ES)'s
EHCI logical root hub existing.
The regulators are made a device_asset of the EHCI logical root hub by
passing them through the hsusb - mfd path. Although the ehci-related
Hi Tomi,
On Monday 12 November 2012 15:33:38 Tomi Valkeinen wrote:
Hi,
This patch removes use of cpu_is_* funcs from omap_vout, and uses omapdss's
version instead. The other patch removes an unneeded plat/dma.h include.
These are based on current omapdss master branch, which has the
On Wed, Nov 28, 2012 at 10:04:33AM -0400, Eduardo Valentin wrote:
Tony, Russell,
On 20-11-2012 13:57, Tony Lindgren wrote:
* Russell King - ARM Linux li...@arm.linux.org.uk [121117 01:35]:
On Wed, Nov 14, 2012 at 09:26:43AM +, Russell King - ARM Linux wrote:
And the randconfig found:
On Tue, Nov 20, 2012 at 05:00:19PM -0600, Jon Hunter wrote:
On 11/20/2012 11:57 AM, Tony Lindgren wrote:
* Russell King - ARM Linux li...@arm.linux.org.uk [121117 01:35]:
On Wed, Nov 14, 2012 at 09:26:43AM +, Russell King - ARM Linux wrote:
OMAP* allnoconfig fails:
On 11/28/2012 12:09 AM, Santosh Shilimkar wrote:
On Wednesday 28 November 2012 07:45 AM, Jon Hunter wrote:
In commit fa6d79d (ARM: OMAP: Add initialisation for the real-time
counter), the function realtime_counter_init() was added. However, if
the kernel configuration option CONFIG_SOC_OMAP5
On Wednesday 28 November 2012 09:17 PM, Jon Hunter wrote:
On 11/28/2012 12:09 AM, Santosh Shilimkar wrote:
On Wednesday 28 November 2012 07:45 AM, Jon Hunter wrote:
In commit fa6d79d (ARM: OMAP: Add initialisation for the real-time
counter), the function realtime_counter_init() was added.
On 11/28/2012 09:55 AM, Santosh Shilimkar wrote:
On Wednesday 28 November 2012 09:17 PM, Jon Hunter wrote:
On 11/28/2012 12:09 AM, Santosh Shilimkar wrote:
On Wednesday 28 November 2012 07:45 AM, Jon Hunter wrote:
In commit fa6d79d (ARM: OMAP: Add initialisation for the real-time
counter),
On Wednesday 28 November 2012 09:17 PM, Jon Hunter wrote:
On 11/28/2012 12:09 AM, Santosh Shilimkar wrote:
On Wednesday 28 November 2012 07:45 AM, Jon Hunter wrote:
In commit fa6d79d (ARM: OMAP: Add initialisation for the real-time
counter), the function realtime_counter_init() was added.
On 11/28/2012 01:20 AM, Santosh Shilimkar wrote:
On Wednesday 28 November 2012 12:16 PM, Igor Grinberg wrote:
On 11/28/12 08:28, Santosh Shilimkar wrote:
On Wednesday 28 November 2012 07:45 AM, Jon Hunter wrote:
When compiling the kernel with configuration options ...
# CONFIG_ARCH_OMAP2
On Wednesday 28 November 2012 09:31 PM, Jon Hunter wrote:
On 11/28/2012 09:55 AM, Santosh Shilimkar wrote:
On Wednesday 28 November 2012 09:17 PM, Jon Hunter wrote:
On 11/28/2012 12:09 AM, Santosh Shilimkar wrote:
On Wednesday 28 November 2012 07:45 AM, Jon Hunter wrote:
In commit fa6d79d
* Roger Quadros rog...@ti.com [121128 06:52]:
Both OMAP4 and 5 exhibit the same revision ID in the REVISION register
but they have different number of ports i.e. 2 and 3 respectively.
So we can't rely on REVISION register for number of ports on OMAP5
and depend on platform data (or device
* Roger Quadros rog...@ti.com [121128 06:51]:
Instead of using cpu_is_omap..() macros in the device driver we
rely on information provided in the platform data.
The only information we need is whether the USB Host module has
a single ULPI bypass control bit for all ports or individual bypass
* Daniel Mack zon...@gmail.com [121128 06:40]:
Please add a patch description here.
Regards,
Tony
Signed-off-by: Daniel Mack zon...@gmail.com
---
arch/arm/mach-omap2/gpmc-nand.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c
On Wed, 28 Nov 2012, Roger Quadros wrote:
board file:
static struct regulator myreg = {
.name = mydevice-regulator,
};
static struct device_asset mydevice_assets[] = {
{
.name = mydevice-regulator,
.handler =
* Daniel Mack zon...@gmail.com [121128 06:40]:
This patch adds basic DT bindings for OMAP GPMC.
The actual peripherals are instantiated from child nodes within the GPMC
node, and the only type of device that is currently supported is NAND.
Code was added to parse the generic GPMC timing
On 11/28/2012 06:36 PM, Tony Lindgren wrote:
* Roger Quadros rog...@ti.com [121128 06:51]:
Instead of using cpu_is_omap..() macros in the device driver we
rely on information provided in the platform data.
The only information we need is whether the USB Host module has
a single ULPI bypass
gpmc_nand_init() will be called from another driver's probe() function,
so the easiest way to prevent section mismatches is to drop the
annotation here.
Signed-off-by: Daniel Mack zon...@gmail.com
---
arch/arm/mach-omap2/gpmc-nand.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Pass an optional device_node pointer in the platform data, which in turn
will be put into a mtd_part_parser_data. This way, code that sets up the
platform devices can pass along the node from DT so that the partitions
can be parsed.
For non-DT boards, this change has no effect.
Signed-off-by:
This patch adds basic DT bindings for OMAP GPMC.
The actual peripherals are instantiated from child nodes within the GPMC
node, and the only type of device that is currently supported is NAND.
Code was added to parse the generic GPMC timing parameters and some
documentation with examples on how
The am33xx is capable of handling bch error correction modes, so
enable that feature in the driver.
Signed-off-by: Daniel Mack zon...@gmail.com
---
arch/arm/mach-omap2/gpmc-nand.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c
On 28.11.2012 17:46, Tony Lindgren wrote:
* Daniel Mack zon...@gmail.com [121128 06:40]:
This patch adds basic DT bindings for OMAP GPMC.
The actual peripherals are instantiated from child nodes within the GPMC
node, and the only type of device that is currently supported is NAND.
Code was
[Resending +devicetree-discuss, +Rob, +Grant]
This is a series of patches to support GPMC peripherals on OMAP boards.
Depends on Linus' master +
omap-next (branch omap-for-v3.8/cleanup-headers-gpmc)
The only supported peripheral for now is NAND, but other types would be
easy to add.
Version 2
On Fri, 2012-11-16 at 09:45 -0600, Jon Hunter wrote:
Thanks, Vinod. Can you make sure you also pick up the two fixes [1][2]
I sent out?
Cheers
Jon
[1] http://marc.info/?l=linux-omapm=134859981920598w=2
[2] http://marc.info/?l=linux-omapm=134998461526129w=2
Applied both and merged
On Wed, Nov 28, 2012 at 09:54:57AM +0100, Peter Ujfalusi wrote:
Hi Grant, Lars, Thierry,
On 11/26/2012 04:46 PM, Grant Likely wrote:
You're effectively asking the pwm layer to behave like a gpio (which
is completely reasonable). Having a completely separate translation node
really
On 11/28/2012 09:54 AM, Peter Ujfalusi wrote:
Hi Grant, Lars, Thierry,
On 11/26/2012 04:46 PM, Grant Likely wrote:
You're effectively asking the pwm layer to behave like a gpio (which
is completely reasonable). Having a completely separate translation node
really doesn't make sense because
On 11/28/2012 09:18 AM, Russell King - ARM Linux wrote:
On Tue, Nov 20, 2012 at 05:00:19PM -0600, Jon Hunter wrote:
On 11/20/2012 11:57 AM, Tony Lindgren wrote:
* Russell King - ARM Linux li...@arm.linux.org.uk [121117 01:35]:
On Wed, Nov 14, 2012 at 09:26:43AM +, Russell King - ARM
Fixes for build warnings and errors seen with various kernel
configuration combinations. Based upon Tony Lindgren's OMAP
master branch.
V2 changes:
- Update fix for realtime counter per feedback from Santosh
- Update fix when building for only AM335x with Igor's suggestion to
use __maybe_unused
From: Vaibhav Hiremath hvaib...@ti.com
Sparse generates the following warnings when compiling mach-omap2/timer.c.
CHECK arch/arm/mach-omap2/timer.c
arch/arm/mach-omap2/timer.c:193:13: warning: symbol 'omap_dmtimer_init'
was not declared. Should it be static?
In commit fa6d79d (ARM: OMAP: Add initialisation for the real-time
counter), the function realtime_counter_init() was added. However, if
the kernel configuration option CONFIG_SOC_OMAP5 is not selected then
the following compiler warning is observed.
CC arch/arm/mach-omap2/timer.o
When compiling the kernel with configuration options ...
# CONFIG_ARCH_OMAP2 is not set
# CONFIG_ARCH_OMAP3 is not set
# CONFIG_ARCH_OMAP4 is not set
# CONFIG_SOC_OMAP5 is not set
CONFIG_SOC_AM33XX=y
... the following build warning is seen.
CC arch/arm/mach-omap2/timer.o
When compiling the kernel with configuration option CONFIG_ARCH_OMAP4
enabled and CONFIG_LOCAL_TIMERS disabled, the following build error and
warning is seen.
CC arch/arm/mach-omap2/timer.o
arch/arm/mach-omap2/timer.c: In function ‘omap4_local_timer_init’:
From: Mugunthan V N mugunthan...@ti.com
Date: Tue, 27 Nov 2012 23:23:40 +0530
CC drivers/net/ethernet/ti/cpsw.o
drivers/net/ethernet/ti/cpsw.c: In function 'cpsw_ndo_ioctl':
drivers/net/ethernet/ti/cpsw.c:881:20: warning: unused variable 'priv'
The build warning is generated when
IGEP technology devices are TI OMAP3 SoC based industrial embedded
and computer-on-module boards. This patchset adds initial device
tree support for these devices.
The device trees allows to boot from an MMC and are working all the
components that already have device tree support on OMAP3 SoCs:
ISEE IGEPv2 is an TI OMAP3 SoC based embedded board.
This patch adds an initial device tree support to boot
an IGEPv2 from the MMC/SD.
Currently is working everything that is supported by DT
on OMAP3 SoCs (MMC/SD, GPIO LEDs, EEPROM, TWL4030 audio).
Signed-off-by: Javier Martinez Canillas
ISEE IGEP COM Module is an TI OMAP3 SoC computer on module.
This patch adds an initial device tree support to boot an
IGEP COM Module from the MMC/SD.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
arch/arm/boot/dts/Makefile |1 +
Add a generic .dtsi device tree source file for the
common characteristics across IGEP Technology devices.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
arch/arm/boot/dts/omap3-igep.dtsi | 93 +
1 files changed, 93
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
MAINTAINERS | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 9386a63..17f2ad2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5236,7 +5236,7 @@ S:Maintained
F:
On Thu, Nov 29, 2012 at 12:43 AM, Alan Stern st...@rowland.harvard.edu wrote:
On Wed, 28 Nov 2012, Roger Quadros wrote:
board file:
static struct regulator myreg = {
.name = mydevice-regulator,
};
static struct device_asset mydevice_assets[] = {
{
On Thursday 29 November 2012 03:34 AM, Jon Hunter wrote:
When compiling the kernel with configuration options ...
# CONFIG_ARCH_OMAP2 is not set
# CONFIG_ARCH_OMAP3 is not set
# CONFIG_ARCH_OMAP4 is not set
# CONFIG_SOC_OMAP5 is not set
CONFIG_SOC_AM33XX=y
... the following build
On Thursday 29 November 2012 03:35 AM, Jon Hunter wrote:
From: Vaibhav Hiremath hvaib...@ti.com
Sparse generates the following warnings when compiling mach-omap2/timer.c.
CHECK arch/arm/mach-omap2/timer.c
arch/arm/mach-omap2/timer.c:193:13: warning: symbol 'omap_dmtimer_init'
was
On Wed, Nov 28, 2012 at 22:28:55, Daniel Mack wrote:
[Resending +devicetree-discuss, +Rob, +Grant]
This is a series of patches to support GPMC peripherals on OMAP boards.
Depends on Linus' master +
omap-next (branch omap-for-v3.8/cleanup-headers-gpmc)
Can you resend this series on top
On 11/28/2012 11:06 PM, the mail apparently from Roger Quadros included:
Hi Roger -
On 11/28/2012 02:59 PM, Andy Green wrote:
This adds regulators which are controlled by the OMAP4 PandaBoard (ES)'s
EHCI logical root hub existing.
The regulators are made a device_asset of the EHCI logical
1 - 100 of 104 matches
Mail list logo
