Hi Linus, > -----Original Message----- > From: Linus Walleij [mailto:linus.walleij@xxxxxxxxxx] > Sent: 2018年2月7日 17:09 > To: Lucas Stach <l.stach@xxxxxxxxxxxxxx>; A.s. Dong > <aisheng.dong@xxxxxxx>; dl-linux-imx <linux-imx@xxxxxxx>; Gary Bisson > <gary.bisson@xxxxxxxxxxxxxxxxxxx>; Vladimir Zapolskiy > <vladimir_zapolskiy@xxxxxxxxxx>; Sascha Hauer <kernel@xxxxxxxxxxxxxx> > Cc: Rob Herring <robh@xxxxxxxxxx>; Mark Rutland <mark.rutland@xxxxxxx>; > linux-gpio@xxxxxxxxxxxxxxx; open list:OPEN FIRMWARE AND FLATTENED > DEVICE TREE BINDINGS <devicetree@xxxxxxxxxxxxxxx>; > patchwork-lst@xxxxxxxxxxxxxx > Subject: Re: [PATCH v2 1/3] dt-bindings: add binding for i.MX8MQ IOMUXC > > On Tue, Feb 6, 2018 at 4:47 PM, Lucas Stach <l.stach@xxxxxxxxxxxxxx> wrote: > > > To be fully honest I'm a bit annoyed with the pinctrl framework making > > things (IMHO) unnecessarily complex, for what is basically a pretty > > easy task. > > My ambition is to make things readable, understandable and maintainable. In > generic terms, incorporating a bunch of knowledge of the electronics that really > happen into the stuff we encode in the kernel. > > I guess it varies a bit on what goal one has. > > If the goal is "ship product with upstream kernel really fast now" > then things like pinctrl-single.c where we just hammer magic values into > registers, make sense. OMAP developers had no idea whatsoever what their > ASIC people or cell library authors were doing so they just threw in the towel. > HiSilicon also use this. Intels ambition was to use ACPI BIOS to handle all pin > control and route around the kernel altogether, but that is not working out so > well for them I think. > > All of them are approaches to avoid putting the hairy details into the kernel, just > poke some magic values into some magic registers and be happy. > > So i.MX could have been like that, but then I guess you need to take legacy into > account and discuss with the other i.MX driver authors about how they really > wanted and want to do things. > > Their current silence wrt this mailchain is actually becoming a problem, and the > problem is that discussing with you falls upwards to me as subsystem maintainer. > Which sucks. I prefer that people who know this hardware discuss amongst > themselves how they want things to work. > > Surely Sascha must have an opinion? It means much to me what he wants to do. > I take it you guys are colleagues? > > > Pengutronix is mostly contracted by customers of NXP to enable stuff > > in mainline. So I'm not working on this in my spare time, but I still > > have to deal with the fact that I can only get the information from > > the reference manual, NXP downstream BSPs and the occasional helpful > > NXP employee. > > Hm I see, this seems like a bit of crappy position to be in when you just want to > ask someone in hardware how things really work. > > But we have Freescale i.MX maintainers on the inside of the company now NXP > (soon Qualcomm? soon Broadcom?). > > Hell this mail is even going to linux-imx@xxxxxxx, what do they do with it? Put > it in a mailbox and never read it? > > Surely someone on the inside must be able to provide some details. > I feel terribly sorry that did not come up in the first time these two days as I was busy with some other urgent things requested by my boss. It should be my responsibility as I promised to take that ownership before. I quickly went through the email and I fully understand your concern. As I'm not a specialist on the HW internals of IOMUX design, i already forwarded the Issue to our IP owner. Due to it's already off work time at my side, I will discuss with him tomorrow Morning and get back to you later. And i will carefully review the reference manual and doc on my hands. Hopefully I can give you some information later you want. Regards Dong Aisheng > > Also even if we were inside of NXP, pad cells are usually something > > that chip makers buy or get from the Fab design library. So probably > > even they don't know what's inside exactly. > > Yeah that is what I call "throw over the wall engineering". > It's not good, if NXP works with information brick walls like that it is not any good > for them, because it is not any good for their customers. > > Not something you or I can fix though... > > > What usually happens is that hardware (I'm talking about board/system > > here) designers start by reading the reference manual and hardware > > design guide and work with that. They come up with all the necessary > > configuration in the terms of the manual. > > Sometimes half-guessing and a bit of trial-and-error right? > > > After that they or someone else has to translate this into DT. Things > > get confusing when the reference manual and the DT binding disagree > > about the used terms. > > I see. > > >> If you want something to match the specific hardware manual from NXP > >> and you don't want it to be translated into the units of the DT > >> binding, then I think it is better to use something prefixed "nxp,*". > > > >> That clearly indicates that this is some NXP oddity that we don't > >> really understand. > > > > I'm not keen on using the common padctrl stuff, which already bloats > > the DT description compared to i.MX6, > > This you need to discuss with the generic i.MX driver maintainers. > They are the maintainers of drivers/pinctrl/freescale/* after all. > > They never put an entry in MAINTAINERS though, but I always regarded these as > the pinctrl maintainers for i.MX: > > ARM/FREESCALE IMX / MXC ARM ARCHITECTURE > M: Shawn Guo <shawnguo@xxxxxxxxxx> > M: Sascha Hauer <kernel@xxxxxxxxxxxxxx> > R: Fabio Estevam <fabio.estevam@xxxxxxx> > > On top of this, Dong Aisheng, Gary Bisson and Vladimir Zapolskiy has made major > contributions. > > It's a little ecosystem on its own, not really to be discussed by just you and me. I > wonder where the rest of the voices are, I hope not silenced by organizational > stress after the NXP merger... > > > and then again need to introduce > > custom properties. That's just worst of both worlds, verbose DT to use > > the common stuff, mixed with special properties, only valid on this > > single controller. > > No matter how much you dislike it, it is what e.g. Qualcomm is doing. (Who > might soon be one and the same as NXP I hear.) > > > If you insist I guess I'm fine with compromising on an "output- > > impedance" common property, but then this just makes things harder for > > everyone involved, as the impedance even seems to vary slightly with > > the used pad voltage. So to not get into a combinatorial explosion, we > > would need to describe this property as somethings like "output > > impedance at 3.3v)", at least on this specific hardware. > > Hm, should it me "nxp,drive-strength" then, as it is just some magic value? I > guess "nxp,magic-drive-strength" is not going to cut it :D > > Also maybe we should use the old "freescale,*" notation for legacy reasons... I > don't know. This Vendor prefix seems less stable than the chipsets. > > > Or we could agree that drive-strength property could be described in > > some unit that makes sense on each controller. mA for hardware > > described with some fabled ideal load matching, Ohms for hardware that > > models it this way with maximum drive strength at the point of best > > load matching. > > I am not like stubbornly against. I just want some discussion here, it would be > nice to know the opinion of the i.MX maintainers. > > > In the end this is about mapping 3 hardware bits to a DT description... > > Pleas don't think about it like "can't we just do this real simple thing now, just > merge this and stop being an ass". > > Things just poking three bits can look very simple, like in so many BSPs: > > volatile unsigned long *foo; > > foo = (unsigned long *) 0xfec0be00; > *foo &= ~0x700; > *foo |= 0x200; /* do the magic */ > > But this is not helpful for developers or maintainers. That is IMHO why we have > the frameworks and all the DT standardization in the first place, exactly so we > understand what we are doing. > > Yours, > Linus Walleij ��.n��������+%������w��{.n����z�{��ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
