Re: [RFC PATCH 3/4] drm: bridge: Generic GPIO mux driver

(whoops, apologies for the CHROMIUM tag in the subject line...) On Tue, Jun 28, 2016 at 4:52 PM, Archit Taneja <arch...@codeaurora.org> wrote: > > > On 06/27/2016 01:18 PM, Nicolas Boichat wrote: >> >> This driver supports single input, 2 output display mux (e.g. >

Re: [RFC PATCH 3/4] drm: bridge: Generic GPIO mux driver

(whoops, apologies for the CHROMIUM tag in the subject line...) On Tue, Jun 28, 2016 at 4:52 PM, Archit Taneja wrote: > > > On 06/27/2016 01:18 PM, Nicolas Boichat wrote: >> >> This driver supports single input, 2 output display mux (e.g. >> HDMI mux), that pro

Re: [RFC PATCH 0/4] drm: bridge: anx7688 and mux drivers

Hi Archit, Sorry got swamped by other things and forgot to reply. On Tue, Jun 28, 2016 at 4:28 PM, Archit Taneja <arch...@codeaurora.org> wrote: > > > On 06/27/2016 01:18 PM, Nicolas Boichat wrote: >> >> Hi all, >> >> This is a follow up to the 2 patch

Re: [RFC PATCH 0/4] drm: bridge: anx7688 and mux drivers

Hi Archit, Sorry got swamped by other things and forgot to reply. On Tue, Jun 28, 2016 at 4:28 PM, Archit Taneja wrote: > > > On 06/27/2016 01:18 PM, Nicolas Boichat wrote: >> >> Hi all, >> >> This is a follow up to the 2 patches to add suppor

[RFC PATCH 2/4] devicetree: Add ANX7688 transmitter binding

Signed-off-by: Nicolas Boichat <drink...@chromium.org> Change-Id: I618ddf114bb93700daf6572d954191e10b6961c8 --- .../devicetree/bindings/drm/bridge/anx7688.txt | 32 ++ 1 file changed, 32 insertions(+) create mode 100644 Documentation/devicetree/bindings/drm/

[RFC PATCH 2/4] devicetree: Add ANX7688 transmitter binding

Signed-off-by: Nicolas Boichat Change-Id: I618ddf114bb93700daf6572d954191e10b6961c8 --- .../devicetree/bindings/drm/bridge/anx7688.txt | 32 ++ 1 file changed, 32 insertions(+) create mode 100644 Documentation/devicetree/bindings/drm/bridge/anx7688.txt diff --git

[RFC PATCH 4/4] CHROMIUM: devicetree: Add GPIO display mux binding

Signed-off-by: Nicolas Boichat <drink...@chromium.org> --- .../devicetree/bindings/drm/bridge/gpio-mux.txt| 59 ++ 1 file changed, 59 insertions(+) create mode 100644 Documentation/devicetree/bindings/drm/bridge/gpio-mux.txt diff --git a/Documentation/devicetree/bi

[RFC PATCH 4/4] CHROMIUM: devicetree: Add GPIO display mux binding

Signed-off-by: Nicolas Boichat --- .../devicetree/bindings/drm/bridge/gpio-mux.txt| 59 ++ 1 file changed, 59 insertions(+) create mode 100644 Documentation/devicetree/bindings/drm/bridge/gpio-mux.txt diff --git a/Documentation/devicetree/bindings/drm/bridge/gpio

[RFC PATCH 0/4] drm: bridge: anx7688 and mux drivers

e 1 by filtering only when ANX7688 is active. I understand this patch series might not be acceptable as-is, but I hope this sort of setup can be taken into account when better support for connector drivers is introduced. Thanks! Best, Nicolas Nicolas Boichat (4): drm: bridge: anx7688: Add anx7

[RFC PATCHv2 1/4] FROMLIST: drm: bridge: anx7688: Add anx7688 bridge driver support.

nalogix,anx7688", }, + { /* sentinel */ }, +}; +MODULE_DEVICE_TABLE(of, anx7688_match_table); +#endif + +static struct i2c_driver anx7688_driver = { + .driver = { + .name = "anx7688", + .of_match_table = of_match_ptr(anx7688_match_table), +

[RFC PATCH 0/4] drm: bridge: anx7688 and mux drivers

e 1 by filtering only when ANX7688 is active. I understand this patch series might not be acceptable as-is, but I hope this sort of setup can be taken into account when better support for connector drivers is introduced. Thanks! Best, Nicolas Nicolas Boichat (4): drm: bridge: anx7688: Add anx7

[RFC PATCHv2 1/4] FROMLIST: drm: bridge: anx7688: Add anx7688 bridge driver support.

nalogix,anx7688", }, + { /* sentinel */ }, +}; +MODULE_DEVICE_TABLE(of, anx7688_match_table); +#endif + +static struct i2c_driver anx7688_driver = { + .driver = { + .name = "anx7688", + .of_match_table = of_match_ptr(anx7688_match_table), + }, + .probe = anx7688_i2c_probe, + .remove = anx7688_i2c_remove, + .id_table = anx7688_id, +}; + +module_i2c_driver(anx7688_driver); + +MODULE_DESCRIPTION("ANX7688 SlimPort Transmitter driver"); +MODULE_AUTHOR("Nicolas Boichat "); +MODULE_LICENSE("GPL v2"); -- 2.8.0.rc3.226.g39d4020

[RFC PATCH 3/4] CHROMIUM: drm: bridge: Generic GPIO mux driver

This driver supports single input, 2 output display mux (e.g. HDMI mux), that provides its status via a GPIO. Signed-off-by: Nicolas Boichat <drink...@chromium.org> --- drivers/gpu/drm/bridge/Kconfig| 11 + drivers/gpu/drm/bridge/Makefile | 1 + drivers/gpu/drm/

[RFC PATCH 3/4] CHROMIUM: drm: bridge: Generic GPIO mux driver

This driver supports single input, 2 output display mux (e.g. HDMI mux), that provides its status via a GPIO. Signed-off-by: Nicolas Boichat --- drivers/gpu/drm/bridge/Kconfig| 11 + drivers/gpu/drm/bridge/Makefile | 1 + drivers/gpu/drm/bridge/generic-gpio-mux.c | 347

Re: [RFC PATCH 1/2] drm: bridge: anx7688: Add anx7688 bridge driver support.

Hi Philipp, On Wed, Jun 22, 2016 at 4:51 PM, Philipp Zabel <p.za...@pengutronix.de> wrote: > Hi Nicolas, > > Am Mittwoch, den 22.06.2016, 14:32 +0800 schrieb Nicolas Boichat: >> >> Actually, experimenting a bit more with the code, I realized that the >>

Re: [RFC PATCH 1/2] drm: bridge: anx7688: Add anx7688 bridge driver support.

Hi Philipp, On Wed, Jun 22, 2016 at 4:51 PM, Philipp Zabel wrote: > Hi Nicolas, > > Am Mittwoch, den 22.06.2016, 14:32 +0800 schrieb Nicolas Boichat: >> >> Actually, experimenting a bit more with the code, I realized that the >> >> connector is always attached t

Re: [RFC PATCH 1/2] drm: bridge: anx7688: Add anx7688 bridge driver support.

+Philipp On Wed, Jun 22, 2016 at 11:54 AM, Archit Taneja <arch...@codeaurora.org> wrote: > > > On 6/22/2016 8:14 AM, Nicolas Boichat wrote: >> >> Hi Archit, >> >> Thanks for your reply. >> >> On Tue, Jun 21, 2016 at 11:39 PM, Archit T

Re: [RFC PATCH 1/2] drm: bridge: anx7688: Add anx7688 bridge driver support.

+Philipp On Wed, Jun 22, 2016 at 11:54 AM, Archit Taneja wrote: > > > On 6/22/2016 8:14 AM, Nicolas Boichat wrote: >> >> Hi Archit, >> >> Thanks for your reply. >> >> On Tue, Jun 21, 2016 at 11:39 PM, Archit Taneja >> wrote: >>>

Re: [RFC PATCH 1/2] drm: bridge: anx7688: Add anx7688 bridge driver support.

Hi Archit, Thanks for your reply. On Tue, Jun 21, 2016 at 11:39 PM, Archit Taneja <arch...@codeaurora.org> wrote: > Hi, > > On 6/20/2016 12:44 PM, Nicolas Boichat wrote: >> >> ANX7688 is a HDMI to DP converter (as well as USB-C port controller), >> tha

Re: [RFC PATCH 1/2] drm: bridge: anx7688: Add anx7688 bridge driver support.

Hi Archit, Thanks for your reply. On Tue, Jun 21, 2016 at 11:39 PM, Archit Taneja wrote: > Hi, > > On 6/20/2016 12:44 PM, Nicolas Boichat wrote: >> >> ANX7688 is a HDMI to DP converter (as well as USB-C port controller), >> that has an internal microcontroller. &g

[RFC PATCH 1/2] drm: bridge: anx7688: Add anx7688 bridge driver support.

by the bridge via 2 registers on I2C. Signed-off-by: Nicolas Boichat <drink...@chromium.org> --- Hi, I tested this driver using the Mediatek HDMI controller (MT8173) upstream of the ANX bridge chip (Phillip sent a PULL request on June 13: git://git.pengutronix.de/git/pza/linux.git tags/mediat

[RFC PATCH 1/2] drm: bridge: anx7688: Add anx7688 bridge driver support.

by the bridge via 2 registers on I2C. Signed-off-by: Nicolas Boichat --- Hi, I tested this driver using the Mediatek HDMI controller (MT8173) upstream of the ANX bridge chip (Phillip sent a PULL request on June 13: git://git.pengutronix.de/git/pza/linux.git tags/mediatek-drm-2016-06-13 ). I have 2

[RFC PATCH 2/2] devicetree: Add ANX7688 transmitter binding

ANX7688 is a transmitter to support DisplayPort over USB-C for smartphone and tablets. This binding only describes the HDMI to DP component of the chip. Signed-off-by: Nicolas Boichat <drink...@chromium.org> --- .../devicetree/bindings/video/bridge/anx7688.txt | 32 +++

[RFC PATCH 2/2] devicetree: Add ANX7688 transmitter binding

ANX7688 is a transmitter to support DisplayPort over USB-C for smartphone and tablets. This binding only describes the HDMI to DP component of the chip. Signed-off-by: Nicolas Boichat --- .../devicetree/bindings/video/bridge/anx7688.txt | 32 ++ 1 file changed, 32

INFO: inconsistent lock state in ecryptfs_calculate_md5

Hi, We've run into the following lockdep warning while using a system with ecryptfs, under heavy memory pressure. If I understand the issue correctly, fs/ecryptfs/crypto.c:ecryptfs_calculate_md5: - Locks _stat->cs_hash_tfm_mutex -> Calls crypto_alloc_hash -> Calls crypto_alloc_base ->

INFO: inconsistent lock state in ecryptfs_calculate_md5

Hi, We've run into the following lockdep warning while using a system with ecryptfs, under heavy memory pressure. If I understand the issue correctly, fs/ecryptfs/crypto.c:ecryptfs_calculate_md5: - Locks _stat->cs_hash_tfm_mutex -> Calls crypto_alloc_hash -> Calls crypto_alloc_base ->

Re: [PATCH v2 3/3] drm: bridge: anx78xx: Add anx78xx driver support.

@chromium.org> > Signed-off-by: Enric Balletbo i Serra <enric.balle...@collabora.com> Some minor nits below, otherwise: Tested-by: Nicolas Boichat <drink...@chromium.org> Reviewed-by: Nicolas Boichat <drink...@chromium.org> > --- > > Changes since v1: > - Dan

Re: [PATCH v2 3/3] drm: bridge: anx78xx: Add anx78xx driver support.

r > designed for portable devices. This driver adds initial support for HDMI > to DP pass-through mode. > > Cc: Emil Velikov > Cc: Rob Herring > Cc: Dan Carpenter > Cc: Daniel Kurtz > Signed-off-by: Enric Balletbo i Serra Some minor nits below, otherwise: Tested-by: Nicolas B

[PATCH 1/2] mmc: mediatek: Change signal voltage error to dev_dbg()

In commit ceae98f20e36 ("mmc: core: Try other signal levels during power up") we can see that there are times when it's valid to try several signal voltages. Don't print an ugly error in the logs when that happens. Signed-off-by: Nicolas Boichat <drink...@chromium.org&

[PATCH 1/2] mmc: mediatek: Change signal voltage error to dev_dbg()

In commit ceae98f20e36 ("mmc: core: Try other signal levels during power up") we can see that there are times when it's valid to try several signal voltages. Don't print an ugly error in the logs when that happens. Signed-off-by: Nicolas Boichat --

[PATCH 2/2] mmc: mediatek: Use mmc_regulator_set_vqmmc in start_signal_voltage_switch

compatibility. 2. We get rid of a few more warnings when probing unsupported voltages. 3. We get rid of some non-mediatek specific code in mtk-sd. Signed-off-by: Nicolas Boichat <drink...@chromium.org> --- Similar to e0848f5d294c703917260a6228cc08b8be46c527 mmc: dw_mm

[PATCH 2/2] mmc: mediatek: Use mmc_regulator_set_vqmmc in start_signal_voltage_switch

compatibility. 2. We get rid of a few more warnings when probing unsupported voltages. 3. We get rid of some non-mediatek specific code in mtk-sd. Signed-off-by: Nicolas Boichat --- Similar to e0848f5d294c703917260a6228cc08b8be46c527 mmc: dw_mmc: Use mmc_regulator_set_vqmmc

[RESEND PATCH] drivers: android: correct the size of struct binder_uintptr_t for BC_DEAD_BINDER_DONE

system. Correct it here. Signed-off-by: Lisa Du <c...@marvell.com> Signed-off-by: Nicolas Boichat <drink...@chromium.org> --- This patch was first sent upstream here: https://lkml.org/lkml/2015/5/28/747, but was not picked up (probably because it was part of a bigger series that refactore

[RESEND PATCH] drivers: android: correct the size of struct binder_uintptr_t for BC_DEAD_BINDER_DONE

Signed-off-by: Lisa Du Signed-off-by: Nicolas Boichat --- This patch was first sent upstream here: https://lkml.org/lkml/2015/5/28/747, but was not picked up (probably because it was part of a bigger series that refactored binder). This patch fixes issues when using 64-bit binder API on 32-b

[PATCH] spi: mediatek: Prevent overflows in FIFO transfers

memcpy on the remainder of the bytes. Signed-off-by: Nicolas Boichat --- drivers/spi/spi-mt65xx.c | 28 ++-- 1 file changed, 18 insertions(+), 10 deletions(-) diff --git a/drivers/spi/spi-mt65xx.c b/drivers/spi/spi-mt65xx.c index 00a36da..8763eff 100644 --- a/drivers/spi/spi-mt65xx.c

[PATCH] spi: mediatek: Prevent overflows in FIFO transfers

memcpy on the remainder of the bytes. Signed-off-by: Nicolas Boichat <drink...@chromium.org> --- drivers/spi/spi-mt65xx.c | 28 ++-- 1 file changed, 18 insertions(+), 10 deletions(-) diff --git a/drivers/spi/spi-mt65xx.c b/drivers/spi/spi-mt65xx.c index 00a36da..8763eff 100644 -

Re: [PATCH v2 2/3] nvmem: mediatek: Add Mediatek EFUSE driver

On Thu, Nov 19, 2015 at 6:46 PM, Andrew-CT Chen wrote: > Add Mediatek EFUSE driver to access hardware data like > thermal sensor calibration or HDMI impedance. > > Signed-off-by: Andrew-CT Chen > --- > drivers/nvmem/Kconfig | 11 ++ > drivers/nvmem/Makefile| 2 ++ >

Re: [PATCH v2 2/3] nvmem: mediatek: Add Mediatek EFUSE driver

On Thu, Nov 19, 2015 at 6:46 PM, Andrew-CT Chen wrote: > Add Mediatek EFUSE driver to access hardware data like > thermal sensor calibration or HDMI impedance. > > Signed-off-by: Andrew-CT Chen > --- > drivers/nvmem/Kconfig | 11

[PATCH v3] mfd: cros ec: Lock the SPI bus while holding chipselect

. Signed-off-by: Nicolas Boichat --- v2: Move bus_unlock earlier in the functions. v3: Remove comments. Applies on top on linux-next/master (20151124) drivers/mfd/cros_ec_spi.c | 30 ++ 1 file changed, 18 insertions(+), 12 deletions(-) diff --git a/drivers/mfd

[PATCH v3] mfd: cros ec: Lock the SPI bus while holding chipselect

. Signed-off-by: Nicolas Boichat <drink...@chromium.org> --- v2: Move bus_unlock earlier in the functions. v3: Remove comments. Applies on top on linux-next/master (20151124) drivers/mfd/cros_ec_spi.c | 30 ++ 1 file changed, 18 insertions(+), 12 deletions(-) diff

[PATCH] watchdog: mtk_wdt: Use MODE_KEY when stopping the watchdog

WDT_MODE value need to be or-ed with MODE_KEY when setting watchdog mode. Add it to mtk_wdt_stop function, so that the watchdog can be stopped (e.g. during suspend). Signed-off-by: Nicolas Boichat --- drivers/watchdog/mtk_wdt.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers

[PATCH] watchdog: mtk_wdt: Use MODE_KEY when stopping the watchdog

WDT_MODE value need to be or-ed with MODE_KEY when setting watchdog mode. Add it to mtk_wdt_stop function, so that the watchdog can be stopped (e.g. during suspend). Signed-off-by: Nicolas Boichat <drink...@chromium.org> --- drivers/watchdog/mtk_wdt.c | 1 + 1 file changed, 1 insertion(+)

[PATCH v2] mfd: cros ec: Lock the SPI bus while holding chipselect

. Signed-off-by: Nicolas Boichat --- v2: Move bus_unlock earlier in the functions. Applies on top on linux-next/master (20151109) drivers/mfd/cros_ec_spi.c | 41 + 1 file changed, 29 insertions(+), 12 deletions(-) diff --git a/drivers/mfd/cros_ec_spi.c b

[PATCH v2] spi: mediatek: single device does not require cs_gpios

This fixes the crash, and re-introduces backward compatibility. Signed-off-by: Nicolas Boichat --- v2: Use gpio_is_valid() Applies on top of broonie/spi.git/for-next. drivers/spi/spi-mt65xx.c | 26 ++ 1 file changed, 18 insertions(+), 8 deletions(-) diff --git a/drive

[PATCH v2] mfd: cros ec: Lock the SPI bus while holding chipselect

. Signed-off-by: Nicolas Boichat <drink...@chromium.org> --- v2: Move bus_unlock earlier in the functions. Applies on top on linux-next/master (20151109) drivers/mfd/cros_ec_spi.c | 41 + 1 file changed, 29 insertions(+), 12 deletions(-) diff --git a/d

[PATCH v2] spi: mediatek: single device does not require cs_gpios

This fixes the crash, and re-introduces backward compatibility. Signed-off-by: Nicolas Boichat <drink...@chromium.org> --- v2: Use gpio_is_valid() Applies on top of broonie/spi.git/for-next. drivers/spi/spi-mt65xx.c | 26 ++ 1 file changed, 18 insertions(+), 8 deletion

Re: [PATCH] spi: mediatek: single device does not require cs_gpios

On Thu, Nov 5, 2015 at 5:16 PM, Andy Shevchenko wrote: > On Thu, Nov 5, 2015 at 7:50 AM, Nicolas Boichat wrote: [...] >> diff --git a/drivers/spi/spi-mt65xx.c b/drivers/spi/spi-mt65xx.c >> index 563954a..f694031 100644 >> --- a/drivers/spi/spi-mt65xx.c >> +++

Re: [PATCH] spi: mediatek: single device does not require cs_gpios

On Thu, Nov 5, 2015 at 5:16 PM, Andy Shevchenko <andy.shevche...@gmail.com> wrote: > On Thu, Nov 5, 2015 at 7:50 AM, Nicolas Boichat <drink...@chromium.org> wrote: [...] >> diff --git a/drivers/spi/spi-mt65xx.c b/drivers/spi/spi-mt65xx.c >> index 563954a..f694031 1006

[PATCH] spi: mediatek: single device does not require cs_gpios

This fixes the crash, and re-introduces backward compatibility. Signed-off-by: Nicolas Boichat --- Applies on top of broonie/spi.git topic/mtk. Thanks! drivers/spi/spi-mt65xx.c | 26 ++ 1 file changed, 18 insertions(+), 8 deletions(-) diff --git a/drivers/spi/spi-mt65xx.c b/d

[PATCH] spi: mediatek: single device does not require cs_gpios

This fixes the crash, and re-introduces backward compatibility. Signed-off-by: Nicolas Boichat <drink...@chromium.org> --- Applies on top of broonie/spi.git topic/mtk. Thanks! drivers/spi/spi-mt65xx.c | 26 ++ 1 file changed, 18 insertions(+), 8 deletions(-) diff --git a

Re: [PATCH] mfd: cros ec: Lock the SPI bus while holding chipselect

+gwen...@chromium.org On Thu, Oct 29, 2015 at 4:17 PM, Nicolas Boichat wrote: > @@ -482,6 +493,7 @@ static int cros_ec_pkt_xfer_spi(struct cros_ec_device > *ec_dev, > > ret = len; > exit: > + spi_bus_unlock(ec_spi->spi->master); Gwendal noted offline tha

Re: [PATCH] mfd: cros ec: Lock the SPI bus while holding chipselect

+gwen...@chromium.org On Thu, Oct 29, 2015 at 4:17 PM, Nicolas Boichat <drink...@chromium.org> wrote: > @@ -482,6 +493,7 @@ static int cros_ec_pkt_xfer_spi(struct cros_ec_device > *ec_dev, > > ret = len; > exit: > + spi_bus_unlock(ec_spi->spi->m

[PATCH] mfd: cros ec: Lock the SPI bus while holding chipselect

. Signed-off-by: Nicolas Boichat --- drivers/mfd/cros_ec_spi.c | 37 + 1 file changed, 25 insertions(+), 12 deletions(-) diff --git a/drivers/mfd/cros_ec_spi.c b/drivers/mfd/cros_ec_spi.c index 30a296b..659240d 100644 --- a/drivers/mfd/cros_ec_spi.c +++ b/drivers/mfd

[PATCH] mfd: cros ec: Lock the SPI bus while holding chipselect

. Signed-off-by: Nicolas Boichat <drink...@chromium.org> --- drivers/mfd/cros_ec_spi.c | 37 + 1 file changed, 25 insertions(+), 12 deletions(-) diff --git a/drivers/mfd/cros_ec_spi.c b/drivers/mfd/cros_ec_spi.c index 30a296b..659240d 100644 --- a/drive

[PATCH v2] modpost: Add flag -E for making section mismatches fatal

when using allmodconfig on some architectures, and we do not want to break these builds by default. Signed-off-by: Nicolas Boichat Change-Id: Ic346706e3297c9f0d790e3552aa94e5cff9897a6 --- v2 (Rusty Russell feedback): - Renamed flag from -f to -E (-f means force, so we pick -E for error

[PATCH v2] modpost: Add flag -E for making section mismatches fatal

when using allmodconfig on some architectures, and we do not want to break these builds by default. Signed-off-by: Nicolas Boichat <drink...@chromium.org> Change-Id: Ic346706e3297c9f0d790e3552aa94e5cff9897a6 --- v2 (Rusty Russell feedback): - Renamed flag from -f to -E (-f means force,

[PATCH] modpost: Add flag -f for making section mismatches fatal

when using allmodconfig on some architectures, and we do not want to break these builds by default. Signed-off-by: Nicolas Boichat Change-Id: Ic346706e3297c9f0d790e3552aa94e5cff9897a6 --- I'm trying to revive this old patch. When it was first submitted [1], Jonathan got the following feedback

[PATCH] modpost: Add flag -f for making section mismatches fatal

when using allmodconfig on some architectures, and we do not want to break these builds by default. Signed-off-by: Nicolas Boichat <drink...@chromium.org> Change-Id: Ic346706e3297c9f0d790e3552aa94e5cff9897a6 --- I'm trying to revive this old patch. When it was first submitted [1], Jonath

Re: [PATCHv3 3/3] drm: bridge: anx78xx: Add anx78xx driver support by analogix.

Hi Enric, Partial review for now, thanks for you work. Best, On Thu, Sep 10, 2015 at 06:35:52PM +0200, Enric Balletbo i Serra wrote: > At the moment it only supports ANX7814. > > The ANX7814 is an ultra-low power Full-HD (1080p60) SlimPort transmitter > designed for portable devices. > > This

Re: [PATCHv3 3/3] drm: bridge: anx78xx: Add anx78xx driver support by analogix.

Hi Enric, Partial review for now, thanks for you work. Best, On Thu, Sep 10, 2015 at 06:35:52PM +0200, Enric Balletbo i Serra wrote: > At the moment it only supports ANX7814. > > The ANX7814 is an ultra-low power Full-HD (1080p60) SlimPort transmitter > designed for portable devices. > > This

Re: [PATCH v7] arm64: dts: Add spi bus dts

On Mon, Aug 31, 2015 at 9:44 PM, Leilk Liu wrote: > This patch adds MT8173 spi bus controllers into device tree. The corresponding SPI driver has already been merged in git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git . > Signed-off-by: Leilk Liu Reviewed-and-Tested-by: N

Re: [PATCH v7] arm64: dts: Add spi bus dts

k Liu <leilk@mediatek.com> Reviewed-and-Tested-by: Nicolas Boichat <drink...@chromium.org> > --- > Change in this patch: > 1. fix spi clock flow usage error. > --- > arch/arm64/boot/dts/mediatek/mt8173-evb.dts | 18 ++ > arch/arm64/boot/dts/mediatek/mt

Re: [PATCH v2] spi: bitbang: Replace spinlock by mutex

Hi Mark, On Mon, Aug 17, 2015 at 11:52 AM, Nicolas Boichat wrote: > chipselect (in the case of spi-gpio: spi_gpio_chipselect, which > calls gpiod_set_raw_value_cansleep) can sleep, so we should not > hold a spinlock while calling it from spi_bitbang_setup. > > This issue

Re: [PATCH v2] spi: bitbang: Replace spinlock by mutex

Hi Mark, On Mon, Aug 17, 2015 at 11:52 AM, Nicolas Boichat <drink...@chromium.org> wrote: > chipselect (in the case of spi-gpio: spi_gpio_chipselect, which > calls gpiod_set_raw_value_cansleep) can sleep, so we should not > hold a spinlock while calling it from spi_bitbang_setup.

[PATCH v2] spi: bitbang: Replace spinlock by mutex

d the lock for similar purpose. Signed-off-by: Nicolas Boichat --- Going the "safer" way and just replacing the spinlock by a mutex. Applies on top of broonie-sound/for-next, and compile-tested on x86-64/arm (allyesconfig) and ppc44x (defconfig+SPI driver), and runtime-tested on an a

[PATCH v2] spi: bitbang: Replace spinlock by mutex

for similar purpose. Signed-off-by: Nicolas Boichat drink...@chromium.org --- Going the safer way and just replacing the spinlock by a mutex. Applies on top of broonie-sound/for-next, and compile-tested on x86-64/arm (allyesconfig) and ppc44x (defconfig+SPI driver), and runtime-tested on an arm

Re: [v5,2/3] spi: mediatek: Add spi bus for Mediatek MT8173

Hi Leilk, On Fri, Aug 7, 2015 at 3:19 PM, wrote: > This patch adds basic spi bus for MT8173. > > Signed-off-by: Leilk Liu > > --- > Change in this patch: > 1. change "pad-select" to "mediatek,pad-select". > 2. modify clk relevant implement. > --- > drivers/spi/Kconfig |

[PATCH RESEND] regmap: Move documentation to regmap.h

Init functions defined in regmap*.c files are now prefixed with __, take lockdep key and class parameters, and should not be called directly: move the documentation to regmap.h, where the macros are defined. Signed-off-by: Nicolas Boichat --- Resending without modification, now that "r

[PATCH RESEND] regmap: Move documentation to regmap.h

Init functions defined in regmap*.c files are now prefixed with __, take lockdep key and class parameters, and should not be called directly: move the documentation to regmap.h, where the macros are defined. Signed-off-by: Nicolas Boichat drink...@chromium.org --- Resending without modification

Re: [v5,2/3] spi: mediatek: Add spi bus for Mediatek MT8173

Hi Leilk, On Fri, Aug 7, 2015 at 3:19 PM, leilk@mediatek.com wrote: This patch adds basic spi bus for MT8173. Signed-off-by: Leilk Liu leilk@mediatek.com --- Change in this patch: 1. change pad-select to mediatek,pad-select. 2. modify clk relevant implement. ---

Re: [PATCH] regmap: Move documentation to regmap.h

Hi Mark, On Wed, Jul 8, 2015 at 6:32 PM, Nicolas Boichat wrote: > Init functions defined in regmap*.c files are now prefixed with > __, take lockdep key and class parameters, and should not be > called directly: move the documentation to regmap.h, where the > macros are defined. &g

Re: [PATCH] regmap: Move documentation to regmap.h

Hi Mark, On Wed, Jul 8, 2015 at 6:32 PM, Nicolas Boichat drink...@chromium.org wrote: Init functions defined in regmap*.c files are now prefixed with __, take lockdep key and class parameters, and should not be called directly: move the documentation to regmap.h, where the macros are defined

Re: [PATCH 1/3] spi: bitbang: Replace spinlock by mutex when calling chipselect

On Tue, Aug 4, 2015 at 6:59 PM, Mark Brown wrote: > On Tue, Aug 04, 2015 at 02:09:56PM +0800, Nicolas Boichat wrote: [snip] >> Actually, I'm not sure if I understand the existing code: why are we not >> waiting for busy to go down to 0, then call chipselect, instead of

Re: [PATCH 1/3] spi: bitbang: Replace spinlock by mutex when calling chipselect

On Tue, Aug 4, 2015 at 6:59 PM, Mark Brown broo...@kernel.org wrote: On Tue, Aug 04, 2015 at 02:09:56PM +0800, Nicolas Boichat wrote: [snip] Actually, I'm not sure if I understand the existing code: why are we not waiting for busy to go down to 0, then call chipselect, instead of not calling

[PATCH 2/3] spi: ppc44x: Remove chipselect from setupxfer

The chipselect operation is already done in spi_bitbang_transfer_one, or in spi_bitbang_setup, so there is no need to do it in setupxfer as well. Signed-off-by: Nicolas Boichat --- drivers/spi/spi-ppc4xx.c | 7 --- 1 file changed, 7 deletions(-) diff --git a/drivers/spi/spi-ppc4xx.c b

[PATCH 3/3] spi: s3c24xx: Convert spinlock to mutex

bitbang->lock is now a mutex: replace spinlock function calls by mutex functions. Signed-off-by: Nicolas Boichat --- drivers/spi/spi-s3c24xx.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/spi/spi-s3c24xx.c b/drivers/spi/spi-s3c24xx.c index f36bc32..b1d0

[PATCH 1/3] spi: bitbang: Replace spinlock by mutex when calling chipselect

rted spi-gpio to cansleep variants: d9dda5a191 "spi: spi-gpio: Use 'cansleep' variants to access GPIO" Replace spinlock + busy variable by a mutex, and get rid of spi_bitbang_prepare_hardware and spi_bitbang_unprepare_hardware, which are not useful anymore. Signed-off-by: Nicolas Boichat ---

[PATCH 1/3] spi: bitbang: Replace spinlock by mutex when calling chipselect

Replace spinlock + busy variable by a mutex, and get rid of spi_bitbang_prepare_hardware and spi_bitbang_unprepare_hardware, which are not useful anymore. Signed-off-by: Nicolas Boichat drink...@chromium.org --- Actually, I'm not sure if I understand the existing code: why are we not waiting

[PATCH 3/3] spi: s3c24xx: Convert spinlock to mutex

bitbang-lock is now a mutex: replace spinlock function calls by mutex functions. Signed-off-by: Nicolas Boichat drink...@chromium.org --- drivers/spi/spi-s3c24xx.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/spi/spi-s3c24xx.c b/drivers/spi/spi-s3c24xx.c index

[PATCH 2/3] spi: ppc44x: Remove chipselect from setupxfer

The chipselect operation is already done in spi_bitbang_transfer_one, or in spi_bitbang_setup, so there is no need to do it in setupxfer as well. Signed-off-by: Nicolas Boichat drink...@chromium.org --- drivers/spi/spi-ppc4xx.c | 7 --- 1 file changed, 7 deletions(-) diff --git a/drivers

Re: [PATCHv2 0/3] regmap: Use different lockdep class for each regmap init call

Hi Mark, On Wed, Jul 8, 2015 at 2:30 PM, Nicolas Boichat wrote: > Second version. Small fixup in the regmap patch itself [3/3] (the > declaration of __devm_regmap_init_ac97 was missing lock_key/name > parameters). > > Also, there are 2 drivers that are using function

Re: [PATCHv2 0/3] regmap: Use different lockdep class for each regmap init call

Hi Mark, On Wed, Jul 8, 2015 at 2:30 PM, Nicolas Boichat drink...@chromium.org wrote: Second version. Small fixup in the regmap patch itself [3/3] (the declaration of __devm_regmap_init_ac97 was missing lock_key/name parameters). Also, there are 2 drivers that are using function pointers

Re: [alsa-devel] [PATCH] ASoC: rt5645: remove unused variable

On Fri, Jul 17, 2015 at 3:23 PM, Sudip Mukherjee wrote: > We were getting a build warning about unused variable. This variable was > a leftover from: > a4e3c5fa955c ("ASoC: rt5645: Simplify rt5645_enable_push_button_irq") Yes, I already sent a patch to fix it:

Re: [alsa-devel] [PATCH] ASoC: rt5645: remove unused variable

On Fri, Jul 17, 2015 at 3:23 PM, Sudip Mukherjee sudipm.mukher...@gmail.com wrote: We were getting a build warning about unused variable. This variable was a leftover from: a4e3c5fa955c (ASoC: rt5645: Simplify rt5645_enable_push_button_irq) Yes, I already sent a patch to fix it:

[PATCH] ASoC: rt5645: Remove unused rt5645 variable

"ASoC: rt5645: Simplify rt5645_enable_push_button_irq" removes the test that accessed rt5645->pdata.jd_mode (that test is now done in rt5645_jack_detect only), so we do not need that variable anymore. Signed-off-by: Nicolas Boichat --- Applies on top of topic/rt5645. Sorry for

[PATCH] ASoC: rt5645: Remove unused rt5645 variable

ASoC: rt5645: Simplify rt5645_enable_push_button_irq removes the test that accessed rt5645-pdata.jd_mode (that test is now done in rt5645_jack_detect only), so we do not need that variable anymore. Signed-off-by: Nicolas Boichat drink...@chromium.org --- Applies on top of topic/rt5645. Sorry

[PATCH] regmap: Move documentation to regmap.h

Init functions defined in regmap*.c files are now prefixed with __, take lockdep key and class parameters, and should not be called directly: move the documentation to regmap.h, where the macros are defined. Signed-off-by: Nicolas Boichat --- Applies on top of this series: [PATCHv2 0/3] regmap

[PATCHv2 3/3] regmap: Use different lockdep class for each regmap init call

tor now clearly identifies the 2 regmaps as separate. Signed-off-by: Nicolas Boichat --- drivers/base/regmap/regmap-ac97.c | 22 +++-- drivers/base/regmap/regmap-i2c.c | 22 +++-- drivers/base/regmap/regmap-mmio.c | 27 -- drivers/base/regmap/regmap-spi.c | 22 +++-- drivers

[PATCHv2 0/3] regmap: Use different lockdep class for each regmap init call

arentheses to prevent the preprocessor from substituting them. Patches 1+2 should be pushed first to avoid breaking git bissect. Compile tested with allyesconfig on x86_64 and arm. Nicolas Boichat (3): mfd: vexpress: Add parentheses around bridge->ops->regmap_init call thermal: sti: Add pa

[PATCHv2 2/3] thermal: sti: Add parentheses around bridge->ops->regmap_init call

regmap_init(...) is a macro since commit "regmap: Use different lockdep class for each regmap init call". That same name is used as a function pointer: prevent its expansion by adding parentheses around the function pointer. Signed-off-by: Nicolas Boichat --- drivers/thermal/st/st_the

[PATCHv2 1/3] mfd: vexpress: Add parentheses around bridge->ops->regmap_init call

regmap_init(...) is a macro since commit "regmap: Use different lockdep class for each regmap init call". That same name is used as a function pointer: prevent its expansion by adding parentheses around the function pointer. Signed-off-by: Nicolas Boichat --- drivers/bus/vexpress-co

[PATCH] regmap: Move documentation to regmap.h

Init functions defined in regmap*.c files are now prefixed with __, take lockdep key and class parameters, and should not be called directly: move the documentation to regmap.h, where the macros are defined. Signed-off-by: Nicolas Boichat drink...@chromium.org --- Applies on top of this series

[PATCHv2 2/3] thermal: sti: Add parentheses around bridge-ops-regmap_init call

regmap_init(...) is a macro since commit regmap: Use different lockdep class for each regmap init call. That same name is used as a function pointer: prevent its expansion by adding parentheses around the function pointer. Signed-off-by: Nicolas Boichat drink...@chromium.org --- drivers/thermal

[PATCHv2 1/3] mfd: vexpress: Add parentheses around bridge-ops-regmap_init call

regmap_init(...) is a macro since commit regmap: Use different lockdep class for each regmap init call. That same name is used as a function pointer: prevent its expansion by adding parentheses around the function pointer. Signed-off-by: Nicolas Boichat drink...@chromium.org --- drivers/bus

[PATCHv2 0/3] regmap: Use different lockdep class for each regmap init call

to prevent the preprocessor from substituting them. Patches 1+2 should be pushed first to avoid breaking git bissect. Compile tested with allyesconfig on x86_64 and arm. Nicolas Boichat (3): mfd: vexpress: Add parentheses around bridge-ops-regmap_init call thermal: sti: Add parentheses around

[PATCHv2 3/3] regmap: Use different lockdep class for each regmap init call

identifies the 2 regmaps as separate. Signed-off-by: Nicolas Boichat drink...@chromium.org --- drivers/base/regmap/regmap-ac97.c | 22 +++-- drivers/base/regmap/regmap-i2c.c | 22 +++-- drivers/base/regmap/regmap-mmio.c | 27 -- drivers/base/regmap/regmap-spi.c | 22 +++-- drivers/base

Re: [PATCH] regmap: Use different lockdep class for each regmap init call

On Tue, Jul 7, 2015 at 8:13 PM, Mark Brown wrote: > On Wed, Jul 01, 2015 at 12:43:59PM +0800, Nicolas Boichat wrote: > >> (this also applies to all other regmap_init functions...). We do not want to >> document the lock_key/name parameters, so we could either leave it like th

Re: [PATCH] regmap: Use different lockdep class for each regmap init call

On Tue, Jul 7, 2015 at 8:13 PM, Mark Brown broo...@kernel.org wrote: On Wed, Jul 01, 2015 at 12:43:59PM +0800, Nicolas Boichat wrote: (this also applies to all other regmap_init functions...). We do not want to document the lock_key/name parameters, so we could either leave it like

[PATCH] regmap: Use different lockdep class for each regmap init call

tor now clearly identifies the 2 regmaps as separate. Signed-off-by: Nicolas Boichat --- Following up on the discussion here: http://mailman.alsa-project.org/pipermail/alsa-devel/2015-June/094124.html , and Lars-Peter's idea on how to define the macros, this converts all regmap_init calls to macr

[PATCH] regmap: Use different lockdep class for each regmap init call

identifies the 2 regmaps as separate. Signed-off-by: Nicolas Boichat drink...@chromium.org --- Following up on the discussion here: http://mailman.alsa-project.org/pipermail/alsa-devel/2015-June/094124.html , and Lars-Peter's idea on how to define the macros, this converts all regmap_init calls

<    1   2   3   4   5   6   >