* Linus Walleij linus.wall...@linaro.org [130710 13:42]:
On Thu, Jun 27, 2013 at 4:01 PM, Grygorii Strashko
grygorii.stras...@ti.com wrote:
I think, In the future the OMAP pinctrl configurations would be manged in
more flexible way then now (thanks to pinctrl PM helpers and you;))
- Idle
On Wednesday 10 July 2013 07:56 PM, Tony Lindgren wrote:
* Kevin Hilman khil...@linaro.org [130710 01:29]:
Felipe Balbi ba...@ti.com writes:
Right, but calling serial_omap_restore_context() even when the context
is not lost, should not ideally cause an issue.
it does in one condition. If
* Rajendra Nayak rna...@ti.com [130710 23:25]:
On Wednesday 10 July 2013 07:56 PM, Tony Lindgren wrote:
Felipe is right, looks like all we need is to check if context is
initialized or not. So no need for mach-omap2/serial.c or hwmod tinkering.
After that having DEBUG_LL and cmdline
* Felipe Balbi ba...@ti.com [130710 09:18]:
On Wed, Jul 10, 2013 at 07:07:04PM +0300, Felipe Balbi wrote:
how about something like below ? It makes omap_device/hwmod and
pm_runtime agree on the initial state of the device and will prevent
-runtime_resume() from being called on first
Hi,
AM43x PRCM support (excluding clock tree) is being added with this
series. AM43x reuses most of the IP's from AM335x, as that is the
case, it was felt that reusing AM335x code as much as possible for
AM43x is better - it also helps to keep LOC less.
This RFC is
AM335x AM43x have most of the interconnects, IPs similar. Instead of
adding new hwmod data for AM43x, reuse AM335x hwmod data as much as
possible.
In the hwmod entries that could be reused on AM43x, major changes are
in register offsets and different ocpif clock for most of peripherals
that
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
Update AM335x CLKCTRL, RSTCTRL, RSTST offsets, clockdomain ocpif clk
that differ with AM43x at runtime. This is being done so that static
initialization of these details (which are different between AM335x
and AM43x) can be removed to aid in sharing of hwmod data between both
platforms as much as
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 | 148 +
1 file changed, 148 insertions(+)
create mode 100644
Hwmod common to AM43x AM335x has some of fields different (CLKCTRL,
RSTCTRL, RSTST, ocpif clk and clockdomain). It is now updated based
on SoC detection at run time, hence remove statically initialized
entries.
Signed-off-by: Afzal Mohammed af...@ti.com
---
From: Ambresh K ambr...@ti.com
Add the data file to describe all power domains in AM43x SoC.
Signed-off-by: Ambresh K ambr...@ti.com
Signed-off-by: Afzal Mohammed af...@ti.com
---
Note: domain operations to be used would have to modified as mentioned in
the cover letter
From: Ambresh K ambr...@ti.com
Reuse OMAP4 operations on AM43x.
Signed-off-by: Ambresh K ambr...@ti.com
Signed-off-by: Afzal Mohammed af...@ti.com
---
Note: This may have to modified as mentioned in the cover letter.
arch/arm/mach-omap2/omap_hwmod.c | 2 +-
1 file changed, 1 insertion(+), 1
Update AM43x CLKCTRL, RSTCTRL, RSTST offsets, clockdomain ocpif clk
that differ with AM335x at runtime. This helps in resuing much of the
AM335x hwmod data's for AM43x.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 110 +
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
From: Ambresh K ambr...@ti.com
Add the data file to describe clock domains in AM43x SoC.
Signed-off-by: Ambresh K ambr...@ti.com
Signed-off-by: Afzal Mohammed af...@ti.com
---
Note: domain operations to be used would have to modified as mentioned in
the cover letter
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 is much similar to OMAP4/5, AM335x
AM43x PKA module has sysconfig bitmap different from that of the
existing available types, hence add a new one.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.h | 5 +
arch/arm/mach-omap2/omap_hwmod_common_data.c | 6 ++
2 files changed, 11
AM43x has a few IP's that are not present in AM335x,
1. qspi
2. hdq1w
3. vpfe (two instances)
4. pka
5. des
6. rng
7. synctimer
In addition it has a few new instances of existing IP's,
1. timer8-11
2. ehrpwm3-5
3. spi2-4
Also a different pruss interconnect.
Update hwmod with the above details
4. pka
5. des
6. Rng
Needs some re-wording..
PKA, DES, RNG are there on AM335x silicon.
with regards, pekon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at
On 07/10/2013 09:45 PM, Alan Stern wrote:
On Wed, 10 Jul 2013, Roger Quadros wrote:
Some platforms e.g. ehci-omap can generate an interrupt
(i.e. remote wakeup) even when the controller is suspended i.e.
HW_ACCESSIBLE is cleared.
Introduce a flag has_wakeup_irq in struct usb_hcd to
On 07/10/2013 10:08 PM, Alan Stern wrote:
On Wed, 10 Jul 2013, Roger Quadros wrote:
Some platforms e.g. ehci-omap can generate an interrupt
(i.e. remote wakeup) even when the controller is suspended i.e.
HW_ACCESSIBLE is cleared.
Introduce a flag has_wakeup_irq in struct usb_hcd to
Hi,
On Wednesday 10 July 2013 06:38 PM, Pali Rohár wrote:
* On RX-51 probing for acx565akm driver is later then for omapfb which cause
that omapfb probe fail and framebuffer is not working
* EPROBE_DEFER causing that kernel try to probe for omapfb later again which
fixing this problem
*
On 07/10/2013 10:04 PM, Alan Stern wrote:
On Wed, 10 Jul 2013, Roger Quadros wrote:
Call ehci_suspend/resume() during runtime suspend/resume
as well as system suspend/resume.
Use a flag bound to indicate that the HCD structures are valid.
This is only true between usb_add_hcd() and
On Wednesday 10 July 2013 09:37 PM, Felipe Balbi wrote:
how about something like below ? It makes omap_device/hwmod and
pm_runtime agree on the initial state of the device and will prevent
-runtime_resume() from being called on first pm_runtime_get*() done
during probe.
This is similar to
On Monday 08 July 2013 08:02 PM, Felipe Balbi wrote:
Hi,
On Mon, Jul 08, 2013 at 07:12:59PM +0530, Sourav Poddar wrote:
+static inline unsigned long dra7xxx_readl(struct dra7xxx_qspi *qspi,
+ unsigned long reg)
+{
+ return readl(qspi-base + reg);
+}
+
+static inline void
On Thursday 11 July 2013 11:54 AM, Tony Lindgren wrote:
* Rajendra Nayak rna...@ti.com [130710 23:25]:
On Wednesday 10 July 2013 07:56 PM, Tony Lindgren wrote:
Felipe is right, looks like all we need is to check if context is
initialized or not. So no need for mach-omap2/serial.c or hwmod
Hi,
On Thu, Jul 11, 2013 at 02:47:00PM +0530, Rajendra Nayak wrote:
On Wednesday 10 July 2013 09:37 PM, Felipe Balbi wrote:
how about something like below ? It makes omap_device/hwmod and
pm_runtime agree on the initial state of the device and will prevent
-runtime_resume() from being
Hello Grant,
Hi Grant,
Hello Grant,
Could you pull this Please?
A gentle ping on this.
A gentle ping on this. Could you pull this one?
Signed-off-by: J Keerthy j-keer...@ti.com
Acked-by: Samuel Ortiz sa...@linux.intel.com
Why does Grant have to pull this?
Do you know why
On 07/11/2013 12:17 PM, Rajendra Nayak wrote:
On Wednesday 10 July 2013 09:37 PM, Felipe Balbi wrote:
how about something like below ? It makes omap_device/hwmod and
pm_runtime agree on the initial state of the device and will prevent
-runtime_resume() from being called on first
Hi,
On 07/11/2013 09:32 AM, Tony Lindgren wrote:
* Felipe Balbi ba...@ti.com [130710 09:18]:
On Wed, Jul 10, 2013 at 07:07:04PM +0300, Felipe Balbi wrote:
how about something like below ? It makes omap_device/hwmod and
pm_runtime agree on the initial state of the device and will prevent
in order to make HWMOD and pm_runtime agree on the
initial state of the device, we will unidle the device
and call pm_runtime_set_active() to tell pm_runtime
that the device is really active.
By the time driver's probe() is reached, a call to
pm_runtime_get_sync() will not cause driver's
On 07/09/2013 05:16 PM, Stefan Roese wrote:
Hi Roger,
I have been too lazy to setup NFS :). But I will give it a shot soon to see
what's going
wrong.
Really appreciated. :) Please let me know if you need anything else from
me to reproduce this issue.
Stefan,
I tried it out today and
On Thu, 20 Jun 2013, J Keerthy wrote:
Add TPS659038 documentation under Palmas.
Signed-off-by: J Keerthy j-keer...@ti.com
Acked-by: Samuel Ortiz sa...@linux.intel.com
---
Documentation/devicetree/bindings/mfd/palmas.txt |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff
On Thursday 11 July 2013 04:13 PM, Lee Jones wrote:
On Thu, 20 Jun 2013, J Keerthy wrote:
Add TPS659038 documentation under Palmas.
Signed-off-by: J Keerthy j-keer...@ti.com
Acked-by: Samuel Ortiz sa...@linux.intel.com
---
Documentation/devicetree/bindings/mfd/palmas.txt |2 ++
1 files
Hi Roger,
On 07/11/2013 12:24 PM, Roger Quadros wrote:
Stefan,
I tried it out today and it worked 5/5 times. I used a bare bones
debian root filesystem for
the NFS root.
Thanks for testing.
Could it be possible that the boot scripts on your filesystem are
somehow shutting down
the
This series should fix the issue with the early serial crash seen
during hwmod _setup() as reported by [1]
The issue was reported on a am33xx device and was not seen on omap4
or omap5 devices as the hwmod data for both omap4 and omap5 had
statically defined HWMOD_INIT_NO_IDLE and
This reverts commit 82702ea11ddfe0e43382e1fa5b66d807d8114916.
The above commit stubbed out omap_serial_early_init() in case of
DT build thinking it was doing the serial port initializations.
omap_serial_early_init() however does not do the serial port
inits (its instead done by
The HWMOD_INIT_NO_IDLE and HWMOD_INIT_NO_RESET flags don't belong in the
SoC data but instead need to be set runtime based on the uart thats used
for debug console, so hwmod avoids doing a reset followed by a idling of
the device. This is already happening as part of the omap_serial_early_init()
On Wed, 19 Jun 2013, Keerthy wrote:
From: J Keerthy j-keer...@ti.com
Check if irq value obtained is valid. If it is not valid
then skip the irq request step and go ahead with the probe.
Signed-off-by: J Keerthy j-keer...@ti.com
---
drivers/mfd/palmas.c |6 ++
1 files changed,
On Thu, 11 Jul 2013, Lee Jones wrote:
On Wed, 19 Jun 2013, Keerthy wrote:
From: J Keerthy j-keer...@ti.com
Check if irq value obtained is valid. If it is not valid
then skip the irq request step and go ahead with the probe.
Signed-off-by: J Keerthy j-keer...@ti.com
---
On 07/11/2013 01:45 PM, Stefan Roese wrote:
Hi Roger,
On 07/11/2013 12:24 PM, Roger Quadros wrote:
Stefan,
I tried it out today and it worked 5/5 times. I used a bare bones
debian root filesystem for
the NFS root.
Thanks for testing.
Could it be possible that the boot scripts on
On 07/11/2013 02:00 PM, Roger Quadros wrote:
Could it be possible that the boot scripts on your filesystem are
somehow shutting down
the ethernet interface? Might be worth checking on a fresh filesystem.
I'm pretty sure that its not a problem with the filesystem. I'm using
exactly this
On 07/11/2013 12:24 PM, Roger Quadros wrote:
My u-boot script is below and boot log is attached.
BTW: I noticed a git ID (8e1cacd) in your kernel that I can't identify.
Do you have any patches locally applied to the kernel.org version that
might be helpful with this USB issue I'm seeing?
On Wed, Jul 10, 2013 at 09:36:24PM +0530, a-bin...@ti.com wrote:
From: Amarinder Bindra a-bin...@ti.com
OMAP's hs_mmc driver is used for MMC controller operation on many
omap2plus SoCs (OMAP2430, OMAP3, 4, 5 and AM335x).
Considering that the device tree entries are already present for
omap_hsmmc.c depends on linux/sizes.h being
included indirectly by another header. Once we
enable COMPILE_TEST for this driver, we might
compile under architectures which won't include
linux/sizes.h for us. In fact, one such case
is x86.
In order to prevent compile breakages, let's
explicitly
On Thu, Jul 11, 2013 at 04:23:03PM +0530, Rajendra Nayak wrote:
This series should fix the issue with the early serial crash seen
during hwmod _setup() as reported by [1]
The issue was reported on a am33xx device and was not seen on omap4
or omap5 devices as the hwmod data for both omap4 and
McPDM and DMIC only available on OMAP4/5 which no longer boots in legacy
mode.
The code to create the devices in legacy mode can be removed.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2/devices.c | 40
1 file changed, 40
OMAP4 no longer boots in legacy mode so the code here is no longer used.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2/twl-common.c | 332 ++-
arch/arm/mach-omap2/twl-common.h | 8 -
2 files changed, 12 insertions(+), 328
Define PWM_POLARITY_NORMAL and PWM_POLARITY_INVERTED macros in
include/dt-bindings/pwm/pwm.h to be used by device tree sources.
Signed-off-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com
---
Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt | 6 +++---
On 07/11/2013 03:41 PM, Stefan Roese wrote:
On 07/11/2013 12:24 PM, Roger Quadros wrote:
My u-boot script is below and boot log is attached.
BTW: I noticed a git ID (8e1cacd) in your kernel that I can't identify.
Do you have any patches locally applied to the kernel.org version that
might
The i.MX53 PWM controller uses two cells to describe the PWM specifier.
Remove the extra unused values from the backlight DT node pwms property.
Signed-off-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com
---
arch/arm/boot/dts/imx53-mba53.dts | 2 +-
1 file changed, 1 insertion(+),
Hello,
Here's a small patch set that replaces PWM polarity numerical constants with
macros in DT. The series starts with a fix for an error in the i.MX53 mba53 DT,
and the second patch then introduces the macros and update both bindings
documentation and existing DT.
Laurent Pinchart (2):
ARM
On 16:23-20130711, Peter Ujfalusi wrote:
OMAP4 no longer boots in legacy mode so the code here is no longer used.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2/twl-common.c | 332
++-
arch/arm/mach-omap2/twl-common.h | 8
On Thu, 11 Jul 2013, Roger Quadros wrote:
The other two problems are both related to the interaction between
system PM and runtime PM. Suppose the controller is already runtime
suspended when the system goes to sleep. Because it is runtime
suspended, it is enabled for wakeup. But
On 07/11/2013 04:35 PM, Roger Quadros wrote:
BTW: I noticed a git ID (8e1cacd) in your kernel that I can't identify.
Do you have any patches locally applied to the kernel.org version that
might be helpful with this USB issue I'm seeing?
Yes I had tested it on a more recent kernel with some
On Thu, Jul 11, 2013 at 04:37:48PM +0200, Laurent Pinchart wrote:
[...]
diff --git a/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt
b/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt
index de0eaed..be09be4 100644
--- a/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt
On 07/11/2013 04:59 PM, Nishanth Menon wrote:
On 16:23-20130711, Peter Ujfalusi wrote:
OMAP4 no longer boots in legacy mode so the code here is no longer used.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2/twl-common.c | 332
On 17:45-20130711, Peter Ujfalusi wrote:
On 07/11/2013 04:59 PM, Nishanth Menon wrote:
On 16:23-20130711, Peter Ujfalusi wrote:
OMAP4 no longer boots in legacy mode so the code here is no longer used.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2/twl
On 07/11/2013 08:37 AM, Laurent Pinchart wrote:
Define PWM_POLARITY_NORMAL and PWM_POLARITY_INVERTED macros in
include/dt-bindings/pwm/pwm.h to be used by device tree sources.
Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt | 6 +++---
On 07/11/2013 09:36 AM, Thierry Reding wrote:
On Thu, Jul 11, 2013 at 04:37:48PM +0200, Laurent Pinchart wrote:
[...]
diff --git
a/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt
b/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt index
de0eaed..be09be4 100644 ---
On 07/09/2013 11:55 AM, Tony Lindgren wrote:
* Peter Barada peter.bar...@logicpd.com [130709 08:14]:
I'm working with a 3.0.8 kernel in Android ICS and have run into a
problem using wl12xx bluetooth after a suspend/resume cycle.
GPIO_162 in this design is connected to the BT_EN pin of the
On Thu, Jul 11, 2013 at 11:50:48AM -0600, Stephen Warren wrote:
On 07/11/2013 09:36 AM, Thierry Reding wrote:
On Thu, Jul 11, 2013 at 04:37:48PM +0200, Laurent Pinchart wrote:
[...]
diff --git
a/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt
Оригинално писмо
От: Dave Martin
Относно: Re: [PATCH v2 1/2] ARM: OMAP: Add secure function omap_smc3() which
calling instruction smc #1
До: Pali Rohár
Изпратено на: Сряда, 2013, Юли 10 20:45:26 EEST
On Wed, Jul 10, 2013 at 02:59:04PM +0200, Pali Rohár wrote:
On Thursday 11 July 2013 03:43 PM, Ивайло Димитров wrote:
Оригинално писмо
От: Dave Martin
Относно: Re: [PATCH v2 1/2] ARM: OMAP: Add secure function omap_smc3() which
calling instruction smc #1
До: Pali Rohár
Изпратено на: Сряда, 2013, Юли 10 20:45:26
On 07/11/2013 01:32 PM, Thierry Reding wrote:
On Thu, Jul 11, 2013 at 11:50:48AM -0600, Stephen Warren wrote:
On 07/11/2013 09:36 AM, Thierry Reding wrote:
On Thu, Jul 11, 2013 at 04:37:48PM +0200, Laurent Pinchart
wrote: [...]
diff --git
Hi Peter,
On 07/11/2013 10:00 PM, Peter Barada wrote:
On 07/09/2013 11:55 AM, Tony Lindgren wrote:
* Peter Barada peter.bar...@logicpd.com [130709 08:14]:
I'm working with a 3.0.8 kernel in Android ICS and have run into a
problem using wl12xx bluetooth after a suspend/resume cycle.
GPIO_162
On 07/11/2013 04:15 PM, Grygorii Strashko wrote:
Hi Peter,
On 07/11/2013 10:00 PM, Peter Barada wrote:
On 07/09/2013 11:55 AM, Tony Lindgren wrote:
* Peter Barada peter.bar...@logicpd.com [130709 08:14]:
I'm working with a 3.0.8 kernel in Android ICS and have run into a
problem using wl12xx
On Thu, Jun 20, 2013 at 4:42 PM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
The IGEPv2 has a number of GPIO LED connected to OMAP
pins. Configure these pins as output GPIO.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
On 07/11/2013 04:59 AM, Grygorii Strashko wrote:
Hi,
On 07/11/2013 09:32 AM, Tony Lindgren wrote:
* Felipe Balbi ba...@ti.com [130710 09:18]:
On Wed, Jul 10, 2013 at 07:07:04PM +0300, Felipe Balbi wrote:
how about something like below ? It makes omap_device/hwmod and
pm_runtime agree on
2013/7/10 Wolfram Sang w...@the-dreams.de:
Since commit ab78029 (drivers/pinctrl: grab default handles from device core),
we can rely on device core for setting the default pins. Compile tested only.
Acked-by: Linus Walleij linus.wall...@linaro.org (personally at LCE13)
Signed-off-by: Wolfram
2013/7/10 Anna, Suman s-a...@ti.com:
Barry,
On Mon, Jul 8, 2013 at 10:31 AM, Barry Song 21cn...@gmail.com wrote:
hi Ohad/all,
i am trying to find some real users of rpmsg, here i only get
samples/rpmsg/rpmsg_client_sample.c, does it mean other real drivers
are out of mainline?
Yes
There is a error message within devm_ioremap_resource
already, so remove the dev_err call to avoid redundant
error message.
Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn
Acked-by: Nishanth Menon n...@ti.com
---
cc to linux-pm with Nishanth Menon's ACK
---
72 matches
Mail list logo
