Pending patches

Pending patches

[Dirk Behme]

Hello,

find below a list of pending patches from last weeks.

Feel free to update, correct, extend etc.

Hth,

Dirk


List of pending patches for OMAP Linux.

Last modified: 2005/12/27

Pending patches (ready for inclusion):
======================================

1) Fix OMAP audio miscompile
http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005830.html

2) Fix miscompile if CONFIG_FB_OMAP_LCDC_INTERNAL=n
http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005831.html

3) Fix omap keypad
http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005833.html

4) Convert touchscreen to input_allocate_device
http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005837.html
(input_allocate_device & timer fix)

_or_ (timer fix only!)

OMAP touchscreen timer BUG
http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005899.html

5) Fix warning in pm.c
http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005838.html

6) USB clock changes from Juha
http://linux.omap.com/pipermail/linux-omap-open-source/2005-August/004818.html
(http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005846.html)
(http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/006027.html)

7) OSS Audio L/R Channel Interchanges fix
http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005890.html

8) omap1510 MPU interupt BUG
http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005894.html

9) LDM wakeup flags for OMAP keypad
http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005897.html

10) Add MMC password protection (lock/unlock) support
http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005911.html
http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005912.html
http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005913.html
http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005914.html
http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005915.html
http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005916.html

Note: Still in discussion with RMK?

11) MMC - CONFIG_HOTPLUG support
http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005963.html

Note: Still in discussion with RMK?

12) ALSA Audio L/R Channel Interchanges fix
http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005971.html

13) Disable DEBUG_LL in omap_h3_1710_defconfig
http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005997.html

14) I2C: Use struct platform_driver
http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/006025.html


Experimental & test (do not apply yet):
=======================================

1) omap24xx vout and dispc library
http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005932.html

2) omap24xx spi + touchscreen
http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005980.html

3) keypad: platform_data and 24xx support -exp
http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005889.html

4) omap24xx IrDA update
http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005992.html


Already applied (by Juha, nothing to do):
=========================================

1) Omapfb: panel enable/disable reordering
http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005844.html

2) H3 LCD clocking changes suggested by the driver
http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005898.html

3) fix watchdog
http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005969.html

Re: Pending patches

[Anderson.Briglia]

> Hello,

> find below a list of pending patches from last weeks.

> Feel free to update, correct, extend etc.

> Hth,

> Dirk

> List of pending patches for OMAP Linux.

> Last modified: 2005/12/27

> Pending patches (ready for inclusion):
> ======================================

> 11) MMC - CONFIG_HOTPLUG support
> http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005963.html

> Note: Still in discussion with RMK?

I guess it's ok this one. Please, see the lastest RMK e-mail about the patch:

http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/006024.html

BR,

Anderson Briglia

Re: Pending patches

[Anderson Lizardo]

On 12/27/05, Dirk Behme <dirk.behme@de.bosch.com> wrote:
> Hello,
>
> find below a list of pending patches from last weeks.
>
> Feel free to update, correct, extend etc.
> [...]
> 10) Add MMC password protection (lock/unlock) support

Hi,

These series of patches are not intended for inclusion on linux-omap
(they are platform independent). We have CC: ed the linux-omap list
because one of the patches is OMAP specific:

http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005916.html

But this patch is still in discussion, so don't apply it yet.

Regards,
--
Anderson Lizardo
Embedded Linux Lab - 10LE
Nokia Institute of Technology - INdT
Manaus - Brazil

Re: Pending patches

[Tony Lindgren]

* Dirk Behme <dirk.behme@de.bosch.com> [051227 01:56]:
> Hello,
> 
> find below a list of pending patches from last weeks.

Cool, this is a nice summary :)
 
> Feel free to update, correct, extend etc.

Anybody else know if pending patches?
 
> List of pending patches for OMAP Linux.
> 
> 6) USB clock changes from Juha
> http://linux.omap.com/pipermail/linux-omap-open-source/2005-August/004818.html
> (http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005846.html)
> (http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/006027.html)

No comments from Dave, so let's plan on pushing the USB clock patches.

Regards,

Tony 

Re: Pending patches mostly pushed, please check

[Tony Lindgren]

Hi all,

I've pushed bunch of patches listed. Please check the status of
your patches below.

Also reply to this thread if you know if a patch that you think
should be pushed and has not been pushed yet. 

* Dirk Behme <dirk.behme@de.bosch.com> [051227 01:56]:
> Hello,
> 
> find below a list of pending patches from last weeks.
> 
> Feel free to update, correct, extend etc.
> 
> Hth,
> 
> Dirk
> 
> 
> List of pending patches for OMAP Linux.
> 
> Last modified: 2005/12/27

Last modified: 2006/01/03
 
> Pending patches (ready for inclusion):
> ======================================
> 
> 1) Fix OMAP audio miscompile
> http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005830.html

Applied.


> 2) Fix miscompile if CONFIG_FB_OMAP_LCDC_INTERNAL=n
> http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005831.html

Applied.


> 3) Fix omap keypad
> http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005833.html

Applied.


> 4) Convert touchscreen to input_allocate_device
> http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005837.html
> (input_allocate_device & timer fix)
> 
> _or_ (timer fix only!)

Dirk, I've only pushed Todd's timer fix below like you suggested. Can you please
update your patch?


> OMAP touchscreen timer BUG
> http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005899.html

Applied.

 
> 5) Fix warning in pm.c
> http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005838.html

Applied.


> 6) USB clock changes from Juha
> http://linux.omap.com/pipermail/linux-omap-open-source/2005-August/004818.html
> (http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005846.html)
> (http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/006027.html)

Applied.


> 7) OSS Audio L/R Channel Interchanges fix
> http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005890.html

Applied. 

> 8) omap1510 MPU interupt BUG
> http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005894.html

Can't read this patch because of the bad formatting... Can you please repost?


> 9) LDM wakeup flags for OMAP keypad
> http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005897.html

Let's think about this one a bit more. Maybe we should have u32 device_wakeup in
pm.c, and then various drivers would mask it with OMAP_WAKEUP_KEYPAD etc?

Or maybe device_init_wakeup() should register a callback function in the driver,
and them pm.c just calls all registered wakeup callback functions? That would
move the enable/disable code to drivers.


> 10) Add MMC password protection (lock/unlock) support
> http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005911.html
> http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005912.html
> http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005913.html
> http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005914.html
> http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005915.html
> http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005916.html
> 
> Note: Still in discussion with RMK?

Not applied based on comments from Andersons.


> 11) MMC - CONFIG_HOTPLUG support
> http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005963.html
> 
> Note: Still in discussion with RMK?

Not applied based on comments from Andersons.

 
> 12) ALSA Audio L/R Channel Interchanges fix
> http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005971.html

Applied.

 
> 13) Disable DEBUG_LL in omap_h3_1710_defconfig
> http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005997.html

Applied.


> 14) I2C: Use struct platform_driver
> http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/006025.html

Applied.


15) Problem on mounting a jffs2 rootfs image
http://linux.omap.com/pipermail/linux-omap-open-source/2006-January/006064.html

Applied.


16) [PATCH] gpio expander debug cleanup 
http://linux.omap.com/pipermail/linux-omap-open-source/2006-January/006061.html

Applied.


> Experimental & test (do not apply yet):
> =======================================
> 
> 1) omap24xx vout and dispc library
> http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005932.html
> 
> 2) omap24xx spi + touchscreen
> http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005980.html
> 
> 3) keypad: platform_data and 24xx support -exp
> http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005889.html
> 
> 4) omap24xx IrDA update
> http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005992.html
> 
> 
> Already applied (by Juha, nothing to do):
> =========================================
> 
> 1) Omapfb: panel enable/disable reordering
> http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005844.html
> 
> 2) H3 LCD clocking changes suggested by the driver
> http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005898.html
> 
> 3) fix watchdog
> http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005969.html

Re: Pending patches mostly pushed, please check

[Ladislav Michl]

On Tue, Jan 03, 2006 at 11:13:56AM -0800, Tony Lindgren wrote:
> Hi all,
> 
> I've pushed bunch of patches listed. Please check the status of
> your patches below.
> 
> Also reply to this thread if you know if a patch that you think
> should be pushed and has not been pushed yet. 

Umm, here is one more :-)

Remove support for board Netstar. I hope it helped to sort out various
needs to drivers and now when nearly everything [1] was converted to
platform device there is no more need to bother you with updates to
board file :-). I'll maintain it as separate patch (using PTXdist).
Thanks for all the fish :-)

Best regards,
	ladis

[1] Oh, it seems USB host driver still contains those
    machine_is_omap_xxx. Will fix that later...

diff --git a/arch/arm/mach-omap1/Kconfig b/arch/arm/mach-omap1/Kconfig
index a8d2d9a..f17b4ac 100644
--- a/arch/arm/mach-omap1/Kconfig
+++ b/arch/arm/mach-omap1/Kconfig
@@ -69,12 +69,6 @@ config MACH_VOICEBLUE
 	  Support for Voiceblue GSM/VoIP gateway. Say Y here if you have
 	  such a board.
 
-config MACH_NETSTAR
-	bool "NetStar"
-	depends on ARCH_OMAP1 && ARCH_OMAP15XX
-	help
-	  Support for NetStar PBX. Say Y here if you have such a board.
-
 config MACH_OMAP_PALMTE
 	bool "Palm Tungsten E"
 	depends on ARCH_OMAP1 && ARCH_OMAP15XX
diff --git a/arch/arm/mach-omap1/Makefile b/arch/arm/mach-omap1/Makefile
index 856fedf..fe6598d 100644
--- a/arch/arm/mach-omap1/Makefile
+++ b/arch/arm/mach-omap1/Makefile
@@ -20,7 +20,6 @@ obj-$(CONFIG_MACH_OMAP_PERSEUS2)	+= boar
 obj-$(CONFIG_MACH_OMAP_OSK)		+= board-osk.o
 obj-$(CONFIG_MACH_OMAP_H3)		+= board-h3.o
 obj-$(CONFIG_MACH_VOICEBLUE)		+= board-voiceblue.o
-obj-$(CONFIG_MACH_NETSTAR)		+= board-netstar.o
 obj-$(CONFIG_MACH_OMAP_PALMTE)		+= board-palmte.o
 
 ifeq ($(CONFIG_ARCH_OMAP15XX),y)
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index cc31113..f4c4e8e 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -50,10 +50,10 @@ config MTD_NAND_SPIA
 	  If you had to ask, you don't have one. Say 'N'.
 
 config MTD_NAND_OMAP
-        tristate "NAND Flash device on OMAP H3/H2/P2 or NETSTAR boards"
-	depends on ARM && ARCH_OMAP1 && MTD_NAND && (MACH_OMAP_H2 || MACH_OMAP_H3 || MACH_NETSTAR || MACH_OMAP_PERSEUS2)
-        help
-          Support for NAND flash on Texas Instruments H3/H2/P2/NETSTAR platforms.
+	tristate "NAND Flash device on OMAP H3/H2/P2 boards"
+	depends on ARM && ARCH_OMAP1 && MTD_NAND && (MACH_OMAP_H2 || MACH_OMAP_H3 || MACH_OMAP_PERSEUS2)
+	help
+	  Support for NAND flash on Texas Instruments H3/H2/P2 platforms.
 
 config MTD_NAND_TOTO
 	tristate "NAND Flash device on TOTO board"
diff --git a/include/asm-arm/arch-omap/hardware.h b/include/asm-arm/arch-omap/hardware.h
index 5406b87..ecf5bae 100644
--- a/include/asm-arm/arch-omap/hardware.h
+++ b/include/asm-arm/arch-omap/hardware.h
@@ -314,10 +314,6 @@
 #include "board-voiceblue.h"
 #endif
 
-#ifdef CONFIG_MACH_NETSTAR
-#include "board-netstar.h"
-#endif
-
 #endif /* !__ASSEMBLER__ */
 
 #endif	/* __ASM_ARCH_OMAP_HARDWARE_H */
--- a/include/asm-arm/arch-omap/board-netstar.h	2006-01-03 21:23:00.000000000 +0100
+++ b/include/asm-arm/arch-omap/board-netstar.h	2006-01-03 15:00:45.568894352 +0100
@@ -1,19 +0,0 @@
-/*
- * Copyright (C) 2004 2N Telekomunikace, Ladislav Michl <michl@2n.cz>
- *
- * Hardware definitions for OMAP5910 based NetStar board.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-#ifndef __ASM_ARCH_NETSTAR_H
-#define __ASM_ARCH_NETSTAR_H
-
-#include <asm/arch/tc.h>
-
-#define OMAP_NAND_FLASH_START1		OMAP_CS1_PHYS + (1 << 23)
-#define OMAP_NAND_FLASH_START2		OMAP_CS1_PHYS + (2 << 23)
-
-#endif /*  __ASM_ARCH_NETSTAR_H */
--- a/arch/arm/mach-omap1/board-netstar.c	2006-01-03 21:22:43.000000000 +0100
+++ b/arch/arm/mach-omap1/board-netstar.c	2006-01-03 15:00:45.568894352 +0100
@@ -1,160 +0,0 @@
-/*
- * Modified from board-generic.c
- *
- * Copyright (C) 2004 2N Telekomunikace, Ladislav Michl <michl@2n.cz>
- *
- * Code for Netstar OMAP board.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-#include <linux/delay.h>
-#include <linux/platform_device.h>
-#include <linux/interrupt.h>
-#include <linux/init.h>
-#include <linux/kernel.h>
-#include <linux/notifier.h>
-#include <linux/reboot.h>
-
-#include <asm/hardware.h>
-#include <asm/mach-types.h>
-#include <asm/mach/arch.h>
-#include <asm/mach/map.h>
-
-#include <asm/arch/gpio.h>
-#include <asm/arch/mux.h>
-#include <asm/arch/usb.h>
-#include <asm/arch/common.h>
-
-extern void __init omap_init_time(void);
-extern int omap_gpio_init(void);
-
-static struct resource netstar_smc91x_resources[] = {
-	[0] = {
-		.start	= OMAP_CS1_PHYS + 0x300,
-		.end	= OMAP_CS1_PHYS + 0x300 + 16,
-		.flags	= IORESOURCE_MEM,
-	},
-	[1] = {
-		.start	= OMAP_GPIO_IRQ(8),
-		.end	= OMAP_GPIO_IRQ(8),
-		.flags	= IORESOURCE_IRQ,
-	},
-};
-
-static struct platform_device netstar_smc91x_device = {
-	.name		= "smc91x",
-	.id		= 0,
-	.num_resources	= ARRAY_SIZE(netstar_smc91x_resources),
-	.resource	= netstar_smc91x_resources,
-};
-
-static struct platform_device *netstar_devices[] __initdata = {
-	&netstar_smc91x_device,
-};
-
-static struct omap_uart_config netstar_uart_config __initdata = {
-	.enabled_uarts = ((1 << 0) | (1 << 1) | (1 << 2)),
-};
-
-static struct omap_board_config_kernel netstar_config[] = {
-	{ OMAP_TAG_UART,	&netstar_uart_config },
-};
-
-static void __init netstar_init_irq(void)
-{
-	omap_init_irq();
-	omap_gpio_init();
-}
-
-static void __init netstar_init(void)
-{
-	/* green LED */
-	omap_request_gpio(4);
-	omap_set_gpio_direction(4, 0);
-	/* smc91x reset */
-	omap_request_gpio(7);
-	omap_set_gpio_direction(7, 0);
-	omap_set_gpio_dataout(7, 1);
-	udelay(2);	/* wait at least 100ns */
-	omap_set_gpio_dataout(7, 0);
-	mdelay(50);	/* 50ms until PHY ready */
-	/* smc91x interrupt pin */
-	omap_request_gpio(8);
-
-	omap_request_gpio(12);
-	omap_request_gpio(13);
-	omap_request_gpio(14);
-	omap_request_gpio(15);
-	set_irq_type(OMAP_GPIO_IRQ(12), IRQT_FALLING);
-	set_irq_type(OMAP_GPIO_IRQ(13), IRQT_FALLING);
-	set_irq_type(OMAP_GPIO_IRQ(14), IRQT_FALLING);
-	set_irq_type(OMAP_GPIO_IRQ(15), IRQT_FALLING);
-
-	platform_add_devices(netstar_devices, ARRAY_SIZE(netstar_devices));
-
-	/* Switch on green LED */
-	omap_set_gpio_dataout(4, 0);
-	/* Switch off red LED */
-	omap_writeb(0x00, OMAP_LPG1_PMR);	/* Disable clock */
-	omap_writeb(0x80, OMAP_LPG1_LCR);
-
-	omap_board_config = netstar_config;
-	omap_board_config_size = ARRAY_SIZE(netstar_config);
-	omap_serial_init();
-}
-
-static void __init netstar_map_io(void)
-{
-	omap_map_common_io();
-}
-
-#define MACHINE_PANICED		1
-#define MACHINE_REBOOTING	2
-#define MACHINE_REBOOT		4
-static unsigned long machine_state;
-
-static int panic_event(struct notifier_block *this, unsigned long event,
-	 void *ptr)
-{
-	if (test_and_set_bit(MACHINE_PANICED, &machine_state))
-		return NOTIFY_DONE;
-
-	/* Switch off green LED */
-	omap_set_gpio_dataout(4, 1);
-	/* Flash red LED */
-	omap_writeb(0x78, OMAP_LPG1_LCR);
-	omap_writeb(0x01, OMAP_LPG1_PMR);	/* Enable clock */
-
-	return NOTIFY_DONE;
-}
-
-static struct notifier_block panic_block = {
-	.notifier_call	= panic_event,
-};
-
-static int __init netstar_late_init(void)
-{
-	/* TODO: Setup front panel switch here */
-
-	/* Setup panic notifier */
-	notifier_chain_register(&panic_notifier_list, &panic_block);
-
-	return 0;
-}
-
-postcore_initcall(netstar_late_init);
-
-MACHINE_START(NETSTAR, "NetStar OMAP5910")
-	/* Maintainer: Ladislav Michl <michl@2n.cz> */
-	.phys_ram	= 0x10000000,
-	.phys_io	= 0xfff00000,
-	.io_pg_offst	= ((0xfef00000) >> 18) & 0xfffc,
-	.boot_params	= 0x10000100,
-	.map_io		= netstar_map_io,
-	.init_irq	= netstar_init_irq,
-	.init_machine	= netstar_init,
-	.timer		= &omap_timer,
-MACHINE_END

Re: Pending patches mostly pushed, please check

[Tony Lindgren]

* Ladislav Michl <ladis@linux-mips.org> [060103 12:41]:
> On Tue, Jan 03, 2006 at 11:13:56AM -0800, Tony Lindgren wrote:
> > Hi all,
> > 
> > I've pushed bunch of patches listed. Please check the status of
> > your patches below.
> > 
> > Also reply to this thread if you know if a patch that you think
> > should be pushed and has not been pushed yet. 
> 
> Umm, here is one more :-)
> 
> Remove support for board Netstar. I hope it helped to sort out various
> needs to drivers and now when nearly everything [1] was converted to
> platform device there is no more need to bother you with updates to
> board file :-). I'll maintain it as separate patch (using PTXdist).
> Thanks for all the fish :-)

OK, so long :) Pushing today.
 
> Best regards,
> 	ladis
> 
> [1] Oh, it seems USB host driver still contains those
>     machine_is_omap_xxx. Will fix that later...

OK

Tony

Re: Pending patches mostly pushed, please check

[Todd Poynor]

On Tue, Jan 03, 2006 at 11:13:56AM -0800, Tony Lindgren wrote:
> 
> Also reply to this thread if you know if a patch that you think
> should be pushed and has not been pushed yet. 

Here's one that probably should go in, although del_mtd_partitions +
mtdblock is known broken
(http://lists.infradead.org/pipermail/linux-mtd/2004-November/011007.html).

---------- snip

OMAP MTD NOR mapping driver remove partitions created from platform data.

Signed-off-by: Todd Poynor <tpoynor@mvista.com>

---
commit 54131af1a43d5ddabfd5b96fd74e51de86943894
tree 94686025ea41abb2ecd102e3bb15f93b3e77f09f
parent 91b3e09b5720c0ed00d059a3b95cdf3a4c1a18fb
author Todd Poynor <tpoynor@mvista.com> Tue, 03 Jan 2006 14:31:59 -0800
committer Todd Poynor <tpoynor@mvista.com> Tue, 03 Jan 2006 14:31:59 -0800

 drivers/mtd/maps/omap_nor.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/mtd/maps/omap_nor.c b/drivers/mtd/maps/omap_nor.c
index a6e705f..6614e97 100644
--- a/drivers/mtd/maps/omap_nor.c
+++ b/drivers/mtd/maps/omap_nor.c
@@ -137,11 +137,12 @@ out_free_info:
 static int __devexit omapflash_remove(struct platform_device *pdev)
 {
 	struct omapflash_info *info = platform_get_drvdata(pdev);
+	struct flash_platform_data *pdata = pdev->dev.platform_data;
 
 	platform_set_drvdata(pdev, NULL);
 
 	if (info) {
-		if (info->parts) {
+		if (info->parts || (pdata && pdata->parts)) {
 			del_mtd_partitions(info->mtd);
 			kfree(info->parts);
 		} else

Re: Pending patches mostly pushed, please check

[Tony Lindgren]

* Todd Poynor <tpoynor@mvista.com> [060103 14:36]:
> On Tue, Jan 03, 2006 at 11:13:56AM -0800, Tony Lindgren wrote:
> > 
> > Also reply to this thread if you know if a patch that you think
> > should be pushed and has not been pushed yet. 
> 
> Here's one that probably should go in, although del_mtd_partitions +
> mtdblock is known broken
> (http://lists.infradead.org/pipermail/linux-mtd/2004-November/011007.html).
> 
> ---------- snip
> 
> OMAP MTD NOR mapping driver remove partitions created from platform data.
> 
> Signed-off-by: Todd Poynor <tpoynor@mvista.com>
> 
> ---
> commit 54131af1a43d5ddabfd5b96fd74e51de86943894
> tree 94686025ea41abb2ecd102e3bb15f93b3e77f09f
> parent 91b3e09b5720c0ed00d059a3b95cdf3a4c1a18fb
> author Todd Poynor <tpoynor@mvista.com> Tue, 03 Jan 2006 14:31:59 -0800
> committer Todd Poynor <tpoynor@mvista.com> Tue, 03 Jan 2006 14:31:59 -0800
> 
>  drivers/mtd/maps/omap_nor.c |    3 ++-
>  1 files changed, 2 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/mtd/maps/omap_nor.c b/drivers/mtd/maps/omap_nor.c
> index a6e705f..6614e97 100644
> --- a/drivers/mtd/maps/omap_nor.c
> +++ b/drivers/mtd/maps/omap_nor.c
> @@ -137,11 +137,12 @@ out_free_info:
>  static int __devexit omapflash_remove(struct platform_device *pdev)
>  {
>  	struct omapflash_info *info = platform_get_drvdata(pdev);
> +	struct flash_platform_data *pdata = pdev->dev.platform_data;
>  
>  	platform_set_drvdata(pdev, NULL);
>  
>  	if (info) {
> -		if (info->parts) {
> +		if (info->parts || (pdata && pdata->parts)) {
>  			del_mtd_partitions(info->mtd);
>  			kfree(info->parts);
>  		} else
> 

Just pushed this one.

Tony

Re: Pending patches mostly pushed, please check

[Todd Poynor]

Tony Lindgren wrote:

>> 9) LDM wakeup flags for OMAP keypad
>> http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005897.html
> 
> Let's think about this one a bit more. Maybe we should have u32 device_wakeup in
> pm.c, and then various drivers would mask it with OMAP_WAKEUP_KEYPAD etc?
> 
> Or maybe device_init_wakeup() should register a callback function in the driver,
> and them pm.c just calls all registered wakeup callback functions? That would
> move the enable/disable code to drivers.

Agreed, I should have labeled this patch as at an RFC stage.  It's the 
first attempt I'm aware of to apply the wakeup flags stuff begun for 
PCI/USB to an embedded SoC, and was intended to start a discussion on 
the above sorts of issues, which should also occur on 
linux-pm@lists.osdl.org (and other embedded-oriented wakeup patches are 
being floated there as well).  It would be nice to move the wakeup 
enable code to drivers, but with the per-core keypad IRQ assignments, 
the need to enable level-2 IRQs, etc., not sure if a platform core file 
ends up being more suitable, don't have a strong opinion myself so far.

On a related note, if anybody knows how to tell what source woke up an 
OMAP from deep/big sleep I'd appreciate hearing about it.  I haven't 
found a register devoted to it, and keypad wakeup on my H3 seemed to 
show a pending Level-2 interrupt in the level-1 ITR, but the level-2 
ITRs all read zero (reading prior to enabling interrupts upon deep sleep 
resume).  Thanks,


-- 
Todd

Re: Pending patches mostly pushed, please check

[Tony Lindgren]

* Todd Poynor <tpoynor@mvista.com> [060103 16:26]:
> Tony Lindgren wrote:
> 
> >>9) LDM wakeup flags for OMAP keypad
> >>http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005897.html
> >
> >Let's think about this one a bit more. Maybe we should have u32 
> >device_wakeup in
> >pm.c, and then various drivers would mask it with OMAP_WAKEUP_KEYPAD etc?
> >
> >Or maybe device_init_wakeup() should register a callback function in the 
> >driver,
> >and them pm.c just calls all registered wakeup callback functions? That 
> >would
> >move the enable/disable code to drivers.
> 
> Agreed, I should have labeled this patch as at an RFC stage.  It's the 
> first attempt I'm aware of to apply the wakeup flags stuff begun for 
> PCI/USB to an embedded SoC, and was intended to start a discussion on 
> the above sorts of issues, which should also occur on 
> linux-pm@lists.osdl.org (and other embedded-oriented wakeup patches are 
> being floated there as well).  It would be nice to move the wakeup 
> enable code to drivers, but with the per-core keypad IRQ assignments, 
> the need to enable level-2 IRQs, etc., not sure if a platform core file 
> ends up being more suitable, don't have a strong opinion myself so far.

Yeah, let's discuss this on linux-pm.
 
> On a related note, if anybody knows how to tell what source woke up an 
> OMAP from deep/big sleep I'd appreciate hearing about it.  I haven't 
> found a register devoted to it, and keypad wakeup on my H3 seemed to 
> show a pending Level-2 interrupt in the level-1 ITR, but the level-2 
> ITRs all read zero (reading prior to enabling interrupts upon deep sleep 
> resume).  Thanks,

I'd like to know too if there is such a register!

Tony

Re: Pending patches mostly pushed, please check

[Komal Shah]

--- Tony Lindgren <tony@atomide.com> wrote:

> > Experimental & test (do not apply yet):
> > =======================================
> > 
> > 1) omap24xx vout and dispc library
> >
>
http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005932.html

Imre, 
Could you please reply on this? If needed I can re-work on integration
as per your suggestions.


> > 
> > 3) keypad: platform_data and 24xx support -exp
> >
>
>http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005889.html

> > 
> > 4) omap24xx IrDA update
> >
>
>http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005992.html

Please comment on keypad and irda patches. If acceptable then I can
regenerate them against latest git tree. Thanx.

IrDA patch is now working on H4 without crash.

Patches sitting under my ompt-git tree:

o h4 nand patch (not able to test...as got stuck with x-loader an d
u-boot flashing). If someone wants to experiment, I can release.

o OMAP2 spi master controller driver + tsc2101 protocol driver
as per david's framework. I have written good amount of the code for
this, but not yet working successfully. If someone wants to have fun
then I can submit to them.

---Komal Shah
http://komalshah.blogspot.com/


		
__________________________________________ 
Yahoo! DSL – Something to write home about. 
Just $16.99/mo. or less. 
dsl.yahoo.com 

[PATCH] Convert touchscreen to input_allocate_device

[Dirk Behme]

[-- Attachment #1: Type: text/plain, Size: 397 bytes --]

Tony Lindgren wrote:
> Dirk, I've only pushed Todd's timer fix below like you suggested. Can you please
> update your patch?

ARM: OMAP: Convert touchscreen to input_allocate_device() to remove:

input: device omap_ts is statically allocated, will not register
Please convert to input_allocate_device() or contact dtor_core@ameritech.net

Signed-off-by: Dirk Behme <dirk.behme_at_de.bosch.com>




[-- Attachment #2: touchscreen_input_allocate_device.patch --]
[-- Type: text/plain, Size: 3403 bytes --]

--- ./drivers/input/touchscreen/omap/omap_ts.c_orig	2006-01-06 16:43:40.000000000 +0100
+++ ./drivers/input/touchscreen/omap/omap_ts.c	2006-01-06 18:48:39.754015208 +0100
@@ -65,10 +65,10 @@ static int omap_ts_read(void)
 
 	ts_omap.dev->read(data);
 
-	input_report_abs(&(ts_omap.inputdevice), ABS_X, data[0]);
-	input_report_abs(&(ts_omap.inputdevice), ABS_Y, data[1]);
-	input_report_abs(&(ts_omap.inputdevice), ABS_PRESSURE, data[2]);
-	input_sync(&(ts_omap.inputdevice));
+	input_report_abs(ts_omap.inputdevice, ABS_X, data[0]);
+	input_report_abs(ts_omap.inputdevice, ABS_Y, data[1]);
+	input_report_abs(ts_omap.inputdevice, ABS_PRESSURE, data[2]);
+	input_sync(ts_omap.inputdevice);
 
 	DEBUG_TS("omap_ts_read: read x=%d,y=%d,p=%d\n", data[0], data[1],
 		 data[2]);
@@ -85,7 +85,7 @@ static void omap_ts_timer(unsigned long 
 	if (!ts_omap.dev->penup()) {
 		if (!ts_omap.touched) {
 			DEBUG_TS("omap_ts_timer: pen down\n");
-			input_report_key(&(ts_omap.inputdevice), BTN_TOUCH, 1);
+			input_report_key(ts_omap.inputdevice, BTN_TOUCH, 1);
 		}
 		ts_omap.touched = 1;
 		omap_ts_read();
@@ -95,12 +95,12 @@ static void omap_ts_timer(unsigned long 
 		if (ts_omap.touched) {
 			DEBUG_TS("omap_ts_timer: pen up\n");
 			ts_omap.touched = 0;
-			input_report_abs(&(ts_omap.inputdevice), ABS_X, 0);
-			input_report_abs(&(ts_omap.inputdevice), ABS_Y, 0);
-			input_report_abs(&(ts_omap.inputdevice), ABS_PRESSURE,
+			input_report_abs(ts_omap.inputdevice, ABS_X, 0);
+			input_report_abs(ts_omap.inputdevice, ABS_Y, 0);
+			input_report_abs(ts_omap.inputdevice, ABS_PRESSURE,
 					 0);
-			input_sync(&(ts_omap.inputdevice));
-			input_report_key(&(ts_omap.inputdevice), BTN_TOUCH, 0);
+			input_sync(ts_omap.inputdevice);
+			input_report_key(ts_omap.inputdevice, BTN_TOUCH, 0);
 		}
 		if (!ts_omap.irq_enabled) {
 			ts_omap.irq_enabled = 1;
@@ -167,14 +167,14 @@ static int __init omap_ts_probe(struct p
 		return -EINVAL;
 	}
 
-	init_input_dev(&(ts_omap.inputdevice));
-	ts_omap.inputdevice.name = OMAP_TS_NAME;
-	ts_omap.inputdevice.dev = &pdev->dev;
-	ts_omap.inputdevice.evbit[0] = BIT(EV_KEY) | BIT(EV_ABS);
-	ts_omap.inputdevice.keybit[LONG(BTN_TOUCH)] |= BIT(BTN_TOUCH);
-	ts_omap.inputdevice.absbit[0] =
+	ts_omap.inputdevice = input_allocate_device();
+	ts_omap.inputdevice->name = OMAP_TS_NAME;
+	ts_omap.inputdevice->dev = &pdev->dev;
+	ts_omap.inputdevice->evbit[0] = BIT(EV_KEY) | BIT(EV_ABS);
+	ts_omap.inputdevice->keybit[LONG(BTN_TOUCH)] |= BIT(BTN_TOUCH);
+	ts_omap.inputdevice->absbit[0] =
 	    BIT(ABS_X) | BIT(ABS_Y) | BIT(ABS_PRESSURE);
-	input_register_device(&(ts_omap.inputdevice));
+	input_register_device(ts_omap.inputdevice);
 
 	ts_omap.dev->enable();
 
@@ -186,7 +186,7 @@ static int __init omap_ts_probe(struct p
 static int omap_ts_remove(struct platform_device *pdev)
 {
 	ts_omap.dev->disable();
-	input_unregister_device(&ts_omap.inputdevice);
+	input_unregister_device(ts_omap.inputdevice);
 	if (ts_omap.irq != -1)
 		free_irq(ts_omap.irq, &ts_omap);
 
--- ./drivers/input/touchscreen/omap/omap_ts.h_orig	2006-01-06 16:43:40.000000000 +0100
+++ ./drivers/input/touchscreen/omap/omap_ts.h	2006-01-06 18:48:39.756014904 +0100
@@ -42,7 +42,7 @@ struct ts_device {
 };
 
 struct omap_ts_t{
-	struct input_dev inputdevice;
+	struct input_dev * inputdevice;
 	struct timer_list ts_timer;      // Timer for triggering acquisitions
 	int touched;
 	int irq;


[-- Attachment #3: Type: text/plain, Size: 0 bytes --]

Re: [PATCH] Convert touchscreen to input_allocate_device

[Tony Lindgren]

* Dirk Behme <dirk.behme@de.bosch.com> [060106 11:36]:
> Tony Lindgren wrote:
> >Dirk, I've only pushed Todd's timer fix below like you suggested. Can you 
> >please
> >update your patch?
> 
> ARM: OMAP: Convert touchscreen to input_allocate_device() to remove:
> 
> input: device omap_ts is statically allocated, will not register
> Please convert to input_allocate_device() or contact dtor_core@ameritech.net

Pushing this one today, thanks.

Tony

[PATCH] Re: Pending patches mostly pushed, please check

[Dirk Behme]

[-- Attachment #1: Type: text/plain, Size: 392 bytes --]

Hi Tony,

Tony Lindgren wrote:

>>12) ALSA Audio L/R Channel Interchanges fix
>>http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005971.html
>  
> Applied.

Can you check if this is really applied? Using most recent git I can
still apply it ;-)

There were two similiar patches: One for OSS (is applied, number 7 of
the list) and this one for ALSA.

Best regards

Dirk




[-- Attachment #2: audio_alsa_LR.patch --]
[-- Type: text/plain, Size: 3414 bytes --]

--- ./sound/arm/omap-aic23.c_orig	2005-12-02 16:57:32.000000000 +0100
+++ ./sound/arm/omap-aic23.c	2005-12-18 18:17:51.360077016 +0100
@@ -34,6 +34,8 @@
  *
  * 2005-07-29   INdT Kernel Team - Alsa driver for omap osk. Creation of new 
  *                                 file omap-aic23.c
+ *
+ * 2005-12-18   Dirk Behme      - Added L/R Channel Interchange fix as proposed by Ajaya Babu
  */
 
 #include <linux/config.h>
@@ -156,6 +158,20 @@ static snd_pcm_hw_constraint_list_t hw_c
 	.mask = 0,
 };
 
+/*
+ * HW interface start and stop helper functions
+ */
+static int audio_ifc_start(void)
+{
+	omap_mcbsp_start(AUDIO_MCBSP); 
+	return 0;
+}
+
+static int audio_ifc_stop(void)
+{
+	omap_mcbsp_stop(AUDIO_MCBSP);
+	return 0;
+}
 
 /*
  * Codec/mcbsp init and configuration section
@@ -243,12 +259,20 @@ static void omap_aic23_audio_init(struct
 	    SNDRV_PCM_STREAM_PLAYBACK;
 	omap_aic23->s[SNDRV_PCM_STREAM_PLAYBACK].dma_dev =
 	    OMAP_DMA_MCBSP1_TX;
+	omap_aic23->s[SNDRV_PCM_STREAM_PLAYBACK].hw_start =
+	    audio_ifc_start;
+	omap_aic23->s[SNDRV_PCM_STREAM_PLAYBACK].hw_stop =
+	    audio_ifc_stop;
 
 	omap_aic23->s[SNDRV_PCM_STREAM_CAPTURE].id = "Alsa AIC23 in";
 	omap_aic23->s[SNDRV_PCM_STREAM_CAPTURE].stream_id =
 	    SNDRV_PCM_STREAM_CAPTURE;
 	omap_aic23->s[SNDRV_PCM_STREAM_CAPTURE].dma_dev =
 	    OMAP_DMA_MCBSP1_RX;
+	omap_aic23->s[SNDRV_PCM_STREAM_CAPTURE].hw_start =
+	    audio_ifc_start;
+	omap_aic23->s[SNDRV_PCM_STREAM_CAPTURE].hw_stop =
+	    audio_ifc_stop;
 
 	/* configuring the McBSP */
 	omap_mcbsp_request(AUDIO_MCBSP);
--- ./sound/arm/omap-aic23.h_orig	2005-11-20 17:38:56.000000000 +0100
+++ ./sound/arm/omap-aic23.h	2005-12-18 18:17:51.362076712 +0100
@@ -33,7 +33,8 @@
  *  2005/07/25 INdT-10LE Kernel Team - 	Alsa driver for omap osk,
  *  					original version based in sa1100 driver
  *  					and omap oss driver.
- *  
+ *
+ *  2005-12-18   Dirk Behme      - Added L/R Channel Interchange fix as proposed by Ajaya Babu
  */
 
 #ifndef __OMAP_AIC23_H
@@ -85,6 +86,8 @@ struct audio_stream {
 	snd_pcm_substream_t *stream;	/* the pcm stream */
 	unsigned linked:1;	/* dma channels linked */
 	int offset;		/* store start position of the last period in the alsa buffer */
+        int (*hw_start)(void);  /* interface to start HW interface, e.g. McBSP */
+        int (*hw_stop)(void);   /* interface to stop HW interface, e.g. McBSP */
 };
 
 /*
--- ./sound/arm/omap-alsa-dma.c_orig	2005-11-20 17:38:56.000000000 +0100
+++ ./sound/arm/omap-alsa-dma.c	2005-12-18 18:17:51.365076256 +0100
@@ -34,7 +34,9 @@
  * 2005-07-19	INdT Kernel Team - Alsa port. Creation of new file omap-alsa-dma.c based in
  * 				   omap-audio-dma-intfc.c oss file. Support for aic23 codec.
  * 				   Removal of buffer handling (Alsa does that), modifications
- * 				   in dma handling and port to alsa structures. 
+ * 				   in dma handling and port to alsa structures.
+ *
+ * 2005-12-18   Dirk Behme      - Added L/R Channel Interchange fix as proposed by Ajaya Babu
  */
 
 #include <linux/config.h>
@@ -356,8 +358,10 @@ static int audio_start_dma_chain(struct 
 	int channel = s->lch[s->dma_q_head];
 	FN_IN;
 	if (!s->started) {
+	        s->hw_stop();            /* stops McBSP Interface */ 
 		omap_start_dma(channel);
 		s->started = 1;
+		s->hw_start();           /* start McBSP interface */ 
 	}
 	/* else the dma itself will progress forward with out our help */
 	FN_OUT(0);




[-- Attachment #3: Type: text/plain, Size: 0 bytes --]

Re: [PATCH] Re: Pending patches mostly pushed, please check

[Tony Lindgren]

* Dirk Behme <dirk.behme@de.bosch.com> [060106 11:37]:
> Hi Tony,
> 
> Tony Lindgren wrote:
> 
> >>12) ALSA Audio L/R Channel Interchanges fix
> >>http://linux.omap.com/pipermail/linux-omap-open-source/2005-December/005971.html
> > 
> >Applied.
> 
> Can you check if this is really applied? Using most recent git I can
> still apply it ;-)
> 
> There were two similiar patches: One for OSS (is applied, number 7 of
> the list) and this one for ALSA.

Thanks for checking, I had indeed missed this one.

Tony

pending patches

[Vadim Pasternak]

Hi Pavel,

I have two pending patches:
https://patches.linaro.org/patch/432324/ from 2021-05-07
https://patches.linaro.org/patch/403538/ from 2021-03-16, which has been re-sent.

Could these patches be accepted?

Thanks,
Vadim.

Re: pending patches

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 713 bytes --]

Hi!

> I have two pending patches:
> https://patches.linaro.org/patch/432324/ from 2021-05-07

I don't understand this one. Are these normal single-color LEDs, or is
it some kind of weird red/orange/amber/green combination exposed as
single LED?

> https://patches.linaro.org/patch/403538/ from 2021-03-16, which has been re-sent.

In this case, I don't think i2c bus number is suitable way to identify
add-on card. Having some way of identifying add-on cards makes sense
(as we'll probably have other vendors having "fault" or "activity"
light on their cards), but those boards will not neccessarily have i2c
on them.

Best regards,
								Pavel
-- 
http://www.livejournal.com/~pavelmachek

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

RE: pending patches

[Vadim Pasternak]

> -----Original Message-----
> From: Pavel Machek <pavel@ucw.cz>
> Sent: Friday, August 20, 2021 11:07 AM
> To: Vadim Pasternak <vadimp@nvidia.com>
> Cc: linux-leds@vger.kernel.org
> Subject: Re: pending patches
> 
> Hi!
> 
> > I have two pending patches:
> > https://patches.linaro.org/patch/432324/ from 2021-05-07
> 
> I don't understand this one. Are these normal single-color LEDs, or is it some
> kind of weird red/orange/amber/green combination exposed as single LED?

This is not single-color LED. LED is controlled by programmable device, color is
set by writing relevant bit mask combination to the related LED register.

> 
> > https://patches.linaro.org/patch/403538/ from 2021-03-16, which has been
> re-sent.
> 
> In this case, I don't think i2c bus number is suitable way to identify add-on
> card. Having some way of identifying add-on cards makes sense (as we'll
> probably have other vendors having "fault" or "activity"
> light on their cards), but those boards will not neccessarily have i2c on them.

Line card always has I2C connection, LED color is controlled through a programmable
device, which is always I2C device. So, this is I2C and bus number identifies topology.

Pavel,
I have those patches pending very long time. Could you, please, help to get them
accepted?

Thanks,
Vadim.


> 
> Best regards,
> 								Pavel
> --
> http://www.livejournal.com/~pavelmachek

Re: pending patches

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1541 bytes --]

Hi!

> > > I have two pending patches:
> > > https://patches.linaro.org/patch/432324/ from 2021-05-07
> > 
> > I don't understand this one. Are these normal single-color LEDs, or is it some
> > kind of weird red/orange/amber/green combination exposed as single LED?
> 
> This is not single-color LED. LED is controlled by programmable device, color is
> set by writing relevant bit mask combination to the related LED register.

Not a single-color LED yet using single-color API, and now you are
introducing additional hacks on the top of it. Sorry, no.

> > > https://patches.linaro.org/patch/403538/ from 2021-03-16, which has been
> > re-sent.
> > 
> > In this case, I don't think i2c bus number is suitable way to identify add-on
> > card. Having some way of identifying add-on cards makes sense (as we'll
> > probably have other vendors having "fault" or "activity"
> > light on their cards), but those boards will not neccessarily have i2c on them.
> 
> Line card always has I2C connection, LED color is controlled through a programmable
> device, which is always I2C device. So, this is I2C and bus number identifies topology.

I see it works for your hardware. I don't believe it works for other
vendors having "activity" LED on their card, and I'd like to see
consistent naming across vendors.

> Pavel,
> I have those patches pending very long time. Could you, please, help to get them
> accepted?

Not really, sorry.

Best regards,
									Pavel
-- 
http://www.livejournal.com/~pavelmachek

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

RE: pending patches

[Vadim Pasternak]

> -----Original Message-----
> From: Pavel Machek <pavel@ucw.cz>
> Sent: Sunday, September 12, 2021 10:11 AM
> To: Vadim Pasternak <vadimp@nvidia.com>
> Cc: linux-leds@vger.kernel.org
> Subject: Re: pending patches
> 
> Hi!
> 
> > > > I have two pending patches:
> > > > https://patches.linaro.org/patch/432324/ from 2021-05-07
> > >
> > > I don't understand this one. Are these normal single-color LEDs, or
> > > is it some kind of weird red/orange/amber/green combination exposed
> as single LED?
> >
> > This is not single-color LED. LED is controlled by programmable
> > device, color is set by writing relevant bit mask combination to the related
> LED register.
> 
> Not a single-color LED yet using single-color API, and now you are introducing
> additional hacks on the top of it. Sorry, no.

Could you explain your point, please?
Where is the hack? API is used on top of specific hardware by setting bitmask, while
generic API is used.

> 
> > > > https://patches.linaro.org/patch/403538/ from 2021-03-16, which
> > > > has been
> > > re-sent.
> > >
> > > In this case, I don't think i2c bus number is suitable way to
> > > identify add-on card. Having some way of identifying add-on cards
> > > makes sense (as we'll probably have other vendors having "fault" or
> "activity"
> > > light on their cards), but those boards will not neccessarily have i2c on
> them.
> >
> > Line card always has I2C connection, LED color is controlled through a
> > programmable device, which is always I2C device. So, this is I2C and bus
> number identifies topology.
> 
> I see it works for your hardware. I don't believe it works for other vendors
> having "activity" LED on their card, and I'd like to see consistent naming
> across vendors.

Name is constructed like:
/sys/class/leds/<card type><bus>:status:green/
In same way it will work for other vendors. 

> 
> > Pavel,
> > I have those patches pending very long time. Could you, please, help
> > to get them accepted?
> 
> Not really, sorry.
> 
> Best regards,
> 									Pavel
> --
> http://www.livejournal.com/~pavelmachek

Pending patches

[Denys Dmytriyenko]

All,

Most of the patches submitted this week probably won't make it to 2016.02 
release, as the last RC was cut on Monday and we are trying to close it this 
week. So, I'll get back to pending patches as soon as release is out.

-- 
Denys

Pending patches

[Denys Dmytriyenko]

All,

I have not forgotten about the patches submitted last week. There are some 
critical issues I'm investigating right and will get to the patches as soon as 
possible. Thanks.

-- 
Denys

Pending patches

[Robert Jarzmik]

[-- Attachment #1: Type: text/plain, Size: 386 bytes --]

Hi Sascha,

I have 2 sent patches which were somehow ... lost.
They have been sent on January the 26th, with the following subjects:
 - [PATCH] arm/mach-pxa: add standard LCD panel GPIO settings
 - [PATCH] arm/mach-pxa: add CCCR bits definitions

These are targeted at next branch. Could you consider pulling them ?
I joined them in this mail to ease your search.

Cheers.

-- 
Robert


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-arm-mach-pxa-add-standard-LCD-panel-GPIO-settings.patch --]
[-- Type: text/x-diff, Size: 1630 bytes --]

From 2a3e758be559e34bffca8224b92e1d6f304ca5b8 Mon Sep 17 00:00:00 2001
From: Robert Jarzmik <robert.jarzmik@free.fr>
Date: Wed, 25 Jan 2012 10:12:28 +0100
Subject: [PATCH 1/2] arm/mach-pxa: add standard LCD panel GPIO settings

Add standard GPIO routings for LCD panels, taken from linux
kernel.

Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
---
 arch/arm/mach-pxa/include/mach/mfp-pxa27x.h |   32 +++++++++++++++++++++++++++
 1 files changed, 32 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-pxa/include/mach/mfp-pxa27x.h b/arch/arm/mach-pxa/include/mach/mfp-pxa27x.h
index 6543c05..f6a27a2 100644
--- a/arch/arm/mach-pxa/include/mach/mfp-pxa27x.h
+++ b/arch/arm/mach-pxa/include/mach/mfp-pxa27x.h
@@ -434,5 +434,37 @@
 #define GPIO112_nMSINS		MFP_CFG_IN(GPIO112, AF2)
 #define GPIO32_MSSCLK		MFP_CFG_OUT(GPIO32, AF1, DRIVE_LOW)
 
+/* commonly used pin configurations */
+#define GPIOxx_LCD_16BPP	\
+	GPIO58_LCD_LDD_0,	\
+	GPIO59_LCD_LDD_1,	\
+	GPIO60_LCD_LDD_2,	\
+	GPIO61_LCD_LDD_3,	\
+	GPIO62_LCD_LDD_4,	\
+	GPIO63_LCD_LDD_5,	\
+	GPIO64_LCD_LDD_6,	\
+	GPIO65_LCD_LDD_7,	\
+	GPIO66_LCD_LDD_8,	\
+	GPIO67_LCD_LDD_9,	\
+	GPIO68_LCD_LDD_10,	\
+	GPIO69_LCD_LDD_11,	\
+	GPIO70_LCD_LDD_12,	\
+	GPIO71_LCD_LDD_13,	\
+	GPIO72_LCD_LDD_14,	\
+	GPIO73_LCD_LDD_15
+
+#define GPIOxx_LCD_DSTN_16BPP	\
+	GPIOxx_LCD_16BPP,	\
+	GPIO74_LCD_FCLK,	\
+	GPIO75_LCD_LCLK,	\
+	GPIO76_LCD_PCLK
+
+#define GPIOxx_LCD_TFT_16BPP	\
+	GPIOxx_LCD_16BPP,	\
+	GPIO74_LCD_FCLK,	\
+	GPIO75_LCD_LCLK,	\
+	GPIO76_LCD_PCLK,	\
+	GPIO77_LCD_BIAS
+
 extern int keypad_set_wake(unsigned int on);
 #endif /* __ASM_ARCH_MFP_PXA27X_H */
-- 
1.7.5.4


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: 0002-arm-mach-pxa-add-CCCR-bits-definitions.patch --]
[-- Type: text/x-diff, Size: 1459 bytes --]

From f6f80c5430c279eddaee39929e2182b6f4b6ac90 Mon Sep 17 00:00:00 2001
From: Robert Jarzmik <robert.jarzmik@free.fr>
Date: Wed, 25 Jan 2012 10:13:55 +0100
Subject: [PATCH 2/2] arm/mach-pxa: add CCCR bits definitions

Add CCCR bits definition for PXA SoC, so that the bootloader
can setup a stable core clock frequency, which is not the
initial reset clock, as required by Intel's PXA27x Processor
family developer's guide, chapter 3.5.5, table 3.7 (clock
frequencies).

Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
---
 arch/arm/mach-pxa/include/mach/pxa2xx-regs.h |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-pxa/include/mach/pxa2xx-regs.h b/arch/arm/mach-pxa/include/mach/pxa2xx-regs.h
index 4762d8a..b43648e 100644
--- a/arch/arm/mach-pxa/include/mach/pxa2xx-regs.h
+++ b/arch/arm/mach-pxa/include/mach/pxa2xx-regs.h
@@ -222,6 +222,11 @@
 #define CCCR_N_MASK	0x0380	/* Run Mode Frequency to Turbo Mode Frequency Multiplier */
 #define CCCR_M_MASK	0x0060	/* Memory Frequency to Run Mode Frequency Multiplier */
 #define CCCR_L_MASK	0x001f	/* Crystal Frequency to Memory Frequency Multiplier */
+#define CCCR_CPDIS	(1 << 31)
+#define CCCR_PPDIS	(1 << 30)
+#define CCCR_LCD26	(1 << 27)
+#define CCCR_PLL_EARLY	(1 << 26)
+#define CCCR_A		(1 << 25)
 
 #define CKEN_AC97CONF   (1 << 31)    /* AC97 Controller Configuration */
 #define CKEN_CAMERA	(1 << 24)	/* Camera Interface Clock Enable */
-- 
1.7.5.4


[-- Attachment #4: Type: text/plain, Size: 149 bytes --]

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: Pending patches

[Sascha Hauer]

Hi Robert,

On Tue, Feb 21, 2012 at 01:10:34PM +0100, Robert Jarzmik wrote:
> Hi Sascha,
> 
> I have 2 sent patches which were somehow ... lost.
> They have been sent on January the 26th, with the following subjects:
>  - [PATCH] arm/mach-pxa: add standard LCD panel GPIO settings
>  - [PATCH] arm/mach-pxa: add CCCR bits definitions
> 
> These are targeted at next branch. Could you consider pulling them ?
> I joined them in this mail to ease your search.

Yeah, I lost them. Applied now.

Thanks
 Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Pending patches

[Alan Stern]

James:

Have you had any time to review these three bug-fix patches?

	http://marc.info/?l=linux-scsi&m=126894117503693&w=2
	http://marc.info/?l=linux-scsi&m=126894127403891&w=2
	http://marc.info/?l=linux-scsi&m=126894128403918&w=2

Each one is quite short, and it should be easy to verify that they 
really do what they claim.

Alan Stern

Pending patches

[Alan Stern]

James:

Whatever happened to the 6-part patch series I submitted at the end of 
May?

0/6:	http://marc.info/?l=linux-scsi&m=124388632706196&w=2
1/6:	http://marc.info/?l=linux-scsi&m=124388639906873&w=2
2/6:	http://marc.info/?l=linux-scsi&m=124388664609269&w=2
3/6:	http://marc.info/?l=linux-scsi&m=124388664009217&w=2
4/6:	http://marc.info/?l=linux-scsi&m=124388742715268&w=2
5/6:	http://marc.info/?l=linux-scsi&m=124388752015618&w=2
6/6v2:	http://marc.info/?l=linux-scsi&m=124404339912876&w=2

Is there any reason they haven't gotten into scsi-misc for the next 
merge window?  It has been six weeks...

Alan Stern

Re: Pending patches

[James Bottomley]

On Wed, 2009-07-15 at 14:01 -0400, Alan Stern wrote:
> James:
> 
> Whatever happened to the 6-part patch series I submitted at the end of 
> May?
> 
> 0/6:	http://marc.info/?l=linux-scsi&m=124388632706196&w=2
> 1/6:	http://marc.info/?l=linux-scsi&m=124388639906873&w=2
> 2/6:	http://marc.info/?l=linux-scsi&m=124388664609269&w=2
> 3/6:	http://marc.info/?l=linux-scsi&m=124388664009217&w=2
> 4/6:	http://marc.info/?l=linux-scsi&m=124388742715268&w=2
> 5/6:	http://marc.info/?l=linux-scsi&m=124388752015618&w=2
> 6/6v2:	http://marc.info/?l=linux-scsi&m=124404339912876&w=2
> 
> Is there any reason they haven't gotten into scsi-misc for the next 
> merge window?  It has been six weeks...

According to the thread, there's no confirmation from the reporter that
they actually fix the problem.

James

Re: Pending patches

[Alan Stern]

On Thu, 16 Jul 2009, James Bottomley wrote:

> On Wed, 2009-07-15 at 14:01 -0400, Alan Stern wrote:
> > James:
> > 
> > Whatever happened to the 6-part patch series I submitted at the end of 
> > May?
> > 
> > 0/6:	http://marc.info/?l=linux-scsi&m=124388632706196&w=2
> > 1/6:	http://marc.info/?l=linux-scsi&m=124388639906873&w=2
> > 2/6:	http://marc.info/?l=linux-scsi&m=124388664609269&w=2
> > 3/6:	http://marc.info/?l=linux-scsi&m=124388664009217&w=2
> > 4/6:	http://marc.info/?l=linux-scsi&m=124388742715268&w=2
> > 5/6:	http://marc.info/?l=linux-scsi&m=124388752015618&w=2
> > 6/6v2:	http://marc.info/?l=linux-scsi&m=124404339912876&w=2
> > 
> > Is there any reason they haven't gotten into scsi-misc for the next 
> > merge window?  It has been six weeks...
> 
> According to the thread, there's no confirmation from the reporter that
> they actually fix the problem.

Please reconsider them not as specific bug fixes but rather as general
cleanups and improvements.  I.e., the sort of thing one would not send
to Linus until the next merge window.

Alan Stern

Re: Pending patches

[Alan Stern]

On Thu, 16 Jul 2009, Alan Stern wrote:

> On Thu, 16 Jul 2009, James Bottomley wrote:
> 
> > On Wed, 2009-07-15 at 14:01 -0400, Alan Stern wrote:
> > > James:
> > > 
> > > Whatever happened to the 6-part patch series I submitted at the end of 
> > > May?
> > > 
> > > 0/6:	http://marc.info/?l=linux-scsi&m=124388632706196&w=2
> > > 1/6:	http://marc.info/?l=linux-scsi&m=124388639906873&w=2
> > > 2/6:	http://marc.info/?l=linux-scsi&m=124388664609269&w=2
> > > 3/6:	http://marc.info/?l=linux-scsi&m=124388664009217&w=2
> > > 4/6:	http://marc.info/?l=linux-scsi&m=124388742715268&w=2
> > > 5/6:	http://marc.info/?l=linux-scsi&m=124388752015618&w=2
> > > 6/6v2:	http://marc.info/?l=linux-scsi&m=124404339912876&w=2
> > > 
> > > Is there any reason they haven't gotten into scsi-misc for the next 
> > > merge window?  It has been six weeks...
> > 
> > According to the thread, there's no confirmation from the reporter that
> > they actually fix the problem.
> 
> Please reconsider them not as specific bug fixes but rather as general
> cleanups and improvements.  I.e., the sort of thing one would not send
> to Linus until the next merge window.

James, I haven't heard anything back about this.  It's very 
discouraging to submit serious patches only to have them ignored for 
two months.

Would it help if I rewrote the changelogs?  Is there anything else I 
can do to bring these into consideration?

Alan Stern

Pending patches

[Alan Stern]

James:

The patches below have been pending for quite a while:

	http://marc.info/?l=linux-scsi&m=122814525009429&w=2
	http://marc.info/?l=linux-scsi&m=122935526508941&w=2

I expected to see them already in 2.6.29-rc1.  They certainly should be 
merged sometime during the 2.6.29 time frame.

Alan Stern

Pending patches

[Felipe Balbi]

Hi Tony,

You seem to have pushed most of the patches I sent but we're still
missing some of them.

Are there still any comments for those patches ? It's higly tested on my
n810 and all of them are working fine here.

Below is an output from:
$ git cherry master | cut -d+ -f2 | xargs git show --stat

commit a3b9e4f4397876d32d51f7fb3742318285a78601
Author: Daniel Stone <daniel.stone@nokia.com>
Date:   Mon Apr 7 17:07:37 2008 +0300

    I2C: LM8323: Introduce lm8323 keypad driver
    
    Introduce lm8323 keypad driver.
    
    Signed-off-by: Daniel Stone <daniel.stone@nokia.com
    
    Updated to build with recent linux-omap and new-style
    i2c driver.
    
    Signed-off-by: Felipe Balbi <felipe.balbi@nokia.com>

 arch/arm/mach-omap2/board-n800.c |   77 ++++
 arch/arm/mach-omap2/board-n810.c |    2 +
 drivers/input/keyboard/Kconfig   |    7 +
 drivers/input/keyboard/Makefile  |    1 +
 drivers/input/keyboard/lm8323.c  |  911 ++++++++++++++++++++++++++++++++++++++
 include/linux/i2c/lm8323.h       |   39 ++
 6 files changed, 1037 insertions(+), 0 deletions(-)

commit a68ff943d8e2e09e218b127142dfa99e6c618ac8
Author: Mathias Nyman <mathias.nyman@nokia.com>
Date:   Mon Apr 7 16:21:28 2008 +0300

    I2C: TSL2563: Add support for Taos tsl2563 ambient light sensor
    
    Add support for Taos tsl2563 ambient light sensor.
    
    Signed-off-by: Mathias Nyman <mathias.nyman@nokia.com>
    
    Updated to build with current linux-omap, new-style
    i2c driver and cleaned up checkpatch.pl issues.
    
    Signed-off-by: Felipe Balbi <felipe.balbi@nokia.com>

 arch/arm/mach-omap2/board-n800.c |    4 +
 drivers/i2c/chips/Kconfig        |   10 +
 drivers/i2c/chips/Makefile       |    2 +-
 drivers/i2c/chips/tsl2563.c      |  731 ++++++++++++++++++++++++++++++++++++++
 4 files changed, 746 insertions(+), 1 deletions(-)

commit 9416f0ccc9669a0588e16f776308f8f6c9e91661
Author: Lauri Leukkunen <lauri.leukkunen@nokia.com>
Date:   Mon Apr 7 19:57:43 2008 +0300

    INPUT: TOUCHSCREEN: Introduce tsc2005 driver
    
    Introduce n810's tsc2005 driver
    
    Signed-off-by: Lauri Leukkunen <lauri.leukkunen@nokia.com>
    
    Updated to build with current linux-omap.
    
    Signed-off-by: Felipe Balbi <felipe.balbi@nokia.com>

 arch/arm/mach-omap2/board-n800.c    |   95 +++++-
 drivers/input/touchscreen/Kconfig   |    5 +
 drivers/input/touchscreen/Makefile  |    1 +
 drivers/input/touchscreen/tsc2005.c |  739 +++++++++++++++++++++++++++++++++++
 include/linux/spi/tsc2005.h         |   29 ++
 5 files changed, 865 insertions(+), 4 deletions(-)

commit 57871dcd31fa8598ae5d0d3e3979e5e6f5477ea4
Author: Mathias Nyman <mathias.nyman@nokia.com>
Date:   Tue Apr 8 13:33:04 2008 +0300

    I2C: LP5521: Introduce lp5521 LED driver
    
    Introduce n810's lp5521 LED driver.
    
    Signed-off-by: Mathias Nyman <mathias.nyman@nokia.com
    
    Updated to new style i2c driver and to build on current
    linux-omap head.
    
    Signed-off-by: Felipe Balbi <felipe.balbi@nokia.com>

 arch/arm/mach-omap2/board-n800.c |    4 +
 drivers/i2c/chips/Kconfig        |    7 +
 drivers/i2c/chips/Makefile       |    1 +
 drivers/i2c/chips/lp5521.c       |  577 ++++++++++++++++++++++++++++++++++++++
 4 files changed, 589 insertions(+), 0 deletions(-)

commit 88573faf7d1e556376c0abb1adaf3497d814660b
Author: Felipe Balbi <felipe.balbi@nokia.com>
Date:   Tue Apr 8 15:36:32 2008 +0300

    ARM: N800: Update n800 defconfig
    
    Enables recent drivers and usb.
    
    Signed-off-by: Felipe Balbi <felipe.balbi@nokia.com>

 arch/arm/configs/n800_defconfig |  189 +++++++++++++++++++++++++++++++++++++--
 1 files changed, 182 insertions(+), 7 deletions(-)

-- 
	- Balbi

Re: Pending patches

[Tony Lindgren]

* Felipe Balbi <felipe.balbi@nokia.com> [080412 09:42]:
> Hi Tony,
> 
> You seem to have pushed most of the patches I sent but we're still
> missing some of them.
> 
> Are there still any comments for those patches ? It's higly tested on my
> n810 and all of them are working fine here.

Yeah, thanks. Pushing all of them today.

Tony


> Below is an output from:
> $ git cherry master | cut -d+ -f2 | xargs git show --stat
> 
> commit a3b9e4f4397876d32d51f7fb3742318285a78601
> Author: Daniel Stone <daniel.stone@nokia.com>
> Date:   Mon Apr 7 17:07:37 2008 +0300
> 
>     I2C: LM8323: Introduce lm8323 keypad driver
>     
>     Introduce lm8323 keypad driver.
>     
>     Signed-off-by: Daniel Stone <daniel.stone@nokia.com
>     
>     Updated to build with recent linux-omap and new-style
>     i2c driver.
>     
>     Signed-off-by: Felipe Balbi <felipe.balbi@nokia.com>
> 
>  arch/arm/mach-omap2/board-n800.c |   77 ++++
>  arch/arm/mach-omap2/board-n810.c |    2 +
>  drivers/input/keyboard/Kconfig   |    7 +
>  drivers/input/keyboard/Makefile  |    1 +
>  drivers/input/keyboard/lm8323.c  |  911 ++++++++++++++++++++++++++++++++++++++
>  include/linux/i2c/lm8323.h       |   39 ++
>  6 files changed, 1037 insertions(+), 0 deletions(-)
> 
> commit a68ff943d8e2e09e218b127142dfa99e6c618ac8
> Author: Mathias Nyman <mathias.nyman@nokia.com>
> Date:   Mon Apr 7 16:21:28 2008 +0300
> 
>     I2C: TSL2563: Add support for Taos tsl2563 ambient light sensor
>     
>     Add support for Taos tsl2563 ambient light sensor.
>     
>     Signed-off-by: Mathias Nyman <mathias.nyman@nokia.com>
>     
>     Updated to build with current linux-omap, new-style
>     i2c driver and cleaned up checkpatch.pl issues.
>     
>     Signed-off-by: Felipe Balbi <felipe.balbi@nokia.com>
> 
>  arch/arm/mach-omap2/board-n800.c |    4 +
>  drivers/i2c/chips/Kconfig        |   10 +
>  drivers/i2c/chips/Makefile       |    2 +-
>  drivers/i2c/chips/tsl2563.c      |  731 ++++++++++++++++++++++++++++++++++++++
>  4 files changed, 746 insertions(+), 1 deletions(-)
> 
> commit 9416f0ccc9669a0588e16f776308f8f6c9e91661
> Author: Lauri Leukkunen <lauri.leukkunen@nokia.com>
> Date:   Mon Apr 7 19:57:43 2008 +0300
> 
>     INPUT: TOUCHSCREEN: Introduce tsc2005 driver
>     
>     Introduce n810's tsc2005 driver
>     
>     Signed-off-by: Lauri Leukkunen <lauri.leukkunen@nokia.com>
>     
>     Updated to build with current linux-omap.
>     
>     Signed-off-by: Felipe Balbi <felipe.balbi@nokia.com>
> 
>  arch/arm/mach-omap2/board-n800.c    |   95 +++++-
>  drivers/input/touchscreen/Kconfig   |    5 +
>  drivers/input/touchscreen/Makefile  |    1 +
>  drivers/input/touchscreen/tsc2005.c |  739 +++++++++++++++++++++++++++++++++++
>  include/linux/spi/tsc2005.h         |   29 ++
>  5 files changed, 865 insertions(+), 4 deletions(-)
> 
> commit 57871dcd31fa8598ae5d0d3e3979e5e6f5477ea4
> Author: Mathias Nyman <mathias.nyman@nokia.com>
> Date:   Tue Apr 8 13:33:04 2008 +0300
> 
>     I2C: LP5521: Introduce lp5521 LED driver
>     
>     Introduce n810's lp5521 LED driver.
>     
>     Signed-off-by: Mathias Nyman <mathias.nyman@nokia.com
>     
>     Updated to new style i2c driver and to build on current
>     linux-omap head.
>     
>     Signed-off-by: Felipe Balbi <felipe.balbi@nokia.com>
> 
>  arch/arm/mach-omap2/board-n800.c |    4 +
>  drivers/i2c/chips/Kconfig        |    7 +
>  drivers/i2c/chips/Makefile       |    1 +
>  drivers/i2c/chips/lp5521.c       |  577 ++++++++++++++++++++++++++++++++++++++
>  4 files changed, 589 insertions(+), 0 deletions(-)
> 
> commit 88573faf7d1e556376c0abb1adaf3497d814660b
> Author: Felipe Balbi <felipe.balbi@nokia.com>
> Date:   Tue Apr 8 15:36:32 2008 +0300
> 
>     ARM: N800: Update n800 defconfig
>     
>     Enables recent drivers and usb.
>     
>     Signed-off-by: Felipe Balbi <felipe.balbi@nokia.com>
> 
>  arch/arm/configs/n800_defconfig |  189 +++++++++++++++++++++++++++++++++++++--
>  1 files changed, 182 insertions(+), 7 deletions(-)
> 
> -- 
> 	- Balbi

Pending patches

[Mauro Carvalho Chehab]

Hi guys,

Unfortunately, there were a crash at the server that I use for my inboxes. Due
to that, I lost several non-proccessed pull requests and e-mail patches that
should be committed into v4l-dvb tree and forward to kernel.

While I still hope that people will recover the lost e-mails, it would be safer
if those of you that forwarded me a patch, to re-send they to my inbox.

I kindly ask you to send those requests to me, c/c the lists, with the magic
tags at the subject:
[PATCH (resend)] - for patches that you're re-sending to me
[PULL (resend)] - for hg pull requests that you're re-sending



Cheers,
Mauro

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

pending patches

[Yoshinori K. Okuji]

Hello,

As you know, I am quite inactive these days, and haven't dealt with pending 
patches at all. But I am willing to solve them as soon as possible, thus I 
would appreciate if somebody could assist me. Unfortunately, due to my short 
memory, I even don't remember all of them. In addition, I now have 400 unread 
messages in my mailbox, and I don't think I can read every message carefully.

So, if you know any patches I should take a look, please remind me. What I can 
recall are:

- IA-64 port. I think I can find it myself.

- Various patches by Ozeki-san.

- (Unofficial) reiserfs patch by Vincent. I must test this really soon...

Best regards,
Okuji

Re: pending patches

[Robert Millan]

Hi Okuji!

Sorry for the late reply.  I don't have much time lately either.. ;-)

On Tue, Aug 07, 2007 at 09:26:31PM +0200, Yoshinori K. Okuji wrote:
> Hello,
> 
> As you know, I am quite inactive these days, and haven't dealt with pending 
> patches at all. But I am willing to solve them as soon as possible, thus I 
> would appreciate if somebody could assist me. Unfortunately, due to my short 
> memory, I even don't remember all of them. In addition, I now have 400 unread 
> messages in my mailbox, and I don't think I can read every message carefully.
> 
> So, if you know any patches I should take a look, please remind me. What I can 
> recall are:
> 
> - IA-64 port. I think I can find it myself.
> 
> - Various patches by Ozeki-san.
> 
> - (Unofficial) reiserfs patch by Vincent. I must test this really soon...

I found three patches/comments that I think deserve your attention:

  "bug-grub@gnu.org"

  http://lists.gnu.org/archive/html/grub-devel/2007-05/msg00083.html

  "Self multiboot patch"
  http://lists.gnu.org/archive/html/grub-devel/2007-06/msg00170.html

  "Re: Self multiboot patch" (Marco's reply)
  http://lists.gnu.org/archive/html/grub-devel/2007-07/msg00078.html

-- 
Robert Millan

<GPLv2> I know my rights; I want my phone call!
<DRM> What use is a phone call, if you are unable to speak?
(as seen on /.)

Re: pending patches

[tgingold]

Quoting "Yoshinori K. Okuji" <okuji@enbug.org>:

> Hello,
>
> So, if you know any patches I should take a look, please remind me. What I
> can
> recall are:
>
> - IA-64 port. I think I can find it myself.

I plan to work again on the ia64 port soon.

There are three different parts/issues:

* ia64 specific files: no real issues, the copyright assignment process is
  completed.

* build issue: the old patch uses objdump+tricks to convert from ELF to PE/COFF
 (EFI object format).  A small part of the trick is based on an HP start.S which
 is not assigned to FSF.
  During work on EFI, I have written a standalone ELF to PE/COFF converted.  I
  still have to mark it work within the grub framework.  Not a lot of work but
  it requires a few hours.

* modules: Dynamically loading modules requires handling relocation, which is
  a nightmare on ia64.  On the other side, because it's ia64 and EFI this
  feature is certainly not a must have (this should be discussed more lengthly).
  This is currently working by prelinking required modules.
  I think the pre-link method is a good idea (it simplifies porting work),
  is not target dependent but patches common files.

This is the current status.
I am very interested in having an ia64 port of grub (almost required for Xen).
Tristan.

Re: pending patches

[Johan Rydberg]

[-- Attachment #1: Type: text/plain, Size: 393 bytes --]

tgingold@free.fr writes:

>   During work on EFI, I have written a standalone ELF to PE/COFF converted.  I
>   still have to mark it work within the grub framework.  Not a lot of work but
>   it requires a few hours.

IIRC, we already have a ELF to PE/COFF converter in GRUB.  Look at 
util/i386/efi/grub-mkimage.c .

If not, I have one written for GNUFI that could be used.  

~j

[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]

Pending patches

[Alan Stern]

James:

May I draw your attention to these patch submissions:

http://marc.theaimsgroup.com/?l=linux-scsi&m=111221335824727&w=2
http://marc.theaimsgroup.com/?l=linux-scsi&m=112117962214214&w=2
http://marc.theaimsgroup.com/?l=linux-scsi&m=112238708903663&w=2 (this 
	is a cover message, not a patch)
http://marc.theaimsgroup.com/?l=linux-scsi&m=112238726326927&w=2
http://marc.theaimsgroup.com/?l=linux-scsi&m=112238753725214&w=2
http://marc.theaimsgroup.com/?l=linux-scsi&m=112238771326644&w=2
http://marc.theaimsgroup.com/?l=linux-scsi&m=112238804301664&w=2
http://marc.theaimsgroup.com/?l=linux-scsi&m=112238825727146&w=2

I never received any word back after submitting them, and they aren't 
present in the source tree at

http://www.parisc-linux.org/cgi-bin/gitweb.pl

Is it possible to get these patches into the queue?

Alan Stern

Re: Pending patches

[Patrick Mansfield]

On Tue, Sep 06, 2005 at 04:17:53PM -0400, Alan Stern wrote:

> I never received any word back after submitting them, and they aren't 
> present in the source tree at
> 
> http://www.parisc-linux.org/cgi-bin/gitweb.pl
> 
> Is it possible to get these patches into the queue?

Not that your patches are in it, but the scsi-misc tre is at:

http://www.kernel.org/git/?p=linux/kernel/git/jejb/scsi-misc-2.6.git;a=summary

-- Patrick Mansfield

Re: Pending patches

[Alan Stern]

On Tue, 6 Sep 2005, Patrick Mansfield wrote:

> On Tue, Sep 06, 2005 at 04:17:53PM -0400, Alan Stern wrote:
> 
> > I never received any word back after submitting them, and they aren't 
> > present in the source tree at
> > 
> > http://www.parisc-linux.org/cgi-bin/gitweb.pl
> > 
> > Is it possible to get these patches into the queue?
> 
> Not that your patches are in it, but the scsi-misc tre is at:
> 
> http://www.kernel.org/git/?p=linux/kernel/git/jejb/scsi-misc-2.6.git;a=summary

Thanks for the pointer.  James's earlier message didn't make it clear
whether the browser he mentioned was for the scsi-rc-fixes tree or the
scsi-misc tree.  Nor was it clear which patches one should expect to find 
in those two trees; I assume that patches go first into the scsi-misc 
tree, then eventually migrate to the scsi-rc-fixes tree, and hence to 
Linus.  Is that right?

Alan Stern

Re: Pending patches

[James Bottomley]

On Tue, 2005-09-06 at 16:17 -0400, Alan Stern wrote:
> May I draw your attention to these patch submissions:
> 
> http://marc.theaimsgroup.com/?l=linux-scsi&m=111221335824727&w=2
> http://marc.theaimsgroup.com/?l=linux-scsi&m=112117962214214&w=2

These two should be in.

> http://marc.theaimsgroup.com/?l=linux-scsi&m=112238708903663&w=2 (this 
> 	is a cover message, not a patch)
> http://marc.theaimsgroup.com/?l=linux-scsi&m=112238726326927&w=2
> http://marc.theaimsgroup.com/?l=linux-scsi&m=112238753725214&w=2
> http://marc.theaimsgroup.com/?l=linux-scsi&m=112238771326644&w=2
> http://marc.theaimsgroup.com/?l=linux-scsi&m=112238804301664&w=2
> http://marc.theaimsgroup.com/?l=linux-scsi&m=112238825727146&w=2

I was hoping that Mike Anderson would review these, but since he hasn't
I'll take a look.

James

Re: Pending patches

[Mike Anderson]

James Bottomley <James.Bottomley@SteelEye.com> wrote:
> On Tue, 2005-09-06 at 16:17 -0400, Alan Stern wrote:
> > http://marc.theaimsgroup.com/?l=linux-scsi&m=112238726326927&w=2

On as542. The first hunk of the diff is already in (declare of
scsi_host_set_state). The second hunk looks good (SHOST_RECOVERY label).
The third hunk I will take in combination with the other patch that
effects the scan code. This should have probably been
another patch.

> > http://marc.theaimsgroup.com/?l=linux-scsi&m=112238771326644&w=2

Have not looked at this yet, but will look at it in combination to the
above scan change.

> > http://marc.theaimsgroup.com/?l=linux-scsi&m=112238804301664&w=2

Do we need to revist how we are walking these lists for cleanup post
James's kilst fix / update?

> > http://marc.theaimsgroup.com/?l=linux-scsi&m=112238825727146&w=2

This looks ok for an added check, but I guess I need to look at old mail
and understand how we got here with the added scan mutex.

> 
> I was hoping that Mike Anderson would review these, but since he hasn't
> I'll take a look.

Sorry asleep at the keyboard on these. Comments above if you have not
already looked at them.

-andmike
--
Michael Anderson
andmike@us.ibm.com