On 8/31/2012 2:02 AM, Tony Lindgren wrote:
* AnilKumar Ch anilku...@ti.com [120828 01:11]:
Adds basic pinctrl device tree data for AM33XX family of devices.
This patch is based on the pinctrl-single driver.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
arch/arm/boot/dts/am33xx.dtsi |
On Thursday 30 August 2012 10:12 PM, Tomi Valkeinen wrote:
On Thu, 2012-08-30 at 13:57 +0200, Benoit Cousson wrote:
On 08/30/2012 10:39 AM, Rajendra Nayak wrote:
On Thursday 30 August 2012 05:45 AM, Turquette, Mike wrote:
On Wed, Aug 29, 2012 at 1:56 AM, Rajendra Nayakrna...@ti.com wrote:
On Fri, 2012-08-31 at 11:53 +0530, Archit Taneja wrote:
The only little problem was that during bootup, when hwmods are setup,
only the 'parent' hwmod was able to get reset properly, all the other
'child' hwmods don't have modulemode bits tied to them, and hence
weren't able to reset. So
Hello,
This patchset fixes the i2c adapter id on OMAP3 and OMAP4/AM33xx when booting
from a device tree.
Currently, pdev-id is used, regardless of the boot method. The first patch
checks for of_node, and get the id from the alias if a device tree is found.
The boot message is updated
When booting from a device tree, the omap driver is using pdev-id,
which is incorrect. The proposed patch uses aliases, as done in
omap-serial.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
---
drivers/i2c/busses/i2c-omap.c | 19 +++
1 files changed, 15
I2C aliases need to be set, for the omap-i2c driver to get a correct adapter id.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
---
arch/arm/boot/dts/am33xx.dtsi |3 +++
arch/arm/boot/dts/omap3.dtsi |3 +++
arch/arm/boot/dts/omap4.dtsi |4
3 files changed, 10
On Friday 31 August 2012 12:45 PM, Tomi Valkeinen wrote:
On Fri, 2012-08-31 at 11:53 +0530, Archit Taneja wrote:
The only little problem was that during bootup, when hwmods are setup,
only the 'parent' hwmod was able to get reset properly, all the other
'child' hwmods don't have modulemode
On Fri, 2012-08-31 at 13:50 +0530, Archit Taneja wrote:
On Friday 31 August 2012 12:45 PM, Tomi Valkeinen wrote:
On Fri, 2012-08-31 at 11:53 +0530, Archit Taneja wrote:
The only little problem was that during bootup, when hwmods are setup,
only the 'parent' hwmod was able to get reset
On Friday 31 August 2012 01:57 PM, Tomi Valkeinen wrote:
On Fri, 2012-08-31 at 13:50 +0530, Archit Taneja wrote:
On Friday 31 August 2012 12:45 PM, Tomi Valkeinen wrote:
On Fri, 2012-08-31 at 11:53 +0530, Archit Taneja wrote:
The only little problem was that during bootup, when hwmods are
On Wed, 2012-07-04 at 06:11 -0600, Paul Walmsley wrote:
Hi Tomi
On Wed, 27 Jun 2012, Paul Walmsley wrote:
On Thu, 10 May 2012, Tomi Valkeinen wrote:
These patches fix DSS hwmod data related to sysc flags. I haven't seen any
problem produced by these missing bits, but by looking at
Hi Florian,
On 08/31/2012 09:52 AM, Florian Vaussard wrote:
When booting from a device tree, the omap driver is using pdev-id,
which is incorrect.
Not really, see below...
The proposed patch uses aliases, as done in omap-serial.
Mmm, but is it really needed?
In the case of serial the id is
Adds GPIO pinctrl nodes to am3358_pinmux master node to control
user leds (USR0, USR1, USR2 and USR3) present on BeagleBone.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
arch/arm/boot/dts/am335x-bone.dts | 41 +
1 file changed, 41 insertions(+)
diff
Add Bosch D_CAN controller device tree data to AM33XX dtsi
file by adding d_can device nodes with all the necessary
parameters.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
arch/arm/boot/dts/am33xx.dtsi | 18 ++
1 file changed, 18 insertions(+)
diff --git
Adds basic pinctrl device tree data for AM33XX family of devices.
This patch is based on the pinctrl-single driver.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
arch/arm/boot/dts/am33xx.dtsi |9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi
Add pinctrl and d_can device tree data to AM33XX family of devices.
First two patches add support for pinctrl DT data and third one
adds dcan DT data.
Reason behind combining these patches is to apply cleanly on
linux-omap tree, because these are sequential patches.
These patches were tested on
Modify c_can binding documentation according to recent review comments
on device tree data addition patches.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
.../devicetree/bindings/net/can/c_can.txt | 25
1 file changed, 20 insertions(+), 5 deletions(-)
diff
Adopt pinctrl support to leds-gpio driver, based on the device
pointer (leds-gpio) pinctrl driver configure SoC pins to GPIO
mode.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
drivers/leds/leds-gpio.c | 31 ---
1 file changed, 24 insertions(+), 7 deletions(-)
Hi Sourav,
While rebasing your series on top of Tony's lo/devel-dt, I realized that the
keypad nodes are not located at the correct place :-(
At the moment they are just floating at the top level of the dts while they
belong to the ocp bus and thus should be put there.
I fixed that since it
Add DT OPP table for AM33XX family of devices. This data is
decoded by OF with of_init_opp_table() helper function.
Also adds cpu0 supply name to the corresponding dts files.
cpu0-supply name is used by cpufreq-cpu0 driver to get the
regulator pointer for voltage modifications.
Signed-off-by:
Add cpufreq support to AM33XX family of devices by adding OPP
information, clock entry with cpu0 name and voltage supplies
to cpu0.
These patches have been tested on AM335x-EVM, AM335x-Bone and
these patches are based on cpufreq-cpu0 driver
http://marc.info/?l=linux-arm-kernelm=134457735413293w=2
Add AM335x cpu0 clock entry to the corresponding clock data
file. This is useful in getting the correct mpu clock pointer
to change the cpu frequency in cpufreq driver.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
arch/arm/mach-omap2/clock33xx_data.c |1 +
1 file changed, 1 insertion(+)
Hi Benoit,
[0.658843] omap_i2c i2c.15: bus -1 rev2.4.0 at 400 kHz
[0.760192] omap_i2c i2c.16: bus -1 rev2.4.0 at 400 kHz
[0.775817] omap_i2c i2c.17: bus -1 rev2.4.0 at 400 kHz
[0.791442] omap_i2c i2c.18: bus -1 rev2.4.0 at 400 kHz
OK, it is true that the current log is not that
Hi,
On Thu, Aug 30, 2012 at 03:39:40PM +0400, Sergei Shtylyov wrote:
Hello.
On 30-08-2012 14:50, Ravi Babu wrote:
From: Ajay Kumar Gupta ajay.gu...@ti.com
Added device tree data for usbss on am33xx. There are two musb controllers
on am33xx platform so have port0_mode and port1_mode
On Thu, Aug 30, 2012 at 03:39:40PM +0400, Sergei Shtylyov wrote:
Hello.
On 30-08-2012 14:50, Ravi Babu wrote:
From: Ajay Kumar Gupta ajay.gu...@ti.com
Added device tree data for usbss on am33xx. There are two musb
controllers on am33xx platform so have port0_mode and
Hi,
On Thu, Aug 30, 2012 at 4:20 PM, Ravi Babu ravib...@ti.com wrote:
From: Ajay Kumar Gupta ajay.gu...@ti.com
Added device tree data for usbss on am33xx. There are two musb controllers
on am33xx platform so have port0_mode and port1_mode additional data.
Signed-off-by: Ajay Kumar Gupta
On Thu, Aug 30, 2012 at 4:20 PM, Ravi Babu ravib...@ti.com wrote:
From: Ajay Kumar Gupta ajay.gu...@ti.com
Added device tree data for usbss on am33xx. There are two musb
controllers on am33xx platform so have port0_mode and
port1_mode additional data.
Signed-off-by: Ajay Kumar
Hi Benoit,
On Fri, Aug 31, 2012 at 3:02 PM, Benoit Cousson b-cous...@ti.com wrote:
Hi Sourav,
While rebasing your series on top of Tony's lo/devel-dt, I realized that the
keypad nodes are not located at the correct place :-(
At the moment they are just floating at the top level of the dts
On Fri, Aug 24, 2012 at 21:21:45, Hiremath, Vaibhav wrote:
On Fri, Aug 17, 2012 at 18:00:54, Cousson, Benoit wrote:
Hi Vaibhav,
On 08/17/2012 12:12 PM, Vaibhav Hiremath wrote:
On 7/16/2012 7:41 PM, Vaibhav Hiremath wrote:
Hi All,
Paul,
From last couple of
When booting using a device tree, the adapter number is dynamically
assigned after the log message is sent.
This patch modifies the log message to get a correct adapter id.
Applies on 3.6-rc3. Tested on OMAP3 (Gumstix Overo).
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
---
From: Ajay Kumar Gupta ajay.gu...@ti.com
Added device tree data for usbss on am33xx. There are two musb controllers
on am33xx platform so have port0_mode and port1_mode additional data.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
Signed-off-by: Santhapuri, Damodar damodar.santhap...@ti.com
From: Santhapuri, Damodar damodar.santhap...@ti.com
AM33xx has two PHY of same type used by each musb controller so
use phandle of phy nodes to get the phy pointer.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
Signed-off-by: Santhapuri, Damodar damodar.santhap...@ti.com
Signed-off-by: Ravi
From: Ajay Kumar Gupta ajay.gu...@ti.com
Enabled the phy control logic for am335x also based on usbss
revision register.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
Signed-off-by: Santhapuri, Damodar damodar.santhap...@ti.com
Signed-off-by: Ravi Babu ravib...@ti.com
---
From: Ajay Kumar Gupta ajay.gu...@ti.com
As NOP device node is now added in am33xx tree so remove the call
which creates the NOP platform_device.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
Signed-off-by: Santhapuri, Damodar damodar.santhap...@ti.com
Signed-off-by: Ravi Babu
AM335x and TI81xx platform has dual musb controller so updating the
musb_dspc.c to support the same.
Changes:
- Moved otg_workaround timer to glue structure
- Moved static local variable last_timer to glue structure
- PHY on/off related cleanups
Signed-off-by: Ajay Kumar
Added musb_ida in musb_core.c to manage the multi core ids.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
Signed-off-by: Santhapuri, Damodar damodar.santhap...@ti.com
Signed-off-by: Ravi Babu ravib...@ti.com
---
drivers/usb/musb/am35x.c | 42 --
From: Ajay Kumar Gupta ajay.gu...@ti.com
Moved global variable musb_debugfs_root and static variable
old_state to 'struct musb' to help support multi instance of
musb controller as present on AM335x platform.
Also removed the global variable orig_dma_mask and filled the
dev-dma_mask with parent
From: Santhapuri, Damodar damodar.santhap...@ti.com
Currently we have one single nop transceiver support as same is
defined as a global variable in drivers/usb/otg/nop-usb-xceiv.c.
This need to be changed to support multiple otg controller each
using nop transceiver on a platform such as am335x.
This series of patches adds,
a) Multi instances support in musb driver
b) DT support for musb_dsps glue layer
c) DT support for NOP transceiver
AM33xx and TI81xx has dual musb controller and has two usb PHY of same type.
This patch series uses 'phandle' based API devm_usb_get_phy_by_phandle() to
From: Santhapuri, Damodar damodar.santhap...@ti.com
AM335x uses NOP transceiver driver and need to enable builtin PHY
by writing into usb_ctrl register available in system control
module register space. This is being added at musb glue driver
layer untill a separate system control module driver
From: Ajay Kumar Gupta ajay.gu...@ti.com
Added NOP PHY phandle to usbss device node as same will be used
to get the phy from otg framework.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
Signed-off-by: Santhapuri, Damodar damodar.santhap...@ti.com
Signed-off-by: Ravi Babu ravib...@ti.com
---
From: Ajay Kumar Gupta ajay.gu...@ti.com
AM33xx has two musb controller and they have one NOP PHY each.
Added the device tree data for NOP PHY.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
Signed-off-by: Santhapuri, Damodar damodar.santhap...@ti.com
Signed-off-by: Ravi Babu ravib...@ti.com
Added device tree support for nop transceiver driver and updated the
Documentation with device tree binding information for am33xx platform.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
Signed-off-by: Ravi Babu ravib...@ti.com
---
.../devicetree/bindings/usb/am33xx-usb.txt |3
From: Ajay Kumar Gupta ajay.gu...@ti.com
Added device tree support for dsps musb glue driver and updated the
Documentation with device tree binding information.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
Signed-off-by: Santhapuri, Damodar damodar.santhap...@ti.com
Signed-off-by: Ravi Babu
On Thu, 2012-08-30 at 10:19 -0700, Tony Lindgren wrote:
Hi,
* Tomi Valkeinen tomi.valkei...@ti.com [120830 00:35]:
On Wed, 2012-08-29 at 17:20 -0700, Tony Lindgren wrote:
Good to see this, we need this badly to avoid blocking
single zImage effort on omaps. Can you also please take
On Fri, 2012-08-31 at 13:35 +0200, Andreas Bießmann wrote:
Do not kfree() the mtd_info, it is handled in the mtd subsystem and already
freed by nand_release(). Instead kfree() the struct omap_nand_info allocated
in
omap_nand_probe which was not kfree()ed before.
This patch fixes following
Unloading the omap2 nand driver missed to release the memory region which will
result in not being able to request it again if one want to load the driver
later on.
This patch fixes following error when loading omap2 module after unloading:
---8---
~ $ rmmod omap2
~ $ modprobe omap2
[
Do not kfree() the mtd_info, it is handled in the mtd subsystem and already
freed by nand_release(). Instead kfree() the struct omap_nand_info allocated in
omap_nand_probe which was not kfree()ed before.
This patch fixes following error when unloading the omap2 module:
---8---
~ $ rmmod omap2
These two patches fixes the omap_nand_remove function to release all resources
properly and be able to re-load the driver later on.
Andreas Bießmann (2):
mtd/nand/omap2: fix omap_nand_remove segfault
mtd/nand/omap2: fix module loading
drivers/mtd/nand/omap2.c |3 ++-
1 file changed, 2
On Thu, 2012-08-30 at 17:10 +0530, Archit Taneja wrote:
Add output structs to output driver's private data. Register output instances
by
having an init function in the probes of the platform device drivers for
different outputs. The *_init_output for each output registers the output and
fill
On Friday 31 August 2012 05:27 PM, Tomi Valkeinen wrote:
On Thu, 2012-08-30 at 17:10 +0530, Archit Taneja wrote:
Add output structs to output driver's private data. Register output instances by
having an init function in the probes of the platform device drivers for
different outputs. The
On Thu, 2012-08-30 at 17:10 +0530, Archit Taneja wrote:
An output entity represented by the struct omap_dss_output connects to a
omap_dss_device entity. Add functions to set or unset an output's device. This
is similar to how managers and devices were connected previously. An output
can
On Thu, 2012-08-30 at 17:10 +0530, Archit Taneja wrote:
With the introduction of output entities, managers will now connect to
outputs.
Use the helper op for managers named get_device. This will abstract away the
information on how to get the device from an overlay manager.
Using the
On Friday 31 August 2012 05:33 PM, Tomi Valkeinen wrote:
On Thu, 2012-08-30 at 17:10 +0530, Archit Taneja wrote:
An output entity represented by the struct omap_dss_output connects to a
omap_dss_device entity. Add functions to set or unset an output's device. This
is similar to how managers and
Hi,
On Fri, Aug 31, 2012 at 04:39:47PM +0530, Ravi Babu wrote:
From: Santhapuri, Damodar damodar.santhap...@ti.com
AM335x uses NOP transceiver driver and need to enable builtin PHY
by writing into usb_ctrl register available in system control
module register space. This is being added at
On Fri, 2012-08-31 at 17:54 +0530, Archit Taneja wrote:
On Friday 31 August 2012 05:33 PM, Tomi Valkeinen wrote:
I don't think there's need for this indirection. We should use function
pointers only when the func pointer may lead to different functions.
Here we'll always have just one
On Friday 31 August 2012 05:41 PM, Tomi Valkeinen wrote:
On Thu, 2012-08-30 at 17:10 +0530, Archit Taneja wrote:
With the introduction of output entities, managers will now connect to outputs.
Use the helper op for managers named get_device. This will abstract away the
information on how to get
On 08/31/2012 01:02 PM, Florian Vaussard wrote:
When booting using a device tree, the adapter number is dynamically
assigned after the log message is sent.
This patch modifies the log message to get a correct adapter id.
Applies on 3.6-rc3. Tested on OMAP3 (Gumstix Overo).
Thanks for the
Hi,
On Fri, Aug 31, 2012 at 5:53 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Fri, Aug 31, 2012 at 04:39:47PM +0530, Ravi Babu wrote:
From: Santhapuri, Damodar damodar.santhap...@ti.com
AM335x uses NOP transceiver driver and need to enable builtin PHY
by writing into usb_ctrl register
On Fri, Aug 31, 2012 at 06:51:04PM +0530, ABRAHAM, KISHON VIJAY wrote:
Hi,
On Fri, Aug 31, 2012 at 5:53 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Fri, Aug 31, 2012 at 04:39:47PM +0530, Ravi Babu wrote:
From: Santhapuri, Damodar damodar.santhap...@ti.com
AM335x uses NOP
On Thu, 2012-08-30 at 17:10 +0530, Archit Taneja wrote:
When a panel driver calls a DPI function, it passes the omap_dss_device
pointer, this pointer currently propagates within the DPI driver to configure
the interface.
Extract the omap_dss_output pointer from omap_dss_device received from
On Thu, 2012-08-30 at 17:10 +0530, Archit Taneja wrote:
Links between DSS entities are made in dss_recheck_connections when a new
panel
is probed. Rewrite the code in dss_recheck_connections to link managers to
outputs, and outputs to devices.
The fields in omap_dss_device struct gives
On Thu, 2012-08-30 at 17:10 +0530, Archit Taneja wrote:
All functions of an interface driver used by a panel driver should have an
omap_dss_device pointer as an argument. This may not be needed by some of the
interfaces now as driver data is globally visible in them. The correct way
to
On Friday 31 August 2012 07:40 PM, Tomi Valkeinen wrote:
On Thu, 2012-08-30 at 17:10 +0530, Archit Taneja wrote:
Links between DSS entities are made in dss_recheck_connections when a new panel
is probed. Rewrite the code in dss_recheck_connections to link managers to
outputs, and outputs to
On Friday 31 August 2012 07:50 PM, Tomi Valkeinen wrote:
On Thu, 2012-08-30 at 17:10 +0530, Archit Taneja wrote:
All functions of an interface driver used by a panel driver should have an
omap_dss_device pointer as an argument. This may not be needed by some of the
interfaces now as driver data
On Thu, 2012-08-30 at 17:10 +0530, Archit Taneja wrote:
The display sysfs attribute's store function needs to be changed with the
introduction of outputs.
Providing a manager to the display isn't enough to create a link now, the
manager needs and output to connect to. A manager's display
On Friday 31 August 2012 08:00 PM, Tomi Valkeinen wrote:
On Thu, 2012-08-30 at 17:10 +0530, Archit Taneja wrote:
The display sysfs attribute's store function needs to be changed with the
introduction of outputs.
Providing a manager to the display isn't enough to create a link now, the
manager
On Fri, 2012-08-31 at 19:54 +0530, Archit Taneja wrote:
On Friday 31 August 2012 07:40 PM, Tomi Valkeinen wrote:
On Thu, 2012-08-30 at 17:10 +0530, Archit Taneja wrote:
Links between DSS entities are made in dss_recheck_connections when a new
panel
is probed. Rewrite the code in
Hi Russell Tony,
AM335X EVM (based on AM33XX device) only supports DT boot mode and
doesn't have CONFIG_MACH_AM335XEVM option defined. Some time back during
baseport submission we had aligned that, we won't create separate EVM
options, killing the board file all-together.
Having said that, the
On Fri, 2012-08-31 at 17:45 +0300, Tomi Valkeinen wrote:
So I'm not really against having the enum. It just would've been neat to
have the output type and instance number encoded into this enum, so that
it'd be easy to extract either one. But that kinda ruins the possibility
to use it in a
Hi Vaibhav,
On 08/29/2012 11:48 AM, Vaibhav Hiremath wrote:
With the new devices (like, AM33XX and OMAP5) we now only support
DT boot mode of operation and now it is the time to start killing
slowly the dependency on hwmod, so with this patch, we are starting
with device resources.
Thanks
* Rob Herring robherri...@gmail.com [120830 22:59]:
On 08/30/2012 07:52 PM, Tony Lindgren wrote:
Hi all,
Here's the first set of omap header clean-up patches needed for single
zImage support. This series is based v3.6-rc3 and the following patches
to avoid merge conflicts with the
On Fri, Aug 31, 2012 at 20:54:53, Cousson, Benoit wrote:
Hi Vaibhav,
On 08/29/2012 11:48 AM, Vaibhav Hiremath wrote:
With the new devices (like, AM33XX and OMAP5) we now only support
DT boot mode of operation and now it is the time to start killing
slowly the dependency on hwmod, so with
On 08/31/2012 05:36 PM, Hiremath, Vaibhav wrote:
On Fri, Aug 31, 2012 at 20:54:53, Cousson, Benoit wrote:
...
I think you are getting confused between Vaibhav B and Vaibhav H :)
We have two Vaibhav's roaming around here ;-)
Oops, sorry, this is the very first time I realized that two different
On Fri, Aug 31, 2012 at 6:49 PM, Felipe Balbi ba...@ti.com wrote:
On Fri, Aug 31, 2012 at 06:51:04PM +0530, ABRAHAM, KISHON VIJAY wrote:
Hi,
On Fri, Aug 31, 2012 at 5:53 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Fri, Aug 31, 2012 at 04:39:47PM +0530, Ravi Babu wrote:
From:
* Vaibhav Hiremath hvaib...@ti.com [120831 07:55]:
Hi Russell Tony,
AM335X EVM (based on AM33XX device) only supports DT boot mode and
doesn't have CONFIG_MACH_AM335XEVM option defined. Some time back during
baseport submission we had aligned that, we won't create separate EVM
options,
Op 30 aug. 2012, om 22:35 heeft Tony Lindgren t...@atomide.com het volgende
geschreven:
* AnilKumar Ch anilku...@ti.com [120828 01:11]:
Adds GPIO pinctrl nodes to am3358_pinmux master node to control
user leds (USR0, USR1, USR2 and USR3) present on BeagleBone.
Signed-off-by: AnilKumar Ch
* Ravi Babu ravib...@ti.com [120831 04:10]:
--- a/arch/arm/plat-omap/include/plat/usb.h
+++ b/arch/arm/plat-omap/include/plat/usb.h
@@ -95,7 +95,6 @@ extern void am35x_musb_reset(void);
extern void am35x_musb_phy_power(u8 on);
extern void am35x_musb_clear_irq(void);
extern void
* AnilKumar Ch anilku...@ti.com [120831 02:30]:
Adopt pinctrl support to leds-gpio driver, based on the device
pointer (leds-gpio) pinctrl driver configure SoC pins to GPIO
mode.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
drivers/leds/leds-gpio.c | 31
On Fri, Aug 31, 2012 at 21:22:26, Tony Lindgren wrote:
* Vaibhav Hiremath hvaib...@ti.com [120831 07:55]:
Hi Russell Tony,
AM335X EVM (based on AM33XX device) only supports DT boot mode and
doesn't have CONFIG_MACH_AM335XEVM option defined. Some time back during
baseport submission we
The Gumstix Overo is a computer on module using an OMAP3 processor.
This module must be plugged into an expansion board.
This patchset adds a first device tree support for the Overo, using the
Tobi expansion board. The current support is able to boot and mount
the rootfs from MMC, with a few
The Gumstix Overo is a computer on module using an OMAP3 processor.
This module must be plugged into an expansion board.
This patch adds a first device tree support for the Overo, using the
Tobi expansion board. The current support is able to boot and mount
the rootfs from MMC.
This patche also
Add the Tobi/Overo board to the list of supported platforms.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
---
.../devicetree/bindings/arm/omap/omap.txt |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git
* Hiremath, Vaibhav hvaib...@ti.com [120831 09:06]:
On Fri, Aug 31, 2012 at 21:22:26, Tony Lindgren wrote:
* Vaibhav Hiremath hvaib...@ti.com [120831 07:55]:
Hi Russell Tony,
AM335X EVM (based on AM33XX device) only supports DT boot mode and
doesn't have CONFIG_MACH_AM335XEVM
On Fri, Aug 31, 2012 at 21:41:22, Tony Lindgren wrote:
* Hiremath, Vaibhav hvaib...@ti.com [120831 09:06]:
On Fri, Aug 31, 2012 at 21:22:26, Tony Lindgren wrote:
* Vaibhav Hiremath hvaib...@ti.com [120831 07:55]:
Hi Russell Tony,
AM335X EVM (based on AM33XX device) only
On Fri, Aug 31, 2012 at 22:07:37, Hiremath, Vaibhav wrote:
On Fri, Aug 31, 2012 at 21:41:22, Tony Lindgren wrote:
* Hiremath, Vaibhav hvaib...@ti.com [120831 09:06]:
On Fri, Aug 31, 2012 at 21:22:26, Tony Lindgren wrote:
* Vaibhav Hiremath hvaib...@ti.com [120831 07:55]:
Hi Russell
* Hiremath, Vaibhav hvaib...@ti.com [120831 09:47]:
On Fri, Aug 31, 2012 at 21:41:22, Tony Lindgren wrote:
Can you please review below patch? If you think its ok, I will send the
patch -
Yeah thanks looks OK to me, at least I can't think of better options for now.
Regards,
Tony
diff
On Fri, Aug 31, 2012 at 08:24:51PM +0530, Vaibhav Hiremath wrote:
Hi Russell Tony,
AM335X EVM (based on AM33XX device) only supports DT boot mode and
doesn't have CONFIG_MACH_AM335XEVM option defined. Some time back during
baseport submission we had aligned that, we won't create separate
On Fri, Aug 31, 2012 at 22:43:36, Russell King - ARM Linux wrote:
On Fri, Aug 31, 2012 at 08:24:51PM +0530, Vaibhav Hiremath wrote:
Hi Russell Tony,
AM335X EVM (based on AM33XX device) only supports DT boot mode and
doesn't have CONFIG_MACH_AM335XEVM option defined. Some time back
This adds am335x-evm and am335x-bone dtb targets to
'make dtbs', just like other platforms.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/Makefile.boot |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git
Hi Tony,
Thanks for the review,
On Fri, Aug 31, 2012 at 21:34:04, Tony Lindgren wrote:
* AnilKumar Ch anilku...@ti.com [120831 02:30]:
Adopt pinctrl support to leds-gpio driver, based on the device
pointer (leds-gpio) pinctrl driver configure SoC pins to GPIO
mode.
Signed-off-by:
On Fri, 31 Aug 2012, Hiremath, Vaibhav wrote:
On Fri, Aug 31, 2012 at 22:43:36, Russell King - ARM Linux wrote:
On Fri, Aug 31, 2012 at 08:24:51PM +0530, Vaibhav Hiremath wrote:
Hi Russell Tony,
AM335X EVM (based on AM33XX device) only supports DT boot mode and
doesn't have
On Wed, Aug 29, 2012 at 07:04:48AM +0200, Janusz Krzysztofik wrote:
On Tue, 28 Aug 2012 11:13:39 Mark Brown wrote:
The above looks like you already have a platform driver? All I'm
suggesting is changing the above to use platform rather than driver
data.
The ams-delta asoc driver doesn't
On Thu, Aug 30, 2012 at 11:16 AM, Peter Ujfalusi peter.ujfal...@ti.com wrote:
Hi Samuel, Linus,
(...)
Did you had time to look at this series? Do you want me to resend it?
I have provided my ACK on the GPIO part assuming you're taking this
series through the MFD tree. There is not more I can
On Fri, Aug 31, 2012 at 2:52 AM, Tony Lindgren t...@atomide.com wrote:
We can't use hardcoded interrupts for SPARSE_IRQ, and can replace
the hardcoded gpio_base with twl_gpiochip.base after it's been
allocated.
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Linus Walleij
On Fri, Aug 31, 2012 at 2:52 AM, Tony Lindgren t...@atomide.com wrote:
This way we can remove includes of plat/gpio.h which won't work
with the single zImage support.
Note that we also remove the cpu_class_is_omap2() check
in gpio-omap.c as the drivers should not call it as we need to
make
* Tony Lindgren t...@atomide.com [120830 17:53]:
We can't use hardcoded interrupts for SPARSE_IRQ, and can replace
the hardcoded gpio_base with twl_gpiochip.base after it's been
allocated.
...
--- a/include/linux/mfd/twl6040.h
+++ b/include/linux/mfd/twl6040.h
@@ -194,7 +194,6 @@ struct
Hi all,
Here are the changes needed to make hardware.h local for mach-omap2.
These patches are based on v3.6-rc3 and the following patches:
- Arnd's patch ARM: omap: move platform_data definitions
- Igor's series ARM: OMAP: cleanup plat/board.h file
- Afzal's series Prepare for GPMC driver
This is no longer used anywhere.
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/plat-omap/include/plat/gpio-switch.h | 54 -
1 file changed, 54 deletions(-)
delete mode 100644 arch/arm/plat-omap/include/plat/gpio-switch.h
diff --git
There's no need to have these in plat-omap any longer. Note that these
could eventually be made local to mach-omap1 instead of being in mach.
But to do that, at least various driver access using omap7xxx.h registers
needs to be fixed first.
Cc: spi-devel-gene...@lists.sourceforge.net
Cc: Grant
These can now be moved to be local headers in mach-omap2.
Note that this patch removes arch/arm/plat-omap/devices.c as it
will get removed anyways with Paul Walmsley's patch
ARM: OMAP: split OMAP1, OMAP2+ RNG device registration.
Signed-off-by: Tony Lindgren t...@atomide.com
---
1 - 100 of 102 matches
Mail list logo
