<html><head></head><body><div class="ydp718ead1eyahoo-style-wrap" style="font-family:Helvetica Neue, Helvetica, Arial, sans-serif;font-size:16px;"><div></div>
<div dir="ltr" data-setdir="false">Hi Tao,</div><div dir="ltr" data-setdir="false">Where can we find the current source or patches for AST2xxx <span><span style="color: rgb(0, 0, 0); font-family: Helvetica Neue, Helvetica, Arial, sans-serif; font-size: 16px;">JTAG master drivers on Linux 6.x?</span></span></div><div dir="ltr" data-setdir="false">Thanks</div><div dir="ltr" data-setdir="false"><br></div><div><br></div><div dir="ltr" data-setdir="false"><div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;">Message: 1<br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;">Date: Wed, 22 Feb 2023 23:33:29 -0800<br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;">From: Tao Ren <<a href="mailto:rentao.bupt@gmail.com" style="color: rgb(25, 106, 212); text-decoration-line: underline;" rel="nofollow" target="_blank">rentao.bupt@gmail.com</a>><br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;">To: Joel Stanley <<a href="mailto:joel@jms.id.au" style="color: rgb(25, 106, 212); text-decoration-line: underline;" rel="nofollow" target="_blank">joel@jms.id.au</a>><br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;">Cc: OpenBMC Maillist <<a href="mailto:openbmc@lists.ozlabs.org" style="color: rgb(25, 106, 212); text-decoration-line: underline;" rel="nofollow" target="_blank">openbmc@lists.ozlabs.org</a>><br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;">Subject: Re: OpenBMC Linux 6.1<br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;">Message-ID: <Y/<a href="mailto:cWyUVGkYA2UvBp@fedora" style="color: rgb(25, 106, 212); text-decoration-line: underline;" rel="nofollow" target="_blank">cWyUVGkYA2UvBp@fedora</a>><br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;">Content-Type: text/plain; charset=us-ascii<br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;"><br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;">On Wed, Feb 22, 2023 at 06:25:13AM +0000, Joel Stanley wrote:<br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;">> On Wed, 22 Feb 2023 at 06:11, Tao Ren <<a href="mailto:rentao.bupt@gmail.com" style="color: rgb(25, 106, 212); text-decoration-line: underline;" rel="nofollow" target="_blank">rentao.bupt@gmail.com</a>> wrote:<br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;">> ><br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;">> > Hi Joel,<br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;">> ><br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;">> > Thanks for the update. Let me move some Meta/Facebook AST2500 and<br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;">> > AST2600 Network OpenBMCs to v6.1, and will share my findings later.<br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;">><br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;">> Thanks Tao, I appreciate it.<br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;"><br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;">Just heads up I sanity tested dev-6.1 branch on 3 aspeed generations,<br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;">and everything looks normal. The 3 openbmc platforms are:<br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;"> - wedge100 (AST2400)<br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;"> - cmm (AST2500)<br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;"> - fbdarwin (AST2600, dts to be upstreamed)<br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;"><br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;">><br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;">> > Besides, could you please share your long term kernel upgrade plan? For<br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;">> > example, are you planning to align with LTS kernel in the future? Or the<br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;">> > ultimate goal is to upgrade openbmc kernel whenever newer kernel is<br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;">> > released?<br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;">><br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;">> Somewhere in between those two.<br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;">><br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;">> If we were to wait 5 or so years between updates, then we remove the<br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;">> motivation for developers to upstream their code, and I imagine it<br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;">> would be a headache to hunt down regressions when making that big<br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;">> jump.<br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;">><br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;">> On the other hand, management has been trained to target the stable<br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;">> releases and somehow consider them to be better than others. I argue<br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;">> this isn't true, because the code is only as stable as the test and<br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;">> development resources that are put into it! That said, it's less work<br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;">> to merge in the stable tree every week or two and test that than it is<br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;">> to do a new rebase every three months.<br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;">><br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;">> The ultimate goal is to have all of our code upstream, and just use<br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;">> whatever kernel yocto has. We're pretty close for aspeed machines; at<br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;">> IBM we have some downstream hacks for misbehaving i2c devices, and<br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;">> some device trees for pre-production hardware that have minor<br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;">> differences to the production version. If we were to upstream the<br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;">> hacks for i2c devices (or stop using them) then we could ship upstream<br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;">> kernels.<br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;">><br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;">> Ultimately it would be best for the project if we used the latest<br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;">> kernel on master, and had a LTS kernel that was used by product<br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;">> branches. This would require the project to fund someone to do this<br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;">> work long term, to ensure the stable updates haven't caused<br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;">> regressions, to cherry pick patches that fix code that was not present<br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;">> in the upstream release, and in their remaining time help get more<br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;">> code in mainline.<br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;">><br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;">> Cheers,<br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;">><br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;">> Joel<br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;"><br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;">Thanks for sharing the details, and in short, I'm moving torward the<br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;">similar direction:)<br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;"><br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;">My current plan is to upgrade openbmc kernel at least once a year<br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;">(skipping ~4 kernel releases) for facebook network openbmc platforms,<br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;">and I'm facing the similar challenges: upstreaming kernel patches and<br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;">test enhancement. I don't have plan to force more frequent kernel<br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;">upgrade in 2023, because if I had bandwidth, I'd rather spend the time<br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;">upstreaming patches: I believe kernel upgrade would be much easier if<br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;">all the patches are upstreamed.<br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;"><br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;">I quickly went through the local kernel patches in my repo, and they<br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;">fall in 3 major categories: 1) JTAG master drivers 2) hwmon drivers 3)<br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;">enabling dsa in a few dts files. I'm not sure if anyone is actively<br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;">looking into the jtag patch series, but I will try my best to clean up<br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;">some patches in #2 and #3 this year.<br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;"><br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;">BTW, I will create the recipe to fetch dev-6.1 into meta/facebook<br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;">openbmc tree soon. Thanks again for maintaining the tree.<br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;"><br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;"><br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;">Cheers,<br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;"><br></div><div dir="ltr" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;">Tao</div></div><br></div>
</div><div id="yahoo_quoted_8144965515" class="yahoo_quoted">
<div style="font-family:'Helvetica Neue', Helvetica, Arial, sans-serif;font-size:13px;color:#26282a;">
<div>
On Friday, February 24, 2023 at 03:08:44 AM GMT+3, openbmc-request@lists.ozlabs.org <openbmc-request@lists.ozlabs.org> wrote:
</div>
<div><br></div>
<div><br></div>
<div><div dir="ltr">Send openbmc mailing list submissions to<br></div><div dir="ltr"> <a ymailto="mailto:openbmc@lists.ozlabs.org" href="mailto:openbmc@lists.ozlabs.org">openbmc@lists.ozlabs.org</a><br></div><div dir="ltr"><br></div><div dir="ltr">To subscribe or unsubscribe via the World Wide Web, visit<br></div><div dir="ltr"> <a href="https://lists.ozlabs.org/listinfo/openbmc" target="_blank">https://lists.ozlabs.org/listinfo/openbmc</a><br></div><div dir="ltr">or, via email, send a message with subject or body 'help' to<br></div><div dir="ltr"> <a ymailto="mailto:openbmc-request@lists.ozlabs.org" href="mailto:openbmc-request@lists.ozlabs.org">openbmc-request@lists.ozlabs.org</a><br></div><div dir="ltr"><br></div><div dir="ltr">You can reach the person managing the list at<br></div><div dir="ltr"> <a ymailto="mailto:openbmc-owner@lists.ozlabs.org" href="mailto:openbmc-owner@lists.ozlabs.org">openbmc-owner@lists.ozlabs.org</a><br></div><div dir="ltr"><br></div><div dir="ltr">When replying, please edit your Subject line so it is more specific<br></div><div dir="ltr">than "Re: Contents of openbmc digest..."<br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr">Today's Topics:<br></div><div dir="ltr"><br></div><div dir="ltr"> 1. Re: OpenBMC Linux 6.1 (Tao Ren)<br></div><div dir="ltr"> 2. RE: [PATCH v5 1/2] dt-bindings: i2c: Add support for ASPEED<br></div><div dir="ltr"> i2Cv2 (Ryan Chen)<br></div><div dir="ltr"> 3. [PATCH v2 0/3] ARM: dts: aspeed: ASRock BMC updates (Zev Weiss)<br></div><div dir="ltr"> 4. [PATCH v2 3/3] ARM: dts: aspeed: asrock: Correct firmware<br></div><div dir="ltr"> flash SPI clocks (Zev Weiss)<br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr">----------------------------------------------------------------------<br></div><div dir="ltr"><br></div><div dir="ltr">Message: 1<br></div><div dir="ltr">Date: Wed, 22 Feb 2023 23:33:29 -0800<br></div><div dir="ltr">From: Tao Ren <<a ymailto="mailto:rentao.bupt@gmail.com" href="mailto:rentao.bupt@gmail.com">rentao.bupt@gmail.com</a>><br></div><div dir="ltr">To: Joel Stanley <<a ymailto="mailto:joel@jms.id.au" href="mailto:joel@jms.id.au">joel@jms.id.au</a>><br></div><div dir="ltr">Cc: OpenBMC Maillist <<a ymailto="mailto:openbmc@lists.ozlabs.org" href="mailto:openbmc@lists.ozlabs.org">openbmc@lists.ozlabs.org</a>><br></div><div dir="ltr">Subject: Re: OpenBMC Linux 6.1<br></div><div dir="ltr">Message-ID: <Y/<a ymailto="mailto:cWyUVGkYA2UvBp@fedora" href="mailto:cWyUVGkYA2UvBp@fedora">cWyUVGkYA2UvBp@fedora</a>><br></div><div dir="ltr">Content-Type: text/plain; charset=us-ascii<br></div><div dir="ltr"><br></div><div dir="ltr">On Wed, Feb 22, 2023 at 06:25:13AM +0000, Joel Stanley wrote:<br></div><div dir="ltr">> On Wed, 22 Feb 2023 at 06:11, Tao Ren <<a ymailto="mailto:rentao.bupt@gmail.com" href="mailto:rentao.bupt@gmail.com">rentao.bupt@gmail.com</a>> wrote:<br></div><div dir="ltr">> ><br></div><div dir="ltr">> > Hi Joel,<br></div><div dir="ltr">> ><br></div><div dir="ltr">> > Thanks for the update. Let me move some Meta/Facebook AST2500 and<br></div><div dir="ltr">> > AST2600 Network OpenBMCs to v6.1, and will share my findings later.<br></div><div dir="ltr">> <br></div><div dir="ltr">> Thanks Tao, I appreciate it.<br></div><div dir="ltr"><br></div><div dir="ltr">Just heads up I sanity tested dev-6.1 branch on 3 aspeed generations,<br></div><div dir="ltr">and everything looks normal. The 3 openbmc platforms are:<br></div><div dir="ltr"> - wedge100 (AST2400)<br></div><div dir="ltr"> - cmm (AST2500)<br></div><div dir="ltr"> - fbdarwin (AST2600, dts to be upstreamed)<br></div><div dir="ltr"><br></div><div dir="ltr">> <br></div><div dir="ltr">> > Besides, could you please share your long term kernel upgrade plan? For<br></div><div dir="ltr">> > example, are you planning to align with LTS kernel in the future? Or the<br></div><div dir="ltr">> > ultimate goal is to upgrade openbmc kernel whenever newer kernel is<br></div><div dir="ltr">> > released?<br></div><div dir="ltr">> <br></div><div dir="ltr">> Somewhere in between those two.<br></div><div dir="ltr">> <br></div><div dir="ltr">> If we were to wait 5 or so years between updates, then we remove the<br></div><div dir="ltr">> motivation for developers to upstream their code, and I imagine it<br></div><div dir="ltr">> would be a headache to hunt down regressions when making that big<br></div><div dir="ltr">> jump.<br></div><div dir="ltr">> <br></div><div dir="ltr">> On the other hand, management has been trained to target the stable<br></div><div dir="ltr">> releases and somehow consider them to be better than others. I argue<br></div><div dir="ltr">> this isn't true, because the code is only as stable as the test and<br></div><div dir="ltr">> development resources that are put into it! That said, it's less work<br></div><div dir="ltr">> to merge in the stable tree every week or two and test that than it is<br></div><div dir="ltr">> to do a new rebase every three months.<br></div><div dir="ltr">> <br></div><div dir="ltr">> The ultimate goal is to have all of our code upstream, and just use<br></div><div dir="ltr">> whatever kernel yocto has. We're pretty close for aspeed machines; at<br></div><div dir="ltr">> IBM we have some downstream hacks for misbehaving i2c devices, and<br></div><div dir="ltr">> some device trees for pre-production hardware that have minor<br></div><div dir="ltr">> differences to the production version. If we were to upstream the<br></div><div dir="ltr">> hacks for i2c devices (or stop using them) then we could ship upstream<br></div><div dir="ltr">> kernels.<br></div><div dir="ltr">> <br></div><div dir="ltr">> Ultimately it would be best for the project if we used the latest<br></div><div dir="ltr">> kernel on master, and had a LTS kernel that was used by product<br></div><div dir="ltr">> branches. This would require the project to fund someone to do this<br></div><div dir="ltr">> work long term, to ensure the stable updates haven't caused<br></div><div dir="ltr">> regressions, to cherry pick patches that fix code that was not present<br></div><div dir="ltr">> in the upstream release, and in their remaining time help get more<br></div><div dir="ltr">> code in mainline.<br></div><div dir="ltr">> <br></div><div dir="ltr">> Cheers,<br></div><div dir="ltr">> <br></div><div dir="ltr">> Joel<br></div><div dir="ltr"><br></div><div dir="ltr">Thanks for sharing the details, and in short, I'm moving torward the<br></div><div dir="ltr">similar direction:)<br></div><div dir="ltr"><br></div><div dir="ltr">My current plan is to upgrade openbmc kernel at least once a year<br></div><div dir="ltr">(skipping ~4 kernel releases) for facebook network openbmc platforms,<br></div><div dir="ltr">and I'm facing the similar challenges: upstreaming kernel patches and<br></div><div dir="ltr">test enhancement. I don't have plan to force more frequent kernel<br></div><div dir="ltr">upgrade in 2023, because if I had bandwidth, I'd rather spend the time<br></div><div dir="ltr">upstreaming patches: I believe kernel upgrade would be much easier if<br></div><div dir="ltr">all the patches are upstreamed.<br></div><div dir="ltr"><br></div><div dir="ltr">I quickly went through the local kernel patches in my repo, and they<br></div><div dir="ltr">fall in 3 major categories: 1) JTAG master drivers 2) hwmon drivers 3)<br></div><div dir="ltr">enabling dsa in a few dts files. I'm not sure if anyone is actively<br></div><div dir="ltr">looking into the jtag patch series, but I will try my best to clean up<br></div><div dir="ltr">some patches in #2 and #3 this year.<br></div><div dir="ltr"><br></div><div dir="ltr">BTW, I will create the recipe to fetch dev-6.1 into meta/facebook<br></div><div dir="ltr">openbmc tree soon. Thanks again for maintaining the tree.<br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr">Cheers,<br></div><div dir="ltr"><br></div><div dir="ltr">Tao<br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr">------------------------------<br></div><div dir="ltr"><br></div><div dir="ltr">Message: 2<br></div><div dir="ltr">Date: Thu, 23 Feb 2023 10:25:56 +0000<br></div><div dir="ltr">From: Ryan Chen <<a ymailto="mailto:ryan_chen@aspeedtech.com" href="mailto:ryan_chen@aspeedtech.com">ryan_chen@aspeedtech.com</a>><br></div><div dir="ltr">To: Krzysztof Kozlowski <<a ymailto="mailto:krzysztof.kozlowski@linaro.org" href="mailto:krzysztof.kozlowski@linaro.org">krzysztof.kozlowski@linaro.org</a>>, Rob Herring<br></div><div dir="ltr"> <robh+<a ymailto="mailto:dt@kernel.org" href="mailto:dt@kernel.org">dt@kernel.org</a>>, Krzysztof Kozlowski<br></div><div dir="ltr"> <krzysztof.kozlowski+<a ymailto="mailto:dt@linaro.org" href="mailto:dt@linaro.org">dt@linaro.org</a>>, Joel Stanley <<a ymailto="mailto:joel@jms.id.au" href="mailto:joel@jms.id.au">joel@jms.id.au</a>>,<br></div><div dir="ltr"> Andrew Jeffery <<a ymailto="mailto:andrew@aj.id.au" href="mailto:andrew@aj.id.au">andrew@aj.id.au</a>>, Philipp Zabel<br></div><div dir="ltr"> <<a ymailto="mailto:p.zabel@pengutronix.de" href="mailto:p.zabel@pengutronix.de">p.zabel@pengutronix.de</a>>, "<a ymailto="mailto:openbmc@lists.ozlabs.org" href="mailto:openbmc@lists.ozlabs.org">openbmc@lists.ozlabs.org</a>"<br></div><div dir="ltr"> <<a ymailto="mailto:openbmc@lists.ozlabs.org" href="mailto:openbmc@lists.ozlabs.org">openbmc@lists.ozlabs.org</a>>, "<a ymailto="mailto:linux-arm-kernel@lists.infradead.org" href="mailto:linux-arm-kernel@lists.infradead.org">linux-arm-kernel@lists.infradead.org</a>"<br></div><div dir="ltr"> <<a ymailto="mailto:linux-arm-kernel@lists.infradead.org" href="mailto:linux-arm-kernel@lists.infradead.org">linux-arm-kernel@lists.infradead.org</a>>,<br></div><div dir="ltr"> "<a ymailto="mailto:linux-aspeed@lists.ozlabs.org" href="mailto:linux-aspeed@lists.ozlabs.org">linux-aspeed@lists.ozlabs.org</a>" <<a ymailto="mailto:linux-aspeed@lists.ozlabs.org" href="mailto:linux-aspeed@lists.ozlabs.org">linux-aspeed@lists.ozlabs.org</a>>,<br></div><div dir="ltr"> "<a ymailto="mailto:linux-kernel@vger.kernel.org" href="mailto:linux-kernel@vger.kernel.org">linux-kernel@vger.kernel.org</a>" <<a ymailto="mailto:linux-kernel@vger.kernel.org" href="mailto:linux-kernel@vger.kernel.org">linux-kernel@vger.kernel.org</a>><br></div><div dir="ltr">Subject: RE: [PATCH v5 1/2] dt-bindings: i2c: Add support for ASPEED<br></div><div dir="ltr"> i2Cv2<br></div><div dir="ltr">Message-ID:<br></div><div dir="ltr"> <<a ymailto="mailto:SEZPR06MB52697747528490B1A16AF87FF2AB9@SEZPR06MB5269.apcprd06.prod.outlook.com" href="mailto:SEZPR06MB52697747528490B1A16AF87FF2AB9@SEZPR06MB5269.apcprd06.prod.outlook.com">SEZPR06MB52697747528490B1A16AF87FF2AB9@SEZPR06MB5269.apcprd06.prod.outlook.com</a>><br></div><div dir="ltr"> <br></div><div dir="ltr">Content-Type: text/plain; charset="utf-8"<br></div><div dir="ltr"><br></div><div dir="ltr">Hello Krzysztof,<br></div><div dir="ltr"><br></div><div dir="ltr">> -----Original Message-----<br></div><div dir="ltr">> From: Krzysztof Kozlowski <<a ymailto="mailto:krzysztof.kozlowski@linaro.org" href="mailto:krzysztof.kozlowski@linaro.org">krzysztof.kozlowski@linaro.org</a>><br></div><div dir="ltr">> Sent: Thursday, February 23, 2023 5:29 PM<br></div><div dir="ltr">> To: Ryan Chen <<a ymailto="mailto:ryan_chen@aspeedtech.com" href="mailto:ryan_chen@aspeedtech.com">ryan_chen@aspeedtech.com</a>>; Rob Herring<br></div><div dir="ltr">> <robh+<a ymailto="mailto:dt@kernel.org" href="mailto:dt@kernel.org">dt@kernel.org</a>>; Krzysztof Kozlowski<br></div><div dir="ltr">> <krzysztof.kozlowski+<a ymailto="mailto:dt@linaro.org" href="mailto:dt@linaro.org">dt@linaro.org</a>>; Joel Stanley <<a ymailto="mailto:joel@jms.id.au" href="mailto:joel@jms.id.au">joel@jms.id.au</a>>; Andrew<br></div><div dir="ltr">> Jeffery <<a ymailto="mailto:andrew@aj.id.au" href="mailto:andrew@aj.id.au">andrew@aj.id.au</a>>; Philipp Zabel <<a ymailto="mailto:p.zabel@pengutronix.de" href="mailto:p.zabel@pengutronix.de">p.zabel@pengutronix.de</a>>;<br></div><div dir="ltr">> <a ymailto="mailto:openbmc@lists.ozlabs.org" href="mailto:openbmc@lists.ozlabs.org">openbmc@lists.ozlabs.org</a>; <a ymailto="mailto:linux-arm-kernel@lists.infradead.org" href="mailto:linux-arm-kernel@lists.infradead.org">linux-arm-kernel@lists.infradead.org</a>;<br></div><div dir="ltr">> <a ymailto="mailto:linux-aspeed@lists.ozlabs.org" href="mailto:linux-aspeed@lists.ozlabs.org">linux-aspeed@lists.ozlabs.org</a>; <a ymailto="mailto:linux-kernel@vger.kernel.org" href="mailto:linux-kernel@vger.kernel.org">linux-kernel@vger.kernel.org</a><br></div><div dir="ltr">> Subject: Re: [PATCH v5 1/2] dt-bindings: i2c: Add support for ASPEED i2Cv2<br></div><div dir="ltr">> <br></div><div dir="ltr">> On 22/02/2023 11:47, Ryan Chen wrote:<br></div><div dir="ltr">> >>>> connector. That slave will keep state to drive clock stretching.<br></div><div dir="ltr">> >>>>> So it is specific enable in i2c bus#1. Others is not needed enable<br></div><div dir="ltr">> timeout.<br></div><div dir="ltr">> >>>>> Does this draw is more clear in scenario?<br></div><div dir="ltr">> >>>><br></div><div dir="ltr">> >>>> I2C bus #1 works in slave mode? So you always need it for slave work?<br></div><div dir="ltr">> >>><br></div><div dir="ltr">> >>> Yes, it is both slave/master mode. It is always dual role. Slave<br></div><div dir="ltr">> >>> must always<br></div><div dir="ltr">> >> work.<br></div><div dir="ltr">> >>> Due to another board master will send.<br></div><div dir="ltr">> >><br></div><div dir="ltr">> >> I meant that you need this property when it works in slave mode? It<br></div><div dir="ltr">> >> would be then redundant to have in DT as it is implied by the mode.<br></div><div dir="ltr">> ><br></div><div dir="ltr">> > But timeout feature is also apply in master. It for avoid suddenly<br></div><div dir="ltr">> > slave miss(un-plug) Master can timeout and release the SDA/SCL, return.<br></div><div dir="ltr">> <br></div><div dir="ltr">> OK, yet the property should describe the hardware, not the register feature you<br></div><div dir="ltr">> want to program. You need to properly model it in DT binding to represent<br></div><div dir="ltr">> hardware setup, not your desired Linux driver behavior.<br></div><div dir="ltr">> <br></div><div dir="ltr">> >>>>> The same draw, in this case, i2c bus#1 that is multi-master<br></div><div dir="ltr">> >>>>> transfer<br></div><div dir="ltr">> >>>> architecture.<br></div><div dir="ltr">> >>>>> Both will inactive with trunk data. That cane enable i2c#1 use DMA<br></div><div dir="ltr">> >>>>> transfer<br></div><div dir="ltr">> >>>> to reduce CPU utilized.<br></div><div dir="ltr">> >>>>> Others (bus#2/3) can keep byte/buff mode.<br></div><div dir="ltr">> >>>><br></div><div dir="ltr">> >>>> Isn't then current bus configuration for I2C#1 known to the driver?<br></div><div dir="ltr">> >>>> Jeremy asked few other questions around here...<br></div><div dir="ltr">> >>><br></div><div dir="ltr">> >>> No, The driver don't know currently board configuration.<br></div><div dir="ltr">> >><br></div><div dir="ltr">> >> It knows whether it is working in multi-master/slave mode.<br></div><div dir="ltr">> ><br></div><div dir="ltr">> > But in DT can decide which i2c bus number can use dma or buffer mode<br></div><div dir="ltr">> transfer.<br></div><div dir="ltr">> > If in another i2c bus support master only, also can use dma to transfer trunk<br></div><div dir="ltr">> data to another slave.<br></div><div dir="ltr">> <br></div><div dir="ltr">> and none of these were explained in commit msg or device description.<br></div><div dir="ltr">> <br></div><div dir="ltr">Thanks your guidance. I will add all those discussion in next patches cover-letter.<br></div><div dir="ltr">Best regards,<br></div><div dir="ltr">Ryan Chen.<br></div><div dir="ltr"><br></div><div dir="ltr">------------------------------<br></div><div dir="ltr"><br></div><div dir="ltr">Message: 3<br></div><div dir="ltr">Date: Thu, 23 Feb 2023 16:03:57 -0800<br></div><div dir="ltr">From: Zev Weiss <<a ymailto="mailto:zev@bewilderbeest.net" href="mailto:zev@bewilderbeest.net">zev@bewilderbeest.net</a>><br></div><div dir="ltr">To: Andrew Jeffery <<a ymailto="mailto:andrew@aj.id.au" href="mailto:andrew@aj.id.au">andrew@aj.id.au</a>>, Joel Stanley <<a ymailto="mailto:joel@jms.id.au" href="mailto:joel@jms.id.au">joel@jms.id.au</a>><br></div><div dir="ltr">Cc: Zev Weiss <<a ymailto="mailto:zev@bewilderbeest.net" href="mailto:zev@bewilderbeest.net">zev@bewilderbeest.net</a>>, <a ymailto="mailto:openbmc@lists.ozlabs.org" href="mailto:openbmc@lists.ozlabs.org">openbmc@lists.ozlabs.org</a>,<br></div><div dir="ltr"> Krzysztof Kozlowski <krzysztof.kozlowski+<a ymailto="mailto:dt@linaro.org" href="mailto:dt@linaro.org">dt@linaro.org</a>>, Rob Herring<br></div><div dir="ltr"> <robh+<a ymailto="mailto:dt@kernel.org" href="mailto:dt@kernel.org">dt@kernel.org</a>>, <a ymailto="mailto:devicetree@vger.kernel.org" href="mailto:devicetree@vger.kernel.org">devicetree@vger.kernel.org</a>,<br></div><div dir="ltr"> <a ymailto="mailto:linux-arm-kernel@lists.infradead.org" href="mailto:linux-arm-kernel@lists.infradead.org">linux-arm-kernel@lists.infradead.org</a>, <a ymailto="mailto:linux-aspeed@lists.ozlabs.org" href="mailto:linux-aspeed@lists.ozlabs.org">linux-aspeed@lists.ozlabs.org</a>,<br></div><div dir="ltr"> <a ymailto="mailto:linux-kernel@vger.kernel.org" href="mailto:linux-kernel@vger.kernel.org">linux-kernel@vger.kernel.org</a><br></div><div dir="ltr">Subject: [PATCH v2 0/3] ARM: dts: aspeed: ASRock BMC updates<br></div><div dir="ltr">Message-ID: <<a ymailto="mailto:20230224000400.12226-1-zev@bewilderbeest.net" href="mailto:20230224000400.12226-1-zev@bewilderbeest.net">20230224000400.12226-1-zev@bewilderbeest.net</a>><br></div><div dir="ltr"><br></div><div dir="ltr">Hello,<br></div><div dir="ltr"><br></div><div dir="ltr">This patch series contains a few small device-tree updates for ASRock<br></div><div dir="ltr">BMCs: an LED polarity fix for romed8hm3, enabling the ast2500 PECI<br></div><div dir="ltr">device on e3c246d4i, and a SPI flash clock frequency fix for both.<br></div><div dir="ltr"><br></div><div dir="ltr">Thanks,<br></div><div dir="ltr">Zev<br></div><div dir="ltr"><br></div><div dir="ltr">Changes since v1 [0]:<br></div><div dir="ltr"> - Added patch 3 correcting SPI flash clocks<br></div><div dir="ltr"><br></div><div dir="ltr">[0] <a href="https://lore.kernel.org/linux-devicetree/20230203105405.21942-1-zev@bewilderbeest.net/" target="_blank">https://lore.kernel.org/linux-devicetree/20230203105405.21942-1-zev@bewilderbeest.net/</a><br></div><div dir="ltr"><br></div><div dir="ltr">Zev Weiss (3):<br></div><div dir="ltr"> ARM: dts: aspeed: romed8hm3: Fix GPIO polarity of system-fault LED<br></div><div dir="ltr"> ARM: dts: aspeed: e3c246d4i: Add PECI device<br></div><div dir="ltr"> ARM: dts: aspeed: asrock: Correct firmware flash SPI clocks<br></div><div dir="ltr"><br></div><div dir="ltr"> arch/arm/boot/dts/aspeed-bmc-asrock-e3c246d4i.dts | 6 +++++-<br></div><div dir="ltr"> arch/arm/boot/dts/aspeed-bmc-asrock-romed8hm3.dts | 4 ++--<br></div><div dir="ltr"> 2 files changed, 7 insertions(+), 3 deletions(-)<br></div><div dir="ltr"><br></div><div dir="ltr">-- <br></div><div dir="ltr">2.39.1.438.gdcb075ea9396.dirty<br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr">------------------------------<br></div><div dir="ltr"><br></div><div dir="ltr">Message: 4<br></div><div dir="ltr">Date: Thu, 23 Feb 2023 16:04:00 -0800<br></div><div dir="ltr">From: Zev Weiss <<a ymailto="mailto:zev@bewilderbeest.net" href="mailto:zev@bewilderbeest.net">zev@bewilderbeest.net</a>><br></div><div dir="ltr">To: Andrew Jeffery <<a ymailto="mailto:andrew@aj.id.au" href="mailto:andrew@aj.id.au">andrew@aj.id.au</a>>, Joel Stanley <<a ymailto="mailto:joel@jms.id.au" href="mailto:joel@jms.id.au">joel@jms.id.au</a>><br></div><div dir="ltr">Cc: Zev Weiss <<a ymailto="mailto:zev@bewilderbeest.net" href="mailto:zev@bewilderbeest.net">zev@bewilderbeest.net</a>>, Krzysztof Kozlowski<br></div><div dir="ltr"> <krzysztof.kozlowski+<a ymailto="mailto:dt@linaro.org" href="mailto:dt@linaro.org">dt@linaro.org</a>>, Rob Herring <robh+<a ymailto="mailto:dt@kernel.org" href="mailto:dt@kernel.org">dt@kernel.org</a>>,<br></div><div dir="ltr"> <a ymailto="mailto:devicetree@vger.kernel.org" href="mailto:devicetree@vger.kernel.org">devicetree@vger.kernel.org</a>, <a ymailto="mailto:linux-arm-kernel@lists.infradead.org" href="mailto:linux-arm-kernel@lists.infradead.org">linux-arm-kernel@lists.infradead.org</a>,<br></div><div dir="ltr"> <a ymailto="mailto:linux-aspeed@lists.ozlabs.org" href="mailto:linux-aspeed@lists.ozlabs.org">linux-aspeed@lists.ozlabs.org</a>, <a ymailto="mailto:linux-kernel@vger.kernel.org" href="mailto:linux-kernel@vger.kernel.org">linux-kernel@vger.kernel.org</a>,<br></div><div dir="ltr"> <a ymailto="mailto:openbmc@lists.ozlabs.org" href="mailto:openbmc@lists.ozlabs.org">openbmc@lists.ozlabs.org</a>, <a ymailto="mailto:stable@vger.kernel.org" href="mailto:stable@vger.kernel.org">stable@vger.kernel.org</a><br></div><div dir="ltr">Subject: [PATCH v2 3/3] ARM: dts: aspeed: asrock: Correct firmware<br></div><div dir="ltr"> flash SPI clocks<br></div><div dir="ltr">Message-ID: <<a ymailto="mailto:20230224000400.12226-4-zev@bewilderbeest.net" href="mailto:20230224000400.12226-4-zev@bewilderbeest.net">20230224000400.12226-4-zev@bewilderbeest.net</a>><br></div><div dir="ltr"><br></div><div dir="ltr">While I'm not aware of any problems that have occurred running these<br></div><div dir="ltr">at 100 MHz, the official word from ASRock is that 50 MHz is the<br></div><div dir="ltr">correct speed to use, so let's be safe and use that instead.<br></div><div dir="ltr"><br></div><div dir="ltr">Signed-off-by: Zev Weiss <<a ymailto="mailto:zev@bewilderbeest.net" href="mailto:zev@bewilderbeest.net">zev@bewilderbeest.net</a>><br></div><div dir="ltr">Cc: <a ymailto="mailto:stable@vger.kernel.org" href="mailto:stable@vger.kernel.org">stable@vger.kernel.org</a><br></div><div dir="ltr">Fixes: 2b81613ce417 ("ARM: dts: aspeed: Add ASRock E3C246D4I BMC")<br></div><div dir="ltr">Fixes: a9a3d60b937a ("ARM: dts: aspeed: Add ASRock ROMED8HM3 BMC")<br></div><div dir="ltr">---<br></div><div dir="ltr"> arch/arm/boot/dts/aspeed-bmc-asrock-e3c246d4i.dts | 2 +-<br></div><div dir="ltr"> arch/arm/boot/dts/aspeed-bmc-asrock-romed8hm3.dts | 2 +-<br></div><div dir="ltr"> 2 files changed, 2 insertions(+), 2 deletions(-)<br></div><div dir="ltr"><br></div><div dir="ltr">diff --git a/arch/arm/boot/dts/aspeed-bmc-asrock-e3c246d4i.dts b/arch/arm/boot/dts/aspeed-bmc-asrock-e3c246d4i.dts<br></div><div dir="ltr">index 67a75aeafc2b..c4b2efbfdf56 100644<br></div><div dir="ltr">--- a/arch/arm/boot/dts/aspeed-bmc-asrock-e3c246d4i.dts<br></div><div dir="ltr">+++ b/arch/arm/boot/dts/aspeed-bmc-asrock-e3c246d4i.dts<br></div><div dir="ltr">@@ -63,7 +63,7 @@ <a ymailto="mailto:flash@0" href="mailto:flash@0">flash@0</a> {<br></div><div dir="ltr"> status = "okay";<br></div><div dir="ltr"> m25p,fast-read;<br></div><div dir="ltr"> label = "bmc";<br></div><div dir="ltr">- spi-max-frequency = <100000000>; /* 100 MHz */<br></div><div dir="ltr">+ spi-max-frequency = <50000000>; /* 50 MHz */<br></div><div dir="ltr"> #include "openbmc-flash-layout.dtsi"<br></div><div dir="ltr"> };<br></div><div dir="ltr"> };<br></div><div dir="ltr">diff --git a/arch/arm/boot/dts/aspeed-bmc-asrock-romed8hm3.dts b/arch/arm/boot/dts/aspeed-bmc-asrock-romed8hm3.dts<br></div><div dir="ltr">index 00efe1a93a69..4554abf0c7cd 100644<br></div><div dir="ltr">--- a/arch/arm/boot/dts/aspeed-bmc-asrock-romed8hm3.dts<br></div><div dir="ltr">+++ b/arch/arm/boot/dts/aspeed-bmc-asrock-romed8hm3.dts<br></div><div dir="ltr">@@ -51,7 +51,7 @@ <a ymailto="mailto:flash@0" href="mailto:flash@0">flash@0</a> {<br></div><div dir="ltr"> status = "okay";<br></div><div dir="ltr"> m25p,fast-read;<br></div><div dir="ltr"> label = "bmc";<br></div><div dir="ltr">- spi-max-frequency = <100000000>; /* 100 MHz */<br></div><div dir="ltr">+ spi-max-frequency = <50000000>; /* 50 MHz */<br></div><div dir="ltr"> #include "openbmc-flash-layout-64.dtsi"<br></div><div dir="ltr"> };<br></div><div dir="ltr"> };<br></div><div dir="ltr">-- <br></div><div dir="ltr">2.39.1.438.gdcb075ea9396.dirty<br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr">End of openbmc Digest, Vol 90, Issue 49<br></div><div dir="ltr">***************************************<br></div></div>
</div>
</div></body></html>