On Mon, Oct 16, 2017 at 11:40 AM, Ben Dooks <ben.dooks@xxxxxxxxxxxxxxx> wrote: > On 16/10/17 06:36, Michal Simek wrote: >> >> Hi, >> >> On 9.10.2017 22:39, Grant Likely wrote: >>> >>> Kernel Summit is now just over 2 weeks away and it is time to pull >>> together the schedule for the Devicetree workshop. Originally I >>> planned on just an afternoon, but I've got the room for the whole day, >>> so I've got a lot of flexibility on the schedule. Unscheduled time can >>> be used for hacking. >>> >>> Date: 26 Oct 2017 >>> Time: 9:00am-5:30pm (Lunch from 12:30-2:30) >>> Location: Athens room - Hilton Prague >>> >>> If you plan to attend, make sure you update your OSSunmitE/ELCE >>> registration to include the DT Workshop (log in to access and modify >>> your registration): >>> >>> >>> https://www.regonline.com/register/login.aspx?eventID=1883377&MethodId=0&EventsessionId=&Email_Address=&membershipID= >>> >>> Here is my current list of topics in no particular order, including >>> the topic moderator: >>> >>> Runtime memory consumption (Rob Herring) >>> Overlay maintenance plan (TBC) >>> Stable ABI for devicetree (TBC) >>> DT YAML encoding (Pantelis Antoniou) >>> DT Schema format - option 1 (Pantelis Antoniou) >>> DT Schema format - option 2 (Grant Likely) >>> Sharing Generic bindings (TBC) >>> devicetree.org update (Grant) >>> >>> Reply to this email if you want to propose another topic. >>> >>> Reply privately if there is a particular topic you want to attend but >>> you are unable to be there in the morning or afternoon. I'll put the >>> actual agenda together a week out from the event. >> >> >> I would like to talk how to add support for AArch32 based on arm64 dts >> file. >> >> And next topic is discuss criteria for adding new DTS board files to >> kernel for supporting custom boards especially for arm32 which can end >> up with a lot of dts files in this folder. >> If make sense to permit only boards with something new or just enable >> reference boards to go in. > > > I am interested in this, as we seem to be repeating the quantity > issue with the board file of having many .dts sources in the kernel. The problem was not so much having board files in the kernel. It was how to scale support for boards and SoCs with each family structuring things their own, different way. IIRC, the ARM tree was at ~400 boards at the start of DT conversion. Now we're at ~1100 boards for arm/arm64. Plus we still have 264 that aren't converted to DT. > I'm not sure how to deal with this, on one hand only having the > reference (and possibly popular) boards is going to keep the size > down. On the other hand out of tree .dts files are going to be > difficult to find (or vanish with the vendor). Why do we care? What problem is that causing? > It seems we are still no closer to having a DT repository outside > the kernel. In relationship to the above what problem would that solve? We've got all the platform maintainers and arm-soc maintainers to handle dts files. Mark and myself along with subsystem maintainers reviewing and applying device bindings. If you move all that to a separate repository, then you have me because no one else has volunteered. I'm pretty sure no one wants me as the single point of failure. Rob -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
