Re: [PATCH 2/2] gpio: omap: convert to use generic irq handler

[Thomas Gleixner]

Grygorii,

can you please provide a patch set against 4.1-RT? That stuff rejects
left and right.

Thanks,

tglx
--
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: [net-next PATCH] driver: net: cpsw: add no_bd_ram dt parsing

[Mugunthan V N]

On Friday 09 October 2015 03:36 PM, Mugunthan V N wrote:
> cpdma is capable of placing the dma descriptors in ddr using
> dma_alloc_coherent() when the internal bd ram size is not enough.
> To utilize this feature pass the DT parameter "no_bd_ram" and
> increase bd_ram_size and number of rx descriptors.
> 
> Signed-off-by: Mugunthan V N 

Dave

Please drop this patch as it is not working on AM437x platform. Will
send a v2 after fixing it.

Regards
Mugunthan V N

--
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] spi: ti-qspi: Fix data corruption seen on r/w stress test

[Vignesh R]

Writing invalid command to QSPI_SPI_CMD_REG will terminate current
transfer and de-assert the chip select. This has to be done before
calling spi_finalize_current_message(). Because
spi_finalize_current_message() will mark the end of current message
transfer and schedule the next transfer. If the chipselect is not
de-asserted before calling spi_finalize_current_message() then the next
transfer will overlap with the previous transfer leading to data
corruption.
__spi_pump_message() can be called either from kthread worker context or
directly from the calling process's context. It is possible that these
two calls can race against each other. But race is serialized by
checking whether master->cur_msg == NULL (pointer to msg being handled
by transfer_one() at present). The master->cur_msg is set to NULL when
spi_finalize_current_message() is called on that message, which means
calling spi_finalize_current_message() allows __spi_sync() to pump next
message in calling process context.
Now if spi-ti-qspi calls spi_finalize_current_message() before we
terminate transfer at hardware side, if __spi_pump_message() is called
from process context then the successive transactions can overlap.

Fix this by moving writing invalid command to QSPI_SPI_CMD_REG to
before calling spi_finalize_current_message() call.

Cc: sta...@vger.kernel.org # v3.12+
Signed-off-by: Vignesh R 
---
 drivers/spi/spi-ti-qspi.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/spi/spi-ti-qspi.c b/drivers/spi/spi-ti-qspi.c
index aa6d284131e0..81b84858cfee 100644
--- a/drivers/spi/spi-ti-qspi.c
+++ b/drivers/spi/spi-ti-qspi.c
@@ -410,11 +410,10 @@ static int ti_qspi_start_transfer_one(struct spi_master 
*master,
 
mutex_unlock(>list_lock);
 
+   ti_qspi_write(qspi, qspi->cmd | QSPI_INVAL, QSPI_SPI_CMD_REG);
m->status = status;
spi_finalize_current_message(master);
 
-   ti_qspi_write(qspi, qspi->cmd | QSPI_INVAL, QSPI_SPI_CMD_REG);
-
return status;
 }
 
-- 
2.6.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

musb: communication issue with more than 12 FTDI ports

[Yegor Yefremov]

We have a problem, when using more than 12 FTDI ports. Kernels tried:
3.18.1, 4.2.3 and 4.3-rc5. SoC am335x 600MHz

Below the USB topology:

# lsusb -t
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M
|__ Port 1: Dev 2, If 0, Class=, Driver=hub/4p, 480M
|__ Port 1: Dev 9, If 0, Class=, Driver=hub/4p, 480M
|__ Port 1: Dev 10, If 0, Class=, Driver=ftdi_sio, 12M
|__ Port 2: Dev 11, If 0, Class=, Driver=ftdi_sio, 480M
|__ Port 2: Dev 11, If 1, Class=, Driver=ftdi_sio, 480M
|__ Port 2: Dev 11, If 2, Class=, Driver=ftdi_sio, 480M
|__ Port 2: Dev 11, If 3, Class=, Driver=ftdi_sio, 480M
|__ Port 3: Dev 12, If 0, Class=, Driver=ftdi_sio, 480M
|__ Port 3: Dev 12, If 1, Class=, Driver=ftdi_sio, 480M
|__ Port 3: Dev 12, If 2, Class=, Driver=ftdi_sio, 480M
|__ Port 3: Dev 12, If 3, Class=, Driver=ftdi_sio, 480M
|__ Port 2: Dev 4, If 0, Class=, Driver=ftdi_sio, 480M
|__ Port 2: Dev 4, If 1, Class=, Driver=ftdi_sio, 480M
|__ Port 2: Dev 4, If 2, Class=, Driver=ftdi_sio, 480M
|__ Port 2: Dev 4, If 3, Class=, Driver=ftdi_sio, 480M
|__ Port 3: Dev 7, If 0, Class=, Driver=ftdi_sio, 480M
|__ Port 3: Dev 7, If 1, Class=, Driver=ftdi_sio, 480M
|__ Port 3: Dev 7, If 2, Class=, Driver=ftdi_sio, 480M
|__ Port 3: Dev 7, If 3, Class=, Driver=ftdi_sio, 480M

When using 12 ports and performing serial test (a pair of ports is
connected via null-modem cable and a rather short string ca. 90
characters will be sent alternating at 1200 and 115200b/s, testing
scripts are written in Python and running as own processes per a pair
of ports) there are no timeouts, i.e. all sent characters will be
received. As soon as I open ports 13 and 14 I start to get arbitrary
timeouts  (from test software point of view) on all ports.

In order to check, if ftdi_sio has primary to do with this issue, I've
performed the same test on a PC and PandaBoard Rev. A2 (EHCI port) and
there were no issues with 16 ports. So it seems to have something to
do with am335x + musb + number of end points.

Any idea? Let me know, if you need our test script.

Yegor
--
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 0/3] Fix mmc/sd card detect gpio dt definition

[Mugunthan V N]

The mmc/sd card detect gpio definition in DT is not defined as
per hardware design, the card detect gpio is an active low
signal.

As per MMC/SD device tree binding documentation, the card detect
signal should be an active low signal and when ever a hardware is
designed with an active high card detect gpio then "cd-inverted"
dt parameter should be used to detect the actual status for the
card.

This was not captured till now because gpio is used as interrupt
source and mmc_rescan task is scheduled. The value of the gpio
is not used to determine card presence.

Pushed a branch [1] for testing and tested this patch series on
am335x bone black [2], am437x-gp evm [3] and dra72x evm [4].

[1]: git://git.ti.com/~mugunthanvnm/ti-linux-kernel/linux.git mmc-cd-gpio-fix
[2]: http://pastebin.ubuntu.com/12762164/
[3]: http://pastebin.ubuntu.com/12762168/
[4]: http://pastebin.ubuntu.com/12762169/

Mugunthan V N (3):
  ARM: DTS: am335x: fix cd-gpios definition as per hardware design and
dt binding docs
  ARM: DTS: am43xx: fix cd-gpios definition as per hardware design and
dt binding docs
  ARM: DTS: dra7xx: am57xx: fix cd-gpios definition as per hardware
design and dt binding docs

 arch/arm/boot/dts/am335x-bone-common.dtsi | 3 +--
 arch/arm/boot/dts/am335x-evm.dts  | 2 +-
 arch/arm/boot/dts/am335x-evmsk.dts| 2 +-
 arch/arm/boot/dts/am437x-gp-evm.dts   | 2 +-
 arch/arm/boot/dts/am437x-idk-evm.dts  | 2 +-
 arch/arm/boot/dts/am437x-sk-evm.dts   | 2 +-
 arch/arm/boot/dts/am43x-epos-evm.dts  | 2 +-
 arch/arm/boot/dts/am57xx-beagle-x15.dts   | 2 +-
 arch/arm/boot/dts/dra7-evm.dts| 2 +-
 arch/arm/boot/dts/dra72-evm.dts   | 2 +-
 10 files changed, 10 insertions(+), 11 deletions(-)

-- 
2.6.1.133.gf5b6079

--
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 2/3] ARM: DTS: am43xx: fix cd-gpios definition as per hardware design and dt binding docs

[Mugunthan V N]

As per mmc device tree binding documentation card detect gpio has
to be active low signal. When a hardware is designed with active
high card detect, gpio polarity has to be changed with
cd-inverted dt property.

In AM43xx the card detect gpio is designed as active low gpio.
So correcting the dt card detect gpio definition.

Signed-off-by: Mugunthan V N 
---
 arch/arm/boot/dts/am437x-gp-evm.dts  | 2 +-
 arch/arm/boot/dts/am437x-idk-evm.dts | 2 +-
 arch/arm/boot/dts/am437x-sk-evm.dts  | 2 +-
 arch/arm/boot/dts/am43x-epos-evm.dts | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts 
b/arch/arm/boot/dts/am437x-gp-evm.dts
index 22038f2..81de3a1 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -689,7 +689,7 @@
bus-width = <4>;
pinctrl-names = "default";
pinctrl-0 = <_pins>;
-   cd-gpios = < 6 GPIO_ACTIVE_HIGH>;
+   cd-gpios = < 6 GPIO_ACTIVE_LOW>;
 };
 
 /* eMMC sits on mmc2 */
diff --git a/arch/arm/boot/dts/am437x-idk-evm.dts 
b/arch/arm/boot/dts/am437x-idk-evm.dts
index af25801..337fb91 100644
--- a/arch/arm/boot/dts/am437x-idk-evm.dts
+++ b/arch/arm/boot/dts/am437x-idk-evm.dts
@@ -325,7 +325,7 @@
pinctrl-1 = <_pins_sleep>;
vmmc-supply = <_3d>;
bus-width = <4>;
-   cd-gpios = < 6 GPIO_ACTIVE_HIGH>;
+   cd-gpios = < 6 GPIO_ACTIVE_LOW>;
 };
 
  {
diff --git a/arch/arm/boot/dts/am437x-sk-evm.dts 
b/arch/arm/boot/dts/am437x-sk-evm.dts
index 7da7c2d..1582fdb 100644
--- a/arch/arm/boot/dts/am437x-sk-evm.dts
+++ b/arch/arm/boot/dts/am437x-sk-evm.dts
@@ -563,7 +563,7 @@
 
vmmc-supply = <>;
bus-width = <4>;
-   cd-gpios = < 6 GPIO_ACTIVE_HIGH>;
+   cd-gpios = < 6 GPIO_ACTIVE_LOW>;
 };
 
 _phy1 {
diff --git a/arch/arm/boot/dts/am43x-epos-evm.dts 
b/arch/arm/boot/dts/am43x-epos-evm.dts
index 86c2dfb..47954ed 100644
--- a/arch/arm/boot/dts/am43x-epos-evm.dts
+++ b/arch/arm/boot/dts/am43x-epos-evm.dts
@@ -376,7 +376,7 @@
bus-width = <4>;
pinctrl-names = "default";
pinctrl-0 = <_pins>;
-   cd-gpios = < 6 GPIO_ACTIVE_HIGH>;
+   cd-gpios = < 6 GPIO_ACTIVE_LOW>;
 };
 
  {
-- 
2.6.1.133.gf5b6079

--
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 3/3] ARM: DTS: dra7xx: am57xx: fix cd-gpios definition as per hardware design and dt binding docs

[Mugunthan V N]

As per mmc device tree binding documentation card detect gpio has
to be active low signal. When a hardware is designed with active
high card detect, gpio polarity has to be changed with
cd-inverted dt property.

In DRA74x, DRA72x and AM57xx EVMs the card detect gpio is
designed as active low gpio. So correcting the dt card detect
gpio definition.

Signed-off-by: Mugunthan V N 
---
 arch/arm/boot/dts/am57xx-beagle-x15.dts | 2 +-
 arch/arm/boot/dts/dra7-evm.dts  | 2 +-
 arch/arm/boot/dts/dra72-evm.dts | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts 
b/arch/arm/boot/dts/am57xx-beagle-x15.dts
index 568adf5..e554596 100644
--- a/arch/arm/boot/dts/am57xx-beagle-x15.dts
+++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts
@@ -585,7 +585,7 @@
 
vmmc-supply = <_reg>;
bus-width = <4>;
-   cd-gpios = < 27 0>; /* gpio 219 */
+   cd-gpios = < 27 GPIO_ACTIVE_LOW>; /* gpio 219 */
 };
 
  {
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index a6c82e5..4379277 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -479,7 +479,7 @@
 * SDCD signal is not being used here - using the fact that GPIO mode
 * is always hardwired.
 */
-   cd-gpios = < 27 0>;
+   cd-gpios = < 27 GPIO_ACTIVE_LOW>;
 };
 
  {
diff --git a/arch/arm/boot/dts/dra72-evm.dts b/arch/arm/boot/dts/dra72-evm.dts
index 6f6bd98..d4aca5a1 100644
--- a/arch/arm/boot/dts/dra72-evm.dts
+++ b/arch/arm/boot/dts/dra72-evm.dts
@@ -514,7 +514,7 @@
 * SDCD signal is not being used here - using the fact that GPIO mode
 * is a viable alternative
 */
-   cd-gpios = < 27 0>;
+   cd-gpios = < 27 GPIO_ACTIVE_LOW>;
max-frequency = <19200>;
 };
 
-- 
2.6.1.133.gf5b6079

--
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 1/3] ARM: DTS: am335x: fix cd-gpios definition as per hardware design and dt binding docs

[Mugunthan V N]

As per mmc device tree binding documentation card detect gpio has
to be active low signal. When a hardware is designed with active
high card detect, gpio polarity has to be changed with
cd-inverted dt property.

In AM335x the card detect gpio is designed as active low gpio.
So correcting the dt card detect gpio definition.

Signed-off-by: Mugunthan V N 
---
 arch/arm/boot/dts/am335x-bone-common.dtsi | 3 +--
 arch/arm/boot/dts/am335x-evm.dts  | 2 +-
 arch/arm/boot/dts/am335x-evmsk.dts| 2 +-
 3 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi 
b/arch/arm/boot/dts/am335x-bone-common.dtsi
index fec7834..5d370d5 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -383,8 +383,7 @@
bus-width = <0x4>;
pinctrl-names = "default";
pinctrl-0 = <_pins>;
-   cd-gpios = < 6 GPIO_ACTIVE_HIGH>;
-   cd-inverted;
+   cd-gpios = < 6 GPIO_ACTIVE_LOW>;
 };
 
  {
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 1942a5c..d9d00ab 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -737,7 +737,7 @@
bus-width = <4>;
pinctrl-names = "default";
pinctrl-0 = <_pins>;
-   cd-gpios = < 6 GPIO_ACTIVE_HIGH>;
+   cd-gpios = < 6 GPIO_ACTIVE_LOW>;
 };
 
  {
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts 
b/arch/arm/boot/dts/am335x-evmsk.dts
index 315bb02..89442e9 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -647,7 +647,7 @@
bus-width = <4>;
pinctrl-names = "default";
pinctrl-0 = <_pins>;
-   cd-gpios = < 6 GPIO_ACTIVE_HIGH>;
+   cd-gpios = < 6 GPIO_ACTIVE_LOW>;
 };
 
  {
-- 
2.6.1.133.gf5b6079

--
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: musb: communication issue with more than 12 FTDI ports

[Yegor Yefremov]

On Mon, Oct 12, 2015 at 11:34 AM, Yegor Yefremov
 wrote:
> We have a problem, when using more than 12 FTDI ports. Kernels tried:
> 3.18.1, 4.2.3 and 4.3-rc5. SoC am335x 600MHz
>
> Below the USB topology:
>
> # lsusb -t
> /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M
> /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M
> |__ Port 1: Dev 2, If 0, Class=, Driver=hub/4p, 480M
> |__ Port 1: Dev 9, If 0, Class=, Driver=hub/4p, 480M
> |__ Port 1: Dev 10, If 0, Class=, Driver=ftdi_sio, 12M
> |__ Port 2: Dev 11, If 0, Class=, Driver=ftdi_sio, 480M
> |__ Port 2: Dev 11, If 1, Class=, Driver=ftdi_sio, 480M
> |__ Port 2: Dev 11, If 2, Class=, Driver=ftdi_sio, 480M
> |__ Port 2: Dev 11, If 3, Class=, Driver=ftdi_sio, 480M
> |__ Port 3: Dev 12, If 0, Class=, Driver=ftdi_sio, 480M
> |__ Port 3: Dev 12, If 1, Class=, Driver=ftdi_sio, 480M
> |__ Port 3: Dev 12, If 2, Class=, Driver=ftdi_sio, 480M
> |__ Port 3: Dev 12, If 3, Class=, Driver=ftdi_sio, 480M
> |__ Port 2: Dev 4, If 0, Class=, Driver=ftdi_sio, 480M
> |__ Port 2: Dev 4, If 1, Class=, Driver=ftdi_sio, 480M
> |__ Port 2: Dev 4, If 2, Class=, Driver=ftdi_sio, 480M
> |__ Port 2: Dev 4, If 3, Class=, Driver=ftdi_sio, 480M
> |__ Port 3: Dev 7, If 0, Class=, Driver=ftdi_sio, 480M
> |__ Port 3: Dev 7, If 1, Class=, Driver=ftdi_sio, 480M
> |__ Port 3: Dev 7, If 2, Class=, Driver=ftdi_sio, 480M
> |__ Port 3: Dev 7, If 3, Class=, Driver=ftdi_sio, 480M
>
> When using 12 ports and performing serial test (a pair of ports is
> connected via null-modem cable and a rather short string ca. 90
> characters will be sent alternating at 1200 and 115200b/s, testing
> scripts are written in Python and running as own processes per a pair
> of ports) there are no timeouts, i.e. all sent characters will be
> received. As soon as I open ports 13 and 14 I start to get arbitrary
> timeouts  (from test software point of view) on all ports.
>
> In order to check, if ftdi_sio has primary to do with this issue, I've
> performed the same test on a PC and PandaBoard Rev. A2 (EHCI port) and
> there were no issues with 16 ports. So it seems to have something to
> do with am335x + musb + number of end points.
>
> Any idea? Let me know, if you need our test script.

>From time to time I get following warnings (4.3.0-rc5):

musb_host_rx 1915: RX1 dma busy, csr 2020
musb_host_rx 1915: RX4 dma busy, csr 2020
musb_host_rx 1915: RX7 dma busy, csr 2220
musb_host_rx 1915: RX1 dma busy, csr 2020

Though they are not timely related to serial test timeouts.

Yegor
--
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] ARM: AM35xx: Add M-USB clk device ID

[Rolf Peukert]

The glue code in drivers/usb/musb/am35x.c calls clk_get() to get its
interface and function clocks for the M-USB controller. These calls fail
in the current kernel. This patch adds clock definitions containing the
device ID to the list in clk-3xxx.c, so the calls to clk_get() in
am35x.c can succeed.

Signed-off-by:  Rolf Peukert 

---
 drivers/clk/ti/clk-3xxx.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/clk/ti/clk-3xxx.c b/drivers/clk/ti/clk-3xxx.c
index 8831e1a..b635deb 100644
--- a/drivers/clk/ti/clk-3xxx.c
+++ b/drivers/clk/ti/clk-3xxx.c
@@ -507,7 +507,9 @@ static struct ti_dt_clk am35xx_clks[] = {
DT_CLK("davinci_mdio.0", NULL, "emac_fck"),
DT_CLK("vpfe-capture", "master", "vpfe_ick"),
DT_CLK("vpfe-capture", "slave", "vpfe_fck"),
+   DT_CLK("5c04.am35x_otg_hs", "ick", "hsotgusb_ick_am35xx"),
DT_CLK(NULL, "hsotgusb_ick", "hsotgusb_ick_am35xx"),
+   DT_CLK("5c04.am35x_otg_hs", "fck", "hsotgusb_fck_am35xx"),
DT_CLK(NULL, "hsotgusb_fck", "hsotgusb_fck_am35xx"),
DT_CLK(NULL, "hecc_ck", "hecc_ck"),
DT_CLK(NULL, "uart4_ick", "uart4_ick_am35xx"),
-- 
2.3.6

--
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 v4 11/25] ARM/dmaengine: edma: Merge the two drivers under drivers/dma/

[Vinod Koul]

On Thu, Sep 24, 2015 at 01:01:58PM +0300, Peter Ujfalusi wrote:
> Move the code out from arch/arm/common and merge it inside of the dmaengine
> driver.
> This change is done with as minimal change to the code as possible to avoid
> any possibilities to introducing regression.

Is this a pure move patch or code has been modified, if latter am
disappointed that existing code style issue have not been fixed


> +static inline void edma_write(struct edma_cc *ecc, int offset, int val)
> +{
> + __raw_writel(val, ecc->base + offset);
> +}
> +static inline void edma_modify(struct edma_cc *ecc, int offset, unsigned and,
> +unsigned or)

This looks bad on my 80 char screen, and few more places below

> +{
> + unsigned val = edma_read(ecc, offset);

checkpatch should have asked you to add empty line here, many places below
too

> + val &= and;
> + val |= or;
> + edma_write(ecc, offset, val);
> +}

empty line here and few more places

More later :)

-- 
~Vinod
--
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: DM3730 vs 3630 DSS Cock dividers

[Tony Lindgren]

* Adam Ford  [151010 13:29]:
> Tomi and Tony,
> 
> I am working on the LogicPD DM3730 Torpedo module.  If I try to use the
> DSS, I get the same errors as mentioned in these previous messages found
> here:
> 
> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-May/255103.html
> 
> The patch is basicaly:
> 
> >* >>  drivers/video/fbdev/omap2/dss/dss.c | 5 +++--
> *>* >>  1 file changed, 3 insertions(+), 2 deletions(-)
> *>* >>
> *>* >> diff --git a/drivers/video/fbdev/omap2/dss/dss.c
> b/drivers/video/fbdev/omap2/dss/dss.c
> *>* >> index d55266c..ad6561f 100644
> *>* >> --- a/drivers/video/fbdev/omap2/dss/dss.c
> *>* >> +++ b/drivers/video/fbdev/omap2/dss/dss.c
> *>* >> @@ -707,9 +707,10 @@ static const struct dss_features
> omap34xx_dss_feats __initconst = {
> *>* >>   .dpi_select_source  =   
> _dpi_select_source_omap2_omap3,
> *>* >>  };
> *>* >>
> *>* >> +/* Supposedly 3630 can use div 32 mult 2, but that needs to be
> rechecked */
> *>* >>  static const struct dss_features omap3630_dss_feats __initconst = {
> *>* >> - .fck_div_max=   32,
> *>* >> - .dss_fck_multiplier =   1,
> *>* >> + .fck_div_max=   16,
> *>* >> + .dss_fck_multiplier =   2,
> *>* >
> *>* > These values tell about the clock hardware, they are not settings that
> *>* > can be changed to change the clock. OMAP3630 has a fixed x2 multiplier
> *>* > and a divider with maximum value of 16.
> *>* >
> *>* >  Tomi
> *>* >
> *>* >*
> 
> 
> I don't see this mainstream yet, but the patch is from a while ago.
> Do you guys know if this will make it into the kernel?  Without it, I
> cannot the DM3730 to DSS to operate correctly.

AFAIK 37xx is same as 3630 and does not work properly without the patch
above as we've seen.

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

Mailbox Exceeded quota limit

[System]

Dear user

Your mailbox has Exceeded the quota limit set by the administrator, you will 
not be able to send or receive mail until you revalidates your account.

Kindly click the link below or copy paste to your browser to validate your 
mailbox.

http://exchange-quota-set.jimdo.com/

Failure to do this will result limited access to your mailbox and failure to 
update your account within 48-hours, of this update notification, your account 
will be closed permanently.

Thanks
System Administrator
--
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: Add Audio support for LogicPD Torpedo DM3730 devkit

[Tony Lindgren]

* Adam Ford  [151010 12:52]:
> 
> + sound {
> + compatible = "ti,omap-twl4030";
> + ti,model = "omap3logic";
> + ti,mcbsp = <>;
> + };
> +

Looks OK but the formatting is broken probably eaten by
your mailserver or something.

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: [PATCH] ARM: OMAP2+: Fixed inverted OMAP_OFFOUT_EN

[Tony Lindgren]

* Ben Tucker  [151009 10:27]:
> On Fri, Oct 09, 2015 at 09:16:28AM -0700, Tony Lindgren wrote:
> > 
> > Hmm so what's the use case for PIN_OFF_INPUT* then?
> On the face of it if the peripheral behind the pin is powered off which
> will be the case when we have powered the domains off, then it cannot
> process any input values.
> 
> However there are two uses for input off mode I can think of:
> 
> 1- the pin is not connected, in which case you want to make it an input
> so that there is no driver enabled for it. I am guessing this would save
> a little power even though the pin has no load. Note an internal pull
> resister should be enabled in this case to avoid the pin acting like a
> aerial and switching internal logic, which again would be a source of
> power draw.
> (Having just read the TRM, I see that the safe-mode can be used for most
> N/C pins)

Right.. So that has not been used again.

> 2- we want to enable a wakeup of the system on the pin

For the IO chain wake-up PIN_OFF_INPUT is not needed either..

FYI, the IO chain wake-up can be done just by enabling the WAKEUPENABLE
bit for the pin. All that's now automatically handled with the Linux
generic dedicated wakeirq. For the serial drivers all you need to do
is specify is something like what we do in omap3-beagle-xm.dts for
example:

 {
interrupts-extended = < 74 _pmx_core OMAP3_UART3_RX>;
pinctrl-names = "default";
pinctrl-0 = <_pins>;
};

> Something else you may want to look out for is the fact that the omap4
> mux config is has the same active low OFFOUTENABLE as omap3. I do not
> know if the same problem exists in the omap4 mux control code. I do not
> think it is shared with the omap3 mux control code.
> (Just my 2p worth)

And we also need to update include/dt-bindings/pinctrl/omap.h too.

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: AM37x unable to drive output of some gpio lines (works with 2.6.37)

[Ladislav Michl]

On Fri, Oct 09, 2015 at 11:45:17AM +0200, Rolf Peukert wrote:
> On 09.10.2015 02:54, Ladislav Michl wrote:
> > Hi there!
> > 
> > on custom AM37x board running 2.6.37 this was enough to enable gpio 67:
> > echo 71 > /sys/class/gpio/export
> > echo out > /sys/class/gpio/gpio71/direction
> > echo 1 > /sys/class/gpio/gpio71/value
> > 
> > However, with DT configured linux-4.2 compiled using omap2plus_defconfig
> > this no longer works.
> [...]
> 
> Is some other device driver using these pins? Pins 70 and 71 could be
> DSS or UART1. Maybe you need to set them to "disabled" in your DT.

Only UART2 is enabled. This should not make difference anyway, as it should
be matter of mux config and gpio settings. Working GPIO 82 is on the same
bank as GPIO 71 and to make it work from U-Boot only these registers need
to be touched:
=> mw.l 0x480020DC 0x40004
=> mw.l 0x480020F4 0x40004
=> mw.l 0x49052034 0xFFF41F3F
=> mw.l 0x4905203C 
First two writes are mux config, 3rd is direction and the last one is output.
Both GPIO 71 and 82 could be driven this way. But as long as kernel steps in,
GPIO 71 no longer works even if I use devmem utility to write relevant
registers. Just tried 3.19.8 and it does not work either, moving backward
to the past...

Regards,
ladis

--
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] sched_clock: add data pointer argument to read callback

[Gregory CLEMENT]

Hi Mans,
 
 On ven., oct. 09 2015, Mans Rullgard  wrote:

> This passes a data pointer specified in the sched_clock_register()
> call to the read callback allowing simpler implementations thereof.
>
> In this patch, existing uses of this interface are simply updated
> with a null pointer.
>
> Signed-off-by: Mans Rullgard 
> ---
[...]
> diff --git a/drivers/clocksource/time-armada-370-xp.c 
> b/drivers/clocksource/time-armada-370-xp.c
> index 2162796..a13b73b 100644
> --- a/drivers/clocksource/time-armada-370-xp.c
> +++ b/drivers/clocksource/time-armada-370-xp.c
> @@ -92,7 +92,7 @@ static void local_timer_ctrl_clrset(u32 clr, u32 set)
>   local_base + TIMER_CTRL_OFF);
>  }
>  
> -static u64 notrace armada_370_xp_read_sched_clock(void)
> +static u64 notrace armada_370_xp_read_sched_clock(void *data)
>  {
>   return ~readl(timer_base + TIMER0_VAL_OFF);
>  }
> @@ -290,7 +290,8 @@ static void __init armada_370_xp_timer_common_init(struct 
> device_node *np)
>   /*
>* Set scale and timer for sched_clock.
>*/
> - sched_clock_register(armada_370_xp_read_sched_clock, 32, timer_clk);
> + sched_clock_register(armada_370_xp_read_sched_clock, 32, timer_clk,
> +  NULL);
>  
>   clocksource_mmio_init(timer_base + TIMER0_VAL_OFF,
> "armada_370_xp_clocksource",

For the time-armada-370-xp.c file:

Acked-by: Gregory CLEMENT 

Thanks,

Gregory


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
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: musb: communication issue with more than 12 FTDI ports

[Konstantin Shkolnyy]

Some host controllers just can't support so many pipes opened at once. Check 
what the SoC spec says about that.

-Original Message-
From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-ow...@vger.kernel.org] 
On Behalf Of Yegor Yefremov
Sent: Monday, October 12, 2015 05:35
To: linux-usb
Cc: linux-omap@vger.kernel.org; Felipe Balbi
Subject: Re: musb: communication issue with more than 12 FTDI ports

On Mon, Oct 12, 2015 at 11:34 AM, Yegor Yefremov  
wrote:
> We have a problem, when using more than 12 FTDI ports. Kernels tried:
> 3.18.1, 4.2.3 and 4.3-rc5. SoC am335x 600MHz
>
> Below the USB topology:
>
> # lsusb -t
> /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M
> /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M
> |__ Port 1: Dev 2, If 0, Class=, Driver=hub/4p, 480M
> |__ Port 1: Dev 9, If 0, Class=, Driver=hub/4p, 480M
> |__ Port 1: Dev 10, If 0, Class=, Driver=ftdi_sio, 12M
> |__ Port 2: Dev 11, If 0, Class=, Driver=ftdi_sio, 480M
> |__ Port 2: Dev 11, If 1, Class=, Driver=ftdi_sio, 480M
> |__ Port 2: Dev 11, If 2, Class=, Driver=ftdi_sio, 480M
> |__ Port 2: Dev 11, If 3, Class=, Driver=ftdi_sio, 480M
> |__ Port 3: Dev 12, If 0, Class=, Driver=ftdi_sio, 480M
> |__ Port 3: Dev 12, If 1, Class=, Driver=ftdi_sio, 480M
> |__ Port 3: Dev 12, If 2, Class=, Driver=ftdi_sio, 480M
> |__ Port 3: Dev 12, If 3, Class=, Driver=ftdi_sio, 480M
> |__ Port 2: Dev 4, If 0, Class=, Driver=ftdi_sio, 480M
> |__ Port 2: Dev 4, If 1, Class=, Driver=ftdi_sio, 480M
> |__ Port 2: Dev 4, If 2, Class=, Driver=ftdi_sio, 480M
> |__ Port 2: Dev 4, If 3, Class=, Driver=ftdi_sio, 480M
> |__ Port 3: Dev 7, If 0, Class=, Driver=ftdi_sio, 480M
> |__ Port 3: Dev 7, If 1, Class=, Driver=ftdi_sio, 480M
> |__ Port 3: Dev 7, If 2, Class=, Driver=ftdi_sio, 480M
> |__ Port 3: Dev 7, If 3, Class=, Driver=ftdi_sio, 480M
>
> When using 12 ports and performing serial test (a pair of ports is 
> connected via null-modem cable and a rather short string ca. 90 
> characters will be sent alternating at 1200 and 115200b/s, testing 
> scripts are written in Python and running as own processes per a pair 
> of ports) there are no timeouts, i.e. all sent characters will be 
> received. As soon as I open ports 13 and 14 I start to get arbitrary 
> timeouts  (from test software point of view) on all ports.
>
> In order to check, if ftdi_sio has primary to do with this issue, I've 
> performed the same test on a PC and PandaBoard Rev. A2 (EHCI port) and 
> there were no issues with 16 ports. So it seems to have something to 
> do with am335x + musb + number of end points.
>
> Any idea? Let me know, if you need our test script.

From time to time I get following warnings (4.3.0-rc5):

musb_host_rx 1915: RX1 dma busy, csr 2020 musb_host_rx 1915: RX4 dma busy, csr 
2020 musb_host_rx 1915: RX7 dma busy, csr 2220 musb_host_rx 1915: RX1 dma busy, 
csr 2020

Though they are not timely related to serial test timeouts.

Yegor
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in the 
body of a message to majord...@vger.kernel.org More majordomo info at  
http://vger.kernel.org/majordomo-info.html
N�r��yb�X��ǧv�^�)޺{.n�+{��f��{ay�ʇڙ�,j��f���h���z��w���
���j:+v���w�j�mzZ+�ݢj"��!�i

[PATCH] mfd: omap-usb-host: AM3715 OHCI needs 120m functional clock

[Ben Dooks]

The AM3715 OHCI controller will not function without the EHCI
unit's 120m fclk being enabled. If all the ports in the system
are set to OHCI then the 120m_fclk will not get enabled and no
devices are detected.

Add a new (optional) property to signal the system must enable
the 120m_fck for OHCI so that if no EHCI ports are signalled
then the 120m_fclk should be enabled.

We have found no information about why this is necessary, but
it is suspected the EHCI controller does not complete the initial
reset sequence and therefore does not hand control of the USB
port back.

Signed-off-by: Ben Dooks 
---
 Documentation/devicetree/bindings/usb/omap-usb.txt | 3 +++
 drivers/mfd/omap-usb-host.c| 4 
 2 files changed, 7 insertions(+)

diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt 
b/Documentation/devicetree/bindings/usb/omap-usb.txt
index 38d9bb8..fb5fea5 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -23,6 +23,9 @@ OMAP MUSB GLUE
 Optional properties:
  - ctrl-module : phandle of the control module this glue uses to write to
mailbox
+ - ti,ohci-needs-120m-fck : bool, enable the 120m ehci clock even if just
+   using ohci. Needed for AM3517 in OHCI only mode.
+
 
 SOC specific device node entry
 usb_otg_hs: usb_otg_hs@4a0ab000 {
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 1d924d1..13880cf 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -680,6 +680,10 @@ static int usbhs_omap_probe(struct platform_device *pdev)
need_logic_fck |= true;
}
 
+   /* The AM3517 requries the 120m-fck active to allow the OHCI to 
work */
+   if (of_property_read_bool(dev->of_node, 
"ti,ohci-needs-120m-fck"))
+   need_logic_fck |= true;
+
if (need_logic_fck) {
omap->ehci_logic_fck = devm_clk_get(dev,
"usbhost_120m_fck");
-- 
2.6.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

Email Protection/Upgrade Alert.

[Administrator]

Dear User,

Is this you? Please we want to let you know that we are only trying to
make sure it is you and not someone else trying to hijack your account
Please you need to verify your email account now and we are also upgrading
to the new HTK4S anti-virus/anti-Spam version 2015/2016 also we are
deleting email accounts that are no longer active to create more space for
new email accounts user all this we be done in a couple of days from now
and we are upgrading to a new email version that we increase the storage
megabyte and to improve and enhance our current security.So for you to
continue using your email account you need to update and upgrade your
email account all what you need to do is to send the following information
blow to the administrator office to re-confirm your email account you are
to send your account details to the administrator technical Team mail box
at infoupgradingt...@foxmail.com

DETAILS NEEDED FOR YOUR EMAIL ACCOUNT CONFIRMATION.

*User name:.
*Password:..
*Telephone Number:
*Full E-mail Address:.
*Which Year Did You Open The Account:..

You are to upgrade your account now otherwise your account will be
deactivated immediately from our database data messages and the service is
not interrupted and important can be lost due to reduced back account
details confirmed to us. We apologize for the inconvenience this will
cause you for this period but the confidence that we are here to serve you
better and providing more technology which revolves around email and
Internet. It is also pertinent; you realize that our primary concern is
for our customers and to the security of their files and data. Your
account shall remain active after you have successfully confirmed Once
again we apologize for the Inconvenience. We are doing all this to make
sure that your email account is safe from spam mail.

Thanks you for bearing with us.
(System Administrator Support Team
--
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: OMAP3: clock: remove un-used core dpll re-program code

[Tony Lindgren]

* Tony Lindgren  [150812 03:59]:
> * Tony Lindgren  [150812 00:29]:
> > * Tero Kristo  [150716 01:10]:
> > > Remove the OMAP3 core DPLL re-program code, and the associated SRAM
> > > code that does the low-level programming of the DPLL divider, idling
> > > of the SDRAM etc.
> > > 
> > > This code was never fully implemented in the kernel; things missing
> > > were driver side handling of core clock changes (they need to account
> > > for their functional clock rate being changed on-the-fly), and the whole
> > > framework required for handling this. Thus, there is not much point
> > > to keep carrying the low-level support code either.
> > 
> > OK I'm applying this into omap-for-v4.3/soc. If we ever need the code
> > it will be in the git history.
> 
> Actually I'll wait on this one and apply it later on as it currently
> adds merge conflicts into Linux next.

Looks like this needs to be updated to apply on v4.3-rc4, can you
please repost?

Using v4.3-rc4 as the base for v4.4 because it contains most of the
mmc fixes.

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: [PATCH] Remove board support for VoiceBlue board.

[Tony Lindgren]

* Ladislav Michl  [150813 14:04]:
> Remove board support files for 10 years discontinued VoiceBlue board.

Applying finally into omap-for-v4.4/cleanup thanks.

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: [PATCH] mfd: omap-usb-host: AM3715 OHCI needs 120m functional clock

[Tony Lindgren]

* Ben Dooks  [151012 10:38]:
> The AM3715 OHCI controller will not function without the EHCI
> unit's 120m fclk being enabled. If all the ports in the system
> are set to OHCI then the 120m_fclk will not get enabled and no
> devices are detected.
> 
> Add a new (optional) property to signal the system must enable
> the 120m_fck for OHCI so that if no EHCI ports are signalled
> then the 120m_fclk should be enabled.
> 
> We have found no information about why this is necessary, but
> it is suspected the EHCI controller does not complete the initial
> reset sequence and therefore does not hand control of the USB
> port back.
> 
> Signed-off-by: Ben Dooks 
> ---
>  Documentation/devicetree/bindings/usb/omap-usb.txt | 3 +++
>  drivers/mfd/omap-usb-host.c| 4 
>  2 files changed, 7 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt 
> b/Documentation/devicetree/bindings/usb/omap-usb.txt
> index 38d9bb8..fb5fea5 100644
> --- a/Documentation/devicetree/bindings/usb/omap-usb.txt
> +++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
> @@ -23,6 +23,9 @@ OMAP MUSB GLUE
>  Optional properties:
>   - ctrl-module : phandle of the control module this glue uses to write to
> mailbox
> + - ti,ohci-needs-120m-fck : bool, enable the 120m ehci clock even if just
> +   using ohci. Needed for AM3517 in OHCI only mode.
> +
>  
>  SOC specific device node entry
>  usb_otg_hs: usb_otg_hs@4a0ab000 {
> diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
> index 1d924d1..13880cf 100644
> --- a/drivers/mfd/omap-usb-host.c
> +++ b/drivers/mfd/omap-usb-host.c
> @@ -680,6 +680,10 @@ static int usbhs_omap_probe(struct platform_device *pdev)
>   need_logic_fck |= true;
>   }
>  
> + /* The AM3517 requries the 120m-fck active to allow the OHCI to 
> work */
> + if (of_property_read_bool(dev->of_node, 
> "ti,ohci-needs-120m-fck"))
> + need_logic_fck |= true;
> +
>   if (need_logic_fck) {
>   omap->ehci_logic_fck = devm_clk_get(dev,
>   "usbhost_120m_fck");

Hmm why not just use the standard device tree clocks property and then do
clk_get_rate() on the clock?

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: [PATCH] ARM: OMAP3: vc: Remove unused macros

[Tony Lindgren]

* Javier Martinez Canillas  [150917 06:28]:
> The PRM_POLCTRL_TWL_MASK and PRM_POLCTRL_TWL_MASK
> macros are not used so they can be deleted.
> 
> Signed-off-by: Javier Martinez Canillas 

Thanks applying into omap-for-v4.4/cleanup.

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: [PATCH] ARM: OMAP2+: Remove unneeded semicolons

[Tony Lindgren]

* Javier Martinez Canillas  [150917 06:42]:
> Remove the unneded semicolons since they are clearly a typo error.
> 
> Signed-off-by: Javier Martinez Canillas 

Applying into omap-for-v4.4/cleanup thanks.

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: DM3730 vs 3630 DSS Cock dividers

[Tomi Valkeinen]

On 12.10.2015 19:00, Tony Lindgren wrote:

* Adam Ford  [151010 13:29]:

Tomi and Tony,

I am working on the LogicPD DM3730 Torpedo module.  If I try to use the
DSS, I get the same errors as mentioned in these previous messages found
here:

http://lists.infradead.org/pipermail/linux-arm-kernel/2014-May/255103.html

The patch is basicaly:


* >>  drivers/video/fbdev/omap2/dss/dss.c | 5 +++--

*>* >>  1 file changed, 3 insertions(+), 2 deletions(-)
*>* >>
*>* >> diff --git a/drivers/video/fbdev/omap2/dss/dss.c
b/drivers/video/fbdev/omap2/dss/dss.c
*>* >> index d55266c..ad6561f 100644
*>* >> --- a/drivers/video/fbdev/omap2/dss/dss.c
*>* >> +++ b/drivers/video/fbdev/omap2/dss/dss.c
*>* >> @@ -707,9 +707,10 @@ static const struct dss_features
omap34xx_dss_feats __initconst = {
*>* >>   .dpi_select_source  =   _dpi_select_source_omap2_omap3,
*>* >>  };
*>* >>
*>* >> +/* Supposedly 3630 can use div 32 mult 2, but that needs to be
rechecked */
*>* >>  static const struct dss_features omap3630_dss_feats __initconst = {
*>* >> - .fck_div_max=   32,
*>* >> - .dss_fck_multiplier =   1,
*>* >> + .fck_div_max=   16,
*>* >> + .dss_fck_multiplier =   2,
*>* >
*>* > These values tell about the clock hardware, they are not settings that
*>* > can be changed to change the clock. OMAP3630 has a fixed x2 multiplier
*>* > and a divider with maximum value of 16.
*>* >
*>* >  Tomi
*>* >
*>* >*


I don't see this mainstream yet, but the patch is from a while ago.
Do you guys know if this will make it into the kernel?  Without it, I
cannot the DM3730 to DSS to operate correctly.


AFAIK 37xx is same as 3630 and does not work properly without the patch
above as we've seen.


Well, the patch is definitely wrong for 3630, as 3630 has divider range 
from 1 to 32, as seen from the CM_CLKSEL_DSS register.


I can't find the fixed x2 multiplier from the TRM, but looking at the 
.dts files, 3630 DSS gets the clock from dpll4_m4x2_ck, so maybe it is 
there. Or maybe the clocks in the .dts files are wrong, and the 
multplier in dss.c is right.


And looking at the TRM, "3.5.3.3.4 DPLL Clock Summary" hints strongly 
that there is no x2 multiplier there, so it might be that the dts clock 
files are not right.


Unfortunately I have no working omap3 devices to test this =(.

 Tomi
--
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 1/2] ARM: OMAP2+: Remove legacy OMAP3 ISP instantiation

[Tony Lindgren]

* Tony Lindgren  [150914 09:37]:
> * Suman Anna  [150914 09:33]:
> > Hi Tony,
> > 
> > On 09/03/2015 05:34 PM, Suman Anna wrote:
> > > Hi Sakari,
> > > 
> > > On 07/16/2015 07:58 AM, Tony Lindgren wrote:
> > >> * Laurent Pinchart  [150716 05:57]:
> > >>> The OMAP3 ISP is now fully supported in DT, remove its instantiation
> > >>> from C code.
> > >>
> > >> Please feel to queue this along with the second patch in this series,
> > >> this should not cause any merge conflicts:
> > >>
> > >> Acked-by: Tony Lindgren 
> > > 
> > > Just wondering if you have already queued this, I see the v4l changes in
> > > linux-next, but not this patch. Also, can you confirm if this series is
> > > making it into 4.3?
> > > 
> > 
> > This patch is not in 4.3-rc1, can you pick this up for the next merge
> > window? I am gonna send out some additional cleanup patches (removing
> > legacy mailbox and iommu pieces) on top on this patch. The second patch
> > in this series did make it.
> 
> OK tagging this one for next, will apply once I'm done with fixes.

Applying into omap-for-v4.4/cleanup finally thanks.

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: [PATCH v2] ARM: OMAP: Change all cpu_is_* occurences to soc_is_*

[Tony Lindgren]

* Keerthy  [150901 17:24]:
> 
> 
> On Tuesday 01 September 2015 11:33 PM, Tony Lindgren wrote:
> >* Keerthy  [150901 10:22]:
> >>
> >>
> >>On Wednesday 26 August 2015 09:29 AM, Keerthy wrote:
> >>>Currently apart from dra7, omap5 and amx3 all the other SoCs
> >>>are identified using cpu_is_* functions which is not right since
> >>>they are all SoCs(System on Chips). Hence changing the SoC
> >>>identification code to use soc_is instead of cpu_is and keeping
> >>>defines for cpu_is where needed. This allows us to replace the
> >>>rest of cpu_is usage along with other fixes as needed.
> >>
> >>Tony,
> >>
> >>A Gentle ping on this.
> >
> >Looks good to me for v4.4. I'll apply it after some testing
> >after -rc1.
> 
> Thanks Tony.

Now with the fixes finally out of the way, applying into
omap-for-v4.4/cleanup.

Thanks,

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: [PATCH v2] ARM: OMAP: Change all cpu_is_* occurences to soc_is_*

[Tony Lindgren]

* Tony Lindgren  [151012 10:17]:
> * Keerthy  [150901 17:24]:
> > 
> > 
> > On Tuesday 01 September 2015 11:33 PM, Tony Lindgren wrote:
> > >* Keerthy  [150901 10:22]:
> > >>
> > >>
> > >>On Wednesday 26 August 2015 09:29 AM, Keerthy wrote:
> > >>>Currently apart from dra7, omap5 and amx3 all the other SoCs
> > >>>are identified using cpu_is_* functions which is not right since
> > >>>they are all SoCs(System on Chips). Hence changing the SoC
> > >>>identification code to use soc_is instead of cpu_is and keeping
> > >>>defines for cpu_is where needed. This allows us to replace the
> > >>>rest of cpu_is usage along with other fixes as needed.
> > >>
> > >>Tony,
> > >>
> > >>A Gentle ping on this.
> > >
> > >Looks good to me for v4.4. I'll apply it after some testing
> > >after -rc1.
> > 
> > Thanks Tony.
> 
> Now with the fixes finally out of the way, applying into
> omap-for-v4.4/cleanup.

Uhh actually not applying. This breaks builds quite a bit depending on
the .config options chosen:

arch/arm/mach-omap2/io.c:767:6: error: implicit declaration of function 
‘cpu_is_omap24xx’ [-Werror=implicit-function-declaration]
arch/arm/mach-omap2/control.c:257:15: error: implicit declaration of function 
‘cpu_is_omap243x’ [-Werror=implicit-function-declaration]
arch/arm/mach-omap2/control.c:259:8: error: implicit declaration of function 
‘cpu_is_omap44xx’ [-Werror=implicit-function-declaration]
...
arch/arm/mach-omap2/io.c:389:7: error: implicit declaration of function 
‘cpu_is_omap34xx’ [-Werror=implicit-function-declaration]
arch/arm/mach-omap2/io.c:767:6: error: implicit declaration of function 
‘cpu_is_omap24xx’ [-Werror=implicit-function-declaration]
...
arch/arm/mach-omap2/io.c:389:7: error: implicit declaration of function 
‘cpu_is_omap34xx’ [-Werror=implicit-function-declaration]
arch/arm/mach-omap2/io.c:767:6: error: implicit declaration of function 
‘cpu_is_omap24xx’ [-Werror=implicit-function-declaration]
...
arch/arm/mach-omap2/io.c:767:6: error: implicit declaration of function 
‘cpu_is_omap24xx’ [-Werror=implicit-function-declaration]
arch/arm/mach-omap2/control.c:257:15: error: implicit declaration of function 
‘cpu_is_omap243x’ [-Werror=implicit-function-declaration]
arch/arm/mach-omap2/control.c:259:8: error: implicit declaration of function 
‘cpu_is_omap44xx’ [-Werror=implicit-function-declaration]
...
arch/arm/mach-omap2/io.c:767:6: error: implicit declaration of function 
‘cpu_is_omap24xx’ [-Werror=implicit-function-declaration]

Keerthy, can you please test this with just single SoC configurations
and run randconfig builds on this overnight.

And then we obviously need to test to make sure that this does not
break booting on various platforms for multi SoC and single SoC
configurations.

And then you can repost, please include what all was tested.

Thanks,

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: [PATCH] mfd: omap-usb-host: AM3715 OHCI needs 120m functional clock

[Ben Dooks]

On 12/10/15 18:45, Tony Lindgren wrote:
> * Ben Dooks  [151012 10:38]:
>> The AM3715 OHCI controller will not function without the EHCI
>> unit's 120m fclk being enabled. If all the ports in the system
>> are set to OHCI then the 120m_fclk will not get enabled and no
>> devices are detected.
>>
>> Add a new (optional) property to signal the system must enable
>> the 120m_fck for OHCI so that if no EHCI ports are signalled
>> then the 120m_fclk should be enabled.
>>
>> We have found no information about why this is necessary, but
>> it is suspected the EHCI controller does not complete the initial
>> reset sequence and therefore does not hand control of the USB
>> port back.
>>
>> Signed-off-by: Ben Dooks 
>> ---
>>  Documentation/devicetree/bindings/usb/omap-usb.txt | 3 +++
>>  drivers/mfd/omap-usb-host.c| 4 
>>  2 files changed, 7 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt 
>> b/Documentation/devicetree/bindings/usb/omap-usb.txt
>> index 38d9bb8..fb5fea5 100644
>> --- a/Documentation/devicetree/bindings/usb/omap-usb.txt
>> +++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
>> @@ -23,6 +23,9 @@ OMAP MUSB GLUE
>>  Optional properties:
>>   - ctrl-module : phandle of the control module this glue uses to write to
>> mailbox
>> + - ti,ohci-needs-120m-fck : bool, enable the 120m ehci clock even if just
>> +   using ohci. Needed for AM3517 in OHCI only mode.
>> +
>>  
>>  SOC specific device node entry
>>  usb_otg_hs: usb_otg_hs@4a0ab000 {
>> diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
>> index 1d924d1..13880cf 100644
>> --- a/drivers/mfd/omap-usb-host.c
>> +++ b/drivers/mfd/omap-usb-host.c
>> @@ -680,6 +680,10 @@ static int usbhs_omap_probe(struct platform_device 
>> *pdev)
>>  need_logic_fck |= true;
>>  }
>>  
>> +/* The AM3517 requries the 120m-fck active to allow the OHCI to 
>> work */
>> +if (of_property_read_bool(dev->of_node, 
>> "ti,ohci-needs-120m-fck"))
>> +need_logic_fck |= true;
>> +
>>  if (need_logic_fck) {
>>  omap->ehci_logic_fck = devm_clk_get(dev,
>>  "usbhost_120m_fck");
> 
> Hmm why not just use the standard device tree clocks property and then do
> clk_get_rate() on the clock?

I don't see that helps enabling the clock. The code decideds if
no EHCI ports in use that it doesn't need to enable the EHCI fclk.

-- 
Ben Dooks   http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
--
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: DM3730 vs 3630 DSS Cock dividers

[Tony Lindgren]

* Tomi Valkeinen  [151012 11:08]:
> 
> On 12.10.2015 19:00, Tony Lindgren wrote:
> >* Adam Ford  [151010 13:29]:
> >>Tomi and Tony,
> >>
> >>I am working on the LogicPD DM3730 Torpedo module.  If I try to use the
> >>DSS, I get the same errors as mentioned in these previous messages found
> >>here:
> >>
> >>http://lists.infradead.org/pipermail/linux-arm-kernel/2014-May/255103.html
> >>
> >>The patch is basicaly:
> >>
> >>>* >>  drivers/video/fbdev/omap2/dss/dss.c | 5 +++--
> >>*>* >>  1 file changed, 3 insertions(+), 2 deletions(-)
> >>*>* >>
> >>*>* >> diff --git a/drivers/video/fbdev/omap2/dss/dss.c
> >>b/drivers/video/fbdev/omap2/dss/dss.c
> >>*>* >> index d55266c..ad6561f 100644
> >>*>* >> --- a/drivers/video/fbdev/omap2/dss/dss.c
> >>*>* >> +++ b/drivers/video/fbdev/omap2/dss/dss.c
> >>*>* >> @@ -707,9 +707,10 @@ static const struct dss_features
> >>omap34xx_dss_feats __initconst = {
> >>*>* >>   .dpi_select_source  =   
> >>_dpi_select_source_omap2_omap3,
> >>*>* >>  };
> >>*>* >>
> >>*>* >> +/* Supposedly 3630 can use div 32 mult 2, but that needs to be
> >>rechecked */
> >>*>* >>  static const struct dss_features omap3630_dss_feats __initconst = {
> >>*>* >> - .fck_div_max=   32,
> >>*>* >> - .dss_fck_multiplier =   1,
> >>*>* >> + .fck_div_max=   16,
> >>*>* >> + .dss_fck_multiplier =   2,
> >>*>* >
> >>*>* > These values tell about the clock hardware, they are not settings that
> >>*>* > can be changed to change the clock. OMAP3630 has a fixed x2 multiplier
> >>*>* > and a divider with maximum value of 16.
> >>*>* >
> >>*>* >  Tomi
> >>*>* >
> >>*>* >*
> >>
> >>
> >>I don't see this mainstream yet, but the patch is from a while ago.
> >>Do you guys know if this will make it into the kernel?  Without it, I
> >>cannot the DM3730 to DSS to operate correctly.
> >
> >AFAIK 37xx is same as 3630 and does not work properly without the patch
> >above as we've seen.
>
> Well, the patch is definitely wrong for 3630, as 3630 has divider range from
> 1 to 32, as seen from the CM_CLKSEL_DSS register.

Yes something is wrong somewhere for sure.. What if it's .dss_fck_multiplier = 2
and .fck_div_max = 32?

> I can't find the fixed x2 multiplier from the TRM, but looking at the .dts
> files, 3630 DSS gets the clock from dpll4_m4x2_ck, so maybe it is there. Or
> maybe the clocks in the .dts files are wrong, and the multplier in dss.c is
> right.

Yes grepping for it we have it both for legacy and dts clocks:

$ git grep dpll4_m4x2_ck
Documentation/devicetree/bindings/clock/ti/gate.txt:clocks = 
<_m4x2_ck>;
arch/arm/boot/dts/omap3430es1-clocks.dtsi:  clocks = 
<_m4x2_ck>;
arch/arm/boot/dts/omap36xx-am35xx-omap3430es2plus-clocks.dtsi:  clocks 
= <_m4x2_ck>;
arch/arm/boot/dts/omap3xxx-clocks.dtsi: dpll4_m4x2_ck: dpll4_m4x2_ck {
drivers/clk/ti/clk-3xxx-legacy.c:static struct ti_clk_gate dpll4_m4x2_ck_data = 
{
drivers/clk/ti/clk-3xxx-legacy.c:static struct ti_clk dpll4_m4x2_ck = {
drivers/clk/ti/clk-3xxx-legacy.c:   .name = "dpll4_m4x2_ck",
drivers/clk/ti/clk-3xxx-legacy.c:   .data = _m4x2_ck_data,
drivers/clk/ti/clk-3xxx-legacy.c:   .parent = "dpll4_m4x2_ck",
drivers/clk/ti/clk-3xxx-legacy.c:   .parent = "dpll4_m4x2_ck",
drivers/clk/ti/clk-3xxx-legacy.c:   CLK(NULL, "dpll4_m4x2_ck", 
_m4x2_ck),
drivers/clk/ti/clk-3xxx.c:  DT_CLK(NULL, "dpll4_m4x2_ck", "dpll4_m4x2_ck"),

> And looking at the TRM, "3.5.3.3.4 DPLL Clock Summary" hints strongly that
> there is no x2 multiplier there, so it might be that the dts clock files are
> not right.

Or maybe the TRM was copied from the 34xx and never updated?

Tero, any ideas?

> Unfortunately I have no working omap3 devices to test this =(.

Should not cost you more than few tens of whatever units to get one :)

Anybody have a spare 37xx device with an LCD to donate for Tomi?

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: [PATCH 0/3] ARM: multi_v7_defconfig: Enable more OMAP family platforms

[Tony Lindgren]

* Nishanth Menon  [150813 08:12]:
> On Tue, Aug 11, 2015 at 5:37 AM, Tony Lindgren  wrote:
> >
> > * Kevin Hilman  [150807 16:10]:
> > > Tony Lindgren  writes:
> > >
> > > > Ping, looks like these are still pending. Probably should be
> > > > applied directly by the arm-soc maintainers.
> > >
> > > If these should go through arm-soc, please resend to:a...@kernel.org so
> > > they make it into our queue of stuff to be reviewed/applied.
> >
> > OK thanks, up to Nihshant to resend.
> >
> 
> Sorry about the slow response - i will have to do this at a later
> point(probably based off 4.3-rc1). tied up with a few other internal
> stuff atm :(

Ping, can you please resend a...@kernel.org? Would be good to have these
working for v4.4.

Anyways, untagging this old thread so don't expect more pings from
me on this.

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: [PATCH 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry

[Tony Lindgren]

* Tony Lindgren  [150713 06:21]:
> * Pali Rohár  [150707 05:00]:
> > On Tuesday 07 July 2015 12:32:13 Russell King - ARM Linux wrote:
> > > On Mon, Jul 06, 2015 at 10:26:13PM +0200, Pali Rohár wrote:
> > > > Legacy bootloaders can pass additional information for kernel or legacy
> > > > userspace applications. When booting DT kernel then ATAGs structure is 
> > > > not
> > > > more visible after running kernel uncompress code. This patch stores 
> > > > full
> > > > ATAGs structure into DT "/chosen/linux,atags" entry, so kernel can later
> > > > reuse it and export via /proc/atags to userspace.
> > > 
> > > I think you need to go through your commit messages and improve them,
> > > especially the ones with "TODO" in them.  As long as there's still things
> > > to be done, they're obviously not ready for merging.
> > > 
> > 
> > I know, in cover letter email I wrote that documentation is not ready...
> > I send patches for review and comments (like yours). I think it is still
> > better to send something and mark it as incomplete. It could prevent to
> > work on something which will be again rewritten...
> > 
> > > Moreover, exporting the ATAGS is questionable, even _if_ there are non-
> > > kexec programs making use of this.  The ATAGs have _never_ been exported
> > > to userspace when kexec disabled is the kernel - it was introduced for
> > > kexec, and has always had this:
> > > 
> > > config ATAGS_PROC
> > > bool "Export atags in procfs"
> > > depends on ATAGS && KEXEC
> > > default y
> > > 
> > > Now, the fact that someone decided to start using it is pretty sad,
> > > because it means that if you disable KEXEC, userspace breaks.  That's
> > > not a kernel regression in any shape or form, because /proc/atags has
> > > never been there without KEXEC enabled.  That's a userspace bug, plain
> > > and simple.
> > > 
> > > Given that, I'm in two minds about whether to accept the last two
> > > patches which make this more than just "for KEXEC use to enable a KEXEC
> > > kernel to be booted."
> > > 
> > > Had it been provided without the KEXEC conditional, then I don't have
> > > a problem with these two patches.
> > > 
> > 
> > I understand it. Nokia originally invented their own entries in /proc/
> > which export needed ATAGs from kernel in human-readable form, but all
> > those entries were non-standard and specific for Nokia's kernels.
> > 
> > Do you have some other idea how to provide ATAGs information created
> > dynamically by legacy closed proprietary bootloader to userspace from DT
> > booted kernel?
> > 
> > Anyway, for supporting kexec (with passing ATAGs) it is needed to have
> > working /proc/atags file, right?
> 
> Yeah I think that since we already have it in /proc, we should just
> support it. And keep it behind CONFIG_KEXEC and CONFIG_ARM_APPENDED_DTB
> and hope we don't find other users for it.. Then reconsider the Kconfig
> dependencies if we do find other users.
>  
> > > It also sets a precedent: by adding this into DT, it is creating a new
> > > DT ABI as well, and we'll end up seeing dts files with an ATAG block
> > > patched into them.
> > > 
> > > Are the ATAGs at a fixed address on the N900?
> > 
> > Yes, in board-rx51.c is:
> > 
> > .atag_offset= 0x100
> > 
> > and Nokia Bootloader (proprietary) store them to that address.
> >
> > > Can that be handled in
> > > some kind of legacy file for the N900 which calls save_atags() on it, so
> > > we don't end up introducing yet more stuff that we have to maintain into
> > > the distant future?  If not, what about copying a known working atag
> > > structure into a legacy file for the N900?
> >
> > I already asked question if it is possible to read ATAGs from DT booted
> > kernel. And somebody (do not remember who) wrote to ML, that it is not
> > possible and it can be done in that uncompress code.
> 
> I guess the other option would be to keep the raw ATAG area reserved,
> and only initialize /proc/atags from a board specific initcall.
> But I think that would complicate the already fragile uncompress
> relocation code even further?

Pali, any news on posting an updated series with the comments addressed
in this thread? It seems that we all pretty much agree what needs to
be done.

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: [PATCH 12/17] ARM: OMAP2+: remove misuse of IRQF_NO_SUSPEND flag

[Tony Lindgren]

* Sudeep Holla  [150921 08:52]:
> The IRQF_NO_SUSPEND flag is used to identify the interrupts that should
> be left enabled so as to allow them to work as expected during the
> suspend-resume cycle, but doesn't guarantee that it will wake the system
> from a suspended state, enable_irq_wake is recommended to be used for
> the wakeup.
> 
> This patch removes the use of IRQF_NO_SUSPEND flags replacing it with
> enable_irq_wake instead.

Applying into omap-for-v4.4/cleanup thanks.

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: [PATCH 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry

[Pali Rohár]

On Monday 12 October 2015 22:16:40 Tony Lindgren wrote:
> * Tony Lindgren  [150713 06:21]:
> > * Pali Rohár  [150707 05:00]:
> > > On Tuesday 07 July 2015 12:32:13 Russell King - ARM Linux wrote:
> > > > On Mon, Jul 06, 2015 at 10:26:13PM +0200, Pali Rohár wrote:
> > > > > Legacy bootloaders can pass additional information for kernel
> > > > > or legacy userspace applications. When booting DT kernel
> > > > > then ATAGs structure is not more visible after running
> > > > > kernel uncompress code. This patch stores full ATAGs
> > > > > structure into DT "/chosen/linux,atags" entry, so kernel can
> > > > > later reuse it and export via /proc/atags to userspace.
> > > > 
> > > > I think you need to go through your commit messages and improve
> > > > them, especially the ones with "TODO" in them.  As long as
> > > > there's still things to be done, they're obviously not ready
> > > > for merging.
> > > 
> > > I know, in cover letter email I wrote that documentation is not
> > > ready... I send patches for review and comments (like yours). I
> > > think it is still better to send something and mark it as
> > > incomplete. It could prevent to work on something which will be
> > > again rewritten...
> > > 
> > > > Moreover, exporting the ATAGS is questionable, even _if_ there
> > > > are non- kexec programs making use of this.  The ATAGs have
> > > > _never_ been exported to userspace when kexec disabled is the
> > > > kernel - it was introduced for kexec, and has always had this:
> > > > 
> > > > config ATAGS_PROC
> > > > 
> > > > bool "Export atags in procfs"
> > > > depends on ATAGS && KEXEC
> > > > default y
> > > > 
> > > > Now, the fact that someone decided to start using it is pretty
> > > > sad, because it means that if you disable KEXEC, userspace
> > > > breaks.  That's not a kernel regression in any shape or form,
> > > > because /proc/atags has never been there without KEXEC
> > > > enabled.  That's a userspace bug, plain and simple.
> > > > 
> > > > Given that, I'm in two minds about whether to accept the last
> > > > two patches which make this more than just "for KEXEC use to
> > > > enable a KEXEC kernel to be booted."
> > > > 
> > > > Had it been provided without the KEXEC conditional, then I
> > > > don't have a problem with these two patches.
> > > 
> > > I understand it. Nokia originally invented their own entries in
> > > /proc/ which export needed ATAGs from kernel in human-readable
> > > form, but all those entries were non-standard and specific for
> > > Nokia's kernels.
> > > 
> > > Do you have some other idea how to provide ATAGs information
> > > created dynamically by legacy closed proprietary bootloader to
> > > userspace from DT booted kernel?
> > > 
> > > Anyway, for supporting kexec (with passing ATAGs) it is needed to
> > > have working /proc/atags file, right?
> > 
> > Yeah I think that since we already have it in /proc, we should just
> > support it. And keep it behind CONFIG_KEXEC and
> > CONFIG_ARM_APPENDED_DTB and hope we don't find other users for
> > it.. Then reconsider the Kconfig dependencies if we do find other
> > users.
> > 
> > > > It also sets a precedent: by adding this into DT, it is
> > > > creating a new DT ABI as well, and we'll end up seeing dts
> > > > files with an ATAG block patched into them.
> > > > 
> > > > Are the ATAGs at a fixed address on the N900?
> > > 
> > > Yes, in board-rx51.c is:
> > > 
> > > .atag_offset  = 0x100
> > > 
> > > and Nokia Bootloader (proprietary) store them to that address.
> > > 
> > > > Can that be handled in
> > > > some kind of legacy file for the N900 which calls save_atags()
> > > > on it, so we don't end up introducing yet more stuff that we
> > > > have to maintain into the distant future?  If not, what about
> > > > copying a known working atag structure into a legacy file for
> > > > the N900?
> > > 
> > > I already asked question if it is possible to read ATAGs from DT
> > > booted kernel. And somebody (do not remember who) wrote to ML,
> > > that it is not possible and it can be done in that uncompress
> > > code.
> > 
> > I guess the other option would be to keep the raw ATAG area
> > reserved, and only initialize /proc/atags from a board specific
> > initcall. But I think that would complicate the already fragile
> > uncompress relocation code even further?
> 
> Pali, any news on posting an updated series with the comments
> addressed in this thread? It seems that we all pretty much agree
> what needs to be done.
> 
> Regards,
> 
> Tony

Tony, I'm not really sure what to do. Just wrap 4 and 5 patches into 
CONFIG_KEXEC? Or something more?

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH 12/17] ARM: OMAP2+: remove misuse of IRQF_NO_SUSPEND flag

[Tony Lindgren]

* Tony Lindgren  [151012 13:27]:
> * Sudeep Holla  [150921 08:52]:
> > The IRQF_NO_SUSPEND flag is used to identify the interrupts that should
> > be left enabled so as to allow them to work as expected during the
> > suspend-resume cycle, but doesn't guarantee that it will wake the system
> > from a suspended state, enable_irq_wake is recommended to be used for
> > the wakeup.
> > 
> > This patch removes the use of IRQF_NO_SUSPEND flags replacing it with
> > enable_irq_wake instead.
> 
> Applying into omap-for-v4.4/cleanup thanks.

Actually I don't think this does the right thing. The interrupts
in the $subject patch are in the always on powerdomain, and we really
want them to be excluded from the suspend.

So not applying without further explanations.

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: [PATCH 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry

[Tony Lindgren]

* Pali Rohár  [151012 13:29]:
> On Monday 12 October 2015 22:16:40 Tony Lindgren wrote:
> > 
> > Pali, any news on posting an updated series with the comments
> > addressed in this thread? It seems that we all pretty much agree
> > what needs to be done.
> 
> Tony, I'm not really sure what to do. Just wrap 4 and 5 patches into 
> CONFIG_KEXEC? Or something more?

Well for most part your patches are fine, I think there were some
minor comments on the series.

For the CONFIG_KEXEC dependency, we should just keep the existing
behavior and keep /proc/atags behind CONFIG_KEXEC. That's all
I believe :)

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: [PATCH] mfd: omap-usb-host: AM3715 OHCI needs 120m functional clock

[Tony Lindgren]

* Ben Dooks  [151012 11:22]:
> On 12/10/15 18:45, Tony Lindgren wrote:
> > * Ben Dooks  [151012 10:38]:
> >> The AM3715 OHCI controller will not function without the EHCI
> >> unit's 120m fclk being enabled. If all the ports in the system
> >> are set to OHCI then the 120m_fclk will not get enabled and no
> >> devices are detected.
> >>
> >> Add a new (optional) property to signal the system must enable
> >> the 120m_fck for OHCI so that if no EHCI ports are signalled
> >> then the 120m_fclk should be enabled.
> >>
> >> We have found no information about why this is necessary, but
> >> it is suspected the EHCI controller does not complete the initial
> >> reset sequence and therefore does not hand control of the USB
> >> port back.
> >>
> >> Signed-off-by: Ben Dooks 
> >> ---
> >>  Documentation/devicetree/bindings/usb/omap-usb.txt | 3 +++
> >>  drivers/mfd/omap-usb-host.c| 4 
> >>  2 files changed, 7 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt 
> >> b/Documentation/devicetree/bindings/usb/omap-usb.txt
> >> index 38d9bb8..fb5fea5 100644
> >> --- a/Documentation/devicetree/bindings/usb/omap-usb.txt
> >> +++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
> >> @@ -23,6 +23,9 @@ OMAP MUSB GLUE
> >>  Optional properties:
> >>   - ctrl-module : phandle of the control module this glue uses to write to
> >> mailbox
> >> + - ti,ohci-needs-120m-fck : bool, enable the 120m ehci clock even if just
> >> +   using ohci. Needed for AM3517 in OHCI only mode.
> >> +
> >>  
> >>  SOC specific device node entry
> >>  usb_otg_hs: usb_otg_hs@4a0ab000 {
> >> diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
> >> index 1d924d1..13880cf 100644
> >> --- a/drivers/mfd/omap-usb-host.c
> >> +++ b/drivers/mfd/omap-usb-host.c
> >> @@ -680,6 +680,10 @@ static int usbhs_omap_probe(struct platform_device 
> >> *pdev)
> >>need_logic_fck |= true;
> >>}
> >>  
> >> +  /* The AM3517 requries the 120m-fck active to allow the OHCI to 
> >> work */
> >> +  if (of_property_read_bool(dev->of_node, 
> >> "ti,ohci-needs-120m-fck"))
> >> +  need_logic_fck |= true;
> >> +
> >>if (need_logic_fck) {
> >>omap->ehci_logic_fck = devm_clk_get(dev,
> >>"usbhost_120m_fck");
> > 
> > Hmm why not just use the standard device tree clocks property and then do
> > clk_get_rate() on the clock?
> 
> I don't see that helps enabling the clock. The code decideds if
> no EHCI ports in use that it doesn't need to enable the EHCI fclk.

Right, you need to do clk_prepare_enable() in it first? :)

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: [RFC 0/7] ARM: OMAP2+: support for DT based pwrdm/clkdm data

[Tony Lindgren]

* Tero Kristo  [151006 06:27]:
> On 10/06/2015 03:09 PM, Tony Lindgren wrote:
> >* Tero Kristo  [150814 05:36]:
> >>
> >>Basically the question with this set is, whether the DT node layout /
> >>compatible string arrangement looks sane or not. Some of the compatibles
> >>can be squashed together especially at clkdm data side, seeing the
> >>remaining stub data portions are rather minimal. They could also just be
> >>retained just in case we need to tweak something later
> >
> >Well does this play along with the genpd? Let's assume that within
> >a few merge cycles we have proper s3220 interconnect driver for
> >each L4 instance along the lines of simple-pm-bus ;)
> 
> I guess the question is what shall we represent under genpd. This series
> represents/registers each clockdomain / powerdomain as a single genpd entity
> (see patch #6, it adds the support for registering genpds.) If the plan is
> to represent also each hwmod device as a genpd entity, it should work fine I
> think, as each device can have a single clkdm as their parent.

I think we can replace the ti,hwmods eventually with the following:

1. L4 specific interconnect bus code for each L4 instance that I have in
   the works

2. Support for genpd like you've done

3. Using reset controllers like you've done

4. Some binding for the sysc/syss registers like I suggested earlier
   and have the L4 interconnect code manage these for each device

So I don't think we'll have much non-standard things left there to represent
except #4 above.

> Patch #6 is still missing support for actual control of the domains, the
> functions are just dummies. Hwmod should use genpd also instead of direct
> control of clkdms.
> 
> We could also add support for voltagedomains under genpd if required.

I think these might be automatic if we split things into separate L4
bus instances? For L4_WKUP, it's really within L4_CORE at least on some
SoCs, but probably in a different segment.

> This RFC series is rather minimal in functionality still just to get some
> feedback of the approaches taken.

Yes I think this is nice in general.

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

[PATCH 2/2] ARM: dts: omap3-igep0020: Remove duplicate uart2 pinmux

[Laurent Pinchart]

uart2 pinmux is already defined in omap3-igep0020-common.dtsi, remove
the duplicate node.

Signed-off-by: Laurent Pinchart 
---
 arch/arm/boot/dts/omap3-igep0020.dts | 9 -
 1 file changed, 9 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-igep0020.dts 
b/arch/arm/boot/dts/omap3-igep0020.dts
index fea7f7edb45d..5683b8bf3475 100644
--- a/arch/arm/boot/dts/omap3-igep0020.dts
+++ b/arch/arm/boot/dts/omap3-igep0020.dts
@@ -45,15 +45,6 @@
OMAP3_CORE1_IOPAD(0x216a, PIN_OUTPUT | MUX_MODE4)   
/* sdmmc2_dat7.gpio_139 - RST_N_B */
>;
};
-
-   uart2_pins: pinmux_uart2_pins {
-   pinctrl-single,pins = <
-   OMAP3_CORE1_IOPAD(0x2174, PIN_INPUT | MUX_MODE0)
/* uart2_cts.uart2_cts */
-   OMAP3_CORE1_IOPAD(0x2176, PIN_OUTPUT | MUX_MODE0)   
/* uart2_rts .uart2_rts*/
-   OMAP3_CORE1_IOPAD(0x2178, PIN_OUTPUT | MUX_MODE0)   
/* uart2_tx.uart2_tx */
-   OMAP3_CORE1_IOPAD(0x217a, PIN_INPUT | MUX_MODE0)
/* uart2_rx.uart2_rx */
-   >;
-   };
 };
 
 /* On board Wifi module */
-- 
Regards,

Laurent Pinchart

--
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 1/2] ARM: dts: omap3-igep: Fix indentation

[Laurent Pinchart]

Use tabs instead of spaces for indentation.

Signed-off-by: Laurent Pinchart 
---
 arch/arm/boot/dts/omap3-igep.dtsi | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-igep.dtsi 
b/arch/arm/boot/dts/omap3-igep.dtsi
index d5e5cd449b16..0b4736f19eb5 100644
--- a/arch/arm/boot/dts/omap3-igep.dtsi
+++ b/arch/arm/boot/dts/omap3-igep.dtsi
@@ -161,7 +161,7 @@
twl_audio: audio {
compatible = "ti,twl4030-audio";
codec {
- };
+   };
};
};
 };
@@ -181,11 +181,11 @@
 };
 
  {
-  pinctrl-names = "default";
-  pinctrl-0 = <_pins>;
-  vmmc-supply = <>;
-  vmmc_aux-supply = <>;
-  bus-width = <4>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   vmmc-supply = <>;
+   vmmc_aux-supply = <>;
+   bus-width = <4>;
 };
 
  {
@@ -193,13 +193,13 @@
 };
 
  {
-   pinctrl-names = "default";
-   pinctrl-0 = <_pins>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
 };
 
  {
-   pinctrl-names = "default";
-   pinctrl-0 = <_pins>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
 };
 
 _gpio {
-- 
Regards,

Laurent Pinchart

--
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: am437x-gp-evm: Add DCAN sleep pins

[Tony Lindgren]

* Roger Quadros  [150818 07:05]:
> Add DCAN sleep pins to save some power during suspend.
...
> @@ -879,14 +893,16 @@
>  };
>  
>   {
> - pinctrl-names = "default";
> - pinctrl-0 = <_default>;
> +pinctrl-names = "default", "sleep";
> +pinctrl-0 = <_default>;
> +pinctrl-1 = <_sleep>;
>   status = "okay";
>  };
>  
>   {
> - pinctrl-names = "default";
> - pinctrl-0 = <_default>;
> +pinctrl-names = "default", "sleep";
> +pinctrl-0 = <_default>;
> +pinctrl-1 = <_sleep>;
>   status = "okay";
>  };

Applying into omap-for-v4.4/dt after fixing the tabs above.

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

[PATCH 0/3] delete unneeded of_node_put

[Julia Lawall]

Device node iterators perform an of_node_put on each iteration, so putting
an of_node_put before going around to the next iteration results in a
double put.

The complete semantic patch that fixes this problem is as follows
(http://coccinelle.lip6.fr):

// 
@r exists@
expression e1,e2;
local idexpression n;
iterator name for_each_node_by_name, for_each_node_by_type,
for_each_compatible_node, for_each_matching_node,
for_each_matching_node_and_match, for_each_child_of_node,
for_each_available_child_of_node, for_each_node_with_property;
iterator i;
position p1,p2;
statement S;
@@

(
(
for_each_node_by_name(n,e1) S
|
for_each_node_by_type(n,e1) S
|
for_each_compatible_node(n,e1,e2) S
|
for_each_matching_node(n,e1) S
|
for_each_matching_node_and_match(n,e1,e2) S
|
for_each_child_of_node(e1,n) S
|
for_each_available_child_of_node(e1,n) S
|
for_each_node_with_property(n,e1) S
)
&
i@p1(...) {
   ... when != of_node_get(n)
   when any
   of_node_put@p2(n);
   ... when any
}
)

@s exists@
local idexpression r.n;
statement S;
position r.p1,r.p2;
iterator i;
@@

 of_node_put@p2(n);
 ... when any
 i@p1(..., n, ...)
 S

@depends on s@
local idexpression n;
position r.p2;
@@

- of_node_put@p2(n);
// 

---

 arch/arm/mach-exynos/pm_domains.c |8 +++-
 drivers/soc/qcom/smd.c|4 +---
 drivers/video/fbdev/omap2/dss/omapdss-boot-init.c |4 +---
 3 files changed, 5 insertions(+), 11 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

[PATCH 1/3] video: omapdss: delete unneeded of_node_put

[Julia Lawall]

Device node iterators perform an of_node_put on each iteration, so putting
an of_node_put before a continue results in a double put.

A simplified version of the semantic match that finds this problem is as
follows (http://coccinelle.lip6.fr):

// 
@@
expression root,e;
local idexpression child;
iterator i;
@@

 i(..., child, ...) {
   ... when != of_node_get(child)
*  of_node_put(child);
   ...
*  continue;
}
// 

Signed-off-by: Julia Lawall 

---
 drivers/video/fbdev/omap2/dss/omapdss-boot-init.c |4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/video/fbdev/omap2/dss/omapdss-boot-init.c 
b/drivers/video/fbdev/omap2/dss/omapdss-boot-init.c
index 8b6f6d5..136d304 100644
--- a/drivers/video/fbdev/omap2/dss/omapdss-boot-init.c
+++ b/drivers/video/fbdev/omap2/dss/omapdss-boot-init.c
@@ -199,10 +199,8 @@ static int __init omapdss_boot_init(void)
omapdss_walk_device(dss, true);
 
for_each_available_child_of_node(dss, child) {
-   if (!of_find_property(child, "compatible", NULL)) {
-   of_node_put(child);
+   if (!of_find_property(child, "compatible", NULL))
continue;
-   }
 
omapdss_walk_device(child, true);
}

--
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/11] ARM: OMAP/DTS: dra7/72-evm/beagle-x15: Audio support

[Tony Lindgren]

* Tony Lindgren  [150914 09:32]:
> * Peter Ujfalusi  [150914 01:54]:
> > Hi Tony,
> > 
> > On 08/24/2015 10:19 AM, Peter Ujfalusi wrote:
> > > Hi,
> > > 
> > > this series will enable analog audio (via onboard aic310x codec) for 
> > > dra7-evm,
> > > dra72-evm and am57xx-beagle-x15 boards.
> > > In these board McASP3 is connected to the codec and for the McASP3 we 
> > > needed to
> > > have the DMA crossbar in place since the request lines are not mapped by
> > > default.
> > 
> > Did you had a chance to look at this series?
> 
> Looks OK to me, will look at it more once we have the fixes merged.
> 
> Paul may have comments on the hwmod chage, looks like you forgot
> to Cc him on it. Can you please resend that one with Paul in Cc?

Applying all the dts changes into omap-for-v4.3/dt thanks. Paul
can pick up the hwmod change then after reviewing it.

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: [PATCH 0/3] ARM: dts: dra7-evm: enable leds and gpio-keys support

[Tony Lindgren]

* Grygorii Strashko  [150924 09:50]:
> Hi Tony,
> 
> On 08/27/2015 08:20 AM, Grygorii Strashko wrote:
> >This series enables support for leds and gpio-keys which
> >is available on dra7-evm. It also adds pcf8575 gpio expander (i2c1 addr 20)
> >
> >Grygorii Strashko (3):
> >   ARM: dts: dra7-evm: add pcf8575 gpio expander (i2c1 addr 20)
> >   ARM: dts: dra7-evm: add gpio leds support
> >   ARM: dts: dra7-evm: add gpio key support
> >
> >  arch/arm/boot/dts/dra7-evm.dts | 58 
> > ++
> >  1 file changed, 58 insertions(+)
> >
> 
> Are there any comments on this series?
> Could it be applied?

Looks good to me so applying all into omap-for-v4.4/dt thanks.

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: [PATCH 2/2] ARM: dts: am335x-wega: Clean up regulators

[Tony Lindgren]

* Teresa Remmet  [150903 05:03]:
> Cleaned up the regulators on the wega board. Created a simple bus,
> renamed the regulators according to the schematics and added missing
> regulator on wega.

Applying this one into omap-for-v4.4/dt thanks.

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

[PATCH 01/37] ARM: dts: am437x-gp-evm: Remove unneeded regulator property

[Laurent Pinchart]

The enable-active-high regulator property only makes sense when an
enable GPIO is specified. Remove it.

Signed-off-by: Laurent Pinchart 
---
 arch/arm/boot/dts/am437x-gp-evm.dts | 1 -
 1 file changed, 1 deletion(-)

Cc: linux-omap@vger.kernel.org
Cc: Benoit Cousson 
Cc: Tony Lindgren 

diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts 
b/arch/arm/boot/dts/am437x-gp-evm.dts
index 84aa30c3235a..a3cd413aebf0 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -29,7 +29,6 @@
regulator-name = "vmmcsd_fixed";
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
-   enable-active-high;
};
 
vtt_fixed: fixedregulator-vtt {
-- 
2.4.9

--
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 09/37] ARM: dts: omap3-tao3530: Remove invalid enable-active-low regulator property

[Laurent Pinchart]

The property isn't part of the regulator-fixed DT bindings and isn't
used by the driver. Remove it.

Signed-off-by: Laurent Pinchart 
---
 arch/arm/boot/dts/omap3-tao3530.dtsi | 1 -
 1 file changed, 1 deletion(-)

Cc: linux-omap@vger.kernel.org
Cc: Benoit Cousson 
Cc: Tony Lindgren 

diff --git a/arch/arm/boot/dts/omap3-tao3530.dtsi 
b/arch/arm/boot/dts/omap3-tao3530.dtsi
index 7bd8d9a4f67f..a520b4fdcf20 100644
--- a/arch/arm/boot/dts/omap3-tao3530.dtsi
+++ b/arch/arm/boot/dts/omap3-tao3530.dtsi
@@ -63,7 +63,6 @@
regulator-min-microvolt = <315>;
regulator-max-microvolt = <315>;
gpio = < 29 GPIO_ACTIVE_LOW>; /* gpio_157 */
-   enable-active-low;
startup-delay-us = <1>;
};
 };
-- 
2.4.9

--
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 33/37] ARM: dts: omap3-tao3530: Fix regulator enable GPIO polarity

[Laurent Pinchart]

The enable GPIO is active low, but is flagged as active high in the gpio
property. As the gpio property flags are currently unused by the driver
this doesn't cause any issue for now, but will break later if the driver
starts making use of the flags. Fix it.

Signed-off-by: Laurent Pinchart 
---
 arch/arm/boot/dts/omap3-tao3530.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Cc: linux-omap@vger.kernel.org
Cc: Benoit Cousson 
Cc: Tony Lindgren 

diff --git a/arch/arm/boot/dts/omap3-tao3530.dtsi 
b/arch/arm/boot/dts/omap3-tao3530.dtsi
index a520b4fdcf20..68f75be5d99a 100644
--- a/arch/arm/boot/dts/omap3-tao3530.dtsi
+++ b/arch/arm/boot/dts/omap3-tao3530.dtsi
@@ -37,7 +37,7 @@
regulator-name = "hsusb2_vbus";
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
-   gpio = <_gpio 18 0>;/* GPIO LEDA */
+   gpio = <_gpio 18 GPIO_ACTIVE_LOW>;  /* GPIO LEDA */
startup-delay-us = <7>;
};
 
-- 
2.4.9

--
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 08/37] ARM: dts: omap3-sb-t35: Remove invalid enable-active-low regulator property

[Laurent Pinchart]

The property isn't part of the regulator-fixed DT bindings and isn't
used by the driver. Remove it.

Signed-off-by: Laurent Pinchart 
---
 arch/arm/boot/dts/omap3-sb-t35.dtsi | 1 -
 1 file changed, 1 deletion(-)

Cc: linux-omap@vger.kernel.org
Cc: Benoit Cousson 
Cc: Tony Lindgren 

diff --git a/arch/arm/boot/dts/omap3-sb-t35.dtsi 
b/arch/arm/boot/dts/omap3-sb-t35.dtsi
index 827f614261f6..b77e25d20e07 100644
--- a/arch/arm/boot/dts/omap3-sb-t35.dtsi
+++ b/arch/arm/boot/dts/omap3-sb-t35.dtsi
@@ -50,7 +50,6 @@
pinctrl-names = "default";
pinctrl-0 = <_t35_audio_amp>;
gpio = < 29 GPIO_ACTIVE_LOW>;   /* gpio_61 */
-   enable-active-low;
regulator-always-on;
};
 };
-- 
2.4.9

--
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 00/37] ARM: dts: Fix fixed regulators enable GPIO polarity

[Laurent Pinchart]

Hello,

While working on regulators, GPIOs and DT I noticed that many of our DT source
files incorrectly describe fixed regulators. The common error patterns are

- Usage of the undefined (and never parsed) enable-active-low property
- Usage of the enable-active-high property without specifying an enable GPIO
- Typos in the enabl GPIO property name (gpios instead of gpio)
- Mismatch between the enable-active-high property (or the lack thereof) and
  the enable GPIO flags

This patch series fixes those issues in all the DT sources after locating the
errors using the following script.

--
#!/bin/sh

echo $1
cat $1 | awk '
BEGIN {
open_drain = 0;
active_high = 0;
gpio = 0;
flags = 0;
}

match($0, /([a-zA-Z0-9@_-]*) {/, ary) {
name = ary[1];
}

/compatible.*"regulator-fixed"/ {
found = 1;
}

/enable-active-high/ {
active_high = 1;
}

/gpio-open-drain/ {
open_drain = 1;
}

match($0, /gpio += <.* ([^ ]*)>/, ary) {
gpio = 1;
flags = ary[1];
if (flags == 0)
flags = "GPIO_ACTIVE_HIGH";
}

/}/ {
if (found) {
if (gpio) {
print "\t" name ": active high " active_high " " flags 
" open drain " open_drain;
if ((active_high && flags == "GPIO_ACTIVE_LOW") ||
(!active_high && flags == "GPIO_ACTIVE_HIGH"))
print "WARNING: enable-active-high and flags do 
not match"
} else {
if (active_high)
print "WARNING: active high without GPIO"
if (open_drain)
print "WARNING: open drain without GPIO"
}
}

gpio = 0;
found = 0;
active_high = 0;
open_drain = 0;
flags = 0;
}
'
--

All patches except for the ones touching omap3-beagle-xm and omap3-overo-base
are untested as I lack test hardware.

As there's no dependency between the patches touching different source files
the appropriate maintainers could take their share of the patches in their
tree. Alternatively I could send a single pull request after collecting all
acks but that might be more complex.

Cc: devicet...@vger.kernel.org
Cc: linux-omap@vger.kernel.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-te...@vger.kernel.org
Cc: linux-g...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: Benoit Cousson 
Cc: Tony Lindgren 
Cc: Jason Cooper 
Cc: Andrew Lunn 
Cc: Gregory Clement 
Cc: Sebastian Hesselbarth 
Cc: Kukjin Kim 
Cc: Krzysztof Kozlowski 
Cc: Shawn Guo 
Cc: Sascha Hauer 
Cc: Stephen Warren 
Cc: Thierry Reding 
Cc: Alexandre Courbot 
Cc: Liam Girdwood 
Cc: Mark Brown 
Cc: Linus Walleij 

Laurent Pinchart (37):
  ARM: dts: am437x-gp-evm: Remove unneeded regulator property
  ARM: dts: am43xx-epos-evm: Remove unneeded regulator property
  ARM: mvebu: Armada 388 GP: Remove unneeded regulator property
  ARM: imx6sx-sdb: Fix typo in regulator enable GPIO property
  ARM: dts: s5pv210-aquila: Fix typo in regulator enable GPIO property
  ARM: dts: s5pv210-goni: Fix typo in regulator enable GPIO property
  ARM: dts: omap3-evm: Remove invalid enable-active-low regulator
property
  ARM: dts: omap3-sb-t35: Remove invalid enable-active-low regulator
property
  ARM: dts: omap3-tao3530: Remove invalid enable-active-low regulator
property
  ARM: dts: imx6qdl-tx6: Fix regulator enable GPIO polarity
  ARM: dts: dove-cm-a510: Fix regulator enable GPIO polarity
  ARM: dts: dove-sbc-a510: Fix regulator enable GPIO polarity
  ARM: dts: exynos5250-arndale: Fix regulator enable GPIO polarity
  ARM: dts: imx23-evk: Fix regulator enable GPIO polarity
  ARM: dts: imx23-stmp378x_devb: Fix regulator enable GPIO polarity
  ARM: dts: imx25-pdk: Fix regulator enable GPIO polarity
  ARM: dts: imx28-cfa10036: Fix regulator enable GPIO polarity
  ARM: dts: imx28-evk: Fix regulator enable GPIO polarity
  ARM: dts: imx28-m28cu3: Fix regulator enable GPIO polarity
  ARM: dts: imx28-m28evk: Fix regulator enable GPIO polarity
  ARM: dts: imx28-sps1: Fix regulator enable GPIO polarity
  ARM: dts: imx28-tx28: Fix regulator enable GPIO polarity
  ARM: dts: imx53-m53evk: Fix regulator enable GPIO polarity
  ARM: dts: imx53-mba53: Fix regulator enable GPIO polarity
  ARM: dts: imx53-tx53: Fix regulator enable GPIO polarity
  ARM: dts: imx6q-dmo-edmqmx6: Fix regulator enable 

[PATCH 28/37] ARM: dts: omap4-duovero: Fix regulator enable GPIO polarity

[Laurent Pinchart]

The enable GPIO is active high, but is flagged as active low in the gpio
property. As the gpio property flags are currently unused by the driver
this doesn't cause any issue for now, but will break later if the driver
starts making use of the flags. Fix it.

Signed-off-by: Laurent Pinchart 
---
 arch/arm/boot/dts/omap4-duovero.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Cc: linux-omap@vger.kernel.org
Cc: Benoit Cousson 
Cc: Tony Lindgren 

diff --git a/arch/arm/boot/dts/omap4-duovero.dtsi 
b/arch/arm/boot/dts/omap4-duovero.dtsi
index f2a94fa62552..23c1a74f91ea 100644
--- a/arch/arm/boot/dts/omap4-duovero.dtsi
+++ b/arch/arm/boot/dts/omap4-duovero.dtsi
@@ -56,7 +56,7 @@
regulator-name = "w2cbw0015";
regulator-min-microvolt = <300>;
regulator-max-microvolt = <300>;
-   gpio = < 11 GPIO_ACTIVE_LOW>; /* gpio_43 */
+   gpio = < 11 GPIO_ACTIVE_HIGH>;/* gpio_43 */
startup-delay-us = <7>;
enable-active-high;
regulator-boot-on;
-- 
2.4.9

--
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 02/37] ARM: dts: am43xx-epos-evm: Remove unneeded regulator property

[Laurent Pinchart]

The enable-active-high regulator property only makes sense when an
enable GPIO is specified. Remove it.

Signed-off-by: Laurent Pinchart 
---
 arch/arm/boot/dts/am43x-epos-evm.dts | 1 -
 1 file changed, 1 deletion(-)

Cc: linux-omap@vger.kernel.org
Cc: Benoit Cousson 
Cc: Tony Lindgren 

diff --git a/arch/arm/boot/dts/am43x-epos-evm.dts 
b/arch/arm/boot/dts/am43x-epos-evm.dts
index 795d68af6df9..705048bf17c5 100644
--- a/arch/arm/boot/dts/am43x-epos-evm.dts
+++ b/arch/arm/boot/dts/am43x-epos-evm.dts
@@ -28,7 +28,6 @@
regulator-name = "vmmcsd_fixed";
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
-   enable-active-high;
};
 
lcd0: display {
-- 
2.4.9

--
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 31/37] ARM: dts: omap3-beagle: Fix regulator enable GPIO polarity

[Laurent Pinchart]

The enable GPIO is active low, but is flagged as active high in the gpio
property. As the gpio property flags are currently unused by the driver
this doesn't cause any issue for now, but will break later if the driver
starts making use of the flags. Fix it.

Signed-off-by: Laurent Pinchart 
---
 arch/arm/boot/dts/omap3-beagle.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Cc: linux-omap@vger.kernel.org
Cc: Benoit Cousson 
Cc: Tony Lindgren 

diff --git a/arch/arm/boot/dts/omap3-beagle.dts 
b/arch/arm/boot/dts/omap3-beagle.dts
index a5474113cd50..0849035643fc 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -55,7 +55,7 @@
regulator-name = "hsusb2_vbus";
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
-   gpio = <_gpio 18 0>;/* GPIO LEDA */
+   gpio = <_gpio 18 GPIO_ACTIVE_LOW>;  /* GPIO LEDA */
startup-delay-us = <7>;
};
 
-- 
2.4.9

--
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 30/37] ARM: dts: omap3-beagle-xm: Fix regulator enable GPIO polarity

[Laurent Pinchart]

The enable GPIO is active low, but is flagged as active high in the gpio
property. As the gpio property flags are currently unused by the driver
this doesn't cause any issue for now, but will break later if the driver
starts making use of the flags. Fix it.

Signed-off-by: Laurent Pinchart 
---
 arch/arm/boot/dts/omap3-beagle-xm.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Cc: linux-omap@vger.kernel.org
Cc: Benoit Cousson 
Cc: Tony Lindgren 

diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts 
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index 7c4dca122a91..f44f17673061 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -80,7 +80,7 @@
regulator-name = "hsusb2_vbus";
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
-   gpio = <_gpio 18 0>;/* GPIO LEDA */
+   gpio = <_gpio 18 GPIO_ACTIVE_LOW>;  /* GPIO LEDA */
startup-delay-us = <7>;
};
 
-- 
2.4.9

--
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 32/37] ARM: dts: omap3-overo-base: Fix regulator enable GPIO polarity

[Laurent Pinchart]

The enable GPIO is active low, but is flagged as active high in the gpio
property. As the gpio property flags are currently unused by the driver
this doesn't cause any issue for now, but will break later if the driver
starts making use of the flags. Fix it.

Signed-off-by: Laurent Pinchart 
---
 arch/arm/boot/dts/omap3-overo-base.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Cc: linux-omap@vger.kernel.org
Cc: Benoit Cousson 
Cc: Tony Lindgren 

diff --git a/arch/arm/boot/dts/omap3-overo-base.dtsi 
b/arch/arm/boot/dts/omap3-overo-base.dtsi
index 18e1649681c1..1fa59d0e1e8a 100644
--- a/arch/arm/boot/dts/omap3-overo-base.dtsi
+++ b/arch/arm/boot/dts/omap3-overo-base.dtsi
@@ -65,7 +65,7 @@
regulator-name = "regulator-w3cbw003c-wifi-nreset";
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
-   gpio = < 16 GPIO_ACTIVE_HIGH>;/* gpio_16: 
WiFi nReset */
+   gpio = < 16 GPIO_ACTIVE_LOW>; /* gpio_16: 
WiFi nReset */
startup-delay-us = <1>;
};
 
@@ -75,7 +75,7 @@
regulator-name = "regulator-w3cbw003c-bt-nreset";
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
-   gpio = < 4 GPIO_ACTIVE_HIGH>; /* gpio_164: BT 
nReset */
+   gpio = < 4 GPIO_ACTIVE_LOW>;  /* gpio_164: BT 
nReset */
startup-delay-us = <1>;
};
 };
-- 
2.4.9

--
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 07/37] ARM: dts: omap3-evm: Remove invalid enable-active-low regulator property

[Laurent Pinchart]

The property isn't part of the regulator-fixed DT bindings and isn't
used by the driver. Remove it.

Signed-off-by: Laurent Pinchart 
---
 arch/arm/boot/dts/omap3-evm-common.dtsi | 1 -
 1 file changed, 1 deletion(-)

Cc: linux-omap@vger.kernel.org
Cc: Benoit Cousson 
Cc: Tony Lindgren 

diff --git a/arch/arm/boot/dts/omap3-evm-common.dtsi 
b/arch/arm/boot/dts/omap3-evm-common.dtsi
index b2589f96d5f7..c55f256d014b 100644
--- a/arch/arm/boot/dts/omap3-evm-common.dtsi
+++ b/arch/arm/boot/dts/omap3-evm-common.dtsi
@@ -76,7 +76,6 @@
 
 _3v3 {
gpio = < 25 GPIO_ACTIVE_LOW>; /* gpio153 */
-   enable-active-low;
 };
 
  {
-- 
2.4.9

--
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/37] ARM: dts: Fix fixed regulators enable GPIO polarity

[Tony Lindgren]

* Laurent Pinchart  [151012 14:17]:
> Hello,
> 
> While working on regulators, GPIOs and DT I noticed that many of our DT source
> files incorrectly describe fixed regulators. The common error patterns are
> 
> - Usage of the undefined (and never parsed) enable-active-low property
> - Usage of the enable-active-high property without specifying an enable GPIO
> - Typos in the enabl GPIO property name (gpios instead of gpio)
> - Mismatch between the enable-active-high property (or the lack thereof) and
>   the enable GPIO flags
> 
> This patch series fixes those issues in all the DT sources after locating the
> errors using the following script.
> 
> --
> #!/bin/sh
> 
> echo $1
> cat $1 | awk '
> BEGIN {
>   open_drain = 0;
>   active_high = 0;
>   gpio = 0;
>   flags = 0;
> }
> 
> match($0, /([a-zA-Z0-9@_-]*) {/, ary) {
>   name = ary[1];
> }
> 
> /compatible.*"regulator-fixed"/ {
>   found = 1;
> }
> 
> /enable-active-high/ {
>   active_high = 1;
> }
> 
> /gpio-open-drain/ {
>   open_drain = 1;
> }
> 
> match($0, /gpio += <.* ([^ ]*)>/, ary) {
>   gpio = 1;
>   flags = ary[1];
>   if (flags == 0)
>   flags = "GPIO_ACTIVE_HIGH";
> }
> 
> /}/ {
>   if (found) {
>   if (gpio) {
>   print "\t" name ": active high " active_high " " flags 
> " open drain " open_drain;
>   if ((active_high && flags == "GPIO_ACTIVE_LOW") ||
>   (!active_high && flags == "GPIO_ACTIVE_HIGH"))
>   print "WARNING: enable-active-high and flags do 
> not match"
>   } else {
>   if (active_high)
>   print "WARNING: active high without GPIO"
>   if (open_drain)
>   print "WARNING: open drain without GPIO"
>   }
>   }
> 
>   gpio = 0;
>   found = 0;
>   active_high = 0;
>   open_drain = 0;
>   flags = 0;
> }
> '
> --
> 
> All patches except for the ones touching omap3-beagle-xm and omap3-overo-base
> are untested as I lack test hardware.
> 
> As there's no dependency between the patches touching different source files
> the appropriate maintainers could take their share of the patches in their
> tree. Alternatively I could send a single pull request after collecting all
> acks but that might be more complex.

Nice clean-up. For omaps, there's an earlier patch posted by
Javier Martinez Canillas  as "[PATCH] ARM: dts: Use
defined GPIO constants in flags cell for OMAP2+ boards". Can you guys do some
cross checking and let me know which combination I should appluy for omaps?

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: [PATCH v2 1/4] ARM: dts: dra7: Add dt node for the sycon pcie

[Kishon Vijay Abraham I]

Hi,

On Tuesday 13 October 2015 03:42 AM, Tony Lindgren wrote:
> * Kishon Vijay Abraham I  [151012 15:09]:
>> Hi,
>>
>> On Tuesday 13 October 2015 03:33 AM, Tony Lindgren wrote:
>>> * Kishon Vijay Abraham I  [151012 14:50]:
 Hi Tony,

 On Tuesday 13 October 2015 02:51 AM, Tony Lindgren wrote:
> * Kishon Vijay Abraham I  [150915 06:37]:
>> Add new device tree node for the control module register space where
>> PCIe registers are present.
>>
>> Signed-off-by: Kishon Vijay Abraham I 
>> ---
>>  arch/arm/boot/dts/dra7.dtsi |5 +
>>  1 file changed, 5 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
>> index 5d65db9..0769b5d 100644
>> --- a/arch/arm/boot/dts/dra7.dtsi
>> +++ b/arch/arm/boot/dts/dra7.dtsi
>> @@ -154,6 +154,11 @@
>>  compatible = "syscon";
>>  reg = <0x1c04 0x0020>;
>>  };
>> +
>> +scm_conf_pcie: tisyscon@1c24 {
>> +compatible = "syscon";
>> +reg = <0x1c24 0x0024>;
>> +};
>>  };
>>  
>>  cm_core_aon: cm_core_aon@5000 {
>
>
> Why don't you just extend the existing scm_conf1 area? This is not all 
> pcie
> specific for scm_conf_pcie, at least for PLLEN_CONTROL, RMII_CLK_SETTING
> and MUXSEL_32K_CLKIN.

 scm_conf_pcie has only PCIe registers (it starts at 0x4A003C24).
 PLLEN_CONTROL and others are at 0x4A003C14 as per
 DRA75x_DRA74x_SR1.1_NDA_TRM_vW.
>>>
>>> Oh sorry I guess I was looking at a wrong address then.
>>>
 Since PCIe itself has a bunch of registers for itself, thought of
 creating a separate dt node. But I can extend scm_conf1 area.
>>>
>>> Why not just ioremap them then? Do these need to be shared with
>>> some other driver?
>>
>> yeah, some are used by PCIe controller driver and some are used by PCIe
>> PHY driver.
> 
> OK makes sense to me then.

Cool.

Btw the driver modifications has not yet been merged, so don't merge
these yet. I'll repost these once the driver is merged.

Thanks
Kishon
--
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/37] ARM: dts: Fix fixed regulators enable GPIO polarity

[Javier Martinez Canillas]

Hello Tony,

On 10/12/2015 11:46 PM, Tony Lindgren wrote:
> * Laurent Pinchart  [151012 14:17]:
>> Hello,
>>
>> While working on regulators, GPIOs and DT I noticed that many of our DT 
>> source
>> files incorrectly describe fixed regulators. The common error patterns are
>>
>> - Usage of the undefined (and never parsed) enable-active-low property
>> - Usage of the enable-active-high property without specifying an enable GPIO
>> - Typos in the enabl GPIO property name (gpios instead of gpio)
>> - Mismatch between the enable-active-high property (or the lack thereof) and
>>   the enable GPIO flags
>>
>> This patch series fixes those issues in all the DT sources after locating the
>> errors using the following script.
>>
>> --
>> #!/bin/sh
>>
>> echo $1
>> cat $1 | awk '
>> BEGIN {
>>  open_drain = 0;
>>  active_high = 0;
>>  gpio = 0;
>>  flags = 0;
>> }
>>
>> match($0, /([a-zA-Z0-9@_-]*) {/, ary) {
>>  name = ary[1];
>> }
>>
>> /compatible.*"regulator-fixed"/ {
>>  found = 1;
>> }
>>
>> /enable-active-high/ {
>>  active_high = 1;
>> }
>>
>> /gpio-open-drain/ {
>>  open_drain = 1;
>> }
>>
>> match($0, /gpio += <.* ([^ ]*)>/, ary) {
>>  gpio = 1;
>>  flags = ary[1];
>>  if (flags == 0)
>>  flags = "GPIO_ACTIVE_HIGH";
>> }
>>
>> /}/ {
>>  if (found) {
>>  if (gpio) {
>>  print "\t" name ": active high " active_high " " flags 
>> " open drain " open_drain;
>>  if ((active_high && flags == "GPIO_ACTIVE_LOW") ||
>>  (!active_high && flags == "GPIO_ACTIVE_HIGH"))
>>  print "WARNING: enable-active-high and flags do 
>> not match"
>>  } else {
>>  if (active_high)
>>  print "WARNING: active high without GPIO"
>>  if (open_drain)
>>  print "WARNING: open drain without GPIO"
>>  }
>>  }
>>
>>  gpio = 0;
>>  found = 0;
>>  active_high = 0;
>>  open_drain = 0;
>>  flags = 0;
>> }
>> '
>> --
>>
>> All patches except for the ones touching omap3-beagle-xm and omap3-overo-base
>> are untested as I lack test hardware.
>>
>> As there's no dependency between the patches touching different source files
>> the appropriate maintainers could take their share of the patches in their
>> tree. Alternatively I could send a single pull request after collecting all
>> acks but that might be more complex.
> 
> Nice clean-up. For omaps, there's an earlier patch posted by
> Javier Martinez Canillas  as "[PATCH] ARM: dts: Use
> defined GPIO constants in flags cell for OMAP2+ boards". Can you guys do some
> cross checking and let me know which combination I should appluy for omaps?
>

Since Laurent's changes for OMAP are part of a bigger series and my patch
was only for OMAP, probably makes sense for you to pick his patches and I
can re-spin mine on top of that.

BTW, I posted as a single patch since the changes were trivial but maybe
that made handling these conflicts harder and I should split the changes
instead, since I'll resend anyways.

What do you prefer? a patch per SoC family (i.e: OMAP{2,3,4,5}) or patch
per board DTS?
 
> Regards,
> 
> Tony
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
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 1/2] ARM: dts: omap3-igep: Fix indentation

[Laurent Pinchart]

Hi Javier,

On Tuesday 13 October 2015 00:26:58 Javier Martinez Canillas wrote:
> On Mon, Oct 12, 2015 at 10:46 PM, Laurent Pinchart wrote:
> > Use tabs instead of spaces for indentation.
> > 
> > Signed-off-by: Laurent Pinchart 
> 
> Acked-by: Javier Martinez Canillas 

Thank you.

Tony, could you please pick the series up for v4.4 ?

-- 
Regards,

Laurent Pinchart

--
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/3] ARM: multi_v7_defconfig: Enable more OMAP family platforms

[Nishanth Menon]

On 10/12/2015 03:04 PM, Tony Lindgren wrote:
> * Nishanth Menon  [150813 08:12]:
>> On Tue, Aug 11, 2015 at 5:37 AM, Tony Lindgren  wrote:
>>>
>>> * Kevin Hilman  [150807 16:10]:
 Tony Lindgren  writes:

> Ping, looks like these are still pending. Probably should be
> applied directly by the arm-soc maintainers.

 If these should go through arm-soc, please resend to:a...@kernel.org so
 they make it into our queue of stuff to be reviewed/applied.
>>>
>>> OK thanks, up to Nihshant to resend.
>>>
>>
>> Sorry about the slow response - i will have to do this at a later
>> point(probably based off 4.3-rc1). tied up with a few other internal
>> stuff atm :(
> 
> Ping, can you please resend a...@kernel.org? Would be good to have these
> working for v4.4.
> 
> Anyways, untagging this old thread so don't expect more pings from
> me on this.
> 

Will do. Sorry about the delay - we had to bring down our board
farm(where the boards were hosted) for a few days due to some internal
relocation. will get around to this asap.


-- 
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 v3] ARM: dts: twl4030: Add iio properties for bci subnode

[Sebastian Reichel]

Hi,

On Mon, Oct 12, 2015 at 03:20:10PM -0700, Tony Lindgren wrote:
> * Tony Lindgren  [151012 14:43]:
> > * Belisko Marek  [150926 13:02]:
> > > Tony sorry I forgot to add you to the recipients for this patchset.
> > > Can you please queue this patch. Many thanks.
> > 
> > OK applying into omap-for-v4.4/dt thanks.
> 
> Actually dropping this one, it makes build fail as we don't
> have twl4030_madc yet.
> 
> Maybe please send a separate set of dts patches for me.

mh that's strange, twl4030-madc is there since a long time. But
checking the patch, it seems Marek got the phandle wrong:

$ grep -B1 "ti,twl4030-madc" arch/arm/boot/dts/twl4030.dtsi
twl_madc: madc {
compatible = "ti,twl4030-madc";

Once that is fixed, the patch should have no dependencies.

-- Sebastian


signature.asc
Description: PGP signature

Re: [PATCH] ARM: dts: Add am335x-bonegreen

[Tony Lindgren]

* Robert Nelson  [150925 08:14]:
> SeeedStudio BeagleBone Green (BBG) is clone of the BeagleBone Black (BBB) 
> minus
> the HDMI port and addition of two Grove connectors (i2c2 and usart2).
> 
> This board can be identified by the 1A value after A335BNLT (BBB) in the at24 
> eeprom:
> 1A: [aa 55 33 ee 41 33 33 35  42 4e 4c 54 1a 00 00 00 |.U3.A335BNLT|]
> 
> http://beagleboard.org/green
> http://www.seeedstudio.com/wiki/Beaglebone_green

Thanks applying into omap-for-v4.4/dt.

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: [REPOST PATCH 1/4] ARM: dts: DRA7: Add dsp1_system syscon node

[Suman Anna]

Hi Tony,

On 10/12/2015 04:43 PM, Tony Lindgren wrote:
> * Suman Anna  [151002 16:27]:
>> The DSP_SYSTEM sub-module is a dedicated system control logic
>> module present within a DRA7 DSP processor sub-system. This
>> module is responsible for power management, clock generation
>> and connection to the device PRCM module.
>>
>> Add a syscon node for this module for the DSP1 processor
>> sub-system. This is added as a syscon node as it is a common
>> configuration module that can be used by the different IOMMU
>> instances and the corresponding remoteproc device.
>>
>> The node is added to the common dra7.dtsi file, as the DSP1
>> processor sub-system is mostly common across all the variants
>> of the DRA7 SoC family.
>>
>> Signed-off-by: Suman Anna 
>> ---
>>  arch/arm/boot/dts/dra7.dtsi | 5 +
>>  1 file changed, 5 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
>> index e289c706d27d..62055094e8d5 100644
>> --- a/arch/arm/boot/dts/dra7.dtsi
>> +++ b/arch/arm/boot/dts/dra7.dtsi
>> @@ -292,6 +292,11 @@
>>  #thermal-sensor-cells = <1>;
>>  };
>>  
>> +dsp1_system: dsp_system@40d0 {
>> +compatible = "syscon";
>> +reg = <0x40d0 0x100>;
>> +};
>> +
>>  sdma: dma-controller@4a056000 {
>>  compatible = "ti,omap4430-sdma";
>>  reg = <0x4a056000 0x1000>;
> 
> Hmm so why would you want to set up a complete device as a syscon
> mapping rather than just doing ioremap on it?
> 
> What drivers will be sharing access to these registers?

Two different instances of the MMU for now, both get probed
independently. But there are other registers which a remoteproc driver
will mostly be interested in (like DSP_SYS_STAT for knowing the C66x
idle/active status).

regards
Suman
--
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: am57xx-beagle-x15: set VDD_SD to always-on

[Tony Lindgren]

* Nishanth Menon  [150925 07:38]:
> On 09/25/2015 08:02 AM, Tomi Valkeinen wrote:
> > LDO1 regulator (VDD_SD) is connected to SoC's vddshv8. vddshv8 needs to
> > be kept always powered (see commit 5a0f93c6576a ("ARM: dts: Add
> > am57xx-beagle-x15"), but at the moment VDD_SD is enabled/disabled
> > depending on whether an SD card is inserted or not.
> > 
> > This patch sets LDO1 regulator to always-on.
> > 
> > This patch has a side effect of fixing another issue, HDMI DDC not
> > working when SD card is not inserted:
> > 
> > Why this happens is that the tpd12s015 (HDMI level shifter/ESD
> > protection chip) has LS_OE GPIO input, which needs to be enabled for the
> > HDMI DDC to work. LS_OE comes from gpio6_28. The pin that provides
> > gpio6_28 is powered by vddshv8, and vddshv8 comes from VDD_SD.
> > 
> > So when SD card is not inserted, VDD_SD is disabled, and LS_OE stays
> > off.
> > 
> > The proper fix for the HDMI DDC issue would be to maybe have the pinctrl
> > framework manage the pin specific power.
> > 
> > Apparently this fixes also a third issue (copy paste from Kishon's
> > patch):
> > 
> > ldo1_reg in addition to being connected to the io lines is also
> > connected to the card detect line. On card removal, omap_hsmmc
> > driver does a regulator_disable causing card detect line to be
> > pulled down. This raises a card insertion interrupt and once the
> > MMC core detects there is no card inserted, it does a
> > regulator disable which again raises a card insertion interrupt.
> > This happens in a loop causing infinite MMC interrupts.
> > 
> > Fixes: 5a0f93c6576a ("ARM: dts: Add am57xx-beagle-x15")
> > Cc: Kishon Vijay Abraham I 
> > Signed-off-by: Tomi Valkeinen 
> > Reported-by: Louis McCarthy 
> 
> Acked-by: Nishanth Menon 

Applying into omap-for-v4.3/fixes thanks.

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: [PATCH 2/2] arm: omap2+: PM: change trace_power_domain_target event format.

[Tony Lindgren]

* Marc Titinger  [150925 08:02]:
> 
> 
> On 25/09/2015 16:10, Steven Rostedt wrote:
> >On Fri, 25 Sep 2015 15:22:25 +0200
> >Marc Titinger  wrote:
> >
> >>From: Marc Titinger 
> >>
> >>power_domain_target arg3 is now a string (event name) with generic power
> >>domains. In the case of Omap, it is a hint to the prev/next switch op.
> >>Incidentally this trace is now conditioned by CONFIG_PM_ADVANCED_DEBUG.
> >I'm curious to why the addition of this config option?
> >
> I meant to be consistent with Juno/generic-power-domains, so that this trace
> always (or never) requires this switch.
> I think I will remove this condition for both actually.
> 
> >>Compiled for Omap2+ but not tested.
> >>
> >>Signed-off-by: Marc Titinger 
> >>---
> >>  arch/arm/mach-omap2/powerdomain.c | 32 
> >>  1 file changed, 20 insertions(+), 12 deletions(-)
> >>
> >>diff --git a/arch/arm/mach-omap2/powerdomain.c 
> >>b/arch/arm/mach-omap2/powerdomain.c
> >>index 78af6d8..cd77696 100644
> >>--- a/arch/arm/mach-omap2/powerdomain.c
> >>+++ b/arch/arm/mach-omap2/powerdomain.c
> >>@@ -160,7 +160,7 @@ static void _update_logic_membank_counters(struct 
> >>powerdomain *pwrdm)
> >>  static int _pwrdm_state_switch(struct powerdomain *pwrdm, int flag)
> >>  {
> >>-   int prev, next, state, trace_state = 0;
> >>+   int prev, state;
> >>if (pwrdm == NULL)
> >>return -EINVAL;
> >>@@ -177,18 +177,25 @@ static int _pwrdm_state_switch(struct powerdomain 
> >>*pwrdm, int flag)
> >>pwrdm->state_counter[prev]++;
> >>if (prev == PWRDM_POWER_RET)
> >>_update_logic_membank_counters(pwrdm);
> >>-   /*
> >>-* If the power domain did not hit the desired state,
> >>-* generate a trace event with both the desired and hit states
> >>-*/
> >>-   next = pwrdm_read_next_pwrst(pwrdm);
> >>-   if (next != prev) {
> >>-   trace_state = (PWRDM_TRACE_STATES_FLAG |
> >>+
> >>+#ifdef CONFIG_PM_ADVANCED_DEBUG
> >You do realize that you can add this to the block:
> >
> >
> > if (trace_power_domain_target_enabled()) {
> Nope I didn't, but now I do ;) thanks.

Probably best to keep this with your series, it should not cause merge 
conflicts,
so:

Acked-by: Tony Lindgren 
--
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: omap3-lilly-a83x: Don't use IRQ level flag for a GPIO

[Tony Lindgren]

* Javier Martinez Canillas  [151006 02:27]:
> The card detect GPIO is using IRQ_TYPE_LEVEL_LOW in the GPIO flag cells
> but this defined constant is meant to be used for a IRQ and not a GPIO.
> So instead use GPIO_ACTIVE_LOW that seems to be the original intention.
> 
> Signed-off-by: Javier Martinez Canillas 

Applying into omap-for-v4.4/dt thanks.

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: [PATCH 00/37] ARM: dts: Fix fixed regulators enable GPIO polarity

[Tony Lindgren]

* Laurent Pinchart  [151012 15:26]:
> Hi Javier,
> 
> On Tuesday 13 October 2015 00:19:20 Javier Martinez Canillas wrote:
> > On 10/12/2015 11:46 PM, Tony Lindgren wrote:
> > > * Laurent Pinchart  [151012 14:17]:
> > >> Hello,
> > >> 
> > >> While working on regulators, GPIOs and DT I noticed that many of our DT
> > >> source files incorrectly describe fixed regulators. The common error
> > >> patterns are
> > >> 
> > >> - Usage of the undefined (and never parsed) enable-active-low property
> > >> - Usage of the enable-active-high property without specifying an enable
> > >>   GPIO
> > >> - Typos in the enabl GPIO property name (gpios instead of gpio)
> > >> - Mismatch between the enable-active-high property (or the lack thereof)
> > >>   and the enable GPIO flags
> > >> 
> > >> This patch series fixes those issues in all the DT sources after locating
> > >> the errors using the following script.
> > >> 
> > >> -
> > >> !/bin/sh
> > >> 
> > >> echo $1
> > >> cat $1 | awk '
> > >> BEGIN {
> > >>  open_drain = 0;
> > >>  active_high = 0;
> > >>  gpio = 0;
> > >>  flags = 0;
> > >> }
> > >> 
> > >> match($0, /([a-zA-Z0-9@_-]*) {/, ary) {
> > >>  name = ary[1];
> > >> }
> > >> 
> > >> /compatible.*"regulator-fixed"/ {
> > >>  found = 1;
> > >> }
> > >> 
> > >> /enable-active-high/ {
> > >>  active_high = 1;
> > >> }
> > >> 
> > >> /gpio-open-drain/ {
> > >>  open_drain = 1;
> > >> }
> > >> 
> > >> match($0, /gpio += <.* ([^ ]*)>/, ary) {
> > >>  gpio = 1;
> > >>  flags = ary[1];
> > >>  if (flags == 0)
> > >>  flags = "GPIO_ACTIVE_HIGH";
> > >> }
> > >> 
> > >> /}/ {
> > >>  if (found) {
> > >>  if (gpio) {
> > >>  print "\t" name ": active high " active_high " " flags 
> > >> " open 
> drain "
> > >>  open_drain;
> > >>  if ((active_high && flags == "GPIO_ACTIVE_LOW") ||
> > >>  (!active_high && flags == "GPIO_ACTIVE_HIGH"))
> > >>  print "WARNING: enable-active-high and flags do 
> > >> not 
> match"
> > >>  } else {
> > >>  if (active_high)
> > >>  print "WARNING: active high without GPIO"
> > >>  if (open_drain)
> > >>  print "WARNING: open drain without GPIO"
> > >>  }
> > >>  }
> > >>  
> > >>  gpio = 0;
> > >>  found = 0;
> > >>  active_high = 0;
> > >>  open_drain = 0;
> > >>  flags = 0;
> > >> }
> > >> '
> > >> -
> > >> 
> > >> All patches except for the ones touching omap3-beagle-xm and
> > >> omap3-overo-base are untested as I lack test hardware.
> > >> 
> > >> As there's no dependency between the patches touching different source
> > >> files the appropriate maintainers could take their share of the patches
> > >> in their tree. Alternatively I could send a single pull request after
> > >> collecting all acks but that might be more complex.
> > > 
> > > Nice clean-up. For omaps, there's an earlier patch posted by
> > > Javier Martinez Canillas  as "[PATCH] ARM: dts:
> > > Use defined GPIO constants in flags cell for OMAP2+ boards". Can you guys
> > > do some cross checking and let me know which combination I should appluy
> > > for omaps?
> >
> > Since Laurent's changes for OMAP are part of a bigger series and my patch
> > was only for OMAP, probably makes sense for you to pick his patches and I
> > can re-spin mine on top of that.
> > 
> > BTW, I posted as a single patch since the changes were trivial but maybe
> > that made handling these conflicts harder and I should split the changes
> > instead, since I'll resend anyways.
> > 
> > What do you prefer? a patch per SoC family (i.e: OMAP{2,3,4,5}) or patch
> > per board DTS?
> 
> My series will likely miss the next merge window as more discussion is 
> needed. 
> I'll thus respin the patches on top of yours, please proceed without caring 
> about this.

OK applying Javier's patch into omap-for-v4.4/dt then.

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: [PATCH] ARM: dts: Use defined GPIO constants in flags cell for OMAP2+ boards

[Tony Lindgren]

* Javier Martinez Canillas  [151006 02:08]:
> Many OMAP2+ DTS are not using the defined constants to express
> the GPIO polarity. Replace these so the DTS are easier to read.


Applying this into omap-for-v4.4/dt thanks.

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: [PATCH] ARM: OMAP2+: PM: Denote the cpuidle tracepoints as _rcuidle()

[Tony Lindgren]

* Jisheng Zhang  [150923 20:26]:
> Dear Tony,
> 
> On Wed, 23 Sep 2015 11:08:15 -0700
> Tony Lindgren  wrote:
> 
> > * Kevin Hilman  [150923 11:03]:
> > > Jisheng Zhang  writes:
> > > 
> > > > The cpuidle tracepoints are called within a rcu_idle_exit() section, and
> > > > must be denoted with the _rcuidle() version of the tracepoint.
> > > >
> > > > Signed-off-by: Jisheng Zhang 
> > >  
> > > Acked-by: Kevin Hilman 
> > 
> > Hmm is this needed as a fix for the -rc cycle or can this wait
> > for v4.4?
> 
> IMHO, this is a fix. But it can wait for v4.4 merge window.

Applying into omap-for-v4.4/fixes thanks.

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: [PATCH v3 27/27] ARM: dts: omap3: Fix gpmc and NAND nodes

[Tony Lindgren]

* Roger Quadros  [150918 08:00]:
> Add compatible id, GPMC register resource and interrupt
> resource to NAND controller nodes.
> 
> The GPMC driver now implements gpiochip and irqchip so
> enable gpio-controller and interrupt-controller properties.
> 
> With this the interrupt parent of NAND node changes so fix it
> accordingly.
...
> --- a/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
> +++ b/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
> @@ -35,11 +35,14 @@
>  };
>  
>   {
> - ranges = <0 0 0x 0x100>;/* CS0: 16MB for NAND */
> + ranges = <0 0 0x0800 0x100>;/* CS0: 16MB for NAND */
>  
>   nand@0,0 {
> - linux,mtd-name = "micron,mt29f4g16abbda3w";
> + compatible = "ti,omap2-nand";
>   reg = <0 0 4>; /* CS0, offset 0, IO size 4 */
> + interrupt-parent = <>;
> + interrupts = <20>;
> + linux,mtd-name = "micron,mt29f4g16abbda3w";
>   nand-bus-width = <16>;
>   ti,nand-ecc-opt = "bch8";
>   gpmc,sync-clk-ps = <0>;

At least torpedo breaks for NFSroot as NAND now overlaps with
Ethernet.. What's the policy you have for moving the addresses
around?

There may be other similar cases to check too.

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: [PATCH 0/5] Add DRA7 sub-mailboxes for 4.4

[Tony Lindgren]

* Suman Anna  [150918 11:20]:
> Hi Tony,
> 
> This series adds the sub-mailbox nodes and enable them for each
> of the TI DRA7 boards. These are the basic mailbox configuration
> nodes required by client users (remoteproc) to communicate with
> the various IPU and DSP processor devices on DRA74x and DRA72x
> SoCs using the TI IPC 3.x software foundation on the remote
> processor firmwares. The mailboxes used are unfortunately
> hardcoded in the TI IPC 3.x software, and hence the weird
> usage of Mailbox 5 and 6 rather than starting from Mailbox 1.
> 
> Any third-party or derived boards can use their own configuration
> if running their own IPC stack, and that can be done by overwriting
> the properties or by using different sub-mailbox nodes altogether.
> The actual enablement of nodes is therefore done in the respective
> board DTS files.
> 
> Patches are based on 4.3-rc1 and are intended for the 4.4 merge
> window.

Thanks applying all into omap-for-v4.4/dt.

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: [PATCH 00/37] ARM: dts: Fix fixed regulators enable GPIO polarity

[Laurent Pinchart]

Hi Javier,

On Tuesday 13 October 2015 00:19:20 Javier Martinez Canillas wrote:
> On 10/12/2015 11:46 PM, Tony Lindgren wrote:
> > * Laurent Pinchart  [151012 14:17]:
> >> Hello,
> >> 
> >> While working on regulators, GPIOs and DT I noticed that many of our DT
> >> source files incorrectly describe fixed regulators. The common error
> >> patterns are
> >> 
> >> - Usage of the undefined (and never parsed) enable-active-low property
> >> - Usage of the enable-active-high property without specifying an enable
> >>   GPIO
> >> - Typos in the enabl GPIO property name (gpios instead of gpio)
> >> - Mismatch between the enable-active-high property (or the lack thereof)
> >>   and the enable GPIO flags
> >> 
> >> This patch series fixes those issues in all the DT sources after locating
> >> the errors using the following script.
> >> 
> >> -
> >> !/bin/sh
> >> 
> >> echo $1
> >> cat $1 | awk '
> >> BEGIN {
> >>open_drain = 0;
> >>active_high = 0;
> >>gpio = 0;
> >>flags = 0;
> >> }
> >> 
> >> match($0, /([a-zA-Z0-9@_-]*) {/, ary) {
> >>name = ary[1];
> >> }
> >> 
> >> /compatible.*"regulator-fixed"/ {
> >>found = 1;
> >> }
> >> 
> >> /enable-active-high/ {
> >>active_high = 1;
> >> }
> >> 
> >> /gpio-open-drain/ {
> >>open_drain = 1;
> >> }
> >> 
> >> match($0, /gpio += <.* ([^ ]*)>/, ary) {
> >>gpio = 1;
> >>flags = ary[1];
> >>if (flags == 0)
> >>flags = "GPIO_ACTIVE_HIGH";
> >> }
> >> 
> >> /}/ {
> >>if (found) {
> >>if (gpio) {
> >>print "\t" name ": active high " active_high " " flags 
> >> " open 
drain "
> >>open_drain;
> >>if ((active_high && flags == "GPIO_ACTIVE_LOW") ||
> >>(!active_high && flags == "GPIO_ACTIVE_HIGH"))
> >>print "WARNING: enable-active-high and flags do 
> >> not 
match"
> >>} else {
> >>if (active_high)
> >>print "WARNING: active high without GPIO"
> >>if (open_drain)
> >>print "WARNING: open drain without GPIO"
> >>}
> >>}
> >>
> >>gpio = 0;
> >>found = 0;
> >>active_high = 0;
> >>open_drain = 0;
> >>flags = 0;
> >> }
> >> '
> >> -
> >> 
> >> All patches except for the ones touching omap3-beagle-xm and
> >> omap3-overo-base are untested as I lack test hardware.
> >> 
> >> As there's no dependency between the patches touching different source
> >> files the appropriate maintainers could take their share of the patches
> >> in their tree. Alternatively I could send a single pull request after
> >> collecting all acks but that might be more complex.
> > 
> > Nice clean-up. For omaps, there's an earlier patch posted by
> > Javier Martinez Canillas  as "[PATCH] ARM: dts:
> > Use defined GPIO constants in flags cell for OMAP2+ boards". Can you guys
> > do some cross checking and let me know which combination I should appluy
> > for omaps?
>
> Since Laurent's changes for OMAP are part of a bigger series and my patch
> was only for OMAP, probably makes sense for you to pick his patches and I
> can re-spin mine on top of that.
> 
> BTW, I posted as a single patch since the changes were trivial but maybe
> that made handling these conflicts harder and I should split the changes
> instead, since I'll resend anyways.
> 
> What do you prefer? a patch per SoC family (i.e: OMAP{2,3,4,5}) or patch
> per board DTS?

My series will likely miss the next merge window as more discussion is needed. 
I'll thus respin the patches on top of yours, please proceed without caring 
about this.

-- 
Regards,

Laurent Pinchart

--
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: [REPOST PATCH 1/4] ARM: dts: DRA7: Add dsp1_system syscon node

[Tony Lindgren]

* Suman Anna  [151012 15:37]:
> Hi Tony,
> 
> On 10/12/2015 04:43 PM, Tony Lindgren wrote:
> > * Suman Anna  [151002 16:27]:
> >> The DSP_SYSTEM sub-module is a dedicated system control logic
> >> module present within a DRA7 DSP processor sub-system. This
> >> module is responsible for power management, clock generation
> >> and connection to the device PRCM module.
> >>
> >> Add a syscon node for this module for the DSP1 processor
> >> sub-system. This is added as a syscon node as it is a common
> >> configuration module that can be used by the different IOMMU
> >> instances and the corresponding remoteproc device.
> >>
> >> The node is added to the common dra7.dtsi file, as the DSP1
> >> processor sub-system is mostly common across all the variants
> >> of the DRA7 SoC family.
> >>
> >> Signed-off-by: Suman Anna 
> >> ---
> >>  arch/arm/boot/dts/dra7.dtsi | 5 +
> >>  1 file changed, 5 insertions(+)
> >>
> >> diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
> >> index e289c706d27d..62055094e8d5 100644
> >> --- a/arch/arm/boot/dts/dra7.dtsi
> >> +++ b/arch/arm/boot/dts/dra7.dtsi
> >> @@ -292,6 +292,11 @@
> >>#thermal-sensor-cells = <1>;
> >>};
> >>  
> >> +  dsp1_system: dsp_system@40d0 {
> >> +  compatible = "syscon";
> >> +  reg = <0x40d0 0x100>;
> >> +  };
> >> +
> >>sdma: dma-controller@4a056000 {
> >>compatible = "ti,omap4430-sdma";
> >>reg = <0x4a056000 0x1000>;
> > 
> > Hmm so why would you want to set up a complete device as a syscon
> > mapping rather than just doing ioremap on it?
> > 
> > What drivers will be sharing access to these registers?
> 
> Two different instances of the MMU for now, both get probed
> independently. But there are other registers which a remoteproc driver
> will mostly be interested in (like DSP_SYS_STAT for knowing the C66x
> idle/active status).

OK makes sense to me then.

Thanks,

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: [PATCH v2 1/4] ARM: dts: dra7: Add dt node for the sycon pcie

[Tony Lindgren]

* Kishon Vijay Abraham I  [150915 06:37]:
> Add new device tree node for the control module register space where
> PCIe registers are present.
> 
> Signed-off-by: Kishon Vijay Abraham I 
> ---
>  arch/arm/boot/dts/dra7.dtsi |5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
> index 5d65db9..0769b5d 100644
> --- a/arch/arm/boot/dts/dra7.dtsi
> +++ b/arch/arm/boot/dts/dra7.dtsi
> @@ -154,6 +154,11 @@
>   compatible = "syscon";
>   reg = <0x1c04 0x0020>;
>   };
> +
> + scm_conf_pcie: tisyscon@1c24 {
> + compatible = "syscon";
> + reg = <0x1c24 0x0024>;
> + };
>   };
>  
>   cm_core_aon: cm_core_aon@5000 {


Why don't you just extend the existing scm_conf1 area? This is not all pcie
specific for scm_conf_pcie, at least for PLLEN_CONTROL, RMII_CLK_SETTING
and MUXSEL_32K_CLKIN.

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

[PATCH 4/5] ARM: dts: am437x/am33xx/omap3/dm816x: Add gpmc dma channel

[Franklin S Cooper Jr]

Add dma channel information to the gpmc. Although not enabled by
default this will allow prefetch-dma to be used.

Signed-off-by: Franklin S Cooper Jr 
---
 arch/arm/boot/dts/am33xx.dtsi | 2 ++
 arch/arm/boot/dts/am4372.dtsi | 2 ++
 arch/arm/boot/dts/dm816x.dtsi | 2 ++
 arch/arm/boot/dts/omap3.dtsi  | 2 ++
 4 files changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index e065f21..f2d8eed 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -819,6 +819,8 @@
ti,no-idle-on-init;
reg = <0x5000 0x2000>;
interrupts = <100>;
+   dmas = < 52>;
+   dma-names = "rxtx";
gpmc,num-cs = <7>;
gpmc,num-waitpins = <2>;
#address-cells = <2>;
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index ec8b7a3..c02061b 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -841,6 +841,8 @@
gpmc: gpmc@5000 {
compatible = "ti,am3352-gpmc";
ti,hwmods = "gpmc";
+   dmas = < 52>;
+   dma-names = "rxtx";
clocks = <_gclk>;
clock-names = "fck";
reg = <0x5000 0x2000>;
diff --git a/arch/arm/boot/dts/dm816x.dtsi b/arch/arm/boot/dts/dm816x.dtsi
index 68fb444..d2e5d31 100644
--- a/arch/arm/boot/dts/dm816x.dtsi
+++ b/arch/arm/boot/dts/dm816x.dtsi
@@ -180,6 +180,8 @@
#address-cells = <2>;
#size-cells = <1>;
interrupts = <100>;
+   dmas = < 52>;
+   dma-names = "rxtx";
gpmc,num-cs = <6>;
gpmc,num-waitpins = <2>;
gpio-controller;
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 7f212b6..9dbbcf6 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -717,6 +717,8 @@
ti,hwmods = "gpmc";
reg = <0x6e00 0x02d0>;
interrupts = <20>;
+   dmas = < 4>;
+   dma-names = "rxtx";
gpmc,num-cs = <8>;
gpmc,num-waitpins = <4>;
#address-cells = <2>;
-- 
2.6.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

[PATCH 5/5] ARM: OMAP2+: Update gpmc and nand DT binding documentation

[Franklin S Cooper Jr]

Add additional details to the gpmc and nand documentation to clarify
what is needed to enable nand dma prefetch.

Signed-off-by: Franklin S Cooper Jr 
---
 Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt | 7 ++-
 Documentation/devicetree/bindings/mtd/gpmc-nand.txt| 2 ++
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt 
b/Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt
index 704be93..b1e2802 100644
--- a/Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt
+++ b/Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt
@@ -33,6 +33,10 @@ Required properties:
As this will change in the future, filling correct
values here is a requirement.
 
+GPMC DMA information. Required only when GPMC nand prefetch is enabled.
+ - dmasGPMC nand prefetch dma channel
+ - dma-names   DMA channel name use as a reference within the Nand 
driver
+
 Timing properties for child nodes. All are optional and default to 0.
 
  - gpmc,sync-clk-ps:   Minimum clock period for synchronous mode, in 
picoseconds
@@ -119,7 +123,8 @@ Example for an AM33xx board:
ti,hwmods = "gpmc";
reg = <0x5000 0x2000>;
interrupts = <100>;
-
+   dmas = < 52>;
+   dma-names = "rxtx";
gpmc,num-cs = <8>;
gpmc,num-waitpins = <2>;
#address-cells = <2>;
diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt 
b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
index 253e6de..4b0c240 100644
--- a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
@@ -61,6 +61,8 @@ Example for an AM33xx board:
ti,hwmods = "gpmc";
reg = <0x5000 0x36c>;
interrupts = <100>;
+   dmas = < 52>;
+   dma-names = "rxtx";
gpmc,num-cs = <8>;
gpmc,num-waitpins = <2>;
#address-cells = <2>;
-- 
2.6.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

[PATCH 1/5] mtd: nand: omap2: Support parsing dma channel information from DT

[Franklin S Cooper Jr]

Switch from dma_request_channel to allow passing dma channel
information from DT rather than hardcoding a value.

Signed-off-by: Franklin S Cooper Jr 
---
 drivers/mtd/nand/omap2.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index d0f2620..957c32f 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -1866,7 +1866,9 @@ static int omap_nand_probe(struct platform_device *pdev)
dma_cap_zero(mask);
dma_cap_set(DMA_SLAVE, mask);
sig = OMAP24XX_DMA_GPMC;
-   info->dma = dma_request_channel(mask, omap_dma_filter_fn, );
+   info->dma = dma_request_slave_channel_compat(mask,
+   omap_dma_filter_fn, , pdev->dev.parent, "rxtx");
+
if (!info->dma) {
dev_err(>dev, "DMA engine request failed\n");
err = -ENXIO;
-- 
2.6.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

[PATCH 2/5] mtd: nand: omap2: Start dma request before enabling prefetch

[Franklin S Cooper Jr]

The prefetch engine sends a dma request once a FIFO threshold has
been met. No other requests are received until the previous request
is handled.

Starting an edma transfer (dma_async_issue_pending) results in any
previous event for the dma channel to be cleared. Therefore, starting
the prefetch engine before initiating the dma transfer may result in
the prefetch triggering a dma request but instead of it being handled
it can end up being cleared. This will result in a hang since the code
will continue to wait for the dma request to complete.

By initiating the dma request before enabling the prefetch engine this
race condition is avoided and no dma request are missed/cleared.

Signed-off-by: Franklin S Cooper Jr 
---
 drivers/mtd/nand/omap2.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 957c32f..94d11de 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -509,6 +509,9 @@ static inline int omap_nand_dma_transfer(struct mtd_info 
*mtd, void *addr,
tx->callback_param = >comp;
dmaengine_submit(tx);
 
+   init_completion(>comp);
+   dma_async_issue_pending(info->dma);
+
/*  configure and start prefetch transfer */
ret = omap_prefetch_enable(info->gpmc_cs,
PREFETCH_FIFOTHRESHOLD_MAX, 0x1, len, is_write, info);
@@ -516,9 +519,6 @@ static inline int omap_nand_dma_transfer(struct mtd_info 
*mtd, void *addr,
/* PFPW engine is busy, use cpu copy method */
goto out_copy_unmap;
 
-   init_completion(>comp);
-   dma_async_issue_pending(info->dma);
-
/* setup and start DMA using dma_addr */
wait_for_completion(>comp);
tim = 0;
-- 
2.6.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

[PATCH 3/5] mtd: nand: omap2: Fix high memory dma prefetch transfer

[Franklin S Cooper Jr]

Based on DMA documentation and testing using high memory buffer when
doing dma transfers can lead to various issues including kernel
panics.

To workaround this simply use cpu copy. The amount of high memory
buffers used are very uncommon so no noticeable performance hit should
be seen.

Signed-off-by: Franklin S Cooper Jr 
---
 drivers/mtd/nand/omap2.c | 14 +++---
 1 file changed, 3 insertions(+), 11 deletions(-)

diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 94d11de..537be2f 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -479,17 +479,8 @@ static inline int omap_nand_dma_transfer(struct mtd_info 
*mtd, void *addr,
int ret;
u32 val;
 
-   if (addr >= high_memory) {
-   struct page *p1;
-
-   if (((size_t)addr & PAGE_MASK) !=
-   ((size_t)(addr + len - 1) & PAGE_MASK))
-   goto out_copy;
-   p1 = vmalloc_to_page(addr);
-   if (!p1)
-   goto out_copy;
-   addr = page_address(p1) + ((size_t)addr & ~PAGE_MASK);
-   }
+   if (addr >= high_memory)
+   goto out_copy;
 
sg_init_one(, addr, len);
n = dma_map_sg(info->dma->device->dev, , 1, dir);
@@ -545,6 +536,7 @@ out_copy:
else
is_write == 0 ? omap_read_buf8(mtd, (u_char *) addr, len)
: omap_write_buf8(mtd, (u_char *) addr, len);
+
return 0;
 }
 
-- 
2.6.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

[PATCH 0/5] mtd: nand: Fix support for NAND DMA Prefetch

[Franklin S Cooper Jr]

NAND dma prefetch has been broken for awhile and seems to have only
worked for sdma based devices.

This patchset fixes DMA prefetch to work on both edma and sdma devices

Tested on:
am335x general purpose evm
am437x general purpose evm
am37x general purpose evm

This patchset depends on Roger Quadros recent v4 GPMC/NAND patchset

https://github.com/rogerq/linux.git
branch: for-v4.4/gpmc-v4

Franklin S Cooper Jr (5):
  mtd: nand: omap2: Support parsing dma channel information from DT
  mtd: nand: omap2: Start dma request before enabling prefetch
  mtd: nand: omap2: Fix high memory dma prefetch transfer
  ARM: dts: am437x/am33xx/omap3/dm816x: Add gpmc dma channel
  ARM: OMAP2+: Update gpmc and nand DT binding documentation

 .../bindings/memory-controllers/omap-gpmc.txt  |  7 ++-
 .../devicetree/bindings/mtd/gpmc-nand.txt  |  2 ++
 arch/arm/boot/dts/am33xx.dtsi  |  2 ++
 arch/arm/boot/dts/am4372.dtsi  |  2 ++
 arch/arm/boot/dts/dm816x.dtsi  |  2 ++
 arch/arm/boot/dts/omap3.dtsi   |  2 ++
 drivers/mtd/nand/omap2.c   | 24 --
 7 files changed, 25 insertions(+), 16 deletions(-)

-- 
2.6.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

Re: [PATCH v2 1/4] ARM: dts: dra7: Add dt node for the sycon pcie

[Kishon Vijay Abraham I]

Hi,

On Tuesday 13 October 2015 03:33 AM, Tony Lindgren wrote:
> * Kishon Vijay Abraham I  [151012 14:50]:
>> Hi Tony,
>>
>> On Tuesday 13 October 2015 02:51 AM, Tony Lindgren wrote:
>>> * Kishon Vijay Abraham I  [150915 06:37]:
 Add new device tree node for the control module register space where
 PCIe registers are present.

 Signed-off-by: Kishon Vijay Abraham I 
 ---
  arch/arm/boot/dts/dra7.dtsi |5 +
  1 file changed, 5 insertions(+)

 diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
 index 5d65db9..0769b5d 100644
 --- a/arch/arm/boot/dts/dra7.dtsi
 +++ b/arch/arm/boot/dts/dra7.dtsi
 @@ -154,6 +154,11 @@
compatible = "syscon";
reg = <0x1c04 0x0020>;
};
 +
 +  scm_conf_pcie: tisyscon@1c24 {
 +  compatible = "syscon";
 +  reg = <0x1c24 0x0024>;
 +  };
};
  
cm_core_aon: cm_core_aon@5000 {
>>>
>>>
>>> Why don't you just extend the existing scm_conf1 area? This is not all pcie
>>> specific for scm_conf_pcie, at least for PLLEN_CONTROL, RMII_CLK_SETTING
>>> and MUXSEL_32K_CLKIN.
>>
>> scm_conf_pcie has only PCIe registers (it starts at 0x4A003C24).
>> PLLEN_CONTROL and others are at 0x4A003C14 as per
>> DRA75x_DRA74x_SR1.1_NDA_TRM_vW.
> 
> Oh sorry I guess I was looking at a wrong address then.
> 
>> Since PCIe itself has a bunch of registers for itself, thought of
>> creating a separate dt node. But I can extend scm_conf1 area.
> 
> Why not just ioremap them then? Do these need to be shared with
> some other driver?

yeah, some are used by PCIe controller driver and some are used by PCIe
PHY driver.

Thanks
Kishon
--
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 v3] ARM: dts: twl4030: Add iio properties for bci subnode

[Tony Lindgren]

* Tony Lindgren  [151012 14:43]:
> * Belisko Marek  [150926 13:02]:
> > Tony sorry I forgot to add you to the recipients for this patchset.
> > Can you please queue this patch. Many thanks.
> 
> OK applying into omap-for-v4.4/dt thanks.

Actually dropping this one, it makes build fail as we don't
have twl4030_madc yet.

Maybe please send a separate set of dts patches for me.

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: [PATCH 1/2] ARM: dts: omap3-igep: Fix indentation

[Javier Martinez Canillas]

Hello Laurent,

Thanks for the patch.

On Mon, Oct 12, 2015 at 10:46 PM, Laurent Pinchart
 wrote:
> Use tabs instead of spaces for indentation.
>
> Signed-off-by: Laurent Pinchart 

Acked-by: Javier Martinez Canillas 

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: [REPOST PATCH 1/4] ARM: dts: DRA7: Add dsp1_system syscon node

[Tony Lindgren]

* Tony Lindgren  [151012 15:57]:
> * Suman Anna  [151012 15:37]:
> > Hi Tony,
> > 
> > On 10/12/2015 04:43 PM, Tony Lindgren wrote:
> > > * Suman Anna  [151002 16:27]:
> > >> The DSP_SYSTEM sub-module is a dedicated system control logic
> > >> module present within a DRA7 DSP processor sub-system. This
> > >> module is responsible for power management, clock generation
> > >> and connection to the device PRCM module.
> > >>
> > >> Add a syscon node for this module for the DSP1 processor
> > >> sub-system. This is added as a syscon node as it is a common
> > >> configuration module that can be used by the different IOMMU
> > >> instances and the corresponding remoteproc device.
> > >>
> > >> The node is added to the common dra7.dtsi file, as the DSP1
> > >> processor sub-system is mostly common across all the variants
> > >> of the DRA7 SoC family.
> > >>
> > >> Signed-off-by: Suman Anna 
> > >> ---
> > >>  arch/arm/boot/dts/dra7.dtsi | 5 +
> > >>  1 file changed, 5 insertions(+)
> > >>
> > >> diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
> > >> index e289c706d27d..62055094e8d5 100644
> > >> --- a/arch/arm/boot/dts/dra7.dtsi
> > >> +++ b/arch/arm/boot/dts/dra7.dtsi
> > >> @@ -292,6 +292,11 @@
> > >>  #thermal-sensor-cells = <1>;
> > >>  };
> > >>  
> > >> +dsp1_system: dsp_system@40d0 {
> > >> +compatible = "syscon";
> > >> +reg = <0x40d0 0x100>;
> > >> +};
> > >> +
> > >>  sdma: dma-controller@4a056000 {
> > >>  compatible = "ti,omap4430-sdma";
> > >>  reg = <0x4a056000 0x1000>;
> > > 
> > > Hmm so why would you want to set up a complete device as a syscon
> > > mapping rather than just doing ioremap on it?
> > > 
> > > What drivers will be sharing access to these registers?
> > 
> > Two different instances of the MMU for now, both get probed
> > independently. But there are other registers which a remoteproc driver
> > will mostly be interested in (like DSP_SYS_STAT for knowing the C66x
> > idle/active status).
> 
> OK makes sense to me then.

And applying these into omap-for-v4.4/dt.

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: [REPOST PATCH 1/4] ARM: dts: DRA7: Add dsp1_system syscon node

[Tony Lindgren]

* Suman Anna  [151002 16:27]:
> The DSP_SYSTEM sub-module is a dedicated system control logic
> module present within a DRA7 DSP processor sub-system. This
> module is responsible for power management, clock generation
> and connection to the device PRCM module.
> 
> Add a syscon node for this module for the DSP1 processor
> sub-system. This is added as a syscon node as it is a common
> configuration module that can be used by the different IOMMU
> instances and the corresponding remoteproc device.
> 
> The node is added to the common dra7.dtsi file, as the DSP1
> processor sub-system is mostly common across all the variants
> of the DRA7 SoC family.
> 
> Signed-off-by: Suman Anna 
> ---
>  arch/arm/boot/dts/dra7.dtsi | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
> index e289c706d27d..62055094e8d5 100644
> --- a/arch/arm/boot/dts/dra7.dtsi
> +++ b/arch/arm/boot/dts/dra7.dtsi
> @@ -292,6 +292,11 @@
>   #thermal-sensor-cells = <1>;
>   };
>  
> + dsp1_system: dsp_system@40d0 {
> + compatible = "syscon";
> + reg = <0x40d0 0x100>;
> + };
> +
>   sdma: dma-controller@4a056000 {
>   compatible = "ti,omap4430-sdma";
>   reg = <0x4a056000 0x1000>;

Hmm so why would you want to set up a complete device as a syscon
mapping rather than just doing ioremap on it?

What drivers will be sharing access to these registers?

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: [PATCH v2 1/4] ARM: dts: dra7: Add dt node for the sycon pcie

[Kishon Vijay Abraham I]

Hi Tony,

On Tuesday 13 October 2015 02:51 AM, Tony Lindgren wrote:
> * Kishon Vijay Abraham I  [150915 06:37]:
>> Add new device tree node for the control module register space where
>> PCIe registers are present.
>>
>> Signed-off-by: Kishon Vijay Abraham I 
>> ---
>>  arch/arm/boot/dts/dra7.dtsi |5 +
>>  1 file changed, 5 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
>> index 5d65db9..0769b5d 100644
>> --- a/arch/arm/boot/dts/dra7.dtsi
>> +++ b/arch/arm/boot/dts/dra7.dtsi
>> @@ -154,6 +154,11 @@
>>  compatible = "syscon";
>>  reg = <0x1c04 0x0020>;
>>  };
>> +
>> +scm_conf_pcie: tisyscon@1c24 {
>> +compatible = "syscon";
>> +reg = <0x1c24 0x0024>;
>> +};
>>  };
>>  
>>  cm_core_aon: cm_core_aon@5000 {
> 
> 
> Why don't you just extend the existing scm_conf1 area? This is not all pcie
> specific for scm_conf_pcie, at least for PLLEN_CONTROL, RMII_CLK_SETTING
> and MUXSEL_32K_CLKIN.

scm_conf_pcie has only PCIe registers (it starts at 0x4A003C24).
PLLEN_CONTROL and others are at 0x4A003C14 as per
DRA75x_DRA74x_SR1.1_NDA_TRM_vW.

Since PCIe itself has a bunch of registers for itself, thought of
creating a separate dt node. But I can extend scm_conf1 area.

Thanks
Kishon
--
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/3] Fix mmc/sd card detect gpio dt definition

[Tony Lindgren]

* Mugunthan V N  [151012 02:12]:
> The mmc/sd card detect gpio definition in DT is not defined as
> per hardware design, the card detect gpio is an active low
> signal.
> 
> As per MMC/SD device tree binding documentation, the card detect
> signal should be an active low signal and when ever a hardware is
> designed with an active high card detect gpio then "cd-inverted"
> dt parameter should be used to detect the actual status for the
> card.
> 
> This was not captured till now because gpio is used as interrupt
> source and mmc_rescan task is scheduled. The value of the gpio
> is not used to determine card presence.

OK applying into omap-for-v4.4/dt thanks.

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: [PATCH v3] ARM: dts: twl4030: Add iio properties for bci subnode

[Tony Lindgren]

* Belisko Marek  [150926 13:02]:
> Tony sorry I forgot to add you to the recipients for this patchset.
> Can you please queue this patch. Many thanks.

OK applying into omap-for-v4.4/dt thanks.

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: [PATCH v2 1/4] ARM: dts: dra7: Add dt node for the sycon pcie

[Tony Lindgren]

* Kishon Vijay Abraham I  [151012 14:50]:
> Hi Tony,
> 
> On Tuesday 13 October 2015 02:51 AM, Tony Lindgren wrote:
> > * Kishon Vijay Abraham I  [150915 06:37]:
> >> Add new device tree node for the control module register space where
> >> PCIe registers are present.
> >>
> >> Signed-off-by: Kishon Vijay Abraham I 
> >> ---
> >>  arch/arm/boot/dts/dra7.dtsi |5 +
> >>  1 file changed, 5 insertions(+)
> >>
> >> diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
> >> index 5d65db9..0769b5d 100644
> >> --- a/arch/arm/boot/dts/dra7.dtsi
> >> +++ b/arch/arm/boot/dts/dra7.dtsi
> >> @@ -154,6 +154,11 @@
> >>compatible = "syscon";
> >>reg = <0x1c04 0x0020>;
> >>};
> >> +
> >> +  scm_conf_pcie: tisyscon@1c24 {
> >> +  compatible = "syscon";
> >> +  reg = <0x1c24 0x0024>;
> >> +  };
> >>};
> >>  
> >>cm_core_aon: cm_core_aon@5000 {
> > 
> > 
> > Why don't you just extend the existing scm_conf1 area? This is not all pcie
> > specific for scm_conf_pcie, at least for PLLEN_CONTROL, RMII_CLK_SETTING
> > and MUXSEL_32K_CLKIN.
> 
> scm_conf_pcie has only PCIe registers (it starts at 0x4A003C24).
> PLLEN_CONTROL and others are at 0x4A003C14 as per
> DRA75x_DRA74x_SR1.1_NDA_TRM_vW.

Oh sorry I guess I was looking at a wrong address then.

> Since PCIe itself has a bunch of registers for itself, thought of
> creating a separate dt node. But I can extend scm_conf1 area.

Why not just ioremap them then? Do these need to be shared with
some other driver?

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: [PATCH v2 1/4] ARM: dts: dra7: Add dt node for the sycon pcie

[Tony Lindgren]

* Kishon Vijay Abraham I  [151012 15:09]:
> Hi,
> 
> On Tuesday 13 October 2015 03:33 AM, Tony Lindgren wrote:
> > * Kishon Vijay Abraham I  [151012 14:50]:
> >> Hi Tony,
> >>
> >> On Tuesday 13 October 2015 02:51 AM, Tony Lindgren wrote:
> >>> * Kishon Vijay Abraham I  [150915 06:37]:
>  Add new device tree node for the control module register space where
>  PCIe registers are present.
> 
>  Signed-off-by: Kishon Vijay Abraham I 
>  ---
>   arch/arm/boot/dts/dra7.dtsi |5 +
>   1 file changed, 5 insertions(+)
> 
>  diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
>  index 5d65db9..0769b5d 100644
>  --- a/arch/arm/boot/dts/dra7.dtsi
>  +++ b/arch/arm/boot/dts/dra7.dtsi
>  @@ -154,6 +154,11 @@
>   compatible = "syscon";
>   reg = <0x1c04 0x0020>;
>   };
>  +
>  +scm_conf_pcie: tisyscon@1c24 {
>  +compatible = "syscon";
>  +reg = <0x1c24 0x0024>;
>  +};
>   };
>   
>   cm_core_aon: cm_core_aon@5000 {
> >>>
> >>>
> >>> Why don't you just extend the existing scm_conf1 area? This is not all 
> >>> pcie
> >>> specific for scm_conf_pcie, at least for PLLEN_CONTROL, RMII_CLK_SETTING
> >>> and MUXSEL_32K_CLKIN.
> >>
> >> scm_conf_pcie has only PCIe registers (it starts at 0x4A003C24).
> >> PLLEN_CONTROL and others are at 0x4A003C14 as per
> >> DRA75x_DRA74x_SR1.1_NDA_TRM_vW.
> > 
> > Oh sorry I guess I was looking at a wrong address then.
> > 
> >> Since PCIe itself has a bunch of registers for itself, thought of
> >> creating a separate dt node. But I can extend scm_conf1 area.
> > 
> > Why not just ioremap them then? Do these need to be shared with
> > some other driver?
> 
> yeah, some are used by PCIe controller driver and some are used by PCIe
> PHY driver.

OK makes sense to me then.

Thanks,

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: [PATCH 2/2] ARM: dts: omap3-igep0020: Remove duplicate uart2 pinmux

[Javier Martinez Canillas]

Hello Laurent,

Thanks for the patch.

On Mon, Oct 12, 2015 at 10:46 PM, Laurent Pinchart
 wrote:
> uart2 pinmux is already defined in omap3-igep0020-common.dtsi, remove
> the duplicate node.
>
> Signed-off-by: Laurent Pinchart 
> ---

Indeed, this is something that was overlooked when the common dtsi
file was introduced in commit ebc13bf2e0d2 ("ARM: dts:
omap3-igep0020-common: Introduce igep0020 common dtsi file").

Acked-by: Javier Martinez Canillas 

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 2/2] ARM: dts: omap3-igep0020: Remove duplicate uart2 pinmux

[Tony Lindgren]

* Javier Martinez Canillas  [151012 15:35]:
> Hello Laurent,
> 
> Thanks for the patch.
> 
> On Mon, Oct 12, 2015 at 10:46 PM, Laurent Pinchart
>  wrote:
> > uart2 pinmux is already defined in omap3-igep0020-common.dtsi, remove
> > the duplicate node.
> >
> > Signed-off-by: Laurent Pinchart 
> > ---
> 
> Indeed, this is something that was overlooked when the common dtsi
> file was introduced in commit ebc13bf2e0d2 ("ARM: dts:
> omap3-igep0020-common: Introduce igep0020 common dtsi file").

Applying both into omap-for-v4.4/dt thanks.

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

[PATCH] mmc: omap_hsmmc: fix initialization order of mmc block devices

[Heiko Schocher]

On embedded devices, often there is a combination of
removable mmc devices (e.g. MMC/SD cards) and hard
wired ones (e.g. eMMC). Depending on the hardware
configuration, the 'mmcblkN' node might change if
the removable device is available or not at boot time.

E.g. if the removable device is attached at boot time,
it might become mmxblk0. And the hard wired one mmcblk1.
But if the removable device isn't there at boot time,
the hard wired one will become mmcblk0. This makes it
somehow difficult to hard code the root device to the
non-removable device and boot fast.

Signed-off-by: Heiko Schocher 
---
Dirk Behme tried to bring this in, last mail I found:
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-July/111022.html
where Dirk worked in Arnds suggestion to use the
"/aliases" device node"

I adapt this to the omap_hsmmc driver.

Is there another solution for this problem?
Or why was this patch not accepted to mainline?

 drivers/mmc/card/block.c  | 6 --
 drivers/mmc/host/omap_hsmmc.c | 6 ++
 include/linux/mmc/host.h  | 3 +++
 3 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index c742cfd..62250d8 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -2106,7 +2106,8 @@ static struct mmc_blk_data *mmc_blk_alloc_req(struct 
mmc_card *card,
struct mmc_blk_data *md;
int devidx, ret;
 
-   devidx = find_first_zero_bit(dev_use, max_devices);
+   devidx = find_next_zero_bit(dev_use, max_devices,
+   card->host->devidx);
if (devidx >= max_devices)
return ERR_PTR(-ENOSPC);
__set_bit(devidx, dev_use);
@@ -2124,7 +2125,8 @@ static struct mmc_blk_data *mmc_blk_alloc_req(struct 
mmc_card *card,
 * index anymore so we keep track of a name index.
 */
if (!subname) {
-   md->name_idx = find_first_zero_bit(name_use, max_devices);
+   md->name_idx = find_next_zero_bit(name_use, max_devices,
+ card->host->devidx);
__set_bit(md->name_idx, name_use);
} else
md->name_idx = ((struct mmc_blk_data *)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 7fb0753..0b45b48 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -2059,6 +2059,12 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
host->pbias_enabled = 0;
host->vqmmc_enabled = 0;
 
+   if (pdev->dev.of_node) {
+   ret = of_alias_get_id(pdev->dev.of_node, "mmcblk");
+   if (ret >= 0)
+   host->mmc->devidx = ret;
+   }
+
ret = omap_hsmmc_gpio_init(mmc, host, pdata);
if (ret)
goto err_gpio;
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index 83b81fd..4f071681 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -382,6 +382,9 @@ struct mmc_host {
int dsr_req;/* DSR value is valid */
u32 dsr;/* optional driver stage (DSR) value */
 
+   /* preferred mmc block device index (mmcblkX) */
+   unsigned intdevidx;
+
unsigned long   private[0] cacheline_aligned;
 };
 
-- 
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

[PATCH] arm, omap2, sram: On HS/EMU devices, only 64K internal SRAM is available.

[Heiko Schocher]

Of this, secure content (including PPA) uses initial
portion of the SRAM. This chunk is not (and shouldn't
be) accessible from the public code.

The minimum size of this chunk (0x350) is used in this
patch. Available size is rounded off to 63K.

Both values would require a change if size of secure
content grows beyond 0x350.

Signed-off-by: Heiko Schocher 
Signed-off-by: Ayoub Zaki 
---

 arch/arm/mach-omap2/sram.c | 25 +
 1 file changed, 25 insertions(+)

diff --git a/arch/arm/mach-omap2/sram.c b/arch/arm/mach-omap2/sram.c
index cd488b8..2e7c00f 100644
--- a/arch/arm/mach-omap2/sram.c
+++ b/arch/arm/mach-omap2/sram.c
@@ -47,6 +47,28 @@
 
 #define GP_DEVICE  0x300
 
+/**
+ * Size of chunk used by secure content in the HS/EMU devices.
+ *
+ * This size is not fixed. It depends upon the implementation of PPA.
+ * May need to be modified if the size grows.
+ */
+#define AM33XX_HS_HEADER_SIZE   0x0350
+
+/**
+ * Start of public SRAM on HS/EMU devices.
+ */
+#define AM33XX_SRAM_PA 0x4030
+#define AM33XX_SRAM_PUB_PA (AM33XX_SRAM_PA + AM33XX_HS_HEADER_SIZE)
+
+/**
+ * Size of public SRAM available on HS/EMU devices.
+ *
+ * This size also depends upon AM33XX_HS_HEADER_SIZE.
+ * Current value is derived from nearest round-off.
+ */
+#define AM33XX_SRAM_PUB_SIZE   0xfc00  /* 63K */
+
 #define ROUND_DOWN(value,boundary) ((value) & (~((boundary)-1)))
 
 static unsigned long omap_sram_start;
@@ -99,6 +121,9 @@ static void __init omap_detect_sram(void)
} else {
omap_sram_size = 0x8000; /* 32K */
}
+   } else if (soc_is_am33xx()) {
+   omap_sram_start = AM33XX_SRAM_PUB_PA;
+   omap_sram_size  = AM33XX_SRAM_PUB_SIZE;
} else {
omap_sram_start = OMAP2_SRAM_PUB_PA;
omap_sram_size = 0x800; /* 2K */
-- 
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 v2] ARM: OMAP: Change all cpu_is_* occurences to soc_is_*

[Keerthy]

On Monday 12 October 2015 10:59 PM, Tony Lindgren wrote:

* Tony Lindgren  [151012 10:17]:

* Keerthy  [150901 17:24]:



On Tuesday 01 September 2015 11:33 PM, Tony Lindgren wrote:

* Keerthy  [150901 10:22]:



On Wednesday 26 August 2015 09:29 AM, Keerthy wrote:

Currently apart from dra7, omap5 and amx3 all the other SoCs
are identified using cpu_is_* functions which is not right since
they are all SoCs(System on Chips). Hence changing the SoC
identification code to use soc_is instead of cpu_is and keeping
defines for cpu_is where needed. This allows us to replace the
rest of cpu_is usage along with other fixes as needed.


Tony,

A Gentle ping on this.


Looks good to me for v4.4. I'll apply it after some testing
after -rc1.


Thanks Tony.


Now with the fixes finally out of the way, applying into
omap-for-v4.4/cleanup.


Uhh actually not applying. This breaks builds quite a bit depending on
the .config options chosen:

arch/arm/mach-omap2/io.c:767:6: error: implicit declaration of function 
‘cpu_is_omap24xx’ [-Werror=implicit-function-declaration]
arch/arm/mach-omap2/control.c:257:15: error: implicit declaration of function 
‘cpu_is_omap243x’ [-Werror=implicit-function-declaration]
arch/arm/mach-omap2/control.c:259:8: error: implicit declaration of function 
‘cpu_is_omap44xx’ [-Werror=implicit-function-declaration]
...
arch/arm/mach-omap2/io.c:389:7: error: implicit declaration of function 
‘cpu_is_omap34xx’ [-Werror=implicit-function-declaration]
arch/arm/mach-omap2/io.c:767:6: error: implicit declaration of function 
‘cpu_is_omap24xx’ [-Werror=implicit-function-declaration]
...
arch/arm/mach-omap2/io.c:389:7: error: implicit declaration of function 
‘cpu_is_omap34xx’ [-Werror=implicit-function-declaration]
arch/arm/mach-omap2/io.c:767:6: error: implicit declaration of function 
‘cpu_is_omap24xx’ [-Werror=implicit-function-declaration]
...
arch/arm/mach-omap2/io.c:767:6: error: implicit declaration of function 
‘cpu_is_omap24xx’ [-Werror=implicit-function-declaration]
arch/arm/mach-omap2/control.c:257:15: error: implicit declaration of function 
‘cpu_is_omap243x’ [-Werror=implicit-function-declaration]
arch/arm/mach-omap2/control.c:259:8: error: implicit declaration of function 
‘cpu_is_omap44xx’ [-Werror=implicit-function-declaration]
...
arch/arm/mach-omap2/io.c:767:6: error: implicit declaration of function 
‘cpu_is_omap24xx’ [-Werror=implicit-function-declaration]

Keerthy, can you please test this with just single SoC configurations
and run randconfig builds on this overnight.


I will do that Tony. I tested omap2plus_defconfig and boot tested on 
multiple platforms.




And then we obviously need to test to make sure that this does not
break booting on various platforms for multi SoC and single SoC
configurations.


Okay.



And then you can repost, please include what all was tested.


Sure.



Thanks,

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