[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RFC 16/24] xen/arm: Build DOM0 FDT by browsing the device tree structure
On 08/22/2013 02:49 PM, Ian Campbell wrote: > On Fri, 2013-08-16 at 22:05 +0100, Julien Grall wrote: >> Remove the usage of the FDT in benefit of the device tree structure. > > "in favour of" is what I think you mean. > >> The latter is easier to use and can embedded meta-data for Xen (ie: is the >> device is used by Xen...). >> >> Signed-off-by: Julien Grall <julien.grall@xxxxxxxxxx> >> --- >> xen/arch/arm/domain_build.c | 270 >> ++++++++++++++++--------------------------- >> 1 file changed, 101 insertions(+), 169 deletions(-) >> >> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c >> index 604ec1c..c8f24ed 100644 >> --- a/xen/arch/arm/domain_build.c >> +++ b/xen/arch/arm/domain_build.c >> @@ -63,10 +63,10 @@ struct vcpu *__init alloc_dom0_vcpu0(void) >> } >> >> static int set_memory_reg_11(struct domain *d, struct kernel_info *kinfo, >> - const void *fdt, const u32 *cell, int len, >> - int address_cells, int size_cells, u32 >> *new_cell) >> + const struct dt_property *pp, >> + const struct dt_device_node *np, __be32 >> *new_cell) >> { >> - int reg_size = (address_cells + size_cells) * sizeof(*cell); >> + int reg_size = dt_cells_to_size(dt_n_addr_cells(np) + >> dt_n_size_cells(np)); >> paddr_t start; >> paddr_t size; >> struct page_info *pg; >> @@ -90,7 +90,7 @@ static int set_memory_reg_11(struct domain *d, struct >> kernel_info *kinfo, >> if ( res ) >> panic("Unable to add pages in DOM0: %d\n", res); >> >> - device_tree_set_reg(&new_cell, address_cells, size_cells, start, size); >> + dt_set_range(&new_cell, np, start, size); >> >> kinfo->mem.bank[0].start = start; >> kinfo->mem.bank[0].size = size; >> @@ -100,25 +100,30 @@ static int set_memory_reg_11(struct domain *d, struct >> kernel_info *kinfo, >> } >> >> static int set_memory_reg(struct domain *d, struct kernel_info *kinfo, >> - const void *fdt, const u32 *cell, int len, >> - int address_cells, int size_cells, u32 *new_cell) >> + const struct dt_property *pp, >> + const struct dt_device_node *np, __be32 *new_cell) >> { >> - int reg_size = (address_cells + size_cells) * sizeof(*cell); >> + int reg_size = dt_cells_to_size(dt_n_addr_cells(np) + >> dt_n_size_cells(np)); >> int l = 0; >> + unsigned int bank = 0; >> u64 start; >> u64 size; >> + int ret; >> >> if ( platform_has_quirk(PLATFORM_QUIRK_DOM0_MAPPING_11) ) >> - return set_memory_reg_11(d, kinfo, fdt, cell, len, address_cells, >> - size_cells, new_cell); >> + return set_memory_reg_11(d, kinfo, pp, np, new_cell); >> >> - while ( kinfo->unassigned_mem > 0 && l + reg_size <= len >> + while ( kinfo->unassigned_mem > 0 && l + reg_size <= pp->length >> && kinfo->mem.nr_banks < NR_MEM_BANKS ) >> { >> - device_tree_get_reg(&cell, address_cells, size_cells, &start, >> &size); >> + ret = dt_device_get_address(np, bank, &start, &size); >> + if ( ret ) >> + panic("Unable to retrieve the bank %u for %s\n", > > Dropping "the" sounds more natural to me. Perhaps say "memory bank" too? I will fix it. > >> -static void make_hypervisor_node(void *fdt, int addrcells, int sizecells) >> +static int make_hypervisor_node(void *fdt, const struct dt_device_node >> *parent) >> { >> const char compat[] = >> "xen,xen-"__stringify(XEN_VERSION)"."__stringify(XEN_SUBVERSION)"\0" >> "xen,xen"; >> - u32 reg[4]; >> - u32 intr[3]; >> - u32 *cell; >> + __be32 reg[4]; >> + __be32 intr[3]; >> + __be32 *cells; >> + int res; >> + int addrcells = dt_n_addr_cells(parent); >> + int sizecells = dt_n_size_cells(parent); >> + >> + DPRINT("Create hypervisor node\n"); > > Not sure there is any point in this print unless you also add DPRINT of > the things we put into it. I will add more print. I think it can be usefull for debugging the device tree. >> >> /* >> * Sanity-check address sizes, since addresses and sizes which do >> [...] > >> izecells)); >> + cells = ®[0]; >> + dt_set_cell(&cells, addrcells, 0xb0000000); >> + dt_set_cell(&cells, sizecells, 0x20000); > > Aside: this really ought to become dynamic, based on finding a hole in > the physical address map... Is this address used somewhere in Xen? I didn't find any place. > > [...] >> + res = fdt_property(fdt, "interrupts", intr, sizeof(intr[0]) * 3); >> + if ( res ) >> + return res; > > the * 3 come from the interrupt-controller nodes properties I think? > Should we assert somewhere that they match? Perhaps we would already die > if it weren't anyway? The GIC node always has #interrupt-size equals to 3. I don't think an assert is necessary. > >> @@ -454,7 +374,8 @@ static int handle_node(struct domain *d, const struct >> dt_device_node *np) >> if ( dt_match_node(skip_matches, np ) ) >> return 0; >> >> - if ( dt_device_used_by(np) != DOMID_XEN ) >> + if ( dt_device_used_by(np) != DOMID_XEN && >> + !dt_device_type_is_equal(np, "memory") ) > > Can we get a comment about why memory is special here please? I will add it. > >> { >> res = map_device(d, np); >> > > Ian. > -- Julien Grall _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |