| Message ID | 20171211050704.20621-1-joel@jms.id.au |
|---|---|
| Headers | show |
| Series | ARM: dts: aspeed: updates and new machines | expand |
On Mon, Dec 11, 2017 at 6:06 AM, Joel Stanley <joel@jms.id.au> wrote:
> +#define ASPEED_NUM_CLKS 35
Why is this part of the ABI? What if they ever come out with a new
chip that needs
one more clock and you can't change it?
Arnd
On Mon, Dec 11, 2017 at 6:06 AM, Joel Stanley <joel@jms.id.au> wrote: > These are used to by the device tree to map pin numbers to constants > required by the GPIO bindings. > + > +#define ASPEED_GPIO_PORT_A 0 > +#define ASPEED_GPIO_PORT_B 1 > +#define ASPEED_GPIO_PORT_C 2 > +#define ASPEED_GPIO_PORT_D 3 > +#define ASPEED_GPIO_PORT_E 4 > +#define ASPEED_GPIO_PORT_F 5 > +#define ASPEED_GPIO_PORT_G 6 > +#define ASPEED_GPIO_PORT_H 7 > +#define ASPEED_GPIO_PORT_I 8 > +#define ASPEED_GPIO_PORT_J 9 > +#define ASPEED_GPIO_PORT_K 10 > +#define ASPEED_GPIO_PORT_L 11 > +#define ASPEED_GPIO_PORT_M 12 > +#define ASPEED_GPIO_PORT_N 13 > +#define ASPEED_GPIO_PORT_O 14 > +#define ASPEED_GPIO_PORT_P 15 > +#define ASPEED_GPIO_PORT_Q 16 > +#define ASPEED_GPIO_PORT_R 17 > +#define ASPEED_GPIO_PORT_S 18 > +#define ASPEED_GPIO_PORT_T 19 > +#define ASPEED_GPIO_PORT_U 20 > +#define ASPEED_GPIO_PORT_V 21 > +#define ASPEED_GPIO_PORT_W 22 > +#define ASPEED_GPIO_PORT_X 23 > +#define ASPEED_GPIO_PORT_Y 24 > +#define ASPEED_GPIO_PORT_Z 25 > +#define ASPEED_GPIO_PORT_AA 26 > +#define ASPEED_GPIO_PORT_AB 27 > +#define ASPEED_GPIO_PORT_AC 28 This looks like a 1:1 mapping, wouldn't it be easier to just describe it in the binding document? Arnd
On Mon, Dec 11, 2017 at 6:06 AM, Joel Stanley <joel@jms.id.au> wrote: > This should have always been 8. > > Signed-off-by: Joel Stanley <joel@jms.id.au> As this is a bugfix, should we backport it to stable kernels? When you fix a bug, I generally recommend including a 'Fixes' tag with the commit ID of the patch that introduced the problem, and either a 'Cc: stable@vger.kernel.org' tag if you want it backported, or an explanation in the changelog why it should not get backported. This really helps Greg and the other stable maintainers trying to make a decision what to backport and what not. Arnd
On Mon, Dec 11, 2017 at 6:06 AM, Joel Stanley <joel@jms.id.au> wrote: > The existing device trees use fixed-clocks in order to boot without a > clk driver. The newly added clk driver provides proper clock support, > including gating, so we move the device trees over to properly request > clocks. > > Signed-off-by: Joel Stanley <joel@jms.id.au> Can you clarify here whether this will break running old kernels with new DT files or vice versa, and why this is ok here? I assume you have thought about it carefully, but I'd still like to document every time we intentionally break compatibility like this. It looks like you too care to merge the driver changes and the DT binding change first, so we don't get any bisection problems. What I'm not completely clear about is the difference between the "aspeed,g4-scu" binding and the "aspeed,ast2400-scu" binding. They are listed as equal in Documentation/devicetree/bindings/mfd/aspeed-scu.txt, so why do you change it here? Arnd
On Mon, Dec 11, 2017 at 6:26 PM, Arnd Bergmann <arnd@arndb.de> wrote: > On Mon, Dec 11, 2017 at 6:06 AM, Joel Stanley <joel@jms.id.au> wrote: >> These are used to by the device tree to map pin numbers to constants >> required by the GPIO bindings. >> + >> +#define ASPEED_GPIO_PORT_A 0 >> +#define ASPEED_GPIO_PORT_B 1 >> +#define ASPEED_GPIO_PORT_C 2 >> +#define ASPEED_GPIO_PORT_D 3 >> +#define ASPEED_GPIO_PORT_E 4 >> +#define ASPEED_GPIO_PORT_F 5 >> +#define ASPEED_GPIO_PORT_G 6 >> +#define ASPEED_GPIO_PORT_H 7 >> +#define ASPEED_GPIO_PORT_I 8 >> +#define ASPEED_GPIO_PORT_J 9 >> +#define ASPEED_GPIO_PORT_K 10 >> +#define ASPEED_GPIO_PORT_L 11 >> +#define ASPEED_GPIO_PORT_M 12 >> +#define ASPEED_GPIO_PORT_N 13 >> +#define ASPEED_GPIO_PORT_O 14 >> +#define ASPEED_GPIO_PORT_P 15 >> +#define ASPEED_GPIO_PORT_Q 16 >> +#define ASPEED_GPIO_PORT_R 17 >> +#define ASPEED_GPIO_PORT_S 18 >> +#define ASPEED_GPIO_PORT_T 19 >> +#define ASPEED_GPIO_PORT_U 20 >> +#define ASPEED_GPIO_PORT_V 21 >> +#define ASPEED_GPIO_PORT_W 22 >> +#define ASPEED_GPIO_PORT_X 23 >> +#define ASPEED_GPIO_PORT_Y 24 >> +#define ASPEED_GPIO_PORT_Z 25 >> +#define ASPEED_GPIO_PORT_AA 26 >> +#define ASPEED_GPIO_PORT_AB 27 >> +#define ASPEED_GPIO_PORT_AC 28 > > This looks like a 1:1 mapping, wouldn't it be easier to just describe > it in the binding document? You're right, it is a linear mapping. We use it so references to GPIO numbers are human readable in the device tree: #define ASPEED_GPIO(port, offset) \ ((ASPEED_GPIO_PORT_##port * 8) + offset) can be used: identify { gpios = <&gpio ASPEED_GPIO(A, 2) GPIO_ACTIVE_LOW>; }; We find that has cut down on mistakes in calculating offsets into GPIO banks. Cheers, Joel
On Mon, Dec 11, 2017 at 6:28 PM, Arnd Bergmann <arnd@arndb.de> wrote: > On Mon, Dec 11, 2017 at 6:06 AM, Joel Stanley <joel@jms.id.au> wrote: >> This should have always been 8. >> >> Signed-off-by: Joel Stanley <joel@jms.id.au> > > As this is a bugfix, should we backport it to stable kernels? When you > fix a bug, > I generally recommend including a 'Fixes' tag with the commit ID of the patch > that introduced the problem, and either a 'Cc: stable@vger.kernel.org' tag > if you want it backported, or an explanation in the changelog why it should > not get backported. This really helps Greg and the other stable maintainers > trying to make a decision what to backport and what not. We could do this, and I generally follow the practice of adding Fixes tags. I hadn't because without an upstream clock driver, the Aspeed port is not usable by anyone without making modifications. We're really depending on getting that code merged. I will send it as a fix to 4.15. Do you mind taking individual patches for the arm dt tree, or would you prefer a pull request? Cheers, Joel
On Mon, Dec 11, 2017 at 6:39 PM, Arnd Bergmann <arnd@arndb.de> wrote: > On Mon, Dec 11, 2017 at 6:06 AM, Joel Stanley <joel@jms.id.au> wrote: >> The existing device trees use fixed-clocks in order to boot without a >> clk driver. The newly added clk driver provides proper clock support, >> including gating, so we move the device trees over to properly request >> clocks. >> >> Signed-off-by: Joel Stanley <joel@jms.id.au> > > Can you clarify here whether this will break running old kernels with > new DT files or vice versa, and why this is ok here? This device tree will break kernels that do not have the clk patches applied (no clocksource, as we don't know the speed of the APB clock. You can boot if you pass a lpj value on the command line, but won't have a uart). Older device trees running with the newer kernel will function as well as pre-4.16 kernels. That is, that some IP blocks (i2c, pwm/tach, adc) will not work as the kernel lacks reset controller and clock enabling. > I assume you have thought about it carefully, but I'd still like to document > every time we intentionally break compatibility like this. It looks like > you too care to merge the driver changes and the DT binding change first, > so we don't get any bisection problems. Thanks for calling it out. I will modify the commit message to say that this device tree change depends on the newer driver, and it will not boot with kernels that lack the driver. > > What I'm not completely clear about is the difference between the > "aspeed,g4-scu" binding and the "aspeed,ast2400-scu" binding. > They are listed as equal in > Documentation/devicetree/bindings/mfd/aspeed-scu.txt, so why do you > change it here? The g4-scu string made it into the tree before we had decided that we would settle on aspeed,astX000-<ip> as the format for the strings. We list both in the docs, but I would like to deprecate the old one. If I was doing this again, I would make sure we had the clock driver upstream before completing the other driver. It's caused a lot of pain. Thanks for your help getting us there. Cheers, Joel
On Mon, Dec 11, 2017 at 11:44 AM, Joel Stanley <joel@jms.id.au> wrote: > On Mon, Dec 11, 2017 at 6:28 PM, Arnd Bergmann <arnd@arndb.de> wrote: >> On Mon, Dec 11, 2017 at 6:06 AM, Joel Stanley <joel@jms.id.au> wrote: >>> This should have always been 8. >>> >>> Signed-off-by: Joel Stanley <joel@jms.id.au> >> >> As this is a bugfix, should we backport it to stable kernels? When you >> fix a bug, >> I generally recommend including a 'Fixes' tag with the commit ID of the patch >> that introduced the problem, and either a 'Cc: stable@vger.kernel.org' tag >> if you want it backported, or an explanation in the changelog why it should >> not get backported. This really helps Greg and the other stable maintainers >> trying to make a decision what to backport and what not. > > We could do this, and I generally follow the practice of adding Fixes > tags. I hadn't because without an upstream clock driver, the Aspeed > port is not usable by anyone without making modifications. We're > really depending on getting that code merged. > > I will send it as a fix to 4.15. Do you mind taking individual patches > for the arm dt tree, or would you prefer a pull request? For bugfixes, we don't distinguish between DT and other fixes. If it's a single patch, a pull request works just as well as a emailed patch, your choice. Arnd