172c6a13653ac8cd6a231293b87c93821e90c1d6
gpio: samsung: add devicetree init for s3c24xx arches
Cc: Heiko Stübner he...@sntech.de
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
This patch stems from a time where I thought pinctrl
Am Mittwoch, 10. April 2013, 12:15:48 schrieb Kukjin Kim:
Heiko Stübner wrote:
This is the second installment of beginning devicetree support the
Samsung S3C24xx architectures and focuses on the s3c2416 for now.
Included is the devicetree support for the s3c24xx irq controller
Commit b2ca78717cea (ARM: S3C24XX: make gta02.h local) already replaced
the GTA02_GPIO_* constants in neo1973-wm8753.c but forgot to remove the
inclusion of mach/gta02.h before moving the file out of mach/.
Signed-off-by: Heiko Stuebner he...@sntech.de
---
sound/soc/samsung/neo1973_wm8753.c |
Am Sonntag, 14. April 2013, 14:20:35 schrieb Wolfram Sang:
On Thu, Apr 11, 2013 at 02:04:50AM +0200, Arnd Bergmann wrote:
No other file in the kernel besides i2c-s3c2410.c uses the current
plat/regs-iic.h, so we can simply move the header file to live in the
same directory as the driver, as
This is the second installment of beginning devicetree support the
Samsung S3C24xx architectures and focuses on the s3c2416 for now.
Included is the devicetree support for the s3c24xx irq controller and
basic support for smdk2416 boards, which can sucessfully boot.
After the discussion with
This move is necessary to make use of the irqchip infrastructure
for the following devicetree support for s3c24xx architectures.
Signed-off-by: Heiko Stuebner he...@sntech.de
---
arch/arm/mach-s3c24xx/Makefile |2 +-
drivers/irqchip/Makefile |
This adds devicetree parsing of the controller-data for the
interrupt controllers on S3C24XX architectures.
As the interrupts and their parent differ on all s3c24xx SoCs the
interrupt-list and parent-relationship is read from a list in the
devicetree data.
Signed-off-by: Heiko Stuebner
This adds a board file and the devicetree source files to support boards
using the Samsung S3C2416 SoC.
The dt source files contain the definitions generic to all S3C24XX SoCs
in the s3c24xx.dtsi file which then gets extendes with S3C2416 specific
definitions.
Signed-off-by: Heiko Stuebner
Hi,
while implementing devicetree support for the s3c2416 I noticed a fault
in the i2c-s3c2410 driver. The s3c2416 does not support pinctrl at the
moment (and will probably for a while), so the fallback functions in
pinctrl/consumer.h were used. These functions fail silently and the
relevant
Currently the fallback functions when pinctrl is not being built do
return either NULL or 0, either no pinctrl handle or no error,
making them fail silently.
All drivers using pinctrl do only test for error conditions, which
made for example the i2c-s3c2410 driver fail on a devicetree based
When pinctrl is not built the fallback functions fail silently
and emit either 0 error codes or NULL pinctrl handles.
Therefore it's needed to also check for this NULL-handle when
falling back to parsing the i2c gpios from devicetree.
Signed-off-by: Heiko Stuebner he...@sntech.de
---
Am Sonntag, 24. Februar 2013, 14:39:45 schrieb Julia Lawall:
[Adding the person who introduced the code]
On Sun, 24 Feb 2013, Russell King - ARM Linux wrote:
On Sun, Feb 24, 2013 at 12:45:11PM +0100, Julia Lawall wrote:
The function s3c24xx_irq_map in arch/arm/mach-s3c24xx/irq.c contains
Am Sonntag, 24. Februar 2013, 16:45:18 schrieb Julia Lawall:
On Sun, 24 Feb 2013, Heiko Stübner wrote:
Am Sonntag, 24. Februar 2013, 14:39:45 schrieb Julia Lawall:
[Adding the person who introduced the code]
On Sun, 24 Feb 2013, Russell King - ARM Linux wrote:
On Sun, Feb 24, 2013
Am Sonntag, 24. Februar 2013, 01:40:58 schrieb Linus Walleij:
On Sat, Feb 23, 2013 at 6:56 PM, Heiko Stübner he...@sntech.de wrote:
Currently the fallback functions when pinctrl is not being built do
return either NULL or 0, either no pinctrl handle or no error,
making them fail silently
Am Sonntag, 24. Februar 2013, 23:42:32 schrieb Linus Walleij:
On Sun, Feb 24, 2013 at 11:34 PM, Heiko Stübner he...@sntech.de wrote:
[Me]
This make me suspect that you have this ugly patch in some
private repo and I will be seeing it again and again :-(
All my s3c24xx work is done
Am Sonntag, 24. Februar 2013, 23:39:44 schrieb Linus Walleij:
On Sun, Feb 24, 2013 at 6:00 PM, Tomasz Figa tomasz.f...@gmail.com wrote:
Note that we are talking here about a temporary solution. The legacy
DT- based pin configuration will go away after all the DT-enabled
platforms using
Hi Alexander,
Am Freitag, 31. August 2012, 13:34:03 schrieb Alexandre Courbot:
Some device drivers (panel backlights especially) need to follow precise
sequences for powering on and off, involving gpios, regulators, PWMs
with a precise powering order and delays to respect between each steps.
Am Freitag, 7. September 2012, 10:04:24 schrieb Alex Courbot:
For your power_seq_run function you write that it simply returns an error
code on failure and looking through it I also just found the error return
statement. This would leave a device half turned on.
So I'm wondering, if it
Originally gpio-regulator used the first item of its state list
that matched the given voltage or current range.
Commit 4dbd8f63f0 (regulator: gpio-regulator: Set the smallest voltage/current
in the specified range) changed this, to make the selection independent of
the ordering of the state
Commit 1d5fcfec22 (PM / Domains: Add device domain data reference counter)
added a check for the return value of dev_pm_get_subsys_data.
But this function does not only return error codes but also 1 when a
new object has been created.
So, change the check to only catch real errors.
Am Sonntag, 5. August 2012, 23:13:46 schrieb Rafael J. Wysocki:
On Sunday, August 05, 2012, Heiko Stübner wrote:
Commit 1d5fcfec22 (PM / Domains: Add device domain data reference
counter) added a check for the return value of dev_pm_get_subsys_data.
But this function does not only return
Hi,
I hit a problem when setting a current limit and am not sure whose fault it is
(i.e. which component to change). Therefore I'd appreciate a pointer in the
right direction.
After the recent changes the gpio-regulator always selects the minimal value
to set. The gpio-vbus driver sets it's
Am Montag, 6. August 2012, 13:56:33 schrieb Mark Brown:
On Mon, Aug 06, 2012 at 01:27:56AM +0200, Heiko Stübner wrote:
500). Therefore if 500mA are the upper limit but the regulator also
supports lower values, these lower values always get selected (100mA in
my case). In contrast pda_power
Until now only the Exynos SoCs could use the serial driver via the
device tree. This patch adds compatible properties for the other
supported SoCs as well.
Tested on a s3c2416 based machine.
Signed-off-by: Heiko Stuebner he...@sntech.de
---
drivers/tty/serial/samsung.c | 10 ++
1
Am Donnerstag, 20. Dezember 2012, 17:56:23 schrieb Woody Wu:
Hi, List
Does the current kernel 3.7.1 support S3C2416 (it's *6* not 0) LCD and
touch screen? I saw the help text of the CONFIG_FB_S3C says it only
supports S3C6400 and S3C6410.
if you look in the mach-smd2416.c file you'll see
This series enables the use of the additional cores on Rockchip
Cortex-A9 SoCs.
To achieve this, add the scu, the needed sram and power-management-unit.
Tested on a rk3066a (dual core) by me and on a rk3188 (quad core)
by Ulrich Prinz.
(Note: rk3188 support in general needs additional upcoming
The pool is created thru devm_gen_pool_create, so the call to
gen_pool_destroy is not necessary.
Instead the sram-clock must be turned off again if it exists.
Signed-off-by: Heiko Stuebner he...@sntech.de
Tested-by: Ulrich Prinz ulrich.pr...@googlemail.com
Acked-by: Philipp Zabel
This adds the device-node and config select to enable the
scu in all Rockchip Cortex-A9 SoCs.
Signed-off-by: Heiko Stuebner he...@sntech.de
Tested-by: Ulrich Prinz ulrich.pr...@googlemail.com
---
arch/arm/boot/dts/rk3066a.dtsi |5 +
arch/arm/mach-rockchip/Kconfig |1 +
2 files
Some SoCs need parts of their sram for special purposes. So while being part
of the peripheral, it should not be part of the genpool controlling the sram.
Therefore add an option mmio-sram-reserved to keep arbitrary portions of the
sram from being part of the pool.
Suggested-by: Rob Herring
The Rockchip SoCs need a special part of their sram for bringup
of additional cores. Therefore also add a reserved section when adding the
mmio-sram node to keep the sram driver from using this space.
Signed-off-by: Heiko Stuebner he...@sntech.de
Tested-by: Ulrich Prinz
The pmu is needed to bring up the cores during smp operations.
Therefore add a node and documentation for it.
Signed-off-by: Heiko Stuebner he...@sntech.de
Tested-by: Ulrich Prinz ulrich.pr...@googlemail.com
---
Documentation/devicetree/bindings/arm/rockchip/pmu.txt | 16
This adds the necessary smp-operations and startup code to use
additional cores on Rockchip SoCs.
We currently hog the power management unit in the smp code, as it is
necessary to control the power to the cpu core and nothing else is
currently using it, so a generic implementation can be done
Am Freitag, 23. August 2013, 09:49:00 schrieb Axel Lin:
If (b-pin_base + b-nr_pins - 1) pin is true, pin = b-pin_base is
always true because b-nr_pins is never less than 0.
Thus this patch simplify the equation.
Signed-off-by: Axel Lin axel@ingics.com
Acked-by: Heiko Stuebner
This series tries to provide a basic dmaengine driver for the s3c24xx
SoCs to subsequently retire the old one with custom API.
Since v2 only some small fixes to the dma driver itself were added.
Since v1 three big changes happened (appart from fixing received comments):
For one the limitation
Each dma channel has its own clock. The upcoming dma driver wants to
handle these itself and therefore needs to be able to get the correct
clock for a channel.
Therefore rename the dma clocks to dma.X for s3c2412, s3c2416 and
s3c2443. This does not change the behaviour for the old dma driver at
This adds a new driver to support the s3c24xx dma using the dmaengine
and makes the old one in mach-s3c24xx obsolete in the long run.
Conceptually the s3c24xx-dma feels like a distant relative of the pl08x
with numerous virtual channels being mapped to a lot less physical ones.
The driver
This includes defining the mapping for the request sources.
Signed-off-by: Heiko Stuebner he...@sntech.de
Acked-by: Linus Walleij linus.wall...@linaro.org
---
changes since v1:
- follow new pdata definition
arch/arm/mach-s3c24xx/common.c| 106 +
The spi-s3c64xx device is also used on the s3c2416 and s3c2443 SoCs.
The driver also already uses only generic dma-engine operations.
Therefore add another elif to set the s3c24xx filter.
Signed-off-by: Heiko Stuebner he...@sntech.de
Acked-by: Linus Walleij linus.wall...@linaro.org
---
Hi Vinod,
Am Montag, 19. August 2013, 06:48:12 schrieb Vinod Koul:
On Wed, Aug 14, 2013 at 02:00:25PM +0200, Heiko Stübner wrote:
This adds a new driver to support the s3c24xx dma using the dmaengine
and makes the old one in mach-s3c24xx obsolete in the long run.
Conceptually
Am Mittwoch, 21. August 2013, 04:28:50 schrieb Axel Lin:
Just return once a match found makes the code simpler and shorter.
Signed-off-by: Axel Lin axel@ingics.com
as I'm a bit late for an Ack it seems, I can only offer a thanks for making
this nicer :-)
Heiko
---
This series tries to provide a basic dmaengine driver for the s3c24xx
SoCs to subsequently retire the old one with custom API.
Since v1 three big changes happened (appart from fixing received comments):
For one the limitation of sg-lists to 1 element is gone.Secondly the
specifics of the virtual
Each dma channel has its own clock. The upcoming dma driver wants to
handle these itself and therefore needs to be able to get the correct
clock for a channel.
Therefore rename the dma clocks to dma.X for s3c2412, s3c2416 and
s3c2443. This does not change the behaviour for the old dma driver at
The spi-s3c64xx device is also used on the s3c2416 and s3c2443 SoCs.
The driver also already uses only generic dma-engine operations.
Therefore add another elif to set the s3c24xx filter.
Signed-off-by: Heiko Stuebner he...@sntech.de
---
arch/arm/plat-samsung/devs.c |5 -
1 file
This includes defining the mapping for the request sources.
Signed-off-by: Heiko Stuebner he...@sntech.de
---
changes since v1:
- follow new pdata definition
arch/arm/mach-s3c24xx/common.c| 106 +
arch/arm/mach-s3c24xx/common.h|3 +
This adds a new driver to support the s3c24xx dma using the dmaengine
and makes the old one in mach-s3c24xx obsolete in the long run.
Conceptually the s3c24xx-dma feels like a distant relative of the pl08x
with numerous virtual channels being mapped to a lot less physical ones.
The driver
This adds a driver for touchscreens using the zforce infrared
technology from Neonode connected via i2c to the host system.
It supports multitouch with up to two fingers and tracking of the
contacts in hardware.
Signed-off-by: Heiko Stuebner he...@sntech.de
---
drivers/input/touchscreen/Kconfig
Hi Mike,
Am Montag, 17. Juni 2013, 04:58:24 schrieb Mike Turquette:
Devicetree binding for the basic clock divider, plus the setup function
to register the clock. Based on the existing fixed-clock binding.
Signed-off-by: Mike Turquette mturque...@linaro.org
---
Changes since v1:
* mask
Am Dienstag, 18. Juni 2013, 02:53:59 schrieb Heiko Stübner:
Am Montag, 17. Juni 2013, 04:58:23 schrieb Mike Turquette:
Device Tree binding for the basic clock multiplexer, plus the setup
function to register the clock. Based on the existing fixed-clock
binding.
Includes minor
Am Mittwoch, 11. September 2013, 10:46:13 schrieb José Miguel Gonçalves:
Some GPIO line limits are incorrectly set which, for instance,
does not allow nRTS1 (GPH11) configuration on a S3C2416 chip.
Signed-off-by: José Miguel Gonçalves jose.goncal...@inov.pt
I thumbed thru the SoC manuals of
Am Montag, 29. Juli 2013, 23:39:45 schrieb Matt Sealey:
On Mon, Jul 29, 2013 at 9:02 AM, Philipp Zabel p.za...@pengutronix.de
wrote:
Hi Heiko,
Am Montag, den 29.07.2013, 15:12 +0200 schrieb Heiko Stübner:
Some SoCs need parts of their sram for special purposes. So while being
part
Am Montag, 4. November 2013, 13:24:10 schrieb Linus Walleij:
In my driver, I have the one entry per pin support for all my
properties instead of just the function property, like the drive_str
property below:
+ grp_1 {
+ brcm,pins = pin1, pin2,
default option in HW.
The description of that pinconfig option is:
7970cb77 (Heiko Stübner2013-06-06 16:44:25 +0200 43) *
@PIN_CONFIG_BIAS_PULL_PIN_DEFAULT: the pin will be pulled up or down
based 70637a6d (Heiko Stübner2013-06-25 14:55:42 +0200 44) *
on embedded
Hi Vinod,
with the removed double-retrival of the cookie state, is the driver ok now?
Because I think kgene needs an ack on it.
Thanks
Heiko
Am Mittwoch, 18. September 2013, 21:19:54 schrieb Heiko Stübner:
This adds a new driver to support the s3c24xx dma using the dmaengine
and makes
This series tries to provide a basic dmaengine driver for the s3c24xx
SoCs to subsequently retire the old one with custom API.
Since v4 an unnecessary second call to retrieve the dma cookie status was
removed.
Since v3 more smaller fixes were added, and memcpy operations now have a very
simple
This adds a new driver to support the s3c24xx dma using the dmaengine
and makes the old one in mach-s3c24xx obsolete in the long run.
Conceptually the s3c24xx-dma feels like a distant relative of the pl08x
with numerous virtual channels being mapped to a lot less physical ones.
The driver
Each dma channel has its own clock. The upcoming dma driver wants to
handle these itself and therefore needs to be able to get the correct
clock for a channel.
Therefore rename the dma clocks to dma.X for s3c2412, s3c2416 and
s3c2443. This does not change the behaviour for the old dma driver at
This includes defining the mapping for the request sources.
Signed-off-by: Heiko Stuebner he...@sntech.de
Acked-by: Linus Walleij linus.wall...@linaro.org
---
changes since v1:
- follow new pdata definition
arch/arm/mach-s3c24xx/common.c| 106 +
The spi-s3c64xx device is also used on the s3c2416 and s3c2443 SoCs.
The driver also already uses only generic dma-engine operations.
Therefore add another elif to set the s3c24xx filter.
Signed-off-by: Heiko Stuebner he...@sntech.de
Acked-by: Linus Walleij linus.wall...@linaro.org
---
Am Mittwoch, 18. September 2013, 19:53:53 schrieb Sebastian Hesselbarth:
With arch/arm calling of_clk_init(NULL) from time_init(), we can now
remove custom .init_time hooks.
Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
Acked-by: Heiko Stuebner he...@sntech.de
---
Add binding documentation for the hym8563 rtc chip.
Signed-off-by: Heiko Stuebner he...@sntech.de
---
.../devicetree/bindings/rtc/haoyu,hym8563.txt | 29
1 file changed, 29 insertions(+)
create mode 100644 Documentation/devicetree/bindings/rtc/haoyu,hym8563.txt
diff
This series adds support for the Haoyu Microelectronics HYM8563 rtc. This
chip is often used in designs around the Cortex-A9 SoCs from Rockchip to
provide rtc functionality and the 32kHz suspend clock the SoC needs.
Heiko Stuebner (2):
Documentation: dt: Add dt hym8563 binding
rtc: add
The Haoyu Microelectronics HYM8563 provides rtc- and alarm functions
as well as a clock output of up to 32kHz.
Signed-off-by: Heiko Stuebner he...@sntech.de
---
drivers/rtc/Kconfig | 11 +
drivers/rtc/Makefile |1 +
drivers/rtc/rtc-hym8563.c | 619
Hi Laxman,
Am Mittwoch, 20. November 2013, 10:54:10 schrieb Laxman Dewangan:
I may be blind, but where get the early-irqs resumed in the error
path of dpm_suspend_noirq?
When a suspend_noirq callback returns an error, dpm_resume_noirq gets
called, which only calls resume_device_irqs
Am Montag, 25. November 2013, 13:01:25 schrieb Mark Rutland:
[...]
+static int hym8563_probe(struct i2c_client *client,
+const struct i2c_device_id *id)
+{
+ struct hym8563 *hym8563;
+ int ret, gpio_int;
+
+ hym8563 =
The Haoyu Microelectronics HYM8563 provides rtc- and alarm functions
as well as a clock output of up to 32kHz.
Signed-off-by: Heiko Stuebner he...@sntech.de
---
drivers/rtc/Kconfig | 11 +
drivers/rtc/Makefile |1 +
drivers/rtc/rtc-hym8563.c | 626
This series adds support for the Haoyu Microelectronics HYM8563 rtc. This
chip is often used in designs around the Cortex-A9 SoCs from Rockchip to
provide rtc functionality and the 32kHz suspend clock the SoC needs.
changes since v1:
- add haoyu prefix to vendor-prefixes.txt
- use gpio_to_irq to
Add binding documentation for the hym8563 rtc chip.
Signed-off-by: Heiko Stuebner he...@sntech.de
---
.../devicetree/bindings/rtc/haoyu,hym8563.txt | 27
.../devicetree/bindings/vendor-prefixes.txt|1 +
2 files changed, 28 insertions(+)
create mode 100644
Am Sonntag, 1. Dezember 2013, 15:38:40 schrieb Richard Weinberger:
On Sun, Dec 1, 2013 at 2:39 PM, Heiko Stübner he...@sntech.de wrote:
+static int hym8563_probe(struct i2c_client *client,
+const struct i2c_device_id *id)
+{
+ struct hym8563 *hym8563
This series adds support for the Haoyu Microelectronics HYM8563 rtc. This
chip is often used in designs around the Cortex-A9 SoCs from Rockchip to
provide rtc functionality and the 32kHz suspend clock the SoC needs.
changes since v2:
- get size for devm_kzalloc from struct not from pointer
Add binding documentation for the hym8563 rtc chip.
Signed-off-by: Heiko Stuebner he...@sntech.de
---
.../devicetree/bindings/rtc/haoyu,hym8563.txt | 27
.../devicetree/bindings/vendor-prefixes.txt|1 +
2 files changed, 28 insertions(+)
create mode 100644
The Haoyu Microelectronics HYM8563 provides rtc- and alarm functions
as well as a clock output of up to 32kHz.
Signed-off-by: Heiko Stuebner he...@sntech.de
---
drivers/rtc/Kconfig | 11 +
drivers/rtc/Makefile |1 +
drivers/rtc/rtc-hym8563.c | 626
Hi,
Commit 9bab0b7fbace (genirq: Add IRQF_RESUME_EARLY and resume such IRQs
earlier) split the suspend/resume of the irqs into two parts.
The early-irqs get resumed during syscore_resume, while the rest get
resumed by the regular resume_device_irqs.
I may be blind, but where get the early-irqs
Commit 60e93575476f (serial: samsung: enable clock before clearing pending
interrupts during init) added handling of the controller clock during init.
On most systems this clock is also one of the baud_clock sources and
possibly used by the earlycon and thus already enabled by the bootloader.
Hi Laxman,
Am Donnerstag, 5. Dezember 2013, 11:49:05 schrieb Laxman Dewangan:
Can you please review this patch?
This patch is pending from long back for review.
the patch already made it into the appropriate tree, as can be seen by tip-bot
message and on [0].
Heiko
[0]
Hi,
Am Freitag, 6. Dezember 2013, 08:10:42 schrieb Jingoo Han:
@@ -351,8 +352,6 @@ static int gpio_regulator_remove(struct platform_device
*pdev) {
struct gpio_regulator_data *drvdata = platform_get_drvdata(pdev);
- regulator_unregister(drvdata-dev);
-
Hi Rob,
Am Mittwoch, 12. März 2014, 09:28:46 schrieb Rob Herring:
On Wed, Mar 12, 2014 at 8:46 AM, Heiko Stübner he...@sntech.de wrote:
From: Heiko Stuebner heiko.stueb...@bq.com
This documents the binding for the gpio-charger power-supply.
How does this relate to what's documented
This series enables the use of the additional cores on Rockchip
Cortex-A9 SoCs.
To achieve this, add the scu, the needed sram and power-management-unit.
Tested on both a BQ Curie2 (rk3066a / dual core) and
on a Radxa Rock (rk3188 / quad core).
As this version again involves bigger changes to
Some SoCs need parts of their sram for special purposes. So while being part
of the peripheral, it should not be part of the genpool controlling the sram.
Therefore add the option to define reserved regions as subnodes of the
sram-node similar to defining reserved global memory regions.
This implements support for defining reserved areas as subnodes,
to keep the genpool from using these.
Suggested-by: Rob Herring robherri...@gmail.com
Signed-off-by: Heiko Stuebner he...@sntech.de
Tested-by: Ulrich Prinz ulrich.pr...@googlemail.com
---
drivers/misc/sram.c | 125
This adds the device-node and config select to enable the
scu in all Rockchip Cortex-A9 SoCs.
Signed-off-by: Heiko Stuebner he...@sntech.de
Tested-by: Ulrich Prinz ulrich.pr...@googlemail.com
---
arch/arm/boot/dts/rk3xxx.dtsi | 5 +
arch/arm/mach-rockchip/Kconfig | 1 +
2 files changed, 6
Add dt-nodes for the sram on rk3066 and rk3188 including the reserved section
needed for smp bringup.
Signed-off-by: Heiko Stuebner he...@sntech.de
Tested-by: Ulrich Prinz ulrich.pr...@googlemail.com
---
.../devicetree/bindings/arm/rockchip/smp-sram.txt | 30 ++
This adds the necessary smp-operations and startup code to use
additional cores on Rockchip SoCs.
We currently hog the power management unit in the smp code, as it is
necessary to control the power to the cpu core and nothing else is
currently using it, so a generic implementation can be done
The pmu is needed to bring up the cores during smp operations and later
also other system parts. Therefore add a node and documentation for it.
Signed-off-by: Heiko Stuebner he...@sntech.de
Tested-by: Ulrich Prinz ulrich.pr...@googlemail.com
---
Some SoCs need parts of their sram for special purposes. So while being part
of the peripheral, it should not be part of the genpool controlling the sram.
Therefore add the option to define reserved regions as subnodes of the
sram-node similar to defining reserved global memory regions.
Am Donnerstag, 27. Februar 2014, 10:48:26 schrieb Pankaj Dubey:
On 02/27/2014 09:16 AM, Mike Turquette wrote:
Quoting Pankaj Dubey (2014-02-25 21:24:07)
CC: Ben Dooks ben-li...@fluff.org
CC: Kukjin Kim kgene@samsung.com
CC: Russell King li...@arm.linux.org.uk
Signed-off-by:
This series adds devicetree support to the gpio-charger and fixes a small
issue with the return value of gpio_get_value.
Heiko Stuebner (3):
dt-bindings: document gpio-charger bindings
power: gpio-charger: add device tree support
power: gpio-charger: do not use gpio value directly
From: Heiko Stuebner heiko.stueb...@bq.com
This documents the binding for the gpio-charger power-supply.
Signed-off-by: Heiko Stuebner heiko.stueb...@bq.com
---
.../bindings/power_supply/gpio-charger.txt | 23 ++
1 file changed, 23 insertions(+)
create mode 100644
From: Heiko Stuebner heiko.stueb...@bq.com
Add the ability to parse gpio-charger data from a devicetree node.
Signed-off-by: Heiko Stuebner heiko.stueb...@bq.com
---
drivers/power/gpio-charger.c | 66 ++--
1 file changed, 63 insertions(+), 3 deletions(-)
From: Heiko Stuebner heiko.stueb...@bq.com
Some gpio implementations return interesting values for gpio_get_value when
the value is not 0 - as seen on a imx6sl board. Therefore do not use the
value returned from gpio_get_value directly but simply check for 0 or not 0.
Signed-off-by: Heiko
From: Heiko Stuebner heiko.stueb...@bqreaders.com
Commit 934624d6e9f0 (regulator: gpio-regulator: do not open-code counting
and access of dt array elements) forgot to convert the recently added
gpios-states property using the same pattern.
Convert this instance to use the of-helpers too,
Am Donnerstag, 13. Februar 2014, 19:03:22 schrieb Mark Brown:
On Thu, Feb 13, 2014 at 12:48:52AM +0100, Heiko Stübner wrote:
From: Heiko Stuebner heiko.stueb...@bqreaders.com
Commit 934624d6e9f0 (regulator: gpio-regulator: do not open-code counting
and access of dt array elements) forgot
From: Heiko Stuebner heiko.stueb...@bqreaders.com
Commit 934624d6e9f0 (regulator: gpio-regulator: do not open-code counting
and access of dt array elements) forgot to convert the recently added
gpios-states property using the same pattern.
Convert this instance to use the of-helpers too,
In a different thread [0] Mark Rutland suggested that drivers should not
repeatedly open-code the counting of array elements in a property as well
as handling the format and endianes of the DTB, as these should be limited
to the of_ helper functions.
Therefore the first patch introduces a set of
From: Heiko Stuebner heiko.stueb...@bqreaders.com
The need to know the number of array elements in a property is
a common pattern. To prevent duplication of open-coded implementations
add a helper static function that also centralises strict sanity
checking and DTB format details, as well as a
From: Heiko Stuebner heiko.stueb...@bqreaders.com
Open coding the counting of elements in a dt-property is abstracted by the newly
introduced of_property_count_uXX_elems functions. Additionally the raw iteration
over the states element exposes the endian conversion and dtb-format details,
which
From: Heiko Stuebner heiko.stueb...@bqreaders.com
Open coding the counting of elements in a dt-property is abstracted by the newly
introduced of_property_count_uXX_elems functions. Additionally the raw iteration
over the states element exposes the endian conversion and dtb-format details,
which
From: Heiko Stuebner heiko.stueb...@bqreaders.com
Commit 934624d6e9f0 (regulator: gpio-regulator: do not open-code counting
and access of dt array elements) forgot to convert the recently added
gpios-states property using the same pattern.
Convert this instance to use the of-helpers too,
Am Freitag, 7. Juni 2013, 14:53:51 schrieb Linus Walleij:
On Thu, Jun 6, 2013 at 9:11 PM, Heiko Stübner he...@sntech.de wrote:
+ for (i = 0, j = 0; i size; i += 4, j++) {
+ unsigned long pinconf;
+
+ num = be32_to_cpu(*list++);
+ bank
Am Samstag, 8. Juni 2013, 01:13:48 schrieb Heiko Stübner:
Am Freitag, 7. Juni 2013, 14:53:51 schrieb Linus Walleij:
On Thu, Jun 6, 2013 at 9:11 PM, Heiko Stübner he...@sntech.de wrote:
+ for (i = 0, j = 0; i size; i += 4, j++) {
+ unsigned long pinconf
Hi Linus,
following your suggestions for a common handling of things like pulls in dt,
I've come up with the following solution - hopefully I've gotten the correct
meaning of your explanaitions.
It handles all the pinconfigs that either ignore the argument, or have very
simple one, like
1 - 100 of 3032 matches
Mail list logo
