* [PATCH 10/19] watchdog: bindings: Remove obsolete platforms from dt doc.
From: Guenter Roeck @ 2016-09-14 22:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473859677-9231-11-git-send-email-peter.griffin@linaro.org>
On Wed, Sep 14, 2016 at 02:27:48PM +0100, Peter Griffin wrote:
> STiH415/6 SoC support is being removed from the kernel
> so update the dt bding document to reflect this.
>
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> Cc: <wim@iguana.be>
> Cc: <linux@roeck-us.net>
> Cc: <robh+dt@kernel.org>
> Cc: <linux-watchdog@vger.kernel.org>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
> ---
> Documentation/devicetree/bindings/watchdog/st_lpc_wdt.txt | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/watchdog/st_lpc_wdt.txt b/Documentation/devicetree/bindings/watchdog/st_lpc_wdt.txt
> index 039c5ca..b949039 100644
> --- a/Documentation/devicetree/bindings/watchdog/st_lpc_wdt.txt
> +++ b/Documentation/devicetree/bindings/watchdog/st_lpc_wdt.txt
> @@ -9,8 +9,7 @@ functionality.
>
> Required properties
>
> -- compatible : Must be one of: "st,stih407-lpc" "st,stih416-lpc"
> - "st,stih415-lpc" "st,stid127-lpc"
> +- compatible : Should be: "st,stih407-lpc"
> - reg : LPC registers base address + size
> - interrupts : LPC interrupt line number and associated flags
> - clocks : Clock used by LPC device (See: ../clock/clock-bindings.txt)
> --
> 1.9.1
>
^ permalink raw reply
* [GIT PULL 1/3] Rockchip driver changes for 4.9
From: Arnd Bergmann @ 2016-09-14 22:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1770547.rOXegfrGOH@phil>
On Thursday, September 8, 2016 4:08:45 PM CEST Heiko Stuebner wrote:
> This enables the active-wakeup functionality of the generic power-domains
> for the rockchip power-domain driver, so that some domains can stay
> active during suspend.
>
>
Pulled into next/drivers, thanks!
Arnd
^ permalink raw reply
* [GIT PULL] Amlogic driver updates for v4.9
From: Arnd Bergmann @ 2016-09-14 22:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7hfuph25v4.fsf@baylibre.com>
On Friday, September 2, 2016 5:18:23 PM CEST Kevin Hilman wrote:
> Amlogic drivers for v4.9
> - add secure monitor and eFuse driver
> - add IR remote driver
>
>
Pulled into next/drivers, thanks!
Arnd
^ permalink raw reply
* [GIT PULL 2/4] Broadcom soc-arm64 changes for 4.9
From: Arnd Bergmann @ 2016-09-14 22:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473213558-11782-2-git-send-email-f.fainelli@gmail.com>
On Tuesday, September 6, 2016 6:59:16 PM CEST Florian Fainelli wrote:
> This pull request contains Broadcom ARM64-based SoC changes for 4.9, please pull
> the following:
>
> - collective effort from Florian, Doug and Markus to add the ARCH_BRCMSTB Kconfig
> symbol to the ARM64 kernel build, which is purposedly the same as the ARM/Linux
> one in order not to update any driver dependencies
>
Pulled into next/arm64, thanks!
Arnd
^ permalink raw reply
* [GIT PULL] Renesas ARM64 Based SoC Defconfig Updates for v4.9
From: Arnd Bergmann @ 2016-09-14 22:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1473233745.git.horms+renesas@verge.net.au>
On Wednesday, September 7, 2016 9:41:26 AM CEST Simon Horman wrote:
> Renesas ARM64 Based SoC Defconfig Updates for v4.9
>
> * Enable HSUSB and SDHI
>
Pulled into next/arm64, thanks!
Arnd
^ permalink raw reply
* [PATCH v2] arm64: defconfig: enable common modules for power management
From: Arnd Bergmann @ 2016-09-14 22:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160908102035.GD1493@arm.com>
On Thursday, September 8, 2016 11:20:35 AM CEST Will Deacon wrote:
> Hi Arnd,
>
> On Thu, Sep 01, 2016 at 09:33:38AM +0200, Arnd Bergmann wrote:
> > On Thursday, September 1, 2016 12:51:09 PM CEST Leo Yan wrote:
> > > Enable common modules for power management; one is to enable
> > > CPUFREQ_DT driver; the driver is used by many platforms by passing OPP
> > > table from device tree.
> > >
> > > Also enables thermal related drivers. Firstly we need enable
> > > configuration CPU_THERMAL for CPU cooling device driver, this will bind
> > > thermal zone with CPU cooling device; and enable 'power allocator'
> > > thermal governor.
> > >
> > > Signed-off-by: Leo Yan <leo.yan@linaro.org>
> > >
> >
> > Looks good,
> >
> > Acked-by: Arnd Bergmann <arnd@arndb.de>
> >
> > Catalin and Will: I never know who should merge this kind of patch
> > as we have a number of other arm64 defconfig patches going through
> > arm-soc, but this patch is not really platform specific.
> >
> > Do you want to pick it up in the arm64 tree or should we take
> > this and others patches like it in general?
>
> I'm perfectly happy with you taking this, but thanks for asking the
> question. I think that, outside of the architectural bits, it makes
> sense for arm-soc to manage config options that are requested by the
> submaintainers. It also helps reduce defconfig churn. I typically wait
> until -rc1 before making any .config changes, unless they're urgent
> (e.g. systemd suddenly starts needing some options enabled in order to
> boot), so if you queue this for the merge window then we should be good.
Ok, thanks for the detailed answer. I've applied the patch to our
next/arm64 branch now.
Arnd
^ permalink raw reply
* [GIT PULL] ARM: mvebu: defconfig64 for v4.9 (#1)
From: Arnd Bergmann @ 2016-09-14 22:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87k2erzmiq.fsf@free-electrons.com>
On Sunday, September 4, 2016 5:56:45 PM CEST Gregory CLEMENT wrote:
> mvebu defconfig64 for 4.9 (part 1)
>
> - add PCIe driver for Aardvark for Armada 3700
> - enable xhci-platform for A7K/A8K
>
Pulled into next/arm64, thanks!
Arnd
^ permalink raw reply
* [GIT PULL] Qualcomm ARM64 Defconfig Updates for v4.9
From: Arnd Bergmann @ 2016-09-14 22:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1472875060-17967-1-git-send-email-andy.gross@linaro.org>
On Friday, September 2, 2016 10:57:40 PM CEST Andy Gross wrote:
> Qualcomm ARM64 Based defconfig Updates for v4.9
>
> * Enable defconfig options for QDF2432
>
Pulled into next/arm64, thanks!
Arnd
^ permalink raw reply
* [PATCH] arm64: defconfig: enable HW random as module
From: Arnd Bergmann @ 2016-09-14 22:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160903001301.32289-1-khilman@baylibre.com>
On Friday, September 2, 2016 5:13:00 PM CEST Kevin Hilman wrote:
> drivers/char/hw_random/Kconfig has 'default m', so
> simply removing this entry from the defconfig will
> enable building HW random drivers as modules.
>
> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
> ---
Applied four patches to next/arm64:
699189c arm64: defconfig: enable meson I2C
5a9a9cf arm64: defconfig: enable meson SPI as module
19b9869 arm64: defconfig: enable meson WDT as modules
5012a09 arm64: defconfig: enable HW random as module
Thanks,
Arnd
^ permalink raw reply
* [GIT PULL] arm64: defconfig: hisilicon config updates for v4.9
From: Arnd Bergmann @ 2016-09-14 22:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57C95675.5060504@hisilicon.com>
On Friday, September 2, 2016 11:37:41 AM CEST Wei Xu wrote:
> ARM64: hisilicon: defconfig updates for 4.9
>
> - Enable hisilicon SAS and XGE for hip05 and hip06
> - Enable drm, powerkey, bluetooth and adv7511/adv7533 for hikey
> - Add PINCTRL to HISI platform
>
Pulled into next/arm64, thanks!
Arnd
^ permalink raw reply
* [GIT PULL 5/5] i.MX defconfig updates for 4.9
From: Arnd Bergmann @ 2016-09-14 22:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473670948-4265-5-git-send-email-shawnguo@kernel.org>
On Monday, September 12, 2016 5:02:28 PM CEST Shawn Guo wrote:
> The following changes since commit 29b4817d4018df78086157ea3a55c1d9424a7cfc:
>
> Linux 4.8-rc1 (2016-08-07 18:18:00 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git tags/imx-defconfig-4.9
>
> for you to fetch changes up to b2ab6f6cc3b1da42acf30e03ce2a4dad3f627272:
>
> ARM: imx_v6_v7_defconfig: Select the wm8960 codec driver (2016-08-29 22:17:26 +0800)
>
> ----------------------------------------------------------------
> i.MX defconfig updates for 4.9:
> - Enable i.MX6 SATA and cpufreq driver support in multi_v7_defconfig.
> - Enable MPL3115, Etnaviv GPU, WM8960 Codec driver and more USB
> functions support in imx_v6_v7_defconfig.
Pulled into next/defconfig, thanks!
Arnd
^ permalink raw reply
* [GIT PULL] ARM: mvebu: defconfig for v4.9 (#1)
From: Arnd Bergmann @ 2016-09-14 21:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87lgz7zmjb.fsf@free-electrons.com>
On Sunday, September 4, 2016 5:56:24 PM CEST Gregory CLEMENT wrote:
> mvebu defconfig for 4.9 (part 1)
>
> - update dsa config with new symbol
> - add flash related config for mvebu v7
>
Pulled into next/defconfig, thanks!
Arnd
^ permalink raw reply
* [GIT PULL 2/2] ARM: config: Keystone config update for 4.9
From: Arnd Bergmann @ 2016-09-14 21:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1472684710-22905-2-git-send-email-ssantosh@kernel.org>
On Wednesday, August 31, 2016 7:05:10 PM CEST Santosh Shilimkar wrote:
> ARM: config: Add CONFIG_NOP_USB_XCEIV
>
> Keystone usb phy needs CONFIG_NOP_USB_XCEIV to be enabled.
>
Pulled into next/defconfig, thanks!
Arnd
^ permalink raw reply
* [PATCH] usb: dwc3: host: inherit dma configuration from parent dev
From: Arnd Bergmann @ 2016-09-14 21:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160914163136.GA26842@red-moon>
On Wednesday, September 14, 2016 5:31:36 PM CEST Lorenzo Pieralisi wrote:
> On Wed, Sep 07, 2016 at 01:47:22PM +0300, Felipe Balbi wrote:
> >
> > Hi,
> >
> > Robin Murphy <robin.murphy@arm.com> writes:
> > > On 07/09/16 10:55, Peter Chen wrote:
> > > [...]
> > >>> Regarding the DMA configuration that you mention in ci_hdrc_add_device(),
> > >>> I think we should replace
> > >>>
> > >>> pdev->dev.dma_mask = dev->dma_mask;
> > >>> pdev->dev.dma_parms = dev->dma_parms;
> > >>> dma_set_coherent_mask(&pdev->dev, dev->coherent_dma_mask);
> > >>>
> > >>> with of_dma_configure(), which has the chance to configure more than
> > >>> just those three, as the dma API might look into different aspects:
> > >>>
> > >>> - iommu specific configuration
> > >>> - cache coherency information
> > >>> - bus type
> > >>> - dma offset
> > >>> - dma_map_ops pointer
> > >>>
> > >>> We try to handle everything in of_dma_configure() at configuration
> > >>> time, and that would be the place to add anything else that we might
> > >>> need in the future.
> > >>>
> > >>
> > >> Yes, I agree with you, but just like Felipe mentioned, we also need to
> > >> consider PCI device, can we do something like gpiod_get_index does? Are
> > >> there any similar APIs like of_dma_configure for ACPI?
> > >
> > > Not yet, but Lorenzo has one in progress[1], primarily for the sake of
> > > abstracting away the IOMMU configuration.
> > >
> > > Robin.
> > >
> > > [1]:http://www.mail-archive.com/linux-kernel at vger.kernel.org/msg1209911.html
> >
> > not exported for drivers to use. If Lorenzo is trying to making a
> > matching API for ACPI systems, then it needs to follow what
> > of_dma_configure() is doing, and add an EXPORT_SYMBOL_GPL()
>
> That's easy enough, not sure I understand though why
> of_dma_deconfigure() is not exported then. The second question mark
> is about the dma-ranges equivalent in ACPI world; the _DMA method
> seems to be the exact equivalent but to the best of my knowledge
> it is ignored by the kernel, to really have an of_dma_configure()
> equivalent that's really necessary, unless we want to resort to
> arch specific methods (is that what x86 is currently doing ?) to
> retrieve/build the dma masks.
Please see the follow-up emails after my proposed patch: if we add
a pointer to the device that firmware knows about in the USB core layer,
there is no longer a problem to be solved and the DMA operations will
do the right thing.
Arnd
^ permalink raw reply
* [PATCH v2 1/4] clk: sunxi-ng: Add A64 clocks
From: Stephen Boyd @ 2016-09-14 21:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160909201029.24530-2-maxime.ripard@free-electrons.com>
On 09/09, Maxime Ripard wrote:
> index 106cba27c331..964f22091a10 100644
> --- a/drivers/clk/sunxi-ng/Makefile
> +++ b/drivers/clk/sunxi-ng/Makefile
> @@ -22,3 +22,4 @@ obj-$(CONFIG_SUN6I_A31_CCU) += ccu-sun6i-a31.o
> obj-$(CONFIG_SUN8I_A23_CCU) += ccu-sun8i-a23.o
> obj-$(CONFIG_SUN8I_A33_CCU) += ccu-sun8i-a33.o
> obj-$(CONFIG_SUN8I_H3_CCU) += ccu-sun8i-h3.o
> +obj-$(CONFIG_SUN50I_A64_CCU) += ccu-sun50i-a64.o
Maybe do alphanumeric ordering?
> diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
> new file mode 100644
> index 000000000000..d51ee416f515
> --- /dev/null
> +++ b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
> @@ -0,0 +1,870 @@
> +
> +static void __init sun50i_a64_ccu_setup(struct device_node *node)
> +{
> + void __iomem *reg;
> + u32 val;
> +
> + reg = of_io_request_and_map(node, 0, of_node_full_name(node));
> + if (IS_ERR(reg)) {
> + pr_err("%s: Could not map the clock registers\n",
> + of_node_full_name(node));
> + return;
> + }
> +
> + /* Force the PLL-Audio-1x divider to 4 */
> + val = readl(reg + SUN50I_A64_PLL_AUDIO_REG);
> + val &= ~GENMASK(19, 16);
> + writel(val | (3 << 16), reg + SUN50I_A64_PLL_AUDIO_REG);
> +
> + writel(0x515, reg + SUN50I_A64_PLL_MIPI_REG);
> +
> + sunxi_ccu_probe(node, reg, &sun50i_a64_ccu_desc);
> +}
> +CLK_OF_DECLARE(sun50i_a64_ccu, "allwinner,sun50i-a64-ccu",
> + sun50i_a64_ccu_setup);
Is there a reason it can't be a platform driver?
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [GIT PULL 4/4] Broadcom devicetree-arm64 changes for 4.9
From: Arnd Bergmann @ 2016-09-14 21:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8d7d7a8b-0bac-e2a0-f6cd-ef8fc8269678@broadcom.com>
On Wednesday, September 14, 2016 10:07:48 AM CEST Florian Fainelli wrote:
> On 09/14/2016 08:20 AM, Arnd Bergmann wrote:
> > On Tuesday, September 6, 2016 6:59:18 PM CEST Florian Fainelli wrote:
> >> This pull request contains Broadcom ARM64-based SoC Device Tree changes for
> >> v4.9, please pull the folllowing:
> >>
> >> - Dhanajay adds the PWM Device Tree nodes to the Northstar 2 DTS files
> >>
> >
> > Pulled into next/dt64, thanks!
> >
> > I did the pull requests for next/dt yesterday but evidently missed yours.
> > Don't worry about it, I've already looked at it and it's fine. We'll
> > pick it up in the next few days along with your other two pull requests.
>
> (plaintext this time)
>
> No worries, would you need me to change anything in the submission
> process to help? Out of curiosity do you have a patchwork or other patch
> tracking tool at arm at kernel.org?
No, you did everything just right, I was just not paying attention
at the right moment when going through my folder.
We don't use patchwork or anything like that, just filtering on
the inbox. Usually Olof and I both go through the lists separately
to make sure that the other one hasn't missed stuff.
Arnd
^ permalink raw reply
* [PATCH 1/5] clk: add support for runtime pm
From: Stephen Boyd @ 2016-09-14 21:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e3cceb9a-7a30-c662-dba4-bc453f6fddb6@samsung.com>
On 09/13, Marek Szyprowski wrote:
> On 2016-09-13 00:31, Stephen Boyd wrote:
> >
> >Great! So you have runtime PM callbacks that are calling
> >clk_prepare/unprepare?
>
> Well, not really. clock controller's runtime pm functions must not call
> clk_prepare/unprepare yet.
>
> I didn't get your question. I thought that you are asking if my change
> won't introduce any deadlock related to prepare and dev->pm locks. My
> runtime pm functions doesn't do any call to clk_prepare/unprepare.
> Although global clock prepare lock is re-entrant from the same process, it
> would cause deadlock if called from runtime pm functions, because runtime
> pm functions might be called from the worker running on the different
> cpu/process.
I mean non-clk controller driver based runtime PM callbacks that
call clk_prepare/unprepare in them. For example, some i2c or spi
device driver that has clk operations in the runtime PM
callbacks. That would allow lockdep to see any potential deadlock
because of aliasing lock classes for the device power lock and
the global prepare lock.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH] cpufreq: ti: Use generic platdev driver
From: Dave Gerlach @ 2016-09-14 21:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160914204137.20346-1-d-gerlach@ti.com>
On 09/14/2016 03:41 PM, Dave Gerlach wrote:
> Now that the cpufreq-dt-platdev is used to create the cpufreq-dt platform
> device for all OMAP platforms and the platform code that did it
> before has been removed, add ti,am33xx and ti,dra7xx to the machine list
> in cpufreq-dt-platdev which had relied on the removed platform code to do
> this previously.
>
> Fixes: 7694ca6e1d6f ("cpufreq: omap: Use generic platdev driver")
> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
> ---
This got left out when OMAP was originally added to the
cpufreq-dt-platdev, so cpufreq disappeared on am335x and dra7 platforms.
This patch together with the series here [1] will fix this regression.
Regards,
Dave
[1] http://marc.info/?l=linux-pm&m=147388667613317&w=2
> drivers/cpufreq/cpufreq-dt-platdev.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq-dt-platdev.c
> index 0bb44d5b5df4..d5e8ba50f8a3 100644
> --- a/drivers/cpufreq/cpufreq-dt-platdev.c
> +++ b/drivers/cpufreq/cpufreq-dt-platdev.c
> @@ -68,6 +68,8 @@ static const struct of_device_id machines[] __initconst = {
>
> { .compatible = "sigma,tango4" },
>
> + { .compatible = "ti,am33xx", },
> + { .compatible = "ti,dra7", },
> { .compatible = "ti,omap2", },
> { .compatible = "ti,omap3", },
> { .compatible = "ti,omap4", },
>
^ permalink raw reply
* [PATCH V3 3/4] ARM64 LPC: support serial based on low-pin-count
From: Arnd Bergmann @ 2016-09-14 21:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57D96701.4050700@hisilicon.com>
On Wednesday, September 14, 2016 11:04:33 PM CEST zhichang.yuan wrote:
> The 8250_hisi_lpc.c support both ACPI and dts similar to 8250_dw :
>
> +static struct platform_driver hs_lpc8250_driver = {
> + .driver = {
> + .name = "hisi-lpc-uart",
> + .of_match_table = hs8250_of_match,
> + .acpi_match_table = ACPI_PTR(hs8250_acpi_match),
>
> So, I am a little confused why we need to support dts in 8250_of.c and support ACPI in another
> driver file.
>
After looking again, I'm pretty sure that drivers/tty/serial/8250/8250_pnp.c
will handle the ACPI case without modifications, you just need to adapt
the 8250_of driver to handle IORESOURCE_IO ports. This will be required
anyway with the next version once the LPC bridge is on the PCI bus.
Arnd
^ permalink raw reply
* [PATCH V3 2/4] ARM64 LPC: LPC driver implementation on Hip06
From: Arnd Bergmann @ 2016-09-14 21:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57D963C4.4010406@hisilicon.com>
On Wednesday, September 14, 2016 10:50:44 PM CEST zhichang.yuan wrote:
>
> On 2016/9/14 20:33, Arnd Bergmann wrote:
> > On Wednesday, September 14, 2016 8:15:52 PM CEST Zhichang Yuan wrote:
> >
> >> +Required properties:
> >> +- compatible: should be "hisilicon,low-pin-count"
> >> +- #address-cells: must be 2 which stick to the ISA/EISA binding doc.
> >> +- #size-cells: must be 1 which stick to the ISA/EISA binding doc.
> >> +- reg: base address and length of the register set for the device.
> >> +- ranges: define a 1:1 mapping between the I/O space of the child device and
> >> + the parent.
> >
> > Do we still need the "ranges" here? The property in your example seems
> > wrong.
>
> I think "ranges" is needed.
> without this, of_translate_address --> __of_translate_address --> of_translate_one will fail when translating the child's IO resource.
>
> >
> >> + ranges = <0x01 0xe4 0x0 0xe4 0x1000>;
> >
> > You translate I/O port 0x00e4 through 0x10e4 to CPU address 0x0e4?
> The hip06 LPC is defined as isa type.
> So, 0x01 0xe4 is the local IO address of 0xe4. With this ranges, 0xe4 of child will be 1:1 mapped as 0xe4.
> It means no translation.
No, "no translation" would be leaving out the ranges, we should
fix the code so it handles this case according to the specification
of the ISA DT binding, rather than adding an incorrect ranges
property to make it work with the incorrect Linux implementation.
of_translate_address() should fail here, and whichever code calls
it should try something else, possibly something we have to
implement that can return the correct IORESOURCE_* type.
> >
> > I don't get this part. The bus driver should not care what its
> > children are, just register and PIO ranges that the bus can handle
> > in theory, i.e. from 0x000 to 0xfff.
>
> Just as we discussed in V2, the legacy PIO range is specific to some
> device, such as for ipmi bt, 0xe4 - 0xe7 will be populated.
> I don't want to occupy a larger PIO range in which only small part PIOs
> are used by our LPC. At this moment, two PIO ranges are using
> through the device property configuration, 0xe4-0xe7, 0x2f8-0x2ff.
>
> If we configure 0-0x1000 for the LPC to cover those two ranges, most
> PIO are wasted and other PIO device on other buses lose the chance to
> use the PIO below 0x1000.
> Otherwise, PIO conflict will happen. So, My idea is only occupied
> the PIO ranges which are really needed for the children.
The only thing it can realistically conflict with would be another
LPC bus behind on a PCI host bridge. On ARM64, all regular PCI
devices that have IORESOURCE_IO ports are intentionally moved
to (bus) port numbers above 0x1000.
> And there are probably multiple child devices under LPC, the global arm64_extio_ops only can cover one PIO range. It is fortunate only ipmi driver can not support I/O
> operation registering, serial driver has serial_in/serial_out to
> be registered. So, only the PIO range for ipmi device is stored
> in arm64_extio_ops and the indirect-IO
> works well for ipmi device.
You should not do that in the serial driver, please just use the
normal 8250 driver that works fine once you handle the entire
port range.
Arnd
^ permalink raw reply
* [PATCH v2 3/6] phy: meson: add USB2 PHY support for Meson8b and GXBB
From: Martin Blumenstingl @ 2016-09-14 21:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160911134111.31141-4-martin.blumenstingl@googlemail.com>
On Sun, Sep 11, 2016 at 3:41 PM, Martin Blumenstingl
<martin.blumenstingl@googlemail.com> wrote:
> This is a new driver for the USB PHY found in Meson8b and GXBB SoCs.
>
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
> Tested-by: Kevin Hilman <khilman@baylibre.com>
> ---
> drivers/phy/Kconfig | 11 ++
> drivers/phy/Makefile | 1 +
> drivers/phy/phy-meson-usb2.c | 280 +++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 292 insertions(+)
> create mode 100644 drivers/phy/phy-meson-usb2.c
>
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index 19bff3a..6ad87ec 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -453,4 +453,15 @@ config PHY_NS2_PCIE
> help
> Enable this to support the Broadcom Northstar2 PCIe PHY.
> If unsure, say N.
> +
> +config PHY_MESON_USB2
> + tristate "Meson USB2 PHY driver"
> + default ARCH_MESON
> + depends on OF && (ARCH_MESON || COMPILE_TEST)
> + select GENERIC_PHY
as pointed out by Arnd Bergmann (see [0]) this is missing a "select
USB_COMMON", just like the PHY_SUN4I_USB and PHY_SUN9I_USB drivers as
we use of_usb_get_dr_mode_by_phy() to get the mode of the USB
controller (as the PHY needs special configuration for host-mode).
I will send an update on Sunday.
Regards,
Martin
[0] http://marc.info/?l=linux-usb&m=147386117604824&w=2
^ permalink raw reply
* [PATCH 4/7] phy: meson: add USB2 PHY support for Meson8b and GXBB
From: Martin Blumenstingl @ 2016-09-14 21:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473842236.6816.0.camel@pengutronix.de>
On Wed, Sep 14, 2016 at 10:37 AM, Philipp Zabel <p.zabel@pengutronix.de> wrote:
> Am Dienstag, den 13.09.2016, 20:38 +0200 schrieb Martin Blumenstingl:
>> Hi Philipp,
>>
>> On Tue, Sep 13, 2016 at 5:28 PM, Philipp Zabel <p.zabel@pengutronix.de> wrote:
>> > Hi Martin,
>> >
>> > Am Freitag, den 09.09.2016, 22:36 +0200 schrieb Martin Blumenstingl:
>> >> On Fri, Sep 9, 2016 at 5:33 PM, Kevin Hilman <khilman@baylibre.com> wrote:
>> >> > Martin Blumenstingl <martin.blumenstingl@googlemail.com> writes:
>> >> >
>> >> >> On Thu, Sep 8, 2016 at 10:53 PM, Ben Dooks <ben.dooks@codethink.co.uk> wrote:
>> >> >>> On 08/09/16 21:42, Kevin Hilman wrote:
>> >> >>>>
>> >> >>>> Ben Dooks <ben.dooks@codethink.co.uk> writes:
>> >> >>>>
>> >> >>>>> On 08/09/16 20:52, Martin Blumenstingl wrote:
>> >> >>>>>>
>> >> >>>>>> On Thu, Sep 8, 2016 at 9:35 PM, Kevin Hilman <khilman@baylibre.com>
>> >> >>>>>> wrote:
>> >> >>>>>>>>
>> >> >>>>>>>> + phy = devm_phy_create(&pdev->dev, NULL, &phy_meson_usb2_ops);
>> >> >>>>>>>> + if (IS_ERR(phy)) {
>> >> >>>>>>>> + dev_err(&pdev->dev, "failed to create PHY\n");
>> >> >>>>>>>> + return PTR_ERR(phy);
>> >> >>>>>>>> + }
>> >> >>>>>>>> +
>> >> >>>>>>>> + if (usb_reset_refcnt++ == 0) {
>> >> >>>>>>>> + ret = device_reset(&pdev->dev);
>> >> >>>>>>>> + if (ret) {
>> >> >>>>>>>> + dev_err(&phy->dev, "Failed to reset USB PHY\n");
>> >> >>>>>>>> + return ret;
>> >> >>>>>>>> + }
>> >> >>>>>>>> + }
>> >> >>>>>>>
>> >> >>>>>>>
>> >> >>>>>>> The ref count + reset here looks like something that could/should be
>> >> >>>>>>> handled in a runtime PM callback.
>> >> >>>>>>
>> >> >>>>>> Unfortunately that doesn't work (as Jerome found out) because both
>> >> >>>>>> PHYs are sharing the same reset line.
>> >> >>>>>> So if the second PHY would call device_reset then it would also reset
>> >> >>>>>> the first PHY!
>> >> >>>>>>
>> >> >>>>>> There's a comment above the declaration of usb_reset_refcnt which
>> >> >>>>>> tries to explain this:
>> >> >>>>>> "The PHYs are sharing a common reset line -> we are only allowed to
>> >> >>>>>> reset once for all PHYs."
>> >> >>>>>> Maybe I should move this comment to the "if (usb_reset_refcnt++ == 0)
>> >> >>>>>> {" line to make it easier to see?
>> >> >>>>>>
>> >> >>>>>
>> >> >>>>> pm-runtime has refcounting in it. When one of the nodes turns on,
>> >> >>>>> the pm-runtime will call your driver to say there is a user when
>> >> >>>>> this first use turns up.
>> >> >>>>>
>> >> >>>>> If all the sub-phys turn off and drop their refcount then the driver
>> >> >>>>> is called to say there are no more users and you can go to sleep.
>> >> >>>>
>> >> >>>>
>> >> >>>> After a chat w/Martin on IRC, It turns out runtime PM wont help here.
>> >> >>>>
>> >> >>>> The reason is because there are physically two PHY devices[1]. Those 2
>> >> >>>> devices will be treated independely by runtime PM, and have separate
>> >> >>>> use-counting, which means doing what I proposed would cause a reset to
>> >> >>>> happen when either device was probed.
>> >> >>>>
>> >> >>>> So, I think it's OK as it is.
>> >> >>>
>> >> >>>
>> >> >>> Surely you can do pm_runtime_get/put on the phy's parent platform
>> >> >>> device and do it that way?
>> >> >> could you please be more specific with that (do you mean pdev->dev.parent)?
>> >> >> so we would use pm_runtime_{get_sync,put} with the parent, while we
>> >> >> would still define the runtime_resume in our driver.
>> >> >
>> >> > You'd also need to do get/put on the children, but yes, that's what Ben
>> >> > is suggesting.
>> >> >
>> >> > However, the problem with all of the solutions proposed (runtime PM ones
>> >> > included) is that we're forcing a board-specific design issue (2 devices
>> >> > sharing a reset line) into a driver that should not have any
>> >> > board-specific assumptions in it.
>> >> >
>> >> > For example, if this driver is used on another platform where different
>> >> > PHYs have different reset lines, then one of them (the unlucky one who
>> >> > is not probed first) will never get reset. So any form of per-device
>> >> > ref-counting is not a portable solution.
>> >> indeed, so in simple words we would need something like
>> >> reset_control_do_once(rstc, RESET/ASSERT/DEASSERT) which would
>> >> remember internally if any action has already been executed: if not it
>> >> does a _reset, _assert or _deassert and otherwise it does nothing.
>> >>
>> >> > I'm not sure yet how the reset framework is supposed to handle shared
>> >> > reset lines, but that needs some investigation. I quick glance and it
>> >> > seems that reset controllers can have shared lines, so that should be
>> >> > investigated.
>> >> I added Philipp and Hans to this thread - maybe they can comment on this.
>> >> To sum it up, our problem is:
>> >> - there are two separate USB PHYs on Meson GXBB
>> >> - both are sharing the same reset line (provided by the reset-meson driver)
>> >> - during initialization of the PHYs we must only call
>> >> reset_control_reset(rstc) once (if we do it for the first *and* second
>> >> PHY then the first PHY gets confused once the second PHY uses the
>> >> reset because the first PHY's state is reset as well)
>> >
>> > If you have an initially asserted reset line and you can enable the
>> > first module by deasserting the reset via reset_control_deassert (and
>> > reset_control_assert to signal when the module may be disabled again
>> > after use), shared resets are for you.
>> >
>> > If you need a reset pulse or have no direct control over the reset line,
>> > (device_reset), the reset framework currently has no solution for this.
>> > The ugly thing about reset_control_once would be that it can't re-reset
>> > modules when unloading and reloading driver modules.
>> The corresponding reset driver in question is reset-meson, which only
>> implements reset (assert/deassert are not implemented). However, I
>> don't know if this is due to hardware design.
>> I think the hardware implements the latter, but maybe Neil can give
>> more information here (I currently don't have access to my board so I
>> cannot test how the hardware actually behaves).
>>
>> > A real solution for shared reset lines with reset pulses would have to
>> > be some kind of reset request framework where if one module requests a
>> > reset, the other module sharing the reset could be notified, and then
>> > either veto the reset or, if possible, cease operations, store its
>> > state, and prepare to be reset, too, and afterwards restore state. I'd
>> > prefer not to think about this too much unless absolutely necessary.
>> I'm not sure if this would work in our case: one PHY instance would
>> have to know if the other has already triggered the reset or not.
>
> We could add a triggered flag or a counter to struct reset_control, and
> have reset_control_reset_once do nothing if it is already set /
> incremented. Since the reset_control goes away with the last consumer,
> the shared reset line would get triggered again after unbinding both PHY
> devices.
I guess that'd do the trick for us:
- we could use devm_reset_control_get_optional_shared() during probe
- power_on would then call reset_control_reset()
- the code in reset_control_reset would be changed: the if
(WARN_ON(rstc->shared)) would be removed. then we return 0 if
(rstc->shared && atomic_read(&rstc->shared_triggered)). otherwise we
proceed with the old logic, except that we use
atomic_set(&rstc->shared_triggerred, 1) in case of success (if an
error was returned we leave it as "not triggered").
Let me know if you want me to (at least try to) implement that and send an RFC.
Regards,
Martin
^ permalink raw reply
* [PATCH] ARM: dts: imx: b650v3: Calibrate USB PHY to pass eye diagram test
From: Jaret Cantu @ 2016-09-14 21:14 UTC (permalink / raw)
To: linux-arm-kernel
Calibrate the USB PHY TX settings to pass the eye diagram signal
integrity test. The settings are taken from the i.MX6 reference
manual's recommended configuration for USB certification (66.2.6).
Signed-off-by: Jaret Cantu <jaret.cantu@timesys.com>
---
arch/arm/boot/dts/imx6q-b650v3.dts | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/imx6q-b650v3.dts b/arch/arm/boot/dts/imx6q-b650v3.dts
index 33cb71a..c266bd2 100644
--- a/arch/arm/boot/dts/imx6q-b650v3.dts
+++ b/arch/arm/boot/dts/imx6q-b650v3.dts
@@ -89,3 +89,9 @@
};
};
};
+
+&usbphy1 {
+ fsl,tx-cal-45-dn-ohms = <55>;
+ fsl,tx-cal-45-dp-ohms = <55>;
+ fsl,tx-d-cal = <100>;
+};
--
1.7.10.4
^ permalink raw reply related
* [PATCH 1/2] pci/layercape: disable all iATUs before initialization
From: Bjorn Helgaas @ 2016-09-14 21:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473315950-6396-1-git-send-email-Minghuan.Lian@nxp.com>
On Thu, Sep 08, 2016 at 02:25:49PM +0800, Minghuan Lian wrote:
> Layerscape PCIe has 6 outbound iATUs. The bootloader such as
> u-boot uses 4 iATUs for CFG0 CFG1 IO and MEM separately. But
> Designware driver only uses two outbound iATUs. To avoid
> conflict between enabled but unused iATUs with used iATUs
> under Linux and unexpected behavior, the patch disables all
> iATUs before initialization.
Do we need similar changes in other DesignWare-based drivers?
> Signed-off-by: Minghuan Lian <Minghuan.Lian@nxp.com>
> ---
> drivers/pci/host/pci-layerscape.c | 17 +++++++++++++++--
> drivers/pci/host/pcie-designware.c | 7 +++++++
> drivers/pci/host/pcie-designware.h | 1 +
> 3 files changed, 23 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pci/host/pci-layerscape.c b/drivers/pci/host/pci-layerscape.c
> index 114ba81..cf783ad 100644
> --- a/drivers/pci/host/pci-layerscape.c
> +++ b/drivers/pci/host/pci-layerscape.c
> @@ -38,6 +38,8 @@
> /* PEX LUT registers */
> #define PCIE_LUT_DBG 0x7FC /* PEX LUT Debug Register */
>
> +#define PCIE_IATU_NUM 6
> +
> struct ls_pcie_drvdata {
> u32 lut_offset;
> u32 ltssm_shift;
> @@ -55,6 +57,8 @@ struct ls_pcie {
>
> #define to_ls_pcie(x) container_of(x, struct ls_pcie, pp)
>
> +static void ls_pcie_host_init(struct pcie_port *pp);
I would prefer to reorder the function definitions so the forward
declaration is not necessary. This would be two patches:
1) Reorder functions (no functional change)
2) Disable iATUs
> static bool ls_pcie_is_bridge(struct ls_pcie *pcie)
> {
> u32 header_type;
> @@ -87,6 +91,14 @@ static void ls_pcie_drop_msg_tlp(struct ls_pcie *pcie)
> iowrite32(val, pcie->dbi + PCIE_STRFMR1);
> }
>
> +static void ls_pcie_disable_outbound_atus(struct ls_pcie *pcie)
> +{
> + int i;
> +
> + for (i = 0; i < PCIE_IATU_NUM; i++)
> + dw_pcie_disable_outbound_atu(&pcie->pp, i);
It looks like maybe the DesignWare ATUs are generic enough that we could
move the loop into the generic code, e.g.,
void dw_pcie_disable_outbound_atu(struct pcie_port *pp, int count)
{
int i;
for (i = 0; i < count; i++) {
dw_pcie_writel_rc(pp, PCIE_ATU_REGION_OUTBOUND | i, PCIE_ATU_VIEWPORT);
dw_pcie_writel_rc(pp, 0, PCIE_ATU_CR2);
}
}
> +}
> +
> static int ls1021_pcie_link_up(struct pcie_port *pp)
> {
> u32 state;
> @@ -124,9 +136,8 @@ static void ls1021_pcie_host_init(struct pcie_port *pp)
> }
> pcie->index = index[1];
>
> + ls_pcie_host_init(pp);
> dw_pcie_setup_rc(pp);
> -
> - ls_pcie_drop_msg_tlp(pcie);
Can you split this to a separate patch? This hunk changes
ls1021_pcie_host_init() so it does several things in addition to
ls_pcie_drop_msg_tlp(), and it is unrelated to the "disable iATU" change.
> }
>
> static int ls_pcie_link_up(struct pcie_port *pp)
> @@ -153,6 +164,8 @@ static void ls_pcie_host_init(struct pcie_port *pp)
> ls_pcie_clear_multifunction(pcie);
> ls_pcie_drop_msg_tlp(pcie);
> iowrite32(0, pcie->dbi + PCIE_DBI_RO_WR_EN);
> +
> + ls_pcie_disable_outbound_atus(pcie);
> }
>
> static int ls_pcie_msi_host_init(struct pcie_port *pp,
> diff --git a/drivers/pci/host/pcie-designware.c b/drivers/pci/host/pcie-designware.c
> index 12afce1..e4d1203 100644
> --- a/drivers/pci/host/pcie-designware.c
> +++ b/drivers/pci/host/pcie-designware.c
> @@ -172,6 +172,13 @@ static void dw_pcie_prog_outbound_atu(struct pcie_port *pp, int index,
> dw_pcie_readl_rc(pp, PCIE_ATU_CR2, &val);
> }
>
> +void dw_pcie_disable_outbound_atu(struct pcie_port *pp, int index)
> +{
> + dw_pcie_writel_rc(pp, PCIE_ATU_REGION_OUTBOUND | index,
> + PCIE_ATU_VIEWPORT);
> + dw_pcie_writel_rc(pp, 0, PCIE_ATU_CR2);
> +}
> +
> static struct irq_chip dw_msi_irq_chip = {
> .name = "PCI-MSI",
> .irq_enable = pci_msi_unmask_irq,
> diff --git a/drivers/pci/host/pcie-designware.h b/drivers/pci/host/pcie-designware.h
> index f437f9b..e998bfc 100644
> --- a/drivers/pci/host/pcie-designware.h
> +++ b/drivers/pci/host/pcie-designware.h
> @@ -85,5 +85,6 @@ int dw_pcie_wait_for_link(struct pcie_port *pp);
> int dw_pcie_link_up(struct pcie_port *pp);
> void dw_pcie_setup_rc(struct pcie_port *pp);
> int dw_pcie_host_init(struct pcie_port *pp);
> +void dw_pcie_disable_outbound_atu(struct pcie_port *pp, int index);
>
> #endif /* _PCIE_DESIGNWARE_H */
> --
> 1.9.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 4/7] phy: meson: add USB2 PHY support for Meson8b and GXBB
From: Martin Blumenstingl @ 2016-09-14 21:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473842240.6816.1.camel@pengutronix.de>
On Wed, Sep 14, 2016 at 10:37 AM, Philipp Zabel <p.zabel@pengutronix.de> wrote:
> Am Dienstag, den 13.09.2016, 17:59 -0700 schrieb Kevin Hilman:
>> Martin Blumenstingl <martin.blumenstingl@googlemail.com> writes:
>>
>> > On Tue, Sep 13, 2016 at 5:28 PM, Philipp Zabel <p.zabel@pengutronix.de> wrote:
>>
>> [...]
>>
>> >>> I added Philipp and Hans to this thread - maybe they can comment on this.
>> >>> To sum it up, our problem is:
>> >>> - there are two separate USB PHYs on Meson GXBB
>> >>> - both are sharing the same reset line (provided by the reset-meson driver)
>> >>> - during initialization of the PHYs we must only call
>> >>> reset_control_reset(rstc) once (if we do it for the first *and* second
>> >>> PHY then the first PHY gets confused once the second PHY uses the
>> >>> reset because the first PHY's state is reset as well)
>> >>
>> >> If you have an initially asserted reset line and you can enable the
>> >> first module by deasserting the reset via reset_control_deassert (and
>> >> reset_control_assert to signal when the module may be disabled again
>> >> after use), shared resets are for you.
>> >>
>> >> If you need a reset pulse or have no direct control over the reset line,
>> >> (device_reset), the reset framework currently has no solution for this.
>> >> The ugly thing about reset_control_once would be that it can't re-reset
>> >> modules when unloading and reloading driver modules.
>> >
>> > The corresponding reset driver in question is reset-meson, which only
>> > implements reset (assert/deassert are not implemented). However, I
>> > don't know if this is due to hardware design.
>> > I think the hardware implements the latter, but maybe Neil can give
>> > more information here (I currently don't have access to my board so I
>> > cannot test how the hardware actually behaves).
>>
>> It's implemented that way because the hardware only supports a reset
>> pulse.
>
> Would it be possible to bring down both PHYs drivers, pull the reset
> line once, and then bring the drivers back up again?
I guess that this is the rmmod case: I haven't tested it yet but that
should work (even with the current code and .dts)
^ 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