From: Abhishek Sahu <absahu@codeaurora.org>
To: Stephen Boyd <sboyd@codeaurora.org>
Cc: mturquette@baylibre.com, andy.gross@linaro.org,
david.brown@linaro.org, rnayak@codeaurora.org,
linux-arm-msm@vger.kernel.org, linux-soc@vger.kernel.org,
linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC 01/12] clk: qcom: support for register offsets from rcg2 clock node
Date: Sun, 30 Jul 2017 18:27:35 +0530 [thread overview]
Message-ID: <3a7dde1470c65b5c6fa066581c46589c@codeaurora.org> (raw)
In-Reply-To: <20170728175522.GF2146@codeaurora.org>
On 2017-07-28 23:25, Stephen Boyd wrote:
> On 07/28, Abhishek Sahu wrote:
>> On 2017-07-28 00:14, Stephen Boyd wrote:
>> >
>> >It looks like the two UBI clks that messed this up don't have an MN
>> >counter, so instead of doing this maddness, just add a flag like
>>
>> I have given example for one of the RCG. IPQ8074 have more clocks for
>> which the offsets are not continuous and some of the clocks have
>> mn counter also (NSS Crypto and PCIE AUX)
>>
>> GCC_NSS_UBI0_CMD_RCGR 0x1868100
>> GCC_NSS_UBI0_CFG_RCGR 0x1868108
>> GCC_NSS_UBI1_CMD_RCGR 0x1868120
>> GCC_NSS_UBI1_CFG_RCGR 0x1868128
>>
>> GCC_NSS_CRYPTO_CMD_RCGR 0x1868140
>> GCC_NSS_CRYPTO_CFG_RCGR 0x1868148
>> GCC_NSS_CRYPTO_M 0x186814C
>> GCC_NSS_CRYPTO_N 0x1868150
>> GCC_NSS_CRYPTO_D 0x1868154
>>
>> GCC_PCIE0_AUX_CMD_RCGR 0x1875020
>> GCC_PCIE0_AUX_CFG_RCGR 0x1875028
>> GCC_PCIE0_AUX_M 0x187502C
>> GCC_PCIE0_AUX_N 0x1875030
>> GCC_PCIE0_AUX_D 0x1875034
>>
>> GCC_PCIE0_AXI_CMD_RCGR 0x1875050
>> GCC_PCIE0_AXI_CFG_RCGR 0x1875058
>>
>> Similarly for PCIE1 also.
>
> Wow. This is awful. Please make sure this never happens again. I
> will go yell at someone as well.
>
Yes. We also yelled badly at HW team for this and raised
the HW bug before tapeout itself but they didn't fix by
saying that this change will be risky and can have side
effects.
>>
>> >m_is_cfg and then make a rcg2_crmd() function that checks this flag and
>> >returns cmd_rcg + CFG_REG or cmd_rgcr + M_REG depending on the flag. We
>>
>> The original idea was to make this generic so in future for all the
>> cases
>> it will work. If we can make function and since some clocks have MN
>> counter, so could we make function for CMD reg itself instead of
>> CFG reg.
>
> I understand the idea. We don't want it to happen again in the
> future though, so let's not make it easy to support in the future
> with some register map thing. Hardware people should follow the
> rules and stop messing with the register layout!
>
>> For this, pass cmd_rcgr as + 4 from GCC driver and when this flag
>> is set
>> then do minus 4 for all CMD_REG
>>
>
> Ok. That's a good solution.
>
> Just to be clear, let's have a flag like 'cmd_reg_is_wrong' (feel
> free to think of a better name) and then have the places where we
> access CMD_REG subtract that by 4, again with some special
> macro/function, and then have the IPQ gcc driver specify the
> cmd_rcgr as the real register + 4. Then the other hardcoded
> offsets can all be the same and the few places that we access
> CMD_REG we can subtract 4 to get the true location. And put all
> that under an ifdef in some macro, so that we don't care about
> this problem at all if we're not compiling this broken hardware
> driver.
Sure. Same plan here and I will do the same.
next prev parent reply other threads:[~2017-07-30 12:57 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-27 11:10 [RFC 00/12] Misc patches for QCOM clocks Abhishek Sahu
2017-07-27 11:10 ` [RFC 01/12] clk: qcom: support for register offsets from rcg2 clock node Abhishek Sahu
2017-07-27 18:44 ` Stephen Boyd
2017-07-28 9:42 ` Abhishek Sahu
2017-07-28 17:55 ` Stephen Boyd
2017-07-30 12:57 ` Abhishek Sahu [this message]
2017-07-27 11:10 ` [RFC 02/12] clk: qcom: flag for 64 bit CONFIG_CTL Abhishek Sahu
2017-07-28 18:33 ` Stephen Boyd
2017-07-30 13:04 ` Abhishek Sahu
2017-08-01 21:17 ` Stephen Boyd
2017-07-27 11:10 ` [RFC 03/12] clk: qcom: support for alpha mode configuration Abhishek Sahu
2017-07-27 11:10 ` [RFC 04/12] clk: qcom: use offset from alpha pll node Abhishek Sahu
2017-07-30 13:26 ` Abhishek Sahu
2017-07-27 11:10 ` [RFC 05/12] clk: qcom: fix 16 bit alpha support calculation Abhishek Sahu
2017-07-27 11:10 ` [RFC 06/12] Clk: qcom: support for dynamic updating the PLL Abhishek Sahu
2017-07-28 18:34 ` Stephen Boyd
2017-07-30 13:57 ` Abhishek Sahu
2017-08-01 21:12 ` Stephen Boyd
2017-08-02 13:50 ` Abhishek Sahu
2017-07-27 11:10 ` [RFC 07/12] clk: qcom: add flag for VCO operation Abhishek Sahu
2017-07-27 11:10 ` [RFC 08/12] clk: qcom: support for Huayra PLL Abhishek Sahu
2017-07-27 11:10 ` [RFC 09/12] clk: qcom: support for Brammo PLL Abhishek Sahu
2017-07-27 11:10 ` [RFC 10/12] clk: qcom: add read-only divider operations Abhishek Sahu
2017-07-27 11:10 ` [RFC 11/12] clk: qcom: add read-only alpha pll post " Abhishek Sahu
2017-07-27 11:10 ` [RFC 12/12] clk: qcom: add parent map for regmap mux Abhishek Sahu
2017-07-27 18:39 ` [RFC 00/12] Misc patches for QCOM clocks Stephen Boyd
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3a7dde1470c65b5c6fa066581c46589c@codeaurora.org \
--to=absahu@codeaurora.org \
--cc=andy.gross@linaro.org \
--cc=david.brown@linaro.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-soc@vger.kernel.org \
--cc=mturquette@baylibre.com \
--cc=rnayak@codeaurora.org \
--cc=sboyd@codeaurora.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).