RE: Bug in drivers/serial/of_serial.c?
On Thursday, November 19, 2009, Arnd Bergmann wrote:
> I'd still add support for the compatible="ns16550a" property
> so that we do the right thing for future systems.
>
OK...
---
Xilinx 16550 UART is actually 16550A-compatible
Signed-off-by: Alon Ziv
diff --git a/drivers/serial/of_serial.c b/drivers/serial/of_serial.c
index 02406ba..241be77 100644
--- a/drivers/serial/of_serial.c
+++ b/drivers/serial/of_serial.c
@@ -161,7 +161,9 @@ static int of_platform_serial_remove(struct
of_device *ofdev)
static struct of_device_id __devinitdata of_platform_serial_table[] = {
{ .type = "serial", .compatible = "ns8250", .data = (void
*)PORT_8250, },
{ .type = "serial", .compatible = "ns16450", .data = (void
*)PORT_16450, },
+ { .type = "serial", .compatible = "xlnx,xps-uart16550-2.00.b",
.data = (void *)PORT_16550A, },
{ .type = "serial", .compatible = "ns16550", .data = (void
*)PORT_16550, },
+ { .type = "serial", .compatible = "ns16550a", .data = (void
*)PORT_16550A, },
{ .type = "serial", .compatible = "ns16750", .data = (void
*)PORT_16750, },
{ .type = "serial", .compatible = "ns16850", .data = (void
*)PORT_16850, },
#ifdef CONFIG_SERIAL_OF_PLATFORM_NWPSERIAL
**
IMPORTANT: The contents of this email and any attachments are confidential.
They are intended for the
named recipient(s) only.
If you have received this email in error, please notify the system manager or
the sender immediately and do
not disclose the contents to anyone or make copies thereof.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: Bug in drivers/serial/of_serial.c?
Hi,
On Thursday, November 19, 2009, Arnd wrote:
> In that case, add another entry for the device encoded in the firmware
> itself. The ns16550 entry should be the second one after a more
specific
> one telling which device it is exactly.
>
Is the following better?
---
[PATCH] Xilinx 16550 UART is actually 16550A-compatible
diff --git a/drivers/serial/of_serial.c b/drivers/serial/of_serial.c
index 02406ba..40bf8f4 100644
--- a/drivers/serial/of_serial.c
+++ b/drivers/serial/of_serial.c
@@ -161,6 +161,7 @@ static int of_platform_serial_remove(struct
of_device *ofdev)
static struct of_device_id __devinitdata of_platform_serial_table[] = {
{ .type = "serial", .compatible = "ns8250", .data = (void
*)PORT_8250, },
{ .type = "serial", .compatible = "ns16450", .data = (void
*)PORT_16450, },
+ { .type = "serial", .compatible = "xlnx,xps-uart16550-2.00.b",
.data = (void *)PORT_16550A, },
{ .type = "serial", .compatible = "ns16550", .data = (void
*)PORT_16550, },
{ .type = "serial", .compatible = "ns16750", .data = (void
*)PORT_16750, },
{ .type = "serial", .compatible = "ns16850", .data = (void
*)PORT_16850, },
**
IMPORTANT: The contents of this email and any attachments are confidential.
They are intended for the
named recipient(s) only.
If you have received this email in error, please notify the system manager or
the sender immediately and do
not disclose the contents to anyone or make copies thereof.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH/RFC] Booting Xilinx ML510 board using SystemACE
Hi, On Monday, November 16, 2009, Stephen wrote: > There are at least two other ways that you might be able to reset a > board: > 1) Internally through the ICAP device. > 2) Through a GPIO connected externally to the reset logic. > Unfortunately none of these is relevant for the specific board in question (Xilinx ML510 reference system)... > Probably it would be best to have a mechanism in the device tree which > references the reset mechanism? I am sorely lacking in expertise for this :(, and wouldn't even know where to begin... Is it possible at all to add custom information into the device tree? And even if yes--how will platform code bind to the reset mechanism? > [...] In any event, you probably don't want a driver to > eplicitly reference the plaform code. If you want to do it explicitly > like this, it would better to have the plaform code reference the driver > mechanism. I don't see how this can be done: if the driver is to publish some "driver_reset_system" function to the platform code, it needs _some_ mechanism for telling this fact to the system... And such a mechanism won't look all that different from my callback, IMO (except it may be slightly prettied up). Of course, one obvious thing that must be done is move this code out of arch/powerpc/platforms/44x/virtex.c and into (e.g.) arch/powerpc/kernel/setup-common.c, and add some "set_machine_restart_function" wrapper to access it more cleanly (also defining this function as a null function when inapplicable). If this satisfies your standards, I can easily post an updated patch :) -az ** IMPORTANT: The contents of this email and any attachments are confidential. They are intended for the named recipient(s) only. If you have received this email in error, please notify the system manager or the sender immediately and do not disclose the contents to anyone or make copies thereof. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: Bug in drivers/serial/of_serial.c?
Hi,
On Monday, November 16, 2009, Arnd wrote:
> > - { .type = "serial", .compatible = "ns16550", .data = (void
*)PORT_16550, },
> > + { .type = "serial", .compatible = "ns16550", .data = (void
*)PORT_16550A, },
>
> Does not seem logical. If the device claims compatibility with
ns16550, we should
> not automatically assume it's an ns16550a. Why not add another line
for
>
Unfortunately, there is no way to change what the device claims--it's
encoded into the OpenFirmware tree by the EDK tools.
And, in any case, the device is actually not lying: it _is_ compatible
with NS16550--just with a non-buggy one. Unfortunately the kernel
driver for 8250-class UARTs makes the conservative choice to assume any
16550 is one of the (early, buggy) revisions where the FIFO was
non-functional; any 16550 with working UART is classed as a 16550A.
-az
**
IMPORTANT: The contents of this email and any attachments are confidential.
They are intended for the
named recipient(s) only.
If you have received this email in error, please notify the system manager or
the sender immediately and do
not disclose the contents to anyone or make copies thereof.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH/RFC] Booting Xilinx ML510 board using SystemACE
I am using locally the attached (hackish) patch; could someone propose a
way to make it acceptable to mainline (or should I just keep this
quiet)?
diff --git a/arch/powerpc/platforms/44x/virtex.c
b/arch/powerpc/platforms/44x/virtex.c
index cf96cca..749a330 100644
--- a/arch/powerpc/platforms/44x/virtex.c
+++ b/arch/powerpc/platforms/44x/virtex.c
@@ -51,6 +51,16 @@ static int __init virtex_probe(void)
return 1;
}
+void (*board_reset_system)(char *);
+EXPORT_SYMBOL(board_reset_system);
+
+static void virtex_reset_system(char *cmd)
+{
+ if (board_reset_system)
+ board_reset_system(cmd);
+ ppc4xx_reset_system(cmd);
+}
+
define_machine(virtex) {
.name = "Xilinx Virtex440",
.probe = virtex_probe,
@@ -58,5 +68,5 @@ define_machine(virtex) {
.init_IRQ = xilinx_intc_init_tree,
.get_irq= xilinx_intc_get_irq,
.calibrate_decr = generic_calibrate_decr,
- .restart= ppc4xx_reset_system,
+ .restart= virtex_reset_system,
};
diff --git a/drivers/block/xsysace.c b/drivers/block/xsysace.c
index b20abe1..f3b4ab9 100644
--- a/drivers/block/xsysace.c
+++ b/drivers/block/xsysace.c
@@ -950,6 +950,19 @@ static struct block_device_operations ace_fops = {
.getgeo = ace_getgeo,
};
+extern void (*board_reset_system)(char *);
+static struct ace_device *the_ace_device;
+
+/*
+ * Board reset using ACE (forced FPGA reconfigure)
+ */
+static void ace_reset_system(char *cmd)
+{
+ printk(KERN_EMERG "ace_reset_system: attempting suicide\n");
+ ace_out(the_ace_device, ACE_CTRL, ACE_CTRL_FORCECFGMODE |
+ ACE_CTRL_CFGMODE | ACE_CTRL_CFGSTART | ACE_CTRL_CFGSEL);
+}
+
/*
* SystemACE device setup/teardown code
*/
@@ -1040,6 +1053,9 @@ static int __devinit ace_setup(struct ace_device
*ace)
val |= ACE_CTRL_DATABUFRDYIRQ | ACE_CTRL_ERRORIRQ;
ace_out(ace, ACE_CTRL, val);
+ board_reset_system = ace_reset_system;
+ the_ace_device = ace;
+
/* Print the identification */
dev_info(ace->dev, "Xilinx SystemACE revision %i.%i.%i\n",
(version >> 12) & 0xf, (version >> 8) & 0x0f, version &
0xff);
**
IMPORTANT: The contents of this email and any attachments are confidential.
They are intended for the
named recipient(s) only.
If you have received this email in error, please notify the system manager or
the sender immediately and do
not disclose the contents to anyone or make copies thereof.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Bug in drivers/serial/of_serial.c?
As of commit eedacbf0, drivers/serial/of_serial.c forces the serial core
to recognize the xps-uart16550-2.00.b as an NS16550 (which had no FIFO).
Prior to this commit, the kernel's auto-configuration logic would
correctly recognize the UART as NS16550A (with 16-byte FIFO).
The following patch corrects the issue in what I believe to be the
correct way:
---
Xilinx 16550 UART is actually 16550A-compatible
diff --git a/drivers/serial/of_serial.c b/drivers/serial/of_serial.c
index 02406ba..78267af 100644
--- a/drivers/serial/of_serial.c
+++ b/drivers/serial/of_serial.c
@@ -161,7 +161,7 @@ static int of_platform_serial_remove(struct
of_device *ofdev)
static struct of_device_id __devinitdata of_platform_serial_table[] = {
{ .type = "serial", .compatible = "ns8250", .data = (void
*)PORT_8250, },
{ .type = "serial", .compatible = "ns16450", .data = (void
*)PORT_16450, },
- { .type = "serial", .compatible = "ns16550", .data = (void
*)PORT_16550, },
+ { .type = "serial", .compatible = "ns16550", .data = (void
*)PORT_16550A, },
{ .type = "serial", .compatible = "ns16750", .data = (void
*)PORT_16750, },
{ .type = "serial", .compatible = "ns16850", .data = (void
*)PORT_16850, },
#ifdef CONFIG_SERIAL_OF_PLATFORM_NWPSERIAL
**
IMPORTANT: The contents of this email and any attachments are confidential.
They are intended for the
named recipient(s) only.
If you have received this email in error, please notify the system manager or
the sender immediately and do
not disclose the contents to anyone or make copies thereof.
03-of_serial-16550A.patch
Description: 03-of_serial-16550A.patch
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
