| Message ID | 20180201174923.7385-1-l.stach@pengutronix.de |
|---|---|
| State | New |
| Headers | show |
| Series | [v2,1/3] dt-bindings: add binding for i.MX8MQ IOMUXC | expand |
On Thu, Feb 01, 2018 at 06:49:21PM +0100, Lucas Stach wrote: > This adds the binding for the i.MX8MQ pin controller, in the same > fashion as earlier i.MX SoCs. > > Signed-off-by: Lucas Stach <l.stach@pengutronix.de> > --- > v2: switch to generic pinconf properties > --- > .../bindings/pinctrl/fsl,imx8mq-pinctrl.txt | 39 ++++++++++++++++++++++ > 1 file changed, 39 insertions(+) > create mode 100644 Documentation/devicetree/bindings/pinctrl/fsl,imx8mq-pinctrl.txt > > diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx8mq-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,imx8mq-pinctrl.txt > new file mode 100644 > index 000000000000..5c5d2d835d05 > --- /dev/null > +++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx8mq-pinctrl.txt > @@ -0,0 +1,39 @@ > +* Freescale IMX8MQ IOMUX Controller > + > +Please refer to fsl,imx-pinctrl.txt and pinctrl-bindings.txt in this directory > +for common binding part and usage. > + > +=== Pin Controller Node === > + > +Required properties: > +- compatible: "fsl,imx8mq-iomuxc" > +- reg: Must contain the base physical address and size of the iomuxc registers. > + > +=== Pin Configuration Node === > +Required properties: > +- pinmux: Array of integersy, representing a group of pins mux setting. > + The format is pinmux = <PIN_FUNC_ID>, PIN_FUNC_ID is a pin working on > + a specific function. > + > + Refer to imx8mq-pinfunc.h in device tree source folder for all available > + imx8mq PIN_FUNC_ID. > + > +Optional Properties: > +- drive-strength Integer: controls Drive Strength I thought drive-strength is supposed to be be in mA. We should not have differing units in common properties. There was an Atmel binding the other day that this came up. > + 0: driver disabled > + 1: 255 Ohm > + 2: 105 Ohm > + 3: 75 Ohm > + 4: 85 Ohm > + 5: 65 Ohm > + 6: 45 Ohm > + 7: 40 Ohm > +- slew-rate: Integer: controls Slew Rate > + 0: Slow > + 1: Medium > + 2: Fast > + 3: Maximum > +- drive-open-drain Bool: enable Open-drian > +- bias-pull-up Bool: enable Pull-up > +- input-schmitt-enable Bool: enable schmitt-trigger > +- input-enable Bool: enable input, overriding module settings > -- > 2.15.1 > -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Am Montag, den 05.02.2018, 00:09 -0600 schrieb Rob Herring: > On Thu, Feb 01, 2018 at 06:49:21PM +0100, Lucas Stach wrote: > > This adds the binding for the i.MX8MQ pin controller, in the same > > fashion as earlier i.MX SoCs. > > > > > > Signed-off-by: Lucas Stach <l.stach@pengutronix.de> > > --- > > v2: switch to generic pinconf properties > > --- > > .../bindings/pinctrl/fsl,imx8mq-pinctrl.txt | 39 ++++++++++++++++++++++ > > 1 file changed, 39 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/pinctrl/fsl,imx8mq-pinctrl.txt > > > > diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx8mq-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,imx8mq-pinctrl.txt > > new file mode 100644 > > index 000000000000..5c5d2d835d05 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx8mq-pinctrl.txt > > @@ -0,0 +1,39 @@ > > +* Freescale IMX8MQ IOMUX Controller > > + > > +Please refer to fsl,imx-pinctrl.txt and pinctrl-bindings.txt in this directory > > +for common binding part and usage. > > + > > +=== Pin Controller Node === > > + > > +Required properties: > > +- compatible: "fsl,imx8mq-iomuxc" > > +- reg: Must contain the base physical address and size of the iomuxc registers. > > + > > +=== Pin Configuration Node === > > +Required properties: > > +- pinmux: Array of integersy, representing a group of pins mux setting. > > > > + The format is pinmux = <PIN_FUNC_ID>, PIN_FUNC_ID is a pin working on > > > > + a specific function. > > + > > > > + Refer to imx8mq-pinfunc.h in device tree source folder for all available > > > > + imx8mq PIN_FUNC_ID. > > + > > +Optional Properties: > > +- drive-strength Integer: controls Drive Strength > > I thought drive-strength is supposed to be be in mA. We should not have > differing units in common properties. > > There was an Atmel binding the other day that this came up. I know it's in the common binding, but it's going to be very hard to support. The drive-strength in mA really depends on external loading of the pin and the pin voltage, at least for the most widespread controllers that only switch between resistors, instead of driving the pin by a current regulator. So we would need much more information, which doesn't really seem practical. I would much prefer if we just remove unit from the common binding and let the drivers define it in a way that fits their hardware description. It's the same thing with the slew-rate really, but the common binding didn't make the mistake to define a single unit there, with many pincontrollers being really vague about how fast the slew really is, but some may actually define it in uS or whatever else makes sense. Regards, Lucas -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Feb 5, 2018 at 11:09 AM, Lucas Stach <l.stach@pengutronix.de> wrote: >> > +Optional Properties: >> > +- drive-strength Integer: controls Drive Strength >> >> I thought drive-strength is supposed to be be in mA. We should not have >> differing units in common properties. >> >> There was an Atmel binding the other day that this came up. > > I know it's in the common binding, but it's going to be very hard to > support. The drive-strength in mA really depends on external loading of > the pin and the pin voltage, at least for the most widespread > controllers that only switch between resistors, instead of driving the > pin by a current regulator. How does this circuit really look? Can you sketch something so we understand what is going on electronically here? The way I imagine most drive strength out there works is by simply connection more MOS-totempoles after each other and each of them has a production-technology-related max output current like 4mA, so by putting two in a series yoy double that to 8 mA. Is that what you mean with "current regulator"? If you mean rather "output impedance", that is something else and something we need a new (generic) property for. I never saw that before, really. > I would much prefer if we just remove unit from the common binding and > let the drivers define it in a way that fits their hardware > description. Yeah but is this really the same thing even ... > It's the same thing with the slew-rate really, but the common binding > didn't make the mistake to define a single unit there, with many > pincontrollers being really vague about how fast the slew really is, > but some may actually define it in uS or whatever else makes sense. I agree with that. Also for skewrate and output time delays (skew delay). It's very unclear how cell libraries really implement this. But with drive strength I thought we knew it ... Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Linus, Am Dienstag, den 06.02.2018, 00:13 +0100 schrieb Linus Walleij: > > On Mon, Feb 5, 2018 at 11:09 AM, Lucas Stach <l.stach@pengutronix.de> wrote: > > > > > +Optional Properties: > > > > +- drive-strength Integer: controls Drive Strength > > > > > > I thought drive-strength is supposed to be be in mA. We should not have > > > differing units in common properties. > > > > > > There was an Atmel binding the other day that this came up. > > > > I know it's in the common binding, but it's going to be very hard to > > support. The drive-strength in mA really depends on external loading of > > the pin and the pin voltage, at least for the most widespread > > controllers that only switch between resistors, instead of driving the > > pin by a current regulator. > > How does this circuit really look? Can you sketch something so > we understand what is going on electronically here? There is no description of how the circuit really looks like and I would very much prefer this not being a prerequisite to get some software support in place. The best description we have is from NXP AN5078: "The drive strength enable (DSE) can be explained as series resistance between an ideal driver's output and its load. To achieve maximal transferred power, the impedance of the driver has to match the load impedance." Which means the control bits don't really vary the output impedance, but the description models it like that. If we _assume_ the simple MOS totempole setup then adding more totempoles will bring down the output impedance. > The way I imagine most drive strength out there works is by simply > connection more MOS-totempoles after each other and each of them > has a production-technology-related max output current like 4mA, so > by putting two in a series yoy double that to 8 mA. So with this description in mind the drive-strength property doesn't describe an actual real world drive-strength, but some maximum current output under ideal load matching? That's pretty confusing actually, as in a real-world setup increasing the drive-strength property value might negatively affect the load matching, leading to _decreasing_ the actual drive-strength. > Is that what you mean with "current regulator"? > > If you mean rather "output impedance", that is something else and > something we need a new (generic) property for. I never saw that > before, really. So, just because the description of the drive-strength value uses some (idealized) output impedance, we are now going to introduce yet another property for the same thing? This is confusing to people reading the reference manual, which never speaks about output-impedance, but always about drive-strength. Hardware people (the ones responsible to come up with the padctrl settings) are much more likely to read the reference manual than any idealized dt-binding. I want to make it as easy as possible for them to match up the hardware and reference manual with the DT description. So, can we please just keep the drive-strength property and deal with it being described in different units in different hardware manuals? Regards, Lucas -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Feb 6, 2018 at 11:53 AM, Lucas Stach <l.stach@pengutronix.de> wrote: Hi Lucas, your reply seems a bit annoyed. Are you annoyed with me? In that case please take it down a bit, I understand it can be stressful as developer, but I need to maintain the stuff we're pushing in for years to come and it's my job to ask the tricksy questions. > Am Dienstag, den 06.02.2018, 00:13 +0100 schrieb Linus Walleij: >> > On Mon, Feb 5, 2018 at 11:09 AM, Lucas Stach <l.stach@pengutronix.de> wrote: >> >> > > > +Optional Properties: >> > > > +- drive-strength Integer: controls Drive Strength >> > > >> > > I thought drive-strength is supposed to be be in mA. We should not have >> > > differing units in common properties. >> > > >> > > There was an Atmel binding the other day that this came up. >> > >> > I know it's in the common binding, but it's going to be very hard to >> > support. The drive-strength in mA really depends on external loading of >> > the pin and the pin voltage, at least for the most widespread >> > controllers that only switch between resistors, instead of driving the >> > pin by a current regulator. >> >> How does this circuit really look? Can you sketch something so >> we understand what is going on electronically here? > > There is no description of how the circuit really looks like and I > would very much prefer this not being a prerequisite to get some > software support in place. That depends. If you're a hobbyist with limited access to documentation I agree. In that case let's go for something that floats your project, I'm fine with that. I have a weak spot for people with a good project and limited resources, so I am here to help. I'd say then let's go for some "nxp,foo" property. If you are working for NXP directly or under contract, what you say is that the left hand does not know what the right hand is doing and that is never a good sign. Such as the hardware and software departments do not talk to each other, do not have each other mail addresses and practice what is called "throw over the wall-engineering". Or throw it all the way over to Pengutronix, maybe, a separate legal entity they don't even prioritize to inform. What do I know. In this latter case it is more or less my responsibility as subsystem maintainer to push back at NXP as a legal body, it has nothing to do with the people involved. Especially not you personally. In this case I am adressing your organization, not you. So which one is it? > The best description we have is from NXP AN5078: > "The drive strength enable (DSE) can be explained as series resistance > between an ideal driver's output and its load. To achieve maximal > transferred power, the impedance of the driver has to match the load > impedance." > > Which means the control bits don't really vary the output impedance, > but the description models it like that. If we _assume_ the simple MOS > totempole setup then adding more totempoles will bring down the output > impedance. +- drive-strength Integer: controls Drive Strength + 0: driver disabled + 1: 255 Ohm + 2: 105 Ohm + 3: 75 Ohm + 4: 85 Ohm + 5: 65 Ohm + 6: 45 Ohm + 7: 40 Ohm As for equal resistances R = Rx/N assuming it is really 255 Ohms internal resistance per totempole: 1: 255 2: 127,5 3: 85 4: 63,75 5: 51 6: 42,5 7: 36,4 I don't know. Something is not right. Maybe this is how CMOS work under load? >> The way I imagine most drive strength out there works is by simply >> connection more MOS-totempoles after each other and each of them >> has a production-technology-related max output current like 4mA, so >> by putting two in a series yoy double that to 8 mA. > > So with this description in mind the drive-strength property doesn't > describe an actual real world drive-strength, but some maximum current > output under ideal load matching? I guess that is what other datasheets have been listing. I have personally seen a few of those. I don't know if it is as simple as a totem-pole, I guess IIRC under ideal circumstances the internal resistance of an operational amplifier is zero. E.g. on a popular TTL part uA 741 it is 5.5 milliohms. What is Rout for a normal CMOS totem-pole? Some googling suggests ~400 Ohm so 255 Ohm may not be so far off. Does anyone else know? This is pretty interesting stuff :D > That's pretty confusing actually, as in a real-world setup increasing > the drive-strength property value might negatively affect the load > matching, leading to _decreasing_ the actual drive-strength. This sounds like a perfect argument to create a new property "output-impedance" and use that in my ears. It makes more sense to a designer, because what they really want to do, electrically, is to match impedances. I am thinking some designer writing this device tree. What they want to control is the output impedance, not drive strength. So that name makes more sense. >> Is that what you mean with "current regulator"? >> >> If you mean rather "output impedance", that is something else and >> something we need a new (generic) property for. I never saw that >> before, really. > > So, just because the description of the drive-strength value uses some > (idealized) output impedance, we are now going to introduce yet another > property for the same thing? Yes it seems like a good idea, if (by your own line of reasoning) it is the physical principle underlying these resistance settings. Then we are likely to see it again. > This is confusing to people reading the > reference manual, which never speaks about output-impedance, but always > about drive-strength. Since we are already (obviously) confused, we have to choose the lesser evil here. Apparently what (board- system-) designers want to do is match output resistance to load, I would argue that it is more confusing to call that "drive strength", i.e. what is misleading is not what I am discussing here, but the manual you are referring to. Just a bad piece of technical writing. > Hardware people (the ones responsible to come up with the padctrl > settings) are much more likely to read the reference manual than any > idealized dt-binding. Can we talk to them about this? I don't like to think about them as some foreign people in a far away dimension we can never understand or communicate with, how do they really do what they do? > I want to make it as easy as possible for them to > match up the hardware and reference manual with the DT description. I was hoping we could dig in a bit and figure out what we are going to do and why and how these people think. I want to avoid poking magic values we don't really understand into registers and using the manual as alchemic magic or spellbook, essentially. (As so often happens...) > So, can we please just keep the drive-strength property and deal with > it being described in different units in different hardware manuals? 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 was just hoping not to introduce too many of these. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Linus, Am Dienstag, den 06.02.2018, 15:32 +0100 schrieb Linus Walleij: > On Tue, Feb 6, 2018 at 11:53 AM, Lucas Stach <l.stach@pengutronix.de> > wrote: > > Hi Lucas, > > your reply seems a bit annoyed. > > Are you annoyed with me? > > In that case please take it down a bit, I understand it can > be stressful as developer, but I need to maintain the stuff > we're pushing in for years to come and it's my job to > ask the tricksy questions. 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. But I'll try to keep things focused on the technical issue at hand, so we can all make some progress. > > Am Dienstag, den 06.02.2018, 00:13 +0100 schrieb Linus Walleij: > > > > On Mon, Feb 5, 2018 at 11:09 AM, Lucas Stach <l.stach@pengutron > > > > ix.de> wrote: > > > > > > +Optional Properties: > > > > > > +- drive-strength Integer: controls Drive > > > > > > Strength > > > > > > > > > > I thought drive-strength is supposed to be be in mA. We > > > > > should not have > > > > > differing units in common properties. > > > > > > > > > > There was an Atmel binding the other day that this came up. > > > > > > > > I know it's in the common binding, but it's going to be very > > > > hard to > > > > support. The drive-strength in mA really depends on external > > > > loading of > > > > the pin and the pin voltage, at least for the most widespread > > > > controllers that only switch between resistors, instead of > > > > driving the > > > > pin by a current regulator. > > > > > > How does this circuit really look? Can you sketch something so > > > we understand what is going on electronically here? > > > > There is no description of how the circuit really looks like and I > > would very much prefer this not being a prerequisite to get some > > software support in place. > > That depends. If you're a hobbyist with limited access to > documentation I agree. In that case let's go for something > that floats your project, I'm fine with that. I have a weak spot > for people with a good project and limited resources, so I > am here to help. I'd say then let's go for some "nxp,foo" property. > > If you are working for NXP directly or under contract, what you say > is that the left hand does not know what the right hand is doing and > that > is never a good sign. Such as the hardware and software departments > do not talk to each other, do not have each other mail addresses > and practice what is called "throw over the wall-engineering". > Or throw it all the way over to Pengutronix, maybe, a separate > legal entity they don't even prioritize to inform. What do I know. > > In this latter case it is more or less my responsibility as subsystem > maintainer to push back at NXP as a legal body, it has nothing to > do with the people involved. Especially not you personally. In this > case I am adressing your organization, not you. > > So which one is it? Neither. 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. 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. > > The best description we have is from NXP AN5078: > > "The drive strength enable (DSE) can be explained as series > > resistance > > between an ideal driver's output and its load. To achieve maximal > > transferred power, the impedance of the driver has to match the > > load > > impedance." > > > > Which means the control bits don't really vary the output > > impedance, > > but the description models it like that. If we _assume_ the simple > > MOS > > totempole setup then adding more totempoles will bring down the > > output > > impedance. > > +- drive-strength Integer: controls Drive Strength > + 0: driver disabled > + 1: 255 Ohm > + 2: 105 Ohm > + 3: 75 Ohm > + 4: 85 Ohm > + 5: 65 Ohm > + 6: 45 Ohm > + 7: 40 Ohm > > As for equal resistances R = Rx/N assuming it is > really 255 Ohms internal resistance per totempole: > > 1: 255 > 2: 127,5 > 3: 85 > 4: 63,75 > 5: 51 > 6: 42,5 > 7: 36,4 > > I don't know. Something is not right. Maybe this is how > CMOS work under load? Semiconductor physics tends to be slightly more complex than this. :) > > > The way I imagine most drive strength out there works is by > > > simply > > > connection more MOS-totempoles after each other and each of them > > > has a production-technology-related max output current like 4mA, > > > so > > > by putting two in a series yoy double that to 8 mA. > > > > So with this description in mind the drive-strength property > > doesn't > > describe an actual real world drive-strength, but some maximum > > current > > output under ideal load matching? > > I guess that is what other datasheets have been listing. > I have personally seen a few of those. > > I don't know if it is as simple as a totem-pole, I guess > IIRC under ideal circumstances the internal resistance of an > operational amplifier is zero. E.g. on a popular TTL part uA 741 > it is 5.5 milliohms. What is Rout for a normal CMOS totem-pole? > Some googling suggests ~400 Ohm so 255 Ohm may not be > so far off. > > Does anyone else know? > > This is pretty interesting stuff :D Interesting indeed, but pretty far away from the dt-binding we set out to discuss. And even if we might come up with a simplistic model of what's going on inside the pad cell, how do we know if it matches reality? Does this really help us define a useful binding? > > That's pretty confusing actually, as in a real-world setup > > increasing > > the drive-strength property value might negatively affect the load > > matching, leading to _decreasing_ the actual drive-strength. > > This sounds like a perfect argument to create a new > property "output-impedance" and use that in my ears. > It makes more sense to a designer, because what they > really want to do, electrically, is to match impedances. > > I am thinking some designer writing this device tree. > What they want to control is the output impedance, not > drive strength. So that name makes more sense. > > > > Is that what you mean with "current regulator"? > > > > > > If you mean rather "output impedance", that is something else and > > > something we need a new (generic) property for. I never saw that > > > before, really. > > > > So, just because the description of the drive-strength value uses > > some > > (idealized) output impedance, we are now going to introduce yet > > another > > property for the same thing? > > Yes it seems like a good idea, if (by your own line of reasoning) > it is the physical principle underlying these resistance settings. > Then we are likely to see it again. > > > This is confusing to people reading the > > reference manual, which never speaks about output-impedance, but > > always > > about drive-strength. > > Since we are already (obviously) confused, we have to choose > the lesser evil here. > > Apparently what (board- system-) designers want to do is match > output resistance to load, I would argue that it is more confusing > to call that "drive strength", i.e. what is misleading is not what I > am > discussing here, but the manual you are referring to. Just a bad > piece of technical writing. 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. 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. > > Hardware people (the ones responsible to come up with the padctrl > > settings) are much more likely to read the reference manual than > > any > > idealized dt-binding. > > Can we talk to them about this? > > I don't like to think about them as some foreign people in a far > away dimension we can never understand or communicate > with, how do they really do what they do? I wasn't referring to the chip design people, but board designers. I talk to them quite often, but it's a lot easier if the Linux people and board designers agree on the terms used. :) > > I want to make it as easy as possible for them to > > match up the hardware and reference manual with the DT description. > > I was hoping we could dig in a bit and figure out what we > are going to do and why and how these people think. > > I want to avoid poking magic values we don't really understand > into registers and using the manual as alchemic magic or > spellbook, essentially. (As so often happens...) > > > So, can we please just keep the drive-strength property and deal > > with > > it being described in different units in different hardware > > manuals? > > 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, 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. 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. 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. In the end this is about mapping 3 hardware bits to a DT description... Regards, Lucas -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Feb 6, 2018 at 4:47 PM, Lucas Stach <l.stach@pengutronix.de> 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@nxp.com, 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. > 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@kernel.org> M: Sascha Hauer <kernel@pengutronix.de> R: Fabio Estevam <fabio.estevam@nxp.com> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
SGkgTGludXMsDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTGludXMg V2FsbGVpaiBbbWFpbHRvOmxpbnVzLndhbGxlaWpAbGluYXJvLm9yZ10NCj4gU2VudDogMjAxOOW5 tDLmnIg35pelIDE3OjA5DQo+IFRvOiBMdWNhcyBTdGFjaCA8bC5zdGFjaEBwZW5ndXRyb25peC5k ZT47IEEucy4gRG9uZw0KPiA8YWlzaGVuZy5kb25nQG54cC5jb20+OyBkbC1saW51eC1pbXggPGxp bnV4LWlteEBueHAuY29tPjsgR2FyeSBCaXNzb24NCj4gPGdhcnkuYmlzc29uQGJvdW5kYXJ5ZGV2 aWNlcy5jb20+OyBWbGFkaW1pciBaYXBvbHNraXkNCj4gPHZsYWRpbWlyX3phcG9sc2tpeUBtZW50 b3IuY29tPjsgU2FzY2hhIEhhdWVyIDxrZXJuZWxAcGVuZ3V0cm9uaXguZGU+DQo+IENjOiBSb2Ig SGVycmluZyA8cm9iaEBrZXJuZWwub3JnPjsgTWFyayBSdXRsYW5kIDxtYXJrLnJ1dGxhbmRAYXJt LmNvbT47DQo+IGxpbnV4LWdwaW9Admdlci5rZXJuZWwub3JnOyBvcGVuIGxpc3Q6T1BFTiBGSVJN V0FSRSBBTkQgRkxBVFRFTkVEDQo+IERFVklDRSBUUkVFIEJJTkRJTkdTIDxkZXZpY2V0cmVlQHZn ZXIua2VybmVsLm9yZz47DQo+IHBhdGNod29yay1sc3RAcGVuZ3V0cm9uaXguZGUNCj4gU3ViamVj dDogUmU6IFtQQVRDSCB2MiAxLzNdIGR0LWJpbmRpbmdzOiBhZGQgYmluZGluZyBmb3IgaS5NWDhN USBJT01VWEMNCj4gDQo+IE9uIFR1ZSwgRmViIDYsIDIwMTggYXQgNDo0NyBQTSwgTHVjYXMgU3Rh Y2ggPGwuc3RhY2hAcGVuZ3V0cm9uaXguZGU+IHdyb3RlOg0KPiANCj4gPiBUbyBiZSBmdWxseSBo b25lc3QgSSdtIGEgYml0IGFubm95ZWQgd2l0aCB0aGUgcGluY3RybCBmcmFtZXdvcmsgbWFraW5n DQo+ID4gdGhpbmdzIChJTUhPKSB1bm5lY2Vzc2FyaWx5IGNvbXBsZXgsIGZvciB3aGF0IGlzIGJh c2ljYWxseSBhIHByZXR0eQ0KPiA+IGVhc3kgdGFzay4NCj4gDQo+IE15IGFtYml0aW9uIGlzIHRv IG1ha2UgdGhpbmdzIHJlYWRhYmxlLCB1bmRlcnN0YW5kYWJsZSBhbmQgbWFpbnRhaW5hYmxlLiBJ bg0KPiBnZW5lcmljIHRlcm1zLCBpbmNvcnBvcmF0aW5nIGEgYnVuY2ggb2Yga25vd2xlZGdlIG9m IHRoZSBlbGVjdHJvbmljcyB0aGF0IHJlYWxseQ0KPiBoYXBwZW4gaW50byB0aGUgc3R1ZmYgd2Ug ZW5jb2RlIGluIHRoZSBrZXJuZWwuDQo+IA0KPiBJIGd1ZXNzIGl0IHZhcmllcyBhIGJpdCBvbiB3 aGF0IGdvYWwgb25lIGhhcy4NCj4gDQo+IElmIHRoZSBnb2FsIGlzICJzaGlwIHByb2R1Y3Qgd2l0 aCB1cHN0cmVhbSBrZXJuZWwgcmVhbGx5IGZhc3Qgbm93Ig0KPiB0aGVuIHRoaW5ncyBsaWtlIHBp bmN0cmwtc2luZ2xlLmMgd2hlcmUgd2UganVzdCBoYW1tZXIgbWFnaWMgdmFsdWVzIGludG8NCj4g cmVnaXN0ZXJzLCBtYWtlIHNlbnNlLiBPTUFQIGRldmVsb3BlcnMgaGFkIG5vIGlkZWEgd2hhdHNv ZXZlciB3aGF0IHRoZWlyDQo+IEFTSUMgcGVvcGxlIG9yIGNlbGwgbGlicmFyeSBhdXRob3JzIHdl cmUgZG9pbmcgc28gdGhleSBqdXN0IHRocmV3IGluIHRoZSB0b3dlbC4NCj4gSGlTaWxpY29uIGFs c28gdXNlIHRoaXMuIEludGVscyBhbWJpdGlvbiB3YXMgdG8gdXNlIEFDUEkgQklPUyB0byBoYW5k bGUgYWxsIHBpbg0KPiBjb250cm9sIGFuZCByb3V0ZSBhcm91bmQgdGhlIGtlcm5lbCBhbHRvZ2V0 aGVyLCBidXQgdGhhdCBpcyBub3Qgd29ya2luZyBvdXQgc28NCj4gd2VsbCBmb3IgdGhlbSBJIHRo aW5rLg0KPiANCj4gQWxsIG9mIHRoZW0gYXJlIGFwcHJvYWNoZXMgdG8gYXZvaWQgcHV0dGluZyB0 aGUgaGFpcnkgZGV0YWlscyBpbnRvIHRoZSBrZXJuZWwsIGp1c3QNCj4gcG9rZSBzb21lIG1hZ2lj IHZhbHVlcyBpbnRvIHNvbWUgbWFnaWMgcmVnaXN0ZXJzIGFuZCBiZSBoYXBweS4NCj4gDQo+IFNv IGkuTVggY291bGQgaGF2ZSBiZWVuIGxpa2UgdGhhdCwgYnV0IHRoZW4gSSBndWVzcyB5b3UgbmVl ZCB0byB0YWtlIGxlZ2FjeSBpbnRvDQo+IGFjY291bnQgYW5kIGRpc2N1c3Mgd2l0aCB0aGUgb3Ro ZXIgaS5NWCBkcml2ZXIgYXV0aG9ycyBhYm91dCBob3cgdGhleSByZWFsbHkNCj4gd2FudGVkIGFu ZCB3YW50IHRvIGRvIHRoaW5ncy4NCj4gDQo+IFRoZWlyIGN1cnJlbnQgc2lsZW5jZSB3cnQgdGhp cyBtYWlsY2hhaW4gaXMgYWN0dWFsbHkgYmVjb21pbmcgYSBwcm9ibGVtLCBhbmQgdGhlDQo+IHBy b2JsZW0gaXMgdGhhdCBkaXNjdXNzaW5nIHdpdGggeW91IGZhbGxzIHVwd2FyZHMgdG8gbWUgYXMg c3Vic3lzdGVtIG1haW50YWluZXIuDQo+IFdoaWNoIHN1Y2tzLiBJIHByZWZlciB0aGF0IHBlb3Bs ZSB3aG8ga25vdyB0aGlzIGhhcmR3YXJlIGRpc2N1c3MgYW1vbmdzdA0KPiB0aGVtc2VsdmVzIGhv dyB0aGV5IHdhbnQgdGhpbmdzIHRvIHdvcmsuDQo+IA0KPiBTdXJlbHkgU2FzY2hhIG11c3QgaGF2 ZSBhbiBvcGluaW9uPyBJdCBtZWFucyBtdWNoIHRvIG1lIHdoYXQgaGUgd2FudHMgdG8gZG8uDQo+ IEkgdGFrZSBpdCB5b3UgZ3V5cyBhcmUgY29sbGVhZ3Vlcz8NCj4gDQo+ID4gUGVuZ3V0cm9uaXgg aXMgbW9zdGx5IGNvbnRyYWN0ZWQgYnkgY3VzdG9tZXJzIG9mIE5YUCB0byBlbmFibGUgc3R1ZmYN Cj4gPiBpbiBtYWlubGluZS4gU28gSSdtIG5vdCB3b3JraW5nIG9uIHRoaXMgaW4gbXkgc3BhcmUg dGltZSwgYnV0IEkgc3RpbGwNCj4gPiBoYXZlIHRvIGRlYWwgd2l0aCB0aGUgZmFjdCB0aGF0IEkg Y2FuIG9ubHkgZ2V0IHRoZSBpbmZvcm1hdGlvbiBmcm9tDQo+ID4gdGhlIHJlZmVyZW5jZSBtYW51 YWwsIE5YUCBkb3duc3RyZWFtIEJTUHMgYW5kIHRoZSBvY2Nhc2lvbmFsIGhlbHBmdWwNCj4gPiBO WFAgZW1wbG95ZWUuDQo+IA0KPiBIbSBJIHNlZSwgdGhpcyBzZWVtcyBsaWtlIGEgYml0IG9mIGNy YXBweSBwb3NpdGlvbiB0byBiZSBpbiB3aGVuIHlvdSBqdXN0IHdhbnQgdG8NCj4gYXNrIHNvbWVv bmUgaW4gaGFyZHdhcmUgaG93IHRoaW5ncyByZWFsbHkgd29yay4NCj4gDQo+IEJ1dCB3ZSBoYXZl IEZyZWVzY2FsZSBpLk1YIG1haW50YWluZXJzIG9uIHRoZSBpbnNpZGUgb2YgdGhlIGNvbXBhbnkg bm93IE5YUA0KPiAoc29vbiBRdWFsY29tbT8gc29vbiBCcm9hZGNvbT8pLg0KPiANCj4gSGVsbCB0 aGlzIG1haWwgaXMgZXZlbiBnb2luZyB0byBsaW51eC1pbXhAbnhwLmNvbSwgd2hhdCBkbyB0aGV5 IGRvIHdpdGggaXQ/IFB1dA0KPiBpdCBpbiBhIG1haWxib3ggYW5kIG5ldmVyIHJlYWQgaXQ/DQo+ IA0KPiBTdXJlbHkgc29tZW9uZSBvbiB0aGUgaW5zaWRlIG11c3QgYmUgYWJsZSB0byBwcm92aWRl IHNvbWUgZGV0YWlscy4NCj4gDQoNCkkgZmVlbCB0ZXJyaWJseSBzb3JyeSB0aGF0IGRpZCBub3Qg Y29tZSB1cCBpbiB0aGUgZmlyc3QgdGltZSB0aGVzZSB0d28gZGF5cyBhcyBJIHdhcw0KYnVzeSB3 aXRoIHNvbWUgb3RoZXIgdXJnZW50IHRoaW5ncyByZXF1ZXN0ZWQgYnkgbXkgYm9zcy4NCkl0IHNo b3VsZCBiZSBteSByZXNwb25zaWJpbGl0eSBhcyBJIHByb21pc2VkIHRvIHRha2UgdGhhdCBvd25l cnNoaXAgYmVmb3JlLg0KDQpJIHF1aWNrbHkgd2VudCB0aHJvdWdoIHRoZSBlbWFpbCBhbmQgSSBm dWxseSB1bmRlcnN0YW5kIHlvdXIgY29uY2Vybi4NCkFzIEknbSBub3QgYSBzcGVjaWFsaXN0IG9u IHRoZSBIVyBpbnRlcm5hbHMgb2YgSU9NVVggZGVzaWduLCBpIGFscmVhZHkgZm9yd2FyZGVkIHRo ZQ0KSXNzdWUgdG8gb3VyIElQIG93bmVyLiANCg0KRHVlIHRvIGl0J3MgYWxyZWFkeSBvZmYgd29y ayB0aW1lIGF0IG15IHNpZGUsIEkgd2lsbCBkaXNjdXNzIHdpdGggaGltIHRvbW9ycm93DQpNb3Ju aW5nIGFuZCBnZXQgYmFjayB0byB5b3UgbGF0ZXIuDQoNCkFuZCBpIHdpbGwgY2FyZWZ1bGx5IHJl dmlldyB0aGUgcmVmZXJlbmNlIG1hbnVhbCBhbmQgZG9jIG9uIG15IGhhbmRzLg0KSG9wZWZ1bGx5 IEkgY2FuIGdpdmUgeW91IHNvbWUgaW5mb3JtYXRpb24gbGF0ZXIgeW91IHdhbnQuDQoNClJlZ2Fy ZHMNCkRvbmcgQWlzaGVuZw0KDQo+ID4gQWxzbyBldmVuIGlmIHdlIHdlcmUgaW5zaWRlIG9mIE5Y UCwgcGFkIGNlbGxzIGFyZSB1c3VhbGx5IHNvbWV0aGluZw0KPiA+IHRoYXQgY2hpcCBtYWtlcnMg YnV5IG9yIGdldCBmcm9tIHRoZSBGYWIgZGVzaWduIGxpYnJhcnkuIFNvIHByb2JhYmx5DQo+ID4g ZXZlbiB0aGV5IGRvbid0IGtub3cgd2hhdCdzIGluc2lkZSBleGFjdGx5Lg0KPiANCj4gWWVhaCB0 aGF0IGlzIHdoYXQgSSBjYWxsICJ0aHJvdyBvdmVyIHRoZSB3YWxsIGVuZ2luZWVyaW5nIi4NCj4g SXQncyBub3QgZ29vZCwgaWYgTlhQIHdvcmtzIHdpdGggaW5mb3JtYXRpb24gYnJpY2sgd2FsbHMg bGlrZSB0aGF0IGl0IGlzIG5vdCBhbnkgZ29vZA0KPiBmb3IgdGhlbSwgYmVjYXVzZSBpdCBpcyBu b3QgYW55IGdvb2QgZm9yIHRoZWlyIGN1c3RvbWVycy4NCj4gDQo+IE5vdCBzb21ldGhpbmcgeW91 IG9yIEkgY2FuIGZpeCB0aG91Z2guLi4NCj4gDQo+ID4gV2hhdCB1c3VhbGx5IGhhcHBlbnMgaXMg dGhhdCBoYXJkd2FyZSAoSSdtIHRhbGtpbmcgYWJvdXQgYm9hcmQvc3lzdGVtDQo+ID4gaGVyZSkg ZGVzaWduZXJzIHN0YXJ0IGJ5IHJlYWRpbmcgdGhlIHJlZmVyZW5jZSBtYW51YWwgYW5kIGhhcmR3 YXJlDQo+ID4gZGVzaWduIGd1aWRlIGFuZCB3b3JrIHdpdGggdGhhdC4gVGhleSBjb21lIHVwIHdp dGggYWxsIHRoZSBuZWNlc3NhcnkNCj4gPiBjb25maWd1cmF0aW9uIGluIHRoZSB0ZXJtcyBvZiB0 aGUgbWFudWFsLg0KPiANCj4gU29tZXRpbWVzIGhhbGYtZ3Vlc3NpbmcgYW5kIGEgYml0IG9mIHRy aWFsLWFuZC1lcnJvciByaWdodD8NCj4gDQo+ID4gQWZ0ZXIgdGhhdCB0aGV5IG9yIHNvbWVvbmUg ZWxzZSBoYXMgdG8gdHJhbnNsYXRlIHRoaXMgaW50byBEVC4gVGhpbmdzDQo+ID4gZ2V0IGNvbmZ1 c2luZyB3aGVuIHRoZSByZWZlcmVuY2UgbWFudWFsIGFuZCB0aGUgRFQgYmluZGluZyBkaXNhZ3Jl ZQ0KPiA+IGFib3V0IHRoZSB1c2VkIHRlcm1zLg0KPiANCj4gSSBzZWUuDQo+IA0KPiA+PiBJZiB5 b3Ugd2FudCBzb21ldGhpbmcgdG8gbWF0Y2ggdGhlIHNwZWNpZmljIGhhcmR3YXJlIG1hbnVhbCBm cm9tIE5YUA0KPiA+PiBhbmQgeW91IGRvbid0IHdhbnQgaXQgdG8gYmUgdHJhbnNsYXRlZCBpbnRv IHRoZSB1bml0cyBvZiB0aGUgRFQNCj4gPj4gYmluZGluZywgdGhlbiBJIHRoaW5rIGl0IGlzIGJl dHRlciB0byB1c2Ugc29tZXRoaW5nIHByZWZpeGVkICJueHAsKiIuDQo+ID4NCj4gPj4gVGhhdCBj bGVhcmx5IGluZGljYXRlcyB0aGF0IHRoaXMgaXMgc29tZSBOWFAgb2RkaXR5IHRoYXQgd2UgZG9u J3QNCj4gPj4gcmVhbGx5IHVuZGVyc3RhbmQuDQo+ID4NCj4gPiBJJ20gbm90IGtlZW4gb24gdXNp bmcgdGhlIGNvbW1vbiBwYWRjdHJsIHN0dWZmLCB3aGljaCBhbHJlYWR5IGJsb2F0cw0KPiA+IHRo ZSBEVCBkZXNjcmlwdGlvbiBjb21wYXJlZCB0byBpLk1YNiwNCj4gDQo+IFRoaXMgeW91IG5lZWQg dG8gZGlzY3VzcyB3aXRoIHRoZSBnZW5lcmljIGkuTVggZHJpdmVyIG1haW50YWluZXJzLg0KPiBU aGV5IGFyZSB0aGUgbWFpbnRhaW5lcnMgb2YgZHJpdmVycy9waW5jdHJsL2ZyZWVzY2FsZS8qIGFm dGVyIGFsbC4NCj4gDQo+IFRoZXkgbmV2ZXIgcHV0IGFuIGVudHJ5IGluIE1BSU5UQUlORVJTIHRo b3VnaCwgYnV0IEkgYWx3YXlzIHJlZ2FyZGVkIHRoZXNlIGFzDQo+IHRoZSBwaW5jdHJsIG1haW50 YWluZXJzIGZvciBpLk1YOg0KPiANCj4gQVJNL0ZSRUVTQ0FMRSBJTVggLyBNWEMgQVJNIEFSQ0hJ VEVDVFVSRQ0KPiBNOiAgICAgIFNoYXduIEd1byA8c2hhd25ndW9Aa2VybmVsLm9yZz4NCj4gTTog ICAgICBTYXNjaGEgSGF1ZXIgPGtlcm5lbEBwZW5ndXRyb25peC5kZT4NCj4gUjogICAgICBGYWJp byBFc3RldmFtIDxmYWJpby5lc3RldmFtQG54cC5jb20+DQo+IA0KPiBPbiB0b3Agb2YgdGhpcywg RG9uZyBBaXNoZW5nLCBHYXJ5IEJpc3NvbiBhbmQgVmxhZGltaXIgWmFwb2xza2l5IGhhcyBtYWRl IG1ham9yDQo+IGNvbnRyaWJ1dGlvbnMuDQo+IA0KPiBJdCdzIGEgbGl0dGxlIGVjb3N5c3RlbSBv biBpdHMgb3duLCBub3QgcmVhbGx5IHRvIGJlIGRpc2N1c3NlZCBieSBqdXN0IHlvdSBhbmQgbWUu IEkNCj4gd29uZGVyIHdoZXJlIHRoZSByZXN0IG9mIHRoZSB2b2ljZXMgYXJlLCBJIGhvcGUgbm90 IHNpbGVuY2VkIGJ5IG9yZ2FuaXphdGlvbmFsDQo+IHN0cmVzcyBhZnRlciB0aGUgTlhQIG1lcmdl ci4uLg0KPiANCj4gPiBhbmQgdGhlbiBhZ2FpbiBuZWVkIHRvIGludHJvZHVjZQ0KPiA+IGN1c3Rv bSBwcm9wZXJ0aWVzLiBUaGF0J3MganVzdCB3b3JzdCBvZiBib3RoIHdvcmxkcywgdmVyYm9zZSBE VCB0byB1c2UNCj4gPiB0aGUgY29tbW9uIHN0dWZmLCBtaXhlZCB3aXRoIHNwZWNpYWwgcHJvcGVy dGllcywgb25seSB2YWxpZCBvbiB0aGlzDQo+ID4gc2luZ2xlIGNvbnRyb2xsZXIuDQo+IA0KPiBO byBtYXR0ZXIgaG93IG11Y2ggeW91IGRpc2xpa2UgaXQsIGl0IGlzIHdoYXQgZS5nLiBRdWFsY29t bSBpcyBkb2luZy4gKFdobw0KPiBtaWdodCBzb29uIGJlIG9uZSBhbmQgdGhlIHNhbWUgYXMgTlhQ IEkgaGVhci4pDQo+IA0KPiA+IElmIHlvdSBpbnNpc3QgSSBndWVzcyBJJ20gZmluZSB3aXRoIGNv bXByb21pc2luZyBvbiBhbiAib3V0cHV0LQ0KPiA+IGltcGVkYW5jZSIgY29tbW9uIHByb3BlcnR5 LCBidXQgdGhlbiB0aGlzIGp1c3QgbWFrZXMgdGhpbmdzIGhhcmRlciBmb3INCj4gPiBldmVyeW9u ZSBpbnZvbHZlZCwgYXMgdGhlIGltcGVkYW5jZSBldmVuIHNlZW1zIHRvIHZhcnkgc2xpZ2h0bHkg d2l0aA0KPiA+IHRoZSB1c2VkIHBhZCB2b2x0YWdlLiBTbyB0byBub3QgZ2V0IGludG8gYSBjb21i aW5hdG9yaWFsIGV4cGxvc2lvbiwgd2UNCj4gPiB3b3VsZCBuZWVkIHRvIGRlc2NyaWJlIHRoaXMg cHJvcGVydHkgYXMgc29tZXRoaW5ncyBsaWtlICJvdXRwdXQNCj4gPiBpbXBlZGFuY2UgYXQgMy4z dikiLCBhdCBsZWFzdCBvbiB0aGlzIHNwZWNpZmljIGhhcmR3YXJlLg0KPiANCj4gSG0sIHNob3Vs ZCBpdCBtZSAibnhwLGRyaXZlLXN0cmVuZ3RoIiB0aGVuLCBhcyBpdCBpcyBqdXN0IHNvbWUgbWFn aWMgdmFsdWU/IEkNCj4gZ3Vlc3MgIm54cCxtYWdpYy1kcml2ZS1zdHJlbmd0aCIgaXMgbm90IGdv aW5nIHRvIGN1dCBpdCA6RA0KPiANCj4gQWxzbyBtYXliZSB3ZSBzaG91bGQgdXNlIHRoZSBvbGQg ImZyZWVzY2FsZSwqIiBub3RhdGlvbiBmb3IgbGVnYWN5IHJlYXNvbnMuLi4gSQ0KPiBkb24ndCBr bm93LiBUaGlzIFZlbmRvciBwcmVmaXggc2VlbXMgbGVzcyBzdGFibGUgdGhhbiB0aGUgY2hpcHNl dHMuDQo+IA0KPiA+IE9yIHdlIGNvdWxkIGFncmVlIHRoYXQgZHJpdmUtc3RyZW5ndGggcHJvcGVy dHkgY291bGQgYmUgZGVzY3JpYmVkIGluDQo+ID4gc29tZSB1bml0IHRoYXQgbWFrZXMgc2Vuc2Ug b24gZWFjaCBjb250cm9sbGVyLiBtQSBmb3IgaGFyZHdhcmUNCj4gPiBkZXNjcmliZWQgd2l0aCBz b21lIGZhYmxlZCBpZGVhbCBsb2FkIG1hdGNoaW5nLCBPaG1zIGZvciBoYXJkd2FyZSB0aGF0DQo+ ID4gbW9kZWxzIGl0IHRoaXMgd2F5IHdpdGggbWF4aW11bSBkcml2ZSBzdHJlbmd0aCBhdCB0aGUg cG9pbnQgb2YgYmVzdA0KPiA+IGxvYWQgbWF0Y2hpbmcuDQo+IA0KPiBJIGFtIG5vdCBsaWtlIHN0 dWJib3JubHkgYWdhaW5zdC4gSSBqdXN0IHdhbnQgc29tZSBkaXNjdXNzaW9uIGhlcmUsIGl0IHdv dWxkIGJlDQo+IG5pY2UgdG8ga25vdyB0aGUgb3BpbmlvbiBvZiB0aGUgaS5NWCBtYWludGFpbmVy cy4NCj4gDQo+ID4gSW4gdGhlIGVuZCB0aGlzIGlzIGFib3V0IG1hcHBpbmcgMyBoYXJkd2FyZSBi aXRzIHRvIGEgRFQgZGVzY3JpcHRpb24uLi4NCj4gDQo+IFBsZWFzIGRvbid0IHRoaW5rIGFib3V0 IGl0IGxpa2UgImNhbid0IHdlIGp1c3QgZG8gdGhpcyByZWFsIHNpbXBsZSB0aGluZyBub3csIGp1 c3QNCj4gbWVyZ2UgdGhpcyBhbmQgc3RvcCBiZWluZyBhbiBhc3MiLg0KPiANCj4gVGhpbmdzIGp1 c3QgcG9raW5nIHRocmVlIGJpdHMgY2FuIGxvb2sgdmVyeSBzaW1wbGUsIGxpa2UgaW4gc28gbWFu eSBCU1BzOg0KPiANCj4gdm9sYXRpbGUgdW5zaWduZWQgbG9uZyAqZm9vOw0KPiANCj4gZm9vID0g KHVuc2lnbmVkIGxvbmcgKikgMHhmZWMwYmUwMDsNCj4gKmZvbyAmPSB+MHg3MDA7DQo+ICpmb28g fD0gMHgyMDA7IC8qIGRvIHRoZSBtYWdpYyAqLw0KPiANCj4gQnV0IHRoaXMgaXMgbm90IGhlbHBm dWwgZm9yIGRldmVsb3BlcnMgb3IgbWFpbnRhaW5lcnMuIFRoYXQgaXMgSU1ITyB3aHkgd2UgaGF2 ZQ0KPiB0aGUgZnJhbWV3b3JrcyBhbmQgYWxsIHRoZSBEVCBzdGFuZGFyZGl6YXRpb24gaW4gdGhl IGZpcnN0IHBsYWNlLCBleGFjdGx5IHNvIHdlDQo+IHVuZGVyc3RhbmQgd2hhdCB3ZSBhcmUgZG9p bmcuDQo+IA0KPiBZb3VycywNCj4gTGludXMgV2FsbGVpag0K -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Feb 07, 2018 at 10:09:20AM +0100, Linus Walleij wrote: > On Tue, Feb 6, 2018 at 4:47 PM, Lucas Stach <l.stach@pengutronix.de> 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? My opinion is that all that is generic about padctrl is a device driver saying "Put my pins into a suitable mode". That is what padctrl is good for and we are there for years now. I have always been happy with the plain register values in the device tree. Before device tree we had exactly these values in the board files and I never heard anyone complaining about it. There were defines for the bits in the register which you could use when you were unhappy with plain register values. It's really trivial to look in the reference manual to make up the needed register values. It's also trivial to take a register value and look into the reference manual what this value does. Every translation layer, call it generic properties, just makes things more complicated. Often enough our input is register value tables from either our customers our from spreadsheets from FSL/NXP. Every translation layer in the way just means we have to translate the already existing register values into something hoping that this correctly translates back into the register values. It's not that some board designer comes up with "I need a drive strength of 150mA" and wants to put that value into the device tree. Instead they start with the reference manual, see which values they can (must) adjust and then adjust the values until they are happy. No one wants to ask questions like "How do I have to manipulate that device tree to change that particular bit?" As said, I am happy with plain register values in the device tree and I consider everything else overengineered. FSL/NXP Reference Manuals are freely available and of high quality so everybody can understand the register values. There's nothing magic to them. That might change slightly when the Manuals are not available, but even then I think that not the device tree ABI is the right place to add that missing documentation. Sascha
[Adding Shawn on Cc] On Wed, Feb 7, 2018 at 9:11 AM, Sascha Hauer <s.hauer@pengutronix.de> wrote: > My opinion is that all that is generic about padctrl is a device driver > saying "Put my pins into a suitable mode". That is what padctrl is good > for and we are there for years now. I have always been happy with the > plain register values in the device tree. Before device tree we had > exactly these values in the board files and I never heard anyone > complaining about it. There were defines for the bits in the register > which you could use when you were unhappy with plain register values. > > It's really trivial to look in the reference manual to make up the > needed register values. It's also trivial to take a register value > and look into the reference manual what this value does. Every > translation layer, call it generic properties, just makes things more > complicated. Often enough our input is register value tables > from either our customers our from spreadsheets from FSL/NXP. Every > translation layer in the way just means we have to translate the already > existing register values into something hoping that this correctly > translates back into the register values. > > It's not that some board designer comes up with "I need a drive strength > of 150mA" and wants to put that value into the device tree. Instead they > start with the reference manual, see which values they can (must) adjust > and then adjust the values until they are happy. No one wants to ask > questions like "How do I have to manipulate that device tree to change > that particular bit?" > > As said, I am happy with plain register values in the device tree and > I consider everything else overengineered. > FSL/NXP Reference Manuals are freely available and of high quality so > everybody can understand the register values. There's nothing magic to > them. That might change slightly when the Manuals are not available, but > even then I think that not the device tree ABI is the right place to > add that missing documentation. I agree 100% with Sascha. I am also happy with the current plain register values in device tree. Having two methods (plain register values on most of i.MX SoCs and the new generic one for imx7ulp, imx8mq) is confusing for the end users. I would prefer to use the plain register values in device tree for all i.MX SoCs instead. Thanks -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Sascha, > -----Original Message----- > From: Sascha Hauer [mailto:s.hauer@pengutronix.de] > Sent: 2018年2月7日 19:12 > To: Linus Walleij <linus.walleij@linaro.org> > Cc: Lucas Stach <l.stach@pengutronix.de>; A.s. Dong > <aisheng.dong@nxp.com>; dl-linux-imx <linux-imx@nxp.com>; Gary Bisson > <gary.bisson@boundarydevices.com>; Vladimir Zapolskiy > <vladimir_zapolskiy@mentor.com>; Sascha Hauer <kernel@pengutronix.de>; > Mark Rutland <mark.rutland@arm.com>; Rob Herring <robh@kernel.org>; > open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS > <devicetree@vger.kernel.org>; patchwork-lst@pengutronix.de; > linux-gpio@vger.kernel.org > Subject: Re: [PATCH v2 1/3] dt-bindings: add binding for i.MX8MQ IOMUXC > > On Wed, Feb 07, 2018 at 10:09:20AM +0100, Linus Walleij wrote: > > On Tue, Feb 6, 2018 at 4:47 PM, Lucas Stach <l.stach@pengutronix.de> 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? > > My opinion is that all that is generic about padctrl is a device driver saying "Put > my pins into a suitable mode". That is what padctrl is good for and we are there > for years now. I have always been happy with the plain register values in the > device tree. Before device tree we had exactly these values in the board files > and I never heard anyone complaining about it. There were defines for the bits > in the register which you could use when you were unhappy with plain register > values. > > It's really trivial to look in the reference manual to make up the needed register > values. It's also trivial to take a register value and look into the reference > manual what this value does. Every translation layer, call it generic properties, > just makes things more complicated. Often enough our input is register value > tables from either our customers our from spreadsheets from FSL/NXP. Every > translation layer in the way just means we have to translate the already existing > register values into something hoping that this correctly translates back into the > register values. > > It's not that some board designer comes up with "I need a drive strength of > 150mA" and wants to put that value into the device tree. Instead they start > with the reference manual, see which values they can (must) adjust and then > adjust the values until they are happy. No one wants to ask questions like "How > do I have to manipulate that device tree to change that particular bit?" > > As said, I am happy with plain register values in the device tree and I consider > everything else overengineered. > FSL/NXP Reference Manuals are freely available and of high quality so everybody > can understand the register values. There's nothing magic to them. That might > change slightly when the Manuals are not available, but even then I think that > not the device tree ABI is the right place to add that missing documentation. > Probably as I first implemented generic pinconfig support for i.MX, personally I'm tend to it a bit, mainly because below reasons we find in real situations: First and most important, plain register value is a bit error prone. (Actually we meet many times of issues during internal development). User has to compose it manually by refer to reference manual which might be more easy to mistake than using standard binding property. And not everyone would like to compose the register value manually when writing their device tree, they may simply do copy & paste of an exist one and quickly test, if it works, everything is done. They don't know which setting is actually used as they can see nothing from the plain register value. Untill the device becomes unwork in some special circumstances, then they have to waste a lot time to find out the pad setting issue. This happens especially more often when switch to a new SoC while the pad config register layout changed a bit. We certainly would like to avoid it! Secondly, plain register value is also unreadable and unmaintainable, also not quite friendly in reviewing other one's patches. Last, it might be trivial, people don't want to refer to reference manual again and again once being asked which driver strength or something else Is used. Regards Dong Aisheng > Sascha > > -- > Pengutronix e.K. | > | > Industrial Linux Solutions | > https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.p > engutronix.de%2F&data=02%7C01%7Caisheng.dong%40nxp.com%7C2644d871 > 2e234a6c2e7a08d56e1b9b29%7Cbd8a2a2207224ec7b35f1c4f0497e341%7C0% > 7C0%7C636535987211269744&sdata=vImuWxtT7Ya0uxEHrnROUYZ%2BiCWLs8 > LmxWB5oNPcgjk%3D&reserved=0 | > Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | > Amtsgericht Hildesheim, HRA 2686 | Fax: > +49-5121-206917-5555 |
On Wed, Feb 07, 2018 at 01:21:44PM +0000, A.s. Dong wrote: > Hi Sascha, > > > -----Original Message----- > > From: Sascha Hauer [mailto:s.hauer@pengutronix.de] > > Sent: 2018年2月7日 19:12 > > To: Linus Walleij <linus.walleij@linaro.org> > > Cc: Lucas Stach <l.stach@pengutronix.de>; A.s. Dong > > <aisheng.dong@nxp.com>; dl-linux-imx <linux-imx@nxp.com>; Gary Bisson > > <gary.bisson@boundarydevices.com>; Vladimir Zapolskiy > > <vladimir_zapolskiy@mentor.com>; Sascha Hauer <kernel@pengutronix.de>; > > Mark Rutland <mark.rutland@arm.com>; Rob Herring <robh@kernel.org>; > > open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS > > <devicetree@vger.kernel.org>; patchwork-lst@pengutronix.de; > > linux-gpio@vger.kernel.org > > Subject: Re: [PATCH v2 1/3] dt-bindings: add binding for i.MX8MQ IOMUXC > > > > On Wed, Feb 07, 2018 at 10:09:20AM +0100, Linus Walleij wrote: > > > On Tue, Feb 6, 2018 at 4:47 PM, Lucas Stach <l.stach@pengutronix.de> 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? > > > > My opinion is that all that is generic about padctrl is a device driver saying "Put > > my pins into a suitable mode". That is what padctrl is good for and we are there > > for years now. I have always been happy with the plain register values in the > > device tree. Before device tree we had exactly these values in the board files > > and I never heard anyone complaining about it. There were defines for the bits > > in the register which you could use when you were unhappy with plain register > > values. > > > > It's really trivial to look in the reference manual to make up the needed register > > values. It's also trivial to take a register value and look into the reference > > manual what this value does. Every translation layer, call it generic properties, > > just makes things more complicated. Often enough our input is register value > > tables from either our customers our from spreadsheets from FSL/NXP. Every > > translation layer in the way just means we have to translate the already existing > > register values into something hoping that this correctly translates back into the > > register values. > > > > It's not that some board designer comes up with "I need a drive strength of > > 150mA" and wants to put that value into the device tree. Instead they start > > with the reference manual, see which values they can (must) adjust and then > > adjust the values until they are happy. No one wants to ask questions like "How > > do I have to manipulate that device tree to change that particular bit?" > > > > As said, I am happy with plain register values in the device tree and I consider > > everything else overengineered. > > FSL/NXP Reference Manuals are freely available and of high quality so everybody > > can understand the register values. There's nothing magic to them. That might > > change slightly when the Manuals are not available, but even then I think that > > not the device tree ABI is the right place to add that missing documentation. > > > > Probably as I first implemented generic pinconfig support for i.MX, personally > I'm tend to it a bit, mainly because below reasons we find in real situations: > > First and most important, plain register value is a bit error prone. > (Actually we meet many times of issues during internal development). > User has to compose it manually by refer to reference manual > which might be more easy to mistake than using standard binding property. > > And not everyone would like to compose the register value manually > when writing their device tree, they may simply do copy & paste of an exist one > and quickly test, if it works, everything is done. They don't know which setting is actually > used as they can see nothing from the plain register value. Untill the device becomes > unwork in some special circumstances, then they have to waste a lot time to find out > the pad setting issue. This happens especially more often when switch to > a new SoC while the pad config register layout changed a bit. > We certainly would like to avoid it! > > Secondly, plain register value is also unreadable and unmaintainable, > also not quite friendly in reviewing other one's patches. > > Last, it might be trivial, people don't want to refer to reference manual > again and again once being asked which driver strength or something else > Is used. These issues could be solved by bitmask defines aswell, no need to bloat the dtbs with strings. Sascha
On Wed, Feb 07, 2018 at 09:41:22AM -0200, Fabio Estevam wrote: > [Adding Shawn on Cc] Thanks Fabio. > On Wed, Feb 7, 2018 at 9:11 AM, Sascha Hauer <s.hauer@pengutronix.de> wrote: > > > My opinion is that all that is generic about padctrl is a device driver > > saying "Put my pins into a suitable mode". That is what padctrl is good > > for and we are there for years now. I have always been happy with the > > plain register values in the device tree. Before device tree we had > > exactly these values in the board files and I never heard anyone > > complaining about it. There were defines for the bits in the register > > which you could use when you were unhappy with plain register values. > > > > It's really trivial to look in the reference manual to make up the > > needed register values. It's also trivial to take a register value > > and look into the reference manual what this value does. Every > > translation layer, call it generic properties, just makes things more > > complicated. Often enough our input is register value tables > > from either our customers our from spreadsheets from FSL/NXP. Every > > translation layer in the way just means we have to translate the already > > existing register values into something hoping that this correctly > > translates back into the register values. > > > > It's not that some board designer comes up with "I need a drive strength > > of 150mA" and wants to put that value into the device tree. Instead they > > start with the reference manual, see which values they can (must) adjust > > and then adjust the values until they are happy. No one wants to ask > > questions like "How do I have to manipulate that device tree to change > > that particular bit?" > > > > As said, I am happy with plain register values in the device tree and > > I consider everything else overengineered. > > FSL/NXP Reference Manuals are freely available and of high quality so > > everybody can understand the register values. There's nothing magic to > > them. That might change slightly when the Manuals are not available, but > > even then I think that not the device tree ABI is the right place to > > add that missing documentation. > > I agree 100% with Sascha. I would vote for not going generic pinconf either, as the controversy here starts from something, that indicates the generic stuff doesn't work for i.MX. Shawn -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBBLnMuIERvbmcNCj4gU2VudDog MjAxOOW5tDLmnIg35pelIDE5OjAzDQo+IFRvOiAnTGludXMgV2FsbGVpaicgPGxpbnVzLndhbGxl aWpAbGluYXJvLm9yZz47IEx1Y2FzIFN0YWNoDQo+IDxsLnN0YWNoQHBlbmd1dHJvbml4LmRlPjsg ZGwtbGludXgtaW14IDxsaW51eC1pbXhAbnhwLmNvbT47IEdhcnkgQmlzc29uDQo+IDxnYXJ5LmJp c3NvbkBib3VuZGFyeWRldmljZXMuY29tPjsgVmxhZGltaXIgWmFwb2xza2l5DQo+IDx2bGFkaW1p cl96YXBvbHNraXlAbWVudG9yLmNvbT47IFNhc2NoYSBIYXVlciA8a2VybmVsQHBlbmd1dHJvbml4 LmRlPg0KPiBDYzogUm9iIEhlcnJpbmcgPHJvYmhAa2VybmVsLm9yZz47IE1hcmsgUnV0bGFuZCA8 bWFyay5ydXRsYW5kQGFybS5jb20+Ow0KPiBsaW51eC1ncGlvQHZnZXIua2VybmVsLm9yZzsgb3Bl biBsaXN0Ok9QRU4gRklSTVdBUkUgQU5EIEZMQVRURU5FRA0KPiBERVZJQ0UgVFJFRSBCSU5ESU5H UyA8ZGV2aWNldHJlZUB2Z2VyLmtlcm5lbC5vcmc+Ow0KPiBwYXRjaHdvcmstbHN0QHBlbmd1dHJv bml4LmRlDQo+IFN1YmplY3Q6IFJFOiBbUEFUQ0ggdjIgMS8zXSBkdC1iaW5kaW5nczogYWRkIGJp bmRpbmcgZm9yIGkuTVg4TVEgSU9NVVhDDQo+IA0KPiBIaSBMaW51cywNCj4gDQo+ID4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBMaW51cyBXYWxsZWlqIFttYWlsdG86bGlu dXMud2FsbGVpakBsaW5hcm8ub3JnXQ0KPiA+IFNlbnQ6IDIwMTjlubQy5pyIN+aXpSAxNzowOQ0K PiA+IFRvOiBMdWNhcyBTdGFjaCA8bC5zdGFjaEBwZW5ndXRyb25peC5kZT47IEEucy4gRG9uZw0K PiA+IDxhaXNoZW5nLmRvbmdAbnhwLmNvbT47IGRsLWxpbnV4LWlteCA8bGludXgtaW14QG54cC5j b20+OyBHYXJ5IEJpc3Nvbg0KPiA+IDxnYXJ5LmJpc3NvbkBib3VuZGFyeWRldmljZXMuY29tPjsg VmxhZGltaXIgWmFwb2xza2l5DQo+ID4gPHZsYWRpbWlyX3phcG9sc2tpeUBtZW50b3IuY29tPjsg U2FzY2hhIEhhdWVyIDxrZXJuZWxAcGVuZ3V0cm9uaXguZGU+DQo+ID4gQ2M6IFJvYiBIZXJyaW5n IDxyb2JoQGtlcm5lbC5vcmc+OyBNYXJrIFJ1dGxhbmQNCj4gPiA8bWFyay5ydXRsYW5kQGFybS5j b20+OyBsaW51eC1ncGlvQHZnZXIua2VybmVsLm9yZzsgb3BlbiBsaXN0Ok9QRU4NCj4gPiBGSVJN V0FSRSBBTkQgRkxBVFRFTkVEIERFVklDRSBUUkVFIEJJTkRJTkdTDQo+ID4gPGRldmljZXRyZWVA dmdlci5rZXJuZWwub3JnPjsgcGF0Y2h3b3JrLWxzdEBwZW5ndXRyb25peC5kZQ0KPiA+IFN1Ympl Y3Q6IFJlOiBbUEFUQ0ggdjIgMS8zXSBkdC1iaW5kaW5nczogYWRkIGJpbmRpbmcgZm9yIGkuTVg4 TVENCj4gPiBJT01VWEMNCj4gPg0KPiA+IE9uIFR1ZSwgRmViIDYsIDIwMTggYXQgNDo0NyBQTSwg THVjYXMgU3RhY2ggPGwuc3RhY2hAcGVuZ3V0cm9uaXguZGU+IHdyb3RlOg0KPiA+DQo+ID4gPiBU byBiZSBmdWxseSBob25lc3QgSSdtIGEgYml0IGFubm95ZWQgd2l0aCB0aGUgcGluY3RybCBmcmFt ZXdvcmsNCj4gPiA+IG1ha2luZyB0aGluZ3MgKElNSE8pIHVubmVjZXNzYXJpbHkgY29tcGxleCwg Zm9yIHdoYXQgaXMgYmFzaWNhbGx5IGENCj4gPiA+IHByZXR0eSBlYXN5IHRhc2suDQo+ID4NCj4g PiBNeSBhbWJpdGlvbiBpcyB0byBtYWtlIHRoaW5ncyByZWFkYWJsZSwgdW5kZXJzdGFuZGFibGUg YW5kDQo+ID4gbWFpbnRhaW5hYmxlLiBJbiBnZW5lcmljIHRlcm1zLCBpbmNvcnBvcmF0aW5nIGEg YnVuY2ggb2Yga25vd2xlZGdlIG9mDQo+ID4gdGhlIGVsZWN0cm9uaWNzIHRoYXQgcmVhbGx5IGhh cHBlbiBpbnRvIHRoZSBzdHVmZiB3ZSBlbmNvZGUgaW4gdGhlIGtlcm5lbC4NCj4gPg0KPiA+IEkg Z3Vlc3MgaXQgdmFyaWVzIGEgYml0IG9uIHdoYXQgZ29hbCBvbmUgaGFzLg0KPiA+DQo+ID4gSWYg dGhlIGdvYWwgaXMgInNoaXAgcHJvZHVjdCB3aXRoIHVwc3RyZWFtIGtlcm5lbCByZWFsbHkgZmFz dCBub3ciDQo+ID4gdGhlbiB0aGluZ3MgbGlrZSBwaW5jdHJsLXNpbmdsZS5jIHdoZXJlIHdlIGp1 c3QgaGFtbWVyIG1hZ2ljIHZhbHVlcw0KPiA+IGludG8gcmVnaXN0ZXJzLCBtYWtlIHNlbnNlLiBP TUFQIGRldmVsb3BlcnMgaGFkIG5vIGlkZWEgd2hhdHNvZXZlcg0KPiA+IHdoYXQgdGhlaXIgQVNJ QyBwZW9wbGUgb3IgY2VsbCBsaWJyYXJ5IGF1dGhvcnMgd2VyZSBkb2luZyBzbyB0aGV5IGp1c3Qg dGhyZXcgaW4NCj4gdGhlIHRvd2VsLg0KPiA+IEhpU2lsaWNvbiBhbHNvIHVzZSB0aGlzLiBJbnRl bHMgYW1iaXRpb24gd2FzIHRvIHVzZSBBQ1BJIEJJT1MgdG8NCj4gPiBoYW5kbGUgYWxsIHBpbiBj b250cm9sIGFuZCByb3V0ZSBhcm91bmQgdGhlIGtlcm5lbCBhbHRvZ2V0aGVyLCBidXQNCj4gPiB0 aGF0IGlzIG5vdCB3b3JraW5nIG91dCBzbyB3ZWxsIGZvciB0aGVtIEkgdGhpbmsuDQo+ID4NCj4g PiBBbGwgb2YgdGhlbSBhcmUgYXBwcm9hY2hlcyB0byBhdm9pZCBwdXR0aW5nIHRoZSBoYWlyeSBk ZXRhaWxzIGludG8gdGhlDQo+ID4ga2VybmVsLCBqdXN0IHBva2Ugc29tZSBtYWdpYyB2YWx1ZXMg aW50byBzb21lIG1hZ2ljIHJlZ2lzdGVycyBhbmQgYmUgaGFwcHkuDQo+ID4NCj4gPiBTbyBpLk1Y IGNvdWxkIGhhdmUgYmVlbiBsaWtlIHRoYXQsIGJ1dCB0aGVuIEkgZ3Vlc3MgeW91IG5lZWQgdG8g dGFrZQ0KPiA+IGxlZ2FjeSBpbnRvIGFjY291bnQgYW5kIGRpc2N1c3Mgd2l0aCB0aGUgb3RoZXIg aS5NWCBkcml2ZXIgYXV0aG9ycw0KPiA+IGFib3V0IGhvdyB0aGV5IHJlYWxseSB3YW50ZWQgYW5k IHdhbnQgdG8gZG8gdGhpbmdzLg0KPiA+DQo+ID4gVGhlaXIgY3VycmVudCBzaWxlbmNlIHdydCB0 aGlzIG1haWxjaGFpbiBpcyBhY3R1YWxseSBiZWNvbWluZyBhDQo+ID4gcHJvYmxlbSwgYW5kIHRo ZSBwcm9ibGVtIGlzIHRoYXQgZGlzY3Vzc2luZyB3aXRoIHlvdSBmYWxscyB1cHdhcmRzIHRvIG1l IGFzDQo+IHN1YnN5c3RlbSBtYWludGFpbmVyLg0KPiA+IFdoaWNoIHN1Y2tzLiBJIHByZWZlciB0 aGF0IHBlb3BsZSB3aG8ga25vdyB0aGlzIGhhcmR3YXJlIGRpc2N1c3MNCj4gPiBhbW9uZ3N0IHRo ZW1zZWx2ZXMgaG93IHRoZXkgd2FudCB0aGluZ3MgdG8gd29yay4NCj4gPg0KPiA+IFN1cmVseSBT YXNjaGEgbXVzdCBoYXZlIGFuIG9waW5pb24/IEl0IG1lYW5zIG11Y2ggdG8gbWUgd2hhdCBoZSB3 YW50cyB0bw0KPiBkby4NCj4gPiBJIHRha2UgaXQgeW91IGd1eXMgYXJlIGNvbGxlYWd1ZXM/DQo+ ID4NCj4gPiA+IFBlbmd1dHJvbml4IGlzIG1vc3RseSBjb250cmFjdGVkIGJ5IGN1c3RvbWVycyBv ZiBOWFAgdG8gZW5hYmxlIHN0dWZmDQo+ID4gPiBpbiBtYWlubGluZS4gU28gSSdtIG5vdCB3b3Jr aW5nIG9uIHRoaXMgaW4gbXkgc3BhcmUgdGltZSwgYnV0IEkNCj4gPiA+IHN0aWxsIGhhdmUgdG8g ZGVhbCB3aXRoIHRoZSBmYWN0IHRoYXQgSSBjYW4gb25seSBnZXQgdGhlIGluZm9ybWF0aW9uDQo+ ID4gPiBmcm9tIHRoZSByZWZlcmVuY2UgbWFudWFsLCBOWFAgZG93bnN0cmVhbSBCU1BzIGFuZCB0 aGUgb2NjYXNpb25hbA0KPiA+ID4gaGVscGZ1bCBOWFAgZW1wbG95ZWUuDQo+ID4NCj4gPiBIbSBJ IHNlZSwgdGhpcyBzZWVtcyBsaWtlIGEgYml0IG9mIGNyYXBweSBwb3NpdGlvbiB0byBiZSBpbiB3 aGVuIHlvdQ0KPiA+IGp1c3Qgd2FudCB0byBhc2sgc29tZW9uZSBpbiBoYXJkd2FyZSBob3cgdGhp bmdzIHJlYWxseSB3b3JrLg0KPiA+DQo+ID4gQnV0IHdlIGhhdmUgRnJlZXNjYWxlIGkuTVggbWFp bnRhaW5lcnMgb24gdGhlIGluc2lkZSBvZiB0aGUgY29tcGFueQ0KPiA+IG5vdyBOWFAgKHNvb24g UXVhbGNvbW0/IHNvb24gQnJvYWRjb20/KS4NCj4gPg0KPiA+IEhlbGwgdGhpcyBtYWlsIGlzIGV2 ZW4gZ29pbmcgdG8gbGludXgtaW14QG54cC5jb20sIHdoYXQgZG8gdGhleSBkbw0KPiA+IHdpdGgg aXQ/IFB1dCBpdCBpbiBhIG1haWxib3ggYW5kIG5ldmVyIHJlYWQgaXQ/DQo+ID4NCj4gPiBTdXJl bHkgc29tZW9uZSBvbiB0aGUgaW5zaWRlIG11c3QgYmUgYWJsZSB0byBwcm92aWRlIHNvbWUgZGV0 YWlscy4NCj4gPg0KPiANCj4gSSBmZWVsIHRlcnJpYmx5IHNvcnJ5IHRoYXQgZGlkIG5vdCBjb21l IHVwIGluIHRoZSBmaXJzdCB0aW1lIHRoZXNlIHR3byBkYXlzIGFzIEkgd2FzDQo+IGJ1c3kgd2l0 aCBzb21lIG90aGVyIHVyZ2VudCB0aGluZ3MgcmVxdWVzdGVkIGJ5IG15IGJvc3MuDQo+IEl0IHNo b3VsZCBiZSBteSByZXNwb25zaWJpbGl0eSBhcyBJIHByb21pc2VkIHRvIHRha2UgdGhhdCBvd25l cnNoaXAgYmVmb3JlLg0KPiANCj4gSSBxdWlja2x5IHdlbnQgdGhyb3VnaCB0aGUgZW1haWwgYW5k IEkgZnVsbHkgdW5kZXJzdGFuZCB5b3VyIGNvbmNlcm4uDQo+IEFzIEknbSBub3QgYSBzcGVjaWFs aXN0IG9uIHRoZSBIVyBpbnRlcm5hbHMgb2YgSU9NVVggZGVzaWduLCBpIGFscmVhZHkgZm9yd2Fy ZGVkDQo+IHRoZSBJc3N1ZSB0byBvdXIgSVAgb3duZXIuDQo+IA0KPiBEdWUgdG8gaXQncyBhbHJl YWR5IG9mZiB3b3JrIHRpbWUgYXQgbXkgc2lkZSwgSSB3aWxsIGRpc2N1c3Mgd2l0aCBoaW0gdG9t b3Jyb3cNCj4gTW9ybmluZyBhbmQgZ2V0IGJhY2sgdG8geW91IGxhdGVyLg0KPiANCj4gQW5kIGkg d2lsbCBjYXJlZnVsbHkgcmV2aWV3IHRoZSByZWZlcmVuY2UgbWFudWFsIGFuZCBkb2Mgb24gbXkg aGFuZHMuDQo+IEhvcGVmdWxseSBJIGNhbiBnaXZlIHlvdSBzb21lIGluZm9ybWF0aW9uIGxhdGVy IHlvdSB3YW50Lg0KPiANCg0KSGVyZSBpcyBzb21lIGluZm9ybWF0aW9uIGZyb20gb3VyIElQIGRl c2lnbmVyLg0KSXQgcHJvYmFibHkgZXhwbGFpbnMgd2h5IGkuTVggdXNlcyBPaG0gdG8gcmVwcmVz ZW50cyBkcml2ZXIgc3RyZW5ndGguDQoNCiJFbGVjdHJpY2FsIHNwZWMgZm9yIGRpZmZlcmVudCBp bnRlcmZhY2VzIHR5cGljYWxseSBkZWZpbmUgb3V0cHV0IGRyaXZlciBpbiBPaG0uDQpTbyB3ZSBm b2xsb3cgdGhlIHNhbWUgd2F5IHRvIGNvbXBseSB3aXRoIHNwZWMgcmVxdWlyZW1lbnQuIEFsc28s IGZvciB0aGUNCmJvYXJkIGRlc2lnbmVyIGl0IGlzIGltcG9ydGFudCB0byBrbm93IHRoZSBkcml2 ZXIgaW1wZWRhbmNlIHRvIG1hdGNoIHRoZQ0KZHJpdmVyIGFuZCBQQ0IgdHJhY2UgcmVzaXN0YW5j ZS4gRGVmaW5pbmcgdGhlIGRyaXZlciBpbiBPaG0gYWxsb3dzIHRvDQpjYWxjdWxhdGUgSVIgZHJv cCwgYXMgd2VsbCBhcyBvdXRwdXQgc2xldyByYXRlLCB3aGljaCBhcmUgaW1wb3J0YW50IHRvIGtu b3cuIg0KDQpBbiBleGFtcGxlIGZyb20gZU1NQyA1LjEgc3BlYzoNCg0KVGFibGUgMjA2IC0gSS9P IGRyaXZlciBzdHJlbmd0aCB0eXBlcw0KMHgwCQk1MM6pCQl4MQ0KMHgxCQkzM86pCQl4MS41DQow eDIJCTY2zqkJCXgwLjc1DQoweDMJCTEwMM6pCXgwLjUNCjB4NAkJNDDOqQkJeDEuMg0KDQpBbmQg Zm9yIG9uZSBxdWVzdGlvbiB5b3UgYXNrZWQgaW4gYW5vdGhlciBlbWFpbC4NCi0gSXMgdGhlIGlu dGVuZGVkIHVzYWdlIGZvciBpbXBlZGFuY2UgbWF0Y2hpbmc/DQpGb3IgbG93IGZyZXF1ZW5jeSBp bnRlcmZhY2UsIGZvciBleGFtcGxlLCBJMkMvR1BJTywgaXTigJlzIG5vdCBuZWNlc3NhcnkuwqAN CkZvciBoaWdoIGZyZXF1ZW5jeSBpbnRlcmZhY2UsIGZvciBleGFtcGxlLCBERFIvSFMyMDAvSFM0 MDAvUmF3bmFuZA0KZGlmZmVyZW50aWFsIDIwME0sIGluIHRoZW9yeSwgd2Ugc2hvdWxkIGNvbnNp ZGVyIGltcGVkYW5jZSBtYXRjaGluZyBmb3INCmJldHRlciBzaWduYWwgcXVhbGl0eS4gQW55d2F5 LCB3ZSBjYW4gY2hlY2sgdGhhdCBieSBib2FyZCBsZXZlbCBzaW11bGF0aW9uDQp3aXRoIHNwaWNl IG1vZGVsLg0KDQpBbmQgSUMgZ3V5cyB0aG91Z2h0IE9obSBwcm9iYWJseSBpcyBtb3JlIHN1aXRh YmxlIGZvciBoaWdoIHNwZWVkDQpJTyBwYWRzLg0KDQpIb3BlIGl0IGhlbHBzLg0KDQpSZWdhcmRz DQpEb25nIEFpc2hlbmcNCg0KPiBSZWdhcmRzDQo+IERvbmcgQWlzaGVuZw0KPiANCj4gPiA+IEFs c28gZXZlbiBpZiB3ZSB3ZXJlIGluc2lkZSBvZiBOWFAsIHBhZCBjZWxscyBhcmUgdXN1YWxseSBz b21ldGhpbmcNCj4gPiA+IHRoYXQgY2hpcCBtYWtlcnMgYnV5IG9yIGdldCBmcm9tIHRoZSBGYWIg ZGVzaWduIGxpYnJhcnkuIFNvIHByb2JhYmx5DQo+ID4gPiBldmVuIHRoZXkgZG9uJ3Qga25vdyB3 aGF0J3MgaW5zaWRlIGV4YWN0bHkuDQo+ID4NCj4gPiBZZWFoIHRoYXQgaXMgd2hhdCBJIGNhbGwg InRocm93IG92ZXIgdGhlIHdhbGwgZW5naW5lZXJpbmciLg0KPiA+IEl0J3Mgbm90IGdvb2QsIGlm IE5YUCB3b3JrcyB3aXRoIGluZm9ybWF0aW9uIGJyaWNrIHdhbGxzIGxpa2UgdGhhdCBpdA0KPiA+ IGlzIG5vdCBhbnkgZ29vZCBmb3IgdGhlbSwgYmVjYXVzZSBpdCBpcyBub3QgYW55IGdvb2QgZm9y IHRoZWlyIGN1c3RvbWVycy4NCj4gPg0KPiA+IE5vdCBzb21ldGhpbmcgeW91IG9yIEkgY2FuIGZp eCB0aG91Z2guLi4NCj4gPg0KPiA+ID4gV2hhdCB1c3VhbGx5IGhhcHBlbnMgaXMgdGhhdCBoYXJk d2FyZSAoSSdtIHRhbGtpbmcgYWJvdXQNCj4gPiA+IGJvYXJkL3N5c3RlbQ0KPiA+ID4gaGVyZSkg ZGVzaWduZXJzIHN0YXJ0IGJ5IHJlYWRpbmcgdGhlIHJlZmVyZW5jZSBtYW51YWwgYW5kIGhhcmR3 YXJlDQo+ID4gPiBkZXNpZ24gZ3VpZGUgYW5kIHdvcmsgd2l0aCB0aGF0LiBUaGV5IGNvbWUgdXAg d2l0aCBhbGwgdGhlIG5lY2Vzc2FyeQ0KPiA+ID4gY29uZmlndXJhdGlvbiBpbiB0aGUgdGVybXMg b2YgdGhlIG1hbnVhbC4NCj4gPg0KPiA+IFNvbWV0aW1lcyBoYWxmLWd1ZXNzaW5nIGFuZCBhIGJp dCBvZiB0cmlhbC1hbmQtZXJyb3IgcmlnaHQ/DQo+ID4NCj4gPiA+IEFmdGVyIHRoYXQgdGhleSBv ciBzb21lb25lIGVsc2UgaGFzIHRvIHRyYW5zbGF0ZSB0aGlzIGludG8gRFQuDQo+ID4gPiBUaGlu Z3MgZ2V0IGNvbmZ1c2luZyB3aGVuIHRoZSByZWZlcmVuY2UgbWFudWFsIGFuZCB0aGUgRFQgYmlu ZGluZw0KPiA+ID4gZGlzYWdyZWUgYWJvdXQgdGhlIHVzZWQgdGVybXMuDQo+ID4NCj4gPiBJIHNl ZS4NCj4gPg0KPiA+ID4+IElmIHlvdSB3YW50IHNvbWV0aGluZyB0byBtYXRjaCB0aGUgc3BlY2lm aWMgaGFyZHdhcmUgbWFudWFsIGZyb20NCj4gPiA+PiBOWFAgYW5kIHlvdSBkb24ndCB3YW50IGl0 IHRvIGJlIHRyYW5zbGF0ZWQgaW50byB0aGUgdW5pdHMgb2YgdGhlIERUDQo+ID4gPj4gYmluZGlu ZywgdGhlbiBJIHRoaW5rIGl0IGlzIGJldHRlciB0byB1c2Ugc29tZXRoaW5nIHByZWZpeGVkICJu eHAsKiIuDQo+ID4gPg0KPiA+ID4+IFRoYXQgY2xlYXJseSBpbmRpY2F0ZXMgdGhhdCB0aGlzIGlz IHNvbWUgTlhQIG9kZGl0eSB0aGF0IHdlIGRvbid0DQo+ID4gPj4gcmVhbGx5IHVuZGVyc3RhbmQu DQo+ID4gPg0KPiA+ID4gSSdtIG5vdCBrZWVuIG9uIHVzaW5nIHRoZSBjb21tb24gcGFkY3RybCBz dHVmZiwgd2hpY2ggYWxyZWFkeSBibG9hdHMNCj4gPiA+IHRoZSBEVCBkZXNjcmlwdGlvbiBjb21w YXJlZCB0byBpLk1YNiwNCj4gPg0KPiA+IFRoaXMgeW91IG5lZWQgdG8gZGlzY3VzcyB3aXRoIHRo ZSBnZW5lcmljIGkuTVggZHJpdmVyIG1haW50YWluZXJzLg0KPiA+IFRoZXkgYXJlIHRoZSBtYWlu dGFpbmVycyBvZiBkcml2ZXJzL3BpbmN0cmwvZnJlZXNjYWxlLyogYWZ0ZXIgYWxsLg0KPiA+DQo+ ID4gVGhleSBuZXZlciBwdXQgYW4gZW50cnkgaW4gTUFJTlRBSU5FUlMgdGhvdWdoLCBidXQgSSBh bHdheXMgcmVnYXJkZWQNCj4gPiB0aGVzZSBhcyB0aGUgcGluY3RybCBtYWludGFpbmVycyBmb3Ig aS5NWDoNCj4gPg0KPiA+IEFSTS9GUkVFU0NBTEUgSU1YIC8gTVhDIEFSTSBBUkNISVRFQ1RVUkUN Cj4gPiBNOiAgICAgIFNoYXduIEd1byA8c2hhd25ndW9Aa2VybmVsLm9yZz4NCj4gPiBNOiAgICAg IFNhc2NoYSBIYXVlciA8a2VybmVsQHBlbmd1dHJvbml4LmRlPg0KPiA+IFI6ICAgICAgRmFiaW8g RXN0ZXZhbSA8ZmFiaW8uZXN0ZXZhbUBueHAuY29tPg0KPiA+DQo+ID4gT24gdG9wIG9mIHRoaXMs IERvbmcgQWlzaGVuZywgR2FyeSBCaXNzb24gYW5kIFZsYWRpbWlyIFphcG9sc2tpeSBoYXMNCj4g PiBtYWRlIG1ham9yIGNvbnRyaWJ1dGlvbnMuDQo+ID4NCj4gPiBJdCdzIGEgbGl0dGxlIGVjb3N5 c3RlbSBvbiBpdHMgb3duLCBub3QgcmVhbGx5IHRvIGJlIGRpc2N1c3NlZCBieSBqdXN0DQo+ID4g eW91IGFuZCBtZS4gSSB3b25kZXIgd2hlcmUgdGhlIHJlc3Qgb2YgdGhlIHZvaWNlcyBhcmUsIEkg aG9wZSBub3QNCj4gPiBzaWxlbmNlZCBieSBvcmdhbml6YXRpb25hbCBzdHJlc3MgYWZ0ZXIgdGhl IE5YUCBtZXJnZXIuLi4NCj4gPg0KPiA+ID4gYW5kIHRoZW4gYWdhaW4gbmVlZCB0byBpbnRyb2R1 Y2UNCj4gPiA+IGN1c3RvbSBwcm9wZXJ0aWVzLiBUaGF0J3MganVzdCB3b3JzdCBvZiBib3RoIHdv cmxkcywgdmVyYm9zZSBEVCB0bw0KPiA+ID4gdXNlIHRoZSBjb21tb24gc3R1ZmYsIG1peGVkIHdp dGggc3BlY2lhbCBwcm9wZXJ0aWVzLCBvbmx5IHZhbGlkIG9uDQo+ID4gPiB0aGlzIHNpbmdsZSBj b250cm9sbGVyLg0KPiA+DQo+ID4gTm8gbWF0dGVyIGhvdyBtdWNoIHlvdSBkaXNsaWtlIGl0LCBp dCBpcyB3aGF0IGUuZy4gUXVhbGNvbW0gaXMgZG9pbmcuDQo+ID4gKFdobyBtaWdodCBzb29uIGJl IG9uZSBhbmQgdGhlIHNhbWUgYXMgTlhQIEkgaGVhci4pDQo+ID4NCj4gPiA+IElmIHlvdSBpbnNp c3QgSSBndWVzcyBJJ20gZmluZSB3aXRoIGNvbXByb21pc2luZyBvbiBhbiAib3V0cHV0LQ0KPiA+ ID4gaW1wZWRhbmNlIiBjb21tb24gcHJvcGVydHksIGJ1dCB0aGVuIHRoaXMganVzdCBtYWtlcyB0 aGluZ3MgaGFyZGVyDQo+ID4gPiBmb3IgZXZlcnlvbmUgaW52b2x2ZWQsIGFzIHRoZSBpbXBlZGFu Y2UgZXZlbiBzZWVtcyB0byB2YXJ5IHNsaWdodGx5DQo+ID4gPiB3aXRoIHRoZSB1c2VkIHBhZCB2 b2x0YWdlLiBTbyB0byBub3QgZ2V0IGludG8gYSBjb21iaW5hdG9yaWFsDQo+ID4gPiBleHBsb3Np b24sIHdlIHdvdWxkIG5lZWQgdG8gZGVzY3JpYmUgdGhpcyBwcm9wZXJ0eSBhcyBzb21ldGhpbmdz DQo+ID4gPiBsaWtlICJvdXRwdXQgaW1wZWRhbmNlIGF0IDMuM3YpIiwgYXQgbGVhc3Qgb24gdGhp cyBzcGVjaWZpYyBoYXJkd2FyZS4NCj4gPg0KPiA+IEhtLCBzaG91bGQgaXQgbWUgIm54cCxkcml2 ZS1zdHJlbmd0aCIgdGhlbiwgYXMgaXQgaXMganVzdCBzb21lIG1hZ2ljDQo+ID4gdmFsdWU/IEkg Z3Vlc3MgIm54cCxtYWdpYy1kcml2ZS1zdHJlbmd0aCIgaXMgbm90IGdvaW5nIHRvIGN1dCBpdCA6 RA0KPiA+DQo+ID4gQWxzbyBtYXliZSB3ZSBzaG91bGQgdXNlIHRoZSBvbGQgImZyZWVzY2FsZSwq IiBub3RhdGlvbiBmb3IgbGVnYWN5DQo+ID4gcmVhc29ucy4uLiBJIGRvbid0IGtub3cuIFRoaXMg VmVuZG9yIHByZWZpeCBzZWVtcyBsZXNzIHN0YWJsZSB0aGFuIHRoZSBjaGlwc2V0cy4NCj4gPg0K PiA+ID4gT3Igd2UgY291bGQgYWdyZWUgdGhhdCBkcml2ZS1zdHJlbmd0aCBwcm9wZXJ0eSBjb3Vs ZCBiZSBkZXNjcmliZWQgaW4NCj4gPiA+IHNvbWUgdW5pdCB0aGF0IG1ha2VzIHNlbnNlIG9uIGVh Y2ggY29udHJvbGxlci4gbUEgZm9yIGhhcmR3YXJlDQo+ID4gPiBkZXNjcmliZWQgd2l0aCBzb21l IGZhYmxlZCBpZGVhbCBsb2FkIG1hdGNoaW5nLCBPaG1zIGZvciBoYXJkd2FyZQ0KPiA+ID4gdGhh dCBtb2RlbHMgaXQgdGhpcyB3YXkgd2l0aCBtYXhpbXVtIGRyaXZlIHN0cmVuZ3RoIGF0IHRoZSBw b2ludCBvZg0KPiA+ID4gYmVzdCBsb2FkIG1hdGNoaW5nLg0KPiA+DQo+ID4gSSBhbSBub3QgbGlr ZSBzdHViYm9ybmx5IGFnYWluc3QuIEkganVzdCB3YW50IHNvbWUgZGlzY3Vzc2lvbiBoZXJlLCBp dA0KPiA+IHdvdWxkIGJlIG5pY2UgdG8ga25vdyB0aGUgb3BpbmlvbiBvZiB0aGUgaS5NWCBtYWlu dGFpbmVycy4NCj4gPg0KPiA+ID4gSW4gdGhlIGVuZCB0aGlzIGlzIGFib3V0IG1hcHBpbmcgMyBo YXJkd2FyZSBiaXRzIHRvIGEgRFQgZGVzY3JpcHRpb24uLi4NCj4gPg0KPiA+IFBsZWFzIGRvbid0 IHRoaW5rIGFib3V0IGl0IGxpa2UgImNhbid0IHdlIGp1c3QgZG8gdGhpcyByZWFsIHNpbXBsZQ0K PiA+IHRoaW5nIG5vdywganVzdCBtZXJnZSB0aGlzIGFuZCBzdG9wIGJlaW5nIGFuIGFzcyIuDQo+ ID4NCj4gPiBUaGluZ3MganVzdCBwb2tpbmcgdGhyZWUgYml0cyBjYW4gbG9vayB2ZXJ5IHNpbXBs ZSwgbGlrZSBpbiBzbyBtYW55IEJTUHM6DQo+ID4NCj4gPiB2b2xhdGlsZSB1bnNpZ25lZCBsb25n ICpmb287DQo+ID4NCj4gPiBmb28gPSAodW5zaWduZWQgbG9uZyAqKSAweGZlYzBiZTAwOw0KPiA+ ICpmb28gJj0gfjB4NzAwOw0KPiA+ICpmb28gfD0gMHgyMDA7IC8qIGRvIHRoZSBtYWdpYyAqLw0K PiA+DQo+ID4gQnV0IHRoaXMgaXMgbm90IGhlbHBmdWwgZm9yIGRldmVsb3BlcnMgb3IgbWFpbnRh aW5lcnMuIFRoYXQgaXMgSU1ITw0KPiA+IHdoeSB3ZSBoYXZlIHRoZSBmcmFtZXdvcmtzIGFuZCBh bGwgdGhlIERUIHN0YW5kYXJkaXphdGlvbiBpbiB0aGUgZmlyc3QNCj4gPiBwbGFjZSwgZXhhY3Rs eSBzbyB3ZSB1bmRlcnN0YW5kIHdoYXQgd2UgYXJlIGRvaW5nLg0KPiA+DQo+ID4gWW91cnMsDQo+ ID4gTGludXMgV2FsbGVpag0K -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Am Donnerstag, den 08.02.2018, 16:56 +0800 schrieb Shawn Guo: > On Wed, Feb 07, 2018 at 09:41:22AM -0200, Fabio Estevam wrote: > > [Adding Shawn on Cc] > > Thanks Fabio. > > > On Wed, Feb 7, 2018 at 9:11 AM, Sascha Hauer <s.hauer@pengutronix.d > > e> wrote: > > > > > My opinion is that all that is generic about padctrl is a device > > > driver > > > saying "Put my pins into a suitable mode". That is what padctrl > > > is good > > > for and we are there for years now. I have always been happy with > > > the > > > plain register values in the device tree. Before device tree we > > > had > > > exactly these values in the board files and I never heard anyone > > > complaining about it. There were defines for the bits in the > > > register > > > which you could use when you were unhappy with plain register > > > values. > > > > > > It's really trivial to look in the reference manual to make up > > > the > > > needed register values. It's also trivial to take a register > > > value > > > and look into the reference manual what this value does. Every > > > translation layer, call it generic properties, just makes things > > > more > > > complicated. Often enough our input is register value tables > > > from either our customers our from spreadsheets from FSL/NXP. > > > Every > > > translation layer in the way just means we have to translate the > > > already > > > existing register values into something hoping that this > > > correctly > > > translates back into the register values. > > > > > > It's not that some board designer comes up with "I need a drive > > > strength > > > of 150mA" and wants to put that value into the device tree. > > > Instead they > > > start with the reference manual, see which values they can (must) > > > adjust > > > and then adjust the values until they are happy. No one wants to > > > ask > > > questions like "How do I have to manipulate that device tree to > > > change > > > that particular bit?" > > > > > > As said, I am happy with plain register values in the device tree > > > and > > > I consider everything else overengineered. > > > FSL/NXP Reference Manuals are freely available and of high > > > quality so > > > everybody can understand the register values. There's nothing > > > magic to > > > them. That might change slightly when the Manuals are not > > > available, but > > > even then I think that not the device tree ABI is the right place > > > to > > > add that missing documentation. > > > > I agree 100% with Sascha. > > I would vote for not going generic pinconf either, as the controversy > here starts from something, that indicates the generic stuff doesn't > work for i.MX. So it seems with that we are at a point where the majority vote of users/maintainers are in favor of keeping the binding that has served us well on MX5/6. Which is right where we started with v1 of the MX8 patches. How do we proceed? I would like to send out a respin of those series next week. Can we all agree to roll back the pinctrl binding to the MX5/6 one? Or are there still major reservations against it? I would like to avoid introducing any unnecessary churn. Regards, Lucas -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Lucas, On Thu, Feb 8, 2018 at 1:28 PM, Lucas Stach <l.stach@pengutronix.de> wrote: > So it seems with that we are at a point where the majority vote of > users/maintainers are in favor of keeping the binding that has served > us well on MX5/6. Which is right where we started with v1 of the MX8 > patches. > > How do we proceed? I would like to send out a respin of those series > next week. Can we all agree to roll back the pinctrl binding to the > MX5/6 one? Or are there still major reservations against it? I would Yes, looks like a good plan IMHO. Thanks -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Feb 8, 2018 at 4:28 PM, Lucas Stach <l.stach@pengutronix.de> wrote: > So it seems with that we are at a point where the majority vote of > users/maintainers are in favor of keeping the binding that has served > us well on MX5/6. Which is right where we started with v1 of the MX8 > patches. > > How do we proceed? I would like to send out a respin of those series > next week. Can we all agree to roll back the pinctrl binding to the > MX5/6 one? Or are there still major reservations against it? I would > like to avoid introducing any unnecessary churn. What we need to see is for i.MX maintainers to agree, e.g. figure out how to do all stuff in drivers/pinctrl/freescale/* should be engineered going forward. (Maybe that filepath and symbols needs to be renamed drivers/pinctrl/imx by the way, this platform seems to change company more often than I change my car tyres.) I'll try to follow up on the resulting patch series. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx8mq-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,imx8mq-pinctrl.txt new file mode 100644 index 000000000000..5c5d2d835d05 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx8mq-pinctrl.txt @@ -0,0 +1,39 @@ +* Freescale IMX8MQ IOMUX Controller + +Please refer to fsl,imx-pinctrl.txt and pinctrl-bindings.txt in this directory +for common binding part and usage. + +=== Pin Controller Node === + +Required properties: +- compatible: "fsl,imx8mq-iomuxc" +- reg: Must contain the base physical address and size of the iomuxc registers. + +=== Pin Configuration Node === +Required properties: +- pinmux: Array of integersy, representing a group of pins mux setting. + The format is pinmux = <PIN_FUNC_ID>, PIN_FUNC_ID is a pin working on + a specific function. + + Refer to imx8mq-pinfunc.h in device tree source folder for all available + imx8mq PIN_FUNC_ID. + +Optional Properties: +- drive-strength Integer: controls Drive Strength + 0: driver disabled + 1: 255 Ohm + 2: 105 Ohm + 3: 75 Ohm + 4: 85 Ohm + 5: 65 Ohm + 6: 45 Ohm + 7: 40 Ohm +- slew-rate: Integer: controls Slew Rate + 0: Slow + 1: Medium + 2: Fast + 3: Maximum +- drive-open-drain Bool: enable Open-drian +- bias-pull-up Bool: enable Pull-up +- input-schmitt-enable Bool: enable schmitt-trigger +- input-enable Bool: enable input, overriding module settings
This adds the binding for the i.MX8MQ pin controller, in the same fashion as earlier i.MX SoCs. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> --- v2: switch to generic pinconf properties --- .../bindings/pinctrl/fsl,imx8mq-pinctrl.txt | 39 ++++++++++++++++++++++ 1 file changed, 39 insertions(+) create mode 100644 Documentation/devicetree/bindings/pinctrl/fsl,imx8mq-pinctrl.txt