[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH V2 3/3] xen/arm: Add SCIFA UART support for early printk

On 21.02.19 20:43, Julien Grall wrote:
Hi Oleksandr,

Hi Julien

On 2/21/19 6:22 PM, Oleksandr wrote:
=>>>>> Actually, the main difference for the "early printk" support is in
two reg offsets:

+#define SCIFA_SCASSR   0x14    /* Serial status register */
+#define SCIFA_SCAFTDR  0x20    /* Transmit FIFO data register */

+#define SCIF_SCFSR             0x10    /* Serial status register */
+#define SCIF_SCFTDR            0x0c    /* Transmit FIFO data register */

I am not mistaken, we will have to introduce two options to cover this case, as the offsets are not correlated with each other, no?

You don't need two options. For instance, you can only introduce an option SCIF_VERSION that would be 0 for SCIF and 61 (ascii 'a') for SCIFA.

Then in the code, you can use SCIF_VERSION to decides which sets of macros you are using.

I think I understand the idea. Will try.

Is it something you would like to see?

Your solution below require to overwrite EARLY_PRINTK_INC and not very easy to extend of other version (e.g scifb). As I suggested earlier, we can introduce an option the same way REG_SHIFT exist for 8250. The definition of CONFIG_EARLY_PRINTK is:


<OTHER_OPTIONS> would be the version. Nothing for SCIF and A for SCFIA.

Then in Rules.mk, you would have something like:

ifneq ($(word 3,$(EARLY_PRINTK_CFG)),)

debug-scif.inc would then contain:

#define foo
#define bar
#define foo
#define bar

The CONFIG_EARLY_PRINTK_VERSION_NONE is here to help catching new addition. If someone if using a different version, it would not compile. Also, the code in Rules.mk is generic enough to extend for other version (e.g scifb).

Does it make sense?

Absolutely. Thank you



Oleksandr Tyshchenko

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.