* [PATCH] cpufreq: exynos: Broadcast frequency change notifications for all cores
From: Tomasz Figa @ 2012-11-13 9:26 UTC (permalink / raw)
To: linux-arm-kernel
On Exynos SoCs all cores share the same frequency setting, so changing
frequency of one core will affect rest of cores.
This patch modifies the exynos-cpufreq driver to inform cpufreq core
about this behavior and broadcast frequency change notifications for all
cores.
Signed-off-by: Tomasz Figa <t.figa@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
---
drivers/cpufreq/exynos-cpufreq.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/cpufreq/exynos-cpufreq.c b/drivers/cpufreq/exynos-cpufreq.c
index af2d81e..c0d54a8 100644
--- a/drivers/cpufreq/exynos-cpufreq.c
+++ b/drivers/cpufreq/exynos-cpufreq.c
@@ -100,7 +100,8 @@ static int exynos_target(struct cpufreq_policy *policy,
}
arm_volt = volt_table[index];
- cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
+ for_each_cpu(freqs.cpu, policy->cpus)
+ cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
/* When the new frequency is higher than current frequency */
if ((freqs.new > freqs.old) && !safe_arm_volt) {
@@ -115,7 +116,8 @@ static int exynos_target(struct cpufreq_policy *policy,
if (freqs.new != freqs.old)
exynos_info->set_freq(old_index, index);
- cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
+ for_each_cpu(freqs.cpu, policy->cpus)
+ cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
/* When the new frequency is lower than current frequency */
if ((freqs.new < freqs.old) ||
@@ -235,6 +237,7 @@ static int exynos_cpufreq_cpu_init(struct cpufreq_policy *policy)
cpumask_copy(policy->related_cpus, cpu_possible_mask);
cpumask_copy(policy->cpus, cpu_online_mask);
} else {
+ policy->shared_type = CPUFREQ_SHARED_TYPE_ANY;
cpumask_setall(policy->cpus);
}
--
1.8.0
^ permalink raw reply related
* [PATCH 0/7] ARM: remove init_consistent_dma_size() stub
From: Arnd Bergmann @ 2012-11-13 9:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50A20AAF.9050809@samsung.com>
On Tuesday 13 November 2012, Marek Szyprowski wrote:
> On 11/13/2012 9:49 AM, Arnd Bergmann wrote:
> > On Tuesday 13 November 2012, Kukjin Kim wrote:
> > > Arnd Bergmann wrote:
> > > >
> > > > Applied patches 2-7 to next/cleanup branch, with the Acks that came in.
> > > >
> > > (- many guys in Cc)
> > >
> > > Hi Arnd,
> > >
> > > If possible, please adding my ack on Samsung stuff.
> > >
> > > Acked-by: Kukjin Kim <kgene.kim@samsung.com>
> > >
> >
> > Thanks for your Ack, but I'd prefer not to redo the branch now, since I already
> > merged other patches on top.
>
> If you redo your branch, please make sure that the patch which removes the
> init_consistent_dma_size() stub from dma-mapping.h (7th in my series) would
> be the last one to avoid build break on git bisect. For unknown reason the
> order of patches on your tree got changed in compared to the series I've
> sent.
Ok, I've redone the branch now and added Kukjin's Ack.
Arnd
^ permalink raw reply
* [PATCH v5 2/3] ASoC: atmel-ssc-dai: register dai and pcm directly
From: Mark Brown @ 2012-11-13 9:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50A20E82.9020704@atmel.com>
On Tue, Nov 13, 2012 at 05:10:26PM +0800, Bo Shen wrote:
> On 11/13/2012 16:30, Mark Brown wrote:
> >Why are you changing this? Single devices are supposed to specify -1 as
> >their id.
> This is for non-dt support, using the id to tell which ssc will be
> used to remap into audio subsystem. Maybe this is a mixed up usage,
> however I can not find good solution, any suggestions?
The machine driver should know which SSC it is using all by itself, it's
specific to a particular machine. This is how it's been doing it since
it was written...
> This is a similar implement as 7840487cd6298f9f931103b558290d8d98d41c49
Don't quote raw commit IDs, they're not legible by humans.
> Yes, this patch is a little more than registration, however when
> change the registration method, the related code will be affected,
> so also clean up them in this patch, do I need to split this patch?
Yes, one change per patch. Having many unrelated changes in one patch
makes it very difficult to review anything.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121113/b893e67e/attachment.sig>
^ permalink raw reply
* [PATCH] ARM: OMAP2+: timer: remove CONFIG_OMAP_32K_TIMER
From: Igor Grinberg @ 2012-11-13 9:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50A14AD1.4070704@ti.com>
On 11/12/12 21:15, Jon Hunter wrote:
>
> On 11/11/2012 05:28 AM, Igor Grinberg wrote:
>>
>>
>> On 11/08/12 21:16, Jon Hunter wrote:
>>>
>>> On 11/08/2012 12:59 PM, Hiremath, Vaibhav wrote:
>>>> On Fri, Nov 09, 2012 at 00:24:23, Hunter, Jon wrote:
>>>>>
>>>>> On 11/08/2012 01:59 AM, Igor Grinberg wrote:
>>>>>
>>>>> [snip]
>>>>>
>>>>>> There is no reliable way to determine which source should be used in runtime
>>>>>> for boards that do not have the 32k oscillator wired.
>>>>>
>>>>> So thinking about this some more and given that we are moving away from
>>>>> board files, if a board does not provide a 32kHz clock source, then this
>>>>> should be reflected in the device-tree source file for that board.
>>>>> Hence, at boot time we should be able to determine if a 32kHz clock
>>>>> source can be used.
>>>>>
>>>>
>>>> Let me feed some more thoughts here :)
>>>>
>>>> The way it is being detected currently is based on timer idle status bit.
>>>> I am worried that, this is the only option we have.
>>>
>>> Why not use device-tree to indicate the presence of a 32k clock source?
>>> This seems like a board level configuration and so device-tree seems to
>>> be the perfect place for this IMO.
>>
>> Well, that is what my commit message says...
>
> Sorry, but that was not clear to me from whats in the commit message.
>From the commit message:
"1) Timer structures and initialization functions are named by the platform
name and the clock source in use. The decision which timer is
used is done statically from the machine_desc structure. In the
future it should come from DT."
The last sentence has it.
The transition to DT is not immediate and we can't (still) neglect
the non-DT setups.
>
> Should we be doing this now instead of adding all these static timer
> init functions?
I don't see this as "adding ...", I see this as expanding the setup
which was previously hidden by the CONFIG_OMAP_32K_TIMER option.
>
> Are there any boards today (supported in the kernel that is), that don't
> support a 32k?
Yes, starting from revision 1.2, CM-T3517 does not have the 32k.
[...]
--
Regards,
Igor.
^ permalink raw reply
* [PATCH] ARM: add get_user() support for 8 byte types
From: Arnd Bergmann @ 2012-11-13 9:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAF6AEGvoXR3YJomjV1YOeNvjr46aYJ2mVxS+jZfH+41+v1nAvw@mail.gmail.com>
On Tuesday 13 November 2012, Rob Clark wrote:
> right, that is what I was worried about.. but what about something
> along the lines of:
>
> case 8: { \
> if (sizeof(x) < 8) \
> __get_user_x(__r2, __p, __e, __l, 4); \
> else \
> __get_user_x(__r2, __p, __e, __l, 8); \
> break; \
> } \
I guess that's still broken if x is 8 or 16 bits wide.
> maybe we need a special variant of __get_user_8() instead to get the
> right 32bits on big vs little endian systems, but I think something
> roughly along these lines could work.
>
> Or maybe in sizeof(x)<8 case, we just __get_user_bad().. I'm not 100%
> sure on whether this is supposed to be treated as an error case at
> compile time or not.
We know that nobody is using that at the moment, so we could define
it to be a compile-time error.
But I still think this is a pointless exercise, a number of people have
concluded independently that it's not worth trying to come up with a
solution, whether one exists or not. Why can't you just use copy_from_user()
anyway?
Arnd
^ permalink raw reply
* [PATCH v5 2/3] ASoC: atmel-ssc-dai: register dai and pcm directly
From: Bo Shen @ 2012-11-13 9:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121113083031.GP18224@opensource.wolfsonmicro.com>
Hi Mark,
On 11/13/2012 16:30, Mark Brown wrote:
> On Mon, Nov 12, 2012 at 03:40:26PM +0800, Bo Shen wrote:
>
>> static struct platform_device sam9g20ek_audio_device = {
>> .name = "at91sam9g20ek-audio",
>> - .id = -1,
>> + .id = 0,
>> };
>
> Why are you changing this? Single devices are supposed to specify -1 as
> their id.
This is for non-dt support, using the id to tell which ssc will be used
to remap into audio subsystem. Maybe this is a mixed up usage, however I
can not find good solution, any suggestions?
This is a similar implement as 7840487cd6298f9f931103b558290d8d98d41c49
>> static int atmel_ssc_startup(struct snd_pcm_substream *substream,
>> struct snd_soc_dai *dai)
>> {
>> - struct atmel_ssc_info *ssc_p = &ssc_info[dai->id];
>> + struct atmel_ssc_info *ssc_p = &ssc_info;
>
> This seems like a very big step backwards, there's now a single global
> variable for the ssc_info which presumably means there can be only one
> SSC active in the system at once. That's changing a lot more than just
> the registration...
This change won't broke other subsystem using ssc, only broke the audio
subsystem if there are two codecs co-exist in a system.
I will fix this in next version.
Yes, this patch is a little more than registration, however when change
the registration method, the related code will be affected, so also
clean up them in this patch, do I need to split this patch?
Thanks.
Best Regards,
Bo Shen
^ permalink raw reply
* linux-next: manual merge of the arm-soc tree with the net-next tree
From: Stephen Rothwell @ 2012-11-13 9:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGhQ9Vx3Y3j0qqkEif09HebFyR+1UYmSbp=3jwuXnoiuWBdymQ@mail.gmail.com>
Hi Joachim,
On Tue, 13 Nov 2012 08:21:26 +0100 Joachim Eastwood <manabian@gmail.com> wrote:
>
> The platform_data/atmel.h include shouldn't be necessary since the
> driver already includes platform_data/macb.h.
>
> Otherwise the fix up looks correct.
Thanks, I have fixed up my fix for tomorrow.
--
Cheers,
Stephen Rothwell sfr at canb.auug.org.au
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121113/07aaa4ef/attachment.sig>
^ permalink raw reply
* [PATCH] ARM: OMAP2+: timer: remove CONFIG_OMAP_32K_TIMER
From: Igor Grinberg @ 2012-11-13 9:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50A14896.1080504@ti.com>
On 11/12/12 21:05, Jon Hunter wrote:
>
> On 11/11/2012 03:16 AM, Igor Grinberg wrote:
>> On 11/08/12 18:20, Tony Lindgren wrote:
>>> * Igor Grinberg <grinberg@compulab.co.il> [121107 23:15]:
>>>> On 11/07/12 19:33, Tony Lindgren wrote:
>>>>>
>>>>> I think this should be the default for the timers as that counter
>>>>> does not stop during deeper idle states.
>>>>
>>>> Well, it is the default as you can see from the patch.
>>>> The problem is that for boards that for some reason do not have
>>>> the 32k wired and rely on MPU/GP timer source, the default will not work
>>>> and currently there is no way for board to specify which timer source
>>>> it can use.
>>>
>>> Yes. I was just wondering if we can avoid patching all the board
>>> files by doing it the other way around by introducing a new
>>> omap_gp_timer rather than renaming all the existing ones?
>>
>> Is the renaming that bad? One line per machine_desc structure?
>> Of course we can skip the renaming, but then it will be less consistent
>> and will not reflect the actual timer source used.
>> I tried to make it flexible as much as possible and self explanatory.
>> So above are my considerations, but at this point in time I don't really
>> care if we rename them or just add a new one, but we have to get rid of
>> the ugly fall back.
>
> I am not sure if you guys disagree, but does it make sense to start
> thinking about this with regard to device-tree? With device-tree all the
> boards files will become obsolete and so we need to be able to handle
> this during boot time and not compile time.
This is understood completely, but I personally think that we should not
neglect the "still not converted to DT boards", because the conversion
takes time and involves much more effort. Also taking into account that
there are subsystems that are still not converted to DT.
Also, removing the CONFIG_OMAP_32K_TIMER _does_ get us closer to handle
the timers init during boot time.
>
>>>
>>>> We have discussed this in San Diego (remember?) and you actually proposed
>>>> this way as a solution. Well, may be I took it a bit further than you
>>>> thought, but this is because the board code cannot know which timer source
>>>> should be used at runtime and the fall back described below, does not work.
>>>
>>> Yes thanks I agree we should get rid of that Kconfig option for sure.
>>>
>>>>>> --- a/arch/arm/mach-omap2/board-2430sdp.c
>>>>>> +++ b/arch/arm/mach-omap2/board-2430sdp.c
>>>>>> @@ -284,6 +284,6 @@ MACHINE_START(OMAP_2430SDP, "OMAP2430 sdp2430 board")
>>>>>> .handle_irq = omap2_intc_handle_irq,
>>>>>> .init_machine = omap_2430sdp_init,
>>>>>> .init_late = omap2430_init_late,
>>>>>> - .timer = &omap2_timer,
>>>>>> + .timer = &omap2_sync32k_timer,
>>>>>> .restart = omap_prcm_restart,
>>>>>> MACHINE_END
>>>>>> --- a/arch/arm/mach-omap2/board-3430sdp.c
>>>>>> +++ b/arch/arm/mach-omap2/board-3430sdp.c
>>>>>> @@ -596,6 +596,6 @@ MACHINE_START(OMAP_3430SDP, "OMAP3430 3430SDP board")
>>>>>> .handle_irq = omap3_intc_handle_irq,
>>>>>> .init_machine = omap_3430sdp_init,
>>>>>> .init_late = omap3430_init_late,
>>>>>> - .timer = &omap3_timer,
>>>>>> + .timer = &omap3_sync32k_timer,
>>>>>> .restart = omap_prcm_restart,
>>>>>> MACHINE_END
>>>>> ...
>>>>>
>>>>> Can't we assume that the default timer is omap[234]_sync32k_timer to
>>>>> avoid renaming the timer entries in all the board files?
>>>>
>>>> Hmmm...
>>>> How will this work with the macros defining the sys_timer structure?
>>>> I would also not want to hide the exact timer used under the default name.
>>>
>>> Can't you just add a new sys_timer (or a new macro) for GP only setups?
>>
>> Of course I can... but I tried to create a flexible generic code, so
>> no meter how a board will be wired, you just need to specify which timer source
>> it uses and be done with it.
>
> If you are concerned about how a board is wired up (if the 32k is
> present), then I think that that is best handled via device-tree and we
> should query device-tree on boot to see what our options are.
>
> What do you guys think?
Yes, but again, you can't neglect the non-DT case... at least
until you have everything converted to DT.
--
Regards,
Igor.
^ permalink raw reply
* [PATCH 0/7] ARM: remove init_consistent_dma_size() stub
From: Marek Szyprowski @ 2012-11-13 8:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201211130849.30280.arnd@arndb.de>
Hello,
On 11/13/2012 9:49 AM, Arnd Bergmann wrote:
> On Tuesday 13 November 2012, Kukjin Kim wrote:
> > Arnd Bergmann wrote:
> > >
> > > Applied patches 2-7 to next/cleanup branch, with the Acks that came in.
> > >
> > (- many guys in Cc)
> >
> > Hi Arnd,
> >
> > If possible, please adding my ack on Samsung stuff.
> >
> > Acked-by: Kukjin Kim <kgene.kim@samsung.com>
> >
>
> Thanks for your Ack, but I'd prefer not to redo the branch now, since I already
> merged other patches on top.
If you redo your branch, please make sure that the patch which removes the
init_consistent_dma_size() stub from dma-mapping.h (7th in my series) would
be the last one to avoid build break on git bisect. For unknown reason the
order of patches on your tree got changed in compared to the series I've
sent.
Best regards
--
Marek Szyprowski
Samsung Poland R&D Center
^ permalink raw reply
* [PATCH 2/2] hwmon: MMA8451: Add mma8451 3 axis digtial accelerometer driver
From: Frank Li @ 2012-11-13 8:54 UTC (permalink / raw)
To: linux-arm-kernel
From: Sammy He <r62914@freescale.com>
Add mma8451 accelerometer driver.
Signed-off-by: Xinyu Chen <xinyu.chen@freescale.com>
Signed-off-by: Sammy He <r62914@freescale.com>
Signed-off-by: Frank Li <Frank.Li@freescale.com>
---
drivers/hwmon/Kconfig | 7 +
drivers/hwmon/Makefile | 1 +
drivers/hwmon/mma8451.c | 426 +++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 434 insertions(+), 0 deletions(-)
create mode 100644 drivers/hwmon/mma8451.c
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 4800d4c..1119a36 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1432,6 +1432,13 @@ config SENSORS_MC13783_ADC
help
Support for the A/D converter on MC13783 and MC13892 PMIC.
+config SENSORS_MMA8451
+ tristate "Freescale MMA8451 device driver"
+ depends on I2C
+ help
+ If you say yes here you get support for the freescale 3 axis
+ accelerometer MMA8451
+
if ACPI
comment "ACPI drivers"
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index a930f09..40e6b10 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -131,6 +131,7 @@ obj-$(CONFIG_SENSORS_W83L785TS) += w83l785ts.o
obj-$(CONFIG_SENSORS_W83L786NG) += w83l786ng.o
obj-$(CONFIG_SENSORS_WM831X) += wm831x-hwmon.o
obj-$(CONFIG_SENSORS_WM8350) += wm8350-hwmon.o
+obj-$(CONFIG_SENSORS_MMA8451) += mma8451.o
obj-$(CONFIG_PMBUS) += pmbus/
diff --git a/drivers/hwmon/mma8451.c b/drivers/hwmon/mma8451.c
new file mode 100644
index 0000000..9ed21be
--- /dev/null
+++ b/drivers/hwmon/mma8451.c
@@ -0,0 +1,426 @@
+/*
+ * mma8451.c - Linux kernel modules for 3-Axis Orientation/Motion
+ * Detection Sensor
+ *
+ * Copyright (C) 2012 Freescale Semiconductor, Inc. All Rights Reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/slab.h>
+#include <linux/i2c.h>
+#include <linux/mutex.h>
+#include <linux/delay.h>
+#include <linux/interrupt.h>
+#include <linux/irq.h>
+#include <linux/hwmon-sysfs.h>
+#include <linux/err.h>
+#include <linux/hwmon.h>
+#include <linux/input-polldev.h>
+#include <linux/regulator/consumer.h>
+
+/*
+ * Defines
+ */
+#define MMA8451_DRV_NAME "mma8451"
+#define MMA8451_I2C_ADDR 0x1C
+#define MMA8451_ID 0x1A
+
+#define POLL_INTERVAL 100
+#define INPUT_FUZZ 32
+#define INPUT_FLAT 32
+#define MODE_CHANGE_DELAY_MS 100
+
+/* register enum for mma8451 registers */
+enum {
+ MMA8451_STATUS = 0x00,
+ MMA8451_OUT_X_MSB,
+ MMA8451_OUT_X_LSB,
+ MMA8451_OUT_Y_MSB,
+ MMA8451_OUT_Y_LSB,
+ MMA8451_OUT_Z_MSB,
+ MMA8451_OUT_Z_LSB,
+
+ MMA8451_F_SETUP = 0x09,
+ MMA8451_TRIG_CFG,
+ MMA8451_SYSMOD,
+ MMA8451_INT_SOURCE,
+ MMA8451_WHO_AM_I,
+ MMA8451_XYZ_DATA_CFG,
+ MMA8451_HP_FILTER_CUTOFF,
+
+ MMA8451_PL_STATUS,
+ MMA8451_PL_CFG,
+ MMA8451_PL_COUNT,
+ MMA8451_PL_BF_ZCOMP,
+ MMA8451_P_L_THS_REG,
+
+ MMA8451_FF_MT_CFG,
+ MMA8451_FF_MT_SRC,
+ MMA8451_FF_MT_THS,
+ MMA8451_FF_MT_COUNT,
+
+ MMA8451_TRANSIENT_CFG = 0x1D,
+ MMA8451_TRANSIENT_SRC,
+ MMA8451_TRANSIENT_THS,
+ MMA8451_TRANSIENT_COUNT,
+
+ MMA8451_PULSE_CFG,
+ MMA8451_PULSE_SRC,
+ MMA8451_PULSE_THSX,
+ MMA8451_PULSE_THSY,
+ MMA8451_PULSE_THSZ,
+ MMA8451_PULSE_TMLT,
+ MMA8451_PULSE_LTCY,
+ MMA8451_PULSE_WIND,
+
+ MMA8451_ASLP_COUNT,
+ MMA8451_CTRL_REG1,
+ MMA8451_CTRL_REG2,
+ MMA8451_CTRL_REG3,
+ MMA8451_CTRL_REG4,
+ MMA8451_CTRL_REG5,
+
+ MMA8451_OFF_X,
+ MMA8451_OFF_Y,
+ MMA8451_OFF_Z,
+
+ MMA8451_REG_END,
+};
+
+enum {
+ MODE_2G = 0,
+ MODE_4G,
+ MODE_8G,
+};
+
+/* mma8451 status */
+struct mma8451_status {
+ u8 mode;
+ u8 ctl_reg1;
+};
+
+static struct mma8451_status mma_status = {
+ .mode = 0,
+ .ctl_reg1 = 0
+};
+
+struct mma8451_data {
+ struct input_polled_dev *idev;
+ struct device *hwmon_dev;
+ struct i2c_client *i2c_client;
+ struct regulator *reg_vdd;
+ struct regulator *reg_vddio;
+};
+
+/***************************************************************
+ *
+ * Initialization function
+ *
+ **************************************************************/
+static int mma8451_init_client(struct i2c_client *client)
+{
+ int result;
+
+ mma_status.ctl_reg1 = 0x00;
+ result =
+ i2c_smbus_write_byte_data(client, MMA8451_CTRL_REG1,
+ mma_status.ctl_reg1);
+ mma_status.mode = MODE_2G;
+ result =
+ i2c_smbus_write_byte_data(client, MMA8451_XYZ_DATA_CFG,
+ mma_status.mode);
+ mma_status.ctl_reg1 |= 0x01;
+ result =
+ i2c_smbus_write_byte_data(client, MMA8451_CTRL_REG1,
+ mma_status.ctl_reg1);
+ mdelay(MODE_CHANGE_DELAY_MS);
+
+ return result;
+}
+
+/***************************************************************
+*
+* read sensor data from mma8451
+*
+***************************************************************/
+static int mma8451_read_data(struct i2c_client *client, short *x, short *y,
+ short *z)
+{
+ u8 tmp_data[7];
+
+ if (i2c_smbus_read_i2c_block_data
+ (client, MMA8451_OUT_X_MSB, 7, tmp_data) < 7) {
+ dev_err(&client->dev, "i2c block read failed\n");
+ return -3;
+ }
+
+ *x = ((tmp_data[0] << 8) & 0xff00) | tmp_data[1];
+ *y = ((tmp_data[2] << 8) & 0xff00) | tmp_data[3];
+ *z = ((tmp_data[4] << 8) & 0xff00) | tmp_data[5];
+
+ *x = (short)(*x) >> 2;
+ *y = (short)(*y) >> 2;
+ *z = (short)(*z) >> 2;
+
+ if (mma_status.mode == MODE_4G) {
+ (*x) = (*x) << 1;
+ (*y) = (*y) << 1;
+ (*z) = (*z) << 1;
+ } else if (mma_status.mode == MODE_8G) {
+ (*x) = (*x) << 2;
+ (*y) = (*y) << 2;
+ (*z) = (*z) << 2;
+ }
+
+ return 0;
+}
+
+static void report_abs(struct mma8451_data *data)
+{
+ short x, y, z;
+ int result;
+
+ do {
+ result =
+ i2c_smbus_read_byte_data(data->i2c_client, MMA8451_STATUS);
+ } while (!(result & 0x08)); /* wait for new data */
+
+ if (mma8451_read_data(data->i2c_client, &x, &y, &z) != 0)
+ return;
+
+ input_report_abs(data->idev->input, ABS_X, x);
+ input_report_abs(data->idev->input, ABS_Y, y);
+ input_report_abs(data->idev->input, ABS_Z, z);
+ input_sync(data->idev->input);
+}
+
+static void mma8451_dev_poll(struct input_polled_dev *dev)
+{
+ struct mma8451_data *data = (struct mma8451_data *)dev->private;
+
+ report_abs(data);
+}
+
+static int __devinit mma8451_probe(struct i2c_client *client,
+ const struct i2c_device_id *id)
+{
+ int result, ret;
+ struct i2c_adapter *adapter = to_i2c_adapter(client->dev.parent);
+ struct mma8451_data *data;
+ struct input_dev *idev;
+
+ data =
+ devm_kzalloc(&client->dev, sizeof(struct mma8451_data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ data->reg_vdd = devm_regulator_get(&client->dev, "vdd");
+ if (!IS_ERR(data->reg_vdd)) {
+ ret = regulator_enable(data->reg_vdd);
+ if (ret) {
+ dev_err(&client->dev,
+ "Failed to enable phy regulator: %d\n", ret);
+ result = -EINVAL;
+ goto err_detach_client;
+ }
+ }
+
+ data->reg_vddio = devm_regulator_get(&client->dev, "vddio");
+ if (!IS_ERR(data->reg_vddio)) {
+ ret = regulator_enable(data->reg_vddio);
+ if (ret) {
+ dev_err(&client->dev,
+ "Failed to enable phy regulator: %d\n", ret);
+ result = -EINVAL;
+ goto err_detach_client;
+ }
+ }
+
+ i2c_set_clientdata(client, data);
+ data->i2c_client = client;
+ result = i2c_check_functionality(adapter,
+ I2C_FUNC_SMBUS_BYTE |
+ I2C_FUNC_SMBUS_BYTE_DATA);
+
+ pr_info("check mma8451 chip ID\n");
+ result = i2c_smbus_read_byte_data(client, MMA8451_WHO_AM_I);
+
+ if (MMA8451_ID != result) {
+ dev_err(&client->dev,
+ "read chip ID 0x%x is not equal to 0x%x!\n", result,
+ MMA8451_ID);
+ pr_info("read chip ID failed\n");
+ result = -EINVAL;
+ goto err_detach_client;
+ }
+
+ /* Initialize the MMA8451 chip */
+ result = mma8451_init_client(client);
+
+ data->hwmon_dev = hwmon_device_register(&client->dev);
+ if (IS_ERR(data->hwmon_dev)) {
+ pr_err("hwmon register fail\n");
+ result = -EINVAL;
+ goto err_detach_client;
+ }
+
+ dev_info(&client->dev, "build time %s %s\n", __DATE__, __TIME__);
+
+ /*input poll device register */
+ data->idev = input_allocate_polled_device();
+ if (IS_ERR(data->idev)) {
+ dev_err(&client->dev, "alloc poll device failed!\n");
+ result = -ENOMEM;
+ goto err_detach_client;
+ }
+ data->idev->poll = mma8451_dev_poll;
+ data->idev->poll_interval = POLL_INTERVAL;
+ data->idev->private = data;
+ idev = data->idev->input;
+ idev->name = MMA8451_DRV_NAME;
+ idev->id.bustype = BUS_I2C;
+ idev->dev.parent = &client->dev;
+ idev->evbit[0] = BIT_MASK(EV_ABS);
+
+ input_set_abs_params(idev, ABS_X, -8192, 8191, INPUT_FUZZ, INPUT_FLAT);
+ input_set_abs_params(idev, ABS_Y, -8192, 8191, INPUT_FUZZ, INPUT_FLAT);
+ input_set_abs_params(idev, ABS_Z, -8192, 8191, INPUT_FUZZ, INPUT_FLAT);
+ result = input_register_polled_device(data->idev);
+ if (result) {
+ dev_err(&client->dev, "register poll device failed!\n");
+ goto err_detach_client;
+ }
+ return result;
+
+err_detach_client:
+ if (!IS_ERR(data->hwmon_dev)) {
+ hwmon_device_unregister(data->hwmon_dev);
+ data->hwmon_dev = NULL;
+ }
+ if (!IS_ERR(data->idev)) {
+ input_unregister_polled_device(data->idev);
+ input_free_polled_device(data->idev);
+ data->idev = NULL;
+ }
+ if (!IS_ERR(data->reg_vdd))
+ regulator_disable(data->reg_vdd);
+ if (!IS_ERR(data->reg_vddio))
+ regulator_disable(data->reg_vddio);
+
+ return result;
+}
+
+static int __devexit mma8451_remove(struct i2c_client *client)
+{
+ int result;
+ struct mma8451_data *data = (struct mma8451_data *)
+ i2c_get_clientdata(client);
+
+ mma_status.ctl_reg1 =
+ i2c_smbus_read_byte_data(client, MMA8451_CTRL_REG1);
+ result =
+ i2c_smbus_write_byte_data(client, MMA8451_CTRL_REG1,
+ mma_status.ctl_reg1 & 0xFE);
+
+ hwmon_device_unregister(data->hwmon_dev);
+ if (!IS_ERR(data->idev)) {
+ input_unregister_polled_device(data->idev);
+ input_free_polled_device(data->idev);
+ data->idev = NULL;
+ }
+
+ if (!IS_ERR(data->reg_vdd))
+ regulator_disable(data->reg_vdd);
+ if (!IS_ERR(data->reg_vddio))
+ regulator_disable(data->reg_vddio);
+
+ return result;
+}
+
+static int mma8451_suspend(struct i2c_client *client, pm_message_t mesg)
+{
+ int result;
+ mma_status.ctl_reg1 =
+ i2c_smbus_read_byte_data(client, MMA8451_CTRL_REG1);
+ result =
+ i2c_smbus_write_byte_data(client, MMA8451_CTRL_REG1,
+ mma_status.ctl_reg1 & 0xFE);
+ return result;
+}
+
+static int mma8451_resume(struct i2c_client *client)
+{
+ int result;
+ result =
+ i2c_smbus_write_byte_data(client, MMA8451_CTRL_REG1,
+ mma_status.ctl_reg1);
+ return result;
+}
+
+static const struct i2c_device_id mma8451_id[] = {
+ {MMA8451_DRV_NAME, 0},
+ {},
+};
+
+static const struct of_device_id mma_match[] = {
+ {.compatible = "fsl,mma8451",},
+ { /* sentinel */ }
+};
+
+MODULE_DEVICE_TABLE(i2c, mma8451_id);
+
+static struct i2c_driver mma8451_driver = {
+ .driver = {
+ .name = MMA8451_DRV_NAME,
+ .owner = THIS_MODULE,
+ .of_match_table = mma_match,
+ },
+ .suspend = mma8451_suspend,
+ .resume = mma8451_resume,
+ .probe = mma8451_probe,
+ .remove = __devexit_p(mma8451_remove),
+ .id_table = mma8451_id,
+};
+
+static int __init mma8451_init(void)
+{
+ /* register driver */
+ int res;
+
+ res = i2c_add_driver(&mma8451_driver);
+ if (res < 0) {
+ pr_info("add mma8451 i2c driver failed\n");
+ return -ENODEV;
+ }
+ pr_info("add mma8451 i2c driver\n");
+
+ return res;
+}
+
+static void __exit mma8451_exit(void)
+{
+ pr_info("remove mma8451 i2c driver.\n");
+ i2c_del_driver(&mma8451_driver);
+}
+
+MODULE_AUTHOR("Freescale Semiconductor, Inc.");
+MODULE_DESCRIPTION("MMA8451 3-Axis Orientation/Motion Detection Sensor driver");
+MODULE_LICENSE("GPL");
+
+module_init(mma8451_init);
+module_exit(mma8451_exit);
--
1.7.1
^ permalink raw reply related
* [PATCH 1/2] ARM: dts: imx6q-sabresd: add i2c1 device and mma8451
From: Frank Li @ 2012-11-13 8:53 UTC (permalink / raw)
To: linux-arm-kernel
add i2c1 device and mma8451 for sabresd board
Signed-off-by: Frank Li <Frank.Li@freescale.com>
---
arch/arm/boot/dts/imx6q-sabresd.dts | 24 ++++++++++++++++++++++++
arch/arm/boot/dts/imx6q.dtsi | 5 +++++
2 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/imx6q-sabresd.dts b/arch/arm/boot/dts/imx6q-sabresd.dts
index e596c28..aefdee4 100644
--- a/arch/arm/boot/dts/imx6q-sabresd.dts
+++ b/arch/arm/boot/dts/imx6q-sabresd.dts
@@ -42,6 +42,7 @@
1410 0x80000000 /* MX6Q_PAD_NANDF_D1__GPIO_2_1 */
1418 0x80000000 /* MX6Q_PAD_NANDF_D2__GPIO_2_2 */
1426 0x80000000 /* MX6Q_PAD_NANDF_D3__GPIO_2_3 */
+ 160 0x80000000 /* MX6Q_PAD_EIM_EB3__GPIO_2_31 */
>;
};
};
@@ -71,6 +72,29 @@
wp-gpios = <&gpio2 1 0>;
status = "okay";
};
+
+ i2c at 021a0000 { /* I2C1 */
+ status = "okay";
+ clock-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c1_2>;
+
+ mma8451 at 1c {
+ compatible = "fsl,mma8451";
+ reg = <0x1c>;
+ vdd-supply = <&sensor>;
+ vddio-supply = <&sensor>;
+ };
+ };
};
};
+ sensor: fixedregulator at 0 {
+ compatible = "regulator-fixed";
+ regulator-name = "sensor-supply";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ gpio = <&gpio2 31 1>;
+ startup-delay-us = <70000>;
+ enable-active-high;
+ };
};
diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index f3990b0..b637c70 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -637,6 +637,11 @@
196 0x4001b8b1 /* MX6Q_PAD_EIM_D28__I2C1_SDA */
>;
};
+ pinctrl_i2c1_2: i2c1grp-2 {
+ fsl,pins = <
+ 1125 0x4001b8b1 /* MX6Q_PAD_CSI0_DAT8__I2C1_SDA */
+ 1133 0x4001b8b1 /* MX6Q_PAD_CSI0_DAT9__I2C1_SCL */ >;
+ };
};
uart1 {
--
1.7.1
^ permalink raw reply related
* [PATCH v4] Add device tree file for the armadeus apf27
From: Sascha Hauer @ 2012-11-13 8:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352752113-21978-1-git-send-email-tremyfr@yahoo.fr>
On Mon, Nov 12, 2012 at 09:28:33PM +0100, Philippe Reynes wrote:
> Signed-off-by: Philippe Reynes <tremyfr@yahoo.fr>
> Signed-off-by: Eric Jarrige <eric.jarrige@armadeus.org>
> ---
>
> v4: update model to use the same format as apf28
> remove some empty line
> v3: set 26M clock to 0 (not used)
> v2: avoid enable again the watchdog
>
> arch/arm/boot/dts/imx27-apf27.dts | 89 +++++++++++++++++++++++++++++++++++++
> 1 files changed, 89 insertions(+), 0 deletions(-)
> create mode 100644 arch/arm/boot/dts/imx27-apf27.dts
Applied, thanks
Sascha
>
> diff --git a/arch/arm/boot/dts/imx27-apf27.dts b/arch/arm/boot/dts/imx27-apf27.dts
> new file mode 100644
> index 0000000..c0327c0
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx27-apf27.dts
> @@ -0,0 +1,89 @@
> +/*
> + * Copyright 2012 Philippe Reynes <tremyfr@yahoo.fr>
> + * Copyright 2012 Armadeus Systems <support@armadeus.com>
> + *
> + * Based on code which is: Copyright 2012 Sascha Hauer, Pengutronix
> + *
> + * The code contained herein is licensed under the GNU General Public
> + * License. You may obtain a copy of the GNU General Public License
> + * Version 2 or later at the following locations:
> + *
> + * http://www.opensource.org/licenses/gpl-license.html
> + * http://www.gnu.org/copyleft/gpl.html
> + */
> +
> +/dts-v1/;
> +/include/ "imx27.dtsi"
> +
> +/ {
> + model = "Armadeus Systems APF27 module";
> + compatible = "armadeus,imx27-apf27", "fsl,imx27";
> +
> + memory {
> + reg = <0xa0000000 0x04000000>;
> + };
> +
> + clocks {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + osc26m {
> + compatible = "fsl,imx-osc26m", "fixed-clock";
> + clock-frequency = <0>;
> + };
> + };
> +
> + soc {
> + aipi at 10000000 {
> + serial at 1000a000 {
> + status = "okay";
> + };
> +
> + ethernet at 1002b000 {
> + status = "okay";
> + };
> + };
> +
> + nand at d8000000 {
> + status = "okay";
> + nand-bus-width = <16>;
> + nand-ecc-mode = "hw";
> + nand-on-flash-bbt;
> +
> + partition at 0 {
> + label = "u-boot";
> + reg = <0x0 0x100000>;
> + };
> +
> + partition at 100000 {
> + label = "env";
> + reg = <0x100000 0x80000>;
> + };
> +
> + partition at 180000 {
> + label = "env2";
> + reg = <0x180000 0x80000>;
> + };
> +
> + partition at 200000 {
> + label = "firmware";
> + reg = <0x200000 0x80000>;
> + };
> +
> + partition at 280000 {
> + label = "dtb";
> + reg = <0x280000 0x80000>;
> + };
> +
> + partition at 300000 {
> + label = "kernel";
> + reg = <0x300000 0x500000>;
> + };
> +
> + partition at 800000 {
> + label = "rootfs";
> + reg = <0x800000 0xf800000>;
> + };
> + };
> + };
> +};
> --
> 1.7.4.4
>
>
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* linux-next: manual merge of the arm-soc tree with the pinctrl tree
From: Nicolas Ferre @ 2012-11-13 8:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121113151754.98aa6471baaf062826c3b133@canb.auug.org.au>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 11/13/2012 05:17 AM, Stephen Rothwell :
> Hi all,
>
> Today's linux-next merge of the arm-soc tree got a conflict in
> drivers/tty/serial/atmel_serial.c between commit 784557decc48
> ("tty: atmel_serial: add pinctrl support") from the pinctrl tree
> and commit bcd2360c1ff9 ("arm: at91: move platfarm_data to
> include/linux/platform_data/atmel.h") from the arm-soc tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no
> action is required).
Stephen, it is the proper merge.
Thanks a lot.
Best regards,
- --
Nicolas Ferre
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
iQEcBAEBAgAGBQJQogoUAAoJEAf03oE53VmQAt0H/iThKsKe+ag10z9Q8xlO6sqR
dvfFtRQxv7W1xVeRc/RJjnE/thKaa+FMiUfvFoj4Gls6UZD3vAvwatI+kkGY30yp
FbflguygU8OvAQcr/dpVx2tBzsqCk7Xynk+D0+DjlJXukP+JzP+3/tl7Gd0/lct7
nLccb1X0sNwTrvlLJO2WJuOGwFlTU3vO1wkehgic2ozfm3FzsaTLUjkUf6YXOG1N
BoABfHJL0PyNk6iENu26j6ulDPaWrpJe5531hTcJm16X+h2gnmnnjpYw9dTTQ5qO
La0UeqkqTxEUOFmo3cxbS0ryBeQBTmHss61JLVcqnlwApTscefmD4x8G310D7oA=
=mEy6
-----END PGP SIGNATURE-----
^ permalink raw reply
* [PATCH v5 1/3] ARM: at91: atmel-ssc: add pinctrl support
From: Mark Brown @ 2012-11-13 8:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352706028-750-2-git-send-email-voice.shen@atmel.com>
On Mon, Nov 12, 2012 at 03:40:25PM +0800, Bo Shen wrote:
> + ssc0 {
> + pinctrl_ssc0_tx: ssc0_tx-0 {
> + atmel,pins =
> + <1 16 0x1 0x1 /* PB16 periph A with pull up */
> + 1 17 0x1 0x1 /* PB17 periph A with pull up */
> + 1 18 0x1 0x1>; /* PB18 periph A with pull up */
> + };
Do we really want the pull ups here? Normally CMOS devices don't have
pulls, or the pulls are disabled during normal operation, as otherwise
when the logic level is different to whatever the pull is doing power is
wasted driving against the resistor.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121113/a2a1b7e3/attachment.sig>
^ permalink raw reply
* [PATCH 0/7] ARM: remove init_consistent_dma_size() stub
From: Arnd Bergmann @ 2012-11-13 8:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <01a301cdc15b$29e23e10$7da6ba30$%kim@samsung.com>
On Tuesday 13 November 2012, Kukjin Kim wrote:
> Arnd Bergmann wrote:
> >
> > Applied patches 2-7 to next/cleanup branch, with the Acks that came in.
> >
> (- many guys in Cc)
>
> Hi Arnd,
>
> If possible, please adding my ack on Samsung stuff.
>
> Acked-by: Kukjin Kim <kgene.kim@samsung.com>
>
Thanks for your Ack, but I'd prefer not to redo the branch now, since I already
merged other patches on top.
Arnd
^ permalink raw reply
* linux-next: manual merge of the arm-soc tree with the usb tree
From: Nicolas Ferre @ 2012-11-13 8:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121113152029.9bcfc18a4bca8dc53a033a86@canb.auug.org.au>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 11/13/2012 05:20 AM, Stephen Rothwell :
> Hi all,
>
> Today's linux-next merge of the arm-soc tree got a conflict in
> arch/arm/configs/stamp9g20_defconfig between commit 77614e025061
> ("arch: Change defconfigs to point to g_mass_storage") from the usb
> tree and commit 2484575268e2 ("arm: at91: drop machine defconfig")
> from the arm-soc tree.
>
> The latter deleted the file so I did that and can carry the fix as
> necessary (no action is required).
Yes. Thanks a lot Stephen.
Best regards,
- --
Nicolas Ferre
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
iQEcBAEBAgAGBQJQogldAAoJEAf03oE53VmQqTgIAKUtqhwnXt8Rm1x+ERPiPLno
VhFc1ZPgiPUepSecHMFPCcWtgwLBg6HUFXg4muM7kpf1hvMtAB6CmpasjceV8g0N
KMFC4GrRi6y0dp59DpBUa1gB87i4gpliqmroO3YGu8iGDHGowDBV8HsfmNpLmGTJ
WmdjDzpWE3hfLjNl5F0qnkI1cqDAyWrQwE9cNIFpzY93GfKkVTjdxiKIf6PprJl8
SIicUbeHV/lrNyusEZw0CcNa89qtKCovdBN7Yk64xwyyTnLprxq/Sr30WaFx4npf
A6vdUeCsKL3glD67rD7MUYXZ5KS0pLOuxIVJvvlugbOCwrNDPrZd6NZhqFkgMh8=
=Fpq2
-----END PGP SIGNATURE-----
^ permalink raw reply
* [GIT PULL v3] Renesas ARM-based SoC boards for v3.8 #2
From: Arnd Bergmann @ 2012-11-13 8:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121113053651.GB18224@opensource.wolfsonmicro.com>
On Tuesday 13 November 2012, Mark Brown wrote:
> Show Details
> On Mon, Nov 12, 2012 at 09:11:03PM +0000, Arnd Bergmann wrote:
>
> > * Always let the person that owns the dependency know that the changes in
> > their tree are also included elsewhere and that things go bad if those
> > changes get rebased after all, or won't make it into the merge window
> > for some reason.
>
> Please never pull anything from me unless there's a signed tag for it,
> anything else I won't know about and may be rebased or vanish or
> something.
Ok, thanks for the reminder. Do you have a signed tag containing ab6f6d8521?
> > I have taken Mark on Cc to let him know about the dependency now, and I've
> > merged ab6f6d85210c4d0265cf48e9958c04e08595055a (which has only shmobile
> > specific ASoC patches) into the next/boards2 branch before merging your
> > branch. This is still not perfect because it breaks bisection, but it's
> > the best I could do aside from forcing you do do another round-trip.
>
> What's the bisection problem?
I merged ab6f6d8521 first, and then Simon's branch, which means that the
linear (first-parent) history is ok, but bisecting the entire state of
the tree may end up in a commit in his branch in a state before it was
merged into mine, where it doesn't contain the patches it depends on,
and as Simon mentioned in his pull request, that will cause a build
failure.
Arnd
^ permalink raw reply
* linux-next: manual merge of the arm-soc tree with the usb tree
From: Nicolas Ferre @ 2012-11-13 8:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121113150631.e316da9049b2ce6685aa729e@canb.auug.org.au>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 11/13/2012 05:06 AM, Stephen Rothwell :
> Hi all,
>
> Today's linux-next merge of the arm-soc tree got a conflict in
> arch/arm/configs/afeb9260_defconfig between commit 77614e025061 ("arch:
> Change defconfigs to point to g_mass_storage") from the usb tree and
> commit 2484575268e2 ("arm: at91: drop machine defconfig") from the
> arm-soc tree.
>
> The latter deletes the file, so I did that and can carry the fix as
> necessary (no action is required).
Absolutely, thanks Stephen.
- --
Nicolas Ferre
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
iQEcBAEBAgAGBQJQogkxAAoJEAf03oE53VmQtxgH/1YpP1OvRv2A8kMAK5zanKHO
J/AanooWZIFrnceRCC5SddeCV667wPoiLiucOuAFQpz5CC0XgSUNRWLEfOQ+x859
y0FXw/Nrbl1OvvFScH4Nm9JeXtoMRpX6t2opTZTjZXy+QeGL6GlNUZx1MvBFOWE7
EbIlWNuf/zNmmxAg5+Wd9du0KIm0xYo5zLYG1isHYA3pEpWVq5bf99V+ym6xg9sL
xFQRxqxyYSJMEhbszIrMszp38ZzE3oDCqWQAFABzQpiTab8+7ykJlP7Rq5RXTfL+
mvd1AtyJjMTbp5Szpa06EDOpNTPaiAuzHEAfwTCHGzxxeo2M4hiOy7nXej1qhCo=
=RVPo
-----END PGP SIGNATURE-----
^ permalink raw reply
* [PATCH v5 2/3] ASoC: atmel-ssc-dai: register dai and pcm directly
From: Mark Brown @ 2012-11-13 8:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352706028-750-3-git-send-email-voice.shen@atmel.com>
On Mon, Nov 12, 2012 at 03:40:26PM +0800, Bo Shen wrote:
> static struct platform_device sam9g20ek_audio_device = {
> .name = "at91sam9g20ek-audio",
> - .id = -1,
> + .id = 0,
> };
Why are you changing this? Single devices are supposed to specify -1 as
their id.
> static int atmel_ssc_startup(struct snd_pcm_substream *substream,
> struct snd_soc_dai *dai)
> {
> - struct atmel_ssc_info *ssc_p = &ssc_info[dai->id];
> + struct atmel_ssc_info *ssc_p = &ssc_info;
This seems like a very big step backwards, there's now a single global
variable for the ssc_info which presumably means there can be only one
SSC active in the system at once. That's changing a lot more than just
the registration...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121113/c38c8800/attachment.sig>
^ permalink raw reply
* [PATCH 1/1] regulator: gpio-regulator: fix crash when no states property in dt
From: Mark Brown @ 2012-11-13 8:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHrpEqTF80XyRD8ZTDGLs+AywznGNdvZfndfWSuw+pJ-D24Rxw@mail.gmail.com>
On Tue, Nov 13, 2012 at 04:12:14PM +0800, Frank Li wrote:
> Yes, I tested it.
> I use gpio-enable to turn on\off a sensor power switcher.
> the below is a part of my dt file.
You should really use a fixed voltage regulator here, or fix the code so
you can specify a voltage for the gpio regulator when no GPIO is
specified (ideally the two drivers would be unified but that's another
story and mostly orthogonal to the DT).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121113/5c5a887c/attachment.sig>
^ permalink raw reply
* [PATCH 1/1] regulator: gpio-regulator: fix crash when no states property in dt
From: Frank Li @ 2012-11-13 8:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121113075733.GN18224@opensource.wolfsonmicro.com>
2012/11/13 Mark Brown <broonie@opensource.wolfsonmicro.com>:
> On Mon, Nov 12, 2012 at 09:56:47AM +0800, Frank Li wrote:
>> 2012/11/10 Mark Brown <broonie@opensource.wolfsonmicro.com>:
>> > On Fri, Nov 09, 2012 at 04:34:36PM +0800, Frank Li wrote:
>
>> >> /* Fetch states. */
>> >> prop = of_find_property(np, "states", NULL);
>> >> - proplen = prop->length / sizeof(int);
>> >> + proplen = prop ? prop->length / sizeof(int) : 0;
>
>> > Aren't states mandatory for this driver, in which case shouldn't the
>> > probe fail here?
>
>> I think No. GPIO-Regulator can be used as just turn on/off power
>> domain and not adjust voltage or current. So "states" is option.
>> "gpios" was already options.
>
> Are you sure this actually works? I glanced at the code and wasn't
> convinced it was taking sufficient care to cope with this possibility.
> Normally people use a fixed regulator for a regulator with a simple
> on/off switch (which allows the voltage to be specified which this
> won't...) so I'd be somewhat surprised if it were tested.
Yes, I tested it.
I use gpio-enable to turn on\off a sensor power switcher.
the below is a part of my dt file.
+ mma8451 at 1c {
+ compatible = "fsl,mma8451";
+ reg = <0x1c>;
+ vdd-supply = <&sensor>;
+ vddio-supply = <&sensor>;
+ };
+ };
};
};
+ sensor: gpio-regulator {
+ compatible = "regulator-gpio";
+ regulator-name = "sensor-supply";
+ enable-gpio = <&gpio2 31 1>;
+ enable-active-high;
+ regulator-type = "voltage";
+ };
best regards
Frank Li
^ permalink raw reply
* [PATCH 1/7] I2c-nomadik: Fix the usage of wait_for_completion_timeout
From: Liu, Chuansheng @ 2012-11-13 8:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121113075813.GA23119@pengutronix.de>
> -----Original Message-----
> From: Wolfram Sang [mailto:w.sang at pengutronix.de]
> Sent: Tuesday, November 13, 2012 3:58 PM
> To: Liu, Chuansheng
> Cc: linus.walleij at linaro.org; linux-arm-kernel at lists.infradead.org;
> linux-kernel at vger.kernel.org; linux-i2c at vger.kernel.org
> Subject: Re: [PATCH 1/7] I2c-nomadik: Fix the usage of
> wait_for_completion_timeout
>
>
> > Thanks your pointing out. I just manually reviewed the code when found
> > this point. Would like to try some auto-script but failed:)
>
> I can suggest 'coccinelle' for that kind of job.
Thanks, let me try, if possible anyone can give some help?
>
> --
> Pengutronix e.K. | Wolfram Sang
> |
> Industrial Linux Solutions | http://www.pengutronix.de/
> |
^ permalink raw reply
* [PATCH 1/7] I2c-nomadik: Fix the usage of wait_for_completion_timeout
From: Wolfram Sang @ 2012-11-13 7:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <27240C0AC20F114CBF8149A2696CBE4A1C3952@SHSMSX101.ccr.corp.intel.com>
> Thanks your pointing out. I just manually reviewed the code when found
> this point. Would like to try some auto-script but failed:)
I can suggest 'coccinelle' for that kind of job.
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121113/65f95058/attachment.sig>
^ permalink raw reply
* [PATCH 1/1] regulator: gpio-regulator: fix crash when no states property in dt
From: Mark Brown @ 2012-11-13 7:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHrpEqSbydeAHngL-NMfQa1HQUsj0US5u=aK6y-ku0DMOW-KkA@mail.gmail.com>
On Mon, Nov 12, 2012 at 09:56:47AM +0800, Frank Li wrote:
> 2012/11/10 Mark Brown <broonie@opensource.wolfsonmicro.com>:
> > On Fri, Nov 09, 2012 at 04:34:36PM +0800, Frank Li wrote:
> >> /* Fetch states. */
> >> prop = of_find_property(np, "states", NULL);
> >> - proplen = prop->length / sizeof(int);
> >> + proplen = prop ? prop->length / sizeof(int) : 0;
> > Aren't states mandatory for this driver, in which case shouldn't the
> > probe fail here?
> I think No. GPIO-Regulator can be used as just turn on/off power
> domain and not adjust voltage or current. So "states" is option.
> "gpios" was already options.
Are you sure this actually works? I glanced at the code and wasn't
convinced it was taking sufficient care to cope with this possibility.
Normally people use a fixed regulator for a regulator with a simple
on/off switch (which allows the voltage to be specified which this
won't...) so I'd be somewhat surprised if it were tested.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121113/d211d11f/attachment.sig>
^ permalink raw reply
* [PATCH v2 12/17] ARM: clps711x: autcpu12: Special driver for handling NAND memory is removed
From: Alexander Shiyan @ 2012-11-13 7:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201211121617.41304.arnd@arndb.de>
On Mon, 12 Nov 2012 16:17:41 +0000
Arnd Bergmann <arnd@arndb.de> wrote:
> On Saturday 10 November 2012, Alexander Shiyan wrote:
> > This patch provide migration to using "gpio-nand" and "basic-mmio-gpio"
> > drivers instead of using special driver for handling NAND memory.
> >
> > Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
>
> Applying this patch fails to build because it requires "GENERIC_GPIO" to be
> enabled in Kconfig, which is not enabled here.
All necessary symbols for build is present in patch:
[PATCH v2 16/17] ARM: clps711x: Update defconfig due latest changes and
new kernel symbols
--
Alexander Shiyan <shc_work@mail.ru>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox