Re: dmaengine: at_hdmac: Regression regarding rs485 via dma in v5.4

Re: dmaengine: at_hdmac: Regression regarding rs485 via dma in v5.4

[Linux regression tracking (Thorsten Leemhuis)]

[Adding a few pople to the list of recipients that were involved in
developing the culprit; also CCing the regression list, as it should be
in the loop for regressions:
https://docs.kernel.org/admin-guide/reporting-regressions.html]

[TLDR: I'm adding this report to the list of tracked Linux kernel
regressions; the text you find below is based on a few templates
paragraphs you might have encountered already in similar form.
See link in footer if these mails annoy you.]

On 29.03.23 16:31, Kristof Havasi wrote:
> 
> I was rebasing the Kernel branch of our SAMA5D35 based board from
> v5.4.189 to v5.4.238.
> I noticed that after the rebase we could _only send, but not receive_
> through our RS485 interface.
> 
> I could bisect the problem to 77b97ef4908aa917e7b68667ec6b344cc5dc5034
> in the v5.4.225 release. 

FWIW, that's 7176a6a8982d ("dmaengine: at_hdmac: Don't start
transactions at tx_submit level") in mainline.

Kristof Havasi: would be good to know if this is something that happens
with recent mainline as well, because if not it might be something the
stable team needs to handle.

> If I revert this commit, the tx/rx works just
> like before.
> Maybe this use-case wasn't considered when this patch was created?
> I haven't seen a documentation change regarding this in DT bindings,
> but if the config should be something else, please let me know.
> Otherwise this commit breaks the RS485 function of atmel_serial at
> least in the v5.4.y branch.
> 
> Best Regards,
> Kristóf Havasi
> 
> The relevant device tree nodes:
> 
> from sama5d3.dtsi:
> 
> usart1: serial@f0020000 {
>   compatible = "atmel,at91sam9260-usart";
>   reg = <0xf0020000 0x100>;
>   interrupts = <13 IRQ_TYPE_LEVEL_HIGH 5>;
>   dmas = <&dma0 2 AT91_DMA_CFG_PER_ID(5)>,
>   <&dma0 2 (AT91_DMA_CFG_PER_ID(6) | AT91_DMA_CFG_FIFOCFG_ASAP)>;
>   dma-names = "tx", "rx";
>   pinctrl-names = "default";
>   pinctrl-0 = <&pinctrl_usart1>;
>   clocks = <&usart1_clk>;
>   clock-names = "usart";
>   status = "disabled";
> };
> 
> pinctrl_usart1: usart1-0 {
>   atmel,pins =
>   <AT91_PIOB 28 AT91_PERIPH_A AT91_PINCTRL_PULL_UP
>    AT91_PIOB 29 AT91_PERIPH_A AT91_PINCTRL_NONE>;
> };
> pinctrl_usart1_rts_cts: usart1_rts_cts-0 {
>   atmel,pins =
>   <AT91_PIOB 26 AT91_PERIPH_A AT91_PINCTRL_NONE /* PB26 periph A,
> conflicts with GRX7 */
>    AT91_PIOB 27 AT91_PERIPH_A AT91_PINCTRL_NONE>; /* PB27 periph A,
> conflicts with G125CKO */
> };
> 
> from our dts:
> 
> &usart1 {
>   pinctrl-0 = <&pinctrl_usart1 &pinctrl_usart1_rts_cts>;
>   atmel,use-dma-rx;
>   atmel,use-dma-tx;
>   rs485-rx-during-tx;
>   linux,rs485-enabled-at-boot-time;
>   status = "okay";
> };
> 
> HW:
> The SAMA5D3's PB27 is connected to the |RE+DE of the RS485 transceiver
> SP3458EN-L


Thanks for the report. To be sure the issue doesn't fall through the
cracks unnoticed, I'm adding it to regzbot, the Linux kernel regression
tracking bot:

#regzbot ^introduced 77b97ef4908aa
#regzbot title dmaengine: at_hdmac: receiving data through the RS485
interface broke
#regzbot ignore-activity

This isn't a regression? This issue or a fix for it are already
discussed somewhere else? It was fixed already? You want to clarify when
the regression started to happen? Or point out I got the title or
something else totally wrong? Then just reply and tell me -- ideally
while also telling regzbot about it, as explained by the page listed in
the footer of this mail.

Developers: When fixing the issue, remember to add 'Link:' tags pointing
to the report (the parent of this mail). See page linked in footer for
details.

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
That page also explains what to do if mails like this annoy you.

Re: dmaengine: at_hdmac: Regression regarding rs485 via dma in v5.4

[Linux regression tracking (Thorsten Leemhuis)]

On 04.04.23 13:25, Linux regression tracking (Thorsten Leemhuis) wrote:
> [Adding a few pople to the list of recipients that were involved in
> developing the culprit; also CCing the regression list, as it should be
> in the loop for regressions:
> https://docs.kernel.org/admin-guide/reporting-regressions.html]
> 
> [TLDR: I'm adding this report to the list of tracked Linux kernel
> regressions; the text you find below is based on a few templates
> paragraphs you might have encountered already in similar form.
> See link in footer if these mails annoy you.]
> 
> On 29.03.23 16:31, Kristof Havasi wrote:
>>
>> I was rebasing the Kernel branch of our SAMA5D35 based board from
>> v5.4.189 to v5.4.238.
>> I noticed that after the rebase we could _only send, but not receive_
>> through our RS485 interface.
>>
>> I could bisect the problem to 77b97ef4908aa917e7b68667ec6b344cc5dc5034
>> in the v5.4.225 release. 
> 
> FWIW, that's 7176a6a8982d ("dmaengine: at_hdmac: Don't start
> transactions at tx_submit level") in mainline.
> 
> Kristof Havasi: would be good to know if this is something that happens
> with recent mainline as well, because if not it might be something the
> stable team needs to handle.

Kristof, any news? Doesn't look like it from here, but maybe I'm missing
something.

And did you try what I suggested? Without trying that it looks like
neither the mainline developers nor the stable team cares enough to look
into your report, as both sides might assume it's the other sides duty
to do so.

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
If I did something stupid, please tell me, as explained on that page.

#regzbot poke

>> If I revert this commit, the tx/rx works just
>> like before.
>> Maybe this use-case wasn't considered when this patch was created?
>> I haven't seen a documentation change regarding this in DT bindings,
>> but if the config should be something else, please let me know.
>> Otherwise this commit breaks the RS485 function of atmel_serial at
>> least in the v5.4.y branch.
>>
>> Best Regards,
>> Kristóf Havasi
>>
>> The relevant device tree nodes:
>>
>> from sama5d3.dtsi:
>>
>> usart1: serial@f0020000 {
>>   compatible = "atmel,at91sam9260-usart";
>>   reg = <0xf0020000 0x100>;
>>   interrupts = <13 IRQ_TYPE_LEVEL_HIGH 5>;
>>   dmas = <&dma0 2 AT91_DMA_CFG_PER_ID(5)>,
>>   <&dma0 2 (AT91_DMA_CFG_PER_ID(6) | AT91_DMA_CFG_FIFOCFG_ASAP)>;
>>   dma-names = "tx", "rx";
>>   pinctrl-names = "default";
>>   pinctrl-0 = <&pinctrl_usart1>;
>>   clocks = <&usart1_clk>;
>>   clock-names = "usart";
>>   status = "disabled";
>> };
>>
>> pinctrl_usart1: usart1-0 {
>>   atmel,pins =
>>   <AT91_PIOB 28 AT91_PERIPH_A AT91_PINCTRL_PULL_UP
>>    AT91_PIOB 29 AT91_PERIPH_A AT91_PINCTRL_NONE>;
>> };
>> pinctrl_usart1_rts_cts: usart1_rts_cts-0 {
>>   atmel,pins =
>>   <AT91_PIOB 26 AT91_PERIPH_A AT91_PINCTRL_NONE /* PB26 periph A,
>> conflicts with GRX7 */
>>    AT91_PIOB 27 AT91_PERIPH_A AT91_PINCTRL_NONE>; /* PB27 periph A,
>> conflicts with G125CKO */
>> };
>>
>> from our dts:
>>
>> &usart1 {
>>   pinctrl-0 = <&pinctrl_usart1 &pinctrl_usart1_rts_cts>;
>>   atmel,use-dma-rx;
>>   atmel,use-dma-tx;
>>   rs485-rx-during-tx;
>>   linux,rs485-enabled-at-boot-time;
>>   status = "okay";
>> };
>>
>> HW:
>> The SAMA5D3's PB27 is connected to the |RE+DE of the RS485 transceiver
>> SP3458EN-L
> 
> 
> Thanks for the report. To be sure the issue doesn't fall through the
> cracks unnoticed, I'm adding it to regzbot, the Linux kernel regression
> tracking bot:
> 
> #regzbot ^introduced 77b97ef4908aa
> #regzbot title dmaengine: at_hdmac: receiving data through the RS485
> interface broke
> #regzbot ignore-activity
> 
> This isn't a regression? This issue or a fix for it are already
> discussed somewhere else? It was fixed already? You want to clarify when
> the regression started to happen? Or point out I got the title or
> something else totally wrong? Then just reply and tell me -- ideally
> while also telling regzbot about it, as explained by the page listed in
> the footer of this mail.
> 
> Developers: When fixing the issue, remember to add 'Link:' tags pointing
> to the report (the parent of this mail). See page linked in footer for
> details.
> 
> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
> --
> Everything you wanna know about Linux kernel regression tracking:
> https://linux-regtracking.leemhuis.info/about/#tldr
> That page also explains what to do if mails like this annoy you.
> 
> 

Re: dmaengine: at_hdmac: Regression regarding rs485 via dma in v5.4

[Thorsten Leemhuis]

On 04.05.23 11:11, Linux regression tracking (Thorsten Leemhuis) wrote:
> On 04.04.23 13:25, Linux regression tracking (Thorsten Leemhuis) wrote:
>> On 29.03.23 16:31, Kristof Havasi wrote:
>>>
>>> I was rebasing the Kernel branch of our SAMA5D35 based board from
>>> v5.4.189 to v5.4.238.
>>> I noticed that after the rebase we could _only send, but not receive_
>>> through our RS485 interface.
>>>
>>> I could bisect the problem to 77b97ef4908aa917e7b68667ec6b344cc5dc5034
>>> in the v5.4.225 release. 
>>
>> FWIW, that's 7176a6a8982d ("dmaengine: at_hdmac: Don't start
>> transactions at tx_submit level") in mainline.
>>
>> Kristof Havasi: would be good to know if this is something that happens
>> with recent mainline as well, because if not it might be something the
>> stable team needs to handle.
> 
> Kristof, any news? Doesn't look like it from here, but maybe I'm missing
> something.
> 
> And did you try what I suggested? Without trying that it looks like
> neither the mainline developers nor the stable team cares enough to look
> into your report, as both sides might assume it's the other sides duty
> to do so.

Hmmm, still no update from . This is unfortunate, as without Kristof's
help the kernel developers are likely unable to get down to this and
provide a fix. That's why I'm dropping it from the tracking now.

#regzbot inconclusive: reporter apparently lost interest

Ciao, Thorsten

>>> If I revert this commit, the tx/rx works just
>>> like before.
>>> Maybe this use-case wasn't considered when this patch was created?
>>> I haven't seen a documentation change regarding this in DT bindings,
>>> but if the config should be something else, please let me know.
>>> Otherwise this commit breaks the RS485 function of atmel_serial at
>>> least in the v5.4.y branch.
>>>
>>> Best Regards,
>>> Kristóf Havasi
>>>
>>> The relevant device tree nodes:
>>>
>>> from sama5d3.dtsi:
>>>
>>> usart1: serial@f0020000 {
>>>   compatible = "atmel,at91sam9260-usart";
>>>   reg = <0xf0020000 0x100>;
>>>   interrupts = <13 IRQ_TYPE_LEVEL_HIGH 5>;
>>>   dmas = <&dma0 2 AT91_DMA_CFG_PER_ID(5)>,
>>>   <&dma0 2 (AT91_DMA_CFG_PER_ID(6) | AT91_DMA_CFG_FIFOCFG_ASAP)>;
>>>   dma-names = "tx", "rx";
>>>   pinctrl-names = "default";
>>>   pinctrl-0 = <&pinctrl_usart1>;
>>>   clocks = <&usart1_clk>;
>>>   clock-names = "usart";
>>>   status = "disabled";
>>> };
>>>
>>> pinctrl_usart1: usart1-0 {
>>>   atmel,pins =
>>>   <AT91_PIOB 28 AT91_PERIPH_A AT91_PINCTRL_PULL_UP
>>>    AT91_PIOB 29 AT91_PERIPH_A AT91_PINCTRL_NONE>;
>>> };
>>> pinctrl_usart1_rts_cts: usart1_rts_cts-0 {
>>>   atmel,pins =
>>>   <AT91_PIOB 26 AT91_PERIPH_A AT91_PINCTRL_NONE /* PB26 periph A,
>>> conflicts with GRX7 */
>>>    AT91_PIOB 27 AT91_PERIPH_A AT91_PINCTRL_NONE>; /* PB27 periph A,
>>> conflicts with G125CKO */
>>> };
>>>
>>> from our dts:
>>>
>>> &usart1 {
>>>   pinctrl-0 = <&pinctrl_usart1 &pinctrl_usart1_rts_cts>;
>>>   atmel,use-dma-rx;
>>>   atmel,use-dma-tx;
>>>   rs485-rx-during-tx;
>>>   linux,rs485-enabled-at-boot-time;
>>>   status = "okay";
>>> };
>>>
>>> HW:
>>> The SAMA5D3's PB27 is connected to the |RE+DE of the RS485 transceiver
>>> SP3458EN-L
>>
>>
>> Thanks for the report. To be sure the issue doesn't fall through the
>> cracks unnoticed, I'm adding it to regzbot, the Linux kernel regression
>> tracking bot:
>>
>> #regzbot ^introduced 77b97ef4908aa
>> #regzbot title dmaengine: at_hdmac: receiving data through the RS485
>> interface broke
>> #regzbot ignore-activity
>>
>> This isn't a regression? This issue or a fix for it are already
>> discussed somewhere else? It was fixed already? You want to clarify when
>> the regression started to happen? Or point out I got the title or
>> something else totally wrong? Then just reply and tell me -- ideally
>> while also telling regzbot about it, as explained by the page listed in
>> the footer of this mail.
>>
>> Developers: When fixing the issue, remember to add 'Link:' tags pointing
>> to the report (the parent of this mail). See page linked in footer for
>> details.
>>
>> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
>> --
>> Everything you wanna know about Linux kernel regression tracking:
>> https://linux-regtracking.leemhuis.info/about/#tldr
>> That page also explains what to do if mails like this annoy you.
>>
>>