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:
CONFIG_EARLY_PRINTK=<INC>,<BASE_ADDRESS>,<OTHER_OPTIONS>
<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)),)
CFLAGS-y += -DCONFIG_EARLY_PRINTK_VERSION_$(word 3, $(EARLY_PRINTK_CFG)
else
CFLAGS-y += -DCONFIG_EARLY_PRINTK_VERSION_NONE
endif
debug-scif.inc would then contain:
#ifdef CONFIG_EARLY_PRINTK_VERSION_A
#define foo
#define bar
#elifdef CONFIG_EARLY_PRINTK_VERSION_NONE
#define foo
#define bar
#endif
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
Cheers,
--
Regards,
Oleksandr Tyshchenko
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel