* [PATCH v4 22/22] phy: Add support for Qualcomm's USB HS phy
From: Rob Herring @ 2016-09-19 21:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <147407072439.8245.12292695359399379462@sboyd-linaro>
On Fri, Sep 16, 2016 at 7:05 PM, Stephen Boyd <stephen.boyd@linaro.org> wrote:
> Quoting Rob Herring (2016-09-16 08:19:51)
>> On Wed, Sep 07, 2016 at 02:35:19PM -0700, Stephen Boyd wrote:
>> > The high-speed phy on qcom SoCs is controlled via the ULPI
>> > viewport.
>> >
[...]
>> > +- qcom,init-seq:
>> > + Usage: optional
>> > + Value type: <u8 array>
>> > + Definition: Should contain a sequence of ULPI register and address pairs to
>> > + program into the ULPI_EXT_VENDOR_SPECIFIC area. This is related
>> > + to Device Mode Eye Diagram test.
>>
>> We generally nak this type of property. For 1 register I don't care so
>> much. For 100, that would be another story.
>>
>> Is this value per unit, per board, per SoC? Can you limit it to certain
>> registers?
>
> I'm told that this can be per board, depending on how it's wired from
> the phy pins to the usb port. Typically it's the same though for the
> boards I have, mostly because those boards are similar designs with
> respect to how USB is wired. The set of registers is not that many, 4 or
> 5 at most. My understanding is these are tuning registers. Right now the
> register part in the binding is the full register offset, and not an
> offset from ULPI_EXT_VENDOR_SPECIFIC (0x80). I could change this to be
> an offset from that area if you like so that this can't be abused to
> write into standard ULPI registers (there really isn't any way to
> enforce this in software though).
Okay, that sounds fine to me.
Rob
^ permalink raw reply
* [PATCH] arm: dts: fix rk3066a based boards vdd_log voltage initialization
From: Boris Brezillon @ 2016-09-19 20:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAD=FV=U_BQez2eCqm7mX9kj0dcEsnBKiFWcLAhXXJD+yTZhACw@mail.gmail.com>
On Mon, 19 Sep 2016 11:12:12 -0700
Doug Anderson <dianders@chromium.org> wrote:
> Hi,
>
> On Mon, Sep 19, 2016 at 11:06 AM, Boris Brezillon
> <boris.brezillon@free-electrons.com> wrote:
> > On Mon, 19 Sep 2016 10:52:51 -0700
> > Doug Anderson <dianders@chromium.org> wrote:
> >
> >> Hi,
> >>
> >> On Mon, Sep 19, 2016 at 10:48 AM, Boris Brezillon
> >> <boris.brezillon@free-electrons.com> wrote:
> >> > The PWM chip has always claimed the pins and muxed them to the PWM IP.
> >> > So, this means it's broken from the beginning, and my patch is only
> >> > uncovering the problem (unless the pins stay configured as input until
> >> > the PWM is enabled, which I'm not sure is the case).
> >>
> >> Such a solution is achievable with the pinctrl APIs pretty easily.
> >> You might not be able to use the automatic "init" state but you can do
> >> something similar and switch to an "active" state once the PWM is
> >> actually turned on the first time.
> >
> > But is it really the case here (I don't see any code requesting a
> > specific pinmux depending on the PWM state)?
>
> It is not happening right now as far as I know. ...but that's a bug.
>
> > Anyway, we really need to handle this case, we should define the
> > typical voltage when the PWM is disabled. Same as what you suggested
> > with voltage-when-input, but with a different naming (since the concept
> > of pinmux is PWM hardware/driver specific).
> >
> > voltage-when-pwm-disabled = <...>;
>
> Voltage when disabled and voltage when input are two different states.
> A disabled PWM will typically either drive high or low (depending on
> where it was when you turned it off). Not all "disabled" states will
> mean that the pin is configured as an input.
Okay, after reading again your first answer, I think I understand why
you want to differentiate the when-disabled and when-input cases. You
want to use the "init" and "default" pinctrl states. The "init" state
(applied at probe time) would keep the PWM pin in gpio+input mode and
the "default" state (applied when the PWM device is enabled for the
first time) would mux the pin to the PWM device.
Your solution requires that the pwm-regulator device knows in which
state the pin attached to the PWM is, which IMO is breaking the
layering we have right now: a PWM-regulator is assigned a PWM device
which is assigned a pin and a pinmux config.
Another solution would be to expose an additional information in the
pwm_state: whether the PWM is in the INIT state (probed, but not yet
configured by its user) or DEFAULT state (probed and already
configured by its user). But again, by doing that we also expose
internal PWM details to its user, which I'm not sure will help keep
the PWM API simple.
Actually, I had something slightly different in mind. I thought about
having two new pinctrl states ("enabled" and "disabled"). The "enabled"
state (pin muxed to the PWM device) would be applied each time the PWM
is enabled, and "disabled" state (gpio+input mode) would be applied each
time the PWM is disabled.
This way we can guarantee that even when the PWM is disabled, the
PWM-driven regulator is configured to output a non-destructive voltage.
Hence my suggestion to name the property 'voltage-when-pwm-disabled'.
^ permalink raw reply
* [PATCH] cpufreq: ti: Use generic platdev driver
From: Dave Gerlach @ 2016-09-19 20:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4712275.44limO7TAi@vostro.rjw.lan>
On 09/16/2016 04:59 PM, Rafael J. Wysocki wrote:
> On Friday, September 16, 2016 04:29:04 PM Dave Gerlach wrote:
>> Hi,
>> On 09/15/2016 01:25 AM, Viresh Kumar wrote:
>>> On 14-09-16, 15:41, Dave Gerlach wrote:
>>>> Now that the cpufreq-dt-platdev is used to create the cpufreq-dt platform
>>>> device for all OMAP platforms and the platform code that did it
>>>> before has been removed, add ti,am33xx and ti,dra7xx to the machine list
>>>> in cpufreq-dt-platdev which had relied on the removed platform code to do
>>>> this previously.
>>>>
>>>> Fixes: 7694ca6e1d6f ("cpufreq: omap: Use generic platdev driver")
>>>> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
>>>
>>> Any stable trees you want this to be added to ?
>>
>> I suppose it'll go for 4.7-stable as the change happened in v4.6.
>
> The commit in the fixes tag went in during the 4.7 cycle, so the fix should
> go into 4.7.y, but I'm not going to push it as urgent material for 4.8.
>
Yes, that is fine, thanks a lot!
Regards,
Dave
> Thanks,
> Rafael
>
^ permalink raw reply
* [GIT PULL 3/3] ZTE arm64 defconfig changes for 4.9
From: Arnd Bergmann @ 2016-09-19 20:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474008641-30859-3-git-send-email-shawnguo@kernel.org>
On Friday, September 16, 2016 2:50:41 PM CEST Shawn Guo wrote:
> ZTE arm64 defconfig updates for 4.9:
> - Enable ZTE ZX family support in arm64 defconfig
>
Pulled into next/arm64, thanks!
Arnd
^ permalink raw reply
* [GIT PULL 1/3] ZTE arm64 soc changes for 4.9
From: Arnd Bergmann @ 2016-09-19 20:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474008641-30859-1-git-send-email-shawnguo@kernel.org>
On Friday, September 16, 2016 2:50:39 PM CEST Shawn Guo wrote:
> ZTE arm64 SoC changes for 4.9:
> - Add a Kconfig option for ZTE ZX SoC family support
>
Pulled into next/arm64, thanks!
Arnd
^ permalink raw reply
* [GIT PULL 2/3] ZTE arm64 device tree changes for 4.9
From: Arnd Bergmann @ 2016-09-19 20:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474008641-30859-2-git-send-email-shawnguo@kernel.org>
On Friday, September 16, 2016 2:50:40 PM CEST Shawn Guo wrote:
> ZTE arm64 device tree changes for 4.9:
> - Add initial DTS support for ZTE ZX296718 SoC and ZX296718 EVB board.
>
>
Pulled into next/dt64, thanks!
Arnd
^ permalink raw reply
* [GIT PULL 2/2] arm64: X-Gene platforms DTS changes queued for 4.9
From: Arnd Bergmann @ 2016-09-19 20:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CADaLNDk7uP8Gv+YB6oJfLqyRgjVVY82jQoPrQMk6y8xXGokyUQ@mail.gmail.com>
On Friday, September 16, 2016 12:01:28 AM CEST Duc Dang wrote:
> This is the DTS changes for X-Gene platforms targeted for 4.9.
>
> The changes include:
> + X-Gene Soc PMU DTS entry from X-Gene PMU patch set of Tai Nguyen [1]
> + Follow up patch to enable DTS entry for SoC PMU on X-Gene v2
> + Correct PCIe legacy interrupt mode to level-active high
> + DTS entry for X-Gene hwmon (v4 acked by Guenter, DT binding document
> and driver is in linux-next now [2])
> + DTS entries for X-Gene v2 CPU clock from X-Gene PMD clock patch set
> (v3 already accepted by Stephen into clk-next [3])
>
>
Pulled into next/dt64, thanks!
Arnd
^ permalink raw reply
* [GIT PULL] ARM: mvebu: dt64 for v4.9 (#2)
From: Arnd Bergmann @ 2016-09-19 20:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87d1k6bio7.fsf@free-electrons.com>
On Wednesday, September 14, 2016 5:33:12 PM CEST Gregory CLEMENT wrote:
> mvebu dt64 for 4.9 (part 2)
>
> - enable MSI for PCIe on Armada 7K/8K
>
Pulled into next/dt64, thanks!
Arnd
^ permalink raw reply
* [PATCH 3/4] watchdog: sa11x0/pxa: get rid of get_clock_tick_rate
From: Guenter Roeck @ 2016-09-19 20:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474312335-20997-4-git-send-email-robert.jarzmik@free.fr>
On Mon, Sep 19, 2016 at 09:12:14PM +0200, Robert Jarzmik wrote:
> The OS timer rate used for the watchdog can now be fetched from the
> standard clock API. This will remove the last user of
> get_clock_tick_rate() in both pxa and sa11x0 architectures.
>
> Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
Did you test this ? Potential problem, if built into the kernel, could be that
the clocks might not be ready by the time the driver is instantiated. Unless
this is converted to a platform driver, it won't be able to handle a
-EPROBE_DEFER from the clock subsystem.
Guenter
> ---
> drivers/watchdog/sa1100_wdt.c | 24 +++++++++++++++++++++++-
> 1 file changed, 23 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/watchdog/sa1100_wdt.c b/drivers/watchdog/sa1100_wdt.c
> index e1d39a1e9628..8965e3f536c3 100644
> --- a/drivers/watchdog/sa1100_wdt.c
> +++ b/drivers/watchdog/sa1100_wdt.c
> @@ -22,6 +22,7 @@
>
> #include <linux/module.h>
> #include <linux/moduleparam.h>
> +#include <linux/clk.h>
> #include <linux/types.h>
> #include <linux/kernel.h>
> #include <linux/fs.h>
> @@ -155,12 +156,27 @@ static struct miscdevice sa1100dog_miscdev = {
> };
>
> static int margin __initdata = 60; /* (secs) Default is 1 minute */
> +static struct clk *clk;
>
> static int __init sa1100dog_init(void)
> {
> int ret;
>
> - oscr_freq = get_clock_tick_rate();
> + clk = clk_get(NULL, "OSTIMER0");
> + if (IS_ERR(clk)) {
> + pr_err("SA1100/PXA2xx Watchdog Timer: clock not found: %d\n",
> + (int) PTR_ERR(clk));
> + return PTR_ERR(clk);
> + }
> +
> + ret = clk_prepare_enable(clk);
> + if (ret) {
> + pr_err("SA1100/PXA2xx Watchdog Timer: clock failed to prepare+enable: %d\n",
> + ret);
> + goto err;
> + }
> +
> + oscr_freq = clk_get_rate(clk);
>
> /*
> * Read the reset status, and save it for later. If
> @@ -176,11 +192,17 @@ static int __init sa1100dog_init(void)
> pr_info("SA1100/PXA2xx Watchdog Timer: timer margin %d sec\n",
> margin);
> return ret;
> +err:
> + clk_disable_unprepare(clk);
> + clk_put(clk);
> + return ret;
> }
>
> static void __exit sa1100dog_exit(void)
> {
> misc_deregister(&sa1100dog_miscdev);
> + clk_disable_unprepare(clk);
> + clk_put(clk);
> }
>
> module_init(sa1100dog_init);
> --
> 2.1.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-watchdog" 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
* [RFC PATCH] PCI/ACPI: xgene: Add ECAM quirk for X-Gene PCIe controller
From: Bjorn Helgaas @ 2016-09-19 20:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474122278-32525-1-git-send-email-dhdang@apm.com>
Hi Duc,
On Sat, Sep 17, 2016 at 07:24:38AM -0700, Duc Dang wrote:
> PCIe controller in X-Gene SoCs is not ECAM compliant: software
> needs to configure additional concontroller register to address
> device at bus:dev:function.
>
> This patch depends on "ECAM quirks handling for ARM64 platforms"
> series (http://www.spinics.net/lists/arm-kernel/msg530692.html)
> to address the limitation above for X-Gene PCIe controller.
>
> The quirk will only be applied for X-Gene PCIe MCFG table with
> OEM revison 1, 2, 3 or 4 (PCIe controller v1 and v2 on X-Gene SoCs).
>
> Signed-off-by: Duc Dang <dhdang@apm.com>
> ---
> drivers/acpi/pci_mcfg.c | 32 +++++
> drivers/pci/host/Makefile | 2 +-
> drivers/pci/host/pci-xgene-ecam.c | 280 ++++++++++++++++++++++++++++++++++++++
> include/linux/pci-ecam.h | 5 +
> 4 files changed, 318 insertions(+), 1 deletion(-)
> create mode 100644 drivers/pci/host/pci-xgene-ecam.c
This adds a bunch of stuff, but doesn't remove anything. So I assume
it's adding new functionality that didn't exist before. What is it?
I sort of expected this to also remove, for example, the seemingly
identical xgene_pcie_config_read32() in drivers/pci/host/pci-xgene.c.
Actually, a bunch of this code seems to be duplicated from there. It
doesn't seem like we should end up with all this duplicated code.
I'd really like it better if all this could get folded into
pci-xgene.c so we don't end up with more files.
> diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
> index ddf338b..adce35f 100644
> --- a/drivers/acpi/pci_mcfg.c
> +++ b/drivers/acpi/pci_mcfg.c
> @@ -123,6 +123,38 @@ static struct mcfg_fixup mcfg_quirks[] = {
> { "CAVIUM", "THUNDERX", 2, 13, MCFG_BUS_ANY, &pci_thunder_ecam_ops,
> MCFG_RES_EMPTY},
> #endif
> +#ifdef CONFIG_PCI_XGENE
> + {"APM ", "XGENE ", 1, 0, MCFG_BUS_ANY,
> + &xgene_v1_pcie_ecam_ops, MCFG_RES_EMPTY},
> + {"APM ", "XGENE ", 1, 1, MCFG_BUS_ANY,
> + &xgene_v1_pcie_ecam_ops, MCFG_RES_EMPTY},
> + {"APM ", "XGENE ", 1, 2, MCFG_BUS_ANY,
> + &xgene_v1_pcie_ecam_ops, MCFG_RES_EMPTY},
> + {"APM ", "XGENE ", 1, 3, MCFG_BUS_ANY,
> + &xgene_v1_pcie_ecam_ops, MCFG_RES_EMPTY},
> + {"APM ", "XGENE ", 1, 4, MCFG_BUS_ANY,
> + &xgene_v1_pcie_ecam_ops, MCFG_RES_EMPTY},
> + {"APM ", "XGENE ", 2, 0, MCFG_BUS_ANY,
> + &xgene_v1_pcie_ecam_ops, MCFG_RES_EMPTY},
> + {"APM ", "XGENE ", 2, 1, MCFG_BUS_ANY,
> + &xgene_v1_pcie_ecam_ops, MCFG_RES_EMPTY},
> + {"APM ", "XGENE ", 2, 2, MCFG_BUS_ANY,
> + &xgene_v1_pcie_ecam_ops, MCFG_RES_EMPTY},
> + {"APM ", "XGENE ", 2, 3, MCFG_BUS_ANY,
> + &xgene_v1_pcie_ecam_ops, MCFG_RES_EMPTY},
> + {"APM ", "XGENE ", 2, 4, MCFG_BUS_ANY,
> + &xgene_v1_pcie_ecam_ops, MCFG_RES_EMPTY},
> + {"APM ", "XGENE ", 3, 0, MCFG_BUS_ANY,
> + &xgene_v2_1_pcie_ecam_ops, MCFG_RES_EMPTY},
> + {"APM ", "XGENE ", 3, 1, MCFG_BUS_ANY,
> + &xgene_v2_1_pcie_ecam_ops, MCFG_RES_EMPTY},
> + {"APM ", "XGENE ", 4, 0, MCFG_BUS_ANY,
> + &xgene_v2_2_pcie_ecam_ops, MCFG_RES_EMPTY},
> + {"APM ", "XGENE ", 4, 1, MCFG_BUS_ANY,
> + &xgene_v2_2_pcie_ecam_ops, MCFG_RES_EMPTY},
> + {"APM ", "XGENE ", 4, 2, MCFG_BUS_ANY,
> + &xgene_v2_2_pcie_ecam_ops, MCFG_RES_EMPTY},
Most of these are the same. Let's add a macro that fills in the
boilerplate so each entry only contains the variable parts. I'm going
to propose the same for the ThunderX quirks.
> +#endif
> };
>
> static char mcfg_oem_id[ACPI_OEM_ID_SIZE];
> diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
> index 8843410..af4f505 100644
> --- a/drivers/pci/host/Makefile
> +++ b/drivers/pci/host/Makefile
> @@ -15,7 +15,7 @@ obj-$(CONFIG_PCIE_SPEAR13XX) += pcie-spear13xx.o
> obj-$(CONFIG_PCI_KEYSTONE) += pci-keystone-dw.o pci-keystone.o
> obj-$(CONFIG_PCIE_XILINX) += pcie-xilinx.o
> obj-$(CONFIG_PCIE_XILINX_NWL) += pcie-xilinx-nwl.o
> -obj-$(CONFIG_PCI_XGENE) += pci-xgene.o
> +obj-$(CONFIG_PCI_XGENE) += pci-xgene.o pci-xgene-ecam.o
> obj-$(CONFIG_PCI_XGENE_MSI) += pci-xgene-msi.o
> obj-$(CONFIG_PCI_LAYERSCAPE) += pci-layerscape.o
> obj-$(CONFIG_PCI_VERSATILE) += pci-versatile.o
> diff --git a/drivers/pci/host/pci-xgene-ecam.c b/drivers/pci/host/pci-xgene-ecam.c
> new file mode 100644
> index 0000000..b66a04f
> --- /dev/null
> +++ b/drivers/pci/host/pci-xgene-ecam.c
> @@ -0,0 +1,280 @@
> +/*
> + * APM X-Gene PCIe ECAM fixup driver
> + *
> + * Copyright (c) 2016, Applied Micro Circuits Corporation
> + * Author:
> + * Duc Dang <dhdang@apm.com>
> + *
> + * 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.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program. If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/of_address.h>
> +#include <linux/of_pci.h>
> +#include <linux/pci-acpi.h>
> +#include <linux/platform_device.h>
> +#include <linux/pci-ecam.h>
> +
> +#ifdef CONFIG_ACPI
> +#define RTDID 0x160
> +#define ROOT_CAP_AND_CTRL 0x5C
> +
> +/* PCIe IP version */
> +#define XGENE_PCIE_IP_VER_UNKN 0
> +#define XGENE_PCIE_IP_VER_1 1
> +#define XGENE_PCIE_IP_VER_2 2
We only use XGENE_PCIE_IP_VER_1, so I think the others should be
removed. I think it would be nicer to have a "crs_broken:1" bit set
by the probe path, and get rid of the version field altogether.
> +#define XGENE_CSR_LENGTH 0x10000
> +
> +struct xgene_pcie_acpi_root {
> + void __iomem *csr_base;
> + u32 version;
> +};
I think this should be folded into struct xgene_pcie_port so we don't
have to allocate and manage it separately.
> +static int xgene_v1_pcie_ecam_init(struct pci_config_window *cfg)
> +{
> + struct xgene_pcie_acpi_root *xgene_root;
> + struct device *dev = cfg->parent;
> + u32 csr_base;
> +
> + xgene_root = devm_kzalloc(dev, sizeof(*xgene_root), GFP_KERNEL);
> + if (!xgene_root)
> + return -ENOMEM;
> +
> + switch (cfg->res.start) {
> + case 0xE0D0000000ULL:
> + csr_base = 0x1F2B0000;
> + break;
> + case 0xD0D0000000ULL:
> + csr_base = 0x1F2C0000;
> + break;
> + case 0x90D0000000ULL:
> + csr_base = 0x1F2D0000;
> + break;
> + case 0xA0D0000000ULL:
> + csr_base = 0x1F500000;
> + break;
> + case 0xC0D0000000ULL:
> + csr_base = 0x1F510000;
> + break;
Ugh. What in the world is going on here? Apparently we're testing a
host bridge resource against this hard-coded list of random values,
and based on that, we know about this *other* list of hard-coded CSR
ranges? This is not the way resource discovery normally works ;)
> + default:
> + return -ENODEV;
> + }
> +
> + xgene_root->csr_base = ioremap(csr_base, XGENE_CSR_LENGTH);
There should be a request_region() somewhere, too. Ideal would be to
use devm_ioremap_resource(), but I don't know where this apparent
resource is coming from.
> + if (!xgene_root->csr_base) {
> + kfree(xgene_root);
> + return -ENODEV;
> + }
> +
> + xgene_root->version = XGENE_PCIE_IP_VER_1;
> +
> + cfg->priv = xgene_root;
> +
> + return 0;
> +}
> +
> +static int xgene_v2_1_pcie_ecam_init(struct pci_config_window *cfg)
> +{
> + struct xgene_pcie_acpi_root *xgene_root;
> + struct device *dev = cfg->parent;
> + resource_size_t csr_base;
> +
> + xgene_root = devm_kzalloc(dev, sizeof(*xgene_root), GFP_KERNEL);
> + if (!xgene_root)
> + return -ENOMEM;
> +
> + switch (cfg->res.start) {
> + case 0xC0D0000000ULL:
> + csr_base = 0x1F2B0000;
> + break;
> + case 0xA0D0000000ULL:
> + csr_base = 0x1F2C0000;
> + break;
> + default:
> + return -ENODEV;
> + }
> +
> + xgene_root->csr_base = ioremap(csr_base, XGENE_CSR_LENGTH);
> + if (!xgene_root->csr_base) {
> + kfree(xgene_root);
> + return -ENODEV;
> + }
> +
> + xgene_root->version = XGENE_PCIE_IP_VER_2;
> +
> + cfg->priv = xgene_root;
> +
> + return 0;
> +}
> +
> +static int xgene_v2_2_pcie_ecam_init(struct pci_config_window *cfg)
> +{
> + struct xgene_pcie_acpi_root *xgene_root;
> + struct device *dev = cfg->parent;
> + resource_size_t csr_base;
> +
> + xgene_root = devm_kzalloc(dev, sizeof(*xgene_root), GFP_KERNEL);
> + if (!xgene_root)
> + return -ENOMEM;
> +
> + switch (cfg->res.start) {
> + case 0xE0D0000000ULL:
> + csr_base = 0x1F2B0000;
> + break;
> + case 0xA0D0000000ULL:
> + csr_base = 0x1F500000;
> + break;
> + case 0x90D0000000ULL:
> + csr_base = 0x1F2D0000;
> + break;
> + default:
> + return -ENODEV;
> + }
> +
> + xgene_root->csr_base = ioremap(csr_base, XGENE_CSR_LENGTH);
> + if (!xgene_root->csr_base) {
> + kfree(xgene_root);
> + return -ENODEV;
> + }
> +
> + xgene_root->version = XGENE_PCIE_IP_VER_2;
> +
> + cfg->priv = xgene_root;
> +
> + return 0;
> +}
> +/*
> + * For Configuration request, RTDID register is used as Bus Number,
> + * Device Number and Function number of the header fields.
> + */
> +static void xgene_pcie_set_rtdid_reg(struct pci_bus *bus, uint devfn)
> +{
> + struct pci_config_window *cfg = bus->sysdata;
> + struct xgene_pcie_acpi_root *port = cfg->priv;
> + unsigned int b, d, f;
> + u32 rtdid_val = 0;
> +
> + b = bus->number;
> + d = PCI_SLOT(devfn);
> + f = PCI_FUNC(devfn);
> +
> + if (!pci_is_root_bus(bus))
> + rtdid_val = (b << 8) | (d << 3) | f;
> +
> + writel(rtdid_val, port->csr_base + RTDID);
> + /* read the register back to ensure flush */
> + readl(port->csr_base + RTDID);
> +}
> +
> +/*
> + * X-Gene PCIe port uses BAR0-BAR1 of RC's configuration space as
> + * the translation from PCI bus to native BUS. Entire DDR region
> + * is mapped into PCIe space using these registers, so it can be
> + * reached by DMA from EP devices. The BAR0/1 of bridge should be
> + * hidden during enumeration to avoid the sizing and resource allocation
> + * by PCIe core.
> + */
> +static bool xgene_pcie_hide_rc_bars(struct pci_bus *bus, int offset)
> +{
> + if (pci_is_root_bus(bus) && ((offset == PCI_BASE_ADDRESS_0) ||
> + (offset == PCI_BASE_ADDRESS_1)))
> + return true;
> +
> + return false;
> +}
> +
> +void __iomem *xgene_pcie_ecam_map_bus(struct pci_bus *bus,
> + unsigned int devfn, int where)
> +{
> + struct pci_config_window *cfg = bus->sysdata;
> + unsigned int busn = bus->number;
> + void __iomem *base;
> +
> + if (busn < cfg->busr.start || busn > cfg->busr.end)
> + return NULL;
> +
> + if ((pci_is_root_bus(bus) && devfn != 0) ||
> + xgene_pcie_hide_rc_bars(bus, where))
> + return NULL;
> +
> + xgene_pcie_set_rtdid_reg(bus, devfn);
> +
> + if (busn > cfg->busr.start)
> + base = cfg->win + (1 << cfg->ops->bus_shift);
> + else
> + base = cfg->win;
> +
> + return base + where;
> +}
> +
> +static int xgene_pcie_config_read32(struct pci_bus *bus, unsigned int devfn,
> + int where, int size, u32 *val)
> +{
> + struct pci_config_window *cfg = bus->sysdata;
> + struct xgene_pcie_acpi_root *port = cfg->priv;
> +
> + if (pci_generic_config_read32(bus, devfn, where & ~0x3, 4, val) !=
> + PCIBIOS_SUCCESSFUL)
> + return PCIBIOS_DEVICE_NOT_FOUND;
> +
> + /*
> + * The v1 controller has a bug in its Configuration Request
> + * Retry Status (CRS) logic: when CRS is enabled and we read the
> + * Vendor and Device ID of a non-existent device, the controller
> + * fabricates return data of 0xFFFF0001 ("device exists but is not
> + * ready") instead of 0xFFFFFFFF ("device does not exist"). This
> + * causes the PCI core to retry the read until it times out.
> + * Avoid this by not claiming to support CRS.
> + */
> + if (pci_is_root_bus(bus) && (port->version == XGENE_PCIE_IP_VER_1) &&
> + ((where & ~0x3) == ROOT_CAP_AND_CTRL))
> + *val &= ~(PCI_EXP_RTCAP_CRSVIS << 16);
> +
> + if (size <= 2)
> + *val = (*val >> (8 * (where & 3))) & ((1 << (size * 8)) - 1);
> +
> + return PCIBIOS_SUCCESSFUL;
> +}
> +
> +struct pci_ecam_ops xgene_v1_pcie_ecam_ops = {
> + .bus_shift = 16,
> + .init = xgene_v1_pcie_ecam_init,
> + .pci_ops = {
> + .map_bus = xgene_pcie_ecam_map_bus,
> + .read = xgene_pcie_config_read32,
> + .write = pci_generic_config_write,
> + }
> +};
> +
> +struct pci_ecam_ops xgene_v2_1_pcie_ecam_ops = {
> + .bus_shift = 16,
> + .init = xgene_v2_1_pcie_ecam_init,
> + .pci_ops = {
> + .map_bus = xgene_pcie_ecam_map_bus,
> + .read = xgene_pcie_config_read32,
> + .write = pci_generic_config_write,
> + }
> +};
> +
> +struct pci_ecam_ops xgene_v2_2_pcie_ecam_ops = {
> + .bus_shift = 16,
> + .init = xgene_v2_2_pcie_ecam_init,
> + .pci_ops = {
> + .map_bus = xgene_pcie_ecam_map_bus,
> + .read = xgene_pcie_config_read32,
> + .write = pci_generic_config_write,
> + }
> +};
> +#endif
> diff --git a/include/linux/pci-ecam.h b/include/linux/pci-ecam.h
> index 35f0e81..40da3e7 100644
> --- a/include/linux/pci-ecam.h
> +++ b/include/linux/pci-ecam.h
> @@ -65,6 +65,11 @@ extern struct pci_ecam_ops pci_thunder_pem_ops;
> #ifdef CONFIG_PCI_HOST_THUNDER_ECAM
> extern struct pci_ecam_ops pci_thunder_ecam_ops;
> #endif
> +#ifdef CONFIG_PCI_XGENE
> +extern struct pci_ecam_ops xgene_v1_pcie_ecam_ops;
> +extern struct pci_ecam_ops xgene_v2_1_pcie_ecam_ops;
> +extern struct pci_ecam_ops xgene_v2_2_pcie_ecam_ops;
> +#endif
>
> #ifdef CONFIG_PCI_HOST_GENERIC
> /* for DT-based PCI controllers that support ECAM */
> --
> 1.9.1
>
^ permalink raw reply
* [PATCH 4/4] ARM: sa11x0/pxa: get rid of get_clock_tick_rate
From: Daniel Lezcano @ 2016-09-19 19:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474312335-20997-5-git-send-email-robert.jarzmik@free.fr>
On 19/09/2016 21:12, Robert Jarzmik wrote:
> The last user of this function is gone, so remove it. The clock API
> should now be used to get clock rates.
>
> Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
> ---
Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
--
<http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply
* [PATCH 3/4] watchdog: sa11x0/pxa: get rid of get_clock_tick_rate
From: Daniel Lezcano @ 2016-09-19 19:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474312335-20997-4-git-send-email-robert.jarzmik@free.fr>
On 19/09/2016 21:12, Robert Jarzmik wrote:
> The OS timer rate used for the watchdog can now be fetched from the
> standard clock API. This will remove the last user of
> get_clock_tick_rate() in both pxa and sa11x0 architectures.
>
> Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
> ---
Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
--
<http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply
* [PATCH 2/4] ARM: sa11x0/pxa: acquire timer rate from the clock rate
From: Daniel Lezcano @ 2016-09-19 19:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474312335-20997-3-git-send-email-robert.jarzmik@free.fr>
On 19/09/2016 21:12, Robert Jarzmik wrote:
> As both pxa and sa1100 provide a clock to the timer, the rate can be
> inferred from the clock rather than hard encoded in a functional call.
>
> This patch changes the pxa timer to have a mandatory clock which is used
> as the timer rate.
>
> Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
> ---
Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
^ permalink raw reply
* [PATCH 17/19] power: reset: st: Remove obsolete platforms from dt doc
From: Sebastian Reichel @ 2016-09-19 19:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473859677-9231-18-git-send-email-peter.griffin@linaro.org>
Hi,
On Wed, Sep 14, 2016 at 02:27:55PM +0100, Peter Griffin wrote:
> This patch removes support for STiH415/6 SoC's from the
> st-restart dt binding documentation, as support for these
> platforms is being removed from the kernel. It also updates
> the dt example to a currently supported platform.
>
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
Also queued to power-supply's for-next branch.
-- Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160919/b61ceb5f/attachment-0001.sig>
^ permalink raw reply
* [PATCH 16/19] power: reset: st-poweroff: Remove obsolete platforms.
From: Sebastian Reichel @ 2016-09-19 19:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473859677-9231-17-git-send-email-peter.griffin@linaro.org>
Hi,
On Wed, Sep 14, 2016 at 02:27:54PM +0100, Peter Griffin wrote:
> This patch removes support for STiH415/6 SoC's from the
> st-poweroff driver, as support for these platforms is
> being removed from the kernel.
I queued this to power-supply's for-next branch. Please
cc me to full thread next time, so that I can see what
is goin on.
-- Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160919/fa4c20cc/attachment.sig>
^ permalink raw reply
* [PATCH 1/4] clk: pxa25x: OSTIMER0 clocks from the main oscillator
From: Stephen Boyd @ 2016-09-19 19:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474312335-20997-2-git-send-email-robert.jarzmik@free.fr>
On 09/19, Robert Jarzmik wrote:
> From: Russell King - ARM Linux <linux@armlinux.org.uk>
>
> The OSTIMER0 clock ticks at the main oscillator rate, not the 32kHz
> oscillator rate. Ensure that it is parented to the main oscillator.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> Acked-by: Robert Jarzmik <robert.jarzmik@free.fr>
> Tested-by: Robert Jarzmik <robert.jarzmik@free.fr>
> ---
Acked-by: Stephen Boyd <sboyd@codeaurora.org>
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [RFC PATCH v3 1/2] ARM: dts: samsung: add rga-lvds panel in itop elite
From: ayaka @ 2016-09-19 19:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5Agngx7b24bo3w7S84xtwZV81c-wAszs0B96FZhMeMW8A@mail.gmail.com>
On 09/20/2016 03:12 AM, Fabio Estevam wrote:
> On Mon, Sep 19, 2016 at 4:02 PM, Randy Li <ayaka@soulik.info> wrote:
>
>> + vcc_sys_lcd: sys-lcd {
>> + compatible = "regulator-fixed";
>> + regulator-name = "vcc_5v";
>> + regulator-min-microvolt = <5000000>;
>> + regulator-max-microvolt = <5000000>;
>> + gpio = <&gpl0 4 GPIO_ACTIVE_HIGH>;
> Is this really active high? If so, you should add the
> 'enable-active-high' property.
I see, thank you. Btw, let me make it clearly, it is really an
independentTransistor, not be controlled by PMIC.
^ permalink raw reply
* [PATCH v5 3/5] arm64: arch_timer: Work around QorIQ Erratum A-008585
From: Scott Wood @ 2016-09-19 19:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160919170707.GC30584@leverpostej>
On Mon, 2016-09-19 at 18:07 +0100, Mark Rutland wrote:
> On Mon, Sep 19, 2016 at 12:01:29PM -0500, Scott Wood wrote:
> >
> > On Mon, 2016-09-19 at 17:52 +0100, Mark Rutland wrote:
> > >
> > > >
> > > > >
> > > > > >
> > > > > >
> > > > > > +static void fsl_a008585_set_sne(struct clock_event_device *clk)
> > > > > > +{
> > > > > > +#ifdef CONFIG_FSL_ERRATUM_A008585
> > > > > > + if
> > > > > > (!static_branch_unlikely(&arch_timer_read_ool_enabled))
> > > > > > + return;
> > > > > > +
> > > > > > + if (arch_timer_uses_ppi == VIRT_PPI)
> > > > > > + clk->set_next_event =
> > > > > > fsl_a008585_set_next_event_virt;
> > > > > > + else
> > > > > > + clk->set_next_event =
> > > > > > fsl_a008585_set_next_event_phys;
> > > > > > +#endif
> > > > > > +}
> > > > > > +
> > > > > I'm not keen on the magic hook to reset the function pointers, and
> > > > > the
> > > > > additional phys/virt stubs seem pointless. Instead, can we fold this
> > > > > into the existing set_next_event? e.g. have that do:
> > > > >
> > > > > if (needs_fsl_a008585_workaround() {
> > > > > fsl_a008585_set_next_event(access, evt, clk);
> > > > > return;
> > > > > }
> > > > OK. ?I had been trying to avoid messing with the standard
> > > > set_next_event,
> > > > but
> > > > it doesn't matter as much now that static branches are being used. ?In
> > > > that
> > > > case we can avoid duplicating the ctrl code, and only replace the tval
> > > > write.
> > > Reconsidering my suggestion, I realise this will also affect the MMIO
> > > timers, so that doesn't work.
> > >
> > > So for the moment, I guess we have to keep fsl_a008585_set_next_event().
> > What is the problem with MMIO timers? ?needs_fsl_a008585_workaround()
> > should
> > always be false for them.
> As suggested, needs_fsl_a008585_workaround() takes no parameter, and
> set_next_event is called for both cp15/sysreg and MMIO timers. So it
> would either be true for all, or false for all.
>
> If it's true for all, we'd end up calling fsl_a008585_set_next_event()
> for the MMIO timers too.
There should not be any MMIO timers on a system where
fsl_a008585_set_next_event() returns true.
-Scott
^ permalink raw reply
* [RFC PATCH v3 1/2] ARM: dts: samsung: add rga-lvds panel in itop elite
From: Fabio Estevam @ 2016-09-19 19:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474311771-23321-2-git-send-email-ayaka@soulik.info>
On Mon, Sep 19, 2016 at 4:02 PM, Randy Li <ayaka@soulik.info> wrote:
> + vcc_sys_lcd: sys-lcd {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc_5v";
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + gpio = <&gpl0 4 GPIO_ACTIVE_HIGH>;
Is this really active high? If so, you should add the
'enable-active-high' property.
^ permalink raw reply
* [PATCH 4/4] ARM: sa11x0/pxa: get rid of get_clock_tick_rate
From: Robert Jarzmik @ 2016-09-19 19:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474312335-20997-1-git-send-email-robert.jarzmik@free.fr>
The last user of this function is gone, so remove it. The clock API
should now be used to get clock rates.
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
---
arch/arm/mach-pxa/generic.c | 15 ---------------
arch/arm/mach-pxa/include/mach/hardware.h | 2 --
arch/arm/mach-sa1100/include/mach/hardware.h | 4 ----
3 files changed, 21 deletions(-)
diff --git a/arch/arm/mach-pxa/generic.c b/arch/arm/mach-pxa/generic.c
index 2a9297991d74..cb73a9723d0e 100644
--- a/arch/arm/mach-pxa/generic.c
+++ b/arch/arm/mach-pxa/generic.c
@@ -43,21 +43,6 @@ void clear_reset_status(unsigned int mask)
}
}
-unsigned long get_clock_tick_rate(void)
-{
- unsigned long clock_tick_rate;
-
- if (cpu_is_pxa25x())
- clock_tick_rate = 3686400;
- else if (machine_is_mainstone())
- clock_tick_rate = 3249600;
- else
- clock_tick_rate = 3250000;
-
- return clock_tick_rate;
-}
-EXPORT_SYMBOL(get_clock_tick_rate);
-
/*
* For non device-tree builds, keep legacy timer init
*/
diff --git a/arch/arm/mach-pxa/include/mach/hardware.h b/arch/arm/mach-pxa/include/mach/hardware.h
index 8d63c211b22f..55064124ca4e 100644
--- a/arch/arm/mach-pxa/include/mach/hardware.h
+++ b/arch/arm/mach-pxa/include/mach/hardware.h
@@ -303,8 +303,6 @@
*/
extern unsigned int get_memclk_frequency_10khz(void);
-/* return the clock tick rate of the OS timer */
-extern unsigned long get_clock_tick_rate(void);
#endif
#endif /* _ASM_ARCH_HARDWARE_H */
diff --git a/arch/arm/mach-sa1100/include/mach/hardware.h b/arch/arm/mach-sa1100/include/mach/hardware.h
index cbedd75a9d65..474844a93e29 100644
--- a/arch/arm/mach-sa1100/include/mach/hardware.h
+++ b/arch/arm/mach-sa1100/include/mach/hardware.h
@@ -61,10 +61,6 @@
# define __REG(x) (*((volatile unsigned long __iomem *)io_p2v(x)))
# define __PREG(x) (io_v2p((unsigned long)&(x)))
-static inline unsigned long get_clock_tick_rate(void)
-{
- return 3686400;
-}
#else
# define __REG(x) io_p2v(x)
--
2.1.4
^ permalink raw reply related
* [PATCH 3/4] watchdog: sa11x0/pxa: get rid of get_clock_tick_rate
From: Robert Jarzmik @ 2016-09-19 19:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474312335-20997-1-git-send-email-robert.jarzmik@free.fr>
The OS timer rate used for the watchdog can now be fetched from the
standard clock API. This will remove the last user of
get_clock_tick_rate() in both pxa and sa11x0 architectures.
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
---
drivers/watchdog/sa1100_wdt.c | 24 +++++++++++++++++++++++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/drivers/watchdog/sa1100_wdt.c b/drivers/watchdog/sa1100_wdt.c
index e1d39a1e9628..8965e3f536c3 100644
--- a/drivers/watchdog/sa1100_wdt.c
+++ b/drivers/watchdog/sa1100_wdt.c
@@ -22,6 +22,7 @@
#include <linux/module.h>
#include <linux/moduleparam.h>
+#include <linux/clk.h>
#include <linux/types.h>
#include <linux/kernel.h>
#include <linux/fs.h>
@@ -155,12 +156,27 @@ static struct miscdevice sa1100dog_miscdev = {
};
static int margin __initdata = 60; /* (secs) Default is 1 minute */
+static struct clk *clk;
static int __init sa1100dog_init(void)
{
int ret;
- oscr_freq = get_clock_tick_rate();
+ clk = clk_get(NULL, "OSTIMER0");
+ if (IS_ERR(clk)) {
+ pr_err("SA1100/PXA2xx Watchdog Timer: clock not found: %d\n",
+ (int) PTR_ERR(clk));
+ return PTR_ERR(clk);
+ }
+
+ ret = clk_prepare_enable(clk);
+ if (ret) {
+ pr_err("SA1100/PXA2xx Watchdog Timer: clock failed to prepare+enable: %d\n",
+ ret);
+ goto err;
+ }
+
+ oscr_freq = clk_get_rate(clk);
/*
* Read the reset status, and save it for later. If
@@ -176,11 +192,17 @@ static int __init sa1100dog_init(void)
pr_info("SA1100/PXA2xx Watchdog Timer: timer margin %d sec\n",
margin);
return ret;
+err:
+ clk_disable_unprepare(clk);
+ clk_put(clk);
+ return ret;
}
static void __exit sa1100dog_exit(void)
{
misc_deregister(&sa1100dog_miscdev);
+ clk_disable_unprepare(clk);
+ clk_put(clk);
}
module_init(sa1100dog_init);
--
2.1.4
^ permalink raw reply related
* [PATCH 2/4] ARM: sa11x0/pxa: acquire timer rate from the clock rate
From: Robert Jarzmik @ 2016-09-19 19:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474312335-20997-1-git-send-email-robert.jarzmik@free.fr>
As both pxa and sa1100 provide a clock to the timer, the rate can be
inferred from the clock rather than hard encoded in a functional call.
This patch changes the pxa timer to have a mandatory clock which is used
as the timer rate.
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
---
arch/arm/mach-pxa/generic.c | 3 +--
arch/arm/mach-sa1100/generic.c | 2 +-
drivers/clocksource/pxa_timer.c | 11 +++++------
include/clocksource/pxa.h | 3 +--
4 files changed, 8 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-pxa/generic.c b/arch/arm/mach-pxa/generic.c
index ec510ecf8370..2a9297991d74 100644
--- a/arch/arm/mach-pxa/generic.c
+++ b/arch/arm/mach-pxa/generic.c
@@ -69,8 +69,7 @@ void __init pxa_timer_init(void)
pxa27x_clocks_init();
if (cpu_is_pxa3xx())
pxa3xx_clocks_init();
- pxa_timer_nodt_init(IRQ_OST0, io_p2v(0x40a00000),
- get_clock_tick_rate());
+ pxa_timer_nodt_init(IRQ_OST0, io_p2v(0x40a00000));
}
/*
diff --git a/arch/arm/mach-sa1100/generic.c b/arch/arm/mach-sa1100/generic.c
index 3e09beddb6e8..2eb00691b07d 100644
--- a/arch/arm/mach-sa1100/generic.c
+++ b/arch/arm/mach-sa1100/generic.c
@@ -378,7 +378,7 @@ void __init sa1100_map_io(void)
void __init sa1100_timer_init(void)
{
- pxa_timer_nodt_init(IRQ_OST0, io_p2v(0x90000000), 3686400);
+ pxa_timer_nodt_init(IRQ_OST0, io_p2v(0x90000000));
}
static struct resource irq_resource =
diff --git a/drivers/clocksource/pxa_timer.c b/drivers/clocksource/pxa_timer.c
index 3e1cb512f3ce..9cae38eebec2 100644
--- a/drivers/clocksource/pxa_timer.c
+++ b/drivers/clocksource/pxa_timer.c
@@ -220,17 +220,16 @@ CLOCKSOURCE_OF_DECLARE(pxa_timer, "marvell,pxa-timer", pxa_timer_dt_init);
/*
* Legacy timer init for non device-tree boards.
*/
-void __init pxa_timer_nodt_init(int irq, void __iomem *base,
- unsigned long clock_tick_rate)
+void __init pxa_timer_nodt_init(int irq, void __iomem *base)
{
struct clk *clk;
timer_base = base;
clk = clk_get(NULL, "OSTIMER0");
- if (clk && !IS_ERR(clk))
+ if (clk && !IS_ERR(clk)) {
clk_prepare_enable(clk);
- else
+ pxa_timer_common_init(irq, clk_get_rate(clk));
+ } else {
pr_crit("%s: unable to get clk\n", __func__);
-
- pxa_timer_common_init(irq, clock_tick_rate);
+ }
}
diff --git a/include/clocksource/pxa.h b/include/clocksource/pxa.h
index 1efbe5a66958..a9a0f03024a4 100644
--- a/include/clocksource/pxa.h
+++ b/include/clocksource/pxa.h
@@ -12,7 +12,6 @@
#ifndef _CLOCKSOURCE_PXA_H
#define _CLOCKSOURCE_PXA_H
-extern void pxa_timer_nodt_init(int irq, void __iomem *base,
- unsigned long clock_tick_rate);
+extern void pxa_timer_nodt_init(int irq, void __iomem *base);
#endif
--
2.1.4
^ permalink raw reply related
* [PATCH 1/4] clk: pxa25x: OSTIMER0 clocks from the main oscillator
From: Robert Jarzmik @ 2016-09-19 19:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474312335-20997-1-git-send-email-robert.jarzmik@free.fr>
From: Russell King - ARM Linux <linux@armlinux.org.uk>
The OSTIMER0 clock ticks at the main oscillator rate, not the 32kHz
oscillator rate. Ensure that it is parented to the main oscillator.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Acked-by: Robert Jarzmik <robert.jarzmik@free.fr>
Tested-by: Robert Jarzmik <robert.jarzmik@free.fr>
---
drivers/clk/pxa/clk-pxa25x.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/pxa/clk-pxa25x.c b/drivers/clk/pxa/clk-pxa25x.c
index a98b98e2a9e4..56b0a6027e38 100644
--- a/drivers/clk/pxa/clk-pxa25x.c
+++ b/drivers/clk/pxa/clk-pxa25x.c
@@ -230,7 +230,7 @@ static struct dummy_clk dummy_clks[] __initdata = {
DUMMY_CLK("GPIO11_CLK", NULL, "osc_3_6864mhz"),
DUMMY_CLK("GPIO12_CLK", NULL, "osc_32_768khz"),
DUMMY_CLK(NULL, "sa1100-rtc", "osc_32_768khz"),
- DUMMY_CLK("OSTIMER0", NULL, "osc_32_768khz"),
+ DUMMY_CLK("OSTIMER0", NULL, "osc_3_6864mhz"),
DUMMY_CLK("UARTCLK", "pxa2xx-ir", "STUART"),
};
--
2.1.4
^ permalink raw reply related
* [PATCH 0/4] kill get_clock_tick_rate()
From: Robert Jarzmik @ 2016-09-19 19:12 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
This serie aims at killing get_clock_tick_rate() from pxa and sa1100 and replace
it by clock API calls.
I'd like to have this reviewed and acked afterwards at least by :
- Russell for the mach-sa1100 and sa1100_wdt.c
- Stephen or Michael for the clk-pxa25x.c
- Thomas or Daniel for the clocksource part
- Wim for sa1100_wdt.c
If the review converges, I'd also like to take it through the pxa/for-next tree,
or alternatively Russell's tree if there is a dependency I'm not seeing, for
v4.10 cycle.
Cheers.
Robert Jarzmik (3):
ARM: sa11x0/pxa: acquire timer rate from the clock rate
watchdog: sa11x0/pxa: get rid of get_clock_tick_rate
ARM: sa11x0/pxa: get rid of get_clock_tick_rate
Russell King - ARM Linux (1):
clk: pxa25x: OSTIMER0 clocks from the main oscillator
arch/arm/mach-pxa/generic.c | 18 +-----------------
arch/arm/mach-pxa/include/mach/hardware.h | 2 --
arch/arm/mach-sa1100/generic.c | 2 +-
arch/arm/mach-sa1100/include/mach/hardware.h | 4 ----
drivers/clk/pxa/clk-pxa25x.c | 2 +-
drivers/clocksource/pxa_timer.c | 11 +++++------
drivers/watchdog/sa1100_wdt.c | 24 +++++++++++++++++++++++-
include/clocksource/pxa.h | 3 +--
8 files changed, 32 insertions(+), 34 deletions(-)
--
2.1.4
^ permalink raw reply
* [RFC PATCH v3 2/2] drm/panel: Add support for Chunghwa CLAA070WP03XG panel
From: Randy Li @ 2016-09-19 19:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474311771-23321-1-git-send-email-ayaka@soulik.info>
The Chunghwa CLAA070WP03XG is a 7" 1280x800 panel, which can be
supported by the simple panel driver.
Signed-off-by: Randy Li <ayaka@soulik.info>
---
.../display/panel/chunghwa,claa070wp03xg.txt | 7 ++++++
drivers/gpu/drm/panel/panel-simple.c | 27 ++++++++++++++++++++++
2 files changed, 34 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/panel/chunghwa,claa070wp03xg.txt
diff --git a/Documentation/devicetree/bindings/display/panel/chunghwa,claa070wp03xg.txt b/Documentation/devicetree/bindings/display/panel/chunghwa,claa070wp03xg.txt
new file mode 100644
index 0000000..dd22685
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/chunghwa,claa070wp03xg.txt
@@ -0,0 +1,7 @@
+Chunghwa Picture Tubes Ltd. 7" WXGA TFT LCD panel
+
+Required properties:
+- compatible: should be "chunghwa,claa070wp03xg"
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index f178998..3204e6b 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -583,6 +583,30 @@ static const struct panel_desc avic_tm070ddh03 = {
},
};
+static const struct drm_display_mode chunghwa_claa070wp03xg_mode = {
+ .clock = 66770,
+ .hdisplay = 800,
+ .hsync_start = 800 + 49,
+ .hsync_end = 800 + 49 + 33,
+ .htotal = 800 + 49 + 33 + 17,
+ .vdisplay = 1280,
+ .vsync_start = 1280 + 1,
+ .vsync_end = 1280 + 1 + 7,
+ .vtotal = 1280 + 1 + 7 + 15,
+ .vrefresh = 60,
+ .flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
+};
+
+static const struct panel_desc chunghwa_claa070wp03xg = {
+ .modes = &chunghwa_claa070wp03xg_mode,
+ .num_modes = 1,
+ .bpc = 6,
+ .size = {
+ .width = 94,
+ .height = 150,
+ },
+};
+
static const struct drm_display_mode chunghwa_claa101wa01a_mode = {
.clock = 72070,
.hdisplay = 1366,
@@ -1544,6 +1568,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "avic,tm070ddh03",
.data = &avic_tm070ddh03,
}, {
+ .compatible = "chunghwa,claa070wp03xg",
+ .data = &chunghwa_claa070wp03xg,
+ }, {
.compatible = "chunghwa,claa101wa01a",
.data = &chunghwa_claa101wa01a
}, {
--
2.7.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox