search for: dt_device_node

Biggest change is to switch the new DTB node to /xen-core-devices instead of /xen at Stefano''s request. I also dropped the few patches title HACK etc which weren''t supposed to be there and fixed up some bits and pieces which folks commented on. George, WRT the freeze I think this is functionality which we cannot ship Xen 4.4 without. The impact is entirely constrained to the

...9;'t start with ''/'', we assuming that it''s an alias. > * @options: UART speficic options (see in each UART driver) > */ > static char __initdata opt_dtuart[30] = ""; > @@ -38,7 +39,7 @@ void __init dt_uart_init(void) > { > struct dt_device_node *dev; > int ret; > - const char *devalias = opt_dtuart; > + const char *devpath = opt_dtuart; > char *options; > > if ( !console_has("dtuart") || !strcmp(opt_dtuart, "") ) > @@ -53,12 +54,15 @@ void __init dt_uart_init(void) >...

Since OMAP UART has a few distinct features than common 8250 UART, I re-implemented its driver rather than porting it based on ns16550.c. There are mainly two big differences between the implementations. First, OMAP UART introduces the concept of register access mode, which divides the register map into seperated space. Switching the access mode is then necessary when configuring it. Second, THRE

I''ve addressed all (I think/hope) of the review comments. The main change is to expose the guest virtual platform (e.g. memory layout and interrupt usage etc) to the toolstack via the public interface. This is then used during FDT generation. I have just codified the current defacto standard layout, it''s probably not the best layout but any change can be a separate patch/series.

See http://www.gossamer-threads.com/lists/xen/devel/297170 for some information on how to get this going. I''ve rebased and addressed the review comments. As before several of the patches are not to be applied because they can be done better using infrastructure from Julien''s "Allow Xen to boot with a raw Device Tree" patch. They are included for completeness. With

I''m afraid this series is rather a grab bag and it is distressingly large at this stage. With this series I can boot an Xgene board until it fails to find its SATA controller. This is a dom0 issue for which patches are pending from APM (/me nudges Anup). As well as the APM specific platform stuff there are also some generic improvements which were either necessary or useful during this

See http://www.gossamer-threads.com/lists/xen/devel/297170 for some information on how to get this going. I''ve rebased and addressed the review comments. With this rebase I''ve picked up some patches from Julien which were required to do things properly, so the gic v7 and device blacklisting patches have been changed to use the proper mechanisms. Previously I was able to boot

Hi, This is the fifth version of this patch series. With the Versatile Express TC2, it''s possible to boot only with A7 or A15. If the user choose to boot with only A7, the CPU ID will start at 0x100. As Xen relies on it to set the logical ID and the GIC, it won''t be possible to use Xen with this use case. This patch series is divided in 3 parts: - Patch 1: prepare Xen

George has release acked all of these. Otherwise mostly minor updates this time around. Summary: A == acked, M == modified A xen: arm64: Add 8250 earlyprintk support A xen: arm64: Add Basic Platform support for APM X-Gene Storm. A xen: arm64: Add APM implementor id to processor implementers. M xen: arm: add a quirk to handle platforms with unusual GIC layout A xen: arm: allow platform

Initially out there as #965245. I strongly prefer to build ARM64 packages on non-ARM systems. Something about my main build machine having twice the cores and twice the clock speed. As such after many builds I've managed to generate a set of patches which appear to mostly function to get functioning cross-builds of Xen. These are NOT a 100% solution. Some packaging hacks were needed. In