On Fri, Jun 09, 2023 at 03:06:36PM +0100, Nikos Nikoleris wrote:
> On 09/06/2023 08:21, Andrew Jones wrote:
> > On Thu, Jun 08, 2023 at 10:24:11AM -0700, Nadav Amit wrote:
> > >
> > >
> > > > On Jun 8, 2023, at 10:18 AM, Nadav Amit <nadav.amit@xxxxxxxxx> wrote:
> > > >
> > > >
> > > > On May 30, 2023, at 9:09 AM, Nikos Nikoleris <nikos.nikoleris@xxxxxxx> wrote:
> > > >
> > > > >
> > > > > +static void uart0_init_acpi(void)
> > > > > +{
> > > > > + struct spcr_descriptor *spcr = find_acpi_table_addr(SPCR_SIGNATURE);
> > > > > +
> > > > > + assert_msg(spcr, "Unable to find ACPI SPCR");
> > > > > + uart0_base = ioremap(spcr->serial_port.address, spcr->serial_port.bit_width);
> > > > > +}
> > > >
> > > > Is it possible as a fallback, is SPCR is not available, to UART_EARLY_BASE as
> > > > address and bit_width as bit-width?
> > > >
> > > > I would appreciate it, since it would help my setup.
> > > >
> > >
> > > Ugh - typo, 8 as bit-width for the fallback (ioremap with these parameters to
> > > make my request clear).
> > >
> >
> > That sounds reasonable to me. Nikos, can you send a fixup! patch? I'll
> > squash it in.
> >
>
> I am not against this idea, but it's not something that we do when we setup
> the uart through FDT. Should ACPI behave differently? Is this really a
> fixup? Either ACPI will setup things differently or we'll change the FDT and
> ACPI path.
Yeah, you're right. It's not really a fixup and I forgot that we abort
when the DT doesn't have a uart node too. Let's leave this as is for now.
We can do a follow patch which adds a config that says "use the early
uart and don't bother looking for another" which we'd apply to both ACPI
and DT.
Thanks,
drew
