On 19 Jan 2016 20:52, "Alistair Francis" <alistair.fran...@xilinx.com> wrote: > > On Fri, Jan 8, 2016 at 3:05 AM, Edgar E. Iglesias > <edgar.igles...@gmail.com> wrote: > > On Fri, Jan 08, 2016 at 10:40:28AM +0000, Peter Maydell wrote: > >> On 8 January 2016 at 00:39, Alistair Francis > >> <alistair.fran...@xilinx.com> wrote: > >> > On Wed, Dec 16, 2015 at 8:33 AM, Alistair Francis > >> > <alistair.fran...@xilinx.com> wrote: > >> >> On Tue, Dec 15, 2015 at 1:56 PM, Peter Maydell < peter.mayd...@linaro.org> wrote: > >> >>> On 15 December 2015 at 20:52, Peter Crosthwaite > >> >>> <crosthwaitepe...@gmail.com> wrote: > >> >>>> It needs to exist before it can be used so there is a bit of a chicken > >> >>>> and egg problem there. > >> > > >> > No one seems to be jumping at reviewing this. Can we just send a pull request? > >> > >> I don't necessarily require review [*]. I would like *somebody* other > >> than you Xilinx folk to say "yes, I think I would use this for > >> modelling devices". Otherwise all we have is "weird thing used > >> only in two or three Xilinx devices and nowhere else", which I'm > >> a bit reluctant to let into the tree. We already have a pretty > >> wide divergence in how devices look just based on the various > >> transitions from older to newer qdev/QOM/etc that are not complete. > >> > >> [*] by which I mean, I will review this series if you can find > >> somebody else who's going to say they'd use it. > >> > > > > Hi, > > > > I have two general comments to the series. > > > > 1. I think we need to do something to allow mem-attributes to be passed to the reg-access callbacks and possibly also to add a way to filter on attrs in the data structure. > > I would prefer to add this in the future. We are already having enough > trouble getting it accepted now and this will add complexity. > > In saying that, it shouldn't be too hard to add in the future. The > basic infrastructure is all there. >
Sounds good > > > > 2. We had trouble in the Xilinx tree with the number of memory regions created when using the style were each reg becomes an MR. I think that style should either be disallowed or we need to fix the low limit (IIRC it was at around 1K MRs/Regs). > > This I can help with. I am sending a V2 which doesn't print the memory > regions with infro mtree. When you start getting hundreds of registers > this becomes really painful. I can't see a nice way to avoid actually > adding the memory subregions though. It is just a linked list, what > limit is there for memory subregions? > I don't remember all the details but it was not directly due to the large amount of MRs but indirectly with the resulting AS. We hit aborts and died. Our skeleton generator does not use the mr style anymore for example. Cheers, Edgar > Thanks, > > Alistair > > > > > I'm part of the Xilinx team so I this outside of Peters review request but anyawy.... > > > > Cheers, > > Edgar > >
