Re: [PATCH v3 5/7] net: cpsw: Add am33xx MACID readout
Hi,
On Tue, Aug 19, 2014 at 12:50:59AM +0200, Javier Martinez Canillas wrote:
> Hello Mugunthan,
>
> On Mon, Aug 18, 2014 at 9:58 PM, Mugunthan V N wrote:
> >>
> >> Thus, for this patchset, as is:
> >>
> >> Tested-by: Steven Rostedt
> >
> > This will fail for DRA7xx not in AM33xx
> >
>
> cpsw_am33xx_cm_get_macid() checks for
> of_machine_is_compatible("ti,am33xx") and returns 0 if the machine is
> not an am33xx. cpsw_probe_dt() only propagates the return value if is
> not 0 so this patch does not change the semantics for other SoCs
> besides am33xx.
Yes, this patch is only about the am33xx. I don't have the DRA7xx
hardware so I am not able to test on that hardware. Mugunthan, perhaps
you can supply some followup patches for DRA7xx.
Best regards,
Markus
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
signature.asc
Description: Digital signature
Re: [PATCH 2/2] remoteproc: add support to handle internal memories
Hi Suman, On Tue, Jul 29, 2014 at 10:33 PM, Suman Anna wrote: > We currently have two usecases. The primary usecase is the WkupM3 > processor on TI Sitara AM335x/AM437x SoCs used for suspend/resume > management. This series is a dependency for the WkupM3 remoteproc driver > that Dave posted [1]. More details are in section 8.1.4.6 of the AM335x > TRM [2]. The program/data sections for this processor all _needs_ to be > in the two internal memory RAMS (16K Unified RAM and 8K Data RAM), and > there is no MMU for this processor. The current RSC_CARVEOUT and > RSC_DEVMEM do not fit to describe this type of memory (we neither > allocate memory through dma api nor do we need to map these into an MMU). Thanks for the details. Can we define a CMA block for these regions, and then just use carveout resource entries instead of the ioremap approach? This may require some changes in remoteproc which we'll need to think about, but it sounds like it may fit the problem better instead of forcing ioremap to provide a regular pointer (we're supposed to use ioremaped memory only with memory primitives such as readl/writel/..). 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 2/2] Input: misc: introduce palmas-pwrbutton
Hi Dmitry
On 08/19/2014 12:23 AM, Dmitry Torokhov wrote:
Thanks for the review.
[...]
+
+/**
+ * pwron_irq() - button press isr
+ * @irq: irq
+ * @palmas_pwron: pwron struct
+ */
+static irqreturn_t pwron_irq(int irq, void *palmas_pwron)
+{
+ struct palmas_pwron *pwron = palmas_pwron;
+ struct input_dev *input_dev = pwron->input_dev;
+
+ cancel_delayed_work_sync(&pwron->input_work);
+
+ pwron->current_state = PALMAS_PWR_KEY_PRESS;
+
+ input_report_key(input_dev, KEY_POWER, pwron->current_state);
+ pm_wakeup_event(input_dev->dev.parent, 0);
+ input_sync(input_dev);
+
+ schedule_delayed_work(&pwron->input_work, 0);
Instead of cancel/schedule use mod_delayed_work. BTW, why do you need to
schedule immediately instead of waiting key_recheck_ms? Also, are there any
Good point, I had missed these. Will fix.
concerns about need to debounce?
I believe PMIC already takes care of debounce, let me see if there are
configuration registers possible. if yes, I think it might be nice to
add in.
[...]
+
+ irq = platform_get_irq(pdev, 0);
+
+ device_init_wakeup(dev, 1);
+
+ ret = devm_request_threaded_irq(dev, irq, NULL, pwron_irq,
+ IRQF_TRIGGER_HIGH |
+ IRQF_TRIGGER_LOW,
+ dev_name(dev),
+ pwron);
I am confused about this code sequence. Why do we get IRQ, then set up wakeup,
and then request irq? Normally you get irq number, and then you request it, and
then do other stuff.
Uggh.. right.. will fix.
+ if (ret < 0) {
+ dev_err(dev, "Can't get IRQ for pwron: %d\n", ret);
+ return ret;
+ }
+
+ enable_irq_wake(irq);
Shouldn't this be in suspend callback?
yes, it should have been.. my bad.. :( thanks for catching it.
+
+ ret = input_register_device(input_dev);
+ if (ret) {
+ dev_dbg(dev, "Can't register power button: %d\n", ret);
+ goto out_irq_wake;
+ }
+ pwron->irq = irq;
+
+ pwron->key_recheck_ms = PALMAS_PWR_KEY_Q_TIME_MS;
+
+ platform_set_drvdata(pdev, pwron);
+
+ return 0;
+
+out_irq_wake:
+ disable_irq_wake(irq);
+
+ return ret;
+}
+
+static int palmas_pwron_remove(struct platform_device *pdev)
+{
+ struct palmas_pwron *pwron = platform_get_drvdata(pdev);
+
+ disable_irq_wake(pwron->irq);
Should be in resume callback().
yep.
+ input_unregister_device(pwron->input_dev);
With devm you do not need to unregister input device. However this has problem:
what will happen if interrupt arrives here and we schedule workqueue? You need
free interrupt then cancel work and then free input device. Similar needs to be
done in probe(). I'd recommend not use devm_* here as you need to manually
unwind anyway.
True. I will fix these as well.
+
+ return 0;
+}
+
+#ifdef CONFIG_PM
+/**
+ * palmas_pwron_suspend() - suspend handler
+ * @dev: power button device
+ *
+ * Cancel all pending work items for the power button
+ */
+static int palmas_pwron_suspend(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct palmas_pwron *pwron = platform_get_drvdata(pdev);
+
+ cancel_delayed_work_sync(&pwron->input_work);
+
+ return 0;
+}
+
+static UNIVERSAL_DEV_PM_OPS(palmas_pwron_pm, palmas_pwron_suspend, NULL, NULL);
Why universal? Do they make sense for runtime pm?
+
+#else
+static UNIVERSAL_DEV_PM_OPS(palmas_pwron_pm, NULL, NULL, NULL);
+#endif
You do not need to protect these with #ifdef and have 2 versions, just pull
UNIVERSAL_DEV_PM_OPS (and change to SIMPLE_DEV_PM_OPS) out of #idef code.
I will just switch over to SIMPLE_DEV_PM_OPS here.. it is better here.
Thanks for the suggestion.
+
+#ifdef CONFIG_OF
+static struct of_device_id of_palmas_pwr_match[] = {
+ {.compatible = "ti,palmas-pwrbutton"},
+ {},
+};
+
+MODULE_DEVICE_TABLE(of, of_palmas_pwr_match);
+#endif
+
+static struct platform_driver palmas_pwron_driver = {
+ .probe = palmas_pwron_probe,
+ .remove = palmas_pwron_remove,
+ .driver = {
+ .name = "palmas_pwrbutton",
+ .owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(of_palmas_pwr_match),
+ .pm = &palmas_pwron_pm,
+ },
Weird indentation here.
Ugggh.. Lindent.. :(
---
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 1/2] doc: dt/bindings: input: introduce palmas power button description
On 08/19/2014 12:28 AM, Dmitry Torokhov wrote:
On Mon, Aug 18, 2014 at 03:13:29PM -0500, Nishanth Menon wrote:
Many palmas family of PMICs have support for interrupt based power
button. This allows the device to notify the processor of external
push button events over the shared palmas interrupt.
Document the hardware support for the same.
Signed-off-by: Nishanth Menon
---
.../bindings/input/ti,palmas-pwrbutton.txt | 32
1 file changed, 32 insertions(+)
create mode 100644
Documentation/devicetree/bindings/input/ti,palmas-pwrbutton.txt
diff --git a/Documentation/devicetree/bindings/input/ti,palmas-pwrbutton.txt
b/Documentation/devicetree/bindings/input/ti,palmas-pwrbutton.txt
new file mode 100644
index 000..6a89bcd
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/ti,palmas-pwrbutton.txt
@@ -0,0 +1,32 @@
+Texas Instruments Palmas family power button module
+
+This module is part of the Palmas family of PMICs. For more details
+about the whole chip see:
+Documentation/devicetree/bindings/mfd/palmas.txt.
+
+This module provides a simple power button event via an Interrupt.
+
+Required properties:
+- compatible: should be one of the following
+ - "ti,palmas-pwrbutton": For Palmas compatible power on button
+- interrupt-parent: Parent interrupt device, must be handle of palmas node.
+- interrupts: Interrupt number of power button submodule on device.
+
+Optional Properties:
+
+- ti,palmas-long-press-seconds: Duration in seconds which the power
+ button should be kept pressed for Palmas to power off automatically.
+ NOTE: This depends on OTP support and POWERHOLD signal configuration
+ on platform.
Only a few values are valid for this property, I think you should mention that.
Agreed. Will do so.
+
+Example:
+
+&palmas {
+ palmas_pwr_button: pwrbutton {
+ compatible = "ti,palmas-pwrbutton";
+ interrupt-parent = <&tps659038>;
+ interrupts = <1 IRQ_TYPE_NONE>;
Why none? Can we specify appropriate trigger here instead of hard-coding in the
driver?
Following the convention as in
Documentation/devicetree/bindings/mfd/palmas.txt - for whatever reason
we went with interrupt-cells = <2> when palmas interrupt configuration
was hardcoded in the chip(not reconfigurable). I believe it was level,
will check and update the example here.
+ wakeup-source;
What handles this attribute? I do not see it handled in the driver.
we dont explicitly need to in the driver, it was meant to indicate that
this is a wakeup source, but in reality, it is a palmas PMIC which is
the wakeup source.. so, will drop this.
+ ti,palmas-long-press-seconds = <12>;
+ };
+};
--
1.7.9.5
Thanks.
--
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/8] clk: ti: add gpio controlled clock
On Mon, Aug 18, 2014 at 10:46:39PM +0100, Jyri Sarha wrote:
> The added ti,gpio-clock is a basic clock that can be enabled and
> disabled trough a gpio output. The DT binding document for the clock
> is also added. For EPROBE_DEFER handling the registering of the clock
> has to be delayed until of_clk_get() call time.
I guess this is basically an AND gate with the GPIO and parent clock as
inputs? Or is this something more complex that we might want to do more
things with later?
If it's the former it sounds like this could be a completely generic
"gpio-gate-clock".
Thanks,
Mark.
> Signed-off-by: Jyri Sarha
> ---
> .../devicetree/bindings/clock/ti/gpio-clock.txt| 21 ++
> drivers/clk/ti/Makefile|2 +-
> drivers/clk/ti/gpio.c | 202
>
> 3 files changed, 224 insertions(+), 1 deletion(-)
> create mode 100644 Documentation/devicetree/bindings/clock/ti/gpio-clock.txt
> create mode 100644 drivers/clk/ti/gpio.c
>
> diff --git a/Documentation/devicetree/bindings/clock/ti/gpio-clock.txt
> b/Documentation/devicetree/bindings/clock/ti/gpio-clock.txt
> new file mode 100644
> index 000..2eb854d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/ti/gpio-clock.txt
> @@ -0,0 +1,21 @@
> +Binding for simple gpio controlled clock.
> +
> +This binding uses the common clock binding[1].
> +
> +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
> +
> +Required properties:
> +- compatible : shall be "ti,gpio-clock".
> +- #clock-cells : from common clock binding; shall be set to 0.
> +- enable-gpios : GPIO reference for enabling and disabling the clock.
> +
> +Optional properties:
> +- clocks: Maximum of one parent clock is supported.
> +
> +Example:
> + clock {
> + compatible = "ti,gpio-clock";
> + clocks = <&parentclk>;
> + #clock-cells = <0>;
> + enable-gpios = <&gpio 1 GPIO_ACTIVE_HIGH>;
> + };
> diff --git a/drivers/clk/ti/Makefile b/drivers/clk/ti/Makefile
> index ed4d0aa..88074d3 100644
> --- a/drivers/clk/ti/Makefile
> +++ b/drivers/clk/ti/Makefile
> @@ -1,7 +1,7 @@
> ifneq ($(CONFIG_OF),)
> obj-y+= clk.o autoidle.o
> clockdomain.o
> clk-common = dpll.o composite.o divider.o gate.o \
> - fixed-factor.o mux.o apll.o
> + fixed-factor.o mux.o apll.o gpio.o
> obj-$(CONFIG_SOC_AM33XX) += $(clk-common) clk-33xx.o
> obj-$(CONFIG_ARCH_OMAP2) += $(clk-common) interface.o clk-2xxx.o
> obj-$(CONFIG_ARCH_OMAP3) += $(clk-common) interface.o clk-3xxx.o
> diff --git a/drivers/clk/ti/gpio.c b/drivers/clk/ti/gpio.c
> new file mode 100644
> index 000..f4c668e
> --- /dev/null
> +++ b/drivers/clk/ti/gpio.c
> @@ -0,0 +1,202 @@
> +/*
> + * Copyright (C) 2012 - 2014 Texas Instruments Incorporated -
> http://www.ti.com
> + * Author: Jyri Sarha
> + *
> + * 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.
> + *
> + * Gpio controlled clock implementation
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +struct clk_gpio {
> + struct clk_hw hw;
> + struct gpio_desc *gpiod;
> +};
> +
> +/**
> + * DOC: basic gpio controlled clock which can be enabled and disabled
> + * with gpio output
> + * Traits of this clock:
> + * prepare - clk_(un)prepare only ensures parent is (un)prepared
> + * enable - clk_enable and clk_disable are functional & control gpio
> + * rate - inherits rate from parent. No clk_set_rate support
> + * parent - fixed parent. No clk_set_parent support
> + */
> +
> +#define to_clk_gpio(_hw) container_of(_hw, struct clk_gpio, hw)
> +
> +static int clk_gpio_enable(struct clk_hw *hw)
> +{
> + struct clk_gpio *clk = to_clk_gpio(hw);
> +
> + gpiod_set_value(clk->gpiod, 1);
> +
> + return 0;
> +}
> +
> +static void clk_gpio_disable(struct clk_hw *hw)
> +{
> + struct clk_gpio *clk = to_clk_gpio(hw);
> +
> + gpiod_set_value(clk->gpiod, 0);
> +}
> +
> +static int clk_gpio_is_enabled(struct clk_hw *hw)
> +{
> + struct clk_gpio *clk = to_clk_gpio(hw);
> +
> + return gpiod_get_value(clk->gpiod);
> +}
> +
> +static const struct clk_ops clk_gpio_ops = {
> + .enable = clk_gpio_enable,
> + .disable = clk_gpio_disable,
> + .is_enabled = clk_gpio_is_enabled,
> +};
> +
> +/**
> + * clk_register_gpio - register a gpip clock with the clock framework
> + * @dev: device that is registering this clock
> + * @name: name of this clock
> + * @parent_name: name of this clock's parent
> + * @gpiod: gpio descriptor to control this clock
> + */
> +static struct clk *clk_register_gpio(struct device *dev, const char *name,
> + const char *p
[PATCH 4/4] tty: omap-serial: support setting of hardware flow control in dts
This makes hardware flow control availability configurable from the device tree. Signed-off-by: Frans Klaver --- Documentation/devicetree/bindings/serial/omap_serial.txt | 1 + drivers/tty/serial/omap-serial.c | 4 2 files changed, 5 insertions(+) diff --git a/Documentation/devicetree/bindings/serial/omap_serial.txt b/Documentation/devicetree/bindings/serial/omap_serial.txt index 342eedd..1b629e9 100644 --- a/Documentation/devicetree/bindings/serial/omap_serial.txt +++ b/Documentation/devicetree/bindings/serial/omap_serial.txt @@ -8,3 +8,4 @@ Required properties: Optional properties: - clock-frequency : frequency of the clock input to the UART +- has-hw-flow-control : the hardware has flow control capability diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c index 57664b9..7d3b3d2 100644 --- a/drivers/tty/serial/omap-serial.c +++ b/drivers/tty/serial/omap-serial.c @@ -1598,6 +1598,10 @@ static struct omap_uart_port_info *of_get_uart_port_info(struct device *dev) of_property_read_u32(dev->of_node, "clock-frequency", &omap_up_info->uartclk); + + if (of_property_read_bool(dev->of_node, "has-hw-flow-control")) + omap_up_info->flags |= UPF_HARD_FLOW; + return omap_up_info; } -- 1.9.3 -- 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
[RFC PATCH 3/4] tty: omap-serial: use threaded interrupt handler
At 3.6Mbaud, with slightly over 2Mbit/s data coming in, we see 1600 uart
rx buffer overflows within 30 seconds. Threading the interrupt handling reduces
this to about 170 overflows in 10 minutes.
In practice this therefore reduces the need for hardware flow control,
meaning the sending side doesn't have to buffer as much either.
Signed-off-by: Frans Klaver
---
drivers/tty/serial/omap-serial.c | 31 ---
1 file changed, 24 insertions(+), 7 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 14a0167..57664b9 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -575,6 +575,21 @@ static void serial_omap_rdi(struct uart_omap_port *up,
unsigned int lsr)
}
/**
+ * serial_omap_fast_irq() - schedule interrupt handling
+ */
+static irqreturn_t serial_omap_fast_irq(int irq, void *dev_id)
+{
+ struct uart_omap_port *up = dev_id;
+ unsigned int iir = serial_in(up, UART_IIR);
+
+ if (iir & UART_IIR_NO_INT)
+ return IRQ_NONE;
+
+ disable_irq_nosync(up->port.irq);
+ return IRQ_WAKE_THREAD;
+}
+
+/**
* serial_omap_irq() - This handles the interrupt from one port
* @irq: uart port irq number
* @dev_id: uart port info
@@ -584,7 +599,6 @@ static irqreturn_t serial_omap_irq(int irq, void *dev_id)
struct uart_omap_port *up = dev_id;
unsigned int iir, lsr;
unsigned int type;
- irqreturn_t ret = IRQ_NONE;
int max_count = 256;
spin_lock(&up->port.lock);
@@ -595,7 +609,6 @@ static irqreturn_t serial_omap_irq(int irq, void *dev_id)
if (iir & UART_IIR_NO_INT)
break;
- ret = IRQ_HANDLED;
lsr = serial_in(up, UART_LSR);
/* extract IRQ type from IIR register */
@@ -630,11 +643,13 @@ static irqreturn_t serial_omap_irq(int irq, void *dev_id)
tty_flip_buffer_push(&up->port.state->port);
+ enable_irq(up->port.irq);
+
pm_runtime_mark_last_busy(up->dev);
pm_runtime_put_autosuspend(up->dev);
up->port_activity = jiffies;
- return ret;
+ return IRQ_HANDLED;
}
static unsigned int serial_omap_tx_empty(struct uart_port *port)
@@ -731,15 +746,17 @@ static int serial_omap_startup(struct uart_port *port)
/*
* Allocate the IRQ
*/
- retval = request_irq(up->port.irq, serial_omap_irq, up->port.irqflags,
- up->name, up);
+ retval = request_threaded_irq(up->port.irq, serial_omap_fast_irq,
+ serial_omap_irq, up->port.irqflags,
+ up->name, up);
if (retval)
return retval;
/* Optional wake-up IRQ */
if (up->wakeirq) {
- retval = request_irq(up->wakeirq, serial_omap_irq,
-up->port.irqflags, up->name, up);
+ retval = request_threaded_irq(up->wakeirq, serial_omap_fast_irq,
+ serial_omap_irq, up->port.irqflags,
+ up->name, up);
if (retval) {
free_irq(up->port.irq, up);
return retval;
--
1.9.3
--
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
[RFC PATCHv2 0/4] omap-serial high-speed fixes/improvements
Here's version 2 of the patches that should improve the behavior of the omap serial port at high baud and data rates. Differences with regard to v1 are: - centralize baud_is_mode16's calculation - fix/unbreak an uninitialized variable in "use threaded interrupt handler" - read has-hw-flow-control property in of_get_uart_port_info Frans Klaver (4): tty: omap-serial: pull out calculation from baud_is_mode16 tty: omap-serial: prevent division by zero tty: omap-serial: use threaded interrupt handler tty: omap-serial: support setting of hardware flow control in dts .../devicetree/bindings/serial/omap_serial.txt | 1 + drivers/tty/serial/omap-serial.c | 65 +- 2 files changed, 51 insertions(+), 15 deletions(-) -- 1.9.3 -- 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/4] tty: omap-serial: prevent division by zero
If the chosen baud rate is large enough (e.g. 3.5 megabaud), the
calculated n values in calculate_baud_abs_diff may become 0. This causes
a division by zero when calculating the difference between calculated
and desired baud rates. To prevent this, cap n on 1.
Signed-off-by: Frans Klaver
---
drivers/tty/serial/omap-serial.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index ae935ce..14a0167 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -246,8 +246,12 @@ static inline int calculate_baud_abs_diff(struct uart_port
*port,
unsigned int baud, unsigned int mode)
{
unsigned int n = port->uartclk / (mode * baud);
- int abs_diff = baud - (port->uartclk / (mode * n));
+ int abs_diff;
+ if (n == 0)
+ n = 1;
+
+ abs_diff = baud - (uartclk / (mode * n));
if (abs_diff < 0)
abs_diff = -abs_diff;
--
1.9.3
--
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] tty: omap-serial: pull out calculation from baud_is_mode16
To determine the correct divisor, we need to know the difference between
the desired baud rate and the actual baud rate. The calculation for this
difference is implemented twice within omap_serial_baud_is_mode16().
Pull out the calculation for easier maintenance.
Signed-off-by: Frans Klaver
---
drivers/tty/serial/omap-serial.c | 26 ++
1 file changed, 18 insertions(+), 8 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index d017cec..ae935ce 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -239,6 +239,22 @@ static void serial_omap_enable_wakeup(struct
uart_omap_port *up, bool enable)
}
/*
+ * Calculate the absolute difference between the desired and actual baud
+ * rate for the given mode.
+ */
+static inline int calculate_baud_abs_diff(struct uart_port *port,
+ unsigned int baud, unsigned int mode)
+{
+ unsigned int n = port->uartclk / (mode * baud);
+ int abs_diff = baud - (port->uartclk / (mode * n));
+
+ if (abs_diff < 0)
+ abs_diff = -abs_diff;
+
+ return abs_diff;
+}
+
+/*
* serial_omap_baud_is_mode16 - check if baud rate is MODE16X
* @port: uart port info
* @baud: baudrate for which mode needs to be determined
@@ -252,14 +268,8 @@ static void serial_omap_enable_wakeup(struct
uart_omap_port *up, bool enable)
static bool
serial_omap_baud_is_mode16(struct uart_port *port, unsigned int baud)
{
- unsigned int n13 = port->uartclk / (13 * baud);
- unsigned int n16 = port->uartclk / (16 * baud);
- int baudAbsDiff13 = baud - (port->uartclk / (13 * n13));
- int baudAbsDiff16 = baud - (port->uartclk / (16 * n16));
- if (baudAbsDiff13 < 0)
- baudAbsDiff13 = -baudAbsDiff13;
- if (baudAbsDiff16 < 0)
- baudAbsDiff16 = -baudAbsDiff16;
+ int baudAbsDiff13 = calculate_baud_abs_diff(port, baud, 13);
+ int baudAbsDiff16 = calculate_baud_abs_diff(port, baud, 16);
return (baudAbsDiff13 >= baudAbsDiff16);
}
--
1.9.3
--
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/8] clk: ti: add gpio controlled clock
On 08/19/2014 02:32 PM, Mark Rutland wrote: On Mon, Aug 18, 2014 at 10:46:39PM +0100, Jyri Sarha wrote: The added ti,gpio-clock is a basic clock that can be enabled and disabled trough a gpio output. The DT binding document for the clock is also added. For EPROBE_DEFER handling the registering of the clock has to be delayed until of_clk_get() call time. I guess this is basically an AND gate with the GPIO and parent clock as inputs? Or is this something more complex that we might want to do more things with later? If it's the former it sounds like this could be a completely generic "gpio-gate-clock". Yes, its completely generic. However, since there has been no response to my several earlier attempts to get this patch in I finally gave up and moved it under clk/ti. "gpio-gate-clock" sound like more accurate name for ti. I'll change that. Do you think I should give this one more try to get it in as generic basic clock? Cheers, Jyri -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/8] clk: ti: add gpio controlled clock
On Tue, Aug 19, 2014 at 01:23:12PM +0100, Jyri Sarha wrote: > On 08/19/2014 02:32 PM, Mark Rutland wrote: > > On Mon, Aug 18, 2014 at 10:46:39PM +0100, Jyri Sarha wrote: > >> The added ti,gpio-clock is a basic clock that can be enabled and > >> disabled trough a gpio output. The DT binding document for the clock > >> is also added. For EPROBE_DEFER handling the registering of the clock > >> has to be delayed until of_clk_get() call time. > > > > I guess this is basically an AND gate with the GPIO and parent clock as > > inputs? Or is this something more complex that we might want to do more > > things with later? > > > > If it's the former it sounds like this could be a completely generic > > "gpio-gate-clock". > > > > Yes, its completely generic. However, since there has been no response > to my several earlier attempts to get this patch in I finally gave up > and moved it under clk/ti. Ah. Apolgoies for that having happened. > "gpio-gate-clock" sound like more accurate name for ti. I'll change that. > > Do you think I should give this one more try to get it in as generic > basic clock? I'd certainly be happy with a generic gpio-gate-clock. Mike, thoughts? Thanks, Mark. -- 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 3/8] ASoC: davinci-evm: HDMI audio support for TDA998x trough McASP I2S bus
On Mon, Aug 18, 2014 at 10:46:41PM +0100, Jyri Sarha wrote: > Add machine driver support for BeagleBone-Black HDMI audio. BBB has > NXP TDA998X HDMI transmitter connected to McASP port in I2S mode. The > 44100 Hz sample-rate and it's multiples can not be accurately produced > on BBB. The only supported sample format is SNDRV_PCM_FORMAT_S32_LE. > The 8 least significant bits are ignored. > > Signed-off-by: Jyri Sarha > --- > .../bindings/sound/davinci-evm-audio.txt |4 +- > sound/soc/davinci/davinci-evm.c| 82 > +++- > 2 files changed, 83 insertions(+), 3 deletions(-) > > diff --git a/Documentation/devicetree/bindings/sound/davinci-evm-audio.txt > b/Documentation/devicetree/bindings/sound/davinci-evm-audio.txt > index 963e100..c137436 100644 > --- a/Documentation/devicetree/bindings/sound/davinci-evm-audio.txt > +++ b/Documentation/devicetree/bindings/sound/davinci-evm-audio.txt > @@ -1,7 +1,9 @@ > * Texas Instruments SoC audio setups with TLV320AIC3X Codec > > Required properties: > -- compatible : "ti,da830-evm-audio" : forDM365/DA8xx/OMAPL1x/AM33xx > +- compatible : "ti,da830-evm-audio" : for DM365/DA8xx/OMAPL1x/AM33xx > + "ti,am335x-beaglebone-black-audio" : for Beaglebone-black HDMI > +audio To keep this legible I'd recommend reorganising this like: - compatible: should contain one of: * "ti,da830-evm-audio" for DM365/DA8xx/OMAPL1x/AM33xx * "ti,am335x-beaglebone-black-audio" for Beaglebone-black HDMI audio For the BBB case, do you expect both strings or just the BBB-specific string? Is the 'x' in the BBB string a wildcard? If we know the particular number for BBB we should use that. Cheers, Mark. -- 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/1] clk: ti: add support for external clock provider
Hi Tero,
On Fri, Aug 01, 2014 at 02:15:48PM +0100, Tero Kristo wrote:
> External clock provider can now be used to register external clocks under
> it. This is needed as the TI clock driver only registers clocks
> hierarchically under clock providers, and external clocks do not belong
> under any of the current ones.
I must admit that I don't understand the justification for this binding.
Why can't these clocks be descrbied elsewhere and wired up as usual? Why
must they be under the TI clock provide node?
>From the limited description above it sounds like the only reason this
exists is to work around a deficiency in the TI clock driver. That does
not sound like a very good reason for having this.
Thanks,
Mark.
>
> Signed-off-by: Tero Kristo
> ---
> .../devicetree/bindings/arm/omap/ext-clocks.txt| 32
>
> arch/arm/mach-omap2/io.c | 12 ++--
> drivers/clk/ti/clk.c | 23 ++
> include/linux/clk/ti.h |2 ++
> 4 files changed, 67 insertions(+), 2 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/arm/omap/ext-clocks.txt
>
> diff --git a/Documentation/devicetree/bindings/arm/omap/ext-clocks.txt
> b/Documentation/devicetree/bindings/arm/omap/ext-clocks.txt
> new file mode 100644
> index 000..8e784bb
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/omap/ext-clocks.txt
> @@ -0,0 +1,32 @@
> +TI external clock provider properties
> +
> +External clock provider is used to group SoC external board specific
> +clock nodes. A separate provider node is required as the TI clock
> +driver registers clocks hierarchically.
> +
> +Required properties:
> +- compatible:Shall be: "ti,external-clocks"
> +- clocks:Contains the external clocks for the board
> +- clockdomains: Contains the external clockdomains for the board
> +
> +Example:
> +
> +ext_clocks {
> + compatible = "ti,external-clocks";
> +
> + ext_clocks: clocks {
> + };
> +
> + ext_clockdomains: clockdomains {
> + };
> +};
> +
> +...
> +
> +&ext_clocks {
> + gpio_test_clock {
> + compatible = "gpio-clock";
> + #clock-cells = <0>;
> + enable-gpios = <&gpio5 25 GPIO_ACTIVE_HIGH>;
> + };
> +};
> diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
> index 8f55945..77be18b 100644
> --- a/arch/arm/mach-omap2/io.c
> +++ b/arch/arm/mach-omap2/io.c
> @@ -21,6 +21,8 @@
> #include
> #include
> #include
> +#include
> +#include
>
> #include
> #include
> @@ -729,8 +731,14 @@ int __init omap_clk_init(void)
> return 0;
>
> ret = of_prcm_init();
> - if (!ret)
> - ret = omap_clk_soc_init();
> + if (ret)
> + return ret;
> +
> + ret = ti_dt_clk_ext_init();
> + if (ret)
> + return ret;
> +
> + ret = omap_clk_soc_init();
>
> return ret;
> }
> diff --git a/drivers/clk/ti/clk.c b/drivers/clk/ti/clk.c
> index b1a6f71..c84ce4d 100644
> --- a/drivers/clk/ti/clk.c
> +++ b/drivers/clk/ti/clk.c
> @@ -165,3 +165,26 @@ void ti_dt_clk_init_provider(struct device_node *parent,
> int index)
> kfree(retry);
> }
> }
> +
> +static struct of_device_id ti_ext_clk_match_table[] = {
> + { .compatible = "ti,external-clocks" },
> + { }
> +};
> +
> +/**
> + * ti_dt_clk_ext_init - initialize external clocks from DT
> + *
> + * Some clocks are provided from external chips outside the main SoC.
> + * The details for these are given under a special DT node, which will
> + * be parsed by this function.
> + */
> +int ti_dt_clk_ext_init(void)
> +{
> + struct device_node *np;
> +
> + for_each_matching_node(np, ti_ext_clk_match_table) {
> + ti_dt_clk_init_provider(np, -1);
> + }
> +
> + return 0;
> +}
> diff --git a/include/linux/clk/ti.h b/include/linux/clk/ti.h
> index e8d8a35..188270c 100644
> --- a/include/linux/clk/ti.h
> +++ b/include/linux/clk/ti.h
> @@ -310,6 +310,8 @@ int am43xx_dt_clk_init(void);
> int omap2420_dt_clk_init(void);
> int omap2430_dt_clk_init(void);
>
> +int ti_dt_clk_ext_init(void);
> +
> #ifdef CONFIG_OF
> void of_ti_clk_allow_autoidle_all(void);
> void of_ti_clk_deny_autoidle_all(void);
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.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
[PATCH] ARM: dts: DRA7: Add PMU nodes
From: Lucas Weaver
DRA74x and DRA72x family of processors vary slightly in the number
of CPUs. So, add different instances of PMU for each of these processor
groups. Further, since the interrupts bypass crossbar and are directly
connected to GIC, mark the dts nodes with relevant information.
Tested with perf utility.
Reviewed-by: Felipe Balbi
Signed-off-by: Lucas Weaver
Signed-off-by: Nishanth Menon
---
arch/arm/boot/dts/dra72x.dtsi |5 +
arch/arm/boot/dts/dra74x.dtsi |6 ++
2 files changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/dra72x.dtsi b/arch/arm/boot/dts/dra72x.dtsi
index f1ec22f..e5a3d23 100644
--- a/arch/arm/boot/dts/dra72x.dtsi
+++ b/arch/arm/boot/dts/dra72x.dtsi
@@ -22,4 +22,9 @@
reg = <0>;
};
};
+
+ pmu {
+ compatible = "arm,cortex-a15-pmu";
+ interrupts = ;
+ };
};
diff --git a/arch/arm/boot/dts/dra74x.dtsi b/arch/arm/boot/dts/dra74x.dtsi
index a4e8bb9..3be544c 100644
--- a/arch/arm/boot/dts/dra74x.dtsi
+++ b/arch/arm/boot/dts/dra74x.dtsi
@@ -38,4 +38,10 @@
reg = <1>;
};
};
+
+ pmu {
+ compatible = "arm,cortex-a15-pmu";
+ interrupts = ,
+;
+ };
};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] mfd: palmas: Add support for optional wakeup
With the recent pinctrl-single changes, omaps can treat wake-up events
from deeper idle states as interrupts.
Let's add support for the optional second interrupt for wake-up
events. And then SoC can wakeup and handle the event using it's
regular handler.
Finally, to pass the wake-up interrupt in the dts file,
interrupts-extended property needs to be passed.
This is similar in approach to commit 2a0b965cfb6e ("serial: omap: Add
support for optional wake-up")
Signed-off-by: Nishanth Menon
---
Documentation/devicetree/bindings/mfd/palmas.txt | 20
drivers/mfd/palmas.c | 59 ++
include/linux/mfd/palmas.h |2 +
3 files changed, 81 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/palmas.txt
b/Documentation/devicetree/bindings/mfd/palmas.txt
index eda8989..2627842 100644
--- a/Documentation/devicetree/bindings/mfd/palmas.txt
+++ b/Documentation/devicetree/bindings/mfd/palmas.txt
@@ -51,3 +51,23 @@ palmas {
};
}
+
+Example: with interrupts extended
+ See Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
+ Use pinmux 0x418 as wakeup interrupt and gpio1_0 as interrupt source
+
+palmas {
+ compatible = "ti,twl6035", "ti,palmas";
+ reg = <0x48>
+ interrupt-parent = <&intc>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts-extended = <&gpio1 0 IRQ_TYPE_LEVEL_HIGH
+ &pinmux 0x418>;
+ pmic {
+ compatible = "ti,twl6035-pmic", "ti,palmas-pmic";
+
+ };
+}
diff --git a/drivers/mfd/palmas.c b/drivers/mfd/palmas.c
index 28cb048..11186ab 100644
--- a/drivers/mfd/palmas.c
+++ b/drivers/mfd/palmas.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
static const struct regmap_config palmas_regmap_config[PALMAS_NUM_CLIENTS] = {
{
@@ -326,6 +327,16 @@ static struct regmap_irq_chip tps65917_irq_chip = {
PALMAS_INT1_MASK),
};
+static irqreturn_t palmas_wake_irq(int irq, void *_palmas)
+{
+ /*
+* Return Not handled so that interrupt is disabled.
+* Level event ensures that the event is eventually handled
+* by the appropriate chip handler already registered
+*/
+ return IRQ_NONE;
+}
+
int palmas_ext_control_req_config(struct palmas *palmas,
enum palmas_external_requestor_id id, int ext_ctrl, bool enable)
{
@@ -409,6 +420,7 @@ static void palmas_dt_to_pdata(struct i2c_client *i2c,
pdata->mux_from_pdata = 1;
pdata->pad2 = prop;
}
+ pdata->wakeirq = irq_of_parse_and_map(node, 1);
/* The default for this register is all masked */
ret = of_property_read_u32(node, "ti,power-ctrl", &prop);
@@ -521,6 +533,7 @@ static int palmas_i2c_probe(struct i2c_client *i2c,
i2c_set_clientdata(i2c, palmas);
palmas->dev = &i2c->dev;
palmas->irq = i2c->irq;
+ palmas->wakeirq = pdata->wakeirq;
match = of_match_device(of_palmas_match_tbl, &i2c->dev);
@@ -587,6 +600,22 @@ static int palmas_i2c_probe(struct i2c_client *i2c,
if (ret < 0)
goto err_i2c;
+ if (!palmas->wakeirq)
+ goto no_wake_irq;
+
+ ret = devm_request_irq(palmas->dev, palmas->wakeirq,
+ palmas_wake_irq,
+ IRQF_ONESHOT | pdata->irq_flags,
+ dev_name(palmas->dev),
+ &palmas);
+ if (ret < 0)
+ goto err_i2c;
+
+ /* We use wakeirq only during suspend-resume path */
+ device_set_wakeup_capable(palmas->dev, true);
+ disable_irq_nosync(palmas->wakeirq);
+
+no_wake_irq:
no_irq:
slave = PALMAS_BASE_TO_SLAVE(PALMAS_PU_PD_OD_BASE);
addr = PALMAS_BASE_TO_REG(PALMAS_PU_PD_OD_BASE,
@@ -706,6 +735,34 @@ static int palmas_i2c_remove(struct i2c_client *i2c)
return 0;
}
+static int palmas_i2c_suspend(struct i2c_client *i2c, pm_message_t mesg)
+{
+ struct palmas *palmas = i2c_get_clientdata(i2c);
+ struct device *dev = &i2c->dev;
+
+ if (!palmas->wakeirq)
+ return 0;
+
+ if (device_may_wakeup(dev))
+ enable_irq(palmas->wakeirq);
+
+ return 0;
+}
+
+static int palmas_i2c_resume(struct i2c_client *i2c)
+{
+ struct palmas *palmas = i2c_get_clientdata(i2c);
+ struct device *dev = &i2c->dev;
+
+ if (!palmas->wakeirq)
+ return 0;
+
+ if (device_may_wakeup(dev))
+ disable_irq_nosync(palmas->wakeirq);
+
+ return 0;
+}
+
static const struct i2c_device_id palmas_i2c_id[] = {
{ "palmas", },
{ "twl6035", },
@@ -721,6 +778,8 @@ static struct i2c_driver palmas_i2c_driver = {
.of_match_table = of_palmas_match_t
hello
Моето Скъпи Едно, Приятно ми е да се запознаем аз видях в пощата си днес, когато аз бях търсят и се интересуват от знаейки, че повече аз наистина биха искали да имат добри отношения с вас, и аз имам специални причини, поради които реших да се свържем с вас Реших да ви пиша, поради неотложността на положението ми тук аз съм Мис Laura, на 25 години момиче от Кот д'Ивоар, единствената дъщеря на края Wintour Sirleaf заместник-министър на националната сигурност, под ръководството на президента Laurent Gbagbo, който в момента е в изгнание след много невинни души бяха убити, баща ми беше убит от Laurent Gbagbo's правителство, обвинявайки то на баща ми се опита за преврат Трябва да се свържем с вас, защото на малтретиране, което получих от моя стъпка майка, мащехата ми, планове е да се вземат всички хазната и имуществото на покойния ми баща от мен, след неочакваната смърт на любимия си баща Бих искал да избяга от страна на Африка, но тя се скрия паспорта ми и други ценни документи за пътуване, За щастие, тя не се намерят, когато си тръгнах файл на баща ми, който съдържа важни документи Затова реших да тичам до бежански лагер, където съм в момента търси убежище под егидата на върховния комисар на ООН за бежанците тук в Ломе, Република Того. Искам да ви пиша лично за дългогодишен бизнес отношения и инвестиции във вашата страна Баща ми депозира сума от US $ 6 500, 000,00 милиона долара в банката, с моето име като най-близък роднина. Независимо от това, искам да се кандидатират за мен като попечител, а също и да ми помогне да преведе парите по сметката си и вие също ще ми помогне да инвестират парите във вашата страна, ако приемете да ми помогне аз ще предаде на вас необходимите документи и аз ще продължа с обучението си, когато аз дойда във вашата страна, аз бях в моя милион години в университета, когато кризата започна Моето намерение е да ви компенсира 20% от общата сума на пари за услугите си и балансът ще бъде мой инвестиционен капитал. Това е причината, поради която реших да се свържем с вас В очакване на вашия спешни и положителен отговор. Моля те, не го оставяйте само за себе си, моля, аз не питам за да го разкрие на всяко друго лице, докато се прави прехвърлянето Моля, нека моето положение докосне сърцето си, аз ви моля да дойдете за моето оздравяване аз страдам толкова много тук , аз никога не съм бил в този вид на ситуацията преди, моля да ми помогне Best рег. Laura
[PATCH v8 5/9] arm: omap1: Migrate debug_ll macros to use 8250.S
The omap1's debug-macro.S is similar to the generic 8250 code. Compared to the 8520 code the omap1 macro automatically determines what UART to use based on breadcrumbs left by the bootloader and automatically copes with the eccentric register layout on OMAP7XX. This patch drops both these features and relies instead on the generic 8250 macros: 1. Dropping support for the bootloader breadcrumbs is identical to the way the migration was handled for OMAP2 (see 808b7e07464d...). 2. Support for OMAP7XX still exists but it must be configured by hand (DEBUG_OMAP7XXUART1/2/3) rather than handled at runtime. Signed-off-by: Daniel Thompson Cc: Russell King Cc: linux-arm-ker...@lists.infradead.org Cc: Tony Lindgren Cc: Arnd Bergmann Cc: linux-omap@vger.kernel.org Tested-by: Aaro Koskinen --- arch/arm/Kconfig.debug | 57 +- arch/arm/mach-omap1/include/mach/debug-macro.S | 101 - 2 files changed, 56 insertions(+), 102 deletions(-) delete mode 100644 arch/arm/mach-omap1/include/mach/debug-macro.S diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug index 97c3058..01f4ee2 100644 --- a/arch/arm/Kconfig.debug +++ b/arch/arm/Kconfig.debug @@ -471,6 +471,30 @@ choice Say Y here if you want kernel low-level debugging support on TI-NSPIRE CX models. + config DEBUG_OMAP1UART1 + bool "Kernel low-level debugging via OMAP1 UART1" + depends on ARCH_OMAP1 + select DEBUG_UART_8250 + help + Say Y here if you want kernel low-level debugging support + on OMAP1 based platforms (expect OMAP730) on the UART1. + + config DEBUG_OMAP1UART2 + bool "Kernel low-level debugging via OMAP1 UART2" + depends on ARCH_OMAP1 + select DEBUG_UART_8250 + help + Say Y here if you want kernel low-level debugging support + on OMAP1 based platforms (expect OMAP730) on the UART2. + + config DEBUG_OMAP1UART3 + bool "Kernel low-level debugging via OMAP1 UART3" + depends on ARCH_OMAP1 + select DEBUG_UART_8250 + help + Say Y here if you want kernel low-level debugging support + on OMAP1 based platforms (expect OMAP730) on the UART3. + config DEBUG_OMAP2UART1 bool "OMAP2/3/4 UART1 (omap2/3 sdp boards and some omap3 boards)" depends on ARCH_OMAP2PLUS @@ -513,6 +537,30 @@ choice depends on ARCH_OMAP2PLUS select DEBUG_OMAP2PLUS_UART + config DEBUG_OMAP7XXUART1 + bool "Kernel low-level debugging via OMAP730 UART1" + depends on ARCH_OMAP730 + select DEBUG_UART_8250 + help + Say Y here if you want kernel low-level debugging support + on OMAP730 based platforms on the UART1. + + config DEBUG_OMAP7XXUART2 + bool "Kernel low-level debugging via OMAP730 UART2" + depends on ARCH_OMAP730 + select DEBUG_UART_8250 + help + Say Y here if you want kernel low-level debugging support + on OMAP730 based platforms on the UART2. + + config DEBUG_OMAP7XXUART3 + bool "Kernel low-level debugging via OMAP730 UART3" + depends on ARCH_OMAP730 + select DEBUG_UART_8250 + help + Say Y here if you want kernel low-level debugging support + on OMAP730 based platforms on the UART3. + config DEBUG_TI81XXUART1 bool "Kernel low-level debugging messages via TI81XX UART1 (ti8148evm)" depends on ARCH_OMAP2PLUS @@ -1120,6 +1168,9 @@ config DEBUG_UART_PHYS default 0xff69 if DEBUG_RK32_UART2 default 0xffc02000 if DEBUG_SOCFPGA_UART default 0xffd82340 if ARCH_IOP13XX + default 0xfffb if DEBUG_OMAP1UART1 || DEBUG_OMAP7XXUART1 + default 0xfffb0800 if DEBUG_OMAP1UART2 || DEBUG_OMAP7XXUART2 + default 0xfffb9800 if DEBUG_OMAP1UART3 || DEBUG_OMAP7XXUART3 default 0xfff36000 if DEBUG_HIGHBANK_UART default 0xf700 if ARCH_IOP33X depends on DEBUG_LL_UART_8250 || DEBUG_LL_UART_PL01X || \ @@ -1188,6 +1239,9 @@ config DEBUG_UART_VIRT default 0xfef0 if ARCH_IXP4XX && !CPU_BIG_ENDIAN default 0xfef3 if ARCH_IXP4XX && CPU_BIG_ENDIAN default 0xfef36000 if DEBUG_HIGHBANK_UART + default 0xfefb if DEBUG_OMAP1UART1 || DEBUG_OMAP7XXUART1 + default 0xfefb0800 if DEBUG_OMAP1UART2 || DEBUG_OMAP7XXUART2 + default 0xfefb9800 if DEBUG_OMAP1UART3 || DEBUG_OMAP7XXUART3 default 0xfefff700 if ARCH_IOP33X default 0xff003000 if DEBUG_U300_UART default DEBUG_UART_PHYS if !MMU @@ -1198,7 +1252,8 @@ confi
Re: Questions about enabling dps(dynamic power switching) and SLM
Hi, * Deepa Raj [140818 10:32]: > Hi Tony, > > I have few more questions on OMAP3: > > 1) As you know there are power scripts in drivers/mfd folder for PMIC chip > (Triton2). Is this mandatory to use these scripts like there are P1,P2,P3 > areas are there in PMIC. Not mandatory, but you need to configure the scripts if you want the PMIC to trigger changes during deeper idle states based on sys_clkreq and sys_off_mode pins. > 2) My understanding was when regulator_enable and disable are called from > device drivers, voltage regulators are powered on/off, is it correct, if yes, > why do we need to use power scripts? We still need to configure scripts as when the system hits retention or off mode during idle, the regulator framework can't do anything. For most part we want to configure PMIC to shut down vpll1, vdd1 and vdd2 during off-idle while keeping everything else controlled by the regulator framework. Optionally also the oscillator can be cut off and regen. FYI, there's a bug in omap3_idle_rconfig that I'll provide a patch for today. Most of it should use TWL4030_RESCONFIG_UNDEF instead of DEV_GRP_NULL. > 3) Suppose HiFreq clk source (Oscillator), since there are no suspend/resume > hooks from PMIC. Do we mandatory to use these scripts during suspend to RAM > or we can directly power off oscillators or is there any hardware mechanism > also, when all voltage regulators are disabled, HiFreq oscillator will be cut > off. That must be done withe the scripts as nothing else can run without the oscillator :) > 4) Do power scripts are mandatory for all OMAP platforms? Not mandatory, but needed for many battery operated devices to save power. 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 v9 5/9] arm: omap1: Migrate debug_ll macros to use 8250.S
The omap1's debug-macro.S is similar to the generic 8250 code. Compared to the 8520 code the omap1 macro automatically determines what UART to use based on breadcrumbs left by the bootloader and automatically copes with the eccentric register layout on OMAP7XX. This patch drops both these features and relies instead on the generic 8250 macros: 1. Dropping support for the bootloader breadcrumbs is identical to the way the migration was handled for OMAP2 (see 808b7e07464d...). 2. Support for OMAP7XX still exists but it must be configured by hand (DEBUG_OMAP7XXUART1/2/3) rather than handled at runtime. Signed-off-by: Daniel Thompson Cc: Russell King Cc: linux-arm-ker...@lists.infradead.org Cc: Tony Lindgren Cc: Arnd Bergmann Cc: linux-omap@vger.kernel.org Tested-by: Aaro Koskinen --- arch/arm/Kconfig.debug | 57 +- arch/arm/mach-omap1/include/mach/debug-macro.S | 101 - 2 files changed, 56 insertions(+), 102 deletions(-) delete mode 100644 arch/arm/mach-omap1/include/mach/debug-macro.S diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug index 97c3058..01f4ee2 100644 --- a/arch/arm/Kconfig.debug +++ b/arch/arm/Kconfig.debug @@ -471,6 +471,30 @@ choice Say Y here if you want kernel low-level debugging support on TI-NSPIRE CX models. + config DEBUG_OMAP1UART1 + bool "Kernel low-level debugging via OMAP1 UART1" + depends on ARCH_OMAP1 + select DEBUG_UART_8250 + help + Say Y here if you want kernel low-level debugging support + on OMAP1 based platforms (expect OMAP730) on the UART1. + + config DEBUG_OMAP1UART2 + bool "Kernel low-level debugging via OMAP1 UART2" + depends on ARCH_OMAP1 + select DEBUG_UART_8250 + help + Say Y here if you want kernel low-level debugging support + on OMAP1 based platforms (expect OMAP730) on the UART2. + + config DEBUG_OMAP1UART3 + bool "Kernel low-level debugging via OMAP1 UART3" + depends on ARCH_OMAP1 + select DEBUG_UART_8250 + help + Say Y here if you want kernel low-level debugging support + on OMAP1 based platforms (expect OMAP730) on the UART3. + config DEBUG_OMAP2UART1 bool "OMAP2/3/4 UART1 (omap2/3 sdp boards and some omap3 boards)" depends on ARCH_OMAP2PLUS @@ -513,6 +537,30 @@ choice depends on ARCH_OMAP2PLUS select DEBUG_OMAP2PLUS_UART + config DEBUG_OMAP7XXUART1 + bool "Kernel low-level debugging via OMAP730 UART1" + depends on ARCH_OMAP730 + select DEBUG_UART_8250 + help + Say Y here if you want kernel low-level debugging support + on OMAP730 based platforms on the UART1. + + config DEBUG_OMAP7XXUART2 + bool "Kernel low-level debugging via OMAP730 UART2" + depends on ARCH_OMAP730 + select DEBUG_UART_8250 + help + Say Y here if you want kernel low-level debugging support + on OMAP730 based platforms on the UART2. + + config DEBUG_OMAP7XXUART3 + bool "Kernel low-level debugging via OMAP730 UART3" + depends on ARCH_OMAP730 + select DEBUG_UART_8250 + help + Say Y here if you want kernel low-level debugging support + on OMAP730 based platforms on the UART3. + config DEBUG_TI81XXUART1 bool "Kernel low-level debugging messages via TI81XX UART1 (ti8148evm)" depends on ARCH_OMAP2PLUS @@ -1120,6 +1168,9 @@ config DEBUG_UART_PHYS default 0xff69 if DEBUG_RK32_UART2 default 0xffc02000 if DEBUG_SOCFPGA_UART default 0xffd82340 if ARCH_IOP13XX + default 0xfffb if DEBUG_OMAP1UART1 || DEBUG_OMAP7XXUART1 + default 0xfffb0800 if DEBUG_OMAP1UART2 || DEBUG_OMAP7XXUART2 + default 0xfffb9800 if DEBUG_OMAP1UART3 || DEBUG_OMAP7XXUART3 default 0xfff36000 if DEBUG_HIGHBANK_UART default 0xf700 if ARCH_IOP33X depends on DEBUG_LL_UART_8250 || DEBUG_LL_UART_PL01X || \ @@ -1188,6 +1239,9 @@ config DEBUG_UART_VIRT default 0xfef0 if ARCH_IXP4XX && !CPU_BIG_ENDIAN default 0xfef3 if ARCH_IXP4XX && CPU_BIG_ENDIAN default 0xfef36000 if DEBUG_HIGHBANK_UART + default 0xfefb if DEBUG_OMAP1UART1 || DEBUG_OMAP7XXUART1 + default 0xfefb0800 if DEBUG_OMAP1UART2 || DEBUG_OMAP7XXUART2 + default 0xfefb9800 if DEBUG_OMAP1UART3 || DEBUG_OMAP7XXUART3 default 0xfefff700 if ARCH_IOP33X default 0xff003000 if DEBUG_U300_UART default DEBUG_UART_PHYS if !MMU @@ -1198,7 +1252,8 @@ confi
Re: Lock Directory failure
Hi Hugh,
On Mon, 18 Aug 2014 13:58:26 -0700 (PDT) Hugh Dickins wrote:
>
> [PATCH next] vfs: initialize m_list to fix crash in mnt_set_mountpoint
>
> Fix mnt_set_mountpoint() crash: new_mountpoint() must initialize m_list.
>
> Reported-by: Felipe Balbi
> Signed-off-by: Hugh Dickins
I assume that this is a fix for commit 89f7ca1af15b ("vfs: Keep a list
of mounts on a mount point") that is currently i the vfs tree. I will
apply this patch as a fix up for the vfs tree in linux-next today.
--
Cheers,
Stephen Rothwell
signature.asc
Description: PGP signature
[PATCH] mfd: twl4030-power: Fix PM idle pin configuration to not conflict with regulators
Commit 43fef47f94a1 (mfd: twl4030-power: Add a configuration to turn
off oscillator during off-idle) added support for configuring the PMIC
to cut off resources during deeper idle states to save power.
This however caused regression for n900 display power that needed the
PMIC configuration to be disabled with commit d937678ab625 (ARM: dts:
Revert enabling of twl configuration for n900).
Turns out the root cause of the problem is that we must use
TWL4030_RESCONFIG_UNDEF instead of DEV_GRP_NULL to avoid disabling
regulators that may have been enabled before the init function
for twl4030-power.c runs. With TWL4030_RESCONFIG_UNDEF we let the
regulator framework control the regulators like it should. Here we
need to only configure the sys_clken and sys_off_mode triggers for
the regulators that cannot be done by the regulator framework as
it's not running at that point.
This allows us to enable the PMIC configuration for n900.
Fixes: 43fef47f94a1 (mfd: twl4030-power: Add a configuration to turn off
oscillator during off-idle)
Cc: sta...@vger.kernel.org # v3.16
Signed-off-by: Tony Lindgren
---
Lee, can you please pick this one for the v3.17-rc series?
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -361,7 +361,7 @@
};
twl_power: power {
- compatible = "ti,twl4030-power-n900";
+ compatible = "ti,twl4030-power-n900",
"ti,twl4030-power-idle-osc-off";
ti,use_poweroff;
};
};
--- a/drivers/mfd/twl4030-power.c
+++ b/drivers/mfd/twl4030-power.c
@@ -724,24 +724,24 @@ static struct twl4030_script *omap3_idle_scripts[] = {
* above.
*/
static struct twl4030_resconfig omap3_idle_rconfig[] = {
- TWL_REMAP_SLEEP(RES_VAUX1, DEV_GRP_NULL, 0, 0),
- TWL_REMAP_SLEEP(RES_VAUX2, DEV_GRP_NULL, 0, 0),
- TWL_REMAP_SLEEP(RES_VAUX3, DEV_GRP_NULL, 0, 0),
- TWL_REMAP_SLEEP(RES_VAUX4, DEV_GRP_NULL, 0, 0),
- TWL_REMAP_SLEEP(RES_VMMC1, DEV_GRP_NULL, 0, 0),
- TWL_REMAP_SLEEP(RES_VMMC2, DEV_GRP_NULL, 0, 0),
+ TWL_REMAP_SLEEP(RES_VAUX1, TWL4030_RESCONFIG_UNDEF, 0, 0),
+ TWL_REMAP_SLEEP(RES_VAUX2, TWL4030_RESCONFIG_UNDEF, 0, 0),
+ TWL_REMAP_SLEEP(RES_VAUX3, TWL4030_RESCONFIG_UNDEF, 0, 0),
+ TWL_REMAP_SLEEP(RES_VAUX4, TWL4030_RESCONFIG_UNDEF, 0, 0),
+ TWL_REMAP_SLEEP(RES_VMMC1, TWL4030_RESCONFIG_UNDEF, 0, 0),
+ TWL_REMAP_SLEEP(RES_VMMC2, TWL4030_RESCONFIG_UNDEF, 0, 0),
TWL_REMAP_OFF(RES_VPLL1, DEV_GRP_P1, 3, 1),
TWL_REMAP_SLEEP(RES_VPLL2, DEV_GRP_P1, 0, 0),
- TWL_REMAP_SLEEP(RES_VSIM, DEV_GRP_NULL, 0, 0),
- TWL_REMAP_SLEEP(RES_VDAC, DEV_GRP_NULL, 0, 0),
+ TWL_REMAP_SLEEP(RES_VSIM, TWL4030_RESCONFIG_UNDEF, 0, 0),
+ TWL_REMAP_SLEEP(RES_VDAC, TWL4030_RESCONFIG_UNDEF, 0, 0),
TWL_REMAP_SLEEP(RES_VINTANA1, TWL_DEV_GRP_P123, 1, 2),
TWL_REMAP_SLEEP(RES_VINTANA2, TWL_DEV_GRP_P123, 0, 2),
TWL_REMAP_SLEEP(RES_VINTDIG, TWL_DEV_GRP_P123, 1, 2),
TWL_REMAP_SLEEP(RES_VIO, TWL_DEV_GRP_P123, 2, 2),
TWL_REMAP_OFF(RES_VDD1, DEV_GRP_P1, 4, 1),
TWL_REMAP_OFF(RES_VDD2, DEV_GRP_P1, 3, 1),
- TWL_REMAP_SLEEP(RES_VUSB_1V5, DEV_GRP_NULL, 0, 0),
- TWL_REMAP_SLEEP(RES_VUSB_1V8, DEV_GRP_NULL, 0, 0),
+ TWL_REMAP_SLEEP(RES_VUSB_1V5, TWL4030_RESCONFIG_UNDEF, 0, 0),
+ TWL_REMAP_SLEEP(RES_VUSB_1V8, TWL4030_RESCONFIG_UNDEF, 0, 0),
TWL_REMAP_SLEEP(RES_VUSB_3V1, TWL_DEV_GRP_P123, 0, 0),
/* Resource #20 USB charge pump skipped */
TWL_REMAP_SLEEP(RES_REGEN, TWL_DEV_GRP_P123, 2, 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 1/7] dmaengine: edma: fix two faults which happen with the 8250_dma user
On Fri, Aug 08, 2014 at 06:29:50PM +0200, Sebastian Andrzej Siewior wrote: > * Vinod Koul | 2014-07-31 17:47:02 [+0530]: > > >On Tue, Jul 29, 2014 at 08:58:58PM +0200, Sebastian Andrzej Siewior wrote: > >> The rx path of the 8250_dma user in the RX-timeout case: > >> - it starts the RX transfer > >> - if the rx-timeout interrupt occures, it dmaengine_pause() the transfer > >> - step two is dmaengine_terminate_all() on this channel. > >Okay after this whole channel needs to be reset, which means all the > >descriptors are discared. > > >> To make the upper case work better, this patch adds dma_cookie_complete() > >> to complete the cookie. Also it adds is an additional check for > >> echan->edesc > >> in case the channel has no descriptor assigned. > >I think we are fixing the behvaiour rather than cause. terminate_all(() > >needs to do a proper cleanup of the channel > > In case you are not ignoring me but $reason here is an example that does > not work (with both drivers); Sorry This seems to have slipped thru, wasn't intentional! > > desc = dmaengine_prep_slave_single(rxchan, …); > rx_cookie = dmaengine_submit(desc); > dma_async_issue_pending(rxchan); > > ssleep(2); > /* Now assume that the transfer did not start */ > st = dmaengine_tx_status(rxchan, rx_cookie, NULL); > /* st is now DMA_IN_PROGRESS as expected */ > > dmaengine_terminate_all(rxchan); > st = dmaengine_tx_status(rxchan, rx_cookie, NULL); and here is the culprit. You have terminated the channel. This means that dmaengine driver is free to clean up all the allocated descriptors on the channels and do whatever it decides to do with them. You have already terminated the channel so what is the point in querying the status of the cookie, which you shouldn't use anyway after invoking terminate_all() as its result is not correct. > /* st is still DMA_IN_PROGRESS but _I_ expect DMA_COMPLETE because > * it has been terminated / canceled > */ > > Both dma driver clean up all / terminate all descriptors as required but > _none_ of them completes the cookie. As a result dma_cookie_status() > still thinks that the transfer is in progress. Btw how does it matter in the driver here if the transaction completed or not after terminate_all() was invoked. What is the purpose of querying status. Thanks -- ~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: Lock Directory failure
On Wed, 20 Aug 2014, Stephen Rothwell wrote:
> On Mon, 18 Aug 2014 13:58:26 -0700 (PDT) Hugh Dickins
> wrote:
> >
> > [PATCH next] vfs: initialize m_list to fix crash in mnt_set_mountpoint
> >
> > Fix mnt_set_mountpoint() crash: new_mountpoint() must initialize m_list.
> >
> > Reported-by: Felipe Balbi
> > Signed-off-by: Hugh Dickins
>
> I assume that this is a fix for commit 89f7ca1af15b ("vfs: Keep a list
> of mounts on a mount point") that is currently i the vfs tree. I will
> apply this patch as a fix up for the vfs tree in linux-next today.
Yes, that's it: thanks a lot, Stephen, that will help everybody.
I should acknowledge that Thierry Reding posted the same fix (a few
lines away) before mine, but I only came across his later in the day.
Hugh
--
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 5/7] net: cpsw: Add am33xx MACID readout
On Tuesday 19 August 2014 02:20 PM, Markus Pargmann wrote:
> Hi,
>
> On Tue, Aug 19, 2014 at 12:50:59AM +0200, Javier Martinez Canillas wrote:
>> Hello Mugunthan,
>>
>> On Mon, Aug 18, 2014 at 9:58 PM, Mugunthan V N wrote:
Thus, for this patchset, as is:
Tested-by: Steven Rostedt
>>> This will fail for DRA7xx not in AM33xx
>>>
>> cpsw_am33xx_cm_get_macid() checks for
>> of_machine_is_compatible("ti,am33xx") and returns 0 if the machine is
>> not an am33xx. cpsw_probe_dt() only propagates the return value if is
>> not 0 so this patch does not change the semantics for other SoCs
>> besides am33xx.
> Yes, this patch is only about the am33xx. I don't have the DRA7xx
> hardware so I am not able to test on that hardware. Mugunthan, perhaps
> you can supply some followup patches for DRA7xx.
>
>
I will check on this thursday and update.
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
Re: [RFC PATCH 3/4] tty: omap-serial: use threaded interrupt handler
On Tue, Aug 19, 2014 at 02:14:47PM +0200, Frans Klaver wrote:
> At 3.6Mbaud, with slightly over 2Mbit/s data coming in, we see 1600 uart
> rx buffer overflows within 30 seconds. Threading the interrupt handling
> reduces
> this to about 170 overflows in 10 minutes.
Can you try Sebastian Siewior's patches for 8250_omap and 8250 dma
support ? That should help you a lot.
> In practice this therefore reduces the need for hardware flow control,
> meaning the sending side doesn't have to buffer as much either.
>
> Signed-off-by: Frans Klaver
> ---
> drivers/tty/serial/omap-serial.c | 31 ---
> 1 file changed, 24 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/tty/serial/omap-serial.c
> b/drivers/tty/serial/omap-serial.c
> index 14a0167..57664b9 100644
> --- a/drivers/tty/serial/omap-serial.c
> +++ b/drivers/tty/serial/omap-serial.c
> @@ -575,6 +575,21 @@ static void serial_omap_rdi(struct uart_omap_port *up,
> unsigned int lsr)
> }
>
> /**
> + * serial_omap_fast_irq() - schedule interrupt handling
> + */
> +static irqreturn_t serial_omap_fast_irq(int irq, void *dev_id)
> +{
> + struct uart_omap_port *up = dev_id;
> + unsigned int iir = serial_in(up, UART_IIR);
> +
> + if (iir & UART_IIR_NO_INT)
> + return IRQ_NONE;
> +
> + disable_irq_nosync(up->port.irq);
NAK. Either use IRQF_ONESHOT or actually mask the IRQs at the device's
registers (basically clearing IER).
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v2 3/8] ASoC: davinci-evm: HDMI audio support for TDA998x trough McASP I2S bus
On 08/19/2014 04:16 PM, Mark Rutland wrote: On Mon, Aug 18, 2014 at 10:46:41PM +0100, Jyri Sarha wrote: Add machine driver support for BeagleBone-Black HDMI audio. BBB has NXP TDA998X HDMI transmitter connected to McASP port in I2S mode. The 44100 Hz sample-rate and it's multiples can not be accurately produced on BBB. The only supported sample format is SNDRV_PCM_FORMAT_S32_LE. The 8 least significant bits are ignored. Signed-off-by: Jyri Sarha --- .../bindings/sound/davinci-evm-audio.txt |4 +- sound/soc/davinci/davinci-evm.c| 82 +++- 2 files changed, 83 insertions(+), 3 deletions(-) diff --git a/Documentation/devicetree/bindings/sound/davinci-evm-audio.txt b/Documentation/devicetree/bindings/sound/davinci-evm-audio.txt index 963e100..c137436 100644 --- a/Documentation/devicetree/bindings/sound/davinci-evm-audio.txt +++ b/Documentation/devicetree/bindings/sound/davinci-evm-audio.txt @@ -1,7 +1,9 @@ * Texas Instruments SoC audio setups with TLV320AIC3X Codec Required properties: -- compatible : "ti,da830-evm-audio" : forDM365/DA8xx/OMAPL1x/AM33xx +- compatible : "ti,da830-evm-audio" : for DM365/DA8xx/OMAPL1x/AM33xx + "ti,am335x-beaglebone-black-audio" : for Beaglebone-black HDMI +audio To keep this legible I'd recommend reorganising this like: - compatible: should contain one of: * "ti,da830-evm-audio" for DM365/DA8xx/OMAPL1x/AM33xx * "ti,am335x-beaglebone-black-audio" for Beaglebone-black HDMI audio The above looks indeed better. I'll make the change. Oh, and I probably should change the first line to something like: * TI SoC audio using McASP to connect to TLV320AIC3X or HDMI endcoder For the BBB case, do you expect both strings or just the BBB-specific string? Normally just the one. In theory a BBB with an audio-cape on top could utilize another sound node with "ti,da830-evm-audio" compatible property. Is the 'x' in the BBB string a wildcard? If we know the particular number for BBB we should use that. Yes, its a wild card. BBBs have been made at least with AM3358 and AM3359 SoCs. Thanks, Jyri -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mfd: twl4030-power: Fix PM idle pin configuration to not conflict with regulators
Hi, On Tue, Aug 19, 2014 at 08:24:05AM -0700, Tony Lindgren wrote: > Commit 43fef47f94a1 (mfd: twl4030-power: Add a configuration to turn > off oscillator during off-idle) added support for configuring the PMIC > to cut off resources during deeper idle states to save power. [...] > Fixes: 43fef47f94a1 (mfd: twl4030-power: Add a configuration to turn off > oscillator during off-idle) > Cc: sta...@vger.kernel.org # v3.16 > Signed-off-by: Tony Lindgren Tested-by: Aaro Koskinen A. -- 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 3/4] tty: omap-serial: use threaded interrupt handler
On Tue, Aug 19, 2014 at 01:57:02PM -0500, Felipe Balbi wrote:
> On Tue, Aug 19, 2014 at 02:14:47PM +0200, Frans Klaver wrote:
> > At 3.6Mbaud, with slightly over 2Mbit/s data coming in, we see 1600 uart
> > rx buffer overflows within 30 seconds. Threading the interrupt handling
> > reduces
> > this to about 170 overflows in 10 minutes.
>
> Can you try Sebastian Siewior's patches for 8250_omap and 8250 dma
> support ? That should help you a lot.
I'll have a look at that series. Thanks for pointing it out.
> > drivers/tty/serial/omap-serial.c | 31 ---
> > 1 file changed, 24 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/tty/serial/omap-serial.c
> > b/drivers/tty/serial/omap-serial.c
> > index 14a0167..57664b9 100644
> > --- a/drivers/tty/serial/omap-serial.c
> > +++ b/drivers/tty/serial/omap-serial.c
> > @@ -575,6 +575,21 @@ static void serial_omap_rdi(struct uart_omap_port *up,
> > unsigned int lsr)
> > }
> >
> > /**
> > + * serial_omap_fast_irq() - schedule interrupt handling
> > + */
> > +static irqreturn_t serial_omap_fast_irq(int irq, void *dev_id)
> > +{
> > + struct uart_omap_port *up = dev_id;
> > + unsigned int iir = serial_in(up, UART_IIR);
> > +
> > + if (iir & UART_IIR_NO_INT)
> > + return IRQ_NONE;
> > +
> > + disable_irq_nosync(up->port.irq);
>
> NAK. Either use IRQF_ONESHOT or actually mask the IRQs at the device's
> registers (basically clearing IER).
Given the work that's been done on the 8250 based driver, what are the
short-term chances omap-serial will be dropped? I'd be happy to improve
here if it makes sense to do so. If the 8250 based driver is going to
replace omap-serial anyway on the short term, I don't see the point of
further developing this patch. The others would still make sense in my
opinion.
Thanks,
Frans
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
