snd_soc_register_card() method instead, as suggested by the ASoC
core generated warning message, and move both the card and codec
platform device registration to the arch board file where those belong.
Created and tested against linux-3.6-rc5.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
...@atomide.com
To: Janusz Krzysztofik jkrzy...@tis.icnet.pl
Cc: Mark Brown broo...@opensource.wolfsonmicro.com, Liam Girdwood
l...@ti.com, linux-omap@vger.kernel.org,
linux-arm-ker...@lists.infradead.org, alsa-de...@alsa-project.org
* Janusz Krzysztofik jkrzy...@tis.icnet.pl [120916 12:18]:
Tony
Dnia niedziela, 16 września 2012 21:17:03 Janusz Krzysztofik pisze:
The old method of registering with the ASoC core by creating a
soc-audio platform device no longer works for Amstrad Delta sound card
after recent changes to drvdata handling (commit
0998d0631001288a5974afc0b2a5f568bcdecb4d
On Wed, 19 Sep 2012 14:05:43 Tony Lindgren wrote:
This is only used by omap1.
And to fix things properly, this should not be included
from the drivers at all.
Akced-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
I'll take care of updating the drivers when I have some spare time.
Thanks
snd_soc_register_card() method instead, as suggested by the ASoC
core generated warning message, and move both the card and codec
platform device registration to the arch board file where those belong.
Created and tested against linux-3.6-rc5.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
/pub/scm/linux/kernel/git/broonie/sound.git for-3.7
Janusz: Can you retest this series on OMAP1 to be sure I have not broken it?
Hi Peter,
It looks like you haven't :-).
For OMAP1:
Tested-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
Thanks,
Janusz
--
To unsubscribe from this list: send the line
phone as I didn't get back home for this weekend, but I think that
the asterisk soft phone is quite a demanding use case.
The only thing I'm not sure about is why the sysfs provided
bytes_transferred values never change from their initial zeros.
For OMAP1:
Tested-by: Janusz Krzysztofik jkrzy
On Tue, 4 Sep 2012 15:08:00 Peter Ujfalusi wrote:
Hi Russell,
Enable the element mode (thus allowing mono playback and probably unblocking
OMAP1, OMAP2420) in OMAP dmaengine and omap-pcm.
Janusz: would it be possible for you to test Russell's series plus this on
OMAP1 to make sure that we
Dnia piątek, 31 sierpnia 2012 14:31:04 Mark Brown pisze:
On Wed, Aug 29, 2012 at 07:04:48AM +0200, Janusz Krzysztofik wrote:
On Tue, 28 Aug 2012 11:13:39 Mark Brown wrote:
The above looks like you already have a platform driver?
Mark,
I should have rather answered: No, ams-delta.c
On Mon, 27 Aug 2012 14:38:35 Mark Brown wrote:
On Mon, Aug 27, 2012 at 11:28:30PM +0200, Janusz Krzysztofik wrote:
- platform_set_drvdata(ams_delta_audio_platform_device,
- ams_delta_audio_card);
-
- ret = platform_device_add(ams_delta_audio_platform_device
On Tue, 28 Aug 2012 11:13:39 Mark Brown wrote:
On Tue, Aug 28, 2012 at 05:13:05PM +0200, Janusz Krzysztofik wrote:
On Mon, 27 Aug 2012 14:38:35 Mark Brown wrote:
On Mon, Aug 27, 2012 at 11:28:30PM +0200, Janusz Krzysztofik wrote:
- platform_set_drvdata
,
is registered. Fix this by moving the codec registration bits up, before
the card is probed for.
Created and tested against linux-3.6-rc3
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
sound/soc/omap/ams-delta.c | 18 ++
1 files changed, 10 insertions(+), 8 deletions(-)
diff
On Tue, 15 May 2012 14:35:08 Oleg Matcovschi wrote:
Use omap_disable_channel_irq() function instead of directly accessing CICR.
The omap_disable_chanel_irq() function clears pending interrupts
and disables interrupt on channel.
Functions omap2_enable_irq_lch()/omap2_disable_irq_lch() clear
On Sunday 06 of May 2012 18:50:16 Jarkko Nikula wrote:
On 05/04/2012 10:39 PM, Janusz Krzysztofik wrote:
This seems like a nice fix to me. As it affects all omaps, I'd like to
see some tested-by from Janusz/Jarkko/Peter. Can you guys give it a
try
with some audio tests?
OK, I can do
On Friday 11 of May 2012 09:53:07 Tony Lindgren wrote:
* Paul Walmsley p...@pwsan.com [120510 15:31]:
Janusz Krzysztofik reported the following build break on OMAP1 builds that
don't include CONFIG_ARCH_OMAP16XX:
LD .tmp_vmlinux1
arch/arm/mach-omap1/built-in.o: In function
Dnia czwartek, 3 maja 2012 13:28:58 Vaibhav Hiremath pisze:
Current OMAP code supports couple of clocksource options based
on compilation flag (CONFIG_OMAP_32K_TIMER). The 32KHz sync-timer
and a gptimer which can run on 32KHz or system clock (e.g 38.4 MHz)
This patch series cleans up the
on Amstrad Delta were not
related, and this patch is still required for GPIO interrupts hardware
being correctly initialized on OMAP1 in 3.4-rc6. You can add my
Tested-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
if you wish.
Thanks,
Janusz
--
To unsubscribe from this list: send the line
Dnia wtorek, 8 maja 2012 10:11:46 Artem Bityutskiy pisze:
On Tue, 2012-05-08 at 10:03 +0300, Artem Bityutskiy wrote:
On Mon, 2012-05-07 at 22:51 +0200, Janusz Krzysztofik wrote:
A call to request_mem_region() has been introduced in the omap-
gpio
driver recently (commit
the request_mem_region() call from
the former, especially as this call is going to be removed while the
long-term solution is implemented.
Tested on Amstrad Delta.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
Acked-by: Tony Lindgren t...@atomide.com
---
Artem, Tony,
I hope the changelog
Dnia piątek, 4 maja 2012 09:59:49 Tony Lindgren pisze:
* Janusz Krzysztofik jkrzy...@tis.icnet.pl [120430 10:30]:
Commit 384ebe1c2849160d040df3e68634ec506f13d9ff, gpio/omap: Add DT
support to GPIO driver, introduced dynamic IRQ numbering of OMAP
GPIO
interrupts, breaking all IH_GPIO_BASE
On Fri, 4 May 2012 10:11:25 Tony Lindgren wrote:
Hi,
* Janusz Krzysztofik jkrzy...@tis.icnet.pl [120430 11:15]:
Dnia czwartek, 26 kwietnia 2012 08:20:59 Artem Bityutskiy pisze:
On Wed, 2012-04-25 at 19:01 +0200, Janusz Krzysztofik wrote:
Both drivers use separate subsets of registers
Dnia piątek, 4 maja 2012 09:51:46 Tony Lindgren pisze:
Hi,
* Oleg Matcovschi oleg.matcovs...@ti.com [120420 13:49]:
Use omap_disable_channel_irq() function instead of directly
accessing CICR.
The omap_disable_chanel_irq() function clears pending interrupts
and disables interrupt on
Dnia piątek, 4 maja 2012 10:43:02 Tony Lindgren pisze:
Hi,
* Kevin Hilman khil...@ti.com [120502 13:11]:
Vaibhav Hiremath hvaib...@ti.com writes:
OMAP1, omap_32k_timer_init() function always returns true,
irrespective of whether error occurred while initializing 32k sync
counter
-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
arch/arm/mach-omap1/ams-delta-fiq.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap1/ams-delta-fiq.c
b/arch/arm/mach-omap1/ams-delta-fiq.c
index fcce7ff..cfd98b1 100644
--- a/arch/arm/mach-omap1/ams-delta
Dnia czwartek, 26 kwietnia 2012 08:20:59 Artem Bityutskiy pisze:
On Wed, 2012-04-25 at 19:01 +0200, Janusz Krzysztofik wrote:
Both drivers use separate subsets of registers that belong to the
OMAP1
MPU I/O device, but are used for controlling different sets of I/O
pins.
The NAND driver
On Friday 27 of April 2012 14:09:11 Tarun Kanti DebBarma wrote:
Breaking commit: ab985f0f7c2c0ef90b7c832f0c04f470dda0593d
Initialization of irqenable, irqstatus registers is the common
operation done in this function for all OMAP platforms, viz.
OMAP1, OMAP2+. The latter _gpio_rmw()'s to
Dnia środa, 25 kwietnia 2012 18:13:38 Artem Bityutskiy pisze:
On Tue, 2012-04-17 at 15:49 +0200, Janusz Krzysztofik wrote:
A call to request_mem_region() has been introduced in the omap-gpio
driver recently (commit 96751fcbe5438e95514b025e9cee7a6d38038f40,
gpio/omap: Use devm_ API and add
Dnia wtorek, 24 kwietnia 2012 21:06:59 DebBarma, Tarun Kanti pisze:
Hi Janusz,
Here is the patch, with attachment as well. I have just tested on
OMAP4 platform.
Testing on other OMAP2+ platforms is pending. In the meantime can you please
validate on OMAP1 platform and confirm? Thanks.
Hi,
On Thursday 02 of February 2012 23:00:37 Tarun Kanti DebBarma wrote:
With register offsets now defined for respective OMAP versions we can get rid
of cpu_class_* checks. This function now has common initialization code for
all OMAP versions...
Signed-off-by: Tarun Kanti DebBarma
request_mem_region() call and related bits from ams-delta NAND
driver.
Created and tested against linux-3.4-rc3.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
drivers/mtd/nand/ams-delta.c | 12 +---
1 files changed, 1 insertions(+), 11 deletions(-)
diff --git a/drivers/mtd
.
Depends on patches 1/3 and 2/3 for clean apply and keep things working.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com
Cc: Tony Lindgren t...@atomide.com
---
v2 - v3 changes: none.
Changes against initial version:
* don't move consumer
the modem initialization procedure,
as this operation was already ineffective since patch 1/3, and not
needed because the regulator is set up as initially enabled.
Depends on patch 1/3 ARM: OMAP1: ams-delta: set up regulator over modem
reset GPIO pin to apply cleanly.
Signed-off-by: Janusz
track the regulator
enable/disable state, compare new target bias level (the codec case)
or power state (the modem case) with the old value instead; thanks to
Mark Brown who suggested this solution,
* a few other minor changes, mostly stylistic.
Janusz Krzysztofik (3):
ARM: OMAP1: ams-delta
for balancing the regulator enable/disable operations,
together with the consumer data needed for tracking the regulator state,
will be removed once the drivers are updated.
Depends on patch series ARM: OMAP1: ams-delta: replace custom I/O with
GPIO.
Signed-off-by: Janusz Krzysztofik jkrzy
On Thu, 1 Mar 2012 15:31:01 Tony Lindgren wrote:
I've pushed ams-delta branch that's based on -rc5 merged
with what Arnd pulled yesterday as -rc1 has i2c-omap.c
a compile bug for omap1. I've applied these two patches
there as the second one depends on what got pulled:
ARM: OMAP1:
On Wed, 29 Feb 2012 13:13:31 Tony Lindgren wrote:
* Arnd Bergmann a...@arndb.de [120229 12:35]:
On Wednesday 29 February 2012, Tony Lindgren wrote:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap
omap1
Janusz Krzysztofik (7):
ARM: OMAP1: ams-delta: register
On Wednesday 15 of February 2012 17:56:15 Ujfalusi, Peter wrote:
Hi,
CC-ing Janusz, since he is the only one I know who have, and use OMAP1
with audio...
Janusz: if your time allows would you be able to test this series on
OMAP1 (it compiles...)?
for OMAP1:
Tested-by: Janusz Krzysztofik
On Thursday 09 of February 2012 14:48:53 Russell King - ARM Linux wrote:
There is no optimisation to adding __refdata to stuff. That's screaming
that you have lots of bugs here.
Thanks for your teaching. I find those aspects not very exhaustively documented
under Documentation/, so any hints
While resolving section mismatches introduced with recent patches
to for-next, a few dangerous, driver bind/unbind unaware section
tagging already present in mainline have been identified. Fix them.
Created and tested against linux-3.3-rc2.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
data found in the board
file have been revised and hopefully corrected and/or optimized.
Created and tested on top of current linux-omap/omap1, commit
967809bd7faf71ddc29c8081e0f21db8b201a0f4.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
arch/arm/mach-omap1/board-ams-delta.c
of all init data found in the
board file have been revised and hopefully optimised.
Created and tested on top of current linux-omap/omap1, commit
967809bd7faf71ddc29c8081e0f21db8b201a0f4.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
arch/arm/mach-omap1/board-ams-delta.c | 35
On Wednesday 08 of February 2012 12:16:13 Igor Grinberg wrote:
...
After updating omap1_defconfig,
there are several section mismatch warnings seen.
Hopefully, I will have time to fix those tomorrow
(unless someone will be kind enough to fix them before me).
Sound like introduced with my
for balancing the regulator enable/disable operations,
together with the consumer data needed for tracking the regulator state,
will be removed once the drivers are updated.
Depends on patch series ARM: OMAP1: ams-delta: replace custom I/O with
GPIO.
Signed-off-by: Janusz Krzysztofik jkrzy
.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
Cc: Tony Lindgren t...@atomide.com
---
No functional changes against initial version.
arch/arm/mach-omap1/board-ams-delta.c | 22 +-
1 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap1
in the board file. While
being at it, simplify the way the modem .pm callback handles the
regulator and drop that helper function and its related consumer setup
completely.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com
Cc: Tony
suggested this solution,
* a few other minor changes, mostly stylistic.
Janusz Krzysztofik (3):
ARM: OMAP1: ams-delta: set up regulator over modem reset GPIO pin
ARM: OMAP1: ams-delta: update the modem to use regulator API
ASoC: OMAP: ams-delta: drop .set_bias_level callback
arch/arm/mach-omap1
track the regulator
enable/disable state, compare new targert bias level (the codec case)
or power state (the modem case) with the old value instead; thanks to
Mark Brown who suggested this solution,
* a few other minor changes, mostly stylistic.
Janusz Krzysztofik (4):
ARM: OMAP1: ams
for balancing the regulator enable/disable operations,
together with the consumer data needed for tracking the regulator state,
will be removed once the drivers are updated.
Depends on patch series ARM: OMAP1: ams-delta: replace custom I/O with
GPIO.
Signed-off-by: Janusz Krzysztofik jkrzy
card .set_bias_level callback to not touch codec-dapm.bias_level.
While extending the cx20442 structure, drop unused control_type member.
Created against linxu-3.2-rc6, tested on top of patch 1/4 ARM: OMAP1:
ams-delta: set up a regulator over the modem reset GPIO pin.
Signed-off-by: Janusz
-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
Changes against initial version:
* don't move consumer setup elements, now named to indicated their
modem related purpose, down the file,
* don't track the regulator enavble/disable state, compare new target
power state with the old one instead; thanks
.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
No functional changes against initial version.
arch/arm/mach-omap1/board-ams-delta.c | 22 +-
1 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap1/board-ams-delta.c
b/arch/arm/mach
On Monday 26 of December 2011 at 12:02:01, Mark Brown wrote:
On Sat, Dec 24, 2011 at 12:12:22AM +0100, Janusz Krzysztofik wrote:
+ case SND_SOC_BIAS_ON:
+ case SND_SOC_BIAS_PREPARE:
+ if (IS_ERR(cx20442-por.regulator)) {
+ err = PTR_ERR(cx20442
On Monday 26 of December 2011 at 12:02:01, Mark Brown wrote:
On Sat, Dec 24, 2011 at 12:12:22AM +0100, Janusz Krzysztofik wrote:
+ case SND_SOC_BIAS_ON:
+ case SND_SOC_BIAS_PREPARE:
+ if (IS_ERR(cx20442-por.regulator)) {
+ err = PTR_ERR(cx20442
On Monday 26 of December 2011 at 12:03:49, Mark Brown wrote:
On Sat, Dec 24, 2011 at 12:12:24AM +0100, Janusz Krzysztofik wrote:
+struct regulator_consumer_data {
+ struct mutex lock;
+ struct regulator *regulator;
+ bool enabled;
+};
+
+static int regulator_toggle(struct
On Monday 26 of December 2011 at 18:23:50, Mark Brown wrote:
On Mon, Dec 26, 2011 at 01:30:22PM +0100, Janusz Krzysztofik wrote:
Why's this code not been dropped and what is it for?
It is, and will be, used by another regulator consumer, the modem. The
device is controlled
conflicts, or trying to solve that sharing issue with a
custom piece of code, set up a fixed regulator device on top of that
GPIO pin and update both drivers to manipulate that regulator, not the
GPIO pin directly.
Janusz Krzysztofik (4):
ARM: OMAP1: ams-delta: set up regulator over modem reset
custom I/O with
GPIO.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
arch/arm/mach-omap1/Kconfig |2 +
arch/arm/mach-omap1/board-ams-delta.c | 103 +++--
2 files changed, 99 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap1
unused control_type member.
Created against linxu-3.2-rc6, tested on top of patch 1/4 ARM: OMAP1:
ams-delta: set up regulator over modem reset GPIO pin.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
sound/soc/codecs/cx20442.c | 58 ++-
1 files
correctly in coexistence with the modem.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
arch/arm/mach-omap1/board-ams-delta.c | 20 +++-
1 files changed, 15 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap1/board-ams-delta.c
b/arch/arm/mach-omap1/board-ams
-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
arch/arm/mach-omap1/board-ams-delta.c | 75 ++---
arch/arm/plat-omap/include/plat/board-ams-delta.h |1 -
sound/soc/omap/ams-delta.c| 34 -
3 files changed, 36 insertions(+), 74 deletions
On Wednesday 21 of December 2011 at 21:07:29, Tony Lindgren wrote:
* Janusz Krzysztofik jkrzy...@tis.icnet.pl [111221 11:20]:
On Wednesday 21 of December 2011 at 20:08:15, Tony Lindgren wrote:
* Janusz Krzysztofik jkrzy...@tis.icnet.pl [111220 13:23]:
In preparation to converting Amstrad
On Wednesday 21 of December 2011 at 20:12:12, Tony Lindgren wrote:
* Janusz Krzysztofik jkrzy...@tis.icnet.pl [111219 14:41]:
Don't use Amstrad Delta custom I/O functions for controlling the device,
use GPIO API instead.
While being at it, add missing gpio_free(AMS_DELTA_GPIO_PIN_NAND_RB
On Wednesday 21 of December 2011 at 20:08:15, Tony Lindgren wrote:
* Janusz Krzysztofik jkrzy...@tis.icnet.pl [111220 13:23]:
In preparation to converting Amstrad Delta on-board latches to
basic_mmio_gpio devices, registration of platform devices which depend
on latches and will require
On Wednesday 21 of December 2011 at 20:09:45, Tony Lindgren wrote:
* Janusz Krzysztofik jkrzy...@tis.icnet.pl [111220 13:39]:
Don't use Amstrad Delta custom I/O functions once GPIO interface is
available for the underlying hardware.
While requesting and initializing GPIO pins used, also
On Wednesday 21 of December 2011 at 19:33:44, Liam Girdwood wrote:
On Sun, 2011-12-11 at 21:12 +0100, Janusz Krzysztofik wrote:
Don't use Amstrad Delta custom I/O functions any longer, replace them
with GPIO. Old pin definitions, no longer used by the modem bits either,
can be dropped
On Tuesday 20 of December 2011 at 19:06:11, Tony Lindgren wrote:
* Janusz Krzysztofik jkrzy...@tis.icnet.pl [111219 14:57]:
Resending because of a typo in the Cc: list, sorry.
8--
In preparation to converting Amstrad Delta on-board latches to
basic_mmio_gpio
On Tuesday 20 of December 2011 at 21:40:46, Russell King - ARM Linux wrote:
On Tue, Dec 20, 2011 at 12:28:32AM +0100, Janusz Krzysztofik wrote:
diff --git a/drivers/input/serio/ams_delta_serio.c
b/drivers/input/serio/ams_delta_serio.c
index d4d08bd..56ffd7c 100644
--- a/drivers/input
will depend on their GPIO pins already requested from
the board late_init() function until updated to register their GPIO pins
themselves.
Created and tested against linux-3.2-rc6.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
Changes since the initial version of this patch:
* use
dependent devices.
Depends on patch 2/7 ARM: OMAP1: ams-delta: convert latches to
basic_mmio_gpio
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
Hi,
I'm submitting only this one refreshed on top of updated 1/7. All others
(2/7-6/7) don't require any refresh, can be rebased smoothly.
Thanks
or Acks.
Janusz
Janusz Krzysztofik (7):
ARM: OMAP1: ams-delta: register latch dependent devices later
ARM: OMAP1: ams-delta: convert latches to basic_mmio_gpio
ARM: OMAP1: ams-delta: supersede custom led device by leds-gpio
LED: drop leds-ams-delta driver
MTD: NAND: ams-delta: use GPIO
after converting selected ams-delta platform devices to
follow generic GPIO based device models.
Depends on patch 1/7, ARM: OMAP1: ams-delta: register latch dependent
devices later.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
Changes against initial version:
* refreshed on top
This driver is no longer needed after the Amstrad Delta on-board LED
devices have been converted to leds-gpio compatible.
Created against linux-3.2-rc6.
Requires patch 3/7 ARM: OMAP1: ams-delta: supersede custom led device
by leds-gpio for those LEDs to still work.
Signed-off-by: Janusz
Don't use Amstrad Delta custom I/O functions for controlling the device,
use GPIO API instead.
While being at it, add missing gpio_free(AMS_DELTA_GPIO_PIN_NAND_RB).
Depends on patch 2/7 ARM: OMAP1: ams-delta: convert latches to
basic_mmio_gpio
Signed-off-by: Janusz Krzysztofik jkrzy
Now that the Amstrad Delta on-board latches have been converted to GPIO
devices, use the generic driver to control on-board LEDs which hang off
those latches.
Depends on patch 2/7 ARM: OMAP1: ams-delta: convert latches to
basic_mmio_gpio
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
Don't use Amstrad Delta custom I/O functions any longer, use GPIO API
instead.
Depends on patch 2/7 ARM: OMAP1: ams-delta: convert latches to
basic_mmio_gpio.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
Acked-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Tony Lindgren t...@atomide.com
latch2 dependent devices.
Depends on patch 2/7 ARM: OMAP1: ams-delta: convert latches to
basic_mmio_gpio
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
Changes against initial version:
* was 9/10,
* rebased on top of v2 of patch 2/7, just in case,
* moved
the board late_init() function until updated to register their GPIO pins
themselves.
Thanks to Tony Lindgren t...@atomide.com who suggested this approach
instead of shifting up the gpio-generic driver initialization.
Created and tested against linux-3.2-rc6.
Signed-off-by: Janusz Krzysztofik jkrzy
On Tuesday 20 of December 2011 at 01:06:00, Tony Lindgren wrote:
* Janusz Krzysztofik jkrzy...@tis.icnet.pl [111219 14:41]:
Once ready, ams-delta specific device drivers currently calling custom
ams_delta_latch[12]_write() functions can be updated to call generic
gpio_set_value() instead
On Tuesday 20 of December 2011 at 02:04:46, Tony Lindgren wrote:
* Janusz Krzysztofik jkrzy...@tis.icnet.pl [111219 16:28]:
On Tuesday 20 of December 2011 at 01:06:00, Tony Lindgren wrote:
This part especially looks like it really should be just a regular
device driver under drivers
after all custom drivers are
converted or replaced.
Depends on patch 1/7, ARM: OMAP1: ams-delta: register latch dependent
devices later.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
Changes against initial version:
* refreshed on top of patch 1/7, which is the old 1/10 replacement
On Sunday 11 of December 2011 at 21:11:59, Janusz Krzysztofik wrote:
This will allow boards with custom memory mapped GPIO ports to set up
and use those port pins while initializing devices from arch init.
Please ignore this patch, I'm going to submit a replacement, based on an
alternative
On Tuesday 13 of December 2011 at 00:55:44, Tony Lindgren wrote:
* Janusz Krzysztofik jkrzy...@tis.icnet.pl [111212 15:13]:
On Tuesday 13 of December 2011 at 00:15:20, Tony Lindgren wrote:
Might be worth checking if some board specific __initcall helps here
too?
If I only knew
(adding Mark Brown and Liam Girdwood - regulator experts - to Cc:)
On Wednesday 14 of December 2011 at 19:21:49, Tony Lindgren wrote:
* Janusz Krzysztofik jkrzy...@tis.icnet.pl [111214 04:40]:
On Tuesday 13 of December 2011 at 00:55:44, Tony Lindgren wrote:
* Janusz Krzysztofik jkrzy
(adding Greg Kroah-Hartman and linux-ser...@vger.kernel.org to Cc:)
On Monday 12 of December 2011 at 19:04:56, Tony Lindgren wrote:
* Janusz Krzysztofik jkrzy...@tis.icnet.pl [111211 11:41]:
This will allow boards with custom memory mapped GPIO ports to set up
and use those port pins while
On Tuesday 13 of December 2011 at 00:15:20, Tony Lindgren wrote:
Might be worth checking if some board specific __initcall helps here
too?
If I only knew how I could insert a board specific __initcall between
two points from where the generic-gpio first, then the 8250 driver, are
called.
On Tuesday 13 of December 2011 at 00:55:44, Tony Lindgren wrote:
* Janusz Krzysztofik jkrzy...@tis.icnet.pl [111212 15:13]:
On Tuesday 13 of December 2011 at 00:15:20, Tony Lindgren wrote:
Might be worth checking if some board specific __initcall helps here
too?
If I only knew
be created, it could be designed as a generic GPIO
based driver, not a custom one.
Janusz Krzysztofik (10):
GPIO: gpio-generic: Move initialization up to postcore
ARM: OMAP1: ams-delta: convert latches to basic_mmio_gpio
ARM: OMAP1: ams-delta: supersede custom led device by leds-gpio
LED: drop
This will allow boards with custom memory mapped GPIO ports to set up
and use those port pins while initializing devices from arch init.
Created against linux-3.2-rc5.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
drivers/gpio/gpio-generic.c |2 +-
1 files changed, 1
selected ams-delta platform devices to follow generic GPIO
based device models.
Created against linux-3.2-rc5.
Requires patch 1/10 GPIO: gpio-generic: Move initialization up to
postcore to work correctly.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
arch/arm/mach-omap1/Kconfig
Now that the Amstrad Delta on-board latches have been converted to GPIO
devices, use the generic driver to control on-board LEDs which hang off
those latches.
Depends on patch 2/10 ARM: OMAP1: Convert Amstrad E3 latches to
basic_mmio_gpio.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
This is no longer needed after the Amstrad Delta on-board LED devices
have been converted to leds-gpio compatible.
Created against linux-3.2-rc5.
Requires patch 3/10 ARM: OMAP1: ams-delta: Supersede custom led device
by leds-gpio for those LEDs to still work.
Signed-off-by: Janusz Krzysztofik
Don't use Amstrad Delta custom I/O functions for controlling the device,
use GPIO API instead.
While being at it, add missing gpio_free(AMS_DELTA_GPIO_PIN_NAND_RB).
Depends on patch 2/10 ARM: OMAP1: Convert Amstrad E3 latches to
basic_mmio_gpio.
Signed-off-by: Janusz Krzysztofik jkrzy
with a power
management hook which toggles one of those new GPIO pins.
Depends on patch 2/10 ARM: OMAP1: Convert Amstrad E3 latches to
basic_mmio_gpio.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
arch/arm/mach-omap1/board-ams-delta.c | 44
1 files changed
Don't use Amstrad Delta custom I/O functions any longer, replace them
with GPIO. Old pin definitions, no longer used by the modem bits either,
can be dropped.
Depends on patch 2/10 ARM: OMAP1: Convert Amstrad E3 latches to
basic_mmio_gpio.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
Don't use Amstrad Delta custom I/O functions any longer, use GPIO API
instead.
Depends on patch 5/10 MTD: NAND: ams-delta: Use GPIO instead of custom
I/O.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
arch/arm/mach-omap1/board-ams-delta.c | 10 ---
arch/arm/plat
Don't use Amstrad Delta custom I/O functions once GPIO interface is
available for the underlying hardware.
Depends on patch 8/10 omapfb: lcd_ams_delta: Drive control lines over
GPIO.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
arch/arm/mach-omap1/board-ams-delta.c
Those are no longer required after all drivers which used them have been
converted to the GPIO interface.
Depends on patch 9/10 input: serio: ams-delta: Toggle keyboard power
over GPIO.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
arch/arm/mach-omap1/board-ams-delta.c
On Saturday 10 of December 2011 at 01:25:03, Russell King - ARM Linux wrote:
On Fri, Dec 09, 2011 at 11:00:01AM +0100, Janusz Krzysztofik wrote:
Those were BogoMIPS, ...
I realise that. But which is which - is 70.40 from recalibrate_delay
or is it 74.54? Your message is too vague
On Friday 09 of December 2011 at 09:42:45, Russell King - ARM Linux wrote:
On Tue, Nov 29, 2011 at 01:25:32AM +0100, Janusz Krzysztofik wrote:
However, the result of cpufreq_scale() differs from that of
(re)calibrate_delay() by ca. 6%, i.e., 70.40 vs. 74.54. Please advise
On Friday 09 of December 2011 at 11:00:01, Janusz Krzysztofik wrote:
On Friday 09 of December 2011 at 09:42:45, Russell King - ARM Linux wrote:
On Tue, Nov 29, 2011 at 01:25:32AM +0100, Janusz Krzysztofik wrote:
However, the result of cpufreq_scale() differs from that of
(re
1 - 100 of 434 matches
Mail list logo
