Re: [PATCH] regulator: axp20x: Get rid of AXP20X_xxx_START/END/STEPS defines

On 27-02-2019 21:05, Mark Brown wrote: > On Wed, Feb 27, 2019 at 08:41:46PM +0100, Olliver Schinagl wrote: >> On 25-02-2019 18:25, Mark Brown wrote: >>> If you find you need to describe what the fields are it would be much >>> more constructive to add a comment at the t

Re: [PATCH] regulator: axp20x: Get rid of AXP20X_xxx_START/END/STEPS defines

On 25-02-2019 18:25, Mark Brown wrote: > On Sat, Feb 23, 2019 at 09:37:01PM +0100, Olliver Schinagl wrote: > >> In any case, you seem like a smart person that reads and writes hex and >> bits often enough. This is not true for everyone. I can just as easily >> reverse

Re: [PATCH] regulator: axp20x: Get rid of AXP20X_xxx_START/END/STEPS defines

On 23-02-2019 13:54, Axel Lin wrote: >> I will not disagree that it may be extra work to look up the define >> (especially if there is no tool tip or split view in the editor) but >> reading the whole lot of code, with only the magic values, you still >> have to look up the meaning of each magic

Re: [PATCH] regulator: axp20x: Get rid of AXP20X_xxx_START/END/STEPS defines

On 21-02-2019 10:42, Mark Brown wrote: > On Thu, Feb 21, 2019 at 08:22:53AM +0800, Axel Lin wrote: >> Olliver Schinagl 於 2019年2月21日 週四 上午6:57寫道： >>> On February 20, 2019 5:50:13 PM GMT+01:00, Axel Lin >>> wrote: >>>> The AXP20X_xxx_START/END/S

Re: [PATCH] regulator: axp20x: Get rid of AXP20X_xxx_START/END/STEPS defines

Hey Axel, On February 20, 2019 5:50:13 PM GMT+01:00, Axel Lin wrote: >The AXP20X_xxx_START/END/STEPS defines make the code hard to read and >very hard to check the linear range settings because it needs to check >the defines one-by-one. >The original code without the defines is very good in

Re: [linux-sunxi] [PATCH v3 00/12] ASoC: Add I2S support for Allwinner H3 SoCs

Hey Marcus, On 29-07-17 16:17, codekip...@gmail.com wrote: From: Marcus Cooper Hi All, please find attached a series of patches to bring i2s support to the Allwinner H3 SoC. This has been tested with the following setups: A20 Olimex EVB connected to a pcm5102 But

Re: [linux-sunxi] [PATCH v3 00/12] ASoC: Add I2S support for Allwinner H3 SoCs

Hey Marcus, On 29-07-17 16:17, codekip...@gmail.com wrote: From: Marcus Cooper Hi All, please find attached a series of patches to bring i2s support to the Allwinner H3 SoC. This has been tested with the following setups: A20 Olimex EVB connected to a pcm5102 But that's not an H3 is it? :)

Re: [linux-sunxi] [PATCH v5 2/6] clk: sunxi-ng: Add sun4i/sun7i CCU driver

Hey Priit, On 07/13/17 21:23, Priit Laes wrote: > On Mon, Jul 10, 2017 at 11:45:32AM +0200, Olliver Schinagl wrote: >> Hi Pleas, >> >> again, but this time with content :) >> >> On 04-07-17 22:04, Priit Laes wrote: >>> Introduce a clock controller dri

Re: [linux-sunxi] [PATCH v5 2/6] clk: sunxi-ng: Add sun4i/sun7i CCU driver

Hey Priit, On 07/13/17 21:23, Priit Laes wrote: > On Mon, Jul 10, 2017 at 11:45:32AM +0200, Olliver Schinagl wrote: >> Hi Pleas, >> >> again, but this time with content :) >> >> On 04-07-17 22:04, Priit Laes wrote: >>> Introduce a clock controller dri

Re: [linux-sunxi] [PATCH v3] drm/sun4i: Implement drm_driver lastclose to restore fbdev console

Hey Jonathan, since I reported this to you on IRC, it's only fair that you can have my: Tested-by: Olliver Schinagl <oli...@schinagl.nl> For those interessted, I've tested it on an Olimex OLinuXino Lime2 with their 4.3 LCD. Olliver On 10-07-17 08:55, Jonathan Liu wrote: The drm_

Re: [linux-sunxi] [PATCH v3] drm/sun4i: Implement drm_driver lastclose to restore fbdev console

Hey Jonathan, since I reported this to you on IRC, it's only fair that you can have my: Tested-by: Olliver Schinagl For those interessted, I've tested it on an Olimex OLinuXino Lime2 with their 4.3 LCD. Olliver On 10-07-17 08:55, Jonathan Liu wrote: The drm_driver lastclose callback

Re: [linux-sunxi] [PATCH v5 5/6] ARM: sun7i: Convert to CCU

Hi Maxime, On 10-07-17 13:55, Maxime Ripard wrote: On Mon, Jul 10, 2017 at 01:23:51PM +0200, Olliver Schinagl wrote: Hi Pleas, On 04-07-17 22:05, Priit Laes wrote: Convert sun7i-a20.dtsi to new CCU driver. Tested on Cubietruck. Signed-off-by: Priit Laes <pl...@plaes.org> --- arch/ar

Re: [linux-sunxi] [PATCH v5 5/6] ARM: sun7i: Convert to CCU

Hi Maxime, On 10-07-17 13:55, Maxime Ripard wrote: On Mon, Jul 10, 2017 at 01:23:51PM +0200, Olliver Schinagl wrote: Hi Pleas, On 04-07-17 22:05, Priit Laes wrote: Convert sun7i-a20.dtsi to new CCU driver. Tested on Cubietruck. Signed-off-by: Priit Laes --- arch/arm/boot/dts/sun7i-a20

Re: [linux-sunxi] [PATCH v5 6/6] ARM: sun4i: Convert to CCU

Hi Pritt, On 04-07-17 22:05, Priit Laes wrote: Convert sun4i-a10.dtsi to new CCU driver. Tested on Gemei G9 tablet. Signed-off-by: Priit Laes --- arch/arm/boot/dts/sun4i-a10.dtsi | 646 +++- 1 file changed, 73 insertions(+), 573 deletions(-)

Re: [linux-sunxi] [PATCH v5 6/6] ARM: sun4i: Convert to CCU

Hi Pritt, On 04-07-17 22:05, Priit Laes wrote: Convert sun4i-a10.dtsi to new CCU driver. Tested on Gemei G9 tablet. Signed-off-by: Priit Laes --- arch/arm/boot/dts/sun4i-a10.dtsi | 646 +++- 1 file changed, 73 insertions(+), 573 deletions(-) diff --git

Re: [linux-sunxi] [PATCH v5 5/6] ARM: sun7i: Convert to CCU

Hi Pleas, On 04-07-17 22:05, Priit Laes wrote: Convert sun7i-a20.dtsi to new CCU driver. Tested on Cubietruck. Signed-off-by: Priit Laes --- arch/arm/boot/dts/sun7i-a20.dtsi | 719 +++- 1 file changed, 84 insertions(+), 635 deletions(-) diff

Re: [linux-sunxi] [PATCH v5 5/6] ARM: sun7i: Convert to CCU

Hi Pleas, On 04-07-17 22:05, Priit Laes wrote: Convert sun7i-a20.dtsi to new CCU driver. Tested on Cubietruck. Signed-off-by: Priit Laes --- arch/arm/boot/dts/sun7i-a20.dtsi | 719 +++- 1 file changed, 84 insertions(+), 635 deletions(-) diff --git

Re: [linux-sunxi] [PATCH v5 2/6] clk: sunxi-ng: Add sun4i/sun7i CCU driver

Hi Pleas, again, but this time with content :) On 04-07-17 22:04, Priit Laes wrote: Introduce a clock controller driver for sun4i A10 and sun7i A20 series SoCs. Signed-off-by: Priit Laes --- drivers/clk/sunxi-ng/Kconfig | 14 +- drivers/clk/sunxi-ng/Makefile

Re: [linux-sunxi] [PATCH v5 2/6] clk: sunxi-ng: Add sun4i/sun7i CCU driver

Hi Pleas, again, but this time with content :) On 04-07-17 22:04, Priit Laes wrote: Introduce a clock controller driver for sun4i A10 and sun7i A20 series SoCs. Signed-off-by: Priit Laes --- drivers/clk/sunxi-ng/Kconfig | 14 +- drivers/clk/sunxi-ng/Makefile |

Re: [linux-sunxi] [PATCH v5 1/6] clk: sunxi-ng: div: Add support for fixed post-divider

Hey Plaes, On 04-07-17 22:04, Priit Laes wrote: SATA clock on sun4i/sun7i is of type (parent) / M / 6 where 6 is fixed post-divider. Signed-off-by: Priit Laes --- drivers/clk/sunxi-ng/ccu_div.c | 18 -- drivers/clk/sunxi-ng/ccu_div.h | 3 ++- 2 files

Re: [linux-sunxi] [PATCH v5 1/6] clk: sunxi-ng: div: Add support for fixed post-divider

Hey Plaes, On 04-07-17 22:04, Priit Laes wrote: SATA clock on sun4i/sun7i is of type (parent) / M / 6 where 6 is fixed post-divider. Signed-off-by: Priit Laes --- drivers/clk/sunxi-ng/ccu_div.c | 18 -- drivers/clk/sunxi-ng/ccu_div.h | 3 ++- 2 files changed, 18

Re: [linux-sunxi] Designware UART bug

Hey Tim, On 04-05-17 05:51, Tim Kryger wrote: On Wed, May 3, 2017 at 8:40 AM, Olliver Schinagl <oli...@schinagl.nl> wrote: Hey Tim, Ok, so as far as I understand (from the datasheet) the intended way to do this would be to check for the BUSY IRQ & USR[0] IRQ and if it is busy,

Re: [linux-sunxi] Designware UART bug

Hey Tim, On 04-05-17 05:51, Tim Kryger wrote: On Wed, May 3, 2017 at 8:40 AM, Olliver Schinagl wrote: Hey Tim, Ok, so as far as I understand (from the datasheet) the intended way to do this would be to check for the BUSY IRQ & USR[0] IRQ and if it is busy, (re-write) the LCR. We no lo

Re: [linux-sunxi] Designware UART bug

Hey Tim, On 03-05-17 16:22, Tim Kryger wrote: On Wed, May 3, 2017 at 4:26 AM, Olliver Schinagl <oli...@schinagl.nl> wrote: Hey Chen-Yu On 03-05-17 12:40, Chen-Yu Tsai wrote: On Wed, May 3, 2017 at 6:17 PM, Olliver Schinagl <oli...@schinagl.nl> wrote: Hey Jamie, Several y

Re: [linux-sunxi] Designware UART bug

Hey Tim, On 03-05-17 16:22, Tim Kryger wrote: On Wed, May 3, 2017 at 4:26 AM, Olliver Schinagl wrote: Hey Chen-Yu On 03-05-17 12:40, Chen-Yu Tsai wrote: On Wed, May 3, 2017 at 6:17 PM, Olliver Schinagl wrote: Hey Jamie, Several years ago you wrote the glue-code [0] for the DW 8250 IP

Re: [linux-sunxi] Designware UART bug

Hey Chen-Yu On 03-05-17 12:40, Chen-Yu Tsai wrote: On Wed, May 3, 2017 at 6:17 PM, Olliver Schinagl <oli...@schinagl.nl> wrote: Hey Jamie, Several years ago you wrote the glue-code [0] for the DW 8250 IP. Over the years various 'fixes' have been applied to resolve certain 'weird' pr

Re: [linux-sunxi] Designware UART bug

Hey Chen-Yu On 03-05-17 12:40, Chen-Yu Tsai wrote: On Wed, May 3, 2017 at 6:17 PM, Olliver Schinagl wrote: Hey Jamie, Several years ago you wrote the glue-code [0] for the DW 8250 IP. Over the years various 'fixes' have been applied to resolve certain 'weird' problems that Tim tried to fix

Designware UART bug

Hey Jamie, Several years ago you wrote the glue-code [0] for the DW 8250 IP. Over the years various 'fixes' have been applied to resolve certain 'weird' problems that Tim tried to fix with [1]. After going over the datasheets and code with a comb several times now, I think I may have found

Designware UART bug

Hey Jamie, Several years ago you wrote the glue-code [0] for the DW 8250 IP. Over the years various 'fixes' have been applied to resolve certain 'weird' problems that Tim tried to fix with [1]. After going over the datasheets and code with a comb several times now, I think I may have found

Re: [PATCH] serial: Do not treat the IIR register as a bitfield

Hey Andy, On 30-03-17 11:56, Andy Shevchenko wrote: On Wed, 2017-03-29 at 20:44 +0200, Olliver Schinagl wrote: It seems that at some point, someone made the assumption that the UART Interrupt ID Register was a bitfield and started to check if certain bits where set. Actually however

Re: [PATCH] serial: Do not treat the IIR register as a bitfield

Hey Andy, On 30-03-17 11:56, Andy Shevchenko wrote: On Wed, 2017-03-29 at 20:44 +0200, Olliver Schinagl wrote: It seems that at some point, someone made the assumption that the UART Interrupt ID Register was a bitfield and started to check if certain bits where set. Actually however

Re: [PATCH] serial: tegra: Map the iir register to default defines

orry for the inconvenience, Olliver -Original Message- From: Laxman Dewangan Sent: Thursday, March 30, 2017 3:48 PM To: Olliver Schinagl <oli...@schinagl.nl>; Greg Kroah-Hartman <gre...@linuxfoundation.org>; Jiri Slaby <jsl...@suse.com>; Stephen Warren <swar..

Re: [PATCH] serial: tegra: Map the iir register to default defines

orry for the inconvenience, Olliver -Original Message- From: Laxman Dewangan Sent: Thursday, March 30, 2017 3:48 PM To: Olliver Schinagl ; Greg Kroah-Hartman ; Jiri Slaby ; Stephen Warren ; Thierry Reding ; Alexandre Courbot Cc: linux-ser...@vger.kernel.org; linux-te...@vger.kernel

Re: [PATCH] serial: Do not treat the IIR register as a bitfield

Hey Ted, On 30-03-17 16:11, Theodore Ts'o wrote: While you're fixing this, there's a bug in samples/vfio-mdev/mtty.c: u8 ier = mdev_state->s[index].uart_reg[UART_IER]; *buf = 0; mutex_lock(_state->rxtx_lock); /* Interrupt

Re: [PATCH] serial: Do not treat the IIR register as a bitfield

Hey Ted, On 30-03-17 16:11, Theodore Ts'o wrote: While you're fixing this, there's a bug in samples/vfio-mdev/mtty.c: u8 ier = mdev_state->s[index].uart_reg[UART_IER]; *buf = 0; mutex_lock(_state->rxtx_lock); /* Interrupt

Re: [PATCH] serial: Do not treat the IIR register as a bitfield

Hey Vignesh, On March 30, 2017 9:57:19 AM CEST, Vignesh R <vigne...@ti.com> wrote: > > >On Thursday 30 March 2017 12:13 PM, Olliver Schinagl wrote: >> >> >> On March 30, 2017 8:15:29 AM CEST, Vignesh R <vigne...@ti.com> wrote: >>> Hi, >>>

Re: [PATCH] serial: Do not treat the IIR register as a bitfield

Hey Vignesh, On March 30, 2017 9:57:19 AM CEST, Vignesh R wrote: > > >On Thursday 30 March 2017 12:13 PM, Olliver Schinagl wrote: >> >> >> On March 30, 2017 8:15:29 AM CEST, Vignesh R wrote: >>> Hi, >>> >>> On Thursday 30 March 2017 12:14

Re: [PATCH] serial: tegra: Map the iir register to default defines

Hey Jon, On March 30, 2017 3:42:19 PM CEST, Jon Hunter <jonath...@nvidia.com> wrote: > >On 29/03/17 19:48, Olliver Schinagl wrote: >> The tegra serial IP seems to be following the common layout and the >> interrupt ID's match up nicely. Replace the magic values to match

Re: [PATCH] serial: tegra: Map the iir register to default defines

Hey Jon, On March 30, 2017 3:42:19 PM CEST, Jon Hunter wrote: > >On 29/03/17 19:48, Olliver Schinagl wrote: >> The tegra serial IP seems to be following the common layout and the >> interrupt ID's match up nicely. Replace the magic values to match the >> c

Re: [PATCH] serial: Do not treat the IIR register as a bitfield

On March 30, 2017 8:15:29 AM CEST, Vignesh R <vigne...@ti.com> wrote: >Hi, > >On Thursday 30 March 2017 12:14 AM, Olliver Schinagl wrote: >> diff --git a/include/uapi/linux/serial_reg.h >b/include/uapi/linux/serial_reg.h >> index 5db76880b4ad..489522389a10 1006

Re: [PATCH] serial: Do not treat the IIR register as a bitfield

On March 30, 2017 8:15:29 AM CEST, Vignesh R wrote: >Hi, > >On Thursday 30 March 2017 12:14 AM, Olliver Schinagl wrote: >> diff --git a/include/uapi/linux/serial_reg.h >b/include/uapi/linux/serial_reg.h >> index 5db76880b4ad..489522389a10 100644 >> --- a/include/ua

[PATCH] serial: tegra: Map the iir register to default defines

The tegra serial IP seems to be following the common layout and the interrupt ID's match up nicely. Replace the magic values to match the common serial_reg defines, with the addition of the Tegra unique End of Data interrupt. Signed-off-by: Olliver Schinagl <oli...@schinagl.nl> --- Not

[PATCH] serial: tegra: Map the iir register to default defines

The tegra serial IP seems to be following the common layout and the interrupt ID's match up nicely. Replace the magic values to match the common serial_reg defines, with the addition of the Tegra unique End of Data interrupt. Signed-off-by: Olliver Schinagl --- Note I do not own any tegra

[PATCH] serial: Do not treat the IIR register as a bitfield

bits. This patch then goes over all UART_IIR_* users and changes the code from bitfield checking, to ID checking instead. Signed-off-by: Olliver Schinagl <oli...@schinagl.nl> --- Note, that I do not have all this hardware and used the fact that UART_IIR_* yields ID's rather then bitfields an

[PATCH] serial: Do not treat the IIR register as a bitfield

bits. This patch then goes over all UART_IIR_* users and changes the code from bitfield checking, to ID checking instead. Signed-off-by: Olliver Schinagl --- Note, that I do not have all this hardware and used the fact that UART_IIR_* yields ID's rather then bitfields and thus mentioned as above

[PATCHv2] serial: 8250_dw: Minor code cleanup

Some very minor code cleanups, such as including the bitops header for DW_UART_MCR_SIRE, use the BIT() macro as suggested by checkpatch and removed a white space to match other invocations. Signed-off-by: Olliver Schinagl <oli...@schinagl.nl> --- Changes since v1: Split up these no

[PATCHv2] serial: 8250_dw: Minor code cleanup

Some very minor code cleanups, such as including the bitops header for DW_UART_MCR_SIRE, use the BIT() macro as suggested by checkpatch and removed a white space to match other invocations. Signed-off-by: Olliver Schinagl --- Changes since v1: Split up these non-code changing changes

Re: [PATCH] serial: 8250_dw: Minor code cleanup

Hey Doug, On 29-03-17 19:10, Olliver Schinagl wrote: Hey Doug, On 29-03-17 17:50, Doug Anderson wrote: Hi, On Wed, Mar 29, 2017 at 3:04 AM, Olliver Schinagl <oli...@schinagl.nl> wrote: Commit 424d79183af0 ("serial: 8250_dw: Avoid "too much work" from bogus rx timeout in

Re: [PATCH] serial: 8250_dw: Minor code cleanup

Hey Doug, On 29-03-17 19:10, Olliver Schinagl wrote: Hey Doug, On 29-03-17 17:50, Doug Anderson wrote: Hi, On Wed, Mar 29, 2017 at 3:04 AM, Olliver Schinagl wrote: Commit 424d79183af0 ("serial: 8250_dw: Avoid "too much work" from bogus rx timeout interrupt") added a

Re: [PATCH] serial: 8250_dw: Minor code cleanup

Hey Doug, On 29-03-17 17:50, Doug Anderson wrote: Hi, On Wed, Mar 29, 2017 at 3:04 AM, Olliver Schinagl <oli...@schinagl.nl> wrote: Commit 424d79183af0 ("serial: 8250_dw: Avoid "too much work" from bogus rx timeout interrupt") added a bit check with quite

Re: [PATCH] serial: 8250_dw: Minor code cleanup

Hey Doug, On 29-03-17 17:50, Doug Anderson wrote: Hi, On Wed, Mar 29, 2017 at 3:04 AM, Olliver Schinagl wrote: Commit 424d79183af0 ("serial: 8250_dw: Avoid "too much work" from bogus rx timeout interrupt") added a bit check with quite a wide mask. To be concise with the

[PATCH] serial: 8250_dw: Minor code cleanup

ic value/mask. Some very minor code cleanups, such as including the bitops header for DW_UART_MCR_SIRE, use the BIT() macro as suggested by checkpatc and removed a whitespace to match other invocations. Signed-off-by: Olliver Schinagl <oli...@schinagl.nl> --- drivers/tty/

[PATCH] serial: 8250_dw: Minor code cleanup

ic value/mask. Some very minor code cleanups, such as including the bitops header for DW_UART_MCR_SIRE, use the BIT() macro as suggested by checkpatc and removed a whitespace to match other invocations. Signed-off-by: Olliver Schinagl --- drivers/tty/serial/8250/8250_dw.c | 25 +

Re: [PATCH v2] serial: 8250_dw: Avoid "too much work" from bogus rx timeout interrupt

Hey Andy, On 29-03-17 11:11, Andy Shevchenko wrote: On Wed, Mar 29, 2017 at 10:58 AM, Olliver Schinagl <oli...@schinagl.nl> wrote: On 07-02-17 00:30, Douglas Anderson wrote: First of all I didn't get why people from Cc list are suddenly disappeared. Check your mail client settings. Ret

Re: [PATCH v2] serial: 8250_dw: Avoid "too much work" from bogus rx timeout interrupt

Hey Andy, On 29-03-17 11:11, Andy Shevchenko wrote: On Wed, Mar 29, 2017 at 10:58 AM, Olliver Schinagl wrote: On 07-02-17 00:30, Douglas Anderson wrote: First of all I didn't get why people from Cc list are suddenly disappeared. Check your mail client settings. Returning back some of them

Re: [PATCH v2] serial: 8250_dw: Avoid "too much work" from bogus rx timeout interrupt

Hey Douglas, On 07-02-17 00:30, Douglas Anderson wrote: On a Rockchip rk3399-based board during suspend/resume testing, we found that we could get the console UART into a state where it would print this to the console a lot: serial8250: too much work for irq42 Followed eventually by: NMI

Re: [PATCH v2] serial: 8250_dw: Avoid "too much work" from bogus rx timeout interrupt

Hey Douglas, On 07-02-17 00:30, Douglas Anderson wrote: On a Rockchip rk3399-based board during suspend/resume testing, we found that we could get the console UART into a state where it would print this to the console a lot: serial8250: too much work for irq42 Followed eventually by: NMI

Re: How to handle quirky behavior with boards.

properly according to its parameters? Olliver On 01-03-17 14:58, Olliver Schinagl wrote: Hey all, We found a bug in the design of a board that we use. This board (Olimex OLinuXino Lime2) features a PMIC (AXP209) and has an LDO, LDO3, that needs special treatment. The bug

Re: How to handle quirky behavior with boards.

properly according to its parameters? Olliver On 01-03-17 14:58, Olliver Schinagl wrote: Hey all, We found a bug in the design of a board that we use. This board (Olimex OLinuXino Lime2) features a PMIC (AXP209) and has an LDO, LDO3, that needs special treatment. The bug

How to handle quirky behavior with boards.

Hey all, We found a bug in the design of a board that we use. This board (Olimex OLinuXino Lime2) features a PMIC (AXP209) and has an LDO, LDO3, that needs special treatment. The bug is, that there is too much capacitance on the output of LDO3, which causes the PMIC to shutdown when

How to handle quirky behavior with boards.

Hey all, We found a bug in the design of a board that we use. This board (Olimex OLinuXino Lime2) features a PMIC (AXP209) and has an LDO, LDO3, that needs special treatment. The bug is, that there is too much capacitance on the output of LDO3, which causes the PMIC to shutdown when

Re: [PATCH] pwm: sunxi: wait for the READY bit

Hey Alexandre, Sorry for the very slow reply. We just bought a house so have been offline for 6+ weeks! On 03-01-17 17:44, Alexandre Belloni wrote: On 03/01/2017 at 16:56:16 +0100, Olliver Schinagl wrote : Hey Alexandre, I've sent several patches regarding pwm a while ago, sadly you never

Re: [PATCH] pwm: sunxi: wait for the READY bit

Hey Alexandre, Sorry for the very slow reply. We just bought a house so have been offline for 6+ weeks! On 03-01-17 17:44, Alexandre Belloni wrote: On 03/01/2017 at 16:56:16 +0100, Olliver Schinagl wrote : Hey Alexandre, I've sent several patches regarding pwm a while ago, sadly you never

Re: [PATCH] pwm: sunxi: wait for the READY bit

Hey Alexandre, I've sent several patches regarding pwm a while ago, sadly you never responded [0]. So I guess this is a follow up from that? I couldn't quickly find the resubmitted version however. Anyway, see below for my comments. On 03-01-17 15:57, Alexandre Belloni wrote: Most of the

Re: [PATCH] pwm: sunxi: wait for the READY bit

Hey Alexandre, I've sent several patches regarding pwm a while ago, sadly you never responded [0]. So I guess this is a follow up from that? I couldn't quickly find the resubmitted version however. Anyway, see below for my comments. On 03-01-17 15:57, Alexandre Belloni wrote: Most of the

Re: [PATCH 1/2] pwm: sunxi: allow the pwm to finish its pulse before disable

Hey Maxime, Happy new year! I'm sorry that I missed your previous mail! I completely looked over it. Sorry! On 12-12-16 13:24, Maxime Ripard wrote: On Thu, Dec 08, 2016 at 02:23:39PM +0100, Olliver Schinagl wrote: Hey Maxime, first off, also sorry for the slow delay :) (pun not intended

Re: [PATCH 1/2] pwm: sunxi: allow the pwm to finish its pulse before disable

Hey Maxime, Happy new year! I'm sorry that I missed your previous mail! I completely looked over it. Sorry! On 12-12-16 13:24, Maxime Ripard wrote: On Thu, Dec 08, 2016 at 02:23:39PM +0100, Olliver Schinagl wrote: Hey Maxime, first off, also sorry for the slow delay :) (pun not intended

Re: [PATCH 1/2] pwm: sunxi: allow the pwm to finish its pulse before disable

On za, 2016-09-24 at 22:25 +0200, Maxime Ripard wrote: > Hi Oliver, > > Sorry for the slow answer. > > On Fri, Sep 09, 2016 at 11:01:08AM +0200, Olliver Schinagl wrote: > > > > > > > > > > > > > > > > > > > >

Re: [PATCH 1/2] pwm: sunxi: allow the pwm to finish its pulse before disable

On za, 2016-09-24 at 22:25 +0200, Maxime Ripard wrote: > Hi Oliver, > > Sorry for the slow answer. > > On Fri, Sep 09, 2016 at 11:01:08AM +0200, Olliver Schinagl wrote: > > > > > > > > > > > > > > > > > > > >

Re: [1/2] pwm: sunxi: allow the pwm to finish its pulse before disable

period is considered to much, it may be contemplated to use a half period + a little bit to ensure we get passed the transition. Signed-off-by: Olliver Schinagl <oli...@schinagl.nl> --- drivers/pwm/pwm-sun4i.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/drivers/pwm/p

Re: [1/2] pwm: sunxi: allow the pwm to finish its pulse before disable

, it may be contemplated to use a half period + a little bit to ensure we get passed the transition. Signed-off-by: Olliver Schinagl --- drivers/pwm/pwm-sun4i.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/drivers/pwm/pwm-sun4i.c b/drivers/pwm/pwm-sun4i.c index 03a99a5

Re: [PATCH 1/2] pwm: sunxi: allow the pwm to finish its pulse before disable

On di, 2016-09-06 at 21:51 +0200, Maxime Ripard wrote: > On Tue, Sep 06, 2016 at 09:12:56AM +0200, Olliver Schinagl wrote: > > > > Hi Maxime!, > > > > On za, 2016-08-27 at 00:19 +0200, Maxime Ripard wrote: > > > > > > On Thu, Aug 25, 201

Re: [PATCH 1/2] pwm: sunxi: allow the pwm to finish its pulse before disable

On di, 2016-09-06 at 21:51 +0200, Maxime Ripard wrote: > On Tue, Sep 06, 2016 at 09:12:56AM +0200, Olliver Schinagl wrote: > > > > Hi Maxime!, > > > > On za, 2016-08-27 at 00:19 +0200, Maxime Ripard wrote: > > > > > > On Thu, Aug 25, 201

Re: [PATCH] leds-pca963x: add bindings to invert polarity

Hi Anders, On ma, 2016-09-05 at 13:02 +0200, Anders Darander wrote: > Hi, > > * Olliver Schinagl <oli...@schinagl.nl> [160504 10:10]: > > > > On 04-05-16 09:55, Anders Darander wrote: > > > > > > * Jacek Anaszewski <j.anaszew...@samsung.c

Re: [PATCH] leds-pca963x: add bindings to invert polarity

Hi Anders, On ma, 2016-09-05 at 13:02 +0200, Anders Darander wrote: > Hi, > > * Olliver Schinagl [160504 10:10]: > > > > On 04-05-16 09:55, Anders Darander wrote: > > > > > > * Jacek Anaszewski [160504 09:28]: > > > > > > >

Re: [PATCH 1/2] pwm: sunxi: allow the pwm to finish its pulse before disable

Hi Maxime!, On za, 2016-08-27 at 00:19 +0200, Maxime Ripard wrote: > On Thu, Aug 25, 2016 at 07:50:10PM +0200, Olliver Schinagl wrote: > > > > When we inform the PWM block to stop toggeling the output, we may > > end up > > in a state where the output is no

Re: [PATCH 1/2] pwm: sunxi: allow the pwm to finish its pulse before disable

Hi Maxime!, On za, 2016-08-27 at 00:19 +0200, Maxime Ripard wrote: > On Thu, Aug 25, 2016 at 07:50:10PM +0200, Olliver Schinagl wrote: > > > > When we inform the PWM block to stop toggeling the output, we may > > end up > > in a state where the output is no

[PATCH 1/1] pwm: core: use bitops's BIT macro

Checkpatch warns about not using the BIT() macro. Replace 1 << bit with BIT(). Signed-off-by: Olliver Schinagl <oli...@schinagl.nl> --- Hi Thierry, I submitted this patch a year ago and you said you didn't much care for it. After a year however, have you changed your mind? I notice i

[PATCH 1/1] pwm: core: use bitops's BIT macro

Checkpatch warns about not using the BIT() macro. Replace 1 << bit with BIT(). Signed-off-by: Olliver Schinagl --- Hi Thierry, I submitted this patch a year ago and you said you didn't much care for it. After a year however, have you changed your mind? I notice it's becoming mandatory i

[PATCH 2/2] pwm: sunxi: Yield some time to the pwm-block to become ready

From: Olliver Schinagl <o.schin...@ultimaker.com> The pwm-block of some of the sunxi chips feature a 'ready' flag to indicate the software that it is ready for new commands. Right now, when we call pwm_config and set the period, we write the values to the registers, and turn off the

[PATCHv2 0/2] pwm: sunxi: give the pwm IP block more time

(of one bus clock cycle?) is overkill. Changes since v1: - Split patch series into several smaller patch series - Added driver author Olliver Schinagl (2): pwm: sunxi: allow the pwm to finish its pulse before disable pwm: sunxi: Yield some time to the pwm-block to become ready

[PATCH 1/2] pwm: sunxi: allow the pwm to finish its pulse before disable

the transition. Signed-off-by: Olliver Schinagl <oli...@schinagl.nl> --- drivers/pwm/pwm-sun4i.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/drivers/pwm/pwm-sun4i.c b/drivers/pwm/pwm-sun4i.c index 03a99a5..5e97c8a 100644 --- a/drivers/pwm/pwm-sun4i.c +++ b/drivers/pwm/pwm-sun4i.c @

[PATCH 2/2] pwm: sunxi: Yield some time to the pwm-block to become ready

From: Olliver Schinagl The pwm-block of some of the sunxi chips feature a 'ready' flag to indicate the software that it is ready for new commands. Right now, when we call pwm_config and set the period, we write the values to the registers, and turn off the clock to the IP. Because

[PATCHv2 0/2] pwm: sunxi: give the pwm IP block more time

(of one bus clock cycle?) is overkill. Changes since v1: - Split patch series into several smaller patch series - Added driver author Olliver Schinagl (2): pwm: sunxi: allow the pwm to finish its pulse before disable pwm: sunxi: Yield some time to the pwm-block to become ready

[PATCH 1/2] pwm: sunxi: allow the pwm to finish its pulse before disable

the transition. Signed-off-by: Olliver Schinagl --- drivers/pwm/pwm-sun4i.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/drivers/pwm/pwm-sun4i.c b/drivers/pwm/pwm-sun4i.c index 03a99a5..5e97c8a 100644 --- a/drivers/pwm/pwm-sun4i.c +++ b/drivers/pwm/pwm-sun4i.c @@ -8,6 +8,7 @@ #include

[PATCHv2] pwm: lpc-18xx: use pwm_set_chip_data

The lpc18xx driver currently manipulates the pwm_device struct directly rather then using the pwm_set_chip_data. While the current method may save a clock cycle or two, it is more obvious that data is set to the local chip data pointer. Signed-off-by: Olliver Schinagl <oli...@schinagl.nl>

[PATCHv2] pwm: lpc-18xx: use pwm_set_chip_data

The lpc18xx driver currently manipulates the pwm_device struct directly rather then using the pwm_set_chip_data. While the current method may save a clock cycle or two, it is more obvious that data is set to the local chip data pointer. Signed-off-by: Olliver Schinagl --- Hi, This is a resend

Re: [PATCH 1/1] ARM: dts: sunxi: Add a olinuxino-lime2-emmc

On 15-07-16 10:39, stefan.mavrod...@gmail.com wrote: Hi Olliver, Why are you using nRST signal? What I mean is this pin is inactive on this eMMC chip. To use the signal byte 162 of ECSD registers should be written. Then that sounds like a bug in the mmc layer I would say (or a missing

Re: [PATCH 1/1] ARM: dts: sunxi: Add a olinuxino-lime2-emmc

On 15-07-16 10:39, stefan.mavrod...@gmail.com wrote: Hi Olliver, Why are you using nRST signal? What I mean is this pin is inactive on this eMMC chip. To use the signal byte 162 of ECSD registers should be written. Then that sounds like a bug in the mmc layer I would say (or a missing

[PATCH 1/1] devicetree: sunxi: Add OLinuXino Lime2 eMMC to the Makefile

commit 27dd9af6bc000ab21fd ("ARM: dts: sunxi: Add a olinuxino-lime2-emmc") added the new emmc equipped lime2 but forgot its Makefile. This patch adds an entry to the Makefile. Signed-off-by: Olliver Schinagl <oli...@schinagl.nl> --- Changes since v1: Added proper commit

[PATCH 1/1] devicetree: sunxi: Add OLinuXino Lime2 eMMC to the Makefile

commit 27dd9af6bc000ab21fd ("ARM: dts: sunxi: Add a olinuxino-lime2-emmc") added the new emmc equipped lime2 but forgot its Makefile. This patch adds an entry to the Makefile. Signed-off-by: Olliver Schinagl --- Changes since v1: Added proper commit reference (again). Change

Re: [PATCHv2] devicetree: sunxi: Add OLinuXino Lime2 eMMC to the Makefile

and now i'm embarrassed and ashamed. Teaches me not to rush things, right? i'll correct it and take some time to do it right. sorry maxime! On 13-05-16 09:48, Maxime Ripard wrote: Hi Olliver, On Thu, May 12, 2016 at 12:10:51PM +0200, Olliver Schinagl wrote: commit 27dd9af6bc (ARM: dts: sunxi

Re: [PATCHv2] devicetree: sunxi: Add OLinuXino Lime2 eMMC to the Makefile

and now i'm embarrassed and ashamed. Teaches me not to rush things, right? i'll correct it and take some time to do it right. sorry maxime! On 13-05-16 09:48, Maxime Ripard wrote: Hi Olliver, On Thu, May 12, 2016 at 12:10:51PM +0200, Olliver Schinagl wrote: commit 27dd9af6bc (ARM: dts: sunxi

[PATCHv2] devicetree: sunxi: Add OLinuXino Lime2 eMMC to the Makefile

commit 27dd9af6bc (ARM: dts: sunxi: Add a olinuxino-lime2-emmc added the new emmc equipped) lime2 but forgot its Makefile. This patch adds an entry to the Makefile. Signed-off-by: Olliver Schinagl <oli...@schinagl.nl> --- Changes since v0: Added proper commit reference. arch/arm/bo

[PATCHv2] devicetree: sunxi: Add OLinuXino Lime2 eMMC to the Makefile

commit 27dd9af6bc (ARM: dts: sunxi: Add a olinuxino-lime2-emmc added the new emmc equipped) lime2 but forgot its Makefile. This patch adds an entry to the Makefile. Signed-off-by: Olliver Schinagl --- Changes since v0: Added proper commit reference. arch/arm/boot/dts/Makefile | 1 + 1 file

Re: [PATCHv1 0/6] leds: pca9653x: support inverted outputs and cleanups

will review this yesterday, but I did not have the time , sorry Regards! On 22 Apr 2016 09:21, "Olliver Schinagl"<oli...@schinagl.nl> wrote: Hi Ricardo, On 20-04-16 11:17, Ricardo Ribalda Delgado wrote: Hello again On Wed, Apr 20, 2016 at 11:06 AM, Olliver Schinagl<oli...@

Re: [PATCHv1 0/6] leds: pca9653x: support inverted outputs and cleanups

I did not have the time , sorry Regards! On 22 Apr 2016 09:21, "Olliver Schinagl" wrote: Hi Ricardo, On 20-04-16 11:17, Ricardo Ribalda Delgado wrote: Hello again On Wed, Apr 20, 2016 at 11:06 AM, Olliver Schinagl wrote: The devil is in the details :) :) Saving mode2 sounds like a

Re: [PATCHv1 0/6] leds: pca9653x: support inverted outputs and cleanups

will review this yesterday, but I did not have the time , sorry Regards! On 22 Apr 2016 09:21, "Olliver Schinagl" <oli...@schinagl.nl> wrote: Hi Ricardo, On 20-04-16 11:17, Ricardo Ribalda Delgado wrote: Hello again On Wed, Apr 20, 2016 at 11:06 AM, Olliver Schinagl <oli...@

Re: [PATCHv1 0/6] leds: pca9653x: support inverted outputs and cleanups

I did not have the time , sorry Regards! On 22 Apr 2016 09:21, "Olliver Schinagl" wrote: Hi Ricardo, On 20-04-16 11:17, Ricardo Ribalda Delgado wrote: Hello again On Wed, Apr 20, 2016 at 11:06 AM, Olliver Schinagl wrote: The devil is in the details :) :) Saving mode2 sounds like a

[PATCH 1/1] devicetree: sunxi: Add OLinuXino Lime2 eMMC to the Makefile

ARM: dts: sunxi: Add a olinuxino-lime2-emmc added the new emmc equipped lime2 but forgot its Makefile. This patch adds an entry to the Makefile. Signed-off-by: Olliver Schinagl <oli...@schinagl.nl> --- Hi list, would it be possible to squash or atleast add this patch with/to my previous

  1   2   3   4   >