| Message ID | 20240327055732.28198-1-yu-chang.lee@mediatek.com |
|---|---|
| Headers | show |
| Series | pmdomain: mediatek: solve power domain glitch issue | expand |
On 27/03/2024 06:57, yu-chang.lee wrote: > Add Smart Multimedia Interface Local Arbiter to mediatek > power domain. > > Signed-off-by: yu-chang.lee <yu-chang.lee@mediatek.com> > --- > .../devicetree/bindings/power/mediatek,power-controller.yaml | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml b/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml > index 8985e2df8a56..228c0dec5253 100644 > --- a/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml > +++ b/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml > @@ -125,6 +125,10 @@ $defs: > $ref: /schemas/types.yaml#/definitions/phandle > description: phandle to the device containing the SMI register range. > > + mediatek,larb: > + $ref: /schemas/types.yaml#/definitions/phandle > + description: phandle to the device containing the LARB register range. Why do you need it? Plus I also see mediatek,larbs and mediatek,larb-id... so now we have third one similar. Best regards, Krzysztof
On 27/03/2024 09:39, Krzysztof Kozlowski wrote: > On 27/03/2024 06:57, yu-chang.lee wrote: >> Add Smart Multimedia Interface Local Arbiter to mediatek >> power domain. >> >> Signed-off-by: yu-chang.lee <yu-chang.lee@mediatek.com> >> --- >> .../devicetree/bindings/power/mediatek,power-controller.yaml | 4 ++++ >> 1 file changed, 4 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml b/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml >> index 8985e2df8a56..228c0dec5253 100644 >> --- a/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml >> +++ b/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml >> @@ -125,6 +125,10 @@ $defs: >> $ref: /schemas/types.yaml#/definitions/phandle >> description: phandle to the device containing the SMI register range. >> >> + mediatek,larb: >> + $ref: /schemas/types.yaml#/definitions/phandle >> + description: phandle to the device containing the LARB register range. > > Why do you need it? > > Plus I also see mediatek,larbs and mediatek,larb-id... so now we have > third one similar. ... and not even tested! Best regards, Krzysztof
On Wed, 2024-03-27 at 09:39 +0100, Krzysztof Kozlowski wrote: > > External email : Please do not click links or open attachments until > you have verified the sender or the content. > On 27/03/2024 06:57, yu-chang.lee wrote: > > Add Smart Multimedia Interface Local Arbiter to mediatek > > power domain. > > > > Signed-off-by: yu-chang.lee <yu-chang.lee@mediatek.com> > > --- > > .../devicetree/bindings/power/mediatek,power-controller.yaml | 4 > ++++ > > 1 file changed, 4 insertions(+) > > > > diff --git > a/Documentation/devicetree/bindings/power/mediatek,power- > controller.yaml > b/Documentation/devicetree/bindings/power/mediatek,power- > controller.yaml > > index 8985e2df8a56..228c0dec5253 100644 > > --- a/Documentation/devicetree/bindings/power/mediatek,power- > controller.yaml > > +++ b/Documentation/devicetree/bindings/power/mediatek,power- > controller.yaml > > @@ -125,6 +125,10 @@ $defs: > > $ref: /schemas/types.yaml#/definitions/phandle > > description: phandle to the device containing the SMI > register range. > > > > + mediatek,larb: > > + $ref: /schemas/types.yaml#/definitions/phandle > > + description: phandle to the device containing the LARB > register range. > > Why do you need it? > > Plus I also see mediatek,larbs and mediatek,larb-id... so now we have > third one similar. > MM driver used "mediatek,larbs" for it larb node. Power domain driver used "mediatek,larb". "mediatek,larb-id" is for larb in dts. The naming is no related to each other. Best Regards, Yu-chang. > Best regards, > Krzysztof >
On Wed, 2024-03-27 at 12:55 +0100, Alexandre Mergnat wrote: > > External email : Please do not click links or open attachments until > you have verified the sender or the content. > Hello Yu-chang Lee, > > SMI LARB must have a power domain, according to "mediatek,smi- > larb.yaml" > Now you try to create a link from power domain to larb. > > Here is my understanding: when you enable/disable power domain, the > larb linked to this power domain may have an issue. Then you want to > retrieve de LARB linked to the power domain though the dts to manage > the LARB. Yes, this is what I am trying to do. > IMHO, using the dts to have this information into the power > driver isn't necessary and may introduce some bugs if the LARB node > and power node in the DTS aren't aligned. > > It seems not implemented today but during the LARB probe, it should > "subscribe" to the linked power domain. Then, when the power domain > status is changing, it is able to "notify" (callback) the LARB, then > implement the good stuff to handle this power domain status change > into LARB driver. > The problem with this method and why "smi clamp" is in power domain driver is that our HW designer gave us a programming guide strictly states the sequence of what we need to do to power on/off power domain. Using callback, this sequence is no longer guaranteed and the side effect is unknown... So I would like to stick with adding larbs just like smi into power domain node. > Regards, > Alexandre Best Regards, Yu-chang > > On Wed, Mar 27, 2024 at 12:04 PM Krzysztof Kozlowski > <krzysztof.kozlowski@linaro.org> wrote: > > > > On 27/03/2024 11:56, Yu-chang Lee (李禹璋) wrote: > > > On Wed, 2024-03-27 at 11:43 +0100, Krzysztof Kozlowski wrote: > > >> > > >> External email : Please do not click links or open attachments > until > > >> you have verified the sender or the content. > > >> On 27/03/2024 11:39, Yu-chang Lee (李禹璋) wrote: > > >>>>>> > > >>>>> Hi, > > >>>>> > > >>>>> I will double check the format of yaml for the next version, > > >> sorry > > >>>> for > > >>>>> inconvenience. But I did test it on mt8188 chromebook, the > reason > > >>>> why > > >>>> > > >>>> How do you test a binding on chromebook? > > >>>> > > >>>>> power domain need larb node is that when mtcmos power on, > signal > > >>>> glitch > > >>>>> may produce. Power domain driver must reset larb when this > happen > > >>>> to > > >>>>> prevent dummy transaction on bus. That why I need larb node > in > > >> dts. > > >>>> > > >>>> No one talks here about larb node... > > >>> > > >>> Sorry, May you elaborate on what information I need to provide > to > > >> you > > >>> or it is just a syntax problem I need to fix? > > >> > > >> Please explain the purpose of this property (how is it going to > be > > >> used by drivers)and what does it represent. > > >> > > > > > > It represent SMI LARB(Local ARBitration). In power domain driver > when > > > power on power domain, It need to reset LARB to prevent potential > power > > > glitch which may cause dummy transaction on bus. Without taking > care of > > > this issue it often leads to camera hang in stress test. > > > > That sounds rather like missing resets... or something else > connecting > > these devices. Maybe the explanation is just imprecise... > > > > Best regards, > > Krzysztof > > > >
On Wed, 2024-03-27 at 12:04 +0100, Krzysztof Kozlowski wrote: > > External email : Please do not click links or open attachments until > you have verified the sender or the content. > On 27/03/2024 11:56, Yu-chang Lee (李禹璋) wrote: > > On Wed, 2024-03-27 at 11:43 +0100, Krzysztof Kozlowski wrote: > >> > >> External email : Please do not click links or open attachments > until > >> you have verified the sender or the content. > >> On 27/03/2024 11:39, Yu-chang Lee (李禹璋) wrote: > >>>>>> > >>>>> Hi, > >>>>> > >>>>> I will double check the format of yaml for the next version, > >> sorry > >>>> for > >>>>> inconvenience. But I did test it on mt8188 chromebook, the > reason > >>>> why > >>>> > >>>> How do you test a binding on chromebook? > >>>> > >>>>> power domain need larb node is that when mtcmos power on, > signal > >>>> glitch > >>>>> may produce. Power domain driver must reset larb when this > happen > >>>> to > >>>>> prevent dummy transaction on bus. That why I need larb node in > >> dts. > >>>> > >>>> No one talks here about larb node... > >>> > >>> Sorry, May you elaborate on what information I need to provide to > >> you > >>> or it is just a syntax problem I need to fix? > >> > >> Please explain the purpose of this property (how is it going to be > >> used by drivers)and what does it represent. > >> > > > > It represent SMI LARB(Local ARBitration). In power domain driver > when > > power on power domain, It need to reset LARB to prevent potential > power > > glitch which may cause dummy transaction on bus. Without taking > care of > > this issue it often leads to camera hang in stress test. > > That sounds rather like missing resets... or something else > connecting > these devices. Maybe the explanation is just imprecise... > Maybe the term "reset" is misleading here. What power domain driver trying to do is "set and then clr" the smi larb to clear potential glitch signal that is already in there. And this step is strongly related to power domain onf that why I want to add it in to power domain node without depending larb driver to do the work to prevent this setting missing. > Best regards, > Krzysztof Best Regards, yu-chang >
On 28/03/2024 07:06, Yu-chang Lee (李禹璋) wrote: > On Wed, 2024-03-27 at 12:55 +0100, Alexandre Mergnat wrote: >> >> External email : Please do not click links or open attachments until >> you have verified the sender or the content. >> Hello Yu-chang Lee, >> >> SMI LARB must have a power domain, according to "mediatek,smi- >> larb.yaml" >> Now you try to create a link from power domain to larb. >> >> Here is my understanding: when you enable/disable power domain, the >> larb linked to this power domain may have an issue. Then you want to >> retrieve de LARB linked to the power domain though the dts to manage >> the LARB. > > Yes, this is what I am trying to do. > >> IMHO, using the dts to have this information into the power >> driver isn't necessary and may introduce some bugs if the LARB node >> and power node in the DTS aren't aligned. >> >> It seems not implemented today but during the LARB probe, it should >> "subscribe" to the linked power domain. Then, when the power domain >> status is changing, it is able to "notify" (callback) the LARB, then >> implement the good stuff to handle this power domain status change >> into LARB driver. >> > > The problem with this method and why "smi clamp" is in power domain > driver is that our HW designer gave us a programming guide strictly > states the sequence of what we need to do to power on/off power domain. > Using callback, this sequence is no longer guaranteed and the side > effect is unknown... > > So I would like to stick with adding larbs just like smi into powe You want your power domain driver to poke, asynchronously, without locking into registers of another device. And how does this not cause issues? No, work with your hardware engineers or Linux engineers on sane behavior. Best regards, Krzysztof