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
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
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
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_unus
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
On Mon, Nov 24, 2014 at 12:21:51PM +0530, Krishna Mohan Dani wrote:
> Document the device tree binding for the Arndale board based machine driver.
This is adding binding documentation but I'm not seeing the matching
driver - please send the two together.
signature.asc
Description: Digital signat
On Mon, Nov 24, 2014 at 04:52:42PM +0530, Krishna Mohan Dani wrote:
> Fixes the following compilation warning:
> Warning: 'rt5631_i2c_dt_ids' defined but not used - when DT is not used.
This doesn't apply, please check and resend.
signature.asc
Description: Digital signature
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 SubmittingPat
On Thu, Nov 20, 2014 at 03:33:17PM +0530, Padmavathi Venna wrote:
> In the i2s_set_sysclk() callback we are currently clearing all bits
> of the IISMOD register in i2s_set_sysclk. It's due to an incorrect
> mask used for the AND operation which is introduced in commit
> a5a56871f804edac93a53b5e871c
On Thu, Nov 13, 2014 at 05:44:22PM +0530, Krishna Mohan Dani wrote:
> Signed-off-by: Krishna Mohan Dani
> ---
> sound/soc/samsung/Kconfig |6 ++
> sound/soc/samsung/Makefile |2 +
> sound/soc/samsung/arndale_rt5631.c | 150
>
> 3 fi
On Wed, Nov 19, 2014 at 09:19:13AM -0800, Doug Anderson wrote:
Please stop CCing my work address for upstream things.
> On Wed, Nov 19, 2014 at 2:07 AM, Javier Martinez Canillas
> > I see, I thought that it was a common practice in the mainline kernel
> > too since I saw that many board DTS curr
On Mon, Nov 17, 2014 at 10:57:54AM +, Richard Fitzgerald wrote:
> Adds QUIRK_SUPPORTS_192KHZ to allow 192kHz rate
> to be selected for hardware that supports it.
> +- samsung,supports-192khz: specify this (without a value) if you want to
> allow
> +192000 sample rate over the I2S link.
T
On Mon, Nov 17, 2014 at 07:26:29PM +0530, Krishna Mohan Dani wrote:
> Fixes the following compilation warning:
> Warning: 'rt5631_i2c_dt_ids' defined but not used - when DT is not used.
>
> Signed-off-by: Claude Youn
> Signed-off-by: Krishna Mohan Dani
Applied, thanks. It's really weird that s
On Thu, Nov 13, 2014 at 05:44:24PM +0530, Krishna Mohan Dani wrote:
> Signed-off-by: Krishna Mohan Dani
Applied, thanks.
signature.asc
Description: Digital signature
On Thu, Nov 13, 2014 at 05:44:23PM +0530, Krishna Mohan Dani wrote:
> Signed-off-by: Krishna Mohan Dani
Applied, please use subject lines matching the style for the subsystem.
signature.asc
Description: Digital signature
On Thu, Nov 13, 2014 at 05:44:21PM +0530, Krishna Mohan Dani wrote:
> Document the device tree binding for the ALC5631 codec and update vendor
> specific prefix for the Realtek.
Applied, thanks.
signature.asc
Description: Digital signature
On Thu, Nov 13, 2014 at 03:45:57PM +0530, D Krishna Mohan wrote:
> From the rest of the comment what I understand is you want me to change the
> names of struct snd_soc_dai_link and struct snd_soc_card.
> Am that right? and/or do you want me to change the names whereever it sounds
> like generic a
On Wed, Nov 12, 2014 at 02:05:39PM +0530, Krishna Mohan Dani wrote:
> +#ifdef CONFIG_OF
> + .of_match_table = of_match_ptr(rt5631_i2c_dt_ids),
> +#endif
This is OK apart from this - you don't need the CONFIG_OF around
of_match_ptr().
signature.asc
Description: Digital signature
On Wed, Nov 12, 2014 at 02:05:37PM +0530, Krishna Mohan Dani wrote:
> + bfs = 32;
> +
> + rfs = 256;
> +
> + rclk = params_rate(params) * rfs;
> +
> + psr = 4;
> +
> + ret = snd_soc_dai_set_sysclk(cpu_dai, SAMSUNG_I2S_CDCLK,
> + 0, SND_SOC_CL
On Mon, Nov 10, 2014 at 10:32:24AM -0800, Dmitry Torokhov wrote:
> - I do not see why sirincling platform specific code around i2c, spi,
> etc bus code (which is not platform-specific) is OK, but a no-no for
> the driver ocre.
sirincling? In the case of I2C and SPI the buses don't define any
On Mon, Nov 10, 2014 at 07:39:51PM +0530, D Krishna Mohan wrote:
> Hi Mark Brown,
Don't top post.
> The codec driver is present in mainline as rt5631.c., Its realtek's
> alc5631 so retained that name.
> Similarly machine driver also is named as arndale_rt5631.c but
On Mon, Nov 10, 2014 at 01:31:56PM +0530, Krishna Mohan Dani wrote:
> Document the device tree binding for the ALC5631 codec and update vendor
> specific prefix for the Realtek.
This driver isn't in mainline, you need to submit the driver.
signature.asc
Description: Digital signature
On Fri, Nov 07, 2014 at 05:15:38PM +0100, Javier Martinez Canillas wrote:
> On 11/07/2014 04:47 PM, Mark Brown wrote:
> >> + if (!of_property_read_u32(np, "regulator-initial-mode", &pval)) {
> >> + if (desc && desc->map_modes)
> >&
On Fri, Nov 07, 2014 at 02:00:05PM +0100, Javier Martinez Canillas wrote:
> + if (!of_property_read_u32(np, "regulator-initial-mode", &pval)) {
> + if (desc && desc->map_modes)
> + constraints->initial_mode = desc->map_modes(pval);
> + else
> +
On Fri, Nov 07, 2014 at 02:00:03PM +0100, Javier Martinez Canillas wrote:
> - initdata = of_get_regulator_init_data(dev, np);
> sreg = devm_kzalloc(dev, sizeof(*sreg), GFP_KERNEL);
> if (!sreg)
> return -ENOMEM;
> - sreg->initdata = initdata;
> sreg->name =
On Fri, Nov 07, 2014 at 04:38:04PM +0100, Javier Martinez Canillas wrote:
> On 11/07/2014 03:58 PM, Mark Brown wrote:
> > On Fri, Nov 07, 2014 at 02:00:01PM +0100, Javier Martinez Canillas wrote:
> >> +The "regulator-mode" property only takes effect if the regula
On Fri, Nov 07, 2014 at 02:00:02PM +0100, Javier Martinez Canillas wrote:
> + * @map_modes: Callback invoked to translate from hardware to standard modes.
> + * The function returns the standard REGULATOR_MODE that maps to
> + * the hardware specific mode passed as an argum
On Fri, Nov 07, 2014 at 02:00:01PM +0100, Javier Martinez Canillas wrote:
> + The "regulator-mode" property only takes effect if the regulator is
> + enabled for the given suspend state using "regulator-on-in-suspend".
Why?
> + If the regulator has not been explicitly disabled
On Fri, Nov 07, 2014 at 12:24:40PM +0530, Padmavathi Venna wrote:
> Exynos7 I2S controller has no internal dma, supports more
> no. of root clock sampling frequencies and has more no.of Rx
> fifos to support 7.1CH recording in TDM mode. Due to more no.
Applied, thanks.
signature.asc
Description:
On Fri, Nov 07, 2014 at 12:24:39PM +0530, Padmavathi Venna wrote:
> Internal DMA is available only on some of Samsung platforms.
> So added a quirk for the same and made it optional.
Applied, thanks.
signature.asc
Description: Digital signature
On Fri, Nov 07, 2014 at 02:01:57PM +0530, Padma Venkat wrote:
> CS can also be controlled automatically by setting AUTO_N_MANUAL to 1
> in CS_CFG. When it is auto CS automatically toggles between packet to
> packet. NCS_TIME_COUNT in CS_CFG controls the inactive period. The
> driver by default use
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.
Could you give a bit more detail on what t
On Wed, Nov 05, 2014 at 07:11:06PM +0100, Andreas Färber wrote:
> Am 05.11.2014 um 18:09 schrieb Mark Brown:
> > On Wed, Nov 05, 2014 at 05:44:52PM +0100, Andreas Färber wrote:
> >> This enables the snd_soc_snow module to be auto-loaded.
> > Applied, thanks.
> Than
On Wed, Nov 05, 2014 at 05:44:52PM +0100, Andreas Färber wrote:
> This enables the snd_soc_snow module to be auto-loaded.
Applied, thanks.
signature.asc
Description: Digital signature
On Mon, Nov 03, 2014 at 03:40:47PM +0100, Javier Martinez Canillas wrote:
> All function dealing with operating modes use unsigned int for modes
> so change max77802_map_mode() function signature for consistency.
Applied, thanks.
signature.asc
Description: Digital signature
On Mon, Nov 03, 2014 at 03:54:43PM +, Mark Brown wrote:
> On Mon, Nov 03, 2014 at 03:40:35PM +0100, Javier Martinez Canillas wrote:
> > Hello Mark,
> >
> > This is the fourth version of the series that adds operating modes
> > support for the regulators in the max77
On Mon, Nov 03, 2014 at 04:48:34PM +0100, Javier Martinez Canillas wrote:
> On 11/03/2014 04:33 PM, Mark Brown wrote:
> > On Mon, Nov 03, 2014 at 03:40:38PM +0100, Javier Martinez Canillas wrote:
> >>if (!of_node_cmp(np->name, info->desc.name)) {
> &
On Mon, Nov 03, 2014 at 03:40:44PM +0100, Javier Martinez Canillas wrote:
> The struct of_regulator_match rmatch[] is declared as a non-static local
> variable so the structure members are not auto-initialized.
Applied, thanks.
signature.asc
Description: Digital signature
On Mon, Nov 03, 2014 at 03:40:43PM +0100, Javier Martinez Canillas wrote:
> The struct of_regulator_match rmatch[] is declared as a non-static local
> variable so the structure members are not auto-initialized.
Applied, thanks.
signature.asc
Description: Digital signature
On Mon, Nov 03, 2014 at 03:40:42PM +0100, Javier Martinez Canillas wrote:
> The struct of_regulator_match is declared as a non-static local variable
> so the structure members are not auto-initialized.
Applied, thanks.
signature.asc
Description: Digital signature
On Mon, Nov 03, 2014 at 03:40:41PM +0100, Javier Martinez Canillas wrote:
> The struct of_regulator_match is declared as a non-static local variable
> so the structure members are not auto-initialized.
Applied, thanks.
signature.asc
Description: Digital signature
On Mon, Nov 03, 2014 at 03:40:35PM +0100, Javier Martinez Canillas wrote:
> Hello Mark,
>
> This is the fourth version of the series that adds operating modes
> support for the regulators in the max77802 PMIC. This version uses
No, it's not. This is a a patch series doing a whole bunch of differ
On Mon, Nov 03, 2014 at 03:40:40PM +0100, Javier Martinez Canillas wrote:
> The struct of_regulator_match rmatch[] is declared as a non-static local
> variable so the structure members are not auto-initialized.
Applied, thanks.
This is a bug fix not *that* closely related to the rest of the serie
On Mon, Nov 03, 2014 at 03:40:38PM +0100, Javier Martinez Canillas wrote:
> for_each_child_of_node(nproot, np) {
> if (!of_node_cmp(np->name, info->desc.name)) {
> config->init_data =
> - of_get_regulator_init_data(&pdev->dev, n
On Mon, Nov 03, 2014 at 01:07:02PM +0100, Krzysztof Kozlowski wrote:
> On pią, 2014-10-31 at 10:32 +0000, Mark Brown wrote:
> > We could always add a callback for the driver to handle any custom
> > properties... one of the advantages of an OS like Linux is that we can
> >
On Fri, Oct 31, 2014 at 02:07:54PM +0100, Krzysztof Kozlowski wrote:
> On pią, 2014-10-31 at 12:23 +0000, Mark Brown wrote:
> > I'm getting very frustrated with what's going on with these drivers,
> > there seem to be a lot of rather large sets of patches spawning lots o
On Wed, Oct 29, 2014 at 12:14:52PM +0100, Krzysztof Kozlowski wrote:
> Some LDOs of Maxim 77686 PMIC support disabling during system suspend
> (LDO{2,6,7,8,10,11,12,14,15,16}). This was already implemented as part
> of set_suspend_mode function. In that case the mode was one of:
Applied, thanks.
On Thu, Oct 30, 2014 at 12:20:40PM +0100, Krzysztof Kozlowski wrote:
> Add of_compatible fields for max77686 and max77802 regulator drivers.
> The driver's node should be the same as voltage-regulators node. This
> simplifies parsing of regulators init data from DTS.
No, this is broken. You're in
On Fri, Oct 31, 2014 at 12:45:47PM +0100, Krzysztof Kozlowski wrote:
> Then I'll add it.
> Mark, what device should be assigned to "config.dev" during registration
> of regulators? The regulator driver's device or its parent (MFD main
> driver)?
> Various drivers do this differently.
Normally t
On Fri, Oct 31, 2014 at 08:51:38AM +0100, Krzysztof Kozlowski wrote:
> However new DT style parsing (regulator_of_get_init_data()) does the
> basic parsing stuff and this removes a lot of code from driver. The
> driver no longer parses all regulaotrs but the regulator core does it.
> Unfortunately
On Thu, Oct 30, 2014 at 01:46:43PM -0700, Kevin Hilman wrote:
> Mark Brown writes:
> > On Fri, Oct 24, 2014 at 09:12:39AM -0700, Kevin Hilman wrote:
> >> I'm confused. Why arent' pm_runtime_get*() and pm_runtime_put*() working?
> >> What's not explain
On Wed, Oct 29, 2014 at 11:18:54AM +0100, Krzysztof Kozlowski wrote:
> On śro, 2014-10-29 at 10:01 +0000, Mark Brown wrote:
> > No, this isn't suspend enable control - this is normal, standard enable
> > control and the device has no suspend enable control.
> You mean that
On Wed, Oct 29, 2014 at 10:20:13AM +0100, Krzysztof Kozlowski wrote:
> On wto, 2014-10-28 at 22:31 +0000, Mark Brown wrote:
> > This looks wrong, you're using the regular enable operation as suspend
> > enable. How does that work without disrupting the current runtime
> &
On Mon, Oct 27, 2014 at 01:11:48PM +0100, Krzysztof Kozlowski wrote:
> Introduce simple helper for calculating the shift for OPMODE field in
> registers. This allows storing the current value of opmode in
> non-shifted form and simplifies a little set_suspend_disable and enable
> functions. Additio
On Mon, Oct 27, 2014 at 01:11:47PM +0100, Krzysztof Kozlowski wrote:
> Add defines for regulator operating modes which should be more readable,
> especially if one does not have Maxim 77686 datasheet.
Applied, thanks.
signature.asc
Description: Digital signature
On Mon, Oct 27, 2014 at 01:11:49PM +0100, Krzysztof Kozlowski wrote:
> @@ -247,6 +250,8 @@ static struct regulator_ops max77686_ldo_ops = {
> .set_voltage_sel= regulator_set_voltage_sel_regmap,
> .set_voltage_time_sel = regulator_set_voltage_time_sel,
> .set_suspend_mod
On Mon, Oct 27, 2014 at 04:03:42PM +0100, Krzysztof Kozlowski wrote:
> The regulator_register() expects array of 'regulator_desc' to be const.
Applied, thanks.
signature.asc
Description: Digital signature
On Mon, Oct 27, 2014 at 04:03:40PM +0100, Krzysztof Kozlowski wrote:
> The driver is used only on Exynos4 based boards with DTS support.
> Convert the driver to DTS-only version.
This doesn't seem like a particularly persuasive reason honestly and if
you're going to mess around with this stuff ple
On Thu, Oct 23, 2014 at 11:28:09AM +0200, Javier Martinez Canillas wrote:
Please fix your mailer to word wrap within paragraphs - you should know
this by now :/ I've reflowed for legibility.
> However this is an implementation detail and should not change the DT
> bindings in the current version
On Fri, Oct 24, 2014 at 09:12:39AM -0700, Kevin Hilman wrote:
> Ulf Hansson writes:
> > There may be more than one device in a PM domain which then will be
> > probed at different points in time.
> > Depending on timing and runtime PM support, in for the device related
> > driver/subsystem, a PM
On Mon, Oct 20, 2014 at 04:47:51PM +0200, Javier Martinez Canillas wrote:
> + char *states[PM_SUSPEND_MAX + 1] = {
> + [PM_SUSPEND_MEM] = "regulator-state-mem",
> + [PM_SUSPEND_MAX] = "regulator-state-disk",
> + };
This still has the same problem as your previous p
On Mon, Oct 20, 2014 at 04:47:48PM +0200, Javier Martinez Canillas wrote:
> of_get_regulation_constraints() calls of_get_child_by_name() to find the
> regulator-state-{mem,disk} child nodes for each regulator. This function
> increments the device node reference counter but this is not decremented
On Mon, Oct 20, 2014 at 09:50:57PM +0200, Javier Martinez Canillas wrote:
> On 10/20/2014 07:36 PM, Doug Anderson wrote:
> > I guess I was just trying to follow the suggestion that was in the
> > regulator code:
> > http://lxr.free-electrons.com/source/drivers/regulator/core.c#L3699
> > that says
On Fri, Oct 17, 2014 at 02:39:15PM +0200, Javier Martinez Canillas wrote:
> Just to be sure I understood correctly, are you suggesting something like
> this?
> ldo1_reg: LDO1 {
> regulator-name = "vdd_1v0";
> regulator-min-microvolt = <100>;
>
On Thu, Oct 16, 2014 at 06:48:49PM +0200, Javier Martinez Canillas wrote:
> The only operating modes that are supported by the regulators in the
> max77802 PMIC are Output ON (normal) and Output On in Low Power Mode.
> OFF was wrongly counted as an operating mode while is only a regulator
> status.
On Thu, Oct 16, 2014 at 06:48:50PM +0200, Javier Martinez Canillas wrote:
> Add a header file for the max77802 constants that could be shared between
> the regulator driver and Device Tree source files. Also, remove standby
> and off opmodes since only normal and low power are valid operating modes
On Thu, Oct 16, 2014 at 06:48:48PM +0200, Javier Martinez Canillas wrote:
> The max77802 PMIC has a special enable pin (PWRREQ) that can be used
> by the Application Processor (AP) to power down and up voltage rails.
Applied, thanks.
signature.asc
Description: Digital signature
On Thu, Oct 16, 2014 at 06:48:47PM +0200, Javier Martinez Canillas wrote:
> Some max77802 LDOs (1, 3, 20 and 21) support to be configured in Low
> Power Mode during system normal operation. Add function handlers for
> the .get_mode and .set_mode operations to set the mode on these LDOs.
Applied, t
On Thu, Oct 16, 2014 at 06:48:51PM +0200, Javier Martinez Canillas wrote:
> +- maxim,regulator-initial-mode: initial operating mode.
> + This property can only be used on regulators that support changing their
> mode
> + during normal operation. These regulators are LDO1, LDO3, LDO20 and LDO21.
On Wed, Oct 15, 2014 at 06:20:33PM +0200, Javier Martinez Canillas wrote:
> Not all the max77802 BUCKs regulators have the same functionality, for
> example BUCKs 2-4 support the output to be configured as normal or Low
> Power Mode by the PWRREQ enable pin while the other BUCKs only support
> thei
On Wed, Oct 15, 2014 at 06:20:31PM +0200, Javier Martinez Canillas wrote:
> The max77802 PMIC has an enable pin (PWRREQ) that can be used to switch
> regulators ON and OFF automatically by the Application Processor when
> the system is leaving and entering sleep mode.
Applied, thanks.
signature.
On Wed, Oct 15, 2014 at 06:20:32PM +0200, Javier Martinez Canillas wrote:
> +#define MAX77802_MODE(pval) ((pval == MAX77802_OPMODE_NORMAL) ? \
> + REGULATOR_MODE_NORMAL : REGULATOR_MODE_STANDBY)
> +
Make this a static inline function if there's any need for it, this
On Thu, Oct 09, 2014 at 11:40:17PM +0200, Javier Martinez Canillas wrote:
> On 10/09/2014 07:48 PM, Mark Brown wrote:
> > On Thu, Oct 09, 2014 at 04:27:37PM +0200, Javier Martinez Canillas wrote:
> >> only two modes: ON and OFF (and some of them have a third Low Power mode).
&
On Thu, Oct 09, 2014 at 05:04:35PM +0200, Javier Martinez Canillas wrote:
> Agree, Mark also pointed out that there is a difference between changing
> how the regulator will behave on runtime vs changing how the regulator
> will behave during system suspend. AFAIU from his explanation, the modes
>
On Thu, Oct 09, 2014 at 04:27:37PM +0200, Javier Martinez Canillas wrote:
> I see, I thought that an operating mode could be anything that alter the
> regulator behavior either during runtime or when the system is suspended.
> But under your definition, it is true that most max77802 regulators hav
On Wed, Oct 08, 2014 at 04:38:53PM +0200, Javier Martinez Canillas wrote:
> On 10/08/2014 04:25 PM, Mark Brown wrote:
> > That doesn't mean that the definition of those modes is something we can
> > sensibly provide in generic code, especially in a completely
> > und
On Wed, Oct 08, 2014 at 03:44:07PM +0200, Javier Martinez Canillas wrote:
> The regulator core now has support to choose a default initial
> operating mode for regulators from DT. Set the initial opmode
> for the max77802 PMIC regulators with the same modes that are
> used in the downstream Chrome
On Wed, Oct 08, 2014 at 03:44:06PM +0200, Javier Martinez Canillas wrote:
> Add a function handler for the struct regulator_ops .set_mode so an
> operating mode (opmode) can be set for regulators.
>
> Regulators opmode are defined using the generic REGULATOR_MODE_*
> modes so the driver maps these
On Wed, Oct 08, 2014 at 03:44:05PM +0200, Javier Martinez Canillas wrote:
> +- regulator-initial-mode: initial regulator operating mode. One of following:
> + <1>: REGULATOR_MODE_FAST- Regulator can handle fast changes.
> + <2>: REGULATOR_MODE_NORMAL - Normal regulator power supply mo
On Wed, Oct 08, 2014 at 03:44:03PM +0200, Javier Martinez Canillas wrote:
> But currently there isn't a way to do the same with DeviceTrees. Argubly
> the operating modes are Linux-specific so that information should not be
> in the DT which should be used to only describe hardware. But regulators
On Thu, Oct 02, 2014 at 06:16:43PM +0200, Sylwester Nawrocki wrote:
> [dropping unrelated addresses from Cc]
You've dropped Liam who's the other ASoC maintainer.
> Sorry for getting back late to this. Indeed we have a mess here.
> I mostly tested interaction between two CPU DAIs - the main and th
On Mon, Sep 29, 2014 at 02:12:43PM +0100, Grant Likely wrote:
> On Mon, Sep 29, 2014 at 1:57 PM, Thierry Reding
> > Though there are two cases: one is to use simplefb as a means to have
> > early boot messages on a graphical display (and optionally hand off to a
> > real driver). The other is to u
On Thu, Sep 18, 2014 at 11:57:07PM +0200, Paul Bolle wrote:
> Mark Brown schreef op do 18-09-2014 om 10:57 [-0700]:
> > On Thu, Sep 18, 2014 at 11:43:29AM +0200, Paul Bolle wrote:
> > > Done on top of next-20140918. Untested.
> > > ->8-
> > &g
On Thu, Sep 18, 2014 at 12:42:16PM +0200, Paul Bolle wrote:
> On Thu, 2014-09-04 at 18:02 +0200, Arnd Bergmann wrote:
> > I think it would be nice if you could submit a patch to remove the
> > drivers from ASoC, then we can see if anybody complains.
> Also the same thing for v3.17-rc5 and next-20
On Thu, Sep 18, 2014 at 11:43:29AM +0200, Paul Bolle wrote:
> On Thu, 2014-09-04 at 18:02 +0200, Arnd Bergmann wrote:
> > I think it would be nice if you could submit a patch to remove the
> > drivers from ASoC, then we can see if anybody complains.
> Same thing for v3.17-rc5 and next-20140918. L
On Tue, Sep 16, 2014 at 02:01:02PM +0200, Tomasz Figa wrote:
> I think the problematic case here is v6+v7 multiplatform, where even
> though CONFIG_ARCH_EXYNOS is defined, compiler flags for lowest common
> denominator (v6) must be used. Using appropriate macros should fix the
> problem indeed.
R
On Mon, Sep 15, 2014 at 11:57:09AM +0100, Build bot for Mark Brown wrote:
Today's -next got a build failure in ARM allmodconfig due to platsmp.c:
| arch/arm/mach-exynos/platsmp.c:198:31: warning: incorrect type in return
expression (different address spaces)
| arch/arm/mach-exynos/platsmp.
On Thu, Sep 11, 2014 at 10:22:32AM +0100, Grant Likely wrote:
> On Wed, 10 Sep 2014 17:57:23 +0100, Mark Brown wrote:
> > It's not quite as simple as just disabling PM - for example in the
> > clocks case we've also got to worry about what happens with rate changes
&
On Thu, Sep 11, 2014 at 10:06:08AM +0100, Grant Likely wrote:
> On Wed, 10 Sep 2014 15:31:44 +0100, Mark Brown wrote:
> > As well as the regulators we'll also need to fix the clocks. If we're
> > going to start adding these fixups perhaps we want to consider having
On Wed, Sep 10, 2014 at 09:45:21AM -0700, Doug Anderson wrote:
> Right now I know that clock disabling is supposed to be inhibited
> during the early boot process. I think regulators too?
No, for regulators we'll quite happily disable anything a consumer asks
us to at any point but we'll only do
On Wed, Sep 10, 2014 at 09:36:32AM -0700, Olof Johansson wrote:
> On Wed, Sep 10, 2014 at 7:31 AM, Mark Brown wrote:
> > As well as the regulators we'll also need to fix the clocks. If we're
> > going to start adding these fixups perhaps we want to consider having a
>
On Wed, Sep 10, 2014 at 05:29:32PM +0100, Grant Likely wrote:
> What we can do is have an inhibit flag for
> simplefb/simpleuart/simplewhatever that holds off PM. When a real
> driver, or a stub that understands parsing the resource dependencies,
> takes ownership of the device (or userspace tells
On Wed, Sep 10, 2014 at 03:56:16PM +0100, Grant Likely wrote:
> On Wed, Sep 10, 2014 at 3:31 PM, Mark Brown wrote:
> > As far as I can tell the problem here is coming from the decision to
> > have simplefb use resources without knowing about them - can we agree
> > that this
On Wed, Sep 10, 2014 at 06:06:46AM -0700, Olof Johansson wrote:
> On Mon, Sep 8, 2014 at 12:40 PM, Grant Likely
> wrote:
> > Well, lets see... We've got a real user complaining about a platform
> > that used to work on mainline, and no longer does. The only loophole
> > for ignoring breakage is
On Tue, Sep 09, 2014 at 04:51:49PM +0100, Charles Keepax wrote:
> In a couple of places the driver is missing a check to ensure there is a
> secondary DAI before it de-references the pointer to it, causing a null
> pointer de-reference. This patch adds a check to avoid this.
Applied, thanks.
sig
On Mon, Sep 08, 2014 at 01:20:11PM +0100, Grant Likely wrote:
> On Mon, Sep 8, 2014 at 12:21 PM, Will Deacon wrote:
> > Whilst I'm sympathetic to people working to enable DRM, I think this is
> > the right solution to the problem. The transition from simplefb to DRM
> > shouldn't break display fo
On Sun, Sep 07, 2014 at 09:36:56PM -0700, Doug Anderson wrote:
> On Sun, Sep 7, 2014 at 8:52 AM, Tomasz Figa wrote:
> > So I believe we've got a process issue here. If you don't have normal
> > support for display hardware, but you want to keep the display
> > operational thanks to bootloader alr
On Sun, Sep 07, 2014 at 11:06:54AM +0200, Javier Martinez Canillas wrote:
> But maybe we could add a boot argument similar to "clk_ignore_unused" but for
> regulators? Something like "regulator_ignore_unused" that would prevent the
> regulator core to disable unused regulators? If Mark agrees with
On Thu, Aug 28, 2014 at 11:59:16AM +0200, Javier Martinez Canillas wrote:
> > On 28/08/2014, at 10:28, Mark Brown wrote:
> >> Yes, AFAIK the bootloader (none of them because Chromebooks use two
> >> chained U-boots) change the regulators default opmode so once is set
On Thu, Aug 28, 2014 at 12:44:18AM +0200, Javier Martinez Canillas wrote:
> On Wed, Aug 27, 2014 at 11:03 PM, Tomasz Figa wrote:
> This is the case for Chromebooks as well but the solution implemented
> in the downstream Chrome OS 3.8 kernel is what Tomasz suggested
*sigh* This is not what you
101 - 200 of 1261 matches
Mail list logo
