Hi,
diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
index df338cb..958e5d5 100644
--- a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
@@ -21,11 +21,8
Anyway, at this point I think your patch series should be nearly
complete. I made a few comments on your patches, and I'd imagine you
only should need one more revision (v7) before I can accept it to the
l2-mtd.git tree.
Yes surely I will send next version (v7), but it might take few
Hi Rob,
On Wed, Sep 25, 2013 at 3:13 AM, Rob Landley r...@landley.net wrote:
Some of us can't ship GPLv3 binaries and are looking forward to the day LLVM
or some such provides a complete solution.
Sorry, I didn't have a coffee yet, but which subtility am I missing
that prohibits
you from
On 25/09/13 19:11, Dr. H. Nikolaus Schaller wrote:
Hm. I a not sure if this model is complete if it ends at the physical
connector.
But that would be a different topic.
Yes, we currently model the components that exist on the board. I've
toyed with the idea of hotplugging a monitor entity
2013/9/26 Tony Lindgren t...@atomide.com:
There have been various patches floating around for enabling
the SDIO IRQ for hsmmc, but none of them ever got merged.
Probably the reason for not merging the SDIO interrupt patches
has been the lack of wake-up path for SDIO on some omaps that
has
* Daniel Mack | 2013-09-22 16:50:03 [+0200]:
cdd-cd and cdd-descs_phys are allocated DESCS_AREAS times from
init_descs() and freed as often from purge_descs(). This leads to both
memory leaks and double-frees.
Fix this by pulling the calls to dma_{alloc,free}_coherent() out of the
loops.
While
On 25/09/13 14:31, Mark Brown wrote:
From: Mark Brown broo...@linaro.org
The DSI-CM driver uses the backlight class so needs to build depend on it.
Signed-off-by: Mark Brown broo...@linaro.org
---
drivers/video/omap2/displays-new/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff
On Wed, Sep 25, 2013 at 10:29:03PM +0100, Brian Norris wrote:
On Wed, Sep 25, 2013 at 01:33:27PM -0700, Olof Johansson wrote:
On Wed, Sep 25, 2013 at 1:05 PM, Brian Norris
computersforpe...@gmail.com wrote:
Olof has given good advice on your DT binding and has (slowly) been
Hi Paul, Benoit, Tony,
This series adds PRCM support (except clock tree) for AM43x SoC's.
Current version is based on Rajendra's comments and discussions, please
consider this for inclusion in the coming merge window.
Major changes compared to v2 (v3 was only an rfc for current approach):
1.
From: Ankur Kishore a-kish...@ti.com
Most of the AM43x CM reg address offsets are with MSB bit '1' (on
16-bit value) leading to arithmetic miscalculations while calculating
CLOCK ENABLE register's address because cm_inst field was a type of
const s16, so make it const u16.
Also modify relevant
Most of IP's in AM335x is present on AM43x and so in those cases both
will use same hwmod database (except for a few cases where clock related
details differ), but there is difference w.r.t register offset between
these. Update register offsets at runtime based on the SoC detected to
help in
Hi Mark,
Pekon, could you please re-send this version of the patches?
As already there are feedbacks on the patches, so re-sending the
Patch series might clutter someone else's mailbox.
Will it be possible for you to fetch the patches from MTD archives?
else I would send you the patches
Hwmod common to AM43x and AM335x has register offsets different. It is
now updated based on SoC detection at run time, hence remove statically
initialized ones.
Signed-off-by: Afzal Mohammed af...@ti.com
---
.../mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c | 57 --
1 file
Add AM43x CMINST, CDOFFS, RM_RSTST RM_RSTCTRL definitions - minimal
ones that would be used.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/prcm43xx.h | 141 +
1 file changed, 141 insertions(+)
create mode 100644
From: Ambresh K ambr...@ti.com
Add the data file to describe clock domains in AM43x SoC.
OMAP4 clockdomain operations is being reused here.
Signed-off-by: Ambresh K ambr...@ti.com
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/clockdomain.h | 2 +
From: Ambresh K ambr...@ti.com
Add the data file to describe all power domains in AM43x SoC.
OMAP4 powerdomain operations is being reused here.
Signed-off-by: Ambresh K ambr...@ti.com
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/powerdomain.h | 1 +
Reuse OMAP4 operations on AM43x.
Context related ops are not used on AM43x, as this would not add value
when using DT and AM43x is DT only boot. This additionally helps not to
add context register offset for each hwmod.
Signed-off-by: Ambresh K ambr...@ti.com
Signed-off-by: Afzal Mohammed
Add hwmod support for IP's that are present in AM43x, but not in AM335x.
AM43x additional ones added here are,
1. synctimer
2. timer8-11
3. ehrpwm3-5
4. spi2-4
5. gpio4-5
AM43x pruss interconnect which is different as compared to AM335x, has
been taken care.
And register offsets for same hwmod's
Build AM43x power domain, clock domain and hwmod data.
Many of AM43x IP's and interconnects are similar as that in AM335x,
hence AM335x hwmod data is being reused with necessary changes.
Earlier the plan was to reuse AM335x specific PRCM code, but as AM43x
PRCM register layout is much similar to
From: Ambresh K ambr...@ti.com
Initialise AM43x HWMOD, powerdomains and clockdomains.
Signed-off-by: Ambresh K ambr...@ti.com
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/io.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/mach-omap2/io.c
Hi Joel,
On 26/09/2013 00:01, Joel Fernandes wrote:
Following series is a collection of dts patches for the below features:
crypto:
aes, sha on am335x
aes, des on am437x
aes, des on omap4
display:
beaglebone black HDMI
am335x-evm panel
Series is based on Benoit Cousson's
On 26/09/2013 00:01, Joel Fernandes wrote:
OMAP4 has an AES module that uses the omap-aes crypto driver.
Add DT entries for the same.
Signed-off-by: Joel Fernandes jo...@ti.com
---
arch/arm/boot/dts/omap4.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git
On Mon, Sep 23, 2013 at 08:31:48PM +0100, Felipe Balbi wrote:
Hi,
On Tue, Aug 20, 2013 at 12:56:03PM +0300, Ivan T. Ivanov wrote:
From: Ivan T. Ivanov iiva...@mm-sol.com
MSM USB3.0 core wrapper consist of USB3.0 IP from Synopsys
(SNPS) and HS, SS PHY's control and configuration
On Thu, Sep 26, 2013 at 11:36:26AM +0300, Tomi Valkeinen wrote:
I wish we could select instead of depends on...
We probably could.
signature.asc
Description: Digital signature
On 26/09/13 13:12, Mark Brown wrote:
On Thu, Sep 26, 2013 at 11:36:26AM +0300, Tomi Valkeinen wrote:
I wish we could select instead of depends on...
We probably could.
I'm not so sure.
If we select BACKLIGHT_CLASS_DEVICE, we could end up compiling
backlight.c without fbdev, and
Hi,
It seems,
[PATCH v4 02/11] ARM: OMAP2+: hwmod: AM335x/AM43x: move common data
is held on LAKML for moderator approval due to big size.
I will wait for some time to see if moderator approves, if not, will
ping him (believe it is David Woodhouse), but not sure how to get it
into omap list
From: Rob Herring [mailto:robherri...@gmail.com]
From: Pekon Gupta [mailto:pe...@ti.com]
diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
index df338cb..958e5d5 100644
---
Hi,
On Friday 20 September 2013 04:41 AM, Russell King wrote:
The correct way for a driver to specify the coherent DMA mask is
not to directly access the field in the struct device, but to use
dma_set_coherent_mask(). Only arch and bus code should access this
member directly.
Convert all
*Changes v5 - v6*
[PATCH 1/4]:
- updated DT binding for gpmc-nand based on 'Olof Johansson's
feedbacks
http://lists.infradead.org/pipermail/linux-mtd/2013-
August/048394.html
- detection of ELM device via ti,elm-id DT node, moved to gpmc.c
driver
[PATCH 2/4]
-
From: Brian Norris [mailto:computersforpe...@gmail.com]
On Thu, Sep 12, 2013 at 05:20:19PM +0530, Pekon Gupta wrote:
DT property values for OMAP based gpmc-nand have been updated
to match changes in commit:
6faf096 ARM: OMAP2+: cleaned-up DT support of various ECC
schemes
Whose
On 26/09/13 14:01, Dr. H. Nikolaus Schaller wrote:
So this essentially means that the invert property and the bypass, acen
properties
should be defined for the VENC (if it also controls the DAC-Stage).
I.e. I am not sure if invert is really a property (control) of the connector
or an
Am 26.09.2013 um 13:49 schrieb Tomi Valkeinen:
On 26/09/13 14:01, Dr. H. Nikolaus Schaller wrote:
So this essentially means that the invert property and the bypass,
acen properties
should be defined for the VENC (if it also controls the DAC-Stage).
I.e. I am not sure if invert is
On 26/09/13 15:37, Dr. H. Nikolaus Schaller wrote:
Although one could argue that one is just controlling the GPIO and the other
one is controlling some regulator...
Sorry, didn't understand that one...
I meant that there could be a differece between enable/disable and
power-on/off
(e.g.
musb_port_reset() sleeps, so we can't call it from atomic context. It
is, however, called from places inside musb_hub_control() while
musb-lock is held, which leads to a scheduling while atomic warning.
Fix this by moving the logic into a worker, and call it where the
function was previously
Make musb_port_suspend() externally available, and call it when to host
goes into suspend. This allows the core to go into suspend while a
device is connected.
Signed-off-by: Daniel Mack zon...@gmail.com
---
drivers/usb/musb/musb_host.c| 2 ++
drivers/usb/musb/musb_host.h| 2 ++
It appears not all platforms featuring a musb core need to save the musb
core registers at suspend time and restore them on resume.
The dsps platform does, however. So add a bit in struct
musb_hdrc_platform_data to let platforms specify their need of such
action being taken.
Signed-off-by:
I've been working on some patches that allow suspending and resuming
the musb-dsps platform. This was tested for host mode only.
With these patches applied, I can successfully bring an AM335x board
to suspend with a USB media connected, and access it again after
resume. Note that this currently
The dsps platform needs to save save some registers at suspend time and
restore them after resume. This patch adds a struct for these registers,
and also lets the musb core know that the core registers need to be
saved as well.
Signed-off-by: Daniel Mack zon...@gmail.com
---
On Thu, Sep 26, 2013 at 1:28 PM, Gupta, Pekon pe...@ti.com wrote:
From: Brian Norris [mailto:computersforpe...@gmail.com]
On Thu, Sep 12, 2013 at 05:20:19PM +0530, Pekon Gupta wrote:
DT property values for OMAP based gpmc-nand have been updated
to match changes in commit:
6faf096 ARM:
Hi,
* Andreas Fenkart afenk...@gmail.com [130926 01:34]:
2013/9/26 Tony Lindgren t...@atomide.com:
@@ -463,27 +469,34 @@ static void omap_hsmmc_stop_clock(struct
omap_hsmmc_host *host)
static void omap_hsmmc_enable_irq(struct omap_hsmmc_host *host,
On Thursday 26 September 2013 07:49 PM, Tony Lindgren wrote:
Hi,
* Andreas Fenkart afenk...@gmail.com [130926 01:34]:
2013/9/26 Tony Lindgren t...@atomide.com:
@@ -463,27 +469,34 @@ static void omap_hsmmc_stop_clock(struct omap_hsmmc_host
*host)
static void omap_hsmmc_enable_irq(struct
Suspend and resume of cards are being handled from the protocol layer
and consequently the mmc_suspend|resume_host APIs are deprecated.
This means we can simplify the suspend|resume callbacks by removing the
use of the deprecated APIs. Additional cleanup done for keeping track
suspended state.
Suspend and resume of cards are handled by the protocol layer and
consequently the mmc_suspend|resume_host APIs are marked as deprecated.
While moving away from using the deprecated APIs, there are nothing
left to be done for the suspend and resume callbacks, so remove them.
Cc: Jarkko Lavinen
On 09/25/2013 03:48 AM, Tero Kristo wrote:
[...]
Test branch available here:
https://github.com/t-kristo/linux-pm.git
branch: mainline-3.12-rc2-ti-dt-clks-v7
Testing done:
- am335x-bone : boot only
- omap5-sevm : boot only
- dra7-evm : boot only
- omap3-beagle : boot + suspend/resume
On 09/26/2013 10:21 AM, Nishanth Menon wrote:
On 09/25/2013 03:48 AM, Tero Kristo wrote:
[...]
Test branch available here:
https://github.com/t-kristo/linux-pm.git
branch: mainline-3.12-rc2-ti-dt-clks-v7
Testing done:
- am335x-bone : boot only
- omap5-sevm : boot only
- dra7-evm : boot
On 11:48-20130925, Tero Kristo wrote:
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 16420ae..bc11b83 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -533,4 +533,11 @@
ram-bits = 12;
};
On 09/26/2013 11:06 AM, Nishanth Menon wrote:
On 11:48-20130925, Tero Kristo wrote:
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 16420ae..bc11b83 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -533,4 +533,11 @@
On Thu, Sep 26, 2013 at 11:54:39AM +0100, Gupta, Pekon wrote:
From: Rob Herring [mailto:robherri...@gmail.com]
From: Pekon Gupta [mailto:pe...@ti.com]
diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
[I see Mark made some of the same comments while I was typing this
email]
On Thu, Sep 26, 2013 at 06:08:42AM +, Gupta, Pekon wrote:
From: Rob Herring [mailto:robherri...@gmail.com]
From: Pekon Gupta [mailto:pe...@ti.com]
diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
On Wed, Aug 21, 2013 at 11:16:07AM +0530, Kishon Vijay Abraham I wrote:
Used the generic PHY framework API to create the PHY. Now the power off and
power on are done in omap_usb_power_off and omap_usb_power_on respectively.
The omap-usb2 driver is also moved to driver/phy.
However using the
From: Suman Anna [mailto:s-a...@ti.com]
Sent: Wednesday, September 25, 2013 11:37 AM
On 09/25/2013 10:02 AM, Santosh Shilimkar wrote:
On Tuesday 24 September 2013 07:59 PM, Paul Zimmerman wrote:
From: Suman Anna [mailto:s-a...@ti.com]
Sent: Tuesday, September 24, 2013 4:48 PM
On
On Thu, Sep 26, 2013 at 10:18:26PM +0300, Jyri Sarha wrote:
The sysclk rate does not change runtime so it should be initialized at
init time.
If you want the DT maintainers to review this stuff you probably need
to send it to them rather than spam the ASoC maintainers again.
signature.asc
2013/9/19 Russell King - ARM Linux li...@arm.linux.org.uk:
This email is only being sent to the mailing lists in question, not to
anyone personally. The list of individuals is far to great to do that.
I'm hoping no mailing lists reject the patches based on the number of
recipients.
Huh, I
Hi Paul,
Hi,
I have an OMAP5432 uEVM which I cannot get to boot with recent mainline
(tried 3.11 and 3.12-rc1). I have the TI GLSDK for this board
(v6.0.0.7),
which comes with 3.8.4 which works fine.
I found this thread: http://marc.info/?l=fedora-armm=137717811815777
and
Wrong
HWMOD removal for MMC is breaking edma_start as the events are being manually
triggered due to unused channel list not being clear.
The above issue is fixed by reading the dmas property from the DT node if it
exists and clearing the bits in the unused channel list if the dma controller
used by
On 09/25/2013 10:52:44 AM, Måns Rullgård wrote:
Rob Landley r...@landley.net writes:
On 09/24/2013 09:07:57 PM, Nicolas Pitre wrote:
I'd strongly suggest you make your binutils compatible with newer
instruction syntax instead of making the kernel more complex.
Meaning I play whack-a-mole
Rob Landley r...@landley.net writes:
On 09/25/2013 10:52:44 AM, Måns Rullgård wrote:
Rob Landley r...@landley.net writes:
On 09/24/2013 09:07:57 PM, Nicolas Pitre wrote:
I'd strongly suggest you make your binutils compatible with newer
instruction syntax instead of making the kernel
On 09/25/2013 11:13:17 AM, Nicolas Pitre wrote:
On Wed, 25 Sep 2013, Rob Landley wrote:
On 09/24/2013 09:07:57 PM, Nicolas Pitre wrote:
I'd strongly suggest you make your binutils compatible with newer
instruction syntax instead of making the kernel more complex.
Meaning I play
On 09/25/2013 03:49:07 PM, Måns Rullgård wrote:
Russell King - ARM Linux li...@arm.linux.org.uk writes:
On Wed, Sep 25, 2013 at 10:23:06AM -0500, Rob Landley wrote:
On 09/24/2013 09:07:57 PM, Nicolas Pitre wrote:
It could be as simple as making gas accept an extra argument for
instructions
On Thu, Sep 26, 2013 at 2:55 PM, Joel Fernandes jo...@ti.com wrote:
HWMOD removal for MMC is breaking edma_start as the events are being manually
triggered due to unused channel list not being clear.
The above issue is fixed by reading the dmas property from the DT node if it
exists and
On 09/24/2013 01:58 AM, Javier Martinez Canillas wrote:
The OMAP GPIO controller HW requires a pin to be configured in GPIO
input mode in order to operate as an interrupt input. Since drivers
should not be aware of whether an interrupt pin is also a GPIO or not,
the HW should be fully
From: Suman Anna [mailto:s-a...@ti.com]
Sent: Thursday, September 26, 2013 1:36 PM
I have an OMAP5432 uEVM which I cannot get to boot with recent
mainline
(tried 3.11 and 3.12-rc1). I have the TI GLSDK for this board
(v6.0.0.7),
which comes with 3.8.4 which works fine.
I found
On 09/26/2013 06:13 PM, Olof Johansson wrote:
On Thu, Sep 26, 2013 at 2:55 PM, Joel Fernandes jo...@ti.com wrote:
HWMOD removal for MMC is breaking edma_start as the events are being manually
triggered due to unused channel list not being clear.
The above issue is fixed by reading the dmas
Hi Russell,
Thank you for the patch.
On Thursday 19 September 2013 22:56:02 Russell King wrote:
The code sequence:
isp-raw_dmamask = DMA_BIT_MASK(32);
isp-dev-dma_mask = isp-raw_dmamask;
isp-dev-coherent_dma_mask = DMA_BIT_MASK(32);
bypasses the architectures check on the
On 09/26/2013 06:44 PM, Paul Zimmerman wrote:
From: Suman Anna [mailto:s-a...@ti.com]
Sent: Thursday, September 26, 2013 1:36 PM
I have an OMAP5432 uEVM which I cannot get to boot with recent
mainline
(tried 3.11 and 3.12-rc1). I have the TI GLSDK for this board
(v6.0.0.7),
which comes
This patch changes a dtsi file to contain the thermal data
for CORE domain on OMAP5 and later SoCs. This data will
enable a thermal shutdown at 125C.
This thermal data can be reused across TI SoC devices.
Cc: Benoît Cousson bcous...@baylibre.com
Cc: Tony Lindgren t...@atomide.com
Cc: Rob Herring
OMAP4430 devices can reach high temperatures and thus
needs to have cpufreq-cooling on systems running on it.
This patch adds the required cooling device properties
so that cpufreq-cpu0 driver loads the cooling device.
Cc: Benoît Cousson bcous...@baylibre.com
Cc: Tony Lindgren t...@atomide.com
OMAP5 devices can reach high temperatures and thus
needs to have cpufreq-cooling on systems running on it.
This patch adds the required cooling device properties
so that cpufreq-cpu0 driver loads the cooling device.
Cc: Benoît Cousson bcous...@baylibre.com
Cc: Tony Lindgren t...@atomide.com
Cc:
This patch changes the dtsi entry on omap4430 to contain
the thermal data. This data will enable the passive
cooling with CPUfreq cooling device at 100C and the
system will do a thermal shutdown at 125C.
Cc: Benoît Cousson bcous...@baylibre.com
Cc: Tony Lindgren t...@atomide.com
Cc: Russell King
This patch changes the dtsi entry on omap5 to contain
the thermal data. This data will enable the passive
cooling with CPUfreq cooling device at 100C. The
system will do a thermal shutdown at 125C whenever
any of its sensors sees this level.
Cc: Benoît Cousson bcous...@baylibre.com
Cc: Tony
OMAP4460 devices can reach high temperatures and thus
needs to have cpufreq-cooling on systems running on it.
This patch adds the required cooling device properties
so that cpufreq-cpu0 driver loads the cooling device.
Cc: Benoît Cousson bcous...@baylibre.com
Cc: Tony Lindgren t...@atomide.com
This patch changes a dtsi file to contain the thermal data
for GPU domain on OMAP5 and later SoCs. This data will
enable a thermal shutdown at 125C.
This thermal data can be reused across TI SoC devices.
Cc: Benoît Cousson bcous...@baylibre.com
Cc: Tony Lindgren t...@atomide.com
Cc: Rob Herring
This patch changes a dtsi file to contain the thermal data
for MPU domain on OMAP4 and later SoCs. This data will
enable the passive cooling with CPUfreq cooling device
at 100C and the system will do a thermal shutdown at 125C.
This thermal data can be reused across TI SoC devices.
Cc: Benoît
This patch changes the dtsi entry on omap4460 to contain
the thermal data. This data will enable the passive
cooling with CPUfreq cooling device at 100C and the
system will do a thermal shutdown at 125C.
Cc: Benoît Cousson bcous...@baylibre.com
Cc: Tony Lindgren t...@atomide.com
Cc: Rob Herring
74 matches
Mail list logo
