Re: [PATCH] regulator: s2m,s5m: constify regulator_ops structures

On Wed, Dec 23, 2015 at 08:20:43AM +0100, Julia Lawall wrote: > On Wed, 23 Dec 2015, Mark Brown wrote: > > On Sat, Dec 19, 2015 at 03:58:00PM +0100, Julia Lawall wrote: > > > The regulator_ops structures are never modified, so declare them as const. > > > Done

Re: [PATCH] regulator: s2m,s5m: constify regulator_ops structures

On Sat, Dec 19, 2015 at 03:58:00PM +0100, Julia Lawall wrote: > The regulator_ops structures are never modified, so declare them as const. > > Done with the help of Coccinelle. This doesn't apply against current code, please check and resend. signature.asc Description: PGP signature

Re: [PATCH 2/3] dt-bindings: regulator/mfd: Reorganize S5M8767 bindings

On Fri, Dec 04, 2015 at 10:10:04AM +0900, Krzysztof Kozlowski wrote: > The regulator/s5m8767-regulator.txt duplicates some of the information > about bindings with old mfd/s2mps11.txt. Now common part exists entirely > in mfd/samsung,sec-core.txt so: Acked-by: Mark Brown <broo..

Re: [PATCH 1/3] dt-bindings: regulator/clock/mfd: Reorganize S2MPS-family bindings

; everything could be organized in a more readable way. Acked-by: Mark Brown <broo...@kernel.org> signature.asc Description: PGP signature

Re: [PATCH 3/3] dt-bindings: regulator/mfd: Reorganize S2MPA01 bindings

On Fri, Dec 04, 2015 at 10:10:05AM +0900, Krzysztof Kozlowski wrote: > The mfd/s2mpa01.txt duplicates some of the information about bindings > with old mfd/s2mps11.txt. Now common part exists entirely in > mfd/samsung,sec-core.txt so: Acked-by: Mark Brown <broo...@kernel.org> &

Re: [PATCH 00/10] ARM: s3c64xx multiplatform

On Wed, Nov 25, 2015 at 05:06:45PM +0100, Arnd Bergmann wrote: > I've posted the series before and we got a few people to test it > the last time, though I think the touchscreen portion is still > untested. > > I'd really like to get this merged for 4.5 and would put it into > a

Re: [RESEND PATCH v5 2/3] regulator: s2mps11: add support for S2MPS15 regulators

interface. This patch adds initial support for LDO/Buck regulators of > S2MPS15 PMIC. Acked-by: Mark Brown <broo...@kernel.org> signature.asc Description: PGP signature

Re: [PATCH v3 3/3] ASoC: samsung: pass filter function as pointer

On Wed, Nov 18, 2015 at 03:26:41PM +0100, Arnd Bergmann wrote: > As we are now passing the filter data as pointers to the drivers, > we can take the final step and also pass the filter function the > same way. I'm keeping this change separate, as there it's less > obvious that this is a net win.

Re: [PATCH v2] mfd: sec-core: Rename MFD and regulator names differently

On Mon, Nov 02, 2015 at 09:36:09AM +0530, Alim Akhtar wrote: > Currently S2MPSXX multifunction device is named as *-pmic, > and these MFDs also supports regulator as a one of its MFD cell which > has the same name, because current name is confusing and we want to > sort it out. Ac

Re: [PATCH v3 5/5] drivers/rtc/rtc-s5m.c: add support for S2MPS15 RTC

On Wed, Oct 28, 2015 at 10:29:56AM +0900, Krzysztof Kozlowski wrote: > If that's true, then don't add new compatibles, new names etc. Re-use. > No new code needed, no changes needed. Keep it simple. Well, it depends - it can be useful to get the information about it being a different part into

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

On Mon, Aug 31, 2015 at 03:54:13PM +0800, Nicolas Boichat wrote: > On Mon, Aug 17, 2015 at 11:52 AM, Nicolas Boichat > wrote: > Any update on this patch? It still applies on for-next but happy to > resend if necessary (patchwork: >

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

On Wed, Aug 05, 2015 at 06:24:05PM +0800, Nicolas Boichat wrote: Anyway, the safer way to fix this would be to keep the prepare/unprepare functions, busy variable, and just protect it with a mutex instead of a spinlock... OK, that seems reasonable. signature.asc Description: Digital

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

On Tue, Aug 04, 2015 at 02:09:58PM +0800, Nicolas Boichat wrote: bitbang-lock is now a mutex: replace spinlock function calls by mutex functions. This would need to be combined with the first patch, individual patches shouldn't break the build. signature.asc Description: Digital signature

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

On Tue, Aug 04, 2015 at 02:09:56PM +0800, Nicolas Boichat wrote: Enabling CONFIG_DEBUG_ATOMIC_SLEEP in kernel configuration, we get this warning in spi_gpio_setup: [1.177747] BUG: sleeping function called from invalid context at drivers/gpio/gpiolib.c:1431 [1.190182] in_atomic(): 1,

Re: [RFC PATCH 2/2] dt: spi: s3c64xx: add compatible to controller-data

On Thu, Jul 30, 2015 at 10:24:37AM +0200, Michal Suchanek wrote: So my suggestion is to 1) search of ofpart subnode in mtd node. If present read address and reg from it and search partitions as subnodes of the ofpart node. In this case unknown nodes can cause error. 2) failing that issue a

Re: [RFC PATCH 2/2] dt: spi: s3c64xx: add compatible to controller-data

On Thu, Jul 30, 2015 at 09:50:51AM +0200, Boris Brezillon wrote: Since you have to patch your DTs anyway, how about putting your partitions in a subnode and patch the ofpart code to parse this subnode if it is present (see the following patch). This is the best idea, yes - if we're changing

Re: [RFC PATCH 2/2] dt: spi: s3c64xx: add compatible to controller-data

On Wed, Jul 29, 2015 at 06:19:24PM +0200, Michal Suchanek wrote: On 29 July 2015 at 16:00, Mark Brown broo...@kernel.org wrote: I can't tell from this commit message what the issue you're trying to fix is, sorry. Nodes without compatible strings are entirely normal and don't need

Re: [RFC PATCH 2/2] dt: spi: s3c64xx: add compatible to controller-data

On Wed, Jul 29, 2015 at 08:21:34PM +0200, Michal Suchanek wrote: On 29 July 2015 at 19:16, Mark Brown broo...@kernel.org wrote: It will not break anything. It will just spam dmesg. I'm confused - if all this change does is to spam dmesg then what's the point? Presumably when your SPI

Re: [RFC PATCH 2/2] dt: spi: s3c64xx: add compatible to controller-data

On Wed, Jul 29, 2015 at 12:19:57PM +0200, Michal Suchanek wrote: Please use subject lines matching the style for the subsytsem so people can spot that the patch is in some way relevant. The controller-data subnode has no compatible. This can lead to other drivers getting confused by it. Add a

Re: [PATCH v2 2/2] spi: s3c64xx: add more debug prints.

On Tue, Jul 28, 2015 at 09:37:03AM -, Michal Suchanek wrote: The SPI transfers can mysteriously fail so add more debug prints about SPI parameters set by the driver. The hardware specific SPI driver is the only place where the programmed SPI parameters are known so there is no other

Re: [PATCH v2 1/4] mfd: max77686: Don't suggest in binding to use a deprecated property

On Mon, Jul 27, 2015 at 12:28:07PM +0200, Javier Martinez Canillas wrote: On 07/20/2015 12:12 PM, Javier Martinez Canillas wrote: This PMIC uses a single I2C address for all the regulators and these are controlled by writing to different I2C register addresses. So the regulator nodes don't

Re: [PATCH] regulator: s2mps11: Fix GPIO suspend enable shift wrapping bug

On Wed, Jun 24, 2015 at 01:02:28PM +0900, Krzysztof Kozlowski wrote: 2015-05-28 23:44 GMT+09:00 Mark Brown broo...@kernel.org: On Wed, May 27, 2015 at 12:22:08PM +0900, Krzysztof Kozlowski wrote: Status of enabling suspend mode for regulator was stored in bitmap-like long integer

Re: [PATCH RESEND] regulator: s2mps11: Fix GPIO suspend enable shift wrapping bug

On Wed, Jun 24, 2015 at 07:48:43PM +0900, Krzysztof Kozlowski wrote: From: Krzysztof Kozlowski k.kozlow...@samsung.com Status of enabling suspend mode for regulator was stored in bitmap-like long integer. Applied, thanks. signature.asc Description: Digital signature

Re: [PATCH 10/11] spi: add more debug prints in s3c64xx

On Thu, Jun 04, 2015 at 11:33:37AM +0200, Michal Suchanek wrote: On 4 June 2015 at 11:16, Mark Brown broo...@kernel.org wrote: Also for this patch (which just adds some trace) there isn't any clear reason for it to be sent as part of the series at all, it doesn't help deliver

Re: [PATCH 10/11] spi: add more debug prints in s3c64xx

On Thu, Jun 04, 2015 at 12:52:19PM +0200, Michal Suchanek wrote: There is no code interdependency with the other patches so if it's preferred I can send patches like this separately. Yes, that's better practice. signature.asc Description: Digital signature

Re: [PATCH 10/11] spi: add more debug prints in s3c64xx

On Wed, Jun 03, 2015 at 09:26:42PM -, Michal Suchanek wrote: The SPI NOR transfers mysteriously fail so add more debug prints about SPI transactions. Please try to only send patches to relevant people - the list of recipients for this is so large that it only barely fits on a single screen

Re: [PATCH 10/11] spi: add more debug prints in s3c64xx

On Thu, Jun 04, 2015 at 11:30:15AM +0200, Geert Uytterhoeven wrote: On Thu, Jun 4, 2015 at 11:16 AM, Mark Brown broo...@kernel.org wrote: --- a/drivers/spi/spi-s3c64xx.c +++ b/drivers/spi/spi-s3c64xx.c @@ -18,6 +18,7 @@ #include linux/interrupt.h #include linux/delay.h #include

Re: [PATCH] regulator: s2mps11: Fix GPIO suspend enable shift wrapping bug

On Wed, May 27, 2015 at 12:22:08PM +0900, Krzysztof Kozlowski wrote: Status of enabling suspend mode for regulator was stored in bitmap-like long integer. Applied, thanks. signature.asc Description: Digital signature

Re: [RFC PATCH 1/4] spi: spidev: Add Google SPI flash compatible string

On Wed, May 20, 2015 at 01:21:53PM +0200, Javier Martinez Canillas wrote: The ChromeOS user-space just uses flashrom to send a raw stream of bytes via spidev to the SPI NOR flash chip. There is drivers/mtd/spi-nor/spi-nor.c but AFAIU there are some limitations when interfacing the flash

Re: [RFC PATCH 1/4] spi: spidev: Add Google SPI flash compatible string

On Tue, May 19, 2015 at 03:34:11PM +0200, Javier Martinez Canillas wrote: Google Chromebooks have a SPI flash that is used to store firmware and different system parameters and data (i.e: Google Binary Block flags). --- drivers/spi/spidev.c | 1 + 1 file changed, 1 insertion(+) This is

Re: [PATCH] ASoC: samsung: s3c24xx-i2s: Fix return value check in s3c24xx_iis_dev_probe()

On Thu, Apr 16, 2015 at 08:18:02PM +0800, weiyj...@163.com wrote: From: Wei Yongjun yongjun_...@trendmicro.com.cn In case of error, the function devm_ioremap_resource() returns ERR_PTR() and never returns NULL. The NULL test in the return value check should be replaced with IS_ERR().

Re: [PATCH] ARM: S3C64XX: Use fixed IRQ bases to avoid conflicts on Cragganmore

this by statically assigning both the IRQ bases. Signed-off-by: Charles Keepax ckee...@opensource.wolfsonmicro.com Reviwed-by: Mark Brown broo...@kernel.org This probably wants to go to stable as well. signature.asc Description: Digital signature

Re: [PATCH 05/10] ARM: s3c64xx: enable sparse IRQ support

On Sat, Mar 21, 2015 at 04:38:21PM +, Charles Keepax wrote: So adding a bit of an offset into the PMIC with the fixed IRQ base fixes the problem. Although I am not sure if it would be better to move both PMICs onto a fixed IRQ base so there is no chance of the clashing. Any thoughts?

Re: [PATCH] ASoC: samsung: Enable SND_SIMPLE_CARD for Odroid X2/U3

On Wed, Mar 18, 2015 at 11:52:19AM +0100, Sylwester Nawrocki wrote: Odroid X2/U3 sound support can now be specified in device tree using the simple card binding, make SND_SOC_ODROIDX2 select SND_SIMPLE_CARD to ensure there are always required drivers in place. No, this isn't an actual

Re: [PATCH 05/10] ARM: s3c64xx: enable sparse IRQ support

crag6410_machine_init(void) MACHINE_START(WLF_CRAGG_6410, Wolfson Cragganmore 6410) /* Maintainer: Mark Brown broo...@opensource.wolfsonmicro.com */ .atag_offset= 0x100, - .nr_irqs= S3C64XX_NR_IRQS + 160, + .nr_irqs= S3C64XX_NR_IRQS, .init_irq

Re: [PATCH 05/10] ARM: s3c64xx: enable sparse IRQ support

On Fri, Mar 06, 2015 at 05:43:16PM +, Charles Keepax wrote: Cragganmore, I need to look into it a bit more but it looks like one of the PMICs can't allocate its IRQs: [0.961455] wm831x 1-0034: WM8311 revision C [0.965066] wm831x 1-0034: Failed to allocate IRQs: -17 And the

Re: [PATCH 02/10] ASoC: samsung/smartq: use dynamic registration

. Acked-by: Mark Brown broo...@kernel.org signature.asc Description: Digital signature

Re: [PATCH 00/10] ARM: s3c64xx multiplatform, help needed

On Mon, Mar 02, 2015 at 01:35:53PM +0100, Arnd Bergmann wrote: Does anyone still have access to the hardware? I'm particularly interested in seeing this patch set get tested on smartq and on smdk6410, which have the majority of the hardware. I and a bunch of other people still have

Re: [PATCH] drivers: spi: fix compiler warning in spi-s3c64xx

On Mon, Feb 23, 2015 at 12:30:46PM +, Andre Przywara wrote: The Exynos 7 arm64 support now allows the S3C64xx SPI driver to be compiled into an ARM64 kernel, so the cast from the [rt]x_dmach int variable to a void* in this driver now triggers a warning. Add a long cast to silence the

Re: [PATCH v2] ASoC: Samsung: add missing I2C/SPI dependencies

On Wed, Feb 18, 2015 at 09:35:08PM +0100, Arnd Bergmann wrote: A few sound drivers for the samsung platforms are missing dependencies on I2C or SPI, which can lead to build errors like Applied, thanks. signature.asc Description: Digital signature

Re: [PATCH 5/6] ASoC: samsung: Extend Snow driver to support max98089

On Thu, Feb 19, 2015 at 09:44:08AM -0800, Doug Anderson wrote: On Thu, Feb 19, 2015 at 1:44 AM, Mark Brown broo...@kernel.org wrote: I think what you're suggesting is that here we should add a new compatible string google,snow-audio instead of adding google,snow-audio-max98089 here

Re: [PATCH 5/6] ASoC: samsung: Extend Snow driver to support max98089

On Wed, Feb 18, 2015 at 07:25:58PM +0100, Andreas Färber wrote: static const struct of_device_id snow_of_match[] = { + { .compatible = google,snow-audio-max98089, }, { .compatible = google,snow-audio-max98090, }, { .compatible = google,snow-audio-max98091, }, {

Re: [PATCH 0/4] ASoC: samsung: clean up references to outdated Kconfig symbols

On Wed, Feb 11, 2015 at 10:21:38AM +0100, Paul Bolle wrote: TL;DR: what exactly should I resend and when? This is disappointing; you're someone who's been contributing for quite some time now, I'd really expect you to be faimilar with the process of submitting patches and able to identify

Re: [RESEND PATCH V3 13/15] ARM: dts: Exynos4 and Odroid X2/U3 sound device nodes update

On Tue, Feb 03, 2015 at 03:06:20PM +0100, Sylwester Nawrocki wrote: Clock related properties are added to the Exynos4 I2S device nodes so they can be referred to as clock providers. Missing i2s_opclk1 clock is added to the I2S0 node and clock properties are added to the MAX98090 codec node to

Re: [RESEND PATCH V3 14/15] ARM: dts: Switch Odroid X2/U2 to simple-audio-card

On Tue, Feb 03, 2015 at 03:06:21PM +0100, Sylwester Nawrocki wrote: Now when the CDCLK I2S output clock can be handled through the clock API the Odroid X2/U3 can be switched to the simple-audio-card DT binding. Applied, thanks. signature.asc Description: Digital signature

Re: [PATCH 0/4] ASoC: samsung: clean up references to outdated Kconfig symbols

On Sat, Feb 07, 2015 at 09:38:04AM +0100, Paul Bolle wrote: Patches 2/4, 3/4, and 4/4 didn't apply. Locally I carry them in a tree that constantly rebases on top of linux-next. So locally I carry these patches on top of next-20150204. What's posted doesn't apply against -next. What tree

Re: [PATCH 4/4] ASoC: samsung: remove outdated Kconfig references

On Mon, Jan 19, 2015 at 11:43:02AM +0100, Paul Bolle wrote: The Kconfig symbols MACH_SMDKC110 and MACH_SMDKV210 were removed in v3.17. But the Kconfig entries for SND_SOC_SAMSUNG_SMDK_WM8580 and SND_SOC_SAMSUNG_SMDK_WM9713 still reference them. This doesn't apply against current code.

Re: [PATCH 0/4] ASoC: samsung: clean up references to outdated Kconfig symbols

On Mon, Jan 19, 2015 at 11:41:07AM +0100, Paul Bolle wrote: A few series of ARM cleanups regarding S5PC100 and S5PV210 were included in v3.17. These series removed these five Kconfig symbols: MACH_AQUILA MACH_GONI MACH_SMDKC100 MACH_SMDKC110 MACH_SMDKV210 This series,

Re: [PATCH 2/4] ASoC: samsung: Remove PCM support for WM8580 on SMDK

On Mon, Jan 19, 2015 at 11:42:07AM +0100, Paul Bolle wrote: Commit 28c8331d386a (ARM: S5PV210: Remove support for board files) removed the Kconfig symbols MACH_SMDKC110 and MACH_SMDKV210. As a result the dependencies of SND_SOC_SMDK_WM8580_PCM can never be met. So remove the unbuildable SoC

Re: [PATCH 3/4] ASoC: samsung: MACH_SMDKC100 isn't supported anymore

On Mon, Jan 19, 2015 at 11:42:45AM +0100, Paul Bolle wrote: Commit b8529ec1c1b0 (ARM: S5PC100: no more support S5PC100 SoC) removed Kconfig symbol MACH_SMDKC100. But there are still two references to that symbol left. These are now pointless. Remove them too. This doesn't apply against current

Re: [PATCH 1/4] ASoC: samsung: Remove goni or aquila with the WM8994

On Mon, Jan 19, 2015 at 11:41:41AM +0100, Paul Bolle wrote: Commit 28c8331d386a (ARM: S5PV210: Remove support for board files) removed the Kconfig symbols MACH_GONI and MACH_AQUILA. As a result the dependencies of SND_SOC_GONI_AQUILA_WM8994 can never be met. So remove the unbuildable SoC I2S

Re: [RESEND PATCH V3 15/15] ARM: dts: Fix I2S1, I2S2 compatible for exynos4 SoCs

On Fri, Feb 06, 2015 at 12:30:45PM +0100, Sylwester Nawrocki wrote: Thank you for merging it. I hope you picked up the previous 2 as well, I couldn't see them in your tree. I probably will if I don't hear anything but since they don't need to go as a bug fix I can leave Kukjin a bit longer to

Re: [RESEND PATCH V3 15/15] ARM: dts: Fix I2S1, I2S2 compatible for exynos4 SoCs

On Tue, Feb 03, 2015 at 03:06:22PM +0100, Sylwester Nawrocki wrote: I2S1, I2S2 on Exynos4 SoC series have limited functionality compared to I2S0, samsung,s3c6410-i2s compatible should be used for them. I've applied this even though I really shouldn't in order to get it in. Since it's a bug fix

Re: [PATCH V3 13/15] ARM: dts: Exynos4 and Odroid X2/U3 sound device nodes update

On Tue, Feb 03, 2015 at 03:05:36PM +0100, Sylwester Nawrocki wrote: On 03/02/15 14:11, Mark Brown wrote: OK, I can apply them if people want but I'd need a resend - I discarded them since they'd normally go via the arch tree. I will resend the last 3 patches then. There also shouldn't

Re: [PATCH V3 13/15] ARM: dts: Exynos4 and Odroid X2/U3 sound device nodes update

On Tue, Feb 03, 2015 at 12:04:16PM +0100, Sylwester Nawrocki wrote: Sorry, I should've said - I applied the ASoC patches, not these. Shall I take 13 to 15 DT patches in Samsung tree? Patches 13, 14 use macro definitions which are added in patch which is already in Mark's sound tree (ASoC:

Re: [PATCH] ASoC: Samsung: add missing I2C/SPI dependencies

On Wed, Jan 28, 2015 at 10:28:55PM +0100, Arnd Bergmann wrote: The SND_SOC_ARNDALE_RT5631_ALC5631 selects the rt5631 codec that requires I2C to work, so we get a build error if I2C is disabled: You rather buried the lead about there being other drivers in this changelog, makes the code a bit

Re: [alsa-devel] [PATCH v4 1/3] ASoC: samsung: Add machine driver for Trats2

On Tue, Jan 27, 2015 at 06:09:39PM +0100, Sylwester Nawrocki wrote: On 23/01/15 06:03, Inha Song wrote: + priv-clk_mclk = of_clk_get_by_name(codec_node, MCLK1); + if (IS_ERR(priv-clk_mclk)) { + dev_err(pdev-dev, Failed to get mclk clock\n); +

Re: [RFC 2/3] regmap: Use the enhancement of i2c API to address circular dependency problem

On Tue, Jan 20, 2015 at 12:14:31PM +0100, Paul Osmialowski wrote: On Mon, 19 Jan 2015, Mark Brown wrote: OK, so that's what should go in the changelog (along with an explanation of why this preparation is required at all) - but I still don't see the async bit of this I'm afraid. I don't

Re: [alsa-devel] [PATCH v4 2/3] ASoC: samsung: Document Trats2 audio subsystem bindings

On Fri, Jan 23, 2015 at 02:03:29PM +0900, Inha Song wrote: + - samsung,audio-routing : A list of the connections between audio + components. each entry is a pair of strings, the first being the + connection's sink, the second being the connection's source The list of valid components

Re: [alsa-devel] [PATCH v4 1/3] ASoC: samsung: Add machine driver for Trats2

On Fri, Jan 23, 2015 at 02:03:28PM +0900, Inha Song wrote: This patch add the sound machine driver for Trats2 board. The codec operate in master mode. This looks like (and mostly should be) a DTified copy of the littlemill driver. The major differences are the fact that this lacks jack

Re: [RFC 2/3] regmap: Use the enhancement of i2c API to address circular dependency problem

On Mon, Jan 19, 2015 at 10:31:22AM +0100, Paul Osmialowski wrote: On Fri, 16 Jan 2015, Mark Brown wrote: What I'm saying is that I want to understand this change from a point of view that isn't tied to I2C - at the regmap level what is this doing, From the regmap point of view, it allows its

Re: [RFC 1/3] i2c: Enhancement of i2c API to address circular lock dependency problem

On Sun, Jan 18, 2015 at 11:54:56AM +0100, Krzysztof Kozlowski wrote: W dniu 18.01.2015 o 07:30, Tomasz Figa pisze: So, the question is, do we actually have hardware that _really_ requires _actual_ preparation or all the clk_prepare_enable()s in I2C drivers (at least in i2c-s3c2410) are just

Re: [PATCH V3 00/15] ASoC: samsung: Add clk provider for I2S internal clocks

On Wed, Jan 14, 2015 at 07:42:27PM +0100, Sylwester Nawrocki wrote: This series is an attempt to resolve the CDCLK clock gating issue on Odroid X2/U3 as reported by Daniel Drake [1], by exposing the CDCLK gate clock (and the two other clocks) through clk API. The upside is we can switch Odroid

Re: [PATCH V3 13/15] ARM: dts: Exynos4 and Odroid X2/U3 sound device nodes update

On Wed, Jan 14, 2015 at 07:42:40PM +0100, Sylwester Nawrocki wrote: Clock related properties are added to the Exynos4 I2S device nodes so they can be referred to as clock providers. Missing i2s_opclk1 clock is added to the I2S0 node and clock properties are added to the MAX98090 codec node to

Re: [PATCH v5 0/5] regulator: Allow parsing custom DT properties with simplified DT parse

On Mon, Jan 05, 2015 at 12:48:40PM +0100, Krzysztof Kozlowski wrote: Hi, The patchset adds: 1. a way of parsing custom DT properties by the driver when simplified DT parsing method is used, 2. GPIO enable control to the max77686 driver. Applied 1-4, thanks. signature.asc

Re: [PATCH v2 16/16] ARM: dts: Fix I2S1, I2S2 compatible for exynos4 SoCs

On Fri, Dec 19, 2014 at 02:55:36PM +0100, Sylwester Nawrocki wrote: I2S1, I2S2 on Exynos4 SoC series have limited functionality compared to I2S0, samsung,s3c6410-i2s compatible should be used for them. Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com --- This should probably go to

Re: [PATCH v2 01/16] ASoC: samsung: i2s: Remove unused gpios field from struct i2s

On Fri, Dec 19, 2014 at 02:55:21PM +0100, Sylwester Nawrocki wrote: The 'gpios' field in 'struct i2s' is now unused, this change seems to be missing in commit 0429ffeff460c4302bd1520e6 (ASoC: samsung: Remove obsolete GPIO based DT pinmuxing). Applied, thanks. signature.asc Description:

Re: [PATCH v2 06/16] ASoC: samsung: i2s: Move clk enable to the platform driver probe()

On Fri, Dec 19, 2014 at 02:55:26PM +0100, Sylwester Nawrocki wrote: Gating the I2S bus clock in the driver's runtime PM callbacks has currently really no effect since the clock is being enabled in the DAI's probe() and thus is permanently turned on. Now we just move the enable to the platform

Re: [PATCH v2 02/16] ASoC: samsung: i2s: samsung_i2s_get_driver_data() cleanup

On Fri, Dec 19, 2014 at 02:55:22PM +0100, Sylwester Nawrocki wrote: Tidy up the samsung_i2s_get_driver_data() function by using IS_ENABLE() instead of #ifdef and add missing braces for the 'else' part. Also ensure we are not dereferencing NULL 'match' pointer. This doesn't apply against

Re: [PATCH v2 00/16] ASoC: samsung: Add clk provider for I2S internal clocks

On Fri, Dec 19, 2014 at 02:55:20PM +0100, Sylwester Nawrocki wrote: This series is an attempt to resolve the CDCLK clock gating issue on Odroid X2/U3 as reported by Daniel Drake [1], by exposing the CDCLK gate clock (and the two other clocks) through clk API. This all looks basically fine

Re: [alsa-devel] [PATCH 2/3] ASoC: samsung: Document Trats2 audio subsystem bindings

On Mon, Jan 05, 2015 at 08:25:16PM +0900, Inha Song wrote: + - clocks : Reference to the codec master clock + - clock-names : The clock should be named mclk This should be done in the CODEC driver, not in the machine driver - the CODEC always needs the clock, it's not something specific to

Re: [PATCH 27/28] ASoC: samsung: drop owner assignment from platform_drivers

On Sun, Dec 21, 2014 at 10:14:48PM +0100, Wolfram Sang wrote: This platform_driver does not need to set an owner, it will be populated by the driver core. Applied, thanks. signature.asc Description: Digital signature

Re: [RFC 02/15] drivers/base: add restrack framework

On Mon, Dec 15, 2014 at 09:28:41AM +0100, Andrzej Hajda wrote: On 12/12/2014 05:52 PM, Mark Brown wrote: On Wed, Dec 10, 2014 at 04:48:20PM +0100, Andrzej Hajda wrote: I don't know about anyone else but I'm having a hard time reading the restrack name, it looks like a misspelling

Re: [RFC 01/15] drivers/base: add track framework

On Sat, Dec 13, 2014 at 12:12:19AM +0100, AH wrote: Mark Brown wrote on 12.12.2014 17:36: On Wed, Dec 10, 2014 at 04:48:19PM +0100, Andrzej Hajda wrote: + kfree(ptask); + + if (empty) + break; + + track_process_task(track, task); ...we

Re: [PATCH] iommu/exynos: Fix arm64 allmodconfig build

On Mon, Dec 15, 2014 at 02:10:37PM +0100, Krzysztof Kozłowski wrote: Hi Mark, Few days ago I posted similar patch: https://lkml.org/lkml/2014/12/5/268 but no one have picked it up. Anyway the fix of yours seems fine to me. I don't mind either way, it just seemed to be easier to report the

[PATCH] iommu/exynos: Fix arm64 allmodconfig build

dependencies removed or the ARMv8 architecture code implements these ARM specific APIs. Signed-off-by: Mark Brown broo...@kernel.org --- Resending to the arm-soc people since the addition of the Exynos platform for ARMv8 went via them, Krzysztof also sent a fix for this earlier but it there's been

Re: [PATCH] iommu/exynos: Fix arm64 allmodconfig build

On Mon, Dec 15, 2014 at 03:38:04PM +, Will Deacon wrote: On Mon, Dec 15, 2014 at 03:35:29PM +, Mark Brown wrote: I don't mind either way, it just seemed to be easier to report the bug with a patch. If Jeorg is busy perhaps it can go via the arm64 tree, the issue is triggered

Re: [RFC 01/15] drivers/base: add track framework

On Wed, Dec 10, 2014 at 04:48:19PM +0100, Andrzej Hajda wrote: track is a generic framework for safe tracking presence of any kernel objects having an id. There are no special requirements about type of object or its id. Id shall be unique. This is pretty confusing, when it talks about kernel

Re: [RFC 02/15] drivers/base: add restrack framework

On Wed, Dec 10, 2014 at 04:48:20PM +0100, Andrzej Hajda wrote: restrack framework allows tracking presence of resources with dynamic life time. Typical example of such resources are all resources provided by device I don't know about anyone else but I'm having a hard time reading the restrack

Re: [PATCH/RFC 04/14] ASoC: samsung: i2s: Request memory region in driver probe()

On Thu, Dec 11, 2014 at 06:45:42PM +0100, Sylwester Nawrocki wrote: The memory mapped registers region is common for both DAIs so request it in the I2S platform device driver's probe for the platform device corresponding to the primary DAI, rather than in the ASoC DAI's probe callback. While

Re: [PATCH/RFC 11/14] ASoC: samsung: odroidx2: Handle I2S CDCLK clock conditionally

On Thu, Dec 11, 2014 at 06:45:49PM +0100, Sylwester Nawrocki wrote: If the codec control it's master clock provider by the I2S module we should not be touching it with set_sysclk() calls. So skip the set_sysclk() call in the machine driver if clocks property is found in the codec device node.

Re: [alsa-devel] [PATCH/RFC 12/14] ASoC: samsung: i2s: Add clock provider for the I2S internal clocks

On Thu, Dec 11, 2014 at 06:45:50PM +0100, Sylwester Nawrocki wrote: +Optional Properties: - samsung,idma-addr: Internal DMA register base address of the audio sub system(used in secondary sound source). - pinctrl-0: Should specify pin control groups used for this controller. -

Re: [RFC 04/15] regulator: add restrack support

On Wed, Dec 10, 2014 at 04:48:22PM +0100, Andrzej Hajda wrote: Regulators supports various methods of lookup. The patch adds restrack support only to DT based regulators. Why, what does this mean and how might one use it? I've not looked at the code since I don't know what it's supposed to

Re: [PATCH] ASoC: samsung: i2s: Add missing assignment of variant_regs

On Mon, Dec 08, 2014 at 06:45:54PM +0100, Sylwester Nawrocki wrote: Add assignment of the variant_regs field which is missing in commit a5a56871f804edac93a53b5e871c0e9818fb9033 (ASoC: samsung: add support for exynos7 I2S controller). Without this attempting to probe the secondary DAI fails

[PATCH] spi/s3c64xx: Remove redundant runtime PM management

The device already asks the core to hold a runtime PM reference while it is active so it is redundant to open code that in the driver itself. Signed-off-by: Mark Brown broo...@kernel.org --- drivers/spi/spi-s3c64xx.c | 9 - 1 file changed, 9 deletions(-) diff --git a/drivers/spi/spi

Re: [PATCH v4 2/7] regulator: dt-bindings: Document the ena-gpios property

On Fri, Nov 28, 2014 at 10:09:44AM +0100, Krzysztof Kozlowski wrote: I understand your concerns here however I didn't want to overengineer this. Is the same GPIO (on more complex PMICs) used in different contexts? Like enable control and something more in the same time? Yes, and it's often

Re: [PATCH v4 4/7] regulator: Use ena_gpio supplied with generic regulator bindings

On Fri, Nov 28, 2014 at 11:30:55AM +0100, Krzysztof Kozlowski wrote: On czw, 2014-11-27 at 18:43 +, Mark Brown wrote: Why do we need some special magic operation for GPIO based enables that's separate to any other enable operation? This seems really confusing, if the constraint

Re: [PATCH v4 2/7] regulator: dt-bindings: Document the ena-gpios property

On Fri, Nov 28, 2014 at 12:54:27PM +0100, Krzysztof Kozlowski wrote: On pią, 2014-11-28 at 11:21 +, Mark Brown wrote: On Fri, Nov 28, 2014 at 10:09:44AM +0100, Krzysztof Kozlowski wrote: I understand your concerns here however I didn't want to overengineer this. Is the same GPIO

Re: [PATCH v4 4/7] regulator: Use ena_gpio supplied with generic regulator bindings

On Fri, Nov 28, 2014 at 03:14:04PM +0100, Krzysztof Kozlowski wrote: On pią, 2014-11-28 at 11:38 +, Mark Brown wrote: This sort of thing is a sign that we're not saving much by moving the parsing to the core and perhaps there's more flexiblity here... The driver receive callbacks

Re: [PATCH v4 1/7] mfd: max77686/802: Remove support for board files

On Thu, Nov 27, 2014 at 12:20:47PM +0100, Krzysztof Kozlowski wrote: The driver is used only on Exynos based boards with DTS support. After removal of board file support from max77686 and max77802 regulator drivers, the MFD driver can be converted to DTS-only version. This simplifies a little

Re: [PATCH v4 2/7] regulator: dt-bindings: Document the ena-gpios property

On Thu, Nov 27, 2014 at 12:20:48PM +0100, Krzysztof Kozlowski wrote: +- ena-gpios: GPIO to use for enable control. Actual implementation depends + on regulator driver. The bindings documentation for given driver describes + which regulator actually supports it. +- ena-gpio-open-drain: GPIO

Re: [PATCH v4 4/7] regulator: Use ena_gpio supplied with generic regulator bindings

On Thu, Nov 27, 2014 at 12:20:50PM +0100, Krzysztof Kozlowski wrote: Use ena_gpio from regulator constraints (filled by parsing generic bindings) to initialize the GPIO enable control. Support also the old way: ena_gpio supplied in regulator_config structure. This also adds a new

Re: [PATCH v4 3/7] regulator: of: Parse ena-gpios property from DTS

On Thu, Nov 27, 2014 at 12:20:49PM +0100, Krzysztof Kozlowski wrote: + constraints-ena_gpio = of_get_named_gpio_flags(np, ena-gpios, 0, + gpio_flags); + if (gpio_is_valid(constraints-ena_gpio)) { No, this isn't sensible - in what way

Re: [PATCH] ASoC: Samsung: Add arndale_rt5631 machine driver and binding

On Wed, Nov 26, 2014 at 02:53:04PM +0530, Krishna Mohan Dani wrote: Adding machine driver to instantiate I2S based realtek's ALC5631 sound card on Arndale board. Applied, thanks. signature.asc Description: Digital signature

Re: [PATCH] ASoC: rt5631: Fixing compilation warning when DT is disabled

On Wed, Nov 26, 2014 at 02:26:07PM +0530, D Krishna Mohan wrote: Following your suggestion I have sent a patch (187024b36c635bd454c1b1587b58c9439d3a46ad on your git, branch: rt5631 ) using ifdef which you have already applied. Since there are more suggestion asking for second (__maybe_unused)

Re: [PATCH v6 0/5] regulator: of: Add initial and suspend modes support

On Mon, Nov 10, 2014 at 02:43:50PM +0100, Javier Martinez Canillas wrote: Hello Mark, This is the sixth version of the series that adds regulator initial and suspend operating modes support. It relies on the existing work that added suspend states bindings. The opmodes are parsed by the

Re: [PATCH] spi: s3c64xx: add support for exynos7 SPI controller

On Thu, Nov 06, 2014 at 03:21:49PM +0530, Padmavathi Venna wrote: Exynos7 SPI controller supports only the auto Selection of CS toggle mode and Exynos7 SoC includes six SPI controllers. Add support for these changes in Exynos7 SPI controller driver. Applied, thanks. It does seem like these

Re: [PATCH 2/3] regulator: max77802: Fill regulator modes translation callback

On Tue, Nov 11, 2014 at 01:04:44PM +0100, Javier Martinez Canillas wrote: The max77802 PMIC regulators output can be configured in one of two modes: Output ON (normal) and Output ON in Low Power Mode. Some of Applied, thanks. signature.asc Description: Digital signature

Re: [PATCH 1/3] regulator: max77802: Document binding for regulator operating modes

On Tue, Nov 11, 2014 at 01:04:43PM +0100, Javier Martinez Canillas wrote: Some regulators from the max77802 PMIC support to be configured in one of two operating mode: Output ON (normal) and Output On Low Power Mode. Applied, thanks. signature.asc Description: Digital signature

Re: [PATCH] ASoC: rt5631: Fixing compilation warning when DT is disabled

On Mon, Nov 24, 2014 at 12:48:31PM +0530, D Krishna Mohan wrote: Attaching the patch with changes suggested by Uwe. Though there is another patch which I submitted, but I leave it to Mark Brown as to which patch to pick. Please send patches in the format covered in SubmittingPatches, the tools

  1   2   3   4   5   6   7   8   9   10   >