On Thursday 10 October 2013 07:49 PM, Nishanth Menon wrote:
On 16:19-20131010, Kishon Vijay Abraham I wrote:
smps10 should be enabled only in the case of host mode. So stop
doing always_on, boot_on from smps10_out1. The driver will enable it in host
mode.
Signed-off-by: Kishon Vijay Abraham
On Fri, Oct 11, 2013 at 1:13 AM, Kishon Vijay Abraham I kis...@ti.com wrote:
regulator-boot-on indicates that PMIC enables it by default as part of
OTP or some internal behavior - Looking at the measurements done on
uEVM and OTP information - regulator-boot-on should be kept here.
No.
Hi,
On Friday 11 October 2013 12:00 PM, Nishanth Menon wrote:
On Fri, Oct 11, 2013 at 1:13 AM, Kishon Vijay Abraham I kis...@ti.com wrote:
regulator-boot-on indicates that PMIC enables it by default as part of
OTP or some internal behavior - Looking at the measurements done on
uEVM and OTP
On Friday 11 October 2013 12:23 PM, Kishon Vijay Abraham I wrote:
Hi,
On Friday 11 October 2013 12:00 PM, Nishanth Menon wrote:
On Fri, Oct 11, 2013 at 1:13 AM, Kishon Vijay Abraham I kis...@ti.com
wrote:
regulator-boot-on indicates that PMIC enables it by default as part of
OTP or some
On 10/11/2013 06:41 AM, Tomi Valkeinen wrote:
On 10/10/13 21:58, Lars-Peter Clausen wrote:
According to the datasheet the the panel as a dedicated dout pin. Maybe
you did not connect it in your design, which means you won't be able to
read any data from the panel at all.
I don't see a
On Fri, Oct 11, 2013 at 1:54 AM, Kishon Vijay Abraham I kis...@ti.com wrote:
On Friday 11 October 2013 12:23 PM, Kishon Vijay Abraham I wrote:
Hi,
On Friday 11 October 2013 12:00 PM, Nishanth Menon wrote:
On Fri, Oct 11, 2013 at 1:13 AM, Kishon Vijay Abraham I kis...@ti.com
wrote:
Hi all,
Am 11.10.2013 um 06:41 schrieb Tomi Valkeinen:
On 10/10/13 21:58, Lars-Peter Clausen wrote:
According to the datasheet the the panel as a dedicated dout pin. Maybe
you did not connect it in your design, which means you won't be able to
read any data from the panel at all.
I
Hi Lars-Peter,
ah, I didn't see your mail while writing mine - so some overlap.
Am 11.10.2013 um 09:08 schrieb Lars-Peter Clausen:
On 10/11/2013 06:41 AM, Tomi Valkeinen wrote:
On 10/10/13 21:58, Lars-Peter Clausen wrote:
According to the datasheet the the panel as a dedicated dout pin.
On 10/09/2013 04:29 PM, Archit Taneja wrote:
VPE is a block which consists of a single memory to memory path which can
perform chrominance up/down sampling, de-interlacing, scaling, and color space
conversion of raster or tiled YUV420 coplanar, YUV422 coplanar or YUV422
interleaved video
On Thu, Oct 10, 2013 at 6:20 PM, Tony Lindgren t...@atomide.com wrote:
* Linus Walleij linus.wall...@linaro.org [131010 09:19]:
On Thu, Oct 10, 2013 at 6:00 PM, Tony Lindgren t...@atomide.com wrote:
* Roger Quadros rog...@ti.com [131010 06:32]:
I tried testing this with the USB EHCI
On 11/10/13 10:42, Dr. H. Nikolaus Schaller wrote:
I am not sure if there is a SPI driver for a McBSP port [1]? And to make that
work (reliably) and tested it might need a lot of work for us. At least I
think
such a change (e.g. setting up clock polarity etc.) is not done in some
minutes.
On 10/10/2013 07:23 PM, Tony Lindgren wrote:
* Tony Lindgren t...@atomide.com [131010 09:09]:
* Roger Quadros rog...@ti.com [131010 06:32]:
I tried testing this with the USB EHCI driver, but I'm not getting wake up
interrupts
while the system is still running and only the EHCI controller is
On 10/10/2013 07:00 PM, Tony Lindgren wrote:
* Roger Quadros rog...@ti.com [131010 06:32]:
I tried testing this with the USB EHCI driver, but I'm not getting wake up
interrupts
while the system is still running and only the EHCI controller is runtime
suspended.
It seems we need to
On 10/11/2013 11:00 AM, Linus Walleij wrote:
On Thu, Oct 10, 2013 at 6:20 PM, Tony Lindgren t...@atomide.com wrote:
* Linus Walleij linus.wall...@linaro.org [131010 09:19]:
On Thu, Oct 10, 2013 at 6:00 PM, Tony Lindgren t...@atomide.com wrote:
* Roger Quadros rog...@ti.com [131010 06:32]:
I
Hi Tomi,
On Fri, Oct 11, 2013 at 10:17 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On 11/10/13 10:42, Dr. H. Nikolaus Schaller wrote:
I am not sure if there is a SPI driver for a McBSP port [1]? And to make that
work (reliably) and tested it might need a lot of work for us. At least I
On 10/11/2013 10:59 AM, Belisko Marek wrote:
Hi Tomi,
On Fri, Oct 11, 2013 at 10:17 AM, Tomi Valkeinen tomi.valkei...@ti.com
wrote:
On 11/10/13 10:42, Dr. H. Nikolaus Schaller wrote:
I am not sure if there is a SPI driver for a McBSP port [1]? And to make
that
work (reliably) and
On 11/10/13 11:59, Belisko Marek wrote:
That's why I won't allow representing this panel as having 4 gpios in
the DT data, because that is not correct. The panel has 3 pins. But
then, the panel does allow reading, which could be implemented using 4
gpios as you have done. This data should be
Hi all,
Am 11.10.2013 um 11:06 schrieb Lars-Peter Clausen:
On 10/11/2013 10:59 AM, Belisko Marek wrote:
Hi Tomi,
On Fri, Oct 11, 2013 at 10:17 AM, Tomi Valkeinen tomi.valkei...@ti.com
wrote:
On 11/10/13 10:42, Dr. H. Nikolaus Schaller wrote:
I am not sure if there is a SPI driver for
On 11/10/13 12:50, Dr. H. Nikolaus Schaller wrote:
Hm. Is this a SPI or does it just look like one? Or is it some - otherwise
unknown - 3 wire serial interface. Or is it a 3(+1) GPIO slave device?
I am still not sure about this.
Lars-Peter said Back in the OpenMoko days we used the panel in
Dear MTD Maintainers,
If I have my NAND formatted with one of the existing ECC schemes (e.g.
OMAP_ECC_HAMMING_CODE_DEFAULT) will it work with the new
OMAP_ECC_HAM1_CODE_HW scheme?
Are they all compatible?
Yes, they all are 1-bit hamming code, the only difference between
xx_Default
On Fri, Oct 11, 2013 at 10:56 AM, Roger Quadros rog...@ti.com wrote:
The register handling is fine. But how do we deal with resource handling?
e.g. the block that has the deep-core registers might need to be clocked or
powered
before the registers can be accessed.
Yeah I saw this in the
Hi Tomi,
Am 11.10.2013 um 12:09 schrieb Tomi Valkeinen:
On 11/10/13 12:50, Dr. H. Nikolaus Schaller wrote:
Hm. Is this a SPI or does it just look like one? Or is it some - otherwise
unknown - 3 wire serial interface. Or is it a 3(+1) GPIO slave device?
I am still not sure about this.
Hi Pekon,
On Fri, Oct 11, 2013 at 05:17:48AM -0500, Gupta, Pekon wrote:
If I have my NAND formatted with one of the existing ECC schemes (e.g.
OMAP_ECC_HAMMING_CODE_DEFAULT) will it work with the new
OMAP_ECC_HAM1_CODE_HW scheme?
Are they all compatible?
Yes, they all are
*Changes v7 - v8*
[PATCH 1/6] no updates
[PATCH 2/6]
- updated DT parsing of ti,nand-ecc-opts so that its ham1 remains
compatible to sw,hw,hw-romcode
- updated DT parsing of ti,elm-id to retain compatibility to elm_id
- using of_parse_phandle() to get ELM
OMAP NAND driver currently supports multiple flavours of 1-bit Hamming
ecc-scheme, like:
- OMAP_ECC_HAMMING_CODE_DEFAULT
1-bit hamming ecc code using software library
- OMAP_ECC_HAMMING_CODE_HW
1-bit hamming ecc-code using GPMC h/w engine
- OMAP_ECC_HAMMING_CODE_HW_ROMCODE
OMAP NAND driver support multiple ECC scheme, which can used in following
different flavours, depending on in-build Hardware engines supported by SoC.
+---+---+---+
| ECC scheme|ECC calculation|Error
OMAP NAND driver support multiple ECC scheme, which can used in following
different flavours, depending on in-build Hardware engines supported by SoC.
+---+---+---+
| ECC scheme|ECC calculation|Error
This patch adds following two flavours of BCH4 ECC scheme in omap2-nand driver
- OMAP_ECC_BCH4_CODE_HW_DETECTION_SW
- uses GPMC H/W engine for calculating ECC.
- uses software library (lib/bch.h nand_bch.h) for error correction.
- OMAP_ECC_BCH4_CODE_HW
- uses GPMC H/W
Updated DTS to replace deprecated binding with newer values
Refer: Documentation/devicetree/bindings/mtd/gpmc-nand.txt
Signed-off-by: Pekon Gupta pe...@ti.com
---
arch/arm/boot/dts/am335x-evm.dts | 3 +--
arch/arm/boot/dts/omap3430-sdp.dts | 2 +-
2 files changed, 2 insertions(+), 3
Managed Device Resource or devm_xx calls takes care of automatic freeing
of the resource in case of:
- failure during driver probe
- failure during resource allocation
- detaching or unloading of driver module (rmmod)
Reference: Documentation/driver-model/devres.txt
Though OMAP NAND driver
On 10/11/2013 11:49 AM, Roger Quadros wrote:
On 10/10/2013 07:00 PM, Tony Lindgren wrote:
* Roger Quadros rog...@ti.com [131010 06:32]:
I tried testing this with the USB EHCI driver, but I'm not getting wake up
interrupts
while the system is still running and only the EHCI controller is
Hi,
On 10/10/2013 01:49 PM, Kishon Vijay Abraham I wrote:
From: George Cherian george.cher...@ti.com
Added dr_mode property in dwc3 and set its default mode to device.
If there is a specific reason why this is not set to otg, we need
to explain it here.
AFAIK the port is meant to be used as
On 09/16/2013 10:37 AM, Roger Quadros wrote:
On 09/16/2013 06:01 AM, Kishon Vijay Abraham I wrote:
On Thursday 12 September 2013 04:49 PM, Roger Quadros wrote:
Hi Kishon,
On 09/02/2013 06:43 PM, Kishon Vijay Abraham I wrote:
Adapted omap-usb3 PHY driver to Generic PHY Framework and moved
Hi,
On 09/02/2013 06:43 PM, Kishon Vijay Abraham I wrote:
Adapted dwc3 core to use the Generic PHY Framework. So for init, exit,
power_on and power_off the following APIs are used phy_init(), phy_exit(),
phy_power_on() and phy_power_off().
However using the old USB phy library wont be
* Roger Quadros rog...@ti.com [131011 07:07]:
On 10/11/2013 11:49 AM, Roger Quadros wrote:
On 10/10/2013 07:00 PM, Tony Lindgren wrote:
Well the irq_set_wake() should only be needed for suspend and resume. For
runtime PM
the wake-events should be always enabled by default as pointed
* Roger Quadros rog...@ti.com [131011 02:04]:
On 10/11/2013 11:00 AM, Linus Walleij wrote:
On Thu, Oct 10, 2013 at 6:20 PM, Tony Lindgren t...@atomide.com wrote:
* Linus Walleij linus.wall...@linaro.org [131010 09:19]:
On Thu, Oct 10, 2013 at 6:00 PM, Tony Lindgren t...@atomide.com wrote:
On Friday 11 October 2013 09:06 PM, Tony Lindgren wrote:
What the pin control driver should do is control the pins. Whether the registers
are spread out in the entire IO-memory does not matter. We did have one system
which placed the IO-muxing together with each peripheral (!) and I did
still
* Linus Walleij linus.wall...@linaro.org [131011 03:40]:
On Fri, Oct 11, 2013 at 10:56 AM, Roger Quadros rog...@ti.com wrote:
The register handling is fine. But how do we deal with resource handling?
e.g. the block that has the deep-core registers might need to be clocked or
powered
* Balaji T K balaj...@ti.com [131011 08:51]:
On Friday 11 October 2013 09:06 PM, Tony Lindgren wrote:
What the pin control driver should do is control the pins. Whether the
registers
are spread out in the entire IO-memory does not matter. We did have one
system
which placed the IO-muxing
On Fri, Oct 11, 2013 at 07:06:42PM +0530, Pekon Gupta wrote:
Updated DTS to replace deprecated binding with newer values
Refer: Documentation/devicetree/bindings/mtd/gpmc-nand.txt
Signed-off-by: Pekon Gupta pe...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
---
On Fri, Oct 11, 2013 at 07:06:39PM +0530, Pekon Gupta wrote:
OMAP NAND driver support multiple ECC scheme, which can used in following
different flavours, depending on in-build Hardware engines supported by SoC.
+---+---+---+
| ECC
On Fri, Oct 11, 2013 at 07:06:41PM +0530, Pekon Gupta wrote:
This patch adds following two flavours of BCH4 ECC scheme in omap2-nand driver
- OMAP_ECC_BCH4_CODE_HW_DETECTION_SW
- uses GPMC H/W engine for calculating ECC.
- uses software library (lib/bch.h nand_bch.h) for error
On Fri, Oct 11, 2013 at 07:06:40PM +0530, Pekon Gupta wrote:
OMAP NAND driver support multiple ECC scheme, which can used in following
different flavours, depending on in-build Hardware engines supported by SoC.
+---+---+---+
| ECC
On Fri, Oct 11, 2013 at 07:06:38PM +0530, Pekon Gupta wrote:
OMAP NAND driver currently supports multiple flavours of 1-bit Hamming
ecc-scheme, like:
- OMAP_ECC_HAMMING_CODE_DEFAULT
1-bit hamming ecc code using software library
- OMAP_ECC_HAMMING_CODE_HW
1-bit hamming ecc-code
On Fri, Oct 11, 2013 at 07:06:43PM +0530, Pekon Gupta wrote:
Managed Device Resource or devm_xx calls takes care of automatic freeing
of the resource in case of:
- failure during driver probe
- failure during resource allocation
- detaching or unloading of driver module (rmmod)
Reference:
On Fri, Oct 11, 2013 at 5:43 PM, Tony Lindgren t...@atomide.com wrote:
* Linus Walleij linus.wall...@linaro.org [131011 03:40]:
On Fri, Oct 11, 2013 at 10:56 AM, Roger Quadros rog...@ti.com wrote:
The register handling is fine. But how do we deal with resource handling?
e.g. the block that
* Tony Lindgren t...@atomide.com [131010 17:52]:
* Mugunthan V N mugunthan...@ti.com [131010 17:15]:
On Thursday 10 October 2013 06:04 PM, Tony Lindgren wrote:
-CONFIG_TI_DAVINCI_MDIO=y
-CONFIG_TI_DAVINCI_CPDMA=y
-CONFIG_TI_CPSW=y
-CONFIG_AT803X_PHY=y
Can you keep the above
* Linus Walleij linus.wall...@linaro.org [131011 09:05]:
On Fri, Oct 11, 2013 at 5:43 PM, Tony Lindgren t...@atomide.com wrote:
* Linus Walleij linus.wall...@linaro.org [131011 03:40]:
On Fri, Oct 11, 2013 at 10:56 AM, Roger Quadros rog...@ti.com wrote:
The register handling is fine. But
* Joel Fernandes jo...@ti.com [131010 08:31]:
On 10/10/2013 10:20 AM, Joel Fernandes wrote:
Adding 6 lines of identical code for every platform seems redundant, I'd
just
define an omap_common_late_init for all platforms for now, and then fork
off for
the future differences. That
On OMAPs the IO ring must be rearmed each time the pad wakeup
configuration is changed. So call pcs_soc-rearm() from
pcs_irq_set().
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/pinctrl/pinctrl-single.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git
OMAP3 PM code needs this functionality during the IVA2 reset, but is currently
using direct CM register accesses for this purpose. Implement a new API so
the PM code can use this instead.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/cm3xxx.c |6 ++
OMAP3 PM core requires IVA2 bootmode to be set to idle during init. Currently,
a direct register write is used for this. Add a new ctrl API for this purpose
instead.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/control.c | 11 +++
arch/arm/mach-omap2/control.h |
Users of the CM funtionality should not access the CM registers directly
by themselves. Thus, added new CM driver APIs for the OMAP2 specific
functionalities which support the existing direct register accesses, and
changed the platform code to use these. This is done in preparation
for moving the
OMAP3 PM code directly writes to CM register space to enable/disable IVA2
clock during boot during the IVA2 reset. Direct access shall be avoided,
thus implement an API call for this, and change the PM core to use this.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/cm3xxx.c
Hi,
A small cleanup set for CM. This basically gets rid of the omap2_cm_*
register accesses from the random code locations, and gathers these
under cm2xxx.c and cm3xxx.c. This is done in preparation for creating
a separate CM driver. The set also contains a couple of PRM cleanups
which I decided
McBSP driver require special hacks to enable/disable the autoidle feature
for its interface clock for the proper function of the sidetone hardware.
Currently the driver just writes CM registers directly, which should be
avoided. Thus, changed the driver to use the new deny/allow_autoidle
clock API
Some drivers require direct access to the autoidle functionality of the
interface clocks. Added clock APIs for these, so that the drivers do not
need to access CM registers directly.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/clock.c | 38
OMAP3 PM code for off-mode currently saves the scratchpad contents for CM
registers within OMAP control module driver. However, as we are separating
CM code into its own driver, this must be moved also. This patch adds a
new API for saving the CM scratchpad contents and uses this from the high
PRCM chain handler needs these to properly acknowledge wakeup events.
Currently this functionality is implemented as direct register accesses,
but as the CM code should eventually move to its own driver, separate
API calls are now added for this purpose. PM core code is also changed
to use these
PM core code should not directly access PRM registers. Thus move the
PRCM interrupt handler helper out of the core PM code to PRM driver,
and use the new API from the core.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/pm34xx.c | 65 ++---
The direct register access macros should not be exposed to CM clients.
Thus, move the register macros to their own file and only include these
to the cm_*.c files.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/cm2xxx.c |1 +
arch/arm/mach-omap2/cm2xxx_3xxx.h | 48
This is correct location for this instead of the PM core, as it is accessing
PRM registers directly.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/pm34xx.c | 48 +
arch/arm/mach-omap2/prm3xxx.c | 45
On Fri, Oct 11, 2013 at 6:13 PM, Roger Quadros rog...@ti.com wrote:
On OMAPs the IO ring must be rearmed each time the pad wakeup
configuration is changed. So call pcs_soc-rearm() from
pcs_irq_set().
Signed-off-by: Roger Quadros rog...@ti.com
If Tony needs to apply this with the other
Hi Tony,
Please pull the following commits for OMAP Device Tree for v3.13.
Thanks,
Benoit
The following changes since commit d0e639c9e06d44e713170031fe05fb60ebe680af:
Linux 3.12-rc4 (2013-10-06 14:00:20 -0700)
are available in the git repository at:
On Thursday 10 October 2013 12:21 AM, Sekhar Nori wrote:
On Monday 07 October 2013 09:55 PM, Balaji T K wrote:
Add mmc1 dt node to dra7-evm board.
Input for ldo1 regulator is controlled by gpio 5 of pcf8575 chip (0x21)
on i2c1 bus. When dt support for gpio-pcf857x is available, input supply
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Tony,
The following changes since commit d0e639c9e06d44e713170031fe05fb60ebe680af:
Linux 3.12-rc4 (2013-10-06 14:00:20 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git
* Roger Quadros rog...@ti.com [131011 09:21]:
On OMAPs the IO ring must be rearmed each time the pad wakeup
configuration is changed. So call pcs_soc-rearm() from
pcs_irq_set().
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/pinctrl/pinctrl-single.c |5 +++--
1 files changed,
* Linus Walleij linus.wall...@linaro.org [131011 09:27]:
On Fri, Oct 11, 2013 at 6:13 PM, Roger Quadros rog...@ti.com wrote:
On OMAPs the IO ring must be rearmed each time the pad wakeup
configuration is changed. So call pcs_soc-rearm() from
pcs_irq_set().
Signed-off-by: Roger Quadros
On Thu, 10 Oct 2013, Tero Kristo wrote:
On 10/09/2013 09:59 PM, Paul Walmsley wrote:
Eh, one correction:
On Wed, 9 Oct 2013, Paul Walmsley wrote:
We could easily wind up with kernels that won't boot at all when used
with newer DT data.
This is a misstatement of the issue:
Hi Benoit,
* Benoit Cousson bcous...@baylibre.com [131011 09:50]:
Add the minimal DTS support for DRA7xx based SoC core.
Add the initial support for N900 and gta04 phones.
Enable USB3 on OMAP5 evm board.
Add support for cryto accelerators
Add new IGEP AQUILA board
Add AM33XX EDMA support
Hi Pekon,
On Fri, Oct 11, 2013 at 07:06:43PM +0530, Pekon Gupta wrote:
Managed Device Resource or devm_xx calls takes care of automatic freeing
of the resource in case of:
- failure during driver probe
- failure during resource allocation
- detaching or unloading of driver module (rmmod)
On 10/11/2013 08:54 PM, Paul Walmsley wrote:
On Thu, 10 Oct 2013, Tero Kristo wrote:
On 10/09/2013 09:59 PM, Paul Walmsley wrote:
Eh, one correction:
On Wed, 9 Oct 2013, Paul Walmsley wrote:
We could easily wind up with kernels that won't boot at all when used
with newer DT data.
This is
* Brian Norris computersforpe...@gmail.com [131011 11:23]:
Hi Pekon,
On Fri, Oct 11, 2013 at 07:06:43PM +0530, Pekon Gupta wrote:
Managed Device Resource or devm_xx calls takes care of automatic freeing
of the resource in case of:
- failure during driver probe
- failure during resource
* Felipe Balbi ba...@ti.com [131011 09:03]:
On Fri, Oct 11, 2013 at 07:06:39PM +0530, Pekon Gupta wrote:
OMAP NAND driver support multiple ECC scheme, which can used in following
different flavours, depending on in-build Hardware engines supported by SoC.
* Felipe Balbi ba...@ti.com [131011 09:04]:
On Fri, Oct 11, 2013 at 07:06:38PM +0530, Pekon Gupta wrote:
OMAP NAND driver currently supports multiple flavours of 1-bit Hamming
ecc-scheme, like:
- OMAP_ECC_HAMMING_CODE_DEFAULT
1-bit hamming ecc code using software library
-
On 10/11/2013 08:54 PM, Paul Walmsley wrote:
On Thu, 10 Oct 2013, Tero Kristo wrote:
On 10/09/2013 09:59 PM, Paul Walmsley wrote:
Eh, one correction:
On Wed, 9 Oct 2013, Paul Walmsley wrote:
We could easily wind up with kernels that won't boot at all when used
with newer DT data.
This is
Hi Tony,
On 11/10/2013 20:03, Tony Lindgren wrote:
Hi Benoit,
* Benoit Cousson bcous...@baylibre.com [131011 09:50]:
Add the minimal DTS support for DRA7xx based SoC core.
Add the initial support for N900 and gta04 phones.
Enable USB3 on OMAP5 evm board.
Add support for cryto accelerators
Add
Hi Balaji,
On 11/10/2013 18:44, Balaji T K wrote:
On Thursday 10 October 2013 12:21 AM, Sekhar Nori wrote:
On Monday 07 October 2013 09:55 PM, Balaji T K wrote:
Add mmc1 dt node to dra7-evm board.
Input for ldo1 regulator is controlled by gpio 5 of pcf8575 chip (0x21)
on i2c1 bus. When dt
Hi Tony,
Please pull the updated branch for OMAP Device Tree for v3.13.
I removed the 2 conflicting patches, and added 2 mores for dra7 to compensate
:-)
Thanks,
Benoit
The following changes since commit d0e639c9e06d44e713170031fe05fb60ebe680af:
Linux 3.12-rc4 (2013-10-06 14:00:20 -0700)
On Fri, Oct 11, 2013 at 11:28 AM, Tony Lindgren t...@atomide.com wrote:
* Brian Norris computersforpe...@gmail.com [131011 11:23]:
Hi Pekon,
On Fri, Oct 11, 2013 at 07:06:43PM +0530, Pekon Gupta wrote:
Managed Device Resource or devm_xx calls takes care of automatic freeing
of the resource
On Fri, Oct 11, 2013 at 07:06:40PM +0530, Pekon Gupta wrote:
OMAP NAND driver support multiple ECC scheme, which can used in following
different flavours, depending on in-build Hardware engines supported by SoC.
+---+---+---+
| ECC
Hi Sricharan,
On 10/10/2013 15:11, Santosh Shilimkar wrote:
On Thursday 10 October 2013 03:50 AM, Sricharan R wrote:
The arm arch timers frequency are now programmed in the CNTFREQ
per-cpu register by the timer code using the secure API [1].
So remove the redundant entry from the dts.
[1]
On Fri, Oct 11, 2013 at 07:06:41PM +0530, Pekon Gupta wrote:
This patch adds following two flavours of BCH4 ECC scheme in omap2-nand driver
- OMAP_ECC_BCH4_CODE_HW_DETECTION_SW
- uses GPMC H/W engine for calculating ECC.
- uses software library (lib/bch.h nand_bch.h) for error
Hi Pekon,
I will try to summarize the standing of your patch series.
Patches 1 and 2 look good and have addressed all of the DT maintainers'
comments, AFAICT. They are ready to go in, except that the following
patches are not ready; they should probably go in together.
You ignored most of my
* Benoit Cousson bcous...@baylibre.com [131011 12:13]:
Hi Tony,
On 11/10/2013 20:03, Tony Lindgren wrote:
Hi Benoit,
* Benoit Cousson bcous...@baylibre.com [131011 09:50]:
Add the minimal DTS support for DRA7xx based SoC core.
Add the initial support for N900 and gta04 phones.
Enable
* Brian Norris computersforpe...@gmail.com [131011 12:35]:
On Fri, Oct 11, 2013 at 11:28 AM, Tony Lindgren t...@atomide.com wrote:
FYI, the .dts changes should be queued separately by Benoit to avoid
pointless merge conflicts. The arch/arm/mach-omap2/gpmc.c changes I
need to look,
On Fri, Oct 11, 2013 at 2:46 PM, Tony Lindgren t...@atomide.com wrote:
* Brian Norris computersforpe...@gmail.com [131011 12:35]:
On Fri, Oct 11, 2013 at 11:28 AM, Tony Lindgren t...@atomide.com wrote:
FYI, the .dts changes should be queued separately by Benoit to avoid
pointless merge
On Fri, 11 Oct 2013, Tero Kristo wrote:
Well, even if you sign something, you can still update it. Writing any
software to true OTP memory is one way to commit suicide IMO. How many nasty
bugs have you seen with ROM code? Also, if people want to make their custom
security solutions which are
* Paul Walmsley p...@pwsan.com [131011 10:08]:
Hi Tony,
The following changes since commit d0e639c9e06d44e713170031fe05fb60ebe680af:
Linux 3.12-rc4 (2013-10-06 14:00:20 -0700)
are available in the git repository at:
On Fri, 11 Oct 2013, Tony Lindgren wrote:
* Paul Walmsley p...@pwsan.com [131011 10:08]:
Basic test logs are available at:
http://www.pwsan.com/omap/testlogs/prcm_fixes_v3.13/20131009094936/
The summary reports that the 4460varsomom boots are failing, but this looks
incorrect -
On Fri, 11 Oct 2013, Tero Kristo wrote:
Oh yea, one additional note you probably have missed. Mike asked us to fall
back to vendor specific bindings at around v6 or so of this set. Take a look
at v8, we have dropped the use of generic bindings, we are not trying to
declare those with this
* Paul Walmsley p...@pwsan.com [131011 15:38]:
On Fri, 11 Oct 2013, Tony Lindgren wrote:
* Paul Walmsley p...@pwsan.com [131011 10:08]:
Basic test logs are available at:
http://www.pwsan.com/omap/testlogs/prcm_fixes_v3.13/20131009094936/
The summary reports that the
* Tero Kristo t-kri...@ti.com [131010 01:25]:
On 10/09/2013 09:55 PM, Paul Walmsley wrote:
So in my view, the right things to do here are to:
1. associate SoC DT clock data with the device node that contains the
clock control registers
So, either cm, prcm, and maybe control_module
* Sebastian Reichel s...@debian.org [131009 14:25]:
Add device tree support for twl4030 keypad driver and update the
Documentation with twl4030 keypad device tree binding information.
This patch also adds a twl4030 keypad node to the twl4030.dtsi file,
so that board files can just add the
* Sebastian Reichel s...@debian.org [131009 14:26]:
Add Keyboard Matrix information to N900's DTS file.
This patch maps the keys exactly as the original
board code.
This should be queued by Benoit along with other .dts
changes, not via the input tree:
Acked-by: Tony Lindgren t...@atomide.com
* Suman Anna s-a...@ti.com [131010 14:24]:
Add the hwspinlock device tree node for OMAP4 family
of SoCs.
Suman, can you please post the .dts changes separately from
the driver changes next time so driver maintainers don't
accidentally pick them up. That leads to unnecessary merge
conflicts with
* Tero Kristo t-kri...@ti.com [131011 09:24]:
If someone could verify the omap2 changes, that would be nice.
Seems to boot on my n800 just fine, dmesg below.
Tony
[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 3.12.0-rc4-00050-gf44928c (tmlind@muffinssi) (gcc
* Tony Lindgren t...@atomide.com [131011 17:18]:
* Tero Kristo t-kri...@ti.com [131011 09:24]:
If someone could verify the omap2 changes, that would be nice.
Seems to boot on my n800 just fine, dmesg below.
Sorry that was the log without these patches, still boots
fine with the patches
* Tony Lindgren t...@atomide.com [131010 10:23]:
* Santosh Shilimkar santosh.shilim...@ti.com [131010 06:20]:
On Thursday 10 October 2013 03:43 AM, Sricharan R wrote:
From: R Sricharan r.sricha...@ti.com
The realtime counter called master counter, produces the count
used by the
On Friday 11 October 2013 08:34 PM, Tony Lindgren wrote:
* Tony Lindgren t...@atomide.com [131010 10:23]:
* Santosh Shilimkar santosh.shilim...@ti.com [131010 06:20]:
On Thursday 10 October 2013 03:43 AM, Sricharan R wrote:
From: R Sricharan r.sricha...@ti.com
The realtime counter called
1 - 100 of 102 matches
Mail list logo
