From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: [RFC 21/24] xen/arm: vexpress: Blacklist a list of board specific devices Date: Thu, 22 Aug 2013 15:24:20 +0100 Message-ID: <52161F14.50206@linaro.org> References: <1376687156-6737-1-git-send-email-julien.grall@linaro.org> <1376687156-6737-22-git-send-email-julien.grall@linaro.org> <1377180031.2825.39.camel@kazak.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1377180031.2825.39.camel@kazak.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: patches@linaro.org, xen-devel@lists.xen.org, andre.przywara@linaro.org, stefano.stabellini@eu.citrix.com List-Id: xen-devel@lists.xenproject.org On 08/22/2013 03:00 PM, Ian Campbell wrote: > On Fri, 2013-08-16 at 22:05 +0100, Julien Grall wrote: >> On Versatile there is a bunch of devices that must not pass-through to any > > "there are a bunch of devices which must not be passed-through" > >> guest (power management and cache coherency devices). >> >> This commit also blacklist the HDLCD device because then is unable to correctly > ^Linux? > >> map the framebuffer. Therefore, when Linux will try to access to the framebuffer, >> Xen will receive a non-handled data access. > > Can/should this be conditional on whether Xen has console=hdlcd or not? > Or does Xen use the device unconditionally if it exists? TBH I think it > would be normal to prefer that Linux gets this device... > > (I'm unclear how this relates to memreserve as mention in the code > comment) This issue is only when the HDLCD is used by Linux (not Xen). To specify where the framebuffer lives in the memory, there is a property "framebuffer" which contains address/size. This regions must be reserved to avoid Linux/u-boot play with it. So the DTS has a memreserve range with the same value. I don't really understand all memreserve things but Xen must cope with it. If this device is mapped, Xen will receive a data abort because Linux can't access to the framebuffer. This solution is not upstream (only in the Linaro tree). I don't know if this driver works with the vanilla kernel. > >> >> Signed-off-by: Julien Grall >> --- >> xen/arch/arm/platforms/vexpress.c | 17 +++++++++++++++++ >> 1 file changed, 17 insertions(+) >> >> diff --git a/xen/arch/arm/platforms/vexpress.c b/xen/arch/arm/platforms/vexpress.c >> index 8fc30c4..ece7bd9 100644 >> --- a/xen/arch/arm/platforms/vexpress.c >> +++ b/xen/arch/arm/platforms/vexpress.c >> @@ -125,9 +125,26 @@ static const char const *vexpress_dt_compat[] __initdata = >> NULL >> }; >> >> +static const struct dt_device_match vexpress_blacklist_dev[] __initconst = >> +{ >> + /* Cache Coherent Interconnect */ >> + DT_MATCH_COMPATIBLE("arm,cci-400"), >> + DT_MATCH_COMPATIBLE("arm,cci-400-pmu"), >> + /* Video device >> + * TODO: remove it once memreserve is handled properly by Xen >> + */ >> + DT_MATCH_COMPATIBLE("arm,hdlcd"), >> + /* Hardware power management */ >> + DT_MATCH_COMPATIBLE("arm,vexpress-reset"), >> + DT_MATCH_COMPATIBLE("arm,vexpress-reboot"), >> + DT_MATCH_COMPATIBLE("arm,vexpress-shutdown"), >> + { /* sentinel */ }, >> +}; >> + >> PLATFORM_START(vexpress, "VERSATILE EXPRESS") >> .compatible = vexpress_dt_compat, >> .reset = vexpress_reset, >> + .blacklist_dev = vexpress_blacklist_dev, >> PLATFORM_END >> >> /* > > -- Julien Grall