Add support for UART serial ports using a Freescale QUICC Engine
(found on some MPC83xx and MPC85xx SOCs).
Updated booting-without-of.txt to define new properties for a QE UART node,
and a new node definition that describes uploaded QE firmware.
Because of a silicon bug in some QE-enabled SOCs (e
On Thu, Jan 03, 2008 at 12:26:27PM -0600, Timur Tabi wrote:
> Scott Wood wrote:
>
> +static struct of_platform_driver ucc_uart_of_driver = {
> +.owner = THIS_MODULE,
> +.name = "ucc_uart",
> >>> Maybe better fsl,ucc_uart?
> >
> > fsl,qe-uart is de
Timur Tabi wrote:
> Scott Wood wrote:
>
> +static struct of_platform_driver ucc_uart_of_driver = {
> +.owner = THIS_MODULE,
> +.name = "ucc_uart",
Maybe better fsl,ucc_uart?
>>
>> fsl,qe-uart is defined by Documentation/powerpc/booting-without-of.txt.
>
> Wait,
Scott Wood wrote:
+static struct of_platform_driver ucc_uart_of_driver = {
+ .owner = THIS_MODULE,
+ .name = "ucc_uart",
>>> Maybe better fsl,ucc_uart?
>
> fsl,qe-uart is defined by Documentation/powerpc/booting-without-of.txt.
Wait, I'm confused. What does t
On Sat, Dec 29, 2007 at 04:10:54PM -0600, Timur Tabi wrote:
> Anton Vorontsov wrote:
>
> >> + [EMAIL PROTECTED] {
> >> + device_type = "serial";
> >> + compatible = "ucc_uart";
> >> + model = "UCC";
> >
> > model isn't used, is it needed
Anton Vorontsov wrote:
>> +[EMAIL PROTECTED] {
>> +device_type = "serial";
>> +compatible = "ucc_uart";
>> +model = "UCC";
>
> model isn't used, is it needed at all?
I have no idea, but all the other UCC nodes have it, so I'
On Fri, Dec 07, 2007 at 10:44:30AM -0600, Timur Tabi wrote:
> Add support for UART serial ports using a Freescale QUICC Engine
> (found on some MPC83xx and MPC85xx SOCs).
>
> Updated booting-without-of.txt to define new properties for a QE UART node,
> and a new node definition that describes uplo
Add support for UART serial ports using a Freescale QUICC Engine
(found on some MPC83xx and MPC85xx SOCs).
Updated booting-without-of.txt to define new properties for a QE UART node,
and a new node definition that describes uploaded QE firmware.
Because of a silicon bug in some QE-enabled SOCs (e
Arnd Bergmann wrote:
> In that case, I think the right solution would be to have different properties
> in the device tree, depending on whether or not you have a soft-uart and
> whether
> you need to download the microcode.
> Having only a compile time option is very bad because it prevents you
On Wed, 5 Dec 2007 00:56:39 +0100
Arnd Bergmann wrote:
> On Wednesday 05 December 2007, Timur Tabi wrote:
> > Arnd Bergmann wrote:
> >
> > > You can argue that the QS is really a DMA device, but in that
> > > case you should convert the driver to use the DMA mapping
> > > interfaces correctly, wh
On Wednesday 05 December 2007, Timur Tabi wrote:
> Arnd Bergmann wrote:
>
> > You can argue that the QS is really a DMA device, but in that case you
> > should convert the driver to use the DMA mapping interfaces correctly,
> > which I would consider overkill.
>
> I'm confused. I'm already calli
Arnd Bergmann wrote:
> You can argue that the QS is really a DMA device, but in that case you
> should convert the driver to use the DMA mapping interfaces correctly,
> which I would consider overkill.
I'm confused. I'm already calling dma_alloc_coherent() and getting a
dma_addr_t
back. Why d
Arnd Bergmann wrote:
> On Wednesday 05 December 2007, Scott Wood wrote:
>>> You can argue that the QS is really a DMA device, but in that
>>> case you should convert the driver to use the DMA mapping
>>> interfaces correctly, which I would consider overkill.
>> Why is it overkill?
>>
>
> Well, if
On Wednesday 05 December 2007, Scott Wood wrote:
>
> > You can argue that the QS is really a DMA device, but in that case you
> > should convert the driver to use the DMA mapping interfaces correctly,
> > which I would consider overkill.
>
> Why is it overkill?
>
Well, if the QE can never be us
Arnd Bergmann wrote:
> From a code clarity perspective, the interesting point is that dma_addr_t is
> what comes back from the functions in dma-mapping.h. If you don't use them,
> a physical address is phys_addr_t.
>
> You can argue that the QS is really a DMA device, but in that case you
> should
On Tuesday 04 December 2007, Timur Tabi wrote:
> When I program the DMA controller, I give it a dma_addr_t. And yet, the DMA
> controller and the QE are both devices on the SoC. So if the DMA controller
> takes a dma_addr_t, then shouldn't the QE also take one?
>
>From a code clarity perspect
Arnd Bergmann wrote:
> I'm guessing that you don't really mean dma_addr_t here, but rather
> phys_addr_t, which is something different.
Now that I think about it, I don't know which is correct. The value is plugged
into the pointer register of a buffer descriptor, and the QE performs a
DMA-lik
Arnd Bergmann wrote:
> Can you use the driver on CPUs without this particular bug when it's built
> in Soft-UART mode?
No, you have to build with Soft-UART mode turned off. Soft-UART mode actually
uses the HMC mode of the QE and hacks it up to act like a UART.
The only way to know at runtime w
On Tuesday 04 December 2007, Timur Tabi wrote:
> Add support for UART serial ports using a Freescale QUICC Engine
> (found on some MPC83xx and MPC85xx SOCs).
>
> Because of a silicon bug in some QE-enabled SOCs (e.g. 8323 and 8360), a new
> microcode is required. This microcode implements UART via
Add support for UART serial ports using a Freescale QUICC Engine
(found on some MPC83xx and MPC85xx SOCs).
Because of a silicon bug in some QE-enabled SOCs (e.g. 8323 and 8360), a new
microcode is required. This microcode implements UART via a work-around,
hence it's called "Soft-UART". This driv
20 matches
Mail list logo
