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
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
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
> - add company prefix
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
sign
; everything could be organized in a more readable way.
Acked-by: Mark Brown
signature.asc
Description: PGP signature
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 next/multiplatform
ial support for LDO/Buck regulators of
> S2MPS15 PMIC.
Acked-by: Mark Brown
signature.asc
Description: PGP signature
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.
T
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
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 DT
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:
> https://patchwork.kernel.org/patch/7023091/).
Please don't send
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 sig
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():
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
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 iss
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
On Wed, Jul 29, 2015 at 08:21:34PM +0200, Michal Suchanek wrote:
> On 29 July 2015 at 19:16, Mark Brown 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?
&g
On Wed, Jul 29, 2015 at 06:19:24PM +0200, Michal Suchanek wrote:
> On 29 July 2015 at 16:00, Mark Brown 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
> >
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
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
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
On Wed, Jun 24, 2015 at 07:48:43PM +0900, Krzysztof Kozlowski wrote:
> From: Krzysztof Kozlowski
>
> Status of enabling suspend mode for regulator was stored in bitmap-like
> long integer.
Applied, thanks.
signature.asc
Description: Digital signature
On Wed, Jun 24, 2015 at 01:02:28PM +0900, Krzysztof Kozlowski wrote:
> 2015-05-28 23:44 GMT+09:00 Mark Brown :
> > 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
> >>
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
On Thu, Jun 04, 2015 at 11:33:37AM +0200, Michal Suchanek wrote:
> On 4 June 2015 at 11:16, Mark Brown 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
> >
On Thu, Jun 04, 2015 at 11:30:15AM +0200, Geert Uytterhoeven wrote:
> On Thu, Jun 4, 2015 at 11:16 AM, Mark Brown wrote:
> >> --- a/drivers/spi/spi-s3c64xx.c
> >> +++ b/drivers/spi/spi-s3c64xx.c
> >> @@ -18,6 +18,7 @@
> >> #include
> >> #includ
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
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
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 thro
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
On Thu, Apr 16, 2015 at 08:18:02PM +0800, weiyj...@163.com wrote:
> From: Wei Yongjun
>
> 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().
Applied, thanks.
signature.as
assigned one. Fix this by statically assigning both the IRQ bases.
>
> Signed-off-by: Charles Keepax
Reviwed-by: Mark Brown
This probably wants to go to stable as well.
signature.asc
Description: Digital signature
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?
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 depend
/mach-s3c64xx/mach-crag6410.c
> +++ b/arch/arm/mach-s3c64xx/mach-crag6410.c
> @@ -855,7 +855,7 @@ static void __init crag6410_machine_init(void)
> MACHINE_START(WLF_CRAGG_6410, "Wolfson Cragganmore 6410")
> /* Maintainer: Mark Brown */
> .atag_offset
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
latform_data.
Acked-by: Mark Brown
signature.asc
Description: Digital signature
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 Cragganm
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 co
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
On Thu, Feb 19, 2015 at 09:44:08AM -0800, Doug Anderson wrote:
> On Thu, Feb 19, 2015 at 1:44 AM, Mark Brown 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
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", },
>
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 answe
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
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
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
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
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
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.
sign
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 cur
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 "
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 t
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 f
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 las
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
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
On Wed, Jan 28, 2015 at 02:27:06PM +0100, Arnd Bergmann wrote:
> The pl08x driver originally selected S3C64XX_PL080 to avoid having
> the legacy Samsung DMA interfaces. Those are now gone, so the
> select is no longer needed, but it now causes problems when
> CONFIG_DMA_ENGINE is disabled:
Applied
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
detect
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 sh
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");
> > + of_n
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
> >asy
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
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
On Fri, Jan 16, 2015 at 06:36:14PM +0100, Paul Osmialowski wrote:
> On Fri, 16 Jan 2015, Mark Brown wrote:
> >I don't know what this means, sorry. I'm also very worried about the
> >fact that this is being discussed purely in terms of I2C - why would
> >this not af
On Fri, Jan 16, 2015 at 03:39:54PM +0100, Paul Osmialowski wrote:
> This adopts i2c-s3c2410 driver for new enhancement of i2c API that
> exposes preparation and unpreparation stages of i2c transfer.
This doesn't seem to have any dependency on the previous patch at all...
it probably does want a be
On Fri, Jan 16, 2015 at 03:39:53PM +0100, Paul Osmialowski wrote:
> This uses the enhancement of i2c API in order to address following problem
> caused by circular lock dependency:
Please don't just dump enormous backtraces into commit messages as
explanations, explain in words what the problem y
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
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
> Odr
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
Descr
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
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
> ---
This should probably go to stable as a bug f
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 cu
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: D
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 platfo
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
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
On Mon, Dec 15, 2014 at 03:38:04PM +, Will Deacon wrote:
> On Mon, Dec 15, 2014 at 03:35:29PM +0000, 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 tr
dependencies removed or the ARMv8 architecture code implements these
ARM specific APIs.
Signed-off-by: Mark Brown
---
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 no res
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
dependencies removed or the ARMv8 architecture code implements these
ARM specific APIs.
Signed-off-by: Mark Brown
---
drivers/iommu/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index 01e8bfae569b..325188eef1c1 100644
--- a
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)
> >>+ br
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,
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.
> - p
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 n
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. Whil
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
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 "kern
On Thu, Dec 11, 2014 at 11:49:54AM +0100, Andrzej Hajda wrote:
> On 12/10/2014 05:07 PM, Mark Brown wrote:
> > On Wed, Dec 10, 2014 at 04:48:22PM +0100, Andrzej Hajda wrote:
> >> Regulators supports various methods of lookup.
> >> The patch adds 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 ac
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 fai
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
---
drivers/spi/spi-s3c64xx.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/drivers/spi/spi-s3c64xx.c b/drivers
On Fri, Nov 28, 2014 at 03:14:04PM +0100, Krzysztof Kozlowski wrote:
> On pią, 2014-11-28 at 11:38 +0000, 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.
On Fri, Nov 28, 2014 at 12:54:27PM +0100, Krzysztof Kozlowski wrote:
> On pią, 2014-11-28 at 11:21 +0000, 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
On Fri, Nov 28, 2014 at 11:30:55AM +0100, Krzysztof Kozlowski wrote:
> On czw, 2014-11-27 at 18:43 +0000, 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
> > co
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
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 w
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 set_ena
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: GP
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 litt
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
1 - 100 of 1261 matches
Mail list logo
