without risking
users data.
To Sascha: this replaces the previous patch which I asked for your ack.
Ack for this one aswell:
Acked-by: Sascha Hauer s.ha...@pengutronix.de
8---
Subject: [PATCH] ARM: Do not disable CPU_32v6K based on platform selection
CPU_32v6K controls whether
fix: arm, mach-mx3/devices.c
includecheck fix: arm, mach-omap1/mcbsp.c
includecheck fix: arm, mach-omap2/mcbsp.c
includecheck fix: arm, plat-s3c64xx/pm.c
includecheck fix: arm, plat-stmp3xxx/pinmux.c
For mach-mx3/devices.c:
Acked-by: Sascha Hauer s.ha
Hi,
The following patch allows it for boards to register a dummy supply for
devices for which no software controllable regulator is available. The
current CONFIG_REGULATOR_DUMMY and (unused) regulator_use_dummy_regulator()
mechanisms only allow to provide a dummy regulator for *all* devices
for
runtime.
This patch allows a board to register dummy supplies for devices
which need a regulator but which is not software controllable
on this board.
Signed-off-by: Sascha Hauer s.ha...@pengutronix.de
---
drivers/regulator/Makefile|2 +-
drivers/regulator/dummy-supply.c | 88
Hi Linus,
On Thu, Oct 27, 2011 at 02:48:11PM +0200, Linus Walleij wrote:
From: Robert Marklund robert.markl...@stericsson.com
Add some basic regulator support for the power pins, as needed
by the ST-Ericsson Snowball platform that powers up the SMSC911
chip using an external regulator.
On Fri, Oct 28, 2011 at 11:59:31PM +0200, Mark Brown wrote:
On Fri, Oct 28, 2011 at 10:26:58PM +0200, Sascha Hauer wrote:
drivers/regulator/Makefile|2 +-
drivers/regulator/dummy-supply.c | 88
+
We already have a dummy regulator
On Tue, Nov 01, 2011 at 06:27:21PM +, Mark Brown wrote:
On Tue, Nov 01, 2011 at 01:50:14PM -0400, Mike Frysinger wrote:
On Friday 28 October 2011 18:47:57 Sascha Hauer wrote:
We already have a dummy regulator driver and a fixed voltage regulator
driver, we shouldn't be adding
On Wed, Nov 02, 2011 at 10:41:27AM +, Mark Brown wrote:
On Wed, Nov 02, 2011 at 11:03:56AM +0100, Sascha Hauer wrote:
On Tue, Nov 01, 2011 at 06:27:21PM +, Mark Brown wrote:
As I think I said earlier I'd use the fixed regulator for this, all
Sascha's actually doing here
to be stolen from the
very top of declared memory, including highmem areas, rather than
our precious lowmem.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
There shouldn't be any problems with this on i.MX.
Acked-by: Sascha Hauer s.ha...@pengutronix.de
---
arch/arm/mm/init.c
ker...@wantstofly.org
Cc: Linus Walleij linus.wall...@stericsson.com
Cc: linux-omap@vger.kernel.org
Cc: Nicolas Pitre n...@fluxnic.net
Cc: Olof Johansson o...@lixom.net
Cc: Sascha Hauer ker...@pengutronix.de
Cc: Tony Lindgren t...@atomide.com
Cc: Viresh Kumar viresh.ku...@st.com
Cc: Wan
Hi Vladimir,
On Mon, May 16, 2011 at 12:45:56AM +0300, Vladimir Zapolskiy wrote:
This change shows a possibility to utilize C preprocessor to remove
redundant data from clock definitions for OMAP4 architecture.
If the change is evaluated as a positive one, the same approach could
be applied
Hi Paul,
On Fri, Mar 16, 2012 at 04:21:17PM -0600, Paul Walmsley wrote:
Hi
On Fri, 16 Mar 2012, Arnd Bergmann wrote:
If the common clock code is to go upstream now, it should be marked as
experimental.
No, please don't do this. This effectively marks the architectures using
the
On Sat, Mar 17, 2012 at 11:02:11AM -0700, Turquette, Mike wrote:
On Sat, Mar 17, 2012 at 2:05 AM, Arnd Bergmann a...@arndb.de wrote:
On Friday 16 March 2012, Turquette, Mike wrote:
On Fri, Mar 16, 2012 at 3:21 PM, Paul Walmsley p...@pwsan.com wrote:
From: Paul Walmsley p...@pwsan.com
On Wed, Mar 21, 2012 at 01:44:01AM -0600, Paul Walmsley wrote:
Hello Saravana,
Certainly a Kconfig help text change seems trivial enough. But even the
resistance to CONFIG_EXPERIMENTAL has been quite surprising to me, given
that every single defconfig in arch/arm/defconfig sets it:
$
On Wed, Mar 21, 2012 at 11:28:47AM +0100, Thierry Reding wrote:
* Arnd Bergmann wrote:
On Wednesday 21 March 2012, Thierry Reding wrote:
I don't have a public tree anywhere. Does anyone have a recommendation
where
I could set one up? github or gitorious are the first to come to my
On Mon, Nov 19, 2012 at 11:40:30AM +0100, Linus Walleij wrote:
On Mon, Nov 19, 2012 at 9:52 AM, Peter Ujfalusi peter.ujfal...@ti.com wrote:
I was actually tempted to remove the whole LED (PWM) thing from the
gpio-twl4030 driver. It was a big surprise to me to see something like this
in
On Mon, Jan 07, 2013 at 09:35:04PM +, Arnd Bergmann wrote:
(Adding Sascha Hauer, Linus Walleij, Lee Jones to Cc)
On Monday 07 January 2013, Tony Lindgren wrote:
At the end of the line, some kind of hardware glue is going to be needed.
I just feel that drawing from a sample
Hi Rob,
On Tue, Jan 08, 2013 at 10:11:23PM -0600, Rob Clark wrote:
Add an output panel driver for LCD panels. Tested with LCD3 cape on
beaglebone.
TODO: need some way to control the appropriate backlight device
TODO: probably want to make the DT bindings more generic for panel-info
v1:
Hi Rob,
On Tue, Jan 22, 2013 at 04:36:21PM -0600, Rob Clark wrote:
drivers/gpu/drm/Kconfig| 2 +
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/i2c/Makefile | 3 +
drivers/gpu/drm/i2c/tda998x_drv.c | 908
On Sun, Feb 10, 2013 at 12:35:43PM +0100, Javier Martinez Canillas wrote:
On Sun, Feb 10, 2013 at 10:37 AM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Sun, Feb 10, 2013 at 02:49:21AM +0100, Javier Martinez Canillas wrote:
I knew this would be controversial and that's why I
On Mon, Feb 11, 2013 at 11:33:19AM +0100, Javier Martinez Canillas wrote:
On Mon, Feb 11, 2013 at 9:16 AM, Sascha Hauer s.ha...@pengutronix.de wrote:
On Sun, Feb 10, 2013 at 12:35:43PM +0100, Javier Martinez Canillas wrote:
On Sun, Feb 10, 2013 at 10:37 AM, Russell King - ARM Linux
li
On Mon, Feb 11, 2013 at 05:44:23PM +0200, Roger Quadros wrote:
Currently on OMAP, it is not possible to specify a clock consumer
to any of the OMAP generated clocks using the device tree. This can pose
a problem for external devices that run off an OMAP clock as we
can't reliably provide a
On Mon, Apr 22, 2013 at 11:50:35PM +0530, Mugunthan V N wrote:
In earlier days phy fixup was added to phy frame work in board files.
As there won't be any board files here after the same has to be done in DT
This patch series adds the following features
* support for adding phy resigter fixup
On Sat, Jul 20, 2013 at 07:59:10PM -0700, Greg KH wrote:
On Sat, Jul 20, 2013 at 10:32:26PM -0400, Alan Stern wrote:
On Sat, 20 Jul 2013, Greg KH wrote:
That should be passed using platform data.
Ick, don't pass strings around, pass pointers. If you have platform
data you
Hi Tomi,
On Mon, Dec 16, 2013 at 04:56:30PM +0200, Tomi Valkeinen wrote:
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/displays-new/connector-dvi.c | 43
1 file changed, 43 insertions(+)
diff --git
and
the drivers. This only changes the places in the drivers where the temperature
is passed around as pointer, when drivers internally use another type this is
not changed.
Signed-off-by: Sascha Hauer s.ha...@pengutronix.de
Cc: Zhang Rui rui.zh...@intel.com
Cc: Eduardo Valentin edubez...@gmail.com
Cc: linux
On Thu, Jul 23, 2015 at 02:07:59PM +0200, Pavel Machek wrote:
On Tue 2015-07-21 09:21:32, Sascha Hauer wrote:
The thermal code uses int, long and unsigned long for temperatures
in different places.
Using an unsigned type limits the thermal framework to positive
temperatures without
and
the drivers. This only changes the places in the drivers where the temperature
is passed around as pointer, when drivers internally use another type this is
not changed.
Signed-off-by: Sascha Hauer s.ha...@pengutronix.de
Acked-by: Geert Uytterhoeven geert+rene...@glider.be
Reviewed-by: Jean Delvare jdelv
this or if you
prefer a new patch instead.
Thanks
Sascha
-8-
From 4907a7c32fd16eaf9f31d9f904276c9a0176b717 Mon Sep 17 00:00:00 2001
From: Sascha Hauer s.ha...@pengutronix.de
Date: Thu, 23 Jul 2015 12:32:31 +0200
Subject: [PATCH] fixup
and
the drivers. This only changes the places in the drivers where the temperature
is passed around as pointer, when drivers internally use another type this is
not changed.
Signed-off-by: Sascha Hauer s.ha...@pengutronix.de
Acked-by: Geert Uytterhoeven geert+rene...@glider.be
Reviewed-by: Jean Delvare jdelv
Hi Punit,
On Fri, Jul 17, 2015 at 12:14:36PM +0100, Punit Agrawal wrote:
Hi Sascha,
Sascha Hauer s.ha...@pengutronix.de writes:
The thermal code uses int, long and unsigned long for temperatures
in different places.
Using an unsigned type limits the thermal framework to positive
> This patch series fixes those issues in all the DT sources after locating the
> errors using the following script.
Nice. For the i.MX boards:
Reviewed-by: Sascha Hauer <s.ha...@pengutronix.de>
Sascha
--
Pengutronix e.K. |
32 matches
Mail list logo
