Re: [alsa-devel] [PATCH v3 0/5] Beaglebone-Black HDMI audio

[Jyri Sarha]

On 09/17/2014 04:06 AM, Dave Airlie wrote:

On 17 September 2014 06:40, Jyri Sarha jsa...@ti.com wrote:

Changes since v2:
- Change compatible property from ti,gpio-clock to ti,gpio-gate-clock
- Some minor cleanups

The code has a functional dependency to:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg109264.html

Without the above patch the audio card does not probe.

The code has been rebased on top of Linux 3.17-rc5. The patches
bellow, the above dependency, and couple of commits to add BBB HDMI audio
support to omap2plus_defconfig can be pulled from:

https://github.com/jsarha/linux.git linux-master-bbb-hdmi-audio


How do you intend to get this merge, sending patchsets like this without
indication to maintainers on a merge strategy is kinda messy.

I'm not sure how maintained tilcdc is.



Well, it is used but AFAIK the people who have been working with it the 
most have left TI. I think eventually someone at TI needs to take it 
over, but I do not know anything about that.


I was hoping that because the change to tilcdc is quite minimal it could 
go in via you. I am sure I could get a reviewed-by and tested-by from 
from Darren how has bit more experience with tilcdc and maybe from Tomi 
too if that helps. (Adding Tomi to cc).


The drm/tilcdc: Add I2S HDMI audio config for tda998x-patch itself 
just adds the audio configuration to pda998x pdata and fills the swap, 
and mirr parameters with default values (they are usually coming in hard 
coded at the beginning of tda998x_create()).


Best regards,
Jyri
--
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  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 00/16 v9] omap 8250 based uart + DMA

[Sebastian Andrzej Siewior]

On 09/16/2014 11:30 PM, Tony Lindgren wrote:
 Found one more issue when booting on 2420 n8x0, maybe something to do
 with runtime PM?
To some degree, yes.

 [4.770507] Internal error: Oops - undefined instruction: 0 [#1]
SMP ARM

  e3a02000mov r2, #0
  ee072fbamcr 15, 0, r2, cr7, cr10, {5}
  e3a01001mov r1, #1
  f5d3f000pld [r3]
=e1d30f9fldrexb  r0, [r3]

That ldrexb is part of the xchg() function in serial8250_rpm_get_tx().
So it looks like 2420 n8x0 does not understand ldrexb but the inline
assembly decided that it should.

This OMAP2420 should be ARM1136 / ARMv6. The ARM1136J(F)-S TRM says for
ldrexb: This command is only available from the rev1 (r1p0) release of
the ARM1136JF-S processor.

So it looks like the CPU should know what to do when this opcode comes
around.

 
 Regards,
 
 Tony
 

Sebastian
--
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  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 00/16 v9] omap 8250 based uart + DMA

[Sebastian Andrzej Siewior]

On 2014-09-10 21:29:55 [+0200], Sebastian Andrzej Siewior wrote:
 the diff of v8…v9 is small:

Greg, do you mind taking patches from this series up to [PATCH 05/16]?
Nobody complained about those so far and it would keep v10 a little smaller.
I have changes to #6 (the omap driver) and need to do some DMA related
changes in the following

Sebastian
--
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  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 09/16] tty: serial: 8250_dma: Add a TX trigger workaround for AM33xx

[Frans Klaver]

Hi,

Yesterday's testing was a bit messy. So here goes again.

On Mon, Sep 15, 2014 at 06:42:04PM +0200, Sebastian Andrzej Siewior wrote:
 On 09/12/2014 12:28 PM, Frans Klaver wrote:
  port config is 115200 8N1. I don't recall doing anything special. I
  boot, login, less file and get a lock.
 
 So I booted my mini Debian 7.6 (basic system + openssh) on my beagle
 bone black which is:
 
 [0.00] AM335X ES2.0 (neon )

Mine's the same.

 configured a console, login, invoked less file. The file was shown, I
 hit on the space key so less shows me more of the file. No lock-up.
 I tried booting via NFS and MMC. I tried various files with less.
 
 My dot config is here
   https://breakpoint.cc/config-am335x-bb.txt.xz
 
 If there is nothing specific to the file you do less on I have no idea
 what else it could if it is not the config.

It could be environmental. I have three test cases right now. Two of
them on the beagle bone black, the third on our custom am335x based
platform.

- All test cases run the same kernel built from uart_v10-pre1.
- For the black, the board, dtb, and u-boot environment are equal for
  the test cases.

- Bone Black: Debian 7.5
  Login, less file doesn't lock up. Scrolling down looks sensible.
  Scrolling up leaves me with a crooked display, provided the minicom
  window is more than 24 lines high. Condensed example:

  Normal less looks like:
  
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do
eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad
minim veniam, quis nostrud exercitation ullamco laboris nisi ut
aliquip ex ea commodo consequat. Duis aute irure dolor in
:

  While after scrolling up it looks like

minim veniam, quis nostrud exercitation ullamco laboris nisi ut
aliquip ex ea commodo consequat. Duis aute irure dolor in
:

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do
eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad

  vi works sensibly, but only occupies part of the total screen estate
  in minicom. After quitting, minicom doesn't use the rest of the screen
  estate anymore.

  After running vi, less doesn't show the weird scrolling behavior
  anymore, since the console has just been limited to 24x80.

- Bone Black: Yocto poky, core-image-minimal
  Login, less file locks up, doesn't show anything. I can exit using
  Ctrl-C.

  vi runs normally, only occupies part of the total screen estate in
  minicom. After quitting, a weird character shows up (typically I see
  ÿ there), but minicom can use the rest of the screen estate again.
  If we disregard the odd character, this is much like the behavior we
  have on the omap-serial driver.

- Custom board: Yocto poky, custom image
  Login, less file locks up, showing only ÿ in the top left corner
  of the screen. Can get out of there by having something dumped through
  /dev/kmsg.

  vi: see Bone Black: Yocto poky, core-image-minimal

Having it summed up like this, I think we're back at ncurses and its
interaction with the serial driver.

Hope this helps. Thanks for your effort so far,
Frans
--
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  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/4] tty: omap-serial: use threaded interrupt handler

[Peter Hurley]

On 09/16/2014 04:50 AM, Frans Klaver wrote:
 On Mon, Sep 15, 2014 at 01:31:56PM -0400, Peter Hurley wrote:
 On 09/15/2014 11:39 AM, Peter Hurley wrote:
 On 09/15/2014 10:00 AM, Frans Klaver wrote:
 At 3.6Mbaud, with slightly over 2Mbit/s data coming in, we see 1600 uart
 rx buffer overflows within 30 seconds. Threading the interrupt handling 
 reduces
 this to about 170 overflows in 10 minutes.

 Why is the threadirqs kernel boot option not sufficient?
 Or conversely, shouldn't this be selectable?

 
 I wasn't aware of the threadirqs boot option. I also wouldn't know if
 this should be selectable. What would be a reason to favor the
 non-threaded irq over the threaded irq?

Not everyone cares enough about serial to dedicate kthreads to it :)

 Also, do you see the same performance differential when you implement this
 in the 8250 driver (that is, on top of Sebastian's omap-8250 conversion)?

 
 I haven't gotten Sebastian's driver to work properly yet on the console.
 There was no reason for me yet to throw my omap changes on top of
 Sebastian's queue.
 
 PS - To overflow the 64 byte RX FIFO at those data rates means interrupt
 latency in excess of 250us?
 
 At 3686400 baud it should take about 174 us to fill a 64 byte buffer. I
 haven't done any measurements on the interrupt latency though. If you
 consider that we're sending about 1kB of data, 240 times a second, we're
 spending a lot of time reading data from the uart. I can imagine the
 system has other work to do as well.

System work should not keep irqs from being serviced. Even 174us is a long
time not to service an interrupt. Maybe console writes are keeping the isr
from running?

Regards,
Peter Hurley

--
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  http://vger.kernel.org/majordomo-info.html

[PATCH v2 3/6] ARM: dts: cm-t54: add HDMI/DVI display data

[Dmitry Lifshitz]

Add DSS related pinmux and display data nodes required to support HDMI
and DVI video out on CM-T54.

Signed-off-by: Dmitry Lifshitz lifsh...@compulab.co.il
---
v2: * Fixed comment style issue for mux mode.
  Follow the convention mode0_name.modeX_name for pins
  which mux mode differs from MUX_MODE0

* Moved aliases node to the top of dts file

 arch/arm/boot/dts/omap5-cm-t54.dts |  158 
 1 files changed, 158 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/omap5-cm-t54.dts 
b/arch/arm/boot/dts/omap5-cm-t54.dts
index 44a9f23..d2f241d 100644
--- a/arch/arm/boot/dts/omap5-cm-t54.dts
+++ b/arch/arm/boot/dts/omap5-cm-t54.dts
@@ -16,6 +16,11 @@
reg = 0x8000 0x7F00; /* 2048 MB */
};
 
+   aliases {
+   display0 = hdmi0;
+   display1 = dvi0;
+   };
+
vmmcsd_fixed: fixed-regulator-mmcsd {
compatible = regulator-fixed;
regulator-name = vmmcsd_fixed;
@@ -66,6 +71,64 @@
default-state = off;
};
};
+
+   hdmi0: connector@0 {
+   compatible = hdmi-connector;
+   label = hdmi;
+
+   type = a;
+
+   pinctrl-names = default;
+   pinctrl-0 = hdmi_conn_pins;
+
+   hpd-gpios = gpio7 1 GPIO_ACTIVE_HIGH; /* GPIO 193, HPD */
+
+   port {
+   hdmi_connector_in: endpoint {
+   remote-endpoint = hdmi_out;
+   };
+   };
+   };
+
+   tfp410: encoder@0 {
+   compatible = ti,tfp410;
+
+   ports {
+   #address-cells = 1;
+   #size-cells = 0;
+
+   port@0 {
+   reg = 0;
+
+   tfp410_in: endpoint@0 {
+   remote-endpoint = dpi_dvi_out;
+   };
+   };
+
+   port@1 {
+   reg = 1;
+
+   tfp410_out: endpoint@0 {
+   remote-endpoint = dvi_connector_in;
+   };
+   };
+   };
+   };
+
+   dvi0: connector@1 {
+   compatible = dvi-connector;
+   label = dvi;
+
+   digital;
+
+   ddc-i2c-bus = i2c2;
+
+   port {
+   dvi_connector_in: endpoint {
+   remote-endpoint = tfp410_out;
+   };
+   };
+   };
 };
 
 omap5_pmx_core {
@@ -88,6 +151,13 @@
;
};
 
+   i2c2_pins: pinmux_i2c2_pins {
+   pinctrl-single,pins = 
+   OMAP5_IOPAD(0x01b8, PIN_INPUT | MUX_MODE0) /* i2c2_scl 
*/
+   OMAP5_IOPAD(0x01ba, PIN_INPUT | MUX_MODE0) /* i2c2_sda 
*/
+   ;
+   };
+
mmc1_pins: pinmux_mmc1_pins {
pinctrl-single,pins = 
OMAP5_IOPAD(0x01e2, PIN_INPUT_PULLUP | MUX_MODE0) /* 
sdcard_clk */
@@ -144,6 +214,53 @@
OMAP5_IOPAD(0x00b6, PIN_OUTPUT | MUX_MODE6) /* 
hsi2_acdata.gpio3_83 */
;
};
+
+   dss_hdmi_pins: pinmux_dss_hdmi_pins {
+   pinctrl-single,pins = 
+   OMAP5_IOPAD(0x013c, PIN_INPUT_PULLUP | MUX_MODE0) /* 
hdmi_cec */
+   OMAP5_IOPAD(0x0140, PIN_INPUT | MUX_MODE0) /* 
hdmi_ddc_scl */
+   OMAP5_IOPAD(0x0142, PIN_INPUT | MUX_MODE0) /* 
hdmi_ddc_sda */
+   ;
+   };
+
+   hdmi_conn_pins: pinmux_hdmi_conn_pins {
+   pinctrl-single,pins = 
+   OMAP5_IOPAD(0x013e, PIN_INPUT | MUX_MODE6) /* 
hdmi_hpd.gpio7_193 */
+   ;
+   };
+
+   dss_dpi_pins: pinmux_dss_dpi_pins {
+   pinctrl-single,pins = 
+   OMAP5_IOPAD(0x0104, PIN_OUTPUT | MUX_MODE3) /* 
rfbi_data15.dispc_data15 */
+   OMAP5_IOPAD(0x0106, PIN_OUTPUT | MUX_MODE3) /* 
rfbi_data14.dispc_data14 */
+   OMAP5_IOPAD(0x0108, PIN_OUTPUT | MUX_MODE3) /* 
rfbi_data13.dispc_data13 */
+   OMAP5_IOPAD(0x010a, PIN_OUTPUT | MUX_MODE3) /* 
rfbi_data12.dispc_data12 */
+   OMAP5_IOPAD(0x010c, PIN_OUTPUT | MUX_MODE3) /* 
rfbi_data11.dispc_data11 */
+   OMAP5_IOPAD(0x010e, PIN_OUTPUT | MUX_MODE3) /* 
rfbi_data10.dispc_data10 */
+   OMAP5_IOPAD(0x0110, PIN_OUTPUT | MUX_MODE3) /* 
rfbi_data9.dispc_data9 */
+   OMAP5_IOPAD(0x0112, PIN_OUTPUT | MUX_MODE3) /* 
rfbi_data8.dispc_data8 */
+   OMAP5_IOPAD(0x0114, PIN_OUTPUT | MUX_MODE3) /* 
rfbi_data7.dispc_data7 */
+   OMAP5_IOPAD(0x0116, 

[PATCH v2 5/6] ARM: dts: cm-t54: add ADS7846 touchscreen support

[Dmitry Lifshitz]

Add ADS7846 touchscreen support.

Signed-off-by: Dmitry Lifshitz lifsh...@compulab.co.il
---
 v2:  Fixed comment style issue for mux mode.

 arch/arm/boot/dts/omap5-cm-t54.dts |   61 
 1 files changed, 61 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/omap5-cm-t54.dts 
b/arch/arm/boot/dts/omap5-cm-t54.dts
index e7afeb4..de76550 100644
--- a/arch/arm/boot/dts/omap5-cm-t54.dts
+++ b/arch/arm/boot/dts/omap5-cm-t54.dts
@@ -51,6 +51,13 @@
enable-active-high;
};
 
+   ads7846reg: ads7846-reg {
+   compatible = regulator-fixed;
+   regulator-name = ads7846-reg;
+   regulator-min-microvolt = 330;
+   regulator-max-microvolt = 330;
+   };
+
/* HS USB Host PHY on PORT 2 */
hsusb2_phy: hsusb2_phy {
compatible = usb-nop-xceiv;
@@ -164,6 +171,15 @@
};
 };
 
+omap5_pmx_wkup {
+
+   ads7846_pins: pinmux_ads7846_pins {
+   pinctrl-single,pins = 
+   0x02 (PIN_INPUT_PULLDOWN | MUX_MODE6)  /* 
llib_wakereqin.gpio1_wk15 */
+   ;
+   };
+};
+
 omap5_pmx_core {
pinctrl-names = default;
pinctrl-0 = 
@@ -300,6 +316,51 @@
OMAP5_IOPAD(0x013a, PIN_OUTPUT | MUX_MODE3) /* 
gpio6_187.dispc_data23 */
;
};
+
+   mcspi2_pins: pinmux_mcspi1_pins {
+   pinctrl-single,pins = 
+   OMAP5_IOPAD(0x00fc, PIN_INPUT | MUX_MODE0) /* 
mcspi2_clk */
+   OMAP5_IOPAD(0x00fe, PIN_INPUT | MUX_MODE0) /* 
mcspi2_simo */
+   OMAP5_IOPAD(0x0100, PIN_INPUT | MUX_MODE0) /* 
mcspi2_somi */
+   OMAP5_IOPAD(0x0102, PIN_INPUT | MUX_MODE0) /* 
mcspi2_cs0 */
+   ;
+   };
+};
+
+mcspi2 {
+   pinctrl-names = default;
+   pinctrl-0 = mcspi2_pins;
+
+   /* touch controller */
+   ads7846@0 {
+   pinctrl-names = default;
+   pinctrl-0 = ads7846_pins;
+
+   compatible = ti,ads7846;
+   vcc-supply = ads7846reg;
+
+   reg = 0;  /* CS0 */
+   spi-max-frequency = 150;
+
+   interrupt-parent = gpio1;
+   interrupts = 15 0;/* gpio1_wk15 */
+   pendown-gpio = gpio1 15 0;
+
+
+   ti,x-min = /bits/ 16 0x0;
+   ti,x-max = /bits/ 16 0x0fff;
+   ti,y-min = /bits/ 16 0x0;
+   ti,y-max = /bits/ 16 0x0fff;
+
+   ti,x-plate-ohms = /bits/ 16 180;
+   ti,pressure-max = /bits/ 16 255;
+
+   ti,debounce-max = /bits/ 16 30;
+   ti,debounce-tol = /bits/ 16 10;
+   ti,debounce-rep = /bits/ 16 1;
+
+   linux,wakeup;
+   };
 };
 
 mmc1 {
-- 
1.7.5.4

--
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  http://vger.kernel.org/majordomo-info.html

[PATCH v2 6/6] ARM: dts: cm-t54: setup omap_dwc3

[Dmitry Lifshitz]

Add extcon and vbus-supply properties of DWC3 node.

Signed-off-by: Dmitry Lifshitz lifsh...@compulab.co.il
---
 v2: No changes

 arch/arm/boot/dts/omap5-cm-t54.dts |5 +
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/omap5-cm-t54.dts 
b/arch/arm/boot/dts/omap5-cm-t54.dts
index de76550..f712e23 100644
--- a/arch/arm/boot/dts/omap5-cm-t54.dts
+++ b/arch/arm/boot/dts/omap5-cm-t54.dts
@@ -631,6 +631,11 @@
phys = 0 hsusb2_phy hsusb3_phy;
 };
 
+usb3 {
+   extcon = extcon_usb3;
+   vbus-supply = smps10_out1_reg;
+};
+
 cpu0 {
cpu0-supply = smps123_reg;
 };
-- 
1.7.5.4

--
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  http://vger.kernel.org/majordomo-info.html

[PATCH v2 2/6] ARM: dts: cm-t54: fix mux mode comment style

[Dmitry Lifshitz]

Follow the comment style of mode0_name.modeX_name for pins
which mux mode differs from MUX_MODE0.

Signed-off-by: Dmitry Lifshitz lifsh...@compulab.co.il
---

 v2: New patch

 arch/arm/boot/dts/omap5-cm-t54.dts |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/omap5-cm-t54.dts 
b/arch/arm/boot/dts/omap5-cm-t54.dts
index 429471a..44a9f23 100644
--- a/arch/arm/boot/dts/omap5-cm-t54.dts
+++ b/arch/arm/boot/dts/omap5-cm-t54.dts
@@ -127,8 +127,8 @@
 
wlan_gpios_pins: pinmux_wlan_gpios_pins {
pinctrl-single,pins = 
-   OMAP5_IOPAD(0x019c, PIN_OUTPUT_PULLDOWN | MUX_MODE6) /* 
gpio4_109 */
-   OMAP5_IOPAD(0x019e, PIN_OUTPUT_PULLDOWN | MUX_MODE6) /* 
gpio4_110 */
+   OMAP5_IOPAD(0x019c, PIN_OUTPUT_PULLDOWN | MUX_MODE6) /* 
abemcpdm_ul_data.gpio4_109 */
+   OMAP5_IOPAD(0x019e, PIN_OUTPUT_PULLDOWN | MUX_MODE6) /* 
abemcpdm_dl_data.gpio4_110 */
;
};
 
-- 
1.7.5.4

--
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  http://vger.kernel.org/majordomo-info.html

[PATCH v2 1/6] ARM: dts: sbc-t54: fix mux mode comment style

[Dmitry Lifshitz]

Follow the comment style of mode0_name.modeX_name for pins
which mux mode differs from MUX_MODE0.

Signed-off-by: Dmitry Lifshitz lifsh...@compulab.co.il
---

 v2: New patch

 arch/arm/boot/dts/omap5-sbc-t54.dts |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/omap5-sbc-t54.dts 
b/arch/arm/boot/dts/omap5-sbc-t54.dts
index 8e89793..337bbbc 100644
--- a/arch/arm/boot/dts/omap5-sbc-t54.dts
+++ b/arch/arm/boot/dts/omap5-sbc-t54.dts
@@ -19,8 +19,8 @@
 
mmc1_aux_pins: pinmux_mmc1_aux_pins {
pinctrl-single,pins = 
-   OMAP5_IOPAD(0x0174, PIN_INPUT_PULLUP | MUX_MODE6) /* 
gpio8_228 */
-   OMAP5_IOPAD(0x0176, PIN_INPUT_PULLUP | MUX_MODE6) /* 
gpio8_229 */
+   OMAP5_IOPAD(0x0174, PIN_INPUT_PULLUP | MUX_MODE6) /* 
timer5_pwm_evt.gpio8_228 */
+   OMAP5_IOPAD(0x0176, PIN_INPUT_PULLUP | MUX_MODE6) /* 
timer6_pwm_evt.gpio8_229 */
;
};
 };
-- 
1.7.5.4

--
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  http://vger.kernel.org/majordomo-info.html

[PATCH v2 0/6] ARM: dts: cm-t54: enable video out, touchscreen and USB3.0

[Dmitry Lifshitz]

Add CM-T54 DT nodes:

* enable HDMI/DVI/LCD video output support
* add ADS7846 touchscreen support
* enchance DWC3 setup to enable power supply for USB3.0 OTG port

v2: * Fixed comment style issue for mux mode.
  Follow the convention mode0_name.modeX_name for pins
  which mux mode differs from MUX_MODE0

* Moved aliases node to the top of dts file

Dmitry Lifshitz (6):
  ARM: dts: sbc-t54: fix mux mode comment style
  ARM: dts: cm-t54: fix mux mode comment style
  ARM: dts: cm-t54: add HDMI/DVI display data
  ARM: dts: cm-t54: add Startek LCD support
  ARM: dts: cm-t54: add ADS7846 touchscreen support
  ARM: dts: cm-t54: setup omap_dwc3

 arch/arm/boot/dts/omap5-cm-t54.dts  |  272 ++-
 arch/arm/boot/dts/omap5-sbc-t54.dts |4 +-
 2 files changed, 272 insertions(+), 4 deletions(-)

-- 
1.7.5.4

--
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  http://vger.kernel.org/majordomo-info.html

[PATCH v2 4/6] ARM: dts: cm-t54: add Startek LCD support

[Dmitry Lifshitz]

Add DT support for Startek KD050C LCD 800x480 panel.

Signed-off-by: Dmitry Lifshitz lifsh...@compulab.co.il
---
 
 v2: Rebased on top of the previous patch changes

 arch/arm/boot/dts/omap5-cm-t54.dts |   44 
 1 files changed, 44 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/omap5-cm-t54.dts 
b/arch/arm/boot/dts/omap5-cm-t54.dts
index d2f241d..e7afeb4 100644
--- a/arch/arm/boot/dts/omap5-cm-t54.dts
+++ b/arch/arm/boot/dts/omap5-cm-t54.dts
@@ -19,6 +19,7 @@
aliases {
display0 = hdmi0;
display1 = dvi0;
+   display2 = lcd0;
};
 
vmmcsd_fixed: fixed-regulator-mmcsd {
@@ -72,6 +73,38 @@
};
};
 
+   lcd0: display {
+compatible = startek,startek-kd050c, panel-dpi;
+label = lcd;
+
+pinctrl-names = default;
+pinctrl-0 = lcd_pins;
+
+enable-gpios = gpio8 3 GPIO_ACTIVE_HIGH;
+
+panel-timing {
+clock-frequency = 3300;
+hactive = 800;
+vactive = 480;
+hfront-porch = 40;
+hback-porch = 40;
+hsync-len = 43;
+vback-porch = 29;
+vfront-porch = 13;
+vsync-len = 3;
+hsync-active = 0;
+vsync-active = 0;
+de-active = 1;
+pixelclk-active = 1;
+};
+
+port {
+lcd_in: endpoint {
+remote-endpoint = dpi_lcd_out;
+};
+};
+};
+
hdmi0: connector@0 {
compatible = hdmi-connector;
label = hdmi;
@@ -223,6 +256,12 @@
;
};
 
+   lcd_pins: pinmux_lcd_pins {
+   pinctrl-single,pins = 
+   OMAP5_IOPAD(0x0172, PIN_OUTPUT_PULLDOWN | MUX_MODE6) /* 
timer11_pwm_evt.gpio8_227 */
+   ;
+   };
+
hdmi_conn_pins: pinmux_hdmi_conn_pins {
pinctrl-single,pins = 
OMAP5_IOPAD(0x013e, PIN_INPUT | MUX_MODE6) /* 
hdmi_hpd.gpio7_193 */
@@ -546,6 +585,11 @@
remote-endpoint = tfp410_in;
data-lines = 24;
};
+
+   dpi_lcd_out: endpoint@1 {
+   remote-endpoint = lcd_in;
+   data-lines = 24;
+   };
};
 };
 
-- 
1.7.5.4

--
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  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/4] tty: omap-serial: use threaded interrupt handler

[Frans Klaver]

On Wed, Sep 17, 2014 at 08:01:08AM -0400, Peter Hurley wrote:
 On 09/16/2014 04:50 AM, Frans Klaver wrote:
  On Mon, Sep 15, 2014 at 01:31:56PM -0400, Peter Hurley wrote:
  On 09/15/2014 11:39 AM, Peter Hurley wrote:
  On 09/15/2014 10:00 AM, Frans Klaver wrote:
  At 3.6Mbaud, with slightly over 2Mbit/s data coming in, we see 1600 uart
  rx buffer overflows within 30 seconds. Threading the interrupt handling 
  reduces
  this to about 170 overflows in 10 minutes.
 
  Why is the threadirqs kernel boot option not sufficient?
  Or conversely, shouldn't this be selectable?
 
  
  I wasn't aware of the threadirqs boot option. I also wouldn't know if
  this should be selectable. What would be a reason to favor the
  non-threaded irq over the threaded irq?
 
 Not everyone cares enough about serial to dedicate kthreads to it :)

Fair enough. In that light, we might not care enough about other
subsystems to dedicate kthreads to it :). Selectable seems reasonable in
that case.


  Also, do you see the same performance differential when you implement this
  in the 8250 driver (that is, on top of Sebastian's omap-8250 conversion)?
 
  
  I haven't gotten Sebastian's driver to work properly yet on the console.
  There was no reason for me yet to throw my omap changes on top of
  Sebastian's queue.
  
  PS - To overflow the 64 byte RX FIFO at those data rates means interrupt
  latency in excess of 250us?
  
  At 3686400 baud it should take about 174 us to fill a 64 byte buffer. I
  haven't done any measurements on the interrupt latency though. If you
  consider that we're sending about 1kB of data, 240 times a second, we're
  spending a lot of time reading data from the uart. I can imagine the
  system has other work to do as well.
 
 System work should not keep irqs from being serviced. Even 174us is a long
 time not to service an interrupt. Maybe console writes are keeping the isr
 from running?

That's quite possible. I'll have to redo the test setup I had for this to
give you a decent answer. I'll have to do that anyway as Sebastian's
8250 conversion improves.

Thanks for the comments,
Frans
--
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  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] mfd: twl4030-power: use 'ti,system-power-controller' as alternative way to support system power off

[Nishanth Menon]

On 16:05-20140916, Lee Jones wrote:
 On Mon, 08 Sep 2014, Tony Lindgren wrote:
 
  * Nishanth Menon n...@ti.com [140903 12:07]:
   ti,system-power-controller is more or less the standard way of
   indicating that the PMIC is the system wide power controller and hence
   may be used to switch off the system. Almost ALL TI PMIC drivers and
   many Maxim PMIC drivers follow the same style.
   
   So support 'ti,system-power-controller' in addition to the usual
   'ti,use_poweroff' to indicate that the PMIC instance has control for
   switching off the system.
   
   Signed-off-by: Nishanth Menon n...@ti.com
  
  Acked-by: Tony Lindgren t...@atomide.com
 
 I assume you're going to resend this with the document modifications?
 When you do, don't forget to apply Tony's Ack, as it will ensure a
 faster merge.
 

Thanks for the reminder, This did indeed slip through the cracks.
Posting updated rev in a few mins..
-- 
Regards,
Nishanth Menon
--
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  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 09/16] tty: serial: 8250_dma: Add a TX trigger workaround for AM33xx

[Peter Hurley]

On 09/16/2014 12:55 PM, Sebastian Andrzej Siewior wrote:
 On 09/15/2014 07:01 PM, Sebastian Andrzej Siewior wrote:
 On 09/11/2014 04:35 PM, Peter Hurley wrote:
 I do need to find out if omap hardware sets UART_MSR_DCTS when auto CTS
 is on. Would you mind running the debug patch below with HW flow control on?

 I didn't forget about this. However I told minicom to use hardware flow
 control (and I see the driver set the HW bit) but I haven't seen that
 uart_handle_cts_change() has been invoked at all. I'm going to check
 two other boards and report then.
 
 No, I don't get into this at all function.

Ok, good to know. Thanks for testing that.

 So I connected my am335x-evm
 with beagle board xm because both of them have an old fashion UART
 connector (instead those uart-to-usb). Both configured with HW-Flow and
 I haven't seen the function invoked but I saw port-icount.overrun
 being incremented. This shouldn't happen. So I am a little puzzled here…

Yeah, that's weird. Do you have a break-out box to confirm that RTS/CTS are
being driven?

Regards,
Peter Hurley

--
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  http://vger.kernel.org/majordomo-info.html

[PATCH V2 1/2] Documentation: devicetree: mfd: twl4030-power: Use the standard 'ti,system-power-controller' to mark power control

[Nishanth Menon]

ti,system-power-controller is more or less the standard way of
indicating that the PMIC is the system wide power controller and hence
may be used to switch off the system. Almost ALL TI PMIC drivers and
many Maxim PMIC drivers follow the same style.

So support 'ti,system-power-controller' in addition to the usual
'ti,use_poweroff' to indicate that the PMIC instance has control for
switching off the system.

Signed-off-by: Nishanth Menon n...@ti.com
---

V2: picked up documentation suggestion from Sebastien
V1: https://patchwork.kernel.org/patch/4836381/

 .../devicetree/bindings/mfd/twl4030-power.txt  |9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/mfd/twl4030-power.txt 
b/Documentation/devicetree/bindings/mfd/twl4030-power.txt
index b9ee7b9..a7390c7 100644
--- a/Documentation/devicetree/bindings/mfd/twl4030-power.txt
+++ b/Documentation/devicetree/bindings/mfd/twl4030-power.txt
@@ -23,8 +23,13 @@ down during off-idle. Note that this does not work on all 
boards
 depending on how the external oscillator is wired.
 
 Optional properties:
-- ti,use_poweroff: With this flag, the chip will initiates an ACTIVE-to-OFF or
-  SLEEP-to-OFF transition when the system poweroffs.
+
+- ti,system-power-controller: This indicates that TWL4030 is the
+  power supply master of the system. With this flag, the chip will
+  initiates an ACTIVE-to-OFF or SLEEP-to-OFF transition when the
+  system poweroffs.
+
+- ti,use_poweroff: Deprecated name for ti,system-power-controller
 
 Example:
 i2c1 {
-- 
1.7.9.5

--
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  http://vger.kernel.org/majordomo-info.html

[PATCH V2 2/2] mfd: twl4030-power: use 'ti,system-power-controller' as alternative way to support system power off

[Nishanth Menon]

ti,system-power-controller is more or less the standard way of
indicating that the PMIC is the system wide power controller and hence
may be used to switch off the system. Almost ALL TI PMIC drivers and
many Maxim PMIC drivers follow the same style.

So support 'ti,system-power-controller' in addition to the usual
'ti,use_poweroff' to indicate that the PMIC instance has control for
switching off the system.

Signed-off-by: Nishanth Menon n...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
---

V2: no change, picked up Tony's ack.
V1: https://patchwork.kernel.org/patch/4836371/
 drivers/mfd/twl4030-power.c |3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/mfd/twl4030-power.c b/drivers/mfd/twl4030-power.c
index 3bc969a..1c129ba 100644
--- a/drivers/mfd/twl4030-power.c
+++ b/drivers/mfd/twl4030-power.c
@@ -627,6 +627,9 @@ static bool twl4030_power_use_poweroff(const struct 
twl4030_power_data *pdata,
if (pdata  pdata-use_poweroff)
return true;
 
+   if (of_property_read_bool(node, ti,system-power-controller))
+   return true;
+
if (of_property_read_bool(node, ti,use_poweroff))
return true;
 
-- 
1.7.9.5

--
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  http://vger.kernel.org/majordomo-info.html

[PATCH V2 0/2] mfd: twl4030-power: support ti,system-power-controller

[Nishanth Menon]

This series adds ti,system-power-controller to Documentation and the
driver seperately as per maintainer preference.

Based on v3.17-rc1

Changes since V1: update in documentation, picked up Tony's ack for patch #2.

V1: http://marc.info/?l=devicetreem=140977126218800w=2

Nishanth Menon (2):
  Documentation: devicetree: mfd: twl4030-power: Use the standard
'ti,system-power-controller' to mark power control
  mfd: twl4030-power: use 'ti,system-power-controller' as alternative
way to support system power off

 .../devicetree/bindings/mfd/twl4030-power.txt  |9 +++--
 drivers/mfd/twl4030-power.c|3 +++
 2 files changed, 10 insertions(+), 2 deletions(-)

-- 
1.7.9.5

--
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  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] CLK: TI: consider the fact that of_clk_get() might return an error

[Nishanth Menon]

On 09/11/2014 11:01 AM, Sebastian Andrzej Siewior wrote:

I forgot to update the dtb and the kernel crashed:
|Unable to handle kernel NULL pointer dereference at virtual address 002e
|PC is at __clk_get_flags+0x4/0xc
|LR is at ti_dt_clockdomains_setup+0x70/0xe8

because I did not have the clock nodes. of_clk_get() returns an error
pointer which is not checked here.

Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
  drivers/clk/ti/clockdomain.c | 5 +
  1 file changed, 5 insertions(+)

diff --git a/drivers/clk/ti/clockdomain.c b/drivers/clk/ti/clockdomain.c
index f1e0038d76ac..fdd458600c2c 100644
--- a/drivers/clk/ti/clockdomain.c
+++ b/drivers/clk/ti/clockdomain.c
@@ -36,6 +36,11 @@ static void __init of_ti_clockdomain_setup(struct 
device_node *node)

for (i = 0; i  num_clks; i++) {
clk = of_clk_get(node, i);
+   if (IS_ERR(clk)) {
+   pr_err(Failed get %s' clock nr %d (%ld)\n,
+   node-full_name, i, PTR_ERR(clk));



Could you add %s: __func__ as well - it kinda helps understand this is 
part of clockdomain setup and not some driver cribbing that it did not 
get some clock.



+   continue;
+   }
if (__clk_get_flags(clk)  CLK_IS_BASIC) {
pr_warn(can't setup clkdm for basic clk %s\n,
__clk_get_name(clk));



--
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  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: OMAP2+: clock: allow omap2_dpll_round_rate() to round to next-lowest rate

[Tomi Valkeinen]

Hi,

On 23/07/14 13:44, Paul Walmsley wrote:
 
 Change the behavior of omap2_dpll_round_rate() to round to either the
 exact rate requested, or the next lowest rate that the clock is able to
 provide.
 
 This is not an ideal fix, but is intended to provide a relatively safe
 way for drivers to set PLL rates, until a better solution can be
 implemented.
 
 For the time being, omap3_noncore_dpll_set_rate() is still allowed to
 set its rate to something other than what the caller requested; but will
 warn when this occurs.
 
 Cc: Tomi Valkeinen tomi.valkei...@ti.com
 Cc: Mike Turquette mturque...@linaro.org
 Signed-off-by: Paul Walmsley p...@pwsan.com
 ---
  arch/arm/mach-omap2/clkt_dpll.c | 28 +---
  arch/arm/mach-omap2/dpll3xxx.c  | 12 ++--
  2 files changed, 31 insertions(+), 9 deletions(-)

This patch improved things quite a bit, but we still have problems. I
noticed that on AM43xx:

clk_round_rate(dss_fclk, 10846) = 199967213
clk_set_rate(dss_fclk, 199967213) - 199966387

So similar to the issue that 7e50e7e176634e8cc0335778915be75df41043dc fixed.

Above you say that omap3_noncore_dpll_set_rate() is still allowed to
set its rate to something other than what the caller requested; but will
warn when this occurs., but I see no warning printed.

I didn't find out where the error comes from, but I (again) noticed the
two issues we have:

- The omap dpll code has no maximum values, so omap2_dpll_round_rate()
goes on to return ~4GHz rates as valid, which I believe it can't do.

- clk-divider.c driver doesn't handle errors from __clk_round_rate(). At
least omap2_dpll_round_rate() returns ~0 on error.

Any ideas where that round/set issue might come from?

 Tomi




signature.asc
Description: OpenPGP digital signature

Re: [PATCH v4 10/11] ARM: OMAP2+: AM33XX: Basic suspend resume support

[Ohad Ben-Cohen]

Hi Suman,

On Tue, Sep 16, 2014 at 7:14 PM, Suman Anna s-a...@ti.com wrote:
 The current remoteproc infrastructure automatically calls rproc_boot
 only as part of the rpmsg/virtio stack (in remoteproc_virtio.c), but
 since the WkupM3 does not use rpmsg, there is no automatic booting of
 the WkupM3 processor.  This is the reason why rproc_boot is called as
 part of the WkupM3 driver probe sequence. What are your concerns here,
 and if you think this is not the right place do invoke rproc_boot, where
 do you expect it to be called?

The remoteproc layer is meant to hide hardware-specific details, and
allow high-level hardware-agnostic code to boot a remote processor, in
order to achieve some task, without even caring what kind of hardware
it is booting.

So generally we have some consumer driver asking remoteproc to boot a
remote processor, and in turn, remoteproc asking a hardware-specific
vendor driver to take care of the hardware details like actually
taking the remote processor out of reset.

The consumer driver is some code that deals with some hardware
agnostic task. Today the only consumer we have is rpmsg, so it's
perfectly reasonable if remoteproc needs to be adapted a bit to
accommodate other consumers as they show up.

Can you think of any component in your code that is not necessarily
hardware specific, and that one day might be useful for other vendors?
Can you describe the task you're trying to achieve, the entities
involved and the flow between them?

 Also do note that, there is no way
 at present to retrieve the struct rproc for a given remote processor, to
 be able to invoke the rproc_boot from a different layer.

It's perfectly ok to make struct rproc public if we have a consumer
that requires it.

 Splitting this would still require some kind of notifier from remoteproc
 for the other layers for them to know that the WkupM3 remote processor
 has been loaded and booted successfully. This is also done as part of
 the WkupM3 driver at the moment.

Are there entities, other than the one that calls rproc_boot, that
needs to know that the WkupM3 is up? if so, let's discuss who should
notify them - remoteproc or the actual invoker of rproc_boot. It
probably depends on who those entities are and what's their relation,
if any, to the WkupM3 driver.

Thanks,
Ohad.
--
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  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: dts: DRA7: Add PMU nodes

[Nishanth Menon]

On 08:39-20140903, Nishanth Menon wrote:
 On 08/19/2014 08:54 AM, Nishanth Menon wrote:
  From: Lucas Weaver l-wea...@ti.com
  
  DRA74x and DRA72x family of processors vary slightly in the number
  of CPUs. So, add different instances of PMU for each of these processor
  groups. Further, since the interrupts bypass crossbar and are directly
  connected to GIC, mark the dts nodes with relevant information.
  
  Tested with perf utility.
  
  Reviewed-by: Felipe Balbi ba...@ti.com
  Signed-off-by: Lucas Weaver l-wea...@ti.com
  Signed-off-by: Nishanth Menon n...@ti.com
  ---
 Hi,
 Gentle ping..

Tony,
I dont see this patch in omap-for-v3.18/dt

Is there anyway you might consider pulling this for 3.18?

Patchworks link:
https://patchwork.kernel.org/patch/4743121/

 
 Regards,
 Nishanth Menon
   arch/arm/boot/dts/dra72x.dtsi |5 +
   arch/arm/boot/dts/dra74x.dtsi |6 ++
   2 files changed, 11 insertions(+)
  
  diff --git a/arch/arm/boot/dts/dra72x.dtsi b/arch/arm/boot/dts/dra72x.dtsi
  index f1ec22f..e5a3d23 100644
  --- a/arch/arm/boot/dts/dra72x.dtsi
  +++ b/arch/arm/boot/dts/dra72x.dtsi
  @@ -22,4 +22,9 @@
  reg = 0;
  };
  };
  +
  +   pmu {
  +   compatible = arm,cortex-a15-pmu;
  +   interrupts = GIC_SPI DIRECT_IRQ(131) IRQ_TYPE_LEVEL_HIGH;
  +   };
   };
  diff --git a/arch/arm/boot/dts/dra74x.dtsi b/arch/arm/boot/dts/dra74x.dtsi
  index a4e8bb9..3be544c 100644
  --- a/arch/arm/boot/dts/dra74x.dtsi
  +++ b/arch/arm/boot/dts/dra74x.dtsi
  @@ -38,4 +38,10 @@
  reg = 1;
  };
  };
  +
  +   pmu {
  +   compatible = arm,cortex-a15-pmu;
  +   interrupts = GIC_SPI DIRECT_IRQ(131) IRQ_TYPE_LEVEL_HIGH,
  +GIC_SPI DIRECT_IRQ(132) IRQ_TYPE_LEVEL_HIGH;
  +   };
   };
  
 
 
 -- 
 Regards,
 Nishanth Menon
 --
 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  http://vger.kernel.org/majordomo-info.html

-- 
Regards,
Nishanth Menon
--
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  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/9] arm: omap: intc: remaining patches

[Tony Lindgren]

* Felipe Balbi ba...@ti.com [140915 14:16]:
 Hi Tony,
 
 Here are the remaining INTC patches rebased on your omap-for-v3.18/intc-v2
 branch.
 
 Based on our IRC chat, I kept irq-omap-intc.h header, but included it
 on common.h instead of modifying every board-file.

Great thanks. We can deal with common.h header once we've dropped
the legacy board-*.c files for omap3.

Applying all into omap-for-v3.18/intc-v2.

Regards,

Tony
 
 cheers
 
 Felipe Balbi (9):
   irqchip: add irq-omap-intc.h header
   arm: omap: irq: move irq.c to drivers/irqchip/
   irqchip: omap-intc: minor improvement to omap_irq_pending()
   irqchip: omap-intc: comment style cleanup
   irqchip: omap-intc: remove unnecesary of_address_to_resource() call
   irqchip: omap-intc: enable IP protection
   irqchip: omap-intc: enable TURBO idle mode
   irqchip: omap-intc: correct maximum number or MIR registers
   irqchip: omap-intc: remove unnecessary comments
 
  arch/arm/mach-omap2/Kconfig|  1 +
  arch/arm/mach-omap2/Makefile   |  3 +-
  arch/arm/mach-omap2/common.h   | 10 +---
  drivers/irqchip/Kconfig|  5 ++
  drivers/irqchip/Makefile   |  1 +
  .../irq.c = drivers/irqchip/irq-omap-intc.c   | 64 
 +-
  include/linux/irqchip/irq-omap-intc.h  | 32 +++
  7 files changed, 78 insertions(+), 38 deletions(-)
  rename arch/arm/mach-omap2/irq.c = drivers/irqchip/irq-omap-intc.c (89%)
  create mode 100644 include/linux/irqchip/irq-omap-intc.h
 
 -- 
 2.0.1.563.g66f467c
 
--
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  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] arm: omap2: n8x0: move i2c devices to DT

[Tony Lindgren]

* Felipe Balbi ba...@ti.com [140916 13:34]:
 On Tue, Sep 16, 2014 at 03:31:40PM -0500, Felipe Balbi wrote:
  By moving i2c devices to DT we can clean up
  i2c_board_info and fix a problem with moving
  INTC to irq domain where IRQs can be renumbered
  on each boot.
  
  Cc: Aaro Koskinen aaro.koski...@iki.fi
  Signed-off-by: Felipe Balbi ba...@ti.com
 
 note that this only causes problem for N8x0 because it boots in kinda of
 a hybrid way, where it uses DT but not all peripherals are created
 through DT.

Thanks applying this into omap-for-v3.18/intc-v2.

Regards,

Tony
--
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  http://vger.kernel.org/majordomo-info.html

[GIT PULL] omap wake-up regression fix for v3.17

[Tony Lindgren]

The following changes since commit 69e273c0b0a3c337a521d083374c918dc52c666f:

  Linux 3.17-rc3 (2014-08-31 18:23:04 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap 
tags/fix-v3.17-io-chain-v3

for you to fetch changes up to 7db143b89137de06ed289cf8b302f3bbbc5baa1f:

  ARM: OMAP3: Fix I/O chain clock line assertion timed out error (2014-09-16 
15:09:44 -0700)


Regression fix for early omap3 revisions for wake-up events that
too some time to narrow down. Although a bit intrusive, this would
be good to get into the -rc cycle as there are quite a few boards
out there with omap3 es2.1 and es3.0, and we have those in at least
three boot test systems too that show errors without this patch.


Tony Lindgren (1):
  ARM: OMAP3: Fix I/O chain clock line assertion timed out error

 arch/arm/mach-omap2/omap_hwmod.c |  2 +-
 arch/arm/mach-omap2/prm3xxx.c| 39 +++
 2 files changed, 36 insertions(+), 5 deletions(-)
--
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  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] arm: omap2: n8x0: move i2c devices to DT

[Felipe Balbi]

On Wed, Sep 17, 2014 at 07:51:32AM -0700, Tony Lindgren wrote:
 * Felipe Balbi ba...@ti.com [140916 13:34]:
  On Tue, Sep 16, 2014 at 03:31:40PM -0500, Felipe Balbi wrote:
   By moving i2c devices to DT we can clean up
   i2c_board_info and fix a problem with moving
   INTC to irq domain where IRQs can be renumbered
   on each boot.
   
   Cc: Aaro Koskinen aaro.koski...@iki.fi
   Signed-off-by: Felipe Balbi ba...@ti.com
  
  note that this only causes problem for N8x0 because it boots in kinda of
  a hybrid way, where it uses DT but not all peripherals are created
  through DT.
 
 Thanks applying this into omap-for-v3.18/intc-v2.

it might be better to apply this on your DT branch and merge DT before
intc-v2, that might avoid a bisection problem.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH] arm: omap2: n8x0: move i2c devices to DT

[Tony Lindgren]

* Felipe Balbi ba...@ti.com [140917 08:03]:
 On Wed, Sep 17, 2014 at 07:51:32AM -0700, Tony Lindgren wrote:
  * Felipe Balbi ba...@ti.com [140916 13:34]:
   On Tue, Sep 16, 2014 at 03:31:40PM -0500, Felipe Balbi wrote:
By moving i2c devices to DT we can clean up
i2c_board_info and fix a problem with moving
INTC to irq domain where IRQs can be renumbered
on each boot.

Cc: Aaro Koskinen aaro.koski...@iki.fi
Signed-off-by: Felipe Balbi ba...@ti.com
   
   note that this only causes problem for N8x0 because it boots in kinda of
   a hybrid way, where it uses DT but not all peripherals are created
   through DT.
  
  Thanks applying this into omap-for-v3.18/intc-v2.
 
 it might be better to apply this on your DT branch and merge DT before
 intc-v2, that might avoid a bisection problem.

Yes it would have been nice to have this as a patch before preparing
for intc-v2, but I did not have my n8x0 booting reliably because of
xhci vs ehci issues on my PC and did not notice it early enough.

I've already sent a pull request for the first part of intc-v2, so
best to keep the related changes together in this case.

Regards,

Tony
--
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  http://vger.kernel.org/majordomo-info.html

Re: [RESEND PATCH] gpio: omap: Fix interrupt names

[Javier Martinez Canillas]

Hello Linus,

On Fri, Sep 5, 2014 at 9:52 PM, Nishanth Menon n...@ti.com wrote:
 When viewing the /proc/interrupts, there is no information about which
 GPIO bank a specific gpio interrupt is hooked on to. This is more than a
 bit irritating as such information can esily be provided back to the
 user and at times, can be crucial for debug.

 So, instead of displaying something like:
 31: 0   0  GPIO   0  palmas
 32: 0   0  GPIO  27  mmc0

 Display the following with appropriate device name:
 31: 0   0  4ae1.gpio   0  palmas
 32: 0   0  4805d000.gpio  27  mmc0

 This requires that we create irq_chip instance specific for each GPIO
 bank which is trivial to achieve.

 Signed-off-by: Nishanth Menon n...@ti.com
 Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
 Acked-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
 Acked-by: Kevin Hilman khil...@linaro.org
 ---
 Requested to be resend by Javier with linux-gpio maintainers in CC.

 Original V1 of the patch: https://patchwork.kernel.org/patch/4757891/

 Probably belongs to 3.18 kernel series at this point in time.


I've no other patches for the GPIO OMAP driver for 3.18, could you
please pick this patch?

Thanks a lot and best regards,
Javier
--
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  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 1/2] Documentation: devicetree: mfd: twl4030-power: Use the standard 'ti,system-power-controller' to mark power control

[Lee Jones]

On Wed, 17 Sep 2014, Nishanth Menon wrote:

 ti,system-power-controller is more or less the standard way of
 indicating that the PMIC is the system wide power controller and hence
 may be used to switch off the system. Almost ALL TI PMIC drivers and
 many Maxim PMIC drivers follow the same style.
 
 So support 'ti,system-power-controller' in addition to the usual
 'ti,use_poweroff' to indicate that the PMIC instance has control for
 switching off the system.
 
 Signed-off-by: Nishanth Menon n...@ti.com
 ---
 
 V2: picked up documentation suggestion from Sebastien

It would be good to get Sebastian's Ack.

 V1: https://patchwork.kernel.org/patch/4836381/
 
  .../devicetree/bindings/mfd/twl4030-power.txt  |9 +++--
  1 file changed, 7 insertions(+), 2 deletions(-)
 
 diff --git a/Documentation/devicetree/bindings/mfd/twl4030-power.txt 
 b/Documentation/devicetree/bindings/mfd/twl4030-power.txt
 index b9ee7b9..a7390c7 100644
 --- a/Documentation/devicetree/bindings/mfd/twl4030-power.txt
 +++ b/Documentation/devicetree/bindings/mfd/twl4030-power.txt
 @@ -23,8 +23,13 @@ down during off-idle. Note that this does not work on all 
 boards
  depending on how the external oscillator is wired.
  
  Optional properties:
 -- ti,use_poweroff: With this flag, the chip will initiates an ACTIVE-to-OFF 
 or
 -SLEEP-to-OFF transition when the system poweroffs.
 +
 +- ti,system-power-controller: This indicates that TWL4030 is the
 +  power supply master of the system. With this flag, the chip will
 +  initiates an ACTIVE-to-OFF or SLEEP-to-OFF transition when the
 +  system poweroffs.
 +
 +- ti,use_poweroff: Deprecated name for ti,system-power-controller
  
  Example:
  i2c1 {

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] arm: omap2: n8x0: move i2c devices to DT

[Felipe Balbi]

On Wed, Sep 17, 2014 at 08:08:18AM -0700, Tony Lindgren wrote:
 * Felipe Balbi ba...@ti.com [140917 08:03]:
  On Wed, Sep 17, 2014 at 07:51:32AM -0700, Tony Lindgren wrote:
   * Felipe Balbi ba...@ti.com [140916 13:34]:
On Tue, Sep 16, 2014 at 03:31:40PM -0500, Felipe Balbi wrote:
 By moving i2c devices to DT we can clean up
 i2c_board_info and fix a problem with moving
 INTC to irq domain where IRQs can be renumbered
 on each boot.
 
 Cc: Aaro Koskinen aaro.koski...@iki.fi
 Signed-off-by: Felipe Balbi ba...@ti.com

note that this only causes problem for N8x0 because it boots in kinda of
a hybrid way, where it uses DT but not all peripherals are created
through DT.
   
   Thanks applying this into omap-for-v3.18/intc-v2.
  
  it might be better to apply this on your DT branch and merge DT before
  intc-v2, that might avoid a bisection problem.
 
 Yes it would have been nice to have this as a patch before preparing
 for intc-v2, but I did not have my n8x0 booting reliably because of
 xhci vs ehci issues on my PC and did not notice it early enough.
 
 I've already sent a pull request for the first part of intc-v2, so
 best to keep the related changes together in this case.

alright, no problems then.

-- 
balbi


signature.asc
Description: Digital signature

[PATCH v2] CLK: TI: consider the fact that of_clk_get() might return an error

[Sebastian Andrzej Siewior]

I forgot to update the dtb and the kernel crashed:
|Unable to handle kernel NULL pointer dereference at virtual address 002e
|PC is at __clk_get_flags+0x4/0xc
|LR is at ti_dt_clockdomains_setup+0x70/0xe8

because I did not have the clock nodes. of_clk_get() returns an error
pointer which is not checked here.

Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
v1…v2:
add %s __func__ to the added pr_err

* Nishanth Menon | 2014-09-17 07:52:33 [-0500]:

Could you add %s: __func__ as well - it kinda helps understand this
is part of clockdomain setup and not some driver cribbing that it did
not get some clock.

As you wish.

 drivers/clk/ti/clockdomain.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/clk/ti/clockdomain.c b/drivers/clk/ti/clockdomain.c
index f1e0038d76ac..446481166ce9 100644
--- a/drivers/clk/ti/clockdomain.c
+++ b/drivers/clk/ti/clockdomain.c
@@ -36,6 +36,12 @@ static void __init of_ti_clockdomain_setup(struct 
device_node *node)
 
for (i = 0; i  num_clks; i++) {
clk = of_clk_get(node, i);
+   if (IS_ERR(clk)) {
+   pr_err(%s: Failed get %s' clock nr %d (%ld)\n,
+   __func__, node-full_name, i,
+   PTR_ERR(clk));
+   continue;
+   }
if (__clk_get_flags(clk)  CLK_IS_BASIC) {
pr_warn(can't setup clkdm for basic clk %s\n,
__clk_get_name(clk));
-- 
2.1.0
--
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  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 09/16] tty: serial: 8250_dma: Add a TX trigger workaround for AM33xx

[Sebastian Andrzej Siewior]

On 09/17/2014 02:20 PM, Peter Hurley wrote:
 So I connected my am335x-evm
 with beagle board xm because both of them have an old fashion UART
 connector (instead those uart-to-usb). Both configured with HW-Flow and
 I haven't seen the function invoked but I saw port-icount.overrun
 being incremented. This shouldn't happen. So I am a little puzzled here…
 
 Yeah, that's weird. Do you have a break-out box to confirm that RTS/CTS are
 being driven?

Yeah, I've been thinking about that, too. I will be gone next week and
hopefully when I get back I will something around to test this.

 
 Regards,
 Peter Hurley
 

Sebastian
--
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  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 09/16] tty: serial: 8250_dma: Add a TX trigger workaround for AM33xx

[Sebastian Andrzej Siewior]

On 09/11/2014 01:42 PM, Sebastian Andrzej Siewior wrote:
 We should add hooks like tx_dma and rx_dma to struct uart_8250_dma so
 that the probe drivers can replace serial8250_tx_dma and
 seria8250_rx_dma, like I think Alan already suggested.
 
 Okay. Wasn't aware that Alan already suggested that.
 I also need a watchdog timer for TX since it seems that on omap3 the
 DMA engine suddenly forgets to continue with DMA…
 
 If this is really what we want, I would need to refactor a few things…
 
 Let's keep serial8250_tx_dma/rx_dma as the default, and not add any
 quirks to them. Only if there is a very common case should it be
 handled in those. The case of RX req needing to be sent before data in
 FIFO maybe one of those, but I'm no sure.
 
 keep in mind that both (RX  TX bugs/hacks) need also a bit of handling
 in the 8250-core so it works together (like the tx_err member so we
 fall back to manual xmit)

Done. I've kept the RX workarounds in the 8250_dma and moved the TX
part into the omap driver.
I needed to add the 8250_core pieces of patch #10 [0]. Now If you say,
couldn't this done in an other way then I could move the RX workarounds
pieces to the omap driver as well as the interrupt routine. Any
preferences?

[0] [PATCH 10/16] tty: serial: 8250_dma: optimize the xmit path due to
UART_BUG_DMA_TX

Sebastian

--
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  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] CLK: TI: consider the fact that of_clk_get() might return an error

[Nishanth Menon]

On 17:56-20140917, Sebastian Andrzej Siewior wrote:
 I forgot to update the dtb and the kernel crashed:
 |Unable to handle kernel NULL pointer dereference at virtual address 002e
 |PC is at __clk_get_flags+0x4/0xc
 |LR is at ti_dt_clockdomains_setup+0x70/0xe8
 
 because I did not have the clock nodes. of_clk_get() returns an error
 pointer which is not checked here.
 
 Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
 ---
 v1…v2:
 add %s __func__ to the added pr_err
 
 * Nishanth Menon | 2014-09-17 07:52:33 [-0500]:
 
 Could you add %s: __func__ as well - it kinda helps understand this
 is part of clockdomain setup and not some driver cribbing that it did
 not get some clock.
 
 As you wish.
 
  drivers/clk/ti/clockdomain.c | 6 ++
  1 file changed, 6 insertions(+)
 
 diff --git a/drivers/clk/ti/clockdomain.c b/drivers/clk/ti/clockdomain.c
 index f1e0038d76ac..446481166ce9 100644
 --- a/drivers/clk/ti/clockdomain.c
 +++ b/drivers/clk/ti/clockdomain.c
 @@ -36,6 +36,12 @@ static void __init of_ti_clockdomain_setup(struct 
 device_node *node)
  
   for (i = 0; i  num_clks; i++) {
   clk = of_clk_get(node, i);
 + if (IS_ERR(clk)) {
 + pr_err(%s: Failed get %s' clock nr %d (%ld)\n,
 + __func__, node-full_name, i,
 + PTR_ERR(clk));
 + continue;
 + }

Once the following is fixed (checkpatch --strict) feel free to add:
Acked-by: Nishanth Menon n...@ti.com

#65: FILE: drivers/clk/ti/clockdomain.c:35:
_node *node)

CHECK: Alignment should match open parenthesis
#71: FILE: drivers/clk/ti/clockdomain.c:40:
+   pr_err(%s: Failed get %s' clock nr %d (%ld)\n,
+   __func__, node-full_name, i,

total: 1 errors, 0 warnings, 1 checks, 16 lines checked


If any of these errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.

-- 
Regards,
Nishanth Menon
--
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  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 02/12] ARM: OMAP3: Use force-idle for UARTs because of DMA errata

[Paul Walmsley]

On Tue, 16 Sep 2014, Tony Lindgren wrote:

 For toggling the DMA vs PIO mode, that should be done with some Linux
 generic API from the driver. But since we don't have that, I don't think
 there's much overhead for always configuring for DMA mode. Or do you
 see some issues with that?

I think it should be OK.  Probably it would not be a case of additional 
overhead.  The impact would be on UART wakeup handling.  We'll just want 
to keep an eye on wakeups from characters received on the UART, and if 
those start flaking out occasionally, we might take a closer look at this 
patch.  

The race window, if it even exists, would be pretty narrow.  And the 
erratum usage note doesn't mention any impact on wakeups...  

 Yes great. I've verified that's enough to make it work properly with off-idle
 and dma when tested against Sebastian's uart_v10_pre1 branch.
 
 Updated patch below, thanks for catching the bogus configuration.

Cool, thanks for looking into those flags.

Reviewed-by: Paul Walmsley p...@pwsan.com


- Paul
--
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  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 1/2] Documentation: devicetree: mfd: twl4030-power: Use the standard 'ti,system-power-controller' to mark power control

[Sebastian Reichel]

On Wed, Sep 17, 2014 at 08:44:00AM -0700, Lee Jones wrote:
 On Wed, 17 Sep 2014, Nishanth Menon wrote:
  ti,system-power-controller is more or less the standard way of
  indicating that the PMIC is the system wide power controller and hence
  may be used to switch off the system. Almost ALL TI PMIC drivers and
  many Maxim PMIC drivers follow the same style.
  
  So support 'ti,system-power-controller' in addition to the usual
  'ti,use_poweroff' to indicate that the PMIC instance has control for
  switching off the system.
  
  Signed-off-by: Nishanth Menon n...@ti.com
  ---
  
  V2: picked up documentation suggestion from Sebastien
 
 It would be good to get Sebastian's Ack.

Acked-By: Sebastian Reichel s...@kernel.org

[...]

  +- ti,system-power-controller: This indicates that TWL4030 is the
  +  power supply master of the system. With this flag, the chip will
  +  initiates an ACTIVE-to-OFF or SLEEP-to-OFF transition when the
  +  system poweroffs.

One minor thing: While the documentation is updated you may want to
fix the typo will initiates to will initiate (or just drop the
will).

-- Sebastian


signature.asc
Description: Digital signature

Re: [PATCH V2 1/2] Documentation: devicetree: mfd: twl4030-power: Use the standard 'ti,system-power-controller' to mark power control

[Nishanth Menon]

On 18:55-20140917, Sebastian Reichel wrote:
 On Wed, Sep 17, 2014 at 08:44:00AM -0700, Lee Jones wrote:
  On Wed, 17 Sep 2014, Nishanth Menon wrote:
   ti,system-power-controller is more or less the standard way of
   indicating that the PMIC is the system wide power controller and hence
   may be used to switch off the system. Almost ALL TI PMIC drivers and
   many Maxim PMIC drivers follow the same style.
   
   So support 'ti,system-power-controller' in addition to the usual
   'ti,use_poweroff' to indicate that the PMIC instance has control for
   switching off the system.
   
   Signed-off-by: Nishanth Menon n...@ti.com
   ---
   
   V2: picked up documentation suggestion from Sebastien
  
  It would be good to get Sebastian's Ack.
 
 Acked-By: Sebastian Reichel s...@kernel.org

Thanks.
 
 [...]
 
   +- ti,system-power-controller: This indicates that TWL4030 is the
   +  power supply master of the system. With this flag, the chip will
   +  initiates an ACTIVE-to-OFF or SLEEP-to-OFF transition when the
   +  system poweroffs.
 
 One minor thing: While the documentation is updated you may want to
 fix the typo will initiates to will initiate (or just drop the
 will).

Updated v3 patch with your ack and correction to drop will below. I
will assume I wont need to repost the following update. Do let me know
if you'd like me to.

---8---
From ae3bcfc74080b14f9fd0178f6526bf8f34a8c865 Mon Sep 17 00:00:00 2001
From: Nishanth Menon n...@ti.com
Date: Wed, 3 Sep 2014 13:55:02 -0500
Subject: [PATCH V3 1/2 ] Documentation: devicetree: mfd: twl4030-power: Use the
 standard 'ti,system-power-controller' to mark power control

ti,system-power-controller is more or less the standard way of
indicating that the PMIC is the system wide power controller and hence
may be used to switch off the system. Almost ALL TI PMIC drivers and
many Maxim PMIC drivers follow the same style.

So support 'ti,system-power-controller' in addition to the usual
'ti,use_poweroff' to indicate that the PMIC instance has control for
switching off the system.

Signed-off-by: Nishanth Menon n...@ti.com
Acked-By: Sebastian Reichel s...@kernel.org
---
 .../devicetree/bindings/mfd/twl4030-power.txt  |9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/mfd/twl4030-power.txt 
b/Documentation/devicetree/bindings/mfd/twl4030-power.txt
index b9ee7b9..15a63e6 100644
--- a/Documentation/devicetree/bindings/mfd/twl4030-power.txt
+++ b/Documentation/devicetree/bindings/mfd/twl4030-power.txt
@@ -23,8 +23,13 @@ down during off-idle. Note that this does not work on all 
boards
 depending on how the external oscillator is wired.
 
 Optional properties:
-- ti,use_poweroff: With this flag, the chip will initiates an ACTIVE-to-OFF or
-  SLEEP-to-OFF transition when the system poweroffs.
+
+- ti,system-power-controller: This indicates that TWL4030 is the
+  power supply master of the system. With this flag, the chip
+  initiates an ACTIVE-to-OFF or SLEEP-to-OFF transition when the
+  system poweroffs.
+
+- ti,use_poweroff: Deprecated name for ti,system-power-controller
 
 Example:
 i2c1 {
-- 
1.7.9.5
-- 
Regards,
Nishanth Menon
--
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  http://vger.kernel.org/majordomo-info.html

[PATCH] MAINTAINERS: omap_hsmmc: remove myself from MAINTAINERS

[Balaji T K]

As I won't be able to maintain omap_hsmmc driver

Signed-off-by: Balaji T K balaji...@gmail.com
---
 MAINTAINERS | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 5e7866a..b296e43 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6540,10 +6540,9 @@ S:   Maintained
 F: drivers/mmc/host/omap.c
 
 OMAP HS MMC SUPPORT
-M: Balaji T K balaj...@ti.com
 L: linux-...@vger.kernel.org
 L: linux-omap@vger.kernel.org
-S: Maintained
+S: Orphan
 F: drivers/mmc/host/omap_hsmmc.c
 
 OMAP RANDOM NUMBER GENERATOR SUPPORT
-- 
1.9.1

--
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  http://vger.kernel.org/majordomo-info.html

bug on ftrace with v3.17-rc5

[Felipe Balbi]

Hi,

I just triggered a bug with trace by using tail on the trace file:

# tail trace
[ 2940.039229] Unable to handle kernel paging request at virtual address 
814efa9e
[ 2940.046904] pgd = ec3dc000
[ 2940.049737] [814efa9e] *pgd=
[ 2940.053552] Internal error: Oops: 5 [#1] SMP ARM
[ 2940.058379] Modules linked in: usb_f_acm u_serial g_serial usb_f_uac2 
libcomposite configfs xhci_hcd dwc3 udc_core matrix_keypad dwc3_omap 
lis3lv02d_i2c lis3lv02d input_polldev [last unloaded: g_audio]
[ 2940.077238] CPU: 0 PID: 3020 Comm: tail Tainted: GW
3.17.0-rc5-dirty #1097
[ 2940.085596] task: ed1b1040 ti: ed07c000 task.ti: ed07c000
[ 2940.091258] PC is at strnlen+0x18/0x68
[ 2940.095177] LR is at 0xfffe
[ 2940.098454] pc : [c0356df8]lr : [fffe]psr: a013
[ 2940.098454] sp : ed07ddb0  ip : ed07ddc0  fp : ed07ddbc
[ 2940.110445] r10: c070ff70  r9 : ed07de70  r8 : 
[ 2940.115906] r7 : 814efa9e  r6 :   r5 : ed4b6087  r4 : ed4b50c7
[ 2940.122726] r3 :   r2 : 814efa9e  r1 :   r0 : 814efa9e
[ 2940.129546] Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM Segment user
[ 2940.137000] Control: 10c5387d  Table: ac3dc059  DAC: 0015
[ 2940.143006] Process tail (pid: 3020, stack limit = 0xed07c248)
[ 2940.149098] Stack: (0xed07ddb0 to 0xed07e000)
[ 2940.153660] dda0: ed07dde4 ed07ddc0 
c0359628 c0356dec
[ 2940.162203] ddc0:  ed4b50c7 bf03ae9c ed4b6087 bf03ae9e 0002 
ed07de3c ed07dde8
[ 2940.170740] dde0: c035ab50 c0359600   ff0a  
ed07de30 ed4b5088
[ 2940.179275] de00: ed4b50c7 0fc0 ff0a0004  ed4b5088 ed4b5088 
 1000
[ 2940.187810] de20: 1008 0fc0 ed4b5088  ed07de68 ed07de40 
c00f1e64 c035a9c4
[ 2940.196341] de40: bf03dae0 ed07de70 ed4b4000 ec25b280 ed4b4000 ec25b280 
bf03dae0 ed07de9c
[ 2940.204886] de60: ed07de78 bf033324 c00f1e0c bf03ae9c 814efa9e ed428bc0 
814eca3e 
[ 2940.213428] de80: 814eba3e ed4b4000 03bd1201 c0c34790 ed07ded4 ed07dea0 
c00edc0c bf0332d0
[ 2940.221994] dea0: 02c7 ed07df10 ed07decc ed07deb8 ed4b4000 209c 
ec278ac0 
[ 2940.230536] dec0: 2000 ec0db340 ed07def4 ed07ded8 c00ee7ec c00eda90 
c00ee7b0 ec278ac0
[ 2940.239075] dee0: ed4b4000 02d5 ed07df44 ed07def8 c018b8d0 c00ee7bc 
c0166d3c ec278af0
[ 2940.247621] df00: 0001f090 ed07df78 02c7  02c8  
 ec0db340
[ 2940.256173] df20: 0001f090 ed07df78 ec0db340 2000 0001f090  
ed07df74 ed07df48
[ 2940.264729] df40: c0166e98 c018b5f4 0001 c018535c 000168c1  
ec0db340 ec0db340
[ 2940.273284] df60: 2000 0001f090 ed07dfa4 ed07df78 c01675c4 c0166e0c 
000168c1 
[ 2940.281829] df80: 2000 000a 0001f090 0003 c000f064 ed07c000 
 ed07dfa8
[ 2940.290365] dfa0: c000ede0 c0167584 2000 000a 0003 0001f090 
2000 
[ 2940.298909] dfc0: 2000 000a 0001f090 0003 7fffe000 0001e1e0 
2004 002f
[ 2940.307445] dfe0:  beed38ec 000104c8 b6e6397c 4010 0003 
 
[ 2940.315992] [c0356df8] (strnlen) from [c0359628] 
(string.isra.8+0x34/0xe8)
[ 2940.323534] [c0359628] (string.isra.8) from [c035ab50] 
(vsnprintf+0x198/0x3fc)
[ 2940.331461] [c035ab50] (vsnprintf) from [c00f1e64] 
(trace_seq_printf+0x68/0x94)
[ 2940.339494] [c00f1e64] (trace_seq_printf) from [bf033324] 
(ftrace_raw_output_dwc3_log_request+0x60/0x78 [dwc3])
[ 2940.350424] [bf033324] (ftrace_raw_output_dwc3_log_request [dwc3]) from 
[c00edc0c] (print_trace_line+0x188/0x418)
[ 2940.361507] [c00edc0c] (print_trace_line) from [c00ee7ec] 
(s_show+0x3c/0x12c)
[ 2940.369330] [c00ee7ec] (s_show) from [c018b8d0] (seq_read+0x2e8/0x4a0)
[ 2940.376519] [c018b8d0] (seq_read) from [c0166e98] (vfs_read+0x98/0x158)
[ 2940.383796] [c0166e98] (vfs_read) from [c01675c4] (SyS_read+0x4c/0xa0)
[ 2940.390981] [c01675c4] (SyS_read) from [c000ede0] 
(ret_fast_syscall+0x0/0x48)
[ 2940.398792] Code: e24cb004 e351 e241e001 0a11 (e5d01000) 
[ 2940.406980] ---[ end trace d8b38370fbb531f3 ]---

This is basically v3.17-rc5 with some USB patches I'm testing for v3.18,
including a patch where I added tracepoints to dwc3 [1]

[1] 
https://git.kernel.org/cgit/linux/kernel/git/balbi/usb.git/commit/?h=nextid=2c4cbe6e5a9c71408b496e00a78ea9284e98af16

-- 
balbi


signature.asc
Description: Digital signature

Re: bug on ftrace with v3.17-rc5

[Felipe Balbi]

Hi,

On Wed, Sep 17, 2014 at 12:22:11PM -0500, Felipe Balbi wrote:
 I just triggered a bug with trace by using tail on the trace file:
 
 # tail trace
 [ 2940.039229] Unable to handle kernel paging request at virtual address 
 814efa9e
 [ 2940.046904] pgd = ec3dc000
 [ 2940.049737] [814efa9e] *pgd=
 [ 2940.053552] Internal error: Oops: 5 [#1] SMP ARM
 [ 2940.058379] Modules linked in: usb_f_acm u_serial g_serial usb_f_uac2 
 libcomposite configfs xhci_hcd dwc3 udc_core matrix_keypad dwc3_omap 
 lis3lv02d_i2c lis3lv02d input_polldev [last unloaded: g_audio]
 [ 2940.077238] CPU: 0 PID: 3020 Comm: tail Tainted: GW
 3.17.0-rc5-dirty #1097
 [ 2940.085596] task: ed1b1040 ti: ed07c000 task.ti: ed07c000
 [ 2940.091258] PC is at strnlen+0x18/0x68
 [ 2940.095177] LR is at 0xfffe
 [ 2940.098454] pc : [c0356df8]lr : [fffe]psr: a013
 [ 2940.098454] sp : ed07ddb0  ip : ed07ddc0  fp : ed07ddbc
 [ 2940.110445] r10: c070ff70  r9 : ed07de70  r8 : 
 [ 2940.115906] r7 : 814efa9e  r6 :   r5 : ed4b6087  r4 : ed4b50c7
 [ 2940.122726] r3 :   r2 : 814efa9e  r1 :   r0 : 814efa9e
 [ 2940.129546] Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM Segment 
 user
 [ 2940.137000] Control: 10c5387d  Table: ac3dc059  DAC: 0015
 [ 2940.143006] Process tail (pid: 3020, stack limit = 0xed07c248)
 [ 2940.149098] Stack: (0xed07ddb0 to 0xed07e000)
 [ 2940.153660] dda0: ed07dde4 ed07ddc0 
 c0359628 c0356dec
 [ 2940.162203] ddc0:  ed4b50c7 bf03ae9c ed4b6087 bf03ae9e 0002 
 ed07de3c ed07dde8
 [ 2940.170740] dde0: c035ab50 c0359600   ff0a  
 ed07de30 ed4b5088
 [ 2940.179275] de00: ed4b50c7 0fc0 ff0a0004  ed4b5088 ed4b5088 
  1000
 [ 2940.187810] de20: 1008 0fc0 ed4b5088  ed07de68 ed07de40 
 c00f1e64 c035a9c4
 [ 2940.196341] de40: bf03dae0 ed07de70 ed4b4000 ec25b280 ed4b4000 ec25b280 
 bf03dae0 ed07de9c
 [ 2940.204886] de60: ed07de78 bf033324 c00f1e0c bf03ae9c 814efa9e ed428bc0 
 814eca3e 
 [ 2940.213428] de80: 814eba3e ed4b4000 03bd1201 c0c34790 ed07ded4 ed07dea0 
 c00edc0c bf0332d0
 [ 2940.221994] dea0: 02c7 ed07df10 ed07decc ed07deb8 ed4b4000 209c 
 ec278ac0 
 [ 2940.230536] dec0: 2000 ec0db340 ed07def4 ed07ded8 c00ee7ec c00eda90 
 c00ee7b0 ec278ac0
 [ 2940.239075] dee0: ed4b4000 02d5 ed07df44 ed07def8 c018b8d0 c00ee7bc 
 c0166d3c ec278af0
 [ 2940.247621] df00: 0001f090 ed07df78 02c7  02c8  
  ec0db340
 [ 2940.256173] df20: 0001f090 ed07df78 ec0db340 2000 0001f090  
 ed07df74 ed07df48
 [ 2940.264729] df40: c0166e98 c018b5f4 0001 c018535c 000168c1  
 ec0db340 ec0db340
 [ 2940.273284] df60: 2000 0001f090 ed07dfa4 ed07df78 c01675c4 c0166e0c 
 000168c1 
 [ 2940.281829] df80: 2000 000a 0001f090 0003 c000f064 ed07c000 
  ed07dfa8
 [ 2940.290365] dfa0: c000ede0 c0167584 2000 000a 0003 0001f090 
 2000 
 [ 2940.298909] dfc0: 2000 000a 0001f090 0003 7fffe000 0001e1e0 
 2004 002f
 [ 2940.307445] dfe0:  beed38ec 000104c8 b6e6397c 4010 0003 
  
 [ 2940.315992] [c0356df8] (strnlen) from [c0359628] 
 (string.isra.8+0x34/0xe8)
 [ 2940.323534] [c0359628] (string.isra.8) from [c035ab50] 
 (vsnprintf+0x198/0x3fc)
 [ 2940.331461] [c035ab50] (vsnprintf) from [c00f1e64] 
 (trace_seq_printf+0x68/0x94)
 [ 2940.339494] [c00f1e64] (trace_seq_printf) from [bf033324] 
 (ftrace_raw_output_dwc3_log_request+0x60/0x78 [dwc3])
 [ 2940.350424] [bf033324] (ftrace_raw_output_dwc3_log_request [dwc3]) from 
 [c00edc0c] (print_trace_line+0x188/0x418)
 [ 2940.361507] [c00edc0c] (print_trace_line) from [c00ee7ec] 
 (s_show+0x3c/0x12c)
 [ 2940.369330] [c00ee7ec] (s_show) from [c018b8d0] (seq_read+0x2e8/0x4a0)
 [ 2940.376519] [c018b8d0] (seq_read) from [c0166e98] (vfs_read+0x98/0x158)
 [ 2940.383796] [c0166e98] (vfs_read) from [c01675c4] (SyS_read+0x4c/0xa0)
 [ 2940.390981] [c01675c4] (SyS_read) from [c000ede0] 
 (ret_fast_syscall+0x0/0x48)
 [ 2940.398792] Code: e24cb004 e351 e241e001 0a11 (e5d01000) 
 [ 2940.406980] ---[ end trace d8b38370fbb531f3 ]---
 
 This is basically v3.17-rc5 with some USB patches I'm testing for v3.18,
 including a patch where I added tracepoints to dwc3 [1]
 
 [1] 
 https://git.kernel.org/cgit/linux/kernel/git/balbi/usb.git/commit/?h=nextid=2c4cbe6e5a9c71408b496e00a78ea9284e98af16

btw, I've tracing for quite a while (over 20 minutes) without any
issues, until this came out.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH] clk: prevent erronous parsing of children during rate change

[Felipe Balbi]

Hi Mike,

On Wed, Sep 03, 2014 at 12:22:03PM -0700, Mike Turquette wrote:
 Quoting Tero Kristo (2014-08-21 06:47:45)
  In some cases, clocks can switch their parent with clk_set_rate, for
  example clk_mux can do this in some cases. Current implementation of
  clk_change_rate uses un-safe list iteration on the clock children, which
  will cause wrong clocks to be parsed in case any of the clock children
  change their parents during the change rate operation. Fixed by using
  the safe list iterator instead.
  
  The problem was detected due to some divide by zero errors generated
  by clock init on dra7-evm board, see discussion under
  http://article.gmane.org/gmane.linux.ports.arm.kernel/349180 for details.
  
  Signed-off-by: Tero Kristo t-kri...@ti.com
  To: Mike Turquette mturque...@linaro.org
  Reported-by: Nishanth Menon n...@ti.com
 
 Applied to clk-fixes.

v3.17-rc5 and today's next still exhibit the same bug. Any chance we can
this fix into v3.17-final ?

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v3 0/2] dmaengine: omap-dma: Fix cyclic suspend/resume

[Peter Ujfalusi]

Vinod,

On 09/16/2014 10:45 PM, Peter Ujfalusi wrote:
 Hi,
 
 Changes since v2:
 - fix typo in patch two
 - Acked-by added from Russell
 
 When the audio is paused/resumed (application paused the sream or board 
 suspend)
 the audio was only playing back one period worth of data and then stops 
 because
 the omap_dam_stop() clears the link configuration and it is not restored in
 start.
 
 Also add memory barrier call to resume path since this could happen right 
 after
 coming out from suspend.

Would it be possible to queue this two patch for 3.17?
This stop/start issue affects not only board suspend/resume, but in all cases
when application pauses the stream as well when we have underrun in ALSA
which would not trigger a full stop and start of audio.

Thanks,
Péter

 Regards,
 Peter
 ---
 Peter Ujfalusi (2):
   dmaengine: omap-dma: Add memory barrier to dma_resume path
   dmaengine: omap-dma: Restore the CLINK_CTRL in resume path
 
  drivers/dma/omap-dma.c | 5 +
  1 file changed, 5 insertions(+)
 


--
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  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 08/10] ARM: OMAP5/DRA7: PM: cpuidle MPU CSWR support

[Daniel Lezcano]

On 08/22/2014 07:02 AM, Nishanth Menon wrote:

From: Santosh Shilimkar santosh.shilim...@ti.com

Add OMAP5/DRA74/72 CPUIDLE support.

This patch adds MPUSS low power states in cpuidle.

 C1 - CPU0 WFI + CPU1 WFI + MPU ON
 C2 - CPU0 RET + CPU1 RET + MPU CSWR

Tested on DRA74/72-EVM for C1 and C2 states.

NOTE: DRA7 does not do voltage scaling as part of retention transition
and has Mercury which speeds up transition paths - Latency numbers are
based on measurements done by toggling GPIOs.

Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
[ j-keer...@ti.com rework on 3.14]
Signed-off-by: Keerthy j-keer...@ti.com
[n...@ti.com: updates based on profiling, OMAP5 squashed]
Signed-off-by: Nishanth Menon n...@ti.com
---
  arch/arm/mach-omap2/cpuidle44xx.c |   82 -
  arch/arm/mach-omap2/pm44xx.c  |2 +-
  2 files changed, 82 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/cpuidle44xx.c 
b/arch/arm/mach-omap2/cpuidle44xx.c
index 2498ab0..8ad4f44 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -22,6 +22,7 @@
  #include common.h
  #include pm.h
  #include prm.h
+#include soc.h
  #include clockdomain.h

  #define MAX_CPUS  2
@@ -31,6 +32,7 @@ struct idle_statedata {
u32 cpu_state;
u32 mpu_logic_state;
u32 mpu_state;
+   u32 mpu_state_vote;
  };

  static struct idle_statedata omap4_idle_data[] = {
@@ -51,12 +53,26 @@ static struct idle_statedata omap4_idle_data[] = {
},
  };

+static struct idle_statedata dra7_idle_data[] = {
+   {
+   .cpu_state = PWRDM_POWER_ON,
+   .mpu_state = PWRDM_POWER_ON,
+   .mpu_logic_state = PWRDM_POWER_ON,
+   },
+   {
+   .cpu_state = PWRDM_POWER_RET,
+   .mpu_state = PWRDM_POWER_RET,
+   .mpu_logic_state = PWRDM_POWER_RET,
+   },
+};
+
  static struct powerdomain *mpu_pd, *cpu_pd[MAX_CPUS];
  static struct clockdomain *cpu_clkdm[MAX_CPUS];

  static atomic_t abort_barrier;
  static bool cpu_done[MAX_CPUS];
  static struct idle_statedata *state_ptr = omap4_idle_data[0];
+static DEFINE_RAW_SPINLOCK(mpu_lock);

  /* Private functions */

@@ -78,6 +94,32 @@ static int omap_enter_idle_simple(struct cpuidle_device *dev,
return index;
  }

+static int omap_enter_idle_smp(struct cpuidle_device *dev,
+  struct cpuidle_driver *drv,
+  int index)
+{
+   struct idle_statedata *cx = state_ptr + index;
+   unsigned long flag;
+
+   raw_spin_lock_irqsave(mpu_lock, flag);


Why do you need this spin_lock_irqsave ? Aren't the local irqs already 
disabled ?



+   cx-mpu_state_vote++;
+   if (cx-mpu_state_vote == num_online_cpus()) {
+   pwrdm_set_logic_retst(mpu_pd, cx-mpu_logic_state);
+   omap_set_pwrdm_state(mpu_pd, cx-mpu_state);
+   }
+   raw_spin_unlock_irqrestore(mpu_lock, flag);
+
+   omap4_enter_lowpower(dev-cpu, cx-cpu_state);
+
+   raw_spin_lock_irqsave(mpu_lock, flag);
+   if (cx-mpu_state_vote == num_online_cpus())
+   omap_set_pwrdm_state(mpu_pd, PWRDM_POWER_ON);
+   cx-mpu_state_vote--;
+   raw_spin_unlock_irqrestore(mpu_lock, flag);


I am not sure that will work. What happens if a cpu exits idle and then 
re-enter idle immediately ?


Could you try a long run of this little program:

https://git.linaro.org/power/pm-qa.git/blob/HEAD:/cpuidle/cpuidle_killer.c


+   return index;
+}
+
  static int omap_enter_idle_coupled(struct cpuidle_device *dev,
struct cpuidle_driver *drv,
int index)
@@ -224,6 +266,34 @@ static struct cpuidle_driver omap4_idle_driver = {
.safe_state_index = 0,
  };

+static struct cpuidle_driver dra7_idle_driver = {
+   .name   = dra7_idle,
+   .owner  = THIS_MODULE,
+   .states = {
+   {
+   /* C1 - CPU0 ON + CPU1 ON + MPU ON */
+   .exit_latency = 2 + 2,
+   .target_residency = 5,
+   .flags = CPUIDLE_FLAG_TIME_VALID,
+   .enter = omap_enter_idle_simple,
+   .name = C1,
+   .desc = CPUx WFI, MPUSS ON
+   },
+   {
+   /* C2 - CPU0 RET + CPU1 RET + MPU CSWR */
+   .exit_latency = 48 + 60,
+   .target_residency = 100,
+   .flags = CPUIDLE_FLAG_TIME_VALID
+   | CPUIDLE_FLAG_TIMER_STOP,
+   .enter = omap_enter_idle_smp,
+   .name = C2,
+   .desc = CPUx CSWR, MPUSS CSWR,
+   },
+   },
+   .state_count = ARRAY_SIZE(dra7_idle_data),
+   .safe_state_index = 0,
+};
+
  /* Public functions */

  

Re: [PATCH v3 4/5] ASoC: davinci: HDMI audio build for AM33XX and TDA998x

[Mark Brown]

On Tue, Sep 16, 2014 at 11:40:17PM +0300, Jyri Sarha wrote:
 Adds configuration option for HDMI audio support for AM33XX based
 boards with NXP TDA998x HDMI transmitter. The audio is connected to
 NXP TDA998x trough McASP running in i2s mode.

So, Jean-Francois is also trying to do things with the TDA998x - what's
the story with that, is this joined up at all?


signature.asc
Description: Digital signature

[PATCH] arm: arm: fiq: fix build breakage with CONFIG_FIQ

[Felipe Balbi]

commit e1add97 (ARM: 8150/2: fiq: Replace default FIQ handler)
has a typo which causes build breakage whenever CONFIG_FIQ is
set.

The bug is very clear as can be noted that a new struct pt_regs
def_fiq_regs was defined but code uses dfl_fiq_regs.

Cc: Daniel Thompson daniel.thomp...@linaro.org
Cc: Catalin Marinas catalin.mari...@arm.com
Cc: Nicolas Pitre n...@linaro.org
Fixes: e1add97 (ARM: 8150/2: fiq: Replace default FIQ handler)
Signed-off-by: Felipe Balbi ba...@ti.com
---

KernelVersion: next-20140917

Russell, let me know if this is the correct KernelVersion tag you want/need

 arch/arm/kernel/fiq.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/kernel/fiq.c b/arch/arm/kernel/fiq.c
index 1743049..b6ab4c7 100644
--- a/arch/arm/kernel/fiq.c
+++ b/arch/arm/kernel/fiq.c
@@ -64,7 +64,7 @@ static int fiq_def_op(void *ref, int relinquish)
if (!relinquish) {
/* Restore default handler and registers */
local_fiq_disable();
-   set_fiq_regs(dfl_fiq_regs);
+   set_fiq_regs(def_fiq_regs);
set_fiq_handler(no_fiq_insn, sizeof(no_fiq_insn));
local_fiq_enable();
 
@@ -159,6 +159,6 @@ void __init init_FIQ(int start)
 {
unsigned offset = FIQ_OFFSET;
no_fiq_insn = *(unsigned long *)(0x + offset);
-   get_fiq_regs(dfl_fiq_regs);
+   get_fiq_regs(def_fiq_regs);
fiq_start = start;
 }
-- 
2.1.0.243.g30d45f7

--
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  http://vger.kernel.org/majordomo-info.html

Re: bug on ftrace with v3.17-rc5

[Steven Rostedt]

On Wed, 17 Sep 2014 12:22:11 -0500
Felipe Balbi ba...@ti.com wrote:

 Hi,
 
 I just triggered a bug with trace by using tail on the trace file:
 
 # tail trace
 [ 2940.039229] Unable to handle kernel paging request at virtual address 
 814efa9e
 [ 2940.046904] pgd = ec3dc000
 [ 2940.049737] [814efa9e] *pgd=
 [ 2940.053552] Internal error: Oops: 5 [#1] SMP ARM
 [ 2940.058379] Modules linked in: usb_f_acm u_serial g_serial usb_f_uac2 
 libcomposite configfs xhci_hcd dwc3 udc_core matrix_keypad dwc3_omap 
 lis3lv02d_i2c lis3lv02d input_polldev [last unloaded: g_audio]
 [ 2940.077238] CPU: 0 PID: 3020 Comm: tail Tainted: GW
 3.17.0-rc5-dirty #1097
 [ 2940.085596] task: ed1b1040 ti: ed07c000 task.ti: ed07c000
 [ 2940.091258] PC is at strnlen+0x18/0x68
 [ 2940.095177] LR is at 0xfffe
 [ 2940.098454] pc : [c0356df8]lr : [fffe]psr: a013
 [ 2940.098454] sp : ed07ddb0  ip : ed07ddc0  fp : ed07ddbc
 [ 2940.110445] r10: c070ff70  r9 : ed07de70  r8 : 
 [ 2940.115906] r7 : 814efa9e  r6 :   r5 : ed4b6087  r4 : ed4b50c7
 [ 2940.122726] r3 :   r2 : 814efa9e  r1 :   r0 : 814efa9e
 [ 2940.129546] Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM Segment 
 user
 [ 2940.137000] Control: 10c5387d  Table: ac3dc059  DAC: 0015
 [ 2940.143006] Process tail (pid: 3020, stack limit = 0xed07c248)
 [ 2940.149098] Stack: (0xed07ddb0 to 0xed07e000)
 [ 2940.153660] dda0: ed07dde4 ed07ddc0 
 c0359628 c0356dec
 [ 2940.162203] ddc0:  ed4b50c7 bf03ae9c ed4b6087 bf03ae9e 0002 
 ed07de3c ed07dde8
 [ 2940.170740] dde0: c035ab50 c0359600   ff0a  
 ed07de30 ed4b5088
 [ 2940.179275] de00: ed4b50c7 0fc0 ff0a0004  ed4b5088 ed4b5088 
  1000
 [ 2940.187810] de20: 1008 0fc0 ed4b5088  ed07de68 ed07de40 
 c00f1e64 c035a9c4
 [ 2940.196341] de40: bf03dae0 ed07de70 ed4b4000 ec25b280 ed4b4000 ec25b280 
 bf03dae0 ed07de9c
 [ 2940.204886] de60: ed07de78 bf033324 c00f1e0c bf03ae9c 814efa9e ed428bc0 
 814eca3e 
 [ 2940.213428] de80: 814eba3e ed4b4000 03bd1201 c0c34790 ed07ded4 ed07dea0 
 c00edc0c bf0332d0
 [ 2940.221994] dea0: 02c7 ed07df10 ed07decc ed07deb8 ed4b4000 209c 
 ec278ac0 
 [ 2940.230536] dec0: 2000 ec0db340 ed07def4 ed07ded8 c00ee7ec c00eda90 
 c00ee7b0 ec278ac0
 [ 2940.239075] dee0: ed4b4000 02d5 ed07df44 ed07def8 c018b8d0 c00ee7bc 
 c0166d3c ec278af0
 [ 2940.247621] df00: 0001f090 ed07df78 02c7  02c8  
  ec0db340
 [ 2940.256173] df20: 0001f090 ed07df78 ec0db340 2000 0001f090  
 ed07df74 ed07df48
 [ 2940.264729] df40: c0166e98 c018b5f4 0001 c018535c 000168c1  
 ec0db340 ec0db340
 [ 2940.273284] df60: 2000 0001f090 ed07dfa4 ed07df78 c01675c4 c0166e0c 
 000168c1 
 [ 2940.281829] df80: 2000 000a 0001f090 0003 c000f064 ed07c000 
  ed07dfa8
 [ 2940.290365] dfa0: c000ede0 c0167584 2000 000a 0003 0001f090 
 2000 
 [ 2940.298909] dfc0: 2000 000a 0001f090 0003 7fffe000 0001e1e0 
 2004 002f
 [ 2940.307445] dfe0:  beed38ec 000104c8 b6e6397c 4010 0003 
  
 [ 2940.315992] [c0356df8] (strnlen) from [c0359628] 
 (string.isra.8+0x34/0xe8)
 [ 2940.323534] [c0359628] (string.isra.8) from [c035ab50] 
 (vsnprintf+0x198/0x3fc)
 [ 2940.331461] [c035ab50] (vsnprintf) from [c00f1e64] 
 (trace_seq_printf+0x68/0x94)
 [ 2940.339494] [c00f1e64] (trace_seq_printf) from [bf033324] 
 (ftrace_raw_output_dwc3_log_request+0x60/0x78 [dwc3])
 [ 2940.350424] [bf033324] (ftrace_raw_output_dwc3_log_request [dwc3]) from 
 [c00edc0c] (print_trace_line+0x188/0x418)

This shows it bugging with your tracepoint dwc3_log_request.

+DECLARE_EVENT_CLASS(dwc3_log_request,
+ TP_PROTO(struct dwc3_request *req),
+ TP_ARGS(req),
+ TP_STRUCT__entry(
+ __field(struct dwc3_request *, req)
+ ),
+ TP_fast_assign(
+ __entry-req = req;
+ ),
+ TP_printk(%s: req %p length %u/%u == %d,
+ __entry-req-dep-name, __entry-req,
+ __entry-req-request.actual, __entry-req-request.length,
+ __entry-req-request.status
+ )
+);

(Bah, cut and paste from the git web page doesn't format nicely)

Anyway, I take issues with that: __entry-req-request.length,
and all the other __entry-req-*

Basically, you saved a pointer in the buffer called req and than you
dereference it when you are printing. Does that pointer still exist?

If whatever you assigned req to gets freed, you can not dereference
it from the buffer! If you need to save the length and other fields, you
need to do it in the fast assign.

-- Steve



 [ 2940.361507] [c00edc0c] (print_trace_line) from [c00ee7ec] 
 (s_show+0x3c/0x12c)
 [ 2940.369330] [c00ee7ec] (s_show) from [c018b8d0] (seq_read+0x2e8/0x4a0)
 [ 2940.376519] [c018b8d0] (seq_read) from [c0166e98] (vfs_read+0x98/0x158)
 [ 2940.383796] [c0166e98] (vfs_read) from [c01675c4] (SyS_read+0x4c/0xa0)
 [ 2940.390981] [c01675c4] 

Re: bug on ftrace with v3.17-rc5

[Felipe Balbi]

Hi,

On Wed, Sep 17, 2014 at 04:42:11PM -0400, Steven Rostedt wrote:
 On Wed, 17 Sep 2014 12:22:11 -0500
 Felipe Balbi ba...@ti.com wrote:
 
  Hi,
  
  I just triggered a bug with trace by using tail on the trace file:
  
  # tail trace
  [ 2940.039229] Unable to handle kernel paging request at virtual address 
  814efa9e
  [ 2940.046904] pgd = ec3dc000
  [ 2940.049737] [814efa9e] *pgd=
  [ 2940.053552] Internal error: Oops: 5 [#1] SMP ARM
  [ 2940.058379] Modules linked in: usb_f_acm u_serial g_serial usb_f_uac2 
  libcomposite configfs xhci_hcd dwc3 udc_core matrix_keypad dwc3_omap 
  lis3lv02d_i2c lis3lv02d input_polldev [last unloaded: g_audio]
  [ 2940.077238] CPU: 0 PID: 3020 Comm: tail Tainted: GW
  3.17.0-rc5-dirty #1097
  [ 2940.085596] task: ed1b1040 ti: ed07c000 task.ti: ed07c000
  [ 2940.091258] PC is at strnlen+0x18/0x68
  [ 2940.095177] LR is at 0xfffe
  [ 2940.098454] pc : [c0356df8]lr : [fffe]psr: a013
  [ 2940.098454] sp : ed07ddb0  ip : ed07ddc0  fp : ed07ddbc
  [ 2940.110445] r10: c070ff70  r9 : ed07de70  r8 : 
  [ 2940.115906] r7 : 814efa9e  r6 :   r5 : ed4b6087  r4 : ed4b50c7
  [ 2940.122726] r3 :   r2 : 814efa9e  r1 :   r0 : 814efa9e
  [ 2940.129546] Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM Segment 
  user
  [ 2940.137000] Control: 10c5387d  Table: ac3dc059  DAC: 0015
  [ 2940.143006] Process tail (pid: 3020, stack limit = 0xed07c248)
  [ 2940.149098] Stack: (0xed07ddb0 to 0xed07e000)
  [ 2940.153660] dda0: ed07dde4 ed07ddc0 
  c0359628 c0356dec
  [ 2940.162203] ddc0:  ed4b50c7 bf03ae9c ed4b6087 bf03ae9e 0002 
  ed07de3c ed07dde8
  [ 2940.170740] dde0: c035ab50 c0359600   ff0a  
  ed07de30 ed4b5088
  [ 2940.179275] de00: ed4b50c7 0fc0 ff0a0004  ed4b5088 ed4b5088 
   1000
  [ 2940.187810] de20: 1008 0fc0 ed4b5088  ed07de68 ed07de40 
  c00f1e64 c035a9c4
  [ 2940.196341] de40: bf03dae0 ed07de70 ed4b4000 ec25b280 ed4b4000 ec25b280 
  bf03dae0 ed07de9c
  [ 2940.204886] de60: ed07de78 bf033324 c00f1e0c bf03ae9c 814efa9e ed428bc0 
  814eca3e 
  [ 2940.213428] de80: 814eba3e ed4b4000 03bd1201 c0c34790 ed07ded4 ed07dea0 
  c00edc0c bf0332d0
  [ 2940.221994] dea0: 02c7 ed07df10 ed07decc ed07deb8 ed4b4000 209c 
  ec278ac0 
  [ 2940.230536] dec0: 2000 ec0db340 ed07def4 ed07ded8 c00ee7ec c00eda90 
  c00ee7b0 ec278ac0
  [ 2940.239075] dee0: ed4b4000 02d5 ed07df44 ed07def8 c018b8d0 c00ee7bc 
  c0166d3c ec278af0
  [ 2940.247621] df00: 0001f090 ed07df78 02c7  02c8  
   ec0db340
  [ 2940.256173] df20: 0001f090 ed07df78 ec0db340 2000 0001f090  
  ed07df74 ed07df48
  [ 2940.264729] df40: c0166e98 c018b5f4 0001 c018535c 000168c1  
  ec0db340 ec0db340
  [ 2940.273284] df60: 2000 0001f090 ed07dfa4 ed07df78 c01675c4 c0166e0c 
  000168c1 
  [ 2940.281829] df80: 2000 000a 0001f090 0003 c000f064 ed07c000 
   ed07dfa8
  [ 2940.290365] dfa0: c000ede0 c0167584 2000 000a 0003 0001f090 
  2000 
  [ 2940.298909] dfc0: 2000 000a 0001f090 0003 7fffe000 0001e1e0 
  2004 002f
  [ 2940.307445] dfe0:  beed38ec 000104c8 b6e6397c 4010 0003 
   
  [ 2940.315992] [c0356df8] (strnlen) from [c0359628] 
  (string.isra.8+0x34/0xe8)
  [ 2940.323534] [c0359628] (string.isra.8) from [c035ab50] 
  (vsnprintf+0x198/0x3fc)
  [ 2940.331461] [c035ab50] (vsnprintf) from [c00f1e64] 
  (trace_seq_printf+0x68/0x94)
  [ 2940.339494] [c00f1e64] (trace_seq_printf) from [bf033324] 
  (ftrace_raw_output_dwc3_log_request+0x60/0x78 [dwc3])
  [ 2940.350424] [bf033324] (ftrace_raw_output_dwc3_log_request [dwc3]) 
  from [c00edc0c] (print_trace_line+0x188/0x418)
 
 This shows it bugging with your tracepoint dwc3_log_request.
 
 +DECLARE_EVENT_CLASS(dwc3_log_request,
 + TP_PROTO(struct dwc3_request *req),
 + TP_ARGS(req),
 + TP_STRUCT__entry(
 + __field(struct dwc3_request *, req)
 + ),
 + TP_fast_assign(
 + __entry-req = req;
 + ),
 + TP_printk(%s: req %p length %u/%u == %d,
 + __entry-req-dep-name, __entry-req,
 + __entry-req-request.actual, __entry-req-request.length,
 + __entry-req-request.status
 + )
 +);
 
 (Bah, cut and paste from the git web page doesn't format nicely)
 
 Anyway, I take issues with that: __entry-req-request.length,
 and all the other __entry-req-*
 
 Basically, you saved a pointer in the buffer called req and than you
 dereference it when you are printing. Does that pointer still exist?
 
 If whatever you assigned req to gets freed, you can not dereference
 it from the buffer! If you need to save the length and other fields, you
 need to do it in the fast assign.

good point, completely missed the fact that req could be long gone. I'll
go think of a better way to do this and get it fixed during the -rc. The
bad thing is that I really still 

Re: [PATCH v3 4/5] ASoC: davinci: HDMI audio build for AM33XX and TDA998x

[Jyri Sarha]

On 09/17/2014 10:41 PM, Mark Brown wrote:

On Tue, Sep 16, 2014 at 11:40:17PM +0300, Jyri Sarha wrote:

Adds configuration option for HDMI audio support for AM33XX based
boards with NXP TDA998x HDMI transmitter. The audio is connected to
NXP TDA998x trough McASP running in i2s mode.


So, Jean-Francois is also trying to do things with the TDA998x - what's
the story with that, is this joined up at all?



Not really. This basic functionality does not touch tda998x at all on 
the fly, but just sets i2s configuation in the beginning and bangs the 
bits trough McASP. But as long as the old platform data for tda998x 
still works after Jean-Francois' patches I should be safe.


The problem with the Jean-Francois' patches is the DT support. The BBB 
HDMI video is implemented trough tilcdc-slave mechanism without a DT 
node for the tda encoder, which renders Jean-Francois' approach unusable 
for BBB.


The whole tilcdc slave approach may not be the most elegant way to use 
the tda driver, but it does not look like it is going to change any time 
soon.


Best regards,
Jyri

ps. I have been thinking on something similar to Jean-Francois' patch 
for SiI9022 which I have been working on lately. Also I have been 
wondering if it would be possible to come up with a generic ASoC codec 
component driver or library that could be used with any HDMI encoder to 
produce the ASoC codec component. Unfortunately I am in too early stage 
to produce anything more concrete.


--
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  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 1/2] Documentation: devicetree: mfd: twl4030-power: Use the standard 'ti,system-power-controller' to mark power control

[Lee Jones]

On Wed, 17 Sep 2014, Sebastian Reichel wrote:

 On Wed, Sep 17, 2014 at 08:44:00AM -0700, Lee Jones wrote:
  On Wed, 17 Sep 2014, Nishanth Menon wrote:
   ti,system-power-controller is more or less the standard way of
   indicating that the PMIC is the system wide power controller and hence
   may be used to switch off the system. Almost ALL TI PMIC drivers and
   many Maxim PMIC drivers follow the same style.
   
   So support 'ti,system-power-controller' in addition to the usual
   'ti,use_poweroff' to indicate that the PMIC instance has control for
   switching off the system.
   
   Signed-off-by: Nishanth Menon n...@ti.com
   ---
   
   V2: picked up documentation suggestion from Sebastien
  
  It would be good to get Sebastian's Ack.
 
 Acked-By: Sebastian Reichel s...@kernel.org
 
 [...]
 
   +- ti,system-power-controller: This indicates that TWL4030 is the
   +  power supply master of the system. With this flag, the chip will
   +  initiates an ACTIVE-to-OFF or SLEEP-to-OFF transition when the
   +  system poweroffs.
 
 One minor thing: While the documentation is updated you may want to
 fix the typo will initiates to will initiate (or just drop the
 will).

Applied with Sebastian's Ack and I fixed this up too.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 2/2] mfd: twl4030-power: use 'ti,system-power-controller' as alternative way to support system power off

[Lee Jones]

On Wed, 17 Sep 2014, Nishanth Menon wrote:

 ti,system-power-controller is more or less the standard way of
 indicating that the PMIC is the system wide power controller and hence
 may be used to switch off the system. Almost ALL TI PMIC drivers and
 many Maxim PMIC drivers follow the same style.
 
 So support 'ti,system-power-controller' in addition to the usual
 'ti,use_poweroff' to indicate that the PMIC instance has control for
 switching off the system.
 
 Signed-off-by: Nishanth Menon n...@ti.com
 Acked-by: Tony Lindgren t...@atomide.com
 ---
 
 V2: no change, picked up Tony's ack.
 V1: https://patchwork.kernel.org/patch/4836371/
  drivers/mfd/twl4030-power.c |3 +++
  1 file changed, 3 insertions(+)

Applied, thanks.

 diff --git a/drivers/mfd/twl4030-power.c b/drivers/mfd/twl4030-power.c
 index 3bc969a..1c129ba 100644
 --- a/drivers/mfd/twl4030-power.c
 +++ b/drivers/mfd/twl4030-power.c
 @@ -627,6 +627,9 @@ static bool twl4030_power_use_poweroff(const struct 
 twl4030_power_data *pdata,
   if (pdata  pdata-use_poweroff)
   return true;
  
 + if (of_property_read_bool(node, ti,system-power-controller))
 + return true;
 +
   if (of_property_read_bool(node, ti,use_poweroff))
   return true;
  

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 08/10] ARM: OMAP5/DRA7: PM: cpuidle MPU CSWR support

[Shilimkar, Santosh]

Sorry for the format. Emailing from webmail.

From: Daniel Lezcano [daniel.lezc...@linaro.org]
Sent: Wednesday, September 17, 2014 2:49 PM
To: Menon, Nishanth; Shilimkar, Santosh; Tony Lindgren; Kristo, Tero; Paul 
Walmsley
Cc: Kevin Hilman; linux-arm-ker...@lists.infradead.org; 
linux-omap@vger.kernel.org; linux-ker...@vger.kernel.org; J, KEERTHY; Benoît 
Cousson
Subject: Re: [PATCH 08/10] ARM: OMAP5/DRA7: PM: cpuidle MPU CSWR support

On 08/22/2014 07:02 AM, Nishanth Menon wrote:
 From: Santosh Shilimkar santosh.shilim...@ti.com

 Add OMAP5/DRA74/72 CPUIDLE support.

 This patch adds MPUSS low power states in cpuidle.

  C1 - CPU0 WFI + CPU1 WFI + MPU ON
  C2 - CPU0 RET + CPU1 RET + MPU CSWR

 Tested on DRA74/72-EVM for C1 and C2 states.

 NOTE: DRA7 does not do voltage scaling as part of retention transition
 and has Mercury which speeds up transition paths - Latency numbers are
 based on measurements done by toggling GPIOs.

 Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
 [ j-keer...@ti.com rework on 3.14]
 Signed-off-by: Keerthy j-keer...@ti.com
 [n...@ti.com: updates based on profiling, OMAP5 squashed]
 Signed-off-by: Nishanth Menon n...@ti.com
 ---
   arch/arm/mach-omap2/cpuidle44xx.c |   82 
 -
   arch/arm/mach-omap2/pm44xx.c  |2 +-
   2 files changed, 82 insertions(+), 2 deletions(-)

 diff --git a/arch/arm/mach-omap2/cpuidle44xx.c 
 b/arch/arm/mach-omap2/cpuidle44xx.c
 index 2498ab0..8ad4f44 100644
 --- a/arch/arm/mach-omap2/cpuidle44xx.c
 +++ b/arch/arm/mach-omap2/cpuidle44xx.c
 @@ -22,6 +22,7 @@
   #include common.h
   #include pm.h
   #include prm.h
 +#include soc.h
   #include clockdomain.h

   #define MAX_CPUS2
 @@ -31,6 +32,7 @@ struct idle_statedata {
   u32 cpu_state;
   u32 mpu_logic_state;
   u32 mpu_state;
 + u32 mpu_state_vote;
   };

   static struct idle_statedata omap4_idle_data[] = {
 @@ -51,12 +53,26 @@ static struct idle_statedata omap4_idle_data[] = {
   },
   };

 +static struct idle_statedata dra7_idle_data[] = {
 + {
 + .cpu_state = PWRDM_POWER_ON,
 + .mpu_state = PWRDM_POWER_ON,
 + .mpu_logic_state = PWRDM_POWER_ON,
 + },
 + {
 + .cpu_state = PWRDM_POWER_RET,
 + .mpu_state = PWRDM_POWER_RET,
 + .mpu_logic_state = PWRDM_POWER_RET,
 + },
 +};
 +
   static struct powerdomain *mpu_pd, *cpu_pd[MAX_CPUS];
   static struct clockdomain *cpu_clkdm[MAX_CPUS];

   static atomic_t abort_barrier;
   static bool cpu_done[MAX_CPUS];
   static struct idle_statedata *state_ptr = omap4_idle_data[0];
 +static DEFINE_RAW_SPINLOCK(mpu_lock);

   /* Private functions */

 @@ -78,6 +94,32 @@ static int omap_enter_idle_simple(struct cpuidle_device 
 *dev,
   return index;
   }

 +static int omap_enter_idle_smp(struct cpuidle_device *dev,
 +struct cpuidle_driver *drv,
 +int index)
 +{
 + struct idle_statedata *cx = state_ptr + index;
 + unsigned long flag;
 +
 + raw_spin_lock_irqsave(mpu_lock, flag);

Why do you need this spin_lock_irqsave ? Aren't the local irqs already
disabled ?

[Santosh] Actually at one point of time before the idle consolidation the local
irq disable was inside the idle drivers. Now with that moved to core layer,
I think plain spin_lock/unlock() should work.

 + cx-mpu_state_vote++;
 + if (cx-mpu_state_vote == num_online_cpus()) {
 + pwrdm_set_logic_retst(mpu_pd, cx-mpu_logic_state);
 + omap_set_pwrdm_state(mpu_pd, cx-mpu_state);
 + }
 + raw_spin_unlock_irqrestore(mpu_lock, flag);
 +
 + omap4_enter_lowpower(dev-cpu, cx-cpu_state);
 +
 + raw_spin_lock_irqsave(mpu_lock, flag);
 + if (cx-mpu_state_vote == num_online_cpus())
 + omap_set_pwrdm_state(mpu_pd, PWRDM_POWER_ON);
 + cx-mpu_state_vote--;
 + raw_spin_unlock_irqrestore(mpu_lock, flag);

I am not sure that will work. What happens if a cpu exits idle and then
re-enter idle immediately ?

[Santosh] It works and that case is already taken care. CPU exist the idle and 
then votes
out for cluster state and if it reenters with the right targeted state, the 
cluster state would
be picked.


Could you try a long run of this little program:

https://git.linaro.org/power/pm-qa.git/blob/HEAD:/cpuidle/cpuidle_killer.c

[Santosh] I am sure there will not be any issue with the long run test case 
here.
Lets see if Nishant sees anything otherwise

Regards,
Santosh--
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  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] arm: arm: fiq: fix build breakage with CONFIG_FIQ

[Daniel Thompson]

On 17/09/14 13:01, Felipe Balbi wrote:
 commit e1add97 (ARM: 8150/2: fiq: Replace default FIQ handler)
 has a typo which causes build breakage whenever CONFIG_FIQ is
 set.
 
 The bug is very clear as can be noted that a new struct pt_regs
 def_fiq_regs was defined but code uses dfl_fiq_regs.

Quite so. My fault.

This error was picked up by Olof's autobuilder and I have offered
a fix as 8150/3 (posted to mailing list in this thread
http://thread.gmane.org/gmane.linux.kernel/1789554 ).

Your fix and mine are slightly different (I standardised on
dfl_fiq_regs) but both approaches should be functionally identical.


Daniel.


 Cc: Daniel Thompson daniel.thomp...@linaro.org
 Cc: Catalin Marinas catalin.mari...@arm.com
 Cc: Nicolas Pitre n...@linaro.org
 Fixes: e1add97 (ARM: 8150/2: fiq: Replace default FIQ handler)
 Signed-off-by: Felipe Balbi ba...@ti.com
 ---
 
 KernelVersion: next-20140917
 
 Russell, let me know if this is the correct KernelVersion tag you want/need
 
  arch/arm/kernel/fiq.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)
 
 diff --git a/arch/arm/kernel/fiq.c b/arch/arm/kernel/fiq.c
 index 1743049..b6ab4c7 100644
 --- a/arch/arm/kernel/fiq.c
 +++ b/arch/arm/kernel/fiq.c
 @@ -64,7 +64,7 @@ static int fiq_def_op(void *ref, int relinquish)
   if (!relinquish) {
   /* Restore default handler and registers */
   local_fiq_disable();
 - set_fiq_regs(dfl_fiq_regs);
 + set_fiq_regs(def_fiq_regs);
   set_fiq_handler(no_fiq_insn, sizeof(no_fiq_insn));
   local_fiq_enable();
  
 @@ -159,6 +159,6 @@ void __init init_FIQ(int start)
  {
   unsigned offset = FIQ_OFFSET;
   no_fiq_insn = *(unsigned long *)(0x + offset);
 - get_fiq_regs(dfl_fiq_regs);
 + get_fiq_regs(def_fiq_regs);
   fiq_start = start;
  }
 

--
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  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 08/10] ARM: OMAP5/DRA7: PM: cpuidle MPU CSWR support

[Daniel Lezcano]

On 09/17/2014 04:20 PM, Shilimkar, Santosh wrote:

Sorry for the format. Emailing from webmail.



[ ... ]


+static int omap_enter_idle_smp(struct cpuidle_device *dev,
+struct cpuidle_driver *drv,
+int index)
+{
+ struct idle_statedata *cx = state_ptr + index;
+ unsigned long flag;
+
+ raw_spin_lock_irqsave(mpu_lock, flag);


Why do you need this spin_lock_irqsave ? Aren't the local irqs already
disabled ?

[Santosh] Actually at one point of time before the idle consolidation the local
irq disable was inside the idle drivers. Now with that moved to core layer,
I think plain spin_lock/unlock() should work.


ok.


+ cx-mpu_state_vote++;
+ if (cx-mpu_state_vote == num_online_cpus()) {
+ pwrdm_set_logic_retst(mpu_pd, cx-mpu_logic_state);
+ omap_set_pwrdm_state(mpu_pd, cx-mpu_state);
+ }
+ raw_spin_unlock_irqrestore(mpu_lock, flag);
+
+ omap4_enter_lowpower(dev-cpu, cx-cpu_state);
+
+ raw_spin_lock_irqsave(mpu_lock, flag);
+ if (cx-mpu_state_vote == num_online_cpus())
+ omap_set_pwrdm_state(mpu_pd, PWRDM_POWER_ON);
+ cx-mpu_state_vote--;
+ raw_spin_unlock_irqrestore(mpu_lock, flag);


I am not sure that will work. What happens if a cpu exits idle and then
re-enter idle immediately ?

[Santosh] It works and that case is already taken care. CPU exist the idle and 
then votes
out for cluster state and if it reenters with the right targeted state, the 
cluster state would
be picked.


It isn't possible to have one cpu disabling the coherency, while the 
other one is looking for a lock ? Or eg. cpu0 is on WFI then cpu1 is the 
last entering idle. While cpu1 is entering 'lowpower', cpu0 exits the 
wfi check the state vote and set the power domain on. In the meantime 
cpu1 disables the coherency and cpu0 decrease the vote and release the 
lock. Could be possible there is a very small racy window here ?



Could you try a long run of this little program:

https://git.linaro.org/power/pm-qa.git/blob/HEAD:/cpuidle/cpuidle_killer.c

[Santosh] I am sure there will not be any issue with the long run test case 
here.
Lets see if Nishant sees anything otherwise


Ok. Make sure the cpu is effectively entering your C2 state with the 
sleep duration in the test program.



--
 http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  http://www.facebook.com/pages/Linaro Facebook |
http://twitter.com/#!/linaroorg Twitter |
http://www.linaro.org/linaro-blog/ Blog

--
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  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 08/10] ARM: OMAP5/DRA7: PM: cpuidle MPU CSWR support

[Shilimkar, Santosh]

From: Daniel Lezcano [daniel.lezc...@linaro.org]
Sent: Wednesday, September 17, 2014 8:22 PM
To: Shilimkar, Santosh; Menon, Nishanth; Tony Lindgren; Kristo, Tero; Paul 
Walmsley
Cc: Kevin Hilman; linux-arm-ker...@lists.infradead.org; 
linux-omap@vger.kernel.org; linux-ker...@vger.kernel.org; J, KEERTHY; Benoît 
Cousson
Subject: Re: [PATCH 08/10] ARM: OMAP5/DRA7: PM: cpuidle MPU CSWR support

On 09/17/2014 04:20 PM, Shilimkar, Santosh wrote:
 Sorry for the format. Emailing from webmail.
 

[ ... ]


 + cx-mpu_state_vote++;
 + if (cx-mpu_state_vote == num_online_cpus()) {
 + pwrdm_set_logic_retst(mpu_pd, cx-mpu_logic_state);
 + omap_set_pwrdm_state(mpu_pd, cx-mpu_state);
 + }
 + raw_spin_unlock_irqrestore(mpu_lock, flag);
 +
 + omap4_enter_lowpower(dev-cpu, cx-cpu_state);
 +
 + raw_spin_lock_irqsave(mpu_lock, flag);
 + if (cx-mpu_state_vote == num_online_cpus())
 + omap_set_pwrdm_state(mpu_pd, PWRDM_POWER_ON);
 + cx-mpu_state_vote--;
 + raw_spin_unlock_irqrestore(mpu_lock, flag);

 I am not sure that will work. What happens if a cpu exits idle and then
 re-enter idle immediately ?

 [Santosh] It works and that case is already taken care. CPU exist the idle 
 and then votes
 out for cluster state and if it reenters with the right targeted state, the 
 cluster state would
 be picked.

It isn't possible to have one cpu disabling the coherency, while the
other one is looking for a lock ? Or eg. cpu0 is on WFI then cpu1 is the
last entering idle. While cpu1 is entering 'lowpower', cpu0 exits the
wfi check the state vote and set the power domain on. In the meantime
cpu1 disables the coherency and cpu0 decrease the vote and release the
lock. Could be possible there is a very small racy window here ?

[Santosh] The coherency isn't disable by CPU. Thats actually taken care by
hardware. CPU takes it own power domain down and takes itself out of
coherency. The Coherency is always ON as long as there is a CPU ON
and SMP bit on that CPU is enabled.

The scenario, you mentioned can never happen on this hardware thanks
to the inbuilt smart hardware.

If you have more questions, lets discuss. I am around here at connect. ;-)

Regards,
Santosh--
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  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] arm: arm: fiq: fix build breakage with CONFIG_FIQ

[Felipe Balbi]

Hi,

On Wed, Sep 17, 2014 at 04:29:03PM -0700, Daniel Thompson wrote:
 On 17/09/14 13:01, Felipe Balbi wrote:
  commit e1add97 (ARM: 8150/2: fiq: Replace default FIQ handler)
  has a typo which causes build breakage whenever CONFIG_FIQ is
  set.
  
  The bug is very clear as can be noted that a new struct pt_regs
  def_fiq_regs was defined but code uses dfl_fiq_regs.
 
 Quite so. My fault.
 
 This error was picked up by Olof's autobuilder and I have offered
 a fix as 8150/3 (posted to mailing list in this thread
 http://thread.gmane.org/gmane.linux.kernel/1789554 ).

aaa, alright. I missed that one :-)

 Your fix and mine are slightly different (I standardised on
 dfl_fiq_regs) but both approaches should be functionally identical.

sure thing, no issues. I reckon it should be in next within the next
couple days ?

cheers

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 3/3] mtd: nand: Force omap_elm to be built as a module if omap2_nand is a module

[Brian Norris]

On Mon, Sep 15, 2014 at 11:27:43AM +0300, Roger Quadros wrote:
 On 09/12/2014 07:56 PM, Ezequiel Garcia wrote:
  On 12 Sep 12:01 PM, Roger Quadros wrote:
  On 09/11/2014 04:47 PM, Ezequiel Garcia wrote:
  This commit adds a hidden option to build the omap_elm as a module, if
  omap2_nand is a module (and similarly in the built-in case).
 
  This fixes the following build error when omap2_nand is chosen built-in,
  and omap_elm is chosen as a module:
 
  drivers/built-in.o: In function `omap_nand_probe':
  /work/linux-2.6/drivers/mtd/nand/omap2.c:2010: undefined reference to 
  `elm_config'
  /work/linux-2.6/drivers/mtd/nand/omap2.c:1980: undefined reference to 
  `elm_config'
  /work/linux-2.6/drivers/mtd/nand/omap2.c:1927: undefined reference to 
  `elm_config'
  drivers/built-in.o: In function `omap_elm_correct_data':
  /work/linux-2.6/drivers/mtd/nand/omap2.c:1444: undefined reference to 
  `elm_decode_bch_error_page'
 
  Signed-off-by: Ezequiel Garcia ezequ...@vanguardiasur.com.ar
  ---
   drivers/mtd/nand/Kconfig  | 8 +++-
   drivers/mtd/nand/Makefile | 2 +-
   2 files changed, 8 insertions(+), 2 deletions(-)
 
  diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
  index f1cf503..12e8ee8 100644
  --- a/drivers/mtd/nand/Kconfig
  +++ b/drivers/mtd/nand/Kconfig
  @@ -96,7 +96,7 @@ config MTD_NAND_OMAP2
   
   config MTD_NAND_OMAP_BCH
depends on MTD_NAND_OMAP2
  - tristate Support hardware based BCH error correction
  + bool Support hardware based BCH error correction
default n
select BCH
help
  @@ -106,6 +106,12 @@ config MTD_NAND_OMAP_BCH
  legacy OMAP families like OMAP2xxx, OMAP3xxx do not have ELM engine
  so they should not enable this config symbol.
   
  +config MTD_NAND_OMAP_BCH_BUILD
  + tristate
  + depends on MTD_NAND_OMAP2
  + default m if MTD_NAND_OMAP2=m  MTD_NAND_OMAP_BCH
  + default y if MTD_NAND_OMAP2=y  MTD_NAND_OMAP_BCH

I think the last 2 lines could be combined:

default MTD_NAND_OMAP2 if MTD_NAND_OMAP_BCH

  +
   config MTD_NAND_IDS
tristate
   
  diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
  index 4bcdeb0..3580188 100644
  --- a/drivers/mtd/nand/Makefile
  +++ b/drivers/mtd/nand/Makefile
  @@ -27,7 +27,7 @@ obj-$(CONFIG_MTD_NAND_NDFC) += ndfc.o
   obj-$(CONFIG_MTD_NAND_ATMEL) += atmel_nand.o
   obj-$(CONFIG_MTD_NAND_GPIO)  += gpio.o
   obj-$(CONFIG_MTD_NAND_OMAP2) += omap2_nand.o
  -obj-$(CONFIG_MTD_NAND_OMAP_BCH)  += omap_elm.o
  +obj-$(CONFIG_MTD_NAND_OMAP_BCH_BUILD)+= omap_elm.o
   obj-$(CONFIG_MTD_NAND_CM_X270)   += cmx270_nand.o
   obj-$(CONFIG_MTD_NAND_PXA3xx)+= pxa3xx_nand.o
   obj-$(CONFIG_MTD_NAND_TMIO)  += tmio_nand.o

Apparently I came up with a nearly identical solution, so it must be
good! ;)

  The overall logic seems to work but I still see the following issue.
 
  In menuconfig, the OMAP_BCH option is still visible as a boolean even 
  though
  the ELM module finally gets built as a module.
  This can be confusing to the user and I'd avoid that behaviour.
 
  
  Yes, I know. But it's either this solution or no solution at all, I think.
  
  Let me give some further context about this patch, so we can have more
  information to decide.
  
  First of all (and IMO) the user doesn't have to know about the ELM being
  a module or not, because modprobe will load it (since omap2_nand depends
  on omap_elm's symbols).
  
  So, the new way seems a bit more intuitive for me. The user choses if he
  wants to have hardware BCH support, and such support gets built the right
  way.
  
  If we still consider this highly confusing, and we want to avoid it,
  then it seems we can only make omap_elm a boolean, which means it'll always
  be built-in. I crafted this patch in an effort to avoid making it boolean.
  
  Finally, the solution is taken from media/usb/stk1160. For good or for bad,
  we have a precedent in doing things this way.
  
  Ultimately, I don't care much as I don't think anyone will build it as a 
  module,
  except maybe for testing the driver under probe/remove cycles.
  
 OK. I personally prefer boolean than the Kconfig magic as it makes my life a 
 bit
 easier and less confusing to the user i.e. wysiwyg ;).
 
 Let's see what the MTD maintainers prefer.
 Brian and David, any insights on this problem?

It seems like 'elm' serves more as an accessory piece of omap2.{o,ko},
not really a separate module, so it's possible it'd make your life even
easier to just link elm.o into omap2.o. There's no requirement that two
source files create two separate kernel modules. I think this would
present the simplest possible interface to the user.

Thoughts?

Brian
--
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  http://vger.kernel.org/majordomo-info.html