Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Compatibility #17

Closed
wants to merge 54 commits into from
Closed

Conversation

lorforlinux
Copy link
Contributor

@RobertCNelson @jadonk, please review my code:)

Copy link
Member

@jadonk jadonk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a nice pattern. I really look forward to seeing it for the other buses.

If you could keep the pinmux helper separate from the other stuff, that might be good in case it doesn't work.

Please fix your tabs.

@@ -265,1700 +267,9 @@
compatible = "ti,pruss-shmem";
reg = <0x4b280000 0x020000>;
};

cape-universal {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought you were going in the direction of adding config-pin to AM5729, though I wouldn't want to depend on it working.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Er, just realized these were just the GPIOs. Why remove them?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn't remove them just shifted them to another file src/arm/am572x-bone-common-univ.dtsi

};

bone_uart_1: &uart1 {
status = "disabled";
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Your indents look to not be set properly. Use tabs with a stop of 8.


bone_uart_3_pins: pinmux_bone_uart_3_pins {
pinctrl-single,pins = <
P9_42A (PIN_OUTPUT_PULLUP | MUX_MODE1)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tabs are off.

};

&dra7_pmx_core {
/************************/
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was a nice summary of information. Is the new organization harder to follow and more scattered? Can't the bone-bus.dtsi files simply reference these?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I was thinking of using phandles from here like pinmux_P8_03_default_pin then we will not require 2 separate files for bone-buses one would suffice and there will be no need for the helper header files for simple pin muxing.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no possibility to achieve this at this moment ^

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are these called phandles? Doesn't sound right to me.

I think the challenge in reusing these definitions is that not all header pins have only one ball/signal connected and that having 1 or 2 signals varies between AM335x (Black) and AM57x (AI) boards.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are these called phandles? Doesn't sound right to me.

I think they are phandles, please correct me if you think i am wrong there.

I think the challenge in reusing these definitions is that not all header pins have only one ball/signal connected and that having 1 or 2 signals varies between AM335x (Black) and AM57x (AI) boards.

No that is not the case, the problem here is that peripheral name is different like uart1 on BBB and uart10 BBAI, the two-pin problem can be solved by using bone-pinmux-helper.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are we closer now to using common symbols/phandles?


/* P8_03 (ball AB8) gpio1_24 */
P8_03_default_pin: pinmux_P8_03_default_pin { pinctrl-single,pins = <
DRA7XX_CORE_IOPAD(0x379C, PIN_OUTPUT_PULLDOWN | INPUT_EN | MUX_MODE14) >; }; /* mmc3_dat6.gpio1_24 */
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't this use the new macro?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you are happy with them I will implement them everywhere they can fit :)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The new macro seems handy. I just don't want to define the address entry in multiple locations. One place to be right or wrong and get fixed.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, I will gradually shift things to use those macros.

};

bone_uart_4_pins: pinmux_bone_uart_4_pins {
pinctrl-single,pins = <
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Watch your tabs!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am really very sorry, It looks fine on vscode here :(

src/arm/bbai-bone-buses.dtsi Outdated Show resolved Hide resolved
P9_13( PIN_OUTPUT_PULLUP | MUX_MODE4) /* mcasp3_axr1.uart5_txd */
P9_11A( PIN_INPUT_PULLUP | MUX_MODE4) /* mcasp3_axr0.uart5_rxd */
/* unused pins */
P9_11B( PIN_OUTPUT | MUX_MODE15)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Missing processor pin comment.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I skipped because IT was not in use. I will make sure everything is commented during code cleanup. I hope that's acceptable?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comment should say something like "pin_xyz.Off" if it is off.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure thing


bone_uart_5_pins: pinmux_bone_uart_5_pins {
pinctrl-single,pins = <
P8_37B( PIN_OUTPUT_PULLUP | MUX_MODE3) /* uart8_txd */
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comment is missing the processor pin.

&am33xx_pinmux {
bone_uart_1_pins: pinmux_bone_uart_1_pins {
pinctrl-single,pins = <
P9_24( PIN_OUTPUT_PULLUP | MUX_MODE0)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Having the consistent comments would be nice. pin.mode

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed 👍

@jadonk
Copy link
Member

jadonk commented Jun 25, 2020

Can you rebase and provide fixes?

@lorforlinux
Copy link
Contributor Author

@jadonk This is my first time rebasing.

@lorforlinux lorforlinux force-pushed the compatibility branch 3 times, most recently from 7ebb04c to ec69013 Compare June 25, 2020 16:30
@lorforlinux
Copy link
Contributor Author

lorforlinux commented Jun 25, 2020

I accidentally rebased with the master branch but I had to rebase with v4.19.x-ti, I have reset the head to the last correct position and now it's saying that it's already up to date when I try to rebase with v4.19.x-ti. What should I do?

Edit: After rebasing with the master I also rebased with v4.19.x-ti, I am setting head to that position so that you can guide me better.

@lorforlinux
Copy link
Contributor Author

hey, It looks okay now!

@lorforlinux
Copy link
Contributor Author

@jadonk Hey, can you merge the changes please?

@lorforlinux lorforlinux requested a review from jadonk June 26, 2020 23:01
@lorforlinux
Copy link
Contributor Author

I have added /bone/i2c code, everything has been tested on BBB and BBAI :)

The default properties are already set in the base files and we don't require these values here.
These nodes provides a way to make DT overlays compatible on both BBB and BBAI. For example, LCD cape and Motor cape uses these PWM and by uisng these nodes we can write one overlay to work on both BBB and BBAI.
The default properties are already set in the base files like dra7.dtsi and we don't require these values here.
These nodes provides a way to make DT overlays compatible on both BBB and BBAI. For example, LCD cape and Motor cape uses these PWM and by uisng these nodes we can write one overlay to work on both BBB and BBAI.

bone_pwmss_2: &epwmss2 {

};
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jadonk @RobertCNelson I am not able to use symlinks with these nodes what could be the reason for that?
These nodes are used in beagleboard/bb.org-overlays#188 and I will also use them for 4D systems LCD cape DT overlay.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there even a udev rule for bone-style symlinks on pwms?

https://elinux.org/Beagleboard:BeagleBone_cape_interface_spec section on methodology need to be brought up-to-date on what is in https://github.com/beagleboard/customizations/ and planned to be in there.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmmm.... I guess even just https://github.com/beagleboard/customizations/blob/master/etc/udev/rules.d/10-of-symlink.rules should cover it. What is our method for debugging udev rules? Does the rule ever run on these? Why doesn't the pull-request include the symlink definitions?

@@ -370,59 +370,41 @@

// UARTs
bone_uart_1: &uart1 {
status = "disabled";
pinctrl-names = "default";
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I removed these because they serve no purpose as the settings are already done in the base files.

Copy link
Member

@jadonk jadonk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Without a justification, I prefer the old way over macros.

/* P8_02 GND */

/* P8_03 (ball AB8) gpio1_24 */
#define P8_03_DEFAULT P8_03( PIN_OUTPUT_PULLDOWN | INPUT_EN | MUX_MODE14) /* mmc3_dat6.gpio1_24 */
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are tabs still off in your editor? Things don't seem to line up for me.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are these defines somehow better than the definitions that could be referenced as symbols before? Is the point to save space in the .dtb? Please include your reasoning for the changes.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you are seeing an outdated version of the file.

P8_03_default_pin: pinmux_P8_03_default_pin { pinctrl-single,pins = < P8_03_DEFAULT >; };
P8_03_gpio_pin: pinmux_P8_03_gpio_pin { pinctrl-single,pins = < P8_03_GPIO >; };
P8_03_gpio_pu_pin: pinmux_P8_03_gpio_pu_pin { pinctrl-single,pins = < P8_03_GPIO_PU >; };
P8_03_gpio_pd_pin: pinmux_P8_03_gpio_pd_pin { pinctrl-single,pins = < P8_03_GPIO_PD >; };
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree to bring back the comment at the end of the line. I don't see the point of using macros here. It seems redundant and error-prone. I'd prefer things be in one place to fix. Besides, this means they can be referenced by overlays. If it is in macros, overlays wouldn't be able to use the symbols. This saves in the .dtb size, but I don't think that is a care-about.

Copy link
Member

@jadonk jadonk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

More change requests interspersed.

@@ -0,0 +1,82 @@
/*
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As long as this is accurate, it seems reasonable to me to have 1 place that associates balls with cape header pins. I'll just be looking to make sure this association isn't needed in other places.

#ifndef _DT_BINDINGS_BOARD_AM5729_BBAI_PINS_H
#define _DT_BINDINGS_BOARD_AM5729_BBAI_PINS_H

#define P8_03(mode) DRA7XX_CORE_IOPAD(0x379C, mode) /* AB8: P8.3: mmc3_dat6 */
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like having the ball number in the comment. The cape header pin definition in the comment is redundant.

#ifndef _DT_BINDINGS_BOARD_AM335X_BBB_PINS_H
#define _DT_BINDINGS_BOARD_AM335X_BBB_PINS_H

#define P8_03(mode) AM33XX_IOPAD(0x0818, mode) /* gpmc_ad6 */
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please add the ball number to the comment. That is super useful.

pinctrl-names = "default";
pinctrl-0 = <&cape_pins_default>;
};
// cape_pins: cape_pins {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I understand doing this on work-in-progress, but please remove it for the pull request.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

okay, I will remove the code.

};

&dra7_pmx_core {
/************************/
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are we closer now to using common symbols/phandles?


led_P8_03 {
gpios = <&gpio1 6 0>;
status = "disabled";
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is the status "reserved" for bbai?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ohh this, I wanted to ask this to you. both "reserved" and "disabled" worked for me which should we choose?

From Deice tree specifications I found this:

"disabled" 
Indicates that the device is not presently operational, but it might become operational in the future
(for example, something is not plugged in, or switched off).
Refer to the device binding for details on what disabled means for a given device.

"reserved"
Indicates that the device is operational, but should not be used. Typically this is used for devices that
are controlled by another software component, such as platform firmware.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the choice of "disabled".


// use only when bone_i2c_2 is not in use
bone_i2c_2a: &i2c2 {
// symlink = "bone/i2c/2a";
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is the symlink commented out?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the previous code was interfering with this, I updated it with the new code yesterday and things are not looking quite right for now. I am in the process of updating this code and DT overlays with it.

#address-cells = <1>;
#size-cells = <0>;

ti,pio-mode; /* disable dma when used as an overlay, dma gets stuck at 160 bits... */
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I find it rather doubtful that this issue exists on both devices. Where did you copy and paste this from? Does it belong here or, more likely, in the device base-tree definition? If it specific to overlays, as is indicated, more information really is needed here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am sorry, this was just meant for testing purpose. I will fix this.
The code will be shifted to overlays just like we had for old overlays.


bone_pwmss_2: &epwmss2 {

};
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there even a udev rule for bone-style symlinks on pwms?

https://elinux.org/Beagleboard:BeagleBone_cape_interface_spec section on methodology need to be brought up-to-date on what is in https://github.com/beagleboard/customizations/ and planned to be in there.


bone_pwmss_2: &epwmss2 {

};
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmmm.... I guess even just https://github.com/beagleboard/customizations/blob/master/etc/udev/rules.d/10-of-symlink.rules should cover it. What is our method for debugging udev rules? Does the rule ever run on these? Why doesn't the pull-request include the symlink definitions?

I have removed the redundant code and changed the file name as discussed on irc.
I have added ball names and changed the name of file as discussed on IRC.
Created dummy nodes for unavailable bone buses to avoid FDT error!
These nodes are just to avoid FDT error while using src/arm/BONE-PWM0-00A0.dts
@lorforlinux
Copy link
Contributor Author

@jadonk @RobertCNelson I am closing this PR as this is no longer required ;)
This code has been merged through another PR -> #18

Copy link
Member

@jadonk jadonk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me. Looks like it is already merged too. :-D


led_P8_03 {
gpios = <&gpio1 6 0>;
status = "disabled";
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the choice of "disabled".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants