linaro-dev March 2012

linaro-dev@lists.linaro.org

152 participants
126 discussions

by Tom Gall

Located in ppa:linaro-maintainers/tools can be found the newest version of live-build, a45 with the following linaro features applied: 1) armhf support (both native and cross) 2) linaro meta bld information as was discussed at 4Q11 Linaro Connect 3) cross support using multistrap Live build a45 supports Maverick, Natty, Oneiric and Precise. With you are you able to build your own images native on an armel or armhf host or cross using either an i386 or x86_64 host creating either armel or armhf targets. For image targets up to oneiric, one is not able to cross assemble the ubuntu-desktop image. However with precise all linaro images including the ubuntu-desktop image can be cross assembled. Enjoy! -- 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

12 years, 2 months

Re: Slow/broken USB and Ethernet on Snowballs/Origen boards?

by Jannis Pohlmann

Hey, On 03/15/2012 01:39 AM, Tony Mansson wrote: > Hi, > > This is interesting. I'd like to reproduce the Ethernet speed tests. > > Do you have the exact command lines? Sure. You'll need two machines, on being the board. Both need to be in the same 100 or 1000 MBit/s LAN. On the receiver's end, run: netcat -l 8000 > /dev/null This will listen for incoming data on a TCP socket on port 8000. Then, given the receiver's IP address, run the following command on the sender's end: dd if=/dev/zero bs=1024k count=256 > /dev/tcp/<RECEIVER IP>/8000 Note that "/dev/tcp/XYZ/8000" is a bash-specific feature. When this command has finished, it will tell you the transfer rate. You can cancel it anytime and it will give you the same information. But be sure not to cancel too early as that makes the measurement less reliable. Obviously, you can change count= to whatever you want. E.g. with the Origen, you'd probably want to only send 10-100 MByte. Also, you can swap receiver and sender to make sure that running netcat on the board is not causing things to slow down. Not the best benchmark in the world, but it's simple and you can run it as often if you want to make it more reliable. Hope that helps, Jannis > ---------- Forwarded message ---------- > From: Jannis Pohlmann <jannis.pohlmann(a)codethink.co.uk> > Date: 14 March 2012 21:04 > Subject: Slow/broken USB and Ethernet on Snowballs/Origen boards? > To: linaro-dev(a)lists.linaro.org > > > Hi, > > I am currently playing with a couple of the development boards for which > there are Linaro hwpacks and LEBs. Since what I am trying to do requires > a lot of disk and network I/O, I've been paying special attention to the > data transfer rates I can get out of these boards. > > Below is a brief summary of my findings. > > 1) i.MX 53 > > * disk I/O using an external SSD drive is very good; good enough to > not require further measurements > > * network I/O is approximately 9-10 MByte/s (perhaps more) which > seems ok given the 100 MBit/s Ethernet interface > > 2) Snowball (PDK, version 8) > > * it seems to be impossible to get the USB OTG host mode to work, > therefore I could not test disk I/O with a USB drive; it appears > the OTG port on the version 8 board does not even have enough power > for a powered USB to actually go online (I am unaware of the > details of how this works unfortunately) > > * performing network I/O with netcat casues netcat, ksoftirqd and > kworker to use ~33% of the CPU each, resulting in 100% CPU usage > only to handle the network data transfer > > * the resulting network transfer rate is about 5.5 MByte/s, which > is significantly less than what the 100 MBit/s Ethernet interface > should be able to produce > > 3) Origen > > * the internal USB hub runs at Full Speed (12 MBit/s), resulting in a > maximum USB disk I/O of 1.5 MByte/s > > * since the board does not feature Ethernet itself, I tried to attach > a USB Ethernet controller to it, but of course the transfer rate > through that is by the I/O upper limit of the USB hub > > * I did not test wireless but it is not feasible for what I am trying > to do anyway > > I guess not all of this is surprising. The i.MX performs quite well but > unfortunately the CPU is quite slow compared to the others. However, I > wonder whether the USB OTG host mode issue on the Snowball is a known > problem? Also, network I/O occupying all of the CPU seems to be a bug or > at least a dodgy driver. About the Origen: I assume there is nothing > that can be done to have High Speed USB on it? > > Thanks in advance! If anyone needs me to provide more information, I'll > gladly try to do that. > > Regards, > Jannis > > _______________________________________________ > linaro-dev mailing list > linaro-dev(a)lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev

12 years, 2 months

[PATCH] EXYNOS: Rename exynos5_tzpc structure to s5p_tzpc

by Chander Kashyap

TZPC IP is common across S5P and Exynos based SoC'c. Renaming exynos5_tzpc in arch/arm/include/asm/arch-exynos/tzpc.h to s5p_tzpc will allow generic usase of tzpc. Also modify board/samsung/smdk5250/tzpc_init.c to use s5p_tzpc. Signed-off-by: Chander Kashyap <chander.kashyap(a)linaro.org> --- arch/arm/include/asm/arch-exynos/tzpc.h | 2 +- board/samsung/smdk5250/tzpc_init.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/include/asm/arch-exynos/tzpc.h b/arch/arm/include/asm/arch-exynos/tzpc.h index 2c9a07b..63736ae 100644 --- a/arch/arm/include/asm/arch-exynos/tzpc.h +++ b/arch/arm/include/asm/arch-exynos/tzpc.h @@ -22,7 +22,7 @@ #define __TZPC_H_ #ifndef __ASSEMBLY__ -struct exynos5_tzpc { +struct s5p_tzpc { unsigned int r0size; char res1[0x7FC]; unsigned int decprot0stat; diff --git a/board/samsung/smdk5250/tzpc_init.c b/board/samsung/smdk5250/tzpc_init.c index c2ccef3..03e46bb 100644 --- a/board/samsung/smdk5250/tzpc_init.c +++ b/board/samsung/smdk5250/tzpc_init.c @@ -28,7 +28,7 @@ /* Setting TZPC[TrustZone Protection Controller] */ void tzpc_init(void) { - struct exynos5_tzpc *tzpc; + struct s5p_tzpc *tzpc; unsigned int addr; for (addr = TZPC0_BASE; addr <= TZPC9_BASE; addr += TZPC_BASE_OFFSET) { -- 1.7.5.4

12 years, 2 months

[PATCH v2 0/4] omap hsmmc device tree support

by Rajendra Nayak

The series adds device tree support for OMAP hsmmc driver. Changes in V2: -1- Minor fixes based on comments from Grant. -2- Added a seperate compatible for omap3. -3- Added a new binding "ti,needs-special-reset" to handle some mmc modules which need special softreset sequence. -4- Updated board dts files with "status = disable;" for unused mmc modules. Rob, I retained your ack on patch 1 despite the additional binding that I added to handle the special softreset sequence. Let me know if you have any issues with it. Chris. Patch 1 and Patch 2 apply cleanly on mmc-next and can be taken in from the mmc tree after relevent acks from DT folks. Patch 3 and Patch 4 which update dts files, I plan to push via linux-omap/Tony's tree. The series is tested on omap4sdp (both external and emmc), omap4panda amd omap3beagle boards. Things to do: -1- Card detect isn't functional and needs twl4030 gpio to be DT converted. -2- pbias cell programming is missing and needs an OMAP control module driver. Rajendra Nayak (4): mmc: omap_hsmmc: Convert hsmmc driver to use device tree mmc: omap_hsmmc: Avoid a regulator voltage change with dt arm/dts: OMAP4: Add mmc controller nodes and board data arm/dts: OMAP3: Add mmc controller nodes and board data .../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 33 +++++++ arch/arm/boot/dts/omap3-beagle.dts | 14 +++ arch/arm/boot/dts/omap3.dtsi | 16 ++++ arch/arm/boot/dts/omap4-panda.dts | 22 +++++ arch/arm/boot/dts/omap4-sdp.dts | 24 ++++++ arch/arm/boot/dts/omap4.dtsi | 31 +++++++ drivers/mmc/host/omap_hsmmc.c | 88 +++++++++++++++++++- 7 files changed, 227 insertions(+), 1 deletions(-) create mode 100644 Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt

12 years, 2 months

implementing "suspend to ram" on cortex A8 based on linux 3.0.8

by yang gqyang

dear all: I am working on arm cortex a8 now, trying to implement "suspend to ram" based on linux 3.0.8. Before i start my work, the soc already support standby(the cpu is on wfi state), so in order to implement "suspend to ram", i think i just need to implement the arch-specific related api. The "suspend to ram" works like this: "echo mem > /sys/power/state" -> enter_state -> suspend_devices_and_enter ->suspend_ops->enter(state) Is that right? Do you think the "suspend to ram" can be realized in this way? In order to power off the cortex A8, i save all the writable co-processor and all modes's state register set, and restore them when resuming. All the code seems work ok, because when I just does not power off the cortex-A8 and jump to excute the resume code, the system works well. But, when I power off the cpu, and wake up and excute resume code, the kernel seem ok, but the busybox toolkit does not work proper, eg: "ls" can not output the result through serial port. i add "printk statement" trying to locate the reason, but at this time, the "ls" work fine. hence, i doubt something must be corrupted after resume. I have checked all the state register and co-processor, having not found any exception, and I also compared all the dram data before power off and after wake up, nothing have changed. Right now, I do not know what has happened, and what should I do to locate the real problem to make the busybox works ok. I also want to know does the linux kernel 3.0.8 support "suspend to ram" like this: "echo mem > /sys/power/state" -> enter_state -> suspend_devices_and_enter ->suspend_ops->enter(state)? Can anyone give me some suggestion? Any comment is welcome, thanks a lot. > > -- > To unsubscribe from this list: send the line "unsubscribe linux-pm" in > the body of a message to majordomo(a)vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >

12 years, 2 months

[PATCH 0/4] thermal: exynos: Add kernel thermal support for exynos platform

by Amit Daniel Kachhap

Changes since RFC: *Moved the Temperature sensor driver from driver/hwmon/ to driver/mfd as discussed with Guenter Roeck <guenter.roeck(a)ericsson.com> and Donggeun Kim <dg77.kim(a)samsung.com> (https://lkml.org/lkml/2012/1/5/7) *Some changes according to the changes in common cpu cooling APIs All the patchset based on Kernel version 3.3-rc5 and uses the cpufreq cooling registration APIs implemented in earlier patchset https://lkml.org/lkml/2012/2/22/123 The code added in this patchset adds a thermal interface layer for samsung exynos platforms. This layer is registered from the temperature sensor driver and recieves/monitor the temperature from the sensor and informs the generic thermal layer to take the necessary cooling action. Currently, this layer can be used to create only one thermal zone and hence only one temperature sensor can register. The future goal is to make this handle multiple thermal zones. Some modifications are done in the temperature sensor driver to export the information needed for the thermal interface to register with the core linux thermal framework and with the cpu frequency based cooling devices. A simple data/control flow diagrams to illustrate this, Core Linux thermal <-------> Exynos thermal <-------- Temperature Sensor | | \|/ | Cpufreq cooling device <----- Amit Daniel Kachhap (4): thermal: exynos: Add thermal interface support for linux thermal layer hwmon: exynos4: Move thermal sensor driver to driver/mfd directory thermal: exynos4: Register the tmu sensor with the thermal interface layer ARM: exynos4: Add thermal sensor driver platform device support Documentation/hwmon/exynos4_tmu | 81 ----- Documentation/mfd/exynos4_tmu | 52 +++ arch/arm/mach-exynos/Kconfig | 11 + arch/arm/mach-exynos/Makefile | 1 + arch/arm/mach-exynos/clock.c | 4 + arch/arm/mach-exynos/dev-tmu.c | 64 ++++ arch/arm/mach-exynos/include/mach/irqs.h | 2 + arch/arm/mach-exynos/include/mach/map.h | 1 + arch/arm/mach-exynos/mach-origen.c | 1 + arch/arm/plat-samsung/include/plat/devs.h | 1 + drivers/hwmon/Kconfig | 10 - drivers/hwmon/Makefile | 1 - drivers/hwmon/exynos4_tmu.c | 514 ----------------------------- drivers/mfd/Kconfig | 10 + drivers/mfd/Makefile | 1 + drivers/mfd/exynos4_tmu.c | 443 +++++++++++++++++++++++++ drivers/thermal/Kconfig | 8 + drivers/thermal/Makefile | 1 + drivers/thermal/exynos_thermal.c | 272 +++++++++++++++ include/linux/exynos_thermal.h | 72 ++++ include/linux/platform_data/exynos4_tmu.h | 7 + 21 files changed, 951 insertions(+), 606 deletions(-) delete mode 100644 Documentation/hwmon/exynos4_tmu create mode 100644 Documentation/mfd/exynos4_tmu create mode 100644 arch/arm/mach-exynos/dev-tmu.c delete mode 100644 drivers/hwmon/exynos4_tmu.c create mode 100644 drivers/mfd/exynos4_tmu.c create mode 100644 drivers/thermal/exynos_thermal.c create mode 100644 include/linux/exynos_thermal.h

12 years, 2 months

boot failure with __iounmap changes in v3.3

by jonsmirl＠gmail.com

I'm working on getting out of tree support for the NXP LPC31xx ARM926EJS based CPUs ready for submission. Everything was working fine on v3.2 but I lost the ability to boot with v3.3. The boot failure is very early in the boot process. I did a bisect and came up with: [6ee723a6570a897208b76ab3e9a495e9106b2f8c] ARM: simplify __iounmap() when dealing with section based mapping I tried to revert it but there have been a bunch of edits in this file. Not sure how to go about debugging this. -- Jon Smirl jonsmirl(a)gmail.com

12 years, 2 months

[PATCH v7 0/9] Consolidate cpuidle functionality

by Robert Lee

This patch series moves various functionality duplicated in platform cpuidle drivers to the core cpuidle driver. Also, the platform irq disabling was removed as it appears that all calls into cpuidle_call_idle will have already called local_irq_disable(). Rafael, Could you review this patchset and merge patch 1/9 once its ready? It seems pretty close to being acceptable. The get_maintainer script shows Len Brown as the cpuidle maintainer but I've been unable to get a response from him so far. If you are not the right person, could you suggest who I can make this request to? Thanks. Note to platform maintainers: Platform patches (2/9 to 9/9) in this patchset are not required to work with patch 1/9 but please review and push these platform changes as possible to allow this consolidation to occur. Based on 3.3-rc5 plus recent exynos cpuidle patch (affects exynos cpuidle only): http://www.spinics.net/lists/linux-samsung-soc/msg09467.html v6 submission tested successfully on Exynos (thanks Amit Kacchap) and OMAP3 (thanks Jean Pihet) platforms. v6 submission can be found here: http://www.spinics.net/lists/arm-kernel/msg162018.html Changes since v6: * Made some struct whitespace alignment changes. * Fixed a coding style violation (thanks Jean Pihet) * Fixed a bug in davinci cpuidle (thanks Jean Pihet) * Corrected the common ARM cpuidle WFI state description to be ARM platform agnostic (thanks Kevin Hilman) * Fixed the problem causing x86 and PPC builds to fail (thanks Deepthi) * Re-added a line of code that was mistakenly removed (thanks Deepthi) Robert Lee (9): cpuidle: Add common time keeping and irq enabling ARM: at91: Consolidate time keeping and irq enable ARM: exynos: Consolidate time keeping and irq enable ARM: kirkwood: Consolidate time keeping and irq enable ARM: davinci: Consolidate time keeping and irq enable ARM: omap: Consolidate OMAP3 time keeping and irq enable ARM: omap: Consolidate OMAP4 time keeping and irq enable ARM: shmobile: Consolidate time keeping and irq enable SH: shmobile: Consolidate time keeping and irq enable arch/arm/include/asm/cpuidle.h | 22 +++++++++ arch/arm/kernel/Makefile | 2 +- arch/arm/kernel/cpuidle.c | 21 ++++++++ arch/arm/mach-at91/cpuidle.c | 67 ++++++++++----------------- arch/arm/mach-davinci/cpuidle.c | 82 +++++++++++++------------------- arch/arm/mach-exynos/cpuidle.c | 53 ++------------------- arch/arm/mach-kirkwood/cpuidle.c | 72 ++++++++-------------------- arch/arm/mach-omap2/cpuidle34xx.c | 42 +++++++---------- arch/arm/mach-omap2/cpuidle44xx.c | 21 +------- arch/arm/mach-shmobile/cpuidle.c | 31 +++---------- arch/sh/kernel/cpu/shmobile/cpuidle.c | 10 +--- drivers/cpuidle/cpuidle.c | 79 +++++++++++++++++++++++++------ include/linux/cpuidle.h | 13 +++++- 13 files changed, 233 insertions(+), 282 deletions(-) create mode 100644 arch/arm/include/asm/cpuidle.h create mode 100644 arch/arm/kernel/cpuidle.c

12 years, 2 months

[PATCH v12] Regulator: Add Anatop regulator driver

by Ying-Chun Liu (PaulLiu)

From: "Ying-Chun Liu (PaulLiu)" <paul.liu(a)linaro.org> Anatop is an integrated regulator inside i.MX6 SoC. There are 3 digital regulators which controls PU, CORE (ARM), and SOC. And 3 analog regulators which controls 1P1, 2P5, 3P0 (USB). This patch adds the Anatop regulator driver. Signed-off-by: Nancy Chen <Nancy.Chen(a)freescale.com> Signed-off-by: Ying-Chun Liu (PaulLiu) <paul.liu(a)linaro.org> Acked-by: Shawn Guo <shawn.guo(a)linaro.org> Reviewed-by: Axel Lin <axel.lin(a)gmail.com> Cc: Mark Brown <broonie(a)opensource.wolfsonmicro.com> Cc: Liam Girdwood <lrg(a)ti.com> Cc: Samuel Ortiz <sameo(a)linux.intel.com> Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj(a)jcrosoft.com> --- drivers/regulator/Kconfig | 8 + drivers/regulator/Makefile | 1 + drivers/regulator/anatop-regulator.c | 241 ++++++++++++++++++++++++++++++++++ 3 files changed, 250 insertions(+), 0 deletions(-) create mode 100644 drivers/regulator/anatop-regulator.c diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig index c733df5..a229de9 100644 --- a/drivers/regulator/Kconfig +++ b/drivers/regulator/Kconfig @@ -102,6 +102,14 @@ config REGULATOR_DA9052 This driver supports the voltage regulators of DA9052-BC and DA9053-AA/Bx PMIC. +config REGULATOR_ANATOP + tristate "Freescale i.MX on-chip ANATOP LDO regulators" + depends on MFD_ANATOP + help + Say y here to support Freescale i.MX on-chip ANATOP LDOs + regulators. It is recommended that this option be + enabled on i.MX6 platform. + config REGULATOR_MC13XXX_CORE tristate diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile index 2b09c81..b5042c8 100644 --- a/drivers/regulator/Makefile +++ b/drivers/regulator/Makefile @@ -15,6 +15,7 @@ obj-$(CONFIG_REGULATOR_AAT2870) += aat2870-regulator.o obj-$(CONFIG_REGULATOR_AB3100) += ab3100.o obj-$(CONFIG_REGULATOR_AB8500) += ab8500.o obj-$(CONFIG_REGULATOR_AD5398) += ad5398.o +obj-$(CONFIG_REGULATOR_ANATOP) += anatop-regulator.o obj-$(CONFIG_REGULATOR_BQ24022) += bq24022.o obj-$(CONFIG_REGULATOR_DA903X) += da903x.o obj-$(CONFIG_REGULATOR_DA9052) += da9052-regulator.o diff --git a/drivers/regulator/anatop-regulator.c b/drivers/regulator/anatop-regulator.c new file mode 100644 index 0000000..17499a5 --- /dev/null +++ b/drivers/regulator/anatop-regulator.c @@ -0,0 +1,241 @@ +/* + * Copyright (C) 2011 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., + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. + */ + +#include <linux/slab.h> +#include <linux/device.h> +#include <linux/module.h> +#include <linux/err.h> +#include <linux/io.h> +#include <linux/platform_device.h> +#include <linux/of.h> +#include <linux/of_address.h> +#include <linux/mfd/anatop.h> +#include <linux/regulator/driver.h> +#include <linux/regulator/of_regulator.h> + +struct anatop_regulator { + const char *name; + u32 control_reg; + struct anatop *mfd; + int vol_bit_shift; + int vol_bit_width; + int min_bit_val; + int min_voltage; + int max_voltage; + struct regulator_desc rdesc; + struct regulator_init_data *initdata; +}; + +static int anatop_set_voltage(struct regulator_dev *reg, int min_uV, + int max_uV, unsigned *selector) +{ + struct anatop_regulator *anatop_reg = rdev_get_drvdata(reg); + u32 val, sel; + int uv; + + uv = min_uV; + dev_dbg(&reg->dev, "%s: uv %d, min %d, max %d\n", __func__, + uv, anatop_reg->min_voltage, + anatop_reg->max_voltage); + + if (uv < anatop_reg->min_voltage) { + if (max_uV > anatop_reg->min_voltage) + uv = anatop_reg->min_voltage; + else + return -EINVAL; + } + + if (!anatop_reg->control_reg) + return -ENOTSUPP; + + sel = DIV_ROUND_UP(uv - anatop_reg->min_voltage, 25000); + if (sel * 25000 + anatop_reg->min_voltage > anatop_reg->max_voltage) + return -EINVAL; + val = anatop_reg->min_bit_val + sel; + *selector = sel; + dev_dbg(&reg->dev, "%s: calculated val %d\n", __func__, val); + anatop_set_bits(anatop_reg->mfd, + anatop_reg->control_reg, + anatop_reg->vol_bit_shift, + anatop_reg->vol_bit_width, + val); + + return 0; +} + +static int anatop_get_voltage_sel(struct regulator_dev *reg) +{ + struct anatop_regulator *anatop_reg = rdev_get_drvdata(reg); + u32 val; + + if (!anatop_reg->control_reg) + return -ENOTSUPP; + + val = anatop_get_bits(anatop_reg->mfd, + anatop_reg->control_reg, + anatop_reg->vol_bit_shift, + anatop_reg->vol_bit_width); + + return val - anatop_reg->min_bit_val; +} + +static int anatop_list_voltage(struct regulator_dev *reg, unsigned selector) +{ + struct anatop_regulator *anatop_reg = rdev_get_drvdata(reg); + int uv; + + uv = anatop_reg->min_voltage + selector * 25000; + dev_dbg(&reg->dev, "vddio = %d, selector = %u\n", uv, selector); + + return uv; +} + +static struct regulator_ops anatop_rops = { + .set_voltage = anatop_set_voltage, + .get_voltage_sel = anatop_get_voltage_sel, + .list_voltage = anatop_list_voltage, +}; + +static int __devinit anatop_regulator_probe(struct platform_device *pdev) +{ + struct device *dev = &pdev->dev; + struct device_node *np = dev->of_node; + struct regulator_desc *rdesc; + struct regulator_dev *rdev; + struct anatop_regulator *sreg; + struct regulator_init_data *initdata; + struct anatop *anatopmfd = dev_get_drvdata(pdev->dev.parent); + int ret = 0; + + initdata = of_get_regulator_init_data(dev, np); + sreg = devm_kzalloc(dev, sizeof(*sreg), GFP_KERNEL); + if (!sreg) + return -ENOMEM; + sreg->initdata = initdata; + sreg->name = kstrdup(of_get_property(np, "regulator-name", NULL), + GFP_KERNEL); + rdesc = &sreg->rdesc; + memset(rdesc, 0, sizeof(*rdesc)); + rdesc->name = sreg->name; + rdesc->ops = &anatop_rops; + rdesc->type = REGULATOR_VOLTAGE; + rdesc->owner = THIS_MODULE; + sreg->mfd = anatopmfd; + ret = of_property_read_u32(np, "reg", &sreg->control_reg); + if (ret) { + dev_err(dev, "no reg property set\n"); + goto anatop_probe_end; + } + ret = of_property_read_u32(np, "anatop-vol-bit-width", + &sreg->vol_bit_width); + if (ret) { + dev_err(dev, "no anatop-vol-bit-width property set\n"); + goto anatop_probe_end; + } + ret = of_property_read_u32(np, "anatop-vol-bit-shift", + &sreg->vol_bit_shift); + if (ret) { + dev_err(dev, "no anatop-vol-bit-shift property set\n"); + goto anatop_probe_end; + } + ret = of_property_read_u32(np, "anatop-min-bit-val", + &sreg->min_bit_val); + if (ret) { + dev_err(dev, "no anatop-min-bit-val property set\n"); + goto anatop_probe_end; + } + ret = of_property_read_u32(np, "anatop-min-voltage", + &sreg->min_voltage); + if (ret) { + dev_err(dev, "no anatop-min-voltage property set\n"); + goto anatop_probe_end; + } + ret = of_property_read_u32(np, "anatop-max-voltage", + &sreg->max_voltage); + if (ret) { + dev_err(dev, "no anatop-max-voltage property set\n"); + goto anatop_probe_end; + } + + rdesc->n_voltages = (sreg->max_voltage - sreg->min_voltage) + / 25000 + 1; + + /* register regulator */ + rdev = regulator_register(rdesc, dev, + initdata, sreg, pdev->dev.of_node); + if (IS_ERR(rdev)) { + dev_err(dev, "failed to register %s\n", + rdesc->name); + ret = PTR_ERR(rdev); + goto anatop_probe_end; + } + + platform_set_drvdata(pdev, rdev); + +anatop_probe_end: + if (ret) + kfree(sreg->name); + + return ret; +} + +static int __devexit anatop_regulator_remove(struct platform_device *pdev) +{ + struct regulator_dev *rdev = platform_get_drvdata(pdev); + struct anatop_regulator *sreg = rdev_get_drvdata(rdev); + const char *name = sreg->name; + + regulator_unregister(rdev); + kfree(name); + + return 0; +} + +static struct of_device_id __devinitdata of_anatop_regulator_match_tbl[] = { + { .compatible = "fsl,anatop-regulator", }, + { /* end */ } +}; + +static struct platform_driver anatop_regulator = { + .driver = { + .name = "anatop_regulator", + .owner = THIS_MODULE, + .of_match_table = of_anatop_regulator_match_tbl, + }, + .probe = anatop_regulator_probe, + .remove = anatop_regulator_remove, +}; + +static int __init anatop_regulator_init(void) +{ + return platform_driver_register(&anatop_regulator); +} +postcore_initcall(anatop_regulator_init); + +static void __exit anatop_regulator_exit(void) +{ + platform_driver_unregister(&anatop_regulator); +} +module_exit(anatop_regulator_exit); + +MODULE_AUTHOR("Nancy Chen <Nancy.Chen(a)freescale.com>, " + "Ying-Chun Liu (PaulLiu) <paul.liu(a)linaro.org>"); +MODULE_DESCRIPTION("ANATOP Regulator driver"); +MODULE_LICENSE("GPL v2"); -- 1.7.9.1

12 years, 2 months

[PATCH 0/3] Framebuffer related fixes for Exynos / Origen

by Tushar Behera

Following patchset is required to add framebuffer support on Origen. The patches are based on following commit on Kukjin's for-next branch. a188e1e "Merge branch 'next-samsung-devel' into for-next" Tushar Behera (3): ARM: EXYNOS: Increase DMA pool allocator size for framebuffer - Required to allocate the framebuffer successfully ARM: EXYNOS: Add clkdev lookup entry for lcd clock - Required for framebuffer operation ARM: EXYNOS: Invert VCLK polarity for framebuffer on Origen board - Required to remove glitch in LCD display arch/arm/mach-exynos/clock.c | 14 +++++++++----- arch/arm/mach-exynos/cpu.c | 7 +++++++ arch/arm/mach-exynos/mach-origen.c | 3 ++- 3 files changed, 18 insertions(+), 6 deletions(-) -- 1.7.4.1

12 years, 2 months

← Newer
1
...
6
7
8
9
10
11
12
13
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev March 2012