On 11/21/2012 6:56 PM, Javier Martinez Canillas wrote:
Since udev-182, udev no longer creates device nodes under /dev
Nit: Looks like this happened from udev-176 onward.
http://permalink.gmane.org/gmane.linux.hotplug.devel/17230
Whoever is taking the patch can _probably_ fix it up while
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 driver to handle access synchronization of shared
resources clock
In some platforms (like am33xx), PWM sub modules (ECAP, EHRPWM, EQEP)
are integrated to PWM subsystem. These PWM submodules has resources
shared and only one register bit-field is provided to control
module/clock enable/disable, makes it difficult to handle common
resources from independent PWMSS
EQEP entry is HWMOD entry is not present in HWMOD entry. Also address
ranges specified for EACP EHRPWM is not correct HWMOD flags of
ADDR_TYPE_RT is added to PWM subsystem register address space. This
patch
1. Corrects register address mapping for ECAP EHRPWM
2. Removes HWMOD flags in PWM
As part of PWM subsystem integration, PWM subsystem are sharing
resources like clock across submodules (ECAP, EQEP EHRPWM). To handle
resource sharing IP integration rework on parent child relation
between PWMSS and ECAP, EQEP EHRPWM child devices to support runtime PM.
Signed-off-by: Philip,
Some platforms (like AM33XX) requires clock gating from control module
explicitly for TBCLK. Enabling of this clock required for the
functioning of the time base sub module in EHRPWM module. Adding support
for handling by enabling the clock on PWM device enable disable on PWM
device disable.
This patch
1. Add support for device-tree binding for EHRWPM driver.
2. Set size of pwm-cells set to 3 to support PWM channel number, PWM
period polarity configuration from device tree.
3. Add enable/disable clock gating in PWM subsystem common config space.
4. When here set .owner member in
Enable pinctrl for pwm-tiehrpwm if pinctrl driver available, else
bail out with warning message.
Signed-off-by: Philip, Avinash avinashphi...@ti.com
---
Changes since v4:
- Changes warning message.
drivers/pwm/pwm-tiehrpwm.c |6 ++
1 files changed, 6 insertions(+), 0
This patch
1. Add support for device-tree binding for ECAP APWM driver.
2. Set size of pwm-cells set to 3 to support PWM channel number, PWM
period polarity configuration from device tree.
3. Add enable/disable clock gating in PWM subsystem common config space.
4. When here set .owner member
Enable pinctrl for pwm-tiecap if pinctrl driver available, else
bail out with warning message.
Signed-off-by: Philip, Avinash avinashphi...@ti.com
---
Changes since v4:
- Changes warning message.
drivers/pwm/pwm-tiecap.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
EHRPWM module requires explicit clock gating of TBCLK from control
module. Hence add TBCLK clock node in clock tree for EHRPWM modules.
Signed-off-by: Philip, Avinash avinashphi...@ti.com
---
Changes since v4:
- Add dev_id field in clcok tree for TBCLK to remove support
for
Add PWMSS device tree nodes in relation with ECAP EHRPWM DT nodes to
AM33XX SoC family. Also populates device tree nodes for ECAP EHRPWM by
adding necessary properties like pwm-cells, base reg set disabled as
status.
Signed-off-by: Philip, Avinash avinashphi...@ti.com
Reviewed-by: Thierry
PWM output from ecap0 uses as backlight source. Also adds low threshold
value to have a uniform divisions in brightness-levels scales.
Signed-off-by: Philip, Avinash avinashphi...@ti.com
Reviewed-by: Thierry Reding thierry.red...@avionic-design.de
---
Changes since v4:
- Replaced usage of
PWM output from ecap2 uses as backlight source. Also adds low threshold
value to have a uniform divisions in brightness-levels scales with
inverse polarity.
Signed-off-by: Philip, Avinash avinashphi...@ti.com
Reviewed-by: Thierry Reding thierry.red...@avionic-design.de
---
Changes since v4:
On 11/27/2012 09:34 AM, Sekhar Nori wrote:
On 11/21/2012 6:56 PM, Javier Martinez Canillas wrote:
Since udev-182, udev no longer creates device nodes under /dev
Nit: Looks like this happened from udev-176 onward.
http://permalink.gmane.org/gmane.linux.hotplug.devel/17230
Whoever is
On 11/26/2012 10:02 PM, Felipe Balbi wrote:
Hi,
On Mon, Nov 26, 2012 at 05:14:45PM +0200, Roger Quadros wrote:
Felipe,
On 11/21/2012 03:39 PM, Felipe Balbi wrote:
Hi,
On Thu, Nov 15, 2012 at 04:34:04PM +0200, Roger Quadros wrote:
All ports have similarly named port clocks so we can
On 11/27/2012 02:21 AM, Javier Martinez Canillas wrote:
Many TI OMAP SoC based boards that uses twl4030 as codec have
been updated to use the unified audio driver (omap-twl4030)
since they have similar audio setup.
So, is good to have it built to add audio support to these boards.
Hello Tomi,
The i2c handling in tfp410 driver, which handles converting parallel RGB
to DVI, was changed in 958f2717b84e88bf833d996997fda8f73276f2af
(OMAPDSS: TFP410: pdata rewrite). The patch changed what value the
driver considers as invalid/undefined. Before the patch, 0 was the
invalid
This driver only supported the Charging indicator LED.
New set of drivers going to provide support for both PWMs and LEDs for twl4030
and twl6030 series of PMICs.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/pwm/Kconfig | 9 ---
drivers/pwm/Makefile | 1 -
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 the last patch
- macro for twl_pwm_chip/twl_pwmled_chip lookup
-
The driver supports the following LED outputs as generic PWM driver:
TWL4030 LEDA and LEDB (PWMA and PWMB)
TWL6030 Charging indicator LED (PWM LED)
On TWL6030 when the PWM requested LED is configured to be controlled by SW.
In this case the user can enable/disable and set the duty period freely.
The driver supports the following PWM outputs:
TWL4030 PWM0 and PWM1
TWL6030 PWM1 and PWM2
On TWL4030 the PWM signals are muxed. Upon requesting the PWM the driver
will select the correct mux so the PWM can be used. When the PWM has been
freed the original configuration is going to be restored.
CC arch/arm/mach-omap2/timer.o
arch/arm/mach-omap2/timer.c: In function 'omap_get_timer_dt':
arch/arm/mach-omap2/timer.c:195:3: error: implicit declaration of function
'prom_add_property'
make[1]: *** [arch/arm/mach-omap2/timer.o] Error 1
make: *** [arch/arm/mach-omap2] Error 2
fix for
CC drivers/net/ethernet/ti/cpts.o
drivers/net/ethernet/ti/cpts.c:30:24: fatal error: plat/clock.h: No such file
or directory
compilation terminated.
make[4]: *** [drivers/net/ethernet/ti/cpts.o] Error 1
make[3]: *** [drivers/net/ethernet/ti] Error 2
make[2]: *** [drivers/net/ethernet]
On 2012-11-26 14:14, Archit Taneja wrote:
So Rajendra and I found the problem.
The function _omap4_update_context_lost() reads the register
RM_DSS_DSS_CONTEXT for all DSS hwmods, and increments the count if we
read a non zero value. The issue is that the DSS's parent platform
device (tied
On 11/27/2012 3:57 PM, Mugunthan V N wrote:
CC drivers/net/ethernet/ti/cpts.o
drivers/net/ethernet/ti/cpts.c:30:24: fatal error: plat/clock.h: No such file
or directory
compilation terminated.
make[4]: *** [drivers/net/ethernet/ti/cpts.o] Error 1
make[3]: *** [drivers/net/ethernet/ti]
On 2012-11-23 17:20, Steve Sakoman wrote:
On Fri, Nov 23, 2012 at 12:46 AM, Tomi Valkeinen tomi.valkei...@ti.com
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
On Tuesday 27 November 2012 04:53 PM, Tomi Valkeinen wrote:
On 2012-11-26 14:14, Archit Taneja wrote:
So Rajendra and I found the problem.
The function _omap4_update_context_lost() reads the register
RM_DSS_DSS_CONTEXT for all DSS hwmods, and increments the count if we
read a non zero value.
On 11/21/2012 03:52 PM, Felipe Balbi wrote:
On Thu, Nov 15, 2012 at 04:34:08PM +0200, Roger Quadros wrote:
OMAPs till date can have upto 3 ports. We need to initialize
s/upto/up to/
the port mode in HOSTCONFIG register for all of them.
why *all* of them ? Isn't it enough to initialize
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
modules are arranged, which module belongs to which power domain, etc.
If it cannot be fixed in the arch code, I guess
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
modules are arranged, which module belongs to which power
On Tue, Nov 27, 2012 at 03:57:14PM +0530, Mugunthan V N wrote:
CC drivers/net/ethernet/ti/cpts.o
drivers/net/ethernet/ti/cpts.c:30:24: fatal error: plat/clock.h: No such file
or directory
compilation terminated.
make[4]: *** [drivers/net/ethernet/ti/cpts.o] Error 1
make[3]: ***
Hi,
On Tue, Nov 27, 2012 at 02:10:50PM +0200, Roger Quadros wrote:
in fact, I would convert this construct into a switch which would look
like:
reg = ~(OMAP4_P1_MODE_MASK i * 2);
switch (port_mode[i]) {
case OMAP4_P1_MODE_TLL:
reg |= OMAP4_P1_MODE_TLL i * 2;
break;
On 11/27/2012 03:28 PM, Felipe Balbi wrote:
Hi,
On Tue, Nov 27, 2012 at 02:10:50PM +0200, Roger Quadros wrote:
in fact, I would convert this construct into a switch which would look
like:
reg = ~(OMAP4_P1_MODE_MASK i * 2);
switch (port_mode[i]) {
case OMAP4_P1_MODE_TLL:
reg |=
Thierry == Thierry Reding thierry.red...@avionic-design.de writes:
Hi,
There's several different situations:
- Platform without pinctrl support
- Platform with pinctrl support but no pinmux specified in dt for device
(E.G. pinmux setup in bootloader)
- Pinmux specified in dt
-
On Tue, 27 Nov 2012, Mugunthan V N wrote:
CC drivers/net/ethernet/ti/cpts.o
drivers/net/ethernet/ti/cpts.c:30:24: fatal error: plat/clock.h: No such file
or directory
compilation terminated.
make[4]: *** [drivers/net/ethernet/ti/cpts.o] Error 1
make[3]: *** [drivers/net/ethernet/ti]
On 11/20/2012 01:22 AM, Kevin Hilman wrote:
Roger Quadros rog...@ti.com writes:
Kevin,
On 11/16/2012 10:08 PM, Kevin Hilman wrote:
Roger Quadros rog...@ti.com writes:
Hi,
This patchset addresses the following
- Avoid addressing clocks one by one by name and use a for loop + bunch
54db6ee ARM: OMAP2+: Introduce local usb.h moved control module bit
definitions from plat/usb.h (which dsps glue was using) to a local
header in mach-omap2. And in parallel,
c68bb4c usb: musb: dsps: control module handling (quirk) added
control module handling capability to dsps glue driver that
On Tue, 27 Nov 2012, Ming Lei wrote:
IMO, all matches mean the devices are inside the ehci-omap bus, so
the direct/simple way is to enable/disable the regulators in the probe() and
remove() of ehci-omap controller driver.
When this discussion started, Felipe argued against such an approach.
On Tue, Nov 27, 2012 at 04:42:47PM +0200, Roger Quadros wrote:
On 11/20/2012 01:22 AM, Kevin Hilman wrote:
Roger Quadros rog...@ti.com writes:
Kevin,
On 11/16/2012 10:08 PM, Kevin Hilman wrote:
Roger Quadros rog...@ti.com writes:
Hi,
This patchset addresses the following
On Tue, 27 Nov 2012, Andy Green wrote:
I don't know if such an approach would be sufficiently general for
future requirements, but it would solve the problem at hand.
We can get a notification about device creation and do things there.
But the cost of that is like the tuple suggestion,
Hi Adam,
On Monday 05 November 2012 16:02:08 Adam Wozniak wrote:
I'm working with a custom board based on an Overo WaterStorm com. The
processor is a DM3730. The kernel is 2.6.32 based.
2.6.32 very probably means you're using the old TI driver. Please don't.
That's buggy and totally
On 11/27/2012 04:24 AM, Mugunthan V N wrote:
CC arch/arm/mach-omap2/timer.o
arch/arm/mach-omap2/timer.c: In function 'omap_get_timer_dt':
arch/arm/mach-omap2/timer.c:195:3: error: implicit declaration of function
'prom_add_property'
make[1]: *** [arch/arm/mach-omap2/timer.o] Error 1
On Tue, Nov 27, 2012 at 11:30:11AM -0500, Alan Stern wrote:
On Tue, 27 Nov 2012, Ming Lei wrote:
IMO, all matches mean the devices are inside the ehci-omap bus, so
the direct/simple way is to enable/disable the regulators in the probe() and
remove() of ehci-omap controller driver.
When
On Wed, Nov 28, 2012 at 12:30 AM, Alan Stern st...@rowland.harvard.edu wrote:
On Tue, 27 Nov 2012, Ming Lei wrote:
IMO, all matches mean the devices are inside the ehci-omap bus, so
the direct/simple way is to enable/disable the regulators in the probe() and
remove() of ehci-omap controller
On 11/28/2012 12:37 AM, the mail apparently from Alan Stern included:
On Tue, 27 Nov 2012, Andy Green wrote:
I don't know if such an approach would be sufficiently general for
future requirements, but it would solve the problem at hand.
We can get a notification about device creation and do
On Mon, Nov 26, 2012 at 11:57 AM, Mike Turquette mturque...@ti.com wrote:
Quoting Russ Dill (2012-11-26 11:20:09)
The helper functions that access the opaque struct clk should
not be marked inline since they are contained in clk.c, but expected
to be used by other compilation units. This
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 CPTS is not selected in Kernel Build.
Fixing by passing the net_device pointer to cpts
On 11/28/2012 01:22 AM, the mail apparently from Ming Lei included:
On Wed, Nov 28, 2012 at 12:30 AM, Alan Stern st...@rowland.harvard.edu wrote:
On Tue, 27 Nov 2012, Ming Lei wrote:
IMO, all matches mean the devices are inside the ehci-omap bus, so
the direct/simple way is to enable/disable
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
this problem.
It's sage advice, but there is zero code provided in my patches that
relies on pathnames in
On Tue, Nov 27, 2012 at 11:23:40PM +0530, Mugunthan V N wrote:
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 CPTS is not
On Tue, Nov 27, 2012 at 3:32 AM, Tomi Valkeinen tomi.valkei...@ti.com 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
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
this problem.
It's sage advice, but there
On Wed, 28 Nov 2012, Andy Green wrote:
OK. So I try to sketch it out iteractively to try to get in sync:
device.h:
enum asset_event {
AE_PROBED,
AE_REMOVED
};
struct device_asset {
char *name; /* name of regulator, clock,
On Wed, Nov 28, 2012 at 1:55 AM, Andy Green andy.gr...@linaro.org wrote:
On 11/28/2012 01:22 AM, the mail apparently from Ming Lei included:
On Wed, Nov 28, 2012 at 12:30 AM, Alan Stern st...@rowland.harvard.edu
wrote:
On Tue, 27 Nov 2012, Ming Lei wrote:
IMO, all matches mean the devices
On Tue, 20 Nov 2012 15:18:43 +0530
AnilKumar Ch anilku...@ti.com wrote:
From: Colin Foe-Parker colin.foepar...@logicpd.com
Add system power off control to rtc driver which is the in-charge
of controlling the BeagleBone system power. The power_off routine
can be hooked up to pm_power_off
On Wed, Nov 28, 2012 at 7:06 AM, Ming Lei tom.leim...@gmail.com wrote:
Also from my intuition, power domain should be involved in the problem,
because these hard-wired and self-powered USB devices should have
its own power domains, and the ehci-omap driver may enable/disable
these power
Fixes for build warnings and errors seen with various kernel
configuration combinations.
Jon Hunter (3):
ARM: OMAP2+: Fix realtime_counter_init warning in timer.c
ARM: OMAP4: Fix build error and warning in timer.c
ARM: AM335x: Fix warning in timer.c
arch/arm/mach-omap2/Kconfig |4
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 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’:
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
On 11/28/2012 04:10 AM, the mail apparently from Alan Stern included:
On Wed, 28 Nov 2012, Andy Green wrote:
OK. So I try to sketch it out iteractively to try to get in sync:
device.h:
enum asset_event {
AE_PROBED,
AE_REMOVED
};
On Tue, Nov 27, 2012 at 19:30:54, Daniel Mack wrote:
Hi Avinash,
Hi Peter,
On 23.11.2012 11:43, Philip, Avinash wrote:
On Wed, Nov 21, 2012 at 15:45:23, Daniel Mack wrote:
On 20.11.2012 16:59, Peter Korsgaard wrote:
Daniel == Daniel Mack zon...@gmail.com writes:
Peter,
In patch
On Wednesday 28 November 2012 07:45 AM, Jon Hunter wrote:
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
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 is not selected then
the following compiler warning
On Wednesday 28 November 2012 07: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
On 11/28/12 04:15, Jon Hunter wrote:
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
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 is not set
# CONFIG_ARCH_OMAP3 is not set
# CONFIG_ARCH_OMAP4 is not set
# CONFIG_SOC_OMAP5 is not set
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 is not set
# CONFIG_ARCH_OMAP3 is not set
#
69 matches
Mail list logo
