* [PATCH v2 1/3] drm/sun4i: hdmi: Check for unset best_parent in sun4i_tmds_determine_rate
From: Jonathan Liu @ 2018-01-05 11:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180105100314.3j5zm4ushv4tfky5@flea.lan>
Hi Maxime,
On 5 January 2018 at 21:03, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> On Fri, Jan 05, 2018 at 09:44:39AM +1100, Jonathan Liu wrote:
>> On 5 January 2018 at 06:56, Maxime Ripard
>> <maxime.ripard@free-electrons.com> wrote:
>> > On Tue, Dec 26, 2017 at 10:12:25PM +1100, Jonathan Liu wrote:
>> >> We should check if the best match has been set before comparing it.
>> >>
>> >> Fixes: 9c5681011a0c ("drm/sun4i: Add HDMI support")
>> >> Signed-off-by: Jonathan Liu <net147@gmail.com>
>> >> ---
>> >> drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c | 2 +-
>> >> 1 file changed, 1 insertion(+), 1 deletion(-)
>> >>
>> >> diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c b/drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c
>> >> index dc332ea56f6c..4d235e5ea31c 100644
>> >> --- a/drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c
>> >> +++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c
>> >> @@ -102,7 +102,7 @@ static int sun4i_tmds_determine_rate(struct clk_hw *hw,
>> >> goto out;
>> >> }
>> >>
>> >> - if (abs(rate - rounded / i) <
>> >> + if (!best_parent || abs(rate - rounded / i) <
>> >
>> > Why is that causing any issue?
>> >
>> > If best_parent is set to 0...
>> >
>> >> abs(rate - best_parent / best_div)) {
>> >
>> > ... the value returned here is going to be rate, which is going to be
>> > higher than the first part of the comparison meaning ...
>> >
>> >> best_parent = rounded;
>> >
>> > ... that best_parent is going to be set there.
>>
>> Consider the following:
>> rate = 83500000
>> rounded = ideal * 2
>>
>> It is possible that if "rounded = clk_hw_round_rate(parent, ideal)"
>> gives high enough values that the condition "abs(rate - rounded / i) <
>> abs(rate - best_parent / best_div)" is never met.
>>
>> Then you can end up with:
>> req->rate = 0
>> req->best_parent_rate = 0
>> req->best_parent_hw = ...
>>
>> Also, the sun4i_tmds_calc_divider function has a similar check.
>
> Ok. That explanation must be part of your commit log, or at least
> which problem you're trying to address and in which situation it will
> trigger.
Ok. I have added amended the commit message with explanation for v3.
Regards,
Jonathan
^ permalink raw reply
* [PATCH][v2] arm64: Allocate elfcorehdr & crashkernel mem before any reservation
From: James Morse @ 2018-01-05 11:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515080048-9154-1-git-send-email-poonam.aggrwal@nxp.com>
Hi Poonam,
On 04/01/18 15:34, Poonam Aggrwal wrote:
> Address for both crashkernel memory and elfcorehdr can be assigned
> statically. For crashkernel memory it is via crashkernel=SIZE at ADDRESS
> and elfcorehdr_addr via by kexec-utils in dump kernel device tree.
There are some crashkernel=SIZE at ADDRESS values that the user can supply that we
must reject. The obvious one is if it overlaps with the kernel text. (this patch
won't spot this). We need to read the hardware's reserved regions from the DT
before we allocate the crashkernel region, for example if the bootloader
reserved a chunk of memory for a frame-buffer, I shouldn't be able to use that
as crashkernel memory.
(you shouldn't need to specify an address, doing so prevents the kernel from
picking memory it can use)
> So memory should be reserved for both the above areas before any
> other memory reservations are done. Otherwise overlaps may happen and
> memory allocations will fail leading to failure in booting the
> dump capture kernel.
> Signed-off-by: Guanhua <guanhua.gao@nxp.com>
The first signed-off-by should be the patch author.
If you want to credit your colleagues you can use 'CC', or they can give
reviewed-by/acked-by to the patch.
> Signed-off-by: Poonam Aggrwal <poonam.aggrwal@nxp.com>
> Signed-off-by: Abhimanyu Saini <abhimanyu.saini@nxp.com>
And the last signed-of-by should be from the person posting to the mailing list.
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index 00e7b90..24ce15d 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -453,6 +453,14 @@ void __init arm64_memblock_init(void)
> * Register the kernel text, kernel data, initrd, and initial
> * pagetables with memblock.
> */
Please don't insert this code between 'memblock_reserve(__pa_symbol(_text), _end
- _text);' and the comment that describes it.
> +
> + /* make these the first reservations to avoid chances of
> + * overlap
> + */
Nit: comment style
> + reserve_elfcorehdr();
(Moving reserve_elfcorehdr() makes sense, but..)
> + reserve_crashkernel();
reserve_crashkernel() does the allocation for the crashkernels reserved memory.
I expect this to always fail in the kdump kernel because there isn't enough
memory. (fdt_enforce_memory_region() at the top of this function calls
memblock_cap_memory_range()).
Moving this allocation above the early_init_fdt_scan_reserved_mem() below means
we may allocate memory for the crashdump that is in use by firmware/hardware and
described as reserved in the DT.
> memblock_reserve(__pa_symbol(_text), _end - _text);
> #ifdef CONFIG_BLK_DEV_INITRD
> if (initrd_start) {
> @@ -472,10 +480,6 @@ void __init arm64_memblock_init(void)
> else
> arm64_dma_phys_limit = PHYS_MASK + 1;
>
> - reserve_crashkernel();
> -
> - reserve_elfcorehdr();
> -
> high_memory = __va(memblock_end_of_DRAM() - 1) + 1;
>
> dma_contiguous_reserve(arm64_dma_phys_limit);
>
Thanks,
James
^ permalink raw reply
* [GIT PULL] Qualcomm Defconfig updates for 4.16
From: Arnd Bergmann @ 2018-01-05 10:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1514789609-4133-3-git-send-email-andy.gross@linaro.org>
On Mon, Jan 1, 2018 at 7:53 AM, Andy Gross <andy.gross@linaro.org> wrote:
> The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
>
> Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/agross/linux.git tags/qcom-defconfig-for-4.16
>
> for you to fetch changes up to b756f49a339aeca053ab71dd089a1868c3932f81:
>
> ARM: qcom_defconfig: Enable Frambuffer console support (2017-12-21 13:28:31 -0600)
>
> ----------------------------------------------------------------
> Qualcomm ARM Based defconfig Updates for v4.16
>
> * Enable framebuffer, IOMMU, and DRM options
Pulled into next/soc, thanks!
Arnd
^ permalink raw reply
* [GIT PULL] Qualcomm Device Tree updates for 4.16
From: Arnd Bergmann @ 2018-01-05 10:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1514789609-4133-5-git-send-email-andy.gross@linaro.org>
On Mon, Jan 1, 2018 at 7:53 AM, Andy Gross <andy.gross@linaro.org> wrote:
> The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
>
> Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/agross/linux.git tags/qcom-dts-for-4.16
>
> for you to fetch changes up to 6e2797bd80001e7f6ffe6fa95efaa27338a43aae:
>
> ARM: dts: msm8974-FP2: Add uSD slot nodes (2017-12-21 13:06:07 -0600)
>
> ----------------------------------------------------------------
> Qualcomm Device Tree Changes for v4.16
>
> * Add uSD slot nodes on msm8974-FP2 board
>
Pulled into next/dt, thanks!
Arnd
^ permalink raw reply
* [PATCH v5 20/20] cpufreq: scmi: add support for fast frequency switching
From: Sudeep Holla @ 2018-01-05 10:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CALW4P++xNXWUYoAEjV2=zfj-ps+JSD3kkkKRAeED08UF3Gabfw@mail.gmail.com>
On 04/01/18 22:10, Alexey Klimov wrote:
> Hi Sudeep,
>
> On Tue, Jan 2, 2018 at 2:42 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>> The cpufreq core provides option for drivers to implement fast_switch
>> callback which is invoked for frequency switching from interrupt context.
>>
>> This patch adds support for fast_switch callback in SCMI cpufreq driver
>> by making use of polling based SCMI transfer. It also sets the flag
>> fast_switch_possible.
>>
>> Cc: linux-pm at vger.kernel.org
>> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
>> ---
>> drivers/cpufreq/scmi-cpufreq.c | 15 +++++++++++++++
>> 1 file changed, 15 insertions(+)
>>
>> diff --git a/drivers/cpufreq/scmi-cpufreq.c b/drivers/cpufreq/scmi-cpufreq.c
>> index 0ee9335d0063..d0a82d7c6fd4 100644
>> --- a/drivers/cpufreq/scmi-cpufreq.c
>> +++ b/drivers/cpufreq/scmi-cpufreq.c
>> @@ -64,6 +64,19 @@ scmi_cpufreq_set_target(struct cpufreq_policy *policy, unsigned int index)
>> return perf_ops->freq_set(handle, priv->domain_id, freq, false);
>> }
>>
>> +static unsigned int scmi_cpufreq_fast_switch(struct cpufreq_policy *policy,
>> + unsigned int target_freq)
>> +{
>> + struct scmi_data *priv = policy->driver_data;
>> + struct scmi_perf_ops *perf_ops = handle->perf_ops;
>> +
>> + if (!perf_ops->freq_set(handle, priv->domain_id,
>> + target_freq * 1000, true))
>> + return target_freq;
>> +
>> + return 0;
>> +}
>
> Could you please explain how it's supposed to work for purpose of fast
> frequency switching?
>
> I am trying to track down ->freq_set.
> So it looks like this will fire an scmi perf level set command and
> will poll for this command to complete without asking for firmware to
> send command completion irq.
>
> scmi_perf_level_set() will call the following functions:
>
> scmi_one_xfer_init();
> scmi_do_xfer(handle, t);
> scmi_one_xfer_put(handle, t);
>
>
> The first function in the list calls scmi_one_xfer_get() which has
> this in the description (I guess because of down_timeout()):
> "This function can sleep depending on pending requests already in the system
> for the SCMI entity. Further, this also holds a spinlock to maintain
> integrity of internal data structures."
>
> So it can sleep.
>
Indeed, I can drop the whole semaphore story and expect the caller to
retry in case buffer is full which is very rare condition.
> As far as I see description of fast frequency switching it's required
> for fast_switch to not sleep:
> (file Documentation/cpu-freq/cpu-drivers.txt)
>
> "This function is used for frequency switching from scheduler's context.
> Not all drivers are expected to implement it, as sleeping from within
> this callback isn't allowed. This callback must be highly optimized to
> do switching as fast as possible."
>
>
> The other questions to this implementation of fast switching:
>
> 1) Fast switching callback must be highly optimized. Is it now? I see
> few spinlocks (in scmi mbox client and in the mailbox framework) there
> and polling functionality with udelay(5) inside that will timeout (if
> my calculations are correct) after 0.5 ms.
Do you have any alternate ideas to avoid that and still achieve fast
switching ?
> 2) Is it highly dependent on transport? If mailbox transport
> ->send_data() may sleep or hrtimer-based polling in mailbox framework
> will be used, then this fast switch won't work, right?
>
Yes.
> I am still looking into that: I can be wrong and just trying to
> understand if it is all okay.
>
Thanks for taking a look at this.
--
Regards,
Sudeep
^ permalink raw reply
* [GIT PULL] Qualcomm ARM64 DT updates for 4.16
From: Arnd Bergmann @ 2018-01-05 10:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1514789609-4133-2-git-send-email-andy.gross@linaro.org>
On Mon, Jan 1, 2018 at 7:53 AM, Andy Gross <andy.gross@linaro.org> wrote:
> Qualcomm ARM64 Updates for v4.16
>
> * Assorted cleanups for msm8916
> * Fix IPC references for smsm
Pulled into next/dt, thanks!
Arnd
^ permalink raw reply
* [GIT PULL] Qualcomm ARM64 Defconfig updates for 4.16
From: Arnd Bergmann @ 2018-01-05 10:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1514789609-4133-1-git-send-email-andy.gross@linaro.org>
On Mon, Jan 1, 2018 at 7:53 AM, Andy Gross <andy.gross@linaro.org> wrote:
> The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
>
> Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/agross/linux.git tags/qcom-arm64-defconfig-for-4.16
>
> for you to fetch changes up to d2fa1f37d21bf9729ae9ee79cb6bfc8de1f0a9a4:
>
> arm64: defconfig: remove CONFIG_USB_QCOM_8X16_PHY (2017-12-21 13:28:11 -0600)
>
> ----------------------------------------------------------------
> Qualcomm ARM64 Based defconfig Updates for v4.16
>
> * Remove legacy QCOM config options
>
> ----------------------------------------------------------------
> Alex Elder (3):
> arm64: defconfig: remove CONFIG_USB_EHCI_MSM
> arm64: defconfig: remove CONFIG_USB_MSM_OTG
> arm64: defconfig: remove CONFIG_USB_QCOM_8X16_PHY
Thanks for taking care of this, merged into next/soc.
I wonder what the long-term plan is for the other drivers/usb/phy drivers now
that one more has been removed.
I just checked what's left there and found:
a) many users of usb-nop-xceiv
b) a few drivers in use on actively maintained platforms (ti,am335x-usb-phy,
ti,twl6030-usb, ti,keystone-usbphy, fsl,imx23-usbphy,
nvidia,tegra20-usb-phy)
c) some more drivers used only by very old platforms (fsl-usb2-otg, gpio-vbus,
mv-otg, isp1301, isp1301_omap, omap_otg, tahvo-usb)
I assume nobody is touching the ones in category c) any more, but should
we encourage the ones using category a) and b) to get replaced with
drivers/phy/ drivers like the Qualcomm ones were?
Arnd
^ permalink raw reply
* [PATCH v4 6/7] ARM: davinci: convert to common clock framework
From: Sekhar Nori @ 2018-01-05 10:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a1593cb6-f471-022f-e41a-74146053fff8@lechnology.com>
On Friday 05 January 2018 08:29 AM, David Lechner wrote:
> On 01/04/2018 11:50 AM, David Lechner wrote:
>> On 1/4/18 6:39 AM, Sekhar Nori wrote:
>>> This is a pretty huge patch again and I hope it can be broken down.
>>> Ideally one per SoC converted and then the unused code removal.
>>>
>>
>> Will do.
>
> Well, I can do this, but I don't think it will compile or run. We can't
> have the common clock framework and the legacy davinci clocks enabled at
> the same time.
I see. Can you at least hive off the code removal into a separate patch
for next submission. I will then take a closer look at this.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH 1/6] ARM64: dts: meson-axg: uart: drop legacy compatible name from EE UART
From: Jerome Brunet @ 2018-01-05 10:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180105095621.196472-2-yixun.lan@amlogic.com>
On Fri, 2018-01-05 at 17:56 +0800, Yixun Lan wrote:
> For the UART controller in EE domain, they require 'pclk' to work.
they ? "the driver" maybe ?
> Current logic of the code will force to go for legacy clock probe
> if it found current compatible string match to 'amlogic,meson-ao-uart'.
did you mean "amlogic,meson-uart" instead ?
Apart from that
Acked-by: Jerome Brunet <jbrunet@baylibre.com>
>
> Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
> ---
> arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> index e2b8a9c8bf0b..1c6002b3fe34 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> @@ -142,14 +142,14 @@
> };
>
> uart_A: serial at 24000 {
> - compatible = "amlogic,meson-gx-uart", "amlogic,meson-uart";
> + compatible = "amlogic,meson-gx-uart";
> reg = <0x0 0x24000 0x0 0x14>;
> interrupts = <GIC_SPI 26 IRQ_TYPE_EDGE_RISING>;
> status = "disabled";
> };
>
> uart_B: serial at 23000 {
> - compatible = "amlogic,meson-gx-uart", "amlogic,meson-uart";
> + compatible = "amlogic,meson-gx-uart";
> reg = <0x0 0x23000 0x0 0x14>;
> interrupts = <GIC_SPI 75 IRQ_TYPE_EDGE_RISING>;
> status = "disabled";
^ permalink raw reply
* [PATCH 2/6] ARM64: dts: meson-axg: uart: fix address space range
From: Jerome Brunet @ 2018-01-05 10:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180105095621.196472-3-yixun.lan@amlogic.com>
On Fri, 2018-01-05 at 17:56 +0800, Yixun Lan wrote:
> The address space range is actually 0x18, fixed here.
Isn't it the same for other meson SoC ? If they are compatible, it should.
Could you please re-submit this change addressing all the required platforms ?
>
> Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
> ---
> arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> index 1c6002b3fe34..9636a7c5f6ed 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> @@ -143,14 +143,14 @@
>
> uart_A: serial at 24000 {
> compatible = "amlogic,meson-gx-uart";
> - reg = <0x0 0x24000 0x0 0x14>;
> + reg = <0x0 0x24000 0x0 0x18>;
> interrupts = <GIC_SPI 26 IRQ_TYPE_EDGE_RISING>;
> status = "disabled";
> };
>
> uart_B: serial at 23000 {
> compatible = "amlogic,meson-gx-uart";
> - reg = <0x0 0x23000 0x0 0x14>;
> + reg = <0x0 0x23000 0x0 0x18>;
> interrupts = <GIC_SPI 75 IRQ_TYPE_EDGE_RISING>;
> status = "disabled";
> };
^ permalink raw reply
* [PATCH 3/6] ARM64: dts: meson-axg: uart: Add the clock info description
From: Jerome Brunet @ 2018-01-05 10:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180105095621.196472-4-yixun.lan@amlogic.com>
On Fri, 2018-01-05 at 17:56 +0800, Yixun Lan wrote:
> Add the clock info description for the EE UART controller.
>
> Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
> ---
> arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> index 9636a7c5f6ed..f6bf01cfff4b 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> @@ -146,6 +146,8 @@
> reg = <0x0 0x24000 0x0 0x18>;
> interrupts = <GIC_SPI 26 IRQ_TYPE_EDGE_RISING>;
> status = "disabled";
> + clocks = <&xtal>, <&clkc CLKID_UART0>, <&xtal>;
> + clock-names = "xtal", "pclk", "baud";
This should squashed with change #1, where you remove amlogic,meson-uartcompatible.
Otherwise uart is going to be broken between these patches.
> };
>
> uart_B: serial at 23000 {
> @@ -153,6 +155,8 @@
> reg = <0x0 0x23000 0x0 0x18>;
> interrupts = <GIC_SPI 75 IRQ_TYPE_EDGE_RISING>;
> status = "disabled";
> + clocks = <&xtal>, <&clkc CLKID_UART1>, <&xtal>;
> + clock-names = "xtal", "pclk", "baud";
> };
> };
>
^ permalink raw reply
* [PATCH 04/11] arm64: cpufeature: Pass capability structure to ->enable callback
From: Suzuki K Poulose @ 2018-01-05 10:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515078515-13723-5-git-send-email-will.deacon@arm.com>
On 04/01/18 15:08, Will Deacon wrote:
> In order to invoke the CPU capability ->matches callback from the ->enable
> callback for applying local-CPU workarounds, we need a handle on the
> capability structure.
>
> This patch passes a pointer to the capability structure to the ->enable
> callback.
>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
> ---
> arch/arm64/kernel/cpufeature.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> index e11c11bb5b02..6133c14b9b01 100644
> --- a/arch/arm64/kernel/cpufeature.c
> +++ b/arch/arm64/kernel/cpufeature.c
> @@ -1151,7 +1151,7 @@ void __init enable_cpu_capabilities(const struct arm64_cpu_capabilities *caps)
> * uses an IPI, giving us a PSTATE that disappears when
> * we return.
> */
> - stop_machine(caps->enable, NULL, cpu_online_mask);
> + stop_machine(caps->enable, (void *)caps, cpu_online_mask);
> }
> }
> }
> @@ -1194,7 +1194,7 @@ verify_local_cpu_features(const struct arm64_cpu_capabilities *caps)
> cpu_die_early();
> }
> if (caps->enable)
> - caps->enable(NULL);
> + caps->enable((void *)caps);
> }
> }
>
>
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
^ permalink raw reply
* [PATCH 4/6] ARM64: dts: meson-axg: uart: Add the pinctrl info description
From: Jerome Brunet @ 2018-01-05 10:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180105095621.196472-5-yixun.lan@amlogic.com>
On Fri, 2018-01-05 at 17:56 +0800, Yixun Lan wrote:
> Describe the pinctrl info for the UART controller which
is
> found
> in the Meson-AXG SoCs.
Yixun,
Could you please review this patch again. Some "strings" used here will
obviously not work. I've picked up a few but I'm pretty sure there are other ...
Thanks
>
> Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
> ---
> arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 96 ++++++++++++++++++++++++++++++
> 1 file changed, 96 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> index f6bf01cfff4b..78bb206e2897 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> @@ -303,6 +303,70 @@
> function = "pwm_d";
> };
> };
> +
> + uart_a_pins: uart_a {
> + mux {
> + groups = "uart_tx_a",
> + "uart_rx_a";
> + function = "uart_a";
> + };
> + };
> +
> + uart_a_cts_rts_pins: uart_a_cts_rts {
> + mux {
> + groups = "uart_ctx_a",
uart_ctx_a does not exist in pinctrl
> + "uart_rts_a";
> + function = "uart_a";
> + };
> + };
> +
> + uart_b_x_pins: uart_b_x {
> + mux {
> + groups = "uart_tx_b_x",
> + "uart_rx_b_x";
> + function = "uart_b";
> + };
> + };
> +
> + uart_b_x_cts_rts_pins: uart_b_x_cts_rts {
> + mux {
> + groups = "uart_cts_b_x",
> + "uart_rts_b_x";
> + function = "uart_b";
> + };
> + };
> +
> + uart_b_z_pins: uart_b_z {
> + mux {
> + groups = "uart_tx_b_z",
> + "uart_rx_b_z";
> + function = "uart_b";
> + };
> + };
> +
> + uart_b_z_cts_rts_pins: uart_b_z_cts_rts {
> + mux {
> + groups = "uart_cts_b_z",
> + "uart_rts_b_z";
> + function = "uart_b";
> + };
> + };
> +
> + uart_ao_b_z_pins: uart_ao_b_z {
> + mux {
> + groups = "uart_ao_tx_b_z",
> + "uart_ao_rx_b_z";
> + function = "uart_ao_b_groupz";
"uart_ao_b_groupz" function does not exist in pinctrl
> + };
> + };
> +
> + uart_ao_b_z_cts_rts_pins: uart_ao_b_z_cts_rts {
> + mux {
> + groups = "uart_ao_cts_b_z",
> + "uart_ao_rts_b_z";
> + function = "uart_ao_b_groupz";
> + };
> + };
> };
> };
>
> @@ -346,6 +410,38 @@
> #gpio-cells = <2>;
> gpio-ranges = <&pinctrl_aobus 0 0 15>;
> };
> +
> + uart_ao_a_pins: uart_ao_a {
> + mux {
> + groups = "uart_ao_tx_a",
> + "uart_ao_rx_a";
> + function = "uart_ao_a";
> + };
> + };
> +
> + uart_ao_a_cts_rts_pins: uart_ao_a_cts_rts {
> + mux {
> + groups = "uart_ao_cts_a",
> + "uart_ao_rts_a";
> + function = "uart_ao_a";
> + };
> + };
> +
> + uart_ao_b_pins: uart_ao_b {
> + mux {
> + groups = "uart_ao_tx_b",
> + "uart_ao_rx_b";
> + function = "uart_ao_b";
> + };
> + };
> +
> + uart_ao_b_cts_rts_pins: uart_ao_b_cts_rts {
> + mux {
> + groups = "uart_ao_cts_b",
> + "uart_ao_rts_b";
> + function = "uart_ao_b";
> + };
> + };
> };
>
> pwm_AO_ab: pwm at 7000 {
^ permalink raw reply
* [PATCH 5/6] arm64: dts: meson-axg: complete the pinctrl info for UART_AO_A
From: Jerome Brunet @ 2018-01-05 10:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180105095621.196472-6-yixun.lan@amlogic.com>
On Fri, 2018-01-05 at 17:56 +0800, Yixun Lan wrote:
> Explictly request the pinctrl info for the UART_AO_A controller,
> otherwise we my rely on bootloader for the initialization.
"we may" ? --^
>
> Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
Please be consistent in the title
s/arm64/ARM64
Otherwise looks good once patch #4 is fixed
Acked-by: Jerome Brunet <jbrunet@baylibre.com>
> ---
> arch/arm64/boot/dts/amlogic/meson-axg-s400.dts | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
> index 70eca1f8736a..2b79be356996 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
> @@ -19,4 +19,6 @@
>
> &uart_AO {
> status = "okay";
> + pinctrl-0 = <&uart_ao_a_pins>;
> + pinctrl-names = "default";
> };
^ permalink raw reply
* [PATCH 6/6] ARM64: dts: meson-axg: enable the UART_A controller
From: Jerome Brunet @ 2018-01-05 10:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180105095621.196472-7-yixun.lan@amlogic.com>
On Fri, 2018-01-05 at 17:56 +0800, Yixun Lan wrote:
> The UART_A is connect to a BT module in the S400 board.
The UART_A is connected to a BT module on the S400 board.
-- --
Apart from this:
Acked-by: Jerome Brunet <jbrunet@baylibre.com>
>
> Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
> ---
> arch/arm64/boot/dts/amlogic/meson-axg-s400.dts | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
> index 2b79be356996..7e03b8da4856 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
> @@ -14,9 +14,16 @@
>
> aliases {
> serial0 = &uart_AO;
> + serial1 = &uart_A;
> };
> };
>
> +&uart_A {
> + status = "okay";
> + pinctrl-0 = <&uart_a_pins>;
> + pinctrl-names = "default";
> +};
> +
> &uart_AO {
> status = "okay";
> pinctrl-0 = <&uart_ao_a_pins>;
^ permalink raw reply
* [PATCH 00/13] replace print_symbol() with printk()-s
From: Sergey Senozhatsky @ 2018-01-05 10:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180105102105.GB471@jagdpanzerIV>
On (01/05/18 19:21), Sergey Senozhatsky wrote:
> On (01/05/18 11:03), Petr Mladek wrote:
> [..]
> > Anyway, print_symbol() is an old weird API and it would be nice
> > to eventually get rid of it. I could take this patches into
> > printk.git.
>
> no objections from my side if the patch set will go through the printk tree.
> shall we wait for ACKs or can we move on? do you plan to land it in 4.16?
>
> > Would you mind if I change the commit messages to something like?:
> >
> > print_symbol() is an old weird API. It has been
> > obsoleted by printk() and %pS format specifier.
>
> I wouldn't. let's drop the "weird" part. other than that looks
> good to me.
oh, one more thing. one extra patch, which gets rid of
print_symbol()/__print_symbol().
8< ===
From: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Subject: [PATCH] kallsyms: remove print_symbol() function
No more print_symbol()/__print_symbol() users left, remove these
symbols.
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Suggested-by: Joe Perches <joe@perches.com>
---
Documentation/filesystems/sysfs.txt | 4 ++--
Documentation/translations/zh_CN/filesystems/sysfs.txt | 4 ++--
include/linux/kallsyms.h | 18 ------------------
kernel/kallsyms.c | 11 -----------
4 files changed, 4 insertions(+), 33 deletions(-)
diff --git a/Documentation/filesystems/sysfs.txt b/Documentation/filesystems/sysfs.txt
index 9a3658cc399e..a1426cabcef1 100644
--- a/Documentation/filesystems/sysfs.txt
+++ b/Documentation/filesystems/sysfs.txt
@@ -154,8 +154,8 @@ static ssize_t dev_attr_show(struct kobject *kobj, struct attribute *attr,
if (dev_attr->show)
ret = dev_attr->show(dev, dev_attr, buf);
if (ret >= (ssize_t)PAGE_SIZE) {
- print_symbol("dev_attr_show: %s returned bad count\n",
- (unsigned long)dev_attr->show);
+ printk("dev_attr_show: %pS returned bad count\n",
+ dev_attr->show);
}
return ret;
}
diff --git a/Documentation/translations/zh_CN/filesystems/sysfs.txt b/Documentation/translations/zh_CN/filesystems/sysfs.txt
index 7d3b05edb8ce..452271dda141 100644
--- a/Documentation/translations/zh_CN/filesystems/sysfs.txt
+++ b/Documentation/translations/zh_CN/filesystems/sysfs.txt
@@ -167,8 +167,8 @@ static ssize_t dev_attr_show(struct kobject *kobj, struct attribute *attr,
if (dev_attr->show)
ret = dev_attr->show(dev, dev_attr, buf);
if (ret >= (ssize_t)PAGE_SIZE) {
- print_symbol("dev_attr_show: %s returned bad count\n",
- (unsigned long)dev_attr->show);
+ printk("dev_attr_show: %pS returned bad count\n",
+ dev_attr->show);
}
return ret;
}
diff --git a/include/linux/kallsyms.h b/include/linux/kallsyms.h
index 23190e5c940b..657a83b943f0 100644
--- a/include/linux/kallsyms.h
+++ b/include/linux/kallsyms.h
@@ -94,9 +94,6 @@ extern int sprint_symbol(char *buffer, unsigned long address);
extern int sprint_symbol_no_offset(char *buffer, unsigned long address);
extern int sprint_backtrace(char *buffer, unsigned long address);
-/* Look up a kernel symbol and print it to the kernel messages. */
-extern void __print_symbol(const char *fmt, unsigned long address);
-
int lookup_symbol_name(unsigned long addr, char *symname);
int lookup_symbol_attrs(unsigned long addr, unsigned long *size, unsigned long *offset, char *modname, char *name);
@@ -166,23 +163,8 @@ static inline int kallsyms_show_value(void)
return false;
}
-/* Stupid that this does nothing, but I didn't create this mess. */
-#define __print_symbol(fmt, addr)
#endif /*CONFIG_KALLSYMS*/
-/* This macro allows us to keep printk typechecking */
-static __printf(1, 2)
-void __check_printsym_format(const char *fmt, ...)
-{
-}
-
-static inline void print_symbol(const char *fmt, unsigned long addr)
-{
- __check_printsym_format(fmt, "");
- __print_symbol(fmt, (unsigned long)
- __builtin_extract_return_addr((void *)addr));
-}
-
static inline void print_ip_sym(unsigned long ip)
{
printk("[<%px>] %pS\n", (void *) ip, (void *) ip);
diff --git a/kernel/kallsyms.c b/kernel/kallsyms.c
index 24f456689f9c..a23e21ada81b 100644
--- a/kernel/kallsyms.c
+++ b/kernel/kallsyms.c
@@ -429,17 +429,6 @@ int sprint_backtrace(char *buffer, unsigned long address)
return __sprint_symbol(buffer, address, -1, 1);
}
-/* Look up a kernel symbol and print it to the kernel messages. */
-void __print_symbol(const char *fmt, unsigned long address)
-{
- char buffer[KSYM_SYMBOL_LEN];
-
- sprint_symbol(buffer, address);
-
- printk(fmt, buffer);
-}
-EXPORT_SYMBOL(__print_symbol);
-
/* To avoid using get_symbol_offset for every symbol, we carry prefix along. */
struct kallsym_iter {
loff_t pos;
--
2.15.1
^ permalink raw reply related
* [PATCH 03/11] arm64: Take into account ID_AA64PFR0_EL1.CSV3
From: Suzuki K Poulose @ 2018-01-05 10:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515078515-13723-4-git-send-email-will.deacon@arm.com>
On 04/01/18 15:08, Will Deacon wrote:
> For non-KASLR kernels where the KPTI behaviour has not been overridden
> on the command line we can use ID_AA64PFR0_EL1.CSV3 to determine whether
> or not we should unmap the kernel whilst running at EL0.
>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
> ---
> arch/arm64/include/asm/sysreg.h | 1 +
> arch/arm64/kernel/cpufeature.c | 7 ++++++-
> 2 files changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
> index 08cc88574659..ae519bbd3f9e 100644
> --- a/arch/arm64/include/asm/sysreg.h
> +++ b/arch/arm64/include/asm/sysreg.h
> @@ -437,6 +437,7 @@
> #define ID_AA64ISAR1_DPB_SHIFT 0
>
> /* id_aa64pfr0 */
> +#define ID_AA64PFR0_CSV3_SHIFT 60
> #define ID_AA64PFR0_SVE_SHIFT 32
> #define ID_AA64PFR0_GIC_SHIFT 24
> #define ID_AA64PFR0_ASIMD_SHIFT 20
> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> index 9f0545dfe497..e11c11bb5b02 100644
> --- a/arch/arm64/kernel/cpufeature.c
> +++ b/arch/arm64/kernel/cpufeature.c
> @@ -145,6 +145,7 @@ static const struct arm64_ftr_bits ftr_id_aa64isar1[] = {
> };
>
> static const struct arm64_ftr_bits ftr_id_aa64pfr0[] = {
> + ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64PFR0_CSV3_SHIFT, 4, 0),
> ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR0_SVE_SHIFT, 4, 0),
> ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR0_GIC_SHIFT, 4, 0),
> S_ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR0_ASIMD_SHIFT, 4, ID_AA64PFR0_ASIMD_NI),
> @@ -851,6 +852,8 @@ static int __kpti_forced; /* 0: not forced, >0: forced on, <0: forced off */
> static bool unmap_kernel_at_el0(const struct arm64_cpu_capabilities *entry,
> int __unused)
> {
> + u64 pfr0 = read_sanitised_ftr_reg(SYS_ID_AA64PFR0_EL1);
> +
> /* Forced on command line? */
> if (__kpti_forced) {
> pr_info_once("kernel page table isolation forced %s by command line option\n",
> @@ -862,7 +865,9 @@ static bool unmap_kernel_at_el0(const struct arm64_cpu_capabilities *entry,
> if (IS_ENABLED(CONFIG_RANDOMIZE_BASE))
> return true;
>
> - return false;
> + /* Defer to CPU feature registers */
> + return !cpuid_feature_extract_unsigned_field(pfr0,
> + ID_AA64PFR0_CSV3_SHIFT);
> }
>
The cpufeature bit changes look good to me. FWIW,
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
^ permalink raw reply
* [GIT PULL] Allwinner DT changes for 4.16, step 2
From: Maxime Ripard @ 2018-01-05 10:22 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd, Olof,
Happy new year :)
Here is the second bunch of changes we talked about in our first PR.
There's one fix for 4.16, and the other patches have been around for
quite a while that I'm feeling confident that we should merge them.
On a side note, my GPG key changed recently. The new fingerprint is
2BA0E943D27E3D2094B10B24D824ECA89C346DCE, and you'll find that it has
been signed by a bunch of kernel developpers already. The old one is
superseeded, but has not been compromised.
Thanks!
Maxime
The following changes since commit 2ce3dc66d75fc204cc42bc4ee9c6f612ef4a8949:
ARM: dts: sun8i: h3: nanopi-m1-plus: fix missing ethernet 0 in aliases (2017-12-19 09:54:46 +0100)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git tags/sunxi-dt-for-4.16-2
for you to fetch changes up to 1ce799079155cab76ccc521b9cf870c2cb9aa96c:
ARM: dts: sun8i: a711: Enable the LCD (2018-01-05 09:54:34 +0100)
----------------------------------------------------------------
Allwinner DT changes for 4.16, bis
A few improvements to our DT support, with:
- basic DRM support for the A83t
- simplefb support for the H3 and H5 SoCs
- One fix for the USB ethernet on the Orange Pi R1
----------------------------------------------------------------
Icenowy Zheng (5):
ARM: dts: sun8i: fix USB Ethernet of Orange Pi R1
dt-bindings: simplefb-sunxi: add pipelines for DE2
ARM: sun8i: h3/h5: add DE2 CCU device node for H3
arm64: allwinner: h5: add compatible string for DE2 CCU
ARM: sunxi: h3/h5: add simplefb nodes
Maxime Ripard (4):
ARM: dts: sun8i: a83t: Add display pipeline
ARM: dts: sun8i: a83t: Enable the PWM
ARM: dts: sun8i: a83t: Add LVDS pins group
ARM: dts: sun8i: a711: Enable the LCD
.../bindings/display/simple-framebuffer-sunxi.txt | 4 +
arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts | 61 +++++++++++++
arch/arm/boot/dts/sun8i-a83t.dtsi | 99 ++++++++++++++++++++++
arch/arm/boot/dts/sun8i-h2-plus-orangepi-r1.dts | 18 ++++
arch/arm/boot/dts/sun8i-h3.dtsi | 4 +
arch/arm/boot/dts/sunxi-h3-h5.dtsi | 38 +++++++++
arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi | 4 +
7 files changed, 228 insertions(+)
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180105/09c260c1/attachment.sig>
^ permalink raw reply
* [PATCH 00/13] replace print_symbol() with printk()-s
From: Sergey Senozhatsky @ 2018-01-05 10:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180105100300.j3svmcvvpfe2iows@pathway.suse.cz>
On (01/05/18 11:03), Petr Mladek wrote:
[..]
> Anyway, print_symbol() is an old weird API and it would be nice
> to eventually get rid of it. I could take this patches into
> printk.git.
no objections from my side if the patch set will go through the printk tree.
shall we wait for ACKs or can we move on? do you plan to land it in 4.16?
> Would you mind if I change the commit messages to something like?:
>
> print_symbol() is an old weird API. It has been
> obsoleted by printk() and %pS format specifier.
I wouldn't. let's drop the "weird" part. other than that looks
good to me.
-ss
^ permalink raw reply
* [PATCH v2 1/3] drm/sun4i: hdmi: Check for unset best_parent in sun4i_tmds_determine_rate
From: Maxime Ripard @ 2018-01-05 10:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANwerB3SKX=H-mhQZ0mLaLXmPiohVwoF+8dbWMhq9Fw7eJA4AA@mail.gmail.com>
On Fri, Jan 05, 2018 at 09:44:39AM +1100, Jonathan Liu wrote:
> Hi Maxime,
>
> On 5 January 2018 at 06:56, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
> > On Tue, Dec 26, 2017 at 10:12:25PM +1100, Jonathan Liu wrote:
> >> We should check if the best match has been set before comparing it.
> >>
> >> Fixes: 9c5681011a0c ("drm/sun4i: Add HDMI support")
> >> Signed-off-by: Jonathan Liu <net147@gmail.com>
> >> ---
> >> drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c b/drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c
> >> index dc332ea56f6c..4d235e5ea31c 100644
> >> --- a/drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c
> >> +++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c
> >> @@ -102,7 +102,7 @@ static int sun4i_tmds_determine_rate(struct clk_hw *hw,
> >> goto out;
> >> }
> >>
> >> - if (abs(rate - rounded / i) <
> >> + if (!best_parent || abs(rate - rounded / i) <
> >
> > Why is that causing any issue?
> >
> > If best_parent is set to 0...
> >
> >> abs(rate - best_parent / best_div)) {
> >
> > ... the value returned here is going to be rate, which is going to be
> > higher than the first part of the comparison meaning ...
> >
> >> best_parent = rounded;
> >
> > ... that best_parent is going to be set there.
>
> Consider the following:
> rate = 83500000
> rounded = ideal * 2
>
> It is possible that if "rounded = clk_hw_round_rate(parent, ideal)"
> gives high enough values that the condition "abs(rate - rounded / i) <
> abs(rate - best_parent / best_div)" is never met.
>
> Then you can end up with:
> req->rate = 0
> req->best_parent_rate = 0
> req->best_parent_hw = ...
>
> Also, the sun4i_tmds_calc_divider function has a similar check.
Ok. That explanation must be part of your commit log, or at least
which problem you're trying to address and in which situation it will
trigger.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180105/04291b5f/attachment.sig>
^ permalink raw reply
* [PATCH 00/13] replace print_symbol() with printk()-s
From: Petr Mladek @ 2018-01-05 10:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211125025.2270-1-sergey.senozhatsky@gmail.com>
On Mon 2017-12-11 21:50:12, Sergey Senozhatsky wrote:
> Hello,
>
> A rather automatic replacement of print_symbol()
> with direct printk() calls. print_symbol() uses extra stack
> buffer (KSYM_SYMBOL_LEN 128 bytes) and, basically, should
> be identical to printk(%pS).
To make it clear, both print_symbol() and printk(%pS)
print the adress using sprint_symbol(). And even printk(%pS)
uses the buffer on the stack, see:
char *symbol_string(char *buf, char *end, void *ptr,
struct printf_spec spec, const char *fmt)
{
[...]
char sym[KSYM_SYMBOL_LEN];
[...]
sprint_symbol(sym, value);
}
Anyway, print_symbol() is an old weird API and it would be nice
to eventually get rid of it. I could take this patches into
printk.git. Would you mind if I change the commit messages
to something like?:
print_symbol() is an old weird API. It has been
obsoleted by printk() and %pS format specifier.
Best Regards,
Petr
^ permalink raw reply
* [PATCH] imx6: fix pcie enumeration
From: Koen Vandeputte @ 2018-01-05 9:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180104202430.GC189897@bhelgaas-glaptop.roam.corp.google.com>
On 2018-01-04 21:24, Bjorn Helgaas wrote:
> [+cc Richard, Lucas, Lorenzo, linux-arm-kernel]
>
> Hi Koen,
>
> Thanks a lot for the fix!
>
> Please run "git log --oneline drivers/pci/dwc/pci-imx6.c" and follow
> the style convention, including "PCIe" capitalization.
>
> "fix pcie enumeration" is not very descriptive. It should say something
> about the specific problem, e.g., setting the root port's subordinate
> bus number.
>
> On Thu, Jan 04, 2018 at 04:48:03PM +0100, Koen Vandeputte wrote:
>> By default, when the imx6 PCIe RC boots up, the subordinate is set
> Not sure what "RC boots up" means. Maybe you're talking about a
> hardware-defined default value at power-up, or maybe a value
> programmed by a boot-loader? Please clarify and update the similar
> comment in the code.
>
>> equally to the secondary bus (1), and does not alter afterwards.
>>
>> This means that theoretically, the highest bus reachable downstream is
>> bus 1.
> Not just theoretically. If the bridge is operating correctly, it
> should not forward any config transaction for a bus number greater
> than the subordinate bus number.
>
>> Before commit a20c7f36bd3d ("PCI: Do not allocate more buses than
>> available in parent"), the driver ignored the subord value and just
>> allowed up to 0xff on each device downstream.
>>
>> This caused a lot of errors to be printed, as this is not logical
>> according to spec. (but it worked ..)
> Including a sample error in the changelog might help somebody
> suffering from the problem find this solution.
>
>> After this commit, the driver stopped scanning deeper when the last
>> allocated busnr equals the subordinate of it's master, causing devices
>> to be undiscovered (especially behind bridges), uncovering the impact of
>> this bug.
>>
>> Before:
>>
>> 00:00.0 PCI bridge: Synopsys, Inc. Device abcd (rev 01) (prog-if 00 ...
>> Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
>>
>> 00:00.0 0604: 16c3:abcd (rev 01)
>> 01:00.0 0604: 10b5:8604 (rev ba)
>> ... stops after bus 1 ...
>>
>> After:
>>
>> 00:00.0 PCI bridge: Synopsys, Inc. Device abcd (rev 01) (prog-if 00
>> ...
>> Bus: primary=00, secondary=01, subordinate=ff, sec-latency=0
>>
>> 00:00.0 0604: 16c3:abcd (rev 01)
>> 01:00.0 0604: 10b5:8604 (rev ba)
>> 02:01.0 0604: 10b5:8604 (rev ba)
>> 02:04.0 0604: 10b5:8604 (rev ba)
>> 02:05.0 0604: 10b5:8604 (rev ba)
>> 03:00.0 0280: 168c:0033 (rev 01)
>> 05:00.0 0280: 168c:0033 (rev 01)
>>
> Should have a "Fixes: a20c7f36bd3d ..." tag if that's really the
> correct commit.
>
>> Signed-off-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
>> ---
>>
>> Needs backports to 4.14 & 4.9 stables
> Add a "CC: stable at vger.kernel.org" after your signed-off-by to handle
> this. But something's wrong because a20c7f36bd3d only appeared in
> v4.15-rc1, so either that's the wrong commit or stable kernels don't
> need the fix.
>
>> drivers/pci/dwc/pci-imx6.c | 14 ++++++++++++++
>> 1 file changed, 14 insertions(+)
>>
>> diff --git a/drivers/pci/dwc/pci-imx6.c b/drivers/pci/dwc/pci-imx6.c
>> index b73483534a5b..3d13fa8c2eb1 100644
>> --- a/drivers/pci/dwc/pci-imx6.c
>> +++ b/drivers/pci/dwc/pci-imx6.c
>> @@ -76,6 +76,9 @@ struct imx6_pcie {
>>
>> #define PCIE_RC_LCSR 0x80
>>
>> +#define PCIE_RC_BNR 0x18
>> +#define PCIE_RC_BNR_MAX_SUBORDINATE (0xff << 16)
>> +
>> /* PCIe Port Logic registers (memory-mapped) */
>> #define PL_OFFSET 0x700
>> #define PCIE_PL_PFLR (PL_OFFSET + 0x08)
>> @@ -562,6 +565,17 @@ static int imx6_pcie_establish_link(struct imx6_pcie *imx6_pcie)
>> int ret;
>>
>> /*
>> + * By default, the subordinate is set equally to the secondary
>> + * bus (0x01) when the RC boots.
>> + * This means that theoretically, only bus 1 is reachable from the RC.
>> + * Force the PCIe RC subordinate to 0xff, otherwise no downstream
>> + * devices will be detected behind bus 1.
>> + */
>> + tmp = dw_pcie_readl_rc(pp, PCIE_RC_BNR);
>> + tmp |= PCIE_RC_BNR_MAX_SUBORDINATE;
>> + dw_pcie_writel_rc(pp, PCIE_RC_BNR, tmp);
> This functionality is not related to establishing the link, so I think
> it should be put elsewhere, maybe either directly in imx6_pcie_probe()
> or in imx6_pcie_host_init().
>
> The DT really should contain a "bus-range" property and
> dw_pcie_host_init() will already pay attention to that if it's
> present, and I think it defaults to 0-0xff if it's not present.
>
> So I think you should be using pp->busn instead of hard-coding
> PCIE_RC_BNR_MAX_SUBORDINATE.
>
>> + /*
>> * Force Gen1 operation when starting the link. In case the link is
>> * started in Gen2 mode, there is a possibility the devices on the
>> * bus will not be detected at all. This happens with PCIe switches.
>> --
>> 2.7.4
>>
Hi Bjorn,
Thanks for your time and patience writing extended comments on all points,
especially since this is my first commit to this list.
Highly appreciated!
Secondly,
Based on your suggestions, I've dug around deeper in the code and found
the actual line that initially causes it:? [1]
*drivers/pci/dwc/pcie-designware-host.c*
<http://elixir.free-electrons.com/linux/v4.15-rc6/source/drivers/pci/dwc/pcie-designware-host.c#L588>
void dw_pcie_setup_rc
<http://elixir.free-electrons.com/linux/v4.15-rc6/ident/dw_pcie_setup_rc>(struct pcie_port <http://elixir.free-electrons.com/linux/v4.15-rc6/ident/pcie_port> *pp <http://elixir.free-electrons.com/linux/v4.15-rc6/ident/pp>)
{
...
/* setup bus numbers */
val = dw_pcie_readl_dbi
<http://elixir.free-electrons.com/linux/v4.15-rc6/ident/dw_pcie_readl_dbi>(pci
<http://elixir.free-electrons.com/linux/v4.15-rc6/ident/pci>, PCI_PRIMARY_BUS
<http://elixir.free-electrons.com/linux/v4.15-rc6/ident/PCI_PRIMARY_BUS>);
val &= 0xff000000;
val |= 0x00010100; <---
dw_pcie_writel_dbi
<http://elixir.free-electrons.com/linux/v4.15-rc6/ident/dw_pcie_writel_dbi>(pci
<http://elixir.free-electrons.com/linux/v4.15-rc6/ident/pci>, PCI_PRIMARY_BUS
<http://elixir.free-electrons.com/linux/v4.15-rc6/ident/PCI_PRIMARY_BUS>, val); ... The i.MX6 reference manual (page 417 - section 48.8.7 "Bus
Number Registers (PCIE_RC_BNR)") shows the following layout [2]: 31 23
15 7 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sec lat timer | Subord num | Sec busnum | Prim busnum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Shouldn't this:"val |= 0x00010100;" change to: "val |= 0x00ff0100;"
?
It seems other platforms also use this function (and thus register layout) to setup the PCIe RC [3],
so instead of doing a single fix for i.MX6 maybe it's best to fix it here so other platforms also benefit?
As you know the code a lot better than me, what's your opinion on this? (or from anyone in CC)
[1] http://elixir.free-electrons.com/linux/v4.15-rc6/source/drivers/pci/dwc/pcie-designware-host.c#L588
[2] https://community.nxp.com/servlet/JiveServlet/downloadBody/101783-102-6-17831/IMX6DQRMr2_part2.pdf
[3] http://elixir.free-electrons.com/linux/v4.15-rc6/ident/dw_pcie_setup_rc
Koen
^ permalink raw reply
* [PATCH 6/6] ARM64: dts: meson-axg: enable the UART_A controller
From: Yixun Lan @ 2018-01-05 9:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180105095621.196472-1-yixun.lan@amlogic.com>
The UART_A is connect to a BT module in the S400 board.
Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
---
arch/arm64/boot/dts/amlogic/meson-axg-s400.dts | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
index 2b79be356996..7e03b8da4856 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
@@ -14,9 +14,16 @@
aliases {
serial0 = &uart_AO;
+ serial1 = &uart_A;
};
};
+&uart_A {
+ status = "okay";
+ pinctrl-0 = <&uart_a_pins>;
+ pinctrl-names = "default";
+};
+
&uart_AO {
status = "okay";
pinctrl-0 = <&uart_ao_a_pins>;
--
2.15.1
^ permalink raw reply related
* [PATCH 5/6] arm64: dts: meson-axg: complete the pinctrl info for UART_AO_A
From: Yixun Lan @ 2018-01-05 9:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180105095621.196472-1-yixun.lan@amlogic.com>
Explictly request the pinctrl info for the UART_AO_A controller,
otherwise we my rely on bootloader for the initialization.
Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
---
arch/arm64/boot/dts/amlogic/meson-axg-s400.dts | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
index 70eca1f8736a..2b79be356996 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
@@ -19,4 +19,6 @@
&uart_AO {
status = "okay";
+ pinctrl-0 = <&uart_ao_a_pins>;
+ pinctrl-names = "default";
};
--
2.15.1
^ permalink raw reply related
* [PATCH 4/6] ARM64: dts: meson-axg: uart: Add the pinctrl info description
From: Yixun Lan @ 2018-01-05 9:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180105095621.196472-1-yixun.lan@amlogic.com>
Describe the pinctrl info for the UART controller which found
in the Meson-AXG SoCs.
Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
---
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 96 ++++++++++++++++++++++++++++++
1 file changed, 96 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
index f6bf01cfff4b..78bb206e2897 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
@@ -303,6 +303,70 @@
function = "pwm_d";
};
};
+
+ uart_a_pins: uart_a {
+ mux {
+ groups = "uart_tx_a",
+ "uart_rx_a";
+ function = "uart_a";
+ };
+ };
+
+ uart_a_cts_rts_pins: uart_a_cts_rts {
+ mux {
+ groups = "uart_ctx_a",
+ "uart_rts_a";
+ function = "uart_a";
+ };
+ };
+
+ uart_b_x_pins: uart_b_x {
+ mux {
+ groups = "uart_tx_b_x",
+ "uart_rx_b_x";
+ function = "uart_b";
+ };
+ };
+
+ uart_b_x_cts_rts_pins: uart_b_x_cts_rts {
+ mux {
+ groups = "uart_cts_b_x",
+ "uart_rts_b_x";
+ function = "uart_b";
+ };
+ };
+
+ uart_b_z_pins: uart_b_z {
+ mux {
+ groups = "uart_tx_b_z",
+ "uart_rx_b_z";
+ function = "uart_b";
+ };
+ };
+
+ uart_b_z_cts_rts_pins: uart_b_z_cts_rts {
+ mux {
+ groups = "uart_cts_b_z",
+ "uart_rts_b_z";
+ function = "uart_b";
+ };
+ };
+
+ uart_ao_b_z_pins: uart_ao_b_z {
+ mux {
+ groups = "uart_ao_tx_b_z",
+ "uart_ao_rx_b_z";
+ function = "uart_ao_b_groupz";
+ };
+ };
+
+ uart_ao_b_z_cts_rts_pins: uart_ao_b_z_cts_rts {
+ mux {
+ groups = "uart_ao_cts_b_z",
+ "uart_ao_rts_b_z";
+ function = "uart_ao_b_groupz";
+ };
+ };
};
};
@@ -346,6 +410,38 @@
#gpio-cells = <2>;
gpio-ranges = <&pinctrl_aobus 0 0 15>;
};
+
+ uart_ao_a_pins: uart_ao_a {
+ mux {
+ groups = "uart_ao_tx_a",
+ "uart_ao_rx_a";
+ function = "uart_ao_a";
+ };
+ };
+
+ uart_ao_a_cts_rts_pins: uart_ao_a_cts_rts {
+ mux {
+ groups = "uart_ao_cts_a",
+ "uart_ao_rts_a";
+ function = "uart_ao_a";
+ };
+ };
+
+ uart_ao_b_pins: uart_ao_b {
+ mux {
+ groups = "uart_ao_tx_b",
+ "uart_ao_rx_b";
+ function = "uart_ao_b";
+ };
+ };
+
+ uart_ao_b_cts_rts_pins: uart_ao_b_cts_rts {
+ mux {
+ groups = "uart_ao_cts_b",
+ "uart_ao_rts_b";
+ function = "uart_ao_b";
+ };
+ };
};
pwm_AO_ab: pwm at 7000 {
--
2.15.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox