| Message ID | 1447108254-19864-1-git-send-email-sboyd@codeaurora.org (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Delegated to: | Andy Gross |
| Headers | show |
Stephen Boyd <sboyd@codeaurora.org> writes: > All these clock controllers are little endian devices, but so far > we've been relying on the regmap mmio bus handling this for us > without explicitly stating that fact. After commit 4a98da2164cf > (regmap-mmio: Use native endianness for read/write, 2015-10-29), > the regmap mmio bus will read/write with the __raw_*() IO > accessors, instead of using the readl/writel() APIs that do > proper byte swapping for little endian devices. > > So if we're running on a big endian processor and haven't > specified the endianness explicitly in the regmap config or in > DT, we're going to switch from doing little endian byte swapping > to big endian accesses without byte swapping, leading to some > confusing results. On my apq8074 dragonboard, this causes the > device to fail to boot as we access the clock controller with > big endian IO accesses even though the device is little endian. > > Specify the endianness explicitly so that the regmap core > properly byte swaps the accesses for us. > > Reported-by: Kevin Hilman <khilman@linaro.org> > Cc: Simon Arlott <simon@fire.lp0.eu> > Cc: Mark Brown <broonie@kernel.org> > Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Tested-by: Kevin Hilman <khilman@linaro.org> Verified that this patch on top of next-20151118 gets my 2 8x94 boards booting again with big-endian kernel. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 9 November 2015 at 14:30, Stephen Boyd <sboyd@codeaurora.org> wrote: > All these clock controllers are little endian devices, but so far > we've been relying on the regmap mmio bus handling this for us > without explicitly stating that fact. After commit 4a98da2164cf > (regmap-mmio: Use native endianness for read/write, 2015-10-29), > the regmap mmio bus will read/write with the __raw_*() IO > accessors, instead of using the readl/writel() APIs that do > proper byte swapping for little endian devices. > > So if we're running on a big endian processor and haven't > specified the endianness explicitly in the regmap config or in > DT, we're going to switch from doing little endian byte swapping > to big endian accesses without byte swapping, leading to some > confusing results. On my apq8074 dragonboard, this causes the > device to fail to boot as we access the clock controller with > big endian IO accesses even though the device is little endian. > > Specify the endianness explicitly so that the regmap core > properly byte swaps the accesses for us. > > Reported-by: Kevin Hilman <khilman@linaro.org> > Cc: Simon Arlott <simon@fire.lp0.eu> > Cc: Mark Brown <broonie@kernel.org> > Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Tested-by: Tyler Baker <tyler.baker@linaro.org> The kernelci.org bot also reported boot failures[1] for the apq8016-sbc in next-20151120 with CONFIG_CPU_BIG_ENDIAN=y enabled. I've bisected the failure down to the same offending remap-mmio patch listed above. I've confirmed this patch applied on top of next-20151120 fixes the boot issue for the apq8016-sbc as well. Any updates or comments on this patch? I'd like to see this fix in linux-next, as it has been broken for over a week and could be masking new issues. Cheers, Tyler [1] http://kernelci.org/boot/all/job/next/kernel/next-20151120/ -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 11/20, Tyler Baker wrote: > On 9 November 2015 at 14:30, Stephen Boyd <sboyd@codeaurora.org> wrote: > > All these clock controllers are little endian devices, but so far > > we've been relying on the regmap mmio bus handling this for us > > without explicitly stating that fact. After commit 4a98da2164cf > > (regmap-mmio: Use native endianness for read/write, 2015-10-29), > > the regmap mmio bus will read/write with the __raw_*() IO > > accessors, instead of using the readl/writel() APIs that do > > proper byte swapping for little endian devices. > > > > So if we're running on a big endian processor and haven't > > specified the endianness explicitly in the regmap config or in > > DT, we're going to switch from doing little endian byte swapping > > to big endian accesses without byte swapping, leading to some > > confusing results. On my apq8074 dragonboard, this causes the > > device to fail to boot as we access the clock controller with > > big endian IO accesses even though the device is little endian. > > > > Specify the endianness explicitly so that the regmap core > > properly byte swaps the accesses for us. > > > > Reported-by: Kevin Hilman <khilman@linaro.org> > > Cc: Simon Arlott <simon@fire.lp0.eu> > > Cc: Mark Brown <broonie@kernel.org> > > Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> > > Tested-by: Tyler Baker <tyler.baker@linaro.org> > > The kernelci.org bot also reported boot failures[1] for the > apq8016-sbc in next-20151120 with CONFIG_CPU_BIG_ENDIAN=y enabled. > I've bisected the failure down to the same offending remap-mmio patch > listed above. I've confirmed this patch applied on top of > next-20151120 fixes the boot issue for the apq8016-sbc as well. > > Any updates or comments on this patch? I'd like to see this fix in > linux-next, as it has been broken for over a week and could be masking > new issues. Yeah I've been lagging on applying patches. I need to send more patches for other regmap-mmio users too. I'll cook those up right now and send them off.
On 11/09, Stephen Boyd wrote: > All these clock controllers are little endian devices, but so far > we've been relying on the regmap mmio bus handling this for us > without explicitly stating that fact. After commit 4a98da2164cf > (regmap-mmio: Use native endianness for read/write, 2015-10-29), > the regmap mmio bus will read/write with the __raw_*() IO > accessors, instead of using the readl/writel() APIs that do > proper byte swapping for little endian devices. > > So if we're running on a big endian processor and haven't > specified the endianness explicitly in the regmap config or in > DT, we're going to switch from doing little endian byte swapping > to big endian accesses without byte swapping, leading to some > confusing results. On my apq8074 dragonboard, this causes the > device to fail to boot as we access the clock controller with > big endian IO accesses even though the device is little endian. > > Specify the endianness explicitly so that the regmap core > properly byte swaps the accesses for us. > > Reported-by: Kevin Hilman <khilman@linaro.org> > Cc: Simon Arlott <simon@fire.lp0.eu> > Cc: Mark Brown <broonie@kernel.org> > Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> > --- Applied to clk-next
diff --git a/drivers/clk/qcom/gcc-apq8084.c b/drivers/clk/qcom/gcc-apq8084.c index 1567c3a79534..c296f61cf216 100644 --- a/drivers/clk/qcom/gcc-apq8084.c +++ b/drivers/clk/qcom/gcc-apq8084.c @@ -3587,6 +3587,7 @@ static const struct regmap_config gcc_apq8084_regmap_config = { .val_bits = 32, .max_register = 0x1fc0, .fast_io = true, + .val_format_endian = REGMAP_ENDIAN_LITTLE, }; static const struct qcom_cc_desc gcc_apq8084_desc = { diff --git a/drivers/clk/qcom/gcc-ipq806x.c b/drivers/clk/qcom/gcc-ipq806x.c index c43d865cfc59..65c7a02a57ed 100644 --- a/drivers/clk/qcom/gcc-ipq806x.c +++ b/drivers/clk/qcom/gcc-ipq806x.c @@ -3002,6 +3002,7 @@ static const struct regmap_config gcc_ipq806x_regmap_config = { .val_bits = 32, .max_register = 0x3e40, .fast_io = true, + .val_format_endian = REGMAP_ENDIAN_LITTLE, }; static const struct qcom_cc_desc gcc_ipq806x_desc = { diff --git a/drivers/clk/qcom/gcc-msm8660.c b/drivers/clk/qcom/gcc-msm8660.c index f110bb5a1df3..7220163af68e 100644 --- a/drivers/clk/qcom/gcc-msm8660.c +++ b/drivers/clk/qcom/gcc-msm8660.c @@ -2702,6 +2702,7 @@ static const struct regmap_config gcc_msm8660_regmap_config = { .val_bits = 32, .max_register = 0x363c, .fast_io = true, + .val_format_endian = REGMAP_ENDIAN_LITTLE, }; static const struct qcom_cc_desc gcc_msm8660_desc = { diff --git a/drivers/clk/qcom/gcc-msm8916.c b/drivers/clk/qcom/gcc-msm8916.c index d0a0313d6bef..998f773d9ad9 100644 --- a/drivers/clk/qcom/gcc-msm8916.c +++ b/drivers/clk/qcom/gcc-msm8916.c @@ -3336,6 +3336,7 @@ static const struct regmap_config gcc_msm8916_regmap_config = { .val_bits = 32, .max_register = 0x80000, .fast_io = true, + .val_format_endian = REGMAP_ENDIAN_LITTLE, }; static const struct qcom_cc_desc gcc_msm8916_desc = { diff --git a/drivers/clk/qcom/gcc-msm8960.c b/drivers/clk/qcom/gcc-msm8960.c index 66c18bc97857..620db1b61cd5 100644 --- a/drivers/clk/qcom/gcc-msm8960.c +++ b/drivers/clk/qcom/gcc-msm8960.c @@ -3468,6 +3468,7 @@ static const struct regmap_config gcc_msm8960_regmap_config = { .val_bits = 32, .max_register = 0x3660, .fast_io = true, + .val_format_endian = REGMAP_ENDIAN_LITTLE, }; static const struct regmap_config gcc_apq8064_regmap_config = { @@ -3476,6 +3477,7 @@ static const struct regmap_config gcc_apq8064_regmap_config = { .val_bits = 32, .max_register = 0x3880, .fast_io = true, + .val_format_endian = REGMAP_ENDIAN_LITTLE, }; static const struct qcom_cc_desc gcc_msm8960_desc = { diff --git a/drivers/clk/qcom/gcc-msm8974.c b/drivers/clk/qcom/gcc-msm8974.c index 28abb8f8f293..126a94401596 100644 --- a/drivers/clk/qcom/gcc-msm8974.c +++ b/drivers/clk/qcom/gcc-msm8974.c @@ -2680,6 +2680,7 @@ static const struct regmap_config gcc_msm8974_regmap_config = { .val_bits = 32, .max_register = 0x1fc0, .fast_io = true, + .val_format_endian = REGMAP_ENDIAN_LITTLE, }; static const struct qcom_cc_desc gcc_msm8974_desc = { diff --git a/drivers/clk/qcom/lcc-ipq806x.c b/drivers/clk/qcom/lcc-ipq806x.c index db3998e5e2d8..62e79fadd5f7 100644 --- a/drivers/clk/qcom/lcc-ipq806x.c +++ b/drivers/clk/qcom/lcc-ipq806x.c @@ -419,6 +419,7 @@ static const struct regmap_config lcc_ipq806x_regmap_config = { .val_bits = 32, .max_register = 0xfc, .fast_io = true, + .val_format_endian = REGMAP_ENDIAN_LITTLE, }; static const struct qcom_cc_desc lcc_ipq806x_desc = { diff --git a/drivers/clk/qcom/lcc-msm8960.c b/drivers/clk/qcom/lcc-msm8960.c index 4fcf9d1d233c..bf95bb0ea1b8 100644 --- a/drivers/clk/qcom/lcc-msm8960.c +++ b/drivers/clk/qcom/lcc-msm8960.c @@ -524,6 +524,7 @@ static const struct regmap_config lcc_msm8960_regmap_config = { .val_bits = 32, .max_register = 0xfc, .fast_io = true, + .val_format_endian = REGMAP_ENDIAN_LITTLE, }; static const struct qcom_cc_desc lcc_msm8960_desc = { diff --git a/drivers/clk/qcom/mmcc-apq8084.c b/drivers/clk/qcom/mmcc-apq8084.c index 30777f9f1a43..1e703fda8a0f 100644 --- a/drivers/clk/qcom/mmcc-apq8084.c +++ b/drivers/clk/qcom/mmcc-apq8084.c @@ -3368,6 +3368,7 @@ static const struct regmap_config mmcc_apq8084_regmap_config = { .val_bits = 32, .max_register = 0x5104, .fast_io = true, + .val_format_endian = REGMAP_ENDIAN_LITTLE, }; static const struct qcom_cc_desc mmcc_apq8084_desc = { diff --git a/drivers/clk/qcom/mmcc-msm8960.c b/drivers/clk/qcom/mmcc-msm8960.c index 00e36192a1de..d73a048d3b9d 100644 --- a/drivers/clk/qcom/mmcc-msm8960.c +++ b/drivers/clk/qcom/mmcc-msm8960.c @@ -3029,6 +3029,7 @@ static const struct regmap_config mmcc_msm8960_regmap_config = { .val_bits = 32, .max_register = 0x334, .fast_io = true, + .val_format_endian = REGMAP_ENDIAN_LITTLE, }; static const struct regmap_config mmcc_apq8064_regmap_config = { @@ -3037,6 +3038,7 @@ static const struct regmap_config mmcc_apq8064_regmap_config = { .val_bits = 32, .max_register = 0x350, .fast_io = true, + .val_format_endian = REGMAP_ENDIAN_LITTLE, }; static const struct qcom_cc_desc mmcc_msm8960_desc = { diff --git a/drivers/clk/qcom/mmcc-msm8974.c b/drivers/clk/qcom/mmcc-msm8974.c index 9d790bcadf25..bbe28ed93669 100644 --- a/drivers/clk/qcom/mmcc-msm8974.c +++ b/drivers/clk/qcom/mmcc-msm8974.c @@ -2594,6 +2594,7 @@ static const struct regmap_config mmcc_msm8974_regmap_config = { .val_bits = 32, .max_register = 0x5104, .fast_io = true, + .val_format_endian = REGMAP_ENDIAN_LITTLE, }; static const struct qcom_cc_desc mmcc_msm8974_desc = {
All these clock controllers are little endian devices, but so far we've been relying on the regmap mmio bus handling this for us without explicitly stating that fact. After commit 4a98da2164cf (regmap-mmio: Use native endianness for read/write, 2015-10-29), the regmap mmio bus will read/write with the __raw_*() IO accessors, instead of using the readl/writel() APIs that do proper byte swapping for little endian devices. So if we're running on a big endian processor and haven't specified the endianness explicitly in the regmap config or in DT, we're going to switch from doing little endian byte swapping to big endian accesses without byte swapping, leading to some confusing results. On my apq8074 dragonboard, this causes the device to fail to boot as we access the clock controller with big endian IO accesses even though the device is little endian. Specify the endianness explicitly so that the regmap core properly byte swaps the accesses for us. Reported-by: Kevin Hilman <khilman@linaro.org> Cc: Simon Arlott <simon@fire.lp0.eu> Cc: Mark Brown <broonie@kernel.org> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> --- FYI, the regmap patch also converts the I/O accessors to use "relaxed" accessors that don't have any barrier semantics. So we've opened up the possibility of reads and writes overlapping each other whereas before that would be handled by the barriers buried in readl/writel, etc. I haven't yet fully examined the qcom clk driver for this problem, but I'm fairly certain we'll need to add some barriers in the driver to handle this. Alternatively we could add explicit barriers. drivers/clk/qcom/gcc-apq8084.c | 1 + drivers/clk/qcom/gcc-ipq806x.c | 1 + drivers/clk/qcom/gcc-msm8660.c | 1 + drivers/clk/qcom/gcc-msm8916.c | 1 + drivers/clk/qcom/gcc-msm8960.c | 2 ++ drivers/clk/qcom/gcc-msm8974.c | 1 + drivers/clk/qcom/lcc-ipq806x.c | 1 + drivers/clk/qcom/lcc-msm8960.c | 1 + drivers/clk/qcom/mmcc-apq8084.c | 1 + drivers/clk/qcom/mmcc-msm8960.c | 2 ++ drivers/clk/qcom/mmcc-msm8974.c | 1 + 11 files changed, 13 insertions(+)