* Re: [PATCH 1/3] Documentation: DT: Add entry for FSL LS1012A RDB, FRDM, QDS boards
From: Rob Herring @ 2016-11-14 23:35 UTC (permalink / raw)
To: Harninder Rai
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
shawnguo-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
oss-fOR+EgIDQEHk1uMJSBkQmQ, Bhaskar Upadhaya,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1478714651-12679-1-git-send-email-harninder.rai-3arQi8VN3Tc@public.gmane.org>
On Wed, Nov 09, 2016 at 11:34:11PM +0530, Harninder Rai wrote:
> Signed-off-by: Harninder Rai <harninder.rai-3arQi8VN3Tc@public.gmane.org>
> Signed-off-by: Bhaskar Upadhaya <Bhaskar.Upadhaya-3arQi8VN3Tc@public.gmane.org>
> ---
> Documentation/devicetree/bindings/arm/fsl.txt | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v7 4/5] of/fdt: mark hotpluggable memory
From: Balbir Singh @ 2016-11-14 23:20 UTC (permalink / raw)
To: Reza Arbab, Michael Ellerman, Benjamin Herrenschmidt,
Paul Mackerras, Andrew Morton, Rob Herring, Frank Rowand,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin
Cc: linuxppc-dev, linux-mm, devicetree, Bharata B Rao,
Nathan Fontenot, Stewart Smith, Alistair Popple, Aneesh Kumar K.V,
linux-kernel
In-Reply-To: <1479160961-25840-5-git-send-email-arbab@linux.vnet.ibm.com>
On 15/11/16 09:02, Reza Arbab wrote:
> When movable nodes are enabled, any node containing only hotpluggable
> memory is made movable at boot time.
>
> On x86, hotpluggable memory is discovered by parsing the ACPI SRAT,
> making corresponding calls to memblock_mark_hotplug().
>
> If we introduce a dt property to describe memory as hotpluggable,
> configs supporting early fdt may then also do this marking and use
> movable nodes.
>
> Signed-off-by: Reza Arbab <arbab@linux.vnet.ibm.com>
> Tested-by: Balbir Singh <bsingharora@gmail.com>
Also
Acked-by: Balbir Singh <bsingharora@gmail.com>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH v7 2/5] mm: remove x86-only restriction of movable_node
From: Balbir Singh @ 2016-11-14 23:20 UTC (permalink / raw)
To: Reza Arbab, Michael Ellerman, Benjamin Herrenschmidt,
Paul Mackerras, Andrew Morton, Rob Herring, Frank Rowand,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin
Cc: linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg,
devicetree-u79uwXL29TY76Z2rM5mHXA, Bharata B Rao, Nathan Fontenot,
Stewart Smith, Alistair Popple, Aneesh Kumar K.V,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1479160961-25840-3-git-send-email-arbab-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
On 15/11/16 09:02, Reza Arbab wrote:
> In commit c5320926e370 ("mem-hotplug: introduce movable_node boot
> option"), the memblock allocation direction is changed to bottom-up and
> then back to top-down like this:
>
> 1. memblock_set_bottom_up(true), called by cmdline_parse_movable_node().
> 2. memblock_set_bottom_up(false), called by x86's numa_init().
>
> Even though (1) occurs in generic mm code, it is wrapped by #ifdef
> CONFIG_MOVABLE_NODE, which depends on X86_64.
>
> This means that when we extend CONFIG_MOVABLE_NODE to non-x86 arches,
> things will be unbalanced. (1) will happen for them, but (2) will not.
>
> This toggle was added in the first place because x86 has a delay between
> adding memblocks and marking them as hotpluggable. Since other arches do
> this marking either immediately or not at all, they do not require the
> bottom-up toggle.
>
> So, resolve things by moving (1) from cmdline_parse_movable_node() to
> x86's setup_arch(), immediately after the movable_node parameter has
> been parsed.
>
> Signed-off-by: Reza Arbab <arbab-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
Acked-by: Balbir Singh <bsingharora-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 01/10] dt-bindings: rockchip-dw-mshc: add RK1108 dw-mshc description
From: Heiko Stuebner @ 2016-11-14 23:09 UTC (permalink / raw)
To: Andy Yan
Cc: shawn.lin, robh+dt, linux-rockchip, devicetree, ulf.hansson,
linux-mmc, linux-kernel, mark.rutland
In-Reply-To: <1479124865-24109-1-git-send-email-andy.yan@rock-chips.com>
Am Montag, 14. November 2016, 20:01:05 CET schrieb Andy Yan:
> From: Shawn Lin <shawn.lin@rock-chips.com>
>
> Add "rockchip,rk1108-dw-mshc", "rockchip,rk3288-dw-mshc" for
> dwmmc on rk1108 platform.
>
> Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
applied to my dts32 branch with Rob's Ack taken from the unchanged v1.
Heiko
^ permalink raw reply
* Re: [PATCH 1/2] usb: dwc2: add amcc,dwc-otg support
From: John Youn @ 2016-11-14 23:00 UTC (permalink / raw)
To: Christian Lamparter, John Youn
Cc: linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
linux-usb@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
Mark Rutland, Rob Herring, Greg Kroah-Hartman, Felipe Balbi
In-Reply-To: <3741942.Du5DzKuQeQ@debian64>
On 11/11/2016 3:12 PM, Christian Lamparter wrote:
> On Friday, November 11, 2016 2:20:42 PM CET John Youn wrote:
>> On 11/11/2016 2:05 PM, Christian Lamparter wrote:
>>> On Friday, November 11, 2016 1:22:16 PM CET John Youn wrote:
>>>> On 11/11/2016 12:59 PM, Christian Lamparter wrote:
>>>>> This patch adds support for the "amcc,usb-otg" device
>>>>> which is found in the PowerPC Canyonlands' dts.
>>>>>
>>>>> The device definition was added by:
>>>>> commit c89b3458d8cc ("powerpc/44x: Add USB DWC DTS entry to Canyonlands board")'
>>>>> but without any driver support as the dwc2 driver wasn't
>>>>> available at that time.
>>>>>
>>>>> Note: The system can't use the generic "snps,dwc2" compatible
>>>>> because of the special ahbcfg configuration. The default
>>>>> GAHBCFG_HBSTLEN_INCR4 of snps,dwc2 can cause a system hang
>>>>> when the USB and SATA is used concurrently.
>>>>
>>>> I don't want to add any more of these param structures to the driver
>>>> unless really necessary. We're trying to remove usage of them in favor
>>>> of using auto-detected defaults and device properties to override
>>>> them.
>>> Ok, thanks. I think that would work. I've attached an updated patch.
>>> Can it be applied/queued now? Or do you want me to resent it later?
>>>
>>>> The AHB Burst is actually one of the ones we were going to do next
>>>> because our platform also doesn't work well with INCR4. In fact I'm
>>>> thinking of making the default INCR.
>>> Is that actually possible to change the default still? This would
>>> require to re-evaluate all existing archs/platforms that use
>>> "snps,dwc2" for INCR16 compatibility.
>>
>> INCR, not INCR16, but you're right, so we may not change it even
>> though though INCR is usually the right choice over INCR4.
> What about making a device-tree property?
Yes, that's what I meant. I'll send a change for this shortly.
>
> Recommended properties:
> - g-ahb-bursts : specifies the ahb bursts length, should be one of
> "single", "INCRx", "INCR4", "INCR8", or "INCR16". If not specified
> the safer but inefficient "INCR4" is used. The optimal setting is
> "INCRx".
>
> Would this work? If so, I can make a patch over the weekend.
>> Anyways, with the binding, can't you just set the compatible string to
>> snps,dwc2?
>
> Ah, let me explain. I had a discussion with Mark Rutland and Rob Herring
> a while back about device-tree bindings.
>
> They made it very clear to me, that they don't want any generic "catch all
> compatible" strings:
>
> "Bindings should be for hardware (either specific device models, or for
> classes), and not for Linux drivers. The latter is subject to arbitrary
> changes while the former is not, as old hardware continues to exist and
> does not change while drivers get completely reworked." [0]
>
> Furthermore, this is an existing binding in kernel's canyonlands.dts [1]
> and this binding can't be easily changed. Rob Herring explained this in
> the context of the "basic-mmio-gpio" patch [2] when I was editing the dts
> to make them work with the changes I made:
>
> "You can't remove the old drivers as they are needed to work with
> old dtbs, so there is no gain.
>
> You would need to match on existing compatibles such as
> moxa,moxart-gpio and provide a match data struct that has all the info
> you are adding here (e.g. data register offset). Then additionally you
> could add "basic-mmio-gpio" (I would drop "basic" part) and the
> additional data associated with it. But it has to be new properties,
> not changing properties. Changing the reg values doesn't work."
>
> So, for this to work with the existing canyonlands.dts, I need to have
> the "amcc,dwc-otg" compatible string.
Ok, if that's the case. But still a bit confused as to what driver was
working with it before since the binding was not defined for dwc2.
>
> Of course, it would be great to hear from Rob Herring and/or Mark Rutland
> about this case.
>
> Regards,
> Christian
>
> [0] <https://patchwork.kernel.org/patch/8976221/>
> [1] <http://lxr.free-electrons.com/source/arch/powerpc/boot/dts/canyonlands.dts#L181>
> [2] <http://www.spinics.net/lists/devicetree/msg124538.html>
>
>
>>>
>>> From what I can tell based would be:
>>> bcm11351, bcm21664, bcm23550, exynos3250, stm32f429, rk3xxx,
>>> stratix10, meson-gxbb, rt3050 and some Altera FPGAs.
>>>
>>>> If that's all you need then a devicetree binding should be enough
>>>> right?
>>> Yes. The device is working fine so far.
>>>
>>> Regards,
>>> Christian
>>>
>>> ---
>>> From 70dd4be016b89655a56bc8260f04683b50f07644 Mon Sep 17 00:00:00 2001
>>> From: Christian Lamparter <chunkeey@gmail.com>
>>> Date: Sun, 6 Nov 2016 00:39:24 +0100
>>> Subject: [PATCH] usb: dwc2: add amcc,dwc-otg support
>>>
>>> This patch adds support for the "amcc,usb-otg" device
>>> which is found in the PowerPC Canyonlands' dts.
>>>
>>> The device definition was added by:
>>> commit c89b3458d8cc ("powerpc/44x: Add USB DWC DTS entry to Canyonlands board")'
>>> but without any driver support as the dwc2 driver wasn't
>>> available at that time.
>>>
>>> Note: The system can't use the generic "snps,dwc2" compatible
>>> because of the special ahbcfg configuration. The default
>>> GAHBCFG_HBSTLEN_INCR4 of snps,dwc2 can cause a system hang
>>> when the USB and SATA is used concurrently.
>>>
>>> Cc: Felipe Balbi <felipe.balbi@linux.intel.com>
>>> Cc: John Youn <johnyoun@synopsys.com>
>>> Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
>>> ---
>>> v1->v2:
>>> - moved definitons to params.c
>>> - removed dma_enable / host_dma parameter
>>> - added dma_desc_fs_enable parameter
>>> v2->v3:
>>> - removed parameters
>>>
>>> Please queue this patch until GAHBCFG_HBSTLEN_INCR16 is the default
>>> for ahbcfg.
>>> ---
>>> Documentation/devicetree/bindings/usb/dwc2.txt | 1 +
>>> drivers/usb/dwc2/params.c | 1 +
>>> 2 files changed, 2 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/usb/dwc2.txt b/Documentation/devicetree/bindings/usb/dwc2.txt
>>> index 10a2a4b..6ccfe85 100644
>>> --- a/Documentation/devicetree/bindings/usb/dwc2.txt
>>> +++ b/Documentation/devicetree/bindings/usb/dwc2.txt
>>> @@ -12,6 +12,7 @@ Required properties:
>>> - "lantiq,xrx200-usb": The DWC2 USB controller instance in Lantiq XRX SoCs;
>>> - "amlogic,meson8b-usb": The DWC2 USB controller instance in Amlogic Meson8b SoCs;
>>> - "amlogic,meson-gxbb-usb": The DWC2 USB controller instance in Amlogic S905 SoCs;
>>> + - "amcc,dwc-otg": The DWC2 USB controller instance in AMCC Canyonlands 460EX SoCs;
>>> - snps,dwc2: A generic DWC2 USB controller with default parameters.
>>> - reg : Should contain 1 register range (address and length)
>>> - interrupts : Should contain 1 interrupt
>>> diff --git a/drivers/usb/dwc2/params.c b/drivers/usb/dwc2/params.c
>>> index 64d5c66..9506ab0 100644
>>> --- a/drivers/usb/dwc2/params.c
>>> +++ b/drivers/usb/dwc2/params.c
>>> @@ -239,6 +239,7 @@ const struct of_device_id dwc2_of_match_table[] = {
>>> { .compatible = "samsung,s3c6400-hsotg", .data = NULL},
>>> { .compatible = "amlogic,meson8b-usb", .data = ¶ms_amlogic },
>>> { .compatible = "amlogic,meson-gxbb-usb", .data = ¶ms_amlogic },
>>> + { .compatible = "amcc,dwc-otg", .data = NULL },
>>> {},
>>> };
>>> MODULE_DEVICE_TABLE(of, dwc2_of_match_table);
>>>
For dwc2 part:
Acked-by: John Youn <johnyoun@synopsys.com>
Regards,
John
^ permalink raw reply
* Re: [PATCH 2/2] usb: dwc2: fixes host_dma logic
From: John Youn @ 2016-11-14 22:53 UTC (permalink / raw)
To: Christian Lamparter,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
Cc: John Youn, Mark Rutland, Rob Herring, Greg Kroah-Hartman,
Felipe Balbi
In-Reply-To: <4043f817106c8dffdc9a3f411d965465168b263d.1478897792.git.chunkeey-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On 11/11/2016 12:59 PM, Christian Lamparter wrote:
> This patch moves the the host_dma initialization
> before dwc2_set_param_dma_desc_enable and
> dwc2_set_param_dma_desc_fs_enable. The reason being
> that both function need it.
>
> Fixes: 1205489cee75bf39 ("usb: dwc2: Get host DMA device properties")
This should probably be omitted since it's only in Felipe's
testing/next.
Otherwise looks good.
Acked-by: John Youn <johnyoun-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
Regards,
John
>
> Cc: John Youn <johnyoun-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
> Cc: Felipe Balbi <felipe.balbi-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
> Signed-off-by: Christian Lamparter <chunkeey-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> drivers/usb/dwc2/params.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/usb/dwc2/params.c b/drivers/usb/dwc2/params.c
> index 5d822c5..222a83c 100644
> --- a/drivers/usb/dwc2/params.c
> +++ b/drivers/usb/dwc2/params.c
> @@ -1157,9 +1157,6 @@ static void dwc2_set_parameters(struct dwc2_hsotg *hsotg,
> bool dma_capable = !(hw->arch == GHWCFG2_SLAVE_ONLY_ARCH);
>
> dwc2_set_param_otg_cap(hsotg, params->otg_cap);
> - dwc2_set_param_dma_desc_enable(hsotg, params->dma_desc_enable);
> - dwc2_set_param_dma_desc_fs_enable(hsotg, params->dma_desc_fs_enable);
> -
> if ((hsotg->dr_mode == USB_DR_MODE_HOST) ||
> (hsotg->dr_mode == USB_DR_MODE_OTG)) {
> bool disable;
> @@ -1174,6 +1171,8 @@ static void dwc2_set_parameters(struct dwc2_hsotg *hsotg,
> !disable, false,
> dma_capable);
> }
> + dwc2_set_param_dma_desc_enable(hsotg, params->dma_desc_enable);
> + dwc2_set_param_dma_desc_fs_enable(hsotg, params->dma_desc_fs_enable);
>
> dwc2_set_param_host_support_fs_ls_low_power(hsotg,
> params->host_support_fs_ls_low_power);
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RESEND PATCH 1/2] PCI: rockchip: cleanup bit definition for PCIE_RC_CONFIG_LCS
From: Bjorn Helgaas @ 2016-11-14 22:50 UTC (permalink / raw)
To: Shawn Lin
Cc: Bjorn Helgaas, Rob Herring, linux-pci-u79uwXL29TY76Z2rM5mHXA,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Wenrui Li,
Brian Norris, Jeffy Chen, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1479096666-112668-1-git-send-email-shawn.lin-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
On Mon, Nov 14, 2016 at 12:11:05PM +0800, Shawn Lin wrote:
> PCIE_RC_CONFIG_LCS contains control and status bits specific
> to the PCIe link. The layout for this register looks the same
> as the existed PCI_EXP_LNKCTL and PCI_EXP_LNKSTA. So let's
> reuse them.
>
> Signed-off-by: Shawn Lin <shawn.lin-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
I applied both to pci/host-rockchip, thanks!
> ---
>
> drivers/pci/host/pcie-rockchip.c | 14 ++++----------
> 1 file changed, 4 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/pci/host/pcie-rockchip.c b/drivers/pci/host/pcie-rockchip.c
> index 7f238af..1dba698 100644
> --- a/drivers/pci/host/pcie-rockchip.c
> +++ b/drivers/pci/host/pcie-rockchip.c
> @@ -141,12 +141,6 @@
> #define PCIE_RC_CONFIG_DCR_CSPL_LIMIT 0xff
> #define PCIE_RC_CONFIG_DCR_CPLS_SHIFT 26
> #define PCIE_RC_CONFIG_LCS (PCIE_RC_CONFIG_BASE + 0xd0)
> -#define PCIE_RC_CONFIG_LCS_RETRAIN_LINK BIT(5)
> -#define PCIE_RC_CONFIG_LCS_CCC BIT(6)
> -#define PCIE_RC_CONFIG_LCS_LBMIE BIT(10)
> -#define PCIE_RC_CONFIG_LCS_LABIE BIT(11)
> -#define PCIE_RC_CONFIG_LCS_LBMS BIT(30)
> -#define PCIE_RC_CONFIG_LCS_LAMS BIT(31)
> #define PCIE_RC_CONFIG_L1_SUBSTATE_CTRL2 (PCIE_RC_CONFIG_BASE + 0x90c)
> #define PCIE_RC_CONFIG_THP_CAP (PCIE_RC_CONFIG_BASE + 0x274)
> #define PCIE_RC_CONFIG_THP_CAP_NEXT_MASK GENMASK(31, 20)
> @@ -229,7 +223,7 @@ static void rockchip_pcie_enable_bw_int(struct rockchip_pcie *rockchip)
> u32 status;
>
> status = rockchip_pcie_read(rockchip, PCIE_RC_CONFIG_LCS);
> - status |= (PCIE_RC_CONFIG_LCS_LBMIE | PCIE_RC_CONFIG_LCS_LABIE);
> + status |= (PCI_EXP_LNKCTL_LBMIE | PCI_EXP_LNKCTL_LABIE);
> rockchip_pcie_write(rockchip, status, PCIE_RC_CONFIG_LCS);
> }
>
> @@ -238,7 +232,7 @@ static void rockchip_pcie_clr_bw_int(struct rockchip_pcie *rockchip)
> u32 status;
>
> status = rockchip_pcie_read(rockchip, PCIE_RC_CONFIG_LCS);
> - status |= (PCIE_RC_CONFIG_LCS_LBMS | PCIE_RC_CONFIG_LCS_LAMS);
> + status |= (PCI_EXP_LNKSTA_LBMS | PCI_EXP_LNKSTA_LABS) << 16;
> rockchip_pcie_write(rockchip, status, PCIE_RC_CONFIG_LCS);
> }
>
> @@ -540,7 +534,7 @@ static int rockchip_pcie_init_port(struct rockchip_pcie *rockchip)
>
> /* Set RC's clock architecture as common clock */
> status = rockchip_pcie_read(rockchip, PCIE_RC_CONFIG_LCS);
> - status |= PCIE_RC_CONFIG_LCS_CCC;
> + status |= PCI_EXP_LNKCTL_CCC;
> rockchip_pcie_write(rockchip, status, PCIE_RC_CONFIG_LCS);
>
> /* Enable Gen1 training */
> @@ -575,7 +569,7 @@ static int rockchip_pcie_init_port(struct rockchip_pcie *rockchip)
> * gen1 finished.
> */
> status = rockchip_pcie_read(rockchip, PCIE_RC_CONFIG_LCS);
> - status |= PCIE_RC_CONFIG_LCS_RETRAIN_LINK;
> + status |= PCI_EXP_LNKCTL_RL;
> rockchip_pcie_write(rockchip, status, PCIE_RC_CONFIG_LCS);
>
> timeout = jiffies + msecs_to_jiffies(500);
> --
> 1.9.1
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RESEND PATCH 1/2] PCI: rockchip: cleanup bit definition for PCIE_RC_CONFIG_LCS
From: Bjorn Helgaas @ 2016-11-14 22:26 UTC (permalink / raw)
To: Shawn Lin
Cc: Bjorn Helgaas, Rob Herring, linux-pci-u79uwXL29TY76Z2rM5mHXA,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Wenrui Li,
Brian Norris, Jeffy Chen, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1479096666-112668-1-git-send-email-shawn.lin-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
On Mon, Nov 14, 2016 at 12:11:05PM +0800, Shawn Lin wrote:
> PCIE_RC_CONFIG_LCS contains control and status bits specific
> to the PCIe link. The layout for this register looks the same
> as the existed PCI_EXP_LNKCTL and PCI_EXP_LNKSTA. So let's
> reuse them.
>
> Signed-off-by: Shawn Lin <shawn.lin-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
Did something change since the version you posted yesterday?
Resending a patch with no changes or with no hint about what changed
doesn't speed things up; in fact, it slows things down.
> ---
>
> drivers/pci/host/pcie-rockchip.c | 14 ++++----------
> 1 file changed, 4 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/pci/host/pcie-rockchip.c b/drivers/pci/host/pcie-rockchip.c
> index 7f238af..1dba698 100644
> --- a/drivers/pci/host/pcie-rockchip.c
> +++ b/drivers/pci/host/pcie-rockchip.c
> @@ -141,12 +141,6 @@
> #define PCIE_RC_CONFIG_DCR_CSPL_LIMIT 0xff
> #define PCIE_RC_CONFIG_DCR_CPLS_SHIFT 26
> #define PCIE_RC_CONFIG_LCS (PCIE_RC_CONFIG_BASE + 0xd0)
> -#define PCIE_RC_CONFIG_LCS_RETRAIN_LINK BIT(5)
> -#define PCIE_RC_CONFIG_LCS_CCC BIT(6)
> -#define PCIE_RC_CONFIG_LCS_LBMIE BIT(10)
> -#define PCIE_RC_CONFIG_LCS_LABIE BIT(11)
> -#define PCIE_RC_CONFIG_LCS_LBMS BIT(30)
> -#define PCIE_RC_CONFIG_LCS_LAMS BIT(31)
> #define PCIE_RC_CONFIG_L1_SUBSTATE_CTRL2 (PCIE_RC_CONFIG_BASE + 0x90c)
> #define PCIE_RC_CONFIG_THP_CAP (PCIE_RC_CONFIG_BASE + 0x274)
> #define PCIE_RC_CONFIG_THP_CAP_NEXT_MASK GENMASK(31, 20)
> @@ -229,7 +223,7 @@ static void rockchip_pcie_enable_bw_int(struct rockchip_pcie *rockchip)
> u32 status;
>
> status = rockchip_pcie_read(rockchip, PCIE_RC_CONFIG_LCS);
> - status |= (PCIE_RC_CONFIG_LCS_LBMIE | PCIE_RC_CONFIG_LCS_LABIE);
> + status |= (PCI_EXP_LNKCTL_LBMIE | PCI_EXP_LNKCTL_LABIE);
> rockchip_pcie_write(rockchip, status, PCIE_RC_CONFIG_LCS);
> }
>
> @@ -238,7 +232,7 @@ static void rockchip_pcie_clr_bw_int(struct rockchip_pcie *rockchip)
> u32 status;
>
> status = rockchip_pcie_read(rockchip, PCIE_RC_CONFIG_LCS);
> - status |= (PCIE_RC_CONFIG_LCS_LBMS | PCIE_RC_CONFIG_LCS_LAMS);
> + status |= (PCI_EXP_LNKSTA_LBMS | PCI_EXP_LNKSTA_LABS) << 16;
> rockchip_pcie_write(rockchip, status, PCIE_RC_CONFIG_LCS);
> }
>
> @@ -540,7 +534,7 @@ static int rockchip_pcie_init_port(struct rockchip_pcie *rockchip)
>
> /* Set RC's clock architecture as common clock */
> status = rockchip_pcie_read(rockchip, PCIE_RC_CONFIG_LCS);
> - status |= PCIE_RC_CONFIG_LCS_CCC;
> + status |= PCI_EXP_LNKCTL_CCC;
> rockchip_pcie_write(rockchip, status, PCIE_RC_CONFIG_LCS);
>
> /* Enable Gen1 training */
> @@ -575,7 +569,7 @@ static int rockchip_pcie_init_port(struct rockchip_pcie *rockchip)
> * gen1 finished.
> */
> status = rockchip_pcie_read(rockchip, PCIE_RC_CONFIG_LCS);
> - status |= PCIE_RC_CONFIG_LCS_RETRAIN_LINK;
> + status |= PCI_EXP_LNKCTL_RL;
> rockchip_pcie_write(rockchip, status, PCIE_RC_CONFIG_LCS);
>
> timeout = jiffies + msecs_to_jiffies(500);
> --
> 1.9.1
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 2/3] PCI: qcom: add support to msm8996 PCIE controller
From: Bjorn Helgaas @ 2016-11-14 22:23 UTC (permalink / raw)
To: Srinivas Kandagatla
Cc: svarbanov-NEYub+7Iv8PQT0dZR+AlfA,
linux-pci-u79uwXL29TY76Z2rM5mHXA, bhelgaas-hpIqsD4AKlfQT0dZR+AlfA,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1479122155-13393-3-git-send-email-srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On Mon, Nov 14, 2016 at 11:15:54AM +0000, Srinivas Kandagatla wrote:
> This patch adds support to msm8996/apq8096 pcie, MSM8996 supports
> Gen 1/2, One lane, 3 pcie root-complex with support to MSI and
> legacy interrupts and it conforms to PCI Express Base 2.1 specification.
>
> This patch adds post_init callback to qcom_pcie_ops, as this is pcie
> pipe clocks are only setup after the phy is powered on.
> It also adds ltssm_enable callback as it is very much different to other
> supported SOCs in the driver.
>
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Will need ack from Stanimir before I can apply it.
> ---
> .../devicetree/bindings/pci/qcom,pcie.txt | 67 +++++++-
> drivers/pci/host/pcie-qcom.c | 177 ++++++++++++++++++++-
> 2 files changed, 238 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie.txt b/Documentation/devicetree/bindings/pci/qcom,pcie.txt
> index 4059a6f..141d8c3 100644
> --- a/Documentation/devicetree/bindings/pci/qcom,pcie.txt
> +++ b/Documentation/devicetree/bindings/pci/qcom,pcie.txt
> @@ -7,6 +7,7 @@
> - "qcom,pcie-ipq8064" for ipq8064
> - "qcom,pcie-apq8064" for apq8064
> - "qcom,pcie-apq8084" for apq8084
> + - "qcom,pcie-msm8996" for msm8996 or apq8096
>
> - reg:
> Usage: required
> @@ -92,6 +93,17 @@
> - "aux" Auxiliary (AUX) clock
> - "bus_master" Master AXI clock
> - "bus_slave" Slave AXI clock
> +
> +- clock-names:
> + Usage: required for msm8996/apq8096
> + Value type: <stringlist>
> + Definition: Should contain the following entries
> + - "pipe" Pipe Clock driving internal logic.
> + - "aux" Auxiliary (AUX) clock.
> + - "cfg" Configuration clk.
> + - "bus_master" Master AXI clock.
> + - "bus_slave" Slave AXI clock.
> +
> - resets:
> Usage: required
> Value type: <prop-encoded-array>
> @@ -115,7 +127,7 @@
> - "core" Core reset
>
> - power-domains:
> - Usage: required for apq8084
> + Usage: required for apq8084 and msm8996/apq8096
> Value type: <prop-encoded-array>
> Definition: A phandle and power domain specifier pair to the
> power domain which is responsible for collapsing
> @@ -231,3 +243,56 @@
> pinctrl-0 = <&pcie0_pins_default>;
> pinctrl-names = "default";
> };
> +
> +* Example for apq8096:
> +
> + pcie@608000{
> + compatible = "qcom,pcie-msm8996", "snps,dw-pcie";
> + power-domains = <&gcc PCIE1_GDSC>;
> + bus-range = <0x00 0xff>;
> + num-lanes = <1>;
> +
> + reg = <0x00608000 0x2000>,
> + <0x0d000000 0xf1d>,
> + <0x0d000f20 0xa8>,
> + <0x0d100000 0x100000>;
> +
> + reg-names = "parf", "dbi", "elbi", "config";
> +
> + phys = <&pcie_phy 1>;
> + phy-names = "pciephy";
> +
> + #address-cells = <3>;
> + #size-cells = <2>;
> + ranges = <0x01000000 0x0 0x0d200000 0x0d200000 0x0 0x100000>,
> + <0x02000000 0x0 0x0d300000 0x0d300000 0x0 0xd00000>;
> +
> + interrupts = <GIC_SPI 413 IRQ_TYPE_NONE>;
> + interrupt-names = "msi";
> + #interrupt-cells = <1>;
> + interrupt-map-mask = <0 0 0 0x7>;
> + interrupt-map = <0 0 0 1 &intc 0 272 IRQ_TYPE_LEVEL_HIGH>, /* int_a */
> + <0 0 0 2 &intc 0 273 IRQ_TYPE_LEVEL_HIGH>, /* int_b */
> + <0 0 0 3 &intc 0 274 IRQ_TYPE_LEVEL_HIGH>, /* int_c */
> + <0 0 0 4 &intc 0 275 IRQ_TYPE_LEVEL_HIGH>; /* int_d */
> +
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <&pcie1_clkreq_default &pcie1_perst_default &pcie1_wake_default>;
> + pinctrl-1 = <&pcie1_clkreq_sleep &pcie1_perst_default &pcie1_wake_sleep>;
> +
> + vdda-1p8-supply = <&pm8994_l12>;
> + vdda-supply = <&pm8994_l28>;
> + linux,pci-domain = <1>;
> +
> + clocks = <&gcc GCC_PCIE_1_PIPE_CLK>,
> + <&gcc GCC_PCIE_1_AUX_CLK>,
> + <&gcc GCC_PCIE_1_CFG_AHB_CLK>,
> + <&gcc GCC_PCIE_1_MSTR_AXI_CLK>,
> + <&gcc GCC_PCIE_1_SLV_AXI_CLK>;
> +
> + clock-names = "pipe",
> + "aux",
> + "cfg",
> + "bus_master",
> + "bus_slave";
> + };
> diff --git a/drivers/pci/host/pcie-qcom.c b/drivers/pci/host/pcie-qcom.c
> index 3593640..03ba6b1 100644
> --- a/drivers/pci/host/pcie-qcom.c
> +++ b/drivers/pci/host/pcie-qcom.c
> @@ -36,11 +36,19 @@
>
> #include "pcie-designware.h"
>
> +#define PCIE20_PARF_DBI_BASE_ADDR 0x168
> +
> +#define PCIE20_PARF_SYS_CTRL 0x00
> #define PCIE20_PARF_PHY_CTRL 0x40
> #define PCIE20_PARF_PHY_REFCLK 0x4C
> #define PCIE20_PARF_DBI_BASE_ADDR 0x168
> #define PCIE20_PARF_SLV_ADDR_SPACE_SIZE 0x16c
> +#define PCIE20_PARF_MHI_CLOCK_RESET_CTRL 0x174
> #define PCIE20_PARF_AXI_MSTR_WR_ADDR_HALT 0x178
> +#define MSM8996_PCIE20_PARF_AXI_MSTR_WR_ADDR_HALT 0x1A8
> +#define PCIE20_PARF_LTSSM 0x1B0
> +#define PCIE20_PARF_SID_OFFSET 0x234
> +#define PCIE20_PARF_BDF_TRANSLATE_CFG 0x24C
>
> #define PCIE20_ELBI_SYS_CTRL 0x04
> #define PCIE20_ELBI_SYS_CTRL_LT_ENABLE BIT(0)
> @@ -72,9 +80,18 @@ struct qcom_pcie_resources_v1 {
> struct regulator *vdda;
> };
>
> +struct qcom_pcie_resources_v2 {
> + struct clk *aux_clk;
> + struct clk *master_clk;
> + struct clk *slave_clk;
> + struct clk *cfg_clk;
> + struct clk *pipe_clk;
> +};
> +
> union qcom_pcie_resources {
> struct qcom_pcie_resources_v0 v0;
> struct qcom_pcie_resources_v1 v1;
> + struct qcom_pcie_resources_v2 v2;
> };
>
> struct qcom_pcie;
> @@ -82,7 +99,9 @@ struct qcom_pcie;
> struct qcom_pcie_ops {
> int (*get_resources)(struct qcom_pcie *pcie);
> int (*init)(struct qcom_pcie *pcie);
> + int (*post_init)(struct qcom_pcie *pcie);
> void (*deinit)(struct qcom_pcie *pcie);
> + void (*ltssm_enable)(struct qcom_pcie *pcie);
> };
>
> struct qcom_pcie {
> @@ -116,17 +135,33 @@ static irqreturn_t qcom_pcie_msi_irq_handler(int irq, void *arg)
> return dw_handle_msi_irq(pp);
> }
>
> -static int qcom_pcie_establish_link(struct qcom_pcie *pcie)
> +static void qcom_pcie_v0_v1_ltssm_enable(struct qcom_pcie *pcie)
> {
> u32 val;
> -
> - if (dw_pcie_link_up(&pcie->pp))
> - return 0;
> -
> /* enable link training */
> val = readl(pcie->elbi + PCIE20_ELBI_SYS_CTRL);
> val |= PCIE20_ELBI_SYS_CTRL_LT_ENABLE;
> writel(val, pcie->elbi + PCIE20_ELBI_SYS_CTRL);
> +}
> +
> +static void qcom_pcie_v2_ltssm_enable(struct qcom_pcie *pcie)
> +{
> + u32 val;
> + /* enable link training */
> + val = readl(pcie->parf + PCIE20_PARF_LTSSM);
> + val |= BIT(8);
> + writel(val, pcie->parf + PCIE20_PARF_LTSSM);
> +}
> +
> +static int qcom_pcie_establish_link(struct qcom_pcie *pcie)
> +{
> +
> + if (dw_pcie_link_up(&pcie->pp))
> + return 0;
> +
> + /* Enable Link Training state machine */
> + if (pcie->ops->ltssm_enable)
> + pcie->ops->ltssm_enable(pcie);
>
> return dw_pcie_wait_for_link(&pcie->pp);
> }
> @@ -421,6 +456,113 @@ static int qcom_pcie_init_v1(struct qcom_pcie *pcie)
> return ret;
> }
>
> +static int qcom_pcie_get_resources_v2(struct qcom_pcie *pcie)
> +{
> + struct qcom_pcie_resources_v2 *res = &pcie->res.v2;
> + struct device *dev = pcie->pp.dev;
> +
> + res->aux_clk = devm_clk_get(dev, "aux");
> + if (IS_ERR(res->aux_clk))
> + return PTR_ERR(res->aux_clk);
> +
> + res->cfg_clk = devm_clk_get(dev, "cfg");
> + if (IS_ERR(res->cfg_clk))
> + return PTR_ERR(res->cfg_clk);
> +
> + res->master_clk = devm_clk_get(dev, "bus_master");
> + if (IS_ERR(res->master_clk))
> + return PTR_ERR(res->master_clk);
> +
> + res->slave_clk = devm_clk_get(dev, "bus_slave");
> + if (IS_ERR(res->slave_clk))
> + return PTR_ERR(res->slave_clk);
> +
> + res->pipe_clk = devm_clk_get(dev, "pipe");
> + if (IS_ERR(res->pipe_clk))
> + return PTR_ERR(res->pipe_clk);
> +
> + return 0;
> +}
> +
> +static int qcom_pcie_init_v2(struct qcom_pcie *pcie)
> +{
> + struct qcom_pcie_resources_v2 *res = &pcie->res.v2;
> + struct device *dev = pcie->pp.dev;
> + u32 val;
> + int ret;
> +
> + ret = clk_prepare_enable(res->aux_clk);
> + if (ret) {
> + dev_err(dev, "cannot prepare/enable aux clock\n");
> + return ret;
> + }
> +
> + ret = clk_prepare_enable(res->cfg_clk);
> + if (ret) {
> + dev_err(dev, "cannot prepare/enable cfg clock\n");
> + goto err_cfg_clk;
> + }
> +
> + ret = clk_prepare_enable(res->master_clk);
> + if (ret) {
> + dev_err(dev, "cannot prepare/enable master clock\n");
> + goto err_master_clk;
> + }
> +
> + ret = clk_prepare_enable(res->slave_clk);
> + if (ret) {
> + dev_err(dev, "cannot prepare/enable slave clock\n");
> + goto err_slave_clk;
> + }
> +
> + /* enable PCIe clocks and resets */
> + val = readl(pcie->parf + PCIE20_PARF_PHY_CTRL);
> + val &= ~BIT(0);
> + writel(val, pcie->parf + PCIE20_PARF_PHY_CTRL);
> +
> + /* change DBI base address */
> + writel(0, pcie->parf + PCIE20_PARF_DBI_BASE_ADDR);
> +
> + /* MAC PHY_POWERDOWN MUX DISABLE */
> + val = readl(pcie->parf + PCIE20_PARF_SYS_CTRL);
> + val &= ~BIT(29);
> + writel(val, pcie->parf + PCIE20_PARF_SYS_CTRL);
> +
> + val = readl(pcie->parf + PCIE20_PARF_MHI_CLOCK_RESET_CTRL);
> + val |= BIT(4);
> + writel(val, pcie->parf + PCIE20_PARF_MHI_CLOCK_RESET_CTRL);
> +
> + val = readl(pcie->parf + MSM8996_PCIE20_PARF_AXI_MSTR_WR_ADDR_HALT);
> + val |= BIT(31);
> + writel(val, pcie->parf + MSM8996_PCIE20_PARF_AXI_MSTR_WR_ADDR_HALT);
> +
> + return 0;
> +
> +err_slave_clk:
> + clk_disable_unprepare(res->master_clk);
> +err_master_clk:
> + clk_disable_unprepare(res->cfg_clk);
> +err_cfg_clk:
> + clk_disable_unprepare(res->aux_clk);
> +
> + return ret;
> +}
> +
> +static int qcom_pcie_post_init_v2(struct qcom_pcie *pcie)
> +{
> + struct qcom_pcie_resources_v2 *res = &pcie->res.v2;
> + struct device *dev = pcie->pp.dev;
> + int ret;
> +
> + ret = clk_prepare_enable(res->pipe_clk);
> + if (ret) {
> + dev_err(dev, "cannot prepare/enable pipe clock\n");
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> static int qcom_pcie_link_up(struct pcie_port *pp)
> {
> struct qcom_pcie *pcie = to_qcom_pcie(pp);
> @@ -429,6 +571,17 @@ static int qcom_pcie_link_up(struct pcie_port *pp)
> return !!(val & PCI_EXP_LNKSTA_DLLLA);
> }
>
> +static void qcom_pcie_deinit_v2(struct qcom_pcie *pcie)
> +{
> + struct qcom_pcie_resources_v2 *res = &pcie->res.v2;
> +
> + clk_disable_unprepare(res->pipe_clk);
> + clk_disable_unprepare(res->slave_clk);
> + clk_disable_unprepare(res->master_clk);
> + clk_disable_unprepare(res->cfg_clk);
> + clk_disable_unprepare(res->aux_clk);
> +}
> +
> static void qcom_pcie_host_init(struct pcie_port *pp)
> {
> struct qcom_pcie *pcie = to_qcom_pcie(pp);
> @@ -444,6 +597,9 @@ static void qcom_pcie_host_init(struct pcie_port *pp)
> if (ret)
> goto err_deinit;
>
> + if (pcie->ops->post_init)
> + pcie->ops->post_init(pcie);
> +
> dw_pcie_setup_rc(pp);
>
> if (IS_ENABLED(CONFIG_PCI_MSI))
> @@ -487,12 +643,22 @@ static const struct qcom_pcie_ops ops_v0 = {
> .get_resources = qcom_pcie_get_resources_v0,
> .init = qcom_pcie_init_v0,
> .deinit = qcom_pcie_deinit_v0,
> + .ltssm_enable = qcom_pcie_v0_v1_ltssm_enable,
> };
>
> static const struct qcom_pcie_ops ops_v1 = {
> .get_resources = qcom_pcie_get_resources_v1,
> .init = qcom_pcie_init_v1,
> .deinit = qcom_pcie_deinit_v1,
> + .ltssm_enable = qcom_pcie_v0_v1_ltssm_enable,
> +};
> +
> +static const struct qcom_pcie_ops ops_v2 = {
> + .get_resources = qcom_pcie_get_resources_v2,
> + .init = qcom_pcie_init_v2,
> + .post_init = qcom_pcie_post_init_v2,
> + .deinit = qcom_pcie_deinit_v2,
> + .ltssm_enable = qcom_pcie_v2_ltssm_enable,
> };
>
> static int qcom_pcie_probe(struct platform_device *pdev)
> @@ -572,6 +738,7 @@ static const struct of_device_id qcom_pcie_match[] = {
> { .compatible = "qcom,pcie-ipq8064", .data = &ops_v0 },
> { .compatible = "qcom,pcie-apq8064", .data = &ops_v0 },
> { .compatible = "qcom,pcie-apq8084", .data = &ops_v1 },
> + { .compatible = "qcom,pcie-msm8996", .data = &ops_v2 },
> { }
> };
>
> --
> 2.10.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RESEND/PATCH v6 3/3] clk: qcom: Add A53 clock driver
From: Stephen Boyd @ 2016-11-14 22:21 UTC (permalink / raw)
To: Georgi Djakov
Cc: Bjorn Andersson, mturquette-rdvid1DuHRBWk0Htik3J/w,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring
In-Reply-To: <549f87fe-7be9-14b4-8e34-86f7f8dad94e-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On 11/11, Georgi Djakov wrote:
> On 11/03/2016 08:28 PM, Bjorn Andersson wrote:
> >On Wed 02 Nov 15:55 PDT 2016, Stephen Boyd wrote:
> >
> >>On 11/02, Bjorn Andersson wrote:
> >>>On Thu 27 Oct 18:54 PDT 2016, Stephen Boyd wrote:
> >>>
> >>>>On 10/19, Georgi Djakov wrote:
> >>>>>Add a driver for the A53 Clock Controller. It is a hardware block that
> >>>>>implements a combined mux and half integer divider functionality. It can
> >>>>>choose between a fixed-rate clock or the dedicated A53 PLL. The source
> >>>>>and the divider can be set both at the same time.
> >>>>>
> >>>>>This is required for enabling CPU frequency scaling on platforms like
> >>>>>MSM8916.
> >>>>>
> >>>>
> >>>>Please Cc DT reviewers.
> >>>>
> >>>>>Signed-off-by: Georgi Djakov <georgi.djakov-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> >>>>>---
> >>>>> .../devicetree/bindings/clock/qcom,a53cc.txt | 22 +++
> >>>>> drivers/clk/qcom/Kconfig | 8 ++
> >>>>> drivers/clk/qcom/Makefile | 1 +
> >>>>> drivers/clk/qcom/a53cc.c | 155 +++++++++++++++++++++
> >>>>> 4 files changed, 186 insertions(+)
> >>>>> create mode 100644 Documentation/devicetree/bindings/clock/qcom,a53cc.txt
> >>>>> create mode 100644 drivers/clk/qcom/a53cc.c
> >>>>>
> >>>>>diff --git a/Documentation/devicetree/bindings/clock/qcom,a53cc.txt b/Documentation/devicetree/bindings/clock/qcom,a53cc.txt
> >>>>>new file mode 100644
> >>>>>index 000000000000..a025f062f177
> >>>>>--- /dev/null
> >>>>>+++ b/Documentation/devicetree/bindings/clock/qcom,a53cc.txt
> >>>>>@@ -0,0 +1,22 @@
> >>>>>+Qualcomm A53 CPU Clock Controller Binding
> >>>>>+------------------------------------------------
> >>>>>+The A53 CPU Clock Controller is hardware, which provides a combined
> >>>>>+mux and divider functionality for the CPU clocks. It can choose between
> >>>>>+a fixed rate clock and the dedicated A53 PLL.
> >>>>>+
> >>>>>+Required properties :
> >>>>>+- compatible : shall contain:
> >>>>>+
> >>>>>+ "qcom,a53cc"
> >>>>>+
> >>>>>+- reg : shall contain base register location and length
> >>>>>+ of the APCS region
> >>>>>+- #clock-cells : shall contain 1
> >>>>>+
> >>>>>+Example:
> >>>>>+
> >>>>>+ apcs: syscon@b011000 {
> >>>>>+ compatible = "qcom,a53cc", "syscon";
> >>>>
> >>>>Why is it a syscon? Is that part used?
> >>>>
> >>>
> >>>I use the register at offset 8 for interrupting the other subsystems, so
> >>>this must be available as something I can poke.
> >>>
> >>>Which makes me think that this should be described as a "simple-mfd" and
> >>>"syscon" with the a53cc node as a child - grabbing the regmap of the
> >>>syscon parent, rather then ioremapping the same region again.
> >>>
> >>
> >>That's sort of a question for DT reviewers. The register space
> >>certainly seems like a free for all with a tilt toward power
> >>management of the CPU, similar to how this was done on Krait
> >>based designs.
> >>
> >
> >Right. But this kind of mashup blocks was the reason why simple-mfd was
> >put in place.
> >
>
> Ok, thanks for the comments. Then i will make it look like this:
>
> apcs: syscon@b011000 {
> compatible = "syscon", "simple-mfd";
> reg = <0x0b011000 0x1000>;
>
> a53mux: clock {
> compatible = "qcom,msm8916-a53cc";
> #clock-cells = <1>;
> };
> };
>
> Thanks,
> Georgi
>
> >>I wonder why we didn't make up some provider/consumer binding for
> >>the "kicking" feature used by SMD/RPM code. Then this could be a
> >>clock provider and a "kick" provider (haha #kick-cells) and the
> >>usage of syscon/regmap wouldn't be mandatory.
> >>
> >
> >I did consider doing that, but had enough dependencies to put in place
> >as it was.
> >
> >I'm in favour of us inventing a kicker API and it's found outside out
> >use cases as well (e.g. virtio/rpmsg).
> >
I'd rather we did this kicker API as well. That way we don't need
to make a syscon and a simple-mfd to get software to work
properly. Don't other silicon vendors need a kicker API as well?
How are they kicking remote processors in other places? GPIOs?
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 2/2] of: changesets: Introduce changeset helper methods
From: Rob Herring @ 2016-11-14 22:16 UTC (permalink / raw)
To: Frank Rowand
Cc: Hans de Goede, Pantelis Antoniou,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <582A060D.50800-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Mon, Nov 14, 2016 at 12:44 PM, Frank Rowand <frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On 11/14/16 03:04, Hans de Goede wrote:
>> Hi,
>>
>> On 14-11-16 08:34, Frank Rowand wrote:
>>> Hi Hans, Pantelis,
>>>
>>> On 11/12/16 18:15, Frank Rowand wrote:
>>>> On 11/04/16 07:42, Hans de Goede wrote:
>>>>> From: Pantelis Antoniou <pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w@public.gmane.org>
>>>>>
>>>>> Changesets are very powerful, but the lack of a helper API
>>>>> makes using them cumbersome. Introduce a simple copy based
>>>>> API that makes things considerably easier.
>>>>>
>>>>> To wit, adding a property using the raw API.
>>>>>
>>>>> struct property *prop;
>>>>> prop = kzalloc(sizeof(*prop)), GFP_KERNEL);
>>>>> prop->name = kstrdup("compatible");
>>>>> prop->value = kstrdup("foo,bar");
>>>>> prop->length = strlen(prop->value) + 1;
>>>>> of_changeset_add_property(ocs, np, prop);
>>>>>
>>>>> while using the helper API
>>>>>
>>>>> of_changeset_add_property_string(ocs, np, "compatible",
>>>>> "foo,bar");
>>>>>
>>>>> Signed-off-by: Pantelis Antoniou <pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w@public.gmane.org>
>>>>> Signed-off-by: Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>>>>> ---
>>>>> Changes in v2 (hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org):
>>>>> -Address review comments from:
>>>>> https://www.spinics.net/lists/kernel/msg2252845.html
>>>>
>>>> That points to the May 9 version 1 patches from Pantelis (as expected),
>>>> but containing 4, not 2, patches. Patch 1/4 was applied. Patch 4/4
>>>> seems to have disappeared?
>>>>
>>>> Pantelis then sent a version 2 set of the patches on May 16.
>>>>
>>>> Your version is a modification of the May 9 patches (as would be expected
>>>> of a version 2). It is confusing to have two different version 2 patch
>>>> sets. I don't have any brilliant ideas on how this patch set could have
>>>> been named differently to avoid that confusion.
>>>>
>>>> The point of this little side-track is simply to note the existence of two
>>>> different version 2 series so I won't be confused when I revisit this
>>>> thread in the future.
>>>>
>>>>> -Simplify (and fix) __of_changeset_add_update_property_copy OOM handling
>>>>> -Remove (by manual inlining) these 2 static helpers:
>>>>> __of_changeset_add_update_property_u32
>>>>> __of_changeset_add_update_property_bool
>>>>> -Remove the following exported helper method:
>>>>> of_changeset_node_move_to
>>>>
>>>> Not all comments were addressed.
>>>>
>>>> There are some other changes made that are not noted in the changelog.
>>>>
>>>> I am still reading through the patches. I will reply again either with
>>>> a reviewed-by or specific comments when I finish.
>>>
>>> Replying here for the entire patchset (there was no patch 0 to reply to).
>>>
>>> After reading through the patches, my reply is meta instead of specific
>>> comments about the code.
>>>
>>> There are very few users of change sets in tree. I do not see the need to
>>> add these helpers until such users are likely to appear.
>>>
>>> I would expect change sets to be _mostly_ used internally by the device tree
>>> overlay framework, not directly by drivers. If change sets are an attractive
>>> technology for drivers, I want to approach that usage very carefully to avoid
>>> inappropriate use, which could be very difficult to reign in after the fact.
>>>
>>> Even if helpers should be added, this seems to be an overly complex approach.
>>> If the need for these helpers becomes apparent I can provide review comments
>>> with the specifics about how it appears to be overly complex.
>>>
>>> Can you please provide some more insights into the needs driving the desire
>>> to have change set helpers and the expected use cases of them? Please put
>>> your architect's hat on when replying to this question.
>>
>> My use case for this is discussed in this thread:
>> https://www.spinics.net/lists/arm-kernel/msg536111.html
>>
>> With the dt-bindings for the hardware-manager I want to add here:
>> https://www.spinics.net/lists/arm-kernel/msg536109.html
>>
>> Note that there is a lot of discussion in this thread whether or
>> not this belongs in the kernel. I strongly believe though that
>> some functionality like this will be needed in the kernel for
>> ARM+dt devices going forward, just like there is plenty of x86
>> code which adjusts itself to specific hardware, because whether
>> we like it or not hardware (revisions) will always have quirks.
>
> Thanks! That context should have been provided with the patches.
>
> The use case discussion is important and I am paying a lot of
> attention to that discussion and many other discussions about
> dynamic device trees. I don't think it makes sense to apply the
> change set helper patches yet, given the unsettled state of the
> various dynamic device tree discussions.
These helpers are useful and easier to use than the existing API
independent of any issues to sort out with how we use overlays. So I
plan to take them whether there's a user right away or not.
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 1/3] bus: simple-pm: add support to pm clocks
From: Bjorn Helgaas @ 2016-11-14 22:14 UTC (permalink / raw)
To: Srinivas Kandagatla
Cc: svarbanov, linux-pci, bhelgaas, robh+dt, linux-arm-msm,
devicetree, Geert Uytterhoeven, Kevin Hilman, Simon Horman
In-Reply-To: <1479122155-13393-2-git-send-email-srinivas.kandagatla@linaro.org>
[+cc Geert, Kevin, Simon]
On Mon, Nov 14, 2016 at 11:15:53AM +0000, Srinivas Kandagatla wrote:
> This patch adds support to pm clocks via device tree, so that the clocks
> can be turned on and off during runtime pm. This patch is required for
> Qualcomm msm8996 pcie controller which sits on a bus with its own
> power-domain and clocks.
>
> Without this patch the clock associated with the bus are never turned on.
>
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
I don't see a formal maintainer for drivers/bus/simple-pm-bus.c, but I'd
like an ack or at least a review from Geert or Simon.
> ---
> drivers/bus/simple-pm-bus.c | 13 ++++++++++++-
> 1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/bus/simple-pm-bus.c b/drivers/bus/simple-pm-bus.c
> index c5eb46c..63b7e8c 100644
> --- a/drivers/bus/simple-pm-bus.c
> +++ b/drivers/bus/simple-pm-bus.c
> @@ -11,6 +11,7 @@
> #include <linux/module.h>
> #include <linux/of_platform.h>
> #include <linux/platform_device.h>
> +#include <linux/pm_clock.h>
> #include <linux/pm_runtime.h>
>
>
> @@ -22,17 +23,26 @@ static int simple_pm_bus_probe(struct platform_device *pdev)
>
> pm_runtime_enable(&pdev->dev);
>
> - if (np)
> + if (np) {
> + of_pm_clk_add_clks(&pdev->dev);
> of_platform_populate(np, NULL, NULL, &pdev->dev);
> + }
>
> return 0;
> }
>
> +static const struct dev_pm_ops simple_pm_bus_pm_ops = {
> + SET_RUNTIME_PM_OPS(pm_clk_suspend,
> + pm_clk_resume, NULL)
> +};
> +
> static int simple_pm_bus_remove(struct platform_device *pdev)
> {
> dev_dbg(&pdev->dev, "%s\n", __func__);
>
> pm_runtime_disable(&pdev->dev);
> + pm_clk_destroy(&pdev->dev);
> +
> return 0;
> }
>
> @@ -48,6 +58,7 @@ static struct platform_driver simple_pm_bus_driver = {
> .driver = {
> .name = "simple-pm-bus",
> .of_match_table = simple_pm_bus_of_match,
> + .pm = &simple_pm_bus_pm_ops,
> },
> };
>
> --
> 2.10.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/5] pinctrl: core: Use delayed work for hogs
From: Tony Lindgren @ 2016-11-14 22:08 UTC (permalink / raw)
To: Linus Walleij
Cc: Haojian Zhuang, Masahiro Yamada, Grygorii Strashko,
Nishanth Menon,
linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux-OMAP
In-Reply-To: <20161114205243.GU7138-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
* Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> [161114 12:54]:
> * Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> [161111 12:27]:
> > * Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> [161111 12:17]:
> > > On Tue, Oct 25, 2016 at 11:02 PM, Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> wrote:
> > > > Signed-off-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
> > >
> > > I don't see why this is necessary?
> >
> > It's needed because the pin controller driver has not yet
> > finished it's probe at this point. We end up calling functions
> > in the device driver where no struct pinctrl_dev is yet known
> > to the driver. Asking a device driver to do something before
> > it's probe is done does not quite follow the Linux driver model :)
> >
> > > The hogging was placed inside pinctrl_register() so that any hogs
> > > would be taken before it returns, so nothing else can take it
> > > before the controller itself has the first chance. This semantic
> > > needs to be preserved I think.
> > >
> > > > + schedule_delayed_work(&pctldev->hog_work,
> > > > + msecs_to_jiffies(100));
> > >
> > > If we arbitrarily delay, something else can go in and take the
> > > pins used by the hogs before the pinctrl core? That is what
> > > we want to avoid.
> > >
> > > Hm, 100ms seems arbitrarily chosen BTW. Can it be 1 ms?
> > > 1 ns?
> >
> > Yeah well seems like it should not matter but the race we need
> > to remove somehow.
> >
> > > I'm pretty sure that whatever it is that needs to happen before
> > > the hog work runs can race with this delayed work under
> > > some circumstances (such as slow external expanders
> > > on i2c). It should be impossible for that to happen
> > > and I don't think it is?
> >
> > Yes it's totally possible even with delay set to 0.
> >
> > Maybe we could add some trigger on the first consumer request
> > and if that does not happen use the timer?
>
> Below is what I came up with for removing the race for hogs. We
> can do it by not registering the pctldev until in the deferred
> work, does that seem OK to you?
Oops, that does not yet work, will have to look into it more.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v7 5/5] dt: add documentation of "hotpluggable" memory property
From: Reza Arbab @ 2016-11-14 22:02 UTC (permalink / raw)
To: Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras,
Andrew Morton, Rob Herring, Frank Rowand, Thomas Gleixner,
Ingo Molnar, H. Peter Anvin
Cc: linuxppc-dev, linux-mm, devicetree, Bharata B Rao,
Nathan Fontenot, Stewart Smith, Alistair Popple, Balbir Singh,
Aneesh Kumar K.V, linux-kernel
In-Reply-To: <1479160961-25840-1-git-send-email-arbab@linux.vnet.ibm.com>
Summarize the "hotpluggable" property of dt memory nodes.
Signed-off-by: Reza Arbab <arbab@linux.vnet.ibm.com>
---
Documentation/devicetree/booting-without-of.txt | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/Documentation/devicetree/booting-without-of.txt b/Documentation/devicetree/booting-without-of.txt
index 3f1437f..280d283 100644
--- a/Documentation/devicetree/booting-without-of.txt
+++ b/Documentation/devicetree/booting-without-of.txt
@@ -974,6 +974,13 @@ compatibility.
4Gb. Some vendors prefer splitting those ranges into smaller
segments, but the kernel doesn't care.
+ Additional properties:
+
+ - hotpluggable : The presence of this property provides an explicit
+ hint to the operating system that this memory may potentially be
+ removed later. The kernel can take this into consideration when
+ doing nonmovable allocations and when laying out memory zones.
+
e) The /chosen node
This node is a bit "special". Normally, that's where Open Firmware
--
1.8.3.1
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related
* [PATCH v7 4/5] of/fdt: mark hotpluggable memory
From: Reza Arbab @ 2016-11-14 22:02 UTC (permalink / raw)
To: Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras,
Andrew Morton, Rob Herring, Frank Rowand, Thomas Gleixner,
Ingo Molnar, H. Peter Anvin
Cc: linuxppc-dev, linux-mm, devicetree, Bharata B Rao,
Nathan Fontenot, Stewart Smith, Alistair Popple, Balbir Singh,
Aneesh Kumar K.V, linux-kernel
In-Reply-To: <1479160961-25840-1-git-send-email-arbab@linux.vnet.ibm.com>
When movable nodes are enabled, any node containing only hotpluggable
memory is made movable at boot time.
On x86, hotpluggable memory is discovered by parsing the ACPI SRAT,
making corresponding calls to memblock_mark_hotplug().
If we introduce a dt property to describe memory as hotpluggable,
configs supporting early fdt may then also do this marking and use
movable nodes.
Signed-off-by: Reza Arbab <arbab@linux.vnet.ibm.com>
Tested-by: Balbir Singh <bsingharora@gmail.com>
---
drivers/of/fdt.c | 19 +++++++++++++++++++
include/linux/of_fdt.h | 1 +
mm/Kconfig | 2 +-
3 files changed, 21 insertions(+), 1 deletion(-)
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index c89d5d2..c9b5cac 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -1015,6 +1015,7 @@ int __init early_init_dt_scan_memory(unsigned long node, const char *uname,
const char *type = of_get_flat_dt_prop(node, "device_type", NULL);
const __be32 *reg, *endp;
int l;
+ bool hotpluggable;
/* We are scanning "memory" nodes only */
if (type == NULL) {
@@ -1034,6 +1035,7 @@ int __init early_init_dt_scan_memory(unsigned long node, const char *uname,
return 0;
endp = reg + (l / sizeof(__be32));
+ hotpluggable = of_get_flat_dt_prop(node, "hotpluggable", NULL);
pr_debug("memory scan node %s, reg size %d,\n", uname, l);
@@ -1049,6 +1051,13 @@ int __init early_init_dt_scan_memory(unsigned long node, const char *uname,
(unsigned long long)size);
early_init_dt_add_memory_arch(base, size);
+
+ if (!hotpluggable)
+ continue;
+
+ if (early_init_dt_mark_hotplug_memory_arch(base, size))
+ pr_warn("failed to mark hotplug range 0x%llx - 0x%llx\n",
+ base, base + size);
}
return 0;
@@ -1146,6 +1155,11 @@ void __init __weak early_init_dt_add_memory_arch(u64 base, u64 size)
memblock_add(base, size);
}
+int __init __weak early_init_dt_mark_hotplug_memory_arch(u64 base, u64 size)
+{
+ return memblock_mark_hotplug(base, size);
+}
+
int __init __weak early_init_dt_reserve_memory_arch(phys_addr_t base,
phys_addr_t size, bool nomap)
{
@@ -1168,6 +1182,11 @@ void __init __weak early_init_dt_add_memory_arch(u64 base, u64 size)
WARN_ON(1);
}
+int __init __weak early_init_dt_mark_hotplug_memory_arch(u64 base, u64 size)
+{
+ return -ENOSYS;
+}
+
int __init __weak early_init_dt_reserve_memory_arch(phys_addr_t base,
phys_addr_t size, bool nomap)
{
diff --git a/include/linux/of_fdt.h b/include/linux/of_fdt.h
index 4341f32..271b3fd 100644
--- a/include/linux/of_fdt.h
+++ b/include/linux/of_fdt.h
@@ -71,6 +71,7 @@ extern int early_init_dt_scan_memory(unsigned long node, const char *uname,
extern void early_init_fdt_scan_reserved_mem(void);
extern void early_init_fdt_reserve_self(void);
extern void early_init_dt_add_memory_arch(u64 base, u64 size);
+extern int early_init_dt_mark_hotplug_memory_arch(u64 base, u64 size);
extern int early_init_dt_reserve_memory_arch(phys_addr_t base, phys_addr_t size,
bool no_map);
extern void * early_init_dt_alloc_memory_arch(u64 size, u64 align);
diff --git a/mm/Kconfig b/mm/Kconfig
index 061b46b..33a9b06 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -153,7 +153,7 @@ config MOVABLE_NODE
bool "Enable to assign a node which has only movable memory"
depends on HAVE_MEMBLOCK
depends on NO_BOOTMEM
- depends on X86_64 || MEMORY_HOTPLUG
+ depends on X86_64 || OF_EARLY_FLATTREE || MEMORY_HOTPLUG
depends on NUMA
default n
help
--
1.8.3.1
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related
* [PATCH v7 3/5] mm: enable CONFIG_MOVABLE_NODE on non-x86 arches
From: Reza Arbab @ 2016-11-14 22:02 UTC (permalink / raw)
To: Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras,
Andrew Morton, Rob Herring, Frank Rowand, Thomas Gleixner,
Ingo Molnar, H. Peter Anvin
Cc: linuxppc-dev, linux-mm, devicetree, Bharata B Rao,
Nathan Fontenot, Stewart Smith, Alistair Popple, Balbir Singh,
Aneesh Kumar K.V, linux-kernel
In-Reply-To: <1479160961-25840-1-git-send-email-arbab@linux.vnet.ibm.com>
To support movable memory nodes (CONFIG_MOVABLE_NODE), at least one of
the following must be true:
1. This config has the capability to identify movable nodes at boot.
Right now, only x86 can do this.
2. Our config supports memory hotplug, which means that a movable node
can be created by hotplugging all of its memory into ZONE_MOVABLE.
Fix the Kconfig definition of CONFIG_MOVABLE_NODE, which currently
recognizes (1), but not (2).
Signed-off-by: Reza Arbab <arbab@linux.vnet.ibm.com>
Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Acked-by: Balbir Singh <bsingharora@gmail.com>
---
mm/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/Kconfig b/mm/Kconfig
index 86e3e0e..061b46b 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -153,7 +153,7 @@ config MOVABLE_NODE
bool "Enable to assign a node which has only movable memory"
depends on HAVE_MEMBLOCK
depends on NO_BOOTMEM
- depends on X86_64
+ depends on X86_64 || MEMORY_HOTPLUG
depends on NUMA
default n
help
--
1.8.3.1
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related
* [PATCH v7 2/5] mm: remove x86-only restriction of movable_node
From: Reza Arbab @ 2016-11-14 22:02 UTC (permalink / raw)
To: Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras,
Andrew Morton, Rob Herring, Frank Rowand, Thomas Gleixner,
Ingo Molnar, H. Peter Anvin
Cc: linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg,
devicetree-u79uwXL29TY76Z2rM5mHXA, Bharata B Rao, Nathan Fontenot,
Stewart Smith, Alistair Popple, Balbir Singh, Aneesh Kumar K.V,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1479160961-25840-1-git-send-email-arbab-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
In commit c5320926e370 ("mem-hotplug: introduce movable_node boot
option"), the memblock allocation direction is changed to bottom-up and
then back to top-down like this:
1. memblock_set_bottom_up(true), called by cmdline_parse_movable_node().
2. memblock_set_bottom_up(false), called by x86's numa_init().
Even though (1) occurs in generic mm code, it is wrapped by #ifdef
CONFIG_MOVABLE_NODE, which depends on X86_64.
This means that when we extend CONFIG_MOVABLE_NODE to non-x86 arches,
things will be unbalanced. (1) will happen for them, but (2) will not.
This toggle was added in the first place because x86 has a delay between
adding memblocks and marking them as hotpluggable. Since other arches do
this marking either immediately or not at all, they do not require the
bottom-up toggle.
So, resolve things by moving (1) from cmdline_parse_movable_node() to
x86's setup_arch(), immediately after the movable_node parameter has
been parsed.
Signed-off-by: Reza Arbab <arbab-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
---
Documentation/kernel-parameters.txt | 2 +-
arch/x86/kernel/setup.c | 24 ++++++++++++++++++++++++
mm/memory_hotplug.c | 20 --------------------
3 files changed, 25 insertions(+), 21 deletions(-)
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 37babf9..adcccd5 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -2401,7 +2401,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
that the amount of memory usable for all allocations
is not too small.
- movable_node [KNL,X86] Boot-time switch to enable the effects
+ movable_node [KNL] Boot-time switch to enable the effects
of CONFIG_MOVABLE_NODE=y. See mm/Kconfig for details.
MTD_Partition= [MTD]
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 9c337b0..4cfba94 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -985,6 +985,30 @@ void __init setup_arch(char **cmdline_p)
parse_early_param();
+#ifdef CONFIG_MEMORY_HOTPLUG
+ /*
+ * Memory used by the kernel cannot be hot-removed because Linux
+ * cannot migrate the kernel pages. When memory hotplug is
+ * enabled, we should prevent memblock from allocating memory
+ * for the kernel.
+ *
+ * ACPI SRAT records all hotpluggable memory ranges. But before
+ * SRAT is parsed, we don't know about it.
+ *
+ * The kernel image is loaded into memory at very early time. We
+ * cannot prevent this anyway. So on NUMA system, we set any
+ * node the kernel resides in as un-hotpluggable.
+ *
+ * Since on modern servers, one node could have double-digit
+ * gigabytes memory, we can assume the memory around the kernel
+ * image is also un-hotpluggable. So before SRAT is parsed, just
+ * allocate memory near the kernel image to try the best to keep
+ * the kernel away from hotpluggable memory.
+ */
+ if (movable_node_is_enabled())
+ memblock_set_bottom_up(true);
+#endif
+
x86_report_nx();
/* after early param, so could get panic from serial */
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index cad4b91..e43142c1 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -1727,26 +1727,6 @@ static bool can_offline_normal(struct zone *zone, unsigned long nr_pages)
static int __init cmdline_parse_movable_node(char *p)
{
#ifdef CONFIG_MOVABLE_NODE
- /*
- * Memory used by the kernel cannot be hot-removed because Linux
- * cannot migrate the kernel pages. When memory hotplug is
- * enabled, we should prevent memblock from allocating memory
- * for the kernel.
- *
- * ACPI SRAT records all hotpluggable memory ranges. But before
- * SRAT is parsed, we don't know about it.
- *
- * The kernel image is loaded into memory at very early time. We
- * cannot prevent this anyway. So on NUMA system, we set any
- * node the kernel resides in as un-hotpluggable.
- *
- * Since on modern servers, one node could have double-digit
- * gigabytes memory, we can assume the memory around the kernel
- * image is also un-hotpluggable. So before SRAT is parsed, just
- * allocate memory near the kernel image to try the best to keep
- * the kernel away from hotpluggable memory.
- */
- memblock_set_bottom_up(true);
movable_node_enabled = true;
#else
pr_warn("movable_node option not supported\n");
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v7 1/5] powerpc/mm: allow memory hotplug into a memoryless node
From: Reza Arbab @ 2016-11-14 22:02 UTC (permalink / raw)
To: Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras,
Andrew Morton, Rob Herring, Frank Rowand, Thomas Gleixner,
Ingo Molnar, H. Peter Anvin
Cc: linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg,
devicetree-u79uwXL29TY76Z2rM5mHXA, Bharata B Rao, Nathan Fontenot,
Stewart Smith, Alistair Popple, Balbir Singh, Aneesh Kumar K.V,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1479160961-25840-1-git-send-email-arbab-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
Remove the check which prevents us from hotplugging into an empty node.
The original commit b226e4621245 ("[PATCH] powerpc: don't add memory to
empty node/zone"), states that this was intended to be a temporary measure.
It is a workaround for an oops which no longer occurs.
Signed-off-by: Reza Arbab <arbab-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
Reviewed-by: Aneesh Kumar K.V <aneesh.kumar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
Acked-by: Balbir Singh <bsingharora-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Acked-by: Michael Ellerman <mpe-Gsx/Oe8HsFggBc27wqDAHg@public.gmane.org>
Cc: Nathan Fontenot <nfont-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
Cc: Bharata B Rao <bharata-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
---
arch/powerpc/mm/numa.c | 13 +------------
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
index a51c188..0cb6bd8 100644
--- a/arch/powerpc/mm/numa.c
+++ b/arch/powerpc/mm/numa.c
@@ -1085,7 +1085,7 @@ static int hot_add_node_scn_to_nid(unsigned long scn_addr)
int hot_add_scn_to_nid(unsigned long scn_addr)
{
struct device_node *memory = NULL;
- int nid, found = 0;
+ int nid;
if (!numa_enabled || (min_common_depth < 0))
return first_online_node;
@@ -1101,17 +1101,6 @@ int hot_add_scn_to_nid(unsigned long scn_addr)
if (nid < 0 || !node_online(nid))
nid = first_online_node;
- if (NODE_DATA(nid)->node_spanned_pages)
- return nid;
-
- for_each_online_node(nid) {
- if (NODE_DATA(nid)->node_spanned_pages) {
- found = 1;
- break;
- }
- }
-
- BUG_ON(!found);
return nid;
}
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v7 0/5] enable movable nodes on non-x86 configs
From: Reza Arbab @ 2016-11-14 22:02 UTC (permalink / raw)
To: Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras,
Andrew Morton, Rob Herring, Frank Rowand, Thomas Gleixner,
Ingo Molnar, H. Peter Anvin
Cc: linuxppc-dev, linux-mm, devicetree, Bharata B Rao,
Nathan Fontenot, Stewart Smith, Alistair Popple, Balbir Singh,
Aneesh Kumar K.V, linux-kernel
This patchset allows more configs to make use of movable nodes. When
CONFIG_MOVABLE_NODE is selected, there are two ways to introduce such
nodes into the system:
1. Discover movable nodes at boot. Currently this is only possible on
x86, but we will enable configs supporting fdt to do the same.
2. Hotplug and online all of a node's memory using online_movable. This
is already possible on any config supporting memory hotplug, not
just x86, but the Kconfig doesn't say so. We will fix that.
We'll also remove some cruft on power which would prevent (2).
/* changelog */
v7:
* Fix error when !CONFIG_HAVE_MEMBLOCK, found by the kbuild test robot.
* Remove the prefix of "linux,hotpluggable". Document the property's purpose.
v6:
* http://lkml.kernel.org/r/1478562276-25539-1-git-send-email-arbab@linux.vnet.ibm.com
* Add a patch enabling the fdt to describe hotpluggable memory.
v5:
* http://lkml.kernel.org/r/1477339089-5455-1-git-send-email-arbab@linux.vnet.ibm.com
* Drop the patches which recognize the "status" property of dt memory
nodes. Firmware can set the size of "linux,usable-memory" to zero instead.
v4:
* http://lkml.kernel.org/r/1475778995-1420-1-git-send-email-arbab@linux.vnet.ibm.com
* Rename of_fdt_is_available() to of_fdt_device_is_available().
Rename of_flat_dt_is_available() to of_flat_dt_device_is_available().
* Instead of restoring top-down allocation, ensure it never goes
bottom-up in the first place, by making movable_node arch-specific.
* Use MEMORY_HOTPLUG instead of PPC64 in the mm/Kconfig patch.
v3:
* http://lkml.kernel.org/r/1474828616-16608-1-git-send-email-arbab@linux.vnet.ibm.com
* Use Rob Herring's suggestions to improve the node availability check.
* More verbose commit log in the patch enabling CONFIG_MOVABLE_NODE.
* Add a patch to restore top-down allocation the way x86 does.
v2:
* http://lkml.kernel.org/r/1473883618-14998-1-git-send-email-arbab@linux.vnet.ibm.com
* Use the "status" property of standard dt memory nodes instead of
introducing a new "ibm,hotplug-aperture" compatible id.
* Remove the patch which explicitly creates a memoryless node. This set
no longer has any bearing on whether the pgdat is created at boot or
at the time of memory addition.
v1:
* http://lkml.kernel.org/r/1470680843-28702-1-git-send-email-arbab@linux.vnet.ibm.com
Reza Arbab (5):
powerpc/mm: allow memory hotplug into a memoryless node
mm: remove x86-only restriction of movable_node
mm: enable CONFIG_MOVABLE_NODE on non-x86 arches
of/fdt: mark hotpluggable memory
dt: add documentation of "hotpluggable" memory property
Documentation/devicetree/booting-without-of.txt | 7 +++++++
Documentation/kernel-parameters.txt | 2 +-
arch/powerpc/mm/numa.c | 13 +------------
arch/x86/kernel/setup.c | 24 ++++++++++++++++++++++++
drivers/of/fdt.c | 19 +++++++++++++++++++
include/linux/of_fdt.h | 1 +
mm/Kconfig | 2 +-
mm/memory_hotplug.c | 20 --------------------
8 files changed, 54 insertions(+), 34 deletions(-)
--
1.8.3.1
^ permalink raw reply
* Re: [PATCH -next] PCI: dra7xx: Add missing of_node_put() in dra7xx_pcie_init_irq_domain()
From: Heiko Stuebner @ 2016-11-14 21:37 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Kishon Vijay Abraham I, Wei Yongjun, Bjorn Helgaas, Wei Yongjun,
linux-omap, linux-pci, Shawn Lin, michal.simek, soren.brinkmann,
bharat.kumar.gogada, robh, Frank Rowand, devicetree
In-Reply-To: <20161114211928.GD9868@bhelgaas-glaptop.roam.corp.google.com>
Am Montag, 14. November 2016, 15:19:28 CET schrieb Bjorn Helgaas:
> [+cc Shawn, Heiko, Michal, Soren, Bharat, Rob H, Frank, devicetree@vger]
>
> On Sat, Nov 12, 2016 at 12:39:01PM +0530, Kishon Vijay Abraham I wrote:
> > Hi,
> >
> > On Saturday 12 November 2016 03:08 AM, Bjorn Helgaas wrote:
> > > On Mon, Oct 17, 2016 at 02:54:37PM +0000, Wei Yongjun wrote:
> > >> From: Wei Yongjun <weiyongjun1@huawei.com>
> > >>
> > >> This node pointer is returned by of_get_next_child() with refcount
> > >> incremented in this function. of_node_put() on it before exitting
> > >> this function on error.
> > >>
> > >> This is detected by Coccinelle semantic patch.
> > >>
> > >> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
> > >
> > > Kishon, this looks correct to me, so I applied it to pci/host-dra7xx for
> > > v4.10. Let me know if you have any issue with it.
> > >
> > >> ---
> > >>
> > >> drivers/pci/host/pci-dra7xx.c | 1 +
> > >> 1 file changed, 1 insertion(+)
> > >>
> > >> diff --git a/drivers/pci/host/pci-dra7xx.c
> > >> b/drivers/pci/host/pci-dra7xx.c
> > >> index 9595fad..79297e9 100644
> > >> --- a/drivers/pci/host/pci-dra7xx.c
> > >> +++ b/drivers/pci/host/pci-dra7xx.c
> > >> @@ -177,6 +177,7 @@ static int dra7xx_pcie_init_irq_domain(struct
> > >> pcie_port *pp)> >>
> > >> &intx_domain_ops, pp);
> > >>
> > >> if (!pp->irq_domain) {
> > >>
> > >> dev_err(dev, "Failed to get a INTx IRQ domain\n");
> > >>
> > >> + of_node_put(pcie_intc_node);
> >
> > I think of_node_put should be used for both the error case and non-error
> > case.
> Hmm, OK. I don't know what the rules are. Certainly if we made these
> drivers modular, I don't think we'd want to leak these references
> every time we unload/reload the module. Should we do the put
> immediately here, or in the module remove path, or ...?
>
> Adding other driver and DT folks for comment.
I think the function above (dra7xx_pcie_init_irq_domain) can do the
of_node_put at its end in all cases as suggested by Kishon.
of_get_next_child() will increment the refcount
irq_domain_add_linear()
__irq_domain_add() also increments the refcount
irq_domain_remove() will decrement the refcount
So it should be safe to decrement the refcount in
dra7xx_pcie_init_irq_domain() in all cases as the irq-domain internals will
always keep it above 1 as long as the node is used.
Heiko
^ permalink raw reply
* [PATCH] can: spi: hi311x: fix semicolon.cocci warnings (fwd)
From: Julia Lawall @ 2016-11-14 21:36 UTC (permalink / raw)
Cc: wg, mkl, robh+dt, mark.rutland, linux-can, netdev, devicetree,
linux-kernel, Akshay Bhat, Akshay Bhat
Remove unneeded semicolon.
Generated by: scripts/coccinelle/misc/semicolon.cocci
CC: Akshay Bhat <akshay.bhat@timesys.com>
Signed-off-by: Julia Lawall <julia.lawall@lip6.fr>
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
---
It's a minor issue, but may as well fix it up now. The tree this code is
from is as follows:
url:
https://github.com/0day-ci/linux/commits/Akshay-Bhat/can-holt_hi311x-documen
t-device-tree-bindings/20161115-034509
:::::: branch date: 2 hours ago
:::::: commit date: 2 hours ago
hi311x.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/can/spi/hi311x.c
+++ b/drivers/net/can/spi/hi311x.c
@@ -673,7 +673,7 @@ static irqreturn_t hi3110_can_ist(int ir
while (!(HI3110_STAT_RXFMTY &
hi3110_read(spi, HI3110_READ_STATF))) {
hi3110_hw_rx(spi);
- };
+ }
intf = hi3110_read(spi, HI3110_READ_INTF);
eflag = hi3110_read(spi, HI3110_READ_ERR);
^ permalink raw reply
* Re: [PATCH v7 9/9] DT:omap3+ads7846: use new common touchscreen bindings
From: Tony Lindgren @ 2016-11-14 21:28 UTC (permalink / raw)
To: H. Nikolaus Schaller
Cc: Sebastian Reichel, Dmitry Torokhov, Mark Rutland,
Benoît Cousson, Russell King, Arnd Bergmann, Michael Welling,
Mika Penttilä, Javier Martinez Canillas, Igor Grinberg,
Andrew F. Davis, Mark Brown, Jonathan Cameron, linux-input,
devicetree, linux-kernel, linux-omap, letux-kernel, linux-iio,
kernel
In-Reply-To: <bb3b82c63810026cd6c23a5788c3efc79fa53e60.1478890925.git.hns@goldelico.com>
* H. Nikolaus Schaller <hns@goldelico.com> [161111 11:03]:
> The standard touch screen bindings [1] replace the private ti,swap-xy
> with touchscreen-swaped-x-y. And for the Openpandora we use
> touchscreen-size etc. to match the LCD screen size.
This one should not cause conflicts, so please feel free to merge along
with the driver changes:
Acked-by: Tony Lindgren <tony@atomide.com>
^ permalink raw reply
* Re: [PATCH 3/4] PCI: dra7xx: Add support to force RC to work in GEN1 mode
From: Bjorn Helgaas @ 2016-11-14 21:24 UTC (permalink / raw)
To: Kishon Vijay Abraham I
Cc: Bjorn Helgaas, Rob Herring, linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-pci-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, nsekhar-l0cyMroinI0,
Shawn Lin
In-Reply-To: <8ecc1325-365d-bdec-d435-729e0ea49d20-l0cyMroinI0@public.gmane.org>
[+cc Shawn]
On Sat, Nov 12, 2016 at 12:40:10PM +0530, Kishon Vijay Abraham I wrote:
> Hi,
>
> On Saturday 12 November 2016 02:45 AM, Bjorn Helgaas wrote:
> > Hi Kishon,
> >
> > On Tue, Oct 11, 2016 at 06:28:34PM +0530, Kishon Vijay Abraham I wrote:
> >> PCIe in AM57x/DRA7x devices is by default
> >> configured to work in GEN2 mode. However there
> >> may be situations when working in GEN1 mode is
> >> desired. One example is limitation i925 (PCIe GEN2
> >> mode not supported at junction temperatures < 0C).
> >>
> >> Add support to force Root Complex to work in GEN1
> >> mode if so desired, but don't force GEN1 mode on
> >> any board just yet.
> >>
> >> Signed-off-by: Kishon Vijay Abraham I <kishon-l0cyMroinI0@public.gmane.org>
> >> Signed-off-by: Sekhar Nori <nsekhar-l0cyMroinI0@public.gmane.org>
> >> ---
> >> Documentation/devicetree/bindings/pci/ti-pci.txt | 1 +
> >> drivers/pci/host/pci-dra7xx.c | 27 ++++++++++++++++++++++
> >> 2 files changed, 28 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/pci/ti-pci.txt b/Documentation/devicetree/bindings/pci/ti-pci.txt
> >> index 60e2516..a3d6ca3 100644
> >> --- a/Documentation/devicetree/bindings/pci/ti-pci.txt
> >> +++ b/Documentation/devicetree/bindings/pci/ti-pci.txt
> >> @@ -25,6 +25,7 @@ PCIe Designware Controller
> >>
> >> Optional Property:
> >> - gpios : Should be added if a gpio line is required to drive PERST# line
> >> + - ti,pcie-is-gen1 : Force the PCIe controller to work in GEN1 (2.5 GT/s).
> >
> > Can we use "max-link-speed" so it's similar to imx6?
>
> yeah, maybe we should make it a generic PCI property?
I forgot that Shawn has already done this! I had already merged those
patches on pci/host-rockchip, but I moved them to pci/host since
they're not Rockchip-specific. Can you take a look at that and see if
you can do what you need based on that pci/host branch?
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v5 4/7] ASoC: sunxi: Add sun8i I2S driver
From: Maxime Ripard @ 2016-11-14 21:22 UTC (permalink / raw)
To: Jean-Francois Moine
Cc: Chen-Yu Tsai, Dave Airlie, Liam Girdwood, Mark Brown, Rob Herring,
Linux-ALSA, devicetree, dri-devel, linux-arm-kernel, linux-sunxi
In-Reply-To: <20161108115129.f315ca5feefd22614859bbe3-GANU6spQydw@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 3472 bytes --]
On Tue, Nov 08, 2016 at 11:51:29AM +0100, Jean-Francois Moine wrote:
> On Mon, 7 Nov 2016 21:05:05 +0100
> Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
>
> > Hi,
> >
> > On Sun, Nov 06, 2016 at 07:02:48PM +0100, Jean-Francois Moine wrote:
> > > On Sun, 23 Oct 2016 09:33:16 +0800
> > > Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org> wrote:
> > >
> > > > On Fri, Oct 21, 2016 at 4:36 PM, Jean-Francois Moine <moinejf-GANU6spQydw@public.gmane.org> wrote:
> > > > > This patch adds I2S support to sun8i SoCs as the A83T and H3.
> > > > >
> > > > > Signed-off-by: Jean-Francois Moine <moinejf-GANU6spQydw@public.gmane.org>
> > > > > ---
> > > > > Note: This driver is closed to the sun4i-i2s except that:
> > > > > - it handles the H3
> > > >
> > > > If it's close to sun4i-i2s, you should probably rework that one to support
> > > > the newer SoCs.
> > >
> > > I started to add the H3 into the sun4i-i2s, but I am blocked with
> > > regmap.
> > > Many H3 registers are common with the A10, but some of them have more
> > > or less fields, the fields may be at different offsets. And, finally,
> > > some registers are completely different.
> > > This would not raise any problem, except with regmap which is really
> > > painful.
> >
> > That's weird, because regmap's regmap_field should make that much
> > easier.
>
> #define field_relaxed(addr, mask, val) \
> writel_relaxed((readl_relaxed(addr) & mask) | val, addr)
I'm not sure what you mean here.
> > > As I may understood, regmap is used to simplify suspend/resume, but, is
> > > it useful to save the I2S register on suspend?
> > > Practically, I am streaming some tune on my device. I suspend it for
> > > any reason. The next morning, I resume it. Are you sure I want to
> > > continue to hear the end of the tune?
> > >
> > > I better think that streaming should be simply stopped on suspend.
> >
> > You're mistaken. The code in there is for *runtime* suspend, ie when
> > the device is no longer used, so that case shouldn't even happen at
> > all.
> >
> > (And real suspend isn't supported anyway)
>
> Is it time to remove this useless code?
Which useless code?
> > > Then, there is no need to save the playing registers, and, here I am,
> > > there is no need to use regmap.
> > >
> > > May I go this way?
> >
> > No, please don't. regmap is also providing very useful features, such
> > as access to all the registers through debugfs, or tracing. What
> > exactly feels painful to you?
>
> When the I/O registers are in memory (that's the case), you may access
> them (read and write) thru /dev/mem.
For all the registers if you want to dump all of them. It needs
scripting, it needs root access, and it needs some tool (either devmem
or a custom one) to dump the values. And this is if you have the right
kernel configuration options (devmem enabled, with the protection
against mapped devices disabled).
It just works with debugfs.
> Also, is a register access trace really needed in this driver?
Yes.
> The pain is to define the regmap_config (which registers can be
> read/write/volatile and which can be the values the u-boot let us in
> the registers at startup time), and the lot of code which is run instead
> of simple load/store machine instructions.
This is only needed if you want to use caching, and caching is
optional.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH -next] PCI: dra7xx: Add missing of_node_put() in dra7xx_pcie_init_irq_domain()
From: Bjorn Helgaas @ 2016-11-14 21:19 UTC (permalink / raw)
To: Kishon Vijay Abraham I
Cc: Wei Yongjun, Bjorn Helgaas, Wei Yongjun,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-pci-u79uwXL29TY76Z2rM5mHXA, Shawn Lin, Heiko Stuebner,
michal.simek-gjFFaj9aHVfQT0dZR+AlfA,
soren.brinkmann-gjFFaj9aHVfQT0dZR+AlfA,
bharat.kumar.gogada-gjFFaj9aHVfQT0dZR+AlfA,
robh-DgEjT+Ai2ygdnm+yROfE0A, Frank Rowand,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1d95b915-ddc0-b48f-270b-fffb60ecfe5e-l0cyMroinI0@public.gmane.org>
[+cc Shawn, Heiko, Michal, Soren, Bharat, Rob H, Frank, devicetree@vger]
On Sat, Nov 12, 2016 at 12:39:01PM +0530, Kishon Vijay Abraham I wrote:
> Hi,
>
> On Saturday 12 November 2016 03:08 AM, Bjorn Helgaas wrote:
> > On Mon, Oct 17, 2016 at 02:54:37PM +0000, Wei Yongjun wrote:
> >> From: Wei Yongjun <weiyongjun1-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> >>
> >> This node pointer is returned by of_get_next_child() with refcount
> >> incremented in this function. of_node_put() on it before exitting
> >> this function on error.
> >>
> >> This is detected by Coccinelle semantic patch.
> >>
> >> Signed-off-by: Wei Yongjun <weiyongjun1-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> >
> > Kishon, this looks correct to me, so I applied it to pci/host-dra7xx for
> > v4.10. Let me know if you have any issue with it.
> >
> >> ---
> >> drivers/pci/host/pci-dra7xx.c | 1 +
> >> 1 file changed, 1 insertion(+)
> >>
> >> diff --git a/drivers/pci/host/pci-dra7xx.c b/drivers/pci/host/pci-dra7xx.c
> >> index 9595fad..79297e9 100644
> >> --- a/drivers/pci/host/pci-dra7xx.c
> >> +++ b/drivers/pci/host/pci-dra7xx.c
> >> @@ -177,6 +177,7 @@ static int dra7xx_pcie_init_irq_domain(struct pcie_port *pp)
> >> &intx_domain_ops, pp);
> >> if (!pp->irq_domain) {
> >> dev_err(dev, "Failed to get a INTx IRQ domain\n");
> >> + of_node_put(pcie_intc_node);
>
> I think of_node_put should be used for both the error case and non-error case.
Hmm, OK. I don't know what the rules are. Certainly if we made these
drivers modular, I don't think we'd want to leak these references
every time we unload/reload the module. Should we do the put
immediately here, or in the module remove path, or ...?
Adding other driver and DT folks for comment.
I dropped these patches for now (dra7xx, rockchip, xilinx-nwl,
xilinx).
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
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