> -----Original Message----- > From: A.s. Dong > Sent: 2018年2月7日 19:03 > To: 'Linus Walleij' <linus.walleij@xxxxxxxxxx>; Lucas Stach > <l.stach@xxxxxxxxxxxxxx>; 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 > > 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. > Here is some information from our IP designer. It probably explains why i.MX uses Ohm to represents driver strength. "Electrical spec for different interfaces typically define output driver in Ohm. So we follow the same way to comply with spec requirement. Also, for the board designer it is important to know the driver impedance to match the driver and PCB trace resistance. Defining the driver in Ohm allows to calculate IR drop, as well as output slew rate, which are important to know." An example from eMMC 5.1 spec: Table 206 - I/O driver strength types 0x0 50Ω x1 0x1 33Ω x1.5 0x2 66Ω x0.75 0x3 100Ω x0.5 0x4 40Ω x1.2 And for one question you asked in another email. - Is the intended usage for impedance matching? For low frequency interface, for example, I2C/GPIO, it’s not necessary. For high frequency interface, for example, DDR/HS200/HS400/Rawnand differential 200M, in theory, we should consider impedance matching for better signal quality. Anyway, we can check that by board level simulation with spice model. And IC guys thought Ohm probably is more suitable for high speed IO pads. Hope it helps. Regards Dong Aisheng > 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
