* [PATCH v3] arm: dts: zynq: Add MicroZed board support
From: Michal Simek @ 2016-09-26 6:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474624113-22825-1-git-send-email-jagan@amarulasolutions.com>
On 23.9.2016 11:48, Jagan Teki wrote:
> From: Jagan Teki <jteki@openedev.com>
>
> Added basic dts support for MicroZed board.
>
> - UART
> - SDHCI
> - Ethernet
>
> Cc: Soren Brinkmann <soren.brinkmann@xilinx.com>
> Cc: Michal Simek <michal.simek@xilinx.com>
> Signed-off-by: Jagan Teki <jteki@openedev.com>
> ---
> Changes for v3:
> - Add Xilinx copyright
> Changes for v2:
> - Add SDHCI
> - Add Ethernet
>
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/zynq-microzed.dts | 96 +++++++++++++++++++++++++++++++++++++
> 2 files changed, 97 insertions(+)
> create mode 100644 arch/arm/boot/dts/zynq-microzed.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index faacd52..4d7b858 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -862,6 +862,7 @@ dtb-$(CONFIG_ARCH_VT8500) += \
> wm8750-apc8750.dtb \
> wm8850-w70v2.dtb
> dtb-$(CONFIG_ARCH_ZYNQ) += \
> + zynq-microzed.dtb \
> zynq-parallella.dtb \
> zynq-zc702.dtb \
> zynq-zc706.dtb \
> diff --git a/arch/arm/boot/dts/zynq-microzed.dts b/arch/arm/boot/dts/zynq-microzed.dts
> new file mode 100644
> index 0000000..b9376a4
> --- /dev/null
> +++ b/arch/arm/boot/dts/zynq-microzed.dts
> @@ -0,0 +1,96 @@
> +/*
> + * Copyright (C) 2011 - 2014 Xilinx
> + * Copyright (C) 2016 Jagan Teki <jteki@openedev.com>
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License version 2, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * 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.
> + */
> +/dts-v1/;
> +/include/ "zynq-7000.dtsi"
> +
> +/ {
> + model = "Zynq MicroZED Development Board";
> + compatible = "xlnx,zynq-microzed", "xlnx,zynq-7000";
> +
> + aliases {
> + ethernet0 = &gem0;
> + serial0 = &uart1;
> + };
> +
> + memory {
> + device_type = "memory";
> + reg = <0x0 0x40000000>;
> + };
> +
> + chosen {
> + bootargs = "earlycon";
> + stdout-path = "serial0:115200n8";
> + };
> +
> + usb_phy0: phy0 {
> + compatible = "usb-nop-xceiv";
> + #phy-cells = <0>;
> + };
> +};
> +
> +&clkc {
> + ps-clk-frequency = <33333333>;
> +};
> +
> +&gem0 {
> + status = "okay";
> + phy-mode = "rgmii-id";
> + phy-handle = <ðernet_phy>;
> +
> + ethernet_phy: ethernet-phy at 0 {
> + reg = <0>;
> + };
> +};
> +
> +&sdhci0 {
> + status = "okay";
> +};
> +
> +&uart1 {
> + status = "okay";
> +};
> +
> +&usb0 {
> + status = "okay";
> + dr_mode = "host";
> + usb-phy = <&usb_phy0>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_usb0_default>;
> +};
> +
> +&pinctrl0 {
> + pinctrl_usb0_default: usb0-default {
> + mux {
> + groups = "usb0_0_grp";
> + function = "usb0";
> + };
> +
> + conf {
> + groups = "usb0_0_grp";
> + slew-rate = <0>;
> + io-standard = <1>;
> + };
> +
> + conf-rx {
> + pins = "MIO29", "MIO31", "MIO36";
> + bias-high-impedance;
> + };
> +
> + conf-tx {
> + pins = "MIO28", "MIO30", "MIO32", "MIO33", "MIO34",
> + "MIO35", "MIO37", "MIO38", "MIO39";
> + bias-disable;
> + };
> + };
> +};
>
Applied.
Thanks,
Michal
^ permalink raw reply
* [PATCH] tty/serial: atmel: fix fractional baud rate computation
From: Uwe Kleine-König @ 2016-09-26 6:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160921104414.16241-1-nicolas.ferre@atmel.com>
Hello,
On Wed, Sep 21, 2016 at 12:44:14PM +0200, Nicolas Ferre wrote:
> From: Alexey Starikovskiy <aystarik@gmail.com>
>
> The problem with previous code was it rounded values in wrong
> place and produced wrong baud rate in some cases.
>
> Signed-off-by: Alexey Starikovskiy <aystarik@gmail.com>
> [nicolas.ferre at atmel.com: port to newer kernel and add commit log]
> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
I first thought this patch results in not always picking the optimal
divider in some cases. But given the right error function (i.e.
error(r) = abs(1/r_target - 1/r_actual) which minimizes the error in the
time domain and so guarantees the maximal count of matched samples) it
can be proved to result in the right values (assuming no overflow etc.).
As writing formulas in email is cumbersome, see the attachment for a
prove.
Reviewed-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: baudrate.pdf
Type: application/pdf
Size: 69704 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160926/02579e68/attachment-0001.pdf>
^ permalink raw reply
* [RFC PATCH 00/11] pci: support for configurable PCI endpoint
From: Kishon Vijay Abraham I @ 2016-09-26 6:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6722152.QTF992tLpW@wuerfel>
Hi Arnd,
On Thursday 22 September 2016 07:04 PM, Arnd Bergmann wrote:
> On Thursday, September 15, 2016 2:03:05 PM CEST Kishon Vijay Abraham I wrote:
>> On Wednesday 14 September 2016 06:55 PM, Arnd Bergmann wrote:
>>> On Wednesday, September 14, 2016 10:41:56 AM CEST Kishon Vijay Abraham I wrote:
>>> I've added the drivers/ntb maintainers to Cc, given that there is
>>> a certain degree of overlap between your work and the existing
>>> code, I think they should be part of the discussion.
>>>
>>>> Known Limitation:
>>>> *) Does not support multi-function devices
>>>
>>> If I understand it right, this was a problem for USB and adding
>>> it later made it somewhat inconsistent. Maybe we can at least
>>> try to come up with an idea of how multi-function devices
>>> could be handled even if we don't implement it until someone
>>> actually needs it.
>>
>> Actually IMO multi-function device in PCI should be much simpler than it is for
>> USB. In the case of USB, all the functions in a multi-function device will
>> share the same *usb configuration* . (USB device can have multiple
>> configuration but only one can be enabled at a time). A multi-function USB
>> device will still have a single vendor-id/product-id/class... So I think a
>> separate library (composite.c) in USB makes sense.
>
> Ok, makes sense.
>
>> But in the case of PCI, every function can be treated independently since all
>> the functions have it's own 4KB configuration space. Each function can be
>> configured independently. Each can have it's own vendor-id/product-id/class..
>> I'm not sure if we'll need a separate library for PCI like we have for USB.
>
> I think it depends on whether we want to add the software multi-function
> support you mention.
>
>> Now the restriction for not allowing multi-function device is because of the
>> following structure definition.
>>
>> struct pci_epc {
>> ..
>> struct pci_epf *epf;
>> ..
>> };
>>
>> EPC has a single reference to EPF and it is used *only* to notify the function
>> driver when the link is up. (If this can be changed to use notification
>> mechanism, multi-function devices can be supported here)
>>
>> One more place where this restriction arises is in designware driver
>>
>> struct dw_pcie_ep {
>> ..
>> u8 bar_to_atu[6];
>> ..
>> };
>>
>> We use single ATU window to configure a BAR (in BAR). If there are multiple
>> functions, then this should also be modified since each function has 6 BARs.
>>
>> This can be fixed without much effort unless some other issue props up.
>
> Ok.
>
>>>
>>> Is your hardware able to make the PCIe endpoint look like
>>> a device with multiple PCI functions, or would one have to
>>> do this in software inside of a single PCI function if we
>>> ever need it?
>>
>> The hardware I have doesn't support multiple PCI functions (like having a
>> separate configuration space for each function). It has a dedicated space for
>> configuration space supporting only one function. [Section 24.9.7.3.2
>> PCIe_SS_EP_CFG_DBICS Register Description in [1]].
>>
>> yeah, it has to be done in software (but that won't be multi-function device in
>> PCI terms).
>>
>> [1] -> http://www.ti.com/lit/ug/spruhz6g/spruhz6g.pdf
>
> Ok, so in theory there can be other hardware (and quite likely is)
> that supports multiple functions, and we can extend the framework
> to support them without major obstacles, but your hardware doesn't,
> so you kept it simple with one hardcoded function, right?
right, PCIe can have upto 8 functions. So the issues with the current framework
has to be fixed. I don't expect major obstacles with this as of now.
>
> Seems completely reasonable to me.
>
>>>> TODO:
>>>> *) access buffers in RC
>>>> *) raise MSI interrupts
>>>> *) Enable user space control for the RC side PCI driver
>>>
>>> The user space control would end up just being one of several
>>> gadget drivers, right? E.g. gadget drivers for standard hardware
>>> (8250 uart, ATA, NVMe, some ethernet) could be done as kernel
>>> drivers while a user space driver can be used for things that
>>> are more unusual and that don't need to interface to another
>>> part of the kernel?
>>
>> Actually I didn't mean that. It was more with respect to the host side PCI test
>> driver (drivers/misc/pci_endpoint_test.c). Right now it validates BAR, irq
>> itself. I wanted to change this so that the user controls which tests to run.
>> (Like for USB gadget zero tests, testusb.c invokes ioctls to perform various
>> tests). Similarly I want to have a userspace program invoke pci_endpoint_test
>> to perform various PCI tests.
>
> Ok, I see. So what I described above would be yet another function
> driver that can be implemented, but so far, you have not planned
> to do that because there was not need, right?
right. I felt pci_endpoint_test is the generic function that would be of
interest to all the vendors. Any new function can be added by taking
pci_endpoint_test as a reference.
The simple usecase I plan to work on after completing the framework is to have
a camera sensor in one board and display in another board (the boards connected
using PCIe) and the display showing the the camera capture.
>
>>>
>>>> *) Adapt all other users of designware to use the new design (only
>>>> dra7xx has been adapted)
>>>
>>> I don't fully understand this part. Does every designware based
>>> driver need modifications, or are the changes to the
>>> generic parts of the designware driver enough to make it
>>> work for the simpler platforms?
>>
>> I have changed the core designware driver structures (like previously the
>> platform drivers will only use pcie_port, but now I introduced struct dw_pcie
>> to support both host and endpoint). This will break (compilation failure) all
>> the designware based drivers (except dra7xx). All these drivers should be
>> adapted to the new change (even if they work only in host mode these has to be
>> adapted).
>
> Ah, so we have to do two separate modifications to each designware driver:
>
> a) make it work with your patch (mandatory)
> b) make it support endpoint mode (optional)
yes.
>
>>>> HOW TO:
>>>>
>>>> ON THE EP SIDE:
>>>> ***************
>>>>
>>>> /* EP function is configured using configfs */
>>>> # mount -t configfs none /sys/kernel/config
>>>>
>>>> /* PCI EP core layer creates "pci_ep" entry in configfs */
>>>> # cd /sys/kernel/config/pci_ep/
>>>>
>>>> /*
>>>> * This is the 1st step in creating an endpoint function. This
>>>> * creates the endpoint function device *instance*. The string
>>>> * before the .<num> suffix will identify the driver this
>>>> * EP function will bind to.
>>>> * Just pci_epf_test is also valid. The .<num> suffix is used
>>>> * if there are multiple PCI controllers and all of them wants
>>>> * to use the same function.
>>>> */
>>>> # mkdir pci_epf_test.0
>>>
>>> I haven't used USB gadgets, but I assume this is modeled around
>>> the same interface. If there are notable differences, please mention
>>> what they are. Otherwise the general concept seems rather nice to me.
>>
>> Yeah, both USB gadget and PCI endpoint use configfs interface but the semantics
>> are quite different.
>>
>> Every directory in *usb_gadget* corresponds to a gadget device, and the gadget
>> device has a functions sub-directory which has the USB functions. And these
>> directories have fields or attributes specific to USB.
>>
>> But in the case of PCI, every directory in *pci_ep* corresponds to a PCI
>> function and it has fields or attributes specific to PCI function.
>
> Ok, I see.
>
>> The main reason for using configfs for PCI endpoint is to give the users to
>> control "which function has to be bound to which controller". The same concept
>> is used for USB gadget as well but there it is "which gadget device has to be
>> bound to which controller".
>
> We should still find out whether it's important that you can have
> a single PCI function with a software multi-function support of some
> sort. We'd still be limited to six BARs in total, and would also need
> something to identify those sub-functions, so implementing that might
> get quite hairy.
>
> Possibly this could be done at a higher level, e.g. by implementing
> a PCI-virtio multiplexer that can host multiple virtio based devices
> inside of a single PCI function. If we think that would be a good idea,
> we should make sure the configfs interface is extensible enough to
> handle that.
Okay. So here the main function (actual PCI function) *can* perform the work of
virtio muliplexer if the platform wants to support sub-functions or it can be a
normal PCI function. right?
>
> One use case I have in mind for this is to have a PCI function that
> can use virtio to provide rootfs (virtio-blk or 9pfs), network
> and console to the system that implements the PCI function (note
> that this is the opposite direction of what almost everyone else
> uses PCI devices for).
Do you mean the virtio should actually be in the host side? Even here the
system that implements PCI function should have multiple functions right? (one
for network, other for console etc..). So there should be a virtio multiplexer
both in the host side and in the device side?
>
>>> Let's talk (high-level) about the DT binding. I see that the way
>>> you have done it here, one will need to have a different .dtb file
>>> for a machine depending on whether the PCIe is used in host or
>>> endpoint mode. The advantage of this way is that it's a much
>>> cleaner binding (PCIe host bindings are a mess, and adding more
>>> options to it will only make it worse), the downside is that
>>> you can't decide at runtime what you want to use it for. E.g.
>>> connecting two identical machines over PCIe requires deciding
>>> in the bootloader which one is the endpoint, or using DT
>>> overlays, which may be awkward for some users. Is this a realistic
>>> use case, or do you expect that all machines will only ever be
>>> used in one of the two ways?
>>
>> It would definitely be nice to select the mode at runtime. Even for this patch
>> series, I added a temporary dtsi patch to configure the pci controller in EP
>> mode (which can't be merged since the same controller is also used to test RC).
>
> I think it should be possible to have two bindings that define a
> distinct set of properties, and have one node that is marked
> as "compatible" with both of them in order to let the OS choose
> one or the other mode.
hmm.. okay.
Thanks
Kishon
^ permalink raw reply
* [PATCH] ARM: uniphier: select ARCH_HAS_RESET_CONTROLLER
From: Masahiro Yamada @ 2016-09-26 5:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474368275.4030.45.camel@pengutronix.de>
Hi Philipp,
2016-09-20 19:44 GMT+09:00 Philipp Zabel <p.zabel@pengutronix.de>:
> Am Dienstag, den 20.09.2016, 17:47 +0900 schrieb Masahiro Yamada:
>> Hi Philipp,
>>
>>
>> 2016-09-20 16:30 GMT+09:00 Philipp Zabel <p.zabel@pengutronix.de>:
>> > Hi Masahiro,
>> >
>> > Am Dienstag, den 20.09.2016, 13:43 +0900 schrieb Masahiro Yamada:
>> >> The UniPhier reset driver (drivers/reset/reset-uniphier.c) has been
>> >> merged. Select ARCH_HAS_RESET_CONTROLLER from the SoC Kconfig.
>> >>
>> >> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
>> >> ---
>> >>
>> >> Philipp,
>> >>
>> >> IIRC, you mentioned that you were planning to consolidate the double
>> >> gurad by CONFIG_RESET_CONTROLLER and CONFIG_ARCH_HAS_RESET_CONTROLLER.
>> >>
>> >> I have not seen it in the ML, so I am sending this.
>> >>
>> >> Please let me know if you have some updates.
>> >
>> > I had started to doodle a bit, see
>> >
>> > git fetch git://git.pengutronix.de/git/pza/linux.git refs/heads/reset/kconfig
>> >
>> > but I haven't found time for cleanup and testing.
>>
>>
>> OK, I will merge this patch for now.
>>
>>
>>
>> BTW, I did not understand some of your commits under way.
>>
>>
>> commit 7fe911f9c83737449565db03bebf953d3d94bbbf
>> Author: Philipp Zabel <p.zabel@pengutronix.de>
>> Date: Tue Aug 9 11:18:51 2016 +0200
>>
>> dmaengine: sunx6i: do not depend on reset controller framework
>>
>> The reset controller framework provides inline function stubs if
>> disabled.
>>
>> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
>>
>>
>>
>>
>>
>> As far as I see from drivers/dma/sun6i-dma.c,
>> the reset control is mandatory for this driver.
>>
>> Why are you removing the dependency?
>>
>>
>> Don't you care if it works on run-time
>> as long as it can build?
>
> I have not thought about this too hard, it's just there because the
> reset framework is not a build dependency (anymore). Some patches were
> necessary to remove dependency loops, but I think this one could just be
> dropped.
I have not taken a close look at it, but
if "dependency loops" is the reason for the change,
please mention it in the git-log.
I do not think we should remove the "depends on"
only for the reason "inline function stubs are already provided".
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* [RFC PATCH 2/2] ARM: i.MX: dts: add fsl, imx25-wdt compatible to all relevant watchdog nodes
From: Baruch Siach @ 2016-09-26 4:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474850361-20884-3-git-send-email-vz@mleia.com>
Hi Vladimir,
On Mon, Sep 26, 2016 at 03:39:21AM +0300, Vladimir Zapolskiy wrote:
> Watchdog device controller found on all modern SoCs from i.MX series
> and firstly introduced in i.MX25 is not one in one compatible with the
> watchdog controllers on i.MX21, i.MX27 and i.MX31, the latter
> controlles don't have WICR (and pretimeout notification support) and
> WMCR registers. To get benefit from the more advanced watchdog device
> and to avoid operations over non-existing registers on legacy SoCs add
> fsl,imx25-wdt compatible to descriptions of all i.MX25 compatible
> watchdog controllers.
Maybe also update Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.txt?
In a separate patch.
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
^ permalink raw reply
* [PATCH v2 2/2] cpufreq: ti: Add cpufreq driver to determine available OPPs at runtime
From: Viresh Kumar @ 2016-09-26 4:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57E555B3.2010304@ti.com>
On 23-09-16, 11:17, Dave Gerlach wrote:
> On 09/23/2016 12:19 AM, Viresh Kumar wrote:
> >On 21-09-16, 14:34, Dave Gerlach wrote:
> >>Viresh,
> >>On 09/07/2016 10:39 PM, Viresh Kumar wrote:
> >>>On 07-09-16, 10:04, Dave Gerlach wrote:
> >>>>>>+static const struct of_device_id ti_cpufreq_of_match[] = {
> >>>>>>+ { .compatible = "operating-points-v2-ti-am3352-cpu",
> >>>>>>+ .data = &am3x_soc_data, },
> >>>>>>+ { .compatible = "operating-points-v2-ti-am4372-cpu",
> >>>>>>+ .data = &am4x_soc_data, },
> >>>>>>+ { .compatible = "operating-points-v2-ti-dra7-cpu",
> >>>>>>+ .data = &dra7_soc_data },
> >>>>>
> >>>>>You should be using your SoC compatible strings here. OPP compatible
> >>>>>property isn't supposed to be (mis)used for this purpose.
> >>>>>
> >>>>
> >>>>Referring to my comments in patch 1, what if we end up changing the bindings
> >>>>based on DT maintainer comments? We will have these compatible strings, and
> >>>>at that point is it acceptable to match against them? Or is it still better
> >>>>to match to SoC compatibles? I think it makes sense to just probe against
> >>>>these.
> >>>
> >>>But even then I think these are not correct. You should have added a
> >>>single compatible string: operating-points-v2-ti-cpu.
> >>>
> >>>As the properties will stay the same across machines. And then you
> >>>need to use SoC strings here.
> >>>
> >>
> >>Are you opposed to moving _of_get_opp_desc_node from
> >>drivers/base/power/opp/opp.h to include/linux/pm_opp.h and renaming it
> >>appropriately?
> >
> >I am not opposed to that, but ...
> >
> >>If I move the ti properties out of the cpu node, as discussed in patch 1 of
> >>this series, and into the operating-points-v2 table, I need a way to get the
> >>operating-points-v2 device node and I think it makes sense to reuse this as
> >>it is what the opp framework uses internally to parse the phandle to the opp
> >>table.
> >
> >I am not sure if those registers belong to the OPP bindings. What are those
> >registers really? What all can be read from them? Why shouldn't they be present
> >as a separate node in DT on the respective bus? Look at how it is done for
> >sti-cpufreq driver.
> >
>
> The sti-cpufreq driver in v4.8-rc7 appears to do what I am already doing in
> this revision of the patch, reading from a syscon phandle that is part of
> the cpu node in the DT which is what I was told not to do.
>
> The register I am referencing in the syscon is a bit-field describing which
> OPPs are valid for the system, so it is very relevant to the OPP binding.
> They really are already present in a separate node, I'm just indexing into a
> syscon, same as the sti-cpufreq driver appears to be doing.
Okay, you can move that function out.
--
viresh
^ permalink raw reply
* [PATCH v2 4/4] PM / AVS: rockchip-cpu-avs: add driver handling Rockchip cpu avs
From: Viresh Kumar @ 2016-09-26 3:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160912215515.GF7243@codeaurora.org>
On 12-09-16, 14:55, Stephen Boyd wrote:
> On 08/29, Viresh Kumar wrote:
> > On 18-08-16, 16:52, Finlye Xiao wrote:
> > > +static int rockchip_adjust_opp_table(struct device *cpu_dev,
> > > + struct cpufreq_frequency_table *table,
> > > + int volt)
> > > +{
> > > + struct opp_table *opp_table;
> > > + struct cpufreq_frequency_table *pos;
> > > + struct dev_pm_opp *opp;
> > > +
> > > + if (!volt)
> > > + return 0;
> > > +
> > > + rcu_read_lock();
> > > +
> > > + opp_table = _find_opp_table(cpu_dev);
> > > + if (IS_ERR(opp_table)) {
> > > + rcu_read_unlock();
> > > + return PTR_ERR(opp_table);
> > > + }
> > > +
> > > + cpufreq_for_each_valid_entry(pos, table) {
> > > + opp = dev_pm_opp_find_freq_exact(cpu_dev, pos->frequency * 1000,
> > > + true);
> > > + if (IS_ERR(opp))
> > > + continue;
> > > +
> > > + opp->u_volt += volt;
> > > + opp->u_volt_min += volt;
> > > + opp->u_volt_max += volt;
> > > + }
> > > +
> > > + rcu_read_unlock();
> > > +
> > > + return 0;
> > > +}
> >
> > I wouldn't prefer altering the opp tables from individual drivers at all. At the
> > least, it should be done via some helpers exposed by the core.
> >
> > But before that I would like to hear from Stephen a bit as I recall he was also
> > working on something similar.
> >
>
> I had a patch to modify the voltage at runtime for the "current"
> OPP. Now that we have regulator and clk control inside OPP that
> became a little easier to do without having to do some notifier
> from the OPP layer to the consumers. I haven't had time to revive
> those patches though. Should we do that?
Perhaps yes, we should have a common place for doing all that.
> Does this need to modify
> anything besides the OPP the device is currently running at?
Finlye, can you please answer this ?
--
viresh
^ permalink raw reply
* [PATCH] cpufreq: st: add missing \n to end of dev_err message
From: Viresh Kumar @ 2016-09-26 3:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160925214013.12430-1-colin.king@canonical.com>
On 25-09-16, 14:40, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> Trival fix, dev_err message is missing a \n, so add it.
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> ---
> drivers/cpufreq/sti-cpufreq.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/cpufreq/sti-cpufreq.c b/drivers/cpufreq/sti-cpufreq.c
> index 0404203..b366e6d 100644
> --- a/drivers/cpufreq/sti-cpufreq.c
> +++ b/drivers/cpufreq/sti-cpufreq.c
> @@ -163,7 +163,7 @@ static int sti_cpufreq_set_opp_info(void)
>
> reg_fields = sti_cpufreq_match();
> if (!reg_fields) {
> - dev_err(dev, "This SoC doesn't support voltage scaling");
> + dev_err(dev, "This SoC doesn't support voltage scaling\n");
> return -ENODEV;
> }
>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
--
viresh
^ permalink raw reply
* [PATCH -next] mmc: sdhci-of-arasan: Fix non static symbol warning
From: Sören Brinkmann @ 2016-09-26 3:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474818243-19207-1-git-send-email-weiyj.lk@gmail.com>
On Sun, 2016-09-25 at 15:44:03 +0000, Wei Yongjun wrote:
> From: Wei Yongjun <weiyongjun1@huawei.com>
>
> Fixes the following sparse warning:
>
> drivers/mmc/host/sdhci-of-arasan.c:253:6: warning:
> symbol 'sdhci_arasan_reset' was not declared. Should it be static?
>
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Acked-by: S?ren Brinkmann <soren.brinkmann@xilinx.com>
S?ren
^ permalink raw reply
* [RFC/PATCH] usb: misc: Add a driver for TC7USB40MU
From: Peter Chen @ 2016-09-26 3:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <147457026249.9057.8712383708019243942@sboyd-linaro>
On Thu, Sep 22, 2016 at 11:51:02AM -0700, Stephen Boyd wrote:
> Quoting Peter Chen (2016-09-16 18:16:05)
> > On Wed, Sep 14, 2016 at 01:55:02AM -0700, Stephen Boyd wrote:
> > > Quoting Stephen Boyd (2016-09-13 18:42:46)
> > > > On the db410c 96boards platform we have a TC7USB40MU[1] on the
> > > > board to mux the D+/D- lines from the SoC between a micro usb
> > > > "device" port and a USB hub for "host" roles. Upon a role switch,
> > > > we need to change this mux to forward the D+/D- lines to either
> > > > the port or the hub. Therefore, introduce a driver for this
> > > > device that intercepts extcon USB_HOST events and logically
> > > > asserts a gpio to mux the "host" D+/D- lines when a host cable is
> > > > attached. When the cable goes away, it will logically deassert
> > > > the gpio and mux the "device" lines.
> > > >
> > > > [1] https://toshiba.semicon-storage.com/ap-en/product/logic/bus-switch/detail.TC7USB40MU.html
> > > >
> > > > Cc: MyungJoo Ham <myungjoo.ham@samsung.com>
> > > > Cc: Chanwoo Choi <cw00.choi@samsung.com>
> > > > Cc: <devicetree@vger.kernel.org>
> > > > Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
> > > > ---
> > > >
> > > > Should I make the extcon part optional? I could see a case where there are two
> > > > "OTG" ports connected to the mux (or two hubs), and for some reason the
> > > > software may want to mux between them at runtime. If we mandate an extcon,
> > > > that won't be possible to support. Perhaps it would be better to have
> > > > the node, but connect it to the usb controller with a phandle (maybe of_graph
> > > > endpoints would be useful too) so that when the controller wants to mux over
> > > > a port it can do so.
> > >
> > > Here's some dts mock-up on top of the db410c for the of_graph stuff. I
> > > haven't written any code around it, but the idea is to allow the binding
> > > to specify how the mux is connected to upstream and downstream D+/D-
> > > lines. This way, we can do some dt parsing of the endpoints and their
> > > parent nodes to figure out if the mux needs to be set high or low to use
> > > a device connector or a usb hub based on if the id cable is present.
> > > Maybe I'm over thinking things though and we could just have a DT
> > > property for that.
> > >
> > > soc {
> > > usb at 78d9000 {
> > > extcon = <&usb_id>, <&usb_id>;
> >
> > Why you have two same extcon phandler? From my mind, one should id,
> > another should is vbus. Besides, I find extcon-usb-gpio.c is lack of
> > vbus support, how you support vbus detection for
> > connection/disconnection with PC for your chipidea msm patch set?
>
> This was already in the dts files for db410c. In the chipidea binding
> one is for EXTCON_USB (vbus) and one is for EXTCON_USB_HOST (id). My
> understanding is that extcon-usb-gpio.c sends events for both EXTCON_USB
> and EXTCON_USB_HOST when the gpio changes state. vbus detection is not
> that great on this board because we only have on gpio for this.
I think extcon-usb-gpio.c needs to extend for supporting vbus event,
otherwise, the micro-b cable's connect/disconnect will introduce
EXTCON_USB_HOST event, if you use two <&usb_idx> for both id and
vbus event.
--
Best Regards,
Peter Chen
^ permalink raw reply
* [v12, 0/8] Fix eSDHC host version register bug
From: Y.B. Lu @ 2016-09-26 3:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474441040-11946-1-git-send-email-yangbo.lu@nxp.com>
Any comments about this version patchset ?
:)
> -----Original Message-----
> From: Yangbo Lu [mailto:yangbo.lu at nxp.com]
> Sent: Wednesday, September 21, 2016 2:57 PM
> To: linux-mmc at vger.kernel.org; ulf.hansson at linaro.org; Scott Wood; Arnd
> Bergmann
> Cc: linuxppc-dev at lists.ozlabs.org; devicetree at vger.kernel.org; linux-arm-
> kernel at lists.infradead.org; linux-kernel at vger.kernel.org; linux-
> clk at vger.kernel.org; linux-i2c at vger.kernel.org; iommu at lists.linux-
> foundation.org; netdev at vger.kernel.org; Mark Rutland; Rob Herring;
> Russell King; Jochen Friedrich; Joerg Roedel; Claudiu Manoil; Bhupesh
> Sharma; Qiang Zhao; Kumar Gala; Santosh Shilimkar; Leo Li; X.B. Xie; M.H.
> Lian; Y.B. Lu
> Subject: [v12, 0/8] Fix eSDHC host version register bug
>
> This patchset is used to fix a host version register bug in the T4240-
> R1.0-R2.0 eSDHC controller. To match the SoC version and revision, 10
> previous version patchsets had tried many methods but all of them were
> rejected by reviewers.
> Such as
> - dts compatible method
> - syscon method
> - ifdef PPC method
> - GUTS driver getting SVR method
> Anrd suggested a soc_device_match method in v10, and this is the only
> available method left now. This v11 patchset introduces the
> soc_device_match interface in soc driver.
>
> The first six patches of Yangbo are to add the GUTS driver. This is used
> to register a soc device which contain soc version and revision
> information.
> The other two patches introduce the soc_device_match method in soc driver
> and apply it on esdhc driver to fix this bug.
>
> Arnd Bergmann (1):
> base: soc: introduce soc_device_match() interface
>
> Yangbo Lu (7):
> dt: bindings: update Freescale DCFG compatible
> ARM64: dts: ls2080a: add device configuration node
> dt: bindings: move guts devicetree doc out of powerpc directory
> powerpc/fsl: move mpc85xx.h to include/linux/fsl
> soc: fsl: add GUTS driver for QorIQ platforms
> MAINTAINERS: add entry for Freescale SoC drivers
> mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
>
> Documentation/devicetree/bindings/arm/fsl.txt | 6 +-
> .../bindings/{powerpc => soc}/fsl/guts.txt | 3 +
> MAINTAINERS | 11 +-
> arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 6 +
> arch/powerpc/kernel/cpu_setup_fsl_booke.S | 2 +-
> arch/powerpc/sysdev/fsl_pci.c | 2 +-
> drivers/base/Kconfig | 1 +
> drivers/base/soc.c | 66 ++++++
> drivers/clk/clk-qoriq.c | 3 +-
> drivers/i2c/busses/i2c-mpc.c | 2 +-
> drivers/iommu/fsl_pamu.c | 3 +-
> drivers/mmc/host/Kconfig | 1 +
> drivers/mmc/host/sdhci-of-esdhc.c | 20 ++
> drivers/net/ethernet/freescale/gianfar.c | 2 +-
> drivers/soc/Kconfig | 2 +-
> drivers/soc/fsl/Kconfig | 19 ++
> drivers/soc/fsl/Makefile | 1 +
> drivers/soc/fsl/guts.c | 257
> +++++++++++++++++++++
> include/linux/fsl/guts.h | 125 ++++++----
> .../asm/mpc85xx.h => include/linux/fsl/svr.h | 4 +-
> include/linux/sys_soc.h | 3 +
> 21 files changed, 478 insertions(+), 61 deletions(-) rename
> Documentation/devicetree/bindings/{powerpc => soc}/fsl/guts.txt (91%)
> create mode 100644 drivers/soc/fsl/Kconfig create mode 100644
> drivers/soc/fsl/guts.c rename arch/powerpc/include/asm/mpc85xx.h =>
> include/linux/fsl/svr.h (97%)
>
> --
> 2.1.0.27.g96db324
^ permalink raw reply
* [PATCH 4/4] arm/versatile: support configuring versatile machine for no-MMU
From: Greg Ungerer @ 2016-09-26 0:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474851150-12532-1-git-send-email-gerg@uclinux.org>
Allow the arm versatile machine to be configured for no-MMU operation.
The approach taken is similar to the support for no-MMU arm v7 machines.
A new define, CONFIG_ARM_SINGLE_ARMV5, is used to enable a class of v5
core based machines that are supported for building with !CONFIG_MMU.
Currently only the versatile machine is configured to support this.
Older kernels had the ability to build the versatile machine with the MMU
disabled (!CONFIG_MMU). Recent changes to convert the versatile machine
to device tree lost this ability. (Although older kernels could be built
they did not run due to a bug in the IO_ADDRESS() mapping on this machine).
The motivation for this is that the versatile machine is well supported
in qemu. And this provides an excellent platform for development and
testing no-MMU support on ARM in general.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
---
arch/arm/Kconfig | 10 ++++++++++
arch/arm/Kconfig.debug | 3 ++-
arch/arm/mach-versatile/Kconfig | 3 ++-
3 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index a9c4e48..f44fe7b 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -353,6 +353,16 @@ config ARM_SINGLE_ARMV7M
select SPARSE_IRQ
select USE_OF
+config ARM_SINGLE_ARMV5
+ bool "ARMv5 based platforms (ARM926T)"
+ depends on !MMU
+ select AUTO_ZRELADDR
+ select CLKSRC_OF
+ select COMMON_CLK
+ select GENERIC_CLOCKEVENTS
+ select SPARSE_IRQ
+ select USE_OF
+
config ARCH_GEMINI
bool "Cortina Systems Gemini"
select CLKSRC_MMIO
diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index a9693b6..9897348 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -1712,7 +1712,8 @@ config DEBUG_UNCOMPRESS
config UNCOMPRESS_INCLUDE
string
default "debug/uncompress.h" if ARCH_MULTIPLATFORM || ARCH_MSM || \
- PLAT_SAMSUNG || ARM_SINGLE_ARMV7M
+ PLAT_SAMSUNG || ARM_SINGLE_ARMV7M || \
+ ARM_SINGLE_ARMV5
default "mach/uncompress.h"
config EARLY_PRINTK
diff --git a/arch/arm/mach-versatile/Kconfig b/arch/arm/mach-versatile/Kconfig
index b0cc262..904a012 100644
--- a/arch/arm/mach-versatile/Kconfig
+++ b/arch/arm/mach-versatile/Kconfig
@@ -1,6 +1,6 @@
config ARCH_VERSATILE
bool "ARM Ltd. Versatile family"
- depends on ARCH_MULTI_V5
+ depends on ARCH_MULTI_V5 || ARM_SINGLE_ARMV5
select ARM_AMBA
select ARM_TIMER_SP804
select ARM_VIC
@@ -14,6 +14,7 @@ config ARCH_VERSATILE
select POWER_RESET
select POWER_RESET_VERSATILE
select VERSATILE_FPGA_IRQ
+ select GPIOLIB
help
This enables support for ARM Ltd Versatile board.
--
1.9.1
^ permalink raw reply related
* [PATCH 3/4] arm/versatile: empty Makefile.boot needed for no-MMU compile
From: Greg Ungerer @ 2016-09-26 0:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474851150-12532-1-git-send-email-gerg@uclinux.org>
To compile the arm versatile board with the MMU disabled (!CONFIG_MMU)
a Makefile.boot is required. Without it you get:
SYSMAP System.map
arch/arm/boot/Makefile:15: arch/arm/mach-versatile//Makefile.boot: No such file or directory
make[2]: *** No rule to make target `arch/arm/mach-versatile//Makefile.boot'. Stop.
Create an empty Makefile.boot for the versatile machine. This is a
copy of the other empty machine Makefile.boot files. (A few have this
same commented empty file: stm32, ep93xx, lpc18xx, efm32 and vexpress).
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
---
arch/arm/mach-versatile/Makefile.boot | 3 +++
1 file changed, 3 insertions(+)
create mode 100644 arch/arm/mach-versatile/Makefile.boot
diff --git a/arch/arm/mach-versatile/Makefile.boot b/arch/arm/mach-versatile/Makefile.boot
new file mode 100644
index 0000000..eacfc3f
--- /dev/null
+++ b/arch/arm/mach-versatile/Makefile.boot
@@ -0,0 +1,3 @@
+# Empty file waiting for deletion once Makefile.boot isn't needed any more.
+# Patch waits for application at
+# http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=7889/1 .
--
1.9.1
^ permalink raw reply related
* [PATCH 2/4] arm/versatile: define empty debug_ll_io_init() for no-MMU
From: Greg Ungerer @ 2016-09-26 0:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474851150-12532-1-git-send-email-gerg@uclinux.org>
No-MMU configured targets have no definition for debug_ll_io_init().
Not all machines use this and it will only be required if CONFIG_DEBUG_LL
is enabled.
But when compiling for a target that uses it and it is configured for
no-MMU (!CONFIG_MMU), for example the versatile machine, you will get:
CC arch/arm/mach-versatile/versatile_dt.o
arch/arm/mach-versatile/versatile_dt.c: In function ?versatile_map_io?:
arch/arm/mach-versatile/versatile_dt.c:283:2: error: implicit declaration of function ?debug_ll_io_init? [-Werror=implicit-function-declaration]
debug_ll_io_init();
^
Fix by adding a macro for it to the !CONFIG_MMU path in map.h.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
---
arch/arm/include/asm/mach/map.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/include/asm/mach/map.h b/arch/arm/include/asm/mach/map.h
index 9b7c328..b1fe9c8 100644
--- a/arch/arm/include/asm/mach/map.h
+++ b/arch/arm/include/asm/mach/map.h
@@ -62,6 +62,7 @@ extern int ioremap_page(unsigned long virt, unsigned long phys,
#else
#define iotable_init(map,num) do { } while (0)
#define vm_reserve_area_early(a,s,c) do { } while (0)
+#define debug_ll_io_init() do { } while (0)
#endif
#endif
--
1.9.1
^ permalink raw reply related
* [PATCH 1/4] arm/versatile: support no-MMU mode addressing
From: Greg Ungerer @ 2016-09-26 0:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474851150-12532-1-git-send-email-gerg@uclinux.org>
Currently for the versatile boards the IO_ADDRESS() macro applies static
virtual address mapping for built-in IO devices. When operating without
the MMU enabled IO devices are accessed at their physical address, no
address translation is required.
For the !CONFIG_MMU case then define the IO_ADDRESS() macro to return the
physical address.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
---
arch/arm/mach-versatile/versatile_dt.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/mach-versatile/versatile_dt.c b/arch/arm/mach-versatile/versatile_dt.c
index 3c8d39c..8cfa05a 100644
--- a/arch/arm/mach-versatile/versatile_dt.c
+++ b/arch/arm/mach-versatile/versatile_dt.c
@@ -37,7 +37,11 @@
#include <asm/mach/map.h>
/* macro to get at MMIO space when running virtually */
+#ifdef CONFIG_MMU
#define IO_ADDRESS(x) (((x) & 0x0fffffff) + (((x) >> 4) & 0x0f000000) + 0xf0000000)
+#else
+#define IO_ADDRESS(x) (x)
+#endif
#define __io_address(n) ((void __iomem __force *)IO_ADDRESS(n))
/*
--
1.9.1
^ permalink raw reply related
* [PATCH 0/4] arm/versatile: no-MMU support
From: Greg Ungerer @ 2016-09-26 0:52 UTC (permalink / raw)
To: linux-arm-kernel
The following patches support configuring and building the versatile
machine with a no-MMU kernel.
There is only a minor few changes required. It was previously possible
in older kernels to build for versatile with CONFIG_MMU disabled, but
the change to devicetree lost that capability. These changes make it
possible again.
One patch is a fix for address translation (broken on older kernels too),
two are build problems when CONFIG_MMU is disabled, and the last is the
actuall configuration changes needed.
The motivation for this is that the versatile machine is well supported
in qemu. And this provides an excellent platform for development and
testing no-MMU support on ARM in general. With these patches applied
it is possible to build and run a kernel with MMU disabled on qemu.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
---
arch/arm/Kconfig | 10 ++++++++++
arch/arm/Kconfig.debug | 3 ++-
arch/arm/include/asm/mach/map.h | 1 +
arch/arm/mach-versatile/Kconfig | 3 ++-
arch/arm/mach-versatile/Makefile.boot | 3 +++
arch/arm/mach-versatile/versatile_dt.c | 4 ++++
6 files changed, 22 insertions(+), 2 deletions(-)
^ permalink raw reply
* [RFC PATCH 2/2] ARM: i.MX: dts: add fsl, imx25-wdt compatible to all relevant watchdog nodes
From: Vladimir Zapolskiy @ 2016-09-26 0:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474850361-20884-1-git-send-email-vz@mleia.com>
Watchdog device controller found on all modern SoCs from i.MX series
and firstly introduced in i.MX25 is not one in one compatible with the
watchdog controllers on i.MX21, i.MX27 and i.MX31, the latter
controlles don't have WICR (and pretimeout notification support) and
WMCR registers. To get benefit from the more advanced watchdog device
and to avoid operations over non-existing registers on legacy SoCs add
fsl,imx25-wdt compatible to descriptions of all i.MX25 compatible
watchdog controllers.
Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
---
arch/arm/boot/dts/imx35.dtsi | 3 ++-
arch/arm/boot/dts/imx50.dtsi | 3 ++-
arch/arm/boot/dts/imx51.dtsi | 6 ++++--
arch/arm/boot/dts/imx53.dtsi | 6 ++++--
arch/arm/boot/dts/imx6qdl.dtsi | 6 ++++--
arch/arm/boot/dts/imx6sl.dtsi | 6 ++++--
arch/arm/boot/dts/imx6sx.dtsi | 9 ++++++---
arch/arm/boot/dts/imx6ul.dtsi | 6 ++++--
arch/arm/boot/dts/imx7s.dtsi | 12 ++++++++----
arch/arm/boot/dts/ls1021a.dtsi | 2 +-
arch/arm/boot/dts/vfxxx.dtsi | 3 ++-
11 files changed, 41 insertions(+), 21 deletions(-)
diff --git a/arch/arm/boot/dts/imx35.dtsi b/arch/arm/boot/dts/imx35.dtsi
index 490b7b4..8fd4482 100644
--- a/arch/arm/boot/dts/imx35.dtsi
+++ b/arch/arm/boot/dts/imx35.dtsi
@@ -284,7 +284,8 @@
};
wdog: wdog at 53fdc000 {
- compatible = "fsl,imx35-wdt", "fsl,imx21-wdt";
+ compatible = "fsl,imx35-wdt", "fsl,imx25-wdt",
+ "fsl,imx21-wdt";
reg = <0x53fdc000 0x4000>;
clocks = <&clks 74>;
clock-names = "";
diff --git a/arch/arm/boot/dts/imx50.dtsi b/arch/arm/boot/dts/imx50.dtsi
index e245713..5ba6d5a 100644
--- a/arch/arm/boot/dts/imx50.dtsi
+++ b/arch/arm/boot/dts/imx50.dtsi
@@ -260,7 +260,8 @@
};
wdog1: wdog at 53f98000 {
- compatible = "fsl,imx50-wdt", "fsl,imx21-wdt";
+ compatible = "fsl,imx50-wdt", "fsl,imx25-wdt",
+ "fsl,imx21-wdt";
reg = <0x53f98000 0x4000>;
interrupts = <58>;
clocks = <&clks IMX5_CLK_DUMMY>;
diff --git a/arch/arm/boot/dts/imx51.dtsi b/arch/arm/boot/dts/imx51.dtsi
index f46fe9b..d91f713 100644
--- a/arch/arm/boot/dts/imx51.dtsi
+++ b/arch/arm/boot/dts/imx51.dtsi
@@ -345,14 +345,16 @@
};
wdog1: wdog at 73f98000 {
- compatible = "fsl,imx51-wdt", "fsl,imx21-wdt";
+ compatible = "fsl,imx51-wdt", "fsl,imx25-wdt",
+ "fsl,imx21-wdt";
reg = <0x73f98000 0x4000>;
interrupts = <58>;
clocks = <&clks IMX5_CLK_DUMMY>;
};
wdog2: wdog at 73f9c000 {
- compatible = "fsl,imx51-wdt", "fsl,imx21-wdt";
+ compatible = "fsl,imx51-wdt", "fsl,imx25-wdt",
+ "fsl,imx21-wdt";
reg = <0x73f9c000 0x4000>;
interrupts = <59>;
clocks = <&clks IMX5_CLK_DUMMY>;
diff --git a/arch/arm/boot/dts/imx53.dtsi b/arch/arm/boot/dts/imx53.dtsi
index cd17037..c9edac2 100644
--- a/arch/arm/boot/dts/imx53.dtsi
+++ b/arch/arm/boot/dts/imx53.dtsi
@@ -390,14 +390,16 @@
};
wdog1: wdog at 53f98000 {
- compatible = "fsl,imx53-wdt", "fsl,imx21-wdt";
+ compatible = "fsl,imx53-wdt", "fsl,imx25-wdt",
+ "fsl,imx21-wdt";
reg = <0x53f98000 0x4000>;
interrupts = <58>;
clocks = <&clks IMX5_CLK_DUMMY>;
};
wdog2: wdog at 53f9c000 {
- compatible = "fsl,imx53-wdt", "fsl,imx21-wdt";
+ compatible = "fsl,imx53-wdt", "fsl,imx25-wdt",
+ "fsl,imx21-wdt";
reg = <0x53f9c000 0x4000>;
interrupts = <59>;
clocks = <&clks IMX5_CLK_DUMMY>;
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index b620ac8..d73edd7 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -593,14 +593,16 @@
};
wdog1: wdog at 020bc000 {
- compatible = "fsl,imx6q-wdt", "fsl,imx21-wdt";
+ compatible = "fsl,imx6q-wdt", "fsl,imx25-wdt",
+ "fsl,imx21-wdt";
reg = <0x020bc000 0x4000>;
interrupts = <0 80 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX6QDL_CLK_DUMMY>;
};
wdog2: wdog at 020c0000 {
- compatible = "fsl,imx6q-wdt", "fsl,imx21-wdt";
+ compatible = "fsl,imx6q-wdt", "fsl,imx25-wdt",
+ "fsl,imx21-wdt";
reg = <0x020c0000 0x4000>;
interrupts = <0 81 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX6QDL_CLK_DUMMY>;
diff --git a/arch/arm/boot/dts/imx6sl.dtsi b/arch/arm/boot/dts/imx6sl.dtsi
index 5425150..b8c71bd 100644
--- a/arch/arm/boot/dts/imx6sl.dtsi
+++ b/arch/arm/boot/dts/imx6sl.dtsi
@@ -430,14 +430,16 @@
};
wdog1: wdog at 020bc000 {
- compatible = "fsl,imx6sl-wdt", "fsl,imx21-wdt";
+ compatible = "fsl,imx6sl-wdt", "fsl,imx25-wdt",
+ "fsl,imx21-wdt";
reg = <0x020bc000 0x4000>;
interrupts = <0 80 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX6SL_CLK_DUMMY>;
};
wdog2: wdog at 020c0000 {
- compatible = "fsl,imx6sl-wdt", "fsl,imx21-wdt";
+ compatible = "fsl,imx6sl-wdt", "fsl,imx25-wdt",
+ "fsl,imx21-wdt";
reg = <0x020c0000 0x4000>;
interrupts = <0 81 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX6SL_CLK_DUMMY>;
diff --git a/arch/arm/boot/dts/imx6sx.dtsi b/arch/arm/boot/dts/imx6sx.dtsi
index 2863c52..2753c71 100644
--- a/arch/arm/boot/dts/imx6sx.dtsi
+++ b/arch/arm/boot/dts/imx6sx.dtsi
@@ -515,14 +515,16 @@
};
wdog1: wdog at 020bc000 {
- compatible = "fsl,imx6sx-wdt", "fsl,imx21-wdt";
+ compatible = "fsl,imx6sx-wdt", "fsl,imx25-wdt",
+ "fsl,imx21-wdt";
reg = <0x020bc000 0x4000>;
interrupts = <GIC_SPI 80 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX6SX_CLK_DUMMY>;
};
wdog2: wdog at 020c0000 {
- compatible = "fsl,imx6sx-wdt", "fsl,imx21-wdt";
+ compatible = "fsl,imx6sx-wdt", "fsl,imx25-wdt",
+ "fsl,imx21-wdt";
reg = <0x020c0000 0x4000>;
interrupts = <GIC_SPI 81 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX6SX_CLK_DUMMY>;
@@ -1178,7 +1180,8 @@
};
wdog3: wdog at 02288000 {
- compatible = "fsl,imx6sx-wdt", "fsl,imx21-wdt";
+ compatible = "fsl,imx6sx-wdt", "fsl,imx25-wdt",
+ "fsl,imx21-wdt";
reg = <0x02288000 0x4000>;
interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX6SX_CLK_DUMMY>;
diff --git a/arch/arm/boot/dts/imx6ul.dtsi b/arch/arm/boot/dts/imx6ul.dtsi
index 33b95d7..fb0373f 100644
--- a/arch/arm/boot/dts/imx6ul.dtsi
+++ b/arch/arm/boot/dts/imx6ul.dtsi
@@ -483,14 +483,16 @@
};
wdog1: wdog at 020bc000 {
- compatible = "fsl,imx6ul-wdt", "fsl,imx21-wdt";
+ compatible = "fsl,imx6ul-wdt", "fsl,imx25-wdt",
+ "fsl,imx21-wdt";
reg = <0x020bc000 0x4000>;
interrupts = <GIC_SPI 80 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX6UL_CLK_WDOG1>;
};
wdog2: wdog at 020c0000 {
- compatible = "fsl,imx6ul-wdt", "fsl,imx21-wdt";
+ compatible = "fsl,imx6ul-wdt", "fsl,imx25-wdt",
+ "fsl,imx21-wdt";
reg = <0x020c0000 0x4000>;
interrupts = <GIC_SPI 81 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX6UL_CLK_WDOG2>;
diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
index 1e90bdb..e7c047e 100644
--- a/arch/arm/boot/dts/imx7s.dtsi
+++ b/arch/arm/boot/dts/imx7s.dtsi
@@ -394,14 +394,16 @@
};
wdog1: wdog at 30280000 {
- compatible = "fsl,imx7d-wdt", "fsl,imx21-wdt";
+ compatible = "fsl,imx7d-wdt", "fsl,imx25-wdt",
+ "fsl,imx21-wdt";
reg = <0x30280000 0x10000>;
interrupts = <GIC_SPI 78 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX7D_WDOG1_ROOT_CLK>;
};
wdog2: wdog at 30290000 {
- compatible = "fsl,imx7d-wdt", "fsl,imx21-wdt";
+ compatible = "fsl,imx7d-wdt", "fsl,imx25-wdt",
+ "fsl,imx21-wdt";
reg = <0x30290000 0x10000>;
interrupts = <GIC_SPI 79 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX7D_WDOG2_ROOT_CLK>;
@@ -409,7 +411,8 @@
};
wdog3: wdog at 302a0000 {
- compatible = "fsl,imx7d-wdt", "fsl,imx21-wdt";
+ compatible = "fsl,imx7d-wdt", "fsl,imx25-wdt",
+ "fsl,imx21-wdt";
reg = <0x302a0000 0x10000>;
interrupts = <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX7D_WDOG3_ROOT_CLK>;
@@ -417,7 +420,8 @@
};
wdog4: wdog at 302b0000 {
- compatible = "fsl,imx7d-wdt", "fsl,imx21-wdt";
+ compatible = "fsl,imx7d-wdt", "fsl,imx25-wdt",
+ "fsl,imx21-wdt";
reg = <0x302b0000 0x10000>;
interrupts = <GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX7D_WDOG4_ROOT_CLK>;
diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
index 368e219..7e36fd8 100644
--- a/arch/arm/boot/dts/ls1021a.dtsi
+++ b/arch/arm/boot/dts/ls1021a.dtsi
@@ -441,7 +441,7 @@
};
wdog0: watchdog at 2ad0000 {
- compatible = "fsl,imx21-wdt";
+ compatible = "fsl,imx25-wdt", "fsl,imx21-wdt";
reg = <0x0 0x2ad0000 0x0 0x10000>;
interrupts = <GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&platform_clk 1>;
diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
index 2c13ec6..35f32ed 100644
--- a/arch/arm/boot/dts/vfxxx.dtsi
+++ b/arch/arm/boot/dts/vfxxx.dtsi
@@ -320,7 +320,8 @@
};
wdoga5: wdog at 4003e000 {
- compatible = "fsl,vf610-wdt", "fsl,imx21-wdt";
+ compatible = "fsl,vf610-wdt", "fsl,imx25-wdt",
+ "fsl,imx21-wdt";
reg = <0x4003e000 0x1000>;
interrupts = <20 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks VF610_CLK_WDT>;
--
2.8.1
^ permalink raw reply related
* [RFC PATCH 1/2] watchdog: imx2: fix hang-up on boot for i.MX21, i.MX27 and i.MX31 SoCs
From: Vladimir Zapolskiy @ 2016-09-26 0:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474850361-20884-1-git-send-email-vz@mleia.com>
Power down counter enable/disable bit switch is located in WMCR
register, but watchdog controllers found on legacy i.MX21, i.MX27 and
i.MX31 SoCs don't have this register. As a result of writing data to
the non-existing register on driver probe the SoC hangs up, to fix the
problem add more OF compatible strings and on this basis get
information about availability of the WMCR register.
Fixes: 5fe65ce7ccbb ("watchdog: imx2_wdt: Disable power down counter on boot")
Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
---
drivers/watchdog/imx2_wdt.c | 47 +++++++++++++++++++++++++++++++++++++++++++--
1 file changed, 45 insertions(+), 2 deletions(-)
diff --git a/drivers/watchdog/imx2_wdt.c b/drivers/watchdog/imx2_wdt.c
index 62f346b..b6763e0 100644
--- a/drivers/watchdog/imx2_wdt.c
+++ b/drivers/watchdog/imx2_wdt.c
@@ -29,6 +29,7 @@
#include <linux/module.h>
#include <linux/moduleparam.h>
#include <linux/of_address.h>
+#include <linux/of_device.h>
#include <linux/platform_device.h>
#include <linux/regmap.h>
#include <linux/watchdog.h>
@@ -57,6 +58,10 @@
#define WDOG_SEC_TO_COUNT(s) ((s * 2 - 1) << 8)
+struct imx2_wdt_data {
+ bool has_pdc;
+};
+
struct imx2_wdt_device {
struct clk *clk;
struct regmap *regmap;
@@ -64,6 +69,8 @@ struct imx2_wdt_device {
bool ext_reset;
};
+static const struct of_device_id imx2_wdt_dt_ids[];
+
static bool nowayout = WATCHDOG_NOWAYOUT;
module_param(nowayout, bool, 0);
MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started (default="
@@ -200,10 +207,13 @@ static const struct regmap_config imx2_wdt_regmap_config = {
static int __init imx2_wdt_probe(struct platform_device *pdev)
{
+ const struct of_device_id *of_id;
+ const struct imx2_wdt_data *data;
struct imx2_wdt_device *wdev;
struct watchdog_device *wdog;
struct resource *res;
void __iomem *base;
+ bool has_pdc;
int ret;
u32 val;
@@ -261,12 +271,24 @@ static int __init imx2_wdt_probe(struct platform_device *pdev)
set_bit(WDOG_HW_RUNNING, &wdog->status);
}
+ if (pdev->dev.of_node) {
+ of_id = of_match_device(imx2_wdt_dt_ids, &pdev->dev);
+ if (!of_id)
+ return -ENODEV;
+
+ data = of_id->data;
+ has_pdc = data->has_pdc;
+ } else {
+ has_pdc = false;
+ }
+
/*
* Disable the watchdog power down counter at boot. Otherwise the power
* down counter will pull down the #WDOG interrupt line for one clock
* cycle.
*/
- regmap_write(wdev->regmap, IMX2_WDT_WMCR, 0);
+ if (has_pdc)
+ regmap_write(wdev->regmap, IMX2_WDT_WMCR, 0);
ret = watchdog_register_device(wdog);
if (ret) {
@@ -363,8 +385,29 @@ static int imx2_wdt_resume(struct device *dev)
static SIMPLE_DEV_PM_OPS(imx2_wdt_pm_ops, imx2_wdt_suspend,
imx2_wdt_resume);
+static const struct imx2_wdt_data imx21_wdt_data = {
+ .has_pdc = false,
+};
+
+static const struct imx2_wdt_data imx25_wdt_data = {
+ .has_pdc = true,
+};
+
static const struct of_device_id imx2_wdt_dt_ids[] = {
- { .compatible = "fsl,imx21-wdt", },
+ { .compatible = "fsl,imx21-wdt", .data = &imx21_wdt_data },
+ { .compatible = "fsl,imx25-wdt", .data = &imx25_wdt_data },
+ { .compatible = "fsl,imx27-wdt", .data = &imx21_wdt_data },
+ { .compatible = "fsl,imx31-wdt", .data = &imx21_wdt_data },
+ { .compatible = "fsl,imx35-wdt", .data = &imx25_wdt_data },
+ { .compatible = "fsl,imx50-wdt", .data = &imx25_wdt_data },
+ { .compatible = "fsl,imx51-wdt", .data = &imx25_wdt_data },
+ { .compatible = "fsl,imx53-wdt", .data = &imx25_wdt_data },
+ { .compatible = "fsl,imx6q-wdt", .data = &imx25_wdt_data },
+ { .compatible = "fsl,imx6sl-wdt", .data = &imx25_wdt_data },
+ { .compatible = "fsl,imx6sx-wdt", .data = &imx25_wdt_data },
+ { .compatible = "fsl,imx6ul-wdt", .data = &imx25_wdt_data },
+ { .compatible = "fsl,imx7d-wdt", .data = &imx25_wdt_data },
+ { .compatible = "fsl,vf610-wdt", .data = &imx25_wdt_data },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, imx2_wdt_dt_ids);
--
2.8.1
^ permalink raw reply related
* [RFC PATCH 0/2] watchdog: imx2+: fix hangup during watchdog initialization
From: Vladimir Zapolskiy @ 2016-09-26 0:39 UTC (permalink / raw)
To: linux-arm-kernel
It was discovered that the current version of imx2+ watchdog driver
does not work properly on i.MX31 boards and due to the same root
cause the kernel should not work on i.MX21 and i.MX27 powered boards,
if watchdog device driver is probed.
The root cause is that the watchdog controller on all modern SoCs from
i.MX series has two more registers in comparison to the watchdog on
i.MX21, i.MX27 and i.MX31, thus write access to the non-existing
register by the driver probe function causes a core hang.
The commit which caused a regression is 5fe65ce7ccbb ("watchdog:
imx2_wdt: Disable power down counter on boot"), for me it's hard
to say if this change is utterly needed or not (e.g. if it is done
in a bootloader), but it seems to be valid for modern i.MX SoCs.
The solution introduces a runtime difference between i.MX21 and i.MX25
compatible watchdog controllers, also this is reflected in the
updated DTS files.
The change is an RFC, because
* it is based on v4.8-rc1 and it will be rebased after getting review
comments,
* the selection of compatible watchdog controllers is partially done
on RMs, but I don't have access to all of them,
* the change fixes legacy boards (prior to DT support), but the fix is
excessive in sense that WMCR register won't be set on them, to cover
this case I feel reluctant to add a new header with platform data
structure declaration for legacy boards, but comments are welcome
* I don't know if a complete list of watchdog compatibles (which is
expected to be growing with time) is wanted in the driver code,
* if the DT change from the series is added, then only a check for
fsl,imx25-wdt compatible migth be good enough, but this will
nullify "disable power down counter" change for boards with
not updated DTBs.
* note that ls1021a.dtsi does not have its named watchdog compatible,
I know that Rob insists on adding SoC-named compatibles for
controllers, this may help in situations like this one, other
opinions or discussion or fix for LS1021A is welcome.
Vladimir Zapolskiy (2):
watchdog: imx2: fix hang-up on boot for i.MX21, i.MX27 and i.MX31 SoCs
ARM: i.MX: dts: add fsl,imx25-wdt compatible to all relevant watchdog nodes
arch/arm/boot/dts/imx35.dtsi | 3 ++-
arch/arm/boot/dts/imx50.dtsi | 3 ++-
arch/arm/boot/dts/imx51.dtsi | 6 ++++--
arch/arm/boot/dts/imx53.dtsi | 6 ++++--
arch/arm/boot/dts/imx6qdl.dtsi | 6 ++++--
arch/arm/boot/dts/imx6sl.dtsi | 6 ++++--
arch/arm/boot/dts/imx6sx.dtsi | 9 +++++---
arch/arm/boot/dts/imx6ul.dtsi | 6 ++++--
arch/arm/boot/dts/imx7s.dtsi | 12 +++++++----
arch/arm/boot/dts/ls1021a.dtsi | 2 +-
arch/arm/boot/dts/vfxxx.dtsi | 3 ++-
drivers/watchdog/imx2_wdt.c | 47 ++++++++++++++++++++++++++++++++++++++++--
12 files changed, 86 insertions(+), 23 deletions(-)
--
2.8.1
^ permalink raw reply
* [PATCH v2 4/4] ARM: clk: imx31: properly init clocks for machines with DT
From: Vladimir Zapolskiy @ 2016-09-26 0:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474848223-19728-1-git-send-email-vz@mleia.com>
Clock initialization for i.MX31 powered machines with DT support
should be done by a call of an init function registered with
CLK_OF_DECLARE() in common clock framework.
The change converts exported mx31_clocks_init_dt() into a static
initialization function registered by CLK_OF_DECLARE().
Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
---
Changes from v1 to v2:
* this change is a squashed change of arch/arm and clk changes,
if only one of two changes is applied there is a compilation
time or runtime issue.
arch/arm/mach-imx/common.h | 1 -
arch/arm/mach-imx/imx31-dt.c | 6 ------
drivers/clk/imx/clk-imx31.c | 50 +++++++++++++++++++++++---------------------
3 files changed, 26 insertions(+), 31 deletions(-)
diff --git a/arch/arm/mach-imx/common.h b/arch/arm/mach-imx/common.h
index a8f4693..e97d8cb 100644
--- a/arch/arm/mach-imx/common.h
+++ b/arch/arm/mach-imx/common.h
@@ -48,7 +48,6 @@ int mx21_clocks_init(unsigned long lref, unsigned long fref);
int mx27_clocks_init(unsigned long fref);
int mx31_clocks_init(unsigned long fref);
int mx35_clocks_init(void);
-int mx31_clocks_init_dt(void);
struct platform_device *mxc_register_gpio(char *name, int id,
resource_size_t iobase, resource_size_t iosize, int irq, int irq_high);
void mxc_set_cpu_type(unsigned int type);
diff --git a/arch/arm/mach-imx/imx31-dt.c b/arch/arm/mach-imx/imx31-dt.c
index 62e6b4f..668d74b 100644
--- a/arch/arm/mach-imx/imx31-dt.c
+++ b/arch/arm/mach-imx/imx31-dt.c
@@ -23,11 +23,6 @@ static const char * const imx31_dt_board_compat[] __initconst = {
NULL
};
-static void __init imx31_dt_timer_init(void)
-{
- mx31_clocks_init_dt();
-}
-
/* FIXME: replace with DT binding */
static const struct resource imx31_rnga_res[] __initconst = {
DEFINE_RES_MEM(MX31_RNGA_BASE_ADDR, SZ_16K),
@@ -43,7 +38,6 @@ DT_MACHINE_START(IMX31_DT, "Freescale i.MX31 (Device Tree Support)")
.map_io = mx31_map_io,
.init_early = imx31_init_early,
.init_irq = mx31_init_irq,
- .init_time = imx31_dt_timer_init,
.init_machine = imx31_dt_mach_init,
.dt_compat = imx31_dt_board_compat,
MACHINE_END
diff --git a/drivers/clk/imx/clk-imx31.c b/drivers/clk/imx/clk-imx31.c
index 6a49ba2..cbce308 100644
--- a/drivers/clk/imx/clk-imx31.c
+++ b/drivers/clk/imx/clk-imx31.c
@@ -21,6 +21,7 @@
#include <linux/io.h>
#include <linux/err.h>
#include <linux/of.h>
+#include <linux/of_address.h>
#include <soc/imx/revision.h>
#include <soc/imx/timer.h>
#include <asm/irq.h>
@@ -72,14 +73,8 @@ static struct clk ** const uart_clks[] __initconst = {
NULL
};
-static void __init _mx31_clocks_init(unsigned long fref)
+static void __init _mx31_clocks_init(void __iomem *base, unsigned long fref)
{
- void __iomem *base;
- struct device_node *np;
-
- base = ioremap(MX31_CCM_BASE_ADDR, SZ_4K);
- BUG_ON(!base);
-
clk[dummy] = imx_clk_fixed("dummy", 0);
clk[ckih] = imx_clk_fixed("ckih", fref);
clk[ckil] = imx_clk_fixed("ckil", 32768);
@@ -147,19 +142,17 @@ static void __init _mx31_clocks_init(unsigned long fref)
clk_prepare_enable(clk[iim_gate]);
mx31_revision();
clk_disable_unprepare(clk[iim_gate]);
-
- np = of_find_compatible_node(NULL, NULL, "fsl,imx31-ccm");
-
- if (np) {
- clk_data.clks = clk;
- clk_data.clk_num = ARRAY_SIZE(clk);
- of_clk_add_provider(np, of_clk_src_onecell_get, &clk_data);
- }
}
int __init mx31_clocks_init(unsigned long fref)
{
- _mx31_clocks_init(fref);
+ void __iomem *base;
+
+ base = ioremap(MX31_CCM_BASE_ADDR, SZ_4K);
+ if (!base)
+ panic("%s: failed to map registers\n", __func__);
+
+ _mx31_clocks_init(base, fref);
clk_register_clkdev(clk[gpt_gate], "per", "imx-gpt.0");
clk_register_clkdev(clk[ipg], "ipg", "imx-gpt.0");
@@ -222,22 +215,31 @@ int __init mx31_clocks_init(unsigned long fref)
return 0;
}
-int __init mx31_clocks_init_dt(void)
+static void __init mx31_clocks_init_dt(struct device_node *np)
{
- struct device_node *np;
+ struct device_node *osc_np;
u32 fref = 26000000; /* default */
+ void __iomem *ccm;
- for_each_compatible_node(np, NULL, "fixed-clock") {
- if (!of_device_is_compatible(np, "fsl,imx-osc26m"))
+ for_each_compatible_node(osc_np, NULL, "fixed-clock") {
+ if (!of_device_is_compatible(osc_np, "fsl,imx-osc26m"))
continue;
- if (!of_property_read_u32(np, "clock-frequency", &fref)) {
- of_node_put(np);
+ if (!of_property_read_u32(osc_np, "clock-frequency", &fref)) {
+ of_node_put(osc_np);
break;
}
}
- _mx31_clocks_init(fref);
+ ccm = of_iomap(np, 0);
+ if (!ccm)
+ panic("%s: failed to map registers\n", __func__);
- return 0;
+ _mx31_clocks_init(ccm, fref);
+
+ clk_data.clks = clk;
+ clk_data.clk_num = ARRAY_SIZE(clk);
+ of_clk_add_provider(np, of_clk_src_onecell_get, &clk_data);
}
+
+CLK_OF_DECLARE(imx31_ccm, "fsl,imx31-ccm", mx31_clocks_init_dt);
--
2.8.1
^ permalink raw reply related
* [PATCH v2 3/4] clk: imx31: fix rewritten input argument of mx31_clocks_init()
From: Vladimir Zapolskiy @ 2016-09-26 0:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474848223-19728-1-git-send-email-vz@mleia.com>
Function mx31_clocks_init() is called during clock intialization on
legacy boards with reference clock frequency passed as its input
argument, this can be verified by examination of the function
declaration found in arch/arm/mach-imx/common.h and actual function
users which include that header file.
Inside CCF driver the function ignores its input argument, by chance
the used value in the function body is the same as input arguments on
side of all callers.
Fixes: d9388c843237 ("clk: imx31: Do not call mxc_timer_init twice when booting with DT")
Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
---
Changes from v1 to v2:
* reworded commit message, thanks to Uwe for review
drivers/clk/imx/clk-imx31.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/clk/imx/clk-imx31.c b/drivers/clk/imx/clk-imx31.c
index 6a96414..6a49ba2 100644
--- a/drivers/clk/imx/clk-imx31.c
+++ b/drivers/clk/imx/clk-imx31.c
@@ -157,10 +157,8 @@ static void __init _mx31_clocks_init(unsigned long fref)
}
}
-int __init mx31_clocks_init(void)
+int __init mx31_clocks_init(unsigned long fref)
{
- u32 fref = 26000000; /* default */
-
_mx31_clocks_init(fref);
clk_register_clkdev(clk[gpt_gate], "per", "imx-gpt.0");
--
2.8.1
^ permalink raw reply related
* [PATCH v2 2/4] ARM: dts: imx31: move CCM device node to AIPS2 bus devices
From: Vladimir Zapolskiy @ 2016-09-26 0:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474848223-19728-1-git-send-email-vz@mleia.com>
i.MX31 Clock Control Module controller is found on AIPS2 bus, move it
there from SPBA bus to avoid a conflict of device IO space mismatch.
Fixes: ef0e4a606fb6 ("ARM: mx31: Replace clk_register_clkdev with clock DT lookup")
Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
---
Changes from v1 to v2:
* new change in the series
arch/arm/boot/dts/imx31.dtsi | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/arm/boot/dts/imx31.dtsi b/arch/arm/boot/dts/imx31.dtsi
index 3e0893e..8d4c0e3 100644
--- a/arch/arm/boot/dts/imx31.dtsi
+++ b/arch/arm/boot/dts/imx31.dtsi
@@ -118,13 +118,6 @@
interrupts = <19>;
clocks = <&clks 25>;
};
-
- clks: ccm at 53f80000{
- compatible = "fsl,imx31-ccm";
- reg = <0x53f80000 0x4000>;
- interrupts = <31>, <53>;
- #clock-cells = <1>;
- };
};
aips at 53f00000 { /* AIPS2 */
@@ -134,6 +127,13 @@
reg = <0x53f00000 0x100000>;
ranges;
+ clks: ccm at 53f80000{
+ compatible = "fsl,imx31-ccm";
+ reg = <0x53f80000 0x4000>;
+ interrupts = <31>, <53>;
+ #clock-cells = <1>;
+ };
+
gpt: timer at 53f90000 {
compatible = "fsl,imx31-gpt";
reg = <0x53f90000 0x4000>;
--
2.8.1
^ permalink raw reply related
* [PATCH v2 1/4] ARM: dts: imx31: fix clock control module interrupts description
From: Vladimir Zapolskiy @ 2016-09-26 0:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474848223-19728-1-git-send-email-vz@mleia.com>
The type of AVIC interrupt controller found on i.MX31 is one-cell,
namely 31 for CCM DVFS and 53 for CCM, however for clock control
module its interrupts are specified as 3-cells, fix it.
Fixes: ef0e4a606fb6 ("ARM: mx31: Replace clk_register_clkdev with clock DT lookup")
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
---
Changes from v1 to v2:
* added Rob's Acked-by tag.
Documentation/devicetree/bindings/clock/imx31-clock.txt | 2 +-
arch/arm/boot/dts/imx31.dtsi | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/clock/imx31-clock.txt b/Documentation/devicetree/bindings/clock/imx31-clock.txt
index 19df842..8163d56 100644
--- a/Documentation/devicetree/bindings/clock/imx31-clock.txt
+++ b/Documentation/devicetree/bindings/clock/imx31-clock.txt
@@ -77,7 +77,7 @@ Examples:
clks: ccm at 53f80000{
compatible = "fsl,imx31-ccm";
reg = <0x53f80000 0x4000>;
- interrupts = <0 31 0x04 0 53 0x04>;
+ interrupts = <31>, <53>;
#clock-cells = <1>;
};
diff --git a/arch/arm/boot/dts/imx31.dtsi b/arch/arm/boot/dts/imx31.dtsi
index 1ce7ae9..3e0893e 100644
--- a/arch/arm/boot/dts/imx31.dtsi
+++ b/arch/arm/boot/dts/imx31.dtsi
@@ -122,7 +122,7 @@
clks: ccm at 53f80000{
compatible = "fsl,imx31-ccm";
reg = <0x53f80000 0x4000>;
- interrupts = <0 31 0x04 0 53 0x04>;
+ interrupts = <31>, <53>;
#clock-cells = <1>;
};
};
--
2.8.1
^ permalink raw reply related
* [PATCH v2 0/4] ARM: imx31: clock initialization fixes
From: Vladimir Zapolskiy @ 2016-09-26 0:03 UTC (permalink / raw)
To: linux-arm-kernel
The change is tested on qemu kzm target and mx31lite board, while both
targets don't have DTS in upstream, I had to write simple DTS files for
them, because the proposed change is for i.MX31 targets with OF support.
i.MX31/OF/clock initialization seems to be broken currently, if
the series is not applied I can not get a working clock source during
early boot stage on a board with DTB supplied.
Changes from v1 to v2, thanks to Uwe and Stephen for review:
* added one more new fix in imx31.dtsi which moves CCM device node
to AIPS2 bus,
* included to the series a fix of CCM interrupts in imx31.dtsi,
the change was sent as a separate patch, the change is included
to avoid a patch application dependency,
* as suggested by Uwe reworded one of the commits removing "stack
corruption" mentioning, the overwritten value is passed in a register,
* as suggested by Uwe squashed clk-imx31.c and imx31-dt.c changes
to avoid a runtime problem if only one of two patches are applied
Vladimir Zapolskiy (4):
ARM: dts: imx31: fix clock control module interrupts description
ARM: dts: imx31: move CCM device node to AIPS2 bus devices
clk: imx31: fix rewritten input argument of mx31_clocks_init()
ARM: clk: imx31: properly init clocks for machines with DT
.../devicetree/bindings/clock/imx31-clock.txt | 2 +-
arch/arm/boot/dts/imx31.dtsi | 14 +++---
arch/arm/mach-imx/common.h | 1 -
arch/arm/mach-imx/imx31-dt.c | 6 ---
drivers/clk/imx/clk-imx31.c | 52 +++++++++++-----------
5 files changed, 34 insertions(+), 41 deletions(-)
--
2.8.1
^ permalink raw reply
* [PATCH 1/2] clk: rockchip: add I2S internal clock IDs for rk3288
From: Heiko Stuebner @ 2016-09-25 21:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160907191823.7f955ae2.john@metanate.com>
Hi John,
sorry this took so long,
Am Mittwoch, 7. September 2016, 19:18:23 CEST schrieb John Keeping:
> On Wed, 07 Sep 2016 19:58:31 +0200, Heiko Stuebner wrote:
> > Am Mittwoch, 7. September 2016, 17:53:29 CEST schrieb John Keeping:
> > > To minimize jitter on the I2S clocks, it is important that the
> > > denominator in the fractional divider is much greater than the
> > > numerator. Add identifiers for these internal clocks so that the
> > > specific clock topology and rates can be specified in the device tree.
> >
> > The TRM states that the denominator must be bigger than 20. Is this the
> > one
> > you found or did you find further constraints?
>
> Is it not that the denominator must be bigger than 20 times the
> numerator? That's what we found, although it seems that the greater the
> divisor the better, so our aim is dividing down from 594MHz from GPLL to
> the target rate in i2s_frac.
That is good to know ... the TRM probably lost the real information during
translation or so and only states that hard value. Looking at the rk3368 TRM
just now, the value really is 20 times greater than the numerator.
> > Did you try teaching the fractional divider to handle these constraints
> > before going this way?
>
> No, I hadn't looked at doing that. I'm not sure how that would work,
> we'd need to add support for fractional divider changing the parent rate
> wouldn't we?
Doug had a somewhat similar problem, mentioning the lack of a "bestdiv"
equivalent that the standard divider provides. I'm not sure if there isn't a
way to provide something like this and/or make the fractional clock honor
specific requirments concerning numerator/denominator - any mathematicians
around? :-)
One could also replace the generic fraction divider use with a rockchip-
specific implementation that somehow handles that.
> > Exporting the internal clocks really would be sort of plan d or e, after
> > handling this in the clock framework failed. Especially as i2s rates are
> > probably dependant on the media being handled (frequencies and such), so
> > setting fractional rates statically in the dts won't help you much in the
> > general case, as any new playback could trigger a clk_set_rate call
> > anyway?
>
> We're not setting the fractional rate specifically, instead we're
> setting the i2s_pre rate and parent explicitly and banning the i2s_src
> mux setting to i2s_pre, which means that clk_set_rate on sclk_i2s0 will
> always change i2s_frac but leave i2s_pre alone.
But then you are again in the situation where some requested rate can ignore
those fractional-divider constraints? In general I really don't like encoding
such board-specific behaviour into the generic clock tree, like needing to
disable parent relationships.
It works for your board now but does not necessarily for all other boards,
which might require other "hacks" and also doesn't solve the general problem
for all other fractional dividers we have.
Heiko
^ 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