Weird/Unneeded call to msleep in exynos_mipi_dsi_wr_data in exynos_mipi_dsi_common.c

Greetings Fellow Maintainers,
Sorry if I wasting your time but it seems there is a unneeded call to msleep

and rather trivial fix me to fix in the file,exynos_mipi_dsi_common.c for the function,exynos_mipi_dsi_wr_data . If there is a valid reason for this call please let me known when any of you have some free time. Otherwise I will send in a patch to remove this unneeded call to msleep.
Thanks,
Nick

Quoted 2 lines · nick

Greetings Fellow Maintainers,
Sorry if I wasting your time but it seems there is a unneeded call to msleep

Hi,

1. Please describe exactly why do you think this is not needed.
2. Do you have Exynos-based hardware to test your changes?

Best regards,
Krzysztof

Quoted 4 lines

and rather trivial fix me to fix in the file,exynos_mipi_dsi_common.c for the function,exynos_mipi_dsi_wr_data . If there is a valid reason for this call please let me known when any of you have some free time. Otherwise I will send in a patch to remove this unneeded call to msleep.
Thanks,
Nick

Krzysztof,
If we look at the code for this function, it already is handling the data correctly. In addition the locks seem to be better protection then msleep. Further more is no reason for this delay as we are neither resetting the hardware or waiting for the hardware here so why is it needed? I don't have Exynos based hardware lying around through to test it.

Am Donnerstag, den 18.12.2014, 08:35 -0500 schrieb nick:

Quoted 5 lines

Krzysztof,
If we look at the code for this function, it already is handling the data correctly. In addition the locks seem to be better protection then msleep. Further more is no reason for this delay as we are neither resetting the hardware or waiting for the hardware here so why is it needed? I don't have Exynos based hardware lying around through to test it.

If you can't test it, don't touch it. It's that simple.

Regards,
Lucas

Lucas,
That's fair do you known of anyone who does have the hardware so we can test my patch. If you do then we can get this fixed rather easily.
Cheers Nick

Quoted 8 lines · Lucas Stach

Am Donnerstag, den 18.12.2014, 08:35 -0500 schrieb nick:

Quoted 5 lines

Krzysztof,
If we look at the code for this function, it already is handling the data correctly. In addition the locks seem to be better protection then msleep. Further more is no reason for this delay as we are neither resetting the hardware or waiting for the hardware here so why is it needed? I don't have Exynos based hardware lying around through to test it.

If you can't test it, don't touch it. It's that simple.

Quoted 13 lines · nick

Lucas,
That's fair do you known of anyone who does have the hardware so we can test my patch. If you do then we can get this fixed rather easily.
Cheers Nick

Quoted 7 lines · Lucas Stach

Am Donnerstag, den 18.12.2014, 08:35 -0500 schrieb nick:

Quoted 5 lines

Krzysztof,
If we look at the code for this function, it already is handling the data correctly. In addition the locks seem to be better protection then msleep. Further more is no reason for this delay as we are neither resetting the hardware or waiting for the hardware here so why is it needed? I don't have Exynos based hardware lying around through to test it.

Quoted 1 line

Quoted 1 line

If you can't test it, don't touch it. It's that simple.

There seems to be multiple msleep(20)s in exynos_mipi_dsi_common.c, a few with /* FIXME */ and a few without any comments. Looks like bad (but relatively harmless) code to me, but as Lucas said, if you can't test it, don't touch it.

Tomi