* [PATCH 2/2] stih-cec: add hdmi-notifier support
From: Benjamin Gaignard @ 2016-12-14 12:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481720229-7587-1-git-send-email-benjamin.gaignard@linaro.org>
By using the HDMI notifier framework there is no longer any reason
to manually set the physical address. This was the one blocking
issue that prevented this driver from going out of staging, so do
this move as well.
Update the bindings documenting the new hdmi phandle and
update stih410.dtsi and stih407-family.dtsi accordingly.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
---
.../devicetree/bindings/media/stih-cec.txt | 2 ++
arch/arm/boot/dts/stih407-family.dtsi | 12 ---------
arch/arm/boot/dts/stih410.dtsi | 15 ++++++++++-
drivers/staging/media/st-cec/Kconfig | 1 +
drivers/staging/media/st-cec/stih-cec.c | 29 +++++++++++++++++++++-
5 files changed, 45 insertions(+), 14 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/stih-cec.txt b/Documentation/devicetree/bindings/media/stih-cec.txt
index 71c4b2f..7d82121 100644
--- a/Documentation/devicetree/bindings/media/stih-cec.txt
+++ b/Documentation/devicetree/bindings/media/stih-cec.txt
@@ -9,6 +9,7 @@ Required properties:
- pinctrl-names: Contains only one value - "default"
- pinctrl-0: Specifies the pin control groups used for CEC hardware.
- resets: Reference to a reset controller
+ - st,hdmi-handle: Phandle to the HMDI controller
Example for STIH407:
@@ -22,4 +23,5 @@ sti-cec at 094a087c {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_cec0_default>;
resets = <&softreset STIH407_LPM_SOFTRESET>;
+ st,hdmi-handle = <&hdmi>;
};
diff --git a/arch/arm/boot/dts/stih407-family.dtsi b/arch/arm/boot/dts/stih407-family.dtsi
index 8f79b41..ef7c79a 100644
--- a/arch/arm/boot/dts/stih407-family.dtsi
+++ b/arch/arm/boot/dts/stih407-family.dtsi
@@ -756,18 +756,6 @@
<&clk_s_c0_flexgen CLK_ETH_PHY>;
};
- cec: sti-cec at 094a087c {
- compatible = "st,stih-cec";
- reg = <0x94a087c 0x64>;
- clocks = <&clk_sysin>;
- clock-names = "cec-clk";
- interrupts = <GIC_SPI 140 IRQ_TYPE_NONE>;
- interrupt-names = "cec-irq";
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_cec0_default>;
- resets = <&softreset STIH407_LPM_SOFTRESET>;
- };
-
rng10: rng at 08a89000 {
compatible = "st,rng";
reg = <0x08a89000 0x1000>;
diff --git a/arch/arm/boot/dts/stih410.dtsi b/arch/arm/boot/dts/stih410.dtsi
index a3ef734..c98d86e 100644
--- a/arch/arm/boot/dts/stih410.dtsi
+++ b/arch/arm/boot/dts/stih410.dtsi
@@ -193,7 +193,7 @@
<&clk_s_d2_quadfs 0>;
};
- sti-hdmi at 8d04000 {
+ hdmi: sti-hdmi at 8d04000 {
compatible = "st,stih407-hdmi";
reg = <0x8d04000 0x1000>;
reg-names = "hdmi-reg";
@@ -259,5 +259,18 @@
clocks = <&clk_sysin>;
interrupts = <GIC_SPI 205 IRQ_TYPE_EDGE_RISING>;
};
+
+ sti-cec at 094a087c {
+ compatible = "st,stih-cec";
+ reg = <0x94a087c 0x64>;
+ clocks = <&clk_sysin>;
+ clock-names = "cec-clk";
+ interrupts = <GIC_SPI 140 IRQ_TYPE_NONE>;
+ interrupt-names = "cec-irq";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_cec0_default>;
+ resets = <&softreset STIH407_LPM_SOFTRESET>;
+ st,hdmi-handle = <&hdmi>;
+ };
};
};
diff --git a/drivers/staging/media/st-cec/Kconfig b/drivers/staging/media/st-cec/Kconfig
index 784d2c6..3072387 100644
--- a/drivers/staging/media/st-cec/Kconfig
+++ b/drivers/staging/media/st-cec/Kconfig
@@ -1,6 +1,7 @@
config VIDEO_STI_HDMI_CEC
tristate "STMicroelectronics STiH4xx HDMI CEC driver"
depends on VIDEO_DEV && MEDIA_CEC && (ARCH_STI || COMPILE_TEST)
+ select HDMI_NOTIFIERS
---help---
This is a driver for STIH4xx HDMI CEC interface. It uses the
generic CEC framework interface.
diff --git a/drivers/staging/media/st-cec/stih-cec.c b/drivers/staging/media/st-cec/stih-cec.c
index 2143448..ce94097 100644
--- a/drivers/staging/media/st-cec/stih-cec.c
+++ b/drivers/staging/media/st-cec/stih-cec.c
@@ -10,11 +10,13 @@
* (at your option) any later version.
*/
#include <linux/clk.h>
+#include <linux/hdmi-notifier.h>
#include <linux/interrupt.h>
#include <linux/kernel.h>
#include <linux/mfd/syscon.h>
#include <linux/module.h>
#include <linux/of.h>
+#include <linux/of_platform.h>
#include <linux/platform_device.h>
#include <linux/version.h>
@@ -130,6 +132,7 @@ struct stih_cec {
void __iomem *regs;
int irq;
u32 irq_status;
+ struct hdmi_notifier *notifier;
};
static int stih_cec_adap_enable(struct cec_adapter *adap, bool enable)
@@ -304,12 +307,29 @@ static int stih_cec_probe(struct platform_device *pdev)
struct device *dev = &pdev->dev;
struct resource *res;
struct stih_cec *cec;
+ struct device_node *np;
+ struct platform_device *hdmi_dev;
int ret;
cec = devm_kzalloc(dev, sizeof(*cec), GFP_KERNEL);
if (!cec)
return -ENOMEM;
+ np = of_parse_phandle(pdev->dev.of_node, "st,hdmi-handle", 0);
+
+ if (!np) {
+ dev_err(&pdev->dev, "Failed to find hdmi node in device tree\n");
+ return -ENODEV;
+ }
+
+ hdmi_dev = of_find_device_by_node(np);
+ if (!hdmi_dev)
+ return -EPROBE_DEFER;
+
+ cec->notifier = hdmi_notifier_get(&hdmi_dev->dev);
+ if (!cec->notifier)
+ return -ENOMEM;
+
cec->dev = dev;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -336,7 +356,7 @@ static int stih_cec_probe(struct platform_device *pdev)
cec->adap = cec_allocate_adapter(&sti_cec_adap_ops, cec,
CEC_NAME,
CEC_CAP_LOG_ADDRS | CEC_CAP_PASSTHROUGH |
- CEC_CAP_PHYS_ADDR | CEC_CAP_TRANSMIT,
+ CEC_CAP_TRANSMIT,
1, &pdev->dev);
ret = PTR_ERR_OR_ZERO(cec->adap);
if (ret)
@@ -348,12 +368,19 @@ static int stih_cec_probe(struct platform_device *pdev)
return ret;
}
+ cec_register_hdmi_notifier(cec->adap, cec->notifier);
+
platform_set_drvdata(pdev, cec);
return 0;
}
static int stih_cec_remove(struct platform_device *pdev)
{
+ struct stih_cec *cec = platform_get_drvdata(pdev);
+
+ cec_unregister_adapter(cec->adap);
+ hdmi_notifier_put(cec->notifier);
+
return 0;
}
--
1.9.1
^ permalink raw reply related
* [PATCH v6 1/8] MFD: add bindings for STM32 Timers driver
From: Benjamin Gaignard @ 2016-12-14 13:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_Jsq+qzhUAMG_jL6CSHz+kHu6M6N8Nko4KfRQRgRgtk-KTKg@mail.gmail.com>
2016-12-13 22:07 GMT+01:00 Rob Herring <robh@kernel.org>:
> On Tue, Dec 13, 2016 at 3:29 AM, Benjamin Gaignard
> <benjamin.gaignard@linaro.org> wrote:
>> 2016-12-12 19:51 GMT+01:00 Rob Herring <robh@kernel.org>:
>>> On Fri, Dec 09, 2016 at 03:15:12PM +0100, Benjamin Gaignard wrote:
>>>> Add bindings information for STM32 Timers
>>>>
>>>> version 6:
>>>> - rename stm32-gtimer to stm32-timers
>>>> - change compatible
>>>> - add description about the IPs
>>>>
>>>> version 2:
>>>> - rename stm32-mfd-timer to stm32-gptimer
>>>> - only keep one compatible string
>>>>
>>>> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
>>>> ---
>>>> .../devicetree/bindings/mfd/stm32-timers.txt | 46 ++++++++++++++++++++++
>>>> 1 file changed, 46 insertions(+)
>>>> create mode 100644 Documentation/devicetree/bindings/mfd/stm32-timers.txt
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/mfd/stm32-timers.txt b/Documentation/devicetree/bindings/mfd/stm32-timers.txt
>>>> new file mode 100644
>>>> index 0000000..b30868e
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/mfd/stm32-timers.txt
>>>> @@ -0,0 +1,46 @@
>>>> +STM32 Timers driver bindings
>>>> +
>>>> +This IP provides 3 types of timer along with PWM functionality:
>>>> +- advanced-control timers consist of a 16-bit auto-reload counter driven by a programmable
>>>> + prescaler, break input feature, PWM outputs and complementary PWM ouputs channels.
>>>> +- general-purpose timers consist of a 16-bit or 32-bit auto-reload counter driven by a
>>>> + programmable prescaler and PWM outputs.
>>>> +- basic timers consist of a 16-bit auto-reload counter driven by a programmable prescaler.
>>>> +
>>>> +Required parameters:
>>>> +- compatible: must be "st,stm32-timers"
>>>> +
>>>> +- reg: Physical base address and length of the controller's
>>>> + registers.
>>>> +- clock-names: Set to "clk_int".
>>>
>>> 'clk' is redundant. Also, you don't really need -names when there is
>>> only one of them.
>>
>> I use devm_regmap_init_mmio_clk() which get the clock by it name so
>> I have to define it in DT.
>
> Are you sure NULL is not allowed? I don't know, but at least clk_get()
> allows NULL.
regmap_mmio_gen_context() doesn't call clk_get() if the clock name isn't set:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/base/regmap/regmap-mmio.c?id=refs/tags/v4.9#n308
so clock-names field is really needed.
> It's fine to keep, just drop the "clk_" part.
ok
>
>>
>>>> +- clocks: Phandle to the clock used by the timer module.
>>>> + For Clk properties, please refer to ../clock/clock-bindings.txt
>>>> +
>>>> +Optional parameters:
>>>> +- resets: Phandle to the parent reset controller.
>>>> + See ../reset/st,stm32-rcc.txt
>>>> +
>>>> +Optional subnodes:
>>>> +- pwm: See ../pwm/pwm-stm32.txt
>>>> +- timer: See ../iio/timer/stm32-timer-trigger.txt
>>>> +
>>>> +Example:
>>>> + timers at 40010000 {
>>>> + #address-cells = <1>;
>>>> + #size-cells = <0>;
>>>> + compatible = "st,stm32-timers";
>>>> + reg = <0x40010000 0x400>;
>>>> + clocks = <&rcc 0 160>;
>>>> + clock-names = "clk_int";
>>>> +
>>>> + pwm {
>>>> + compatible = "st,stm32-pwm";
>>>> + pinctrl-0 = <&pwm1_pins>;
>>>> + pinctrl-names = "default";
>>>> + };
>>>> +
>>>> + timer {
>>>> + compatible = "st,stm32-timer-trigger";
>>>> + reg = <0>;
>>>
>>> You don't need reg here as there is only one. In turn, you don't need
>>> #address-cells or #size-cells.
>>
>> I use "reg" to set each timer configuration.
>> From hardware point of view they are all the same except for which hardware
>> signals they could consume and/or send.
>
> This sounds okay, but...
>
>> "reg" is used as index of the two tables in driver code.
>
> this statement doesn't really sound like valid use of reg.
>
> If you keep reg, then the node needs a unit address (timer at 0).
I will do that in next version but I will wait for other maintainers (PWM/IIO)
remarks before send it
Thanks
Benjamin
>
> Rob
--
Benjamin Gaignard
Graphic Study Group
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH linux v1 0/4] Seven segment display support
From: Neil Armstrong @ 2016-12-14 13:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161214125641.GA5379@kroah.com>
On 12/14/2016 01:56 PM, Greg KH wrote:
> On Wed, Dec 14, 2016 at 01:45:30PM +0100, Thomas Petazzoni wrote:
>> Hello,
>>
>> On Tue, 13 Dec 2016 23:55:00 -0800, Jaghathiswari Rankappagounder
>> Natarajan wrote:
>>
>>> Documentation for the binding which provides an interface for adding clock,
>>> data and clear signal GPIO lines to control seven segment display.
>>>
>>> The platform device driver provides an API for displaying on two 7-segment
>>> displays, and implements the required bit-banging. The hardware assumed is
>>> 74HC164 wired to two 7-segment displays.
>>>
>>> The character device driver implements the user-space API for letting a user
>>> write to two 7-segment displays including any conversion methods necessary
>>> to map the user input to two 7-segment displays.
>>>
>>> Adding clock, data and clear signal GPIO lines in the devicetree to control
>>> seven segment display on zaius platform.
>>>
>>> The platform driver matches on the device tree node; the platform driver also
>>> initializes the character device.
>>>
>>> Tested that the seven segment display works properly by writing to the
>>> character device file on a EVB AST2500 board which also has 74HC164 wired
>>> to two 7-segment displays.
>>
>> FWIW, I proposed a driver for seven segment displays back in 2013:
>>
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-January/139986.html
>>
>> And the feedback from Greg KH was: we don't need a driver for that, do
>> it from userspace. See:
>>
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-January/139992.html
>>
>> So: good luck :-)
>
> Did anyone ever write a library for this type of thing?
>
> Again, I don't want to see one-off drivers for random devices like this
> that should be able to all be controlled from userspace in a common
> manner. Much like we did for fingerprint readers a long long time
> ago...
>
> thanks,
>
> greg k-h
Hi Greg,
Actually, it's more than a random interface, a lot of SoCs and boards actually have such displays
and it's a pity to use UIO, sysfs gpio bitbanging and all sort of ugly stuff to only print a few
characters a simple and clean driver could achieve.
Some very well known SoCs even have integrated registers to lower the BOM and bypass the need for
a 74HC164 like component and avoid gpio bit banging.
My personal concern is that you could also need to drive more segments, thus 7-segments
is too restrictive.
But this driver is well structured, the gpio-bitbanging sub-driver is welcome.
Neil
^ permalink raw reply
* [PATCH] ARM: dts: Add missing CPU frequencies for Exynos5422/5800
From: Bartlomiej Zolnierkiewicz @ 2016-12-14 13:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <26ffeee4-ff43-b3d3-3267-5fcbc50e2974@osg.samsung.com>
On Tuesday, December 13, 2016 04:18:05 PM Javier Martinez Canillas wrote:
> Hello Bartlomiej,
Hi,
> On 12/13/2016 01:52 PM, Bartlomiej Zolnierkiewicz wrote:
> > Add missing 2000MHz & 1900MHz OPPs (for A15 cores) and 1400MHz OPP
> > (for A7 cores). Also update common Odroid-XU3 Lite/XU3/XU4 thermal
> > cooling maps to account for new OPPs.
> >
> > Since new OPPs are not available on all Exynos5422/5800 boards modify
> > dts files for Odroid-XU3 Lite (limited to 1.8 GHz / 1.3 GHz) & Peach
> > Pi (limited to 2.0 GHz / 1.3 GHz) accordingly.
> >
> > Tested on Odroid-XU3 and XU3 Lite.
> >
> > Cc: Doug Anderson <dianders@chromium.org>
> > Cc: Javier Martinez Canillas <javier@osg.samsung.com>
> > Cc: Andreas Faerber <afaerber@suse.de>
> > Cc: Thomas Abraham <thomas.ab@samsung.com>
> > Cc: Ben Gamari <ben@smart-cactus.org>
> > Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> > ---
> > arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 14 +++++++-------
> > arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts | 17 +++++++++++++++++
> > arch/arm/boot/dts/exynos5800-peach-pi.dts | 4 ++++
> > arch/arm/boot/dts/exynos5800.dtsi | 15 +++++++++++++++
> > 4 files changed, 43 insertions(+), 7 deletions(-)
> >
> > Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> > ===================================================================
> > --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-13 15:59:33.779763261 +0100
> > +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-13 15:59:33.775763261 +0100
> > @@ -118,7 +118,7 @@
> > /*
> > * When reaching cpu_alert3, reduce CPU
> > * by 2 steps. On Exynos5422/5800 that would
> > - * be: 1600 MHz and 1100 MHz.
> > + * (usually) be: 1800 MHz and 1200 MHz.
> > */
> > map3 {
> > trip = <&cpu_alert3>;
> > @@ -131,16 +131,16 @@
> >
> > /*
> > * When reaching cpu_alert4, reduce CPU
> > - * further, down to 600 MHz (11 steps for big,
> > - * 7 steps for LITTLE).
> > + * further, down to 600 MHz (13 steps for big,
> > + * 8 steps for LITTLE).
> > */
> > - map5 {
> > + cooling_map5: map5 {
> > trip = <&cpu_alert4>;
> > - cooling-device = <&cpu0 3 7>;
> > + cooling-device = <&cpu0 3 8>;
> > };
> > - map6 {
> > + cooling_map6: map6 {
> > trip = <&cpu_alert4>;
> > - cooling-device = <&cpu4 3 11>;
> > + cooling-device = <&cpu4 3 13>;
> > };
> > };
> > };
> > Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts
> > ===================================================================
> > --- a/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-13 15:59:33.779763261 +0100
> > +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-13 15:59:33.775763261 +0100
> > @@ -21,6 +21,23 @@
> > compatible = "hardkernel,odroid-xu3-lite", "samsung,exynos5800", "samsung,exynos5";
> > };
> >
> > +&cluster_a15_opp_table {
> > + /delete-node/opp at 2000000000;
> > + /delete-node/opp at 1900000000;
> > +};
> > +
> > +&cluster_a7_opp_table {
> > + /delete-node/opp at 1400000000;
> > +};
> > +
>
> I think that a comment in the DTS why these operating points aren't available
> in this board will make more clear why the nodes are being deleted.
Ok, I will add these comments in the next patch revision.
> > +&cooling_map5 {
> > + cooling-device = <&cpu0 3 7>;
> > +};
> > +
> > +&cooling_map6 {
> > + cooling-device = <&cpu4 3 11>;
> > +};
> > +
> > &pwm {
> > /*
> > * PWM 0 -- fan
> > Index: b/arch/arm/boot/dts/exynos5800-peach-pi.dts
> > ===================================================================
> > --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-13 15:59:33.779763261 +0100
> > +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-13 15:59:33.779763261 +0100
> > @@ -146,6 +146,10 @@
> > vdd-supply = <&ldo9_reg>;
> > };
> >
> > +&cluster_a7_opp_table {
> > + /delete-property/opp at 1400000000;
> > +};
> > +
> > &cpu0 {
> > cpu-supply = <&buck2_reg>;
> > };
> > Index: b/arch/arm/boot/dts/exynos5800.dtsi
> > ===================================================================
> > --- a/arch/arm/boot/dts/exynos5800.dtsi 2016-12-13 15:59:33.779763261 +0100
> > +++ b/arch/arm/boot/dts/exynos5800.dtsi 2016-12-13 15:59:33.779763261 +0100
> > @@ -24,6 +24,16 @@
> > };
> >
> > &cluster_a15_opp_table {
> > + opp at 2000000000 {
> > + opp-hz = /bits/ 64 <2000000000>;
> > + opp-microvolt = <1250000>;
> > + clock-latency-ns = <140000>;
> > + };
> > + opp at 1900000000 {
> > + opp-hz = /bits/ 64 <1900000000>;
> > + opp-microvolt = <1250000>;
> > + clock-latency-ns = <140000>;
> > + };
> > opp at 1700000000 {
> > opp-microvolt = <1250000>;
> > };
> > @@ -85,6 +95,11 @@
> > };
> >
>
> AFAIK Thomas restricted the maximum OPP, because for A15 freqs > 1.8GHz the
> INT rail would need to be scaled up as well since there's a maximum voltage
> difference between the ARM and INT rails before the system becomes unstable:
>
> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/276766.html
> https://lkml.org/lkml/2014/5/2/419
>
> The ChromiumOS vendor tree uses a virtual regulator driver that makes sure
> the maximum voltage skew is between a limit. But that never made to mainline:
>
> https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/arch/arm/boot/dts/exynos5420-peach-pit.dtsi#90
> https://lkml.org/lkml/2014/4/29/28
>
> Did that change and there's infrastructure in mainline now to cope with that?
> If that's the case, I think it would be good to mention in the commit message.
I was not aware of this limitation and AFAIK mainline has currently
no code to handle it. I also cannot find any code to handle this in
Hardkernel's vendor kernel for Odroid-XU3 board.
Do you know whether this problem exists also on Exynos5422/5800
SoCs or only on Exynos5420 one? I see that ChromiumOS uses virtual
regulator code also on Exynos5800 SoC based Peach Pi board but was
the problem actually present on this board?
[ I added Arjun to Cc:, maybe he can help in explaining this issue
(unfortunately Inderpal's email is no longer working). ]
Please also note that on Exynos5422/5800 SoCs the same ARM rail
voltage is used for 1.9 GHz & 2.0 GHz OPPs as for the 1.8 GHz one.
IOW if the problem exists it is already present in the mainline
kernel.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
^ permalink raw reply
* partial bluetooth success on n900 [was Re: bluetooth/uart timeout handling]
From: Sebastian Reichel @ 2016-12-14 13:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161214125323.GA4951@amd>
Hi Pali & Pavel,
On Wed, Dec 14, 2016 at 01:53:23PM +0100, Pavel Machek wrote:
> > > [ 220.248596] tty ttyO1: Radio packet sent
> > > [ 220.249328] Bluetooth: hci0: Frame reassembly failed (-84)
> > > [ 220.272949] tty ttyO1: wakeup received: 1 -> 0
> > > [ 221.283477] tty ttyO1: radio packet timeout!
> > > [ 221.283630] enqueue: hu c304cc80 skb cd4a9b40
> > > [ 223.363372] Bluetooth: hci0 command 0xfc18 tx timeout
> > > pavel at n900:~$
> >
> > In log are still some failures, but ... is bluetooth working now?
I could scan for devices. The code is still racy, though. It's
most likely related to the newly introduced idle code. (Without
sending the BT module to correctly idle the bcm2048 does not
work correctly at all)
I was quite busy the last few weeks and did not manage to find
much time for kernel work. Now I will first have to catch up
with my power-supply tree.
> It is... for Sebastian. I'm playing with camera now.
>
> > I see that you applied this patch:
> > https://git.kernel.org/cgit/linux/kernel/git/pavel/linux-n900.git/commit/?id=051aa3fbf03ac770d8344690f5a936a7f04c6884
> >
> > Looks like that pinmux is in DTS file incorrect. Can somebody verify it?
> > Maybe Tony?
>
> Yes, it is. Sebastian was pretty certain about that.
Yes, I'm certain. The bootloader enables the pullup resistors.
Note, that the wrong DTS entry is not in mainline. My bluetooth
branch has a fixed DTS patch instead of a fixup patch on top of
the broken one:
https://git.kernel.org/cgit/linux/kernel/git/sre/linux-n900.git/commit/?h=nokia-bluetooth-dev&id=6b63c111a979d100cfbdd76cb4a6bbadace35216
-- Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161214/28d87fe2/attachment.sig>
^ permalink raw reply
* [PATCHv6] support for AD5820 camera auto-focus coil
From: Pali Rohár @ 2016-12-14 13:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160808214132.GB2946@xo-6d-61-c0.localdomain>
On Monday 08 August 2016 23:41:32 Pavel Machek wrote:
> On Mon 2016-08-08 11:09:56, Sakari Ailus wrote:
> > On Fri, Aug 05, 2016 at 12:26:11PM +0200, Pavel Machek wrote:
> > > This adds support for AD5820 autofocus coil, found for example in
> > > Nokia N900 smartphone.
> >
> > Thanks, Pavel!
> >
> > Let's use V4L2_CID_FOCUS_ABSOLUTE, as is in the patch. If we get
> > something better in the future, we'll switch to that then.
> >
> > I've applied this to ad5820 branch in my tree.
>
> Thanks. If I understands things correctly, both DTS patch and this
> patch are waiting in your tree, so we should be good to go for 4.9
> (unless some unexpected problems surface)?
>
> Best regards,
> Pavel
Was DTS patch merged into 4.9? At least I do not see updated that dts
file omap3-n900.dts in linus tree...
--
Pali Roh?r
pali.rohar at gmail.com
-------------- 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/20161214/d8addaf7/attachment-0001.sig>
^ permalink raw reply
* [PATCH 2/2] ARM: soft-reboot into same mode that we entered the kernel
From: Marc Zyngier @ 2016-12-14 13:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161214120541.GD14217@n2100.armlinux.org.uk>
On 14/12/16 12:05, Russell King - ARM Linux wrote:
> On Wed, Dec 14, 2016 at 11:56:49AM +0000, Mark Rutland wrote:
>> On Wed, Dec 14, 2016 at 10:46:35AM +0000, Russell King wrote:
>>> When we soft-reboot (eg, kexec) from one kernel into the next, we need
>>> to ensure that we enter the new kernel in the same processor mode as
>>> when we were entered, so that (eg) the new kernel can install its own
>>> hypervisor - the old kernel's hypervisor will have been overwritten.
>>>
>>> In order to do this, we need to pass a flag to cpu_reset() so it knows
>>> what to do, and we need to modify the kernel's own hypervisor stub to
>>> allow it to handle a soft-reboot.
>>>
>>> As we are always guaranteed to install our own hypervisor if we're
>>> entered in HYP32 mode, and KVM will have moved itself out of the way
>>> on kexec/normal reboot, we can assume that our hypervisor is in place
>>> when we want to kexec, so changing our hypervisor API should not be a
>>> problem.
>>
>> Just to check, does that also hold true for kdump?
>>
>> I haven't gone digging yet, but it looks like KVM might still be
>> installed, rather than the hyp stub, and we might need some logic to
>> ensure that it's torn down...
>
> The same problem will be true of ARM64 - I don't see any solution to
> that in the present state.
>
>>> @@ -51,7 +52,9 @@ static void __soft_restart(void *addr)
>>>
>>> /* Switch to the identity mapping. */
>>> phys_reset = (phys_reset_t)virt_to_idmap(cpu_reset);
>>> - phys_reset((unsigned long)addr);
>>> +
>>> + /* original stub should be restored by kvm */
>>> + phys_reset((unsigned long)addr, is_hyp_mode_available());
>>
>> ... otherwise here we'd call into the KVM hyp code in a potentially
>> confusing manner.
>>
>> Otherwise, this looks fine to me.
>
> The only thing that I can think which would resolve that would be to
> lay down a standard API for the hyp code, so things like reboot into
> hyp mode can work irrespective of the hyp stub in place.
That looks like a sensible thing to do. I'll look into it.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH 1/2] arm64: Add enable/disable d-cache support for purgatory
From: Mark Rutland @ 2016-12-14 13:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3a6ac655-bfa6-0d90-6351-731ce36e99eb@redhat.com>
Hi,
On Wed, Dec 14, 2016 at 05:51:05PM +0530, Pratyush Anand wrote:
>
> On Wednesday 14 December 2016 05:07 PM, Mark Rutland wrote:
> >I see in an earlier message that the need for sha256 was being discussed
> >in another thread. Do either of you happen to have a pointer to that.
>
> patch 0/2 of this series.
AFAICT, that just says the the existing sha256 check is slow, not *why*
a sha256 check of some description is necessary. I'm still at a loss as
to why it is considered necessary, rather than being a debugging aid or
sanity check.
> >To me, it seems like it doesn't come with much benefit for the kdump
> >case given that's best-effort anyway, and as above the verification code
> >could have been be corrupted. In the non-kdump case it's not strictly
> >necessary and seems like a debugging aid rather than a necessary piece
> >of functionality -- if that's the case, a 20 second delay isn't the end
> >of the world...
>
> Even for the non-kdump ie `kexec -l` case we do not have a
> functionality to bypass sha verification in kexec-tools. --lite
> option with the kexec-tools was discouraged and not accepted.
Ok. Do you have a pointer to the thread regarding that, for context?
> So,it is 20s for both `kexec -l` and `kexec -p`.
Well, unless we can have a --{no-,}sha-check, and make the default NO
for arm64.
> Also other arch like x86_64 takes negligible time in sha verification.
That's certainly an argument for not changing the other architectures,
but given it's slow for arm64, we could have a different default...
Thanks,
Mark.
^ permalink raw reply
* [PATCH v2 2/2] mfd: axp20x: Fix AXP806 access errors on cold boot
From: Chen-Yu Tsai @ 2016-12-14 13:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161213164742.4ztisstxifatlm5a@sirena.org.uk>
On Wed, Dec 14, 2016 at 12:47 AM, Mark Brown <broonie@kernel.org> wrote:
> On Fri, Dec 09, 2016 at 11:20:18AM +0000, Lee Jones wrote:
>
>> Is the following valid/necessary?
>
>> On Wed, 23 Nov 2016, Chen-Yu Tsai wrote:
>> > The AXP806 supports either master/standalone or slave mode.
>> > Slave mode allows sharing the serial bus, even with multiple
>> > AXP806 which all have the same hardware address.
>
>> > This is done with extra "serial interface address extension",
>> > or AXP806_BUS_ADDR_EXT, and "register address extension", or
>> > AXP806_REG_ADDR_EXT, registers. The former is read-only, with
>> > 1 bit customizable at the factory, and 1 bit depending on the
>
> I don't really know anything about the details of this chip, sorry.
If these 2 registers don't match, any access to the other registers
is ignored, so the kernel either read bogus data, or the read fails.
What this patch does is make sure the registers match, to guarantee
access, and then reinitialize the regmap cache to get rid of any
stale data.
>> > This patch sets AXP806_REG_ADDR_EXT to 0x10, which is what we
>> > know to be the proper value for a standard AXP806 in slave mode.
>> > Afterwards it will reinitialize the regmap cache, to purge any
>> > invalid stale values.
>
> If the chip has been reset then you'd want to reset the cache too. I've
> no idea if that's needed here or not though, it depends what happens to
> the global state of the chip when this reconfiguration happens.
It is not a reset in the general sense. I suppose a better way would
be to do an explicit write to the register first, then initialize
the regmap. I'd have to export the write function from the RSB bus
driver first though.
Regards
ChenYu
^ permalink raw reply
* [PATCH] ARM: dts: Add missing CPU frequencies for Exynos5422/5800
From: Javier Martinez Canillas @ 2016-12-14 14:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2340115.HEG9AYUCMD@amdc3058>
Hello Bartlomiej,
On 12/14/2016 10:28 AM, Bartlomiej Zolnierkiewicz wrote:
>
> On Tuesday, December 13, 2016 04:18:05 PM Javier Martinez Canillas wrote:
>> Hello Bartlomiej,
>
> Hi,
>
>> On 12/13/2016 01:52 PM, Bartlomiej Zolnierkiewicz wrote:
>>> Add missing 2000MHz & 1900MHz OPPs (for A15 cores) and 1400MHz OPP
>>> (for A7 cores). Also update common Odroid-XU3 Lite/XU3/XU4 thermal
>>> cooling maps to account for new OPPs.
>>>
>>> Since new OPPs are not available on all Exynos5422/5800 boards modify
>>> dts files for Odroid-XU3 Lite (limited to 1.8 GHz / 1.3 GHz) & Peach
>>> Pi (limited to 2.0 GHz / 1.3 GHz) accordingly.
>>>
>>> Tested on Odroid-XU3 and XU3 Lite.
>>>
>>> Cc: Doug Anderson <dianders@chromium.org>
>>> Cc: Javier Martinez Canillas <javier@osg.samsung.com>
>>> Cc: Andreas Faerber <afaerber@suse.de>
>>> Cc: Thomas Abraham <thomas.ab@samsung.com>
>>> Cc: Ben Gamari <ben@smart-cactus.org>
>>> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
>>> ---
>>> arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 14 +++++++-------
>>> arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts | 17 +++++++++++++++++
>>> arch/arm/boot/dts/exynos5800-peach-pi.dts | 4 ++++
>>> arch/arm/boot/dts/exynos5800.dtsi | 15 +++++++++++++++
>>> 4 files changed, 43 insertions(+), 7 deletions(-)
>>>
>>> Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>> ===================================================================
>>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-13 15:59:33.779763261 +0100
>>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-13 15:59:33.775763261 +0100
>>> @@ -118,7 +118,7 @@
>>> /*
>>> * When reaching cpu_alert3, reduce CPU
>>> * by 2 steps. On Exynos5422/5800 that would
>>> - * be: 1600 MHz and 1100 MHz.
>>> + * (usually) be: 1800 MHz and 1200 MHz.
>>> */
>>> map3 {
>>> trip = <&cpu_alert3>;
>>> @@ -131,16 +131,16 @@
>>>
>>> /*
>>> * When reaching cpu_alert4, reduce CPU
>>> - * further, down to 600 MHz (11 steps for big,
>>> - * 7 steps for LITTLE).
>>> + * further, down to 600 MHz (13 steps for big,
>>> + * 8 steps for LITTLE).
>>> */
>>> - map5 {
>>> + cooling_map5: map5 {
>>> trip = <&cpu_alert4>;
>>> - cooling-device = <&cpu0 3 7>;
>>> + cooling-device = <&cpu0 3 8>;
>>> };
>>> - map6 {
>>> + cooling_map6: map6 {
>>> trip = <&cpu_alert4>;
>>> - cooling-device = <&cpu4 3 11>;
>>> + cooling-device = <&cpu4 3 13>;
>>> };
>>> };
>>> };
>>> Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts
>>> ===================================================================
>>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-13 15:59:33.779763261 +0100
>>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-13 15:59:33.775763261 +0100
>>> @@ -21,6 +21,23 @@
>>> compatible = "hardkernel,odroid-xu3-lite", "samsung,exynos5800", "samsung,exynos5";
>>> };
>>>
>>> +&cluster_a15_opp_table {
>>> + /delete-node/opp at 2000000000;
>>> + /delete-node/opp at 1900000000;
>>> +};
>>> +
>>> +&cluster_a7_opp_table {
>>> + /delete-node/opp at 1400000000;
>>> +};
>>> +
>>
>> I think that a comment in the DTS why these operating points aren't available
>> in this board will make more clear why the nodes are being deleted.
>
> Ok, I will add these comments in the next patch revision.
>
>>> +&cooling_map5 {
>>> + cooling-device = <&cpu0 3 7>;
>>> +};
>>> +
>>> +&cooling_map6 {
>>> + cooling-device = <&cpu4 3 11>;
>>> +};
>>> +
>>> &pwm {
>>> /*
>>> * PWM 0 -- fan
>>> Index: b/arch/arm/boot/dts/exynos5800-peach-pi.dts
>>> ===================================================================
>>> --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-13 15:59:33.779763261 +0100
>>> +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-13 15:59:33.779763261 +0100
>>> @@ -146,6 +146,10 @@
>>> vdd-supply = <&ldo9_reg>;
>>> };
>>>
>>> +&cluster_a7_opp_table {
>>> + /delete-property/opp at 1400000000;
>>> +};
>>> +
>>> &cpu0 {
>>> cpu-supply = <&buck2_reg>;
>>> };
>>> Index: b/arch/arm/boot/dts/exynos5800.dtsi
>>> ===================================================================
>>> --- a/arch/arm/boot/dts/exynos5800.dtsi 2016-12-13 15:59:33.779763261 +0100
>>> +++ b/arch/arm/boot/dts/exynos5800.dtsi 2016-12-13 15:59:33.779763261 +0100
>>> @@ -24,6 +24,16 @@
>>> };
>>>
>>> &cluster_a15_opp_table {
>>> + opp at 2000000000 {
>>> + opp-hz = /bits/ 64 <2000000000>;
>>> + opp-microvolt = <1250000>;
>>> + clock-latency-ns = <140000>;
>>> + };
>>> + opp at 1900000000 {
>>> + opp-hz = /bits/ 64 <1900000000>;
>>> + opp-microvolt = <1250000>;
>>> + clock-latency-ns = <140000>;
>>> + };
>>> opp at 1700000000 {
>>> opp-microvolt = <1250000>;
>>> };
>>> @@ -85,6 +95,11 @@
>>> };
>>>
>>
>> AFAIK Thomas restricted the maximum OPP, because for A15 freqs > 1.8GHz the
>> INT rail would need to be scaled up as well since there's a maximum voltage
>> difference between the ARM and INT rails before the system becomes unstable:
>>
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/276766.html
>> https://lkml.org/lkml/2014/5/2/419
>>
>> The ChromiumOS vendor tree uses a virtual regulator driver that makes sure
>> the maximum voltage skew is between a limit. But that never made to mainline:
>>
>> https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/arch/arm/boot/dts/exynos5420-peach-pit.dtsi#90
>> https://lkml.org/lkml/2014/4/29/28
>>
>> Did that change and there's infrastructure in mainline now to cope with that?
>> If that's the case, I think it would be good to mention in the commit message.
>
> I was not aware of this limitation and AFAIK mainline has currently
> no code to handle it. I also cannot find any code to handle this in
Yes, that's what I thought as well but maybe I was missing something.
> Hardkernel's vendor kernel for Odroid-XU3 board.
>
> Do you know whether this problem exists also on Exynos5422/5800
> SoCs or only on Exynos5420 one? I see that ChromiumOS uses virtual
> regulator code also on Exynos5800 SoC based Peach Pi board but was
> the problem actually present on this board?
>
My understanding is that this problem is present in 5420/5422/5800
but I have no way to confirm this. I'm just guessing from the info
in the ChromiumOS vendor tree.
If you look at the commit that added the regulator-locker driver,
the test says to be done in a Peach Pi so it seems the problem is
not restricted to only Exynos5420:
https://chromium.googlesource.com/chromiumos/third_party/kernel/+/ba63620feace4eaed5572ac2e77d8d61754af704
> [ I added Arjun to Cc:, maybe he can help in explaining this issue
> (unfortunately Inderpal's email is no longer working). ]
>
Added Abhilash to cc list as well since he was involved in the Exynos ChromeOS tree.
> Please also note that on Exynos5422/5800 SoCs the same ARM rail
> voltage is used for 1.9 GHz & 2.0 GHz OPPs as for the 1.8 GHz one.
> IOW if the problem exists it is already present in the mainline
> kernel.
>
Ah, I only looked at your patch and I didn't compare the voltage levels
in your 1.9 GHz and 2.0 GHz OPPs with the current 1.8 GHz in mainline.
I wonder if the voltage levels in your patch are correct then, since the
ChromiumOS tree uses a higher voltages for the 1.9 GHz and 2.0 GHz OPPs:
/*
* Default ASV table
*/
static const unsigned int asv_voltage_5420[CPUFREQ_NUM_LEVELS] = {
1362500, /* L0 2100 */
1312500, /* L1 2000 */
1275000, /* L2 1900 */
1225000, /* L3 1800 */
1200000, /* L4 1700 */
This is from https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/drivers/cpufreq/exynos5420-cpufreq.c#175
> Best regards,
> --
> Bartlomiej Zolnierkiewicz
> Samsung R&D Institute Poland
> Samsung Electronics
>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* [PATCH] ARM: dts: sunxi: Change node name for pwrseq pin on Olinuxino-lime2-emmc
From: Maxime Ripard @ 2016-12-14 14:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161214100856.23735-1-manu@bidouilliste.com>
Hi Emmanuel,
On Wed, Dec 14, 2016 at 11:08:56AM +0100, Emmanuel Vadot wrote:
> The node name for the power seq pin is mmc2 at 0 like the mmc2_pins_a one.
> This makes the original node (mmc2_pins_a) scrapped out of the dtb and
> result in a unusable eMMC if U-Boot didn't configured the pins to the
> correct functions.
>
> Signed-off-by: Emmanuel Vadot <manu@bidouilliste.com>
> ---
> arch/arm/boot/dts/sun7i-a20-olinuxino-lime2-emmc.dts | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2-emmc.dts b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2-emmc.dts
> index 5ea4915..68cb1b5 100644
> --- a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2-emmc.dts
> +++ b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2-emmc.dts
> @@ -56,7 +56,7 @@
> };
>
> &pio {
> - mmc2_pins_nrst: mmc2 at 0 {
> + mmc2_pins_nrst: mmc2 at 1 {
That would be even better if you renamed it to something like
mmc2-rst-pin to avoid all future conflicts (for example if we ever add
a second mmc pins groups.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161214/a7d1b197/attachment-0001.sig>
^ permalink raw reply
* [PATCH 1/2] arm64: Add enable/disable d-cache support for purgatory
From: Pratyush Anand @ 2016-12-14 14:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161214134457.GJ17982@leverpostej>
On Wednesday 14 December 2016 07:14 PM, Mark Rutland wrote:
>> Even for the non-kdump ie `kexec -l` case we do not have a
>> > functionality to bypass sha verification in kexec-tools. --lite
>> > option with the kexec-tools was discouraged and not accepted.
> Ok. Do you have a pointer to the thread regarding that, for context?
>
https://lists.ozlabs.org/pipermail/petitboot/2015-October/000141.html
https://lists.ozlabs.org/pipermail/petitboot/2015-October/000136.html
~Pratyush
^ permalink raw reply
* [PATCH linux v1 0/4] Seven segment display support
From: Arnd Bergmann @ 2016-12-14 14:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ac324946-41da-c090-a0ca-78155611bb7e@baylibre.com>
On Wednesday, December 14, 2016 2:12:41 PM CET Neil Armstrong wrote:
> On 12/14/2016 01:56 PM, Greg KH wrote:
> > On Wed, Dec 14, 2016 at 01:45:30PM +0100, Thomas Petazzoni wrote:
> >> Hello,
> >>
> >> On Tue, 13 Dec 2016 23:55:00 -0800, Jaghathiswari Rankappagounder
> >> Natarajan wrote:
> >>
> >>> Documentation for the binding which provides an interface for adding clock,
> >>> data and clear signal GPIO lines to control seven segment display.
> >>>
> >>> The platform device driver provides an API for displaying on two 7-segment
> >>> displays, and implements the required bit-banging. The hardware assumed is
> >>> 74HC164 wired to two 7-segment displays.
> >>>
> >>> The character device driver implements the user-space API for letting a user
> >>> write to two 7-segment displays including any conversion methods necessary
> >>> to map the user input to two 7-segment displays.
> >>>
> >>> Adding clock, data and clear signal GPIO lines in the devicetree to control
> >>> seven segment display on zaius platform.
> >>>
> >>> The platform driver matches on the device tree node; the platform driver also
> >>> initializes the character device.
> >>>
> >>> Tested that the seven segment display works properly by writing to the
> >>> character device file on a EVB AST2500 board which also has 74HC164 wired
> >>> to two 7-segment displays.
> >>
> >> FWIW, I proposed a driver for seven segment displays back in 2013:
> >>
> >> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-January/139986.html
> >>
> >> And the feedback from Greg KH was: we don't need a driver for that, do
> >> it from userspace. See:
> >>
> >> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-January/139992.html
> >>
> >> So: good luck
> >
> > Did anyone ever write a library for this type of thing?
> >
> > Again, I don't want to see one-off drivers for random devices like this
> > that should be able to all be controlled from userspace in a common
> > manner. Much like we did for fingerprint readers a long long time
> > ago...
> >
> Actually, it's more than a random interface, a lot of SoCs and boards actually have such displays
> and it's a pity to use UIO, sysfs gpio bitbanging and all sort of ugly stuff to only print a few
> characters a simple and clean driver could achieve.
> Some very well known SoCs even have integrated registers to lower the BOM and bypass the need for
> a 74HC164 like component and avoid gpio bit banging.
>
> My personal concern is that you could also need to drive more segments, thus 7-segments
> is too restrictive.
>
> But this driver is well structured, the gpio-bitbanging sub-driver is welcome.
Maybe we can find a way to fit this into the existing drivers/leds/ subsystem?
That already supports blinking, brightness and colour attributes of LEDs,
so could this be extended to support (one of) digit, number, character
or string with a common sysfs attribute and a way to hook up a led driver
to that?
Arnd
^ permalink raw reply
* [RESEND PATCH 0/2] fix some trivial bug involving the contiguous bit
From: zhongjiang @ 2016-12-14 14:19 UTC (permalink / raw)
To: linux-arm-kernel
From: zhong jiang <zhongjiang@huawei.com>
Hi,
The following patch have sent it last week, but it fails to receive any reply.
These patch is simple but reasonable. I hope it can merge to next version. So,
if anyone has any objection, just please let me know.
Thanks
zhongjiang
zhong jiang (2):
arm64: change from CONT_PMD_SHIFT to CONT_PTE_SHIFT
arm64: make WANT_HUGE_PMD_SHARE depends on HUGETLB_PAGE
arch/arm64/Kconfig | 1 +
arch/arm64/mm/hugetlbpage.c | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
--
1.8.3.1
^ permalink raw reply
* [RESEND PATCH 1/2] arm64: change from CONT_PMD_SHIFT to CONT_PTE_SHIFT
From: zhongjiang @ 2016-12-14 14:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481725151-20549-1-git-send-email-zhongjiang@huawei.com>
From: zhong jiang <zhongjiang@huawei.com>
I think that CONT_PTE_SHIFT is more reasonable even if they are some
value. and the patch is not any functional change.
Signed-off-by: zhong jiang <zhongjiang@huawei.com>
---
arch/arm64/mm/hugetlbpage.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/mm/hugetlbpage.c b/arch/arm64/mm/hugetlbpage.c
index 2e49bd2..0a4c97b 100644
--- a/arch/arm64/mm/hugetlbpage.c
+++ b/arch/arm64/mm/hugetlbpage.c
@@ -323,7 +323,7 @@ static __init int setup_hugepagesz(char *opt)
static __init int add_default_hugepagesz(void)
{
if (size_to_hstate(CONT_PTES * PAGE_SIZE) == NULL)
- hugetlb_add_hstate(CONT_PMD_SHIFT);
+ hugetlb_add_hstate(CONT_PTE_SHIFT);
return 0;
}
arch_initcall(add_default_hugepagesz);
--
1.8.3.1
^ permalink raw reply related
* [RESEND PATCH 2/2] arm64: make WANT_HUGE_PMD_SHARE depends on HUGETLB_PAGE
From: zhongjiang @ 2016-12-14 14:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481725151-20549-1-git-send-email-zhongjiang@huawei.com>
From: zhong jiang <zhongjiang@huawei.com>
when HUGETLB_PAGE is disable, WANT_HUGE_PMD_SHARE contains the
fuctions should not be use. therefore, we add the dependency.
Signed-off-by: zhong jiang <zhongjiang@huawei.com>
---
arch/arm64/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 969ef88..694ca73 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -640,6 +640,7 @@ config SYS_SUPPORTS_HUGETLBFS
config ARCH_WANT_HUGE_PMD_SHARE
def_bool y if ARM64_4K_PAGES || (ARM64_16K_PAGES && !ARM64_VA_BITS_36)
+ depends on HUGETLB_PAGE
config ARCH_HAS_CACHE_LINE_SIZE
def_bool y
--
1.8.3.1
^ permalink raw reply related
* [PATCH] clk: stm32f4: Use CLK_OF_DECLARE_DRIVER initialization method
From: gabriel.fernandez at st.com @ 2016-12-14 14:22 UTC (permalink / raw)
To: linux-arm-kernel
From: Gabriel Fernandez <gabriel.fernandez@st.com>
Clock and reset controller use same compatible strings (same IP).
Since commit 989eafd0b609 ("clk: core: Avoid double initialization of
clocks") the OF core flags clock controllers registered with the
CLK_OF_DECLARE() macro as OF_POPULATED, so platform devices with the same
compatible string will not be registered.
Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
---
drivers/clk/clk-stm32f4.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/clk-stm32f4.c b/drivers/clk/clk-stm32f4.c
index 11174a5..0f5ab9b 100644
--- a/drivers/clk/clk-stm32f4.c
+++ b/drivers/clk/clk-stm32f4.c
@@ -1325,5 +1325,5 @@ static void __init stm32f4_rcc_init(struct device_node *np)
kfree(clks);
iounmap(base);
}
-CLK_OF_DECLARE(stm32f42xx_rcc, "st,stm32f42xx-rcc", stm32f4_rcc_init);
-CLK_OF_DECLARE(stm32f46xx_rcc, "st,stm32f469-rcc", stm32f4_rcc_init);
+CLK_OF_DECLARE_DRIVER(stm32f42xx_rcc, "st,stm32f42xx-rcc", stm32f4_rcc_init);
+CLK_OF_DECLARE_DRIVER(stm32f46xx_rcc, "st,stm32f469-rcc", stm32f4_rcc_init);
--
1.9.1
^ permalink raw reply related
* [PATCH] dt-bindings: mfd: stm32f429: Add QSPI & DSI constants into DT include file
From: gabriel.fernandez at st.com @ 2016-12-14 14:23 UTC (permalink / raw)
To: linux-arm-kernel
From: Gabriel Fernandez <gabriel.fernandez@st.com>
It will be used by clock and reset drivers, and DT bindings.
Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
---
include/dt-bindings/mfd/stm32f4-rcc.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/dt-bindings/mfd/stm32f4-rcc.h b/include/dt-bindings/mfd/stm32f4-rcc.h
index e98942d..315f6c3 100644
--- a/include/dt-bindings/mfd/stm32f4-rcc.h
+++ b/include/dt-bindings/mfd/stm32f4-rcc.h
@@ -40,6 +40,7 @@
/* AHB3 */
#define STM32F4_RCC_AHB3_FMC 0
+#define STM32F4_RCC_AHB3_QSPI 1
#define STM32F4_AHB3_RESET(bit) (STM32F4_RCC_AHB3_##bit + (0x18 * 8))
#define STM32F4_AHB3_CLOCK(bit) (STM32F4_RCC_AHB3_##bit + (0x38 * 8))
@@ -91,6 +92,7 @@
#define STM32F4_RCC_APB2_SPI6 21
#define STM32F4_RCC_APB2_SAI1 22
#define STM32F4_RCC_APB2_LTDC 26
+#define STM32F4_RCC_APB2_DSI 27
#define STM32F4_APB2_RESET(bit) (STM32F4_RCC_APB2_##bit + (0x24 * 8))
#define STM32F4_APB2_CLOCK(bit) (STM32F4_RCC_APB2_##bit + (0x44 * 8))
--
1.9.1
^ permalink raw reply related
* [PATCH] pinctrl: stm32: activate strict mux mode
From: gabriel.fernandez at st.com @ 2016-12-14 14:24 UTC (permalink / raw)
To: linux-arm-kernel
From: Gabriel Fernandez <gabriel.fernandez@st.com>
This activates strict mode muxing for the STM32 pin controllers,
as these do not allow GPIO and functions to use the same pin
simultaneously.
Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
---
drivers/pinctrl/stm32/pinctrl-stm32.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/pinctrl/stm32/pinctrl-stm32.c b/drivers/pinctrl/stm32/pinctrl-stm32.c
index efc4371..c983a1e 100644
--- a/drivers/pinctrl/stm32/pinctrl-stm32.c
+++ b/drivers/pinctrl/stm32/pinctrl-stm32.c
@@ -631,6 +631,7 @@ static int stm32_pmx_gpio_set_direction(struct pinctrl_dev *pctldev,
.get_function_groups = stm32_pmx_get_func_groups,
.set_mux = stm32_pmx_set_mux,
.gpio_set_direction = stm32_pmx_gpio_set_direction,
+ .strict = true,
};
/* Pinconf functions */
--
1.9.1
^ permalink raw reply related
* [PATCH] ARM: dts: Add missing CPU frequencies for Exynos5422/5800
From: Bartlomiej Zolnierkiewicz @ 2016-12-14 14:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a3179721-3a0e-651b-f422-c08463aae7e6@osg.samsung.com>
Hi,
On Wednesday, December 14, 2016 11:06:45 AM Javier Martinez Canillas wrote:
>
> Hello Bartlomiej,
>
> On 12/14/2016 10:28 AM, Bartlomiej Zolnierkiewicz wrote:
> >
> > On Tuesday, December 13, 2016 04:18:05 PM Javier Martinez Canillas wrote:
> >> Hello Bartlomiej,
> >
> > Hi,
> >
> >> On 12/13/2016 01:52 PM, Bartlomiej Zolnierkiewicz wrote:
> >>> Add missing 2000MHz & 1900MHz OPPs (for A15 cores) and 1400MHz OPP
> >>> (for A7 cores). Also update common Odroid-XU3 Lite/XU3/XU4 thermal
> >>> cooling maps to account for new OPPs.
> >>>
> >>> Since new OPPs are not available on all Exynos5422/5800 boards modify
> >>> dts files for Odroid-XU3 Lite (limited to 1.8 GHz / 1.3 GHz) & Peach
> >>> Pi (limited to 2.0 GHz / 1.3 GHz) accordingly.
> >>>
> >>> Tested on Odroid-XU3 and XU3 Lite.
> >>>
> >>> Cc: Doug Anderson <dianders@chromium.org>
> >>> Cc: Javier Martinez Canillas <javier@osg.samsung.com>
> >>> Cc: Andreas Faerber <afaerber@suse.de>
> >>> Cc: Thomas Abraham <thomas.ab@samsung.com>
> >>> Cc: Ben Gamari <ben@smart-cactus.org>
> >>> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> >>> ---
> >>> arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 14 +++++++-------
> >>> arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts | 17 +++++++++++++++++
> >>> arch/arm/boot/dts/exynos5800-peach-pi.dts | 4 ++++
> >>> arch/arm/boot/dts/exynos5800.dtsi | 15 +++++++++++++++
> >>> 4 files changed, 43 insertions(+), 7 deletions(-)
> >>>
> >>> Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> >>> ===================================================================
> >>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-13 15:59:33.779763261 +0100
> >>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-13 15:59:33.775763261 +0100
> >>> @@ -118,7 +118,7 @@
> >>> /*
> >>> * When reaching cpu_alert3, reduce CPU
> >>> * by 2 steps. On Exynos5422/5800 that would
> >>> - * be: 1600 MHz and 1100 MHz.
> >>> + * (usually) be: 1800 MHz and 1200 MHz.
> >>> */
> >>> map3 {
> >>> trip = <&cpu_alert3>;
> >>> @@ -131,16 +131,16 @@
> >>>
> >>> /*
> >>> * When reaching cpu_alert4, reduce CPU
> >>> - * further, down to 600 MHz (11 steps for big,
> >>> - * 7 steps for LITTLE).
> >>> + * further, down to 600 MHz (13 steps for big,
> >>> + * 8 steps for LITTLE).
> >>> */
> >>> - map5 {
> >>> + cooling_map5: map5 {
> >>> trip = <&cpu_alert4>;
> >>> - cooling-device = <&cpu0 3 7>;
> >>> + cooling-device = <&cpu0 3 8>;
> >>> };
> >>> - map6 {
> >>> + cooling_map6: map6 {
> >>> trip = <&cpu_alert4>;
> >>> - cooling-device = <&cpu4 3 11>;
> >>> + cooling-device = <&cpu4 3 13>;
> >>> };
> >>> };
> >>> };
> >>> Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts
> >>> ===================================================================
> >>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-13 15:59:33.779763261 +0100
> >>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-13 15:59:33.775763261 +0100
> >>> @@ -21,6 +21,23 @@
> >>> compatible = "hardkernel,odroid-xu3-lite", "samsung,exynos5800", "samsung,exynos5";
> >>> };
> >>>
> >>> +&cluster_a15_opp_table {
> >>> + /delete-node/opp at 2000000000;
> >>> + /delete-node/opp at 1900000000;
> >>> +};
> >>> +
> >>> +&cluster_a7_opp_table {
> >>> + /delete-node/opp at 1400000000;
> >>> +};
> >>> +
> >>
> >> I think that a comment in the DTS why these operating points aren't available
> >> in this board will make more clear why the nodes are being deleted.
> >
> > Ok, I will add these comments in the next patch revision.
> >
> >>> +&cooling_map5 {
> >>> + cooling-device = <&cpu0 3 7>;
> >>> +};
> >>> +
> >>> +&cooling_map6 {
> >>> + cooling-device = <&cpu4 3 11>;
> >>> +};
> >>> +
> >>> &pwm {
> >>> /*
> >>> * PWM 0 -- fan
> >>> Index: b/arch/arm/boot/dts/exynos5800-peach-pi.dts
> >>> ===================================================================
> >>> --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-13 15:59:33.779763261 +0100
> >>> +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-13 15:59:33.779763261 +0100
> >>> @@ -146,6 +146,10 @@
> >>> vdd-supply = <&ldo9_reg>;
> >>> };
> >>>
> >>> +&cluster_a7_opp_table {
> >>> + /delete-property/opp at 1400000000;
> >>> +};
> >>> +
> >>> &cpu0 {
> >>> cpu-supply = <&buck2_reg>;
> >>> };
> >>> Index: b/arch/arm/boot/dts/exynos5800.dtsi
> >>> ===================================================================
> >>> --- a/arch/arm/boot/dts/exynos5800.dtsi 2016-12-13 15:59:33.779763261 +0100
> >>> +++ b/arch/arm/boot/dts/exynos5800.dtsi 2016-12-13 15:59:33.779763261 +0100
> >>> @@ -24,6 +24,16 @@
> >>> };
> >>>
> >>> &cluster_a15_opp_table {
> >>> + opp at 2000000000 {
> >>> + opp-hz = /bits/ 64 <2000000000>;
> >>> + opp-microvolt = <1250000>;
> >>> + clock-latency-ns = <140000>;
> >>> + };
> >>> + opp at 1900000000 {
> >>> + opp-hz = /bits/ 64 <1900000000>;
> >>> + opp-microvolt = <1250000>;
> >>> + clock-latency-ns = <140000>;
> >>> + };
> >>> opp at 1700000000 {
> >>> opp-microvolt = <1250000>;
> >>> };
> >>> @@ -85,6 +95,11 @@
> >>> };
> >>>
> >>
> >> AFAIK Thomas restricted the maximum OPP, because for A15 freqs > 1.8GHz the
> >> INT rail would need to be scaled up as well since there's a maximum voltage
> >> difference between the ARM and INT rails before the system becomes unstable:
> >>
> >> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/276766.html
> >> https://lkml.org/lkml/2014/5/2/419
> >>
> >> The ChromiumOS vendor tree uses a virtual regulator driver that makes sure
> >> the maximum voltage skew is between a limit. But that never made to mainline:
> >>
> >> https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/arch/arm/boot/dts/exynos5420-peach-pit.dtsi#90
> >> https://lkml.org/lkml/2014/4/29/28
> >>
> >> Did that change and there's infrastructure in mainline now to cope with that?
> >> If that's the case, I think it would be good to mention in the commit message.
> >
> > I was not aware of this limitation and AFAIK mainline has currently
> > no code to handle it. I also cannot find any code to handle this in
>
> Yes, that's what I thought as well but maybe I was missing something.
>
> > Hardkernel's vendor kernel for Odroid-XU3 board.
> >
> > Do you know whether this problem exists also on Exynos5422/5800
> > SoCs or only on Exynos5420 one? I see that ChromiumOS uses virtual
> > regulator code also on Exynos5800 SoC based Peach Pi board but was
> > the problem actually present on this board?
> >
>
> My understanding is that this problem is present in 5420/5422/5800
> but I have no way to confirm this. I'm just guessing from the info
> in the ChromiumOS vendor tree.
>
> If you look at the commit that added the regulator-locker driver,
> the test says to be done in a Peach Pi so it seems the problem is
> not restricted to only Exynos5420:
>
> https://chromium.googlesource.com/chromiumos/third_party/kernel/+/ba63620feace4eaed5572ac2e77d8d61754af704
>
> > [ I added Arjun to Cc:, maybe he can help in explaining this issue
> > (unfortunately Inderpal's email is no longer working). ]
> >
>
> Added Abhilash to cc list as well since he was involved in the Exynos ChromeOS tree.
Abhilash's email is also no longer valid.. :(
> > Please also note that on Exynos5422/5800 SoCs the same ARM rail
> > voltage is used for 1.9 GHz & 2.0 GHz OPPs as for the 1.8 GHz one.
> > IOW if the problem exists it is already present in the mainline
> > kernel.
> >
>
> Ah, I only looked at your patch and I didn't compare the voltage levels
> in your 1.9 GHz and 2.0 GHz OPPs with the current 1.8 GHz in mainline.
>
> I wonder if the voltage levels in your patch are correct then, since the
> ChromiumOS tree uses a higher voltages for the 1.9 GHz and 2.0 GHz OPPs:
>
> /*
> * Default ASV table
> */
> static const unsigned int asv_voltage_5420[CPUFREQ_NUM_LEVELS] = {
> 1362500, /* L0 2100 */
> 1312500, /* L1 2000 */
> 1275000, /* L2 1900 */
> 1225000, /* L3 1800 */
> 1200000, /* L4 1700 */
>
> This is from https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/drivers/cpufreq/exynos5420-cpufreq.c#175
I think that the above voltages are original ones for Exynos5420
(not for Exynos5422/5800).
The voltages in my patch were taken from Hardkernel's kernel for
Odroid-XU3:
/*
* ASV group voltage table
*/
static const unsigned int asv_voltage_5422_CA15[CPUFREQ_LEVEL_END_CA15] = {
...
1250000, /* L4 2000 */
1250000, /* L5 1900 */
1250000, /* L6 1800 */
...
https://github.com/hardkernel/linux/blob/odroidxu3-3.10.y-android/drivers/cpufreq/exynos5422-eagle-cpufreq.c#L314
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
^ permalink raw reply
* jemalloc testsuite stalls in memset
From: Andreas Schwab @ 2016-12-14 14:34 UTC (permalink / raw)
To: linux-arm-kernel
When running the jemalloc-4.4.0 testsuite on aarch64 with glibc 2.24 the
test/unit/junk test hangs in memset:
(gdb) r
Starting program: /tmp/jemalloc/jemalloc-4.4.0/test/unit/junk
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
test_junk_small: pass
test_junk_large: pass
^C
Program received signal SIGINT, Interrupt.
memset () at ../sysdeps/aarch64/memset.S:91
91 str q0, [dstin]
(gdb) x/i $pc
=> 0xffffb7ddf54c <memset+140>: str q0, [x0]
x0 is pointing to the start of this mmap'd block:
0xffffb7400000 0xffffb7600000 0x200000 0x0
Any attempt to contine execution or step over the insn still causes the
process to hang here. Only after accessing the memory through the
debugger the test successfully continues to completion.
The kernel has been configured with transparent hugepages.
CONFIG_TRANSPARENT_HUGEPAGE=y
CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y
# CONFIG_TRANSPARENT_HUGEPAGE_MADVISE is not set
CONFIG_TRANSPARENT_HUGE_PAGECACHE=y
This issue has been bisected to commit
b8d3c4c3009d42869dc03a1da0efc2aa687d0ab4 ("mm/huge_memory.c: don't split
THP page when MADV_FREE syscall is called").
Andreas.
--
Andreas Schwab, SUSE Labs, schwab at suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
^ permalink raw reply
* [PATCH] ARM: dts: Add missing CPU frequencies for Exynos5422/5800
From: Javier Martinez Canillas @ 2016-12-14 14:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3539351.vsrnVhEgRT@amdc3058>
Hello Bartlomiej,
On 12/14/2016 11:25 AM, Bartlomiej Zolnierkiewicz wrote:
>
> Hi,
>
> On Wednesday, December 14, 2016 11:06:45 AM Javier Martinez Canillas wrote:
>>
>> Hello Bartlomiej,
>>
>> On 12/14/2016 10:28 AM, Bartlomiej Zolnierkiewicz wrote:
>>>
>>> On Tuesday, December 13, 2016 04:18:05 PM Javier Martinez Canillas wrote:
>>>> Hello Bartlomiej,
>>>
>>> Hi,
>>>
>>>> On 12/13/2016 01:52 PM, Bartlomiej Zolnierkiewicz wrote:
>>>>> Add missing 2000MHz & 1900MHz OPPs (for A15 cores) and 1400MHz OPP
>>>>> (for A7 cores). Also update common Odroid-XU3 Lite/XU3/XU4 thermal
>>>>> cooling maps to account for new OPPs.
>>>>>
>>>>> Since new OPPs are not available on all Exynos5422/5800 boards modify
>>>>> dts files for Odroid-XU3 Lite (limited to 1.8 GHz / 1.3 GHz) & Peach
>>>>> Pi (limited to 2.0 GHz / 1.3 GHz) accordingly.
>>>>>
>>>>> Tested on Odroid-XU3 and XU3 Lite.
>>>>>
>>>>> Cc: Doug Anderson <dianders@chromium.org>
>>>>> Cc: Javier Martinez Canillas <javier@osg.samsung.com>
>>>>> Cc: Andreas Faerber <afaerber@suse.de>
>>>>> Cc: Thomas Abraham <thomas.ab@samsung.com>
>>>>> Cc: Ben Gamari <ben@smart-cactus.org>
>>>>> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
>>>>> ---
>>>>> arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 14 +++++++-------
>>>>> arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts | 17 +++++++++++++++++
>>>>> arch/arm/boot/dts/exynos5800-peach-pi.dts | 4 ++++
>>>>> arch/arm/boot/dts/exynos5800.dtsi | 15 +++++++++++++++
>>>>> 4 files changed, 43 insertions(+), 7 deletions(-)
>>>>>
>>>>> Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>>>> ===================================================================
>>>>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-13 15:59:33.779763261 +0100
>>>>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-13 15:59:33.775763261 +0100
>>>>> @@ -118,7 +118,7 @@
>>>>> /*
>>>>> * When reaching cpu_alert3, reduce CPU
>>>>> * by 2 steps. On Exynos5422/5800 that would
>>>>> - * be: 1600 MHz and 1100 MHz.
>>>>> + * (usually) be: 1800 MHz and 1200 MHz.
>>>>> */
>>>>> map3 {
>>>>> trip = <&cpu_alert3>;
>>>>> @@ -131,16 +131,16 @@
>>>>>
>>>>> /*
>>>>> * When reaching cpu_alert4, reduce CPU
>>>>> - * further, down to 600 MHz (11 steps for big,
>>>>> - * 7 steps for LITTLE).
>>>>> + * further, down to 600 MHz (13 steps for big,
>>>>> + * 8 steps for LITTLE).
>>>>> */
>>>>> - map5 {
>>>>> + cooling_map5: map5 {
>>>>> trip = <&cpu_alert4>;
>>>>> - cooling-device = <&cpu0 3 7>;
>>>>> + cooling-device = <&cpu0 3 8>;
>>>>> };
>>>>> - map6 {
>>>>> + cooling_map6: map6 {
>>>>> trip = <&cpu_alert4>;
>>>>> - cooling-device = <&cpu4 3 11>;
>>>>> + cooling-device = <&cpu4 3 13>;
>>>>> };
>>>>> };
>>>>> };
>>>>> Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts
>>>>> ===================================================================
>>>>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-13 15:59:33.779763261 +0100
>>>>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-13 15:59:33.775763261 +0100
>>>>> @@ -21,6 +21,23 @@
>>>>> compatible = "hardkernel,odroid-xu3-lite", "samsung,exynos5800", "samsung,exynos5";
>>>>> };
>>>>>
>>>>> +&cluster_a15_opp_table {
>>>>> + /delete-node/opp at 2000000000;
>>>>> + /delete-node/opp at 1900000000;
>>>>> +};
>>>>> +
>>>>> +&cluster_a7_opp_table {
>>>>> + /delete-node/opp at 1400000000;
>>>>> +};
>>>>> +
>>>>
>>>> I think that a comment in the DTS why these operating points aren't available
>>>> in this board will make more clear why the nodes are being deleted.
>>>
>>> Ok, I will add these comments in the next patch revision.
>>>
>>>>> +&cooling_map5 {
>>>>> + cooling-device = <&cpu0 3 7>;
>>>>> +};
>>>>> +
>>>>> +&cooling_map6 {
>>>>> + cooling-device = <&cpu4 3 11>;
>>>>> +};
>>>>> +
>>>>> &pwm {
>>>>> /*
>>>>> * PWM 0 -- fan
>>>>> Index: b/arch/arm/boot/dts/exynos5800-peach-pi.dts
>>>>> ===================================================================
>>>>> --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-13 15:59:33.779763261 +0100
>>>>> +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-13 15:59:33.779763261 +0100
>>>>> @@ -146,6 +146,10 @@
>>>>> vdd-supply = <&ldo9_reg>;
>>>>> };
>>>>>
>>>>> +&cluster_a7_opp_table {
>>>>> + /delete-property/opp at 1400000000;
>>>>> +};
>>>>> +
>>>>> &cpu0 {
>>>>> cpu-supply = <&buck2_reg>;
>>>>> };
>>>>> Index: b/arch/arm/boot/dts/exynos5800.dtsi
>>>>> ===================================================================
>>>>> --- a/arch/arm/boot/dts/exynos5800.dtsi 2016-12-13 15:59:33.779763261 +0100
>>>>> +++ b/arch/arm/boot/dts/exynos5800.dtsi 2016-12-13 15:59:33.779763261 +0100
>>>>> @@ -24,6 +24,16 @@
>>>>> };
>>>>>
>>>>> &cluster_a15_opp_table {
>>>>> + opp at 2000000000 {
>>>>> + opp-hz = /bits/ 64 <2000000000>;
>>>>> + opp-microvolt = <1250000>;
>>>>> + clock-latency-ns = <140000>;
>>>>> + };
>>>>> + opp at 1900000000 {
>>>>> + opp-hz = /bits/ 64 <1900000000>;
>>>>> + opp-microvolt = <1250000>;
>>>>> + clock-latency-ns = <140000>;
>>>>> + };
>>>>> opp at 1700000000 {
>>>>> opp-microvolt = <1250000>;
>>>>> };
>>>>> @@ -85,6 +95,11 @@
>>>>> };
>>>>>
>>>>
>>>> AFAIK Thomas restricted the maximum OPP, because for A15 freqs > 1.8GHz the
>>>> INT rail would need to be scaled up as well since there's a maximum voltage
>>>> difference between the ARM and INT rails before the system becomes unstable:
>>>>
>>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/276766.html
>>>> https://lkml.org/lkml/2014/5/2/419
>>>>
>>>> The ChromiumOS vendor tree uses a virtual regulator driver that makes sure
>>>> the maximum voltage skew is between a limit. But that never made to mainline:
>>>>
>>>> https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/arch/arm/boot/dts/exynos5420-peach-pit.dtsi#90
>>>> https://lkml.org/lkml/2014/4/29/28
>>>>
>>>> Did that change and there's infrastructure in mainline now to cope with that?
>>>> If that's the case, I think it would be good to mention in the commit message.
>>>
>>> I was not aware of this limitation and AFAIK mainline has currently
>>> no code to handle it. I also cannot find any code to handle this in
>>
>> Yes, that's what I thought as well but maybe I was missing something.
>>
>>> Hardkernel's vendor kernel for Odroid-XU3 board.
>>>
>>> Do you know whether this problem exists also on Exynos5422/5800
>>> SoCs or only on Exynos5420 one? I see that ChromiumOS uses virtual
>>> regulator code also on Exynos5800 SoC based Peach Pi board but was
>>> the problem actually present on this board?
>>>
>>
>> My understanding is that this problem is present in 5420/5422/5800
>> but I have no way to confirm this. I'm just guessing from the info
>> in the ChromiumOS vendor tree.
>>
>> If you look at the commit that added the regulator-locker driver,
>> the test says to be done in a Peach Pi so it seems the problem is
>> not restricted to only Exynos5420:
>>
>> https://chromium.googlesource.com/chromiumos/third_party/kernel/+/ba63620feace4eaed5572ac2e77d8d61754af704
>>
>>> [ I added Arjun to Cc:, maybe he can help in explaining this issue
>>> (unfortunately Inderpal's email is no longer working). ]
>>>
>>
>> Added Abhilash to cc list as well since he was involved in the Exynos ChromeOS tree.
>
> Abhilash's email is also no longer valid.. :(
>
Yes, I noticed that as well :(
>>> Please also note that on Exynos5422/5800 SoCs the same ARM rail
>>> voltage is used for 1.9 GHz & 2.0 GHz OPPs as for the 1.8 GHz one.
>>> IOW if the problem exists it is already present in the mainline
>>> kernel.
>>>
>>
>> Ah, I only looked at your patch and I didn't compare the voltage levels
>> in your 1.9 GHz and 2.0 GHz OPPs with the current 1.8 GHz in mainline.
>>
>> I wonder if the voltage levels in your patch are correct then, since the
>> ChromiumOS tree uses a higher voltages for the 1.9 GHz and 2.0 GHz OPPs:
>>
>> /*
>> * Default ASV table
>> */
>> static const unsigned int asv_voltage_5420[CPUFREQ_NUM_LEVELS] = {
>> 1362500, /* L0 2100 */
>> 1312500, /* L1 2000 */
>> 1275000, /* L2 1900 */
>> 1225000, /* L3 1800 */
>> 1200000, /* L4 1700 */
>>
>> This is from https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/drivers/cpufreq/exynos5420-cpufreq.c#175
>
> I think that the above voltages are original ones for Exynos5420
> (not for Exynos5422/5800).
>
In the ChromiumOS tree, the same CPUFreq driver is used for both the Peach
Pit (Exynos5420) and Peach Pi (Exynos5800) Chromebooks.
> The voltages in my patch were taken from Hardkernel's kernel for
> Odroid-XU3:
>
> /*
> * ASV group voltage table
> */
> static const unsigned int asv_voltage_5422_CA15[CPUFREQ_LEVEL_END_CA15] = {
> ...
> 1250000, /* L4 2000 */
> 1250000, /* L5 1900 */
> 1250000, /* L6 1800 */
> ...
>
> https://github.com/hardkernel/linux/blob/odroidxu3-3.10.y-android/drivers/cpufreq/exynos5422-eagle-cpufreq.c#L314
>
In general I prefer to use the ChromiumOS tree as a reference instead of the
HardKernel one, since the former is in a much better shape IMHO.
I think is worth to check in a kernel tree in http://opensource.samsung.com/
for a product that's Exynos5422/5800 based.
> Best regards,
> --
> Bartlomiej Zolnierkiewicz
> Samsung R&D Institute Poland
> Samsung Electronics
>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* [RESEND PATCH 1/2] arm64: change from CONT_PMD_SHIFT to CONT_PTE_SHIFT
From: Ard Biesheuvel @ 2016-12-14 14:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481725151-20549-2-git-send-email-zhongjiang@huawei.com>
On 14 December 2016 at 14:19, zhongjiang <zhongjiang@huawei.com> wrote:
> From: zhong jiang <zhongjiang@huawei.com>
>
> I think that CONT_PTE_SHIFT is more reasonable even if they are some
> value. and the patch is not any functional change.
>
This may be the case for 64k pages, but not for 16k pages, and I
actually think add_default_hugepagesz() could be made unconditional,
given that both 64k on 4k kernels and 2 MB on 16k kernels are useful
hugepage sizes that are not otherwise available by default.
> Signed-off-by: zhong jiang <zhongjiang@huawei.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
> arch/arm64/mm/hugetlbpage.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/mm/hugetlbpage.c b/arch/arm64/mm/hugetlbpage.c
> index 2e49bd2..0a4c97b 100644
> --- a/arch/arm64/mm/hugetlbpage.c
> +++ b/arch/arm64/mm/hugetlbpage.c
> @@ -323,7 +323,7 @@ static __init int setup_hugepagesz(char *opt)
> static __init int add_default_hugepagesz(void)
> {
> if (size_to_hstate(CONT_PTES * PAGE_SIZE) == NULL)
> - hugetlb_add_hstate(CONT_PMD_SHIFT);
> + hugetlb_add_hstate(CONT_PTE_SHIFT);
> return 0;
> }
> arch_initcall(add_default_hugepagesz);
> --
> 1.8.3.1
>
^ permalink raw reply
* [PATCH v2] ARM: dts: sunxi: Change node name for pwrseq pin on Olinuxino-lime2-emmc
From: Emmanuel Vadot @ 2016-12-14 14:57 UTC (permalink / raw)
To: linux-arm-kernel
The node name for the power seq pin is mmc2 at 0 like the mmc2_pins_a one.
This makes the original node (mmc2_pins_a) scrapped out of the dtb and
result in a unusable eMMC if U-Boot didn't configured the pins to the
correct functions.
Changes since v1:
* Rename the node mmc2-rst-pin
Signed-off-by: Emmanuel Vadot <manu@bidouilliste.com>
---
arch/arm/boot/dts/sun7i-a20-olinuxino-lime2-emmc.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2-emmc.dts b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2-emmc.dts
index 5ea4915..10d3074 100644
--- a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2-emmc.dts
+++ b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2-emmc.dts
@@ -56,7 +56,7 @@
};
&pio {
- mmc2_pins_nrst: mmc2 at 0 {
+ mmc2_pins_nrst: mmc2-rst-pin {
allwinner,pins = "PC16";
allwinner,function = "gpio_out";
allwinner,drive = <SUN4I_PINCTRL_10_MA>;
--
2.9.2
^ permalink raw reply related
* [PATCH 3/3] crypto: brcm: Add Broadcom SPU driver DT entry.
From: Rob (William) Rice @ 2016-12-14 15:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201612110810.BEVbRp0B%fengguang.wu@intel.com>
I will rebase to Herbert's latest when I submit v3 to address Mark
Rutland's DT comments (and any others that come in).
Rob
On 12/10/2016 7:14 PM, kbuild test robot wrote:
> Hi Rob,
>
> [auto build test ERROR on cryptodev/master]
> [also build test ERROR on v4.9-rc8]
> [cannot apply to next-20161209]
> [if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
>
> url: https://github.com/0day-ci/linux/commits/Rob-Rice/crypto-brcm-DT-documentation-for-Broadcom-SPU-driver/20161202-010038
> base: https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master
> config: arm64-defconfig (attached as .config)
> compiler: aarch64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
> reproduce:
> wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> make.cross ARCH=arm64
>
> All errors (new ones prefixed by >>):
>
>>> ERROR: Input tree has errors, aborting (use -f to force output)
> ---
> 0-DAY kernel test infrastructure Open Source Technology Center
> https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ 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