On Mon, Apr 07, 2014 at 02:15:24PM +0200, Krzysztof Kozlowski wrote:
Don't store pointer to regulator_dev returned by
devm_regulator_register() in state container. It isn't used anywhere
outside of probe.
Applied, thanks.
signature.asc
Description: Digital signature
On Mon, Apr 14, 2014 at 10:09:09AM +0200, Krzysztof Kozlowski wrote:
- - s5m8767,pmic-ext-control-gpios: (optional) GPIO specifier for one
+ - samsung,ext-control-gpios: (optional) GPIO specifier for one
GPIO controlling this regulator (enable/disable); This is
On Mon, Apr 14, 2014 at 10:09:08AM +0200, Krzysztof Kozlowski wrote:
Add documentation for new property for controlling (enable/disable) some
of the S2MPS14 regulators by GPIO.
Applied, thanks.
signature.asc
Description: Digital signature
On Mon, Apr 14, 2014 at 10:09:06AM +0200, Krzysztof Kozlowski wrote:
Refactor code for parsing DTS to increase a little code readability. The
behaviour should not change.
Applied, thanks.
signature.asc
Description: Digital signature
On Mon, Apr 14, 2014 at 10:09:07AM +0200, Krzysztof Kozlowski wrote:
Add support for external control over GPIO for LDO10, LDO11 and LDO12
S2MPS14 regulators. External control can be turned on by writing 0x0 to
control register which in case of other regulators is used for disabling
them.
On Tue, Apr 15, 2014 at 01:14:36PM -0700, Doug Anderson wrote:
Mitigate the problem by:
* Allow setting the overcurrent wait time so devices with this problem
can set it to the max.
* Add retry logic on enables of FETs.
This is two changes, should really be two patches.
+-
On Wed, Apr 16, 2014 at 10:59:22AM +0100, Lee Jones wrote:
NOTE: the IRQnMASK and CG_CTRLn registers are the exception and could
be cached. If we find that we spend a lot of time reading those we
can turn on cache for just those registers.
-static bool is_volatile_reg(struct device
On Wed, Apr 16, 2014 at 11:25:24AM -0700, Doug Anderson wrote:
An issue was discovered with tps65090 where sometimes the FETs
wouldn't actually turn on when requested (they would report
overcurrent). The most problematic FET was the one used for the LCD
Please don't send new patches as
On Wed, Apr 16, 2014 at 08:14:27PM +0200, Arnd Bergmann wrote:
This patch does a partial revert of 313367e7bfa by allowing these
drivers on all samsung platforms except EXYNOS, so we can proceed
with the multiplatform patches.
If support for these drivers is actually needed on EXYNOS
On Wed, Apr 16, 2014 at 02:34:47PM -0700, Doug Anderson wrote:
On Wed, Apr 16, 2014 at 1:51 PM, Mark Brown broo...@kernel.org wrote:
Please don't send new patches as replies in the middle of threads, it
makes it confusing trying to work out which versions of things should be
applied.
I'm
On Wed, Apr 16, 2014 at 04:12:28PM -0700, Doug Anderson wrote:
The tps65090 regulator allows you to specify how long you want it to
wait before detecting an overcurrent condition. Allow specifying that
through the device tree (or through platform data).
Applied, thanks.
+-
On Tue, Apr 15, 2014 at 10:55:45AM +0200, Krzysztof Kozlowski wrote:
Anyway more drivers seem to use this kind of binding (tps65090, max8952,
da9055, arizona) so maybe there is a point in making this generic?
Yes.
signature.asc
Description: Digital signature
On Wed, Apr 16, 2014 at 04:12:29PM -0700, Doug Anderson wrote:
An issue was discovered with tps65090 where sometimes the FETs
wouldn't actually turn on when requested (they would report
overcurrent). The most problematic FET was the one used for the LCD
This is basically fine but you said it
On Tue, Apr 22, 2014 at 01:33:54PM +0530, Tushar Behera wrote:
Added machine driver to instantiate I2S based sound card on Snow
board. It has MAX98095 audio codec on board.
In general this isn't up to modern standards, please do try to check
that new code is following best practices. Did the
On Tue, Apr 22, 2014 at 08:47:09AM +0100, Lee Jones wrote:
If there are cross-subsystem dependencies I prefer to use immutable
branches to eliminate any change of merge conflicts in -next or the
next merge window. I'm happy to either create on with Mark's Acks, or
receive a pull-request from
On Tue, Apr 22, 2014 at 07:17:54PM +0530, Tushar Behera wrote:
On 22 April 2014 16:14, Mark Brown broo...@kernel.org wrote:
In general this isn't up to modern standards, please do try to check
that new code is following best practices. Did the support for setting
the clocking up
On Tue, Apr 22, 2014 at 08:24:56AM -0700, Doug Anderson wrote:
Nearly all of the registers in tps65090 combine control bits and
status bits. Turn off caching of all registers except the select few
that can be cached.
Lee, I don't mind if I apply this and send a pull request to you or I
pull a
On Wed, Apr 23, 2014 at 01:34:24PM +0530, Tushar Behera wrote:
In exiting kernel, if DAIFMT flags are set in dai_link and I2S is
set to run in master mode, the I2S clocks are not getting configured
resulting in no output.
Applied, thanks.
signature.asc
Description: Digital signature
been proposed by Mark Brown to fix the problem of
the regulators not beeing available on the peripheral device probe():
http://lists.infradead.org/pipermail/linux-arm-kernel/2010-March/011971.html
What specifically is this needed for? We *should* be able to use
deferred probe for most things
On Wed, Jun 18, 2014 at 06:22:30PM +0200, Sylwester Nawrocki wrote:
+struct odroidx2_drv_data odroidx2_drvdata = {
+ .dapm_widgets = odroidx2_dapm_widgets,
+ .num_dapm_widgets = ARRAY_SIZE(odroidx2_dapm_widgets),
+};
+
+struct odroidx2_drv_data odroidu3_drvdata = {
On Fri, Jun 20, 2014 at 01:33:15PM +0530, Tushar Behera wrote:
From: Wonjoon Lee woojoo@samsung.com
The MAX98091 CODEC is the same as MAX98090 CODEC, but with an extra
microphone. Existing driver for MAX98090 CODEC already has support
for MAX98091 CODEC. Adding proper compatible string
On Fri, Jun 20, 2014 at 01:33:16PM +0530, Tushar Behera wrote:
Peach-pi board has MAX98091 CODEC. Extend snow machine driver to support
this board.
Applied, thanks.
signature.asc
Description: Digital signature
On Fri, Jun 13, 2014 at 09:29:50AM +0530, Naveen Krishna Chatradhi wrote:
Hence, spi-s3c64xx.c is broken since Jun 21 11:26:12 2013 and
considering the time with no compliants about the breakage.
I'm not clear what the breakage is? Some boards are broken but what's
the driver issue?
On Thu, Jul 03, 2014 at 07:37:07AM +0900, Kukjin Kim wrote:
On 07/02/14 18:23, Mark Brown wrote:
This also wasn't sent to me for review, please always send patches to
maintainers.
Mark, I always send patches to regarding maintainers and in this case the
patch missed the change. I'm
On Fri, Jul 04, 2014 at 11:01:52AM +0200, Arnd Bergmann wrote:
On Thursday 03 July 2014 20:39:41 Olof Johansson wrote:
On Thu, Jul 3, 2014 at 5:39 PM, Kukjin Kim kgene@samsung.com wrote:
Mark is the _only_ linux developer in the world who will give you crap
for sending him patches to
On Fri, Jul 04, 2014 at 04:05:45PM +0200, Sylwester Nawrocki wrote:
We should save/restore relevant I2S registers regardless of
the dai-active flag, otherwise some settings are being lost
after system suspend/resume cycle. E.g. I2S slave mode set only
during dai initialization is not preserved
On Fri, Jul 04, 2014 at 02:50:52PM +0530, Tushar Behera wrote:
Add sound-card name property to Snow/Peach-Pit/Peach-Pi boards.
Acked-by: Mark Brown broo...@linaro.org
signature.asc
Description: Digital signature
On Fri, Jul 04, 2014 at 02:22:59PM +0530, Tushar Behera wrote:
Snow sound-card driver supports multiple boards with different
audio codecs. Updating the sound card name per board basis would provide
some more information to the end-user.
Applied, thanks.
signature.asc
Description: Digital
On Thu, Jul 03, 2014 at 07:40:17AM +0900, Kukjin Kim wrote:
This patch removes s5p64x0 related WM8580 because of removing support
for s5p64x0 SoCs.
Acked-by: Mark Brown broo...@linaro.org
signature.asc
Description: Digital signature
On Mon, Jul 07, 2014 at 11:51:38AM +0530, Naveen Krishna Ch wrote:
On 2 July 2014 22:26, Mark Brown broo...@kernel.org wrote:
On Fri, Jun 13, 2014 at 09:29:50AM +0530, Naveen Krishna Chatradhi wrote:
Hence, spi-s3c64xx.c is broken since Jun 21 11:26:12 2013 and
considering the time
On Fri, Jul 04, 2014 at 02:23:00PM +0530, Tushar Behera wrote:
snd_soc_of_parse_card_name() may be called before card-dev has been
set, which results in a kernel panic.
Applied, thanks.
signature.asc
Description: Digital signature
On Fri, Jul 04, 2014 at 03:13:44PM +0200, Sylwester Nawrocki wrote:
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Applied both, thanks. Please use subject lines consistent with the
subsystem style.
signature.asc
Description: Digital signature
On Tue, Jul 08, 2014 at 05:57:58PM +0530, Amit Daniel Kachhap wrote:
include/linux/mfd/samsung/core.h| 21
include/linux/mfd/samsung/s2mpa01.h | 12 -
include/linux/mfd/samsung/s2mps11.h | 9 ---
include/linux/mfd/samsung/s2mps14.h | 10
You need to
On Thu, Jul 10, 2014 at 06:11:13PM +0200, Sylwester Nawrocki wrote:
Currently configuration of the CDCLK pad is being overwritten in
the i2s_shutdown() callback in order to gate the SoC output clock.
Applied, thanks.
signature.asc
Description: Digital signature
On Fri, Jul 11, 2014 at 01:04:07PM +0200, Javier Martinez Canillas wrote:
Hello Naveen and Mark,
On Mon, Jul 7, 2014 at 1:22 PM, Javier Martinez Canillas
jav...@dowhile0.org wrote:
On Mon, Jul 7, 2014 at 10:31 AM, Naveen Krishna Ch
naveenkrishna...@gmail.com wrote:
Please delete irrelevant
On Sat, Jul 12, 2014 at 09:59:48AM -0700, Olof Johansson wrote:
I've merged these in. I noticed lack of acked-by from Mark Brown, so I pinged
him on IRC about it and the branch is currently at the top so it's easy to
drop
in case he has objections (cc:d here too).
Don't know if I've seen
On Mon, Jul 14, 2014 at 01:27:53PM +0200, Sylwester Nawrocki wrote:
Too bad, I noticed this comment only just now. I'll consider this and
will try again and see how simple-card could be used. There is also the
samsung-i2s-sec secondary 'overlay' CPU DAI that would need to be handled,
and we
On Mon, Jul 14, 2014 at 11:11:44AM +0530, Naveen Krishna Chatradhi wrote:
@@ -812,6 +800,10 @@ static int s3c64xx_spi_setup(struct spi_device *spi)
spi-controller_data = cs;
}
+ /* For the non-DT platforms derive chip selects from controller data */
+ if
On Tue, Jul 01, 2014 at 06:32:27AM +0900, Kukjin Kim wrote:
This patch removes s5pc100 related codes in
linux/platform_data/asoc-s3c.h.
Applied, thanks.
signature.asc
Description: Digital signature
On Thu, Jul 03, 2014 at 07:40:17AM +0900, Kukjin Kim wrote:
This patch removes s5p64x0 related WM8580 because of removing support
for s5p64x0 SoCs.
Applied, thanks.
signature.asc
Description: Digital signature
On Fri, Jul 11, 2014 at 03:45:07PM +0200, Arnd Bergmann wrote:
Commit ae602456e83c92 (ASoC: samsung: drop support for legacy
S3C24XX DMA API) removed the old code for the samsung specific
DMA interfaces, now that everybody can use dmaengine.
Applied, thanks.
signature.asc
Description:
On Fri, Jul 11, 2014 at 03:45:08PM +0200, Arnd Bergmann wrote:
The s3c_dma_client structures and the 'ch' and 'ops' members in
s3c_dma_params were only used by the legacy DMA driver and serve
no function any more. This removes any reference to them.
Applied, thanks.
signature.asc
On Tue, Jul 15, 2014 at 12:31:32AM +0530, Naveen Krishna Ch wrote:
in this case spi-s3c64xx.c will continue to ignore the generic SPI cs-gpios
implementation.
I'm willing to implement any suggestion to fix this issue.
The problem isn't what you're trying to do, the problem is verifying
that
On Tue, Jul 15, 2014 at 09:33:21AM +0530, Naveen Krishna Ch wrote:
On 15 July 2014 00:45, Mark Brown broo...@kernel.org wrote:
The problem isn't what you're trying to do, the problem is verifying
that it has been done correctly - making sure that everything has been
accounted
On Tue, Jul 15, 2014 at 12:38:58PM +0200, Javier Martinez Canillas wrote:
Hello Mark,
Don't top post.
On Mon, Jul 14, 2014 at 7:25 PM, Mark Brown broo...@kernel.org wrote:
On Mon, Jul 14, 2014 at 11:11:44AM +0530, Naveen Krishna Chatradhi wrote:
So, the .line field is used to specify
On Wed, Jul 16, 2014 at 05:19:07PM +0200, Javier Martinez Canillas wrote:
This reverts commit 3146beec21b64f4551fcf0ac148381d54dc41b1b.
For the benefit of those who haven't memorized the SHA1s of every commit
that's spi: s3c64xx: Added provision for dedicated cs pin - please
include the human
On Wed, Jul 16, 2014 at 05:19:08PM +0200, Javier Martinez Canillas wrote:
From: Naveen Krishna Chatradhi ch.nav...@samsung.com
The s3c64xx SPI driver uses a custom DT binding to specify
the GPIO used to drive the chip select (CS) line instead of
using the generic cs-gpios property already
On Wed, Jul 16, 2014 at 05:19:09PM +0200, Javier Martinez Canillas wrote:
From: Naveen Krishna Chatradhi ch.nav...@samsung.com
Samsung SPI driver now uses the generic SPI cs-gpios
binding so update the documentation accordingly.
Applied, thanks. Please do try to use changelogs that are
On Wed, Jul 16, 2014 at 05:19:10PM +0200, Javier Martinez Canillas wrote:
From: Naveen Krishna Chatradhi ch.nav...@samsung.com
This patch replaces the cs-gpio from controller-data node
as was specified in the old binding and uses the standard
cs-gpios property expected by the SPI core as is
On Sat, Jul 19, 2014 at 04:01:27AM +0900, Kukjin Kim wrote:
This removes MACH_SMDKC100 because of no more support for SMDKC100.
Reported-by: Paul Bolle pebo...@tiscali.nl
Signed-off-by: Kukjin Kim kgene@samsung.com
Cc: Mark Brown broo...@linaro.org
This doesn't apply against current
commit message. -- broonie]
Signed-off-by: Victor Kamensky victor.kamen...@linaro.org
Signed-off-by: Mark Brown broo...@linaro.org
---
arch/arm/mach-exynos/headsmp.S | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/mach-exynos/headsmp.S b/arch/arm/mach-exynos/headsmp.S
index
victor.kamen...@linaro.org
Signed-off-by: Mark Brown broo...@linaro.org
---
arch/arm/include/debug/samsung.S | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/include/debug/samsung.S b/arch/arm/include/debug/samsung.S
index 8d8d922e5e44..dc62d4ae04d0 100644
--- a/arch/arm/include
On Mon, Jul 21, 2014 at 02:44:07PM +0200, Javier Martinez Canillas wrote:
On 07/14/2014 01:35 PM, Javier Martinez Canillas wrote:
Mark, Mike and Alessandro,
This is a gentle reminder to look at the patches that touches your subsystems
and provide acks if possible so Lee can merge the
On Fri, Jul 25, 2014 at 01:45:14PM +0900, Kukjin Kim wrote:
Basically, I have no objection on this, BTW is there any requirement to
support
big endian on exynos stuff? Just wondering...
We've been using it for testing within Linaro. I don't know of any real
world users.
signature.asc
-3, LD0-1 and fet7
parent supply is indded VDC but the fet1-6 get their input
supply from the DCDC1 and DCDC2 output voltage rails.
Acked-by: Mark Brown broo...@linaro.org
This *should* be independent of the rest of this series.
signature.asc
Description: Digital signature
On Tue, Jul 29, 2014 at 06:28:58PM +0200, Javier Martinez Canillas wrote:
+#define tps65090_REG_VAR(_id, _sname, en_reg, _en_bits, _ops) \
+ tps65090_REG_DESC(_id, _sname, en_reg, _en_bits, 0, 0, _ops)
I'd expect this to describe a variable regulator when in fact it
seems it describes a
On Tue, Jul 29, 2014 at 06:28:55PM +0200, Javier Martinez Canillas wrote:
Load switches are modeled as regulators but they just provide
the voltage of their parent input supply. So the drivers for
Applied, thanks. The term load switch is a bit unusual - they're
usually just called switches (or
On Tue, Jul 29, 2014 at 06:28:56PM +0200, Javier Martinez Canillas wrote:
Load switches are modeled as regulators but they just provide
the voltage of their parent input supply. So, the drivers for
these switches usually neither provide a .list_voltage handler
not set a .n_voltages count. But
On Sun, Jul 20, 2014 at 11:43:07AM +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(). Also
On Wed, Jul 30, 2014 at 10:49:25AM +0200, Javier Martinez Canillas wrote:
On 07/29/2014 07:18 PM, Mark Brown wrote:
I would also expect any regulator where the supplied devices are able to
vary the voltage to explicitly provide a constraint even if the
implementation is done in a parent
From: Mark Brown broo...@linaro.org
When printing size_t values we should use the %zd or %zx format specifier
in order to ensure the value is displayed correctly and avoid warnings from
sparse.
Signed-off-by: Mark Brown broo...@linaro.org
---
drivers/dma/amba-pl08x.c | 4 ++--
1 file changed, 2
On Wed, Jul 30, 2014 at 11:29:27PM +0200, Andreas Färber wrote:
Specification and existing device trees use vsys-l{1,2}-supply,
not vsys_l{1,2}-supply. Fix the example to match the specification.
Applied. I've previously reminded you to use subject lines appropraite
for the subsystem, please
On Mon, Aug 11, 2014 at 08:57:24AM -0700, Doug Anderson wrote:
On Mon, Aug 11, 2014 at 4:38 AM, Javier Martinez Canillas
After the switch is turned on, a safety timer is started
and before this timer times out the output voltage must
have reached the input voltage. Otherwise the switch is
On Tue, Aug 12, 2014 at 06:44:23PM +0200, Javier Martinez Canillas wrote:
The tps65090 is a Power Management Unit (PMU) used in several
boards so the same information is described on different DTS.
It is better to create a .dtsi fragment that can be included.
Why is it better to do this?
+
On Tue, Aug 12, 2014 at 08:49:29PM +0200, Javier Martinez Canillas wrote:
So, is adding these voltages ranges (the design limits) in the Peach Pit DTS
file directly an acceptable solution? Basically what my previous patch [0]
did.
That matches what is in the board schematic so I assume that
On Wed, Aug 13, 2014 at 01:31:44PM +0200, Javier Martinez Canillas wrote:
Please fix your mailer to word wrap at less than 80 columns, it makes
your mails very hard to read when replying.
On 08/12/2014 11:27 PM, Mark Brown wrote:
Well, I think the question is if you understand where those
On Wed, Aug 13, 2014 at 03:34:12PM +0200, Javier Martinez Canillas wrote:
Indeed. I'll change mmc_regulator_get_ocrmask() in MMC core then to use
regulator_can_change_voltage() to detect if the regulator is a fixed one
and call regulator_get_voltage() instead of list_voltage() in that case.
On Thu, Aug 14, 2014 at 07:13:00AM -0700, Tim Kryger wrote:
On Thu, Aug 14, 2014 at 5:39 AM, Javier Martinez Canillas
Without this patch, the following warning is reported when
a FET is used as a vmmc-supply:
dwmmc_exynos 1222.mmc: Failed getting OCR mask: -22
Signed-off-by: Javier
On Thu, Aug 14, 2014 at 10:36:18PM -0700, Tim Kryger wrote:
On Thu, Aug 14, 2014 at 8:19 AM, Mark Brown broo...@kernel.org wrote:
Right, there's two things going on here. One is that as you describe we
shouldn't be putting constraints in .dtsi files if we don't know they're
OK
On Fri, Aug 15, 2014 at 09:48:43AM +0200, Javier Martinez Canillas wrote:
But now I wonder why regulator_list_voltage() even list the voltage for
fixed regulators (desc-fixed_uV) since they don't have the ability to
vary voltage. The regulator_list_voltage() documentation says:
That's because
On Fri, Aug 15, 2014 at 07:19:41AM -0700, Tim Kryger wrote:
That is a little different from my suggestion where the constraints
check is skipped when the regulator output is fixed. It effectively
does this now when the regulator itself provides the fixed voltage.
However, the checks aren't
On Fri, Aug 15, 2014 at 04:51:38PM +0200, Ulf Hansson wrote:
Just wanted to add some input regarding the errors in the mmc case.
These are of high importance. In principle if you get, Failed getting
OCR mask: -22, likely you will be using a wrong OCR mask while
negotiating the voltage level
On Tue, Jul 15, 2014 at 04:32:51PM +0530, Amit Daniel Kachhap wrote:
This is a cleanup patch and moves min/step voltages in a common samsung
header file so that they can be used by other s2mpxxx PMIC drivers. Only
few required macros are added currently and others can be added if needed.
On Sun, Aug 17, 2014 at 10:11:30AM -0700, Tim Kryger wrote:
On Fri, Aug 15, 2014 at 3:29 PM, Mark Brown broo...@kernel.org wrote:
Nobody has written suitable code, and please bear in mind that even if
the code is written there will probably be cases where it's too
expensive for whatever
On Mon, Aug 18, 2014 at 10:32:42AM +0200, Javier Martinez Canillas wrote:
Add Device Tree binding documentation for the regulators
present in the Maxim 77802 Power Management IC.
Applied, thanks.
signature.asc
Description: Digital signature
On Mon, Aug 18, 2014 at 10:32:41AM +0200, Javier Martinez Canillas wrote:
The MAX77802 PMIC has 10 high-efficiency Buck and 32 Low-dropout
(LDO) regulators. This patch adds support for all these regulators
found on the MAX77802 PMIC and is based on a driver added by Simon
Glass to the Chrome
On Fri, Aug 22, 2014 at 02:15:46PM +0200, Javier Martinez Canillas wrote:
Mark, any opinions on how this should be solved will be highly appreciated.
If someone could tell me what this is that'd help...
signature.asc
Description: Digital signature
On Fri, Aug 22, 2014 at 07:53:19PM +0200, Javier Martinez Canillas wrote:
On 08/22/2014 04:45 PM, Mark Brown wrote:
On Fri, Aug 22, 2014 at 02:15:46PM +0200, Javier Martinez Canillas wrote:
Mark, any opinions on how this should be solved will be highly appreciated.
If someone could tell
On Mon, Aug 25, 2014 at 08:40:40AM -0700, Doug Anderson wrote:
On Mon, Aug 25, 2014 at 2:07 AM, Javier Martinez Canillas
I see, so probably until we have a way to define the operating mode for
each regulator using DT we should set the opmode to normal when enabling a
regulator
On Tue, Aug 26, 2014 at 11:08:07AM +0200, Javier Martinez Canillas wrote:
On 08/26/2014 09:17 AM, Mark Brown wrote:
No, this doesn't make any obvious sense to me at all. Picking normal as
a default if the hardware reads back off due to overlapping
impelementation or something *might* make
From: Mark Brown broo...@linaro.org
Since this is a platform driver and can be probed at any time we can't
annotate funtions in the probe path as __init, the code can't safely be
discarded at the end of kernel init.
Signed-off-by: Mark Brown broo...@linaro.org
---
drivers/cpufreq/s5pv210
On Tue, Aug 26, 2014 at 01:37:41PM +0200, Javier Martinez Canillas wrote:
The max77802 driver reads the default operating mode (opmode)
set for regulators when enabled from the hardware registers.
Applied, thanks.
signature.asc
Description: Digital signature
On Wed, Aug 27, 2014 at 08:32:38PM +0200, Tomasz Figa wrote:
On 26.08.2014 13:37, Javier Martinez Canillas wrote:
+ /*
+* If the regulator is disabled and the system warm rebooted,
+* the hardware reports OFF as the regulator operating mode.
+
On Wed, Aug 27, 2014 at 08:39:39PM +0200, Tomasz Figa wrote:
On 27.08.2014 20:37, Mark Brown wrote:
That's essentially the situation the patch is trying to fix - if we boot
and the regulator is off there's no way to figure out what the operating
mode would have been so we have to pick
On Wed, Aug 27, 2014 at 08:52:49PM +0200, Tomasz Figa wrote:
On 27.08.2014 20:47, Mark Brown wrote:
I'm not convinced that's worth it - chances are that if anything changed
the mode it was a previously running Linux which will most likely be
doing the same things when it starts running
On Wed, Aug 27, 2014 at 09:58:55PM +0200, Tomasz Figa wrote:
On 27.08.2014 21:44, Mark Brown wrote:
The point is that if anything was setting the mode to something other
than normal it was almost certainly a previously running copy of Linux
and one would expect that if the mode does need
On Wed, Aug 27, 2014 at 10:41:42PM +0200, Tomasz Figa wrote:
On 27.08.2014 22:25, Mark Brown wrote:
Well, presumably the bootloader is going to run again even for a warm
reboot?
This is strange, but apparently it's not the case for the hardware which
this patch is supposed to fix
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 tomasz.f...@gmail.com 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*
On Thu, Aug 28, 2014 at 11:59:16AM +0200, Javier Martinez Canillas wrote:
On 28/08/2014, at 10:28, Mark Brown broo...@kernel.org wrote:
Yes, AFAIK the bootloader (none of them because Chromebooks use two
chained U-boots) change the regulators default opmode so once is set
to OFF
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 that
On Sun, Sep 07, 2014 at 09:36:56PM -0700, Doug Anderson wrote:
On Sun, Sep 7, 2014 at 8:52 AM, Tomasz Figa tomasz.f...@gmail.com 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
On Mon, Sep 08, 2014 at 01:20:11PM +0100, Grant Likely wrote:
On Mon, Sep 8, 2014 at 12:21 PM, Will Deacon will.dea...@arm.com 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
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.
On Wed, Sep 10, 2014 at 06:06:46AM -0700, Olof Johansson wrote:
On Mon, Sep 8, 2014 at 12:40 PM, Grant Likely grant.lik...@secretlab.ca
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
On Wed, Sep 10, 2014 at 03:56:16PM +0100, Grant Likely wrote:
On Wed, Sep 10, 2014 at 3:31 PM, Mark Brown broo...@kernel.org 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 is a bad
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 09:36:32AM -0700, Olof Johansson wrote:
On Wed, Sep 10, 2014 at 7:31 AM, Mark Brown broo...@kernel.org 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
wrapper stage
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 Thu, Sep 11, 2014 at 10:06:08AM +0100, Grant Likely wrote:
On Wed, 10 Sep 2014 15:31:44 +0100, Mark Brown broo...@kernel.org 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
wrapper
On Thu, Sep 11, 2014 at 10:22:32AM +0100, Grant Likely wrote:
On Wed, 10 Sep 2014 17:57:23 +0100, Mark Brown broo...@kernel.org 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
(which is going
701 - 800 of 1104 matches
Mail list logo
