On Thu, Mar 30, 2023 at 5:54 PM Chris Johns <chr...@rtems.org> wrote: > > On 31/3/2023 2:55 am, Alex White wrote: > > On Wed, Mar 29, 2023 at 11:04 PM Chris Johns <chr...@rtems.org> wrote: > >> > >> On 30/3/2023 12:26 pm, Sam Price wrote: > >>> Same IP as the regular KCU105. > >>> The current uart ip is dependent on the fpga. > >>> I don't believe this modifies the kcu105 bsp, but allows other bsps to > >>> support up to 4 uarts. > >> > >> I am not sure if this patch is OK. If the UART driver is needed for a > >> console > >> does that limits how it's configuration can be handled? If so that means > >> the > >> patch is OK. Adding options for a user's custom IP is questionable. > > > > This patch allows the user to use multiple instances of the same UART IP > > (AXI UART Lite v2.0) which is currently the only IP supported by the BSP. > > What happens if a user needs more than 4 ports? I was discussing such a > project > recently with someone and Microblaze may be an option? > > I do not have a better solution at the moment so I am just understand the what > we accept and why plus how we manage it.
I see your point. A user could come along needing 5, 6, or 7 ports. It's not sustainable to keep adding ports to the driver like this. It doesn't scale well at all. We probably need a build option for the maximum number of ports and a way to configure the ports at runtime. This should be easy if the user is using a device tree, but if they aren't, they need a way to specify the configuration of each port. It's late so I can't think of a good way to do this right now. Maybe only allow some small number of ports (one?) to be specified if the user isn't using a device tree? Alex _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel