When mali.ko is inserted, it set default clocks
and call all parent clocks to stay into range,
causing pll-video0 to change and subsequently
to change dclk to wrong frequencies.
"gpu" clock has lot of parent plls inside driver,
but on sun7i pll8-gpu does not depend on pll-video0,
pll-ve, pll-video1.
It only depends on 24Mhz main clock.
Remove all pll parents from gpu_parents_sun7i except "pll-gpu".
Signed-off-by: Giulio Benetti <[email protected]>
---
drivers/clk/sunxi-ng/ccu-sun4i-a10.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/clk/sunxi-ng/ccu-sun4i-a10.c b/drivers/clk/sunxi-ng/ccu-sun4i-a10.c
index ffa5dac..49726a6 100644
--- a/drivers/clk/sunxi-ng/ccu-sun4i-a10.c
+++ b/drivers/clk/sunxi-ng/ccu-sun4i-a10.c
@@ -790,9 +790,7 @@ static SUNXI_CCU_M_WITH_MUX_GATE(gpu_sun4i_clk, "gpu", gpu_parents_sun4i,
0x154, 0, 4, 24, 2, BIT(31),
CLK_SET_RATE_PARENT);
-static const char *const gpu_parents_sun7i[] = { "pll-video0", "pll-ve",
- "pll-ddr-other", "pll-video1",
- "pll-gpu" };
+static const char *const gpu_parents_sun7i[] = { "pll-gpu" };
static const u8 gpu_table_sun7i[] = { 0, 1, 2, 3, 4 };
static SUNXI_CCU_M_WITH_MUX_TABLE_GATE(gpu_sun7i_clk, "gpu",
gpu_parents_sun7i, gpu_table_sun7i,
--
2.7.4
Hi,
On Wed, Jan 31, 2018 at 12:23:59AM +0100, Giulio Benetti wrote:
> When mali.ko is inserted, it set default clocks and call all parent
> clocks to stay into range, causing pll-video0 to change and
> subsequently to change dclk to wrong frequencies.
This is what you should fix.
> "gpu" clock has lot of parent plls inside driver, but on sun7i
> pll8-gpu does not depend on pll-video0, pll-ve, pll-video1.
>
> It only depends on 24Mhz main clock.
I don't really know why you are mentionning that. The GPU clock has
all the parents described in the driver. And the parents' parents are
irrelevant to this particular issue.
> Remove all pll parents from gpu_parents_sun7i except "pll-gpu".
However, this is not a proper fix for your issue.
What kernel version did you use?
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
Hi,
Il 31/01/2018 09:43, Maxime Ripard ha scritto:
> Hi,
>
> On Wed, Jan 31, 2018 at 12:23:59AM +0100, Giulio Benetti wrote:
>> When mali.ko is inserted, it set default clocks and call all parent
>> clocks to stay into range, causing pll-video0 to change and
>> subsequently to change dclk to wrong frequencies.
>
> This is what you should fix.
Ok, so it must be patch title(shrinked of course), right?
>
>> "gpu" clock has lot of parent plls inside driver, but on sun7i
>> pll8-gpu does not depend on pll-video0, pll-ve, pll-video1.
>>
>> It only depends on 24Mhz main clock.
>
> I don't really know why you are mentionning that. The GPU clock has
> all the parents described in the driver. And the parents' parents are
> irrelevant to this particular issue.
>
>> Remove all pll parents from gpu_parents_sun7i except "pll-gpu".
>
> However, this is not a proper fix for your issue.
Yes, you're right, now I understand.
It is more complex than I thought.
I need to dig more and study better A20 CCU.
So this patch can be dropped.
>
> What kernel version did you use?
Latest mainline.
>
> Maxime
>
--
Giulio Benetti
R&D Manager &
Advanced Research
MICRONOVA SRL
Sede: Via A. Niedda 3 - 35010 Vigonza (PD)
Tel. 049/8931563 - Fax 049/8931346
Cod.Fiscale - P.IVA 02663420285
Capitale Sociale ? 26.000 i.v.
Iscritta al Reg. Imprese di Padova N. 02663420285
Numero R.E.A. 258642
On Wed, Jan 31, 2018 at 01:05:38PM +0100, Giulio Benetti wrote:
> Hi,
>
> Il 31/01/2018 09:43, Maxime Ripard ha scritto:
> > Hi,
> >
> > On Wed, Jan 31, 2018 at 12:23:59AM +0100, Giulio Benetti wrote:
> > > When mali.ko is inserted, it set default clocks and call all parent
> > > clocks to stay into range, causing pll-video0 to change and
> > > subsequently to change dclk to wrong frequencies.
> >
> > This is what you should fix.
>
> Ok, so it must be patch title(shrinked of course), right?
>
> >
> > > "gpu" clock has lot of parent plls inside driver, but on sun7i
> > > pll8-gpu does not depend on pll-video0, pll-ve, pll-video1.
> > >
> > > It only depends on 24Mhz main clock.
> >
> > I don't really know why you are mentionning that. The GPU clock has
> > all the parents described in the driver. And the parents' parents are
> > irrelevant to this particular issue.
> >
> > > Remove all pll parents from gpu_parents_sun7i except "pll-gpu".
> >
> > However, this is not a proper fix for your issue.
>
> Yes, you're right, now I understand.
>
> It is more complex than I thought.
> I need to dig more and study better A20 CCU.
>
> So this patch can be dropped.
>
> >
> > What kernel version did you use?
>
> Latest mainline.
I guess this patch could fix it:
http://code.bulix.org/1kitrq-268936?raw
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
Hi,
Il 01/02/2018 13:45, Maxime Ripard ha scritto:
> On Wed, Jan 31, 2018 at 01:05:38PM +0100, Giulio Benetti wrote:
>> Hi,
>>
>> Il 31/01/2018 09:43, Maxime Ripard ha scritto:
>>> Hi,
>>>
>>> On Wed, Jan 31, 2018 at 12:23:59AM +0100, Giulio Benetti wrote:
>>>> When mali.ko is inserted, it set default clocks and call all parent
>>>> clocks to stay into range, causing pll-video0 to change and
>>>> subsequently to change dclk to wrong frequencies.
>>>
>>> This is what you should fix.
>>
>> Ok, so it must be patch title(shrinked of course), right?
>>
>>>
>>>> "gpu" clock has lot of parent plls inside driver, but on sun7i
>>>> pll8-gpu does not depend on pll-video0, pll-ve, pll-video1.
>>>>
>>>> It only depends on 24Mhz main clock.
>>>
>>> I don't really know why you are mentionning that. The GPU clock has
>>> all the parents described in the driver. And the parents' parents are
>>> irrelevant to this particular issue.
>>>
>>>> Remove all pll parents from gpu_parents_sun7i except "pll-gpu".
>>>
>>> However, this is not a proper fix for your issue.
>>
>> Yes, you're right, now I understand.
>>
>> It is more complex than I thought.
>> I need to dig more and study better A20 CCU.
>>
>> So this patch can be dropped.
>>
>>>
>>> What kernel version did you use?
>>
>> Latest mainline.
>
> I guess this patch could fix it:
> http://code.bulix.org/1kitrq-268936?raw
This should prevent from modifying parent clock.
But my problem was different.
On A20, gpu_clk can have different PLL,
not I've found out the way to choose right one
with assigned-parent-clocks.
I have patchset ready for adding A20 mali node,
but I need some more time to complete with OPP,
then I will submit entire patchset.
Now it works correctly, using right pll(dedicated PLL8),
setting right frequency.
Btw, do I need to add a board using it,
or can I add only Mali node to sun7i-a20.dtsi(plus other little patches)?
>
> Maxime
>
--
Giulio Benetti
R&D Manager &
Advanced Research
MICRONOVA SRL
Sede: Via A. Niedda 3 - 35010 Vigonza (PD)
Tel. 049/8931563 - Fax 049/8931346
Cod.Fiscale - P.IVA 02663420285
Capitale Sociale ? 26.000 i.v.
Iscritta al Reg. Imprese di Padova N. 02663420285
Numero R.E.A. 258642
Hi,
On Thu, Feb 01, 2018 at 05:17:11PM +0100, Giulio Benetti wrote:
> > > > What kernel version did you use?
> > >
> > > Latest mainline.
> >
> > I guess this patch could fix it:
> > http://code.bulix.org/1kitrq-268936?raw
>
> This should prevent from modifying parent clock. But my problem was
> different.
>
> On A20, gpu_clk can have different PLL, not I've found out the way
> to choose right one with assigned-parent-clocks.
>
> I have patchset ready for adding A20 mali node, but I need some more
> time to complete with OPP, then I will submit entire patchset.
>
> Now it works correctly, using right pll(dedicated PLL8), setting
> right frequency.
The point is that we really don't care about which PLL is actually
being used, as long as the rate is correct and we don't break anything
else. If the GPU rate is accessible through one of the other PLL, it
makes even more sense to not use the GPU PLL and keep it disabled,
since it will result in some power savings.
> Btw, do I need to add a board using it, or can I add only Mali node
> to sun7i-a20.dtsi(plus other little patches)?
You can add it to the DTSI without a board using it (and actually,
nothing should be in the board DTS, everything in the DT for the Mali
applies to all boards).
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com
Il 02/02/2018 11:53, Maxime Ripard ha scritto:
> Hi,
>
> On Thu, Feb 01, 2018 at 05:17:11PM +0100, Giulio Benetti wrote:
>>>>> What kernel version did you use?
>>>>
>>>> Latest mainline.
>>>
>>> I guess this patch could fix it:
>>> http://code.bulix.org/1kitrq-268936?raw
>>
>> This should prevent from modifying parent clock. But my problem was
>> different.
>>
>> On A20, gpu_clk can have different PLL, not I've found out the way
>> to choose right one with assigned-parent-clocks.
>>
>> I have patchset ready for adding A20 mali node, but I need some more
>> time to complete with OPP, then I will submit entire patchset.
>>
>> Now it works correctly, using right pll(dedicated PLL8), setting
>> right frequency.
>
> The point is that we really don't care about which PLL is actually
> being used, as long as the rate is correct and we don't break anything
> else. If the GPU rate is accessible through one of the other PLL, it
> makes even more sense to not use the GPU PLL and keep it disabled,
> since it will result in some power savings.
Ah! I see the point now, very clever system for power saving.
I'm going to check if it's resolutive,
but it sounds good.
>
>> Btw, do I need to add a board using it, or can I add only Mali node
>> to sun7i-a20.dtsi(plus other little patches)?
>
> You can add it to the DTSI without a board using it (and actually,
> nothing should be in the board DTS, everything in the DT for the Mali
> applies to all boards).
Sure. So I would also add the patch you've addressed me:
http://code.bulix.org/1kitrq-268936?raw
as a commit. Can I submit it in patchset to complete the whole job?
>
> Maxime
>
--
Giulio Benetti
R&D Manager &
Advanced Research
MICRONOVA SRL
Sede: Via A. Niedda 3 - 35010 Vigonza (PD)
Tel. 049/8931563 - Fax 049/8931346
Cod.Fiscale - P.IVA 02663420285
Capitale Sociale ? 26.000 i.v.
Iscritta al Reg. Imprese di Padova N. 02663420285
Numero R.E.A. 258642
On Fri, Feb 02, 2018 at 11:57:20AM +0100, Giulio Benetti wrote:
> Il 02/02/2018 11:53, Maxime Ripard ha scritto:
> > Hi,
> >
> > On Thu, Feb 01, 2018 at 05:17:11PM +0100, Giulio Benetti wrote:
> > > > > > What kernel version did you use?
> > > > >
> > > > > Latest mainline.
> > > >
> > > > I guess this patch could fix it:
> > > > http://code.bulix.org/1kitrq-268936?raw
> > >
> > > This should prevent from modifying parent clock. But my problem was
> > > different.
> > >
> > > On A20, gpu_clk can have different PLL, not I've found out the way
> > > to choose right one with assigned-parent-clocks.
> > >
> > > I have patchset ready for adding A20 mali node, but I need some more
> > > time to complete with OPP, then I will submit entire patchset.
> > >
> > > Now it works correctly, using right pll(dedicated PLL8), setting
> > > right frequency.
> >
> > The point is that we really don't care about which PLL is actually
> > being used, as long as the rate is correct and we don't break anything
> > else. If the GPU rate is accessible through one of the other PLL, it
> > makes even more sense to not use the GPU PLL and keep it disabled,
> > since it will result in some power savings.
>
> Ah! I see the point now, very clever system for power saving.
> I'm going to check if it's resolutive,
> but it sounds good.
>
> >
> > > Btw, do I need to add a board using it, or can I add only Mali node
> > > to sun7i-a20.dtsi(plus other little patches)?
> >
> > You can add it to the DTSI without a board using it (and actually,
> > nothing should be in the board DTS, everything in the DT for the Mali
> > applies to all boards).
>
> Sure. So I would also add the patch you've addressed me:
> http://code.bulix.org/1kitrq-268936?raw
> as a commit. Can I submit it in patchset to complete the whole job?
I already sent that patch quite some time ago, I'll just apply it. You
can send the DT patch :)
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com
Hi,
Il 02/02/2018 14:35, Maxime Ripard ha scritto:
> On Fri, Feb 02, 2018 at 11:57:20AM +0100, Giulio Benetti wrote:
>> Il 02/02/2018 11:53, Maxime Ripard ha scritto:
>>> Hi,
>>>
>>> On Thu, Feb 01, 2018 at 05:17:11PM +0100, Giulio Benetti wrote:
>>>>>>> What kernel version did you use?
>>>>>>
>>>>>> Latest mainline.
>>>>>
>>>>> I guess this patch could fix it:
>>>>> http://code.bulix.org/1kitrq-268936?raw
>>>>
>>>> This should prevent from modifying parent clock. But my problem was
>>>> different.
>>>>
>>>> On A20, gpu_clk can have different PLL, not I've found out the way
>>>> to choose right one with assigned-parent-clocks.
>>>>
>>>> I have patchset ready for adding A20 mali node, but I need some more
>>>> time to complete with OPP, then I will submit entire patchset.
>>>>
>>>> Now it works correctly, using right pll(dedicated PLL8), setting
>>>> right frequency.
>>>
>>> The point is that we really don't care about which PLL is actually
>>> being used, as long as the rate is correct and we don't break anything
>>> else. If the GPU rate is accessible through one of the other PLL, it
>>> makes even more sense to not use the GPU PLL and keep it disabled,
>>> since it will result in some power savings.
>>
>> Ah! I see the point now, very clever system for power saving.
>> I'm going to check if it's resolutive,
>> but it sounds good.
>>
>>>
>>>> Btw, do I need to add a board using it, or can I add only Mali node
>>>> to sun7i-a20.dtsi(plus other little patches)?
>>>
>>> You can add it to the DTSI without a board using it (and actually,
>>> nothing should be in the board DTS, everything in the DT for the Mali
>>> applies to all boards).
>>
>> Sure. So I would also add the patch you've addressed me:
>> http://code.bulix.org/1kitrq-268936?raw
>> as a commit. Can I submit it in patchset to complete the whole job?
>
> I already sent that patch quite some time ago, I'll just apply it. You
> can send the DT patch :)
Thanks. Sorry for my ignorance, but where are you applying patches?
Because I've tried to check sunxi-next and a lot of other Repo but I
can't find this and neither "Re: [PATCH] clk: sunxi-ng: ccu-sun4i-a10:
Fix mali changing dclk frequency"
>
> Maxime
>
--
Giulio Benetti
R&D Manager &
Advanced Research
MICRONOVA SRL
Sede: Via A. Niedda 3 - 35010 Vigonza (PD)
Tel. 049/8931563 - Fax 049/8931346
Cod.Fiscale - P.IVA 02663420285
Capitale Sociale ? 26.000 i.v.
Iscritta al Reg. Imprese di Padova N. 02663420285
Numero R.E.A. 258642
On Fri, Feb 02, 2018 at 04:38:13PM +0100, Giulio Benetti wrote:
> Hi,
>
> Il 02/02/2018 14:35, Maxime Ripard ha scritto:
> > On Fri, Feb 02, 2018 at 11:57:20AM +0100, Giulio Benetti wrote:
> > > Il 02/02/2018 11:53, Maxime Ripard ha scritto:
> > > > Hi,
> > > >
> > > > On Thu, Feb 01, 2018 at 05:17:11PM +0100, Giulio Benetti wrote:
> > > > > > > > What kernel version did you use?
> > > > > > >
> > > > > > > Latest mainline.
> > > > > >
> > > > > > I guess this patch could fix it:
> > > > > > http://code.bulix.org/1kitrq-268936?raw
> > > > >
> > > > > This should prevent from modifying parent clock. But my problem was
> > > > > different.
> > > > >
> > > > > On A20, gpu_clk can have different PLL, not I've found out the way
> > > > > to choose right one with assigned-parent-clocks.
> > > > >
> > > > > I have patchset ready for adding A20 mali node, but I need some more
> > > > > time to complete with OPP, then I will submit entire patchset.
> > > > >
> > > > > Now it works correctly, using right pll(dedicated PLL8), setting
> > > > > right frequency.
> > > >
> > > > The point is that we really don't care about which PLL is actually
> > > > being used, as long as the rate is correct and we don't break anything
> > > > else. If the GPU rate is accessible through one of the other PLL, it
> > > > makes even more sense to not use the GPU PLL and keep it disabled,
> > > > since it will result in some power savings.
> > >
> > > Ah! I see the point now, very clever system for power saving.
> > > I'm going to check if it's resolutive,
> > > but it sounds good.
> > >
> > > >
> > > > > Btw, do I need to add a board using it, or can I add only Mali node
> > > > > to sun7i-a20.dtsi(plus other little patches)?
> > > >
> > > > You can add it to the DTSI without a board using it (and actually,
> > > > nothing should be in the board DTS, everything in the DT for the Mali
> > > > applies to all boards).
> > >
> > > Sure. So I would also add the patch you've addressed me:
> > > http://code.bulix.org/1kitrq-268936?raw
> > > as a commit. Can I submit it in patchset to complete the whole job?
> >
> > I already sent that patch quite some time ago, I'll just apply it. You
> > can send the DT patch :)
>
> Thanks. Sorry for my ignorance, but where are you applying patches?
> Because I've tried to check sunxi-next and a lot of other Repo but I can't
> find this and neither "Re: [PATCH] clk: sunxi-ng: ccu-sun4i-a10: Fix mali
> changing dclk frequency"
Usually, in the git tree listed in MAINTAINERS :)
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com
Hi,
Il 02/02/2018 16:52, Maxime Ripard ha scritto:
> On Fri, Feb 02, 2018 at 04:38:13PM +0100, Giulio Benetti wrote:
>> Hi,
>>
>> Il 02/02/2018 14:35, Maxime Ripard ha scritto:
>>> On Fri, Feb 02, 2018 at 11:57:20AM +0100, Giulio Benetti wrote:
>>>> Il 02/02/2018 11:53, Maxime Ripard ha scritto:
>>>>> Hi,
>>>>>
>>>>> On Thu, Feb 01, 2018 at 05:17:11PM +0100, Giulio Benetti wrote:
>>>>>>>>> What kernel version did you use?
>>>>>>>>
>>>>>>>> Latest mainline.
>>>>>>>
>>>>>>> I guess this patch could fix it:
>>>>>>> http://code.bulix.org/1kitrq-268936?raw
>>>>>>
>>>>>> This should prevent from modifying parent clock. But my problem was
>>>>>> different.
>>>>>>
>>>>>> On A20, gpu_clk can have different PLL, not I've found out the way
>>>>>> to choose right one with assigned-parent-clocks.
>>>>>>
>>>>>> I have patchset ready for adding A20 mali node, but I need some more
>>>>>> time to complete with OPP, then I will submit entire patchset.
>>>>>>
>>>>>> Now it works correctly, using right pll(dedicated PLL8), setting
>>>>>> right frequency.
>>>>>
>>>>> The point is that we really don't care about which PLL is actually
>>>>> being used, as long as the rate is correct and we don't break anything
>>>>> else. If the GPU rate is accessible through one of the other PLL, it
>>>>> makes even more sense to not use the GPU PLL and keep it disabled,
>>>>> since it will result in some power savings.
>>>>
>>>> Ah! I see the point now, very clever system for power saving.
>>>> I'm going to check if it's resolutive,
>>>> but it sounds good.
>>>>
>>>>>
>>>>>> Btw, do I need to add a board using it, or can I add only Mali node
>>>>>> to sun7i-a20.dtsi(plus other little patches)?
>>>>>
>>>>> You can add it to the DTSI without a board using it (and actually,
>>>>> nothing should be in the board DTS, everything in the DT for the Mali
>>>>> applies to all boards).
>>>>
>>>> Sure. So I would also add the patch you've addressed me:
>>>> http://code.bulix.org/1kitrq-268936?raw
>>>> as a commit. Can I submit it in patchset to complete the whole job?
>>>
>>> I already sent that patch quite some time ago, I'll just apply it. You
>>> can send the DT patch :)
>>
>> Thanks. Sorry for my ignorance, but where are you applying patches?
>> Because I've tried to check sunxi-next and a lot of other Repo but I can't
>> find this and neither "Re: [PATCH] clk: sunxi-ng: ccu-sun4i-a10: Fix mali
>> changing dclk frequency"
>
> Usually, in the git tree listed in MAINTAINERS :)
Please don't laugh at me! :)
I've tried to check for your patch(drivers/gpu/drm/sun4i/sun4i_tcon.c) on:
https://cgit.freedesktop.org/drm/drm-misc/
according to MAINTAINERS file and nothing found.
For the other one(arch/arm/boot/dts/sun7i-a20.dtsi), I've checked
on:
https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git/
https://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm.git/
https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/
Nothing neither here!
In MAINTANERS file there's no arch/arm/boot/dts/sun* association.
I don't know where else to look, I'm going nut!
And for sure I'm looking idiot,
this is why I've prepended "Please don't laugh at me!" :))
Help!
>
> Maxime
>
--
Giulio Benetti
R&D Manager &
Advanced Research
MICRONOVA SRL
Sede: Via A. Niedda 3 - 35010 Vigonza (PD)
Tel. 049/8931563 - Fax 049/8931346
Cod.Fiscale - P.IVA 02663420285
Capitale Sociale ? 26.000 i.v.
Iscritta al Reg. Imprese di Padova N. 02663420285
Numero R.E.A. 258642
On Fri, Feb 02, 2018 at 06:21:18PM +0100, Giulio Benetti wrote:
> Hi,
>
> Il 02/02/2018 16:52, Maxime Ripard ha scritto:
> > On Fri, Feb 02, 2018 at 04:38:13PM +0100, Giulio Benetti wrote:
> > > Hi,
> > >
> > > Il 02/02/2018 14:35, Maxime Ripard ha scritto:
> > > > On Fri, Feb 02, 2018 at 11:57:20AM +0100, Giulio Benetti wrote:
> > > > > Il 02/02/2018 11:53, Maxime Ripard ha scritto:
> > > > > > Hi,
> > > > > >
> > > > > > On Thu, Feb 01, 2018 at 05:17:11PM +0100, Giulio Benetti wrote:
> > > > > > > > > > What kernel version did you use?
> > > > > > > > >
> > > > > > > > > Latest mainline.
> > > > > > > >
> > > > > > > > I guess this patch could fix it:
> > > > > > > > http://code.bulix.org/1kitrq-268936?raw
> > > > > > >
> > > > > > > This should prevent from modifying parent clock. But my problem was
> > > > > > > different.
> > > > > > >
> > > > > > > On A20, gpu_clk can have different PLL, not I've found out the way
> > > > > > > to choose right one with assigned-parent-clocks.
> > > > > > >
> > > > > > > I have patchset ready for adding A20 mali node, but I need some more
> > > > > > > time to complete with OPP, then I will submit entire patchset.
> > > > > > >
> > > > > > > Now it works correctly, using right pll(dedicated PLL8), setting
> > > > > > > right frequency.
> > > > > >
> > > > > > The point is that we really don't care about which PLL is actually
> > > > > > being used, as long as the rate is correct and we don't break anything
> > > > > > else. If the GPU rate is accessible through one of the other PLL, it
> > > > > > makes even more sense to not use the GPU PLL and keep it disabled,
> > > > > > since it will result in some power savings.
> > > > >
> > > > > Ah! I see the point now, very clever system for power saving.
> > > > > I'm going to check if it's resolutive,
> > > > > but it sounds good.
> > > > >
> > > > > >
> > > > > > > Btw, do I need to add a board using it, or can I add only Mali node
> > > > > > > to sun7i-a20.dtsi(plus other little patches)?
> > > > > >
> > > > > > You can add it to the DTSI without a board using it (and actually,
> > > > > > nothing should be in the board DTS, everything in the DT for the Mali
> > > > > > applies to all boards).
> > > > >
> > > > > Sure. So I would also add the patch you've addressed me:
> > > > > http://code.bulix.org/1kitrq-268936?raw
> > > > > as a commit. Can I submit it in patchset to complete the whole job?
> > > >
> > > > I already sent that patch quite some time ago, I'll just apply it. You
> > > > can send the DT patch :)
> > >
> > > Thanks. Sorry for my ignorance, but where are you applying patches?
> > > Because I've tried to check sunxi-next and a lot of other Repo but I can't
> > > find this and neither "Re: [PATCH] clk: sunxi-ng: ccu-sun4i-a10: Fix mali
> > > changing dclk frequency"
> >
> > Usually, in the git tree listed in MAINTAINERS :)
>
> Please don't laugh at me! :)
>
> I've tried to check for your patch(drivers/gpu/drm/sun4i/sun4i_tcon.c) on:
> https://cgit.freedesktop.org/drm/drm-misc/
> according to MAINTAINERS file and nothing found.
I haven't applied that one yet, so it's not suprising :)
> For the other one(arch/arm/boot/dts/sun7i-a20.dtsi), I've checked
> on:
> https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git/
> https://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm.git/
> https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/
>
> Nothing neither here!
>
> In MAINTANERS file there's no arch/arm/boot/dts/sun* association.
I forgot to push that one:
https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git/log/?h=sunxi/dt-for-4.17
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com
Il 02/02/2018 22:59, Maxime Ripard ha scritto:
> On Fri, Feb 02, 2018 at 06:21:18PM +0100, Giulio Benetti wrote:
>> Hi,
>>
>> Il 02/02/2018 16:52, Maxime Ripard ha scritto:
>>> On Fri, Feb 02, 2018 at 04:38:13PM +0100, Giulio Benetti wrote:
>>>> Hi,
>>>>
>>>> Il 02/02/2018 14:35, Maxime Ripard ha scritto:
>>>>> On Fri, Feb 02, 2018 at 11:57:20AM +0100, Giulio Benetti wrote:
>>>>>> Il 02/02/2018 11:53, Maxime Ripard ha scritto:
>>>>>>> Hi,
>>>>>>>
>>>>>>> On Thu, Feb 01, 2018 at 05:17:11PM +0100, Giulio Benetti wrote:
>>>>>>>>>>> What kernel version did you use?
>>>>>>>>>>
>>>>>>>>>> Latest mainline.
>>>>>>>>>
>>>>>>>>> I guess this patch could fix it:
>>>>>>>>> http://code.bulix.org/1kitrq-268936?raw
>>>>>>>>
>>>>>>>> This should prevent from modifying parent clock. But my problem was
>>>>>>>> different.
>>>>>>>>
>>>>>>>> On A20, gpu_clk can have different PLL, not I've found out the way
>>>>>>>> to choose right one with assigned-parent-clocks.
>>>>>>>>
>>>>>>>> I have patchset ready for adding A20 mali node, but I need some more
>>>>>>>> time to complete with OPP, then I will submit entire patchset.
>>>>>>>>
>>>>>>>> Now it works correctly, using right pll(dedicated PLL8), setting
>>>>>>>> right frequency.
>>>>>>>
>>>>>>> The point is that we really don't care about which PLL is actually
>>>>>>> being used, as long as the rate is correct and we don't break anything
>>>>>>> else. If the GPU rate is accessible through one of the other PLL, it
>>>>>>> makes even more sense to not use the GPU PLL and keep it disabled,
>>>>>>> since it will result in some power savings.
>>>>>>
>>>>>> Ah! I see the point now, very clever system for power saving.
>>>>>> I'm going to check if it's resolutive,
>>>>>> but it sounds good.
>>>>>>
>>>>>>>
>>>>>>>> Btw, do I need to add a board using it, or can I add only Mali node
>>>>>>>> to sun7i-a20.dtsi(plus other little patches)?
>>>>>>>
>>>>>>> You can add it to the DTSI without a board using it (and actually,
>>>>>>> nothing should be in the board DTS, everything in the DT for the Mali
>>>>>>> applies to all boards).
>>>>>>
>>>>>> Sure. So I would also add the patch you've addressed me:
>>>>>> http://code.bulix.org/1kitrq-268936?raw
>>>>>> as a commit. Can I submit it in patchset to complete the whole job?
>>>>>
>>>>> I already sent that patch quite some time ago, I'll just apply it. You
>>>>> can send the DT patch :)
>>>>
>>>> Thanks. Sorry for my ignorance, but where are you applying patches?
>>>> Because I've tried to check sunxi-next and a lot of other Repo but I can't
>>>> find this and neither "Re: [PATCH] clk: sunxi-ng: ccu-sun4i-a10: Fix mali
>>>> changing dclk frequency"
>>>
>>> Usually, in the git tree listed in MAINTAINERS :)
>>
>> Please don't laugh at me! :)
>>
>> I've tried to check for your patch(drivers/gpu/drm/sun4i/sun4i_tcon.c) on:
>> https://cgit.freedesktop.org/drm/drm-misc/
>> according to MAINTAINERS file and nothing found.
>
> I haven't applied that one yet, so it's not suprising :)
Ah ok!
>
>> For the other one(arch/arm/boot/dts/sun7i-a20.dtsi), I've checked
>> on:
>> https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git/
>> https://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm.git/
>> https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/
>>
>> Nothing neither here!
>>
>> In MAINTANERS file there's no arch/arm/boot/dts/sun* association.
>
> I forgot to push that one:
> https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git/log/?h=sunxi/dt-for-4.17
Thank god! I haven't gone nut!! :))
I think I've understood how it works this part.
Thanks!!!
Thanks
>
> Maxime
>
--
Giulio Benetti
R&D Manager &
Advanced Research
MICRONOVA SRL
Sede: Via A. Niedda 3 - 35010 Vigonza (PD)
Tel. 049/8931563 - Fax 049/8931346
Cod.Fiscale - P.IVA 02663420285
Capitale Sociale ? 26.000 i.v.
Iscritta al Reg. Imprese di Padova N. 02663420285
Numero R.E.A. 258642