-
Notifications
You must be signed in to change notification settings - Fork 93
Add support for SiFive Premier P550 #190
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
d0dc528 to
aacc64b
Compare
|
I believe this is ready for review now. |
Signed-off-by: Ivan-Velickovic <i.velickovic@unsw.edu.au>
Signed-off-by: Ivan-Velickovic <i.velickovic@unsw.edu.au>
Signed-off-by: Ivan-Velickovic <i.velickovic@unsw.edu.au>
lsf37
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good from my side.
Longer-term we should try to figure out a mechanism where we can test compilation for new platforms before they are merged. For now, I think we still have to merge first and then see if anything breaks once we can add it to CI.
| #include <stdint.h> | ||
| #include <stdbool.h> | ||
|
|
||
| /* These values correspond to the DTS node 'soc/timer@0x51840000' */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please add a comment to say what timer peripheral is being implemented, and if there are multiple, which one is used. Both the datasheet names and the compat strings would be handy, but either is fine.
| #define ESWIN_TIMER_IRQ 0x159 | ||
|
|
||
| /* This is 24MHz */ | ||
| #define ESWIN_TIMER_TICKS_PER_SECOND 0x16e3600 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Then why not write 24000000 or (24 * 1000 * 1000)?
| #define ESWIN_TIMER_ENABLED 0x1 | ||
| #define ESWIN_TIMER_DISABLED 0x0 | ||
| #define ESWIN_TIMER_MODE_FREE_RUNNING 0x0 | ||
| #define ESWIN_TIMER_MODE_USER_DEFINED (1 << 1) | ||
| #define ESWIN_TIMER_IRQ_UNMASK 0x0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please do (0 << n) so you at least document the bit index that defines this. But it's weird to have defines for 0, you can just say in a comment above the init what the result will be. I'd probably make defines for all settings (with comments behind them for what it means when it's not set) and then one define for the chosen cfg.
| assert(timer); | ||
| assert(timer->regs); | ||
|
|
||
| timer->regs->ctrl &= 0xfffffffe; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| timer->regs->ctrl &= 0xfffffffe; | |
| timer->regs->ctrl &= ~0x1; |
Or set it to just 0 and init it on enable.
| uint64_t value_subsecond_ns = | ||
| (value_subsecond_ticks * NS_IN_S) / ESWIN_TIMER_TICKS_PER_SECOND; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One line please. If it doesn't fit, consider dropping the value_ prefix.
Doing the calculation this way is more exact compared to what I did for the imx93 timer driver.
| handle_irq_wrapper, | ||
| &timers->callback_data); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I really don't understand the point of handle_irq_wrapper, but everyone is using it.
| irqs[0], | ||
| handle_irq_wrapper, | ||
| &timers->callback_data); | ||
| assert(irq_id >= 0); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, you need to store irq_id to use it in destroy.
|
|
||
| int uart_getchar(ps_chardevice_t *d) | ||
| { | ||
| while ((*REG_PTR(d->vaddr, UART_LSR) & BIT(0))); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would be nice to have a define for bit 0, like you did for THRE.
| uart_putchar(d, '\r'); | ||
| } | ||
|
|
||
| while ((*REG_PTR(d->vaddr, UART_LSR) & UART_LSR_THRE) == 0); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably better to check whether the buffer is not full, if there is a queue larger than one byte in the device.
(Ideally printf implementations would wait till the buffer is empty before writing a new line and keep transmitting characters while the buffer has space once they started. That way you can share a UART with multiple users like a Linux VM or other cores pretty well, without it becoming a mess. But oh well.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The NS16650a/DesignWare APB Uart gateware used by the p550 is terrible and (a) the ns16650a doesn't provide a standard TX FIFO not full bit, so practically no software uses the one in the snps,dw-apb-uart (Linux definitely doesn't); and (b) as far as we can tell the TFNF bit also remains as 0 on the P550: au-ts/sddf#443.
See also the copious documentation I wrote about this: https://github.com/au-ts/sddf/blob/904ef0019d0404cb107dcca355126ae9c20cc0be/drivers/serial/ns16550a/uart.c#L43-L87, especially the linked Ultimate PutChar. Linux et al use this implementation where they check "if empty" then write a full FIFO sized without reading any registers, which has issues with sharing drivers as you mentioned.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh well, never mind then.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reading the linked pdf, you can initially poll TEMT to see whether any data is queued and hence there is printing in progress, and poll THRE before queueing consequent bytes. That would avoid the interleaved output if everyone would do this.
Anyway, with the above scheme THRE is used as buffer not empty already, so the code as it is is fine.
| dev->ioops = *ops; | ||
| dev->flags = SERIAL_AUTO_CR; | ||
|
|
||
| *REG_PTR(dev->vaddr, 0x8) = 1; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Defines for this would be nice.
|
I see I have been too slow. Please fix issues in additional PR. |
|
@Indanz thanks for the review, I won't get to it this week probably but I do intend on fixing everything you brought up. |
Draft since I have to write the timer driver. The serial driver is exactly the same as the one in #167.