LED module has dependency on some gpio macros therefore they are moved to a
header file.
This patch is functionally tested on Samsung SMDKV6410.
Signed-off-by: David Dajun Chen <dchen(a)diasemi.com>
Signed-off-by: Ashish Jangam <ashish.jangam(a)kpitcummins.com>
---
drivers/gpio/gpio-da9052.c | 26 ++-------------------
include/linux/mfd/da9052/gpio.h | 46 +++++++++++++++++++++++++++++++++++++++
2 files changed, 49 insertions(+), 23 deletions(-)
create mode 100644 include/linux/mfd/da9052/gpio.h
diff --git a/drivers/gpio/gpio-da9052.c b/drivers/gpio/gpio-da9052.c
index 038f5eb..662f92e 100644
--- a/drivers/gpio/gpio-da9052.c
+++ b/drivers/gpio/gpio-da9052.c
@@ -24,26 +24,6 @@
#include <linux/mfd/da9052/pdata.h>
#include <linux/mfd/da9052/gpio.h>
-#define DA9052_INPUT 1
-#define DA9052_OUTPUT_OPENDRAIN 2
-#define DA9052_OUTPUT_PUSHPULL 3
-
-#define DA9052_SUPPLY_VDD_IO1 0
-
-#define DA9052_DEBOUNCING_OFF 0
-#define DA9052_DEBOUNCING_ON 1
-
-#define DA9052_OUTPUT_LOWLEVEL 0
-
-#define DA9052_ACTIVE_LOW 0
-#define DA9052_ACTIVE_HIGH 1
-
-#define DA9052_GPIO_MAX_PORTS_PER_REGISTER 8
-#define DA9052_GPIO_SHIFT_COUNT(no) (no%8)
-#define DA9052_GPIO_MASK_UPPER_NIBBLE 0xF0
-#define DA9052_GPIO_MASK_LOWER_NIBBLE 0x0F
-#define DA9052_GPIO_NIBBLE_SHIFT 4
-
struct da9052_gpio {
struct da9052 *da9052;
struct gpio_chip gp;
@@ -201,9 +181,9 @@ static struct gpio_chip reference_gp __devinitdata = {
.direction_input = da9052_gpio_direction_input,
.direction_output = da9052_gpio_direction_output,
.to_irq = da9052_gpio_to_irq,
- .can_sleep = 1;
- .ngpio = 16;
- .base = -1;
+ .can_sleep = 1,
+ .ngpio = 16,
+ .base = -1,
};
static int __devinit da9052_gpio_probe(struct platform_device *pdev)
diff --git a/include/linux/mfd/da9052/gpio.h b/include/linux/mfd/da9052/gpio.h
new file mode 100644
index 0000000..8c8eda0
--- /dev/null
+++ b/include/linux/mfd/da9052/gpio.h
@@ -0,0 +1,46 @@
+/*
+ * GPIO module declarations for DA9052 PMICs.
+ *
+ * Copyright(c) 2011 Dialog Semiconductor Ltd.
+ *
+ * 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.
+ *
+ */
+
+#ifndef __LINUX_MFD_DA9052_GPIO_H
+#define __LINUX_MFD_DA9052_GPIO_H
+
+#define DA9052_INPUT 1
+#define DA9052_OUTPUT_OPENDRAIN 2
+#define DA9052_OUTPUT_PUSHPULL 3
+
+#define DA9052_SUPPLY_VDD_IO1 0
+
+#define DA9052_DEBOUNCING_OFF 0
+#define DA9052_DEBOUNCING_ON 1
+
+#define DA9052_OUTPUT_LOWLEVEL 0
+
+#define DA9052_ACTIVE_LOW 0
+#define DA9052_ACTIVE_HIGH 1
+
+#define DA9052_GPIO_MAX_PORTS_PER_REGISTER 8
+#define DA9052_GPIO_SHIFT_COUNT(no) (no%8)
+#define DA9052_GPIO_MASK_UPPER_NIBBLE 0xF0
+#define DA9052_GPIO_MASK_LOWER_NIBBLE 0x0F
+#define DA9052_GPIO_NIBBLE_SHIFT 4
+#define DA9052_IRQ_GPI0 16
+
+#endif /* __LINUX_MFD_DA9052_GPIO_H */
--
1.7.1
The following patch series adds initial support for the Dialog Semiconductor
DA9052/53 PMICs.
The DA9052/53 PMICs support many functionalities like GPIOs, regulators,
power-supply, touchscreen, rtc, backlight, etc. So these patches are applicable
to different sub-systems of the kernel separately.
This patch series adds support for MFD, Regulator, Battery and GPIO. Support
for rest of the devices will be added later.
All the other patches depend on the MFD module of the patch series. There is no
other interdependance of patches.
Ashish Jangam (6):
[MFD]: Core module of DA9052/53 PMICs with I2C and regmap support.
[MFD]: Incremental with ADC support. Battery patch also depends on this.
[MFD]: Incremental with SPI support.
GPIO: Incremental patch for DA9052/53 PMICs gpio driver.
[REGULATOR]: Support for DA9052/53 PMICs regulators.
[POWER]: Support for DA9052/53 battery.
drivers/gpio/gpio-da9052.c | 26 +-
drivers/mfd/Kconfig | 28 ++
drivers/mfd/Makefile | 5 +
drivers/mfd/da9052-core.c | 553 ++++++++++++++++++++++++
drivers/mfd/da9052-i2c.c | 144 +++++++
drivers/mfd/da9052-spi.c | 121 ++++++
drivers/power/Kconfig | 7 +
drivers/power/Makefile | 1 +
drivers/power/da9052-battery.c | 615 +++++++++++++++++++++++++++
drivers/regulator/Kconfig | 7 +
drivers/regulator/Makefile | 1 +
drivers/regulator/da9052-regulator.c | 600 ++++++++++++++++++++++++++
include/linux/mfd/da9052/da9052.h | 173 ++++++++
include/linux/mfd/da9052/gpio.h | 46 ++
include/linux/mfd/da9052/pdata.h | 40 ++
include/linux/mfd/da9052/reg.h | 778 ++++++++++++++++++++++++++++++++++
16 files changed, 3122 insertions(+), 23 deletions(-)
create mode 100644 drivers/mfd/da9052-core.c
create mode 100644 drivers/mfd/da9052-i2c.c
create mode 100644 drivers/mfd/da9052-spi.c
create mode 100644 drivers/power/da9052-battery.c
create mode 100644 drivers/regulator/da9052-regulator.c
create mode 100644 include/linux/mfd/da9052/da9052.h
create mode 100644 include/linux/mfd/da9052/gpio.h
create mode 100644 include/linux/mfd/da9052/pdata.h
create mode 100644 include/linux/mfd/da9052/reg.h
Hi, sorry for the topic, I wanted to catch your attention.
This is a quick brain dump based on my own observations/battle with
master images last week.
1) Unless we use external USB/ETH adapters then cloning a master image
clones the mac address as well. This has serious consequences and I'm
100% sure that's why lava-test had to be switched to the random UUID
mode. This problem applies to the master image mode. In the test image
the software can do anything so we may run with a random MAC or with
the mac that master images' boot loader set (we should check that).
Since making master images is a mess, unless is becomes automated I
will not be convinced that people just know how to make them properly
and are not simply copying from someone. There is no reproducible
master image creation process that ensure two people with the same
board can run a single test in a reproducible way! (different starting
rootfs/bootloader/package selection/random mistakes)
2) Running code via serial on the master image is a mess. It is very
fragile. We need an agent on the board instead of a random master
image+serial shell. The agent will expose board identity, capabilities
and standard APIs to LAVA (notably the dispatcher).
The same API, if done sensibly, will work for software emulators and
hardware boards. Agent API for a software emulator can do different
things. Dispatcher should be based on agent API instead of ramming the
serial line.
3) The master image, as we know it today, should be booting remotely.
The boot loader can stay on the board until we can push it over USB.
The only thing that absolutely has to stay in the card is the lava
board identity file which would be generated from the web UI. There is
no reason to keep rootfs/kernel/initrd there. This means that a single
small card can fit all tests as well. It also means we can reset the
master image (as currently it is writeable by the board and can be
corrupted) before booting to ensure consistent behaviour. I did some
work on that and I managed to boot panda over NFS. Ideally I want to
boot over nbd (netblock device) which is much faster and with proper
"master image" init script we can expose a single read only net block
device to _all_ the boards.
4) With agent on each board, identity file on the SD card LAVA will
know if cloning happened. We could do dynamic board detection (unplug
the board -> it goes away, plug it back -> it shows up). We could move
a board from system to system and have 0config transitions.
5) Dispatcher should drop all configuration files. Sure it made sense
12 months ago when the idea was to run it standalone. Now all of that
configuration should be in the database and should be provided by the
scheduler to the dispatcher as a big serialized argument (or a file
descriptor or a temporary file on disk). Setting up the dispatcher for
a new instance is a pain and unless you can copy stuff from the
validation server and ask everyone around for help it's very hard to
get right. If master images could be constructed programmatically and
with a agent on each "master image" lava would just get that
configuration for free.
6) We should drop conmux. As in the lab we already have TCP/IP sockets
for the serial lines we could just provide my example serial->tcp
script as lava-serial service that people with directly attached
boards would use. We could get a similar lava-power service if that
would make sense. The lava-serial service could be started as an
instance for all USB/SERIAL adapters plugged in if we really wanted
(hello upstart!). The lava-power service would be custom and would
require some config but it is very rare. Only lab and me have
something like that. Again it should be instance based IMHO so I can
say: 'start lava-power CONF=/etc/lava-power/magic-hack.conf' and see
LAVA know about a power service. One could then say that a particular
board uses a particular serial and power services.
That's it.
Best regards
ZK
Hi,
When PM_RUNTIME is enabled, PL330 probe fails because of some
mismatch in pm_runtime calls. This patchset fixes those issues.
This patch is based on Kukjin's for-next branch and tested on
EXYNOS4 based Origen board.
d3d936c "Merge branch 'samsung-fixes-2' into for-next"
Tushar Behera (2):
To Vinod Koul <vinod.koul(a)intel.com>:
DMA: PL330: Remove pm_runtime_xxx calls from pl330 probe/remove
To Kukjin Kim <kgene.kim(a)samsung.com>:
ARM: EXYNOS: Add apb_pclk clkdev entry for mdma1
arch/arm/mach-exynos/clock.c | 1 +
drivers/dma/pl330.c | 17 ++---------------
2 files changed, 3 insertions(+), 15 deletions(-)
--
1.7.4.1
Hi All,
one of the blueprints we have for 11.12 is to modify the LEB/ALIP
images so they include more linaro branding. A linaro wallpaper, maybe
a linaro image as the system is booting, that kind of thing.
Towards that end (and given that time is short if this is to make
11.12) I'd like to propose the following graphic be our new wallpaper
image. This would be the image displayed in the background on a
graphical desktop by default.
I created it in gimp.
http://people.linaro.org/~tgall/LinaroDesktop-1920x1080-1.png
Thoughts? Concerns? Feedback?
--
Regards,
Tom
"Where's the kaboom!? There was supposed to be an earth-shattering
kaboom!" Marvin Martian
Multimedia Tech Lead | Linaro.org │ Open source software for ARM SoCs
w) tom.gall att linaro.org
w) tom_gall att vnet.ibm.com
h) tom_gall att mac.com
On Thu 08 Dec 2011 14:59:02 GMT, Amber Graner wrote:
> The benefits of becoming a Community Contributor will include:
>
> * a Linaro e-mail address
> * the right to carry Linaro business cards (we supply the artwork,
> youprint your own cards)
> * a Linaro IRC cloak
> * listing in the relevant Working Group on our Linaro organisation
> structure
> * listing in the Launchpad Community Contributors Team
Giving a community member a Linaro email address presumably also gives
the access to Google Apps?
Google docs has been, up to now, a suitable place to share things that
must be kept hidden from the general public (for license reasons,
mostly). This also applies to other infrastructure like
people.linaro.org, and the 'Internal' pages of the wiki.
The particular data I'm concerned about is proprietary benchmark
sources, and figures (these are not exactly highly sensitive, but
never-the-less we try to stick to the terms of the license). I'm sure
there are others. I have no idea whether being an officially recognised
member of the team would satisfy the license, or not?
Now, I know that there are technical solutions to this problem, if it is
a problem (i.e. file permissions), but I think there probably needs to
be some official word on how we deal with this.
Andrew