* Applied "ASoC: tfa9879: add DT bindings to MAINTAINERS" to the asoc tree
From: Mark Brown @ 2017-12-12 11:16 UTC (permalink / raw)
To: Peter Rosin
Cc: Mark Brown, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA,
alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw, Liam Girdwood, Rob Herring
In-Reply-To: <20171211142615.11440-3-peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
The patch
ASoC: tfa9879: add DT bindings to MAINTAINERS
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From a73be94364b80388c0a600715117923669f165f8 Mon Sep 17 00:00:00 2001
From: Peter Rosin <peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
Date: Mon, 11 Dec 2017 15:26:15 +0100
Subject: [PATCH] ASoC: tfa9879: add DT bindings to MAINTAINERS
Let's keep maintenance of the driver and the bindings in one place.
Signed-off-by: Peter Rosin <peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
Signed-off-by: Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index aa71ab52fd76..a04aaa270ad5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9805,6 +9805,7 @@ NXP TFA9879 DRIVER
M: Peter Rosin <peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
L: alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw@public.gmane.org (moderated for non-subscribers)
S: Maintained
+F: Documentation/devicetree/bindings/sound/tfa9879.txt
F: sound/soc/codecs/tfa9879*
NXP-NCI NFC DRIVER
--
2.15.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH 4/4] [v4] pinctrl: qcom: qdf2xxx: add support for new ACPI HID QCOM8002
From: Andy Shevchenko @ 2017-12-12 11:07 UTC (permalink / raw)
To: Linus Walleij, Timur Tabi,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
Cc: Archit Taneja, David Brown, linux-arm-msm, Stephen Boyd,
Bjorn Andersson, linux-gpio, thierry.reding@gmail.com, Andy Gross,
Mika Westerberg, Varadarajan Narayanan, Linux ARM
In-Reply-To: <CACRpkdYer_Q5R4XhWTX3=jwshcKZRSDY9=gOvSeUPsQHbUw6vw@mail.gmail.com>
On Tue, 2017-12-12 at 11:42 +0100, Linus Walleij wrote:
> On Sat, Dec 2, 2017 at 12:28 AM, Timur Tabi <timur@codeaurora.org>
> wrote:
> > + /* The number of GPIOs in the approved list */
> > + ret = device_property_read_u16_array(&pdev->dev,
> > "gpios",
> > + NULL, 0);
> > + if (ret < 0) {
> > + dev_err(&pdev->dev, "missing 'gpios'
> > property\n");
> > + return ret;
> > + }
>
> This is in direct conflict with the existing "gpios" binding in device
> tree.
>
> Where is this name coming from? ACPI standards?
Not ACPI standards as of my knowledge. ACPI standard defines a common
scheme how to define properties, it doesn't tell anything about property
names or any mappings between names to values or names to "OS
subsystem").
As for GPIO we just follow *de facto* what DT has right now, i.e. "xxx-
gpio" or "xxx-gpios" pattern is used to map ACPI standard resource to a
GPIO name. That's how GPIO ACPI lib is being developed.
> If device tree and ACPI start defining things which are in direct
> conflict
> we can just shut down this device_property() business altogether,
> it will never work that way.
This is fully understandable. Also it works in other direction, i.e. if
DT will break the established thing it will break also ACPI and built-in
device properties.
We are keeping an eye on this not to happen as much as we can in any
direction.
So, summarize above, I don't see any impediments (except maybe very
broken ARM64 firmware that is already on devices on market) to make it
properly from the beginning.
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
^ permalink raw reply
* Re: [PATCH v2] ARM: dts: exynos: Enable Mixer node for Exynos5800 Peach Pi machine
From: Guillaume Tucker @ 2017-12-12 11:07 UTC (permalink / raw)
To: Marek Szyprowski, Krzysztof Kozlowski, Javier Martinez Canillas
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, Daniel Vetter, Shuah Khan,
devicetree-u79uwXL29TY76Z2rM5mHXA, Kukjin Kim, Russell King,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA, Rob Herring,
Mark Rutland, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1bbedec6-6250-f02a-bf9a-4b9849833de2-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
On 12/12/17 10:55, Marek Szyprowski wrote:
> Hi Guillaume,
>
> On 2017-12-12 11:43, Guillaume Tucker wrote:
>> On 12/12/17 10:17, Marek Szyprowski wrote:
>>> Hi Krzysztof,
>>>
>>> On 2017-12-12 11:09, Krzysztof Kozlowski wrote:
>>>> On Tue, Dec 12, 2017 at 10:55 AM, Krzysztof Kozlowski <krzk-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>>>>> On Tue, Dec 12, 2017 at 8:42 AM, Javier Martinez Canillas
>>>>> <javierm-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>>>>>> Commit 1cb686c08d12 ("ARM: dts: exynos: Add status property to Exynos 542x
>>>>>> Mixer nodes") disabled the Mixer node by default in the DTSI and enabled
>>>>>> for each Exynos 542x DTS. But unfortunately it missed to enable it for the
>>>>>> Exynos5800 Peach Pi machine, since the 5800 is also an 542x SoC variant.
>>>>>>
>>>>>> Fixes: 1cb686c08d12 ("ARM: dts: exynos: Add status property to Exynos 542x Mixer nodes")
>>>>>> Signed-off-by: Javier Martinez Canillas <javierm-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>>>>>> Acked-by: Marek Szyprowski <m.szyprowski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
>>>>>>
>>>>>> ---
>>>>>>
>>>>>> Changes in v2:
>>>>>> - Remove RFT tag.
>>>>> Thanks guys! However I still would like to see a tested-by for this on
>>>>> Peach Pi (AFAIU, Marek's only acked the code/solution).
>>>> On the other hand I could just apply it for my for-next branch and
>>>> we'll see if it fixes kernel-ci boot tests... Not a nice way of
>>>> testing but apparently no one has Peach Pi.
>>>
>>> Frankly, I don't expect that this will solve the boot hang issue on PeachPi.
>>> However it should at least hide the unbalanced regulator issue.
>>
>> We have a peach-pi in our LAVA lab so I've tested it and
>> actually, it does fix the hang on v4.15-rc3:
>>
>> https://lava.collabora.co.uk/scheduler/job/1019877
>> https://lava.collabora.co.uk/scheduler/job/1019878
>>
>> I ran it twice and it booted both times. I also ran the same
>> boot tests with the same kernel but the dtb from v4.15-rc3
>> without the fix to double check and these failed:
>>
>> https://lava.collabora.co.uk/scheduler/job/1019879
>> https://lava.collabora.co.uk/scheduler/job/1019880
>>
>>
>> Tested-by: Guillaume Tucker <guillaume.tucker-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
>>
>>
>> Thanks for the fix!
>
> Well, thanks for the test! It proves that there the boot failure is
> caused by an issue somewhere in the error path of Exynos DRM, Analogix
> DP, Simple Panel or other drivers.
>
> This patch simply hides it by fixing the source issue of the Exynos
> DRM initialization failure. :-)
>
> I hope Javier will be able to investigate the discussed hang issue
> later, as fixing it is also imho important.
Sure. This device tree change is needed to get HDMI to work so
it's still a fix for that. Also it's good to know that nothing
else breaks when the driver issue is "hidden". Might be worth
testing on -next as well as it might help spot any new issues
that haven't been merged in mainline yet, or in general give
another data point.
Guillaume
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/6] ARM: stm32: prepare stm32 family to welcome armv7 architecture
From: afzal mohammed @ 2017-12-12 11:03 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Linus Walleij, Ludovic Barre, Russell King, Rob Herring,
Maxime Coquelin, Alexandre Torgue, Linux ARM,
linux-kernel@vger.kernel.org,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
In-Reply-To: <CAK8P3a2rrpFuwET8r1H0YWVABbCZr5c2ySrKCgA4mfoZPfWp6Q@mail.gmail.com>
Hi,
On Mon, Dec 11, 2017 at 02:40:43PM +0100, Arnd Bergmann wrote:
> On Mon, Dec 11, 2017 at 11:25 AM, Linus Walleij
> >> This patch prepares the STM32 machine for the integration of Cortex-A
> >> based microprocessor (MPU), on top of the existing Cortex-M
> >> microcontroller family (MCU). Since both MCUs and MPUs are sharing
> >> common hardware blocks we can keep using ARCH_STM32 flag for most of
> >> them. If a hardware block is specific to one family we can use either
> >> ARCH_STM32_MCU or ARCH_STM32_MPU flag.
> To what degree do we need to treat them as separate families
> at all then? I wonder if the MCU/MPU distinction is always that
> clear along the Cortex-M/Cortex-A separation,
> What
> exactly would we miss if we do away with the ARCH_STM32_MCU
> symbol here?
Based on this patch series, the only difference seems to be w.r.t ARM
components, not peripherals outside ARM subystem. Vybrid VF610 is a
similar case, though not identical (it can have both instead of
either), deals w/o extra symbols,
8064887e02fd6 (ARM: vf610: enable Cortex-M4 configuration on Vybrid SoC)
> especially if
> we ever get to a chip that has both types of cores.
Your wish fulfilled, Vybrid VF610 has both A5 & M4F and mainline Linux
boots on both (simultaneously as well), and the second Linux support,
i.e. on M4 went thr' your keyboard, see above commit :)
There are quite a few others as well, TI's AM335x (A8 + M3), AM437x
(A9 + M3), AM57x (A15 + M4), but of these Cortex M's, the one in AM57x
only can be Linux'able. On others they are meant for PM with limited
resources.
> > So yesterdays application processors are todays MCU processors.
> >
> > I said this on a lecture for control systems a while back and
> > stated it as a reason I think RTOSes are not really seeing a bright
> > future compared to Linux.
> I think there is still lots of room for smaller RTOS in the long run,
Me being an electrical engineer & worked to some extent in motor
control on RTOS/no OS (the value of my opinion is questionable
though), the thought of handling the same in Linux (even RT) sends
shivers down my spine. Here, case being considered is the type of
motor (like permanent magnet ones) where each phase of the motor has
to be properly excited during every PWM period (say every 100us,
depending on the feedback, algorithm, other synchronization) w/o which
the motor that has been told to run might try to fly. This is
different from stepper motor where if control misbehaves/stops nothing
harmful normally happens.
But my opinion is a kind of knee-jerk reaction and based on prevalent
atitude in that field, hmm.., probably i should attempt it first.
Regards
afzal
^ permalink raw reply
* Re: [PATCH V3 0/2] Tegra PCIe end point config space map code refactoring
From: Lorenzo Pieralisi @ 2017-12-12 11:01 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Thierry Reding, Bjorn Helgaas, Vidya Sagar,
treding-DDmLM1+adcrQT0dZR+AlfA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-pci-u79uwXL29TY76Z2rM5mHXA, kthota-DDmLM1+adcrQT0dZR+AlfA,
mmaddireddy-DDmLM1+adcrQT0dZR+AlfA,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171211175452.GC16032-1RhO1Y9PlrlHTL0Zs8A6p5iNqAH0jzoTYJqu5kTmcBRl57MIdRCFDg@public.gmane.org>
On Mon, Dec 11, 2017 at 11:54:53AM -0600, Bjorn Helgaas wrote:
> [+cc Lorenzo]
>
> On Mon, Dec 11, 2017 at 11:54:31AM +0100, Thierry Reding wrote:
> > On Mon, Dec 04, 2017 at 11:23:48PM +0530, Vidya Sagar wrote:
> > > PCIe host controller in Tegra SoCs has 1GB of aperture available
> > > for mapping end points config space, IO and BARs. In that, currently
> > > 256MB is being reserved for mapping end points configuration space
> > > which leaves less memory space available for mapping end points BARs
> > > on some of the platforms.
> > > This patch series attempts to map only 4K space from 1GB aperture to
> > > access end points configuration space.
> > >
> > > Currently, this change can benefit T20 and T186 in saving (i.e. repurposed
> > > to use for BAR mapping) physical space as well as kernel virtual mapping space,
> > > it saves only kernel virtual address space in T30, T124, T132 and T210.
> > >
> > > NOTE: Since T186 PCIe DT entry is not yet present in main line (it is currently
> > > merged to 'for-4.15/arm64/dt' branch), nothing gets broken with this change for T186.
> > > For older platforms (T20, T30, T124, T132, T210), this change works fine without any
> > > DT modifications
> > >
> > > Testing Done on T124, T210 & T186:
> > > Enumeration and basic functionality of immediate devices
> > > Enumeration of devices behind a PCIe switch
> > > Complete 4K configuration space access
> > >
> > > Vidya Sagar (2):
> > > PCI: tegra: refactor config space mapping code
> > > ARM64: tegra: limit PCIe config space mapping to 4K for T186
> > >
> > > arch/arm64/boot/dts/nvidia/tegra186.dtsi | 8 +-
> > > drivers/pci/host/pci-tegra.c | 125 ++++++++++---------------------
> > > 2 files changed, 44 insertions(+), 89 deletions(-)
> >
> > Hi Bjorn,
> >
> > there's a bunch of PCI related patches for Tegra floating around on the
> > lists. I'm wondering if you'd be okay if I pick those up into the Tegra
> > tree after they've been reviewed and send you a pull request later on
> > (say around v4.15-rc6). That would allow me to get things cooking in
> > linux-next for a bit and get broader testing in addition to the
> > flexibility to patch things up if they break.
>
> Lorenzo will be merging the Tegra stuff, so this is more a question
> for him.
>
> Just to clarify, I think your questions is about putting those patches
> in
> git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git#for-next.
> If you put them there they will show up in linux-next, and then when
> Lorenzo merges them, you'll have to coordinate so they don't get
> merged into linux-next twice (once via the usual PCI tree route and
> again via the Tegra tree).
>
> If you wait until after they've been reviewed to put them into the
> Tegra tree, I'm not sure what the gain is, because I assume Lorenzo
> would merge them at about that same point.
I think that after the review, the Tegra patches that are considered for
upstream they should go to -next via the PCI tree as any other platform PCI
patches; the relevant patches need ACKs from the respective platform
maintainer - I am getting to them as fast as I can.
> This cycle isn't going to be ideal timing with all the holidays
> coming up. I know I'm going to be traveling and on vacation quite a
> bit in the rc5, 6, 7 timeframe.
Yes timing is not ideal - I won't be able to review anything in the -rc5
week either but apart from that I should be online.
Lorenzo
^ permalink raw reply
* Re: [PATCH v2] ARM: dts: exynos: Enable Mixer node for Exynos5800 Peach Pi machine
From: Marek Szyprowski @ 2017-12-12 10:55 UTC (permalink / raw)
To: Guillaume Tucker, Krzysztof Kozlowski, Javier Martinez Canillas
Cc: linux-kernel, Daniel Vetter, Shuah Khan, devicetree, Kukjin Kim,
Russell King, linux-samsung-soc, Rob Herring, Mark Rutland,
linux-arm-kernel
In-Reply-To: <ad03e2a8-00eb-464e-6983-374f83b9abf5@collabora.com>
Hi Guillaume,
On 2017-12-12 11:43, Guillaume Tucker wrote:
> On 12/12/17 10:17, Marek Szyprowski wrote:
>> Hi Krzysztof,
>>
>> On 2017-12-12 11:09, Krzysztof Kozlowski wrote:
>>> On Tue, Dec 12, 2017 at 10:55 AM, Krzysztof Kozlowski
>>> <krzk@kernel.org> wrote:
>>>> On Tue, Dec 12, 2017 at 8:42 AM, Javier Martinez Canillas
>>>> <javierm@redhat.com> wrote:
>>>>> Commit 1cb686c08d12 ("ARM: dts: exynos: Add status property to
>>>>> Exynos 542x
>>>>> Mixer nodes") disabled the Mixer node by default in the DTSI and
>>>>> enabled
>>>>> for each Exynos 542x DTS. But unfortunately it missed to enable it
>>>>> for the
>>>>> Exynos5800 Peach Pi machine, since the 5800 is also an 542x SoC
>>>>> variant.
>>>>>
>>>>> Fixes: 1cb686c08d12 ("ARM: dts: exynos: Add status property to
>>>>> Exynos 542x Mixer nodes")
>>>>> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
>>>>> Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>>>>
>>>>> ---
>>>>>
>>>>> Changes in v2:
>>>>> - Remove RFT tag.
>>>> Thanks guys! However I still would like to see a tested-by for this on
>>>> Peach Pi (AFAIU, Marek's only acked the code/solution).
>>> On the other hand I could just apply it for my for-next branch and
>>> we'll see if it fixes kernel-ci boot tests... Not a nice way of
>>> testing but apparently no one has Peach Pi.
>>
>> Frankly, I don't expect that this will solve the boot hang issue on
>> PeachPi.
>> However it should at least hide the unbalanced regulator issue.
>
> We have a peach-pi in our LAVA lab so I've tested it and
> actually, it does fix the hang on v4.15-rc3:
>
> https://lava.collabora.co.uk/scheduler/job/1019877
> https://lava.collabora.co.uk/scheduler/job/1019878
>
> I ran it twice and it booted both times. I also ran the same
> boot tests with the same kernel but the dtb from v4.15-rc3
> without the fix to double check and these failed:
>
> https://lava.collabora.co.uk/scheduler/job/1019879
> https://lava.collabora.co.uk/scheduler/job/1019880
>
>
> Tested-by: Guillaume Tucker <guillaume.tucker@collabora.com>
>
>
> Thanks for the fix!
Well, thanks for the test! It proves that there the boot failure is
caused by an issue somewhere in the error path of Exynos DRM, Analogix
DP, Simple Panel or other drivers.
This patch simply hides it by fixing the source issue of the Exynos
DRM initialization failure. :-)
I hope Javier will be able to investigate the discussed hang issue
later, as fixing it is also imho important.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* Re: [RFC PATCH 1/3] dt-bindings: pinctrl: sunxi: document new generic binding
From: Linus Walleij @ 2017-12-12 10:52 UTC (permalink / raw)
To: André Przywara
Cc: Thierry Reding, Maxime Ripard, Chen-Yu Tsai,
linux-gpio-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux ARM, Arnd Bergmann, Icenowy Zheng,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
In-Reply-To: <be52417d-9509-f638-65b6-f455fade0c39-5wv7dgnIgG8@public.gmane.org>
On Wed, Dec 6, 2017 at 1:55 AM, André Przywara <andre.przywara-5wv7dgnIgG8@public.gmane.org> wrote:
> On 01/12/17 09:56, Linus Walleij wrote:
>> It is a valid cause. Just
>> has to be weighed with other stuff, like maintainability, debuggability,
>> maintainers viewpoint. ...
>
> So to keep Maxime happy I actually designed this "driver" more like a
> shim: to generate the table the current driver expects from the DT, and
> actually not touching the existing driver at all.
> So maintainability should actually be less of a concern: the driver will
> just work with whatever one throws at it from the DT side, without
> requiring frequent changes or additions.
> In the moment we still need to write, review and merge *data* files for
> each new SoC. And as I mentioned before, Allwinner decided to push for
> new, slightly different chips every few months, so there will be more to
> come. With at least the pinctrl driver out of the way we have one
> problem less to worry about.
I think you need mainly to convince Maxime that this is something that
he wants to maintain, going forward.
I am as subsystem maintainer pretty pleased as long as standard
properties etc are used to encode the data into the devicetree, and
DT maintrainers are not actively vetoing what you do.
If it leads to a conflict between Allwinner maintainers it is not worth the
effort for reasons that are social rather than technical. To me it is a very
nice but as with all volunteer communities also very vulnerable
endavour.
Please make sure not to push your point so hard that it hurts your
our your colleagues feelings.
I know people are passionate about their ideas, which is usally good
but also scare me sometimes because they sometimes become so
passionate that it makes them bad team players.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2] ARM: dts: exynos: Enable Mixer node for Exynos5800 Peach Pi machine
From: Krzysztof Kozlowski @ 2017-12-12 10:51 UTC (permalink / raw)
To: Guillaume Tucker
Cc: Marek Szyprowski, Javier Martinez Canillas, linux-kernel,
Daniel Vetter, Shuah Khan, devicetree, Kukjin Kim, Russell King,
linux-samsung-soc, Rob Herring, Mark Rutland, linux-arm-kernel
In-Reply-To: <ad03e2a8-00eb-464e-6983-374f83b9abf5@collabora.com>
On Tue, Dec 12, 2017 at 11:43 AM, Guillaume Tucker
<guillaume.tucker@collabora.com> wrote:
> On 12/12/17 10:17, Marek Szyprowski wrote:
>>
>> Hi Krzysztof,
>>
>> On 2017-12-12 11:09, Krzysztof Kozlowski wrote:
>>>
>>> On Tue, Dec 12, 2017 at 10:55 AM, Krzysztof Kozlowski <krzk@kernel.org>
>>> wrote:
>>>>
>>>> On Tue, Dec 12, 2017 at 8:42 AM, Javier Martinez Canillas
>>>> <javierm@redhat.com> wrote:
>>>>>
>>>>> Commit 1cb686c08d12 ("ARM: dts: exynos: Add status property to Exynos
>>>>> 542x
>>>>> Mixer nodes") disabled the Mixer node by default in the DTSI and
>>>>> enabled
>>>>> for each Exynos 542x DTS. But unfortunately it missed to enable it for
>>>>> the
>>>>> Exynos5800 Peach Pi machine, since the 5800 is also an 542x SoC
>>>>> variant.
>>>>>
>>>>> Fixes: 1cb686c08d12 ("ARM: dts: exynos: Add status property to Exynos
>>>>> 542x Mixer nodes")
>>>>> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
>>>>> Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>>>>
>>>>> ---
>>>>>
>>>>> Changes in v2:
>>>>> - Remove RFT tag.
>>>>
>>>> Thanks guys! However I still would like to see a tested-by for this on
>>>> Peach Pi (AFAIU, Marek's only acked the code/solution).
>>>
>>> On the other hand I could just apply it for my for-next branch and
>>> we'll see if it fixes kernel-ci boot tests... Not a nice way of
>>> testing but apparently no one has Peach Pi.
>>
>>
>> Frankly, I don't expect that this will solve the boot hang issue on
>> PeachPi.
>> However it should at least hide the unbalanced regulator issue.
>
>
> We have a peach-pi in our LAVA lab so I've tested it and
> actually, it does fix the hang on v4.15-rc3:
>
> https://lava.collabora.co.uk/scheduler/job/1019877
> https://lava.collabora.co.uk/scheduler/job/1019878
>
> I ran it twice and it booted both times. I also ran the same
> boot tests with the same kernel but the dtb from v4.15-rc3
> without the fix to double check and these failed:
>
> https://lava.collabora.co.uk/scheduler/job/1019879
> https://lava.collabora.co.uk/scheduler/job/1019880
>
>
> Tested-by: Guillaume Tucker <guillaume.tucker@collabora.com>
Thank you!
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2] ARM: dts: exynos: Enable Mixer node for Exynos5800 Peach Pi machine
From: Javier Martinez Canillas @ 2017-12-12 10:51 UTC (permalink / raw)
To: Guillaume Tucker, Marek Szyprowski, Krzysztof Kozlowski
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, Daniel Vetter, Shuah Khan,
devicetree-u79uwXL29TY76Z2rM5mHXA, Kukjin Kim, Russell King,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA, Rob Herring,
Mark Rutland, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Inki Dae
In-Reply-To: <ad03e2a8-00eb-464e-6983-374f83b9abf5-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
[adding Inki to cc list]
Hello Guillaume,
On 12/12/2017 11:43 AM, Guillaume Tucker wrote:
> On 12/12/17 10:17, Marek Szyprowski wrote:
>> Hi Krzysztof,
>>
>> On 2017-12-12 11:09, Krzysztof Kozlowski wrote:
>>> On Tue, Dec 12, 2017 at 10:55 AM, Krzysztof Kozlowski <krzk-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>>>> On Tue, Dec 12, 2017 at 8:42 AM, Javier Martinez Canillas
>>>> <javierm-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>>>>> Commit 1cb686c08d12 ("ARM: dts: exynos: Add status property to Exynos 542x
>>>>> Mixer nodes") disabled the Mixer node by default in the DTSI and enabled
>>>>> for each Exynos 542x DTS. But unfortunately it missed to enable it for the
>>>>> Exynos5800 Peach Pi machine, since the 5800 is also an 542x SoC variant.
>>>>>
>>>>> Fixes: 1cb686c08d12 ("ARM: dts: exynos: Add status property to Exynos 542x Mixer nodes")
>>>>> Signed-off-by: Javier Martinez Canillas <javierm-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>>>>> Acked-by: Marek Szyprowski <m.szyprowski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
>>>>>
>>>>> ---
>>>>>
>>>>> Changes in v2:
>>>>> - Remove RFT tag.
>>>> Thanks guys! However I still would like to see a tested-by for this on
>>>> Peach Pi (AFAIU, Marek's only acked the code/solution).
>>> On the other hand I could just apply it for my for-next branch and
>>> we'll see if it fixes kernel-ci boot tests... Not a nice way of
>>> testing but apparently no one has Peach Pi.
>>
>> Frankly, I don't expect that this will solve the boot hang issue on PeachPi.
>> However it should at least hide the unbalanced regulator issue.
>
> We have a peach-pi in our LAVA lab so I've tested it and
> actually, it does fix the hang on v4.15-rc3:
>
> https://lava.collabora.co.uk/scheduler/job/1019877
> https://lava.collabora.co.uk/scheduler/job/1019878
>
> I ran it twice and it booted both times. I also ran the same
> boot tests with the same kernel but the dtb from v4.15-rc3
> without the fix to double check and these failed:
>
> https://lava.collabora.co.uk/scheduler/job/1019879
> https://lava.collabora.co.uk/scheduler/job/1019880
>
>
> Tested-by: Guillaume Tucker <guillaume.tucker-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
>
>
> Thanks for the fix!
>
Thanks for testing!
Now, I think the exynos-drm driver should cope with an incorrect DTB and
don't crash the machine, the driver should only fail to probe and lead
to a working machine with no display.
But as mentioned, that's a different issue and orthogonal to the DTS fix.
> Guillaume
>
Best regards,
--
Javier Martinez Canillas
Software Engineer - Desktop Hardware Enablement
Red Hat
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/2] dt-bindings: Document the Rockchip RK1608 bindings
From: Heiko Stuebner @ 2017-12-12 10:50 UTC (permalink / raw)
To: linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: mark.rutland-5wv7dgnIgG8, devicetree-u79uwXL29TY76Z2rM5mHXA,
Leo Wen, gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
rdunlap-wEGCiKHe2LqWVfeAwA7xHQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, eddie.cai-TNX95d0MmH7DzftRWevZcw,
mchehab-DgEjT+Ai2ygdnm+yROfE0A, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
linux-media-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1513060095-29588-3-git-send-email-leo.wen-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
Hi Leo,
Am Dienstag, 12. Dezember 2017, 14:28:15 CET schrieb Leo Wen:
> +Optional properties:
> +
> +- spi-max-frequency : Maximum SPI clocking speed of the device;
> + (for RK1608)
> +- spi-min-frequency : Minimum SPI clocking speed of the device;
> + (for RK1608)
There is no general spi-min-frequency property specified and I also guess
systems would try to use a frequency close to maximum anyway, so I don't
really see the use of specifying a minimum frequency.
> +&pinctrl {
> + rk1608_irq_gpios {
> + rk1608_irq_gpios: rk1608_irq_gpios {
> + rockchip,pins = <6 2 RK_FUNC_GPIO &pcfg_pull_none>;
> + rockchip,pull = <1>;
> + };
> + };
There is no need to specify the soc-specific pinctrl settings in a general
devicetree example and you're using properties from your vendor-tree
like the rockchip,pull one ... that are not used in the mainline kernel.
So I'd suggest dropping the whole &pinctrl from the example.
Heiko
^ permalink raw reply
* Re: [PATCH v3 3/3] ARM: dts: exynos: Add nodes for True Random Number Generator
From: Krzysztof Kozlowski @ 2017-12-12 10:49 UTC (permalink / raw)
To: Łukasz Stelmach
Cc: Andrew F . Davis, PrasannaKumar Muralidharan, Rob Herring,
Matt Mackall, Herbert Xu, Kukjin Kim, devicetree, linux-crypto,
linux-samsung-soc, linux-kernel, Marek Szyprowski,
Bartlomiej Zolnierkiewicz
In-Reply-To: <87k1xs6xo3.fsf%l.stelmach@samsung.com>
On Tue, Dec 12, 2017 at 11:35 AM, Łukasz Stelmach
<l.stelmach@samsung.com> wrote:
> It was <2017-12-11 pon 19:49>, when Krzysztof Kozlowski wrote:
>> On Mon, Dec 04, 2017 at 01:53:51PM +0100, Łukasz Stelmach wrote:
>>> Add nodes for the True Random Number Generator found in Samsung Exynos
>>> 5250+ SoCs.
>>>
>>> Signed-off-by: Łukasz Stelmach <l.stelmach@samsung.com>
>>> ---
>>> arch/arm/boot/dts/exynos5.dtsi | 5 +++++
>>> arch/arm/boot/dts/exynos5250.dtsi | 5 +++++
>>> arch/arm/boot/dts/exynos5410.dtsi | 5 +++++
>>> arch/arm/boot/dts/exynos5420.dtsi | 5 +++++
>>> 4 files changed, 20 insertions(+)
>>>
>>
>> Unfortunately the same story as with your PRNG patch - does not apply on
>> top of my next/dt (after taking PRNG). Also did not apply on v4.15-rc1 +
>> PRNG.
>>
>> Could you rebase on my next/dt?
>
> Sure. Should I send it as along with the other two patches, if there were
> no changes in them since?
It is fine to resend just this one as it will go through different tree anyway.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] of_mdio / mdiobus: ensure mdio devices have fwnode correctly populated
From: Russell King @ 2017-12-12 10:49 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, Rob Herring
Cc: Frank Rowand, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
Ensure that all mdio devices populate the struct device fwnode pointer
as well as the of_node pointer to allow drivers that wish to use
fwnode APIs to work.
Signed-off-by: Russell King <rmk+kernel-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>
---
drivers/net/phy/mdio_bus.c | 1 +
drivers/of/of_mdio.c | 3 +++
2 files changed, 4 insertions(+)
diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
index d9a185ed0286..c3458b6de7ca 100644
--- a/drivers/net/phy/mdio_bus.c
+++ b/drivers/net/phy/mdio_bus.c
@@ -270,6 +270,7 @@ static void of_mdiobus_link_mdiodev(struct mii_bus *bus,
if (addr == mdiodev->addr) {
dev->of_node = child;
+ dev->fwnode = of_fwnode_handle(child);
return;
}
}
diff --git a/drivers/of/of_mdio.c b/drivers/of/of_mdio.c
index 98258583abb0..3481e69738b5 100644
--- a/drivers/of/of_mdio.c
+++ b/drivers/of/of_mdio.c
@@ -81,6 +81,7 @@ static int of_mdiobus_register_phy(struct mii_bus *mdio,
* can be looked up later */
of_node_get(child);
phy->mdio.dev.of_node = child;
+ phy->mdio.dev.fwnode = of_fwnode_handle(child);
/* All data is now stored in the phy struct;
* register it */
@@ -111,6 +112,7 @@ static int of_mdiobus_register_device(struct mii_bus *mdio,
*/
of_node_get(child);
mdiodev->dev.of_node = child;
+ mdiodev->dev.fwnode = of_fwnode_handle(child);
/* All data is now stored in the mdiodev struct; register it. */
rc = mdio_device_register(mdiodev);
@@ -206,6 +208,7 @@ int of_mdiobus_register(struct mii_bus *mdio, struct device_node *np)
mdio->phy_mask = ~0;
mdio->dev.of_node = np;
+ mdio->dev.fwnode = of_fwnode_handle(np);
/* Get bus level PHY reset GPIO details */
mdio->reset_delay_us = DEFAULT_GPIO_RESET_DELAY;
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH v2] ARM: dts: exynos: Enable Mixer node for Exynos5800 Peach Pi machine
From: Guillaume Tucker @ 2017-12-12 10:43 UTC (permalink / raw)
To: Marek Szyprowski, Krzysztof Kozlowski, Javier Martinez Canillas
Cc: linux-kernel, Daniel Vetter, Shuah Khan, devicetree, Kukjin Kim,
Russell King, linux-samsung-soc, Rob Herring, Mark Rutland,
linux-arm-kernel
In-Reply-To: <a42670aa-b3df-7a53-8ed2-f3acd97fd0d4@samsung.com>
On 12/12/17 10:17, Marek Szyprowski wrote:
> Hi Krzysztof,
>
> On 2017-12-12 11:09, Krzysztof Kozlowski wrote:
>> On Tue, Dec 12, 2017 at 10:55 AM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>>> On Tue, Dec 12, 2017 at 8:42 AM, Javier Martinez Canillas
>>> <javierm@redhat.com> wrote:
>>>> Commit 1cb686c08d12 ("ARM: dts: exynos: Add status property to Exynos 542x
>>>> Mixer nodes") disabled the Mixer node by default in the DTSI and enabled
>>>> for each Exynos 542x DTS. But unfortunately it missed to enable it for the
>>>> Exynos5800 Peach Pi machine, since the 5800 is also an 542x SoC variant.
>>>>
>>>> Fixes: 1cb686c08d12 ("ARM: dts: exynos: Add status property to Exynos 542x Mixer nodes")
>>>> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
>>>> Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>>>
>>>> ---
>>>>
>>>> Changes in v2:
>>>> - Remove RFT tag.
>>> Thanks guys! However I still would like to see a tested-by for this on
>>> Peach Pi (AFAIU, Marek's only acked the code/solution).
>> On the other hand I could just apply it for my for-next branch and
>> we'll see if it fixes kernel-ci boot tests... Not a nice way of
>> testing but apparently no one has Peach Pi.
>
> Frankly, I don't expect that this will solve the boot hang issue on PeachPi.
> However it should at least hide the unbalanced regulator issue.
We have a peach-pi in our LAVA lab so I've tested it and
actually, it does fix the hang on v4.15-rc3:
https://lava.collabora.co.uk/scheduler/job/1019877
https://lava.collabora.co.uk/scheduler/job/1019878
I ran it twice and it booted both times. I also ran the same
boot tests with the same kernel but the dtb from v4.15-rc3
without the fix to double check and these failed:
https://lava.collabora.co.uk/scheduler/job/1019879
https://lava.collabora.co.uk/scheduler/job/1019880
Tested-by: Guillaume Tucker <guillaume.tucker@collabora.com>
Thanks for the fix!
Guillaume
^ permalink raw reply
* Re: [PATCH 4/4] [v4] pinctrl: qcom: qdf2xxx: add support for new ACPI HID QCOM8002
From: Linus Walleij @ 2017-12-12 10:42 UTC (permalink / raw)
To: Timur Tabi,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
Cc: linux-arm-msm-u79uwXL29TY76Z2rM5mHXA, Linux ARM,
linux-gpio-u79uwXL29TY76Z2rM5mHXA, Andy Shevchenko,
Mika Westerberg,
thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
Stephen Boyd, David Brown, Andy Gross, Bjorn Andersson,
Varadarajan Narayanan, Archit Taneja
In-Reply-To: <1512170904-4749-5-git-send-email-timur-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
On Sat, Dec 2, 2017 at 12:28 AM, Timur Tabi <timur-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> wrote:
> /* Query the number of GPIOs from ACPI */
> ret = device_property_read_u32(&pdev->dev, "num-gpios", &num_gpios);
> if (ret < 0) {
> - dev_warn(&pdev->dev, "missing num-gpios property\n");
> + dev_err(&pdev->dev, "missing 'num-gpios' property\n");
> return ret;
> }
It's unfortunate that this driver uses the undocumented "num-gpios"
when the device tree bindings already has standardized "ngpios"
as the name for this.
Maybe it was not standardized back in 2015 when this driver was merged.
Or we were all sloppy :/
> + /* The number of GPIOs in the approved list */
> + ret = device_property_read_u16_array(&pdev->dev, "gpios",
> + NULL, 0);
> + if (ret < 0) {
> + dev_err(&pdev->dev, "missing 'gpios' property\n");
> + return ret;
> + }
This is in direct conflict with the existing "gpios" binding in device tree.
Where is this name coming from? ACPI standards?
If device tree and ACPI start defining things which are in direct conflict
we can just shut down this device_property() business altogether,
it will never work that way.
I would try to merge a DT bindings doc defining "valid-gpios" or something
like this, can we proceed like that?
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2] ARM: dts: exynos: Enable Mixer node for Exynos5800 Peach Pi machine
From: Javier Martinez Canillas @ 2017-12-12 10:40 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: linux-kernel, Marek Szyprowski, Guillaume Tucker, Daniel Vetter,
Shuah Khan, devicetree, Kukjin Kim, Russell King,
linux-samsung-soc, Rob Herring, Mark Rutland, linux-arm-kernel
In-Reply-To: <CAJKOXPc1_n2cdgjuFbA9jNdcSXxfr8Zjf=fUx_jt_N3+LP0n8A@mail.gmail.com>
Hello Krzysztof,
On 12/12/2017 11:09 AM, Krzysztof Kozlowski wrote:
> On Tue, Dec 12, 2017 at 10:55 AM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>> On Tue, Dec 12, 2017 at 8:42 AM, Javier Martinez Canillas
>> <javierm@redhat.com> wrote:
>>> Commit 1cb686c08d12 ("ARM: dts: exynos: Add status property to Exynos 542x
>>> Mixer nodes") disabled the Mixer node by default in the DTSI and enabled
>>> for each Exynos 542x DTS. But unfortunately it missed to enable it for the
>>> Exynos5800 Peach Pi machine, since the 5800 is also an 542x SoC variant.
>>>
>>> Fixes: 1cb686c08d12 ("ARM: dts: exynos: Add status property to Exynos 542x Mixer nodes")
>>> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
>>> Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>>
>>> ---
>>>
>>> Changes in v2:
>>> - Remove RFT tag.
I removed the tag because Marek acked it and the patch has merits on its own
regardless of the boot issue (it just introduces a change that was missed in
the mentioned commit).
>>
>> Thanks guys! However I still would like to see a tested-by for this on
>> Peach Pi (AFAIU, Marek's only acked the code/solution).
>
> On the other hand I could just apply it for my for-next branch and
> we'll see if it fixes kernel-ci boot tests... Not a nice way of
As Marek said this probably won't solve the issue, or at best it would just
mask it. Seems the problem is on the probe deferral path in exynos-drm driver.
> testing but apparently no one has Peach Pi.
>
I do have one, but I haven't used it for months and don't have time to setup
a test environment now. I will probably do that this weekend to dig deeper.
> Best regards,
> Krzysztof
>
Best regards,
--
Javier Martinez Canillas
Software Engineer - Desktop Hardware Enablement
Red Hat
^ permalink raw reply
* Re: [PATCH v3 3/3] ARM: dts: exynos: Add nodes for True Random Number Generator
From: Łukasz Stelmach @ 2017-12-12 10:35 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Andrew F . Davis, PrasannaKumar Muralidharan, Rob Herring,
Matt Mackall, Herbert Xu, Kukjin Kim, devicetree, linux-crypto,
linux-samsung-soc, linux-kernel, Marek Szyprowski,
Bartlomiej Zolnierkiewicz
In-Reply-To: <20171211184913.n67q7vbv2gzknjeb@kozik-lap>
[-- Attachment #1: Type: text/plain, Size: 919 bytes --]
It was <2017-12-11 pon 19:49>, when Krzysztof Kozlowski wrote:
> On Mon, Dec 04, 2017 at 01:53:51PM +0100, Łukasz Stelmach wrote:
>> Add nodes for the True Random Number Generator found in Samsung Exynos
>> 5250+ SoCs.
>>
>> Signed-off-by: Łukasz Stelmach <l.stelmach@samsung.com>
>> ---
>> arch/arm/boot/dts/exynos5.dtsi | 5 +++++
>> arch/arm/boot/dts/exynos5250.dtsi | 5 +++++
>> arch/arm/boot/dts/exynos5410.dtsi | 5 +++++
>> arch/arm/boot/dts/exynos5420.dtsi | 5 +++++
>> 4 files changed, 20 insertions(+)
>>
>
> Unfortunately the same story as with your PRNG patch - does not apply on
> top of my next/dt (after taking PRNG). Also did not apply on v4.15-rc1 +
> PRNG.
>
> Could you rebase on my next/dt?
Sure. Should I send it as along with the other two patches, if there were
no changes in them since?
--
Łukasz Stelmach
Samsung R&D Institute Poland
Samsung Electronics
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 472 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] pinctrl: sunxi: Disable strict mode for H5 driver
From: Chris Obbard @ 2017-12-12 10:35 UTC (permalink / raw)
To: Linus Walleij
Cc: Andre Przywara, Maxime Ripard, Chen-Yu Tsai, Rob Herring,
Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux ARM, linux-gpio-u79uwXL29TY76Z2rM5mHXA, linux-sunxi
In-Reply-To: <CACRpkdaa0rMxaMseTxXryV7=AhWDQgsO_ZGTj-zGzaqBLFp5sw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1647 bytes --]
Excellent, thanks Linus. The new DTS files are not in mainline, but this
can wait ;-)
Cheers!
On 12 December 2017 at 08:52, Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
wrote:
> On Thu, Nov 30, 2017 at 5:07 PM, Andre Przywara <andre.przywara-5wv7dgnIgG8@public.gmane.org>
> wrote:
> > On 30/11/17 15:51, Linus Walleij wrote:
> >> On Sat, Nov 25, 2017 at 1:02 PM, Andre Przywara <andre.przywara-5wv7dgnIgG8@public.gmane.org>
> wrote:
> >>
> >>> All of the H5 boards in the kernel reference the MMC0 CD pin twice in
> >>> their DT, so strict mode will make the MMC driver fail to load.
> >>> To keep existing DTs working, disable strict mode in the H5 driver.
> >>>
> >>> Signed-off-by: Andre Przywara <andre.przywara-5wv7dgnIgG8@public.gmane.org>
> >>> Reported-by: Chris Obbard <obbardc-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> >>
> >> Patch applied with Maxime's ACK.
> >
> > Thanks for that (also to Maxime and Chen-Yu) and the smooth handling!
> >
> > Sorry, I just see that I didn't point this out explicitly, but this is
> > to fix a regression introduced in 4.15-rc1, so is this on a branch that
> > will be pushed for 4.15-rc, still? (Couldn't find anything quickly on
> > kernel.org)
>
> Should be upstream as:
> commit 07c43a382d7de3db01cc28bf2e17ed151cde2046
>
> Yours,
> Linus Walleij
>
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
[-- Attachment #2: Type: text/html, Size: 2714 bytes --]
^ permalink raw reply
* Re: [PATCH v2] ARM: dts: exynos: Enable Mixer node for Exynos5800 Peach Pi machine
From: Marek Szyprowski @ 2017-12-12 10:17 UTC (permalink / raw)
To: Krzysztof Kozlowski, Javier Martinez Canillas
Cc: linux-kernel, Guillaume Tucker, Daniel Vetter, Shuah Khan,
devicetree, Kukjin Kim, Russell King, linux-samsung-soc,
Rob Herring, Mark Rutland, linux-arm-kernel
In-Reply-To: <CAJKOXPc1_n2cdgjuFbA9jNdcSXxfr8Zjf=fUx_jt_N3+LP0n8A@mail.gmail.com>
Hi Krzysztof,
On 2017-12-12 11:09, Krzysztof Kozlowski wrote:
> On Tue, Dec 12, 2017 at 10:55 AM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>> On Tue, Dec 12, 2017 at 8:42 AM, Javier Martinez Canillas
>> <javierm@redhat.com> wrote:
>>> Commit 1cb686c08d12 ("ARM: dts: exynos: Add status property to Exynos 542x
>>> Mixer nodes") disabled the Mixer node by default in the DTSI and enabled
>>> for each Exynos 542x DTS. But unfortunately it missed to enable it for the
>>> Exynos5800 Peach Pi machine, since the 5800 is also an 542x SoC variant.
>>>
>>> Fixes: 1cb686c08d12 ("ARM: dts: exynos: Add status property to Exynos 542x Mixer nodes")
>>> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
>>> Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>>
>>> ---
>>>
>>> Changes in v2:
>>> - Remove RFT tag.
>> Thanks guys! However I still would like to see a tested-by for this on
>> Peach Pi (AFAIU, Marek's only acked the code/solution).
> On the other hand I could just apply it for my for-next branch and
> we'll see if it fixes kernel-ci boot tests... Not a nice way of
> testing but apparently no one has Peach Pi.
Frankly, I don't expect that this will solve the boot hang issue on PeachPi.
However it should at least hide the unbalanced regulator issue.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* Re: [PATCH v2] ARM: dts: exynos: Enable Mixer node for Exynos5800 Peach Pi machine
From: Krzysztof Kozlowski @ 2017-12-12 10:09 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: linux-kernel, Marek Szyprowski, Guillaume Tucker, Daniel Vetter,
Shuah Khan, devicetree, Kukjin Kim, Russell King,
linux-samsung-soc, Rob Herring, Mark Rutland, linux-arm-kernel
In-Reply-To: <CAJKOXPc1rJCWABXUuyU2MKxnLY-MptrM9Mm0HyHVCJn870R+sg@mail.gmail.com>
On Tue, Dec 12, 2017 at 10:55 AM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On Tue, Dec 12, 2017 at 8:42 AM, Javier Martinez Canillas
> <javierm@redhat.com> wrote:
>> Commit 1cb686c08d12 ("ARM: dts: exynos: Add status property to Exynos 542x
>> Mixer nodes") disabled the Mixer node by default in the DTSI and enabled
>> for each Exynos 542x DTS. But unfortunately it missed to enable it for the
>> Exynos5800 Peach Pi machine, since the 5800 is also an 542x SoC variant.
>>
>> Fixes: 1cb686c08d12 ("ARM: dts: exynos: Add status property to Exynos 542x Mixer nodes")
>> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
>> Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>
>> ---
>>
>> Changes in v2:
>> - Remove RFT tag.
>
> Thanks guys! However I still would like to see a tested-by for this on
> Peach Pi (AFAIU, Marek's only acked the code/solution).
On the other hand I could just apply it for my for-next branch and
we'll see if it fixes kernel-ci boot tests... Not a nice way of
testing but apparently no one has Peach Pi.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v5 1/3] clocksource/drivers/atcpit100: Add andestech atcpit100 timer
From: Daniel Lezcano @ 2017-12-12 10:05 UTC (permalink / raw)
To: Rick Chen, rick, linux-kernel, arnd, linus.walleij, linux-arch,
tglx, jason, marc.zyngier, robh+dt, netdev, deanbo422, devicetree,
viro, dhowells, will.deacon, linux-serial
Cc: Greentime Hu
In-Reply-To: <1513057621-19084-2-git-send-email-rickchen36@gmail.com>
On 12/12/2017 06:46, Rick Chen wrote:
> ATCPIT100 is often used on the Andes architecture,
> This timer provide 4 PIT channels. Each PIT channel is a
> multi-function timer, can be configured as 32,16,8 bit timers
> or PWM as well.
>
> For system timer it will set channel 1 32-bit timer0 as clock
> source and count downwards until underflow and restart again.
[ ... ]
> +config CLKSRC_ATCPIT100
> + bool "Clocksource for AE3XX platform"
> + depends on NDS32 || COMPILE_TEST
> + depends on HAS_IOMEM
> + help
> + This option enables support for the Andestech AE3XX platform timers.
Hi Rick,
the general rule for the Kconfig is:
bool "Clocksource for AE3XX platform" if COMPILE_TEST
and no deps on the platform.
It is up to the platform Kconfig to select the option.
We want here a silent option but make it selectable in case of
compilation test coverage.
Also, this driver is not a CLKSRC but a TIMER. Rename CLKSRC_ATCPIT100
to TIMER_ATCPIT100.
> +
> endmenu
> diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
> index 72711f1..7d072f5 100644
> --- a/drivers/clocksource/Makefile
> +++ b/drivers/clocksource/Makefile
> @@ -75,3 +75,4 @@ obj-$(CONFIG_H8300_TMR16) += h8300_timer16.o
> obj-$(CONFIG_H8300_TPU) += h8300_tpu.o
> obj-$(CONFIG_CLKSRC_ST_LPC) += clksrc_st_lpc.o
> obj-$(CONFIG_X86_NUMACHIP) += numachip.o
> +obj-$(CONFIG_CLKSRC_ATCPIT100) += timer-atcpit100.o
[ ... ]
> +static struct timer_of to = {
> + .flags = TIMER_OF_IRQ | TIMER_OF_CLOCK | TIMER_OF_BASE,
> +
> + .clkevt = {
> + .name = "atcpit100_tick",
> + .rating = 300,
> + .features = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT,
> + .set_state_shutdown = atcpit100_clkevt_shutdown,
> + .set_state_periodic = atcpit100_clkevt_set_periodic,
> + .set_state_oneshot = atcpit100_clkevt_set_oneshot,
> + .tick_resume = atcpit100_clkevt_shutdown,
> + .set_next_event = atcpit100_clkevt_next_event,
> + .cpumask = cpu_all_mask,
You may consider CLOCK_EVT_DYN_IRQ
https://lwn.net/Articles/540160/
> + },
> +
> + .of_irq = {
> + .handler = atcpit100_timer_interrupt,
> + .flags = IRQF_TIMER | IRQF_IRQPOLL,
> + },
> +
> + /*
> + * FIXME: we currently only support clocking using PCLK
> + * and using EXTCLK is not supported in the driver.
> + */
> + .of_clk = {
> + .name = "PCLK",
> + }
What do you mean ? We can't specify several clock names with timer-of?
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply
* Re: [PATCH 0/4] Sunxi: Add SMP support on A83T
From: Mylene JOSSERAND @ 2017-12-12 10:01 UTC (permalink / raw)
To: Corentin Labbe
Cc: maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8,
thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20171212104025.0bba3685-K8i4uRanGBt8XcdJbWeDu7NAH6kLmebB@public.gmane.org>
Le Tue, 12 Dec 2017 10:40:25 +0100,
Mylene JOSSERAND <mylene.josserand-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> a écrit :
[...]
> I have done further tests.
>
> I booted a previous kernel that I know it was working fine (kernel
> v4.13) then, I booted the kernel with this series and it worked just
> fine.
>
> Only after a power cycle, I am able to reproduce the error, otherwise,
> it is working well. See the boot log of this two tests:
> http://code.bulix.org/7kr0e0-239697?raw
I wrote this mail too fast, I am wrong, the error I had/copied is not
the same error than Corentin is having (and I have 8 CPUS up).
--
Mylène Josserand, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2] ARM: dts: exynos: Enable Mixer node for Exynos5800 Peach Pi machine
From: Krzysztof Kozlowski @ 2017-12-12 9:55 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: linux-kernel, Marek Szyprowski, Guillaume Tucker, Daniel Vetter,
Shuah Khan, devicetree, Kukjin Kim, Russell King,
linux-samsung-soc, Rob Herring, Mark Rutland, linux-arm-kernel
In-Reply-To: <20171212074208.30753-1-javierm@redhat.com>
On Tue, Dec 12, 2017 at 8:42 AM, Javier Martinez Canillas
<javierm@redhat.com> wrote:
> Commit 1cb686c08d12 ("ARM: dts: exynos: Add status property to Exynos 542x
> Mixer nodes") disabled the Mixer node by default in the DTSI and enabled
> for each Exynos 542x DTS. But unfortunately it missed to enable it for the
> Exynos5800 Peach Pi machine, since the 5800 is also an 542x SoC variant.
>
> Fixes: 1cb686c08d12 ("ARM: dts: exynos: Add status property to Exynos 542x Mixer nodes")
> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
> Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
>
> ---
>
> Changes in v2:
> - Remove RFT tag.
Thanks guys! However I still would like to see a tested-by for this on
Peach Pi (AFAIU, Marek's only acked the code/solution).
Best regards,
Krzysztof
> - Add Marek's Acked-by tag.
> - Add fixes tag.
>
> arch/arm/boot/dts/exynos5800-peach-pi.dts | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts b/arch/arm/boot/dts/exynos5800-peach-pi.dts
> index b2b95ff205e8..0029ec27819c 100644
> --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
> +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
> @@ -664,6 +664,10 @@
> status = "okay";
> };
>
> +&mixer {
> + status = "okay";
> +};
> +
> /* eMMC flash */
> &mmc_0 {
> status = "okay";
> --
> 2.14.3
>
^ permalink raw reply
* Re: [PATCH v3 2/2] clocksource: sprd: Add timer driver for Spreadtrum SC9860 platform
From: Daniel Lezcano @ 2017-12-12 9:43 UTC (permalink / raw)
To: Baolin Wang
Cc: Baolin Wang, Thomas Gleixner, Rob Herring, Mark Rutland, DTML,
LKML, Mark Brown, Chunyan Zhang
In-Reply-To: <CAMz4ku+4F6dLSrt=D9mt7=aaQu1G=deiK50YhBDnTN2jKtFGrA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 12/12/2017 10:41, Baolin Wang wrote:
> Hi Daniel,
>
> On 12 December 2017 at 17:26, Baolin Wang <baolin.wang-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>> Hi Daniel,
>>
>> On 12 December 2017 at 17:16, Daniel Lezcano <daniel.lezcano-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>>>
>>> Hi Baolin,
>>>
>>>
>>> On 08/12/2017 09:20, Baolin Wang wrote:
>>>
>>> [ ... ]
>>>
>>>>>> +static irqreturn_t sprd_timer_interrupt(int irq, void *dev_id)
>>>>>> +{
>>>>>> + struct clock_event_device *ce = (struct clock_event_device *)dev_id;
>>>>>> + struct timer_of *to = to_timer_of(ce);
>>>>>> +
>>>>>> + sprd_timer_clear_interrupt(timer_of_base(to));
>>>>>> +
>>>>>> + if (clockevent_state_oneshot(ce))
>>>>>> + sprd_timer_disable(timer_of_base(to));
>>>>>> +
>>>>>> + ce->event_handler(ce);
>>>>>> + return IRQ_HANDLED;
>>>>>> +}
>>>>>> +
>>>>>> +static struct timer_of to = {
>>>>>> + .flags = TIMER_OF_IRQ | TIMER_OF_BASE,
>>>>>
>>>>> Why not the TIMER_OF_CLOCK ?
>>>>
>>>> The timer's clock is fixed to 32.768K and no need to divide the
>>>> frequency, so our clock tree does not supply the timer's clock now.
>>>
>>> The driver is fine. However, I would like to unify the clk usage in the
>>> timer driver, so if you refer to a clock so the TIMER_OF_CLOCK can be
>>> used, that will nice.
>>
>> I understand your concern, but I've asked our clock driver owner in
>> Spreadtrum, we have no related registers to describe the topology of
>> the RTC fixed 32.768K, so the clock driver can not add timer's clock
>> node.
>
> Sorry for my misunderstanding, I confirmed with Chunyan (who
> upstreamed our clock driver), she told me that we can get the clock
> rate from clock node. I will fix this issue in next version. Thanks
> for your comments.
Great, thanks Baolin.
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 2/2] clocksource: sprd: Add timer driver for Spreadtrum SC9860 platform
From: Arnd Bergmann @ 2017-12-12 9:42 UTC (permalink / raw)
To: Baolin Wang
Cc: Daniel Lezcano, Baolin Wang, Thomas Gleixner, Rob Herring,
Mark Rutland, DTML, LKML, Mark Brown
In-Reply-To: <CAMz4kuLQyD5=X7PEOX98_drt66yc=Fq+KxMFHDW6tp_yZsxtsQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Tue, Dec 12, 2017 at 10:26 AM, Baolin Wang <baolin.wang-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> On 12 December 2017 at 17:16, Daniel Lezcano <daniel.lezcano-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>> On 08/12/2017 09:20, Baolin Wang wrote:
>>>>> +static irqreturn_t sprd_timer_interrupt(int irq, void *dev_id)
>>>>> +{
>>>>> + struct clock_event_device *ce = (struct clock_event_device *)dev_id;
>>>>> + struct timer_of *to = to_timer_of(ce);
>>>>> +
>>>>> + sprd_timer_clear_interrupt(timer_of_base(to));
>>>>> +
>>>>> + if (clockevent_state_oneshot(ce))
>>>>> + sprd_timer_disable(timer_of_base(to));
>>>>> +
>>>>> + ce->event_handler(ce);
>>>>> + return IRQ_HANDLED;
>>>>> +}
>>>>> +
>>>>> +static struct timer_of to = {
>>>>> + .flags = TIMER_OF_IRQ | TIMER_OF_BASE,
>>>>
>>>> Why not the TIMER_OF_CLOCK ?
>>>
>>> The timer's clock is fixed to 32.768K and no need to divide the
>>> frequency, so our clock tree does not supply the timer's clock now.
>>
>> The driver is fine. However, I would like to unify the clk usage in the
>> timer driver, so if you refer to a clock so the TIMER_OF_CLOCK can be
>> used, that will nice.
>
> I understand your concern, but I've asked our clock driver owner in
> Spreadtrum, we have no related registers to describe the topology of
> the RTC fixed 32.768K, so the clock driver can not add timer's clock
> node.
I think you can easily put a separate DT node in the tree with
compatible="fixed-clock". This will be available during early boot,
and interpreted by setting TIMER_OF_CLOCK.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 2/2] clocksource: sprd: Add timer driver for Spreadtrum SC9860 platform
From: Baolin Wang @ 2017-12-12 9:41 UTC (permalink / raw)
To: Daniel Lezcano
Cc: Baolin Wang, Thomas Gleixner, Rob Herring, Mark Rutland, DTML,
LKML, Mark Brown, Chunyan Zhang
In-Reply-To: <CAMz4kuLQyD5=X7PEOX98_drt66yc=Fq+KxMFHDW6tp_yZsxtsQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi Daniel,
On 12 December 2017 at 17:26, Baolin Wang <baolin.wang-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> Hi Daniel,
>
> On 12 December 2017 at 17:16, Daniel Lezcano <daniel.lezcano-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>>
>> Hi Baolin,
>>
>>
>> On 08/12/2017 09:20, Baolin Wang wrote:
>>
>> [ ... ]
>>
>>>>> +static irqreturn_t sprd_timer_interrupt(int irq, void *dev_id)
>>>>> +{
>>>>> + struct clock_event_device *ce = (struct clock_event_device *)dev_id;
>>>>> + struct timer_of *to = to_timer_of(ce);
>>>>> +
>>>>> + sprd_timer_clear_interrupt(timer_of_base(to));
>>>>> +
>>>>> + if (clockevent_state_oneshot(ce))
>>>>> + sprd_timer_disable(timer_of_base(to));
>>>>> +
>>>>> + ce->event_handler(ce);
>>>>> + return IRQ_HANDLED;
>>>>> +}
>>>>> +
>>>>> +static struct timer_of to = {
>>>>> + .flags = TIMER_OF_IRQ | TIMER_OF_BASE,
>>>>
>>>> Why not the TIMER_OF_CLOCK ?
>>>
>>> The timer's clock is fixed to 32.768K and no need to divide the
>>> frequency, so our clock tree does not supply the timer's clock now.
>>
>> The driver is fine. However, I would like to unify the clk usage in the
>> timer driver, so if you refer to a clock so the TIMER_OF_CLOCK can be
>> used, that will nice.
>
> I understand your concern, but I've asked our clock driver owner in
> Spreadtrum, we have no related registers to describe the topology of
> the RTC fixed 32.768K, so the clock driver can not add timer's clock
> node.
Sorry for my misunderstanding, I confirmed with Chunyan (who
upstreamed our clock driver), she told me that we can get the clock
rate from clock node. I will fix this issue in next version. Thanks
for your comments.
--
Baolin.wang
Best Regards
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ 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