On Fri, Feb 8, 2013 at 9:19 AM, Claudio Scordino
<claudio@xxxxxxxxxxxxxxx> wrote:
>> The sysfs entry ttgr is there, but I couldn't manage to assign a
>> value. It is always read back as zero and seams to have no effect on
>> the gap between sent chars. I am not so familiar with sysfs, but I
>> could imagine that something white the deduction of the port pointer
>> may be wrong.
>
>
> Quite strange.
>
I found my mistake, the sysfs entries are lying under
/sys/devices/platform/atmel_usart.*
as expected, but they are numbered different to the /dev/ttyAT*
devices. So I used the entry of the DBGU. The DBGU lacks some features
the normal USARTs have include the TTGR. I wonder why the atmel_serial
driver not checks if the device is the DBGU or a USART and in case
DBGU don't allow to set features (example character length) not
supported?
I have split you patch in two parts. I think the TTGR sysfs entries
are a different concern than the RS485 timing issues. Please find
attached the TTGR patch with some modifications I made:
- simplify obtaining the uart_port pointer using dev_get_drvdata()
- present ttgr sysfs entry only when port is not the DBGU
The function is_uart_port_dbgu() is a kind of hack, I found no
better way to determinate the
type of the port. Perhaps we should add a is_dbgu field to the
atmel_uart_data structure which
is set by the CPU specific initialization.
Next I will have a look on the RS485 timing.
Regards,
Guido
Attachment:
0001-add-generic-atmel-serial-TTGR-support.patch
Description: Binary data
