Hello,
On Mon, Mar 19, 2018 at 11:52:02AM +0100, Uwe Kleine-König wrote:
> Given that irq_to_desc() is a radix_tree_lookup and the reverse
> operation is only a pointer dereference and that all callers of
> __free_irq already have the desc, pass the desc instead of the irq
> number.
Hello Thomas,
On Mon, Mar 26, 2018 at 11:43:27AM +0200, Thomas Gleixner wrote:
> On Mon, 26 Mar 2018, Uwe Kleine-König wrote:
> >
> > On Mon, Mar 19, 2018 at 11:52:02AM +0100, Uwe Kleine-König wrote:
> > > Given that irq_to_desc() is a radix_tree_lookup and the reverse
&
and me.
Acked-by: Sascha Hauer
Signed-off-by: Uwe Kleine-König
---
Hello,
I'm not sure how feels responsible to apply such a patch. Maybe akpm?
Best regards
Uwe
MAINTAINERS | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
"simulate" level sensitive
irqs if the hardware only implements edge logic (which affects
armada-37xx, too, which annoys me).
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
Hello Michal,
On Thu, Nov 22, 2018 at 04:46:39PM +, Vokáč Michal wrote:
> On 22.11.2018 17:23, Uwe Kleine-König wrote:
> > On Thu, Nov 22, 2018 at 03:42:14PM +, Vokáč Michal wrote:
> >> On 16.11.2018 09:25, Uwe Kleine-König wrote:
> >>> On Fri, Nov 16, 20
_CYGNUS
This looks good. As pointed out before the default is a bit strange
and could include ARCH_BCM_MOBILE for symmetry.
Anyhow:
Acked-by: Uwe Kleine-König
Related to this driver I have a set of questions: If the disable
callback completed, does the hardware still drive the pin? If yes, wou
+ b/drivers/tty/serial/imx.c
> @@ -2068,7 +2068,7 @@ imx_uart_console_setup(struct console *co, char
> *options)
>
> retval = clk_prepare(sport->clk_per);
> if (retval)
> - clk_disable_unprepare(sport->clk_ipg);
> + clk_unprepare(spo
t;
I doubt this is right. imx_uart_console_setup is called once, and
if the console is on (say) ttymxc0 you don't want to unprepare the
clocks if ttymxc3 gets unbound.
So I think this cleanup must go into imx_uart_exit().
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
Hello Clément,
On Fri, Nov 23, 2018 at 10:31:18AM +0100, Clément Péron wrote:
> On Thu, 22 Nov 2018 at 21:05, Uwe Kleine-König
> wrote:
> > Related to this driver I have a set of questions: If the disable
> > callback completed, does the hardware still drive the pin? If ye
Hello Michal,
On Fri, Nov 23, 2018 at 03:15:11PM +, Vokáč Michal wrote:
> On 22.11.2018 20:03, Uwe Kleine-König wrote:
> > On Thu, Nov 22, 2018 at 04:46:39PM +, Vokáč Michal wrote:
> >> On 22.11.2018 17:23, Uwe Kleine-König wrote:
> >>> So I'd expect t
On Fri, Nov 23, 2018 at 04:59:46PM +0100, Bartosz Golaszewski wrote:
> śr., 21 lis 2018 o 20:15 Uwe Kleine-König
> napisał(a):
> >
> > Hello Bartosz,
> >
> > On Wed, Nov 21, 2018 at 05:34:32PM +0100, Bartosz Golaszewski wrote:
> > > wt., 20 lis 2018 o
Hallo Lothar,
On Mon, Nov 26, 2018 at 10:11:16AM +0100, Lothar Waßmann wrote:
> Uwe Kleine-König wrote:
> > @Lothar: if Michal did something different than you expected, please
> > tell us with a few more details.
>
> No, Michal's findings are in sync with what I c
Hello,
On Mon, Nov 26, 2018 at 10:31:58PM +0100, Uwe Kleine-König wrote:
> On Mon, Nov 26, 2018 at 12:23:19AM +0800, Hao Zhang wrote:
> > The sun8i R40/T3/V40 PWM has 8 PWM channals and divides to 4 PWM pairs,
> > each PWM pair built-in 1 clock module, 2 timer logic module and 1
&
er Schrempf
do we need to change the binding document accordingly?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
Hello,
On Tue, Nov 20, 2018 at 09:35:47AM +0100, Linus Walleij wrote:
> On Mon, Nov 19, 2018 at 9:32 AM Uwe Kleine-König
> wrote:
>
> > To sumarize: When the pwm driver probes it is not yet clear if the idle
> > state of the output pin is high or low. Even when the pinc
Hello Michal,
On Tue, Nov 20, 2018 at 01:14:33PM +, Vokáč Michal wrote:
> On 16.11.2018 10:51, Thierry Reding wrote:
> > On Thu, Nov 15, 2018 at 09:37:33PM +0100, Uwe Kleine-König wrote:
> >> On Thu, Nov 15, 2018 at 04:25:45PM +0100, Thierry Reding wrote:
> > My im
m_irq_ctx *irq = &sim->irqs[offset];
> +
> + if (irq->enabled && (irq->edge & edge)) {
> set_bit(offset, sim->work_ctx.pending);
> irq_work_queue(&sim->work_ctx.work);
> }
> }
> -EXPORT_SYMBOL_GP
Hello Bartosz,
On Wed, Nov 21, 2018 at 05:34:32PM +0100, Bartosz Golaszewski wrote:
> wt., 20 lis 2018 o 18:17 Uwe Kleine-König
> napisał(a):
> >
> > On Tue, Nov 20, 2018 at 02:40:31PM +0100, Bartosz Golaszewski wrote:
> > > From: Bartosz Golaszewski
> > &g
Hello Thierry,
On Thu, Nov 22, 2018 at 04:03:38PM +0100, Thierry Reding wrote:
> On Sun, Nov 18, 2018 at 09:08:15PM +0100, Uwe Kleine-König wrote:
> > Thinking a bit about this it doesn't really matter for the consumer if
> > the pin stays in the idle level because there is a
Hello Michal,
On Thu, Nov 22, 2018 at 03:42:14PM +, Vokáč Michal wrote:
> On 16.11.2018 09:25, Uwe Kleine-König wrote:
> > On Fri, Nov 16, 2018 at 08:34:30AM +0100, Lothar Waßmann wrote:
> > > No. You can disable the output driver via pinctrl, so that only the
> > &g
Hello Thierry,
On Wed, Nov 14, 2018 at 12:34:49PM +0100, Thierry Reding wrote:
> On Fri, Nov 09, 2018 at 05:55:55PM +0100, Uwe Kleine-König wrote:
> > On Fri, Nov 09, 2018 at 02:24:42PM +, Vokáč Michal wrote:
> > > On 8.11.2018 20:18, Uwe Kleine-König wrote:
> > >
Hello Thierry,
On Thu, Nov 15, 2018 at 04:25:45PM +0100, Thierry Reding wrote:
> On Wed, Nov 14, 2018 at 10:51:20PM +0100, Uwe Kleine-König wrote:
> > On Wed, Nov 14, 2018 at 12:34:49PM +0100, Thierry Reding wrote:
> > > On Fri, Nov 09, 2018 at 05:55:55PM +0100, Uwe Kleine-König
ework first and then make the driver use it.
The usual policy is: If the things specified in the dt are
wrong or incomplete, it's ok to fail however you like. So from a
correctness POV I think the change is fine.
I don't know about the mips details that John pointed out in a foll
On Fri, Nov 16, 2018 at 08:34:30AM +0100, Lothar Waßmann wrote:
> Uwe Kleine-König wrote:
>
> > Hello Thierry,
> >
> > On Thu, Nov 15, 2018 at 04:25:45PM +0100, Thierry Reding wrote:
> > > On Wed, Nov 14, 2018 at 10:51:20PM +0100, Uwe Kleine-König wrote:
>
Hello Thierry,
On Fri, Nov 16, 2018 at 10:51:24AM +0100, Thierry Reding wrote:
> On Thu, Nov 15, 2018 at 09:37:33PM +0100, Uwe Kleine-König wrote:
> > On Thu, Nov 15, 2018 at 04:25:45PM +0100, Thierry Reding wrote:
> > > On Wed, Nov 14, 2018 at 10:51:20PM +0100, Uwe Kleine-König
Hello Lothar,
On Fri, Nov 16, 2018 at 12:56:33PM +0100, Lothar Waßmann wrote:
> Uwe Kleine-König wrote:
> > On Fri, Nov 16, 2018 at 10:51:24AM +0100, Thierry Reding wrote:
> > > On Thu, Nov 15, 2018 at 09:37:33PM +0100, Uwe Kleine-König wrote:
> > > > On Thu, No
Hello Thierry,
On Fri, Nov 16, 2018 at 01:24:45PM +0100, Thierry Reding wrote:
> On Fri, Nov 16, 2018 at 11:39:29AM +0100, Uwe Kleine-König wrote:
> > On Fri, Nov 16, 2018 at 10:51:24AM +0100, Thierry Reding wrote:
> > > On Thu, Nov 15, 2018 at 09:37:33PM +0100, Uwe Kleine-König
red as part of its consumer this
is legitimate.
Thanks for your feedback.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
Hello,
On Sun, Nov 18, 2018 at 09:08:15PM +0100, Uwe Kleine-König wrote:
> On Fri, Nov 16, 2018 at 01:24:45PM +0100, Thierry Reding wrote:
> > On Fri, Nov 16, 2018 at 11:39:29AM +0100, Uwe Kleine-König wrote:
> > > Also note that you don't include the poor souls where the
Hello Phil,
On Mon, Nov 19, 2018 at 10:41:42AM +, Phil Edworthy wrote:
> On 16 November 2018 16:11 Uwe Kleine-König wrote:
> > On Fri, Nov 16, 2018 at 05:01:28PM +0100, Uwe Kleine-König wrote:
> > > Other than that I think the patch is fine
> >
> > Thinking a
Hello Phil,
On Mon, Nov 19, 2018 at 12:53:46PM +, Phil Edworthy wrote:
> On 19 November 2018 10:46 Uwe Kleine-König wrote:
> > On Mon, Nov 19, 2018 at 10:41:42AM +, Phil Edworthy wrote:
> > > btw, do we need to add of_clk_get_by_name_optional()? I only added it
> &g
atch as is. Just the motiviation is wrong
and I'd do both: Modify the mockup driver to start with direction=input
and modify the tests to not expect this.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
get_optional(struct device *dev, const char *id)
that return NULL instead of ERR_PTR(-ENODEV).
Then the above would simplify to:
pc->clks[i] = devm_clk_get_optional(&pdev->dev, mtk_pwm_clk_name[i]);
if (IS_ERR(pc->clks[i]) {
if (PTR_ERR(pc->clks[i]) == -EPROBE_DEFER)
dev_err(...);
return PTR_ERR(pc->clks[i]);
}
(added the clk people to Cc for this question).
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
Optional properties" to match what
is implemented in patch 1 of this series.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
Hello Michal,
On Fri, Nov 09, 2018 at 05:55:55PM +0100, Uwe Kleine-König wrote:
> On Fri, Nov 09, 2018 at 02:24:42PM +, Vokáč Michal wrote:
> > On 8.11.2018 20:18, Uwe Kleine-König wrote:
> > > On Thu, Nov 08, 2018 at 03:21:44PM +, Vokáč Michal wrote:
> > >
On Wed, Dec 05, 2018 at 01:19:54PM +0100, Linus Walleij wrote:
> On Mon, Dec 3, 2018 at 12:06 PM Uwe Kleine-König
> wrote:
> > On Mon, Dec 03, 2018 at 11:57:26AM +0100, Bartosz Golaszewski wrote:
>
> > > It used to live in the gpio-mockup driver and I generalized it
>
pwm_get_state(imx->chip.pwms, &cstate);
> + if (cstate.enabled) {
> + dev_dbg(&pdev->dev,
> + "PWM entered probe in enabled state\n");
> + pinctrl_select_state(imx->pinctrl,
> + imx->pinctrl_pins_pwm);
> + } else {
> + pinctrl_select_state(imx->pinctrl,
> + imx->pinctrl_pins_gpio);
> + }
> + }
> +
ISTR that there was a patch that implements get_state for imx. Is there
a dependency on that one? Otherwise the state returned by
pwm_get_state() might not be what is actually configured.
Do you know if this is required for the old i.MX pwm, e.g. on i.MX21?
I ask because of https://patchwork.ozlabs.org/patch/171/
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
On Thu, Dec 06, 2018 at 03:37:55PM +, Vokáč Michal wrote:
> On 6.12.2018 14:59, Uwe Kleine-König wrote:
> > On Thu, Dec 06, 2018 at 01:41:31PM +, Vokáč Michal wrote:
> >> +{
> >> + imx_chip->pinctrl = devm_pinctrl_get(&pdev->dev);
ions?
Just for the record: I objected the patch, Bartosz agrees to discuss
further and but because this is too much detail the patch should now be
applied anyhow to fix the test suite of an external project. This seems
wrong to me.
Best regards
Uwe
--
Pengutronix e.K.
On Mon, Dec 03, 2018 at 11:23:38AM +0100, Bartosz Golaszewski wrote:
> niedz., 2 gru 2018 o 23:20 Bartosz Golaszewski napisał(a):
> >
> > niedz., 2 gru 2018 o 22:56 Uwe Kleine-König
> > napisał(a):
> > >
> > > Hello,
> > >
> > > On Thu, No
On Mon, Dec 03, 2018 at 11:57:26AM +0100, Bartosz Golaszewski wrote:
> pon., 3 gru 2018 o 11:49 Uwe Kleine-König
> napisał(a):
> >
> > On Mon, Dec 03, 2018 at 11:23:38AM +0100, Bartosz Golaszewski wrote:
> > > niedz., 2 gru 2018 o 23:20 Bartosz Golaszewski napisał(a)
hip->irqsim, priv->offset);
> + edge = val == 0 ? IRQ_TYPE_EDGE_FALLING : IRQ_TYPE_EDGE_RISING;
> + irq_sim_fire_edge(&chip->irqsim, priv->offset, edge);
If I write 0 twice into the debugfs file, does it fire two irqs or only
one? I think it fires two but only one would be the right
7 Nov 2018 at 17:48, Scott Branden
> > > wrote:
> > > >
> > > >
> > > > On 2018-11-07 8:12 a.m., Uwe Kleine-König wrote:
> > > > > On Wed, Nov 07, 2018 at 10:36:12AM +0100, Clément Péron wrote:
> > > > >> The Cygnus ar
Hello Bartosz,
On Fri, Nov 09, 2018 at 12:13:44PM +0100, Bartosz Golaszewski wrote:
> czw., 8 lis 2018 o 21:35 Uwe Kleine-König
> napisał(a):
> > On Thu, Nov 08, 2018 at 05:52:53PM +0100, Bartosz Golaszewski wrote:
> > > Commit 3edfb7bd76bd ("gpiolib: Show
Hello,
On Fri, Nov 09, 2018 at 01:24:36PM +0100, Bartosz Golaszewski wrote:
> pt., 9 lis 2018 o 12:54 Uwe Kleine-König
> napisał(a):
> > On Fri, Nov 09, 2018 at 12:13:44PM +0100, Bartosz Golaszewski wrote:
> > > czw., 8 lis 2018 o 21:35 Uwe Kleine-König
> > > napi
On Fri, Nov 09, 2018 at 02:53:16PM +0100, Bartosz Golaszewski wrote:
> pt., 9 lis 2018 o 14:10 Uwe Kleine-König
> napisał(a):
> >
> > Hello,
> >
> > On Fri, Nov 09, 2018 at 01:24:36PM +0100, Bartosz Golaszewski wrote:
> > > pt., 9 lis 2018 o 12:54 Uwe Kle
On Fri, Nov 09, 2018 at 02:24:42PM +, Vokáč Michal wrote:
> On 8.11.2018 20:18, Uwe Kleine-König wrote:
> > On Thu, Nov 08, 2018 at 03:21:44PM +, Vokáč Michal wrote:
> >> Hi Uwe,
> >>
> >> On 7.11.2018 16:01, Uwe Kleine-König wrote:
> >>>&
Hello Bartosz,
On Fri, Nov 09, 2018 at 04:24:10PM +0100, Bartosz Golaszewski wrote:
> pt., 9 lis 2018 o 15:39 Uwe Kleine-König
> napisał(a):
> > On Fri, Nov 09, 2018 at 02:53:16PM +0100, Bartosz Golaszewski wrote:
> > > pt., 9 lis 2018 o 14:10 Uwe Kleine-König
> > &
On Fri, Nov 09, 2018 at 06:23:01PM +0100, Bartosz Golaszewski wrote:
> pt., 9 lis 2018 o 18:03 Uwe Kleine-König
> napisał(a):
> >
> > Hello Bartosz,
> >
> > On Fri, Nov 09, 2018 at 04:24:10PM +0100, Bartosz Golaszewski wrote:
> > > pt., 9 lis 2018 o
Hello,
On Mon, Jul 02, 2018 at 09:34:04AM +1000, Stephen Rothwell wrote:
> On Fri, 29 Jun 2018 09:38:58 +0200 Uwe Kleine-König
> wrote:
> >
> > On Thu, Jun 28, 2018 at 09:57:42AM +0200, Uwe Kleine-König wrote:
> > > Greg, you applied the initial patches creating drive
Hello Peter,
On Mon, Jun 25, 2018 at 02:51:05PM +0200, Peter Zijlstra wrote:
> On Mon, Jun 25, 2018 at 12:20:56PM +0200, Uwe Kleine-König wrote:
> > when I just boot without any other siox-related action. So the kthread
> > (created
> > in drivers/siox/siox-core.c:siox_
> Signed-off-by: Robin Gong
Looks wrong (because of tx_status vs rx_cookie), but is right
nevertheless I think:
Acked-by: Uwe Kleine-König
Thanks
Uwe
> ---
> drivers/tty/serial/imx.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/tty/serial
state TASK_IDLE
which doesn't trigger the above warning.
As siox_poll_thread() uses some variables of the device the
initialisation of these is moved before thread creation.
Acked-by: Peter Zijlstra (Intel)
Signed-off-by: Uwe Kleine-König
---
Hello,
this is the same patch as before wi
Hello Peter,
On Tue, Jun 26, 2018 at 09:38:41AM +0200, Peter Zijlstra wrote:
> On Mon, Jun 25, 2018 at 09:21:21PM +0200, Uwe Kleine-König wrote:
> > > I don't think so, that patch has an issue with INTERRUPTIBLE, but IDLE
> > > very much doesn't allow signals like
. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
Hello Greg,
Cc -= Peter Zijlstra
Cc += Stephen Rothwell
On Thu, Jun 28, 2018 at 09:57:42AM +0200, Uwe Kleine-König wrote:
> Greg, you applied the initial patches creating drivers/siox. I assume
> you will continue to apply siox patches and tell if I should search a
> different path for
adl(sport, UCR4);
> + ucr4 &= ~UCR4_OREN;
> + imx_uart_writel(sport, ucr4, UCR4);
Not sure this is necessary, but I assume it cannot hurt either, so
Acked-by: Uwe Kleine-König
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
On Thu, May 24, 2018 at 07:30:23PM +0200, Sebastian Reichel wrote:
> According to Documentation/serial/driver the shutdown function should
> not disable RTS, so drop it.
>
> Suggested-by: Uwe Kleine-König
Great idea! :-)
Acked-by: Uwe Kleine-König
--
Pen
Hello Tomas,
On 05/25/2018 12:08 AM, Tomas Hlavacek wrote:
> But I also have good news: The FW of the MCU is also OSS (see the repo
> in the link (1)). There is a method for flashing the MCU over I2C from
> Linux and there is JTAG connector for the MCU, in case un-bricking is
> needed. Therefore t
t me to change the patch, but to make this
explicit: My patch doesn't make this problem worse, so this would be an
orthogonal change and doesn't affect this one.
Spaces don't seem to be allowed in netdev names:
uwe@taurus:~$ sudo ip link set wlp3s0 name 'la la'
Error: argument "la la" is wrong: "name" not a valid ifname
(Didn't check if only ip forbids that, of if that is a kernel policy.) I
could rename my device to "lala[]" though.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
, I wish we had kernel in Rust, so we could have real units
> > attached to our variables...)
>
> Well, the variable itself could always be named "delay_ms" if it's really
> that important.
FTR: That's what I did for v3.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
*cur_msg = &ddata->msgs[ddata->current_msg];
>
> efm32_i2c_write32(ddata, REG_CMD, REG_CMD_START);
> - efm32_i2c_write32(ddata, REG_TXDATA, cur_msg->addr << 1 |
> - (cur_msg->flags & I2C_M_RD ? 1 : 0));
> + efm32_i2c_write32(ddat
On Mon, May 14, 2018 at 04:53:21PM +0200, Peter Rosin wrote:
> Because it looks neater.
> i2c_imx_dma_write and i2c_imx_write are always called with a
> write in msgs->flags, and i2c_imx_read with a read.
>
> Signed-off-by: Peter Rosin
Reviewed-by: Uwe Kleine-König
The type bits are part of the per-device status word. So it's natural to
consider an error in the type bits as a status error instead of only
resulting in an unsynced state.
Signed-off-by: Uwe Kleine-König
---
drivers/siox/siox-core.c | 20 ++--
1 file changed, 10 inser
mplete() and before
s/compleition/completion/
> wait_for_completion_timeout().
Is this a theoretical problem, or did it trigger on your side?
> Signed-off-by: Esben Haabendal
Fixes: ce1a78840ff7 ("i2c: imx: add DMA support for freescale i2c driver")
Reviewed-by: Uwe Kleine-
PTR_ERR(rinfo->scl_gpiod) == -EPROBE_DEFER) {
return -EPROBE_DEFER;
} else if (IS_ERR(rinfo->sda_gpiod) ||
IS_ERR(rinfo->scl_gpiod) ||
IS_ERR(i2c_imx->pinctrl_pins_default) ||
IS_ERR(i2c_imx->pinctrl_pins_gpio)) {
dev_dbg(&pdev->dev, "recovery information incomplete\n");
return 0;
}
So if a patch changes devm_gpiod_get() to return -EPROBE_DEFER in more
cases that doesn't seem to hurt. Moreover TTBOMK this driver should only
be used by dt-machines today such that changing gpio* for non-DT users
shouldn't affect it.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
ead, and no DMA request is generated
> to kickstart the DMA read, and a timeout happens after DMA_TIMEOUT (1 sec).
>
> Fixed by setting the DMAEN bit before the dummy read.
Does this fix the problem or just narrow the race window?
Best regards
Uwe
--
Pengutronix e.K.
On Tue, Jun 12, 2018 at 02:11:44PM +0200, Stefan Agner wrote:
> On 07.06.2018 09:56, Uwe Kleine-König wrote:
> > On Fri, Apr 20, 2018 at 02:44:07PM +0200, Stefan Agner wrote:
> >> To reset the UART the SRST needs be cleared (low active). According
> >> to the docume
e errors cause the stopped state to be left in
> incorrect state in i2c_imx_stop(), i2c_imx_dma_read(), i2c_imx_read() and
> i2c_imx_xfer().
>
> Signed-off-by: Esben Haabendal
Acked-by: Uwe Kleine-König
--
Pengutronix e.K. | Uwe Kleine-König
gs->len >= DMA_THRESHOLD && !block_data;
and then simplify the two conditions to just "use_dma".
With this changed you can add my Ack.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
e to me.
Acked-by: Uwe Kleine-König
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
e on Cc who might have mentioned a relevant keyword
once.
Thanks
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
er what output polarity is configured. Let's use
> + * pinctrl to switch the output pin to GPIO functon and keep
> + * the output at the same level as for duty-cycle = 0.
> + */
> + if (imx->pinctrl)
> + pinctrl_select_state(imx->pinctrl,
> + imx->pinctrl_pins_gpio);
> +
On thing I noticed while looking at the rcar driver is: This doesn't
wait for the current period to end. Is this supposed to happen? Also for
the enable case the hardware is configured for the desired duty cycle
and only then the pinctrl is switched to pwm. Both might result in a
spike that is not desired.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
Hello,
On Mon, Oct 01, 2018 at 04:19:48PM +0200, Michal Vokáč wrote:
> Implement the get_state() function and set the initial state to reflect
> real state of the hardware. This allows to keep the PWM running if it was
> enabled in bootloader. It is very similar to the GPIO behavior. GPIO pin
> se
On Mon, Oct 01, 2018 at 04:19:47PM +0200, Michal Vokáč wrote:
> Use existing macros to define register fields instead of manually shifting
> the bit masks. Also define some more register bits.
I didn't check, but wonder if these additional register bits are then
used in the next patch. Maybe I'd c
On Wed, Dec 12, 2018 at 11:42:17AM +, Vokáč Michal wrote:
> On 12.12.2018 09:01, Uwe Kleine-König wrote:
> > On Thu, Dec 06, 2018 at 01:41:31PM +, Vokáč Michal wrote:
> >> Normally the PWM output is held LOW when PWM is disabled. This can cause
> >> proble
.head.reference.commit.tree,
> > p)
> > else:
> > --
> > 2.19.1
> >
>
> It might be worth noting this fixes commit 6f4d29df66ac
> ("scripts/spdxcheck.py: make python3 compliant") and also Cc this for
> stable
or this patch or did you choose to ignore it?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
for v3) and v4 of the series criss-crossed. So the problem with the
peaks that could happen is still unaddressed.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
ent_res)
> + return -EINVAL;
> +
> jz4740->chip.dev = dev;
> jz4740->chip.ops = &jz4740_pwm_ops;
> jz4740->chip.npwm = NUM_PWM;
Thanks
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
; + clk_set_rate(clk, rate);
Maybe this could better live in a separate patch. If you split still
further to have the conversion to regmap in a single patch, then the
conversion to the clk_* functions and then improve the algorithm for the
clk settings each of the patches is easier to r
On Thu, Dec 13, 2018 at 10:10:52AM -0500, Jeremy Cline wrote:
> On Thu, Dec 13, 2018 at 08:37:08AM +0100, Uwe Kleine-König wrote:
> > It didn't break for me. Can you provide details about how and when it
> > broke for you?
>
> I was wrong about it being Python 2 th
Hello Thierry,
On Thu, Dec 13, 2018 at 06:00:00PM +0100, Thierry Reding wrote:
> On Thu, Dec 13, 2018 at 09:52:13AM +0100, Uwe Kleine-König wrote:
> > On Wed, Dec 12, 2018 at 11:54:32AM +0100, Thierry Reding wrote:
> > > On Mon, Oct 01, 2018 at 04:19:48PM +0200,
On Thu, Dec 13, 2018 at 02:58:31PM +0100, Paul Cercueil wrote:
> Hi,
>
> Le jeu. 13 déc. 2018 à 10:18, Uwe Kleine-König
> a écrit :
> > On Wed, Dec 12, 2018 at 11:09:07PM +0100, Paul Cercueil wrote:
> > > The TCU channels 0 and 1 were previously reserved for system t
[Adding Linus Walleij to Cc:]
Hello,
On Thu, Dec 13, 2018 at 03:03:15PM +0100, Paul Cercueil wrote:
> Le jeu. 13 déc. 2018 à 10:24, Uwe Kleine-König
> a écrit :
> > On Wed, Dec 12, 2018 at 11:09:10PM +0100, Paul Cercueil wrote:
> > > The PWM in the JZ4725B works the
;
> + reg = <0x0 0x10020000 0x0 0x1000>;
> + clocks = <&tlclk>;
> + interrupt-parent = <&plic>;
> + interrupts = <42 43 44 45>;
> + #pwm-cells = <2>;
> + sifive,approx-period = <100>;
> +};
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
wm_clock_notifier;
> + ret = clk_notifier_register(pwm->clk, &pwm->notifier);
> + if (ret) {
> + dev_err(dev, "failed to register clock notifier: %d\n", ret);
> + return ret;
> + }
> +
> + /* Initialize PWM config */
>
clocks = <&clks IMX6SL_CLK_PERCLK>,
><&clks IMX6SL_CLK_PWM1>;
> clock-names = "ipg", "per";
It's a bit irritating that IMX6SL_CLK_PERCLK is used for the "ipg" clk,
not
= "ipg", "per";
> >
> > It's a bit irritating that IMX6SL_CLK_PERCLK is used for the "ipg" clk, not
> > the
> > "per" clk. Is this correct?
>
> Yes, you can check the i.MX6SL CCM chapter for PWM clocks, the ipg_clk
Hello,
On Fri, Dec 14, 2018 at 02:50:20PM +0100, Linus Walleij wrote:
> On Thu, Dec 13, 2018 at 9:42 PM Uwe Kleine-König
> wrote:
> > [Adding Linus Walleij to Cc:]
> > On Thu, Dec 13, 2018 at 03:03:15PM +0100, Paul Cercueil wrote:
> > > Le jeu. 13 déc. 2018 à 10:24
Hello Paul,
On Sun, Dec 16, 2018 at 02:36:03PM +0100, Paul Cercueil wrote:
> Le jeu. 13 déc. 2018 à 21:32, Uwe Kleine-König
> a écrit :
> > On Thu, Dec 13, 2018 at 02:58:31PM +0100, Paul Cercueil wrote:
> > > Hi,
> > >
> > > Le jeu. 13 déc. 2018 à
On Sun, Dec 16, 2018 at 03:18:52PM +0100, Paul Cercueil wrote:
> Hi,
>
> Le ven. 14 déc. 2018 à 15:26, Uwe Kleine-König
> a écrit :
> > Hello,
> >
> > On Fri, Dec 14, 2018 at 02:50:20PM +0100, Linus Walleij wrote:
> > > On Thu, Dec 13, 2018 a
line here à la:
Fixes: 90ad2cbe88c2 ("i2c: imx: use clk notifier for rate changes")
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
On Fri, Dec 14, 2018 at 03:07:37PM +0100, Linus Walleij wrote:
> On Wed, Dec 5, 2018 at 2:20 PM Uwe Kleine-König
> wrote:
> > On Wed, Dec 05, 2018 at 01:19:54PM +0100, Linus Walleij wrote:
>
> > > > The iio testing driver only needs the trigger and relies on an irq
On Mon, Dec 17, 2018 at 11:32:45AM +0100, Bartosz Golaszewski wrote:
> śr., 5 gru 2018 o 13:38 Bartosz Golaszewski
> napisał(a):
> >
> > śr., 5 gru 2018 o 13:20 Linus Walleij napisał(a):
> > >
> > > On Mon, Dec 3, 2018 at 12:06 PM Uwe Kleine-König
> > &g
On Mon, Dec 10, 2018 at 11:15:05AM +, Vokáč Michal wrote:
> On 6.12.2018 17:16, Uwe Kleine-König wrote:
> > On Thu, Dec 06, 2018 at 03:37:55PM +, Vokáč Michal wrote:
> >> On 6.12.2018 14:59, Uwe Kleine-König wrote:
> >>> On Thu, Dec 06, 2018 at 01:41:
Hello Bartosz,
On Mon, Dec 03, 2018 at 12:09:16PM +0100, Uwe Kleine-König wrote:
> On Tue, Nov 20, 2018 at 02:40:32PM +0100, Bartosz Golaszewski wrote:
> > @@ -213,7 +213,8 @@ static ssize_t gpio_mockup_event_write(struct file
> > *file,
> >
On Thu, Dec 20, 2018 at 06:39:04PM +0100, Thierry Reding wrote:
> On Mon, Dec 17, 2018 at 08:53:21AM +0100, Uwe Kleine-König wrote:
> > On Sun, Dec 16, 2018 at 03:18:52PM +0100, Paul Cercueil wrote:
> > > Hi,
> > >
> > > Le ven. 14 déc. 2018 à 15
TCU_TCSR_PWM_SD, TCU_TCSR_PWM_SD);
I think I already pointed that out before: abrupt mode is wrong. If
.apply is called with a new set of parameters the currently running
period with the old values is expected to complete before the new values
take effect.
Best regards
Uwe
--
Pengutronix e.K
201 - 300 of 1828 matches
Mail list logo
