New bindings use "fsl,t1040-ucc-uart" as the compatible for qe-uart.
So add it.
Signed-off-by: Zhao Qiang
---
drivers/tty/serial/ucc_uart.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/tty/serial/ucc_uart.c b/drivers/tty/serial/ucc_uart.c
index 1a7dc3c..481eb29 10
On Jul 10, 2012, at 2:52 AM, Zhicheng wrote:
> From: Zhicheng Fan
>
> Signed-off-by: Zhicheng Fan
> ---
> arch/powerpc/boot/dts/fsl/p1021si-post.dtsi | 16 ++-
> arch/powerpc/boot/dts/p1025rdb.dtsi | 40 +++
> 2 files changed, 55 insertions(+), 1 delet
From: Zhicheng Fan
Signed-off-by: Zhicheng Fan
---
arch/powerpc/boot/dts/fsl/p1021si-post.dtsi | 16 ++-
arch/powerpc/boot/dts/p1025rdb.dtsi | 40 +++
2 files changed, 55 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/boot/dts/fsl/p1021si-po
On Jun 18, 2010, at 8:22 AM, Chuck Meade wrote:
> From: Chuck Meade
>
> The UCC UART driver is missing a call to uart_update_timeout().
> Without this call, attempting to close the port after outputting large
> amounts of data (i.e. using tty and uart buffering) results in
On 06/24/2010 03:20 PM, Timur Tabi wrote:
Timur Tabi wrote:
I'd say that there are plenty of unknown issues with this driver/hardware.
For some reason, QE UART is just unreliable. I've had several people try to
use the QE for UART, and almost everyone has problems with it.
I finally got in to
Timur Tabi wrote:
> I'd say that there are plenty of unknown issues with this driver/hardware.
> For some reason, QE UART is just unreliable. I've had several people try to
> use the QE for UART, and almost everyone has problems with it.
I finally got in touch with one of the other development
>> You can use strategic printk debugging in the ucc_uart.c driver to
>> determine
>> on the Tx side what is going wrong. For example, after you tell the
>> QE to
>> output chars, wait a bit and printk out the BD. See if the QE is
>> clearing the
>> READY bit in that BD. That will tell you if th
are binary out of the firmware header file.
I have not used this script, since the existing binary worked for me.
But I am using only one UCC UART, so you are going beyond what I have done
with this firmware.
You can try to use that script to create a newer firmware binary from the header
in tha
http://opensource.freescale.com/firmware there is a script
make_qe_firmware.py
that Timur said would create a firmware binary out of the firmware header file.
I have not used this script, since the existing binary worked for me.
But I am using only one UCC UART, so you are going beyond what I have
On 06/24/2010 06:54 AM, Gary Thomas wrote:
I thought I had this working, but it seems to only work for UCC3.
Sadly, I can't get it to work on UCC4/UCC5/UCC8 at all.
Starting with UCC4, I have:
/* ttyQE0 (UCC4) */
serial_qe0: ser...@3200 {
device_type = "serial";
compatible = "ucc_uart";
cell-ind
I thought I had this working, but it seems to only work for UCC3.
Sadly, I can't get it to work on UCC4/UCC5/UCC8 at all.
Starting with UCC4, I have:
/* ttyQE0 (UCC4) */
serial_qe0: ser...@3200 {
device_type = "serial";
compatible = "ucc_uar
>> Also in the current Linux kernel, there is a dependence on the
>> correctness
>> of the "brg-frequency" property from the dts. Look up above
>> qe_setbrg() at
>> the qe_get_brg_clk() function. Before the return (there are multiple
>> return
>> points) printk the brg_clk being returned. That m
On 06/22/2010 01:01 PM, Chuck Meade wrote:
What BRGs did you choose for tx and rx?
BRG1& BRG2
OK
Get a scope on the UCC3 tx pin and try to output some chars. See if
there is
any digital activity on that pin at all. If you are looking at a
terminal for
output, there are too many things th
>> What BRGs did you choose for tx and rx?
>
> BRG1 & BRG2
OK
>> Get a scope on the UCC3 tx pin and try to output some chars. See if
>> there is
>> any digital activity on that pin at all. If you are looking at a
>> terminal for
>> output, there are too many things that could be wrong between
because I had to backport this UCC UART driver to an
older
Linux kernel, and that kernel was from before dts existed.
Add whatever you need to your dts to make it run in soft UART mode and
get
the firmware loaded. Use two different BRGs for tx and rx. Make sure
your
BRG choice is valid for your UCC3
mine because I had to backport this UCC UART driver to an
>> older
>> Linux kernel, and that kernel was from before dts existed.
>>
>> Add whatever you need to your dts to make it run in soft UART mode and
>> get
>> the firmware loaded. Use two different BRG
get the driver to operate in
Soft UART mode.
I hardcoded mine because I had to backport this UCC UART driver to an older
Linux kernel, and that kernel was from before dts existed.
Add whatever you need to your dts to make it run in soft UART mode and get
the firmware loaded. Use two different BRGs
do I need to follow the directions in
> Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe/firmware.txt
I did not do that, and I have it running here. I will say though that I
hardcoded the driver to run in soft UART mode. You will need to at least
add the appropriate line to your dts to get the driver
On 06/22/2010 09:28 AM, Chuck Meade wrote:
Hi Gary,
According to the errata, it looks like the MPC8358 is subject to
erratum QE_UART6. You'll need to use soft UART mode and load the
microcode patch. Once that is done you will also need to use two
different BRG's, one for tx and one for rx, sin
Gary Thomas wrote:
> I'm still trying to get UCC UART to work on my MPC8358 with
> the 2.6.33.3 kernel.
>
> When I try to send data to the port, there is no output, not
> even any interrupts on the device. What I see is that the UART
> driver seems to initialize fine and
>> Hi Gary,
>>
>> According to the errata, it looks like the MPC8358 is subject to
>> erratum QE_UART6. You'll need to use soft UART mode and load the
>> microcode patch. Once that is done you will also need to use two
>> different BRG's, one for tx and one for rx, since the soft UART mode
>> mic
On 06/22/2010 09:10 AM, Chuck Meade wrote:
On 06/22/2010 10:55 AM, Gary Thomas wrote:
I'm still trying to get UCC UART to work on my MPC8358 with
the 2.6.33.3 kernel.
When I try to send data to the port, there is no output, not
even any interrupts on the device. What I see is that the
On 06/22/2010 10:55 AM, Gary Thomas wrote:
> I'm still trying to get UCC UART to work on my MPC8358 with
> the 2.6.33.3 kernel.
>
> When I try to send data to the port, there is no output, not
> even any interrupts on the device. What I see is that the UART
> driver seems
I'm still trying to get UCC UART to work on my MPC8358 with
the 2.6.33.3 kernel.
When I try to send data to the port, there is no output, not
even any interrupts on the device. What I see is that the UART
driver seems to initialize fine and pushes characters into
the output bu
On Fri, Jun 18, 2010 at 8:22 AM, Chuck Meade wrote:
> From: Chuck Meade
>
> The UCC UART driver is missing a call to uart_update_timeout().
> Without this call, attempting to close the port after outputting large
> amounts of data (i.e. using tty and uart buffering) results in
From: Chuck Meade
The UCC UART driver is missing a call to uart_update_timeout().
Without this call, attempting to close the port after outputting large
amounts of data (i.e. using tty and uart buffering) results in long
timeouts before the port will actually be shut down.
For example, cat a
26 matches
Mail list logo
