From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754052AbeBURFe (ORCPT ); Wed, 21 Feb 2018 12:05:34 -0500 Received: from vern.gendns.com ([206.190.152.46]:55067 "EHLO vern.gendns.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752394AbeBURFa (ORCPT ); Wed, 21 Feb 2018 12:05:30 -0500 Subject: =?UTF-8?Q?Re:_[PATCH_v7_00/42]_ARM:_davinci:_convert_to_common_cloc?= =?UTF-8?Q?k_framework=e2=80=8b?= To: Bartosz Golaszewski Cc: linux-clk@vger.kernel.org, devicetree , Linux ARM , Michael Turquette , Stephen Boyd , Rob Herring , Mark Rutland , Sekhar Nori , Kevin Hilman , Bartosz Golaszewski , Adam Ford , Linux Kernel Mailing List References: <1519071723-31790-1-git-send-email-david@lechnology.com> <6142ab0d-85b1-84da-3a35-bdd8733bebd9@lechnology.com> From: David Lechner Message-ID: Date: Wed, 21 Feb 2018 11:05:41 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vern.gendns.com X-AntiAbuse: Original Domain - vger.kernel.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - lechnology.com X-Get-Message-Sender-Via: vern.gendns.com: authenticated_id: davidmain+lechnology.com/only user confirmed/virtual account not confirmed X-Authenticated-Sender: vern.gendns.com: davidmain@lechnology.com X-Source: X-Source-Args: X-Source-Dir: Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/21/2018 06:01 AM, Bartosz Golaszewski wrote: > 2018-02-20 19:39 GMT+01:00 David Lechner : >> On 02/20/2018 07:33 AM, Bartosz Golaszewski wrote: >>> >>> 2018-02-19 21:21 GMT+01:00 David Lechner : >>>> >>>> This series converts mach-davinci to use the common clock framework. >>>> >>>> >>> >>> Hi David, >>> >>> just some quick results from today's playing with v7. >>> >>> I started out with da850-lcdk with my standard rootfs over NFS. I was >>> not able to boot to console so far. The first problem is that mdio >>> fails to probe: >>> >>> libphy: Fixed MDIO Bus: probed >>> davinci_mdio 1e24000.mdio: davinci mdio revision 1.5, bus freq 2200000 >>> davinci_mdio 1e24000.mdio: no live phy, scanning all >>> davinci_mdio: probe of 1e24000.mdio failed with error -5> After some >>> digging I noticed that the supplied clock rate differs >>> between mainline (114000000Hz) vs common-clock-v7 (18000000). Since >>> we're not setting the rate in mdio, using LPSC_SET_RATE_PARENT would >>> not help like with lcdc. >> >> >> Can you post the output of this command so that I can see how your >> clocks are setup: >> >> cat /sys/kernel/debug/clk/clk_summary >> >> >>> >>> After that, the boot just hangs without ever getting to emac's probe. >> >> >> Using your workaround, can you run: >> >> cat /sys/kernel/debug/pm_genpd/pm_genpd_summary >> >> If you see: >> 1e27000.clock-controller: emac off-0 >> >> then genpd is not working like it is supposed to. You should see something >> like this for device that are working: >> 1e27000.clock-controller: uart2 on >> /devices/platform/soc@1c00000/1d0d000.serial active >> >> >>> >>> Once I set the emac clock to always enabled (a workaround that was >>> necessary with v6, but could be dropped with my first >>> genpd-in-a-separate-driver attempt), I'm getting a rather strange NULL >>> pointer dereference: >> >> >> I noticed this too when adding the power-domains property to some device >> tree nodes. This is part of the reason why I didn't add it everywhere. >> I wasn't able to figure out the cause of this yet. As a work around >> though, please try removing the power-domains property from the emac >> and mdio nodes and use your previous workaround of having an always >> enabled clock. >> >> > > When I use any of the workarounds I just keep getting more problems > (e.g. [1] from blk and pinctrl). I only had a couple hours today to > play with it but it seems to me we have some memory corruption > somewhere. I'll check the initialization order of all the frameworks > involved tomorrow. > > Best regards, > Bartosz > > [1] https://pastebin.com/75mkkuJL > I wonder if we need to delete all of the __init and __initconst attributes now that this has been converted to platform devices. From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Lechner Subject: =?UTF-8?Q?Re:_[PATCH_v7_00/42]_ARM:_davinci:_convert_to_common_cloc?= =?UTF-8?Q?k_framework=e2=80=8b?= Date: Wed, 21 Feb 2018 11:05:41 -0600 Message-ID: References: <1519071723-31790-1-git-send-email-david@lechnology.com> <6142ab0d-85b1-84da-3a35-bdd8733bebd9@lechnology.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Content-Language: en-US List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: Bartosz Golaszewski Cc: Mark Rutland , devicetree , Kevin Hilman , Sekhar Nori , Michael Turquette , Stephen Boyd , Linux Kernel Mailing List , Bartosz Golaszewski , Rob Herring , Adam Ford , linux-clk@vger.kernel.org, Linux ARM List-Id: devicetree@vger.kernel.org On 02/21/2018 06:01 AM, Bartosz Golaszewski wrote: > 2018-02-20 19:39 GMT+01:00 David Lechner : >> On 02/20/2018 07:33 AM, Bartosz Golaszewski wrote: >>> >>> 2018-02-19 21:21 GMT+01:00 David Lechner : >>>> >>>> This series converts mach-davinci to use the common clock framework. >>>> >>>> >>> >>> Hi David, >>> >>> just some quick results from today's playing with v7. >>> >>> I started out with da850-lcdk with my standard rootfs over NFS. I was >>> not able to boot to console so far. The first problem is that mdio >>> fails to probe: >>> >>> libphy: Fixed MDIO Bus: probed >>> davinci_mdio 1e24000.mdio: davinci mdio revision 1.5, bus freq 2200000 >>> davinci_mdio 1e24000.mdio: no live phy, scanning all >>> davinci_mdio: probe of 1e24000.mdio failed with error -5> After some >>> digging I noticed that the supplied clock rate differs >>> between mainline (114000000Hz) vs common-clock-v7 (18000000). Since >>> we're not setting the rate in mdio, using LPSC_SET_RATE_PARENT would >>> not help like with lcdc. >> >> >> Can you post the output of this command so that I can see how your >> clocks are setup: >> >> cat /sys/kernel/debug/clk/clk_summary >> >> >>> >>> After that, the boot just hangs without ever getting to emac's probe. >> >> >> Using your workaround, can you run: >> >> cat /sys/kernel/debug/pm_genpd/pm_genpd_summary >> >> If you see: >> 1e27000.clock-controller: emac off-0 >> >> then genpd is not working like it is supposed to. You should see something >> like this for device that are working: >> 1e27000.clock-controller: uart2 on >> /devices/platform/soc@1c00000/1d0d000.serial active >> >> >>> >>> Once I set the emac clock to always enabled (a workaround that was >>> necessary with v6, but could be dropped with my first >>> genpd-in-a-separate-driver attempt), I'm getting a rather strange NULL >>> pointer dereference: >> >> >> I noticed this too when adding the power-domains property to some device >> tree nodes. This is part of the reason why I didn't add it everywhere. >> I wasn't able to figure out the cause of this yet. As a work around >> though, please try removing the power-domains property from the emac >> and mdio nodes and use your previous workaround of having an always >> enabled clock. >> >> > > When I use any of the workarounds I just keep getting more problems > (e.g. [1] from blk and pinctrl). I only had a couple hours today to > play with it but it seems to me we have some memory corruption > somewhere. I'll check the initialization order of all the frameworks > involved tomorrow. > > Best regards, > Bartosz > > [1] https://pastebin.com/75mkkuJL > I wonder if we need to delete all of the __init and __initconst attributes now that this has been converted to platform devices. From mboxrd@z Thu Jan 1 00:00:00 1970 From: david@lechnology.com (David Lechner) Date: Wed, 21 Feb 2018 11:05:41 -0600 Subject: =?UTF-8?Q?Re:_[PATCH_v7_00/42]_ARM:_davinci:_convert_to_common_cloc?= =?UTF-8?Q?k_framework=e2=80=8b?= In-Reply-To: References: <1519071723-31790-1-git-send-email-david@lechnology.com> <6142ab0d-85b1-84da-3a35-bdd8733bebd9@lechnology.com> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 02/21/2018 06:01 AM, Bartosz Golaszewski wrote: > 2018-02-20 19:39 GMT+01:00 David Lechner : >> On 02/20/2018 07:33 AM, Bartosz Golaszewski wrote: >>> >>> 2018-02-19 21:21 GMT+01:00 David Lechner : >>>> >>>> This series converts mach-davinci to use the common clock framework. >>>> >>>> >>> >>> Hi David, >>> >>> just some quick results from today's playing with v7. >>> >>> I started out with da850-lcdk with my standard rootfs over NFS. I was >>> not able to boot to console so far. The first problem is that mdio >>> fails to probe: >>> >>> libphy: Fixed MDIO Bus: probed >>> davinci_mdio 1e24000.mdio: davinci mdio revision 1.5, bus freq 2200000 >>> davinci_mdio 1e24000.mdio: no live phy, scanning all >>> davinci_mdio: probe of 1e24000.mdio failed with error -5> After some >>> digging I noticed that the supplied clock rate differs >>> between mainline (114000000Hz) vs common-clock-v7 (18000000). Since >>> we're not setting the rate in mdio, using LPSC_SET_RATE_PARENT would >>> not help like with lcdc. >> >> >> Can you post the output of this command so that I can see how your >> clocks are setup: >> >> cat /sys/kernel/debug/clk/clk_summary >> >> >>> >>> After that, the boot just hangs without ever getting to emac's probe. >> >> >> Using your workaround, can you run: >> >> cat /sys/kernel/debug/pm_genpd/pm_genpd_summary >> >> If you see: >> 1e27000.clock-controller: emac off-0 >> >> then genpd is not working like it is supposed to. You should see something >> like this for device that are working: >> 1e27000.clock-controller: uart2 on >> /devices/platform/soc at 1c00000/1d0d000.serial active >> >> >>> >>> Once I set the emac clock to always enabled (a workaround that was >>> necessary with v6, but could be dropped with my first >>> genpd-in-a-separate-driver attempt), I'm getting a rather strange NULL >>> pointer dereference: >> >> >> I noticed this too when adding the power-domains property to some device >> tree nodes. This is part of the reason why I didn't add it everywhere. >> I wasn't able to figure out the cause of this yet. As a work around >> though, please try removing the power-domains property from the emac >> and mdio nodes and use your previous workaround of having an always >> enabled clock. >> >> > > When I use any of the workarounds I just keep getting more problems > (e.g. [1] from blk and pinctrl). I only had a couple hours today to > play with it but it seems to me we have some memory corruption > somewhere. I'll check the initialization order of all the frameworks > involved tomorrow. > > Best regards, > Bartosz > > [1] https://pastebin.com/75mkkuJL > I wonder if we need to delete all of the __init and __initconst attributes now that this has been converted to platform devices.