> -----Original Message----- > From: Peter Korsgaard [mailto:jacmet@xxxxxxxxx] On Behalf Of Peter Korsgaard > Sent: Wednesday, January 20, 2010 12:24 PM > To: John Linn > Cc: linux-serial@xxxxxxxxxxxxxxx; grant.likely@xxxxxxxxxxxx; michal.simek@xxxxxxxxxxxxx; > john.williams@xxxxxxxxxxxxx > Subject: Re: [PATCH] uartlite: move from byte accesses to word accesses > > >>>>> "John" == John Linn <john.linn@xxxxxxxxxx> writes: > > John> From: XAQ IP Librarian <abq_iplib@xaqiptest40.(none)> > John> Byte accesses for I/O devices in Xilinx IP is going to be less > John> desired in the future such that the driver is being changed to > John> use 32 bit accesses. > > Why is it less desired? We are wanting to use our IP cores over a PCIe bus and it only allows 32 bit accesses. > > Back when I wrote the driver, I used 8bit access on purpose to be > independent of register widths / endianess. > > We have used the driver on systems where (something looking like) a > uartlite was behind a 16bit bus, so doing 32bit accesses would require > double the bus accesses. I understand. Most of our customers are using a 32 bit bus so that this wouldn't be a problem for most people. We could do some kind of conditional compilation for the accesses, but it's certainly less desired. We could make 32 bit the default and then allow a kernel config to change the access size. > > Btw, the abq_iplib@xaqiptest40 address is (obviously) invalid. Yes, I saw that after it went out, I'll have to find the source of that weirdness. Thanks, John > > -- > Bye, Peter Korsgaard This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
