* [PATCH] Adding basic support for the INet-97F_Rev_02 board
From: David Lanzendörfer @ 2014-02-07 14:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52F4E83A.1060109@redhat.com>
Hi Hans
> Thanks for the patch, I've added it to my sunxi-devel tree.
Great!
> It seems this has been missed by Maxime, because you did not send it
> directly to him. Can you please rebase it one 3.14-rc1, and then send it
> directly to Maxime Ripard, with the relevant mailinglists in the CC?
Yes. I can and I will.
cheers
David
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140207/119b5cbd/attachment.sig>
^ permalink raw reply
* [PATCH] Adding basic support for the INet-97F_Rev_02 board
From: Hans de Goede @ 2014-02-07 14:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9275469.c2bJ2hMSsV@dizzy-6.o2s.ch>
Hi David,
Thanks for the patch, I've added it to my sunxi-devel tree.
It seems this has been missed by Maxime, because you did not send it directly
to him. Can you please rebase it one 3.14-rc1, and then send it directly to
Maxime Ripard, with the relevant mailinglists in the CC?
Thanks & Regards,
Hans
On 01/23/2014 08:38 PM, David Lanzend?rfer wrote:
> This patch adds basic support for the INet-97F_Rev_02 board found in various
> low cost consumer tablet devices (http://linux-sunxi.org/INet-97F_Rev_02)
>
> Signed-off-by: David Lanzend?rfer <david.lanzendoerfer@o2s.ch>
> ---
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/sun4i-a10-inet97fv2.dts | 106
> ++++++++++++++++++++++++++++++
> 2 files changed, 107 insertions(+)
> create mode 100644 arch/arm/boot/dts/sun4i-a10-inet97fv2.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index b663ed7..57ec008 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -253,6 +253,7 @@ dtb-$(CONFIG_ARCH_SUNXI) += \
> sun4i-a10-cubieboard.dtb \
> sun4i-a10-mini-xplus.dtb \
> sun4i-a10-hackberry.dtb \
> + sun4i-a10-inet97fv2.dtb \
> sun5i-a10s-olinuxino-micro.dtb \
> sun5i-a13-olinuxino.dtb \
> sun5i-a13-olinuxino-micro.dtb \
> diff --git a/arch/arm/boot/dts/sun4i-a10-inet97fv2.dts
> b/arch/arm/boot/dts/sun4i-a10-inet97fv2.dts
> new file mode 100644
> index 0000000..82b4306
> --- /dev/null
> +++ b/arch/arm/boot/dts/sun4i-a10-inet97fv2.dts
> @@ -0,0 +1,106 @@
> +/*
> + * Copyright 2014 Open Source Support GmbH
> + *
> + * David Lanzend?rfer <david.lanzendoerfer@o2s.ch>
> + *
> + * The code contained herein is licensed under the GNU General Public
> + * License. You may obtain a copy of the GNU General Public License
> + * Version 2 or later at the following locations:
> + *
> + * http://www.opensource.org/licenses/gpl-license.html
> + * http://www.gnu.org/copyleft/gpl.html
> + */
> +
> +/dts-v1/;
> +/include/ "sun4i-a10.dtsi"
> +
> +/ {
> + model = "INet-97F Rev 02";
> + compatible = "primux,inet97fv2", "allwinner,sun4i-a10";
> +
> + aliases {
> + serial0 = &uart0;
> + };
> +
> + soc at 01c00000 {
> + mmc0: mmc at 01c0f000 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&mmc0_pins_a>;
> + pinctrl-1 = <&mmc0_cd_pin_inet97fv2>;
> + cd-gpios = <&pio 7 1 0>; /* PH1 */
> + cd-mode = <1>;
> + status = "okay";
> + };
> +
> + pinctrl at 01c20800 {
> + mmc0_cd_pin_inet97fv2: mmc0_cd_pin at 0 {
> + allwinner,pins = "PH1";
> + allwinner,function = "gpio_in";
> + allwinner,drive = <0>;
> + allwinner,pull = <0>;
> + };
> +
> + usb1_vbus_pin: usb1_vbus_pin at 0 {
> + allwinner,pins = "PH6";
> + allwinner,function = "gpio_out";
> + allwinner,drive = <0>;
> + allwinner,pull = <2>;
> + };
> +
> + usb2_vbus_pin: usb2_vbus_pin at 0 {
> + allwinner,pins = "PH3";
> + allwinner,function = "gpio_out";
> + allwinner,drive = <0>;
> + allwinner,pull = <2>;
> + };
> + };
> +
> + uart0: serial at 01c28000 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&uart0_pins_a>;
> + status = "okay";
> + };
> +
> + i2c0: i2c at 01c2ac00 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c0_pins_a>;
> + status = "okay";
> + };
> +
> + ehci0: ehci0 at 0x01c14000 {
> + vbus-supply = <®_usb1_vbus>;
> + status = "okay";
> + };
> +
> + ehci1: ehci1 at 0x01c1c000 {
> + vbus-supply = <®_usb2_vbus>;
> + status = "okay";
> + };
> + };
> +
> + regulators {
> + compatible = "simple-bus";
> +
> + reg_usb1_vbus: usb1-vbus {
> + compatible = "regulator-fixed";
> + pinctrl-names = "default";
> + pinctrl-0 = <&usb1_vbus_pin>;
> + regulator-name = "usb1-vbus";
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + enable-active-high;
> + gpio = <&pio 7 6 0>;
> + };
> +
> + reg_usb2_vbus: usb2-vbus {
> + compatible = "regulator-fixed";
> + pinctrl-names = "default";
> + pinctrl-0 = <&usb2_vbus_pin>;
> + regulator-name = "usb2-vbus";
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + enable-active-high;
> + gpio = <&pio 7 3 0>;
> + };
> + };
> +};
>
^ permalink raw reply
* [PATCH v2 2/5] clk: sunxi: Add USB clock register defintions
From: Hans de Goede @ 2014-02-07 13:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140207134831.GJ3192@lukather>
Hi,
On 02/07/2014 02:48 PM, Maxime Ripard wrote:
> On Tue, Feb 04, 2014 at 11:14:44AM +0100, Hans de Goede wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Hi,
>>
>> On 02/04/2014 10:40 AM, Maxime Ripard wrote:
>>> Hi Hans,
>>>
>>> On Tue, Jan 28, 2014 at 11:00:45AM +0100, Hans de Goede wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>>>
>>>> Hi,
>>>>
>>>> On 01/28/2014 10:44 AM, Maxime Ripard wrote:
>>>>> On Mon, Jan 27, 2014 at 03:54:14PM +0100, Hans de Goede wrote:
>>>>>>>> "allwinner,sun5i-a13-usb-gates-clk" - for usb gates + resets on A13
>>>>>>>
>>>>>>> Maybe we can just remove the gates from there? Even though they are gates, they are also (a bit) more than that.
>>>>>>
>>>>>> To be clear you mean s/usb-gates-clk/usb-clk/ right ?
>>>>>
>>>>> Yep, exactly
>>>>>
>>>>>>> I guess that means that we will have the OHCI0 gate declared with <&...-gates-clk 6>, while it's actually the first gate for this clock?
>>>>>>
>>>>>> Correct.
>>>>>>
>>>>>>> Maybe introducing an offset field in the gates_data would be a good idea, so that we always start from indexing the gates from 0 in the DT?
>>>>>>
>>>>>> Well for the other "gates" type clks we also have holes in the range, and we always refer to the clk with the bit number in the reg as the clock-cell value.
>>>>>
>>>>> Yes, we have holes, but I see two majors differences here: - the other gates are just gates, while the usb clocks are a bit more than that.
>>>>
>>>> The usb-clk registers contain more then that, but the bits we are talking about now are gates.
>>>>
>>>>> - the other gates' gating bits thus all start at bit 0, while - here, since it's kind of a "mixed" clock, the gating bits start - at bit 6 (on the A20 at least)
>>>>
>>>> Right, still I believe that the consistent thing to do is keeping the bit-number for the bit in the register controlling the gate as the specifier. When adding new dts entries / reviewing existing ones I'm used to matching the specifier to the bit-nr in the data-sheet, I think making things different just for this one register is counter productive.
>>>
>>> And if you turn it the other way around, it would be inconsistent that all gates indices start at 0, and we would start at 6 here :)
>>
>> I think the problem here is that you see the specifier part of the clk
>> phandle as an index, which it is not. All devicetree docs / code talks
>> about specifiers or arguments not indexes. Once you stop seeing this as
>> an index, you will hopefully also stop insisting this needs to
>> start at 0 :)
>>
>> Also note that it already is not an index for existing sunxi clks which have
>> cells != 0, as there are holes in the bits used in the gates registers and
>> calling the specifier an index suggest we're dealing with an array, and
>> arrays never have holes.
>>
>> The clk specifier as currently used in sunxi clks is a 1:1 mapping of the
>> gate register bit numbers, as is clearly documented in ie:
>> Documentation/devicetree/bindings/clock/sunxi/sun4i-a10-gates.txt
>> Where the datasheet is referenced as the source for (most) of the values
>> to put in the specifier.
>>
>> My biggest objection is that this would loose 1:1 mapping we currently
>> have between the specifier and bit-nr in the register, which really is
>> convenient when writing new dts bindings.
>>
>> When we add an offset users will need to first lookup which clk they need in
>> the datasheet and then look at both the dts bindings doc to find how this is
>> mapped to the specifier. In my experience such an extra level of indirection
>> in documentation is a PITA, and all that just so that some random number
>> (it is not an index!) can start at 0 ?
>>
>> To me adding an offset here and making the clk gates different form all
>> our other clock gates just feels wrong.
>
> Emilio pretty much share your feeling. I won't get in the way then :)
>
> I only had the compatible name comment left then.
Yes I've already fixed that in my latest sunxi-devel tree:
https://github.com/linux-sunxi/linux-sunxi/commits/sunxi-devel
Which is also rebased to 3.14-rc1 for those interested, I'll resend
the usb-clk patches with this + Emilio's reverted remark fixed soon-ish
then.
Regards,
Hans
^ permalink raw reply
* [PATCH 01/18] arm64: initial support for GICv3
From: Christopher Covington @ 2014-02-07 13:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <loom.20140207T065340-308@post.gmane.org>
On 02/07/2014 03:59 AM, Arnab Basu wrote:
> Hi Marc
>
> Marc Zyngier <marc.zyngier <at> arm.com> writes:
>
>> +
>> +static inline void __iomem *gic_dist_base(struct irq_data *d)
>
> I would suggest that this function be renamed (something like
> gic_base_for_irq?) since it returns dist or redist sgi base address. The
> name suggests it always returns the dist base address.
>
>> +{
>> + if (d->hwirq < 32) /* SGI+PPI -> SGI_base for this CPU */
>> + return gic_data_rdist_sgi_base();
>> +
>> + if (d->hwirq <= 1023) /* SPI -> dist_base */
>> + return gic_data.dist_base;
>> +
>> + if (d->hwirq >= 8192)
>> + BUG(); /* LPI Detected!!! */
>> +
>> + return NULL;
>> +}
>> +
>> +static inline unsigned int gic_irq(struct irq_data *d)
>> +{
>> + return d->hwirq;
>> +}
>> +
>> +static void gic_do_wait_for_rwp(void __iomem *base)
>> +{
>> + u32 val;
>> +
>> + do {
>> + val = readl_relaxed(base + GICD_CTLR);
>
> Maybe rename GICD_CTLR to GICx_CTLR since it is being used for both the
> distributor and the redistributor.
GICx_ makes it sound relevant for GIC CPU interfaces (GICC) as well. Unless it
is, maybe something more like GICDR_ for Generic Interrupt Controller
Distributor/Redistributor would be best?
Christopher
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by the Linux Foundation.
^ permalink raw reply
* [PATCHv5] omap3: Add basic support for 720MHz part
From: Nishanth Menon @ 2014-02-07 13:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1623915.4eAJkBo57q@avalon>
Laurent,
On Thu, Feb 6, 2014 at 1:26 PM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> Hi all,
>
> On Friday 22 June 2012 11:33:51 Laurent Pinchart wrote:
>> On Thursday 10 February 2011 08:45:00 Kevin Hilman wrote:
>> > Sanjeev Premi <premi@ti.com> writes:
>> > > This patch adds support for speed enhanced variant of OMAP35x
>> > > processors. These parts allow ARM and IVA running at 720MHz
>> > > and 520MHz respectively.
>> > >
>> > > These parts can be detected at runtime by reading contents of
>> > > PRODID.SKUID[3:0] at 0x4830A20C [1].
>> > >
>> > > This patch specifically does following:
>> > > * Add new OPP to omap34xx_opp_def_list[] - disabled by default.
>> > > * Detect devices capable of running at new OPP.
>> > > * Enable new OPP only if device supports it.
>> > > * Check for presence of IVA before attempting to enable the
>> > >
>> > > corresponding OPP.
>> > >
>> > > [1] http://focus.ti.com/lit/ug/spruff1d/spruff1d.pdf
>> > >
>> > > It appears from discussions (on this patch) that a variant of
>> > > OMAP3430 supports this OPP but lacks runtime detection. This
>> > >
>> > > OPP can be enabled for these device by either:
>> > > 1) Setting the bit corresponding to OMAP3_HAS_720MHZ
>> > >
>> > > in 'omap3_features'. (Refer changes to id.c)
>> > >
>> > > 2) Removing check for omap3_has_720mhz() before enabling
>> > >
>> > > the OPP. (Refer changes to opp3xxx_data.c)
>> > >
>> > > 3) Calling opp_enable() for 720MHz/VDD1 and 520MHz/VDD2 in
>> > >
>> > > the board file. (Refer changes to opp3xxx_data.c).
>> > > This should, ideally, be done before omap3_opp_init() is
>> > > called during device_initcall().
>> > >
>> > > CAUTION: This should be done for identified parts only.
>> > >
>> > > Else, the device could be damaged permanently.
>> > >
>> > > Signed-off-by: Sanjeev Premi <premi@ti.com>
>> > > Reviewed-by: G, Manjunath Kondaiah <manjugk@ti.com>
>> >
>> > Acked-by: Kevin Hilman <khilman@ti.com>
>>
>> This patch seems to never have made it upstream. Is there a reason for that
>> ?
>
> Ping ?
We'd have to figure out a proper opp modifier logic with device tree.
considering that non-dt boot is slowly getting dismantled in
mach-omap2, to add new capabilities in non-dt is not really a good
idea at this point in time - Further, we do have equivalent
requirements in other TI SoCs as well -
Regards,
Nishanth Menon
^ permalink raw reply
* [PATCH] iommu/exynos: Remove driver
From: Marek Szyprowski @ 2014-02-07 13:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAH9JG2Xoz1_Y7CV6FUiGAO9o5T7jtFUYqJpcAysLttwu4527zQ@mail.gmail.com>
Hello,
On 2014-02-07 13:44, Kyungmin Park wrote:
>
> On Friday, February 7, 2014, Inki Dae <inki.dae@samsung.com
> <mailto:inki.dae@samsung.com>> wrote:
>
> 2014-02-07 Olof Johansson <olof@lixom.net <javascript:;>>:
> > The driver has been unbuildable due to unfulfilled dependencies
> since
> > 3.11, and even if enabled it won't build due to build breakage.
> Emails
> > about status on this have gone unanswered, and fixes seem to
> have been
> > abandoned.
> >
> > It's obvious that nobody cares about it, so let's remove it.
>
> Wait, we are going to fix up this module. It seems that KyoungHo,
> original author, is busy with some works related to product.
>
> we can care about it if KyoungHo cannot afford to care for the
> time being.
>
> Any volunteers?
> Marek or Bartek, how do you think?
>
> Before that it makes orphan or unsupported at maintainer file first and
> change it to new volunteers.
I think that it might be easier to remove the existing non-functional driver
now and add it again once the driver is ready. I have it on my TODO
list, but
doubt I will manage to finish it for v3.15.
Discussing the DT bindings might take some time.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* [PATCH v2 2/5] clk: sunxi: Add USB clock register defintions
From: Maxime Ripard @ 2014-02-07 13:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52F0BD94.1060601@redhat.com>
On Tue, Feb 04, 2014 at 11:14:44AM +0100, Hans de Goede wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> On 02/04/2014 10:40 AM, Maxime Ripard wrote:
> > Hi Hans,
> >
> > On Tue, Jan 28, 2014 at 11:00:45AM +0100, Hans de Goede wrote:
> >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
> >>
> >> Hi,
> >>
> >> On 01/28/2014 10:44 AM, Maxime Ripard wrote:
> >>> On Mon, Jan 27, 2014 at 03:54:14PM +0100, Hans de Goede wrote:
> >>>>>> "allwinner,sun5i-a13-usb-gates-clk" - for usb gates + resets on A13
> >>>>>
> >>>>> Maybe we can just remove the gates from there? Even though they are gates, they are also (a bit) more than that.
> >>>>
> >>>> To be clear you mean s/usb-gates-clk/usb-clk/ right ?
> >>>
> >>> Yep, exactly
> >>>
> >>>>> I guess that means that we will have the OHCI0 gate declared with <&...-gates-clk 6>, while it's actually the first gate for this clock?
> >>>>
> >>>> Correct.
> >>>>
> >>>>> Maybe introducing an offset field in the gates_data would be a good idea, so that we always start from indexing the gates from 0 in the DT?
> >>>>
> >>>> Well for the other "gates" type clks we also have holes in the range, and we always refer to the clk with the bit number in the reg as the clock-cell value.
> >>>
> >>> Yes, we have holes, but I see two majors differences here: - the other gates are just gates, while the usb clocks are a bit more than that.
> >>
> >> The usb-clk registers contain more then that, but the bits we are talking about now are gates.
> >>
> >>> - the other gates' gating bits thus all start at bit 0, while - here, since it's kind of a "mixed" clock, the gating bits start - at bit 6 (on the A20 at least)
> >>
> >> Right, still I believe that the consistent thing to do is keeping the bit-number for the bit in the register controlling the gate as the specifier. When adding new dts entries / reviewing existing ones I'm used to matching the specifier to the bit-nr in the data-sheet, I think making things different just for this one register is counter productive.
> >
> > And if you turn it the other way around, it would be inconsistent that all gates indices start at 0, and we would start at 6 here :)
>
> I think the problem here is that you see the specifier part of the clk
> phandle as an index, which it is not. All devicetree docs / code talks
> about specifiers or arguments not indexes. Once you stop seeing this as
> an index, you will hopefully also stop insisting this needs to
> start at 0 :)
>
> Also note that it already is not an index for existing sunxi clks which have
> cells != 0, as there are holes in the bits used in the gates registers and
> calling the specifier an index suggest we're dealing with an array, and
> arrays never have holes.
>
> The clk specifier as currently used in sunxi clks is a 1:1 mapping of the
> gate register bit numbers, as is clearly documented in ie:
> Documentation/devicetree/bindings/clock/sunxi/sun4i-a10-gates.txt
> Where the datasheet is referenced as the source for (most) of the values
> to put in the specifier.
>
> My biggest objection is that this would loose 1:1 mapping we currently
> have between the specifier and bit-nr in the register, which really is
> convenient when writing new dts bindings.
>
> When we add an offset users will need to first lookup which clk they need in
> the datasheet and then look at both the dts bindings doc to find how this is
> mapped to the specifier. In my experience such an extra level of indirection
> in documentation is a PITA, and all that just so that some random number
> (it is not an index!) can start at 0 ?
>
> To me adding an offset here and making the clk gates different form all
> our other clock gates just feels wrong.
Emilio pretty much share your feeling. I won't get in the way then :)
I only had the compatible name comment left then.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140207/8b67746f/attachment-0001.sig>
^ permalink raw reply
* [PATCH v6 05/19] watchdog: orion: Make sure the watchdog is initially stopped
From: Guenter Roeck @ 2014-02-07 13:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140207104044.GA11063@localhost>
On 02/07/2014 02:40 AM, Ezequiel Garcia wrote:
> On Thu, Feb 06, 2014 at 06:02:56PM -0800, Guenter Roeck wrote:
>> On 02/06/2014 09:20 AM, Ezequiel Garcia wrote:
>>> Having the watchdog initially fully stopped is important to avoid
>>> any spurious watchdog triggers, in case the registers are not in
>>> its reset state.
>>>
>>> Reviewed-by: Guenter Roeck <linux@roeck-us.net>
>>> Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
>>> Tested-by: Willy Tarreau <w@1wt.eu>
>>> Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
>>> ---
>>> drivers/watchdog/orion_wdt.c | 3 +++
>>> 1 file changed, 3 insertions(+)
>>>
>>> diff --git a/drivers/watchdog/orion_wdt.c b/drivers/watchdog/orion_wdt.c
>>> index 6746033..2dbeee9 100644
>>> --- a/drivers/watchdog/orion_wdt.c
>>> +++ b/drivers/watchdog/orion_wdt.c
>>> @@ -142,6 +142,9 @@ static int orion_wdt_probe(struct platform_device *pdev)
>>> orion_wdt.max_timeout = wdt_max_duration;
>>> watchdog_init_timeout(&orion_wdt, heartbeat, &pdev->dev);
>>>
>>> + /* Let's make sure the watchdog is fully stopped */
>>> + orion_wdt_stop(&orion_wdt);
>>> +
>>
>> Actually we just had that in another driver, and I stumbled over it there.
>>
>> Problem with stopping the watchdog in probe unconditionally is that you can
>> use it to defeat nowayout: unload the module, then load it again,
>> and the watchdog is stopped even if nowayout is true.
>>
>
> Hm... I see.
>
>> Is this really what you want ? Or, in other words, what is the problem
>> you are trying to solve ?
>>
>
> Well, this is related to the discussion about the bootloader not
> reseting the watchdog properly, provoking spurious watchdog triggering.
>
> Jason Gunthorpe explained [1] that we needed a particular sequence:
>
> 1. Disable WDT
> 2. Clear bridge
> 3. Enable WDT
>
> We added the irq handling to satisfy (2), and the watchdog stop for (1).
>
> The watchdog stop was agreed specifically [2].
>
> Ideas?
>
Other drivers assume that if the watchdog is running, it is supposed
to be running. The more common approach in such cases is to ping the
watchdog once to give userspace more time to get ready, but leave
it enabled. So you could check if the watchdog is enabled, and if
it was enabled re-enable it after initialization is complete
(and maybe log a message stating that the watchdog is enabled).
If you don't want to do that, and if you are defeating nowayout
on purpose to fix a problem with a broken bootloader,
you should at least put in comment describing the problem you are
trying to solve, and that you accept breaking nowayout with your fix.
Thanks,
Guenter
^ permalink raw reply
* [PATCH v4] gpio: davinci: reuse for keystone soc
From: Sekhar Nori @ 2014-02-07 13:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdbgteBtuwdEn+Bg+kA1JnEHus2FOfTbj-hm5fKBsw7XeA@mail.gmail.com>
Hi Linus,
On Thursday 06 February 2014 06:50 PM, Linus Walleij wrote:
> On Wed, Feb 5, 2014 at 4:47 PM, Grygorii Strashko
> <grygorii.strashko@ti.com> wrote:
>
>> The similar GPIO HW block is used by keystone SoCs as
>> in Davinci SoCs.
>> Hence, reuse Davinci GPIO driver for Keystone taking into
>> account that Keystone contains ARM GIC IRQ controller which
>> is implemented using IRQ Chip.
>>
>> Documentation:
>> http://www.ti.com/lit/ug/sprugv1/sprugv1.pdf
>>
>> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>> Acked-by: Linus Walleij <linus.walleij@linaro.org>
>> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
>> ---
>> Changes in v4:
>> - rebased on top of v3.14 +
>> [patch] gpio: davinci: signedness bug in davinci_gpio_irq_setup()
>
> Are you taking this through ARM SoC or is this something
> I should be merging?
Can you please merge this through your tree as there aren't any
dependencies with mach-davinci anymore.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH 1/3] wdt: sunxi: Introduce a new compatible for the A10 and A31
From: Maxime Ripard @ 2014-02-07 13:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52F36E8D.4050503@redhat.com>
Hi Hans,
On Thu, Feb 06, 2014 at 12:14:21PM +0100, Hans de Goede wrote:
> On 02/02/2014 02:55 PM, Maxime Ripard wrote:
> >For historical reasons, the Allwinner A10 compatibles are not following the
> >patterns used for this other Allwinner SoCs.
> >
> >Introduce a new compatible following the usual pattern, and deprecate the olders.
> >
> >Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> >---
> > Documentation/devicetree/bindings/watchdog/sunxi-wdt.txt | 7 ++++---
> > drivers/watchdog/sunxi_wdt.c | 1 +
> > 2 files changed, 5 insertions(+), 3 deletions(-)
> >
> >diff --git a/Documentation/devicetree/bindings/watchdog/sunxi-wdt.txt b/Documentation/devicetree/bindings/watchdog/sunxi-wdt.txt
> >index e39cb26..6e8c937 100644
> >--- a/Documentation/devicetree/bindings/watchdog/sunxi-wdt.txt
> >+++ b/Documentation/devicetree/bindings/watchdog/sunxi-wdt.txt
> >@@ -2,13 +2,14 @@ Allwinner SoCs Watchdog timer
> >
> > Required properties:
> >
> >-- compatible : should be "allwinner,<soc-family>-wdt", the currently supported
> >- SoC families being sun4i and sun6i
> >+- compatible : should be either "allwinner,sun4i-a10-wdt" or
> >+ "allwinner,sun6i-a31-wdt" (deprecated:
> >+ "allwinner,sun4i-wdt", "allwinner,sun6i-wdt")
> > - reg : Specifies base physical address and size of the registers.
> >
> > Example:
> >
> > wdt: watchdog at 01c20c90 {
> >- compatible = "allwinner,sun4i-wdt";
> >+ compatible = "allwinner,sun4i-a10-wdt";
> > reg = <0x01c20c90 0x10>;
> > };
>
> You talk about deprecating the old compat strings in the commit message, but
> here you outright replace them, which will break things with old dtb files ?
I'm replacing them only in the Documentation here.
I only add it to the driver after that, which means that the driver
will be probed with both the new and the old compatibles.
However, the DT maintainers said it was ok to remove them entirely, so
I'll send a v2.
Maxime
>
> Other 2 patches in the series look good and are:
>
> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
>
>
> >diff --git a/drivers/watchdog/sunxi_wdt.c b/drivers/watchdog/sunxi_wdt.c
> >index 76332d8..7c8923d 100644
> >--- a/drivers/watchdog/sunxi_wdt.c
> >+++ b/drivers/watchdog/sunxi_wdt.c
> >@@ -206,6 +206,7 @@ static void sunxi_wdt_shutdown(struct platform_device *pdev)
> >
> > static const struct of_device_id sunxi_wdt_dt_ids[] = {
> > { .compatible = "allwinner,sun4i-wdt" },
> >+ { .compatible = "allwinner,sun4i-a10-wdt" },
> > { /* sentinel */ }
> > };
> > MODULE_DEVICE_TABLE(of, sunxi_wdt_dt_ids);
> >
>
> Regards,
>
> Hans
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140207/f1d6c888/attachment.sig>
^ permalink raw reply
* [PATCH] clk: respect the clock dependencies in of_clk_init
From: Emilio López @ 2014-02-07 13:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391554766-11285-1-git-send-email-gregory.clement@free-electrons.com>
Hi all,
El 04/02/14 19:59, Gregory CLEMENT escribi?:
> Until now the clock providers were initialized in the order found in
> the device tree. This led to have the dependencies between the clocks
> not respected: children clocks could be initialized before their
> parent clocks.
>
> Instead of forcing each platform to manage its own initialization order,
> this patch adds this work inside the framework itself.
>
> Using the data of the device tree the of_clk_init function now delayed
> the initialization of a clock provider if its parent provider was not
> ready yet.
>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
After discussing this on IRC with Ezequiel, I must say I'm not really
fond of this solution, as it adds unnecessary complexity to the
framework and slows down clock registration to solve one particular
problem that can be resolved in a simpler, less intrusive way.
The triggering issue which has resulted on this patch is really a simple
dependency on the name of the parent clock - something that should not
be an issue if DT is used to provide them (see of_clk_get_parent_name),
and even when this is not the case, it should not require poking the
clock tree to find out. It wouldn't be hard to fix however, even if you
cannot modify your device trees to provide proper naming; a tiny patch
like the one below should suffice (Ezequiel has kindly tested it today
on a a370-rd and found it working correctly).
In other words, I feel this patch is a pretty good demonstration of
over-engineering and bloating of an otherwise good framework to cover up
for bugs/bad design on other parts of the kernel. Think about it; why
does the framework require char *parent instead of struct clk *parent to
link a child with their parent? Randomly-ordered registration is a
pretty core principle of it; whether by design or not.
So, until someone has a real reason to enforce dependencies on clock
registration time, I would like this to stay uncommited. And, if the
time comes and something like this is ever needed, *please* make it
optional (ie, have a special macro and separate table to register clocks
which are dependency-sensitive, and do so after registering all the
non-dependency-sensitive clocks).
Cheers,
Emilio
-----8<------
From ffdb49506e3ce92090c15e1f9b37f4d465097ac1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Emilio=20L=C3=B3pez?= <emilio@elopez.com.ar>
Date: Thu, 6 Feb 2014 18:07:07 -0300
Subject: [PATCH] clk: mvebu: fix name dependency during registration time
Currently, mvebu_clk_gating_setup has a silly dependency on clock
registration order just to gather the parent clock name. This is
completely unnecesary, as it supports using an already provided name
via the clk_gating_soc_desc structs, and we can therefore solve this
issue with a 69+/- line patch. But, given that the parent name is
always "tclk" as default-hardcoded on mvebu_coreclk_setup(), we can
just default-hardcode it here too and get away with solving this
problem with a one-liner.
---
drivers/clk/mvebu/common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/mvebu/common.c b/drivers/clk/mvebu/common.c
index 25ceccf..6c63b43 100644
--- a/drivers/clk/mvebu/common.c
+++ b/drivers/clk/mvebu/common.c
@@ -121,7 +121,7 @@ void __init mvebu_clk_gating_setup(struct
device_node *np,
struct clk_gating_ctrl *ctrl;
struct clk *clk;
void __iomem *base;
- const char *default_parent = NULL;
+ const char *default_parent = "tclk";
int n;
base = of_iomap(np, 0);
--
1.8.5.3
^ permalink raw reply related
* [PATCH 3/6] irqchip: gic: use writel instead of dsb + writel_relaxed
From: Catalin Marinas @ 2014-02-07 12:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140207112337.GC5976@mudshark.cambridge.arm.com>
On Fri, Feb 07, 2014 at 11:23:38AM +0000, Will Deacon wrote:
> On Thu, Feb 06, 2014 at 03:20:48PM +0000, Catalin Marinas wrote:
> > On Thu, Feb 06, 2014 at 01:26:44PM +0000, Will Deacon wrote:
> > > On Thu, Feb 06, 2014 at 12:23:40PM +0000, Catalin Marinas wrote:
> > > > On Thu, Feb 06, 2014 at 12:13:50PM +0000, Will Deacon wrote:
> > > > > Ok, so if we assume that a dsb(ishst) is sufficient because the CPU we're
> > > > > talking to is either (a) coherent in the inner-shareable domain or (b)
> > > > > incoherent, and we flushed everything to PoC, then why wouldn't a dmb(ishst)
> > > > > work?
> > > >
> > > > Because you want to guarantee the ordering between a store to Normal
> > > > Cacheable memory vs store to Device for the IPI (see the mailbox example
> > > > in the Barrier Litmus section ;)). The second is just a slave access, DMB
> > > > guarantees observability from the master access perspective.
> > >
> > > Ok, my reasoning is as follows:
> > >
> > > - CPU0 tries to message CPU1. It writes to a location in normal memory,
> > > then writes to the GICD to send the SGI
> > >
> > > - We need to ensure that CPU1 observes the write to normal memory before
> > > the write to GICD reaches the distributor. This is *not* about end-point
> > > ordering (the usual non-coherent DMA example).
> > >
> > > - A dmb ishst ensures that the two writes are observed in order by CPU1
> > > (and, in fact, the inner-shareable domain containing CPU0).
> >
> > The last bullet point is not correct. DMB would only guarantee that the
> > two writes (memory and GICD) are observed by CPU1 if CPU1 actually read
> > the GICD (observability is defined for master accesses).
>
> No, that's not how observability is defined, unfortunately.
According to the ARM ARM, "an observer is a master in the system that is
capable of observing memory accesses". GICD is not memory, hence the
assumptions about DMB in this context no longer work.
> Rather than attempt to solve this via email (your examples below are already
> getting hard to follow :), how about we sit down with $drink_of_choice and
> post back here with our conclusions?
Sounds good (though not a wide choice of drinks).
> In the meantime, I'll use dsb(ishst) because I think we now agree that
> works. The question is whether it can be relaxed further to a dmb.
I'm fine with dsb(ishst).
--
Catalin
^ permalink raw reply
* [PATCH v2 0/6] ARM: STi reset controller support
From: srinivas kandagatla @ 2014-02-07 12:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391592486.11239.4.camel@pizza.hi.pengutronix.de>
Hi Philipp,
Thankyou for looking at the patches.
On 05/02/14 09:28, Philipp Zabel wrote:
> Hi Srinivas,
>
...
>
> the patchset looks good to me for the soft resets. But for the powerdown
> bits I am wondering whether the reset controller API is the right
> abstraction. Depending on whether those bits really just put the IPs
> into reset or there is some power gating / sequencing involved,
> shouldn't this rather be handled as a set of pm domains?
The hardware name of these control signals into the devices is
slightly unfortunate and a bit misleading. We do not generally
have separate power domains for peripheral devices in our
current STB SoCs, in the sense that the voltage cannot actually be
removed from individual devices. In the USB case we believe the
powerdown signals internally gate off two of the three
incoming clocks to most of the USB controller's logic blocks,
essentially holding the device in a disabled (enable/disable
might have been a better name for the signal) state.
The primary requirement to manipulate these signals is to bring
the device out of its cold boot default powerdown/disabled/reset
(whatever you want to call it) state when the device is probed or
after a SoC wide power loss when resuming from PM_SUSPEND_MEM.
> I see that for example on STiH415 there are both soft resets and
> powerdown bits for USB[012].
Our IPs typically have two or sometimes three signals going into
them, controlled from outside of the IP block itself (typically using
SoC global system configuration registers) that you could view
as "reset-a-like"; that is toggling each of the signals puts the IP
into a state where it is in some way unusable and then back to
being useable again. The reset controller API appeared to be the
natural abstraction for the drivers to be given access to such control
signals, regardless of the precise effect the signals have on the
device's internal state.
With regards to sequencing between these signals; it is the case that
there is a likely sequencing because at least in the USB case it is
thought that the "powerdown" stops the clock going to the reset chain
logic. But we did not see that as an issue as the reset controller
framework allows for multiple named "reset" lines being defined for
a device through its DT attributes. The driver knows which signal
is which and what each does, because it asks for them by name;
therefore, it knows how to impose any required ordering when changing
the state of those signals.
Thanks,
srini
^ permalink raw reply
* [PATCH v2 6/6] cpu/idle.c: move to sched/idle.c
From: Peter Zijlstra @ 2014-02-07 12:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.11.1402071051140.1906@knanqh.ubzr>
On Fri, Feb 07, 2014 at 11:09:23AM +0000, Nicolas Pitre wrote:
> On Thu, 6 Feb 2014, Peter Zijlstra wrote:
> > tree, tree, what's in a word.
>
> Something you may plant on a patch of grass? "Merging" becomes a
> strange concept in that context though. :-)
I do know some farmers who splice trees thought :-)
> > Its in my patch stack yes.
>
> Quilt I suppose?? (yet another word.)
Yes, I'm one of the refugee Quilt users. Comes in handy when cold too
:-)
> > I should get some of that into tip I suppose, been side-tracked a bit
> > this week. Sorry for the delay.
>
> If you prefer we pile those patches (and future ones after revew)
> ourselves just let me know. Future patches are likely to be more
> intimate with the scheduler so I just need to know who to upstream them
> through afterwards.
Normally I get Ingo to pick up the queue 1-2 times a week so latency
shouldn't be too bad. But we just had the merge window and then I got
side-tracked rewriting all atomic implementations.
So usually submit patches against tip/master unless you know there's
other pending bits that conflict, in which case you can grab my queue on
top of tip/master -- but I try to make sure that's usually not needed.
^ permalink raw reply
* [PATCH RFC 26/46] drivers/base: provide an infrastructure for componentised subsystems
From: Russell King - ARM Linux @ 2014-02-07 12:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140207125721.2d925387@armhf>
On Fri, Feb 07, 2014 at 12:57:21PM +0100, Jean-Francois Moine wrote:
> I started to use your code (which works fine, thanks), and it avoids a
> lot of problems, especially, about probe_defer in a DT context.
>
> I was wondering if your componentised mechanism could be extended to the
> devices defined by DT.
It was developed against imx-drm, which is purely DT based. I already
have a solution for the cubox armada DRM.
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* [PATCH] ARM: mm: implement pte_accessible for faulting mappings
From: Will Deacon @ 2014-02-07 12:21 UTC (permalink / raw)
To: linux-arm-kernel
The pte_accessible macro can be used to identify page table entries
capable of being cached by a TLB. In principle, this differs from
pte_present, since PROT_NONE mappings are mapped using invalid entries
identified as present and ptes designated as `old' can use either
invalid entries or those with the access flag cleared (guaranteed not to
be in the TLB). However, there is a race to take care of, as described
in 20841405940e ("mm: fix TLB flush race between migration, and
change_protection_range"), between a page being migrated and mprotected
at the same time. In this case, we can check whether a TLB invalidation
is pending for the mm and if so, temporarily consider PROT_NONE mappings
as valid.
This patch implements a quick pte_accessible macro for ARM by simply
checking if the pte is valid/present depending on the mm. For classic
MMU, these checks are identical and will generate some false positives
for PROT_NONE mappings, but this is better than the current asm-generic
definition of ((void)(pte),1).
Finally, pte_present_user is moved to use pte_valid (and renamed
appropriately) since we don't care about cache flushing for faulting
mappings.
Acked-by: Steve Capper <steve.capper@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
arch/arm/include/asm/pgtable.h | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/pgtable.h b/arch/arm/include/asm/pgtable.h
index 7d59b524f2af..5478e5d6ad89 100644
--- a/arch/arm/include/asm/pgtable.h
+++ b/arch/arm/include/asm/pgtable.h
@@ -216,13 +216,16 @@ static inline pte_t *pmd_page_vaddr(pmd_t pmd)
#define pte_none(pte) (!pte_val(pte))
#define pte_present(pte) (pte_val(pte) & L_PTE_PRESENT)
+#define pte_valid(pte) (pte_val(pte) & L_PTE_VALID)
+#define pte_accessible(mm, pte) (mm_tlb_flush_pending(mm) ? pte_present(pte) : pte_valid(pte))
#define pte_write(pte) (!(pte_val(pte) & L_PTE_RDONLY))
#define pte_dirty(pte) (pte_val(pte) & L_PTE_DIRTY)
#define pte_young(pte) (pte_val(pte) & L_PTE_YOUNG)
#define pte_exec(pte) (!(pte_val(pte) & L_PTE_XN))
#define pte_special(pte) (0)
-#define pte_present_user(pte) (pte_present(pte) && (pte_val(pte) & L_PTE_USER))
+#define pte_valid_user(pte) \
+ (pte_valid(pte) && (pte_val(pte) & L_PTE_USER) && pte_young(pte))
#if __LINUX_ARM_ARCH__ < 6
static inline void __sync_icache_dcache(pte_t pteval)
@@ -237,7 +240,7 @@ static inline void set_pte_at(struct mm_struct *mm, unsigned long addr,
{
unsigned long ext = 0;
- if (addr < TASK_SIZE && pte_present_user(pteval)) {
+ if (addr < TASK_SIZE && pte_valid_user(pteval)) {
__sync_icache_dcache(pteval);
ext |= PTE_EXT_NG;
}
--
1.8.2.2
^ permalink raw reply related
* [PATCH] ARM: enable IRQs in user undefined instruction vector
From: vinayak menon @ 2014-02-07 12:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140207100649.GZ26684@n2100.arm.linux.org.uk>
> I don't see any point to this change - it does nothing to address the
> point I raised.
I see.
The issue that was observed can be summarized like this. There was a
userspace crash which was because of an 8 byte offset to SP when
returning from a function (strtoimax).
Analysis showed that the vpush {d8} instruction at the beginning of
strtoimax failed to execute, but vpop {d8} at the end did execute.
This resulted in a 8 byte offset in SP and resulted in the crash.
Further debugging showed that this was happening because, one of the
ldrht instructions in __und_usr was hitting a page fault, and the
fixup code was returning to the next instruction.
Correction was added to PC in the fixup (str r4, [sp, #S_PC] , in
the patch above), to fix the problem. But we were left with the
warning (might_sleep).
Reading the discussions, I thought enabling irq is an issue, and felt
that without enabling the interrupts, just disabling preemption before
calling ldrht should stop the warnings. Because do_page_fault jumps to
call fixup, if its an atomic context.
Thanks
^ permalink raw reply
* [PATCH] regulator: core: Allow regulator_set_voltage for fixed regulators
From: Mark Brown @ 2014-02-07 12:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391632226-10060-1-git-send-email-bjorn.andersson@sonymobile.com>
On Wed, Feb 05, 2014 at 12:30:26PM -0800, Bjorn Andersson wrote:
> Make it okay to call regulator_set_voltage on regulators with fixed
> voltage if the requested range overlaps the current/configured voltage.
Applied, thanks.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140207/655ab5f2/attachment-0001.sig>
^ permalink raw reply
* [PATCH RFC 26/46] drivers/base: provide an infrastructure for componentised subsystems
From: Jean-Francois Moine @ 2014-02-07 11:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140207094656.GY26684@n2100.arm.linux.org.uk>
On Fri, 7 Feb 2014 09:46:56 +0000
Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> On Fri, Feb 07, 2014 at 10:04:30AM +0100, Daniel Vetter wrote:
> > I've chatted a bit with Hans Verkuil about this topic at fosdem and
> > apparently both v4l and alsa have something like this already in their
> > helper libraries. Adding more people as fyi in case they want to
> > switch to the new driver core stuff from Russell.
>
> It's not ALSA, but ASoC which has this. Mark is already aware of this
> and will be looking at it from an ASoC perspective.
Russell,
I started to use your code (which works fine, thanks), and it avoids a
lot of problems, especially, about probe_defer in a DT context.
I was wondering if your componentised mechanism could be extended to the
devices defined by DT.
In the DT, when a device_node is a phandle, this means it is referenced
by some other device(s), and these device(s) will not start until the
phandle device is registered.
Then, the idea is to do a component_add() for such phandle devices in
device_add() (device_register).
Pratically,
- the component_add() call in device_register would not include any
bind/unbind callback function, so, this should be tested in
component_bind/unbind(),
- component_add would not be called if the device being added already
called component_add in its probe function. A simple flag in the
struct device_node should solve this problem.
What do you think about this?
--
Ken ar c'henta? | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
^ permalink raw reply
* [PATCH v2 0/9] Samsung PM consolidation part 1 (clocks)
From: Sylwester Nawrocki @ 2014-02-07 11:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJuA9ah97MQKrNeKG2vijFCr8b7T4r2Zr9gsGtETwtBLmKBrXg@mail.gmail.com>
On 07/02/14 04:45, Thomas Abraham wrote:
> On Thu, Feb 6, 2014 at 11:46 PM, Tomasz Figa <t.figa@samsung.com> wrote:
>> > This series reworks suspend/resume handling of Samsung clock drivers
>> > to cover more SoC specific aspects that are beyond simple register
>> > save and restore. The goal is to have all the suspend/resume code
>> > that touches the clock controller in single place, which is the
>> > clock driver.
>> >
>> > On Exynos4210-based Trats, Exynos4412-based Trats2 and Exynos5250-based
>> > Arndale boards (except suspend/resume, which is broken because of
>> > unrelated reasons):
>> >
>> > Tested-by: Tomasz Figa <t.figa@samsung.com>
>> >
>> > Tomasz Figa (9):
>> > clk: exynos4: Remove remnants of non-DT support
>> > clk: samsung: Provide common helpers for register save/restore
>> > clk: samsung: exynos4: Move suspend/resume handling to SoC driver
>> > clk: samsung: exynos5250: Move suspend/resume handling to SoC driver
>> > clk: samsung: exynos5420: Move suspend/resume handling to SoC driver
>> > clk: samsung: s3c64xx: Move suspend/resume handling to SoC driver
>> > clk: samsung: Drop old suspend/resume code
>> > clk: samsung: exynos4: Add remaining suspend/resume handling
>> > ARM: EXYNOS: pm: Drop legacy Exynos4 clock suspend/resume code
>> >
>> > arch/arm/mach-exynos/pm.c | 148 +-----------------------------
>> > drivers/clk/samsung/clk-exynos4.c | 172 +++++++++++++++++++++++++++++++----
>> > drivers/clk/samsung/clk-exynos5250.c | 49 +++++++++-
>> > drivers/clk/samsung/clk-exynos5420.c | 49 +++++++++-
>> > drivers/clk/samsung/clk-exynos5440.c | 2 +-
>> > drivers/clk/samsung/clk-s3c64xx.c | 79 +++++++++++++---
>> > drivers/clk/samsung/clk.c | 71 ++++++---------
>> > drivers/clk/samsung/clk.h | 14 ++-
>> > 8 files changed, 348 insertions(+), 236 deletions(-)
>
> Nice series!
> Reviewed-by: Thomas Abraham <thomas.ab@samsung.com>
Yes, that's a nice cleanup.
Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
^ permalink raw reply
* [linux-sunxi] Re: [PATCH] irq: Add new flag to ack level-triggered interrupts before unmasking
From: Thomas Gleixner @ 2014-02-07 11:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOQ7t2bzz9vKh_5h2nF=m+JpeYVa=Ttd4XQgrAa6Lhdzjg_Qxw@mail.gmail.com>
On Fri, 7 Feb 2014, Carlo Caione wrote:
> The context and the rationale is fully explained in this thread
> http://www.spinics.net/lists/arm-kernel/msg299952.html and some
> answers are already given along the thread especially by Hans here
> http://www.spinics.net/lists/arm-kernel/msg303542.html
> Shortly, the double interrupt problem as seen on sunxi NMI controller
> (and other chips AFAIK) is specific for level-triggered interrupts
> when the hard interrupt handler is not able to ACK the interrupts on
> the originating device since this device can only be accessed via a
> bus (in our case it was a PMIC on I2C).
> This explains why my patch was specific for the threaded case and why
> the ACK on mask is not really effective in actually acking the IRQs
> (so that I need a second ACK before unmasking the line). In fact in
> our case (PMIC connected via I2C with an interrupt line on a special
> NMI controller) the implicit ACK done by the unmask is ignored if the
> NMI line is still high, and to have the line going down we have to ACK
> all the IRQs on the device accessing to it by I2C in the thread and
> then ACK the NMI controller with the second ACK before the unmasking
> callback.
I can't see why it would be specific for the threaded case.
The explanation says that the NMI chip is ignoring the ack on mask,
which is basically the entry of the interrupt handler. Now it does not
matter whether you are threaded or not. The interrupt line at the NMI
controller is asserted in both cases. So the same issue should be
visible for a non threaded interrupt, if the NMI controller really
needs an ack on unmask. But there is another detail:
sunxi_sc_nmi_handle_irq()
chained_irq_enter()
NOP, because GIC uses EOI
generic_handle_irq();
nmi->mask();
dev_handler();
nmi->unmask();
chained_irq_exit()
gic->eoi();
In the threaded case this looks like:
sunxi_sc_nmi_handle_irq()
chained_irq_enter()
NOP, because GIC uses EOI
generic_handle_irq();
nmi->mask();
wake_thread();
chained_irq_exit()
gic->eoi();
run_thread()
dev_handler();
nmi->unmask();
So the difference is that in the non threaded case the gic->eoi is
called after the device interrupt has been cleared and the
nmi->interrupt has been unmasked. And in the threaded case its the
other way round. I have no idea how that stuff is connected internaly,
but I suspect that the gic->eoi is related to this as it might
actually ack the NMI chip, which of course only works in the non
threaded case.
Now back to your patch.
I'm not against having a flag, but this should be done less convoluted
and have proper names which make the use case clear along with a good
technical explanation of the flag in the comment.
unmask_and_ack() plus IRQCHIP_ACK_ON_UNMASK are not really telling
what the heck is going on. You can restrict it to level irqs in the
core, but please use the proper functions and not some opencoded
hackery.
Thanks,
tglx
^ permalink raw reply
* [PATCH 2/3] PCI: ARM: add support for virtual PCI host controller
From: Will Deacon @ 2014-02-07 11:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3724624.kd9jZNUiTF@wuerfel>
Hi Arnd, Jason,
First of all, thanks for the really helpful feedback. I'll take it on-board
for v2.
On Wed, Feb 05, 2014 at 08:26:17PM +0000, Arnd Bergmann wrote:
> On Wednesday 05 February 2014 19:09:47 Will Deacon wrote:
> > On Tue, Feb 04, 2014 at 07:13:49PM +0000, Arnd Bergmann wrote:
> > > This should really compute an io_offset.
> > >
> > > > + if (resource_type(&pci->mem))
> > > > + pci_add_resource(&sys->resources, &pci->mem);
> > >
> > > and also a mem_offset, which is something different.
> >
> > As somebody new to PCI, I'm afraid you've lost me here. Are you referring to
> > using pci_add_resource_offset instead, then removing my restriction on
> > having a single resource from the parsing code?
>
> I mean pci_add_resource_offset, but I don't understand what the
> restriction is that you are talking about. To elaborate on the offsets,
> the common case is that the PCI memory space is the same as the
> host physical address space for both MMIO and DMA, while you have
> only one PCI host with a single I/O space range from port 0 to 65536.
>
> If you mandate that, your code is actually correct and you do not
> require an io_offset or mem_offset.
Right, so that's what I've currently been relying on. If I mandate that,
will I be making this driver significantly less useful?
> In practice, there can be various ways that a system requires something
> more complex:
>
> * You can have a memory space range that puts PCI bus address zero
> at the start of the pci->mem resource. In this case, you have
> mem_offset = pci->mem.start. We should probably try not to do
> this, but there is existing hardware doing it.
If it's not the common case, then the generic driver might not need to care
(at least, initially).
> * You might have multiple sections of the PCI bus space mapped
> into CPU physical space. If you want to support legacy VGA
> console, you probably want to map the first 16MB of the bus
> space at an arbitrary location (with the mem_offset as above),
> plus a second, larger section of the bus space with an identity
> mapping (mem_offset_= 0) for all devices other than VGA.
> You'd also need to copy some VGA specific code from arm32 to
> arm64 to actually make this work.
Again, I'd rather cross that bridge (no pun intended) when we decide we want
legacy VGA.
> * If you have two PCI host bridges and each of them comes with
> its own I/O space range starting between 0x0-0xffff, you have
> to map one of them into logical I/O space address 0x10000-0x1ffff
> and set io_offset = 0x10000 for that bus.
Right, this sounds a lot more plausible from the perspective of a generic
driver. Since the current code only allows exactly one I/O space region, we
avoid the issue but I can remove that restriction (that I mentioned earlier)
and offset the region based on the bridge.
> > > This shows once more that the range parser code is suboptimal. So far
> > > every single driver got the I/O space wrong here, because the obvious
> > > way to write this function is also completely wrong.
> >
> > I see you mentioned to Liviu that you should register a logical resource,
> > rather than physical resource returned from the parser. It seems odd that
> > I/O space appears to work with this code as-is (I've tested it on arm using
> > kvmtool by removing the memory bars).
>
> what do you see in /proc/ioports and /proc/iomem then?
bash-4.2# cat /proc/ioports
00006200-000065ff : virtio-pci
00006600-000069ff : virtio-pci
00006a00-00006dff : virtio-pci
00006e00-000071ff : virtio-pci
bash-4.2# cat /proc/iomem
40000000-40ffffff : /pci
41000400-410005ff : virtio-pci
41000c00-41000dff : virtio-pci
41001400-410015ff : virtio-pci
41001c00-41001dff : virtio-pci
80000000-93ffffff : System RAM
80008000-8053df0b : Kernel code
80570000-805c07fb : Kernel data
> > > What you get out of "of_pci_range_to_resource(&range, np, &pci->io)"
> > > is not the resource you want to pass into pci_add_resource()
> > > later.
> >
> > Do I need to open-code the resource translation from phys -> logical?
>
> I think we should have some common infrastructure that lets you
> get this right more easily.
Okey doke, is anybody working on that? (I see the follow up from Jason, but
it's not clear whether that's going to be merged).
Cheers,
Will
^ permalink raw reply
* [PATCH v2 2/9] clk: samsung: Provide common helpers for register save/restore
From: Sylwester Nawrocki @ 2014-02-07 11:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391710616-14226-3-git-send-email-t.figa@samsung.com>
On 06/02/14 19:16, Tomasz Figa wrote:
> As suspend/resume handlers are being moved to SoC specific code, due to
> differencies in suspend/resume handling of particular SoCs, to minimize
> code duplication this patch provides common register save/restore
> helpers that save/restore given list of registers of clock controller.
>
> Signed-off-by: Tomasz Figa <t.figa@samsung.com>
> Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
^ permalink raw reply
* [PATCH v2 1/9] clk: exynos4: Remove remnants of non-DT support
From: Sylwester Nawrocki @ 2014-02-07 11:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391710616-14226-2-git-send-email-t.figa@samsung.com>
On 06/02/14 19:16, Tomasz Figa wrote:
> This patch simplifies a bit clock initialization code by removing
> remnants of non-DT clock initialization, such as reg_base and xom values
> passed in function parameters.
>
> Signed-off-by: Tomasz Figa <t.figa@samsung.com>
> Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
^ permalink raw reply
* [PATCH v2 1/7] ARM: perf_event: Support percpu irqs for the CPU PMU
From: Will Deacon @ 2014-02-07 11:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52D96E5C.4040506@codeaurora.org>
Hi Stephen,
I just remembered about this series.
On Fri, Jan 17, 2014 at 05:54:36PM +0000, Stephen Boyd wrote:
> On 01/17/14 07:04, Will Deacon wrote:
> > Hi Stephen,
> >
> > On Wed, Jan 15, 2014 at 08:54:27PM +0000, Stephen Boyd wrote:
> >> On 01/15, Stephen Boyd wrote:
> >>> diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c
> >>> index 789d846a9184..e76750980b38 100644
> >>> --- a/arch/arm/kernel/perf_event.c
> >>> +++ b/arch/arm/kernel/perf_event.c
> >>> @@ -295,9 +297,15 @@ validate_group(struct perf_event *event)
> >>>
> >>> static irqreturn_t armpmu_dispatch_irq(int irq, void *dev)
> >>> {
> >>> - struct arm_pmu *armpmu = (struct arm_pmu *) dev;
> >>> - struct platform_device *plat_device = armpmu->plat_device;
> >>> - struct arm_pmu_platdata *plat = dev_get_platdata(&plat_device->dev);
> >>> + struct arm_pmu *armpmu;
> >>> + struct platform_device *plat_device;
> >>> + struct arm_pmu_platdata *plat;
> >>> +
> >>> + if (irq_is_percpu(irq))
> >>> + dev = *(struct arm_pmu_cpu **)dev;
> >> Oh. I just realized that struct arm_pmu_cpu doesn't even exist. This
> >> still compiles though because we're dealing with a void pointer.
> >>
> >> Perhaps its better to just do
> >>
> >> dev = *(void **)dev;
> >>
> >> here. Can you fix that up when applying? Otherwise I'll do it on
> >> the next send if there are more comments.
> > Shouldn't that actually be some per_cpu accessor like this_cpu_ptr?
> >
>
> Nope. The genirq layer unwraps the per_cpu pointer and passes it to the
> handler.
I think we resolved all the questions/issues that came up during review.
Please can you send a new version that I can take into my tree for 3.15?
Cheers,
Will
^ 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