Re: [PATCH 03/16] tty: serial: 8250_core: read only RX if there is something in the FIFO
On 02/12/2015 02:23 PM, Sebastian Andrzej Siewior wrote:
* Peter Hurley | 2015-02-12 11:32:04 [-0500]:
That said, I don't think serial8250_do_startup() is really doing that much
for OMAP h/w startup; open-coding what omap_8250 really needs is probably
10 loc.
10 loc? I have a few more.
:)
serial8250_clear_fifos(),
serial_link_irq_chain() aren't exported. serial8250_set_mctrl() can
maybe accessed via uart_ops-set_mctrl(). Maybe I'm not removing the
obvious not required code but here it looks better to just a BUG flag for
the Omap.
Ok.
FWIW,
--- a/drivers/tty/serial/8250/8250_omap.c
+++ b/drivers/tty/serial/8250/8250_omap.c
@@ -557,9 +557,74 @@ static int omap_8250_startup(struct uart_port *port)
pm_runtime_get_sync(port-dev);
- ret = serial8250_do_startup(port);
- if (ret)
- goto err;
+ up-mcr = 0;
+
+ /*
+ * Clear the FIFO buffers and disable them.
+ * (they will be reenabled in set_termios())
+ */
+ serial8250_clear_fifos(up);
For omap this would just be:
serial_out(up, UART_FCR, UART_FCR_CLEAR_RCVR | UART_FCR_CLEAR_XMIT);
In any event, the fifo enable/disable is probably not happening since
FIFO_EN is ignored unless the divisor == 0.
+
+ /*
+ * Clear the interrupt registers.
+ */
+ if (serial_port_in(port, UART_LSR) UART_LSR_DR)
+ serial_port_in(port, UART_RX);
+ serial_port_in(port, UART_IIR);
+ serial_port_in(port, UART_MSR);
+
+ retval = serial_link_irq_chain(up);
+ if (retval)
+ goto out;
omap doesn't really need the legacy irq chain handling; this could just be
request_irq().
In the 8250 split I'll be posting soon, all the irq chaining and
polling-via-timeout workarounds stays in the universal/legacy driver so
other 8250 drivers can opt-out.
+
+ /*
+ * Now, initialize the UART
+ */
+ serial_port_out(port, UART_LCR, UART_LCR_WLEN8);
+
--- % ---
+ spin_lock_irqsave(port-lock, flags);
+ /*
+ * Most PC uarts need OUT2 raised to enable interrupts.
+ */
+ if (port-irq)
+ up-port.mctrl |= TIOCM_OUT2;
+
+ serial8250_set_mctrl(port, port-mctrl);
+
+ spin_unlock_irqrestore(port-lock, flags);
+
None of this is required because there is no OUT2 on omap.
-
--- %
+ /*
+ * Clear the interrupt registers again for luck, and clear the
+ * saved flags to avoid getting false values from polling
+ * routines or the previous session.
+ */
+ if (serial_port_in(port, UART_LSR) UART_LSR_DR)
+ serial_port_in(port, UART_RX);
+ serial_port_in(port, UART_IIR);
+ serial_port_in(port, UART_MSR);
None of this is required because none of the probing is taking place.
+ up-lsr_saved_flags = 0;
+ up-msr_saved_flags = 0;
+
+ /*
+ * Request DMA channels for both RX and TX.
+ */
+ if (up-dma) {
+ retval = serial8250_request_dma(up);
+ if (retval) {
+ pr_warn_ratelimited(ttyS%d - failed to request DMA\n,
+ serial_index(port));
+ up-dma = NULL;
+ }
+ }
+
+ /*
+ * Finally, enable interrupts. Note: Modem status interrupts
+ * are set via set_termios(), which will be occurring imminently
+ * anyway, so we don't enable them here.
+ */
+ up-ier = UART_IER_RLSI | UART_IER_RDI;
+ serial_port_out(port, UART_IER, up-ier);
+
#ifdef CONFIG_PM
up-capabilities |= UART_CAP_RPM;
Sebastian
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/16] tty: serial: 8250_core: read only RX if there is something in the FIFO
* Peter Hurley | 2015-02-12 11:32:04 [-0500]:
That said, I don't think serial8250_do_startup() is really doing that much
for OMAP h/w startup; open-coding what omap_8250 really needs is probably
10 loc.
10 loc? I have a few more. serial8250_clear_fifos(),
serial_link_irq_chain() aren't exported. serial8250_set_mctrl() can
maybe accessed via uart_ops-set_mctrl(). Maybe I'm not removing the
obvious not required code but here it looks better to just a BUG flag for
the Omap.
--- a/drivers/tty/serial/8250/8250_omap.c
+++ b/drivers/tty/serial/8250/8250_omap.c
@@ -557,9 +557,74 @@ static int omap_8250_startup(struct uart_port *port)
pm_runtime_get_sync(port-dev);
- ret = serial8250_do_startup(port);
- if (ret)
- goto err;
+ up-mcr = 0;
+
+ /*
+* Clear the FIFO buffers and disable them.
+* (they will be reenabled in set_termios())
+*/
+ serial8250_clear_fifos(up);
+
+ /*
+* Clear the interrupt registers.
+*/
+ if (serial_port_in(port, UART_LSR) UART_LSR_DR)
+ serial_port_in(port, UART_RX);
+ serial_port_in(port, UART_IIR);
+ serial_port_in(port, UART_MSR);
+
+ retval = serial_link_irq_chain(up);
+ if (retval)
+ goto out;
+
+ /*
+* Now, initialize the UART
+*/
+ serial_port_out(port, UART_LCR, UART_LCR_WLEN8);
+
+ spin_lock_irqsave(port-lock, flags);
+ /*
+* Most PC uarts need OUT2 raised to enable interrupts.
+*/
+ if (port-irq)
+ up-port.mctrl |= TIOCM_OUT2;
+
+ serial8250_set_mctrl(port, port-mctrl);
+
+ spin_unlock_irqrestore(port-lock, flags);
+
+ /*
+* Clear the interrupt registers again for luck, and clear the
+* saved flags to avoid getting false values from polling
+* routines or the previous session.
+*/
+ if (serial_port_in(port, UART_LSR) UART_LSR_DR)
+ serial_port_in(port, UART_RX);
+ serial_port_in(port, UART_IIR);
+ serial_port_in(port, UART_MSR);
+ up-lsr_saved_flags = 0;
+ up-msr_saved_flags = 0;
+
+ /*
+* Request DMA channels for both RX and TX.
+*/
+ if (up-dma) {
+ retval = serial8250_request_dma(up);
+ if (retval) {
+ pr_warn_ratelimited(ttyS%d - failed to request DMA\n,
+ serial_index(port));
+ up-dma = NULL;
+ }
+ }
+
+ /*
+* Finally, enable interrupts. Note: Modem status interrupts
+* are set via set_termios(), which will be occurring imminently
+* anyway, so we don't enable them here.
+*/
+ up-ier = UART_IER_RLSI | UART_IER_RDI;
+ serial_port_out(port, UART_IER, up-ier);
+
#ifdef CONFIG_PM
up-capabilities |= UART_CAP_RPM;
Sebastian
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] ARM: dts: omap3-pandora: add common device tree
Am 12.02.2015 um 18:47 schrieb Grazvydas Ignotas nota...@gmail.com:
On Thu, Feb 12, 2015 at 3:03 PM, Marek Belisko ma...@goldelico.com wrote:
From: H. Nikolaus Schaller h...@goldelico.com
This device tree allows to boot, supports the panel,
framebuffer, touch screen, as well as some more peripherals.
Since there is a OMAP3530 based 600 MHz variant and a DM3730 based
1 GHz variant we must include this common device tree code
in one of two CPU specific device trees.
Signed-off-by: H. Nikolaus Schaller h...@goldelico.com
Signed-off-by: Marek Belisko ma...@goldelico.com
---
arch/arm/boot/dts/omap3-pandora-common.dtsi | 641
1 file changed, 641 insertions(+)
create mode 100644 arch/arm/boot/dts/omap3-pandora-common.dtsi
diff --git a/arch/arm/boot/dts/omap3-pandora-common.dtsi
b/arch/arm/boot/dts/omap3-pandora-common.dtsi
new file mode 100644
index 000..0a2a878
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-pandora-common.dtsi
@@ -0,0 +1,641 @@
...
+
+ gpio-leds {
+
+ compatible = gpio-leds;
+
+ pinctrl-names = default;
+ pinctrl-0 = led_pins;
+
+ led@1 {
+ label = pandora::sd1;
+ gpios = gpio5 0 GPIO_ACTIVE_HIGH;/* GPIO_128
*/
+ linux,default-trigger = mmc0;
+ default-state = off;
+ };
+
+ led@2 {
+ label = pandora::sd2;
+ gpios = gpio5 1 GPIO_ACTIVE_HIGH;/* GPIO_129
*/
+ linux,default-trigger = mmc1;
+ default-state = off;
+ };
+
+ led@3 {
+ label = pandora::bluetooth;
+ gpios = gpio5 30 GPIO_ACTIVE_HIGH; /* GPIO_158
*/
+ linux,default-trigger = heartbeat;
I’d prefer this had no trigger, but no strong feelings here.
Ok. Well, this is more or less our testing setup - so that we did see something
before
we could fix the display setup. I think practice will show what is better, and
then
it can be patched. We are at the beginning of Pandora DT work…
+ default-state = off;
+ };
+
+ led@4 {
+ label = pandora::wifi;
+ gpios = gpio5 31 GPIO_ACTIVE_HIGH; /* GPIO_159
*/
+ linux,default-trigger = mmc2;
+ default-state = off;
+ };
+ };
+
+ gpio-keys {
+ compatible = gpio-keys;
+
+ pinctrl-names = default;
+ pinctrl-0 = button_pins;
+
+ up-button {
+ label = up;
+ linux,code = KEY_UP;
+ gpios = gpio4 14 GPIO_ACTIVE_HIGH; /* GPIO_110
*/
+ gpio-key,wakeup;
+ };
+
+ down-button {
+ label = down;
+ linux,code = KEY_DOWN;
+ gpios = gpio4 7 GPIO_ACTIVE_HIGH;/* GPIO_103
*/
+ gpio-key,wakeup;
+ };
+
+ left-button {
+ label = left;
+ linux,code = KEY_LEFT;
+ gpios = gpio4 0 GPIO_ACTIVE_HIGH;/* GPIO_96 */
+ gpio-key,wakeup;
+ };
+
+ right-button {
+ label = right;
+ linux,code = KEY_RIGHT;
+ gpios = gpio4 2 GPIO_ACTIVE_HIGH;/* GPIO_98 */
+ gpio-key,wakeup;
+ };
+
+ pageup-button {
+ label = game 1;
+ linux,code = KEY_PAGEUP;
+ gpios = gpio4 13 GPIO_ACTIVE_HIGH; /* GPIO_109
*/
+ gpio-key,wakeup;
+ };
+
+ pagedown-button {
+ label = game 3;
+ linux,code = KEY_PAGEDOWN;
+ gpios = gpio4 10 GPIO_ACTIVE_HIGH; /* GPIO_106
*/
+ gpio-key,wakeup;
+ };
+
+ home-button {
+ label = game 4;
+ linux,code = KEY_HOME;
+ gpios = gpio4 5 GPIO_ACTIVE_HIGH;/* GPIO_101
*/
+ gpio-key,wakeup;
+ };
+
+ end-button {
+ label = game 2;
+ linux,code = KEY_END;
+ gpios = gpio4 15 GPIO_ACTIVE_HIGH; /* GPIO_111
*/
+ gpio-key,wakeup;
+ };
+
+ right-shift {
+ label = l;
+ linux,code = KEY_RIGHTSHIFT;
+
Re: [PATCH 03/16] tty: serial: 8250_core: read only RX if there is something in the FIFO
On Thu, Feb 12, 2015 at 09:45:38AM +0100, Sebastian Andrzej Siewior wrote: On 02/11/2015 09:42 PM, Peter Hurley wrote: Reverting makes sense to me if it has caused a regression. Maybe Sebastian can update his patch to do this based on some quirk flag instead? That's fine with me. There's a 'bugs' field in struct 8250_uart_port and UART_BUG_* defines in 8250/8250.h for that purpose. Makes sense. Reading an empty FIFO does not look right. Maybe we should do the bug flag the other way around? But I can do what I am told to so if there is more fallout than just this Marvell UART I could come around with a patch to the bug field for the older OMAP. Reading the RX FIFO is something that goes back a long time in the 8250 driver, to the time when Ted Ts'o wrote the driver. I would suggest that it remains there as the default (it was obviously found to be necessary for x86 all those years ago when Linux was in its infancy) and has survived for getting on 20 years without issue. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- 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: OMAP1: PM: fix some build warnings on 1510-only Kconfigs
On 02/11/2015 09:14 PM, Tony Lindgren wrote: * Paul Walmsley p...@pwsan.com [150211 13:03]: On Wed, 11 Feb 2015, Tony Lindgren wrote: * Paul Walmsley p...@pwsan.com [150210 18:28]: On Tue, 10 Feb 2015, Jon Hunter wrote: On 07/02/2015 00:23, Paul Walmsley wrote: Unfortunately, there is not a single TRM for the omap5910 but individual documents for each chapter in the original TRM. Check out the OMAP5910 Dual-Core Processor Timer Reference Guide and possibly the OMAP5910 Dual-Core Processor Clock Generation and System Reset Management Reference Guide The omap15xx/5910 did have a 32k timer but as you can see it appears it was never supported by the kernel for this device (not sure why). I do recall that there is some errata regarding the 32k timer, if you look at the omap5910 errata document and search for 32k you should find it. OK thanks for the context. I probably am not going to investigate adding support for this timer on OMAP1510/5910 - am primarily trying to avoid causing a regression on the existing platforms. At least I've never seen the 32KiHz timer registers in any 15xx documentation. Jon are you sure you're not mixing up 5910 (15xx) and 5912 (16xx)? It's documented in the OMAP5910 Timer Reference Guide (SPRU682A) Section 3 32-kHz Timer, at the link Jon mentioned. Have not checked the errata that Jon mentioned though. Interesting. Looks like it's the same as on 16xx at 0xfffb9000. AFAIK that never worked on 15xx. Or maybe the issue was that 15xx is missing the constantly running 32KiHz counter making the timer unusable from PM point of view as the clockevent alone is not enough. Regarding the patch: I'd suggest keeping the compilation warning fixes (which was the original purpose of the patch) from anything that changes the logic too much. That way if there's an error in the patch that changes the logic and it needs to be reverted, it won't also revert the warning fixes. Makes sense to me. Yes that's fine with me as well, I don't wish to over complicate matters. I have a couple minor comments though and will respond to the latest patch rev. Cheers Jon -- 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 2/2] remoteproc: add support to handle internal memories
Hi Ohad,
On 02/12/2015 03:09 AM, Ohad Ben-Cohen wrote:
On Wed, Feb 11, 2015 at 10:57 PM, Tony Lindgren t...@atomide.com wrote:
+static int rproc_handle_intmem(struct rproc *rproc, struct fw_rsc_intmem
*rsc,
+ int offset, int avail)
+{
...
+ va = (__force void *)ioremap_nocache(rsc-pa, rsc-len);
Back in the days when we developed remoteproc there was a tremendous
effort to move away from ioremap when not strictly needed.
The use of ioremap in general is just fine for drivers as long
as they access a dedicated area to the specific device. Accessing
random registers and memory in the SoC is what I'm worried about.
Yes, the proposed interface essentially allows exactly this random
access, since the parameters to ioremap would be provided from the
user space (specifically from the resource table contained within the
firmware of the remote processor).
My original motivation was that it would only need to be added on
firmwares requiring support for loading into internal memories,
otherwise, these are something left to be managed by the software
running on the remote processor completely, and MPU will not even touch
them.
So, let me know if this is a NAK. If so, we have two options - one to go
the sram node model where each of them have to be defined separately,
and have a specific property in the rproc nodes to be able to get the
gen_pool handles. The other one is simply to define these as reg and
use devm_ioremap_resource() (so use DT for defining the regions instead
of a resource table entry).
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 03/16] tty: serial: 8250_core: read only RX if there is something in the FIFO
On 02/12/2015 08:55 PM, Peter Hurley wrote: On 02/12/2015 02:23 PM, Sebastian Andrzej Siewior wrote: * Peter Hurley | 2015-02-12 11:32:04 [-0500]: That said, I don't think serial8250_do_startup() is really doing that much for OMAP h/w startup; open-coding what omap_8250 really needs is probably 10 loc. 10 loc? I have a few more. :) serial8250_clear_fifos(), serial_link_irq_chain() aren't exported. serial8250_set_mctrl() can maybe accessed via uart_ops-set_mctrl(). Maybe I'm not removing the obvious not required code but here it looks better to just a BUG flag for the Omap. Ok. Okay. I will try to post something tomorrow. --- a/drivers/tty/serial/8250/8250_omap.c +++ b/drivers/tty/serial/8250/8250_omap.c + +/* + * Clear the interrupt registers. + */ +if (serial_port_in(port, UART_LSR) UART_LSR_DR) +serial_port_in(port, UART_RX); +serial_port_in(port, UART_IIR); +serial_port_in(port, UART_MSR); + +retval = serial_link_irq_chain(up); +if (retval) +goto out; omap doesn't really need the legacy irq chain handling; this could just be request_irq(). In the 8250 split I'll be posting soon, all the irq chaining and polling-via-timeout workarounds stays in the universal/legacy driver so other 8250 drivers can opt-out. Ah. This sounds interesting. Sebastian -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] ARM: dts: omap3-pandora: add DM3730 1 GHz version
On Thu, Feb 12, 2015 at 3:03 PM, Marek Belisko ma...@goldelico.com wrote:
From: H. Nikolaus Schaller h...@goldelico.com
Signed-off-by: H. Nikolaus Schaller h...@goldelico.com
---
arch/arm/boot/dts/omap3-pandora-1ghz.dts | 65
1 file changed, 65 insertions(+)
create mode 100644 arch/arm/boot/dts/omap3-pandora-1ghz.dts
diff --git a/arch/arm/boot/dts/omap3-pandora-1ghz.dts
b/arch/arm/boot/dts/omap3-pandora-1ghz.dts
new file mode 100644
index 000..6286f41
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-pandora-1ghz.dts
...
+
+ control_pins: pinmux_control_pins {
+ pinctrl-single,pins =
+ OMAP3630_CORE2_IOPAD(0x25dc, PIN_INPUT_PULLDOWN |
MUX_MODE4)/* etk_d0.gpio_14 = HP_SHUTDOWN */
+ OMAP3630_CORE2_IOPAD(0x25de, PIN_OUTPUT | MUX_MODE4)
/* etk_d1.gpio_15 = BT_SHUTDOWN */
+ OMAP3630_CORE2_IOPAD(0x25e0, PIN_OUTPUT | MUX_MODE4)
/* etk_d2.gpio_16 = RESET_USB_HOST */
+ OMAP3630_CORE2_IOPAD(0x25ea, PIN_INPUT_PULLUP |
MUX_MODE4) /* etk_d7.gpio_21 = WIFI IRQ */
The WG7210 document claims that no pulldown/pullup is needed, and we
always had it disabled. The mainline wl1251 driver also reconfigures
that signal to be active high on wl1251 side, and uses rising edge
interrupts (I don't know why it does that).
+ OMAP3630_CORE2_IOPAD(0x25ec, PIN_OUTPUT | MUX_MODE4)
/* etk_d8.gpio_22 = MSECURE */
+ OMAP3630_CORE2_IOPAD(0x25ee, PIN_OUTPUT | MUX_MODE4)
/* etk_d9.gpio_23 = WIFI_POWER */
I think we also need these here:
OMAP3_WKUP_IOPAD(0x2a54, PIN_INPUT | MUX_MODE4) /*
reserved.gpio_127 = MMC2_WP */
OMAP3_WKUP_IOPAD(0x2a56, PIN_INPUT | MUX_MODE4) /*
reserved.gpio_126 = MMC1_WP */
OMAP3_WKUP_IOPAD(0x2a58, PIN_OUTPUT | MUX_MODE4) /*
reserved.gpio_128 = LED_MMC1 */
OMAP3_WKUP_IOPAD(0x2a5a, PIN_OUTPUT | MUX_MODE4) /*
reserved.gpio_129 = LED_MMC2 */
Gražvydas
--
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] ASoC: omap-hdmi-audio: Add missing error check for devm_kzalloc
This patch add a missing check on the return value of devm_kzalloc, which would cause a NULL pointer dereference in a OOM situation. Signed-off-by: Kiran Padwal kiran.pad...@smartplayin.com --- sound/soc/omap/omap-hdmi-audio.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/sound/soc/omap/omap-hdmi-audio.c b/sound/soc/omap/omap-hdmi-audio.c index ccfb41c..f7eb42a 100644 --- a/sound/soc/omap/omap-hdmi-audio.c +++ b/sound/soc/omap/omap-hdmi-audio.c @@ -352,6 +352,9 @@ static int omap_hdmi_audio_probe(struct platform_device *pdev) return ret; card = devm_kzalloc(dev, sizeof(*card), GFP_KERNEL); + if (!card) + return -ENOMEM; + card-name = devm_kasprintf(dev, GFP_KERNEL, HDMI %s, dev_name(ad-dssdev)); card-owner = THIS_MODULE; -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/2] remoteproc: add support to handle internal memories
On Wed, Feb 11, 2015 at 10:57 PM, Tony Lindgren t...@atomide.com wrote:
+static int rproc_handle_intmem(struct rproc *rproc, struct fw_rsc_intmem
*rsc,
+ int offset, int avail)
+{
...
+ va = (__force void *)ioremap_nocache(rsc-pa, rsc-len);
Back in the days when we developed remoteproc there was a tremendous
effort to move away from ioremap when not strictly needed.
The use of ioremap in general is just fine for drivers as long
as they access a dedicated area to the specific device. Accessing
random registers and memory in the SoC is what I'm worried about.
Yes, the proposed interface essentially allows exactly this random
access, since the parameters to ioremap would be provided from the
user space (specifically from the resource table contained within the
firmware of the remote processor).
Thanks,
Ohad.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ASoC: omap-hdmi-audio: Add missing error check for devm_kzalloc
On 02/12/2015 11:08 AM, Kiran Padwal wrote: This patch add a missing check on the return value of devm_kzalloc, which would cause a NULL pointer dereference in a OOM situation. Acked-by: Peter Ujfalusi peter.ujfal...@ti.com Signed-off-by: Kiran Padwal kiran.pad...@smartplayin.com --- sound/soc/omap/omap-hdmi-audio.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/sound/soc/omap/omap-hdmi-audio.c b/sound/soc/omap/omap-hdmi-audio.c index ccfb41c..f7eb42a 100644 --- a/sound/soc/omap/omap-hdmi-audio.c +++ b/sound/soc/omap/omap-hdmi-audio.c @@ -352,6 +352,9 @@ static int omap_hdmi_audio_probe(struct platform_device *pdev) return ret; card = devm_kzalloc(dev, sizeof(*card), GFP_KERNEL); + if (!card) + return -ENOMEM; + card-name = devm_kasprintf(dev, GFP_KERNEL, HDMI %s, dev_name(ad-dssdev)); card-owner = THIS_MODULE; -- Péter -- 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 2/2] remoteproc: add support to handle internal memories
On Thu, Feb 12, 2015 at 10:54 PM, Suman Anna s-a...@ti.com wrote: My original motivation was that it would only need to be added on firmwares requiring support for loading into internal memories, otherwise, these are something left to be managed by the software running on the remote processor completely, and MPU will not even touch them. Sure. But even if you guys will use this interface correctly, this patch essentially exposes ioremap to user space, which is something we generally want to avoid. So, let me know if this is a NAK. If so, we have two options - one to go the sram node model where each of them have to be defined separately, and have a specific property in the rproc nodes to be able to get the gen_pool handles. The other one is simply to define these as reg and use devm_ioremap_resource() (so use DT for defining the regions instead of a resource table entry). Any approach where these regions are defined explicitly really sounds better. If you could look into these two alternatives that would be great. Thanks, Ohad. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] ARM: DRA: hwmod: RTC: Add reset function for RTC
Hi Paul, On Thursday 12 February 2015 10:11 PM, Paul Walmsley wrote: + Felipe, Nishanth Hi Lokesh, what's the status here? Sorry for the delayed response. I am currently on a high priority issue. Once I am done with it Ill address your comments and repost the patch. Thanks and regards, Lokesh - Paul On Fri, 2 Jan 2015, Paul Walmsley wrote: Ping. Are you going to redo this one? - Paul On Wed, 26 Nov 2014, Paul Walmsley wrote: Hi Lokesh On Tue, 25 Nov 2014, Lokesh Vutla wrote: Hi Paul, On Thursday 20 November 2014 10:26 PM, Paul Walmsley wrote: On Thu, 20 Nov 2014, Lokesh Vutla wrote: On Monday 17 November 2014 10:13 AM, Lokesh Vutla wrote: RTC IP have kicker feature which prevents spurious writes to its registers. In order to write into any of the RTC registers, KICK values has te be written to KICK registers. Currently hwmod is updating the IDLEMODE in rtc sysconfig register without writing into any kick register which is a noop. When autoidle is allowed for rtc, interruts are not received until IDLEMODE is set to SIDLE_SMART_WKUP. Adding a reset function to unlock RTC registers so that IDLEMODE is updated. Ping..!! Is this patch acceptable? Lokesh 1. This looks like a fix. Is this intended to go in as a v3.18-rc patch, or against v3.19? If so it would be very helpful for the maintainers if you were to state that somewhere. Yes. This is a fix, intended to go in 3.18-rc. Sorry should have mentioned it. A few questions. Do you know when this problem started (in terms of kernel versions)? Also: the patch description states that this is only a problem when autoidle is allowed for RTC. What enables autoidle for RTC - the RTCSS driver? Or does hwmod wind up doing this after the RTCSS driver unlocks it? 2. Your patch unlocks the RTC registers, but never relocks it. This seems to defeat the point of the spurious write protection. Shouldn't your patch only unlock the RTC immediately before the hwmod code touches the RTC registers, and then relock it immediately afterwards, per SPRUHZ6 section 23.4.3.3? If so then the .reset function pointer is the wrong place for this; I would suggest adding some .lock and .unlock function pointers that are to be called before and after any register write to the IP block. Yeah I agree with you. Currently rtc driver unlocks these kick registers in probe and leaves it unlocks for further use. But if hwmod does unlock and lock for every sysconfig write driver should also implement unlock and lock for every rtc register write, which adds an extra overhead. I am not sure if some one writes into rtc registers other than hwmod and driver. IMO we can leave it unlocked as the driver does. I would think that the best approach would be to set up .lock and .unlock function pointers, then add a temporary hwmod flag that, if set, would prevent the .lock function from ever being called. Then once the driver is fixed, that flag can be dropped. 3. Your macros don't mention DRA7xx specifically. Does this sequence apply to some other TI chips, or just DRA7xx? Please document this in a comment above the macros, and possibly change the name of the macros to refer to DRA7XX. This sequence applies to AM43xx and AM33xx also. So made it generic. Ill document it. OK but it would need more than just documentation, right? Wouldn't the hwmod data also need to be modified for AM33xx/AM43xx to add the .reset function pointer? Any reason why folks wouldn't have seen this problem on AM33xx/AM43xx? - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html - Paul - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] add openpandora device support
On Thu, Feb 12, 2015 at 3:03 PM, Marek Belisko ma...@goldelico.com wrote: This series of patches adds initial device tree support for the OpenPandora. The most important parts are working (display, keyboard, touch, charging, fuel gauge, musb port, sd/mmc ports, leds, buttons). Not yet supported are: usb host port, nubs, wifi, bluetooth, audio. First patch add common dtsi file which is then used in 600mhz and 1ghz variants of openpandora which support is added in patches 2 and 3. Nice, thanks for those patches. There is also a OMAP3530 variant with 256MB of RAM (otherwise identical to 512MB OMAP3530) that the legacy board file supports, over 1000 such units were made. Could we also have support for that? I guess that will make 4 pandora related .dts files... Gražvydas -- 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: OMAP1: PM: fix some build warnings on 1510-only Kconfigs
On 02/12/2015 11:26 AM, Jon Hunter wrote: On 02/11/2015 09:14 PM, Tony Lindgren wrote: * Paul Walmsley p...@pwsan.com [150211 13:03]: On Wed, 11 Feb 2015, Tony Lindgren wrote: * Paul Walmsley p...@pwsan.com [150210 18:28]: On Tue, 10 Feb 2015, Jon Hunter wrote: On 07/02/2015 00:23, Paul Walmsley wrote: Unfortunately, there is not a single TRM for the omap5910 but individual documents for each chapter in the original TRM. Check out the OMAP5910 Dual-Core Processor Timer Reference Guide and possibly the OMAP5910 Dual-Core Processor Clock Generation and System Reset Management Reference Guide The omap15xx/5910 did have a 32k timer but as you can see it appears it was never supported by the kernel for this device (not sure why). I do recall that there is some errata regarding the 32k timer, if you look at the omap5910 errata document and search for 32k you should find it. OK thanks for the context. I probably am not going to investigate adding support for this timer on OMAP1510/5910 - am primarily trying to avoid causing a regression on the existing platforms. At least I've never seen the 32KiHz timer registers in any 15xx documentation. Jon are you sure you're not mixing up 5910 (15xx) and 5912 (16xx)? It's documented in the OMAP5910 Timer Reference Guide (SPRU682A) Section 3 32-kHz Timer, at the link Jon mentioned. Have not checked the errata that Jon mentioned though. Interesting. Looks like it's the same as on 16xx at 0xfffb9000. AFAIK that never worked on 15xx. Or maybe the issue was that 15xx is missing the constantly running 32KiHz counter making the timer unusable from PM point of view as the clockevent alone is not enough. Regarding the patch: I'd suggest keeping the compilation warning fixes (which was the original purpose of the patch) from anything that changes the logic too much. That way if there's an error in the patch that changes the logic and it needs to be reverted, it won't also revert the warning fixes. Makes sense to me. Yes that's fine with me as well, I don't wish to over complicate matters. I have a couple minor comments though and will respond to the latest patch rev. Actually, nevermind the latest version is fine with me. Jon -- 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 1/5] xhci: add a quirk for device disconnection errata for Synopsis Designware USB3 core
On 25.01.2015 10:13, Sneeker Yeh wrote:
This issue is defined by a three-way race at disconnect, between
1) Class driver interrupt endpoint resheduling attempts if the ISR gave an ep
error event due to device detach (it would try 3 times)
2) Disconnect interrupt on PORTSC_CSC, which is cleared by hub thread
asynchronously
3) The hardware IP was configured in silicon with
- DWC_USB3_SUSPEND_ON_DISCONNECT_EN=1
- Synopsys IP version is 3.00a
The IP will auto-suspend itself on device detach with some phy-specific
interval
after CSC is cleared by 2)
If 2) and 3) complete before 1), the interrupts it expects will not be
generated
by the autosuspended IP, leading to a deadlock. Even later disconnection
procedure would detect that corresponding urb is still in-progress and issue a
ep stop command, auto-suspended IP still won't respond to that command.
So did I understand correctly that the class driver submits a new urb which
is enqueued by xhci_urb_enqueue() before the hub thread notices the device is
disconnected.
Then hub thread clears CSC bit, controller suspends and the new urb is never
given back?
Doesn't the CSC bit and PORT_CONNECT bit show the device is disconnected when
we enter
xhci_enqueue_urb(), even it the hub thread doesn't know this yet?
Would it make sense to check those bits in xhci_enqueue_urb, and just return
error
in the xhci_urb_enqueue() if device is not connected? Then there wouldn't be a
need for any quirk
at all.
If that doesn't work then this patch looks good in general. See comments below
this defect would result in this when device detached:
---
[ 99.603544] usb 4-1: USB disconnect, device number 2
[ 104.615254] xhci-hcd xhci-hcd.0.auto: xHCI host not responding to stop
endpoint command.
[ 104.623362] xhci-hcd xhci-hcd.0.auto: Assuming host is dying, halting host.
[ 104.653261] xhci-hcd xhci-hcd.0.auto: Host not halted after 16000
microseconds.
[ 104.660584] xhci-hcd xhci-hcd.0.auto: Non-responsive xHCI host is not
halting.
[ 104.667817] xhci-hcd xhci-hcd.0.auto: Completing active URBs anyway.
[ 104.674198] xhci-hcd xhci-hcd.0.auto: HC died; cleaning up
--
As a result, when device detached, we desired to postpone PORTCSC clear
behind
disable slot. it's found that all executed ep command related to
disconnetion,
are executed before disable slot.
Signed-off-by: Sneeker Yeh sneeker@tw.fujitsu.com
---
drivers/usb/host/xhci-hub.c |4
drivers/usb/host/xhci.c | 29 +
drivers/usb/host/xhci.h | 24
3 files changed, 57 insertions(+)
diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index a7865c4..3b8f7fc 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -368,6 +368,10 @@ static void xhci_clear_port_change_bit(struct xhci_hcd
*xhci, u16 wValue,
port_change_bit = warm(BH) reset;
break;
case USB_PORT_FEAT_C_CONNECTION:
+ if ((xhci-quirks XHCI_DISCONNECT_QUIRK)
+ !(readl(addr) PORT_CONNECT))
+ return;
+
New port status event are prevented until CSC is cleared, not sure if there's
any harm in that?
status = PORT_CSC;
port_change_bit = connect;
break;
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index c50d8d2..aa8e02a 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -3584,6 +3584,33 @@ command_cleanup:
return ret;
}
+static void xhci_try_to_clear_csc(struct usb_hcd *hcd, int dev_port_num)
+{
+ int max_ports;
+ struct xhci_hcd *xhci = hcd_to_xhci(hcd);
+ __le32 __iomem **port_array;
+ u32 status;
+
+ /* print debug info */
+ if (hcd-speed == HCD_USB3) {
+ max_ports = xhci-num_usb3_ports;
+ port_array = xhci-usb3_ports;
+ } else {
+ max_ports = xhci-num_usb2_ports;
+ port_array = xhci-usb2_ports;
+ }
+
+ if (dev_port_num max_ports) {
+ xhci_err(xhci, %s() port number invalid, __func__);
+ return;
+ }
+ status = readl(port_array[dev_port_num - 1]);
+
+ /* write 1 to clear */
+ if (!(status PORT_CONNECT) (status PORT_CSC))
+ writel(status PORT_CSC, port_array[0]);
Shouldn't this be writel(...,port_array[dev_port_num - 1]) ?
-Mathias
--
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/4] add openpandora device support
This series of patches adds initial device tree support for the OpenPandora. The most important parts are working (display, keyboard, touch, charging, fuel gauge, musb port, sd/mmc ports, leds, buttons). Not yet supported are: usb host port, nubs, wifi, bluetooth, audio. First patch add common dtsi file which is then used in 600mhz and 1ghz variants of openpandora which support is added in patches 2 and 3. H. Nikolaus Schaller (4): ARM: dts: omap3-pandora: add common device tree ARM: dts: omap3-pandora: add OMAP3530 600 MHz version ARM: dts: omap3-pandora: add DM3730 1 GHz version ARM: dts: omap3-pandora: include in dts Makefile arch/arm/boot/dts/Makefile | 2 + arch/arm/boot/dts/omap3-pandora-1ghz.dts| 65 +++ arch/arm/boot/dts/omap3-pandora-600mhz.dts | 65 +++ arch/arm/boot/dts/omap3-pandora-common.dtsi | 641 4 files changed, 773 insertions(+) create mode 100644 arch/arm/boot/dts/omap3-pandora-1ghz.dts create mode 100644 arch/arm/boot/dts/omap3-pandora-600mhz.dts create mode 100644 arch/arm/boot/dts/omap3-pandora-common.dtsi -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] ARM: dts: omap3-pandora: add DM3730 1 GHz version
From: H. Nikolaus Schaller h...@goldelico.com
Signed-off-by: H. Nikolaus Schaller h...@goldelico.com
---
arch/arm/boot/dts/omap3-pandora-1ghz.dts | 65
1 file changed, 65 insertions(+)
create mode 100644 arch/arm/boot/dts/omap3-pandora-1ghz.dts
diff --git a/arch/arm/boot/dts/omap3-pandora-1ghz.dts
b/arch/arm/boot/dts/omap3-pandora-1ghz.dts
new file mode 100644
index 000..6286f41
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-pandora-1ghz.dts
@@ -0,0 +1,65 @@
+/*
+ * Copyright (C) 2015
+ * Nikolaus Schaller h...@goldelico.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/*
+ * device tree for OpenPandora 1GHz with DM3730
+ */
+
+/dts-v1/;
+
+#include omap36xx.dtsi
+#include omap3-pandora-common.dtsi
+
+/ {
+ model = Pandora Handheld Console 1GHz;
+
+ compatible = ti,omap36xx, ti,omap3;
+};
+
+omap3_pmx_core2 {
+
+ pinctrl-names = default;
+ pinctrl-0 =
+ hsusb2_2_pins
+ control_pins
+ ;
+
+ hsusb2_2_pins: pinmux_hsusb2_2_pins {
+ pinctrl-single,pins =
+ OMAP3630_CORE2_IOPAD(0x25f0, PIN_OUTPUT | MUX_MODE3)
/* etk_d10.hsusb2_clk */
+ OMAP3630_CORE2_IOPAD(0x25f2, PIN_OUTPUT | MUX_MODE3)
/* etk_d11.hsusb2_stp */
+ OMAP3630_CORE2_IOPAD(0x25f4, PIN_INPUT_PULLDOWN |
MUX_MODE3)/* etk_d12.hsusb2_dir */
+ OMAP3630_CORE2_IOPAD(0x25f6, PIN_INPUT_PULLDOWN |
MUX_MODE3)/* etk_d13.hsusb2_nxt */
+ OMAP3630_CORE2_IOPAD(0x25f8, PIN_INPUT_PULLDOWN |
MUX_MODE3)/* etk_d14.hsusb2_data0 */
+ OMAP3630_CORE2_IOPAD(0x25fa, PIN_INPUT_PULLDOWN |
MUX_MODE3)/* etk_d15.hsusb2_data1 */
+ ;
+ };
+
+ mmc3_pins: pinmux_mmc3_pins {
+ pinctrl-single,pins =
+ OMAP3630_CORE2_IOPAD(0x25d8, PIN_INPUT_PULLUP |
MUX_MODE2) /* etk_clk.sdmmc3_clk */
+ OMAP3630_CORE2_IOPAD(0x25da, PIN_INPUT_PULLUP |
MUX_MODE2) /* etk_ctl.sdmmc3_cmd */
+ OMAP3630_CORE2_IOPAD(0x25e2, PIN_INPUT_PULLUP |
MUX_MODE2) /* etk_d3.sdmmc3_dat3 */
+ OMAP3630_CORE2_IOPAD(0x25e4, PIN_INPUT_PULLUP |
MUX_MODE2) /* etk_d4.sdmmc3_dat0 */
+ OMAP3630_CORE2_IOPAD(0x25e6, PIN_INPUT_PULLUP |
MUX_MODE2) /* etk_d5.sdmmc3_dat1 */
+ OMAP3630_CORE2_IOPAD(0x25e8, PIN_INPUT_PULLUP |
MUX_MODE2) /* etk_d6.sdmmc3_dat2 */
+ ;
+ };
+
+ control_pins: pinmux_control_pins {
+ pinctrl-single,pins =
+ OMAP3630_CORE2_IOPAD(0x25dc, PIN_INPUT_PULLDOWN |
MUX_MODE4)/* etk_d0.gpio_14 = HP_SHUTDOWN */
+ OMAP3630_CORE2_IOPAD(0x25de, PIN_OUTPUT | MUX_MODE4)
/* etk_d1.gpio_15 = BT_SHUTDOWN */
+ OMAP3630_CORE2_IOPAD(0x25e0, PIN_OUTPUT | MUX_MODE4)
/* etk_d2.gpio_16 = RESET_USB_HOST */
+ OMAP3630_CORE2_IOPAD(0x25ea, PIN_INPUT_PULLUP |
MUX_MODE4) /* etk_d7.gpio_21 = WIFI IRQ */
+ OMAP3630_CORE2_IOPAD(0x25ec, PIN_OUTPUT | MUX_MODE4)
/* etk_d8.gpio_22 = MSECURE */
+ OMAP3630_CORE2_IOPAD(0x25ee, PIN_OUTPUT | MUX_MODE4)
/* etk_d9.gpio_23 = WIFI_POWER */
+ ;
+ };
+};
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] ARM: dts: omap3-pandora: include in dts Makefile
From: H. Nikolaus Schaller h...@goldelico.com Signed-off-by: H. Nikolaus Schaller h...@goldelico.com --- arch/arm/boot/dts/Makefile | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile index 91bd5bd..69f3106 100644 --- a/arch/arm/boot/dts/Makefile +++ b/arch/arm/boot/dts/Makefile @@ -343,6 +343,8 @@ dtb-$(CONFIG_ARCH_OMAP3) += am3517-craneboard.dtb \ omap3-overo-storm-tobi.dtb \ omap3-overo-summit.dtb \ omap3-overo-tobi.dtb \ + omap3-pandora-600mhz.dtb \ + omap3-pandora-1ghz.dtb \ omap3-sbc-t3517.dtb \ omap3-sbc-t3530.dtb \ omap3-sbc-t3730.dtb \ -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] ARM: dts: omap3-pandora: add common device tree
From: H. Nikolaus Schaller h...@goldelico.com
This device tree allows to boot, supports the panel,
framebuffer, touch screen, as well as some more peripherals.
Since there is a OMAP3530 based 600 MHz variant and a DM3730 based
1 GHz variant we must include this common device tree code
in one of two CPU specific device trees.
Signed-off-by: H. Nikolaus Schaller h...@goldelico.com
Signed-off-by: Marek Belisko ma...@goldelico.com
---
arch/arm/boot/dts/omap3-pandora-common.dtsi | 641
1 file changed, 641 insertions(+)
create mode 100644 arch/arm/boot/dts/omap3-pandora-common.dtsi
diff --git a/arch/arm/boot/dts/omap3-pandora-common.dtsi
b/arch/arm/boot/dts/omap3-pandora-common.dtsi
new file mode 100644
index 000..0a2a878
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-pandora-common.dtsi
@@ -0,0 +1,641 @@
+/*
+ * Copyright (C) 2015
+ * Nikolaus Schaller h...@goldelico.com
+ *
+ * Common device tree include for OpenPandora devices.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include dt-bindings/input/input.h
+
+/ {
+ cpus {
+ cpu@0 {
+ cpu0-supply = vcc;
+ };
+ };
+
+ memory {
+ device_type = memory;
+ reg = 0x8000 0x2000; /* 512 MB */
+ };
+
+ aliases {
+ display0 = lcd;
+ };
+
+ tv: connector@1 {
+ compatible = connector-analog-tv;
+ label = tv;
+
+ port {
+ tv_connector_in: endpoint {
+ remote-endpoint = venc_out;
+ };
+ };
+ };
+
+ gpio-leds {
+
+ compatible = gpio-leds;
+
+ pinctrl-names = default;
+ pinctrl-0 = led_pins;
+
+ led@1 {
+ label = pandora::sd1;
+ gpios = gpio5 0 GPIO_ACTIVE_HIGH;/* GPIO_128 */
+ linux,default-trigger = mmc0;
+ default-state = off;
+ };
+
+ led@2 {
+ label = pandora::sd2;
+ gpios = gpio5 1 GPIO_ACTIVE_HIGH;/* GPIO_129 */
+ linux,default-trigger = mmc1;
+ default-state = off;
+ };
+
+ led@3 {
+ label = pandora::bluetooth;
+ gpios = gpio5 30 GPIO_ACTIVE_HIGH; /* GPIO_158 */
+ linux,default-trigger = heartbeat;
+ default-state = off;
+ };
+
+ led@4 {
+ label = pandora::wifi;
+ gpios = gpio5 31 GPIO_ACTIVE_HIGH; /* GPIO_159 */
+ linux,default-trigger = mmc2;
+ default-state = off;
+ };
+ };
+
+ gpio-keys {
+ compatible = gpio-keys;
+
+ pinctrl-names = default;
+ pinctrl-0 = button_pins;
+
+ up-button {
+ label = up;
+ linux,code = KEY_UP;
+ gpios = gpio4 14 GPIO_ACTIVE_HIGH; /* GPIO_110 */
+ gpio-key,wakeup;
+ };
+
+ down-button {
+ label = down;
+ linux,code = KEY_DOWN;
+ gpios = gpio4 7 GPIO_ACTIVE_HIGH;/* GPIO_103 */
+ gpio-key,wakeup;
+ };
+
+ left-button {
+ label = left;
+ linux,code = KEY_LEFT;
+ gpios = gpio4 0 GPIO_ACTIVE_HIGH;/* GPIO_96 */
+ gpio-key,wakeup;
+ };
+
+ right-button {
+ label = right;
+ linux,code = KEY_RIGHT;
+ gpios = gpio4 2 GPIO_ACTIVE_HIGH;/* GPIO_98 */
+ gpio-key,wakeup;
+ };
+
+ pageup-button {
+ label = game 1;
+ linux,code = KEY_PAGEUP;
+ gpios = gpio4 13 GPIO_ACTIVE_HIGH; /* GPIO_109 */
+ gpio-key,wakeup;
+ };
+
+ pagedown-button {
+ label = game 3;
+ linux,code = KEY_PAGEDOWN;
+ gpios = gpio4 10 GPIO_ACTIVE_HIGH; /* GPIO_106 */
+ gpio-key,wakeup;
+ };
+
+ home-button {
+ label = game 4;
+ linux,code = KEY_HOME;
+ gpios = gpio4 5 GPIO_ACTIVE_HIGH;/* GPIO_101 */
+ gpio-key,wakeup;
+ };
+
+
[PATCH 2/4] ARM: dts: omap3-pandora: add OMAP3530 600 MHz version
From: H. Nikolaus Schaller h...@goldelico.com
Signed-off-by: H. Nikolaus Schaller h...@goldelico.com
---
arch/arm/boot/dts/omap3-pandora-600mhz.dts | 65 ++
1 file changed, 65 insertions(+)
create mode 100644 arch/arm/boot/dts/omap3-pandora-600mhz.dts
diff --git a/arch/arm/boot/dts/omap3-pandora-600mhz.dts
b/arch/arm/boot/dts/omap3-pandora-600mhz.dts
new file mode 100644
index 000..7a51b04
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-pandora-600mhz.dts
@@ -0,0 +1,65 @@
+/*
+ * Copyright (C) 2015
+ * Nikolaus Schaller h...@goldelico.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/*
+ * device tree for OpenPandora with OMAP3530
+ */
+
+/dts-v1/;
+
+#include omap34xx.dtsi
+#include omap3-pandora-common.dtsi
+
+/ {
+ model = Pandora Handheld Console;
+
+ compatible = ti,omap3;
+};
+
+omap3_pmx_core2 {
+
+ pinctrl-names = default;
+ pinctrl-0 =
+ hsusb2_2_pins
+ control_pins
+ ;
+
+ hsusb2_2_pins: pinmux_hsusb2_2_pins {
+ pinctrl-single,pins =
+ OMAP3430_CORE2_IOPAD(0x25f0, PIN_OUTPUT | MUX_MODE3)
/* etk_d10.hsusb2_clk */
+ OMAP3430_CORE2_IOPAD(0x25f2, PIN_OUTPUT | MUX_MODE3)
/* etk_d11.hsusb2_stp */
+ OMAP3430_CORE2_IOPAD(0x25f4, PIN_INPUT_PULLDOWN |
MUX_MODE3)/* etk_d12.hsusb2_dir */
+ OMAP3430_CORE2_IOPAD(0x25f6, PIN_INPUT_PULLDOWN |
MUX_MODE3)/* etk_d13.hsusb2_nxt */
+ OMAP3430_CORE2_IOPAD(0x25f8, PIN_INPUT_PULLDOWN |
MUX_MODE3)/* etk_d14.hsusb2_data0 */
+ OMAP3430_CORE2_IOPAD(0x25fa, PIN_INPUT_PULLDOWN |
MUX_MODE3)/* etk_d15.hsusb2_data1 */
+ ;
+ };
+
+ mmc3_pins: pinmux_mmc3_pins {
+ pinctrl-single,pins =
+ OMAP3430_CORE2_IOPAD(0x25d8, PIN_INPUT_PULLUP |
MUX_MODE2) /* etk_clk.sdmmc3_clk */
+ OMAP3430_CORE2_IOPAD(0x25da, PIN_INPUT_PULLUP |
MUX_MODE2) /* etk_ctl.sdmmc3_cmd */
+ OMAP3430_CORE2_IOPAD(0x25e2, PIN_INPUT_PULLUP |
MUX_MODE2) /* etk_d3.sdmmc3_dat3 */
+ OMAP3430_CORE2_IOPAD(0x25e4, PIN_INPUT_PULLUP |
MUX_MODE2) /* etk_d4.sdmmc3_dat0 */
+ OMAP3430_CORE2_IOPAD(0x25e6, PIN_INPUT_PULLUP |
MUX_MODE2) /* etk_d5.sdmmc3_dat1 */
+ OMAP3430_CORE2_IOPAD(0x25e8, PIN_INPUT_PULLUP |
MUX_MODE2) /* etk_d6.sdmmc3_dat2 */
+ ;
+ };
+
+ control_pins: pinmux_control_pins {
+ pinctrl-single,pins =
+ OMAP3430_CORE2_IOPAD(0x25dc, PIN_INPUT_PULLDOWN |
MUX_MODE4)/* etk_d0.gpio_14 = HP_SHUTDOWN */
+ OMAP3430_CORE2_IOPAD(0x25de, PIN_OUTPUT | MUX_MODE4)
/* etk_d1.gpio_15 = BT_SHUTDOWN */
+ OMAP3430_CORE2_IOPAD(0x25e0, PIN_OUTPUT | MUX_MODE4)
/* etk_d2.gpio_16 = RESET_USB_HOST */
+ OMAP3430_CORE2_IOPAD(0x25ea, PIN_INPUT_PULLUP |
MUX_MODE4) /* etk_d7.gpio_21 = WIFI IRQ */
+ OMAP3430_CORE2_IOPAD(0x25ec, PIN_OUTPUT | MUX_MODE4)
/* etk_d8.gpio_22 = MSECURE */
+ OMAP3430_CORE2_IOPAD(0x25ee, PIN_OUTPUT | MUX_MODE4)
/* etk_d9.gpio_23 = WIFI_POWER */
+ ;
+ };
+};
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] ARM: dts: omap3-pandora: include in dts Makefile
* Marek Belisko ma...@goldelico.com [150212 05:07]: From: H. Nikolaus Schaller h...@goldelico.com Signed-off-by: H. Nikolaus Schaller h...@goldelico.com --- arch/arm/boot/dts/Makefile | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile index 91bd5bd..69f3106 100644 --- a/arch/arm/boot/dts/Makefile +++ b/arch/arm/boot/dts/Makefile @@ -343,6 +343,8 @@ dtb-$(CONFIG_ARCH_OMAP3) += am3517-craneboard.dtb \ omap3-overo-storm-tobi.dtb \ omap3-overo-summit.dtb \ omap3-overo-tobi.dtb \ + omap3-pandora-600mhz.dtb \ + omap3-pandora-1ghz.dtb \ omap3-sbc-t3517.dtb \ omap3-sbc-t3530.dtb \ omap3-sbc-t3730.dtb \ This change you can fold into patches 3 and 4 :) 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: dra7xx: hwmod: drop .modulemode from pcie1/2 hwmods
On 02/12/2015 11:08 PM, Paul Walmsley wrote: Thanks guys. On Thu, 12 Feb 2015, grygorii.stras...@linaro.org wrote: Looks good for me and seems working. Grygorii, can I add your Acked-by? - Paul There is my Signed-off-by :) -- regards, -grygorii -- 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: dra7xx: hwmod: drop .modulemode from pcie1/2 hwmods
On Fri, 13 Feb 2015, grygorii.stras...@linaro.org wrote: On 02/12/2015 11:08 PM, Paul Walmsley wrote: Thanks guys. On Thu, 12 Feb 2015, grygorii.stras...@linaro.org wrote: Looks good for me and seems working. Grygorii, can I add your Acked-by? - Paul There is my Signed-off-by :) OK thanks, queued for v3.20-rc. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dra7xx: hwmod: drop .modulemode from pcie1/2 hwmods
Thanks guys. On Thu, 12 Feb 2015, grygorii.stras...@linaro.org wrote: Looks good for me and seems working. Grygorii, can I add your Acked-by? - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
3.20-rc0: very poor performance when running festival
Hi! I'm using echo 'Come shall then well bload? Then well bload shell when blaight!' | bash -c 'time festival --tts' to test audio, and I noticed that in 3.20-rc0, it takes about 3x longer than it should, on Nokia N900. Normally on 3.19, it takes 12 seconds, but it takes 30 on 3.20. Any ideas? Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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 1/5] xhci: add a quirk for device disconnection errata for Synopsis Designware USB3 core
On Thu, 12 Feb 2015, Mathias Nyman wrote: On 25.01.2015 10:13, Sneeker Yeh wrote: This issue is defined by a three-way race at disconnect, between 1) Class driver interrupt endpoint resheduling attempts if the ISR gave an ep error event due to device detach (it would try 3 times) 2) Disconnect interrupt on PORTSC_CSC, which is cleared by hub thread asynchronously 3) The hardware IP was configured in silicon with - DWC_USB3_SUSPEND_ON_DISCONNECT_EN=1 - Synopsys IP version is 3.00a The IP will auto-suspend itself on device detach with some phy-specific interval after CSC is cleared by 2) If 2) and 3) complete before 1), the interrupts it expects will not be generated by the autosuspended IP, leading to a deadlock. Even later disconnection procedure would detect that corresponding urb is still in-progress and issue a ep stop command, auto-suspended IP still won't respond to that command. If the Synopsys IP provides a way to do it, it would be better to turn off the autosuspend feature entirely. Doesn't autosuspend violate the xHCI specification? So did I understand correctly that the class driver submits a new urb which is enqueued by xhci_urb_enqueue() before the hub thread notices the device is disconnected. Then hub thread clears CSC bit, controller suspends and the new urb is never given back? Doesn't the CSC bit and PORT_CONNECT bit show the device is disconnected when we enter xhci_enqueue_urb(), even it the hub thread doesn't know this yet? What if the device disconnects _after_ the new URB is enqueued? Would it make sense to check those bits in xhci_enqueue_urb, and just return error in the xhci_urb_enqueue() if device is not connected? Then there wouldn't be a need for any quirk at all. That wouldn't help URBs that were already enqueued when the disconnect occurred. Alan Stern -- 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/4] ARM: dts: omap3-pandora: add OMAP3530 600 MHz version
* Marek Belisko ma...@goldelico.com [150212 05:07]: From: H. Nikolaus Schaller h...@goldelico.com Can you please add a patch description for the board varian patches? 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] ARM OMAP2 GPMC: don't undef DEBUG
Signed-off-by: Robert ABEL ra...@cit-ec.uni-bielefeld.de --- arch/arm/mach-omap2/gpmc.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c index ab43755..1ab6bc0 100644 --- a/arch/arm/mach-omap2/gpmc.c +++ b/arch/arm/mach-omap2/gpmc.c @@ -12,8 +12,6 @@ * it under the terms of the GNU General Public License version 2 as * published by the Free Software Foundation. */ -#undef DEBUG - #include linux/irq.h #include linux/kernel.h #include linux/init.h -- 2.3.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 GPMC undefines DEBUG
The GPMC driver in OMAP2 undef's DEBUG, which makes it unnecessarily hard to turn DEBUG on, because that's not expected behavior. My proposed patch gets rid of the line undef'ing DEBUG. Robert ABEL (1): ARM OMAP2 GPMC: don't undef DEBUG arch/arm/mach-omap2/gpmc.c | 2 -- 1 file changed, 2 deletions(-) -- 2.3.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 1/4] ARM: dts: omap3-pandora: add common device tree
Hi,
Few comments below.
* Marek Belisko ma...@goldelico.com [150212 05:07]:
+
+omap3_pmx_core {
+
+ mmc1_pins: pinmux_mmc1_pins {
+ pinctrl-single,pins =
+ OMAP3_CORE1_IOPAD(0x2144, PIN_INPUT_PULLUP | MUX_MODE0)
/* sdmmc1_clk.sdmmc1_clk */
+ OMAP3_CORE1_IOPAD(0x2146, PIN_INPUT_PULLUP | MUX_MODE0)
/* sdmmc1_cmd.sdmmc1_cmd */
+ OMAP3_CORE1_IOPAD(0x2148, PIN_INPUT_PULLUP | MUX_MODE0)
/* sdmmc1_dat0.sdmmc1_dat0 */
+ OMAP3_CORE1_IOPAD(0x214a, PIN_INPUT_PULLUP | MUX_MODE0)
/* sdmmc1_dat1.sdmmc1_dat1 */
+ OMAP3_CORE1_IOPAD(0x214c, PIN_INPUT_PULLUP | MUX_MODE0)
/* sdmmc1_dat2.sdmmc1_dat2 */
+ OMAP3_CORE1_IOPAD(0x214e, PIN_INPUT_PULLUP | MUX_MODE0)
/* sdmmc1_dat3.sdmmc1_dat3 */
+ ;
...
+omap3_pmx_core2 {
+ /* define in CPU specific file that includes this one
+ * use either OMAP3430_CORE2_IOPAD() or OMAP3630_CORE2_IOPAD()
+ */
+};
OK looks like you have some SoC specific pins too.. I assume you
guys have checked that all the pins defined in this file are at
the same offset between 34xx and 36xx variants?
+i2c1 {
+ clock-frequency = 260;
+
+ twl: twl@48 {
+ reg = 0x48;
+ interrupts = 7; /* SYS_NIRQ cascaded to intc */
+ interrupt-parent = intc;
+
+ twl_power: power {
+ compatible = ti,twl4030-power-reset;
+ ti,use_poweroff;
+ };
+
+ twl_audio: audio {
+ compatible = ti,twl4030-audio;
+
+ codec {
+ ti,ramp_delay_value = 3;
+ };
+ };
+ };
+};
Can be done later naturally, but ere you probably want
ti,twl4030-power-idle or ti,twl4030-power-idle-osc-off
if the osicllator can be shut down during off-idle.
+gpmc {
+ ranges = 0 0 0x3000 0x04; /* CS0: NAND */
The ranges here allocate the GPMC partition, so it needs to be
a minimum of 16MB:
ranges = 0 0 0x3000 0x100,/* CS0: 16MB for NAND */
+ nand@0,0 {
+ reg = 0 0 0; /* CS0, offset 0 */
The reg is for the device driver to ioremap it's registers,
for NAND it's just 4:
reg = 0 0 4; /* CS0, offset 0, IO size 4 */
+ filesystem@68 {
+ label = rootfs;
+ reg = 0xc8 0; /* 0 = MTDPART_SIZ_FULL */
+ };
+ };
+};
Is the NAND the same size on all of them? I don't think dts
has a binding for MTDPART_SIZ_FULL type thing..
+ lcd: lcd@1 {
+ reg = 1; /* CS1 */
+ compatible =omapdss,tpo,td043mtea1;
+ spi-max-frequency = 10;
+ spi-cpol;
+ spi-cpha;
+
+ label = lcd;
+ reset-gpios = gpio5 29 GPIO_ACTIVE_LOW; /* GPIO_157 */
+ vcc-supply = vaux1;
+
+ port {
+ lcd_in: endpoint {
+ remote-endpoint = dpi_out;
+ };
+ };
+ };
Oh there's already a binding for the LCD too? That's great :)
Nine job, good to see this happening!
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] gpio: omap: use raw locks for locking
This patch converts gpio_bank.lock from a spin_lock into a
raw_spin_lock. The call path to access this lock is always under a
raw_spin_lock, for instance
- __setup_irq() holds desc-lock with irq off
+ __irq_set_trigger()
+ omap_gpio_irq_type()
- handle_level_irq() (runs with irqs off therefore raw locks)
+ mask_ack_irq()
+ omap_gpio_mask_irq()
This fixes the obvious backtrace on -RT. However I noticed two cases
where it looks wrong and this is not limited to -RT:
- omap_gpio_irq_type() is called with IRQ off and has an conditional
call to pm_runtime_get_sync() which may sleep. Either it may happen or
it may not happen but pm_runtime_get_sync() should not be called in an
atomic section.
- omap_gpio_debounce() is holding the lock with IRQs off.
+ omap2_set_gpio_debounce()
+ clk_prepare_enable()
+ clk_prepare() this one might sleep.
The number of users of gpiod_set_debounce() / gpio_set_debounce()
looks low but still this is not good.
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/gpio/gpio-omap.c | 78
1 file changed, 39 insertions(+), 39 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index f476ae2eb0b3..27e835f4c39d 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -57,7 +57,7 @@ struct gpio_bank {
u32 saved_datain;
u32 level_mask;
u32 toggle_mask;
- spinlock_t lock;
+ raw_spinlock_t lock;
struct gpio_chip chip;
struct clk *dbck;
u32 mod_usage;
@@ -515,15 +515,15 @@ static int omap_gpio_irq_type(struct irq_data *d,
unsigned type)
(type (IRQ_TYPE_LEVEL_LOW|IRQ_TYPE_LEVEL_HIGH)))
return -EINVAL;
- spin_lock_irqsave(bank-lock, flags);
+ raw_spin_lock_irqsave(bank-lock, flags);
offset = GPIO_INDEX(bank, gpio);
retval = omap_set_gpio_triggering(bank, offset, type);
omap_gpio_init_irq(bank, gpio, offset);
if (!omap_gpio_is_input(bank, BIT(offset))) {
- spin_unlock_irqrestore(bank-lock, flags);
+ raw_spin_unlock_irqrestore(bank-lock, flags);
return -EINVAL;
}
- spin_unlock_irqrestore(bank-lock, flags);
+ raw_spin_unlock_irqrestore(bank-lock, flags);
if (type (IRQ_TYPE_LEVEL_LOW | IRQ_TYPE_LEVEL_HIGH))
__irq_set_handler_locked(d-irq, handle_level_irq);
@@ -641,14 +641,14 @@ static int omap_set_gpio_wakeup(struct gpio_bank *bank,
int gpio, int enable)
return -EINVAL;
}
- spin_lock_irqsave(bank-lock, flags);
+ raw_spin_lock_irqsave(bank-lock, flags);
if (enable)
bank-context.wake_en |= gpio_bit;
else
bank-context.wake_en = ~gpio_bit;
writel_relaxed(bank-context.wake_en, bank-base + bank-regs-wkup_en);
- spin_unlock_irqrestore(bank-lock, flags);
+ raw_spin_unlock_irqrestore(bank-lock, flags);
return 0;
}
@@ -683,7 +683,7 @@ static int omap_gpio_request(struct gpio_chip *chip,
unsigned offset)
if (!BANK_USED(bank))
pm_runtime_get_sync(bank-dev);
- spin_lock_irqsave(bank-lock, flags);
+ raw_spin_lock_irqsave(bank-lock, flags);
/* Set trigger to none. You need to enable the desired trigger with
* request_irq() or set_irq_type(). Only do this if the IRQ line has
* not already been requested.
@@ -693,7 +693,7 @@ static int omap_gpio_request(struct gpio_chip *chip,
unsigned offset)
omap_enable_gpio_module(bank, offset);
}
bank-mod_usage |= BIT(offset);
- spin_unlock_irqrestore(bank-lock, flags);
+ raw_spin_unlock_irqrestore(bank-lock, flags);
return 0;
}
@@ -703,11 +703,11 @@ static void omap_gpio_free(struct gpio_chip *chip,
unsigned offset)
struct gpio_bank *bank = container_of(chip, struct gpio_bank, chip);
unsigned long flags;
- spin_lock_irqsave(bank-lock, flags);
+ raw_spin_lock_irqsave(bank-lock, flags);
bank-mod_usage = ~(BIT(offset));
omap_disable_gpio_module(bank, offset);
omap_reset_gpio(bank, bank-chip.base + offset);
- spin_unlock_irqrestore(bank-lock, flags);
+ raw_spin_unlock_irqrestore(bank-lock, flags);
/*
* If this is the last gpio to be freed in the bank,
@@ -810,9 +810,9 @@ static unsigned int omap_gpio_irq_startup(struct irq_data
*d)
if (!BANK_USED(bank))
pm_runtime_get_sync(bank-dev);
- spin_lock_irqsave(bank-lock, flags);
+ raw_spin_lock_irqsave(bank-lock, flags);
omap_gpio_init_irq(bank, gpio, offset);
- spin_unlock_irqrestore(bank-lock, flags);
+ raw_spin_unlock_irqrestore(bank-lock, flags);
omap_gpio_unmask_irq(d);
return 0;
@@ -825,12 +825,12 @@ static void omap_gpio_irq_shutdown(struct irq_data *d)
Re: [RFC PATCH] ARM: DRA: hwmod: RTC: Add reset function for RTC
+ Felipe, Nishanth Hi Lokesh, what's the status here? - Paul On Fri, 2 Jan 2015, Paul Walmsley wrote: Ping. Are you going to redo this one? - Paul On Wed, 26 Nov 2014, Paul Walmsley wrote: Hi Lokesh On Tue, 25 Nov 2014, Lokesh Vutla wrote: Hi Paul, On Thursday 20 November 2014 10:26 PM, Paul Walmsley wrote: On Thu, 20 Nov 2014, Lokesh Vutla wrote: On Monday 17 November 2014 10:13 AM, Lokesh Vutla wrote: RTC IP have kicker feature which prevents spurious writes to its registers. In order to write into any of the RTC registers, KICK values has te be written to KICK registers. Currently hwmod is updating the IDLEMODE in rtc sysconfig register without writing into any kick register which is a noop. When autoidle is allowed for rtc, interruts are not received until IDLEMODE is set to SIDLE_SMART_WKUP. Adding a reset function to unlock RTC registers so that IDLEMODE is updated. Ping..!! Is this patch acceptable? Lokesh 1. This looks like a fix. Is this intended to go in as a v3.18-rc patch, or against v3.19? If so it would be very helpful for the maintainers if you were to state that somewhere. Yes. This is a fix, intended to go in 3.18-rc. Sorry should have mentioned it. A few questions. Do you know when this problem started (in terms of kernel versions)? Also: the patch description states that this is only a problem when autoidle is allowed for RTC. What enables autoidle for RTC - the RTCSS driver? Or does hwmod wind up doing this after the RTCSS driver unlocks it? 2. Your patch unlocks the RTC registers, but never relocks it. This seems to defeat the point of the spurious write protection. Shouldn't your patch only unlock the RTC immediately before the hwmod code touches the RTC registers, and then relock it immediately afterwards, per SPRUHZ6 section 23.4.3.3? If so then the .reset function pointer is the wrong place for this; I would suggest adding some .lock and .unlock function pointers that are to be called before and after any register write to the IP block. Yeah I agree with you. Currently rtc driver unlocks these kick registers in probe and leaves it unlocks for further use. But if hwmod does unlock and lock for every sysconfig write driver should also implement unlock and lock for every rtc register write, which adds an extra overhead. I am not sure if some one writes into rtc registers other than hwmod and driver. IMO we can leave it unlocked as the driver does. I would think that the best approach would be to set up .lock and .unlock function pointers, then add a temporary hwmod flag that, if set, would prevent the .lock function from ever being called. Then once the driver is fixed, that flag can be dropped. 3. Your macros don't mention DRA7xx specifically. Does this sequence apply to some other TI chips, or just DRA7xx? Please document this in a comment above the macros, and possibly change the name of the macros to refer to DRA7XX. This sequence applies to AM43xx and AM33xx also. So made it generic. Ill document it. OK but it would need more than just documentation, right? Wouldn't the hwmod data also need to be modified for AM33xx/AM43xx to add the .reset function pointer? Any reason why folks wouldn't have seen this problem on AM33xx/AM43xx? - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html - Paul - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dra7xx: hwmod: drop .modulemode from pcie1/2 hwmods
On Thu, 12 Feb 2015, Paul Walmsley wrote:
On Fri, 13 Feb 2015, grygorii.stras...@linaro.org wrote:
On 02/12/2015 11:08 PM, Paul Walmsley wrote:
Thanks guys.
On Thu, 12 Feb 2015, grygorii.stras...@linaro.org wrote:
Looks good for me and seems working.
Grygorii, can I add your Acked-by?
- Paul
There is my Signed-off-by :)
OK thanks, queued for v3.20-rc.
Actually, could you guys test the updated patch? It had to be changed to
apply on mainline and I don't have a DRA7xx board to test.
- Paul
From 0f9a1ee083a7adbb2c867d5c8d25d7e5fcb38b07 Mon Sep 17 00:00:00 2001
From: Kishon Vijay Abraham I kis...@ti.com
Date: Thu, 12 Feb 2015 09:29:31 -0700
Subject: [PATCH] ARM: DRA7: hwmod_data: Fix hwmod data for pcie
Fixed hwmod data for pcie by having the correct module mode offset.
Previously this module mode offset was part of pcie PHY which was wrong.
Now this module mode offset was moved to pcie hwmod and removed the
hwmod data
for pcie phy. While at that renamed pcie_hwmod to pciess_hwmod in order
to match with the name given in TRM.
This helps to get rid of the following warning
omap_hwmod: pcie1: _wait_target_disable failed
[grygorii.stras...@linaro.org: Found the issue that actually caused
omap_hwmod: pcie1: _wait_target_disable failed]
Signed-off-by: Grygorii Strashko grygorii.stras...@linaro.org
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
[p...@pwsan.com: updated to apply on mainline]
---
arch/arm/boot/dts/dra7.dtsi | 2 -
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 111 ++
2 files changed, 35 insertions(+), 78 deletions(-)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 5827fedafd43..18a904db32bb 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -,7 +,6 @@
wkupclk, refclk,
div-clk, phy-div;
#phy-cells = 0;
- ti,hwmods = pcie1-phy;
};
pcie2_phy: pciephy@4a095000 {
@@ -1130,7 +1129,6 @@
wkupclk, refclk,
div-clk, phy-div;
#phy-cells = 0;
- ti,hwmods = pcie2-phy;
status = disabled;
};
};
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index e8692e7675b8..6a74a7ea8c95 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -1466,29 +1466,43 @@ static struct omap_hwmod dra7xx_ocp2scp3_hwmod = {
*
*/
-static struct omap_hwmod_class dra7xx_pcie_hwmod_class = {
+static struct omap_hwmod_class dra7xx_pciess_hwmod_class = {
.name = pcie,
};
/* pcie1 */
-static struct omap_hwmod dra7xx_pcie1_hwmod = {
+static struct omap_hwmod_rst_info dra7xx_pciess1_resets[] = {
+ { .name = pcie, .rst_shift = 0 },
+};
+
+static struct omap_hwmod dra7xx_pciess1_hwmod = {
.name = pcie1,
- .class = dra7xx_pcie_hwmod_class,
+ .class = dra7xx_pciess_hwmod_class,
.clkdm_name = pcie_clkdm,
.main_clk = l4_root_clk_div,
+ .rst_lines = dra7xx_pciess1_resets,
+ .rst_lines_cnt = ARRAY_SIZE(dra7xx_pciess1_resets),
.prcm = {
.omap4 = {
- .clkctrl_offs = DRA7XX_CM_PCIE_CLKSTCTRL_OFFSET,
+ .clkctrl_offs =
DRA7XX_CM_L3INIT_PCIESS1_CLKCTRL_OFFSET,
+ .context_offs =
DRA7XX_RM_L3INIT_PCIESS1_CONTEXT_OFFSET,
.modulemode = MODULEMODE_SWCTRL,
},
},
};
/* pcie2 */
-static struct omap_hwmod dra7xx_pcie2_hwmod = {
+
+static struct omap_hwmod_rst_info dra7xx_pciess2_resets[] = {
+ { .name = pcie, .rst_shift = 1 },
+};
+
+static struct omap_hwmod dra7xx_pciess2_hwmod = {
.name = pcie2,
- .class = dra7xx_pcie_hwmod_class,
+ .class = dra7xx_pciess_hwmod_class,
.clkdm_name = pcie_clkdm,
+ .rst_lines = dra7xx_pciess2_resets,
+ .rst_lines_cnt = ARRAY_SIZE(dra7xx_pciess2_resets),
.main_clk = l4_root_clk_div,
.prcm = {
.omap4 = {
@@ -1498,44 +1512,7 @@ static struct omap_hwmod dra7xx_pcie2_hwmod = {
},
};
-/*
- * 'PCIE PHY' class
- *
- */
-static struct omap_hwmod_class dra7xx_pcie_phy_hwmod_class = {
- .name = pcie-phy,
-};
-
-/* pcie1 phy */
-static struct omap_hwmod dra7xx_pcie1_phy_hwmod = {
- .name = pcie1-phy,
- .class = dra7xx_pcie_phy_hwmod_class,
- .clkdm_name = l3init_clkdm,
- .main_clk =
Re: [PATCH 03/16] tty: serial: 8250_core: read only RX if there is something in the FIFO
On 02/12/2015 03:45 AM, Sebastian Andrzej Siewior wrote: On 02/11/2015 09:42 PM, Peter Hurley wrote: Reverting makes sense to me if it has caused a regression. Maybe Sebastian can update his patch to do this based on some quirk flag instead? That's fine with me. There's a 'bugs' field in struct 8250_uart_port and UART_BUG_* defines in 8250/8250.h for that purpose. Makes sense. Reading an empty FIFO does not look right. Maybe we should do the bug flag the other way around? But I can do what I am told to so if there is more fallout than just this Marvell UART I could come around with a patch to the bug field for the older OMAP. I agree with Russell on this; better to stick with the rx read that's been running on 20 years of hardware. That said, I don't think serial8250_do_startup() is really doing that much for OMAP h/w startup; open-coding what omap_8250 really needs is probably 10 loc. Regards, Peter Hurley -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] ARM: dts: omap3-pandora: add common device tree
Am 12.02.2015 um 17:03 schrieb Tony Lindgren t...@atomide.com:
Hi,
Few comments below.
* Marek Belisko ma...@goldelico.com [150212 05:07]:
+
+omap3_pmx_core {
+
+mmc1_pins: pinmux_mmc1_pins {
+pinctrl-single,pins =
+OMAP3_CORE1_IOPAD(0x2144, PIN_INPUT_PULLUP | MUX_MODE0)
/* sdmmc1_clk.sdmmc1_clk */
+OMAP3_CORE1_IOPAD(0x2146, PIN_INPUT_PULLUP | MUX_MODE0)
/* sdmmc1_cmd.sdmmc1_cmd */
+OMAP3_CORE1_IOPAD(0x2148, PIN_INPUT_PULLUP | MUX_MODE0)
/* sdmmc1_dat0.sdmmc1_dat0 */
+OMAP3_CORE1_IOPAD(0x214a, PIN_INPUT_PULLUP | MUX_MODE0)
/* sdmmc1_dat1.sdmmc1_dat1 */
+OMAP3_CORE1_IOPAD(0x214c, PIN_INPUT_PULLUP | MUX_MODE0)
/* sdmmc1_dat2.sdmmc1_dat2 */
+OMAP3_CORE1_IOPAD(0x214e, PIN_INPUT_PULLUP | MUX_MODE0)
/* sdmmc1_dat3.sdmmc1_dat3 */
+;
...
+omap3_pmx_core2 {
+/* define in CPU specific file that includes this one
+ * use either OMAP3430_CORE2_IOPAD() or OMAP3630_CORE2_IOPAD()
+ */
+};
OK looks like you have some SoC specific pins too.. I assume you
guys have checked that all the pins defined in this file are at
the same offset between 34xx and 36xx variants?
Yes. All in this file are common between 34xx and 36xx.
The 600mhz / 1ghz files cover the differences for pmx_core2 through the
different macros
(OMAP3430_CORE2_IOPAD vs. OMAP3460_CORE2_IOPAD).
+i2c1 {
+clock-frequency = 260;
+
+twl: twl@48 {
+reg = 0x48;
+interrupts = 7; /* SYS_NIRQ cascaded to intc */
+interrupt-parent = intc;
+
+twl_power: power {
+compatible = ti,twl4030-power-reset;
+ti,use_poweroff;
+};
+
+twl_audio: audio {
+compatible = ti,twl4030-audio;
+
+codec {
+ti,ramp_delay_value = 3;
+};
+};
+};
+};
Can be done later naturally, but ere you probably want
ti,twl4030-power-idle or ti,twl4030-power-idle-osc-off
if the osicllator can be shut down during off-idle.
Good hint. We have to check and test if it can be shut down.
But as said, this is just the beginning of DT support.
+gpmc {
+ranges = 0 0 0x3000 0x04; /* CS0: NAND */
The ranges here allocate the GPMC partition, so it needs to be
a minimum of 16MB:
ranges = 0 0 0x3000 0x100,/* CS0: 16MB for NAND */
+nand@0,0 {
+reg = 0 0 0; /* CS0, offset 0 */
The reg is for the device driver to ioremap it's registers,
for NAND it's just 4:
reg = 0 0 4; /* CS0, offset 0, IO size 4 */
Ok, that was a typo and we have not tested how compatible it is to the
board file scheme.
+filesystem@68 {
+label = rootfs;
+reg = 0xc8 0; /* 0 = MTDPART_SIZ_FULL */
+};
+};
+};
Is the NAND the same size on all of them?
AFAIK not necessarily.
I don't think dts
has a binding for MTDPART_SIZ_FULL type thing..
It does not need a special binding, we just set the size to 0. This
is interpreted as MTDPART_SIZ_FULL later on. For board files,
there is just a #define in include/linux/mtd/partitions.h and it appears
to work.
+lcd: lcd@1 {
+reg = 1; /* CS1 */
+compatible =omapdss,tpo,td043mtea1;
+spi-max-frequency = 10;
+spi-cpol;
+spi-cpha;
+
+label = lcd;
+reset-gpios = gpio5 29 GPIO_ACTIVE_LOW; /* GPIO_157 */
+vcc-supply = vaux1;
+
+port {
+lcd_in: endpoint {
+remote-endpoint = dpi_out;
+};
+};
+};
Oh there's already a binding for the LCD too? That’s great :)
Yes, we were happy to find that the panel driver has already been upgraded
for DT use.
Nine job, good to see this happening!
Regards,
Tony
BR,
Nikolaus
--
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/4] ARM: dts: omap3-pandora: add common device tree
* Dr. H. Nikolaus Schaller h...@goldelico.com [150212 08:34]: Am 12.02.2015 um 17:03 schrieb Tony Lindgren t...@atomide.com: I don't think dts has a binding for MTDPART_SIZ_FULL type thing.. It does not need a special binding, we just set the size to 0. This is interpreted as MTDPART_SIZ_FULL later on. For board files, there is just a #define in include/linux/mtd/partitions.h and it appears to work. Oh OK good to know. 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: dra7xx: hwmod: drop .modulemode from pcie1/2 hwmods
On 02/12/2015 02:43 PM, Kishon Vijay Abraham I wrote:
On Monday 09 February 2015 08:22 PM, grygorii.stras...@linaro.org wrote:
On 02/09/2015 09:24 PM, Kishon Vijay Abraham I wrote:
Hi,
On Monday 09 February 2015 03:58 PM, grygorii.stras...@linaro.org wrote:
Hi Kishon,
On 02/09/2015 04:50 PM, Kishon Vijay Abraham I wrote:
On Tuesday 03 February 2015 09:21 PM, grygorii.stras...@linaro.org
wrote:
From: Grygorii Strashko grygorii.stras...@linaro.org
Now DRA7xx pcie1/2 hwmods define PRCM configuration as following:
.clkctrl_offs = DRA7XX_CM_PCIE_CLKSTCTRL_OFFSET,
.rstctrl_offs = DRA7XX_RM_L3INIT_RSTCTRL_OFFSET,
.modulemode = MODULEMODE_SWCTRL,
which is completely wrong because DRA7XX_CM_PCIE_CLKSTCTRL_OFFSET
is clockdomain ctrl register and NOT module ctrl register.
And they have diffrent allowed values for bits[0,1]:
CLKTRCTRL MODULEMODE
0x0: NO_SLEEP 0x0: Module is disabled by SW.
0x1: SW_SLEEP 0x1: Module is managed automatically by HW
0x2: SW_WKUP 0x2: Module is explicitly enabled.
0x3: HW_AUTO 0x3: Reserved
As result, following message can be seen during suspend:
omap_hwmod: pcie1: _wait_target_disable failed
Fix it by removing .modulemode from pcie1/2 hwmods and, in that
way, prevent clockdomain ctrl register writing from HWMOD core.
Looks correct except for one change.
Acked-by: Kishon Vijay Abraham I kis...@ti.com
Signed-off-by: Grygorii Strashko grygorii.stras...@linaro.org
---
More over, it looks like pcie1/2 hwmods are fake and have to be
dropped at all.
The real HWMODs are PCIESS1/2.
Not sure I get this. You mean dra7xx_pcie1_hwmod should be
replaced with
dra7xx_pciess1_hwmod? Or you mean an entire new hwmod is missing?
Please note we still have to enable the clock domain and main clock.
We've also
purposefully omitted sysconfig from hwmod data since pcie reset
(RM_PCIESS_RSTCTRL) should be done before accessing the syconfig
register and
the infrastructure for that is currently not present.
What I'm trying to say is that now PM control data mixed between
pcieX and pcieX-phy hwmods.
After this patch pcieX hwmods will actually do nothing (I assume
that pciex-phy will be
enabled before pcieX), and probably can be removed if pcie_clkdm
could be attached to pcieX-phy hwmod
instead.
More over, now, pcie_clkdm is connected to pcieX hwmod while
MODULEMODE register is controlled
by pciex-phy hwmod, so when pciess is going to be enabled the
l3init_clkdm will be waken-up by
hwmode core and not pcie_clkdm - as I can remember this is not good
(we should alway wake-up clockdomain
and keep it in SWSUP mode while changing MODULEMODE and SYSC
registers).
static struct omap_hwmod dra7xx_pcie1_hwmod = {
.name= pcie1,
.class= dra7xx_pcie_hwmod_class,
.clkdm_name= pcie_clkdm,
.main_clk= l4_root_clk_div,
static struct omap_hwmod dra7xx_pcie1_phy_hwmod = {
.name= pcie1-phy,
.class= dra7xx_pcie_phy_hwmod_class,
.clkdm_name= l3init_clkdm,
.main_clk= l4_root_clk_div,
So, in my opinion, some rework may be needed here.
Am I right?
you are right. We should have a single hwmod like dra7xx_pciess1_hwmod
whose
clkdm should be pcie_clkdm and whose clkctrl_offs should be
DRA7XX_CM_L3INIT_PCIESS1_CLKCTRL_OFFSET (for controlling MODULEMODE).
PCIE PHY
shouldn't have a hwmod entry at all.
Thanks
Kishon
Could this patch be applied any way? It fixes real issue for me.
A proper fix should look something like below IMO
Looks good for me and seems working.
From 1c177d37ac46885a4dc17bacec33071ac23c56da Mon Sep 17 00:00:00 2001
From: Kishon Vijay Abraham I kis...@ti.com
Date: Thu, 12 Feb 2015 11:55:08 +0530
Subject: [RFC PATCH] ARM: DRA7: hwmod_data: Fix hwmod data for pcie
Fixed hwmod data for pcie by having the correct module mode offset.
Previously this module mode offset was part of pcie PHY which was wrong.
Now this module mode offset was moved to pcie hwmod and removed the
hwmod data
for pcie phy. While at that renamed pcie_hwmod to pciess_hwmod in order
to match with the name given in TRM.
This helps to get rid of the following warning
omap_hwmod: pcie1: _wait_target_disable failed
[grygorii.stras...@linaro.org: Found the issue that actually caused
omap_hwmod: pcie1: _wait_target_disable failed]
Signed-off-by: Grygorii Strashko grygorii.stras...@linaro.org
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
this patch was created on 3.14 kernel after applying reset framework
patches
required for testing PCIe. I can port this to mainline if this patch is
fine.
arch/arm/boot/dts/dra7.dtsi |2 -
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 107
+++--
2 files changed, 26 insertions(+), 83 deletions(-)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index a4b1337..d7a1ff9 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++
Re: [PATCH 03/16] tty: serial: 8250_core: read only RX if there is something in the FIFO
On 02/11/2015 09:42 PM, Peter Hurley wrote: Reverting makes sense to me if it has caused a regression. Maybe Sebastian can update his patch to do this based on some quirk flag instead? That's fine with me. There's a 'bugs' field in struct 8250_uart_port and UART_BUG_* defines in 8250/8250.h for that purpose. Makes sense. Reading an empty FIFO does not look right. Maybe we should do the bug flag the other way around? But I can do what I am told to so if there is more fallout than just this Marvell UART I could come around with a patch to the bug field for the older OMAP. Regards, Peter Hurley Sebastian -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] ARM: dts: omap3-pandora: add common device tree
On Thu, Feb 12, 2015 at 3:03 PM, Marek Belisko ma...@goldelico.com wrote:
From: H. Nikolaus Schaller h...@goldelico.com
This device tree allows to boot, supports the panel,
framebuffer, touch screen, as well as some more peripherals.
Since there is a OMAP3530 based 600 MHz variant and a DM3730 based
1 GHz variant we must include this common device tree code
in one of two CPU specific device trees.
Signed-off-by: H. Nikolaus Schaller h...@goldelico.com
Signed-off-by: Marek Belisko ma...@goldelico.com
---
arch/arm/boot/dts/omap3-pandora-common.dtsi | 641
1 file changed, 641 insertions(+)
create mode 100644 arch/arm/boot/dts/omap3-pandora-common.dtsi
diff --git a/arch/arm/boot/dts/omap3-pandora-common.dtsi
b/arch/arm/boot/dts/omap3-pandora-common.dtsi
new file mode 100644
index 000..0a2a878
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-pandora-common.dtsi
@@ -0,0 +1,641 @@
...
+
+ gpio-leds {
+
+ compatible = gpio-leds;
+
+ pinctrl-names = default;
+ pinctrl-0 = led_pins;
+
+ led@1 {
+ label = pandora::sd1;
+ gpios = gpio5 0 GPIO_ACTIVE_HIGH;/* GPIO_128 */
+ linux,default-trigger = mmc0;
+ default-state = off;
+ };
+
+ led@2 {
+ label = pandora::sd2;
+ gpios = gpio5 1 GPIO_ACTIVE_HIGH;/* GPIO_129 */
+ linux,default-trigger = mmc1;
+ default-state = off;
+ };
+
+ led@3 {
+ label = pandora::bluetooth;
+ gpios = gpio5 30 GPIO_ACTIVE_HIGH; /* GPIO_158 */
+ linux,default-trigger = heartbeat;
I'd prefer this had no trigger, but no strong feelings here.
+ default-state = off;
+ };
+
+ led@4 {
+ label = pandora::wifi;
+ gpios = gpio5 31 GPIO_ACTIVE_HIGH; /* GPIO_159 */
+ linux,default-trigger = mmc2;
+ default-state = off;
+ };
+ };
+
+ gpio-keys {
+ compatible = gpio-keys;
+
+ pinctrl-names = default;
+ pinctrl-0 = button_pins;
+
+ up-button {
+ label = up;
+ linux,code = KEY_UP;
+ gpios = gpio4 14 GPIO_ACTIVE_HIGH; /* GPIO_110 */
+ gpio-key,wakeup;
+ };
+
+ down-button {
+ label = down;
+ linux,code = KEY_DOWN;
+ gpios = gpio4 7 GPIO_ACTIVE_HIGH;/* GPIO_103 */
+ gpio-key,wakeup;
+ };
+
+ left-button {
+ label = left;
+ linux,code = KEY_LEFT;
+ gpios = gpio4 0 GPIO_ACTIVE_HIGH;/* GPIO_96 */
+ gpio-key,wakeup;
+ };
+
+ right-button {
+ label = right;
+ linux,code = KEY_RIGHT;
+ gpios = gpio4 2 GPIO_ACTIVE_HIGH;/* GPIO_98 */
+ gpio-key,wakeup;
+ };
+
+ pageup-button {
+ label = game 1;
+ linux,code = KEY_PAGEUP;
+ gpios = gpio4 13 GPIO_ACTIVE_HIGH; /* GPIO_109 */
+ gpio-key,wakeup;
+ };
+
+ pagedown-button {
+ label = game 3;
+ linux,code = KEY_PAGEDOWN;
+ gpios = gpio4 10 GPIO_ACTIVE_HIGH; /* GPIO_106 */
+ gpio-key,wakeup;
+ };
+
+ home-button {
+ label = game 4;
+ linux,code = KEY_HOME;
+ gpios = gpio4 5 GPIO_ACTIVE_HIGH;/* GPIO_101 */
+ gpio-key,wakeup;
+ };
+
+ end-button {
+ label = game 2;
+ linux,code = KEY_END;
+ gpios = gpio4 15 GPIO_ACTIVE_HIGH; /* GPIO_111 */
+ gpio-key,wakeup;
+ };
+
+ right-shift {
+ label = l;
+ linux,code = KEY_RIGHTSHIFT;
+ gpios = gpio4 6 GPIO_ACTIVE_HIGH;/* GPIO_102 */
+ gpio-key,wakeup;
+ };
+
+ kp-plus {
+ label = l2;
+ linux,code = KEY_KPPLUS;
+ gpios = gpio4 1 GPIO_ACTIVE_HIGH;/* GPIO_97 */
+
