* Re: [PATCH 1/5] USB: Make usb_hcd_irq work for multi-role USB controllers w/ shared irq
From: Grant Likely @ 2007-11-24 19:28 UTC (permalink / raw)
To: David Brownell; +Cc: akpm, linuxppc-dev, gregkh, linux-usb-devel
In-Reply-To: <200711241106.46515.david-b@pacbell.net>
On 11/24/07, David Brownell <david-b@pacbell.net> wrote:
> On Friday 23 November 2007, Grant Likely wrote:
> > Some multi-role (host/peripheral) USB controllers use a shared interrupt
> > line for all parts of the chip.
>
> Like the musb_hdrc code ... soonish to go upstream (it needs some
> updates to catch up to usbcore urb->status changes), this is used
> by the Nokia 800 and 810. In terms of chips with Linux support:
> DaVinci, TUSB60x0, OMAP 2430, OMAP 3430, Blackfin BF527; and ISTR
> a few less-publicised ones (including, yes, some PPC SOCs).
>
> That driver hasn't needed to change usbcore for IRQ handling though.
>
>
> > Export usb_hcd_irq so drivers can call it
> > from their interrupt handler instead of duplicating code.
>
> This seems to be the main point of this patch. I'd rather just
> make that "static" though; it should already be marked that way.
>
> That routine doesn't do enough to make me like it any more; and
> with dual-role controllers, the driver lifecycle is more complex
> than usbcore can be expected to mediate. Best to just call the
> host side IRQ logic directly from your toplevel IRQ handler.
>
>
> > Drivers pass an irqnum of 0 to usb_add_hcd to signal that the interrupt handler
> > shouldn't be registerred by the core.
>
> The current way to get that behavior is to leave hcd->driver->irq
> as zero; then "irqnum" is ignored, and your dual role driver can
> register its own handler.
Okay, I'll make that change.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH 2/5] USB: Add Cypress c67x00 low level interface code
From: David Brownell @ 2007-11-24 19:39 UTC (permalink / raw)
To: Grant Likely; +Cc: akpm, linuxppc-dev, gregkh, linux-usb-devel
In-Reply-To: <20071124002436.25361.50445.stgit@trillian.cg.shawcable.net>
On Friday 23 November 2007, Grant Likely wrote:
> +/* These functions could also be implemented with SPI of HSS.
> + * This is currently not supported */
Give that this "HPI" interface seems to use a parallel bus
with irq-safe synchronous accesses, and SPI is a serial bus
where synchronous accesses can't be done in IRQ context ...
that comment doesn't seem accurate.
Surely a more correct statement would be that while the chip
can also be accessed using SPI, that would require updating
the driver structure to stop assuming register accesses can
always be done from IRQ context?
If that's not the case, then those spinlocks are overkill,
and they should become mutexes. :)
- Dave
^ permalink raw reply
* Re: [PATCH 5/5] USB: Add Cypress c67x00 OTG controller driver to Kconfig and Makefiles
From: David Brownell @ 2007-11-24 20:12 UTC (permalink / raw)
To: Grant Likely; +Cc: akpm, linuxppc-dev, gregkh, linux-usb-devel
In-Reply-To: <20071124002451.25361.90102.stgit@trillian.cg.shawcable.net>
On Friday 23 November 2007, Grant Likely wrote:
> +config USB_C67X00_DRV
> + tristate "Cypress C67x00 support"
> + # only allowed to be =y if both USB!=m and USB_GADGET!=m
This is wrong. Remember that since this is a dual-role driver,
there are exactly three possible driver modes ... and the driver
must support only one of them at a time:
- Host-only ... only allowed if host side USB is enabled. The
controller driver can be statically linked iff usbcore is too.
- Peripheral-only ... only allowed if peripheral side USB is
enabled. Only one port may be used as the peripheral; the
controller driver can be linked statically or as a module.
- OTG ... only allowed if both host and peripheral side USB
are enabled. Only one port can be the OTG port, but other
ports can be used for host functionality. Static/modular
linkage follows (more restrictive) the host-only rule.
And of course, what a given board supports is controlled by the
connectors it has ... A, B, or AB. (Possibly AB plus n*A.) So
the driver should probably be able to make sense of having OTG
support, but needing to cope with a non-OTG board ... or having
an OTG board, a driver that only copes with one role.
Hmmm ... your patches don't include peripheral mode support yet.
Either all these gadget hooks should vanish, or you should try
to get the controller mode stuff right from the beginning.
I've appended the relevant Kconfig bits from the musb_hdrc
driver, which (despite some glitches) are pretty much correct.
- Dave
> + depends on (!USB && USB_GADGET) || (!USB_GADGET && USB) || (USB && USB_GADGET)
> + default n
> + help
> + The Cypress C67x00 (EZ-Host/EZ-OTG) chips are dual-role
> + host/peripheral USB controllers.
> +
> + To compile this driver as a module, choose M here: the
> + module will be called c67x00.
> +
> +config USB_C67X00_HCD
> + bool "Cypress C67X00 Host support"
> + depends on USB_C67X00_DRV
> + depends on USB
> + default y
> + help
> + This enables the host functionality of the Cypress C67X00.
>
================
#
# USB Dual Role (OTG-ready) Controller Drivers
# for silicon based on Mentor Graphics INVENTRA designs
#
comment "Enable Host or Gadget support to see Inventra options"
depends on !USB && USB_GADGET=n
# (M)HDRC = (Multipoint) Highspeed Dual-Role Controller
config USB_MUSB_HDRC
depends on USB || USB_GADGET
tristate 'Inventra Highspeed Dual Role Controller (TI, ...)'
help
Say Y here if your system has a dual role high speed USB
controller based on the Mentor Graphics silicon IP. Then
configure options to match your silicon and the board
it's being used with, including the USB peripheral role,
or the USB host role, or both.
Texas Instruments parts using this IP include DaVinci 644x,
OMAP 243x, OMAP 343x, and TUSB 6010.
If you do not know what this is, please say N.
To compile this driver as a module, choose M here; the
module will be called "musb_hdrc".
config USB_MUSB_SOC
boolean
depends on USB_MUSB_HDRC
default y if ARCH_DAVINCI
default y if ARCH_OMAP2430
default y if ARCH_OMAP343X
help
Use a static <asm/arch/hdrc_cnf.h> file to describe how the
controller is configured (endpoints, mechanisms, etc) on the
current iteration of a given system-on-chip.
comment "DaVinci 644x USB support"
depends on USB_MUSB_HDRC && ARCH_DAVINCI
comment "OMAP 243x high speed USB support"
depends on USB_MUSB_HDRC && ARCH_OMAP2430
comment "OMAP 343x high speed USB support"
depends on USB_MUSB_HDRC && ARCH_OMAP343X
config USB_TUSB6010
boolean "TUSB 6010 support"
depends on USB_MUSB_HDRC && !USB_MUSB_SOC
default y
help
The TUSB 6010 chip, from Texas Instruments, connects a discrete
HDRC core using a 16-bit parallel bus. It can use system-specific
external DMA controllers.
choice
prompt "Driver Mode"
depends on USB_MUSB_HDRC
help
Dual-Role devices can support both host and peripheral roles,
as well as a the special "OTG Device" role which can switch
between both roles as needed.
# use USB_MUSB_HDRC_HCD not USB_MUSB_HOST to #ifdef host side support;
# OTG needs both roles, not just USB_MUSB_HOST.
config USB_MUSB_HOST
depends on USB
bool "USB Host"
help
Say Y here if your system supports the USB host role.
If it has a USB "A" (rectangular), "Mini-A" (uncommon),
or "Mini-AB" connector, it supports the host role.
(With a "Mini-AB" connector, you should enable USB OTG.)
# use USB_GADGET_MUSB_HDRC not USB_MUSB_PERIPHERAL to #ifdef peripheral
# side support ... OTG needs both roles
config USB_MUSB_PERIPHERAL
depends on USB_GADGET
bool "USB Peripheral (gadget stack)"
select USB_GADGET_MUSB_HDRC
help
Say Y here if your system supports the USB peripheral role.
If it has a USB "B" (squarish), "Mini-B", or "Mini-AB"
connector, it supports the peripheral role.
(With a "Mini-AB" connector, you should enable USB OTG.)
config USB_MUSB_OTG
depends on USB && USB_GADGET && EXPERIMENTAL
bool "Both host and peripheral: USB OTG (On The Go) Device"
select USB_GADGET_MUSB_HDRC
select USB_OTG
select PM
help
The most notable feature of USB OTG is support for a
"Dual-Role" device, which can act as either a device
or a host. The initial role choice can be changed
later, when two dual-role devices talk to each other.
Select this if your system has a Mini-AB connector, or
to simplify certain kinds of configuration.
To implement your OTG Targeted Peripherals List (TPL), enable
USB_OTG_WHITELIST and update "drivers/usb/core/otg_whitelist.h"
to match your requirements.
endchoice
# enable peripheral support (including with OTG)
config USB_GADGET_MUSB_HDRC
bool
depends on USB_MUSB_HDRC && (USB_MUSB_PERIPHERAL || USB_MUSB_OTG)
# enables host support (including with OTG)
config USB_MUSB_HDRC_HCD
bool
depends on USB_MUSB_HDRC && (USB_MUSB_HOST || USB_MUSB_OTG)
select USB_OTG if USB_GADGET_MUSB_HDRC
default y
^ permalink raw reply
* [RFC/PATCHv3] powerpc: Move CPM command handling into the cpm drivers
From: Jochen Friedrich @ 2007-11-24 20:17 UTC (permalink / raw)
To: linuxppc-dev
This patch moves the CPM command handling into commproc.c
for CPM1 and cpm2_common.c. This is yet another preparation
to get rid of drivers accessing the CPM via the global cpmp.
Signed-off-by: Jochen Friedrich <jochen@scram.de>
---
arch/powerpc/sysdev/commproc.c | 28 ++++++++++++++++++++++++++++
arch/powerpc/sysdev/cpm2_common.c | 25 +++++++++++++++++++++++++
drivers/net/fs_enet/mac-fcc.c | 10 +---------
drivers/net/fs_enet/mac-scc.c | 11 +----------
drivers/serial/cpm_uart/cpm_uart_cpm1.c | 6 +-----
drivers/serial/cpm_uart/cpm_uart_cpm2.c | 8 +-------
include/asm-powerpc/cpm.h | 1 +
7 files changed, 58 insertions(+), 31 deletions(-)
diff --git a/arch/powerpc/sysdev/commproc.c b/arch/powerpc/sysdev/commproc.c
index f6a6378..2426bcb 100644
--- a/arch/powerpc/sysdev/commproc.c
+++ b/arch/powerpc/sysdev/commproc.c
@@ -240,6 +240,34 @@ void __init cpm_reset(void)
#endif
}
+static DEFINE_SPINLOCK(cmd_lock);
+
+#define MAX_CR_CMD_LOOPS 10000
+
+int cpm_command(u32 command, u8 opcode)
+{
+ int i, ret;
+ unsigned long flags;
+
+ if (command & 0xffffff0f)
+ return -EINVAL;
+
+ spin_lock_irqsave(&cmd_lock, flags);
+
+ ret = 0;
+ out_be16(&cpmp->cp_cpcr, command | CPM_CR_FLG | (opcode << 8));
+ for (i = 0; i < MAX_CR_CMD_LOOPS; i++)
+ if ((in_be16(&cpmp->cp_cpcr) & CPM_CR_FLG) == 0)
+ goto out;
+
+ printk(KERN_ERR "%s(): Not able to issue CPM command\n", __FUNCTION__);
+ ret = -EIO;
+out:
+ spin_unlock_irqrestore(&cmd_lock, flags);
+ return ret;
+}
+EXPORT_SYMBOL_GPL(cpm_command);
+
/* We used to do this earlier, but have to postpone as long as possible
* to ensure the kernel VM is now running.
*/
diff --git a/arch/powerpc/sysdev/cpm2_common.c b/arch/powerpc/sysdev/cpm2_common.c
index 859362f..e2acc60 100644
--- a/arch/powerpc/sysdev/cpm2_common.c
+++ b/arch/powerpc/sysdev/cpm2_common.c
@@ -83,6 +83,31 @@ cpm2_reset(void)
cpmp = &cpm2_immr->im_cpm;
}
+static DEFINE_SPINLOCK(cmd_lock);
+
+#define MAX_CR_CMD_LOOPS 10000
+
+int cpm_command(u32 command, u8 opcode)
+{
+ int i, ret;
+ unsigned long flags;
+
+ spin_lock_irqsave(&cmd_lock, flags);
+
+ ret = 0;
+ out_be32(&cpmp->cp_cpcr, command | opcode | CPM_CR_FLG);
+ for (i = 0; i < MAX_CR_CMD_LOOPS; i++)
+ if ((in_be32(&cpmp->cp_cpcr) & CPM_CR_FLG) == 0)
+ goto out;
+
+ printk(KERN_ERR "%s(): Not able to issue CPM command\n", __FUNCTION__);
+ ret = -EIO;
+out:
+ spin_unlock_irqrestore(&cmd_lock, flags);
+ return ret;
+}
+EXPORT_SYMBOL_GPL(cpm_command);
+
/* Set a baud rate generator. This needs lots of work. There are
* eight BRGs, which can be connected to the CPM channels or output
* as clocks. The BRGs are in two different block of internal
diff --git a/drivers/net/fs_enet/mac-fcc.c b/drivers/net/fs_enet/mac-fcc.c
index da4efbc..e363211 100644
--- a/drivers/net/fs_enet/mac-fcc.c
+++ b/drivers/net/fs_enet/mac-fcc.c
@@ -81,16 +81,8 @@
static inline int fcc_cr_cmd(struct fs_enet_private *fep, u32 op)
{
const struct fs_platform_info *fpi = fep->fpi;
- int i;
-
- W32(cpmp, cp_cpcr, fpi->cp_command | op | CPM_CR_FLG);
- for (i = 0; i < MAX_CR_CMD_LOOPS; i++)
- if ((R32(cpmp, cp_cpcr) & CPM_CR_FLG) == 0)
- return 0;
- printk(KERN_ERR "%s(): Not able to issue CPM command\n",
- __FUNCTION__);
- return 1;
+ return cpm_command(fpi->cp_command, op);
}
static int do_pd_setup(struct fs_enet_private *fep)
diff --git a/drivers/net/fs_enet/mac-scc.c b/drivers/net/fs_enet/mac-scc.c
index 03134f4..5ff856d 100644
--- a/drivers/net/fs_enet/mac-scc.c
+++ b/drivers/net/fs_enet/mac-scc.c
@@ -89,21 +89,12 @@
* Delay to wait for SCC reset command to complete (in us)
*/
#define SCC_RESET_DELAY 50
-#define MAX_CR_CMD_LOOPS 10000
static inline int scc_cr_cmd(struct fs_enet_private *fep, u32 op)
{
const struct fs_platform_info *fpi = fep->fpi;
- int i;
-
- W16(cpmp, cp_cpcr, fpi->cp_command | CPM_CR_FLG | (op << 8));
- for (i = 0; i < MAX_CR_CMD_LOOPS; i++)
- if ((R16(cpmp, cp_cpcr) & CPM_CR_FLG) == 0)
- return 0;
- printk(KERN_ERR "%s(): Not able to issue CPM command\n",
- __FUNCTION__);
- return 1;
+ return cpm_command(fpi->cp_command, op);
}
static int do_pd_setup(struct fs_enet_private *fep)
diff --git a/drivers/serial/cpm_uart/cpm_uart_cpm1.c b/drivers/serial/cpm_uart/cpm_uart_cpm1.c
index 52fb044..6ea0366 100644
--- a/drivers/serial/cpm_uart/cpm_uart_cpm1.c
+++ b/drivers/serial/cpm_uart/cpm_uart_cpm1.c
@@ -52,11 +52,7 @@
#ifdef CONFIG_PPC_CPM_NEW_BINDING
void cpm_line_cr_cmd(struct uart_cpm_port *port, int cmd)
{
- u16 __iomem *cpcr = &cpmp->cp_cpcr;
-
- out_be16(cpcr, port->command | (cmd << 8) | CPM_CR_FLG);
- while (in_be16(cpcr) & CPM_CR_FLG)
- ;
+ cpm_command(port->command, cmd);
}
#else
void cpm_line_cr_cmd(struct uart_cpm_port *port, int cmd)
diff --git a/drivers/serial/cpm_uart/cpm_uart_cpm2.c b/drivers/serial/cpm_uart/cpm_uart_cpm2.c
index 882dbc1..def0158 100644
--- a/drivers/serial/cpm_uart/cpm_uart_cpm2.c
+++ b/drivers/serial/cpm_uart/cpm_uart_cpm2.c
@@ -52,13 +52,7 @@
#ifdef CONFIG_PPC_CPM_NEW_BINDING
void cpm_line_cr_cmd(struct uart_cpm_port *port, int cmd)
{
- cpm_cpm2_t __iomem *cp = cpm2_map(im_cpm);
-
- out_be32(&cp->cp_cpcr, port->command | cmd | CPM_CR_FLG);
- while (in_be32(&cp->cp_cpcr) & CPM_CR_FLG)
- ;
-
- cpm2_unmap(cp);
+ cpm_command(port->command, cmd);
}
#else
void cpm_line_cr_cmd(struct uart_cpm_port *port, int cmd)
diff --git a/include/asm-powerpc/cpm.h b/include/asm-powerpc/cpm.h
index 48df9f3..fae83b1 100644
--- a/include/asm-powerpc/cpm.h
+++ b/include/asm-powerpc/cpm.h
@@ -10,5 +10,6 @@ int cpm_muram_free(unsigned long offset);
unsigned long cpm_muram_alloc_fixed(unsigned long offset, unsigned long size);
void __iomem *cpm_muram_addr(unsigned long offset);
dma_addr_t cpm_muram_dma(void __iomem *addr);
+int cpm_command(u32 command, u8 opcode);
#endif
--
1.5.3.5
^ permalink raw reply related
* Re: [PATCH 5/5] USB: Add Cypress c67x00 OTG controller driver to Kconfig and Makefiles
From: Grant Likely @ 2007-11-24 20:20 UTC (permalink / raw)
To: David Brownell; +Cc: akpm, linuxppc-dev, gregkh, linux-usb-devel
In-Reply-To: <200711241212.27787.david-b@pacbell.net>
On 11/24/07, David Brownell <david-b@pacbell.net> wrote:
> On Friday 23 November 2007, Grant Likely wrote:
> > +config USB_C67X00_DRV
> > +tristate "Cypress C67x00 support"
> > +# only allowed to be =y if both USB!=m and USB_GADGET!=m
>
> This is wrong. Remember that since this is a dual-role driver,
> there are exactly three possible driver modes ... and the driver
> must support only one of them at a time:
Actually, this part has 2 serial in interface engines; either of which
can be in host, peripheral or OTG mode. So; it is entirely relevant
for the driver to be doing both host and peripheral at the same time
with a single device.
>
> - Host-only ... only allowed if host side USB is enabled. The
> controller driver can be statically linked iff usbcore is too.
>
> - Peripheral-only ... only allowed if peripheral side USB is
> enabled. Only one port may be used as the peripheral; the
> controller driver can be linked statically or as a module.
>
> - OTG ... only allowed if both host and peripheral side USB
> are enabled. Only one port can be the OTG port, but other
> ports can be used for host functionality. Static/modular
> linkage follows (more restrictive) the host-only rule.
>
> And of course, what a given board supports is controlled by the
> connectors it has ... A, B, or AB. (Possibly AB plus n*A.) So
> the driver should probably be able to make sense of having OTG
> support, but needing to cope with a non-OTG board ... or having
> an OTG board, a driver that only copes with one role.
>
> Hmmm ... your patches don't include peripheral mode support yet.
No, nobody has written it yet.
>
> Either all these gadget hooks should vanish, or you should try
> to get the controller mode stuff right from the beginning.
>
> I've appended the relevant Kconfig bits from the musb_hdrc
> driver, which (despite some glitches) are pretty much correct.
I'll drop the gadget hooks for now. Most likely gadget and OTG
support will require more changes to this driver regardless, so it's
not a big deal.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [RFC][PATCH 0/3] OF-platform PATA driver
From: Arnd Bergmann @ 2007-11-24 20:50 UTC (permalink / raw)
To: linuxppc-dev, avorontsov; +Cc: linux-ide, Paul Mundt, Jeff Garzik
In-Reply-To: <20071123175229.GA27143@localhost.localdomain>
On Friday 23 November 2007, Anton Vorontsov wrote:
> Here is the PATA Platform driver using OF infrastructure.
>
> Mostly it's just a wrapper around a bit modified pata_platform
> driver.
Thanks a lot for doing this. Patches 2/3 are what I tried to get
people to do for some time now but was too lazy to do myself.
As a further thought, do the drivers now still need to be
pata specific, or should the OF part be called ata_of_platform
instead and also be used for sata devices?
Arnd <><
^ permalink raw reply
* Re: [PATCH 3/3] [POWERPC] MPC8349E-mITX: introduce pata node, make use pata_of_platform driver
From: Arnd Bergmann @ 2007-11-24 20:57 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linux-ide
In-Reply-To: <20071123175356.GC27338@localhost.localdomain>
On Friday 23 November 2007, Anton Vorontsov wrote:
>=20
> +static struct of_device_id mpc834x_ids[] =3D {
> +=A0=A0=A0=A0=A0=A0=A0{ .compatible =3D "pata-platform", },
> +=A0=A0=A0=A0=A0=A0=A0{},
> +};
> +
> +static int __init mpc834x_declare_of_platform_devices(void)
> +{
> +=A0=A0=A0=A0=A0=A0=A0if (!machine_is(mpc834x_itx))
> +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0return 0;
> +
> +=A0=A0=A0=A0=A0=A0=A0of_platform_bus_probe(NULL, mpc834x_ids, NULL);
> +
> +=A0=A0=A0=A0=A0=A0=A0return 0;
> +}
> +device_initcall(mpc834x_declare_of_platform_devices);
This is not really how of_platform_bus_probe was meant to be used.
Instead of listing the device you want to probe, you should list
all buses that potentially contain a device that you are probing.
Normally, an ata controller is not a top-level device but instead
the child of an SOC bus device, and then you just probe all
SOC devices, which means their children get added to the device
tree.
In your case, that would probably mean that you have to another
entry in the "ranges" of the soc8349 node, or add a second socXXXX
node that has the 0xf0000000 ranges, depending on the actual layout
of the SOC.
Arnd <><
^ permalink raw reply
* Re: [PATCH 5/5] USB: Add Cypress c67x00 OTG controller driver to Kconfig and Makefiles
From: David Brownell @ 2007-11-24 21:03 UTC (permalink / raw)
To: Grant Likely; +Cc: akpm, linuxppc-dev, gregkh, linux-usb-devel
In-Reply-To: <fa686aa40711241220r4e808ad8obb27ae8bf5890048@mail.gmail.com>
On Saturday 24 November 2007, Grant Likely wrote:
> On 11/24/07, David Brownell <david-b@pacbell.net> wrote:
> > On Friday 23 November 2007, Grant Likely wrote:
> > > +config USB_C67X00_DRV
> > > +tristate "Cypress C67x00 support"
> > > +# only allowed to be =y if both USB!=m and USB_GADGET!=m
> >
> > This is wrong. Remember that since this is a dual-role driver,
> > there are exactly three possible driver modes ... and the driver
> > must support only one of them at a time:
>
> Actually, this part has 2 serial in interface engines; either of which
> can be in host, peripheral or OTG mode. So; it is entirely relevant
> for the driver to be doing both host and peripheral at the same time
> with a single device.
While conforming with USB specs? Has that changed recently?
In the not-too-distant past I know there was explicit language
saying that such configurations are not allowed. (At least,
in terms of external connectors. A board using USB for internal
peripheral connections would be OK.)
Those issues can be deferred until peripheral support exists.
At that point you'll need to get better solutions to those config
issues...
> > Hmmm ... your patches don't include peripheral mode support yet.
>
> No, nobody has written it yet.
Then what's it doing in that GIT tree you pointed me at? :)
> > Either all these gadget hooks should vanish, or you should try
> > to get the controller mode stuff right from the beginning.
> >
> > I've appended the relevant Kconfig bits from the musb_hdrc
> > driver, which (despite some glitches) are pretty much correct.
>
> I'll drop the gadget hooks for now. Most likely gadget and OTG
> support will require more changes to this driver regardless, so it's
> not a big deal.
OK. Then the first incaration of this will be as a host-only
driver, in its own directory, and adding peripheral support will
cause minor lunacy. :)
- Dave
^ permalink raw reply
* Re: [PATCH 5/5] USB: Add Cypress c67x00 OTG controller driver to Kconfig and Makefiles
From: Grant Likely @ 2007-11-24 21:13 UTC (permalink / raw)
To: David Brownell; +Cc: akpm, linuxppc-dev, gregkh, linux-usb-devel
In-Reply-To: <200711241303.31700.david-b@pacbell.net>
On 11/24/07, David Brownell <david-b@pacbell.net> wrote:
> On Saturday 24 November 2007, Grant Likely wrote:
> > On 11/24/07, David Brownell <david-b@pacbell.net> wrote:
> > > On Friday 23 November 2007, Grant Likely wrote:
> > > > +config USB_C67X00_DRV
> > > > +tristate "Cypress C67x00 support"
> > > > +# only allowed to be =y if both USB!=m and USB_GADGET!=m
> > >
> > > This is wrong. Remember that since this is a dual-role driver,
> > > there are exactly three possible driver modes ... and the driver
> > > must support only one of them at a time:
> >
> > Actually, this part has 2 serial in interface engines; either of which
> > can be in host, peripheral or OTG mode. So; it is entirely relevant
> > for the driver to be doing both host and peripheral at the same time
> > with a single device.
>
> While conforming with USB specs? Has that changed recently?
Let me rephrase; the silicon implements 2 USB engines with separate
pinouts. They can be configured as 2 host controllers; 2 peripheral
controllers or 1 of each. They share registers and the IRQ line from
the software interface, but they are distinctly separate USB busses.
This driver actually implements 2 sub devices. Each sub device is
either bound to the host part of the driver or the gadget part.
>
> In the not-too-distant past I know there was explicit language
> saying that such configurations are not allowed. (At least,
> in terms of external connectors. A board using USB for internal
> peripheral connections would be OK.)
>
> Those issues can be deferred until peripheral support exists.
> At that point you'll need to get better solutions to those config
> issues...
ok
>
>
> > > Hmmm ... your patches don't include peripheral mode support yet.
> >
> > No, nobody has written it yet.
>
> Then what's it doing in that GIT tree you pointed me at? :)
Sitting there being useless. :-) That driver doesn't actually work;
it's just a proof of concept placeholder (which is why I didn't
include it in my series)
>
>
> > > Either all these gadget hooks should vanish, or you should try
> > > to get the controller mode stuff right from the beginning.
> > >
> > > I've appended the relevant Kconfig bits from the musb_hdrc
> > > driver, which (despite some glitches) are pretty much correct.
> >
> > I'll drop the gadget hooks for now. Most likely gadget and OTG
> > support will require more changes to this driver regardless, so it's
> > not a big deal.
>
> OK. Then the first incaration of this will be as a host-only
> driver, in its own directory, and adding peripheral support will
> cause minor lunacy. :)
:-)
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [RFC/PATCH] powerpc: Move CPM command handling into the cpm drivers
From: Vitaly Bordug @ 2007-11-24 21:47 UTC (permalink / raw)
To: Jochen Friedrich; +Cc: linuxppc-dev
In-Reply-To: <4748651E.2020806@scram.de>
On Sat, 24 Nov 2007 18:53:34 +0100
Jochen Friedrich wrote:
> Hi Vitaly,
>
> >>> + printk(KERN_ERR "%s(): Not able to issue CPM command\n",
> >>> + __FUNCTION__);
> >>> + return -EIO;
> >>>
> >> Do these need to be protected with a spin lock?
> >>
> > Even that might be not enough - we may have simultaneous call of
> > this func in non-smp case... I was thinking of some kind of
> > refcount, so one that is going to issue CPM command, must do say
> > pq_cpmp_get() and another driver won't be able to mangle with cpcr
> > while it's not done with previous request.
> >
> > Yet I am not telling it was better the way it used to be - this
> > approach looks okay but needs some efforts to defend against
> > deadlocks while we are at it
>
> Wouldn't spin_lock_irqsave() prevent a deadlock?
>
yes, I believe it is OK for now.
> Thanks,
> Jochen
--
Sincerely, Vitaly
^ permalink raw reply
* Re: [PATCH] IB/ehca: Fix static rate regression
From: Roland Dreier @ 2007-11-24 21:48 UTC (permalink / raw)
To: Joachim Fenkes
Cc: LKML, OF-EWG, LinuxPPC-Dev, Christoph Raisch, Marcus Eder,
OF-General, Stefan Roscher
In-Reply-To: <200711221126.27465.fenkes@de.ibm.com>
thanks, applied.
^ permalink raw reply
* Re: [PATCH 4/5] PowerPC 74xx: Katana Qp base support
From: Benjamin Herrenschmidt @ 2007-11-24 22:28 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev
In-Reply-To: <200711241952.00186.arnd@arndb.de>
On Sat, 2007-11-24 at 19:51 +0100, Arnd Bergmann wrote:
>
> This should be done automatically using of_platform_bus_probe().
Not necessarily. of_platform_bus_probe() is an optional facility that is
common used by SoCs that have lots of otherwise non-probable on chip
devices, but for platforms with more classic setups, it's totally
acceptable to have the platform code explicitely register only those
devices it wants exposed.
Ben.
^ permalink raw reply
* Access to PCI Expansion ROMs on PPC
From: Robin H. Johnson @ 2007-11-25 1:57 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1226 bytes --]
Following up from initial conversation with benh in #ppc64, I did a bit
of testing (and then a bit more).
Two PCIe cards for my testing:
a) sata_sil24 eSATA (x86 BIOS)
b) ATI X700 graphics (x86 BIOS)
I put the card into an amd64 box, found the relevant 'rom' node ($ROM) under
/sys/device/pci*, and dumped it as follows:
# echo 1>$ROM
# cat $ROM >/tmp/dump
# echo 0>$ROM
On amd64, this produced the ROM for the cards fine (contained
recognizable strings).
I then repeated the same on my G5 (PM11,2), while the $ROM files have a
non-zero size in sysfs (that corresponds to the size shown by lspci
-vv), reading them always results in a 0-byte output.
Is the PPC kernel broken? Does something in the PPC architecture forbid
this? Instructions to muck with PCI code welcome.
This was under 2.6.24_rc3-git1, kernel .config available if needed.
Why am I trying to access the PCI ROM? To make my newer X1900 card work
under at least one of the newer (ati,radeonhd,avivo) drivers, that all
try to access the ATI AtomBIOS for varying data.
--
Robin Hugh Johnson
Gentoo Linux Developer & Infra Guy
E-Mail : robbat2@gentoo.org
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
[-- Attachment #2: Type: application/pgp-signature, Size: 321 bytes --]
^ permalink raw reply
* Re: Access to PCI Expansion ROMs on PPC
From: Jon Smirl @ 2007-11-25 2:13 UTC (permalink / raw)
To: Robin H. Johnson; +Cc: linuxppc-dev
In-Reply-To: <20071125015707.GO3174@curie-int.orbis-terrarum.net>
On 11/24/07, Robin H. Johnson <robbat2@gentoo.org> wrote:
> Following up from initial conversation with benh in #ppc64, I did a bit
> of testing (and then a bit more).
>
> Two PCIe cards for my testing:
> a) sata_sil24 eSATA (x86 BIOS)
> b) ATI X700 graphics (x86 BIOS)
>
> I put the card into an amd64 box, found the relevant 'rom' node ($ROM) under
> /sys/device/pci*, and dumped it as follows:
> # echo 1>$ROM
> # cat $ROM >/tmp/dump
> # echo 0>$ROM
> On amd64, this produced the ROM for the cards fine (contained
> recognizable strings).
>
> I then repeated the same on my G5 (PM11,2), while the $ROM files have a
> non-zero size in sysfs (that corresponds to the size shown by lspci
> -vv), reading them always results in a 0-byte output.
>
> Is the PPC kernel broken? Does something in the PPC architecture forbid
> this? Instructions to muck with PCI code welcome.
The ROM is mapped in drivers/pci/rom.c
You could add some printks and see if there is an error and if the ROM
is accessible
rom = ioremap(start, *size);
if (!rom) {
/* restore enable if ioremap fails */
if (!(res->flags & (IORESOURCE_ROM_ENABLE |
IORESOURCE_ROM_SHADOW |
IORESOURCE_ROM_COPY)))
pci_disable_rom(pdev);
return NULL;
}
>
> This was under 2.6.24_rc3-git1, kernel .config available if needed.
>
> Why am I trying to access the PCI ROM? To make my newer X1900 card work
> under at least one of the newer (ati,radeonhd,avivo) drivers, that all
> try to access the ATI AtomBIOS for varying data.
>
> --
> Robin Hugh Johnson
> Gentoo Linux Developer & Infra Guy
> E-Mail : robbat2@gentoo.org
> GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* PCI to Parallel for PowerPC
From: Bai Shuwei @ 2007-11-25 5:06 UTC (permalink / raw)
To: linuxppc-dev, linuxppc-embedded; +Cc: zhang_wei, puyq, shekr06
[-- Attachment #1: Type: text/plain, Size: 719 bytes --]
hi, all
I bought a SMC1500 stepper motor card. And it can connect with host
through parallel port. My target board is PowerPC 440, which hasn't
parrallel port. So I bought a PCI to Parallel line for SMC1500. But when I
run the stepper motor, I find it's not stable. I doubt there are somthing
wrong with my PCI to Parallel line. So I beg somebody can tell me where I
can bought the appropriate conversion line from PCI to parallel, and does
somebody give me some idea about how to control my stepper motor
through PowerPC 440? thx all
Best Regards!
Buroc
--
Add: Tianshui South Road 222, Lanzhou, P.R.China
Tel: +86-931-8912025
Zip Code: 730000
URL: oss.lzu.edu.cn
Email: baishuwei@gmail.com, buroc@126.com
[-- Attachment #2: Type: text/html, Size: 1232 bytes --]
^ permalink raw reply
* RE: Xilinx devicetrees
From: Stephen Neuendorffer @ 2007-11-25 5:24 UTC (permalink / raw)
To: Grant Likely, David H. Lynch Jr.; +Cc: linuxppc-embedded
In-Reply-To: <fa686aa40711240912r192aba72o2cbdb798370e7b7c@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2181 bytes --]
-----Original Message-----
From: linuxppc-embedded-bounces+stephen=neuendorffer.name@ozlabs.org on behalf of Grant Likely
Sent: Sat 11/24/2007 9:12 AM
To: David H. Lynch Jr.
Cc: linuxppc-embedded
Subject: Re: Xilinx devicetrees
On 11/24/07, David H. Lynch Jr. <dhlii@dlasys.net> wrote:
>> I am having some difficulty grasping the significant advantages to
>> this.
>> If the firmware for a given target is not fairly static - and I load
>> different firmware depending on what I am doing all the time, then I
>> know have to manage both a bit file for the firmware, and a devicetree
>> file describing it to the kernel.
The device tree file is meta-information about your bitfile. Think of it as 'part of the firmware'. In the (hopefully short) future, it won't even have to be managed, it will just be one of the things that is generated by the EDK flow.
> That being said, using the device tree does not preclude using
> platform code to setup devices *where it makes sense to do so*. Many
> things are one-off board specific things that are not well described
> with the device tree. For example, we've been debating how to handle
> on board sound which use common codec chips, but have custom wireup.
> The codec chip can use a common driver, but the wireup is handled with
> an ALSA 'fabric' driver that is pretty much a one-off for the board.
> It probably makes more sense for the fabric driver to be instantiated
> by the platform code rather than trying to do a full device tree
> representation.
Actually, even this is still driven by the device tree, because the platform code binds to the toplevel 'compatible' property... It's just 'different' from a standard device driver.
>>
>> What am missing about devicetrees that would make me more
>> interested in them ?
You won't have to write a bunch of code that deciphers which fpga firmware you are running on.. That information will be found with the firmware and can be dealt with in a generic way. If you already HAVE that code, you can keep using it, but maintaining that kind of code is probably not where you want to spend your time.
Steve
[-- Attachment #2: Type: text/html, Size: 2897 bytes --]
^ permalink raw reply
* RE: Xilinx EDK BSP generation of device trees for microblaze and PowerPC
From: Stephen Neuendorffer @ 2007-11-25 6:24 UTC (permalink / raw)
To: Stephen Neuendorffer, microblaze-uclinux, linuxppc-dev,
Grant Likely, Michal Simek
Cc: git
In-Reply-To: <20071120194411.E183B100060@mail17-sin.bigfish.com>
[-- Attachment #1: Type: text/plain, Size: 5054 bytes --]
Here's what I've gotten so far:
Hard_Ethernet_MAC: xps-ll-temac@81c00000 {
#address-cells = <1>;
#size-cells = <1>;
network@81c00000 {
compatible = "xlnx,xps-ll-temac-1.00.a", "xlnx,xps-ll-temac";
interrupt-parent = <&xps_intc_0>;
interrupts = < 3 0 >;
llink-connected = <&PIM3>;
reg = < 81c00000 40 >;
xlnx,bus2core-clk-ratio = <1>;
xlnx,phy-type = <1>;
xlnx,phyaddr = <1>;
xlnx,rxcsum = <0>;
xlnx,rxfifo = <1000>;
xlnx,temac-type = <0>;
xlnx,txcsum = <0>;
xlnx,txfifo = <1000>;
} ;
} ;
mpmc@90000000 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "xlnx,mpmc-3.00.a", "xlnx,mpmc";
PIM3: sdma@84600180 {
compatible = "xlnx,ll-dma-1.00a", "xlnx,ll-dma";
interrupt-parent = <&xps_intc_0>;
interrupts = < 1 0 0 0 >;
reg = < 84600180 80 >;
} ;
} ;
DDR2_SDRAM: memory@90000000 {
device_type = "memory";
reg = < 90000000 10000000 >;
} ;
So: the mpmc generates a 'memory' node, corresponding to it's memory interface. It also gets a separate entry which contains the (optional, not present in this example) slave management interface (for ECC and performance information), and any sdma ports. In this case, this node is mpmc@90000000, because there is no management interface. If a management interface was present, then it would be @ the management address.
The mpmc gets a compatible string that describes its management interface.
The sdma port has information about the tx and rx interrupts and the slave management interface. Note that the slave management interface has the correct baseaddress for port3, generated from the base SDMA_CTRL_ address from the mpmc + the port 3 offset. Note that sdma has an artificial compatible name. I'm not sure whether the ll_dma driver can be easily convinced to bind to this, or whether the ll_temac driver will just traverse the device tree and then do a match against this.
The temac works similarly, although the temac itself doesn't have a slave interface, so no compatible node for it. The sub nodes get the compatible string for the ll_temac driver. In this case, there is only one temac port active. Some of the parameters are specific to port 0, in which case the parameter names (e.g. phyaddr) are generated by stripping off the complete C_TEMAC0 prefix. Other parameters (e.g. phy-type) are common to both sub nodes, but are duplicated to make it easier for the driver to get the information out. At runtime, the driver has to follow the llink-connected path to find what it is connected to, and use the dma code, or the fifo code.
the xps-ll-fifo structure is a bit simpler, with llink-connected pointing to the fifo, which looks like a 'normal' peripheral.
Points for comment:
1) I don't like the "PIM3" label, which is artificial (i.e. it doesn't correspond to a name in the .mhs) and not guaranteed to be unique. However, in the BSP generator it seems awkward to generate path references easily in a single pass. What I'd might prefer is:
DDR2_SDRAM: mpmc@90000000 {
sdma@3 {
and refer to the sdma port using something like <&DDR2_SDRAM/sdma@3>, but I don't think you can do that in dtc?
2) Not sure whether this is really simpler than just having a 'simple' node with both temacs and letting the driver sort everything out. In particular, I'm concerned about maintaining a bunch of semantic information about the ll_temac driver outside of the driver itself.
3) All of this is very different in structure from the way that the xparameters are organized. The ll_temac BSP code copies the xparameters out of the MPMC and they are simply other parameters of the ll_temac driver. Although the above structure better represents the actual system, there is another organization for people to be confused about.
Steve
-----Original Message-----
From: linuxppc-dev-bounces+stephen.neuendorffer=xilinx.com@ozlabs.org on behalf of Stephen Neuendorffer
Sent: Tue 11/20/2007 11:44 AM
To: microblaze-uclinux@itee.uq.edu.au; linuxppc-dev@ozlabs.org; Grant Likely; Michal Simek
Subject: Xilinx EDK BSP generation of device trees for microblaze and PowerPC
I've updated some code from Michel Simek to generate Flat Device Trees
from Xilinx EDK projects. This code is now hosted at:
git://git.xilinx.com/gen-mhs-devtree.git
This has one major advantage over the gen-mhs-devtree.py approach:
default IP core parameters that are not specified in the mhs file can
now be generated, since EDK pulls these in from the core .mpd file.
I've also managed to incorporate a few more improvements from the
previous review, so the BSP generator should include at least as much
information as gen-mhs-devtree.py
The next major order of business is to represent the DMA engines in the
MPMC and locallink connections to the lltemac.
Steve
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[-- Attachment #2: Type: text/html, Size: 11019 bytes --]
^ permalink raw reply
* SPI driver for spi_mpc83xx
From: fabio777 @ 2007-11-25 8:23 UTC (permalink / raw)
To: linuxppc-embedded
Has anyone been using this driver ?
For legacy reasons I need to keep the ppc=arch however I haven't found
out how to get this driver probed at start-up even basing my init on
Lublock.
Any help would be very appreciated - Thanks
^ permalink raw reply
* Re: Xilinx devicetrees
From: David H. Lynch Jr. @ 2007-11-25 9:15 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-embedded
In-Reply-To: <fa686aa40711240912r192aba72o2cbdb798370e7b7c@mail.gmail.com>
First;
I am not deliberately trying to be obstructive. It is apparent
that the ppc kernel is moving towards devicetrees and initially I
thought that sounded like a good idea.
Now I am trying to reconcile the positive benefits with my
perception of the negative side effects.
> Yes, you are correct in all of the above.
>
> One more point; it is also possible to bind the device tree up with
> the kernel so you've got a single image just like old times. :-)
>
But that is not actually the same is dynamically detecting
configuration.
On an ordinary PC where the critical core configuration is somewhat
fixed and the rest can be determined by firmware (code), this makes a
great deal of sense.
In a system where the hardware itself is actually firmware and there
is little or no startup software to query the device and build a device
tree dynamically for you, it is of more questionable value.
Maybe if there is some mechanism existed to have the devicetree
stored into the FPGA firmware where there is a natural link between the
implimented hardware and its description. But I am not gathering things
going in that direction and storing the device tree in the FPGA consumes
valuable FPGA resources.
>
> The board description has to live *somewhere*.
I have done alot of code for many purposes where the code went to a
great deal of effort to figure out its own environment dynamically.
Some (relatively minimal) assumptions have to be made. And some
balance has to be struck between code complexity and dynamic flexibility.
though sometimes dynamic detection can be simpler.
Part of what bothers me about devicetrees, is that the entire design
seems to presume either standard hardware with minimal permutations, or
fairly complex firmware - like boot roms to dynamically build atleast
parts of the device tree.
>
> That being said, using the device tree does not preclude using
> platform code to setup devices *where it makes sense to do so*. Many
> things are one-off board specific things that are not well described
> with the device tree. For example, we've been debating how to handle
> on board sound which use common codec chips, but have custom wireup.
> The codec chip can use a common driver, but the wireup is handled with
> an ALSA 'fabric' driver that is pretty much a one-off for the board.
> It probably makes more sense for the fabric driver to be instantiated
> by the platform code rather than trying to do a full device tree
> representation.
>
So I can hard code some relatively simple stripped devicetree
that may do little more than specify the CPU, major elements of the
memory map (maybe), and say the PIC, and then let the BSP, detect things
like the UART(s), NIC, ...
> In arch/powerpc
> we're *still* data driven; it's just that the data is no longer
> compiled into a static structure. Plus, in the transition we've moved
> from needed per-device platform data structures to a more expressive
> format. Also, per-board platform support code has become much simpler
> (compare ml300.c in arch/ppc with platforms/40x/virtex.c)
>
I have not pulled your tree in a while - are devicetree's in your
current git tree ?
Thanks for the remarks.
Again, I am just trying to figure out how to keep my Pico code in
sync and hopefully make my life better rather than worse at the same time.
Unfortunately, I am coming to the conclusion that DeviceTrees are
probably not going to make it that much better,
but they are probably not going to make it that much worse either.
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dhlii@dlasys.net http://www.dlasys.net
fax: 1.253.369.9244 Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
^ permalink raw reply
* Re: Xilinx devicetrees
From: David H. Lynch Jr. @ 2007-11-25 9:37 UTC (permalink / raw)
To: Stephen Neuendorffer; +Cc: linuxppc-embedded
In-Reply-To: <20071125052459.DA8B1EE805F@mail70-blu.bigfish.com>
Stephen Neuendorffer wrote:
>
> -----Original Message-----
> From: linuxppc-embedded-bounces+stephen=neuendorffer.name@ozlabs.org on behalf of Grant Likely
> Sent: Sat 11/24/2007 9:12 AM
> To: David H. Lynch Jr.
> Cc: linuxppc-embedded
> Subject: Re: Xilinx devicetrees
>
> On 11/24/07, David H. Lynch Jr. <dhlii@dlasys.net> wrote:
>
>
>>> I am having some difficulty grasping the significant advantages to
>>> this.
>>> If the firmware for a given target is not fairly static - and I load
>>> different firmware depending on what I am doing all the time, then I
>>> know have to manage both a bit file for the firmware, and a devicetree
>>> file describing it to the kernel.
>>>
>
> The device tree file is meta-information about your bitfile. Think of it as 'part of the firmware'. In the (hopefully short) future, it won't even have to be managed, it will just be one of the things that is generated by the EDK flow.
>
Part of the bad news is that I have been kept so busy on the
software side of things, I have had very very little time to play with
xilinx tools and firmware. But overall at Pico we have a love hate
relationship with them. Our products are primarily wrapped arround
FPGA's particularly Xilinx.
We love what we can do. But there are days that I here loud muttering
about completely rewriting all the xilinx software tools - there is a
surprisingly large amount that many of the Pico firmware people do not
use already.
Regardless, I think I saw a post of yours on the microblaze list
about exporting a devicetree list with the firmware.
that is probably a better solution that what exists now.
> You won't have to write a bunch of code that deciphers which fpga firmware you are running on.. That information will be found with the firmware and can be dealt with in a generic way. If you already HAVE that code, you can keep using it, but maintaining that kind of code is probably not where you want to spend your time.
>
I am curious - with the firmware is not the same as in the firmware.
But since you brought up deciphering firmware - to me and to Pico,
and I gather to alot of others, providing indentity information within
the firmware is a really really important issue - one which xilinx seems
to be unable to make up its mind about.
There are frequent posts addressing issues like this driver only
works with this version of some IP - but there is no way to query the IP
to enough detail to determine whether the driver will work. It is one
thing to make version registers an option. It is entirely different to
just omit them entirely or change the IP without changing the version.
Our clients beat us up for things like that. DevieTrees do nto solve
that problem.
Anyway, my .02 would be to put the device tree into the firmware. In
a perfect world - litterally in the firmware so that when the firmware
loads the device tree data is already in the FPGA somewhere that it can
be easily ready - oh and do that without consuming many FPGA resources.
But in a more likely realworld scenario - append the information to
the .bit file in some fashion so that if can easily be found and passed on.
Binding it to a kernel, is a non-starter for us. That means a
permuation of multiple different OS kernels for each bit file we might
have. That is huge number. I am tasked with getting one binary for each
OS to work with nearly every device(hardware) we make including
addressing options that change with firmware AND the whim of the user.
But life might not be to unpleasant - it might even actually be
better, if our kernel loader just extracted the devicetree from the end
of the currently executing firmware.
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dhlii@dlasys.net http://www.dlasys.net
fax: 1.253.369.9244 Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
^ permalink raw reply
* Re: Access to PCI Expansion ROMs on PPC
From: Andreas Schwab @ 2007-11-25 9:42 UTC (permalink / raw)
To: Robin H. Johnson; +Cc: linuxppc-dev
In-Reply-To: <20071125015707.GO3174@curie-int.orbis-terrarum.net>
"Robin H. Johnson" <robbat2@gentoo.org> writes:
> I put the card into an amd64 box, found the relevant 'rom' node ($ROM) under
> /sys/device/pci*, and dumped it as follows:
> # echo 1>$ROM
Did you run it exactly like this? Because this will echo exactly one
newline to $ROM. If you want to echo "1\n" you need to put a space
between "1" and ">".
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* SPI, I2C
From: David H. Lynch Jr. @ 2007-11-25 9:44 UTC (permalink / raw)
To: linuxppc-embedded
I have been asked to do SPI and I2C drivers for Pico cards.
I am trying to grasp what the practical use of either could be in an
environment where neither SPI nor I2C are going to be able to
communicate outside the FPGA.
I am guessing that SPI and I2C implementations already exist for
Xilinx FPGA's - any chance that drivers might already exist ?
I would prefer not to charge a client to reinvent something that
exists, or that can not serve a useful purpose.
I am not trying to imply that SPI or I2C are not useful, just that
they are communications channels, and unless they have outside I2C or
SPI hardware to talk to what purpose might they serve ?
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dhlii@dlasys.net http://www.dlasys.net
fax: 1.253.369.9244 Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
^ permalink raw reply
* Re: Access to PCI Expansion ROMs on PPC
From: Robin H. Johnson @ 2007-11-25 9:58 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev
In-Reply-To: <jey7cmfyp9.fsf@sykes.suse.de>
[-- Attachment #1: Type: text/plain, Size: 718 bytes --]
On Sun, Nov 25, 2007 at 10:42:42AM +0100, Andreas Schwab wrote:
> "Robin H. Johnson" <robbat2@gentoo.org> writes:
>
> > I put the card into an amd64 box, found the relevant 'rom' node ($ROM) under
> > /sys/device/pci*, and dumped it as follows:
> > # echo 1>$ROM
> Did you run it exactly like this? Because this will echo exactly one
> newline to $ROM. If you want to echo "1\n" you need to put a space
> between "1" and ">".
I did run the correct version, "echo 1 >$ROM", so that a "1\n" was
actually sent, and not a newline without a digit.
--
Robin Hugh Johnson
Gentoo Linux Developer & Infra Guy
E-Mail : robbat2@gentoo.org
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
[-- Attachment #2: Type: application/pgp-signature, Size: 321 bytes --]
^ permalink raw reply
* Re: Access to PCI Expansion ROMs on PPC
From: Robin H. Johnson @ 2007-11-25 11:15 UTC (permalink / raw)
To: Jon Smirl, linuxppc-dev
In-Reply-To: <9e4733910711241813r3412d459l95fb3b84cbee1d8a@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1648 bytes --]
On Sat, Nov 24, 2007 at 09:13:40PM -0500, Jon Smirl wrote:
> The ROM is mapped in drivers/pci/rom.c
>
> You could add some printks and see if there is an error and if the ROM
> is accessible
>
> rom = ioremap(start, *size);
> if (!rom) {
> /* restore enable if ioremap fails */
> if (!(res->flags & (IORESOURCE_ROM_ENABLE |
> IORESOURCE_ROM_SHADOW |
> IORESOURCE_ROM_COPY)))
> pci_disable_rom(pdev);
> return NULL;
> }
I started in there from that, and ended up in pci-sysfs.c...
The ROM memcpy in drivers/pci/pci-sysfs.c:pci_read_rom() is never running.
Relevant section of my debug output:
[ 306.396743] drivers/pci/pci-sysfs.c:577:pci_read_rom: size=0x0 rom=0xd000080082580000 off=0x0
[ 306.396764] drivers/pci/pci-sysfs.c:579:pci_read_rom: off >= size!
[ 306.396768] drivers/pci/pci-sysfs.c:588pci_read_rom: unmapping
Relevant snippet of my debug patching:
- if (off >= size)
+ printk(KERN_INFO "%s:%d:%s: size=0x%lx rom=0x%lx off=0x%lx\n", __FILE__,__LINE__,__FUNCTION__,size,rom,off);
+ if (off >= size) {
+ printk(KERN_INFO "%s:%d:%s: off >= size!\n", __FILE__,__LINE__,__FUNCTION__);
count = 0;
- else {
+ } else {
So next, why is it failing to decode the ROM size correctly?
pci_get_rom_size(), here I come.
--
Robin Hugh Johnson
Gentoo Linux Developer & Infra Guy
E-Mail : robbat2@gentoo.org
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
[-- Attachment #2: Type: application/pgp-signature, Size: 321 bytes --]
^ permalink raw reply
* Re: Access to PCI Expansion ROMs on PPC
From: Robin H. Johnson @ 2007-11-25 11:49 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20071125111535.GB14557@curie-int.orbis-terrarum.net>
[-- Attachment #1: Type: text/plain, Size: 1118 bytes --]
On Sun, Nov 25, 2007 at 03:15:35AM -0800, Robin H. Johnson wrote:
> I started in there from that, and ended up in pci-sysfs.c...
> The ROM memcpy in drivers/pci/pci-sysfs.c:pci_read_rom() is never running.
...
> [ 306.396743] drivers/pci/pci-sysfs.c:577:pci_read_rom: size=0x0 rom=0xd000080082580000 off=0x0
> [ 306.396764] drivers/pci/pci-sysfs.c:579:pci_read_rom: off >= size!
...
> So next, why is it failing to decode the ROM size correctly?
> pci_get_rom_size(), here I come.
Instead of the expected value of 0x55, 0xAA at the start of the ROM
size decode in pci_get_rom_size(), the first two readb() calls both
return either 0xFF or 0x00 so the size check fails right away.
The two cards with x86 firmware return 0xFF for those two readb()
instructions, while the X1900 with OF returns 0x00 for the readb().
Could one of the more knowledgeable folk for PPC intricacies suggest why
those readb calls are returning the wrong data?
--
Robin Hugh Johnson
Gentoo Linux Developer & Infra Guy
E-Mail : robbat2@gentoo.org
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
[-- Attachment #2: Type: application/pgp-signature, Size: 321 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox