* [PATCH 3/5] staging/vchi: Fix some pointer math for 64-bit.
From: Greg Kroah-Hartman @ 2016-10-25 7:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161017194406.1080-4-eric@anholt.net>
On Mon, Oct 17, 2016 at 12:44:04PM -0700, Eric Anholt wrote:
> These were throwing warnings on aarch64, and all are trivially
> converted to longs.
>
> Signed-off-by: Eric Anholt <eric@anholt.net>
> ---
> drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c | 6 +++---
> drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c | 5 +++--
> 2 files changed, 6 insertions(+), 5 deletions(-)
This didnt apply anymore as I think I took the other fixups, sorry.
greg k-h
^ permalink raw reply
* [PATCH] ARM: sti: stih410-clocks: Add PROC_STFE as a critical clock
From: Lee Jones @ 2016-10-25 7:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161024134416.GB10440@griffinp-ThinkPad-X1-Carbon-2nd>
On Mon, 24 Oct 2016, Peter Griffin wrote:
> Hi Lee,
>
> On Mon, 24 Oct 2016, Lee Jones wrote:
> > On Tue, 18 Oct 2016, Peter Griffin wrote:
> >
> > > Once the ST frontend demux HW IP has been enabled, the clock can't
> > > be disabled otherwise the system will hang and the board will
> > > be unserviceable.
> > >
> > > To allow balanced clock enable/disable calls in the driver we use
> > > the critical clock infrastructure to take an extra reference on the
> > > clock so the clock will never actually be disabled.
> >
> > This is an abuse of the critical-clocks framework, and is exactly the
> > type of hack I promised the clk guys I'd try to prevent.
>
> I expect the best way to do this would be to write some documentation on the
> clock-critical DT binding and/or CRITICAL_CLK flag. The only documentation I can
> find currently is with the initial patch series [1] and the comment in
> clk-provider.h of
>
> #define CLK_IS_CRITICAL BIT(11) /* do not gate, ever */
>
> Or the patch decription
>
> "Critical clocks are those which must not be gated, else undefined
> or catastrophic failure would occur. Here we have chosen to
> ensure the prepare/enable counts are correctly incremented, so as
> not to confuse users with enabled clocks with no visible users."
>
> Which is the functionality I want for this clock.
No, that's not the functionality you want. You want for the clock not
to be RE-gated (big difference). Currently, the STFE clock will never
be gated, even when a) it's not used and b) can actually be disabled.
You're needlessly wasting power here.
Also, in your use-case there is a visible user, and the prepare/enable
counts will be correct.
> > If this, or
> > any other IP has some quirks (i.e. once enabled, if this clock is
> > subsequently disabled it will have a catastrophic effect on the
> > platform), then they should be worked around in the driver.
> >
> > The correct thing to do here is craft a clk-keep-on flag and ensure it
> > is set to true for the effected platform(s)' platform data.
>
> I'm always wary of creating a driver specific flag, especially when its
> purpose is to do the same thing as an existing mechanism provided by the
> subsystem of not gating the clock.
Using existing sub-system supplied mechanisms in the way they were not
intended is sub-optimal (read "hacky").
> I can see a couple of problems with what you propose:
>
> 1) You have to put the clk-keep-on flag in every driver which consumes the
> clock. IMO it is much better to have this knowledge in the SoC's
> clock driver so every consumer of the clock automatically benefits.
That would also be fine(ish). The issue is that this problem is
board specific, so the platform clock driver would have to contain
board level knowledge. Also, if you were to implement this, it would
too mess up reference counting in the core.
> 2) You don't benefit from the CLK_IS_CRITICAL reference counting logic in
> clk.c. So then each driver has to also work around that to get sensible reference
> counts. e.g.
>
> if (!__clk_is_enabled(clk) && pdata->clk-keep-on)
> clk_enable(clk)
>
> Which seems to me to be fighting against the subsystem. Given that the only use of
> _clk_is_enabled() outside drivers/clk is in an old arch/arm/mach-omap2/pm24xx.c
> driver I suspect its use is frowned upon, and it shouldn't really be an EXPORTED_SYMBOL.
In this instance, since the STFE clock is only used by this IP, I
would choose to handle it in the driver. This can be done using a
single flag stored in pdata which should be fetched using
of_match_device(). This way there is no need for any more API abuse;
either by incorrectly identifying the STFE clock as critical OR
invoking any internal __clk_*() calls.
Enable the clock once in .probe(), which you already do.
Then, whenever you do any power saving do:
suspend()
{
if (!ddata->enable_clk_once)
clk_disable(clk);
}
resume()
{
if (!ddata->enable_clk_once)
clk_enable(clk);
}
However, looking at your driver, I think this point might even be
moot, since you don't have any power saving. The only time you
disable the clock is in the error path. Just replace that with a
comment about the platform's unfortunate errata.
> [1] https://lkml.org/lkml/2016/1/18/272
I'm glad you mentioned this. Let's take a look:
> Some platforms contain clocks which if gated, will cause undefined or
> catastrophic behaviours. As such they are not to be turned off, ever.
Not the case here.
This clock *can* be gated and can be turned off *sometimes*.
> Many of these such clocks do not have devices, thus device drivers
> where clocks may be enabled and references taken to ensure they stay
> enabled do not exist. Therefore, we must handle these such cases in
> the core.
This clock *does* have a driver and correct references *can* be
taken.
[...]
All I'm saying is, and it's the same thing I've said many times; these
types of issues do not exhibit the same set of symptoms as a critical
clock by definition. Critical clocks are those which references can
not be taken by any other means. Think of the critical clock
framework as a mechanism to circumvent the requirement of writing a
special driver which would *only* handle clocks i.e. an interconnect
driver in the ST case.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH/RFT v2 11/17] USB: OHCI: make ohci-da8xx a separate driver
From: Axel Haslam @ 2016-10-25 7:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <403743d8-dff2-3389-105b-1082b674b0b8@lechnology.com>
On Tue, Oct 25, 2016 at 2:38 AM, David Lechner <david@lechnology.com> wrote:
> On 10/24/2016 11:46 AM, ahaslam at baylibre.com wrote:
>>
>> From: Manjunath Goudar <manjunath.goudar@linaro.org>
>>
>> Separate the Davinci OHCI host controller driver from ohci-hcd
>> host code so that it can be built as a separate driver module.
>> This work is part of enabling multi-platform kernels on ARM;
>> it would be nice to have in 3.11.
>
>
> No need for comment about kernel 3.11.
yes, ok.
>
>>
>> Signed-off-by: Manjunath Goudar <manjunath.goudar@linaro.org>
>> ---
>> drivers/usb/host/Kconfig | 2 +-
>> drivers/usb/host/Makefile | 1 +
>> drivers/usb/host/ohci-da8xx.c | 185
>> +++++++++++++++++-------------------------
>> drivers/usb/host/ohci-hcd.c | 18 ----
>> 4 files changed, 76 insertions(+), 130 deletions(-)
>>
>> diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
>> index 83b6cec..642c6fe8 100644
>> --- a/drivers/usb/host/Kconfig
>> +++ b/drivers/usb/host/Kconfig
>> @@ -479,7 +479,7 @@ config USB_OHCI_HCD_OMAP3
>> OMAP3 and later chips.
>>
>> config USB_OHCI_HCD_DAVINCI
>> - bool "OHCI support for TI DaVinci DA8xx"
>> + tristate "OHCI support for TI DaVinci DA8xx"
>> depends on ARCH_DAVINCI_DA8XX
>> depends on USB_OHCI_HCD=y
>
>
> Need to drop the "=y" here, otherwise you still can't compile this as a
> module.
Im able to complile it as a module, but ok ill remove it.
>
>> select PHY_DA8XX_USB
>> diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
>> index 6ef785b..2644537 100644
>> --- a/drivers/usb/host/Makefile
>> +++ b/drivers/usb/host/Makefile
>> @@ -61,6 +61,7 @@ obj-$(CONFIG_USB_OHCI_HCD_AT91) += ohci-at91.o
>> obj-$(CONFIG_USB_OHCI_HCD_S3C2410) += ohci-s3c2410.o
>> obj-$(CONFIG_USB_OHCI_HCD_LPC32XX) += ohci-nxp.o
>> obj-$(CONFIG_USB_OHCI_HCD_PXA27X) += ohci-pxa27x.o
>> +obj-$(CONFIG_USB_OHCI_HCD_DAVINCI) += ohci-da8xx.o
>>
>> obj-$(CONFIG_USB_UHCI_HCD) += uhci-hcd.o
>> obj-$(CONFIG_USB_FHCI_HCD) += fhci.o
>> diff --git a/drivers/usb/host/ohci-da8xx.c b/drivers/usb/host/ohci-da8xx.c
>> index e98066d..5585d9e 100644
>> --- a/drivers/usb/host/ohci-da8xx.c
>> +++ b/drivers/usb/host/ohci-da8xx.c
>> @@ -11,16 +11,31 @@
>> * kind, whether express or implied.
>> */
>>
>> +#include <linux/clk.h>
>> +#include <linux/io.h>
>> #include <linux/interrupt.h>
>> #include <linux/jiffies.h>
>> +#include <linux/kernel.h>
>> +#include <linux/module.h>
>> #include <linux/platform_device.h>
>> -#include <linux/clk.h>
>> #include <linux/phy/phy.h>
>> #include <linux/platform_data/usb-davinci.h>
>> +#include <linux/platform_device.h>
>
>
> linux/platform_device.h is listed twice
>
>> +#include <linux/usb.h>
>> +#include <linux/usb/hcd.h>
>> +#include <asm/unaligned.h>
>>
>> -#ifndef CONFIG_ARCH_DAVINCI_DA8XX
>> -#error "This file is DA8xx bus glue. Define CONFIG_ARCH_DAVINCI_DA8XX."
>> -#endif
>> +#include "ohci.h"
>> +
>> +#define DRIVER_DESC "OHCI DA8XX driver"
>> +
>> +static const char hcd_name[] = "ohci-da8xx";
>
>
> why static const char instead of #define? This is only used one time in a
> pr_info, so it seems kind of pointless anyway.
Other drivers are using static const for the same variable.
i think static const is preferred over #define because #define doet give a type.
If you dont mind ill keep it static const.
>
>> +
>> +static struct hc_driver __read_mostly ohci_da8xx_hc_driver;
>> +
>> +static int (*orig_ohci_hub_control)(struct usb_hcd *hcd, u16 typeReq,
>> + u16 wValue, u16 wIndex, char *buf, u16 wLength);
>> +static int (*orig_ohci_hub_status_data)(struct usb_hcd *hcd, char *buf);
>>
>> static struct clk *usb11_clk;
>> static struct phy *usb11_phy;
>> @@ -73,7 +88,7 @@ static void ohci_da8xx_ocic_handler(struct
>> da8xx_ohci_root_hub *hub)
>> hub->set_power(0);
>> }
>>
>> -static int ohci_da8xx_init(struct usb_hcd *hcd)
>> +static int ohci_da8xx_reset(struct usb_hcd *hcd)
>> {
>> struct device *dev = hcd->self.controller;
>> struct da8xx_ohci_root_hub *hub = dev_get_platdata(dev);
>> @@ -93,7 +108,7 @@ static int ohci_da8xx_init(struct usb_hcd *hcd)
>> */
>> ohci->num_ports = 1;
>>
>> - result = ohci_init(ohci);
>> + result = ohci_setup(hcd);
>> if (result < 0) {
>> ohci_da8xx_disable();
>> return result;
>> @@ -121,30 +136,12 @@ static int ohci_da8xx_init(struct usb_hcd *hcd)
>> return result;
>> }
>>
>> -static void ohci_da8xx_stop(struct usb_hcd *hcd)
>> -{
>> - ohci_stop(hcd);
>> - ohci_da8xx_disable();
>> -}
>> -
>> -static int ohci_da8xx_start(struct usb_hcd *hcd)
>> -{
>> - struct ohci_hcd *ohci = hcd_to_ohci(hcd);
>> - int result;
>> -
>> - result = ohci_run(ohci);
>> - if (result < 0)
>> - ohci_da8xx_stop(hcd);
>> -
>> - return result;
>> -}
>> -
>> /*
>> * Update the status data from the hub with the over-current indicator
>> change.
>> */
>> static int ohci_da8xx_hub_status_data(struct usb_hcd *hcd, char *buf)
>> {
>> - int length = ohci_hub_status_data(hcd, buf);
>> + int length = orig_ohci_hub_status_data(hcd, buf);
>>
>> /* See if we have OCIC flag set */
>> if (ocic_flag) {
>> @@ -226,66 +223,13 @@ static int ohci_da8xx_hub_control(struct usb_hcd
>> *hcd, u16 typeReq, u16 wValue,
>> }
>> }
>>
>> - return ohci_hub_control(hcd, typeReq, wValue, wIndex, buf,
>> wLength);
>> + return orig_ohci_hub_control(hcd, typeReq, wValue,
>> + wIndex, buf, wLength);
>> }
>>
>> -static const struct hc_driver ohci_da8xx_hc_driver = {
>> - .description = hcd_name,
>> - .product_desc = "DA8xx OHCI",
>> - .hcd_priv_size = sizeof(struct ohci_hcd),
>> -
>> - /*
>> - * generic hardware linkage
>> - */
>> - .irq = ohci_irq,
>> - .flags = HCD_USB11 | HCD_MEMORY,
>> -
>> - /*
>> - * basic lifecycle operations
>> - */
>> - .reset = ohci_da8xx_init,
>> - .start = ohci_da8xx_start,
>> - .stop = ohci_da8xx_stop,
>> - .shutdown = ohci_shutdown,
>> -
>> - /*
>> - * managing i/o requests and associated device resources
>> - */
>> - .urb_enqueue = ohci_urb_enqueue,
>> - .urb_dequeue = ohci_urb_dequeue,
>> - .endpoint_disable = ohci_endpoint_disable,
>> -
>> - /*
>> - * scheduling support
>> - */
>> - .get_frame_number = ohci_get_frame,
>> -
>> - /*
>> - * root hub support
>> - */
>> - .hub_status_data = ohci_da8xx_hub_status_data,
>> - .hub_control = ohci_da8xx_hub_control,
>> -
>> -#ifdef CONFIG_PM
>> - .bus_suspend = ohci_bus_suspend,
>> - .bus_resume = ohci_bus_resume,
>> -#endif
>> - .start_port_reset = ohci_start_port_reset,
>> -};
>> -
>>
>> /*-------------------------------------------------------------------------*/
>>
>> -
>> -/**
>> - * usb_hcd_da8xx_probe - initialize DA8xx-based HCDs
>> - * Context: !in_interrupt()
>> - *
>> - * Allocates basic resources for this USB host controller, and
>> - * then invokes the start() method for the HCD associated with it
>> - * through the hotplug entry's driver_data.
>> - */
>> -static int usb_hcd_da8xx_probe(const struct hc_driver *driver,
>> - struct platform_device *pdev)
>> +static int ohci_da8xx_probe(struct platform_device *pdev)
>> {
>> struct da8xx_ohci_root_hub *hub = dev_get_platdata(&pdev->dev);
>> struct usb_hcd *hcd;
>> @@ -295,6 +239,11 @@ static int usb_hcd_da8xx_probe(const struct hc_driver
>> *driver,
>> if (hub == NULL)
>> return -ENODEV;
>>
>> + hcd = usb_create_hcd(&ohci_da8xx_hc_driver, &pdev->dev,
>> + dev_name(&pdev->dev));
>> + if (!hcd)
>> + return -ENOMEM;
>> +
>
>
> Won't this leak hdc if there is an error later?
>
>> usb11_clk = devm_clk_get(&pdev->dev, "usb11");
>> if (IS_ERR(usb11_clk)) {
>> if (PTR_ERR(usb11_clk) != -EPROBE_DEFER)
>> @@ -309,9 +258,6 @@ static int usb_hcd_da8xx_probe(const struct hc_driver
>> *driver,
>> return PTR_ERR(usb11_phy);
>> }
>>
>> - hcd = usb_create_hcd(driver, &pdev->dev, dev_name(&pdev->dev));
>> - if (!hcd)
>> - return -ENOMEM;
>
>
> Why does this need to be moved?
>
it should not have moved this, will fix.
>>
>> mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> hcd->regs = devm_ioremap_resource(&pdev->dev, mem);
>> @@ -323,13 +269,12 @@ static int usb_hcd_da8xx_probe(const struct
>> hc_driver *driver,
>> hcd->rsrc_start = mem->start;
>> hcd->rsrc_len = resource_size(mem);
>>
>> - ohci_hcd_init(hcd_to_ohci(hcd));
>> -
>> irq = platform_get_irq(pdev, 0);
>> if (irq < 0) {
>> error = -ENODEV;
>> goto err;
>> }
>> +
>> error = usb_add_hcd(hcd, irq, 0);
>> if (error)
>> goto err;
>> @@ -348,35 +293,14 @@ static int usb_hcd_da8xx_probe(const struct
>> hc_driver *driver,
>> return error;
>> }
>>
>> -/**
>> - * usb_hcd_da8xx_remove - shutdown processing for DA8xx-based HCDs
>> - * @dev: USB Host Controller being removed
>> - * Context: !in_interrupt()
>> - *
>> - * Reverses the effect of usb_hcd_da8xx_probe(), first invoking
>> - * the HCD's stop() method. It is always called from a thread
>> - * context, normally "rmmod", "apmd", or something similar.
>> - */
>> -static inline void
>> -usb_hcd_da8xx_remove(struct usb_hcd *hcd, struct platform_device *pdev)
>> +static int ohci_da8xx_remove(struct platform_device *pdev)
>> {
>> + struct usb_hcd *hcd = platform_get_drvdata(pdev);
>> struct da8xx_ohci_root_hub *hub = dev_get_platdata(&pdev->dev);
>>
>> hub->ocic_notify(NULL);
>> usb_remove_hcd(hcd);
>> usb_put_hcd(hcd);
>> -}
>> -
>> -static int ohci_hcd_da8xx_drv_probe(struct platform_device *dev)
>> -{
>> - return usb_hcd_da8xx_probe(&ohci_da8xx_hc_driver, dev);
>> -}
>> -
>> -static int ohci_hcd_da8xx_drv_remove(struct platform_device *dev)
>> -{
>> - struct usb_hcd *hcd = platform_get_drvdata(dev);
>> -
>> - usb_hcd_da8xx_remove(hcd, dev);
>>
>> return 0;
>> }
>> @@ -426,12 +350,16 @@ static int ohci_da8xx_resume(struct platform_device
>> *dev)
>> }
>> #endif
>>
>> +static const struct ohci_driver_overrides da8xx_overrides __initconst = {
>> + .reset = ohci_da8xx_reset
>> +};
>> +
>> /*
>> * Driver definition to register with platform structure.
>> */
>> static struct platform_driver ohci_hcd_da8xx_driver = {
>> - .probe = ohci_hcd_da8xx_drv_probe,
>> - .remove = ohci_hcd_da8xx_drv_remove,
>> + .probe = ohci_da8xx_probe,
>> + .remove = ohci_da8xx_remove,
>> .shutdown = usb_hcd_platform_shutdown,
>> #ifdef CONFIG_PM
>> .suspend = ohci_da8xx_suspend,
>
>
> It would probably be a good idea to change the driver name here. Currently
> it is "ohci". Although this would be better in a separate patch if the name
> has to be changed to match in other files as well.
>
ok, ill do a separate patch for that.
>> @@ -442,4 +370,39 @@ static int ohci_da8xx_resume(struct platform_device
>> *dev)
>> },
>> };
>>
>> +static int __init ohci_da8xx_init(void)
>> +{
>> +
>> + if (usb_disabled())
>> + return -ENODEV;
>> +
>> + pr_info("%s: " DRIVER_DESC "\n", hcd_name);
>> + ohci_init_driver(&ohci_da8xx_hc_driver, &da8xx_overrides);
>> +
>> + /*
>> + * The Davinci da8xx HW has some unusual quirks, which require
>> + * da8xx-specific workarounds. We override certain hc_driver
>> + * functions here to achieve that. We explicitly do not enhance
>> + * ohci_driver_overrides to allow this more easily, since this
>> + * is an unusual case, and we don't want to encourage others to
>> + * override these functions by making it too easy.
>> + */
>> +
>> + orig_ohci_hub_control = ohci_da8xx_hc_driver.hub_control;
>> + orig_ohci_hub_status_data = ohci_da8xx_hc_driver.hub_status_data;
>> +
>> + ohci_da8xx_hc_driver.hub_status_data =
>> ohci_da8xx_hub_status_data;
>> + ohci_da8xx_hc_driver.hub_control = ohci_da8xx_hub_control;
>> +
>> + return platform_driver_register(&ohci_hcd_da8xx_driver);
>> +}
>> +module_init(ohci_da8xx_init);
>> +
>> +static void __exit ohci_da8xx_cleanup(void)
>
>
> ohci_da8xx_exit would be a better name
>
ok.
>> +{
>> + platform_driver_unregister(&ohci_hcd_da8xx_driver);
>> +}
>> +module_exit(ohci_da8xx_cleanup);
>> +MODULE_DESCRIPTION(DRIVER_DESC);
>> +MODULE_LICENSE("GPL");
>> MODULE_ALIAS("platform:ohci");
>
>
> this will need to be changed too if you change the driver name
>
>> diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
>> index 1700908..8de174a 100644
>> --- a/drivers/usb/host/ohci-hcd.c
>> +++ b/drivers/usb/host/ohci-hcd.c
>> @@ -1219,11 +1219,6 @@ void ohci_init_driver(struct hc_driver *drv,
>> #define SA1111_DRIVER ohci_hcd_sa1111_driver
>> #endif
>>
>> -#ifdef CONFIG_USB_OHCI_HCD_DAVINCI
>> -#include "ohci-da8xx.c"
>> -#define DAVINCI_PLATFORM_DRIVER ohci_hcd_da8xx_driver
>> -#endif
>> -
>> #ifdef CONFIG_USB_OHCI_HCD_PPC_OF
>> #include "ohci-ppc-of.c"
>> #define OF_PLATFORM_DRIVER ohci_hcd_ppc_of_driver
>> @@ -1303,19 +1298,9 @@ static int __init ohci_hcd_mod_init(void)
>> goto error_tmio;
>> #endif
>>
>> -#ifdef DAVINCI_PLATFORM_DRIVER
>> - retval = platform_driver_register(&DAVINCI_PLATFORM_DRIVER);
>> - if (retval < 0)
>> - goto error_davinci;
>> -#endif
>> -
>> return retval;
>>
>> /* Error path */
>> -#ifdef DAVINCI_PLATFORM_DRIVER
>> - platform_driver_unregister(&DAVINCI_PLATFORM_DRIVER);
>> - error_davinci:
>> -#endif
>> #ifdef TMIO_OHCI_DRIVER
>> platform_driver_unregister(&TMIO_OHCI_DRIVER);
>> error_tmio:
>> @@ -1351,9 +1336,6 @@ static int __init ohci_hcd_mod_init(void)
>>
>> static void __exit ohci_hcd_mod_exit(void)
>> {
>> -#ifdef DAVINCI_PLATFORM_DRIVER
>> - platform_driver_unregister(&DAVINCI_PLATFORM_DRIVER);
>> -#endif
>> #ifdef TMIO_OHCI_DRIVER
>> platform_driver_unregister(&TMIO_OHCI_DRIVER);
>> #endif
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 2/2] cpufreq: retire the Integrator cpufreq driver
From: Linus Walleij @ 2016-10-25 7:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477380085-6929-1-git-send-email-linus.walleij@linaro.org>
After switching the core module clocks controlling the Integrator
clock frequencies to the common clock framework, defining the
operating points in the device tree, and activating the generic
DT-based CPUfreq driver, we can retire the old Integrator
cpufreq driver.
Cc: Rafael J. Wysocki <rafael@kernel.org>
Cc: Russell King <linux@armlinux.org.uk>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
drivers/cpufreq/Kconfig.arm | 8 --
drivers/cpufreq/Makefile | 1 -
drivers/cpufreq/integrator-cpufreq.c | 239 -----------------------------------
3 files changed, 248 deletions(-)
delete mode 100644 drivers/cpufreq/integrator-cpufreq.c
diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index d89b8afe23b6..fdbc630272b3 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -60,14 +60,6 @@ config ARM_IMX6Q_CPUFREQ
If in doubt, say N.
-config ARM_INTEGRATOR
- tristate "CPUfreq driver for ARM Integrator CPUs"
- depends on ARCH_INTEGRATOR
- default y
- help
- This enables the CPUfreq driver for ARM Integrator CPUs.
- If in doubt, say Y.
-
config ARM_KIRKWOOD_CPUFREQ
def_bool MACH_KIRKWOOD
help
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index 0a9b6a093646..7dde82179d62 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -56,7 +56,6 @@ obj-$(CONFIG_UX500_SOC_DB8500) += dbx500-cpufreq.o
obj-$(CONFIG_ARM_EXYNOS5440_CPUFREQ) += exynos5440-cpufreq.o
obj-$(CONFIG_ARM_HIGHBANK_CPUFREQ) += highbank-cpufreq.o
obj-$(CONFIG_ARM_IMX6Q_CPUFREQ) += imx6q-cpufreq.o
-obj-$(CONFIG_ARM_INTEGRATOR) += integrator-cpufreq.o
obj-$(CONFIG_ARM_KIRKWOOD_CPUFREQ) += kirkwood-cpufreq.o
obj-$(CONFIG_ARM_MT8173_CPUFREQ) += mt8173-cpufreq.o
obj-$(CONFIG_ARM_OMAP2PLUS_CPUFREQ) += omap-cpufreq.o
diff --git a/drivers/cpufreq/integrator-cpufreq.c b/drivers/cpufreq/integrator-cpufreq.c
deleted file mode 100644
index 79e3ff2771a6..000000000000
--- a/drivers/cpufreq/integrator-cpufreq.c
+++ /dev/null
@@ -1,239 +0,0 @@
-/*
- * Copyright (C) 2001-2002 Deep Blue Solutions Ltd.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- * CPU support functions
- */
-#include <linux/module.h>
-#include <linux/types.h>
-#include <linux/kernel.h>
-#include <linux/cpufreq.h>
-#include <linux/sched.h>
-#include <linux/smp.h>
-#include <linux/init.h>
-#include <linux/io.h>
-#include <linux/platform_device.h>
-#include <linux/of.h>
-#include <linux/of_address.h>
-
-#include <asm/mach-types.h>
-#include <asm/hardware/icst.h>
-
-static void __iomem *cm_base;
-/* The cpufreq driver only use the OSC register */
-#define INTEGRATOR_HDR_OSC_OFFSET 0x08
-#define INTEGRATOR_HDR_LOCK_OFFSET 0x14
-
-static struct cpufreq_driver integrator_driver;
-
-static const struct icst_params lclk_params = {
- .ref = 24000000,
- .vco_max = ICST525_VCO_MAX_5V,
- .vco_min = ICST525_VCO_MIN,
- .vd_min = 8,
- .vd_max = 132,
- .rd_min = 24,
- .rd_max = 24,
- .s2div = icst525_s2div,
- .idx2s = icst525_idx2s,
-};
-
-static const struct icst_params cclk_params = {
- .ref = 24000000,
- .vco_max = ICST525_VCO_MAX_5V,
- .vco_min = ICST525_VCO_MIN,
- .vd_min = 12,
- .vd_max = 160,
- .rd_min = 24,
- .rd_max = 24,
- .s2div = icst525_s2div,
- .idx2s = icst525_idx2s,
-};
-
-/*
- * Validate the speed policy.
- */
-static int integrator_verify_policy(struct cpufreq_policy *policy)
-{
- struct icst_vco vco;
-
- cpufreq_verify_within_cpu_limits(policy);
-
- vco = icst_hz_to_vco(&cclk_params, policy->max * 1000);
- policy->max = icst_hz(&cclk_params, vco) / 1000;
-
- vco = icst_hz_to_vco(&cclk_params, policy->min * 1000);
- policy->min = icst_hz(&cclk_params, vco) / 1000;
-
- cpufreq_verify_within_cpu_limits(policy);
- return 0;
-}
-
-
-static int integrator_set_target(struct cpufreq_policy *policy,
- unsigned int target_freq,
- unsigned int relation)
-{
- cpumask_t cpus_allowed;
- int cpu = policy->cpu;
- struct icst_vco vco;
- struct cpufreq_freqs freqs;
- u_int cm_osc;
-
- /*
- * Save this threads cpus_allowed mask.
- */
- cpus_allowed = current->cpus_allowed;
-
- /*
- * Bind to the specified CPU. When this call returns,
- * we should be running on the right CPU.
- */
- set_cpus_allowed_ptr(current, cpumask_of(cpu));
- BUG_ON(cpu != smp_processor_id());
-
- /* get current setting */
- cm_osc = __raw_readl(cm_base + INTEGRATOR_HDR_OSC_OFFSET);
-
- if (machine_is_integrator())
- vco.s = (cm_osc >> 8) & 7;
- else if (machine_is_cintegrator())
- vco.s = 1;
- vco.v = cm_osc & 255;
- vco.r = 22;
- freqs.old = icst_hz(&cclk_params, vco) / 1000;
-
- /* icst_hz_to_vco rounds down -- so we need the next
- * larger freq in case of CPUFREQ_RELATION_L.
- */
- if (relation == CPUFREQ_RELATION_L)
- target_freq += 999;
- if (target_freq > policy->max)
- target_freq = policy->max;
- vco = icst_hz_to_vco(&cclk_params, target_freq * 1000);
- freqs.new = icst_hz(&cclk_params, vco) / 1000;
-
- if (freqs.old == freqs.new) {
- set_cpus_allowed_ptr(current, &cpus_allowed);
- return 0;
- }
-
- cpufreq_freq_transition_begin(policy, &freqs);
-
- cm_osc = __raw_readl(cm_base + INTEGRATOR_HDR_OSC_OFFSET);
-
- if (machine_is_integrator()) {
- cm_osc &= 0xfffff800;
- cm_osc |= vco.s << 8;
- } else if (machine_is_cintegrator()) {
- cm_osc &= 0xffffff00;
- }
- cm_osc |= vco.v;
-
- __raw_writel(0xa05f, cm_base + INTEGRATOR_HDR_LOCK_OFFSET);
- __raw_writel(cm_osc, cm_base + INTEGRATOR_HDR_OSC_OFFSET);
- __raw_writel(0, cm_base + INTEGRATOR_HDR_LOCK_OFFSET);
-
- /*
- * Restore the CPUs allowed mask.
- */
- set_cpus_allowed_ptr(current, &cpus_allowed);
-
- cpufreq_freq_transition_end(policy, &freqs, 0);
-
- return 0;
-}
-
-static unsigned int integrator_get(unsigned int cpu)
-{
- cpumask_t cpus_allowed;
- unsigned int current_freq;
- u_int cm_osc;
- struct icst_vco vco;
-
- cpus_allowed = current->cpus_allowed;
-
- set_cpus_allowed_ptr(current, cpumask_of(cpu));
- BUG_ON(cpu != smp_processor_id());
-
- /* detect memory etc. */
- cm_osc = __raw_readl(cm_base + INTEGRATOR_HDR_OSC_OFFSET);
-
- if (machine_is_integrator())
- vco.s = (cm_osc >> 8) & 7;
- else
- vco.s = 1;
- vco.v = cm_osc & 255;
- vco.r = 22;
-
- current_freq = icst_hz(&cclk_params, vco) / 1000; /* current freq */
-
- set_cpus_allowed_ptr(current, &cpus_allowed);
-
- return current_freq;
-}
-
-static int integrator_cpufreq_init(struct cpufreq_policy *policy)
-{
-
- /* set default policy and cpuinfo */
- policy->max = policy->cpuinfo.max_freq = 160000;
- policy->min = policy->cpuinfo.min_freq = 12000;
- policy->cpuinfo.transition_latency = 1000000; /* 1 ms, assumed */
-
- return 0;
-}
-
-static struct cpufreq_driver integrator_driver = {
- .flags = CPUFREQ_NEED_INITIAL_FREQ_CHECK,
- .verify = integrator_verify_policy,
- .target = integrator_set_target,
- .get = integrator_get,
- .init = integrator_cpufreq_init,
- .name = "integrator",
-};
-
-static int __init integrator_cpufreq_probe(struct platform_device *pdev)
-{
- struct resource *res;
-
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!res)
- return -ENODEV;
-
- cm_base = devm_ioremap(&pdev->dev, res->start, resource_size(res));
- if (!cm_base)
- return -ENODEV;
-
- return cpufreq_register_driver(&integrator_driver);
-}
-
-static int __exit integrator_cpufreq_remove(struct platform_device *pdev)
-{
- return cpufreq_unregister_driver(&integrator_driver);
-}
-
-static const struct of_device_id integrator_cpufreq_match[] = {
- { .compatible = "arm,core-module-integrator"},
- { },
-};
-
-MODULE_DEVICE_TABLE(of, integrator_cpufreq_match);
-
-static struct platform_driver integrator_cpufreq_driver = {
- .driver = {
- .name = "integrator-cpufreq",
- .of_match_table = integrator_cpufreq_match,
- },
- .remove = __exit_p(integrator_cpufreq_remove),
-};
-
-module_platform_driver_probe(integrator_cpufreq_driver,
- integrator_cpufreq_probe);
-
-MODULE_AUTHOR("Russell M. King");
-MODULE_DESCRIPTION("cpufreq driver for ARM Integrator CPUs");
-MODULE_LICENSE("GPL");
--
2.7.4
^ permalink raw reply related
* [PATCH 1/2] cpufreq: enable the DT cpufreq driver on the Integrators
From: Linus Walleij @ 2016-10-25 7:21 UTC (permalink / raw)
To: linux-arm-kernel
This enables the generic DT and OPP-based cpufreq driver on the
ARM Integrator/AP and Integrator/CP.
Cc: Rafael J. Wysocki <rafael@kernel.org>
Cc: Russell King <linux@armlinux.org.uk>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
drivers/cpufreq/cpufreq-dt-platdev.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq-dt-platdev.c
index 71267626456b..142a6f615e52 100644
--- a/drivers/cpufreq/cpufreq-dt-platdev.c
+++ b/drivers/cpufreq/cpufreq-dt-platdev.c
@@ -26,6 +26,9 @@ static const struct of_device_id machines[] __initconst = {
{ .compatible = "allwinner,sun8i-a83t", },
{ .compatible = "allwinner,sun8i-h3", },
+ { .compatible = "arm,integrator-ap", },
+ { .compatible = "arm,integrator-cp", },
+
{ .compatible = "hisilicon,hi6220", },
{ .compatible = "fsl,imx27", },
--
2.7.4
^ permalink raw reply related
* [PATCH RESEND 1/2] dt: bindings: add allwinner,otg-routed property for phy-sun4i-usb
From: Maxime Ripard @ 2016-10-25 7:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161025041139.46454-1-icenowy@aosc.xyz>
Hi,
On Tue, Oct 25, 2016 at 12:11:38PM +0800, Icenowy Zheng wrote:
> On some newer Allwinner SoCs (H3 or A64), the PHY0 can be either routed to
> the MUSB controller (which is an OTG controller) or the OHCI/EHCI pair
> (which is a Host-only controller, but more stable and easy to implement).
>
> This property marks whether on a certain board which controller should be
> attached to the PHY.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
Didn't Hans reject this already? Why are you resending it?
Thanks,
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161025/027156a6/attachment.sig>
^ permalink raw reply
* [PATCH 0/5] Switch to the DT cpufreq policy on the Integrator
From: Linus Walleij @ 2016-10-25 7:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJZ5v0gb8XTTrSgQzT==7=tLiAyy3RemmVnDYfm-kNULw0_uZQ@mail.gmail.com>
On Mon, Oct 24, 2016 at 10:15 PM, Rafael J. Wysocki <rafael@kernel.org> wrote:
> On Mon, Oct 24, 2016 at 9:28 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
>> On Wed, Oct 19, 2016 at 12:14 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>>
>>> I don't see any hard dependency here, so I'd suggest to merge the
>>> two cpufreq patches through the subsystem tree, and the ARM patches
>>> through arm-soc.
>>
>> That's right, Viresh can you merge patches 1 and 5 to the
>> cpufreq tree please?
>
> Well, that would be me.
>
> Can you please resend the two as a separate series, with all tags
> collected so far if any?
Sure no problem.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] nvmem: sunxi-sid: SID content is not a valid source of randomness
From: Jean-Francois Moine @ 2016-10-25 7:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161025053855.GA901@Red>
On Tue, 25 Oct 2016 07:38:55 +0200
LABBE Corentin <clabbe.montjoie@gmail.com> wrote:
> > On Sat, Oct 22, 2016 at 03:53:28PM +0200, Corentin Labbe wrote:
> > > Since SID's content is constant over reboot,
> >
> > That's not true, at least not across all the Allwinner SoCs, and
> > especially not on the A10 and A20 that this driver supports.
> >
>
> On my cubieboard2 (A20)
> hexdump -C /sys/devices/platform/soc\@01c00000/1c23800.eeprom/sunxi-sid0/nvmem
> 00000000 16 51 66 83 80 48 50 72 56 54 48 48 03 c2 75 72 |.Qf..HPrVTHH..ur|
> 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> *
> 00000100 16 51 66 83 80 48 50 72 56 54 48 48 03 c2 75 72 |.Qf..HPrVTHH..ur|
> 00000110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> *
> 00000200
> cubiedev ~ # reboot
> cubiedev ~ # hexdump -C /sys/devices/platform/soc\@01c00000/1c23800.eeprom/sunxi-sid0/nvmem
> 00000000 16 51 66 83 80 48 50 72 56 54 48 48 03 c2 75 72 |.Qf..HPrVTHH..ur|
> 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> *
> 00000100 16 51 66 83 80 48 50 72 56 54 48 48 03 c2 75 72 |.Qf..HPrVTHH..ur|
> 00000110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> *
> 00000200
>
> So clearly for me its constant.
Even after power off/power on?
--
Ken ar c'henta? | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
^ permalink raw reply
* [PATCH v5 1/7] drm: sunxi: Add a basic DRM driver for Allwinner DE2
From: Daniel Vetter @ 2016-10-25 6:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161025064422.4jua6qmpr7zu3ijt@phenom.ffwll.local>
On Tue, Oct 25, 2016 at 08:44:22AM +0200, Daniel Vetter wrote:
> On Fri, Oct 21, 2016 at 09:26:18AM +0200, Jean-Francois Moine wrote:
> > +static int de2_drm_bind(struct device *dev)
> > +{
> > + struct drm_device *drm;
> > + struct priv *priv;
> > + int ret;
> > +
> > + drm = drm_dev_alloc(&de2_drm_driver, dev);
Oh and you might want to look into drm_dev_init, allows you to use
subclassing instead of pointer chasing for your driver-private data.
-Daniel
> > + if (!drm)
> > + return -ENOMEM;
> > +
> > + priv = kzalloc(sizeof(*priv), GFP_KERNEL);
> > + if (!priv) {
> > + dev_err(dev, "failed to allocate private area\n");
> > + ret = -ENOMEM;
> > + goto out1;
> > + }
> > +
> > + dev_set_drvdata(dev, drm);
> > + drm->dev_private = priv;
> > +
> > + drm_mode_config_init(drm);
> > + drm->mode_config.min_width = 32; /* needed for cursor */
> > + drm->mode_config.min_height = 32;
> > + drm->mode_config.max_width = 1920;
> > + drm->mode_config.max_height = 1080;
> > + drm->mode_config.funcs = &de2_mode_config_funcs;
> > +
> > + drm->irq_enabled = true;
> > +
> > + /* initialize the display engine */
> > + priv->soc_type = (int) of_match_device(de2_drm_of_match, dev)->data;
> > + ret = de2_de_init(priv, dev);
> > + if (ret)
> > + goto out2;
> > +
> > + /* start the subdevices */
> > + ret = component_bind_all(dev, drm);
> > + if (ret < 0)
> > + goto out2;
> > +
> > + ret = drm_dev_register(drm, 0);
>
> This needs to be the very last step in your driver load sequence.
> Kerneldoc explains why. Similar, but inverted for unloading:
> drm_dev_unregister is the very first thing you must call.
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply
* [PATCH v5 1/7] drm: sunxi: Add a basic DRM driver for Allwinner DE2
From: Daniel Vetter @ 2016-10-25 6:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8afc5e020c5767face34fe3a9ab300ce9e67ba00.1477142934.git.moinejf@free.fr>
On Fri, Oct 21, 2016 at 09:26:18AM +0200, Jean-Francois Moine wrote:
> +static int de2_drm_bind(struct device *dev)
> +{
> + struct drm_device *drm;
> + struct priv *priv;
> + int ret;
> +
> + drm = drm_dev_alloc(&de2_drm_driver, dev);
> + if (!drm)
> + return -ENOMEM;
> +
> + priv = kzalloc(sizeof(*priv), GFP_KERNEL);
> + if (!priv) {
> + dev_err(dev, "failed to allocate private area\n");
> + ret = -ENOMEM;
> + goto out1;
> + }
> +
> + dev_set_drvdata(dev, drm);
> + drm->dev_private = priv;
> +
> + drm_mode_config_init(drm);
> + drm->mode_config.min_width = 32; /* needed for cursor */
> + drm->mode_config.min_height = 32;
> + drm->mode_config.max_width = 1920;
> + drm->mode_config.max_height = 1080;
> + drm->mode_config.funcs = &de2_mode_config_funcs;
> +
> + drm->irq_enabled = true;
> +
> + /* initialize the display engine */
> + priv->soc_type = (int) of_match_device(de2_drm_of_match, dev)->data;
> + ret = de2_de_init(priv, dev);
> + if (ret)
> + goto out2;
> +
> + /* start the subdevices */
> + ret = component_bind_all(dev, drm);
> + if (ret < 0)
> + goto out2;
> +
> + ret = drm_dev_register(drm, 0);
This needs to be the very last step in your driver load sequence.
Kerneldoc explains why. Similar, but inverted for unloading:
drm_dev_unregister is the very first thing you must call.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply
* [PATCH 3/4] iommu/arm-smmu: Add context save restore support
From: Sricharan @ 2016-10-25 6:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANLsYkxumkKodObeH9N4KGecsWYpwEo1DfR1WrBctzRY-ESFrg@mail.gmail.com>
Hi,
>> The smes registers and the context bank registers are
>> back. The data required to configure the context banks
>> are the master's domain data and pgtable cfgs.
>> So store them as a part of the context banks info
>> the ones that are needs to be saved and restored.
>> Fortunately the smes are already stored as a part
>> of the smmu device structure. So just write that
>> and just reconfigure the context banks on the restore
>> path.
>>
>> Signed-off-by: Sricharan R <sricharan@codeaurora.org>
>> ---
>> drivers/iommu/arm-smmu.c | 52 +++++++++++++++++++++++++++++++++++++++++++++++-
>> 1 file changed, 51 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
>> index 45f2762..578cdc2 100644
>> --- a/drivers/iommu/arm-smmu.c
>> +++ b/drivers/iommu/arm-smmu.c
>> @@ -328,6 +328,11 @@ struct arm_smmu_master_cfg {
>> #define for_each_cfg_sme(fw, i, idx) \
>> for (i = 0; idx = __fwspec_cfg(fw)->smendx[i], i < fw->num_ids; ++i)
>>
>> +struct cbinfo {
>> + struct arm_smmu_domain *domain;
>> + struct io_pgtable_cfg pgtbl_cfg;
>> +};
>> +
>> struct arm_smmu_device {
>> struct device *dev;
>>
>> @@ -378,6 +383,9 @@ struct arm_smmu_device {
>> struct clk **clocks;
>>
>> u32 cavium_id_base; /* Specific to Cavium */
>> +
>> + /* For save/restore of context bank registers */
>> + struct cbinfo *cb_saved_ctx;
>
>It's not that clear to me this will become an array - better
>documentation would help reviewing the code.
ok, will add the doc for this.
>
>> };
>>
>> enum arm_smmu_context_fmt {
>> @@ -972,6 +980,8 @@ static int arm_smmu_init_domain_context(struct iommu_domain *domain,
>>
>> /* Initialise the context bank with our page table cfg */
>> arm_smmu_init_context_bank(smmu_domain, &pgtbl_cfg);
>> + smmu->cb_saved_ctx[cfg->cbndx].domain = smmu_domain;
>> + smmu->cb_saved_ctx[cfg->cbndx].pgtbl_cfg = pgtbl_cfg;
>>
>> /*
>> * Request context fault interrupt. Do this last to avoid the
>> @@ -1861,6 +1871,10 @@ static int arm_smmu_device_cfg_probe(struct arm_smmu_device *smmu)
>> }
>> dev_notice(smmu->dev, "\t%u context banks (%u stage-2 only)\n",
>> smmu->num_context_banks, smmu->num_s2_context_banks);
>> +
>> + smmu->cb_saved_ctx = devm_kzalloc(smmu->dev,
>> + sizeof(struct cbinfo) * smmu->num_context_banks,
>> + GFP_KERNEL);
>> /*
>> * Cavium CN88xx erratum #27704.
>> * Ensure ASID and VMID allocation is unique across all SMMUs in
>> @@ -2115,8 +2129,44 @@ static int arm_smmu_resume(struct device *dev)
>> {
>> struct platform_device *pdev = to_platform_device(dev);
>> struct arm_smmu_device *smmu = platform_get_drvdata(pdev);
>> + struct arm_smmu_domain *domain = NULL;
>> + struct io_pgtable_cfg *pgtbl_cfg = NULL;
>> + struct arm_smmu_smr *smrs = smmu->smrs;
>> + int i = 0, idx, cb, ret, pcb = 0;
>> +
>> + ret = arm_smmu_enable_clocks(smmu);
>> + if (ret)
>> + return ret;
>> +
>> + arm_smmu_device_reset(smmu);
>>
>> - return arm_smmu_enable_clocks(smmu);
>> + /* Restore the smes and the context banks */
>> + for (idx = 0; idx < smmu->num_mapping_groups; ++idx) {
>> + mutex_lock(&smmu->stream_map_mutex);
>> + if (!smrs[idx].valid) {
>> + mutex_unlock(&smmu->stream_map_mutex);
>> + continue;
>> + }
>> +
>> + arm_smmu_write_sme(smmu, idx);
>> + cb = smmu->s2crs[idx].cbndx;
>> + mutex_unlock(&smmu->stream_map_mutex);
>> +
>> + if (!i || (cb != pcb)) {
>> + domain = smmu->cb_saved_ctx[cb].domain;
>> + pgtbl_cfg = &smmu->cb_saved_ctx[cb].pgtbl_cfg;
>> +
>> + if (domain) {
>> + mutex_lock(&domain->init_mutex);
>> + arm_smmu_init_context_bank(domain, pgtbl_cfg);
>> + mutex_unlock(&domain->init_mutex);
>> + }
>> + }
>> + pcb = cb;
>> + i++;
>
>What are you doing with variable 'i'? Again, some comments would
>greatly help with reviewing.
hmm, i was using variable 'i' to pass through the 'if' first time
even if cb != pcb, because pcb is uninitialized at that point.
But i could just initialize 'pcb' with some -EINVAL and then
avoid the extra 'i' itself. Also check for cb != pcb was required
because same context bank could be populated multiple times
for different sids in sequence. I will document these and send V2.
Thanks for your time to review this.
Regards,
Sricharan
^ permalink raw reply
* [PATCH] drivers: mfd: ti_am335x_tscadc: increase ADC ref clock to 24MHz
From: Lee Jones @ 2016-10-25 6:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <DB09B26E-C5AB-427A-82D5-6FE857E7C218@gmail.com>
On Mon, 24 Oct 2016, John Syne wrote:
> > On Oct 24, 2016, at 11:01 PM, John Syne <john3909@gmail.com> wrote:
> >> On Oct 24, 2016, at 10:52 PM, Mugunthan V N <mugunthanvnm@ti.com> wrote:
> >>
> >> On Tuesday 25 October 2016 02:28 AM, John Syne wrote:
> >>>>> On Oct 23, 2016, at 11:02 PM, Mugunthan V N <mugunthanvnm@ti.com> wrote:
> >>>>>
> >>>>> Increase ADC reference clock from 3MHz to 24MHz so that the
> >>>>> sampling rates goes up from 100K samples per second to 800K
> >>>>> samples per second on AM335x and AM437x SoC.
> >>>>>
> >>>>> Also increase opendelay for touchscreen configuration to
> >>>>> equalize the increase in ADC reference clock frequency,
> >>>>> which results in the same amount touch events reported via
> >>>>> evtest on AM335x GP EVM.
> >>>>>
> >>>>> Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
> >>>>> ---
> >>>>>
> >>>>> This patch depends on ADC DMA patch series [1]
> >>>>>
> >>>>> Without DMA support, when ADC ref clock is set at 24MHz, I am
> >>>>> seeing fifo overflow as CPU is not able to pull the ADC samples.
> >>>>> This answers that DMA support is must for ADC to consume the
> >>>>> samples generated at 24MHz with no open, step delay or
> >>>>> averaging with patch [2].
> >>>>>
> >>>>> Measured the performance with the iio_generic_buffer with the
> >>>>> patch [3] applied
> >>>>>
> >>>>> [1] - http://www.spinics.net/lists/devicetree/msg145045.html
> >>>>> [2] - http://pastebin.ubuntu.com/23357935/
> >>>>> [3] - http://pastebin.ubuntu.com/23357939/
> >>>>>
> >>>>> ---
> >>>>> include/linux/mfd/ti_am335x_tscadc.h | 4 ++--
> >>>>> 1 file changed, 2 insertions(+), 2 deletions(-)
> >>>>>
> >>>>> diff --git a/include/linux/mfd/ti_am335x_tscadc.h b/include/linux/mfd/ti_am335x_tscadc.h
> >>>>> index b9a53e0..96c4207 100644
> >>>>> --- a/include/linux/mfd/ti_am335x_tscadc.h
> >>>>> +++ b/include/linux/mfd/ti_am335x_tscadc.h
> >>>>> @@ -90,7 +90,7 @@
> >>>>> /* Delay register */
> >>>>> #define STEPDELAY_OPEN_MASK (0x3FFFF << 0)
> >>>>> #define STEPDELAY_OPEN(val) ((val) << 0)
> >>>>> -#define STEPCONFIG_OPENDLY STEPDELAY_OPEN(0x098)
> >>> Wouldn?t this be better to add this to the devicetree?
> >>>
> >>> ti,chan-step-avg = <0x16 0x16 0x16 0x16 0x16 0x16 0x16>;
> >>> ti,chan-step-opendelay = <0x500 0x500 0x500 0x500 0x500 0x500 0x500>;
> >>> ti,chan-step-sampledelay = <0x0 0x0 0x0 0x0 0x0 0x0 0x0>;
> >>
> >> For a touch screen, there is not need to change in these parameter
> >> settings, so my opinion is to keep it as is. Or am I missing something?
> > I was thinking that if you are using this driver as an ADC, you may want the flexibility to make these changes in the DT. I?m doing this by connecting sensors to the ADC inputs. I?m not using this driver for a touchscreen.
>
> Here is a DT overlay were this gets using on the BeagleBoneBlack.
>
> https://github.com/RobertCNelson/bb.org-overlays/blob/master/src/arm/BB-ADC-00A0.dts
>
> Besides, these DT features are already implemented in the driver so it is just a matter of adding these entries to the am33xx.dtsi & am4372.dtsi, which you modified in this patch series.
This looks like configuration, no?
DT should be used to describe the hardware.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH] drivers: mfd: ti_am335x_tscadc: increase ADC ref clock to 24MHz
From: Vignesh R @ 2016-10-25 6:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <DB09B26E-C5AB-427A-82D5-6FE857E7C218@gmail.com>
On Tuesday 25 October 2016 11:46 AM, John Syne wrote:
>
>> On Oct 24, 2016, at 11:01 PM, John Syne <john3909@gmail.com> wrote:
>>
>>>
>>> On Oct 24, 2016, at 10:52 PM, Mugunthan V N <mugunthanvnm@ti.com> wrote:
>>>
[...]
>>>>>>
>>>>>> ---
>>>>>> include/linux/mfd/ti_am335x_tscadc.h | 4 ++--
>>>>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>>>>
>>>>>> diff --git a/include/linux/mfd/ti_am335x_tscadc.h b/include/linux/mfd/ti_am335x_tscadc.h
>>>>>> index b9a53e0..96c4207 100644
>>>>>> --- a/include/linux/mfd/ti_am335x_tscadc.h
>>>>>> +++ b/include/linux/mfd/ti_am335x_tscadc.h
>>>>>> @@ -90,7 +90,7 @@
>>>>>> /* Delay register */
>>>>>> #define STEPDELAY_OPEN_MASK (0x3FFFF << 0)
>>>>>> #define STEPDELAY_OPEN(val) ((val) << 0)
>>>>>> -#define STEPCONFIG_OPENDLY STEPDELAY_OPEN(0x098)
>>>> Wouldn?t this be better to add this to the devicetree?
>>>>
>>>> ti,chan-step-avg = <0x16 0x16 0x16 0x16 0x16 0x16 0x16>;
>>>> ti,chan-step-opendelay = <0x500 0x500 0x500 0x500 0x500 0x500 0x500>;
>>>> ti,chan-step-sampledelay = <0x0 0x0 0x0 0x0 0x0 0x0 0x0>;
>>>
>>> For a touch screen, there is not need to change in these parameter
>>> settings, so my opinion is to keep it as is. Or am I missing something?
>> I was thinking that if you are using this driver as an ADC, you may want the flexibility to make these changes in the DT. I?m doing this by connecting sensors to the ADC inputs. I?m not using this driver for a touchscreen.
>
ti_am335x_adc driver already supports above DT parameters and its upto
the user to adjust these parameters as required.
> Here is a DT overlay were this gets using on the BeagleBoneBlack.
>
> https://github.com/RobertCNelson/bb.org-overlays/blob/master/src/arm/BB-ADC-00A0.dts
>
> Besides, these DT features are already implemented in the driver so it is just a matter of adding these entries to the am33xx.dtsi & am4372.dtsi, which you modified in this patch series.
>
Touchscreen driver (ti_am335x_tsc.c) does not support above DT parameters.
--
Regards
Vignesh
^ permalink raw reply
* [PATCH 2/4] iommu/arm-smmu: Add pm_runtime/sleep ops
From: Sricharan @ 2016-10-25 6:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANLsYkw8Y-5MkeM2U9fLWX951Mo7ErsMCUBjSx3-0689jWD4rQ@mail.gmail.com>
Hi,
>On 21 October 2016 at 11:14, Sricharan R <sricharan@codeaurora.org> wrote:
>> The smmu needs to be functional when the respective
>> master/s using it are active. As there is a device_link
>> between the master and smmu, the pm runtime ops for the smmu
>> gets invoked in sync with the master's runtime, thus the
>> smmu remains powered only when needed.
>>
>> There are couple of places in the driver during probe,
>> master attach, where the smmu needs to be clocked without
>> the context of the master. So doing a pm_runtime_get/put sync
>> in those places separately.
>>
>> Signed-off-by: Sricharan R <sricharan@codeaurora.org>
>> ---
>> drivers/iommu/arm-smmu.c | 109 ++++++++++++++++++++++++++++++++++++++++++++++-
>> 1 file changed, 108 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
>> index 083489e4..45f2762 100644
>> --- a/drivers/iommu/arm-smmu.c
>> +++ b/drivers/iommu/arm-smmu.c
>> @@ -45,6 +45,7 @@
>> #include <linux/of_iommu.h>
>> #include <linux/pci.h>
>> #include <linux/platform_device.h>
>> +#include <linux/pm_runtime.h>
>> #include <linux/slab.h>
>> #include <linux/spinlock.h>
>>
>> @@ -373,6 +374,8 @@ struct arm_smmu_device {
>> u32 num_global_irqs;
>> u32 num_context_irqs;
>> unsigned int *irqs;
>> + int num_clocks;
>> + struct clk **clocks;
>>
>> u32 cavium_id_base; /* Specific to Cavium */
>> };
>> @@ -430,6 +433,31 @@ static struct arm_smmu_domain *to_smmu_domain(struct iommu_domain *dom)
>> return container_of(dom, struct arm_smmu_domain, domain);
>> }
>>
>> +static int arm_smmu_enable_clocks(struct arm_smmu_device *smmu)
>> +{
>> + int i, ret = 0;
>> +
>> + for (i = 0; i < smmu->num_clocks; ++i) {
>> + ret = clk_prepare_enable(smmu->clocks[i]);
>> + if (ret) {
>> + dev_err(smmu->dev, "Couldn't enable clock #%d\n", i);
>> + while (i--)
>> + clk_disable_unprepare(smmu->clocks[i]);
>> + break;
>> + }
>> + }
>> +
>> + return ret;
>> +}
>> +
>> +static void arm_smmu_disable_clocks(struct arm_smmu_device *smmu)
>> +{
>> + int i;
>> +
>> + for (i = 0; i < smmu->num_clocks; ++i)
>> + clk_disable_unprepare(smmu->clocks[i]);
>> +}
>> +
>> static void parse_driver_options(struct arm_smmu_device *smmu)
>> {
>> int i = 0;
>> @@ -1187,11 +1215,13 @@ static void arm_smmu_master_free_smes(struct iommu_fwspec *fwspec)
>> int i, idx;
>>
>> mutex_lock(&smmu->stream_map_mutex);
>> + pm_runtime_get_sync(smmu->dev);
>
>Since this is generic code it is probably a good idea to check the
>return value, same for _put_sync() below.
Ok, i will do it for V2.
>
>> for_each_cfg_sme(fwspec, i, idx) {
>> if (arm_smmu_free_sme(smmu, idx))
>> arm_smmu_write_sme(smmu, idx);
>> cfg->smendx[i] = INVALID_SMENDX;
>> }
>> + pm_runtime_put_sync(smmu->dev);
>> mutex_unlock(&smmu->stream_map_mutex);
>> }
>>
>> @@ -1424,9 +1454,11 @@ static int arm_smmu_add_device(struct device *dev)
>> while (i--)
>> cfg->smendx[i] = INVALID_SMENDX;
>>
>> + pm_runtime_get_sync(smmu->dev);
>> ret = arm_smmu_master_alloc_smes(dev);
>> if (ret)
>> goto out_free;
>> + pm_runtime_put_sync(smmu->dev);
>>
>> return 0;
>>
>> @@ -1650,6 +1682,44 @@ static int arm_smmu_id_size_to_bits(int size)
>> }
>> }
>>
>> +static int arm_smmu_init_clocks(struct arm_smmu_device *smmu)
>> +{
>> + const char *cname;
>> + struct property *prop;
>> + int i;
>> + struct device *dev = smmu->dev;
>> +
>> + smmu->num_clocks =
>> + of_property_count_strings(dev->of_node, "clock-names");
>> +
>> + if (smmu->num_clocks < 1)
>> + return 0;
>> +
>> + smmu->clocks = devm_kzalloc(dev,
>> + sizeof(*smmu->clocks) * smmu->num_clocks,
>> + GFP_KERNEL);
>> +
>> + if (!smmu->clocks) {
>> + dev_err(dev, "Failed to allocate memory for clocks\n");
>> + return -ENODEV;
>> + }
>> +
>> + i = 0;
>
>Please do the initialisation above when you declare the variable.
ok, will change it.
Regards,
Sricharan
^ permalink raw reply
* [PATCH V3 0/8] IOMMU probe deferral support
From: Archit Taneja @ 2016-10-25 6:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475600632-21289-1-git-send-email-sricharan@codeaurora.org>
On 10/04/2016 10:33 PM, Sricharan R wrote:
> Initial post from Laurent Pinchart[1]. This is
> series calls the dma ops configuration for the devices
> at a generic place so that it works for all busses.
> The dma_configure_ops for a device is now called during
> the device_attach callback just before the probe of the
> bus/driver is called. Similarly dma_deconfigure is called during
> device/driver_detach path.
>
>
> pci_bus_add_devices (platform/amba)(_device_create/driver_register)
> | |
> pci_bus_add_device (device_add/driver_register)
> | |
> device_attach device_initial_probe
> | |
> __device_attach_driver __device_attach_driver
> |
> driver_probe_device
> |
> really_probe
> |
> dma_configure
>
> Similarly on the device/driver_unregister path __device_release_driver is
> called which inturn calls dma_deconfigure.
>
> If the ACPI bus code follows the same, we can add acpi_dma_configure
> at the same place as of_dma_configure.
>
> This series is based on the recently merged Generic DT bindings for
> PCI IOMMUs and ARM SMMU from Robin Murphy robin.murphy at arm.com [2]
>
> This time tested this with platform and pci device for probe deferral
> and reprobe on arm64 based platform. There is an issue on the cleanup
> path for arm64 though, where there is WARN_ON if the dma_ops is reset while
> device is attached to an domain in arch_teardown_dma_ops.
> But with iommu_groups created from the iommu driver, the device is always
> attached to a domain/default_domain. So so the WARN has to be removed/handled
> probably.
>
Tested-by: Archit Taneja <architt@codeaurora.org>
> Previous post of this series [3].
>
> [V3]
> * Removed the patch to split dma_masks/dma_ops configuration separately
> based on review comments that both masks and ops are required only
> during the device probe time.
>
> * Reworked the series based on Generic DT bindings series [2].
>
> * Added call to iommu's remove_device in the cleanup path for arm and arm64.
>
> * Removed the notifier trick in arm64 to handle early device registration.
>
> * Added reset of dma_ops in cleanup path for arm based on comments.
>
> * Fixed the pci_iommu_configure path and tested with PCI device as well.
>
> * Fixed a bug to return the correct iommu_ops from patch 7 [4] in last post.
>
> * Fixed few other cosmetic comments.
>
> [V2]
> * Updated the Initial post to call dma_configure/deconfigure from generic code
>
> * Added iommu add_device callback from of_iommu_configure path
>
> [V1]
> * Initial post
>
> [1] http://lists.linuxfoundation.org/pipermail/iommu/2015-May/013016.html
> [2] http://www.spinics.net/lists/devicetree/msg142943.html
> [3] https://www.mail-archive.com/iommu at lists.linux-foundation.org/msg13941.html
> [4] https://www.mail-archive.com/iommu at lists.linux-foundation.org/msg13940.html
>
>
>
> Laurent Pinchart (4):
> arm: dma-mapping: Don't override dma_ops in arch_setup_dma_ops()
> of: dma: Move range size workaround to of_dma_get_range()
> of: dma: Make of_dma_deconfigure() public
> iommu: of: Handle IOMMU lookup failure with deferred probing or error
>
> Sricharan R (4):
> drivers: platform: Configure dma operations at probe time
> arm: dma-mapping: Reset the device's dma_ops
> arm/arm64: dma-mapping: Call iommu's remove_device callback during
> device detach
> arm64: dma-mapping: Remove the notifier trick to handle early setting
> of dma_ops
>
> arch/arm/mm/dma-mapping.c | 18 ++++++++
> arch/arm64/mm/dma-mapping.c | 107 +++++---------------------------------------
> drivers/base/dd.c | 10 +++++
> drivers/base/dma-mapping.c | 11 +++++
> drivers/iommu/of_iommu.c | 47 +++++++++++++++++--
> drivers/of/address.c | 20 ++++++++-
> drivers/of/device.c | 34 +++++++-------
> drivers/of/platform.c | 9 ----
> drivers/pci/probe.c | 5 +--
> include/linux/dma-mapping.h | 3 ++
> include/linux/of_device.h | 7 ++-
> 11 files changed, 138 insertions(+), 133 deletions(-)
>
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH] drivers: mfd: ti_am335x_tscadc: increase ADC ref clock to 24MHz
From: John Syne @ 2016-10-25 6:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <12725C92-9BB8-4F77-A7B4-F3C3DA9F8B0B@gmail.com>
> On Oct 24, 2016, at 11:01 PM, John Syne <john3909@gmail.com> wrote:
>
>>
>> On Oct 24, 2016, at 10:52 PM, Mugunthan V N <mugunthanvnm@ti.com> wrote:
>>
>> On Tuesday 25 October 2016 02:28 AM, John Syne wrote:
>>>>> On Oct 23, 2016, at 11:02 PM, Mugunthan V N <mugunthanvnm@ti.com> wrote:
>>>>>
>>>>> Increase ADC reference clock from 3MHz to 24MHz so that the
>>>>> sampling rates goes up from 100K samples per second to 800K
>>>>> samples per second on AM335x and AM437x SoC.
>>>>>
>>>>> Also increase opendelay for touchscreen configuration to
>>>>> equalize the increase in ADC reference clock frequency,
>>>>> which results in the same amount touch events reported via
>>>>> evtest on AM335x GP EVM.
>>>>>
>>>>> Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
>>>>> ---
>>>>>
>>>>> This patch depends on ADC DMA patch series [1]
>>>>>
>>>>> Without DMA support, when ADC ref clock is set at 24MHz, I am
>>>>> seeing fifo overflow as CPU is not able to pull the ADC samples.
>>>>> This answers that DMA support is must for ADC to consume the
>>>>> samples generated at 24MHz with no open, step delay or
>>>>> averaging with patch [2].
>>>>>
>>>>> Measured the performance with the iio_generic_buffer with the
>>>>> patch [3] applied
>>>>>
>>>>> [1] - http://www.spinics.net/lists/devicetree/msg145045.html
>>>>> [2] - http://pastebin.ubuntu.com/23357935/
>>>>> [3] - http://pastebin.ubuntu.com/23357939/
>>>>>
>>>>> ---
>>>>> include/linux/mfd/ti_am335x_tscadc.h | 4 ++--
>>>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/include/linux/mfd/ti_am335x_tscadc.h b/include/linux/mfd/ti_am335x_tscadc.h
>>>>> index b9a53e0..96c4207 100644
>>>>> --- a/include/linux/mfd/ti_am335x_tscadc.h
>>>>> +++ b/include/linux/mfd/ti_am335x_tscadc.h
>>>>> @@ -90,7 +90,7 @@
>>>>> /* Delay register */
>>>>> #define STEPDELAY_OPEN_MASK (0x3FFFF << 0)
>>>>> #define STEPDELAY_OPEN(val) ((val) << 0)
>>>>> -#define STEPCONFIG_OPENDLY STEPDELAY_OPEN(0x098)
>>> Wouldn?t this be better to add this to the devicetree?
>>>
>>> ti,chan-step-avg = <0x16 0x16 0x16 0x16 0x16 0x16 0x16>;
>>> ti,chan-step-opendelay = <0x500 0x500 0x500 0x500 0x500 0x500 0x500>;
>>> ti,chan-step-sampledelay = <0x0 0x0 0x0 0x0 0x0 0x0 0x0>;
>>
>> For a touch screen, there is not need to change in these parameter
>> settings, so my opinion is to keep it as is. Or am I missing something?
> I was thinking that if you are using this driver as an ADC, you may want the flexibility to make these changes in the DT. I?m doing this by connecting sensors to the ADC inputs. I?m not using this driver for a touchscreen.
Here is a DT overlay were this gets using on the BeagleBoneBlack.
https://github.com/RobertCNelson/bb.org-overlays/blob/master/src/arm/BB-ADC-00A0.dts
Besides, these DT features are already implemented in the driver so it is just a matter of adding these entries to the am33xx.dtsi & am4372.dtsi, which you modified in this patch series.
Regards,
John
>
> Regards,
> John
>>
>> Regards
>> Mugunthan V N
^ permalink raw reply
* [PATCH v1] ARM: at91/dt: add dts file for sama5d36ek CMP board
From: Wenyou Yang @ 2016-10-25 6:08 UTC (permalink / raw)
To: linux-arm-kernel
The difference between sama5d36ek_cmp.dts and sama5d36ek.dts
is listed as below.
1. The USB host nodes are removed, that is, the USB host is disabled.
2. The gpio_keys node is added to wake up from the sleep.
3. The sama5d3xdm.dtsi isn't included, because the pins for LCD are
conflicted with one for gpio_keys.
As said in errata, "When the USB host ports are used in high speed
mode (EHCI), it is not possible to suspend the ports if no device is
attached on each port. This leads to increased power consumption even
if the system is in a low power mode." That is why the the USB host
isn't enabled.
Signed-off-by: Wenyou Yang <wenyou.yang@atmel.com>
---
arch/arm/boot/dts/sama5d36ek_cmp.dts | 51 ++++++++
arch/arm/boot/dts/sama5d3xcm_cmp.dtsi | 166 ++++++++++++++++++++++++
arch/arm/boot/dts/sama5d3xmb_cmp.dtsi | 230 ++++++++++++++++++++++++++++++++++
3 files changed, 447 insertions(+)
create mode 100644 arch/arm/boot/dts/sama5d36ek_cmp.dts
create mode 100644 arch/arm/boot/dts/sama5d3xcm_cmp.dtsi
create mode 100644 arch/arm/boot/dts/sama5d3xmb_cmp.dtsi
diff --git a/arch/arm/boot/dts/sama5d36ek_cmp.dts b/arch/arm/boot/dts/sama5d36ek_cmp.dts
new file mode 100644
index 0000000..fd6bcd6
--- /dev/null
+++ b/arch/arm/boot/dts/sama5d36ek_cmp.dts
@@ -0,0 +1,51 @@
+/*
+ * sama5d36ek_cmp.dts - Device Tree file for SAMA5D36-EK CMP board
+ *
+ * Copyright (C) 2016 Atmel,
+ *
+ * Licensed under GPLv2 or later.
+ */
+/dts-v1/;
+#include "sama5d36.dtsi"
+#include "sama5d3xmb_cmp.dtsi"
+
+/ {
+ model = "Atmel SAMA5D36-EK";
+ compatible = "atmel,sama5d36ek", "atmel,sama5d3xmb", "atmel,sama5d3xcm", "atmel,sama5d36", "atmel,sama5d3", "atmel,sama5";
+
+ ahb {
+ apb {
+ spi0: spi at f0004000 {
+ status = "okay";
+ };
+
+ ssc0: ssc at f0008000 {
+ status = "okay";
+ };
+
+ can0: can at f000c000 {
+ status = "okay";
+ };
+
+ i2c0: i2c at f0014000 {
+ status = "okay";
+ };
+
+ i2c1: i2c at f0018000 {
+ status = "okay";
+ };
+
+ macb0: ethernet at f0028000 {
+ status = "okay";
+ };
+
+ macb1: ethernet at f802c000 {
+ status = "okay";
+ };
+ };
+ };
+
+ sound {
+ status = "okay";
+ };
+};
diff --git a/arch/arm/boot/dts/sama5d3xcm_cmp.dtsi b/arch/arm/boot/dts/sama5d3xcm_cmp.dtsi
new file mode 100644
index 0000000..77638c3
--- /dev/null
+++ b/arch/arm/boot/dts/sama5d3xcm_cmp.dtsi
@@ -0,0 +1,166 @@
+/*
+ * sama5d3xcm_cmp.dtsi - Device Tree Include file for SAMA5D36 CMP CPU Module
+ *
+ * Copyright (C) 2016 Atmel,
+ *
+ * Licensed under GPLv2 or later.
+ */
+
+/ {
+ compatible = "atmel,sama5d3xcm", "atmel,sama5d3", "atmel,sama5";
+
+ chosen {
+ bootargs = "rootfstype=ubifs ubi.mtd=5 root=ubi0:rootfs";
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory {
+ reg = <0x20000000 0x20000000>;
+ };
+
+ clocks {
+ slow_xtal {
+ clock-frequency = <32768>;
+ };
+
+ main_xtal {
+ clock-frequency = <12000000>;
+ };
+ };
+
+ ahb {
+ apb {
+ spi0: spi at f0004000 {
+ cs-gpios = <&pioD 13 0>, <0>, <0>, <0>;
+ };
+
+ macb0: ethernet at f0028000 {
+ phy-mode = "rgmii";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet-phy at 1 {
+ reg = <0x1>;
+ interrupt-parent = <&pioB>;
+ interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
+ txen-skew-ps = <800>;
+ txc-skew-ps = <3000>;
+ rxdv-skew-ps = <400>;
+ rxc-skew-ps = <3000>;
+ rxd0-skew-ps = <400>;
+ rxd1-skew-ps = <400>;
+ rxd2-skew-ps = <400>;
+ rxd3-skew-ps = <400>;
+ };
+
+ ethernet-phy at 7 {
+ reg = <0x7>;
+ interrupt-parent = <&pioB>;
+ interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
+ txen-skew-ps = <800>;
+ txc-skew-ps = <3000>;
+ rxdv-skew-ps = <400>;
+ rxc-skew-ps = <3000>;
+ rxd0-skew-ps = <400>;
+ rxd1-skew-ps = <400>;
+ rxd2-skew-ps = <400>;
+ rxd3-skew-ps = <400>;
+ };
+ };
+
+ i2c1: i2c at f0018000 {
+ pmic: act8865 at 5b {
+ compatible = "active-semi,act8865";
+ reg = <0x5b>;
+ status = "disabled";
+
+ regulators {
+ vcc_1v8_reg: DCDC_REG1 {
+ regulator-name = "VCC_1V8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ };
+
+ vcc_1v2_reg: DCDC_REG2 {
+ regulator-name = "VCC_1V2";
+ regulator-min-microvolt = <1100000>;
+ regulator-max-microvolt = <1300000>;
+ regulator-always-on;
+ };
+
+ vcc_3v3_reg: DCDC_REG3 {
+ regulator-name = "VCC_3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ vddana_reg: LDO_REG1 {
+ regulator-name = "VDDANA";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ vddfuse_reg: LDO_REG2 {
+ regulator-name = "FUSE_2V5";
+ regulator-min-microvolt = <2500000>;
+ regulator-max-microvolt = <2500000>;
+ };
+ };
+ };
+ };
+ };
+
+ nand0: nand at 60000000 {
+ nand-bus-width = <8>;
+ nand-ecc-mode = "hw";
+ atmel,has-pmecc;
+ atmel,pmecc-cap = <4>;
+ atmel,pmecc-sector-size = <512>;
+ nand-on-flash-bbt;
+ status = "okay";
+
+ at91bootstrap at 0 {
+ label = "at91bootstrap";
+ reg = <0x0 0x40000>;
+ };
+
+ bootloader at 40000 {
+ label = "bootloader";
+ reg = <0x40000 0x80000>;
+ };
+
+ bootloaderenv at c0000 {
+ label = "bootloader env";
+ reg = <0xc0000 0xc0000>;
+ };
+
+ dtb at 180000 {
+ label = "device tree";
+ reg = <0x180000 0x80000>;
+ };
+
+ kernel at 200000 {
+ label = "kernel";
+ reg = <0x200000 0x600000>;
+ };
+
+ rootfs at 800000 {
+ label = "rootfs";
+ reg = <0x800000 0x0f800000>;
+ };
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ d2 {
+ label = "d2";
+ gpios = <&pioE 25 GPIO_ACTIVE_LOW>; /* PE25, conflicts with A25, RXD2 */
+ linux,default-trigger = "heartbeat";
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/sama5d3xmb_cmp.dtsi b/arch/arm/boot/dts/sama5d3xmb_cmp.dtsi
new file mode 100644
index 0000000..3ec78867
--- /dev/null
+++ b/arch/arm/boot/dts/sama5d3xmb_cmp.dtsi
@@ -0,0 +1,230 @@
+/*
+ * sama5d3xmb_cmp.dts - Device Tree file for SAMA5D3x CMP mother board
+ *
+ * Copyright (C) 2016 Atmel,
+ *
+ * Licensed under GPLv2 or later.
+ */
+#include "sama5d3xcm_cmp.dtsi"
+
+/ {
+ compatible = "atmel,sama5d3xmb", "atmel,sama5d3xcm", "atmel,sama5d3", "atmel,sama5";
+
+ ahb {
+ apb {
+ mmc0: mmc at f0000000 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_mmc0_clk_cmd_dat0 &pinctrl_mmc0_dat1_3 &pinctrl_mmc0_cd>;
+ status = "okay";
+ slot at 0 {
+ reg = <0>;
+ bus-width = <4>;
+ cd-gpios = <&pioD 17 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ spi0: spi at f0004000 {
+ dmas = <0>, <0>; /* Do not use DMA for spi0 */
+
+ m25p80 at 0 {
+ compatible = "atmel,at25df321a";
+ spi-max-frequency = <50000000>;
+ reg = <0>;
+ };
+ };
+
+ ssc0: ssc at f0008000 {
+ atmel,clk-from-rk-pin;
+ };
+
+ /*
+ * i2c0 conflicts with ISI:
+ * disable it to allow the use of ISI
+ * can not enable audio when i2c0 disabled
+ */
+ i2c0: i2c at f0014000 {
+ wm8904: wm8904 at 1a {
+ compatible = "wlf,wm8904";
+ reg = <0x1a>;
+ clocks = <&pck0>;
+ clock-names = "mclk";
+ };
+ };
+
+ i2c1: i2c at f0018000 {
+ ov2640: camera at 0x30 {
+ compatible = "ovti,ov2640";
+ reg = <0x30>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pck1_as_isi_mck &pinctrl_sensor_power &pinctrl_sensor_reset>;
+ resetb-gpios = <&pioE 24 GPIO_ACTIVE_LOW>;
+ pwdn-gpios = <&pioE 29 GPIO_ACTIVE_HIGH>;
+ /* use pck1 for the master clock of ov2640 */
+ clocks = <&pck1>;
+ clock-names = "xvclk";
+ assigned-clocks = <&pck1>;
+ assigned-clock-rates = <25000000>;
+
+ port {
+ ov2640_0: endpoint {
+ remote-endpoint = <&isi_0>;
+ bus-width = <8>;
+ };
+ };
+ };
+ };
+
+ usart1: serial at f0020000 {
+ dmas = <0>, <0>; /* Do not use DMA for usart1 */
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usart1 &pinctrl_usart1_rts_cts>;
+ status = "okay";
+ };
+
+ isi: isi at f0034000 {
+ port {
+ isi_0: endpoint {
+ remote-endpoint = <&ov2640_0>;
+ bus-width = <8>;
+ vsync-active = <1>;
+ hsync-active = <1>;
+ };
+ };
+ };
+
+ mmc1: mmc at f8000000 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_mmc1_clk_cmd_dat0 &pinctrl_mmc1_dat1_3 &pinctrl_mmc1_cd>;
+ status = "okay";
+ slot at 0 {
+ reg = <0>;
+ bus-width = <4>;
+ cd-gpios = <&pioD 18 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ adc0: adc at f8018000 {
+ pinctrl-names = "default";
+ pinctrl-0 = <
+ &pinctrl_adc0_adtrg
+ &pinctrl_adc0_ad0
+ &pinctrl_adc0_ad1
+ &pinctrl_adc0_ad2
+ &pinctrl_adc0_ad3
+ &pinctrl_adc0_ad4
+ >;
+ status = "okay";
+ };
+
+ macb1: ethernet at f802c000 {
+ phy-mode = "rmii";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+ phy0: ethernet-phy at 1 {
+ /*interrupt-parent = <&pioE>;*/
+ /*interrupts = <30 IRQ_TYPE_EDGE_FALLING>;*/
+ reg = <1>;
+ };
+ };
+
+ pinctrl at fffff200 {
+ board {
+ pinctrl_gpio_keys: gpio_keys {
+ atmel,pins =
+ <AT91_PIOE 27 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP>;
+ };
+
+ pinctrl_mmc0_cd: mmc0_cd {
+ atmel,pins =
+ <AT91_PIOD 17 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP_DEGLITCH>; /* PD17 GPIO with pullup deglitch */
+ };
+
+ pinctrl_mmc1_cd: mmc1_cd {
+ atmel,pins =
+ <AT91_PIOD 18 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP_DEGLITCH>; /* PD18 GPIO with pullup deglitch */
+ };
+
+ pinctrl_pck0_as_audio_mck: pck0_as_audio_mck {
+ atmel,pins =
+ <AT91_PIOD 30 AT91_PERIPH_B AT91_PINCTRL_NONE>; /* PD30 periph B */
+ };
+
+ pinctrl_pck1_as_isi_mck: pck1_as_isi_mck-0 {
+ atmel,pins =
+ <AT91_PIOD 31 AT91_PERIPH_B AT91_PINCTRL_NONE>; /* PD31 periph B ISI_MCK */
+ };
+
+ pinctrl_sensor_reset: sensor_reset-0 {
+ atmel,pins =
+ <AT91_PIOE 24 AT91_PERIPH_GPIO AT91_PINCTRL_NONE>; /* PE24 gpio */
+ };
+
+ pinctrl_sensor_power: sensor_power-0 {
+ atmel,pins =
+ <AT91_PIOE 29 AT91_PERIPH_GPIO AT91_PINCTRL_NONE>; /* PE29 gpio */
+ };
+
+ pinctrl_usba_vbus: usba_vbus {
+ atmel,pins =
+ <AT91_PIOD 29 AT91_PERIPH_GPIO AT91_PINCTRL_DEGLITCH>; /* PD29 GPIO with deglitch */
+ };
+ };
+ };
+
+ dbgu: serial at ffffee00 {
+ dmas = <0>, <0>; /* Do not use DMA for dbgu */
+ status = "okay";
+ };
+
+ watchdog at fffffe40 {
+ status = "okay";
+ };
+ };
+
+ usb0: gadget at 00500000 {
+ atmel,vbus-gpio = <&pioD 29 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usba_vbus>;
+ status = "okay";
+ };
+ };
+
+ sound {
+ compatible = "atmel,asoc-wm8904";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pck0_as_audio_mck>;
+
+ atmel,model = "wm8904 @ SAMA5D3EK";
+ atmel,audio-routing =
+ "Headphone Jack", "HPOUTL",
+ "Headphone Jack", "HPOUTR",
+ "IN2L", "Line In Jack",
+ "IN2R", "Line In Jack",
+ "Mic", "MICBIAS",
+ "IN1L", "Mic";
+
+ atmel,ssc-controller = <&ssc0>;
+ atmel,audio-codec = <&wm8904>;
+
+ status = "disabled";
+ };
+
+ /* Conflict with LCD pins */
+ gpio_keys {
+ compatible = "gpio-keys";
+ status = "okay";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio_keys>;
+
+ pb_user1 {
+ label = "pb_user1";
+ gpios = <&pioE 27 GPIO_ACTIVE_HIGH>;
+ linux,code = <0x100>;
+ gpio-key,wakeup;
+ };
+ };
+};
--
2.7.4
^ permalink raw reply related
* [PATCH] drivers: mfd: ti_am335x_tscadc: increase ADC ref clock to 24MHz
From: John Syne @ 2016-10-25 6:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <086ab2fa-63ee-c5ab-2715-b2efd78270d7@ti.com>
> On Oct 24, 2016, at 10:52 PM, Mugunthan V N <mugunthanvnm@ti.com> wrote:
>
> On Tuesday 25 October 2016 02:28 AM, John Syne wrote:
>>>> On Oct 23, 2016, at 11:02 PM, Mugunthan V N <mugunthanvnm@ti.com> wrote:
>>>>
>>>> Increase ADC reference clock from 3MHz to 24MHz so that the
>>>> sampling rates goes up from 100K samples per second to 800K
>>>> samples per second on AM335x and AM437x SoC.
>>>>
>>>> Also increase opendelay for touchscreen configuration to
>>>> equalize the increase in ADC reference clock frequency,
>>>> which results in the same amount touch events reported via
>>>> evtest on AM335x GP EVM.
>>>>
>>>> Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
>>>> ---
>>>>
>>>> This patch depends on ADC DMA patch series [1]
>>>>
>>>> Without DMA support, when ADC ref clock is set at 24MHz, I am
>>>> seeing fifo overflow as CPU is not able to pull the ADC samples.
>>>> This answers that DMA support is must for ADC to consume the
>>>> samples generated at 24MHz with no open, step delay or
>>>> averaging with patch [2].
>>>>
>>>> Measured the performance with the iio_generic_buffer with the
>>>> patch [3] applied
>>>>
>>>> [1] - http://www.spinics.net/lists/devicetree/msg145045.html
>>>> [2] - http://pastebin.ubuntu.com/23357935/
>>>> [3] - http://pastebin.ubuntu.com/23357939/
>>>>
>>>> ---
>>>> include/linux/mfd/ti_am335x_tscadc.h | 4 ++--
>>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/include/linux/mfd/ti_am335x_tscadc.h b/include/linux/mfd/ti_am335x_tscadc.h
>>>> index b9a53e0..96c4207 100644
>>>> --- a/include/linux/mfd/ti_am335x_tscadc.h
>>>> +++ b/include/linux/mfd/ti_am335x_tscadc.h
>>>> @@ -90,7 +90,7 @@
>>>> /* Delay register */
>>>> #define STEPDELAY_OPEN_MASK (0x3FFFF << 0)
>>>> #define STEPDELAY_OPEN(val) ((val) << 0)
>>>> -#define STEPCONFIG_OPENDLY STEPDELAY_OPEN(0x098)
>> Wouldn?t this be better to add this to the devicetree?
>>
>> ti,chan-step-avg = <0x16 0x16 0x16 0x16 0x16 0x16 0x16>;
>> ti,chan-step-opendelay = <0x500 0x500 0x500 0x500 0x500 0x500 0x500>;
>> ti,chan-step-sampledelay = <0x0 0x0 0x0 0x0 0x0 0x0 0x0>;
>
> For a touch screen, there is not need to change in these parameter
> settings, so my opinion is to keep it as is. Or am I missing something?
I was thinking that if you are using this driver as an ADC, you may want the flexibility to make these changes in the DT. I?m doing this by connecting sensors to the ADC inputs. I?m not using this driver for a touchscreen.
Regards,
John
>
> Regards
> Mugunthan V N
^ permalink raw reply
* [PATCH] drivers: mfd: ti_am335x_tscadc: increase ADC ref clock to 24MHz
From: Mugunthan V N @ 2016-10-25 5:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <038C6B01-8443-4321-9C65-BAC4095237D3@gmail.com>
On Tuesday 25 October 2016 02:28 AM, John Syne wrote:
>> > On Oct 23, 2016, at 11:02 PM, Mugunthan V N <mugunthanvnm@ti.com> wrote:
>> >
>> > Increase ADC reference clock from 3MHz to 24MHz so that the
>> > sampling rates goes up from 100K samples per second to 800K
>> > samples per second on AM335x and AM437x SoC.
>> >
>> > Also increase opendelay for touchscreen configuration to
>> > equalize the increase in ADC reference clock frequency,
>> > which results in the same amount touch events reported via
>> > evtest on AM335x GP EVM.
>> >
>> > Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
>> > ---
>> >
>> > This patch depends on ADC DMA patch series [1]
>> >
>> > Without DMA support, when ADC ref clock is set at 24MHz, I am
>> > seeing fifo overflow as CPU is not able to pull the ADC samples.
>> > This answers that DMA support is must for ADC to consume the
>> > samples generated at 24MHz with no open, step delay or
>> > averaging with patch [2].
>> >
>> > Measured the performance with the iio_generic_buffer with the
>> > patch [3] applied
>> >
>> > [1] - http://www.spinics.net/lists/devicetree/msg145045.html
>> > [2] - http://pastebin.ubuntu.com/23357935/
>> > [3] - http://pastebin.ubuntu.com/23357939/
>> >
>> > ---
>> > include/linux/mfd/ti_am335x_tscadc.h | 4 ++--
>> > 1 file changed, 2 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/include/linux/mfd/ti_am335x_tscadc.h b/include/linux/mfd/ti_am335x_tscadc.h
>> > index b9a53e0..96c4207 100644
>> > --- a/include/linux/mfd/ti_am335x_tscadc.h
>> > +++ b/include/linux/mfd/ti_am335x_tscadc.h
>> > @@ -90,7 +90,7 @@
>> > /* Delay register */
>> > #define STEPDELAY_OPEN_MASK (0x3FFFF << 0)
>> > #define STEPDELAY_OPEN(val) ((val) << 0)
>> > -#define STEPCONFIG_OPENDLY STEPDELAY_OPEN(0x098)
> Wouldn?t this be better to add this to the devicetree?
>
> ti,chan-step-avg = <0x16 0x16 0x16 0x16 0x16 0x16 0x16>;
> ti,chan-step-opendelay = <0x500 0x500 0x500 0x500 0x500 0x500 0x500>;
> ti,chan-step-sampledelay = <0x0 0x0 0x0 0x0 0x0 0x0 0x0>;
For a touch screen, there is not need to change in these parameter
settings, so my opinion is to keep it as is. Or am I missing something?
Regards
Mugunthan V N
^ permalink raw reply
* [PATCH v2] drm/mediatek: fixed the calc method of data rate per lane
From: Jitao Shi @ 2016-10-25 5:40 UTC (permalink / raw)
To: linux-arm-kernel
Tune dsi frame rate by pixel clock, dsi add some extra signal (i.e. Tlpx,
Ths-prepare, Ths-zero, Ths-trail,Ths-exit) when enter and exit LP mode, this
signal will cause h-time larger than normal and reduce FPS.
Need to multiply a coefficient to offset the extra signal's effect.
coefficient = ((htotal*bpp/lane_number)+Tlpx+Ths_prep+Ths_zero+Ths_trail+
Ths_exit)/(htotal*bpp/lane_number))
Signed-off-by: Jitao Shi <jitao.shi@mediatek.com>
---
Change since v1:
- phy_timing2 and phy_timing3 refer clock cycle time.
- define values of LPX HS_PRPR HS_ZERO HS_TRAIL TA_GO TA_SURE TA_GET DA_HS_EXIT
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 103 +++++++++++++++++++++++-------------
1 file changed, 67 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 28b2044..ade6f46 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -85,16 +85,16 @@
#define LD0_WAKEUP_EN BIT(2)
#define DSI_PHY_TIMECON0 0x110
-#define LPX (0xff << 0)
-#define HS_PRPR (0xff << 8)
-#define HS_ZERO (0xff << 16)
-#define HS_TRAIL (0xff << 24)
+#define LPX (5 << 0)
+#define HS_PRPR (6 << 8)
+#define HS_ZERO (10 << 16)
+#define HS_TRAIL (8 << 24)
#define DSI_PHY_TIMECON1 0x114
-#define TA_GO (0xff << 0)
-#define TA_SURE (0xff << 8)
-#define TA_GET (0xff << 16)
-#define DA_HS_EXIT (0xff << 24)
+#define TA_GO (20 << 0)
+#define TA_SURE (7 << 8)
+#define TA_GET (25 << 16)
+#define DA_HS_EXIT (7 << 24)
#define DSI_PHY_TIMECON2 0x118
#define CONT_DET (0xff << 0)
@@ -158,28 +158,14 @@ static void mtk_dsi_mask(struct mtk_dsi *dsi, u32 offset, u32 mask, u32 data)
writel((temp & ~mask) | (data & mask), dsi->regs + offset);
}
-static void dsi_phy_timconfig(struct mtk_dsi *dsi)
+static void dsi_phy_timconfig(struct mtk_dsi *dsi, u32 phy_timing0,
+ u32 phy_timing1, u32 phy_timing2,
+ u32 phy_timing3)
{
- u32 timcon0, timcon1, timcon2, timcon3;
- unsigned int ui, cycle_time;
- unsigned int lpx;
-
- ui = 1000 / dsi->data_rate + 0x01;
- cycle_time = 8000 / dsi->data_rate + 0x01;
- lpx = 5;
-
- timcon0 = (8 << 24) | (0xa << 16) | (0x6 << 8) | lpx;
- timcon1 = (7 << 24) | (5 * lpx << 16) | ((3 * lpx) / 2) << 8 |
- (4 * lpx);
- timcon2 = ((NS_TO_CYCLE(0x64, cycle_time) + 0xa) << 24) |
- (NS_TO_CYCLE(0x150, cycle_time) << 16);
- timcon3 = (2 * lpx) << 16 | NS_TO_CYCLE(80 + 52 * ui, cycle_time) << 8 |
- NS_TO_CYCLE(0x40, cycle_time);
-
- writel(timcon0, dsi->regs + DSI_PHY_TIMECON0);
- writel(timcon1, dsi->regs + DSI_PHY_TIMECON1);
- writel(timcon2, dsi->regs + DSI_PHY_TIMECON2);
- writel(timcon3, dsi->regs + DSI_PHY_TIMECON3);
+ writel(phy_timing0, dsi->regs + DSI_PHY_TIMECON0);
+ writel(phy_timing1, dsi->regs + DSI_PHY_TIMECON1);
+ writel(phy_timing2, dsi->regs + DSI_PHY_TIMECON2);
+ writel(phy_timing3, dsi->regs + DSI_PHY_TIMECON3);
}
static void mtk_dsi_enable(struct mtk_dsi *dsi)
@@ -202,19 +188,51 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
{
struct device *dev = dsi->dev;
int ret;
+ u64 bit_clock, total_bits;
+ u32 htotal, htotal_bits, bit_per_pixel, overhead_cycles, overhead_bits;
+ u32 phy_timing0, phy_timing1, phy_timing2, phy_timing3;
+ u32 ui, cycle_time;
if (++dsi->refcount != 1)
return 0;
+ switch (dsi->format) {
+ case MIPI_DSI_FMT_RGB565:
+ bit_per_pixel = 16;
+ break;
+ case MIPI_DSI_FMT_RGB666_PACKED:
+ bit_per_pixel = 18;
+ break;
+ case MIPI_DSI_FMT_RGB666:
+ case MIPI_DSI_FMT_RGB888:
+ default:
+ bit_per_pixel = 24;
+ break;
+ }
+ /**
+ * data_rate = (pixel_clock) * bit_per_pixel * mipi_ratio / lane_num;
+ * vm.pixelclock is Khz, data_rata unit is Hz, so need to multiply 1000
+ * mipi_ratio is (htotal * byte_per_pixel / lane_num + Tlpx + Ths_prep
+ * + Thstrail + Ths_exit + Ths_zero) /
+ * (htotal * byte_per_pixel /lane_number)
+ */
+ bit_clock = dsi->vm.pixelclock * 1000 * bit_per_pixel;
+ htotal = dsi->vm.hactive + dsi->vm.hback_porch + dsi->vm.hfront_porch +
+ dsi->vm.hsync_len;
+ htotal_bits = htotal * bit_per_pixel;
+
/**
- * data_rate = (pixel_clock / 1000) * pixel_dipth * mipi_ratio;
- * pixel_clock unit is Khz, data_rata unit is MHz, so need divide 1000.
- * mipi_ratio is mipi clk coefficient for balance the pixel clk in mipi.
- * we set mipi_ratio is 1.05.
+ * overhead = lpx + hs_prepare + hs_zero + hs_trail + hs_exit
*/
- dsi->data_rate = dsi->vm.pixelclock * 3 * 21 / (1 * 1000 * 10);
+ overhead_cycles = LPX + (HS_PRPR >> 8) + (HS_ZERO >> 16) +
+ (HS_TRAIL >> 24) + (DA_HS_EXIT >> 24);
+ overhead_bits = overhead_cycles * dsi->lanes * 8;
+ total_bits = htotal_bits + overhead_bits;
- ret = clk_set_rate(dsi->hs_clk, dsi->data_rate * 1000000);
+ dsi->data_rate = DIV_ROUND_UP_ULL(bit_clock * total_bits,
+ htotal_bits * dsi->lanes);
+
+ ret = clk_set_rate(dsi->hs_clk, dsi->data_rate);
if (ret < 0) {
dev_err(dev, "Failed to set data rate: %d\n", ret);
goto err_refcount;
@@ -236,7 +254,20 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
mtk_dsi_enable(dsi);
mtk_dsi_reset(dsi);
- dsi_phy_timconfig(dsi);
+
+ ui = 1000 / dsi->data_rate + 0x01;
+ cycle_time = 8000 / dsi->data_rate + 0x01;
+
+ phy_timing0 = LPX | HS_PRPR | HS_ZERO | HS_TRAIL;
+ phy_timing1 = TA_GO | TA_SURE | TA_GET | DA_HS_EXIT;
+ phy_timing2 = ((NS_TO_CYCLE(0x64, cycle_time) + 0xa) << 24) |
+ (NS_TO_CYCLE(0x150, cycle_time) << 16);
+ phy_timing3 = (2 * LPX) << 16 |
+ NS_TO_CYCLE(80 + 52 * ui, cycle_time) << 8 |
+ NS_TO_CYCLE(0x40, cycle_time);
+
+ dsi_phy_timconfig(dsi, phy_timing0, phy_timing1, phy_timing2,
+ phy_timing3);
return 0;
--
1.7.9.5
^ permalink raw reply related
* [PATCH] nvmem: sunxi-sid: SID content is not a valid source of randomness
From: LABBE Corentin @ 2016-10-25 5:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161024201020.h6akyqad2o42xkhq@lukather>
On Mon, Oct 24, 2016 at 10:10:20PM +0200, Maxime Ripard wrote:
> On Sat, Oct 22, 2016 at 03:53:28PM +0200, Corentin Labbe wrote:
> > Since SID's content is constant over reboot,
>
> That's not true, at least not across all the Allwinner SoCs, and
> especially not on the A10 and A20 that this driver supports.
>
On my cubieboard2 (A20)
hexdump -C /sys/devices/platform/soc\@01c00000/1c23800.eeprom/sunxi-sid0/nvmem
00000000 16 51 66 83 80 48 50 72 56 54 48 48 03 c2 75 72 |.Qf..HPrVTHH..ur|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000100 16 51 66 83 80 48 50 72 56 54 48 48 03 c2 75 72 |.Qf..HPrVTHH..ur|
00000110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000200
cubiedev ~ # reboot
cubiedev ~ # hexdump -C /sys/devices/platform/soc\@01c00000/1c23800.eeprom/sunxi-sid0/nvmem
00000000 16 51 66 83 80 48 50 72 56 54 48 48 03 c2 75 72 |.Qf..HPrVTHH..ur|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000100 16 51 66 83 80 48 50 72 56 54 48 48 03 c2 75 72 |.Qf..HPrVTHH..ur|
00000110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000200
So clearly for me its constant.
> > it must not be used as source of randomness.
>
> And I don't think that's true either. A constant entropy provider will
> not add any entropy, but will not remove any, would it?
I cced linux-crypto at the begining for confirmation on that.
But the problem is increased as a part of the content is predicatable over same type of device (at least the thirst bytes and all the zeros).
^ permalink raw reply
* [PATCH RESEND 2/2] phy-sun4i-usb: add support for host mode of phy0 on A64 SoC
From: Icenowy Zheng @ 2016-10-25 4:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161025041139.46454-1-icenowy@aosc.xyz>
The OTG phy of A64 can be put into the host mode with an OHCI/EHCI pair,
just like the H3 SoC.
Some A64 boards (such as Pine64 series) use the USB OTG port as a generic
USB-A port, and thus can be fully support by the driver now.
The register's name is changed to PHY_OTG_CFG, as it's described in the
A64 downstream BSP kernel source, at drivers/usb/host/sunxi_hci.h .
Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
---
drivers/phy/phy-sun4i-usb.c | 46 +++++++++++++++++++++++++++++++++------------
1 file changed, 34 insertions(+), 12 deletions(-)
diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
index a4db658..9287247 100644
--- a/drivers/phy/phy-sun4i-usb.c
+++ b/drivers/phy/phy-sun4i-usb.c
@@ -47,7 +47,7 @@
#define REG_PHYBIST 0x08
#define REG_PHYTUNE 0x0c
#define REG_PHYCTL_A33 0x10
-#define REG_PHY_UNK_H3 0x20
+#define REG_PHY_OTG_CFG 0x20
#define REG_PMU_UNK1 0x10
@@ -107,6 +107,7 @@ struct sun4i_usb_phy_cfg {
u8 phyctl_offset;
bool dedicated_clocks;
bool enable_pmu_unk1;
+ bool route_otg;
};
struct sun4i_usb_phy_data {
@@ -135,6 +136,7 @@ struct sun4i_usb_phy_data {
int id_det;
int vbus_det;
struct delayed_work detect;
+ bool otg_routed;
};
#define to_sun4i_usb_phy_data(phy) \
@@ -263,10 +265,11 @@ static int sun4i_usb_phy_init(struct phy *_phy)
writel(val & ~2, phy->pmu + REG_PMU_UNK1);
}
- if (data->cfg->type == sun8i_h3_phy) {
- if (phy->index == 0) {
- val = readl(data->base + REG_PHY_UNK_H3);
- writel(val & ~1, data->base + REG_PHY_UNK_H3);
+ if (data->cfg->route_otg) {
+ if (phy->index == 0 && data->otg_routed) {
+ /* Route the OTG PHY to HCI */
+ val = readl(data->base + REG_PHY_OTG_CFG);
+ writel(val & ~1, data->base + REG_PHY_OTG_CFG);
}
} else {
/* Enable USB 45 Ohm resistor calibration */
@@ -283,7 +286,7 @@ static int sun4i_usb_phy_init(struct phy *_phy)
sun4i_usb_phy_passby(phy, 1);
- if (phy->index == 0) {
+ if (phy->index == 0 && !data->otg_routed) {
data->phy0_init = true;
/* Enable pull-ups */
@@ -310,7 +313,7 @@ static int sun4i_usb_phy_exit(struct phy *_phy)
struct sun4i_usb_phy *phy = phy_get_drvdata(_phy);
struct sun4i_usb_phy_data *data = to_sun4i_usb_phy_data(phy);
- if (phy->index == 0) {
+ if (phy->index == 0 && !data->otg_routed) {
/* Disable pull-ups */
sun4i_usb_phy0_update_iscr(_phy, ISCR_DPDM_PULLUP_EN, 0);
sun4i_usb_phy0_update_iscr(_phy, ISCR_ID_PULLUP_EN, 0);
@@ -377,7 +380,7 @@ static int sun4i_usb_phy_power_on(struct phy *_phy)
/* For phy0 only turn on Vbus if we don't have an ext. Vbus */
if (phy->index == 0 && sun4i_usb_phy0_have_vbus_det(data) &&
- data->vbus_det)
+ data->vbus_det && !data->otg_routed)
return 0;
ret = regulator_enable(phy->vbus);
@@ -387,7 +390,7 @@ static int sun4i_usb_phy_power_on(struct phy *_phy)
phy->regulator_on = true;
/* We must report Vbus high within OTG_TIME_A_WAIT_VRISE msec. */
- if (phy->index == 0 && sun4i_usb_phy0_poll(data))
+ if (phy->index == 0 && sun4i_usb_phy0_poll(data) && !data->otg_routed)
mod_delayed_work(system_wq, &data->detect, DEBOUNCE_TIME);
return 0;
@@ -408,7 +411,7 @@ static int sun4i_usb_phy_power_off(struct phy *_phy)
* phy0 vbus typically slowly discharges, sometimes this causes the
* Vbus gpio to not trigger an edge irq on Vbus off, so force a rescan.
*/
- if (phy->index == 0 && !sun4i_usb_phy0_poll(data))
+ if (phy->index == 0 && !sun4i_usb_phy0_poll(data) && !data->otg_routed)
mod_delayed_work(system_wq, &data->detect, POLL_TIME);
return 0;
@@ -567,7 +570,17 @@ static int sun4i_usb_phy_probe(struct platform_device *pdev)
return -ENOMEM;
mutex_init(&data->mutex);
- INIT_DELAYED_WORK(&data->detect, sun4i_usb_phy0_id_vbus_det_scan);
+ if (device_property_read_bool(dev, "allwinner,otg-routed")) {
+ /*
+ * PHY0 is routed to HCI rather than OTG Controller.
+ * In this situation, the port can only be used as a host port.
+ */
+ data->otg_routed = true;
+ } else {
+ /* ID/Vbus detection is only meaningful when it's really OTG */
+ INIT_DELAYED_WORK(&data->detect,
+ sun4i_usb_phy0_id_vbus_det_scan);
+ }
dev_set_drvdata(dev, data);
data->cfg = of_device_get_match_data(dev);
if (!data->cfg)
@@ -647,7 +660,8 @@ static int sun4i_usb_phy_probe(struct platform_device *pdev)
return PTR_ERR(phy->reset);
}
- if (i) { /* No pmu for usbc0 */
+ /* PMU is only valid on PHYs in HCI mode */
+ if (i || data->otg_routed) {
snprintf(name, sizeof(name), "pmu%d", i);
res = platform_get_resource_byname(pdev,
IORESOURCE_MEM, name);
@@ -719,6 +733,7 @@ static const struct sun4i_usb_phy_cfg sun4i_a10_cfg = {
.phyctl_offset = REG_PHYCTL_A10,
.dedicated_clocks = false,
.enable_pmu_unk1 = false,
+ .route_otg = false,
};
static const struct sun4i_usb_phy_cfg sun5i_a13_cfg = {
@@ -728,6 +743,7 @@ static const struct sun4i_usb_phy_cfg sun5i_a13_cfg = {
.phyctl_offset = REG_PHYCTL_A10,
.dedicated_clocks = false,
.enable_pmu_unk1 = false,
+ .route_otg = false,
};
static const struct sun4i_usb_phy_cfg sun6i_a31_cfg = {
@@ -737,6 +753,7 @@ static const struct sun4i_usb_phy_cfg sun6i_a31_cfg = {
.phyctl_offset = REG_PHYCTL_A10,
.dedicated_clocks = true,
.enable_pmu_unk1 = false,
+ .route_otg = false,
};
static const struct sun4i_usb_phy_cfg sun7i_a20_cfg = {
@@ -746,6 +763,7 @@ static const struct sun4i_usb_phy_cfg sun7i_a20_cfg = {
.phyctl_offset = REG_PHYCTL_A10,
.dedicated_clocks = false,
.enable_pmu_unk1 = false,
+ .route_otg = false,
};
static const struct sun4i_usb_phy_cfg sun8i_a23_cfg = {
@@ -755,6 +773,7 @@ static const struct sun4i_usb_phy_cfg sun8i_a23_cfg = {
.phyctl_offset = REG_PHYCTL_A10,
.dedicated_clocks = true,
.enable_pmu_unk1 = false,
+ .route_otg = false,
};
static const struct sun4i_usb_phy_cfg sun8i_a33_cfg = {
@@ -764,6 +783,7 @@ static const struct sun4i_usb_phy_cfg sun8i_a33_cfg = {
.phyctl_offset = REG_PHYCTL_A33,
.dedicated_clocks = true,
.enable_pmu_unk1 = false,
+ .route_otg = false,
};
static const struct sun4i_usb_phy_cfg sun8i_h3_cfg = {
@@ -772,6 +792,7 @@ static const struct sun4i_usb_phy_cfg sun8i_h3_cfg = {
.disc_thresh = 3,
.dedicated_clocks = true,
.enable_pmu_unk1 = true,
+ .route_otg = true,
};
static const struct sun4i_usb_phy_cfg sun50i_a64_cfg = {
@@ -781,6 +802,7 @@ static const struct sun4i_usb_phy_cfg sun50i_a64_cfg = {
.phyctl_offset = REG_PHYCTL_A33,
.dedicated_clocks = true,
.enable_pmu_unk1 = true,
+ .route_otg = true,
};
static const struct of_device_id sun4i_usb_phy_of_match[] = {
--
2.10.1
^ permalink raw reply related
* [PATCH RESEND 1/2] dt: bindings: add allwinner, otg-routed property for phy-sun4i-usb
From: Icenowy Zheng @ 2016-10-25 4:11 UTC (permalink / raw)
To: linux-arm-kernel
On some newer Allwinner SoCs (H3 or A64), the PHY0 can be either routed to
the MUSB controller (which is an OTG controller) or the OHCI/EHCI pair
(which is a Host-only controller, but more stable and easy to implement).
This property marks whether on a certain board which controller should be
attached to the PHY.
Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
---
Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
index 287150d..a63c766 100644
--- a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
+++ b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
@@ -36,6 +36,12 @@ Optional properties:
- usb1_vbus-supply : regulator phandle for controller usb1 vbus
- usb2_vbus-supply : regulator phandle for controller usb2 vbus
+Optional properties for H3 or A64 SoCs:
+- allwinner,otg-routed : USB0 (OTG) PHY is routed to OHCI/EHCI pair rather than
+ MUSB. (boolean, if this property is set, the OHCI/EHCI
+ controllers at PHY0 should be enabled and the MUSB
+ controller must *NOT* be enabled)
+
Example:
usbphy: phy at 0x01c13400 {
#phy-cells = <1>;
--
2.10.1
^ permalink raw reply related
* [PATCH 5/8] ARM: gr8: Add missing pwm channel 1 pin
From: Chen-Yu Tsai @ 2016-10-25 4:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161020170739.lgt2ywm346vm47zd@lukather>
On Fri, Oct 21, 2016 at 1:07 AM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> On Thu, Oct 20, 2016 at 10:10:03PM +0800, Chen-Yu Tsai wrote:
>> On Thu, Oct 20, 2016 at 4:12 PM, Maxime Ripard
>> <maxime.ripard@free-electrons.com> wrote:
>> > The PWM controller has two different channels, but only the first pin was
>> > exposed in the DTSI. Add the other one.
>> >
>> > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
>>
>> Acked-by: Chen-Yu Tsai <wens@csie.org>
>>
>> > ---
>> > arch/arm/boot/dts/ntc-gr8.dtsi | 7 +++++++
>> > 1 file changed, 7 insertions(+), 0 deletions(-)
>> >
>> > diff --git a/arch/arm/boot/dts/ntc-gr8.dtsi b/arch/arm/boot/dts/ntc-gr8.dtsi
>> > index 74aff795e723..fad7381630f3 100644
>> > --- a/arch/arm/boot/dts/ntc-gr8.dtsi
>> > +++ b/arch/arm/boot/dts/ntc-gr8.dtsi
>> > @@ -854,6 +854,13 @@
>> > allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
>> > };
>> >
>> > + pwm1_pins_a: pwm1 at 0 {
>>
>> Nit: really don't need "_a" and "@0" here.
>
> Fixed and applied.
Oops, you forgot to fix the label in the chip-pro dts:
DTC arch/arm/boot/dts/ntc-gr8-chip-pro.dtb
ERROR (phandle_references): Reference to non-existent node or label
"pwm1_pins_a"
ERROR: Input tree has errors, aborting (use -f to force output)
scripts/Makefile.lib:313: recipe for target
'arch/arm/boot/dts/ntc-gr8-chip-pro.dtb' failed
ChenYu
^ permalink raw reply
* [PATCH] ARM64: dts: bcm2835: Fix bcm2837 compatible string
From: Eric Anholt @ 2016-10-25 3:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477321791-7896-1-git-send-email-afaerber@suse.de>
e<#secure method=pgpmime mode=sign>
Andreas F?rber <afaerber@suse.de> writes:
> bcm2837-rpi-3-b.dts, its only in-tree user, was overriding it as
> "brcm,bcm2837" already.
Pulled to bcm2835-dt-64-next. Thanks!
^ 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