Hi Daniel,
On 12/18/11 21:13, Daniel Mack wrote:
Signed-off-by: Daniel Mack zon...@gmail.com
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/vp.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/vp.c b/arch/arm/mach-omap2/vp.c
On Fri, Dec 16, 2011 at 01:05:08AM +0200, Felipe Contreras wrote:
Properly call pm_runtime_put() afer pm_runttime_get() on errors.
Untested.
sorry, but I'm not applying untested patches. I need someone to give a
Tested-by.
--
balbi
signature.asc
Description: Digital signature
Hi Ricardo,
On Fri, 2011-12-16 at 01:03 -0600, Ricardo Neri wrote:
The function hdmi_audio_trigger is a callback used by ASoC to stop/start
HDMI audio. Also, it does not perform IP-specific configuration directly.
Hence, it should be placed in the general portion of the HDMI driver,
along
Hi Tomi,
On Tue, Dec 13, 2011 at 2:18 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Tue, 2011-12-13 at 11:26 +0530, mythr...@ti.com wrote:
From: Mythri P K mythr...@ti.com
Disables the internal pull resistor for SDA and SCL which are enabled by
default, as there are expernal pull up's
Hi Tero,
On Fri, Dec 09, 2011 at 05:29:48PM +0200, Tero Kristo wrote:
This is needed for SMPS regulators, which use the OMAP voltage
processor for voltage get/set functions instead of the normal I2C
channel. For this purpose, regulator_init_data-driver_data contents
are expanded, it is now a
Hi everyone,
the following patch set directs to improve the scaling performance of DISPC
module which consists of two pacthes.
The first patch is based on code of Lajos Molnar la...@ti.com from Android
Kernel, which updates the code with new set of coefficients to improve the
scaling performance.
The FIR coefficients present in kernel are being updated to new coefficients
consisting of 24 coefficient tables, with 12 each for 3 tap and 5 tap scenario,
which are chosen on the basis of DISPC up/downsampling filters M value. M is
the inverse of low pass cut off frequency of the sampling
Clock requirements for scaling in OMAP2, OMAP3 and OMAP4 are different. In
OMAP2 and OMAP3 the required clock rate is a function of pixel clock, vertical
downscale ratio and horizontal downscale ratio whereas in OMAP4 it is a
function of pixel clock and horizontal downscale ratio only. Selection
On Mon, 2011-12-19 at 13:56 +0530, K, Mythri P wrote:
+ /*
+ * CONTROL_I2C_1: HDMI_DDC_SDA_PULLUPRESX (bit 28) and
+ * HDMI_DDC_SCL_PULLUPRESX (bit 24) are set to disable
+ * internal pull up resistor - This is a change needed in
+ * OMAP4460SDP/Blaze and OMAP4430
On 19 December 2011 08:33, Samuel Ortiz sa...@linux.intel.com wrote:
Hi Tero,
On Fri, Dec 09, 2011 at 05:29:48PM +0200, Tero Kristo wrote:
This is needed for SMPS regulators, which use the OMAP voltage
processor for voltage get/set functions instead of the normal I2C
channel. For this
Change log:
==
Changes from V2:
- Split the patch to make it more readable.
- Make omap3_cpuinfo void funtion, since cpu_rev is global now.
Changes from V1:
- Incorporated suggessions from Tony to split the function
Vaibhav Hiremath (2):
arm:omap: Make cpu_rev
As part of omap revision code cleanup, make cpu_rev variable static
global to the file (id.c).
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
CC: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/id.c | 146 +++---
1 files changed, 72 insertions(+),
This patch doesn't change functionality or behavior of the code
execution; it barely cleans up the code and splits into SoC
specific implementation for Rev ID and feature detection.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
CC: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/id.c
such utilities are currently duplicated on all UDC
drivers basically with the same structure. Let's group
all implementations into one generic implementation
and get rid of that duplication.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/usb/gadget/udc-core.c | 53
Hi all,
here's a more complete map/unmap rework patchset.
Please give it a try and reply with your Tested-by ASAP.
These patches were written on top of the Scatter/Gather
support patchset, so if you want to try it out, you might
need those first, as an alternative, you can drop patch 2
of this
those routines have everything we need to map/unmap
USB requests and it's better to use them.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/usb/dwc3/gadget.c | 80 +++--
1 files changed, 12 insertions(+), 68 deletions(-)
diff --git
those routines have everything we need to map/unmap
USB requests and it's better to use them.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/usb/gadget/amd5536udc.c | 32 +---
1 files changed, 5 insertions(+), 27 deletions(-)
diff --git
those routines have everything we need to map/unmap
USB requests and it's better to use them.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/usb/gadget/r8a66597-udc.c | 10 ++
1 files changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/gadget/r8a66597-udc.c
those routines have everything we need to map/unmap
USB requests and it's better to use them.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/usb/gadget/net2280.c | 19 +--
1 files changed, 9 insertions(+), 10 deletions(-)
diff --git a/drivers/usb/gadget/net2280.c
those routines have everything we need to map/unmap
USB requests and it's better to use them.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/usb/gadget/goku_udc.c | 17 +++--
1 files changed, 7 insertions(+), 10 deletions(-)
diff --git a/drivers/usb/gadget/goku_udc.c
those routines have everything we need to map/unmap
USB requests and it's better to use them.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/usb/gadget/net2272.c | 18 --
1 files changed, 8 insertions(+), 10 deletions(-)
diff --git a/drivers/usb/gadget/net2272.c
those routines have everything we need to map/unmap
USB requests and it's better to use them.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/usb/renesas_usbhs/mod_gadget.c | 60
1 files changed, 7 insertions(+), 53 deletions(-)
diff --git
those routines have everything we need to map/unmap
USB requests and it's better to use them.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/usb/gadget/langwell_udc.c | 45 +---
1 files changed, 7 insertions(+), 38 deletions(-)
diff --git
Hi Benoit,
On Fri, Dec 09, 2011 at 03:02:34PM +0100, Benoit Cousson wrote:
Add initial device-tree support for twl familly chips.
The current version is missing the regulator entries due
to the lack of DT regulator bindings for the moment.
Only the simple sub-modules that do not depend on
From: Mythri P K mythr...@ti.com
Move duplicate HDMI mux_init code from omap4 and panda board file
to display file.
Signed-off-by: Mythri P K mythr...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c| 16 +---
arch/arm/mach-omap2/board-omap4panda.c | 17 +
From: Mythri P K mythr...@ti.com
Disables the internal pull resistor for SDA and SCL which are enabled by
default, as there are external pull up's in 4460 and 4430 ES2.3
SDP, Blaze and Panda Boards, It is done to avoid the EDID read failure.
Signed-off-by: Ricardo Salveti de Araujo
On Mon, 2011-12-19 at 18:06 +0530, mythr...@ti.com wrote:
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index 0cb0469..799470f 100644
--- a/include/video/omapdss.h
+++ b/include/video/omapdss.h
@@ -200,6 +200,10 @@ enum omap_dss_clk_source {
Hello.
On 19-12-2011 14:30, Felipe Balbi wrote:
those routines have everything we need to map/unmap
USB requests and it's better to use them.
Signed-off-by: Felipe Balbiba...@ti.com
---
drivers/usb/gadget/goku_udc.c | 17 +++--
1 files changed, 7 insertions(+), 10
On Mon, Dec 19, 2011 at 05:02:51PM +0400, Sergei Shtylyov wrote:
Hello.
On 19-12-2011 14:30, Felipe Balbi wrote:
those routines have everything we need to map/unmap
USB requests and it's better to use them.
Signed-off-by: Felipe Balbiba...@ti.com
---
drivers/usb/gadget/goku_udc.c |
Hello.
On 19-12-2011 17:09, Felipe Balbi wrote:
On 19-12-2011 14:30, Felipe Balbi wrote:
those routines have everything we need to map/unmap
USB requests and it's better to use them.
Signed-off-by: Felipe Balbiba...@ti.com
---
drivers/usb/gadget/goku_udc.c | 17 +++--
1
Hello.
On 19-12-2011 17:02, Sergei Shtylyov wrote:
those routines have everything we need to map/unmap
USB requests and it's better to use them.
Signed-off-by: Felipe Balbiba...@ti.com
---
drivers/usb/gadget/goku_udc.c | 17 +++--
1 files changed, 7 insertions(+), 10 deletions(-)
Hi Grant and Rob,
Gentle ping: Do you have some comment on that series?
Thanks,
Benoit
On 12/5/2011 3:23 PM, Benoit Cousson wrote:
Hi Grant Rob,
Following the previous patch submission [1], here is an updated series
that adds the support for both reg and irq names.
A small improvement is
Salut Samuel,
On 12/19/2011 1:03 PM, Samuel Ortiz wrote:
Hi Benoit,
On Fri, Dec 09, 2011 at 03:02:34PM +0100, Benoit Cousson wrote:
Add initial device-tree support for twl familly chips.
The current version is missing the regulator entries due
to the lack of DT regulator bindings for the
On 12/05/2011 08:23 AM, Benoit Cousson wrote:
The current implementation just ignore any NULL string inserted in a
multiple strings property.
In some cases we can have a property with a fix number of strings but
not necessarily used, like for example in a list of valid pinmux modes.
prop =
Hi Mark, Tony,
On 12/17/2011 11:36 AM, Mark Brown wrote:
Yes this is planed for the Dtree support, but the aim here is to get working
audio on PandaBoard as well with upstream kernel.
Just do it right to start off with, the device tree bindings should
normally map closely onto the platform
This is an RFC to add new device tree bindings for DDR memories and
EMIF - TI's DDR SDRAM controller.
The first patch adds bindings for DDR memories. Currently,
we have added properties for only DDR3 and LPDDR2 memories.
However, the binding can be easily extended to describe
other types such as
device tree bindings for DDR SDRAM memories compliant
to JEDEC standards. Currently only DDR3 and LPDDR2 have
been considered for this binding. Properties for other
memory types(DDR2 etc) could be added to this binding
on a need-basis.
The 'ddr' binding in-turn uses another binding 'ddr-timings'
EMIF - External Memory Interface - is an SDRAM controller used in
TI SoCs. EMIF supports, based on the IP revision, one or more of
DDR2/DDR3/LPDDR2 protocols. This binding describes a given instance
of the EMIF IP and memory parts attached to it.
Cc: Rajendra Nayak rna...@ti.com
Cc: Benoit
Device tree data for the EMIF sdram controllers in OMAP4
and DDR memories attached to OMAP4 boards.
Cc: Rajendra Nayak rna...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Signed-off-by: Aneesh V ane...@ti.com
---
arch/arm/boot/dts/omap-common-devices.dtsi | 63
On Mon, 19 Dec 2011, Felipe Balbi wrote:
such utilities are currently duplicated on all UDC
drivers basically with the same structure. Let's group
all implementations into one generic implementation
and get rid of that duplication.
Signed-off-by: Felipe Balbi ba...@ti.com
---
On Mon, 19 Dec 2011, Felipe Balbi wrote:
those routines have everything we need to map/unmap
USB requests and it's better to use them.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/usb/gadget/net2280.c | 19 +--
1 files changed, 9 insertions(+), 10 deletions(-)
Hi,
On Mon, Dec 19, 2011 at 10:19:46AM -0500, Alan Stern wrote:
On Mon, 19 Dec 2011, Felipe Balbi wrote:
such utilities are currently duplicated on all UDC
drivers basically with the same structure. Let's group
all implementations into one generic implementation
and get rid of that
Hi,
On Mon, Dec 19, 2011 at 10:21:36AM -0500, Alan Stern wrote:
On Mon, 19 Dec 2011, Felipe Balbi wrote:
those routines have everything we need to map/unmap
USB requests and it's better to use them.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/usb/gadget/net2280.c | 19
On Fri, Dec 16, 2011 at 4:01 AM, Ramirez Luna, Omar omar.rami...@ti.com wrote:
On Thu, Dec 15, 2011 at 6:39 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
Are you sure you are not missing something like:
.clk = cam_ick,
I believe in this case cam_ick is used as the main clock as it
On Fri, Dec 16, 2011 at 5:18 AM, Ramirez Luna, Omar omar.rami...@ti.com wrote:
On Thu, Dec 15, 2011 at 6:53 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Thu, Dec 15, 2011 at 6:18 AM, Omar Ramirez Luna omar.rami...@ti.com
wrote:
Use runtime PM functionality interfaced with hwmod
On Mon, 19 Dec 2011, Felipe Balbi wrote:
+ if (dma_mapping_error(gadget-dev, req-dma)) {
+ dev_err(gadget-dev, failed to map buffer\n);
+ return -EFAULT;
+ }
+ }
+
+ return 0;
You forgot to set req-mapped.
actually
Hi Shubhro,
On 12/18/2011 9:01 AM, Shubhrajyoti wrote:
[...]
The driver does a reset in the error path.
Since we are not supposed to access the sysc reg the function is needed.
I'm just wondering what will happen to the driver if this callback is
not provided during the device creation?
Hi,
Some comments below, but also a more general question: How much of
this generic data makes sense to encode in the device tree? Final
hardware configuration usually has to take into consideration board
layout/signal delays, etc, and that's not part of this binding.
On Mon, Dec 19, 2011 at
Hi Alessandro,
Gentle ping on this patch.
Thanks,
Benoit
On 12/9/2011 3:02 PM, Benoit Cousson wrote:
Add the DT support for the TI rtc-twl present in the twl4030
and twl6030 devices.
Signed-off-by: Benoit Coussonb-cous...@ti.com
Cc: Alessandro Zummoa.zu...@towertech.it
---
Hi,
Fewer comments here. :) But see below.
On Mon, Dec 19, 2011 at 6:05 AM, Aneesh V ane...@ti.com wrote:
--- /dev/null
+++ b/Documentation/devicetree/bindings/memory-controllers/ti/emif.txt
@@ -0,0 +1,64 @@
+* EMIF family of TI SDRAM controllers
+
+EMIF - External Memory Interface - is
On Fri, Dec 16, 2011 at 10:53 PM, Tony Lindgren t...@atomide.com wrote:
You should use ttyO for the omap ports, but zoom debug board
has external 8250 ftdi ports, so those show up as ttyS and
not ttyO.
Plus that was changed on 2.6.36 (or after?) and he is using 2.6.35.
--
Felipe Contreras
--
Oh wait, when I saw 3/3 I realized the following too:
On Mon, Dec 19, 2011 at 6:05 AM, Aneesh V ane...@ti.com wrote:
+- phy-type : string indicating the phy type. Should be one of the
+ following:
+
+ phy-type-omap4 : PHY used in OMAP4 family of SoCs
+
+ phy-type-dm81xx : PHY used
On Monday 19 December 2011 10:02 PM, Cousson, Benoit wrote:
Hi Shubhro,
On 12/18/2011 9:01 AM, Shubhrajyoti wrote:
[...]
The driver does a reset in the error path.
Since we are not supposed to access the sysc reg the function is needed.
I'm just wondering what will happen to the driver
* Peter Ujfalusi peter.ujfal...@ti.com [111219 05:33]:
Hi Mark, Tony,
On 12/17/2011 11:36 AM, Mark Brown wrote:
Yes this is planed for the Dtree support, but the aim here is to get
working
audio on PandaBoard as well with upstream kernel.
Just do it right to start off with, the
Hi Arnd Olof,
Here are two fixes that could potentially go into v3.2 -rc cycle.
One fixes a harmless but annoying warning that happens on omap 34xx
processors during boot. The other one fixes booting on pretty rare
secure mode development board, but that's fixed in features that
never worked
Hi Arnd Olof,
Please pull omap hwmod changes from:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap hwmod
These changes are mostly needed for the USB *HCI support to
behave. These depend on the fixes-non-critical-part2 posted
earlier.
Regards,
Tony
The following changes
Hi Arnd Olof,
Please pull omap echi changes from:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap ehci
These are needed for runtime PM support for the usb *hci controllers
on omap. These depend on the fixes-non-critical-part2 + hwmod branches
posted earlier.
Regards,
Tony
Hi Arnd Olof,
Please pull omap prcm changes from:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap prcm
These changes adds support for PRCM (Power, Reset, Clock, Module)
chained interrupt handling. This will eventually allow us to start
making PM parts into driver modules and
From: Felipe Contreras felipe.contre...@gmail.com
In musb_init_controller() there's a pm_runtime_put(), but there's no
pm_runtime_get(), which creates a mismatch that causes the driver to
sleep when it shouldn't.
This was introduced in 7acc619[1], but it wasn't triggered in my setup
until
Hi Arnd Olof,
Please pull omap uart changes from:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap uart
These allow us to remove quite a bit of serial port code
from arch/arm/*omap* as the omap-serial.c driver can now do
the necessary things using runtime PM :) Also this series
From: Felipe Contreras felipe.contre...@gmail.com
These are handled by drivers core, and in a way that doesn't wake up the
devices.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
drivers/usb/musb/omap2430.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git
On Mon, Dec 19, 2011 at 10:11 AM, Felipe Balbi ba...@ti.com wrote:
On Fri, Dec 16, 2011 at 01:05:08AM +0200, Felipe Contreras wrote:
Properly call pm_runtime_put() afer pm_runttime_get() on errors.
Untested.
sorry, but I'm not applying untested patches. I need someone to give a
Tested-by.
From: Felipe Contreras felipe.contre...@gmail.com
Properly call pm_runtime_put() afer pm_runttime_get() on errors.
Comments from Alan Stern.
Untested.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
drivers/usb/musb/musb_gadget.c |1 +
drivers/usb/musb/omap2430.c|1 +
From: Felipe Contreras felipe.contre...@gmail.com
And use dev instead of musb-controller.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
drivers/usb/musb/omap2430.c | 27 +--
1 files changed, 13 insertions(+), 14 deletions(-)
diff --git
From: Felipe Contreras felipe.contre...@gmail.com
enabled driver || !enabled can be simplified to !enabled || driver.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
drivers/usb/musb/omap2430.c |8 +---
1 files changed, 1 insertions(+), 7 deletions(-)
diff --git
Hi,
Here's a few cleanups and possible fixes. Nothing major.
In v2 I added comments from Alan Stern, and another possible fix by removing
some pm_runtime_disable() calls.
Felipe Contreras (4):
usb: musb: fix pm_runtime mismatches
usb: musb: trivial cleanup
usb: musb: remove a bit of
On Fri, Dec 16, 2011 at 5:30 AM, Alan Stern st...@rowland.harvard.edu wrote:
On Fri, 16 Dec 2011, Felipe Contreras wrote:
Should these calls be pm_runtime_put_sync() instead of
pm_runtime_put()?
I don't see why... The thing failed, it's not going to be used any
more so better let PM
Resending with mailing lists in Cc.
* Tony Lindgren t...@atomide.com [111219 11:45]:
Hi Arnd Olof,
Please pull few non-critical fixes for v3.3 merge window from:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap
fixes-non-critical-part2
These will be needed for some
Hi Jean
I'm really sorry it's taken me so long to do detailed review of these
patches for merging... anyway -
On Wed, 14 Dec 2011, jean.pi...@newoldbits.com wrote:
From: Jean Pihet j-pi...@ti.com
. Implement the devices wake-up latency constraints using the global
device PM QoS
Hi
On Wed, 14 Dec 2011, jean.pi...@newoldbits.com wrote:
From: Jean Pihet j-pi...@ti.com
The OMAP PM code implements a handler for the per-device PM QoS framework.
The handler queries the omap_hwmod layer in order to manage the power domains
wake-up latency constraints. Hwmod retrieves the
Hi
On Wed, 14 Dec 2011, jean.pi...@newoldbits.com wrote:
From: Jean Pihet j-pi...@ti.com
Implement the devices wake-up latency constraints using the global
device PM QoS notification handler which applies the constraints to the
underlying layer by calling the corresponding function at
Hi Benoît,
On Fri, 16 Dec 2011, Cousson, Benoit wrote:
On 12/16/2011 6:53 AM, Paul Walmsley wrote:
Hi Benoît
On Wed, 14 Dec 2011, Ming Lei wrote:
Signed-off-by: Ming Leiming@canonical.com
Acked-by: Benoit Cousson b-cous...@ti.com
---
Hi
On Fri, 16 Dec 2011, Cousson, Benoit wrote:
On 12/16/2011 7:28 AM, Paul Walmsley wrote:
On Mon, 28 Nov 2011, Peter Ujfalusi wrote:
To be able to get the memory resources by name from
the DMIC driver (for MPU and for DMA).
Any comments on this one? Looks like we'd need to add
Hi Tony
The following changes since commit dc47ce90c3a822cd7c9e9339fe4d5f61dcb26b50:
Linux 3.2-rc5 (2011-12-09 15:09:32 -0800)
are available in the git repository at:
git://git.pwsan.com/linux-2.6 hwmod_data_b_devel_3.3
Ming Lei (1):
ARM: OMAP4: hwmod data: introduce fdif(face detect
I'm working with linux-3.0 (I know its not the latest), and I have the
USB host working.
However when I try to suspend, the usbhost power domain doesn't go into
suspend. I've added code to capture the PRCM registers in SRAM just
before the WFI is executed and dump them after it resumes. For
On 12/19/2011 08:05 AM, Aneesh V wrote:
This is an RFC to add new device tree bindings for DDR memories and
EMIF - TI's DDR SDRAM controller.
The first patch adds bindings for DDR memories. Currently,
we have added properties for only DDR3 and LPDDR2 memories.
However, the binding can be
The Amstrad Delta board has two extra output ports used for driving
input lines of different on-board devices. Those ports are now
controlled with custom functions, provided by the board arch code and
used by several device drivers.
The idea behind the series is to replace those custom I/O
Once ready, ams-delta specific device drivers currently calling custom
ams_delta_latch[12]_write() functions can be updated to call generic
gpio_set_value() instead, which will make them less platform dependent.
Even more, some custom ams-delta only drivers can perhaps be dropped
from the tree
This driver is no longer needed after the Amstrad Delta on-board LED
devices have been converted to leds-gpio compatible.
Created against linux-3.2-rc6.
Requires patch 3/7 ARM: OMAP1: ams-delta: supersede custom led device
by leds-gpio for those LEDs to still work.
Signed-off-by: Janusz
Don't use Amstrad Delta custom I/O functions for controlling the device,
use GPIO API instead.
While being at it, add missing gpio_free(AMS_DELTA_GPIO_PIN_NAND_RB).
Depends on patch 2/7 ARM: OMAP1: ams-delta: convert latches to
basic_mmio_gpio
Signed-off-by: Janusz Krzysztofik
Now that the Amstrad Delta on-board latches have been converted to GPIO
devices, use the generic driver to control on-board LEDs which hang off
those latches.
Depends on patch 2/7 ARM: OMAP1: ams-delta: convert latches to
basic_mmio_gpio
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
Don't use Amstrad Delta custom I/O functions any longer, use GPIO API
instead.
Depends on patch 2/7 ARM: OMAP1: ams-delta: convert latches to
basic_mmio_gpio.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
Acked-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Tony Lindgren t...@atomide.com
Don't use Amstrad Delta custom I/O functions once GPIO interface is
available for the underlying hardware.
While requesting and initializing GPIO pins used, also take care of one
extra pin KEYBRD_DATAOUT which, even if not used by the driver, belongs
to the device and affects its functioning.
Resending because of a typo in the Cc: list, sorry.
8--
In preparation to converting Amstrad Delta on-board latches to
basic_mmio_gpio devices, registration of platform devices which depend
on latches and will require initialization of their GPIO pins first,
should be
* Rob Herring robherri...@gmail.com [111219 14:29]:
On 12/19/2011 08:05 AM, Aneesh V wrote:
This is an RFC to add new device tree bindings for DDR memories and
EMIF - TI's DDR SDRAM controller.
The first patch adds bindings for DDR memories. Currently,
we have added properties for
* Vaibhav Hiremath hvaib...@ti.com [111219 01:48]:
This patch doesn't change functionality or behavior of the code
execution; it barely cleans up the code and splits into SoC
specific implementation for Rev ID and feature detection.
Thanks, looks good now and allows further clean-up later on.
Current OMAP3 PM code seems to be incompatible with AM35{05,17} and
leads to system hang during boot.
Disable PM init on AM35{05,17} until working implementation will be
merged.
Signed-off-by: Ilya Yanok ya...@emcraft.com
---
This patch solves the problem for me but I'm curious why simple
* Janusz Krzysztofik jkrzy...@tis.icnet.pl [111219 14:41]:
Once ready, ams-delta specific device drivers currently calling custom
ams_delta_latch[12]_write() functions can be updated to call generic
gpio_set_value() instead, which will make them less platform dependent.
Even more, some custom
On Mon, Dec 19, 2011 at 04:04:53PM +0200, Peter Ujfalusi wrote:
On 12/17/2011 11:36 AM, Mark Brown wrote:
Just do it right to start off with, the device tree bindings should
normally map closely onto the platform data where platform data exists
already and you're going to have to have the
On Mon, Dec 19, 2011 at 09:56:50AM +, Girdwood, Liam wrote:
Mark will take it for this kernel release (if he's OK with it).
Someone would need to send the change to me, prefereably with a subject
line which makes it look relevant.
--
To unsubscribe from this list: send the line unsubscribe
Hi Paul,
Paul Walmsley paul at pwsan.com writes:
[0.238494] Kernel BUG at c0033e34 [verbose debug info unavailable]
[0.245025] Internal error: Oops - undefined instruction: 0 [#1] SMP
[0.262390] PC is at omap3_l3_app_irq+0x108/0x12c
I'm getting the same error on one of my AM3517
warning: (ARCH_OMAP4 ARCH_VEXPRESS_CA9X4) selects ARM_ERRATA_720789 which
has unmet direct dependencies (CPU_V7 SMP)
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
arch/arm/mach-omap2/Kconfig |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git
warning: (MACH_OMAP_ZOOM2 MACH_OMAP_ZOOM3 MACH_OMAP_4430SDP
MACH_OMAP4_PANDA TPS6105X) selects REGULATOR_FIXED_VOLTAGE which has unmet
direct dependencies (REGULATOR)
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
arch/arm/mach-omap2/Kconfig | 10 +-
1 files
warning: (MACH_OMAP3_TOUCHBOOK DRM_RADEON_KMS DRM_I915 STUB_POULSBO
FB_BACKLIGHT USB_APPLEDISPLAY FB_OLPC_DCON ASUS_LAPTOP SONY_LAPTOP
THINKPAD_ACPI EEEPC_LAPTOP ACPI_ASUS ACPI_CMPC SAMSUNG_Q10)
selects BACKLIGHT_CLASS_DEVICE which has unmet direct dependencies (HAS_IOMEM
* Paul Walmsley p...@pwsan.com [111219 13:25]:
Hi Tony
The following changes since commit dc47ce90c3a822cd7c9e9339fe4d5f61dcb26b50:
Linux 3.2-rc5 (2011-12-09 15:09:32 -0800)
are available in the git repository at:
git://git.pwsan.com/linux-2.6 hwmod_data_b_devel_3.3
Thanks pulling
On Mon, Dec 19, 2011 at 11:20:37AM -0800, Tony Lindgren wrote:
* Peter Ujfalusi peter.ujfal...@ti.com [111219 05:33]:
struct omap-abe-twl6040-connection sdp4430_asoc_route[] = {
{MAINMIC, Main Mic Bias},
{SUBMIC, Main Mic Bias},
{Main Mic Bias, Ext Mic},
Hmm does it make
On Tuesday 20 of December 2011 at 01:06:00, Tony Lindgren wrote:
* Janusz Krzysztofik jkrzy...@tis.icnet.pl [111219 14:41]:
Once ready, ams-delta specific device drivers currently calling custom
ams_delta_latch[12]_write() functions can be updated to call generic
gpio_set_value() instead,
On Tue, Dec 13, 2011 at 03:49:33PM +0530, Rajendra Nayak wrote:
I'm OK with this but would prefer that OMAP or TWL people were OK with
it too. If you do need to respin:
+For twl4030 regulators/LDO's
' should *not* be used for plurals except when omitting a duplicated s
introduced by one
* Janusz Krzysztofik jkrzy...@tis.icnet.pl [111219 16:28]:
On Tuesday 20 of December 2011 at 01:06:00, Tony Lindgren wrote:
This part especially looks like it really should be just a regular
device driver under drivers/ somewhere.
I really don't understand what kind of a driver you
On Tuesday 20 of December 2011 at 02:04:46, Tony Lindgren wrote:
* Janusz Krzysztofik jkrzy...@tis.icnet.pl [111219 16:28]:
On Tuesday 20 of December 2011 at 01:06:00, Tony Lindgren wrote:
This part especially looks like it really should be just a regular
device driver under drivers/
1 - 100 of 112 matches
Mail list logo
