Re: [PATCH 1/8] drm/mediatek: Use regmap for register access

s + addr) & ~value; > - writel_relaxed(reg, config_regs + addr); > + regmap_read(config_regs, addr, ); > + reg &= ~value; > + regmap_write(config_regs, addr, reg); regmap_update_bits(config_regs, addr, value, 0); Reviewed-by: Philipp Zabel <p.za...@pengutronix.de> regards Philipp

Re: [PATCH 1/8] drm/mediatek: Use regmap for register access

~value; > - writel_relaxed(reg, config_regs + addr); > + regmap_read(config_regs, addr, ); > + reg &= ~value; > + regmap_write(config_regs, addr, reg); regmap_update_bits(config_regs, addr, value, 0); Reviewed-by: Philipp Zabel regards Philipp

Re: [PATCH] media: coda: fix comparision of decoded frames' indexes

Hi Martin, On Fri, 2017-11-17 at 15:30 +0100, Martin Kepplinger wrote: > At this point the driver looks the currently decoded frame's index > and compares is to VPU-specific state values. Directly before this > if and else statements the indexes are read (index for decoded and > for displayed

Re: [PATCH] media: coda: fix comparision of decoded frames' indexes

Hi Martin, On Fri, 2017-11-17 at 15:30 +0100, Martin Kepplinger wrote: > At this point the driver looks the currently decoded frame's index > and compares is to VPU-specific state values. Directly before this > if and else statements the indexes are read (index for decoded and > for displayed

Re: [PATCH 4/9] ARM: dts: am335x-pepper: Fix the audio CODEC's reset pin

On Wed, 2017-11-08 at 15:25 -0600, Andrew F. Davis wrote: > The correct DT property for specifying a GPIO used for reset > is "reset-gpio", fix this here. > > Fixes: 4341881d0562 ("ARM: dts: Add devicetree for Gumstix Pepper board") > > Signed-off-by: Andrew F. Davis > --- >

Re: [PATCH 4/9] ARM: dts: am335x-pepper: Fix the audio CODEC's reset pin

On Wed, 2017-11-08 at 15:25 -0600, Andrew F. Davis wrote: > The correct DT property for specifying a GPIO used for reset > is "reset-gpio", fix this here. > > Fixes: 4341881d0562 ("ARM: dts: Add devicetree for Gumstix Pepper board") > > Signed-off-by: Andrew F. Davis > --- >

Re: [PATCH 1/9] ASoC: tlv320aic31xx: Fix typo in DT binding documentation

Hi Andrew, On Wed, 2017-11-08 at 15:24 -0600, Andrew F. Davis wrote: > The property used to specify a GPIO intended for reset is "reset-gpio", > this binding uses "gpio-reset", as almost all other bindings use the > former name this use of the latter is certainly not intended and > was a typo. It

Re: [PATCH 1/9] ASoC: tlv320aic31xx: Fix typo in DT binding documentation

Hi Andrew, On Wed, 2017-11-08 at 15:24 -0600, Andrew F. Davis wrote: > The property used to specify a GPIO intended for reset is "reset-gpio", > this binding uses "gpio-reset", as almost all other bindings use the > former name this use of the latter is certainly not intended and > was a typo. It

Re: [PATCH] media: coda: remove definition of CODA_STD_MJPG

_MJPG 3 > #define CODA9_STD_MPEG4 3 > > #define CODA_CMD_ENC_SEQ_SRC_SIZE0x190 Thanks, Acked-by: Philipp Zabel <p.za...@pengutronix.de> regards Philipp

Re: [PATCH] media: coda: remove definition of CODA_STD_MJPG

3 > #define CODA9_STD_MPEG4 3 > > #define CODA_CMD_ENC_SEQ_SRC_SIZE0x190 Thanks, Acked-by: Philipp Zabel regards Philipp

Re: [PATCH] media: coda: Fix definition of CODA_STD_MJPG

Hi Martin, thank you for the patch. I'd prefer to just drop CODA_STD_MJPG altogether, to avoid confusion. Explanation below: On Wed, 2017-11-08 at 15:12 +0100, Martin Kepplinger wrote: > According to i.MX 6 VPU API Reference Manual Rev. L3.0.35_1.1.0, 01/2013 > chapter 3.2.1.5, the MJPG video

Re: [PATCH] media: coda: Fix definition of CODA_STD_MJPG

Hi Martin, thank you for the patch. I'd prefer to just drop CODA_STD_MJPG altogether, to avoid confusion. Explanation below: On Wed, 2017-11-08 at 15:12 +0100, Martin Kepplinger wrote: > According to i.MX 6 VPU API Reference Manual Rev. L3.0.35_1.1.0, 01/2013 > chapter 3.2.1.5, the MJPG video

[PATCH] rtc: pcf8563: fix output clock rate

The pcf8563_clkout_recalc_rate function erroneously ignores the frequency index read from the CLKO register and always returns 32768 Hz. Signed-off-by: Philipp Zabel <p.za...@pengutronix.de> --- drivers/rtc/rtc-pcf8563.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/d

[PATCH] rtc: pcf8563: fix output clock rate

The pcf8563_clkout_recalc_rate function erroneously ignores the frequency index read from the CLKO register and always returns 32768 Hz. Signed-off-by: Philipp Zabel --- drivers/rtc/rtc-pcf8563.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/rtc/rtc-pcf8563.c b

Re: [PATCH v7 1/4] reset: Add APIs to manage array of resets

Hi Bjorn, On Wed, 2017-11-01 at 15:24 -0700, Bjorn Andersson wrote: [...] > > > This looks more or less identical to how regulators and clocks already > > > deals with resources in bulk; see regulator_bulk_data and clk_bulk_data > > > and their associated functions. > > > > > > I would really

Re: [PATCH v7 1/4] reset: Add APIs to manage array of resets

Hi Bjorn, On Wed, 2017-11-01 at 15:24 -0700, Bjorn Andersson wrote: [...] > > > This looks more or less identical to how regulators and clocks already > > > deals with resources in bulk; see regulator_bulk_data and clk_bulk_data > > > and their associated functions. > > > > > > I would really

[PATCH] serial: imx: add hibernation support

. Signed-off-by: Philipp Zabel <p.za...@pengutronix.de> --- drivers/tty/serial/imx.c | 28 1 file changed, 28 insertions(+) diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c index dfeff3951f934..6bbe7dd58ac62 100644 --- a/drivers/tty/serial/imx.c

[PATCH] serial: imx: add hibernation support

. Signed-off-by: Philipp Zabel --- drivers/tty/serial/imx.c | 28 1 file changed, 28 insertions(+) diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c index dfeff3951f934..6bbe7dd58ac62 100644 --- a/drivers/tty/serial/imx.c +++ b/drivers/tty/serial/imx.c

Re: [PATCH v2] iio: adc: aspeed: Deassert reset in probe

ut given that the old bindings never worked, this is better than to pretend a required reset is optional. Reviewed-by: Philipp Zabel <philipp.za...@gmail.com> regards Philipp > --- > v2: > - Ensure disabling path unwinds in opposite order as the enable path > - Note that

Re: [PATCH v2] iio: adc: aspeed: Deassert reset in probe

ked, this is better than to pretend a required reset is optional. Reviewed-by: Philipp Zabel regards Philipp > --- > v2: > - Ensure disabling path unwinds in opposite order as the enable path > - Note that the bindings were incorrect without the reset phandle, > and for the system t

Re: [PATCH] iio: adc: aspeed: Deassert reset in probe

Hi Joel, On Mon, Oct 30, 2017 at 8:22 AM, Joel Stanley wrote: > The ASPEED SoC must deassert a reset in order to use the ADC peripheral. > > The device tree bindings are updated to document the resets phandle, and > the example is updated to match what is expected for both the

Re: [PATCH] iio: adc: aspeed: Deassert reset in probe

Hi Joel, On Mon, Oct 30, 2017 at 8:22 AM, Joel Stanley wrote: > The ASPEED SoC must deassert a reset in order to use the ADC peripheral. > > The device tree bindings are updated to document the resets phandle, and > the example is updated to match what is expected for both the reset and > clock

Re: [PATCH v3] i2c: aspeed: Deassert reset in probe

Brendan Higgins <brendanhigg...@google.com> > Reviewed-by: Philipp Zabel <philipp.za...@gmail.com> > Signed-off-by: Joel Stanley <j...@jms.id.au> > --- > v3: Check for bad reset controller probe (caused by eg. bad device tree) > and set ->rst to NULL so assert

Re: [PATCH v3] i2c: aspeed: Deassert reset in probe

emove the reset is asserted, which only touches the hardware once > the last i2c bus is removed. > > The request is optional, so if a device tree does not specify a reset > controller (or the driver is not built in), the driver continues to > probe. > > Reviewed-by: Brendan Higgins &g

Re: [PATCH 1/4] reset: make device_reset_optional() really optional

Hi Masahiro, On Sun, 2017-10-29 at 01:50 +0900, Masahiro Yamada wrote: > Commit bb475230b8e5 ("reset: make optional functions really optional") > converted *_get_optional* functions, but device_reset_optional() was > left behind. Convert it in the same way. > > Signed-off-by: Masahiro Yamada

Re: [PATCH 1/4] reset: make device_reset_optional() really optional

Hi Masahiro, On Sun, 2017-10-29 at 01:50 +0900, Masahiro Yamada wrote: > Commit bb475230b8e5 ("reset: make optional functions really optional") > converted *_get_optional* functions, but device_reset_optional() was > left behind. Convert it in the same way. > > Signed-off-by: Masahiro Yamada

Re: [PATCH] drm/bridge/synopsys: dsi: add optional pixel clock

Hi Philippe, On Thu, 2017-10-26 at 18:09 +0200, Philippe Cornu wrote: > The pixel clock is optional. When available, it offers a better > preciseness for timing computations. > > Signed-off-by: Philippe Cornu > --- > drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 24

Re: [PATCH] drm/bridge/synopsys: dsi: add optional pixel clock

Hi Philippe, On Thu, 2017-10-26 at 18:09 +0200, Philippe Cornu wrote: > The pixel clock is optional. When available, it offers a better > preciseness for timing computations. > > Signed-off-by: Philippe Cornu > --- > drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 24 ++-- >

Re: [PATCH v7 4/4] soc/tegra: pmc: Use the new reset APIs to manage reset controllers

On Fri, Oct 20, 2017 at 04:51:24PM +0100, Jon Hunter wrote: > Hi Philipp, > > On 19/10/17 16:17, Philipp Zabel wrote: > > Hi Jon, Thierry, > > > > On Wed, 2017-07-19 at 17:59 +0200, Philipp Zabel wrote: > >> From: Vivek Gautam <vivek.ga

Re: [PATCH v7 4/4] soc/tegra: pmc: Use the new reset APIs to manage reset controllers

On Fri, Oct 20, 2017 at 04:51:24PM +0100, Jon Hunter wrote: > Hi Philipp, > > On 19/10/17 16:17, Philipp Zabel wrote: > > Hi Jon, Thierry, > > > > On Wed, 2017-07-19 at 17:59 +0200, Philipp Zabel wrote: > >> From: Vivek Gautam > >> > >

Re: [PATCH v7 1/4] reset: Add APIs to manage array of resets

Hi, On Thu, 2017-10-19 at 11:54 -0700, Bjorn Andersson wrote: > On Wed 19 Jul 08:59 PDT 2017, Philipp Zabel wrote: > > > From: Vivek Gautam <vivek.gau...@codeaurora.org> > > > > Many devices may want to request a bunch of resets and control them. So > > it

Re: [PATCH v7 1/4] reset: Add APIs to manage array of resets

Hi, On Thu, 2017-10-19 at 11:54 -0700, Bjorn Andersson wrote: > On Wed 19 Jul 08:59 PDT 2017, Philipp Zabel wrote: > > > From: Vivek Gautam > > > > Many devices may want to request a bunch of resets and control them. So > > it's better to manage them as an arra

Re: [PATCH v8] usb: dwc3: of-simple: Add support to get resets for the device

On Fri, 2017-10-20 at 17:10 +0530, Manu Gautam wrote: > Hi, > > > On 10/19/2017 5:17 PM, Philipp Zabel wrote: > > From: Vivek Gautam <vivek.gau...@codeaurora.org> > > > > Add support to get a list of resets available for the device. > > These resets

Re: [PATCH v8] usb: dwc3: of-simple: Add support to get resets for the device

On Fri, 2017-10-20 at 17:10 +0530, Manu Gautam wrote: > Hi, > > > On 10/19/2017 5:17 PM, Philipp Zabel wrote: > > From: Vivek Gautam > > > > Add support to get a list of resets available for the device. > > These resets must be kept de-asserted until the d

Re: [PATCH v7 4/4] soc/tegra: pmc: Use the new reset APIs to manage reset controllers

Hi Jon, Thierry, On Wed, 2017-07-19 at 17:59 +0200, Philipp Zabel wrote: > From: Vivek Gautam <vivek.gau...@codeaurora.org> > > Make use of of_reset_control_array_get_exclusive() to manage > an array of reset controllers available with the device. > > Cc: Jon Hunter <

Re: [PATCH v7 4/4] soc/tegra: pmc: Use the new reset APIs to manage reset controllers

Hi Jon, Thierry, On Wed, 2017-07-19 at 17:59 +0200, Philipp Zabel wrote: > From: Vivek Gautam > > Make use of of_reset_control_array_get_exclusive() to manage > an array of reset controllers available with the device. > > Cc: Jon Hunter > Cc: Thierry Reding > Sig

Re: [RFC resend] arm64: mt8173: Fix Acer Chromebooks mmsys probe problem

Hi Laurent, On Thu, 2017-10-19 at 16:39 +0300, Laurent Pinchart wrote: > Hi Philipp, > > On Thursday, 19 October 2017 16:01:54 EEST Philipp Zabel wrote: > > On Thu, 2017-10-19 at 13:26 +0200, Matthias Brugger wrote: > > > In theory the MMSYS device tree identifier is m

Re: [RFC resend] arm64: mt8173: Fix Acer Chromebooks mmsys probe problem

Hi Laurent, On Thu, 2017-10-19 at 16:39 +0300, Laurent Pinchart wrote: > Hi Philipp, > > On Thursday, 19 October 2017 16:01:54 EEST Philipp Zabel wrote: > > On Thu, 2017-10-19 at 13:26 +0200, Matthias Brugger wrote: > > > In theory the MMSYS device tree identifier is m

Re: [RFC resend 1/4] dt-bindings: display: mediatek: add drm binding

On Thu, 2017-10-19 at 15:53 +0300, Laurent Pinchart wrote: > Hi Matthias, > > Thank you for the patch. > > On Thursday, 19 October 2017 14:26:07 EEST Matthias Brugger wrote: > > DRM subysystem and clock driver shared the same compatible mmsys. > > This stopped does not work, as only the first

Re: [RFC resend 1/4] dt-bindings: display: mediatek: add drm binding

On Thu, 2017-10-19 at 15:53 +0300, Laurent Pinchart wrote: > Hi Matthias, > > Thank you for the patch. > > On Thursday, 19 October 2017 14:26:07 EEST Matthias Brugger wrote: > > DRM subysystem and clock driver shared the same compatible mmsys. > > This stopped does not work, as only the first

Re: [RFC resend] arm64: mt8173: Fix Acer Chromebooks mmsys probe problem

On Thu, 2017-10-19 at 13:26 +0200, Matthias Brugger wrote: > In theory the MMSYS device tree identifier is matches twice, by the clk > driver > and the DRM subsystem. But the kernel only matches the first driver for a > device (clk) and discards the second one. This breaks graphics on mt8173

Re: [RFC resend] arm64: mt8173: Fix Acer Chromebooks mmsys probe problem

On Thu, 2017-10-19 at 13:26 +0200, Matthias Brugger wrote: > In theory the MMSYS device tree identifier is matches twice, by the clk > driver > and the DRM subsystem. But the kernel only matches the first driver for a > device (clk) and discards the second one. This breaks graphics on mt8173

Re: [RFC resend 1/4] dt-bindings: display: mediatek: add drm binding

}; > > +dispsys: display-system { Could we call this node display-subsystem for consistency with i.MX and Rockchip device trees? With that change, Acked-by: Philipp Zabel <p.za...@pengutronix.de> > + compatible = "mediatek,mt2701-dispsys"; > + mediatek,mmsys = <>; > +} > + > ovl0: ovl@1400c000 { > compatible = "mediatek,mt8173-disp-ovl"; > reg = <0 0x1400c000 0 0x1000>; regards Philipp

Re: [RFC resend 1/4] dt-bindings: display: mediatek: add drm binding

vl" - overlay (4 layers, blending, csc) > "mediatek,-disp-rdma" - read DMA / line buffer > "mediatek,-disp-wdma" - write DMA > @@ -71,6 +72,11 @@ mmsys: clock-controller@1400 { > #clock-cells = <1>; > }; > > +dispsys:

Re: [RFC resend 3/4] arm64: dts: mt8173: Fix drm subsystem

+ compatible = "mediatek,mt2701-dispsys"; Same comment as for patch 1, I'd prefer the node to be called "display- subsystem" instead. With that changed, Acked-by: Philipp Zabel <p.za...@pengutronix.de> > + mediatek,mmsys = <>; &

Re: [RFC resend 3/4] arm64: dts: mt8173: Fix drm subsystem

= "mediatek,mt2701-dispsys"; Same comment as for patch 1, I'd prefer the node to be called "display- subsystem" instead. With that changed, Acked-by: Philipp Zabel > + mediatek,mmsys = <>; > + } > + &

[PATCH v8] usb: dwc3: of-simple: Add support to get resets for the device

ontrol array] Signed-off-by: Philipp Zabel <p.za...@pengutronix.de> --- v7: Rebased onto git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git testing/next --- drivers/usb/dwc3/dwc3-of-simple.c | 27 +-- 1 file changed, 25 insertions(+), 2 deletions(-) diff -

[PATCH v8] usb: dwc3: of-simple: Add support to get resets for the device

From: Vivek Gautam Add support to get a list of resets available for the device. These resets must be kept de-asserted until the device is in use. Signed-off-by: Vivek Gautam [p.za...@pengutronix.de: switch to hidden reset control array] Signed-off-by: Philipp Zabel --- v7: Rebased onto git

Re: [PATCH v7 3/4] usb: dwc3: of-simple: Add support to get resets for the device

On Thu, 2017-10-19 at 14:31 +0300, Felipe Balbi wrote: > Hi, > > Philipp Zabel <p.za...@pengutronix.de> writes: > > Hi Felipe, > > > > On Thu, 2017-10-19 at 12:38 +0300, Felipe Balbi wrote: > > > Philipp Zabel <p.za...@pengutronix.de> writ

Re: [PATCH v7 3/4] usb: dwc3: of-simple: Add support to get resets for the device

On Thu, 2017-10-19 at 14:31 +0300, Felipe Balbi wrote: > Hi, > > Philipp Zabel writes: > > Hi Felipe, > > > > On Thu, 2017-10-19 at 12:38 +0300, Felipe Balbi wrote: > > > Philipp Zabel writes: > > > > > > > From: Vivek Gautam >

Re: [PATCH v7 3/4] usb: dwc3: of-simple: Add support to get resets for the device

Hi Felipe, On Thu, 2017-10-19 at 12:38 +0300, Felipe Balbi wrote: > Philipp Zabel <p.za...@pengutronix.de> writes: > > > From: Vivek Gautam <vivek.gau...@codeaurora.org> > > > > Add support to get a list of resets available for the device. > > T

Re: [PATCH v7 3/4] usb: dwc3: of-simple: Add support to get resets for the device

Hi Felipe, On Thu, 2017-10-19 at 12:38 +0300, Felipe Balbi wrote: > Philipp Zabel writes: > > > From: Vivek Gautam > > > > Add support to get a list of resets available for the device. > > These resets must be kept de-asserted until the device is > &g

Re: [PATCH v2] i2c: aspeed: Deassert reset in probe

R(bus->rst) and handle the error here. > + reset_control_deassert(bus->rst); Otherwise this will dump a warning. > + > ret = of_property_read_u32(pdev->dev.of_node, >"bus-frequency", >bus_frequency); > if (ret < 0) { &g

Re: [PATCH v2] i2c: aspeed: Deassert reset in probe

trol_deassert(bus->rst); Otherwise this will dump a warning. > + > ret = of_property_read_u32(pdev->dev.of_node, >"bus-frequency", >bus_frequency); > if (ret < 0) { > @@ -919,6 +925,8 @@ static int aspeed_i2c_remove_bus(struct platform_device > *pdev) > > i2c_del_adapter(>adap); > > + reset_control_assert(bus->rst); As will this. Reviewed-by: Philipp Zabel regards Philipp

Re: [PATCH v4 3/5] reset: socfpga: use the reset-simple driver

On Wed, 2017-10-18 at 14:00 +0100, Andre Przywara wrote: > Hi, Thank you for the review. > On 17/10/17 14:03, Philipp Zabel wrote: > > Add reset line status readback, inverted status support, and socfpga > > device tree quirks to the simple reset driver, and use it to repla

Re: [PATCH v4 3/5] reset: socfpga: use the reset-simple driver

On Wed, 2017-10-18 at 14:00 +0100, Andre Przywara wrote: > Hi, Thank you for the review. > On 17/10/17 14:03, Philipp Zabel wrote: > > Add reset line status readback, inverted status support, and socfpga > > device tree quirks to the simple reset driver, and use it to repla

[PATCH v4 3/5] reset: socfpga: use the reset-simple driver

Add reset line status readback, inverted status support, and socfpga device tree quirks to the simple reset driver, and use it to replace the socfpga driver. Signed-off-by: Philipp Zabel <p.za...@pengutronix.de> --- Changes since v3: - Rebased onto reset/next - Only warn about missin

[PATCH v4 3/5] reset: socfpga: use the reset-simple driver

Add reset line status readback, inverted status support, and socfpga device tree quirks to the simple reset driver, and use it to replace the socfpga driver. Signed-off-by: Philipp Zabel --- Changes since v3: - Rebased onto reset/next - Only warn about missing altr,modrst-offset property

[PATCH v4 2/5] reset: sunxi: use reset-simple driver

Use the newly created copies in the reset-simple driver to replace the sunxi platform driver code and reset operations. The separate sunxi driver still remains to register the early reset controllers, but it reuses the reset operations in reset-simple. Signed-off-by: Philipp Zabel <p

[PATCH v4 2/5] reset: sunxi: use reset-simple driver

Use the newly created copies in the reset-simple driver to replace the sunxi platform driver code and reset operations. The separate sunxi driver still remains to register the early reset controllers, but it reuses the reset operations in reset-simple. Signed-off-by: Philipp Zabel Reviewed

[PATCH v4 1/5] reset: add reset-simple to unify socfpga, stm32, sunxi, and zx2967

with reset-simple, extending it where necessary. Signed-off-by: Philipp Zabel <p.za...@pengutronix.de> Reviewed-by: Alexandru Gagniuc <ale...@adaptrum.com> --- Changes since v3: - Split patch 1 into reset-simple and reset-sunxi parts. - Renamed reset_simple_set to reset_simple_update

[PATCH v4 1/5] reset: add reset-simple to unify socfpga, stm32, sunxi, and zx2967

with reset-simple, extending it where necessary. Signed-off-by: Philipp Zabel Reviewed-by: Alexandru Gagniuc --- Changes since v3: - Split patch 1 into reset-simple and reset-sunxi parts. - Renamed reset_simple_set to reset_simple_update --- drivers/reset/Kconfig| 10 drivers/reset

[PATCH v4 4/5] reset: stm32: use the reset-simple driver

The reset-simple driver can be used without changes. Signed-off-by: Philipp Zabel <p.za...@pengutronix.de> Acked-by: Gabriel Fernandez <gabriel.fernan...@st.com> --- drivers/reset/Kconfig| 11 ++--- drivers/reset/Makefile | 1 - drivers/reset/reset-simple.c |

[PATCH v4 4/5] reset: stm32: use the reset-simple driver

The reset-simple driver can be used without changes. Signed-off-by: Philipp Zabel Acked-by: Gabriel Fernandez --- drivers/reset/Kconfig| 11 ++--- drivers/reset/Makefile | 1 - drivers/reset/reset-simple.c | 1 + drivers/reset/reset-stm32.c | 108

[PATCH v4 0/5] Unify simple reset drivers

is series is about unifying the existing drivers. [1] https://patchwork.kernel.org/patch/9903375/ https://patchwork.kernel.org/patch/9903373/ https://patchwork.kernel.org/patch/9903371/ https://patchwork.kernel.org/patch/9903377/ https://patchwork.kernel.org/patch/9903379/ regards Phili

[PATCH v4 0/5] Unify simple reset drivers

is series is about unifying the existing drivers. [1] https://patchwork.kernel.org/patch/9903375/ https://patchwork.kernel.org/patch/9903373/ https://patchwork.kernel.org/patch/9903371/ https://patchwork.kernel.org/patch/9903377/ https://patchwork.kernel.org/patch/9903379/ regards Phili

[PATCH v4 5/5] reset: zx2967: use the reset-simple driver

The reset-simple driver can be used without changes. Signed-off-by: Philipp Zabel <p.za...@pengutronix.de> Reviewed-by: Alexandru Gagniuc <ale...@adaptrum.com> --- MAINTAINERS | 1 - drivers/reset/Kconfig| 10 + drivers/reset/Makefile | 1 - d

[PATCH v4 5/5] reset: zx2967: use the reset-simple driver

The reset-simple driver can be used without changes. Signed-off-by: Philipp Zabel Reviewed-by: Alexandru Gagniuc --- MAINTAINERS | 1 - drivers/reset/Kconfig| 10 + drivers/reset/Makefile | 1 - drivers/reset/reset-simple.c | 2 + drivers/reset/reset

Re: [PATCH v2] reset: meson: add level reset support for GX SoC family

On Tue, 2017-10-17 at 12:19 +0200, Neil Armstrong wrote: > The Amlogic GX SoC family embeds alternate registers to drive the reset > levels next to the pulse registers. > > This patch adds support for level reset handling on the GX family only. > > The Meson8 family has an alternate way to

Re: [PATCH v2] reset: meson: add level reset support for GX SoC family

On Tue, 2017-10-17 at 12:19 +0200, Neil Armstrong wrote: > The Amlogic GX SoC family embeds alternate registers to drive the reset > levels next to the pulse registers. > > This patch adds support for level reset handling on the GX family only. > > The Meson8 family has an alternate way to

Re: [PATCH 3/4] reset: tegra: check BPMP response return code

; drivers/reset/tegra/reset-bpmp.c | 9 - > > 1 file changed, 8 insertions(+), 1 deletion(-) > > Hi Philipp, > > Would you provide an Acked-by on this so that I can take it into the > Tegra tree? There's a build dependency on patch 1/4 in the series. Acked-by: Philipp Zab

Re: [PATCH 3/4] reset: tegra: check BPMP response return code

-bpmp.c | 9 - > > 1 file changed, 8 insertions(+), 1 deletion(-) > > Hi Philipp, > > Would you provide an Acked-by on this so that I can take it into the > Tegra tree? There's a build dependency on patch 1/4 in the series. Acked-by: Philipp Zabel to take this

Re: [PATCH] reset: meson: add level reset support for GX SoC family

Hi Neil, On Mon, 2017-10-16 at 17:26 +0200, Neil Armstrong wrote: > The Amlogic GX SoC family embeds alternate registers to drive the reset > levels next to the pulse registers. > > This patch adds support for level reset handling on the GX family only. > > The Meson8 family has an alternate

Re: [PATCH] reset: meson: add level reset support for GX SoC family

Hi Neil, On Mon, 2017-10-16 at 17:26 +0200, Neil Armstrong wrote: > The Amlogic GX SoC family embeds alternate registers to drive the reset > levels next to the pulse registers. > > This patch adds support for level reset handling on the GX family only. > > The Meson8 family has an alternate

Re: [PATCH] gpio: gpio-dwapb: add optional reset

quest > drop conditions on asserting/deasserting reset Reviewed-by: Philipp Zabel <p.za...@pengutronix.de> Could you also update the device tree binding docs [1] to mention the optional resets phandle? [1] Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt regards Philipp &g

Re: [PATCH] gpio: gpio-dwapb: add optional reset

on asserting/deasserting reset Reviewed-by: Philipp Zabel Could you also update the device tree binding docs [1] to mention the optional resets phandle? [1] Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt regards Philipp > --- > drivers/gpio/gpio-dwapb.c | 9 + &

Re: [PATCH v3 5/7] nvmem: imx-ocotp: Add i.MX7D timing write clock setup support

On Mon, 2017-10-09 at 15:11 +0100, Bryan O'Donoghue wrote: > This patch adds logic to correctly setup the write timing parameters > when blowing an OTP fuse for the i.MX7S/D. > > Fixes: 0642bac7da42 ("nvmem: imx-ocotp: add write support") > > Signed-off-by: Bryan O'Donoghue

Re: [PATCH v3 5/7] nvmem: imx-ocotp: Add i.MX7D timing write clock setup support

On Mon, 2017-10-09 at 15:11 +0100, Bryan O'Donoghue wrote: > This patch adds logic to correctly setup the write timing parameters > when blowing an OTP fuse for the i.MX7S/D. > > Fixes: 0642bac7da42 ("nvmem: imx-ocotp: add write support") > > Signed-off-by: Bryan O'Donoghue > --- >

Re: [PATCH v3 3/7] nvmem: imx-ocotp: Add support for banked OTP addressing

SY. A write request to a > @@ -313,11 +365,11 @@ static struct nvmem_config imx_ocotp_nvmem_config = { > }; > > static const struct ocotp_params params[] = { > - { .nregs = 128 }, > - { .nregs = 64 }, > - { .nregs = 128 }, > - { .nregs = 128 }, > - { .nregs = 64 }, > + { .nregs = 128, .bank_address_words = 0 }, > + { .nregs = 64, .bank_address_words = 0 }, > + { .nregs = 128, .bank_address_words = 0 }, > + { .nregs = 128, .bank_address_words = 0 }, > + { .nregs = 64, .bank_address_words = 4 }, See my comment on the last patch, I'd like to be able see which entry corresponds to which SoC in this patch. Otherwise, Reviewed-by: Philipp Zabel <p.za...@pengutronix.de> regards Philipp

Re: [PATCH v3 3/7] nvmem: imx-ocotp: Add support for banked OTP addressing

@ -313,11 +365,11 @@ static struct nvmem_config imx_ocotp_nvmem_config = { > }; > > static const struct ocotp_params params[] = { > - { .nregs = 128 }, > - { .nregs = 64 }, > - { .nregs = 128 }, > - { .nregs = 128 }, > - { .nregs = 64 }, > + { .nregs = 128, .bank_address_words = 0 }, > + { .nregs = 64, .bank_address_words = 0 }, > + { .nregs = 128, .bank_address_words = 0 }, > + { .nregs = 128, .bank_address_words = 0 }, > + { .nregs = 64, .bank_address_words = 4 }, See my comment on the last patch, I'd like to be able see which entry corresponds to which SoC in this patch. Otherwise, Reviewed-by: Philipp Zabel regards Philipp

Re: [PATCH v3 2/7] nvmem: imx-ocotp: Pass parameters via a struct

tible = "fsl,imx7d-ocotp", (void *)64 }, > + { .compatible = "fsl,imx6q-ocotp", .data = [0] }, > + { .compatible = "fsl,imx6sl-ocotp", .data = [1] }, > + { .compatible = "fsl,imx6sx-ocotp", .data = [2] }, > + { .compatible = "fsl,imx6u

Re: [PATCH v3 2/7] nvmem: imx-ocotp: Pass parameters via a struct

> + { .compatible = "fsl,imx6q-ocotp", .data = [0] }, > + { .compatible = "fsl,imx6sl-ocotp", .data = [1] }, > + { .compatible = "fsl,imx6sx-ocotp", .data = [2] }, > + { .compatible = "fsl,imx6ul-ocotp", .data = [3] }, > +

Re: [PATCH 09/12] ARM: dts: imx6-tx6: move display configuration to .dtsi file

by: Lothar Waßmann <l...@karo-electronics.de> This is much appreciated, Acked-by: Philipp Zabel <p.za...@pengutronix.de> This patch does conflict with Marco's "ARM: dts: imx: Fix incorrect display nodes notation" patch [1], which renames the display@di0 nodes to disp0. Ass

Re: [PATCH 09/12] ARM: dts: imx6-tx6: move display configuration to .dtsi file

by: Lothar Waßmann This is much appreciated, Acked-by: Philipp Zabel This patch does conflict with Marco's "ARM: dts: imx: Fix incorrect display nodes notation" patch [1], which renames the display@di0 nodes to disp0. Assuming it gets merged as-is, maybe rebase on top of that? [1]

Re: [PATCH] gpio: gpio-dwapb: add optional reset

Hi Alan, Linus, On Wed, 2017-10-11 at 10:31 +0200, Linus Walleij wrote: > On Tue, Oct 10, 2017 at 11:26 PM, Alan Tull wrote: > > > Some platforms require reset to be released to allow register > > access. > > > > Signed-off-by: Alan Tull > > Fair enough. >

Re: [PATCH] gpio: gpio-dwapb: add optional reset

Hi Alan, Linus, On Wed, 2017-10-11 at 10:31 +0200, Linus Walleij wrote: > On Tue, Oct 10, 2017 at 11:26 PM, Alan Tull wrote: > > > Some platforms require reset to be released to allow register > > access. > > > > Signed-off-by: Alan Tull > > Fair enough. > > (...) > > + rst =

Re: drm/imx: lock scanout transfers for consecutive bursts

Hi Patrick, On Tue, 2017-10-10 at 10:24 +, Patrick Brünn wrote: > Hi Philipp, > > since commit 790cb4c7c9545953d22d3d425e49b36a711bae5b my display on CX9020 (a > i.MX53 based machine) stopped working: > > # dmesg | grep -i drm > [0.141829] [drm] Supports vblank timestamp caching Rev 2

Re: drm/imx: lock scanout transfers for consecutive bursts

Hi Patrick, On Tue, 2017-10-10 at 10:24 +, Patrick Brünn wrote: > Hi Philipp, > > since commit 790cb4c7c9545953d22d3d425e49b36a711bae5b my display on CX9020 (a > i.MX53 based machine) stopped working: > > # dmesg | grep -i drm > [0.141829] [drm] Supports vblank timestamp caching Rev 2

Re: [RESEND][PATCH 5/7] nvmem: imx-ocotp: Add i.MX7D timing write clock setup support

On Wed, 2017-10-04 at 23:25 +0100, Bryan O'Donoghue wrote: > This patch adds logic to correctly setup the write timing parameters > when blowing an OTP fuse for the i.MX7S/D. > > Fixes: 0642bac7da42 ("nvmem: imx-ocotp: add write support") > > Signed-off-by: Bryan O'Donoghue

Re: [RESEND][PATCH 5/7] nvmem: imx-ocotp: Add i.MX7D timing write clock setup support

On Wed, 2017-10-04 at 23:25 +0100, Bryan O'Donoghue wrote: > This patch adds logic to correctly setup the write timing parameters > when blowing an OTP fuse for the i.MX7S/D. > > Fixes: 0642bac7da42 ("nvmem: imx-ocotp: add write support") > > Signed-off-by: Bryan O'Donoghue > --- >  

Re: [RESEND][PATCH 4/7] nvmem: imx-ocotp: Move i.MX6 write clock setup to dedicated function

x-ocotp: add write support") > > Signed-off-by: Bryan O'Donoghue <pure.lo...@nexus-software.ie> Reviewed-by: Philipp Zabel <p.za...@pengutronix.de> regards Philipp

Re: [RESEND][PATCH 4/7] nvmem: imx-ocotp: Move i.MX6 write clock setup to dedicated function

x-ocotp: add write support") > > Signed-off-by: Bryan O'Donoghue Reviewed-by: Philipp Zabel regards Philipp

Re: [RESEND][PATCH 2/7] nvmem: imx-ocotp: Pass parameters via a struct

Hi Bryan, a few small nitpicks below. On Wed, 2017-10-04 at 23:25 +0100, Bryan O'Donoghue wrote: > It will be useful in later patches to know the register access mode > and bit-shift to apply to a given input offset. > > Fixes: 0642bac7da42 ("nvmem: imx-ocotp: add write support") > >

Re: [RESEND][PATCH 3/7] nvmem: imx-ocotp: Add support for banked OTP addressing

On Wed, 2017-10-04 at 23:25 +0100, Bryan O'Donoghue wrote: > The i.MX7S/D takes the bank address in the CTRLn.ADDR field and the > data > value in one of the DATAx {0, 1, 2, 3} register fields. The current > write > routine is based on writing the CTRLn.ADDR field and writing a single > DATA >

Re: [RESEND][PATCH 2/7] nvmem: imx-ocotp: Pass parameters via a struct

Hi Bryan, a few small nitpicks below. On Wed, 2017-10-04 at 23:25 +0100, Bryan O'Donoghue wrote: > It will be useful in later patches to know the register access mode > and bit-shift to apply to a given input offset. > > Fixes: 0642bac7da42 ("nvmem: imx-ocotp: add write support") > >

Re: [RESEND][PATCH 3/7] nvmem: imx-ocotp: Add support for banked OTP addressing

On Wed, 2017-10-04 at 23:25 +0100, Bryan O'Donoghue wrote: > The i.MX7S/D takes the bank address in the CTRLn.ADDR field and the > data > value in one of the DATAx {0, 1, 2, 3} register fields. The current > write > routine is based on writing the CTRLn.ADDR field and writing a single > DATA >

Re: [RESEND][PATCH 1/7] nvmem: imx-ocotp: Restrict OTP write to IMX6 processors

> > Since OTP programming is one-time destructive its important we > restrict > this interface ASAP. > > Fixes: 0642bac7da42 ("nvmem: imx-ocotp: add write support") > > Signed-off-by: Bryan O'Donoghue <pure.lo...@nexus-software.ie> Acked-by: Philipp Zabel <p.za...@pengutronix.de> regards Philipp

Re: [RESEND][PATCH 1/7] nvmem: imx-ocotp: Restrict OTP write to IMX6 processors

> > Since OTP programming is one-time destructive its important we > restrict > this interface ASAP. > > Fixes: 0642bac7da42 ("nvmem: imx-ocotp: add write support") > > Signed-off-by: Bryan O'Donoghue Acked-by: Philipp Zabel regards Philipp

Re: [PATCH] reset: uniphier: add PXs3 reset data

On Thu, 2017-10-05 at 11:30 +0900, Masahiro Yamada wrote: > Add basic reset data for Socionext's new SoC PXs3. > > Signed-off-by: Masahiro Yamada Thanks, applied to the reset/next branch. regards Philipp > --- > >  

Re: [PATCH] reset: uniphier: add PXs3 reset data

On Thu, 2017-10-05 at 11:30 +0900, Masahiro Yamada wrote: > Add basic reset data for Socionext's new SoC PXs3. > > Signed-off-by: Masahiro Yamada Thanks, applied to the reset/next branch. regards Philipp > --- > >  .../devicetree/bindings/reset/uniphier-reset.txt   |  3 +++ >  

<    2   3   4   5   6   7   8   9   10   11   >