On Thu, Apr 07, 2011 at 09:31:10AM +0900, Sangbeom Kim wrote:
+config SND_SOC_SAMSUNG_SMDK_WM8580_PCM
+ tristate
+
What is the purpose of this variable? Just the config for the machine
should be enough.
@@ -1,12 +1,12 @@
-# S3c24XX Platform Support
+# SAMSUNG Platform Support
On Sat, Apr 09, 2011 at 10:53:58AM +0900, Sangbeom Kim wrote:
Fix the inverted clocks handling for pcm cpu driver.
By using SND_SOC_DAIFMT_NB_NF, Audio noise can be generated on SMDK.
Signed-off-by: Sangbeom Kim sbki...@samsung.com
Applied, thanks.
--
To unsubscribe from this list: send the
On Tue, Apr 19, 2011 at 10:46:47AM +0900, Kukjin Kim wrote:
- Device tree (with Linaro)
What is going on with device tree? I've asked a couple of times about
this in the other thread but I'm still not clear where the code is or
what could usefully be done with it.
--
To unsubscribe from this
after the restore code puts the original configurations
back in after the
Signed-off-by: Ben Dooks ben-li...@fluff.org
Signed-off-by: Mark Brown broo...@opensource.wolfsonmicro.com
---
arch/arm/mach-s3c2410/include/mach/pm-core.h |3 +++
arch/arm/mach-s3c64xx/include/mach/pm-core.h | 17
On Thu, Apr 28, 2011 at 10:32:50AM +0900, Sangbeom Kim wrote:
This is 2nd patchset for WM8994 pcm machine driver that supports
PCM audio on SMDKV310, SMDKC210 and test is done.
As with your first patch set I'm waiting for a response from Kukjin
here. I'm expecting that the arch/arm parts
On Thu, Apr 28, 2011 at 10:32:52AM +0900, Sangbeom Kim wrote:
+ /* Set the codec DAI configuration */
+ ret = snd_soc_dai_set_fmt(codec_dai, SND_SOC_DAIFMT_DSP_B
+ | SND_SOC_DAIFMT_IB_NF
+ | SND_SOC_DAIFMT_CBS_CFS);
+ if
On Tue, May 17, 2011 at 10:06:23PM +0200, Sylwester Nawrocki wrote:
As we have I2C, SPI and platform device v4l subdevs ideally those buses should
support Runtime PM.
They all do so.
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to
On Tue, May 31, 2011 at 11:10:36AM +0530, Giridhar Maruthy wrote:
--- a/arch/arm/mach-exynos4/Kconfig
+++ b/arch/arm/mach-exynos4/Kconfig
@@ -12,6 +12,7 @@ if ARCH_EXYNOS4
config CPU_EXYNOS4210
bool
select S3C_PL330_DMA
+ select I2C_S3C2410 if MFD_WM8994
help
On Tue, Jun 07, 2011 at 07:29:23PM +0100, Russell King - ARM Linux wrote:
2. Circular buffer support has been added - see device_prep_dma_cyclic().
However, 2 is not really a requirement for audio - you can queue several
single slave transfers (one per period) initially, and then you get
On Wed, Jun 08, 2011 at 12:31:42AM +0530, Jassi Brar wrote:
On Wed, Jun 8, 2011 at 12:13 AM, Mark Brown
Circular buffers are nice from the point of view of allowing you to
(providing the hardware supports it) totally disable the periodic audio
interrupts and leave the system to run
On Wed, Jun 08, 2011 at 08:21:08AM +0530, Jassi Brar wrote:
On Wed, Jun 8, 2011 at 3:11 AM, Mark Brown
That's fairly unusual, though - usually DMA controllers seem to support
chaining requests before they support circular operation, at which point
unless the hardware is badly misdone you
On Thu, Jun 09, 2011 at 05:09:09PM +0900, Sangbeom Kim wrote:
Change platform driver to support internal dma
for smdk_wm8994 and smdk_wm8580
When you resubmit for the API change update it'd be helpful to update
the changelog to explain why the platforms are being changed to use only
internal
On Fri, Jun 10, 2011 at 12:56:45PM +0530, Jassi Brar wrote:
On Fri, Jun 10, 2011 at 12:46 PM, Sangbeom Kim sbki...@samsung.com wrote:
I only focused on S5PV210 and S5PV310.
I didn't consider s3c and s5p series.
In the next version, I will delete it.
Though if then everything works fine
On Fri, Jun 10, 2011 at 03:42:27PM +0530, Jassi Brar wrote:
On Fri, Jun 10, 2011 at 3:19 PM, Mark Brown
If iDMA is always a better choice on CPUs that support it then the
cpu_is_() macros might be a good way to make the selection?
Actually I remembered just after I posted - iDMA wouldn't
On Fri, Jun 10, 2011 at 12:04:27PM +0530, Naveen Krishna Chatradhi wrote:
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
Applied, thanks.
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More
On Tue, Jun 21, 2011 at 11:07:13AM +0900, MyungJoo Ham wrote:
+#include linux/platform_data/ntc_thermistor.h
This doesn't appear to be in mainline.
+/* NTC Thermistor */
+static struct platform_device nuri_ncp15wb473_thermistor;
+static int read_thermistor_uV(void)
Blank line between these
On Tue, Jun 21, 2011 at 11:07:10AM +0900, MyungJoo Ham wrote:
Signed-off-by: MyungJoo Ham myungjoo@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
This looks good, though you should also be able to make the supply lists
into __initdata.
--
To unsubscribe from this list:
On Tue, Jun 21, 2011 at 11:03:12AM +0530, Tushar Behera wrote:
Will it be possible to move PMIC specific defines to a common file
and make appropriate calls in the board-specific file?
In that way, we can re-use this PMIC code on some other boards (e.g.
Insignal low-cost board Origen
On Mon, Jun 20, 2011 at 10:43:50AM -0600, Grant Likely wrote:
I think I've commented on this before, but I do try to avoid direct
coding registers into the DT. That said, sometimes there really isn't
a nice human-friendly way of encoding things and direct register
values is the best
On Tue, Jun 21, 2011 at 05:19:14PM +0530, Tushar Behera wrote:
On Tuesday 21 June 2011 04:40 PM, Mark Brown wrote:
If the board is similar enough in design to be sharing the PMIC code
that sounds like it should be sharing a lot more of the board setup
code.
Origen board details can be found
On Wed, Jun 22, 2011 at 02:00:37PM +0900, MyungJoo Ham wrote:
On Tue, Jun 21, 2011 at 7:50 PM, Mark Brown
+#include linux/platform_data/ntc_thermistor.h
This doesn't appear to be in mainline.
Right, not just yet. I should've added comment about the patch just
being applied to next.
I
On Wed, Jun 22, 2011 at 05:07:41PM +0900, Kukjin Kim wrote:
if (freqs.new freqs.old) {
/* Voltage up: will be implemented */
Presumably this comment is bitrotted?
+ if (!IS_ERR(arm_regulator)
+ !IS_ERR(int_regulator)) {
You
On Wed, Jun 22, 2011 at 05:07:44PM +0900, Kukjin Kim wrote:
From: Todd Poynor toddpoy...@google.com
Voltage scaling accesses the MAX8998 regulators over bit-banged I2C
with lots of udelays. In the case of decreasing CPU speed, the
number of loops per us for udelay needs to be adjusted prior
On Thu, Jun 30, 2011 at 11:22:50AM +0300, Vasily Khoruzhick wrote:
On Thursday 30 June 2011 10:49:30 MyungJoo Ham wrote:
+ adc-vdd = regulator_get(dev, vdd);
+ if (IS_ERR(adc-vdd)) {
+ dev_err(dev, operating without regulator \vdd\ .\n);
+ ret = PTR_ERR(adc-vdd);
On Fri, Jul 01, 2011 at 05:15:05PM +0200, Linus Walleij wrote:
There is no clean nice ADC subsystem though, and *that* feels
like a big problem to drivers like this (and no I don't like the AB8500
GPADC living in MFD either) so if you'd like to create a ADC
subsystem just go ahead, there is
On Fri, Jul 01, 2011 at 07:23:13PM +0200, Arnd Bergmann wrote:
On Friday 01 July 2011, Mark Brown wrote:
The other issue is that it's designed for high volume data and these
AUXADCs tend to be relatively slow. That said I've had some discussions
with Jonathan about supporting
On Mon, Jul 04, 2011 at 10:42:51AM -0600, Grant Likely wrote:
Wow. A lot of #ifdefs here. It does not look multiplatform friendly
at all. Are the s3c2410_dma functions obsolete when DMADEV_PL330 is
selected? If so, can they be removed entirely, or are they required
to support certain
On Mon, Jul 04, 2011 at 09:18:35PM +0900, Kukjin Kim wrote:
+static void audio_buffdone(void *data)
+{
+ struct snd_pcm_substream *substream = data;
+ struct runtime_data *prtd;
+ struct dma_chan *chan;
+
+ prtd = substream-runtime-private_data;
+
+ chan =
On Tue, Jul 05, 2011 at 05:06:19PM +0900, Kukjin Kim wrote:
+int exynos4_cpufreq_lock(unsigned int nId,
+ enum cpufreq_level_request cpufreq_level);
+void exynos4_cpufreq_lock_free(unsigned int nId);
This feels like something cpufreq should support to at least some extent
On Wed, Jul 13, 2011 at 04:52:06PM +0530, Giridhar Maruthy wrote:
Using 256fs or 512fs will result in distortion of 24-bit
audio samples. This is because the lrclk generated is not
proper. Using 384 fs generates proper output.
Applied, thanks.
--
To unsubscribe from this list: send the line
On Wed, Jul 13, 2011 at 05:47:37PM +0900, Kukjin Kim wrote:
-static inline bool s3c_dma_has_circular(void)
+static inline bool dma_has_circular(void)
{
return false;
}
The namespacing here doesn't look great, this is still a Samsung
specific internal API.
Otherwise this looks good.
driver to transfer PCM data.
Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Jul 18, 2011 at 04:08:53PM +0900, Kukjin Kim wrote:
This feels like something cpufreq should support to at least some extent
in the core, especially the thing with forcing a particular mode on
suspend. Not that I have any particularly bright ideas for how
immediately.
On Sat, Jul 16, 2011 at 02:07:13PM +0900, Kukjin Kim wrote:
Mark Brown wrote:
If there isn't a separate supply for the regulators on S3C24xx devices
then I guess the best option is to provide that supply as a dummy
regulator in the s3c24xx core code.
OK, but it means I can't apply
On Tue, Aug 16, 2011 at 04:38:46PM +0530, Inderpal Singh wrote:
On 14 August 2011 20:31, Mark Brown
broo...@opensource.wolfsonmicro.comwrote:
On Thu, Aug 11, 2011 at 09:26:05AM +0530, Inderpal Singh wrote:
+static struct regulator_consumer_supply __initdata ldo7_consumer
On Tue, Aug 16, 2011 at 06:11:28PM +0530, Banajit Goswami wrote:
Remove un-used backlight code for SMDK6410 board
Is the data actually wrong? If not it'd seem better to finish hooking
it up properly than to remove it.
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc
On Fri, Aug 19, 2011 at 09:40:29AM +0530, Banajit Goswami wrote:
On Fri, Aug 19, 2011 at 7:29 AM, Mark Brown
broo...@opensource.wolfsonmicro.com wrote:
On Tue, Aug 16, 2011 at 06:11:28PM +0530, Banajit Goswami wrote:
Remove un-used backlight code for SMDK6410 board
Is the data actually
On Sat, Jan 11, 2014 at 08:42:43PM +0100, Tomasz Figa wrote:
static struct s3c64xx_pm_domain s3c64xx_pm_irom = {
- .name = IROM,
.ena = S3C64XX_NORMALCFG_IROM_ON,
.pd = {
+ .name = domain_irom,
This is nitpicking a bit but are you sure this is actually a
On Sun, Jan 12, 2014 at 08:03:50PM +0100, Tomasz Figa wrote:
Also, there are multiple devices in most domains, so that would
rather end up being Domain_I (JPEG, Cam I/F), Domain_P (2D, TV
Enc., Scaler), Domain_F (Rot, Post, LCD).
It's not just that there's multiple devices either, it's also
On Sat, Jan 11, 2014 at 08:42:48PM +0100, Tomasz Figa wrote:
This patch adds support for registering power domains of S3C64xx SoCs
and binding devices to them using device tree.
+#ifdef CONFIG_OF
+static struct of_device_id s3c64xx_pd_matches[] = {
+ { .compatible =
On Sun, Jan 12, 2014 at 08:34:10PM +0100, Tomasz Figa wrote:
On 12.01.2014 20:29, Mark Brown wrote:
On Sat, Jan 11, 2014 at 08:42:48PM +0100, Tomasz Figa wrote:
This patch adds support for registering power domains of S3C64xx SoCs
and binding devices to them using device tree.
+#ifdef
On Mon, Jan 13, 2014 at 01:13:52PM +0100, Tomasz Figa wrote:
Power domain control registers are part of the system controller
block, which uses the samsung,s3c64*-clock compatible string. I
know this is a bit unfortunate, but all registers of this IP block
are mapped at the same page and some
between machines and drivers, using it for these broad macros
and config settings is wrong.
Acked-by: Mark Brown broo...@linaro.org
signature.asc
Description: Digital signature
From: Mark Brown broo...@linaro.org
When using dmaengine allow the core to do the DMA mapping. We still need
local mapping code for the non-dmaengine case so this doesn't save us
anything for now.
Signed-off-by: Mark Brown broo...@linaro.org
---
drivers/spi/spi-s3c64xx.c | 178
From: Mark Brown broo...@linaro.org
The process of DMA mapping buffers for SPI transfers does not vary between
devices so in order to save duplication of code in drivers this can be
factored out into the core, allowing it to be integrated with the work that
is being done on factoring out
On Thu, Jan 16, 2014 at 08:18:41AM -0800, Greg KH wrote:
On Thu, Jan 16, 2014 at 10:33:22AM +0530, Tushar Behera wrote:
In a multi-platform scenario, the hard-coded major/minor numbers in
serial drivers may conflict with each other. A typical scenario is
observed with amba-pl011 and
On Thu, Jan 16, 2014 at 09:22:40AM -0800, Greg KH wrote:
On Thu, Jan 16, 2014 at 05:08:14PM +, Mark Brown wrote:
No, the issue is happening because the drivers are registering things
at module load time and not at device instantiation time.
That's a driver bug that could easily
On Mon, Jan 20, 2014 at 09:43:05PM +, Alan Cox wrote:
The dynamic major/minor is the right patch. If the userspace breaks then
the userspace was broken, but I see no evidence in the discussion that
the userspace broke.
The userspace breakage is that if someone has a static /dev that
On Mon, Jan 20, 2014 at 11:47:34PM +, Alan Cox wrote:
Mark Brown broo...@kernel.org wrote:
On Mon, Jan 20, 2014 at 09:43:05PM +, Alan Cox wrote:
The userspace breakage is that if someone has a static /dev that doesn't
handle any dynamic devices then renumbering the device
On Thu, Jan 23, 2014 at 07:47:56PM +0100, Tomasz Figa wrote:
On 23.01.2014 19:40, Mark Brown wrote:
We'd need to leave it user selectable rather than enabling it for ARM,
the whole reason this got noticed is that people are trying to build
kernels that support a wider range of devices for ARM
On Thu, Jan 23, 2014 at 07:51:44PM +, Alan Cox wrote:
That strikes me as rather more risky. We can propogate it through the
drivers as we are sure it is safe to do so on that platform and encourage
driver authors to migrate. Better than a big bang and the inevitable
fallout.
I don't see
On Thu, Jan 23, 2014 at 09:33:21PM +, Alan Cox wrote:
Mark Brown broo...@kernel.org wrote:
I don't see how we can meaningfully test this on a platform - the kernel
would have to be pretty demented to care, it's userspace that cares and
that's not really tied to individual serial
From: Mark Brown broo...@linaro.org
There is no meaningful code sharing between the PIO and DMA variants
(just the timeout calculation) so in order to make the code easier to
work with split the two cases.
Looking at the code it is not clear how the PIO version works for large
transmits, greater
On Sun, Jan 26, 2014 at 01:36:53PM -0800, Dmitry Torokhov wrote:
On Sat, Jan 25, 2014 at 11:35:54PM +0530, Manish Badarkhe wrote:
Use devm_regulator_register instead of regulator_register
which simplifies the code.
... and also breaks the driver: now you are freeing desc-name and
On Fri, Jan 24, 2014 at 02:38:59PM +, Alan Cox wrote:
Mark Brown broo...@kernel.org wrote:
I don't see how that follows? For the most part architecture
maintainers aren't going to be able to say too much about which
userspaces are being run on their platforms if the architecture
has
On Fri, Jan 24, 2014 at 02:37:58PM +0100, Krzysztof Kozlowski wrote:
Add documentation for new binding for controlling (enable/disable) the
Buck9 Converter by GPIO (BUCK9EN).
Applied, thanks.
signature.asc
Description: Digital signature
On Tue, Jan 28, 2014 at 02:31:32PM +0530, Manish Badarkhe wrote:
On Tue, Jan 28, 2014 at 2:25 PM, Heiko Stübner he...@sntech.de wrote:
I don't have a strong opinion on this and others are most likely more
qualified
to have a definitive answer, I just found it strange to exchange one
From: Mark Brown broo...@linaro.org
We cannot unconditionally use dma_map_single() to map data for use with
SPI since transfers may exceed a page and virtual addresses may not be
provided with physically contiguous pages. Further, addresses allocated
using vmalloc() need to be mapped differently
On Wed, Feb 05, 2014 at 07:30:57AM +0100, Marek Vasut wrote:
On Sunday, February 02, 2014 at 02:52:52 PM, Mark Brown wrote:
+static int spi_map_buf(struct spi_master *master, struct device *dev,
+ struct sg_table *sgt, void *buf, size_t len,
+ enum
On Fri, Feb 07, 2014 at 01:40:33PM +0100, Krzysztof Kozlowski wrote:
I can't find these patches in your tree. Did you applied them or am I
missing something?
They're there now.
signature.asc
Description: Digital signature
From: Mark Brown broo...@linaro.org
Remove functions that only had an effect when using S3C_DMA and inline
dmaengine_terminate_all() since it's pointless to have a function which
expands to a single function call.
Signed-off-by: Mark Brown broo...@linaro.org
---
drivers/spi/spi-s3c64xx.c | 39
From: Mark Brown broo...@linaro.org
All the platforms which use the old S3C_DMA API have now been converted to
dmaengine so we can remove the legacy code from the driver, simplifying
maintenance.
Signed-off-by: Mark Brown broo...@linaro.org
---
drivers/spi/spi-s3c64xx.c | 191
On Sun, Feb 09, 2014 at 07:47:52PM +0100, Richard Weinberger wrote:
The symbol is an orphan, get rid of it.
Please fix whatever script you're using to generate your mails, it's
generating corrupt headers. Please also use subject lines consistent
with the rest of the subsystem - between the two
On Mon, Feb 10, 2014 at 02:31:12PM +0100, Paul Bolle wrote:
On Mon, 2014-02-10 at 11:41 +, Mark Brown wrote:
On Sun, Feb 09, 2014 at 07:47:52PM +0100, Richard Weinberger wrote:
Please fix whatever script you're using to generate your mails, it's
generating corrupt headers.
I think
On Mon, Feb 10, 2014 at 04:30:42PM +0100, Paul Bolle wrote:
On Mon, 2014-02-10 at 14:12 +, Mark Brown wrote:
Yes, that's correct. Now, like I say think about what the symbol was
there for in the first place.
So, next step: the Kconfig symbols MACH_SMDKV310 and MACH_SMDKC210 were
On Mon, Feb 10, 2014 at 10:25:31PM +0100, Paul Bolle wrote:
Signed-off-by: Paul Bolle pebo...@tiscali.nl
Applied, thanks.
signature.asc
Description: Digital signature
On Mon, Feb 10, 2014 at 11:09:19PM +0100, Paul Bolle wrote:
See, if you scan v3.10:arch/arm/mach-exynos/mach-smdkv310.c you'll
notice the string smdk-audio. If you grep that string you get a few
hits. But none in v3.10:sound/soc/samsung/smdk_wm9713.c. And if you scan
On Thu, Feb 13, 2014 at 01:37:03PM +0100, Krzysztof Kozlowski wrote:
Add __initconst to 'regulator_desc' array with supported regulators.
During probe choose how many and which regulators will be supported
according to device ID. Then copy the 'regulator_desc' array to
allocated memory so the
On Thu, Feb 13, 2014 at 10:14:04AM +0100, Krzysztof Kozlowski wrote:
S2MPS11/S2MPS14 regulators support different modes of operation:
- Always off;
- On/Off controlled by pin/GPIO (PWREN/LDOEN/EMMCEN);
- Always on;
This is very similar to S5M8767 regulator driver which also supports
On Thu, Feb 13, 2014 at 10:14:02AM +0100, Krzysztof Kozlowski wrote:
Add support for S2MPS14 PMIC regulators to s2mps11 driver. The S2MPS14
has fewer BUCK-s and LDO-s than S2MPS11. It also does not support
controlling the BUCK ramp delay.
How different are the other Samsung PMICs? They share
On Fri, Feb 14, 2014 at 08:38:16PM +0800, Axel Lin wrote:
Set bits_per_word_mask so spi core will reject transfers that attempt to use
an unsupported bits_per_word value.
Applied, thanks.
signature.asc
Description: Digital signature
On Fri, Feb 14, 2014 at 09:15:12AM +0100, Krzysztof Kozlowski wrote:
My initial idea was to do this similarly to the S5M8767 regulator (where
there is also 4th mode: low power). The presence of GPIO in DTS can
simplify the bindings but on the other hand it wouldn't be compatible
with S5M8767
On Fri, Feb 14, 2014 at 02:05:56PM +0100, Krzysztof Kozlowski wrote:
On Thu, 2014-02-13 at 17:46 +0530, Yadwinder Singh Brar wrote:
- low-power mode;
- low-power mode controlled by PWREN;
Although not all are present for each regulator.
What exactly is low power mode and how does it
On Mon, Feb 17, 2014 at 03:35:18PM +, One Thousand Gnomes wrote:
We've identified a correct working approach which is to simply add a
CONFIG entry to the ARM tree and a few ifdefs to the problem drivers to
make the problem (in fact a complete fictional non-problem) go away and
to get rid
On Mon, Feb 17, 2014 at 09:07:34AM +0100, Krzysztof Kozlowski wrote:
The low power maps to REGULATOR_MODE_IDLE or REGULATOR_MODE_STANDBY
(depending on the understanding of more efficient and most efficient
for light loads). However the suspend mode of S5M8767/S2MPS14 is more
like automatic
On Tue, Feb 18, 2014 at 09:12:09AM +0100, Krzysztof Kozlowski wrote:
On Tue, 2014-02-18 at 09:35 +0900, Mark Brown wrote:
I don't understand the above? Are you saying that suspend mode actually
turns off the regulator or something else? If it's a separate setting
for suspend mode
On Wed, Feb 19, 2014 at 11:09:40AM +0100, Krzysztof Kozlowski wrote:
I can't only find a way to set this from DTS. There are no bindings for
regulation_constraints-state_{disk,mem,standby}.
Should the driver set manually after obtaining init_data from DTS?
Someone should work out a suitably
On Tue, Feb 18, 2014 at 10:09:43AM +, Etched Pixels wrote:
Mark Brown broo...@kernel.org wrote:
It's a very real problem which affects actual kernels that distro style
users are building.
Only because you persist in trying to keep the old static minor
numbers even though
On Wed, Feb 19, 2014 at 03:19:00PM +0100, Krzysztof Kozlowski wrote:
As I understand the suspend mode (correct me if I'm wrong), the
regulator core during suspend to mem:
1. Calls suspend_set_state().
2. rstate-disabled is true so the ops-set_suspend_disable() is called.
3. The
On Wed, Feb 19, 2014 at 02:47:51PM +, One Thousand Gnomes wrote:
anything to complain that people are following the recommendations of
the maintainer or to demand that this somehow gets hacked around in
arch/ when we're trying to convince all the architectures to get their
drivers
On Fri, Feb 28, 2014 at 10:43:09PM +0100, Paul Bolle wrote:
That commit is fine with me, of course. I now see no reason to continue
my, rather slowly progressing, search for the problem that you wanted to
get properly fixed. I suppose another commit already fixed it.
No, but it's someone from
On Fri, Feb 28, 2014 at 11:01:49AM +0100, Krzysztof Kozlowski wrote:
Constify the regulator_desc 'regulators' array.
Applied, thanks.
signature.asc
Description: Digital signature
On Fri, Feb 28, 2014 at 11:01:50AM +0100, Krzysztof Kozlowski wrote:
Add __initconst to 'regulator_desc' array with supported regulators.
During probe choose how many and which regulators will be supported
according to device ID. Then copy the 'regulator_desc' array to
allocated memory so the
the generic framework in further patch.
Reviwed-by: Mark Brown broo...@linaro.org
(mainly the binding)
signature.asc
Description: Digital signature
-by: Mark Brown broo...@linaro.org
signature.asc
Description: Digital signature
On Mon, Mar 03, 2014 at 05:02:10PM +0100, Tomasz Figa wrote:
This patch adds always_on field to s3c64xx_pm_domain struct to allow
handling registration of all domains in the same way, without the need
to have separate arrays for normal and always on domains.
Reviwed-by: Mark Brown broo
On Mon, Mar 03, 2014 at 05:02:11PM +0100, Tomasz Figa wrote:
There is a status bit for domain G present in BLK_PWR_STAT register, but
it is currently not specified in the driver.
This patch adds the status bit of domain G to structure describing it.
Reviwed-by: Mark Brown broo...@linaro.org
On Mon, Mar 03, 2014 at 05:02:14PM +0100, Tomasz Figa wrote:
This patch adds device tree nodes for power domains available on S3C64xx
SoCs.
Reviwed-by: Mark Brown broo...@linaro.org
signature.asc
Description: Digital signature
On Mon, Mar 03, 2014 at 05:02:12PM +0100, Tomasz Figa wrote:
This patch adds support for registering power domains of S3C64xx SoCs
and binding devices to them using device tree.
Reviwed-by: Mark Brown broo...@linaro.org
signature.asc
Description: Digital signature
On Mon, Mar 03, 2014 at 05:02:13PM +0100, Tomasz Figa wrote:
This patch adds call to s3c64xx_pm_init() from init_machine() callback
of mach-s3c64xx-dt to enable SoC-level power management features, such
as power domain management and sleep support.
Reviewed-by: Mark Brown broo...@linaro.org
On Wed, Mar 05, 2014 at 10:22:52AM +0100, Krzysztof Kozlowski wrote:
+ ret = regmap_read(rdev-regmap, rdev-desc-enable_reg, data);
+ if (ret 0)
+ return ret;
+
+ /*
+ * Don't enable suspend mode if regulator is already disabled because
+ * this would
On Thu, Mar 06, 2014 at 10:48:54AM +0100, Krzysztof Kozlowski wrote:
Anyway can you look at other two patches and apply them if they are OK?
They don't depend on this.
There appears to be some external dependency for the definition of
macros like S2MPS14X?
signature.asc
Description: Digital
On Thu, Mar 06, 2014 at 03:42:22PM +0100, Krzysztof Kozlowski wrote:
However in that case the driver won't be able later to change that value
back to normal enable (enable_mask). Consider such flow:
1. System is going to suspend.
2. Some regulator has rstate-disabled so set_suspend_disable()
On Wed, Mar 05, 2014 at 03:17:23PM +0800, Axel Lin wrote:
This is required since commit 2025172e3280 spi/bitbang: Use core message
pump.
spi-bitbang now uses core message pump, so it needs to call
spi_master_suspend/
spi_master_resume to start/stop the queue while suspend/resume.
Applied,
On Thu, Mar 13, 2014 at 10:33:29AM +, Mark Rutland wrote:
On Wed, Mar 12, 2014 at 04:31:56AM +, Kukjin Kim wrote:
+/ {
+ model = SAMSUNG SSDK-GH7 board based on GH7 SoC;
Is the based on GH7 SoC part necessary? Does the SSDK-GH7 not give
that away?
In this case,
From: Mark Brown broo...@linaro.org
serial_s3c.h uses upf_t which is defined in serial_core.h but does not
include that itself meaning that users which include serial_s3c.h by
itself don't build.
Signed-off-by: Mark Brown broo...@linaro.org
---
This is needed together with patch 2 to fix build
From: Mark Brown broo...@linaro.org
Some very recent change appears to have removed an implicit inclusion of
serial_s3c.h causing build failures due to references to UART registers
in the serial port restore code in next-20140318. Include it explicitly
to fix the build.
Signed-off-by: Mark
On Tue, Mar 18, 2014 at 06:34:12PM +0100, Krzysztof Kozlowski wrote:
Lee Jones in his pull request [1] put also my changes for S2MPS14
support in MFD sec-core driver. They are needed by this patchset for adding
suppt for regulators on S2MPS14.
Do you have time to look at these patches and
On Mon, Mar 31, 2014 at 11:37:29AM +0800, Axel Lin wrote:
Simplify the cleanup code.
Applied, thanks.
signature.asc
Description: Digital signature
On Mon, Apr 07, 2014 at 02:15:23PM +0200, Krzysztof Kozlowski wrote:
During registration of regulators if external control for regulator was
set in DTS the ena_gpio and ena_gpio_flags fields of regulator_config
were set to proper values.
Applied, thanks.
signature.asc
Description: Digital
601 - 700 of 1104 matches
Mail list logo
