On 01/10/2019 16:06, Adam Ford wrote:
Do you want me to push a patch to remove the
CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK hack once these patches have been
posted? It seems like the divider fix eliminates the need for this
hack.
No, the point of OMAP2_DSS_MIN_FCK_PER_PCK was never to work around
d
On Tue, Oct 1, 2019 at 4:31 AM Tomi Valkeinen wrote:
>
> On 01/10/2019 11:12, Tero Kristo wrote:
> > On 01/10/2019 08:07, Tomi Valkeinen wrote:
> >> On 30/09/2019 20:48, Tero Kristo wrote:
> >>
> >>> Hmmh, after some testing, it seems there is bad stuff happening with
> >>> the divider clock imple
On 01/10/2019 11:12, Tero Kristo wrote:
On 01/10/2019 08:07, Tomi Valkeinen wrote:
On 30/09/2019 20:48, Tero Kristo wrote:
Hmmh, after some testing, it seems there is bad stuff happening with
the divider clock implementation, I am re-working it as of now.
Basically what is wrong is that with
On 01/10/2019 08:07, Tomi Valkeinen wrote:
On 30/09/2019 20:48, Tero Kristo wrote:
Hmmh, after some testing, it seems there is bad stuff happening with
the divider clock implementation, I am re-working it as of now.
Basically what is wrong is that with a divider max value of say 16,
the drive
On 01/10/2019 08:07, Tomi Valkeinen wrote:
On 30/09/2019 20:48, Tero Kristo wrote:
Hmmh, after some testing, it seems there is bad stuff happening with
the divider clock implementation, I am re-working it as of now.
Basically what is wrong is that with a divider max value of say 16,
the drive
On 30/09/2019 20:48, Tero Kristo wrote:
Hmmh, after some testing, it seems there is bad stuff happening with the
divider clock implementation, I am re-working it as of now. Basically
what is wrong is that with a divider max value of say 16, the driver
attempts to craft the max value into a mas
On 30/09/2019 18:10, Adam Ford wrote:
On Mon, Sep 30, 2019 at 9:27 AM Tomi Valkeinen wrote:
On 30/09/2019 17:20, Tomi Valkeinen wrote:
Let's see what Tero says, but yeah, something is odd here. I expected
the max divider to be 16 with Tero's patch, but I don't see it having
that effect. I ca
On Mon, Sep 30, 2019 at 9:27 AM Tomi Valkeinen wrote:
>
> On 30/09/2019 17:20, Tomi Valkeinen wrote:
>
> > Let's see what Tero says, but yeah, something is odd here. I expected
> > the max divider to be 16 with Tero's patch, but I don't see it having
> > that effect. I can get the div to 31.
> >
>
> Am 30.09.2019 um 16:27 schrieb Tomi Valkeinen :
>
> On 30/09/2019 17:20, Tomi Valkeinen wrote:
>
>> Let's see what Tero says, but yeah, something is odd here. I expected the
>> max divider to be 16 with Tero's patch, but I don't see it having that
>> effect. I can get the div to 31.
>> You
On 30/09/2019 17:20, Tomi Valkeinen wrote:
Let's see what Tero says, but yeah, something is odd here. I expected
the max divider to be 16 with Tero's patch, but I don't see it having
that effect. I can get the div to 31.
You can see this from the clock register 0x48004e40 (CM_CLKSEL_DSS). The
On 30/09/2019 17:12, Adam Ford wrote:
I don't know the implications, so if the people from TI say stick with
16, I'm fine with that, but at least there is some evidence that it
can be higher than 16, but lower than 32.
Sorry for all the spam, but I moved both of them to 31 from 32, and it
als
On Mon, Sep 30, 2019 at 9:04 AM Adam Ford wrote:
>
> On Mon, Sep 30, 2019 at 8:54 AM Adam Ford wrote:
> >
> > On Mon, Sep 30, 2019 at 8:39 AM H. Nikolaus Schaller
> > wrote:
> > >
> > >
> > > > Am 30.09.2019 um 10:53 schrieb Tero Kristo :
> > > >
> > > > The best action here is probably to drop
On Mon, Sep 30, 2019 at 8:54 AM Adam Ford wrote:
>
> On Mon, Sep 30, 2019 at 8:39 AM H. Nikolaus Schaller
> wrote:
> >
> >
> > > Am 30.09.2019 um 10:53 schrieb Tero Kristo :
> > >
> > > The best action here is probably to drop the max-div value for this clock
> > > to 16. Can someone check this
On Mon, Sep 30, 2019 at 8:39 AM H. Nikolaus Schaller wrote:
>
>
> > Am 30.09.2019 um 10:53 schrieb Tero Kristo :
> >
> > The best action here is probably to drop the max-div value for this clock
> > to 16. Can someone check this with their display setup and see what
> > happens? Attached patch s
> Am 30.09.2019 um 10:53 schrieb Tero Kristo :
>
> The best action here is probably to drop the max-div value for this clock to
> 16. Can someone check this with their display setup and see what happens?
> Attached patch should do the trick.
I have checked on GTA04 and OpenPandora (DM3730 res
On 30/09/2019 16:17, Adam Ford wrote:
It looks like it's unhappy that its trying to get one frequency and
getting something different instead.
[ 10.014099] WARNING: CPU: 0 PID: 111 at
drivers/gpu/drm/omapdrm/dss/dss.c:655 dss_set_fck_rate+0x70/0x90
[omapdss]
[ 10.014129] clk rate mismatch:
On Mon, Sep 30, 2019 at 7:48 AM Tero Kristo wrote:
>
> On 30/09/2019 15:41, Adam Ford wrote:
> > On Mon, Sep 30, 2019 at 3:53 AM Tero Kristo wrote:
> >>
> >> On 30/09/2019 09:45, Tomi Valkeinen wrote:
> >>> Hi,
> >>>
> >>> On 27/09/2019 18:47, Tomi Valkeinen wrote:
> On 27/09/2019 18:37, Ter
On 30/09/2019 15:41, Adam Ford wrote:
On Mon, Sep 30, 2019 at 3:53 AM Tero Kristo wrote:
On 30/09/2019 09:45, Tomi Valkeinen wrote:
Hi,
On 27/09/2019 18:47, Tomi Valkeinen wrote:
On 27/09/2019 18:37, Tero Kristo wrote:
If you can provide details about what clock framework / driver does
wr
On Mon, Sep 30, 2019 at 3:53 AM Tero Kristo wrote:
>
> On 30/09/2019 09:45, Tomi Valkeinen wrote:
> > Hi,
> >
> > On 27/09/2019 18:47, Tomi Valkeinen wrote:
> >> On 27/09/2019 18:37, Tero Kristo wrote:
> >>
> >>> If you can provide details about what clock framework / driver does
> >>> wrong (samp
On 30/09/2019 09:45, Tomi Valkeinen wrote:
Hi,
On 27/09/2019 18:47, Tomi Valkeinen wrote:
On 27/09/2019 18:37, Tero Kristo wrote:
If you can provide details about what clock framework / driver does
wrong (sample clk_set_xyz call sequence, expected results via
clk_get_xyz, and what fails), I
On 27/09/2019 18:37, Tero Kristo wrote:
If you can provide details about what clock framework / driver does
wrong (sample clk_set_xyz call sequence, expected results via
clk_get_xyz, and what fails), I can take a look at it. Just reporting
arbitrary display driver issues I won't be able to deb
On 27/09/2019 16:47, Tomi Valkeinen wrote:
On 27/09/2019 15:33, Adam Ford wrote:
It looks like a bug in omap clock handling.
DSS uses dss1_alwon_fck_3430es2 as fclk. dss1_alwon_fck_3430es2 comes
from dpll4_ck, and there's a divider after the PLL, dpll4_m4_ck.
When the DSS driver sets dss1_alw
On 27/09/2019 15:33, Adam Ford wrote:
It looks like a bug in omap clock handling.
DSS uses dss1_alwon_fck_3430es2 as fclk. dss1_alwon_fck_3430es2 comes
from dpll4_ck, and there's a divider after the PLL, dpll4_m4_ck.
When the DSS driver sets dss1_alwon_fck_3430es2 rate to 2700 or
27870967,
On 27/09/2019 15:13, Adam Ford wrote:
On Fri, Sep 27, 2019 at 1:22 AM Tomi Valkeinen wrote:
On 26/09/2019 17:12, Adam Ford wrote:
And what is the hdmi5_configure there? I don't see anything in the
driver that would print hdmi5_configure. And, of course, there's no
hdmi5 on that platform. Hmm
On Fri, Sep 27, 2019 at 2:55 AM Tomi Valkeinen wrote:
>
> (dropping folks who're probably not interested...)
>
> On 26/09/2019 17:12, Adam Ford wrote:
> > On Thu, Sep 26, 2019 at 1:55 AM Tomi Valkeinen
> > wrote:
> >>
> >> On 25/09/2019 23:51, Adam Ford wrote:
> >>
> Has anyone debugged why
On Fri, Sep 27, 2019 at 1:22 AM Tomi Valkeinen wrote:
>
> On 26/09/2019 17:12, Adam Ford wrote:
>
> >> And what is the hdmi5_configure there? I don't see anything in the
> >> driver that would print hdmi5_configure. And, of course, there's no
> >> hdmi5 on that platform. Hmm, ok... it's from compo
(dropping folks who're probably not interested...)
On 26/09/2019 17:12, Adam Ford wrote:
On Thu, Sep 26, 2019 at 1:55 AM Tomi Valkeinen wrote:
On 25/09/2019 23:51, Adam Ford wrote:
Has anyone debugged why the hang is happening?
I started to debug this, but I got distracted when I noticed t
On 26/09/2019 17:12, Adam Ford wrote:
And what is the hdmi5_configure there? I don't see anything in the
driver that would print hdmi5_configure. And, of course, there's no
hdmi5 on that platform. Hmm, ok... it's from component.c, using "%ps".
Somehow that goes wrong. Which is a bit alarming, bu
On Thu, Sep 26, 2019 at 1:55 AM Tomi Valkeinen wrote:
>
> On 25/09/2019 23:51, Adam Ford wrote:
>
> >> Has anyone debugged why the hang is happening?
> > I started to debug this, but I got distracted when I noticed the LCD
> > did't work at all on modern kernels. I have that fixed now, so I can
>
On 25/09/2019 23:51, Adam Ford wrote:
Has anyone debugged why the hang is happening?
I started to debug this, but I got distracted when I noticed the LCD
did't work at all on modern kernels. I have that fixed now, so I can
go back to investigating this.
Working version:
[7.999359] DISPC:
On 5/28/19 4:11 AM, Tomi Valkeinen wrote:
> Hi,
>
> On 10/05/2019 22:42, Adam Ford wrote:
>> Currently the source code is compiled using hard-coded values
>> from CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK. This patch allows this
>> clock divider value to be moved to the device tree and be changed
>> witho
On Tue, May 28, 2019 at 10:53 AM Tomi Valkeinen wrote:
>
> Hi,
>
> On 28/05/2019 18:09, Adam Ford wrote:
> > On Tue, May 28, 2019 at 4:11 AM Tomi Valkeinen
> > wrote:
> >>
> >> Hi,
> >>
> >> On 10/05/2019 22:42, Adam Ford wrote:
> >>> Currently the source code is compiled using hard-coded values
On Fri, May 10, 2019 at 02:42:29PM -0500, Adam Ford wrote:
> Currently the source code is compiled using hard-coded values
> from CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK. This patch allows this
> clock divider value to be moved to the device tree and be changed
> without having to recompile the kernel.
>
On Tue, May 28, 2019 at 10:53 AM Tomi Valkeinen wrote:
>
> Hi,
>
> On 28/05/2019 18:09, Adam Ford wrote:
> > On Tue, May 28, 2019 at 4:11 AM Tomi Valkeinen
> > wrote:
> >>
> >> Hi,
> >>
> >> On 10/05/2019 22:42, Adam Ford wrote:
> >>> Currently the source code is compiled using hard-coded values
Hi,
On 28/05/2019 18:09, Adam Ford wrote:
On Tue, May 28, 2019 at 4:11 AM Tomi Valkeinen wrote:
Hi,
On 10/05/2019 22:42, Adam Ford wrote:
Currently the source code is compiled using hard-coded values
from CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK. This patch allows this
clock divider value to be mo
> Am 28.05.2019 um 17:09 schrieb Adam Ford :
>
> On Tue, May 28, 2019 at 4:11 AM Tomi Valkeinen wrote:
>>
>> Hi,
>>
>> On 10/05/2019 22:42, Adam Ford wrote:
>>> Currently the source code is compiled using hard-coded values
>>> from CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK. This patch allows this
>>>
On Tue, May 28, 2019 at 4:11 AM Tomi Valkeinen wrote:
>
> Hi,
>
> On 10/05/2019 22:42, Adam Ford wrote:
> > Currently the source code is compiled using hard-coded values
> > from CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK. This patch allows this
> > clock divider value to be moved to the device tree and be
Hi,
On 10/05/2019 22:42, Adam Ford wrote:
Currently the source code is compiled using hard-coded values
from CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK. This patch allows this
clock divider value to be moved to the device tree and be changed
without having to recompile the kernel.
Signed-off-by: Adam Fo
38 matches
Mail list logo
