* (unknown),
@ 2011-02-16 11:53 Hema HK
[not found] ` <1297857190-27449-1-git-send-email-hemahk-l0cyMroinI0@public.gmane.org>
2011-02-16 12:00 ` Sergei Shtylyov
0 siblings, 2 replies; 16+ messages in thread
From: Hema HK @ 2011-02-16 11:53 UTC (permalink / raw)
To: linux-usb; +Cc: linux-omap, Hema HK
From: Hema HK <hemahk@ti.com
Moved all the board specific internal PHY functions out of usb_musb.c file
as this file is shared between the OMAP2+ and AM35xx platforms.
There exists a file which has the functions specific to internal PHY
used for OMAP4 platform. Moved all phy specific functions to this file
and passing these functions through board data in the board file.
Signed-off-by: Hema HK <hemahk@ti.com>
Index: linux-2.6/arch/arm/mach-omap2/board-am3517evm.c
===================================================================
--- linux-2.6.orig/arch/arm/mach-omap2/board-am3517evm.c
+++ linux-2.6/arch/arm/mach-omap2/board-am3517evm.c
@@ -409,6 +409,10 @@ static struct omap_musb_board_data musb_
.interface_type = MUSB_INTERFACE_ULPI,
.mode = MUSB_OTG,
.power = 500,
+ .set_phy_power = am35x_musb_phy_power,
+ .clear_irq = am35x_musb_clear_irq,
+ .set_mode = am35x_musb_set_mode,
+ .reset = am35x_musb_reset,
};
static __init void am3517_evm_musb_init(void)
Index: linux-2.6/arch/arm/mach-omap2/omap_phy_internal.c
===================================================================
--- linux-2.6.orig/arch/arm/mach-omap2/omap_phy_internal.c
+++ linux-2.6/arch/arm/mach-omap2/omap_phy_internal.c
@@ -29,6 +29,7 @@
#include <linux/usb.h>
#include <plat/usb.h>
+#include "control.h"
/* OMAP control module register for UTMI PHY */
#define CONTROL_DEV_CONF 0x300
@@ -147,3 +148,95 @@ int omap4430_phy_exit(struct device *dev
return 0;
}
+
+void am35x_musb_reset(void)
+{
+ u32 regval;
+
+ /* Reset the musb interface */
+ regval = omap_ctrl_readl(AM35XX_CONTROL_IP_SW_RESET);
+
+ regval |= AM35XX_USBOTGSS_SW_RST;
+ omap_ctrl_writel(regval, AM35XX_CONTROL_IP_SW_RESET);
+
+ regval &= ~AM35XX_USBOTGSS_SW_RST;
+ omap_ctrl_writel(regval, AM35XX_CONTROL_IP_SW_RESET);
+
+ regval = omap_ctrl_readl(AM35XX_CONTROL_IP_SW_RESET);
+}
+
+void am35x_musb_phy_power(u8 on)
+{
+ unsigned long timeout = jiffies + msecs_to_jiffies(100);
+ u32 devconf2;
+
+ if (on) {
+ /*
+ * Start the on-chip PHY and its PLL.
+ */
+ devconf2 = omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2);
+
+ devconf2 &= ~(CONF2_RESET | CONF2_PHYPWRDN | CONF2_OTGPWRDN);
+ devconf2 |= CONF2_PHY_PLLON;
+
+ omap_ctrl_writel(devconf2, AM35XX_CONTROL_DEVCONF2);
+
+ pr_info(KERN_INFO "Waiting for PHY clock good...\n");
+ while (!(omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2)
+ & CONF2_PHYCLKGD)) {
+ cpu_relax();
+
+ if (time_after(jiffies, timeout)) {
+ pr_err(KERN_ERR "musb PHY clock good timed out\n");
+ break;
+ }
+ }
+ } else {
+ /*
+ * Power down the on-chip PHY.
+ */
+ devconf2 = omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2);
+
+ devconf2 &= ~CONF2_PHY_PLLON;
+ devconf2 |= CONF2_PHYPWRDN | CONF2_OTGPWRDN;
+ omap_ctrl_writel(devconf2, AM35XX_CONTROL_DEVCONF2);
+ }
+}
+
+void am35x_musb_clear_irq(void)
+{
+ u32 regval;
+
+ regval = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
+ regval |= AM35XX_USBOTGSS_INT_CLR;
+ omap_ctrl_writel(regval, AM35XX_CONTROL_LVL_INTR_CLEAR);
+ regval = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
+}
+
+void am35x_musb_set_mode(u8 musb_mode)
+{
+ u32 devconf2 = omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2);
+
+ devconf2 &= ~CONF2_OTGMODE;
+ switch (musb_mode) {
+#ifdef CONFIG_USB_MUSB_HDRC_HCD
+ case MUSB_HOST: /* Force VBUS valid, ID = 0 */
+ devconf2 |= CONF2_FORCE_HOST;
+ break;
+#endif
+#ifdef CONFIG_USB_GADGET_MUSB_HDRC
+ case MUSB_PERIPHERAL: /* Force VBUS valid, ID = 1 */
+ devconf2 |= CONF2_FORCE_DEVICE;
+ break;
+#endif
+#ifdef CONFIG_USB_MUSB_OTG
+ case MUSB_OTG: /* Don't override the VBUS/ID comparators */
+ devconf2 |= CONF2_NO_OVERRIDE;
+ break;
+#endif
+ default:
+ pr_info(KERN_INFO "Unsupported mode %u\n", musb_mode);
+ }
+
+ omap_ctrl_writel(devconf2, AM35XX_CONTROL_DEVCONF2);
+}
Index: linux-2.6/arch/arm/mach-omap2/usb-musb.c
===================================================================
--- linux-2.6.orig/arch/arm/mach-omap2/usb-musb.c
+++ linux-2.6/arch/arm/mach-omap2/usb-musb.c
@@ -30,102 +30,9 @@
#include <mach/irqs.h>
#include <mach/am35xx.h>
#include <plat/usb.h>
-#include "control.h"
#if defined(CONFIG_USB_MUSB_OMAP2PLUS) || defined (CONFIG_USB_MUSB_AM35X)
-static void am35x_musb_reset(void)
-{
- u32 regval;
-
- /* Reset the musb interface */
- regval = omap_ctrl_readl(AM35XX_CONTROL_IP_SW_RESET);
-
- regval |= AM35XX_USBOTGSS_SW_RST;
- omap_ctrl_writel(regval, AM35XX_CONTROL_IP_SW_RESET);
-
- regval &= ~AM35XX_USBOTGSS_SW_RST;
- omap_ctrl_writel(regval, AM35XX_CONTROL_IP_SW_RESET);
-
- regval = omap_ctrl_readl(AM35XX_CONTROL_IP_SW_RESET);
-}
-
-static void am35x_musb_phy_power(u8 on)
-{
- unsigned long timeout = jiffies + msecs_to_jiffies(100);
- u32 devconf2;
-
- if (on) {
- /*
- * Start the on-chip PHY and its PLL.
- */
- devconf2 = omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2);
-
- devconf2 &= ~(CONF2_RESET | CONF2_PHYPWRDN | CONF2_OTGPWRDN);
- devconf2 |= CONF2_PHY_PLLON;
-
- omap_ctrl_writel(devconf2, AM35XX_CONTROL_DEVCONF2);
-
- pr_info(KERN_INFO "Waiting for PHY clock good...\n");
- while (!(omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2)
- & CONF2_PHYCLKGD)) {
- cpu_relax();
-
- if (time_after(jiffies, timeout)) {
- pr_err(KERN_ERR "musb PHY clock good timed out\n");
- break;
- }
- }
- } else {
- /*
- * Power down the on-chip PHY.
- */
- devconf2 = omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2);
-
- devconf2 &= ~CONF2_PHY_PLLON;
- devconf2 |= CONF2_PHYPWRDN | CONF2_OTGPWRDN;
- omap_ctrl_writel(devconf2, AM35XX_CONTROL_DEVCONF2);
- }
-}
-
-static void am35x_musb_clear_irq(void)
-{
- u32 regval;
-
- regval = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
- regval |= AM35XX_USBOTGSS_INT_CLR;
- omap_ctrl_writel(regval, AM35XX_CONTROL_LVL_INTR_CLEAR);
- regval = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
-}
-
-static void am35x_musb_set_mode(u8 musb_mode)
-{
- u32 devconf2 = omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2);
-
- devconf2 &= ~CONF2_OTGMODE;
- switch (musb_mode) {
-#ifdef CONFIG_USB_MUSB_HDRC_HCD
- case MUSB_HOST: /* Force VBUS valid, ID = 0 */
- devconf2 |= CONF2_FORCE_HOST;
- break;
-#endif
-#ifdef CONFIG_USB_GADGET_MUSB_HDRC
- case MUSB_PERIPHERAL: /* Force VBUS valid, ID = 1 */
- devconf2 |= CONF2_FORCE_DEVICE;
- break;
-#endif
-#ifdef CONFIG_USB_MUSB_OTG
- case MUSB_OTG: /* Don't override the VBUS/ID comparators */
- devconf2 |= CONF2_NO_OVERRIDE;
- break;
-#endif
- default:
- pr_info(KERN_INFO "Unsupported mode %u\n", musb_mode);
- }
-
- omap_ctrl_writel(devconf2, AM35XX_CONTROL_DEVCONF2);
-}
-
static struct resource musb_resources[] = {
[0] = { /* start and end set dynamically */
.flags = IORESOURCE_MEM,
@@ -189,10 +96,6 @@ void __init usb_musb_init(struct omap_mu
musb_device.name = "musb-am35x";
musb_resources[0].start = AM35XX_IPSS_USBOTGSS_BASE;
musb_resources[1].start = INT_35XX_USBOTG_IRQ;
- board_data->set_phy_power = am35x_musb_phy_power;
- board_data->clear_irq = am35x_musb_clear_irq;
- board_data->set_mode = am35x_musb_set_mode;
- board_data->reset = am35x_musb_reset;
} else if (cpu_is_omap34xx()) {
musb_resources[0].start = OMAP34XX_HSUSB_OTG_BASE;
} else if (cpu_is_omap44xx()) {
Index: linux-2.6/arch/arm/plat-omap/include/plat/usb.h
===================================================================
--- linux-2.6.orig/arch/arm/plat-omap/include/plat/usb.h
+++ linux-2.6/arch/arm/plat-omap/include/plat/usb.h
@@ -91,6 +91,10 @@ extern int omap4430_phy_exit(struct devi
#endif
+extern void am35x_musb_reset(void);
+extern void am35x_musb_phy_power(u8 on);
+extern void am35x_musb_clear_irq(void);
+extern void am35x_musb_set_mode(u8 musb_mode);
/*
* FIXME correct answer depends on hmc_mode,
Index: linux-2.6/arch/arm/mach-omap2/Makefile
===================================================================
--- linux-2.6.orig/arch/arm/mach-omap2/Makefile
+++ linux-2.6/arch/arm/mach-omap2/Makefile
@@ -218,7 +218,8 @@ obj-$(CONFIG_MACH_OMAP4_PANDA) += board
hsmmc.o \
omap_phy_internal.o
-obj-$(CONFIG_MACH_OMAP3517EVM) += board-am3517evm.o
+obj-$(CONFIG_MACH_OMAP3517EVM) += board-am3517evm.o \
+ omap_phy_internal.o \
obj-$(CONFIG_MACH_CRANEBOARD) += board-am3517crane.o
^ permalink raw reply [flat|nested] 16+ messages in thread
[parent not found: <1297857190-27449-1-git-send-email-hemahk-l0cyMroinI0@public.gmane.org>]
* Re:
2011-02-16 11:53 (unknown), Hema HK
[not found] ` <1297857190-27449-1-git-send-email-hemahk-l0cyMroinI0@public.gmane.org>
@ 2011-02-16 12:00 ` Sergei Shtylyov
[not found] ` <4D5BBC61.2000905-hkdhdckH98+B+jHODAdFcQ@public.gmane.org>
1 sibling, 1 reply; 16+ messages in thread
From: Sergei Shtylyov @ 2011-02-16 12:00 UTC (permalink / raw)
To: Hema HK; +Cc: linux-usb, linux-omap
On 16-02-2011 14:53, Hema HK wrote:
> From: Hema HK<hemahk@ti.com
> Moved all the board specific internal PHY functions out of usb_musb.c file
> as this file is shared between the OMAP2+ and AM35xx platforms.
> There exists a file which has the functions specific to internal PHY
> used for OMAP4 platform. Moved all phy specific functions to this file
> and passing these functions through board data in the board file.
> Signed-off-by: Hema HK<hemahk@ti.com>
> Index: linux-2.6/arch/arm/mach-omap2/board-am3517evm.c
> ===================================================================
> --- linux-2.6.orig/arch/arm/mach-omap2/board-am3517evm.c
> +++ linux-2.6/arch/arm/mach-omap2/board-am3517evm.c
> @@ -409,6 +409,10 @@ static struct omap_musb_board_data musb_
> .interface_type = MUSB_INTERFACE_ULPI,
> .mode = MUSB_OTG,
> .power = 500,
> + .set_phy_power = am35x_musb_phy_power,
> + .clear_irq = am35x_musb_clear_irq,
> + .set_mode = am35x_musb_set_mode,
> + .reset = am35x_musb_reset,
> };
>
> static __init void am3517_evm_musb_init(void)
[...]
> Index: linux-2.6/arch/arm/mach-omap2/Makefile
> ===================================================================
> --- linux-2.6.orig/arch/arm/mach-omap2/Makefile
> +++ linux-2.6/arch/arm/mach-omap2/Makefile
> @@ -218,7 +218,8 @@ obj-$(CONFIG_MACH_OMAP4_PANDA) += board
> hsmmc.o \
> omap_phy_internal.o
>
> -obj-$(CONFIG_MACH_OMAP3517EVM) += board-am3517evm.o
> +obj-$(CONFIG_MACH_OMAP3517EVM) += board-am3517evm.o \
> + omap_phy_internal.o \
>
> obj-$(CONFIG_MACH_CRANEBOARD) += board-am3517crane.o
Doesn't the above board needs board data modified as well?
WBR, Sergei
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re:
@ 2020-02-06 2:24 Viviane Jose Pereira
0 siblings, 0 replies; 16+ messages in thread
From: Viviane Jose Pereira @ 2020-02-06 2:24 UTC (permalink / raw)
--
Hallo, ich entschuldige mich dafür, dass ich deine Privatsphäre gestört habe. Ich kontaktiere Sie für eine äußerst dringende und vertrauliche Angelegenheit.
Ihnen wurde eine Spende von 15.000.000,00 EUR angeboten Kontakt: cristtom063@gmail.com für weitere Informationen.
Dies ist keine Spam-Nachricht, sondern eine wichtige Mitteilung an Sie. Antworten Sie auf die obige E-Mail, um immer mehr Informationen über die Spende und den Erhalt von Geldern zu erhalten.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re:
@ 2014-12-06 13:18 Quan Han
0 siblings, 0 replies; 16+ messages in thread
From: Quan Han @ 2014-12-06 13:18 UTC (permalink / raw)
To: Recipients
Hello,
Compliments of the day to you and I believe all is well. My name is Mr. Quan Han and I work in bank of china. I have a transaction that I believe will be of mutual benefits to both of us. It involves an investment portfolio worth(eight million,three hundred and seventy thousand USD) which I like to acquire with your help and assistance.
Yours sincerely,
Quan Han.
^ permalink raw reply [flat|nested] 16+ messages in thread
* (unknown),
@ 2012-07-31 23:52 Ricardo Neri
2012-07-31 23:58 ` Ricardo Neri
0 siblings, 1 reply; 16+ messages in thread
From: Ricardo Neri @ 2012-07-31 23:52 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: archit, s-guiriec, linux-omap, Ricardo Neri
>From 8b0f9153d078b7182efd604ef8525d50899ce1a3 Mon Sep 17 00:00:00 2001
From: Ricardo Neri <ricardo.neri@ti.com>
Date: Mon, 30 Jul 2012 17:54:59 -0500
Subject: [PATCH v3] OMAPDSS: DISPC: Improvements to DIGIT sync signal selection
DSS code wrongly assumes that VENC is always available as source for the external
sync signal for the display controller DIGIT channel. One cannot blindly write/read
the value of DSS_CONTROL[15] as in certain processors (e.g., OMAP5) this operation
may not be valid. If the the sync source is not read correctly, the callers of
dss_get_hdmi_venc_clk_source might make wrong assumptions about, for instance,
video timings.
Logic is added to correctly get the sync signal based on the available displays
in the DIGIT channel. The source is set only if both VENC and HDMI are supported.
Signed-off-by: Ricardo Neri <ricardo.neri@ti.com>
---
v3: instead of BUG_ON calls, select only if both VENC and HDMI are available.
v2: use BUG_ON() to simplify handling of invalid cases.
drivers/video/omap2/dss/dss.c | 12 ++++++++++--
1 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index 04b4586..29e677e 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -648,9 +648,14 @@ void dss_set_dac_pwrdn_bgz(bool enable)
REG_FLD_MOD(DSS_CONTROL, enable, 5, 5); /* DAC Power-Down Control */
}
-void dss_select_hdmi_venc_clk_source(enum dss_hdmi_venc_clk_source_select hdmi)
+void dss_select_hdmi_venc_clk_source(enum dss_hdmi_venc_clk_source_select src)
{
- REG_FLD_MOD(DSS_CONTROL, hdmi, 15, 15); /* VENC_HDMI_SWITCH */
+ enum omap_display_type dp;
+ dp = dss_feat_get_supported_displays(OMAP_DSS_CHANNEL_DIGIT);
+
+ /* Select only if we have options */
+ if ((dp & OMAP_DISPLAY_TYPE_VENC) && (dp & OMAP_DISPLAY_TYPE_HDMI))
+ REG_FLD_MOD(DSS_CONTROL, src, 15, 15);
}
enum dss_hdmi_venc_clk_source_select dss_get_hdmi_venc_clk_source(void)
@@ -661,6 +666,9 @@ enum dss_hdmi_venc_clk_source_select dss_get_hdmi_venc_clk_source(void)
if ((displays & OMAP_DISPLAY_TYPE_HDMI) == 0)
return DSS_VENC_TV_CLK;
+ if ((displays & OMAP_DISPLAY_TYPE_VENC) == 0)
+ return DSS_HDMI_M_PCLK;
+
return REG_GET(DSS_CONTROL, 15, 15);
}
--
1.7.5.4
^ permalink raw reply related [flat|nested] 16+ messages in thread
* Re:
2012-07-31 23:52 (unknown), Ricardo Neri
@ 2012-07-31 23:58 ` Ricardo Neri
0 siblings, 0 replies; 16+ messages in thread
From: Ricardo Neri @ 2012-07-31 23:58 UTC (permalink / raw)
To: Ricardo Neri; +Cc: tomi.valkeinen, archit, s-guiriec, linux-omap
On 07/31/2012 06:52 PM, Ricardo Neri wrote:
> From 8b0f9153d078b7182efd604ef8525d50899ce1a3 Mon Sep 17 00:00:00 2001
> From: Ricardo Neri<ricardo.neri@ti.com>
> Date: Mon, 30 Jul 2012 17:54:59 -0500
> Subject: [PATCH v3] OMAPDSS: DISPC: Improvements to DIGIT sync signal selection
A small issue while sending the patch. I resubmitted correctly. Sorry
for the spam!
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re:
@ 2011-12-13 2:58 Matt Shaw
0 siblings, 0 replies; 16+ messages in thread
From: Matt Shaw @ 2011-12-13 2:58 UTC (permalink / raw)
To: doshoes1990
https://docs.google.com/document/d/1-MgXERW0_TNnd0VK2caXYhDXtT58z1DJ0laAmJajrEs/edit
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re:
@ 2010-07-20 0:22 wins
0 siblings, 0 replies; 16+ messages in thread
From: wins @ 2010-07-20 0:22 UTC (permalink / raw)
Your e mail address was picked in the Chevron award 2010 which was held
july 15th 2010 , and you are to claim the
sum of $750,000.00 USD. that means you are one of the five(5) lucky
recipents . Your winning number is: (CT-222-6747,FGN/P-900-56).
You are to send us this informations
NAME IN FULL:
DELIVERY ADDRESS:
AGE:
NATIONALITY:
OCCUPATION:
PHONE:
SEX:
^ permalink raw reply [flat|nested] 16+ messages in thread
* RE:
@ 2010-07-07 18:15 Coca Cola Promo
0 siblings, 0 replies; 16+ messages in thread
From: Coca Cola Promo @ 2010-07-07 18:15 UTC (permalink / raw)
One Million Pounds has been Awarded to in you in our COCA COLA
PROMO.Send your
Name..
Country..
Address..
Tel..
^ permalink raw reply [flat|nested] 16+ messages in thread
* RE:
@ 2010-04-29 2:49 ABC MICROFINANCE BANK (NIG)
0 siblings, 0 replies; 16+ messages in thread
From: ABC MICROFINANCE BANK (NIG) @ 2010-04-29 2:49 UTC (permalink / raw)
We are currently offering loans with very low annual interest rate of 3% to any
part of the world To Apply: Fullname, Country, Age,Loan duration, amount
needed. If interested email us at: Email: abcmicrofinance@discuz.org
^ permalink raw reply [flat|nested] 16+ messages in thread
* (no subject)
@ 2010-01-20 19:47 Ben Gamari
2010-01-21 0:04 ` Ben Dooks
` (2 more replies)
0 siblings, 3 replies; 16+ messages in thread
From: Ben Gamari @ 2010-01-20 19:47 UTC (permalink / raw)
To: Ben Dooks
Cc: David Brownell, Michael Hennerich, beagleboard, Eric Miao,
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, linux-omap
Bcc:
Subject: GPIO chip select support in omap2_mcspi driver
Hey,
Recently I have been looking to use a BeagleBoard to drive several
serial ADCs and DACs in a data acquisition and analysis setup. Unfortunately, the
BeagleBoard is severely limited by the number of SPI controllers it
exposes on the expansion connector (McSPI3 with 2 CS lines and McSPI4
with one). This is insufficient for our application and thus I have been
investigating adding support to the mcspi driver for using GPIO lines as
chip select lines, as is done in the pxa2xx, bfin5xx, and s3c24xx drivers.
To this end, I have a few questions about how this support was
implemented. First, it seems that the s3c24xx driver is built on the
spi_bitbang driver, despite interfacing with a dedicated hardware SPI
controller. What is the reason for this? Was this done specifically for
the purpose of incorporating support for GPIO CS pins?
It seems like the rough idea is to add a cs_gpio field to the device
struct (omap2_mcspi) and add the appropriate code to the
omap2_mcspi_force_cs() to bring cs_gpio high or low if it is valid. The
potential problem I can see with this is that omap2_mcspi_set_enable()
is called to enable the channel before the force_cs() is called (in
omap2_mcspi_work()). If I'm interpreting the documentation correctly,
the enable bit starts the clocks, meaning that the chip will begin
clocking out data before CS is brought high. I must be missing something
here, no?
For reference, I included a short list of relevant commits below, largely for
my own benefit. I would greatly appreciate any feedback you might have.
Thanks,
- Ben
pxa2xx_spi: a7bb3909b3293d503211d7f6af8ed62c1644b686
bfin_spi: 42c78b2bf51bafb4cfa98dfecc28dd9b8bcd04b0
------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re:
2010-01-20 19:47 (no subject) Ben Gamari
@ 2010-01-21 0:04 ` Ben Dooks
2010-01-21 0:04 ` Re: Ben Dooks
2010-01-22 15:53 ` Re: Ben Gamari
2 siblings, 0 replies; 16+ messages in thread
From: Ben Dooks @ 2010-01-21 0:04 UTC (permalink / raw)
To: Ben Gamari
Cc: beagleboard, linux-omap, David Brownell, Eric Miao,
Michael Hennerich, Grant Likely, spi-devel-general
Ben Gamari wrote:
> Bcc:
> Subject: GPIO chip select support in omap2_mcspi driver
>
> Hey,
>
> Recently I have been looking to use a BeagleBoard to drive several
> serial ADCs and DACs in a data acquisition and analysis setup. Unfortunately, the
> BeagleBoard is severely limited by the number of SPI controllers it
> exposes on the expansion connector (McSPI3 with 2 CS lines and McSPI4
> with one). This is insufficient for our application and thus I have been
> investigating adding support to the mcspi driver for using GPIO lines as
> chip select lines, as is done in the pxa2xx, bfin5xx, and s3c24xx drivers.
>
> To this end, I have a few questions about how this support was
> implemented. First, it seems that the s3c24xx driver is built on the
> spi_bitbang driver, despite interfacing with a dedicated hardware SPI
> controller. What is the reason for this? Was this done specifically for
> the purpose of incorporating support for GPIO CS pins?
The spi_bitbang driver also has a really useful spi queue and workqueue
built into it, which is what the s3c24xx spi driver actually bothers to
use.
> It seems like the rough idea is to add a cs_gpio field to the device
> struct (omap2_mcspi) and add the appropriate code to the
> omap2_mcspi_force_cs() to bring cs_gpio high or low if it is valid. The
> potential problem I can see with this is that omap2_mcspi_set_enable()
> is called to enable the channel before the force_cs() is called (in
> omap2_mcspi_work()). If I'm interpreting the documentation correctly,
> the enable bit starts the clocks, meaning that the chip will begin
> clocking out data before CS is brought high. I must be missing something
> here, no?
>
> For reference, I included a short list of relevant commits below, largely for
> my own benefit. I would greatly appreciate any feedback you might have.
>
> Thanks,
> - Ben
>
>
> pxa2xx_spi: a7bb3909b3293d503211d7f6af8ed62c1644b686
> bfin_spi: 42c78b2bf51bafb4cfa98dfecc28dd9b8bcd04b0
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re:
2010-01-20 19:47 (no subject) Ben Gamari
2010-01-21 0:04 ` Ben Dooks
@ 2010-01-21 0:04 ` Ben Dooks
2010-01-22 15:53 ` Re: Ben Gamari
2 siblings, 0 replies; 16+ messages in thread
From: Ben Dooks @ 2010-01-21 0:04 UTC (permalink / raw)
To: Ben Gamari
Cc: beagleboard, linux-omap, David Brownell, Eric Miao,
Michael Hennerich, Grant Likely,
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
[-- Attachment #1: Type: text/plain, Size: 1981 bytes --]
Ben Gamari wrote:
> Bcc:
> Subject: GPIO chip select support in omap2_mcspi driver
>
> Hey,
>
> Recently I have been looking to use a BeagleBoard to drive several
> serial ADCs and DACs in a data acquisition and analysis setup. Unfortunately, the
> BeagleBoard is severely limited by the number of SPI controllers it
> exposes on the expansion connector (McSPI3 with 2 CS lines and McSPI4
> with one). This is insufficient for our application and thus I have been
> investigating adding support to the mcspi driver for using GPIO lines as
> chip select lines, as is done in the pxa2xx, bfin5xx, and s3c24xx drivers.
>
> To this end, I have a few questions about how this support was
> implemented. First, it seems that the s3c24xx driver is built on the
> spi_bitbang driver, despite interfacing with a dedicated hardware SPI
> controller. What is the reason for this? Was this done specifically for
> the purpose of incorporating support for GPIO CS pins?
The spi_bitbang driver also has a really useful spi queue and workqueue
built into it, which is what the s3c24xx spi driver actually bothers to
use.
> It seems like the rough idea is to add a cs_gpio field to the device
> struct (omap2_mcspi) and add the appropriate code to the
> omap2_mcspi_force_cs() to bring cs_gpio high or low if it is valid. The
> potential problem I can see with this is that omap2_mcspi_set_enable()
> is called to enable the channel before the force_cs() is called (in
> omap2_mcspi_work()). If I'm interpreting the documentation correctly,
> the enable bit starts the clocks, meaning that the chip will begin
> clocking out data before CS is brought high. I must be missing something
> here, no?
>
> For reference, I included a short list of relevant commits below, largely for
> my own benefit. I would greatly appreciate any feedback you might have.
>
> Thanks,
> - Ben
>
>
> pxa2xx_spi: a7bb3909b3293d503211d7f6af8ed62c1644b686
> bfin_spi: 42c78b2bf51bafb4cfa98dfecc28dd9b8bcd04b0
[-- Attachment #2: Type: text/plain, Size: 409 bytes --]
--
You received this message because you are subscribed to the Google Groups "Beagle Board" group.
To post to this group, send email to beagleboard-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit this group at http://groups.google.com/group/beagleboard?hl=en.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re:
2010-01-20 19:47 (no subject) Ben Gamari
2010-01-21 0:04 ` Ben Dooks
2010-01-21 0:04 ` Re: Ben Dooks
@ 2010-01-22 15:53 ` Ben Gamari
2 siblings, 0 replies; 16+ messages in thread
From: Ben Gamari @ 2010-01-22 15:53 UTC (permalink / raw)
To: Ben Gamari
Cc: Ben Dooks, beagleboard, linux-omap, David Brownell, Eric Miao,
Michael Hennerich, Grant Likely, spi-devel-general
Excerpts from Ben Gamari's message of Wed Jan 20 14:47:23 -0500 2010:
> Bcc:
> Subject: GPIO chip select support in omap2_mcspi driver
>
> It seems like the rough idea is to add a cs_gpio field to the device
> struct (omap2_mcspi) and add the appropriate code to the
> omap2_mcspi_force_cs() to bring cs_gpio high or low if it is valid. The
> potential problem I can see with this is that omap2_mcspi_set_enable()
> is called to enable the channel before the force_cs() is called (in
> omap2_mcspi_work()). If I'm interpreting the documentation correctly,
> the enable bit starts the clocks, meaning that the chip will begin
> clocking out data before CS is brought high. I must be missing something
> here, no?
Could someone comment on how this ordering works? As I said, it seems to
me like the SPI controller starts sending before CS is brought high.
I would appreciate any feedback. Thanks!
- Ben
^ permalink raw reply [flat|nested] 16+ messages in thread
* RE:
@ 2009-12-05 22:29 Irish News Center
0 siblings, 0 replies; 16+ messages in thread
From: Irish News Center @ 2009-12-05 22:29 UTC (permalink / raw)
You won 750,000gbp.Send:Name,Age,Country
^ permalink raw reply [flat|nested] 16+ messages in thread
* (unknown),
@ 2009-08-25 10:34 Syed Rafiuddin
2009-08-26 11:10 ` Ben Dooks
0 siblings, 1 reply; 16+ messages in thread
From: Syed Rafiuddin @ 2009-08-25 10:34 UTC (permalink / raw)
To: soni.trilok, linux-input; +Cc: linux-omap, linux-arm-kernel
From: Syed Rafiuddin <rafiuddin.syed@ti.com>
This patch Adds Keypad support on OMAP4.And adds
OMAP4 register addresses and configures them for OMAP4.
This patch has been updated as per the comments received from
Trilok Soni to remove GPIO based omap2 keypad logic from omap_keypad.c
(http://www.mail-archive.com/linux-omap@vger.kernel.org/msg14570.html)
Matrix_keypad.c (gpio based keypad driver) can be used in OMAP2,
which is not tested on OMAP2 since unavailability of omap2 target's.
Signed-off-by: Syed Rafiuddin <rafiuddin.syed@ti.com>
---
drivers/input/keyboard/omap-keypad.c | 247 ++++++++++++++++-------------------
1 files changed, 115 insertions(+), 132 deletions(-)
Index: kernel-omap4-base/drivers/input/keyboard/omap-keypad.c
===================================================================
--- kernel-omap4-base.orig/drivers/input/keyboard/omap-keypad.c 2009-08-19 12:23:14.000000000 +0530
+++ kernel-omap4-base/drivers/input/keyboard/omap-keypad.c 2009-08-19 18:25:17.000000000 +0530
@@ -44,6 +44,36 @@
#undef NEW_BOARD_LEARNING_MODE
+#define OMAP4_KBDOCP_BASE 0x4A31C000
+#define OMAP4_KBD_REVISION 0x00
+#define OMAP4_KBD_SYSCONFIG 0x10
+#define OMAP4_KBD_SYSSTATUS 0x14
+#define OMAP4_KBD_IRQSTATUS 0x18
+#define OMAP4_KBD_IRQENABLE 0x1C
+#define OMAP4_KBD_WAKEUPENABLE 0x20
+#define OMAP4_KBD_PENDING 0x24
+#define OMAP4_KBD_CTRL 0x28
+#define OMAP4_KBD_DEBOUNCINGTIME 0x2C
+#define OMAP4_KBD_LONGKEYTIME 0x30
+#define OMAP4_KBD_TIMEOUT 0x34
+#define OMAP4_KBD_STATEMACHINE 0x38
+#define OMAP4_KBD_ROWINPUTS 0x3C
+#define OMAP4_KBD_COLUMNOUTPUTS 0x40
+#define OMAP4_KBD_FULLCODE31_0 0x44
+#define OMAP4_KBD_FULLCODE63_32 0x48
+
+#define OMAP4_KBD_SYSCONFIG_SOFTRST (1 << 1)
+#define OMAP4_KBD_SYSCONFIG_ENAWKUP (1 << 2)
+#define OMAP4_KBD_IRQENABLE_EVENTEN (1 << 0)
+#define OMAP4_KBD_IRQENABLE_LONGKEY (1 << 1)
+#define OMAP4_KBD_IRQENABLE_TIMEOUTEN (1 << 2)
+#define OMAP4_KBD_CTRL_NOSOFTMODE (1 << 1)
+#define OMAP4_KBD_CTRLPTVVALUE (1 << 2)
+#define OMAP4_KBD_CTRLPTV (1 << 1)
+#define OMAP4_KBD_IRQDISABLE 0x00
+
+#define OMAP4_KBD_IRQSTATUSDISABLE 0xffff
+
static void omap_kp_tasklet(unsigned long);
static void omap_kp_timer(unsigned long);
@@ -65,55 +95,16 @@ struct omap_kp {
static DECLARE_TASKLET_DISABLED(kp_tasklet, omap_kp_tasklet, 0);
static int *keymap;
-static unsigned int *row_gpios;
-static unsigned int *col_gpios;
-
-#ifdef CONFIG_ARCH_OMAP2
-static void set_col_gpio_val(struct omap_kp *omap_kp, u8 value)
-{
- int col;
-
- for (col = 0; col < omap_kp->cols; col++)
- gpio_set_value(col_gpios[col], value & (1 << col));
-}
-
-static u8 get_row_gpio_val(struct omap_kp *omap_kp)
-{
- int row;
- u8 value = 0;
-
- for (row = 0; row < omap_kp->rows; row++) {
- if (gpio_get_value(row_gpios[row]))
- value |= (1 << row);
- }
- return value;
-}
-#else
-#define set_col_gpio_val(x, y) do {} while (0)
-#define get_row_gpio_val(x) 0
-#endif
static irqreturn_t omap_kp_interrupt(int irq, void *dev_id)
{
- struct omap_kp *omap_kp = dev_id;
+ if (cpu_is_omap44xx()) {
+ /* disable keyboard interrupt and schedule for handling */
+ omap_writel(OMAP4_KBD_IRQDISABLE, OMAP4_KBDOCP_BASE +
+ OMAP4_KBD_IRQENABLE);
- /* disable keyboard interrupt and schedule for handling */
- if (cpu_is_omap24xx()) {
- int i;
-
- for (i = 0; i < omap_kp->rows; i++) {
- int gpio_irq = gpio_to_irq(row_gpios[i]);
- /*
- * The interrupt which we're currently handling should
- * be disabled _nosync() to avoid deadlocks waiting
- * for this handler to complete. All others should
- * be disabled the regular way for SMP safety.
- */
- if (gpio_irq == irq)
- disable_irq_nosync(gpio_irq);
- else
- disable_irq(gpio_irq);
- }
+ omap_writel(omap_readl(OMAP4_KBDOCP_BASE + OMAP4_KBD_IRQSTATUS),
+ OMAP4_KBDOCP_BASE + OMAP4_KBD_IRQSTATUS);
} else
/* disable keyboard interrupt and schedule for handling */
omap_writew(1, OMAP_MPUIO_BASE + OMAP_MPUIO_KBD_MASKIT);
@@ -132,14 +123,13 @@ static void omap_kp_scan_keypad(struct o
{
int col = 0;
+ u32 *p = (u32 *) state;
/* read the keypad status */
- if (cpu_is_omap24xx()) {
- /* read the keypad status */
- for (col = 0; col < omap_kp->cols; col++) {
- set_col_gpio_val(omap_kp, ~(1 << col));
- state[col] = ~(get_row_gpio_val(omap_kp)) & 0xff;
- }
- set_col_gpio_val(omap_kp, 0);
+ if (cpu_is_omap44xx()) {
+
+ *p = omap_readl(OMAP4_KBDOCP_BASE + OMAP4_KBD_FULLCODE31_0);
+ *(p + 1) = omap_readl(OMAP4_KBDOCP_BASE +
+ OMAP4_KBD_FULLCODE63_32);
} else {
/* disable keyboard interrupt and schedule for handling */
@@ -198,7 +188,13 @@ static void omap_kp_tasklet(unsigned lon
row, (new_state[col] & (1 << row)) ?
"pressed" : "released");
#else
- key = omap_kp_find_key(col, row);
+
+ /* Keymappings have changed in omap4.*/
+ if (cpu_is_omap44xx())
+ key = omap_kp_find_key(row, col);
+ else
+ key = omap_kp_find_key(col, row);
+
if (key < 0) {
printk(KERN_WARNING
"omap-keypad: Spurious key event %d-%d\n",
@@ -213,8 +209,16 @@ static void omap_kp_tasklet(unsigned lon
continue;
kp_cur_group = key & GROUP_MASK;
- input_report_key(omap_kp_data->input, key & ~GROUP_MASK,
- new_state[col] & (1 << row));
+
+ if (cpu_is_omap44xx())
+ input_report_key(omap_kp_data->input,
+ key & ~GROUP_MASK, new_state[row]
+ & (1 << col));
+ else
+ input_report_key(omap_kp_data->input,
+ key & ~GROUP_MASK, new_state[col]
+ & (1 << row));
+
#endif
}
}
@@ -229,14 +233,18 @@ static void omap_kp_tasklet(unsigned lon
mod_timer(&omap_kp_data->timer, jiffies + delay);
} else {
/* enable interrupts */
- if (cpu_is_omap24xx()) {
- int i;
- for (i = 0; i < omap_kp_data->rows; i++)
- enable_irq(gpio_to_irq(row_gpios[i]));
- } else {
- omap_writew(0, OMAP_MPUIO_BASE + OMAP_MPUIO_KBD_MASKIT);
+ if (cpu_is_omap44xx()) {
+ omap_writew(OMAP4_KBD_IRQENABLE_EVENTEN |
+ OMAP4_KBD_IRQENABLE_LONGKEY,
+ OMAP4_KBDOCP_BASE +
+ OMAP4_KBD_IRQENABLE);
kp_cur_group = -1;
- }
+ } else {
+ omap_writew(0, OMAP_MPUIO_BASE +
+ OMAP_MPUIO_KBD_MASKIT);
+ kp_cur_group = -1;
+ }
+
}
}
@@ -296,7 +304,7 @@ static int __devinit omap_kp_probe(struc
struct omap_kp *omap_kp;
struct input_dev *input_dev;
struct omap_kp_platform_data *pdata = pdev->dev.platform_data;
- int i, col_idx, row_idx, irq_idx, ret;
+ int i, col_idx, row_idx, ret;
if (!pdata->rows || !pdata->cols || !pdata->keymap) {
printk(KERN_ERR "No rows, cols or keymap from pdata\n");
@@ -316,7 +324,7 @@ static int __devinit omap_kp_probe(struc
omap_kp->input = input_dev;
/* Disable the interrupt for the MPUIO keyboard */
- if (!cpu_is_omap24xx())
+ if (!cpu_is_omap44xx())
omap_writew(1, OMAP_MPUIO_BASE + OMAP_MPUIO_KBD_MASKIT);
keymap = pdata->keymap;
@@ -327,39 +335,11 @@ static int __devinit omap_kp_probe(struc
if (pdata->delay)
omap_kp->delay = pdata->delay;
- if (pdata->row_gpios && pdata->col_gpios) {
- row_gpios = pdata->row_gpios;
- col_gpios = pdata->col_gpios;
- }
-
omap_kp->rows = pdata->rows;
omap_kp->cols = pdata->cols;
- if (cpu_is_omap24xx()) {
- /* Cols: outputs */
- for (col_idx = 0; col_idx < omap_kp->cols; col_idx++) {
- if (gpio_request(col_gpios[col_idx], "omap_kp_col") < 0) {
- printk(KERN_ERR "Failed to request"
- "GPIO%d for keypad\n",
- col_gpios[col_idx]);
- goto err1;
- }
- gpio_direction_output(col_gpios[col_idx], 0);
- }
- /* Rows: inputs */
- for (row_idx = 0; row_idx < omap_kp->rows; row_idx++) {
- if (gpio_request(row_gpios[row_idx], "omap_kp_row") < 0) {
- printk(KERN_ERR "Failed to request"
- "GPIO%d for keypad\n",
- row_gpios[row_idx]);
- goto err2;
- }
- gpio_direction_input(row_gpios[row_idx]);
- }
- } else {
- col_idx = 0;
- row_idx = 0;
- }
+ col_idx = 0;
+ row_idx = 0;
setup_timer(&omap_kp->timer, omap_kp_timer, (unsigned long)omap_kp);
@@ -369,7 +349,7 @@ static int __devinit omap_kp_probe(struc
ret = device_create_file(&pdev->dev, &dev_attr_enable);
if (ret < 0)
- goto err2;
+ goto err1;
/* setup input device */
__set_bit(EV_KEY, input_dev->evbit);
@@ -387,47 +367,54 @@ static int __devinit omap_kp_probe(struc
ret = input_register_device(omap_kp->input);
if (ret < 0) {
printk(KERN_ERR "Unable to register omap-keypad input device\n");
- goto err3;
+ goto err2;
}
- if (pdata->dbounce)
- omap_writew(0xff, OMAP_MPUIO_BASE + OMAP_MPUIO_GPIO_DEBOUNCING);
+ if (pdata->dbounce) {
+ if (cpu_is_omap44xx())
+ omap_writew(0xff, OMAP_MPUIO_BASE +
+ OMAP4_KBD_DEBOUNCINGTIME);
+ else
+ omap_writew(0xff, OMAP_MPUIO_BASE +
+ OMAP_MPUIO_GPIO_DEBOUNCING);
+ }
/* scan current status and enable interrupt */
omap_kp_scan_keypad(omap_kp, keypad_state);
- if (!cpu_is_omap24xx()) {
- omap_kp->irq = platform_get_irq(pdev, 0);
- if (omap_kp->irq >= 0) {
- if (request_irq(omap_kp->irq, omap_kp_interrupt, 0,
- "omap-keypad", omap_kp) < 0)
- goto err4;
- }
+
+ /* Configuring OMAP4 keypad registers */
+ if (cpu_is_omap44xx()) {
+ omap_writew(OMAP4_KBD_SYSCONFIG_SOFTRST |
+ OMAP4_KBD_SYSCONFIG_ENAWKUP, OMAP4_KBDOCP_BASE
+ + OMAP4_KBD_SYSCONFIG);
+ omap_writew((OMAP4_KBD_CTRLPTVVALUE << OMAP4_KBD_CTRLPTV) |
+ OMAP4_KBD_CTRL_NOSOFTMODE,
+ OMAP4_KBDOCP_BASE + OMAP4_KBD_CTRL);
+ }
+
+ omap_kp->irq = platform_get_irq(pdev, 0);
+
+ if (omap_kp->irq >= 0) {
+ if (request_irq(omap_kp->irq, omap_kp_interrupt, 0,
+ "omap-keypad", omap_kp) < 0)
+ goto err3;
+ }
+
+ if (!cpu_is_omap44xx())
omap_writew(0, OMAP_MPUIO_BASE + OMAP_MPUIO_KBD_MASKIT);
- } else {
- for (irq_idx = 0; irq_idx < omap_kp->rows; irq_idx++) {
- if (request_irq(gpio_to_irq(row_gpios[irq_idx]),
- omap_kp_interrupt,
- IRQF_TRIGGER_FALLING,
- "omap-keypad", omap_kp) < 0)
- goto err5;
- }
+
+ if (cpu_is_omap44xx()) {
+ omap_writew(OMAP4_KBD_IRQENABLE_EVENTEN |
+ OMAP4_KBD_IRQENABLE_LONGKEY, OMAP4_KBDOCP_BASE +
+ OMAP4_KBD_IRQENABLE);
}
return 0;
-err5:
- for (i = irq_idx - 1; i >=0; i--)
- free_irq(row_gpios[i], 0);
-err4:
+err3:
input_unregister_device(omap_kp->input);
input_dev = NULL;
-err3:
- device_remove_file(&pdev->dev, &dev_attr_enable);
err2:
- for (i = row_idx - 1; i >=0; i--)
- gpio_free(row_gpios[i]);
+ device_remove_file(&pdev->dev, &dev_attr_enable);
err1:
- for (i = col_idx - 1; i >=0; i--)
- gpio_free(col_gpios[i]);
-
kfree(omap_kp);
input_free_device(input_dev);
@@ -440,14 +427,10 @@ static int __devexit omap_kp_remove(stru
/* disable keypad interrupt handling */
tasklet_disable(&kp_tasklet);
- if (cpu_is_omap24xx()) {
- int i;
- for (i = 0; i < omap_kp->cols; i++)
- gpio_free(col_gpios[i]);
- for (i = 0; i < omap_kp->rows; i++) {
- gpio_free(row_gpios[i]);
- free_irq(gpio_to_irq(row_gpios[i]), 0);
- }
+ if (cpu_is_omap44xx()) {
+ omap_writel(OMAP4_KBD_IRQDISABLE, OMAP4_KBDOCP_BASE +
+ OMAP4_KBD_IRQENABLE);
+ free_irq(omap_kp->irq, 0);
} else {
omap_writew(1, OMAP_MPUIO_BASE + OMAP_MPUIO_KBD_MASKIT);
free_irq(omap_kp->irq, 0);
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2020-02-06 2:31 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-02-16 11:53 (unknown), Hema HK
[not found] ` <1297857190-27449-1-git-send-email-hemahk-l0cyMroinI0@public.gmane.org>
2011-02-16 11:55 ` your mail Felipe Balbi
2011-02-16 12:00 ` Sergei Shtylyov
[not found] ` <4D5BBC61.2000905-hkdhdckH98+B+jHODAdFcQ@public.gmane.org>
2011-02-16 12:17 ` Hema Kalliguddi
-- strict thread matches above, loose matches on Subject: below --
2020-02-06 2:24 Viviane Jose Pereira
2014-12-06 13:18 Re: Quan Han
2012-07-31 23:52 (unknown), Ricardo Neri
2012-07-31 23:58 ` Ricardo Neri
2011-12-13 2:58 Re: Matt Shaw
2010-07-20 0:22 Re: wins
2010-07-07 18:15 Coca Cola Promo
2010-04-29 2:49 RE: ABC MICROFINANCE BANK (NIG)
2010-01-20 19:47 (no subject) Ben Gamari
2010-01-21 0:04 ` Ben Dooks
2010-01-21 0:04 ` Re: Ben Dooks
2010-01-22 15:53 ` Re: Ben Gamari
2009-12-05 22:29 Irish News Center
2009-08-25 10:34 (unknown), Syed Rafiuddin
2009-08-26 11:10 ` Ben Dooks
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).