* Re: [PATCH v2 06/15] drm/mxsfb: Update mxsfb with additional pixel formats
From: Daniel Stone @ 2019-08-14 11:44 UTC (permalink / raw)
To: Robert Chiras
Cc: Marek Vasut, Mark Rutland, Pengutronix Kernel Team, dri-devel,
devicetree, David Airlie, Fabio Estevam, Guido Günther,
Linux Kernel Mailing List, Stefan Agner, Rob Herring,
NXP Linux Team, Daniel Vetter, Shawn Guo, Sascha Hauer,
linux-arm-kernel
In-Reply-To: <1565779731-1300-7-git-send-email-robert.chiras@nxp.com>
Hi Robert,
On Wed, 14 Aug 2019 at 11:49, Robert Chiras <robert.chiras@nxp.com> wrote:
> + case DRM_FORMAT_BGR565: /* BG16 */
> + if (mxsfb->devdata->ipversion < 4)
> + goto err;
> + writel(CTRL2_ODD_LINE_PATTERN(CTRL2_LINE_PATTERN_BGR) |
> + CTRL2_EVEN_LINE_PATTERN(CTRL2_LINE_PATTERN_BGR),
> + mxsfb->base + LCDC_V4_CTRL2 + REG_SET);
> + /* Fall through */
> + case DRM_FORMAT_RGB565: /* RG16 */
> + ctrl |= CTRL_SET_WORD_LENGTH(0);
> + ctrl &= ~CTRL_DF16;
> + ctrl1 |= CTRL1_SET_BYTE_PACKAGING(0xf);
> + break;
For non-BGR formats, do you need to write RGB line-pattern back to the
CTRL2 register? Otherwise, if you start with BGR565 then switch back
to RGB565, presumably CTRL2 would still be programmed for BGR so you
would display inverted channels.
Same goes for all the other BGR/RGB format pairs below.
Cheers,
Daniel
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V5 00/12] 52-bit kernel + user VAs
From: Bhupesh Sharma @ 2019-08-14 11:59 UTC (permalink / raw)
To: Will Deacon
Cc: Christoph von Recklinghausen, Ard Biesheuvel, Catalin Marinas,
Steve Capper, Linux-Renesas, Geert Uytterhoeven, maz, Linux ARM
In-Reply-To: <20190814082137.mnk242lp2vw5b4ot@willie-the-truck>
On Wed, Aug 14, 2019 at 1:51 PM Will Deacon <will@kernel.org> wrote:
>
> On Wed, Aug 14, 2019 at 01:34:49PM +0530, Bhupesh Sharma wrote:
> > I still see the following issue on a 48-bit hardware (i.e. _non_
> > ARMv8.2 hardware) with branch 'for-next/52-bit-kva' with commit
> > d2d73d2fef421ca0d4 as the HEAD:
>
> Have you tried the patches I posted here:
>
> http://lists.infradead.org/pipermail/linux-arm-kernel/2019-August/673315.html
>
> ?
>
> Whilst they're being reviewed, I've dropped the 52-bit branch from
> linux-next (for-next/core) so that people don't keep running into this.
Thanks will try the above and get back with my results.
However just to make sure that the 52-bit changes are tested properly
(before landing up linux-next) - as we had issues with the 52-bit User
space VA + PA changes in the past (which broke userspace), I was
wondering if we can have a dedicated branch to have the v5 patches
from Steve + fixes, so that they can be easily tested and issues (if
any) reported with easy reference.
Or, if such a branch already exists, kindly share the pointer to the
same as well.
Thanks,
Bhupesh
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 5/8] arm64: memory: Simplify _VA_START and _PAGE_OFFSET definitions
From: Will Deacon @ 2019-08-14 12:00 UTC (permalink / raw)
To: Mark Rutland
Cc: Steve Capper, Andrey Konovalov, Geert Uytterhoeven,
Catalin Marinas, Qian Cai, linux-arm-kernel
In-Reply-To: <20190814112337.GB17931@lakrids.cambridge.arm.com>
On Wed, Aug 14, 2019 at 12:23:39PM +0100, Mark Rutland wrote:
> On Tue, Aug 13, 2019 at 06:01:46PM +0100, Will Deacon wrote:
> > Rather than subtracting from -1 and then adding 1, we can simply
> > subtract from 0.
> >
> > Cc: Steve Capper <steve.capper@arm.com>
> > Signed-off-by: Will Deacon <will@kernel.org>
> > ---
> > arch/arm64/include/asm/memory.h | 6 ++----
> > 1 file changed, 2 insertions(+), 4 deletions(-)
> >
> > diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> > index 56be462c69ce..5552c8cba1e2 100644
> > --- a/arch/arm64/include/asm/memory.h
> > +++ b/arch/arm64/include/asm/memory.h
> > @@ -44,8 +44,7 @@
> > * VA_START - the first kernel virtual address.
> > */
> > #define VA_BITS (CONFIG_ARM64_VA_BITS)
> > -#define _PAGE_OFFSET(va) (UL(0xffffffffffffffff) - \
> > - (UL(1) << (va)) + 1)
> > +#define _PAGE_OFFSET(va) (-(UL(1) << (va)))
> > #define PAGE_OFFSET (_PAGE_OFFSET(VA_BITS))
> > #define KIMAGE_VADDR (MODULES_END)
> > #define BPF_JIT_REGION_START (KASAN_SHADOW_END)
> > @@ -63,8 +62,7 @@
> > #else
> > #define VA_BITS_MIN (VA_BITS)
> > #endif
> > -#define _VA_START(va) (UL(0xffffffffffffffff) - \
> > - (UL(1) << ((va) - 1)) + 1)
> > +#define _VA_START(va) (-(UL(1) << ((va) - 1)))
>
> This didn't make any sense to me until I realised that we changed the
> meaning of VA_START when flippnig the VA space. Given that, this cleanup
> looks sound to me.
>
> However...
>
> VA_START used to be the start of the TTBR1 address space, which was what
> the "first kernel virtual address" comment was trying to say. Now it's
> the first non-linear kernel virtual addres, which I think is very
> confusing.
>
> AFAICT, that change breaks at least:
>
> * is_ttbr1_addr() -- now returns false for linear map addresses
> * ptdump_check_wx() -- now skips the linear map
> * ptdump_init() -- initialises start_address inccorrectly.
>
> ... so could we please find a new name for the first non-linear address,
> e.g. PAGE_END, and leave VA_START as the first TTBR1 address?
I think VA_START becomes PAGE_END and then things like is_ttbr1_addr()
just refer to PAGE_OFFSET instead. ptdump_init() looks ok to me, but I could
be missing something.
Anyway, these seem to be comments on the original patches from Steve rather
than my fixes, so please send additional fixes on top. I'll push out an
updated branch for you to work with...
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/8] arm64: memory: Fix virt_addr_valid() using __is_lm_address()
From: Will Deacon @ 2019-08-14 12:02 UTC (permalink / raw)
To: Catalin Marinas
Cc: Mark Rutland, Steve Capper, Andrey Konovalov, Geert Uytterhoeven,
Qian Cai, linux-arm-kernel
In-Reply-To: <20190814104022.GI50688@arrakis.emea.arm.com>
On Wed, Aug 14, 2019 at 11:40:23AM +0100, Catalin Marinas wrote:
> On Wed, Aug 14, 2019 at 10:48:20AM +0100, Will Deacon wrote:
> > On Wed, Aug 14, 2019 at 10:19:42AM +0100, Catalin Marinas wrote:
> > > On Tue, Aug 13, 2019 at 06:01:42PM +0100, Will Deacon wrote:
> > > > -#define _virt_addr_is_linear(kaddr) \
> > > > - (__tag_reset((u64)(kaddr)) >= PAGE_OFFSET)
> > > > +#define virt_addr_valid(addr) ({ \
> > > > + __typeof__(addr) __addr = addr; \
> > > > + __is_lm_address(__addr) && pfn_valid(virt_to_pfn(__addr)); \
> > > > +})
> > >
> > > There is a slight change of semantics here but I don't think it's an
> > > issue currently. __is_lm_address() is true even for a user address, so
> > > at least the first part of virt_addr_valid() now accepts such addresses.
> > > The pfn would be wrong eventually because of the virt-to-phys offsetting
> > > and pfn_valid() false but we rely on this rather than checking it's a
> > > kernel address. Slight concern as this macro is called from drivers.
> > >
> > > Should we keep the PAGE_OFFSET check as well?
> >
> > In virt_addr_valid() or __is_lm_address()?
> >
> > To be honest with you, I'm not even sure what virt_addr_valid() is supposed
> > to do with non-linear kernel addresses: look at powerpc and riscv, who
> > appear to convert the address straight to a pfn. Many callers check against
> > is_vmalloc_addr() first, but not all of them.
>
> Even if they call is_vmalloc_addr(), it would return false for user
> address. Anyway, at a quick look, I couldn't find any virt_addr_valid()
> where it would be an issue.
Sure, but my point was more that it would be crazy to have a macro that
accepted user and linear addresses, but not vmalloc addresses!
> > I think passing in a *user* address would be a huge bug in the caller,
> > just like it would be if you called virt_to_phys() on a user address.
> > If we care about that, then I think __is_lm_address() should be the one
> > doing the check against PAGE_OFFSET.
> >
> > Thoughts? I'd be inclined to leave this patch as it is.
>
> Leave it as it is. The way pfn_valid() is written it wouldn't return
> true for a user address due to the fact that virt_to_phys() cannot
> return the same physical address for a user and linear map one.
>
> For this patch:
>
> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Ta,
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [EXT] Re: [PATCH v2 09/15] dt-bindings: display: Add max-res property for mxsfb
From: Robert Chiras @ 2019-08-14 12:03 UTC (permalink / raw)
To: stefan@agner.ch
Cc: marex@denx.de, devicetree@vger.kernel.org, kernel@pengutronix.de,
airlied@linux.ie, shawnguo@kernel.org, agx@sigxcpu.org,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
robh+dt@kernel.org, dl-linux-imx, daniel@ffwll.ch,
mark.rutland@arm.com, festevam@gmail.com, s.hauer@pengutronix.de,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <33feedd20e0fc154c5b736f882d24569@agner.ch>
Hi Stefann,
On Mi, 2019-08-14 at 13:25 +0200, Stefan Agner wrote:
> On 2019-08-14 13:14, Robert Chiras wrote:
> >
> > Hi Stefan,
> > On Mi, 2019-08-14 at 13:03 +0200, Stefan Agner wrote:
> > >
> > > On 2019-08-14 12:48, Robert Chiras wrote:
> > > >
> > > >
> > > > Add new optional property 'max-res', to limit the maximum
> > > > supported
> > > > resolution by the MXSFB_DRM driver.
> > > I would also mention the reason why we need this.
> > >
> > > I guess this needs a vendor prefix as well (fsl,max-res). I also
> > > would
> > > like to have the ack of the device tree folks here.
> > Rob Herring also aked be about this, and I'll copy here the reply,
> > with
> > explanations:
> >
> > Indeed, this limitation is actually due to bandwidth limitation,
> > but
> > the problem is that this limitation comes on i.MX8M (known as
> > mScale
> > 850D), where the memory bandwidth cannot support: GPU/VPU workload
> > in
> > the same time with both DCSS driving 4k@60 and eLCDIF driving 1080p
> > @60.
> > Since eLCDIF is a secondary display we though to add the posibility
> > to
> > limit it's bandwidth by limiting the resolution.
> > If you say that more details are needed, I can add them in the
> > description.
> Oh sorry I missed that.
>
> Rob Herring also wrote:
> >
> > I suppose what you are after is bandwidth limits? IIRC, there's
> > already
> > some bindings expressing such limits. Also, wouldn't you need to
> > account
> > for bpp and using the 2nd plane (IIRC that there is one).
> I guess the binding he refers to is max-memory-bandwidth, which is
> used
> in multiple driver already. It makes sense to reuse this property
> instead of inventing a new set of property which is also not taking
> bpp
> into account...
Actually I saw this binding, but I thought it is strictly related to
that driver, where it is documented. Now, that you say this one is used
in many drivers (and recalling that you suggested for my 'max-res' to
add a prefix), I get it now.
>
> The pl111 driver implements this property, it should be fairly easy
> to
> adopt that code.
Sure, I will do something similar here, too.
>
> --
> Stefan
>
>
>
> >
> > >
> > >
> > > --
> > > Stefan
> > >
> > > >
> > > >
> > > >
> > > > Signed-off-by: Robert Chiras <robert.chiras@nxp.com>
> > > > ---
> > > > Documentation/devicetree/bindings/display/mxsfb.txt | 6 ++++++
> > > > 1 file changed, 6 insertions(+)
> > > >
> > > > diff --git
> > > > a/Documentation/devicetree/bindings/display/mxsfb.txt
> > > > b/Documentation/devicetree/bindings/display/mxsfb.txt
> > > > index 472e1ea..55e22ed 100644
> > > > --- a/Documentation/devicetree/bindings/display/mxsfb.txt
> > > > +++ b/Documentation/devicetree/bindings/display/mxsfb.txt
> > > > @@ -17,6 +17,12 @@ Required properties:
> > > > Required sub-nodes:
> > > > - port: The connection to an encoder chip.
> > > >
> > > > +Optional properties:
> > > > +- max-res: an array with a maximum of two integers,
> > > > representing
> > > > the
> > > > + maximum supported resolution, in the form of
> > > > + <maxX>, <maxY>; if one of the item is <0>, the
> > > > default
> > > > + driver-defined maximum resolution for that axis
> > > > is
> > > > used
> > > > +
> > > > Example:
> > > >
> > > > lcdif1: display-controller@2220000 {
> > Thanks,
> > Robert
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V5 00/12] 52-bit kernel + user VAs
From: Will Deacon @ 2019-08-14 12:24 UTC (permalink / raw)
To: Bhupesh Sharma
Cc: mark.rutland, Christoph von Recklinghausen, Ard Biesheuvel,
Catalin Marinas, Steve Capper, Linux-Renesas, Geert Uytterhoeven,
maz, Linux ARM
In-Reply-To: <CACi5LpMNC2h-JAmT3gc8wt6rwPBzQaAUZq_P18D3Atjg9CNS5A@mail.gmail.com>
[+Mark]
On Wed, Aug 14, 2019 at 05:29:09PM +0530, Bhupesh Sharma wrote:
> On Wed, Aug 14, 2019 at 1:51 PM Will Deacon <will@kernel.org> wrote:
> >
> > On Wed, Aug 14, 2019 at 01:34:49PM +0530, Bhupesh Sharma wrote:
> > > I still see the following issue on a 48-bit hardware (i.e. _non_
> > > ARMv8.2 hardware) with branch 'for-next/52-bit-kva' with commit
> > > d2d73d2fef421ca0d4 as the HEAD:
> >
> > Have you tried the patches I posted here:
> >
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2019-August/673315.html
> >
> > ?
> >
> > Whilst they're being reviewed, I've dropped the 52-bit branch from
> > linux-next (for-next/core) so that people don't keep running into this.
>
> Thanks will try the above and get back with my results.
>
> However just to make sure that the 52-bit changes are tested properly
> (before landing up linux-next) - as we had issues with the 52-bit User
> space VA + PA changes in the past (which broke userspace), I was
> wondering if we can have a dedicated branch to have the v5 patches
> from Steve + fixes, so that they can be easily tested and issues (if
> any) reported with easy reference.
>
> Or, if such a branch already exists, kindly share the pointer to the
> same as well.
I've pushed the current round of fixes on top of:
https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/log/?h=for-next/52-bit-kva
Mark has spotted a couple of other issues, but they shoudn't hold up your
testing (although I'm going to hold off putting this back into -next until
we've got them resolved).
Mark -- please use the branch above as a basis for any additional fixes.
HEAD should be d0b3c32ed922.
Thanks,
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 0/6] Add support of New Amlogic temperature sensor for G12 SoCs
From: Christian Hewitt @ 2019-08-14 12:24 UTC (permalink / raw)
To: Guillaume La Roque
Cc: devicetree, linux-pm, khilman, daniel.lezcano, linux-kernel,
linux-amlogic, linux-arm-kernel
In-Reply-To: <20190806130506.8753-1-glaroque@baylibre.com>
On 6 Aug 2019, at 5:05 pm, Guillaume La Roque <glaroque@baylibre.com> wrote:
>
> This patchs series add support of New Amlogic temperature sensor and minimal
> thermal zone for SEI510 and ODROID-N2 boards.
>
> First implementation was doing on IIO[1] but after comments i move on thermal framework.
> Formulas and calibration values come from amlogic.
>
> Changes since v2:
> - fix yaml documention
> - remove unneeded status variable for temperature-sensor node
> - rework driver after Martin review
> - add some information in commit message
>
> Changes since v1:
> - fix enum vs const in documentation
> - fix error with thermal-sensor-cells value set to 1 instead of 0
> - add some dependencies needed to add cooling-maps
>
> Dependencies :
> - patch 3,4 & 5: depends on Neil's patch and series :
> - missing dwc2 phy-names[2]
> - patchsets to add DVFS on G12a[3] which have deps on [4] and [5]
>
> [1] https://lore.kernel.org/linux-amlogic/20190604144714.2009-1-glaroque@baylibre.com/
> [2] https://lore.kernel.org/linux-amlogic/20190625123647.26117-1-narmstrong@baylibre.com/
> [3] https://lore.kernel.org/linux-amlogic/20190729132622.7566-1-narmstrong@baylibre.com/
> [4] https://lore.kernel.org/linux-amlogic/20190731084019.8451-5-narmstrong@baylibre.com/
> [5] https://lore.kernel.org/linux-amlogic/20190729132622.7566-3-narmstrong@baylibre.com/
>
> Guillaume La Roque (6):
> dt-bindings: thermal: Add DT bindings documentation for Amlogic
> Thermal
> thermal: amlogic: Add thermal driver to support G12 SoCs
> arm64: dts: amlogic: g12: add temperature sensor
> arm64: dts: meson: sei510: Add minimal thermal zone
> arm64: dts: amlogic: odroid-n2: add minimal thermal zone
> MAINTAINERS: add entry for Amlogic Thermal driver
Tested-by: Christian Hewitt <christianshewitt@gmail.com>
I’ve tested this series with Odroid N2 and Khadas VIM3, X96-Max. Patches to add
support for VIM3/X96-max will be submitted once the driver is merged.
VIM3:~ # dmesg | grep thermal
[ 0.046375] thermal_sys: Registered thermal governor 'step_wise'
VIM3:~ # cat /sys/devices/virtual/thermal/thermal_zone0/temp
51300
VIM3:~ # cat /sys/devices/virtual/thermal/thermal_zone1/temp
52800
Christian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/3] CP115 pinctrl support
From: Thomas Petazzoni @ 2019-08-14 12:34 UTC (permalink / raw)
To: Linus Walleij
Cc: Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Yan Markman, Antoine Tenart, Grzegorz Jaszczyk, Gregory Clement,
Maxime Chevallier, Nadav Haklai, open list:GPIO SUBSYSTEM,
Rob Herring, Miquel Raynal, Stefan Chulski, Marcin Wojtas,
Linux ARM
In-Reply-To: <CACRpkdbEw5eCKb=nTCK4wuMsPEadEQdGx62cGRhk7F78p5X2CA@mail.gmail.com>
Hello Linus,
On Wed, 14 Aug 2019 10:12:36 +0200
Linus Walleij <linus.walleij@linaro.org> wrote:
> On Wed, Aug 7, 2019 at 2:47 PM Linus Walleij <linus.walleij@linaro.org> wrote:
> > On Mon, Aug 5, 2019 at 12:16 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> >
> > > This is the second batch of changes (out of three) to support the brand
> > > new Marvell CN9130 SoCs which are made of one AP807 and one CP115.
> > >
> > > We add a new compatible (and the relevant support in the pinctrl
> > > driver) before the addition in batch 3/3 of CN9130 SoCs DT using it.
> >
> > Waiting for review from the Mvebu maintainers.
> >
> > If it takes too long just nudge me, it looks good to me.
>
> So if the other MVEBU maintainers don't really look much at MVEBU
> patches anymore while Miquel is working a lot on the platform,
> what about listing Miquel as maintainer under the SoC entry, hm?
Miquel sent his series on August 5, i.e 9 days ago. We're in August, in
the middle of the summer vacations for many people. While it is nice to
see subsystem maintainers who want to get code merged in a timely
fashion, I think it is probably wise to give it some more time for
review in this period of the year.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 6/6] dt-bindings: arm: coresight: Add support for coresight-needs-save-restore
From: Suzuki K Poulose @ 2019-08-14 12:35 UTC (permalink / raw)
To: mike.leach, andrew.murray
Cc: Al.Grant, mathieu.poirier, alexander.shishkin, coresight,
Sudeep.Holla, leo.yan, linux-arm-kernel
In-Reply-To: <CAJ9a7Vj+bo2PMnh2fbMJnaHRwJm9jU689P+iZ4q8_Vg7-3SnDg@mail.gmail.com>
Hi Mike,
On 14/08/2019 12:06, Mike Leach wrote:
> Hi,
>
> On Wed, 14 Aug 2019 at 11:01, Andrew Murray <andrew.murray@arm.com> wrote:
>>
>> On Sun, Aug 04, 2019 at 07:13:45AM -0600, Mathieu Poirier wrote:
>>> On Fri, 2 Aug 2019 at 08:37, Andrew Murray <andrew.murray@arm.com> wrote:
>>>>
>>>> On Fri, Aug 02, 2019 at 11:40:54AM +0100, Suzuki K Poulose wrote:
>>>>> Hi Andrew,
>>>>>
>>>>> On 30/07/2019 13:51, Andrew Murray wrote:
>>>>>> Some coresight components, because of choices made during hardware
>>>>>> integration, require their state to be saved and restored across CPU low
>>>>>> power states.
...
>>>>>> --- a/Documentation/devicetree/bindings/arm/coresight.txt
>>>>>> +++ b/Documentation/devicetree/bindings/arm/coresight.txt
>>>>>> @@ -92,6 +92,9 @@ its hardware characteristcs.
>>>>>> * arm,cp14: must be present if the system accesses ETM/PTM management
>>>>>> registers via co-processor 14.
>>>>>> + * arm,coresight-needs-save-restore: boolean. Indicates that software
>>>>>> + should save/restore state across power down.
>>>>>> +
>>>>>
>>>>> Do you think we could be a bit more descriptive here about when people could add
>>>>> it to the DT ? Here we don't mention when someone should use this property and
>>>>> it may be added to platforms where it may be absolutely unnecessary. How about :
>>>>>
>>>>> "Indicates that the hardware implementation may not honor the Powerup request
>>>>> from the software and thus might loose the register context on CPU power
>>>>> down (e.g, during CPUIdle). Software must save/restore the context during a
>>>>> CPU power transition cycle."
>>>>
>>>> How about the following:
>>>>
>>>> "Indicates that the hardware will loose register context on CPU power down (e.g.
>>>> CPUIdle), despite the TRCPDCR.PU bit being set."
>>>>
>>>> I'm keen to avoid making suggestions about what the kernel will do when it sees
>>>> this flag and thus prefer to focus on describing what the hardware does. So I
>>>> dropped your last sentence. However the name of the flag still implies policy
>>>> which I don't like.
>>>>
>>>> I also changed the 'may not honor' wording, I'm not sure if this is really the
>>>> case or if the spec is open to interpretation.
>>>>
>>>> It would great for this wording to also apply to other CS components though I
>>>> haven't investigated if these have a PU bit or something different.
>>>
>>> Exactly - the definition needs to be broad enough to apply to other CS
>>> components. Mike what do you think would be appropriate for CTIs?
>>
> CTIs have no power control at all - i.e. no PU bit to request we stay
> up - and reside in the debug power domain. So they are coupled to the
> CS/CPU/ETM/ power domains and reliant on outside forces to request
> power.
> The expectation is that for a PE bound CTI, if debug is powered then
> it will be fully powered - so an ETM with PU respected, or the
> external debug logic with DBGNOPWRDWN respected should be sufficient
> for CTI to stay alive.
I am trying to understand why we need this property for CTI.
Don't we always need to save-restore the CTI controls on a CPU_DOWN for the
associated CTI ? Since it may not be really tied to an ETM (e.g, if the CTI is
purely used to handle CPU triggers, PMU etc,). If that is the case, do we need
this property for CTI at all ?
>
>> How about we keep this short and simple:
>>
>> * arm,coresight-loses-context-with-cpu : boolean. Indicates that the hardware
nit: s/loses/looses ?
>> will lose register context on CPU power down (e.g. CPUIdle).
>>
>
> So the above name is generic enough to encompass the CTI as well.
>
>> I could have added something like "... despite TRCPDCR.PU being set", or to
>> apply more generically: "... despite available register controls being set to
>> prevent such context loss". However whilst these are more informative - they
>> elude to some of reasons as to why context is lost and as we cannot be
>> exhaustive I'd rather not give a limited example.
>>
>> However if a longer explaination is required:
>>
>> * arm,coresight-loses-context-with-cpu : boolean. Indicates that the hardware
>> will lose register context on CPU power down (e.g. CPUIdle). An example of
>> where this may be needed are systems which contain a coresight component and
>> CPU in the same power domain. When the CPU powers down the coresight
>> component also powers down and loses its context.
This looks fine for me. But I am trying to understand the rationale behind
using this for CTI
Suzuki
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 6/6] dt-bindings: arm: coresight: Add support for coresight-needs-save-restore
From: Andrew Murray @ 2019-08-14 12:49 UTC (permalink / raw)
To: Suzuki K Poulose
Cc: Al.Grant, mathieu.poirier, alexander.shishkin, coresight, leo.yan,
Sudeep.Holla, linux-arm-kernel, mike.leach
In-Reply-To: <718b5bdf-9828-f215-9a81-637308be3b49@arm.com>
On Wed, Aug 14, 2019 at 01:35:27PM +0100, Suzuki K Poulose wrote:
> Hi Mike,
>
> On 14/08/2019 12:06, Mike Leach wrote:
> > Hi,
> >
> > On Wed, 14 Aug 2019 at 11:01, Andrew Murray <andrew.murray@arm.com> wrote:
> > >
> > > On Sun, Aug 04, 2019 at 07:13:45AM -0600, Mathieu Poirier wrote:
> > > > On Fri, 2 Aug 2019 at 08:37, Andrew Murray <andrew.murray@arm.com> wrote:
> > > > >
> > > > > On Fri, Aug 02, 2019 at 11:40:54AM +0100, Suzuki K Poulose wrote:
> > > > > > Hi Andrew,
> > > > > >
> > > > > > On 30/07/2019 13:51, Andrew Murray wrote:
> > > > > > > Some coresight components, because of choices made during hardware
> > > > > > > integration, require their state to be saved and restored across CPU low
> > > > > > > power states.
>
> ...
>
> > > > > > > --- a/Documentation/devicetree/bindings/arm/coresight.txt
> > > > > > > +++ b/Documentation/devicetree/bindings/arm/coresight.txt
> > > > > > > @@ -92,6 +92,9 @@ its hardware characteristcs.
> > > > > > > * arm,cp14: must be present if the system accesses ETM/PTM management
> > > > > > > registers via co-processor 14.
> > > > > > > + * arm,coresight-needs-save-restore: boolean. Indicates that software
> > > > > > > + should save/restore state across power down.
> > > > > > > +
> > > > > >
> > > > > > Do you think we could be a bit more descriptive here about when people could add
> > > > > > it to the DT ? Here we don't mention when someone should use this property and
> > > > > > it may be added to platforms where it may be absolutely unnecessary. How about :
> > > > > >
> > > > > > "Indicates that the hardware implementation may not honor the Powerup request
> > > > > > from the software and thus might loose the register context on CPU power
> > > > > > down (e.g, during CPUIdle). Software must save/restore the context during a
> > > > > > CPU power transition cycle."
> > > > >
> > > > > How about the following:
> > > > >
> > > > > "Indicates that the hardware will loose register context on CPU power down (e.g.
> > > > > CPUIdle), despite the TRCPDCR.PU bit being set."
> > > > >
> > > > > I'm keen to avoid making suggestions about what the kernel will do when it sees
> > > > > this flag and thus prefer to focus on describing what the hardware does. So I
> > > > > dropped your last sentence. However the name of the flag still implies policy
> > > > > which I don't like.
> > > > >
> > > > > I also changed the 'may not honor' wording, I'm not sure if this is really the
> > > > > case or if the spec is open to interpretation.
> > > > >
> > > > > It would great for this wording to also apply to other CS components though I
> > > > > haven't investigated if these have a PU bit or something different.
> > > >
> > > > Exactly - the definition needs to be broad enough to apply to other CS
> > > > components. Mike what do you think would be appropriate for CTIs?
> > >
> > CTIs have no power control at all - i.e. no PU bit to request we stay
> > up - and reside in the debug power domain. So they are coupled to the
> > CS/CPU/ETM/ power domains and reliant on outside forces to request
> > power.
> > The expectation is that for a PE bound CTI, if debug is powered then
> > it will be fully powered - so an ETM with PU respected, or the
> > external debug logic with DBGNOPWRDWN respected should be sufficient
> > for CTI to stay alive.
>
> I am trying to understand why we need this property for CTI.
> Don't we always need to save-restore the CTI controls on a CPU_DOWN for the
> associated CTI ? Since it may not be really tied to an ETM (e.g, if the CTI is
> purely used to handle CPU triggers, PMU etc,). If that is the case, do we need
> this property for CTI at all ?
>
> >
> > > How about we keep this short and simple:
> > >
> > > * arm,coresight-loses-context-with-cpu : boolean. Indicates that the hardware
>
> nit: s/loses/looses ?
Given that lose refers to missing something and loose refers to something not fitting
well, I'd have thought the pural is loses. Though I've now looked at these words for
too long and nothing makes sense any more...
>
> > > will lose register context on CPU power down (e.g. CPUIdle).
> > >
> >
> > So the above name is generic enough to encompass the CTI as well.
> >
> > > I could have added something like "... despite TRCPDCR.PU being set", or to
> > > apply more generically: "... despite available register controls being set to
> > > prevent such context loss". However whilst these are more informative - they
> > > elude to some of reasons as to why context is lost and as we cannot be
> > > exhaustive I'd rather not give a limited example.
> > >
> > > However if a longer explaination is required:
> > >
> > > * arm,coresight-loses-context-with-cpu : boolean. Indicates that the hardware
> > > will lose register context on CPU power down (e.g. CPUIdle). An example of
> > > where this may be needed are systems which contain a coresight component and
> > > CPU in the same power domain. When the CPU powers down the coresight
> > > component also powers down and loses its context.
>
> This looks fine for me. But I am trying to understand the rationale behind
> using this for CTI
Thanks.
Thanks,
Andrew Murray
>
> Suzuki
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 0/2] ARM: psci: cpuidle: defconfig updates
From: Lorenzo Pieralisi @ 2019-08-14 12:52 UTC (permalink / raw)
To: soc
Cc: Mark Rutland, Ulf Hansson, Lorenzo Pieralisi, Catalin Marinas,
Will Deacon, Daniel Lezcano, Sudeep Holla, Shawn Guo, LAKML
Rerouting defconfig updates related to this patch series:
https://lore.kernel.org/linux-arm-kernel/cover.1565348376.git.lorenzo.pieralisi@arm.com/
to arm-soc, as agreed in:
https://lore.kernel.org/linux-arm-kernel/58d9677db3510ed106fe23118090c84f78a44102.1565348376.git.lorenzo.pieralisi@arm.com/
Patches [1-6] are already queued in the ARM64 tree.
Please consider pulling these defconfig changes, thank you very much.
Cc: Will Deacon <will@kernel.org>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Sudeep Holla <sudeep.holla@arm.com>
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Lorenzo Pieralisi (2):
arm64: defconfig: Enable the PSCI CPUidle driver
ARM: imx_v6_v7_defconfig: Enable the PSCI CPUidle driver
arch/arm/configs/imx_v6_v7_defconfig | 1 +
arch/arm64/configs/defconfig | 1 +
2 files changed, 2 insertions(+)
--
2.21.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 2/2] ARM: imx_v6_v7_defconfig: Enable the PSCI CPUidle driver
From: Lorenzo Pieralisi @ 2019-08-14 12:52 UTC (permalink / raw)
To: soc
Cc: Mark Rutland, Ulf Hansson, Lorenzo Pieralisi, Will Deacon,
Catalin Marinas, Daniel Lezcano, Sudeep Holla, Shawn Guo, LAKML
In-Reply-To: <20190814125239.6270-1-lorenzo.pieralisi@arm.com>
Enable the PSCI CPUidle driver to replace the functionality
previously provided by the generic ARM CPUidle driver.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Shawn Guo <shawnguo@kernel.org>
---
arch/arm/configs/imx_v6_v7_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/imx_v6_v7_defconfig b/arch/arm/configs/imx_v6_v7_defconfig
index a53b29251ed4..4174fd1b79e7 100644
--- a/arch/arm/configs/imx_v6_v7_defconfig
+++ b/arch/arm/configs/imx_v6_v7_defconfig
@@ -60,6 +60,7 @@ CONFIG_ARM_IMX6Q_CPUFREQ=y
CONFIG_ARM_IMX_CPUFREQ_DT=y
CONFIG_CPU_IDLE=y
CONFIG_ARM_CPUIDLE=y
+CONFIG_ARM_PSCI_CPUIDLE=y
CONFIG_VFP=y
CONFIG_NEON=y
CONFIG_PM_DEBUG=y
--
2.21.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 1/2] arm64: defconfig: Enable the PSCI CPUidle driver
From: Lorenzo Pieralisi @ 2019-08-14 12:52 UTC (permalink / raw)
To: soc
Cc: Mark Rutland, Ulf Hansson, Lorenzo Pieralisi, Catalin Marinas,
Daniel Lezcano, Sudeep Holla, Shawn Guo, Will Deacon, LAKML
In-Reply-To: <20190814125239.6270-1-lorenzo.pieralisi@arm.com>
Enable the PSCI CPUidle driver to replace the functionality
previously provided by the generic ARM CPUidle driver through
CPU operations.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Sudeep Holla <sudeep.holla@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 0e58ef02880c..c0a7cfe3aebd 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -72,6 +72,7 @@ CONFIG_RANDOMIZE_BASE=y
CONFIG_HIBERNATION=y
CONFIG_WQ_POWER_EFFICIENT_DEFAULT=y
CONFIG_ARM_CPUIDLE=y
+CONFIG_ARM_PSCI_CPUIDLE=y
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_STAT=y
CONFIG_CPU_FREQ_GOV_POWERSAVE=m
--
2.21.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: kexec on rk3399
From: Vicente Bergas @ 2019-08-14 12:53 UTC (permalink / raw)
To: Felipe Balbi, Robin Murphy
Cc: Matthias Brugger, Heiko Stuebner, Marc Zyngier, Catalin Marinas,
linux-usb, Will Deacon, linux-kernel, linux-rockchip,
Greg Kroah-Hartman, linux-arm-kernel
In-Reply-To: <ebcb52be-2063-4e2c-9a09-fdcacb94f855@gmail.com>
On Monday, July 22, 2019 4:31:27 PM CEST, Vicente Bergas wrote:
> Hi, i have been running linux on rk3399 booted with kexec fine until 5.2
> From 5.2 onwards, there are memory corruption issues as reported here:
> http://lkml.iu.edu/hypermail/linux/kernel/1906.2/07211.html
> kexec has been identified as the principal reason for the issues.
>
> It turns out that kexec has never worked reliably on this platform,
> i was just lucky until recently.
>
> Please, can you provide some directions on how to debug the issue?
Thank you all for your suggestions on where the issue could be.
It seems that it was the USB driver.
Now using v5.2.8 booted with kexec from v5.2.8 with a workaround and
so far so good. It is being tested on the Sapphire board.
The workaround is:
--- a/drivers/usb/dwc3/dwc3-of-simple.c
+++ b/drivers/usb/dwc3/dwc3-of-simple.c
@@ -133,6 +133,13 @@
return 0;
}
+static void dwc3_of_simple_shutdown(struct platform_device *pdev)
+{
+ struct dwc3_of_simple *simple = platform_get_drvdata(pdev);
+
+ reset_control_assert(simple->resets);
+}
+
static int __maybe_unused dwc3_of_simple_runtime_suspend(struct device
*dev)
{
struct dwc3_of_simple *simple = dev_get_drvdata(dev);
@@ -190,6 +197,7 @@
static struct platform_driver dwc3_of_simple_driver = {
.probe = dwc3_of_simple_probe,
.remove = dwc3_of_simple_remove,
+ .shutdown = dwc3_of_simple_shutdown,
.driver = {
.name = "dwc3-of-simple",
.of_match_table = of_dwc3_simple_match,
If this patch is OK after review i can resubmit it as a pull request.
Should a similar change be applied to drivers/usb/dwc3/core.c ?
Regards,
Vicenç.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] i2c: stm32: Use the correct style for SPDX License Identifier
From: Wolfram Sang @ 2019-08-14 12:58 UTC (permalink / raw)
To: Nishad Kamdar
Cc: Alexandre Torgue, Greg Kroah-Hartman, linux-kernel,
Pierre-Yves MORDRET, linux-i2c, Maxime Coquelin,
Uwe Kleine-König, Joe Perches, linux-stm32, linux-arm-kernel
In-Reply-To: <20190803141331.GA3588@nishad>
[-- Attachment #1.1: Type: text/plain, Size: 665 bytes --]
On Sat, Aug 03, 2019 at 07:43:35PM +0530, Nishad Kamdar wrote:
> This patch corrects the SPDX License Identifier style
> in header file related to STM32 Driver for I2C hardware
> bus support.
> For C header files Documentation/process/license-rules.rst
> mandates C-like comments (opposed to C source files where
> C++ style should be used)
>
> Changes made by using a script provided by Joe Perches here:
> https://lkml.org/lkml/2019/2/7/46
>
> Suggested-by: Joe Perches <joe@perches.com>
> Signed-off-by: Nishad Kamdar <nishadkamdar@gmail.com>
Pierre-Yves is on holiday and this patch is obviously correct, so
applied to for-current, thanks!
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 3/9] soc: samsung: Add Exynos Adaptive Supply Voltage driver
From: Krzysztof Kozlowski @ 2019-08-14 12:58 UTC (permalink / raw)
To: Sylwester Nawrocki
Cc: devicetree, linux-samsung-soc@vger.kernel.org, linux-pm,
pankaj.dubey, Bartłomiej Żołnierkiewicz,
linux-kernel@vger.kernel.org, robh+dt, kgene, vireshk,
linux-arm-kernel, Marek Szyprowski
In-Reply-To: <20190813150827.31972-4-s.nawrocki@samsung.com>
On Tue, 13 Aug 2019 at 17:08, Sylwester Nawrocki <s.nawrocki@samsung.com> wrote:
>
> The Adaptive Supply Voltage (ASV) driver adjusts CPU cluster operating
> points depending on exact revision of an SoC retrieved from the CHIPID
> block or the OTP memory. This allows for some power saving as for some
> CPU clock frequencies we can lower CPU cluster supply voltage comparing
> to safe values common to the all chip revisions.
>
> This patch adds support for Exynos5422/5800 SoC, it is partially based
> on code from https://github.com/hardkernel/linux repository,
> branch odroidxu4-4.14.y, files: arch/arm/mach-exynos/exynos5422-asv.[ch].
>
> Tested on Odroid XU3, XU4, XU3 Lite.
>
> Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
> ---
> Changes since v2:
> - Use devm_kzalloc() in probe() to avoid memory leak,
> - removed leading spaces in exynos-chipid.h,
> - removed unneeded <linux/init.h> header inclusion,
> - dropped parentheses from exynos542_asv_parse_sg(),
> - updated Kconfig entry,
> - added const attribute to struct exynos_asv_susbsys::cpu_dt_compat.
>
> Changes since v1 (RFC):
> - removed code for parsing the ASV OPP tables from DT, the ASV OPP tables
> moved to the driver;
> - converted to use the regmap API;
> - converted to normal platform driver.
> ---
> drivers/soc/samsung/Kconfig | 10 +
> drivers/soc/samsung/Makefile | 3 +
> drivers/soc/samsung/exynos-asv.c | 184 ++++++++++
> drivers/soc/samsung/exynos-asv.h | 82 +++++
> drivers/soc/samsung/exynos5422-asv.c | 498 +++++++++++++++++++++++++++
> drivers/soc/samsung/exynos5422-asv.h | 25 ++
> 6 files changed, 802 insertions(+)
> create mode 100644 drivers/soc/samsung/exynos-asv.c
> create mode 100644 drivers/soc/samsung/exynos-asv.h
> create mode 100644 drivers/soc/samsung/exynos5422-asv.c
> create mode 100644 drivers/soc/samsung/exynos5422-asv.h
>
> diff --git a/drivers/soc/samsung/Kconfig b/drivers/soc/samsung/Kconfig
> index 2905f5262197..73ccf59676a1 100644
> --- a/drivers/soc/samsung/Kconfig
> +++ b/drivers/soc/samsung/Kconfig
> @@ -7,6 +7,16 @@ menuconfig SOC_SAMSUNG
>
> if SOC_SAMSUNG
>
> +config EXYNOS_ASV
> + bool "Exynos Adaptive Supply Voltage support" if COMPILE_TEST
> + depends on (ARCH_EXYNOS && EXYNOS_CHIPID) || COMPILE_TEST
> + select EXYNOS_ASV_ARM if ARM && ARCH_EXYNOS
> +
> +# There is no need to enable these drivers for ARMv8
> +config EXYNOS_ASV_ARM
> + bool "Exynos ASV ARMv7-specific driver extensions" if COMPILE_TEST
> + depends on EXYNOS_ASV
> +
> config EXYNOS_CHIPID
> bool "Exynos Chipid controller driver" if COMPILE_TEST
> depends on ARCH_EXYNOS || COMPILE_TEST
> diff --git a/drivers/soc/samsung/Makefile b/drivers/soc/samsung/Makefile
> index 3b6a8797416c..edd1d6ea064d 100644
> --- a/drivers/soc/samsung/Makefile
> +++ b/drivers/soc/samsung/Makefile
> @@ -1,5 +1,8 @@
> # SPDX-License-Identifier: GPL-2.0
>
> +obj-$(CONFIG_EXYNOS_ASV) += exynos-asv.o
> +obj-$(CONFIG_EXYNOS_ASV_ARM) += exynos5422-asv.o
> +
> obj-$(CONFIG_EXYNOS_CHIPID) += exynos-chipid.o
> obj-$(CONFIG_EXYNOS_PMU) += exynos-pmu.o
>
> diff --git a/drivers/soc/samsung/exynos-asv.c b/drivers/soc/samsung/exynos-asv.c
> new file mode 100644
> index 000000000000..481deb600afc
> --- /dev/null
> +++ b/drivers/soc/samsung/exynos-asv.c
> @@ -0,0 +1,184 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2019 Samsung Electronics Co., Ltd.
> + * http://www.samsung.com/
> + * Author: Sylwester Nawrocki <s.nawrocki@samsung.com>
> + *
> + * Samsung Exynos SoC Adaptive Supply Voltage support
> + */
> +
> +#include <linux/cpu.h>
> +#include <linux/delay.h>
> +#include <linux/device.h>
> +#include <linux/errno.h>
> +#include <linux/init.h>
> +#include <linux/mfd/syscon.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>
> +#include <linux/platform_device.h>
> +#include <linux/pm_opp.h>
> +#include <linux/regmap.h>
> +#include <linux/soc/samsung/exynos-chipid.h>
> +
> +#include "exynos-asv.h"
> +#include "exynos5422-asv.h"
> +
> +#define MHZ 1000000U
> +
> +static int exynos_asv_update_cpu_opps(struct exynos_asv *asv,
> + struct device *cpu)
> +{
> + struct exynos_asv_subsys *subsys = NULL;
> + struct dev_pm_opp *opp;
> + unsigned int opp_freq;
> + int i;
> +
> + for (i = 0; i < ARRAY_SIZE(asv->subsys); i++) {
> + if (of_device_is_compatible(cpu->of_node,
> + asv->subsys[i].cpu_dt_compat)) {
> + subsys = &asv->subsys[i];
> + break;
> + }
> + }
> + if (!subsys)
> + return -EINVAL;
> +
> + for (i = 0; i < subsys->table.num_rows; i++) {
> + unsigned int new_voltage;
> + unsigned int voltage;
> + int timeout = 1000;
> + int err;
> +
> + opp_freq = exynos_asv_opp_get_frequency(subsys, i);
> +
> + opp = dev_pm_opp_find_freq_exact(cpu, opp_freq * MHZ, true);
> + if (IS_ERR(opp)) {
> + dev_info(asv->dev, "cpu%d opp%d, freq: %u missing\n",
> + cpu->id, i, opp_freq);
> +
> + continue;
> + }
> +
> + voltage = dev_pm_opp_get_voltage(opp);
> + new_voltage = asv->opp_get_voltage(subsys, i, voltage);
> + dev_pm_opp_put(opp);
> +
> + opp_freq *= MHZ;
> + dev_pm_opp_remove(cpu, opp_freq);
> +
> + while (--timeout) {
> + opp = dev_pm_opp_find_freq_exact(cpu, opp_freq, true);
> + if (IS_ERR(opp))
> + break;
> + dev_pm_opp_put(opp);
> + msleep(1);
> + }
> +
> + err = dev_pm_opp_add(cpu, opp_freq, new_voltage);
> + if (err < 0)
> + dev_err(asv->dev,
> + "Failed to add OPP %u Hz/%u uV for cpu%d\n",
> + opp_freq, new_voltage, cpu->id);
> + }
> +
> + return 0;
> +}
> +
> +static int exynos_asv_update_opps(struct exynos_asv *asv)
> +{
> + struct opp_table *last_opp_table = NULL;
> + struct device *cpu;
> + int ret, cpuid;
> +
> + for_each_possible_cpu(cpuid) {
> + struct opp_table *opp_table;
> +
> + cpu = get_cpu_device(cpuid);
> + if (!cpu)
> + continue;
> +
> + opp_table = dev_pm_opp_get_opp_table(cpu);
> + if (IS_ERR(opp_table))
> + continue;
> +
> + if (!last_opp_table || opp_table != last_opp_table) {
> + last_opp_table = opp_table;
> +
> + ret = exynos_asv_update_cpu_opps(asv, cpu);
> + if (ret < 0)
> + dev_err(asv->dev, "Couldn't udate OPPs for cpu%d\n",
> + cpuid);
> + }
> +
> + dev_pm_opp_put_opp_table(opp_table);
> + }
> +
> + return 0;
> +}
> +
> +static int exynos_asv_probe(struct platform_device *pdev)
> +{
> + int (*probe_func)(struct exynos_asv *asv);
> + struct exynos_asv *asv;
> + struct device *cpu_dev;
> + u32 product_id = 0;
> + int ret, i;
> +
> + cpu_dev = get_cpu_device(0);
> + ret = dev_pm_opp_get_opp_count(cpu_dev);
> + if (ret < 0)
> + return -EPROBE_DEFER;
> +
> + asv = devm_kzalloc(&pdev->dev, sizeof(*asv), GFP_KERNEL);
> + if (!asv)
> + return -ENOMEM;
> +
> + asv->chipid_regmap = syscon_node_to_regmap(pdev->dev.of_node);
> + if (IS_ERR(asv->chipid_regmap)) {
> + dev_err(&pdev->dev, "Could not find syscon regmap\n");
> + return PTR_ERR(asv->chipid_regmap);
> + }
> +
> + regmap_read(asv->chipid_regmap, EXYNOS_CHIPID_REG_PRO_ID, &product_id);
> +
> + switch (product_id & EXYNOS_MASK) {
> + case 0xE5422000:
> + probe_func = exynos5422_asv_init;
> + break;
> + default:
> + dev_err(&pdev->dev, "Unsupported product ID: %#x", product_id);
> + return -ENODEV;
> + }
> +
> + ret = of_property_read_u32(pdev->dev.of_node, "samsung,asv-bin",
> + &asv->of_bin);
> + if (ret < 0)
> + asv->of_bin = -EINVAL;
> +
> + asv->dev = &pdev->dev;
> + dev_set_drvdata(&pdev->dev, asv);
> +
> + for (i = 0; i < ARRAY_SIZE(asv->subsys); i++)
> + asv->subsys[i].asv = asv;
> +
> + ret = probe_func(asv);
> + if (ret < 0)
> + return ret;
> +
> + return exynos_asv_update_opps(asv);
> +}
> +
> +static const struct of_device_id exynos_asv_of_device_ids[] = {
> + { .compatible = "samsung,exynos4210-chipid" },
> + {}
> +};
> +
> +static struct platform_driver exynos_asv_driver = {
> + .driver = {
> + .name = "exynos-asv",
> + .of_match_table = exynos_asv_of_device_ids,
> + },
> + .probe = exynos_asv_probe,
> +};
> +module_platform_driver(exynos_asv_driver);
> diff --git a/drivers/soc/samsung/exynos-asv.h b/drivers/soc/samsung/exynos-asv.h
> new file mode 100644
> index 000000000000..14b4fedf2ddd
> --- /dev/null
> +++ b/drivers/soc/samsung/exynos-asv.h
> @@ -0,0 +1,82 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (c) 2019 Samsung Electronics Co., Ltd.
> + * http://www.samsung.com/
> + * Author: Sylwester Nawrocki <s.nawrocki@samsung.com>
> + *
> + * Samsung Exynos SoC Adaptive Supply Voltage support
> + */
> +#ifndef __LINUX_SOC_EXYNOS_ASV_H
> +#define __LINUX_SOC_EXYNOS_ASV_H
Yikes, that was my mistake. The file is in drivers/soc, not include,
so this could stay as previous one. Or make more path dependend -
__DRIVERS_SOC... Now it is inconsistent with
drivers/soc/samsung/exynos5422-asv.h.
I can fixup these two files while applying but if there is going to be
a resend, then change both to __DRIVERS_SOC_..._H.
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 7/9] soc: samsung: Update the CHIP ID DT binding documentation
From: Krzysztof Kozlowski @ 2019-08-14 13:00 UTC (permalink / raw)
To: Sylwester Nawrocki
Cc: devicetree, linux-samsung-soc@vger.kernel.org, linux-pm,
pankaj.dubey, Bartłomiej Żołnierkiewicz,
linux-kernel@vger.kernel.org, robh+dt, kgene, vireshk,
linux-arm-kernel, Marek Szyprowski
In-Reply-To: <20190813150827.31972-8-s.nawrocki@samsung.com>
On Tue, 13 Aug 2019 at 17:09, Sylwester Nawrocki <s.nawrocki@samsung.com> wrote:
>
> This patch adds documentation of a new optional "samsung,asv-bin"
> property in the chipid device node and documents requirement of
> "syscon" compatible string. These additions are needed to support
> Exynos ASV (Adaptive Supply Voltage) feature.
>
> Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
> ---
> Changes since v2:
> - none
>
> Changes since v1 (RFC):
> - new patch
> ---
> .../devicetree/bindings/arm/samsung/exynos-chipid.txt | 10 ++++++++--
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-chipid.txt b/Documentation/devicetree/bindings/arm/samsung/exynos-chipid.txt
> index 85c5dfd4a720..be3657e6c00c 100644
> --- a/Documentation/devicetree/bindings/arm/samsung/exynos-chipid.txt
> +++ b/Documentation/devicetree/bindings/arm/samsung/exynos-chipid.txt
> @@ -1,12 +1,18 @@
> -SAMSUNG Exynos SoCs Chipid driver.
> +SAMSUNG Exynos SoC series CHIPID subsystem
>
> Required properties:
> -- compatible : Should at least contain "samsung,exynos4210-chipid".
> +- compatible : Should at least contain "samsung,exynos4210-chipid", "syscon".
>
> - reg: offset and length of the register set
>
> +Optional properties:
> + - samsung,asv-bin : Adaptive Supply Voltage bin selection. This can be used
> + to determine the ASV bin of an SoC if respective information is missing
> + in the CHIPID registers or in the OTP memory. Possible values: 0...3.
> +
> Example:
> chipid@10000000 {
> compatible = "samsung,exynos4210-chipid";
Please update the example with new required compatible.
Best regards,
Krzysztof
> reg = <0x10000000 0x100>;
> + samsung,asv-bin = <2>;
> };
> --
> 2.17.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/9] arm64: Stolen time support
From: Alexander Graf @ 2019-08-14 13:02 UTC (permalink / raw)
To: Steven Price, Marc Zyngier
Cc: kvm, linux-doc, Catalin Marinas, linux-kernel, Russell King,
Paolo Bonzini, Will Deacon, kvmarm, linux-arm-kernel
In-Reply-To: <6789f477-8ab5-cc54-1ad2-8627917b07c9@arm.com>
On 05.08.19 15:06, Steven Price wrote:
> On 03/08/2019 19:05, Marc Zyngier wrote:
>> On Fri, 2 Aug 2019 15:50:08 +0100
>> Steven Price <steven.price@arm.com> wrote:
>>
>> Hi Steven,
>>
>>> This series add support for paravirtualized time for arm64 guests and
>>> KVM hosts following the specification in Arm's document DEN 0057A:
>>>
>>> https://developer.arm.com/docs/den0057/a
>>>
>>> It implements support for stolen time, allowing the guest to
>>> identify time when it is forcibly not executing.
>>>
>>> It doesn't implement support for Live Physical Time (LPT) as there are
>>> some concerns about the overheads and approach in the above
>>> specification, and I expect an updated version of the specification to
>>> be released soon with just the stolen time parts.
>>
>> Thanks for posting this.
>>
>> My current concern with this series is around the fact that we allocate
>> memory from the kernel on behalf of the guest. It is the first example
>> of such thing in the ARM port, and I can't really say I'm fond of it.
>>
>> x86 seems to get away with it by having the memory allocated from
>> userspace, why I tend to like more. Yes, put_user is more
>> expensive than a straight store, but this isn't done too often either.
>>
>> What is the rational for your current approach?
>
> As I see it there are 3 approaches that can be taken here:
>
> 1. Hypervisor allocates memory and adds it to the virtual machine. This
> means that everything to do with the 'device' is encapsulated behind the
> KVM_CREATE_DEVICE / KVM_[GS]ET_DEVICE_ATTR ioctls. But since we want the
> stolen time structure to be fast it cannot be a trapping region and has
> to be backed by real memory - in this case allocated by the host kernel.
>
> 2. Host user space allocates memory. Similar to above, but this time
> user space needs to manage the memory region as well as the usual
> KVM_CREATE_DEVICE dance. I've no objection to this, but it means
> kvmtool/QEMU needs to be much more aware of what is going on (e.g. how
> to size the memory region).
You ideally want to get the host overhead for a VM to as little as you
can. I'm not terribly fond of the idea of reserving a full page just
because we're too afraid of having the guest donate memory.
>
> 3. Guest kernel "donates" the memory to the hypervisor for the
> structure. As far as I'm aware this is what x86 does. The problems I see
> this approach are:
>
> a) kexec becomes much more tricky - there needs to be a disabling
> mechanism for the guest to stop the hypervisor scribbling on memory
> before starting the new kernel.
I wouldn't call "quiesce a device" much more tricky. We have to do that
for other devices as well today.
> b) If there is more than one entity that is interested in the
> information (e.g. firmware and kernel) then this requires some form of
> arbitration in the guest because the hypervisor doesn't want to have to
> track an arbitrary number of regions to update.
Why would FW care?
> c) Performance can suffer if the host kernel doesn't have a suitably
> aligned/sized area to use. As you say - put_user() is more expensive.
Just define the interface to always require natural alignment when
donating a memory location?
> The structure is updated on every return to the VM.
If you really do suffer from put_user(), there are alternatives. You
could just map the page on the registration hcall and then leave it
pinned until the vcpu gets destroyed again.
> Of course x86 does prove the third approach can work, but I'm not sure
> which is actually better. Avoid the kexec cancellation requirements was
> the main driver of the current approach. Although many of the
I really don't understand the problem with kexec cancellation. Worst
case, let guest FW set it up for you and propagate only the address down
via ACPI/DT. That way you can mark the respective memory as reserved too.
But even with a Linux only mechanism, just take a look at
arch/x86/kernel/kvmclock.c. All they do to remove the map is to hook
into machine_crash_shutdown() and machine_shutdown().
Alex
> conversations about this were also tied up with Live Physical Time which
> adds its own complications.
>
> Steve
> _______________________________________________
> kvmarm mailing list
> kvmarm@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 0/9] Exynos Adaptive Supply Voltage support
From: Krzysztof Kozlowski @ 2019-08-14 13:03 UTC (permalink / raw)
To: Sylwester Nawrocki
Cc: devicetree, linux-samsung-soc@vger.kernel.org, linux-pm,
pankaj.dubey, Bartłomiej Żołnierkiewicz,
linux-kernel@vger.kernel.org, robh+dt, kgene, vireshk,
linux-arm-kernel, Marek Szyprowski
In-Reply-To: <20190813150827.31972-1-s.nawrocki@samsung.com>
On Tue, 13 Aug 2019 at 17:08, Sylwester Nawrocki <s.nawrocki@samsung.com> wrote:
>
> This is third iteration of my patch series adding ASV (Adaptive Supply
> Voltage) support for Exynos SoCs. The previous one can be found at:
> https://lore.kernel.org/lkml/20190718143044.25066-1-s.nawrocki@samsung.com
>
> There is no major changes in this series comparing to v2, only minor
> corrections addressing review comments.
>
> I was not sure it was a good idea to try to extend the OPP binding
> so as to include the ASV data tables in DT, so the tables are left
> in the driver.
>
> This patch set includes Exynos CHIPID driver posted by Pankaj Dubey and
> futher improved by Bartłomiej Żołnierkiewicz [1].
>
> Tested on Odroid XU3, XU3 Lite, XU4.
>
> One of the things on TODO list is support for the Adaptive Body Bias.
> This will require modifications on the cpufreq driver side in order to
> support multiple voltage regulators and changes in the OPP framework
> to support adding OPPs with multiple voltages.
>
> [1] https://lkml.org/lkml/2018/11/15/908
>
> Pankaj Dubey (3):
> soc: samsung: Add exynos chipid driver support
> ARM: EXYNOS: enable exynos_chipid for ARCH_EXYNOS
> ARM64: EXYNOS: enable exynos_chipid for ARCH_EXYNOS
>
> Sylwester Nawrocki (6):
> soc: samsung: Convert exynos-chipid driver to use the regmap API
> soc: samsung: Add Exynos Adaptive Supply Voltage driver
> ARM: EXYNOS: Enable exynos-asv driver for ARCH_EXYNOS
> soc: samsung: Update the CHIP ID DT binding documentation
> ARM: dts: Add "syscon" compatible string to chipid node
> ARM: dts: Add samsung,asv-bin property for odroidxu3-lite
All look good to me but I need acks for bindings before applying.
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: kexec on rk3399
From: Felipe Balbi @ 2019-08-14 13:06 UTC (permalink / raw)
To: Vicente Bergas, Robin Murphy
Cc: Matthias Brugger, Heiko Stuebner, Marc Zyngier, Catalin Marinas,
linux-usb, Will Deacon, linux-kernel, linux-rockchip,
Greg Kroah-Hartman, linux-arm-kernel
In-Reply-To: <c6993a1e-6fc2-44ab-b59e-152142e2ff4d@gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 2085 bytes --]
Hi,
Vicente Bergas <vicencb@gmail.com> writes:
> On Monday, July 22, 2019 4:31:27 PM CEST, Vicente Bergas wrote:
>> Hi, i have been running linux on rk3399 booted with kexec fine until 5.2
>> From 5.2 onwards, there are memory corruption issues as reported here:
>> http://lkml.iu.edu/hypermail/linux/kernel/1906.2/07211.html
>> kexec has been identified as the principal reason for the issues.
>>
>> It turns out that kexec has never worked reliably on this platform,
>> i was just lucky until recently.
>>
>> Please, can you provide some directions on how to debug the issue?
>
> Thank you all for your suggestions on where the issue could be.
>
> It seems that it was the USB driver.
> Now using v5.2.8 booted with kexec from v5.2.8 with a workaround and
> so far so good. It is being tested on the Sapphire board.
>
> The workaround is:
> --- a/drivers/usb/dwc3/dwc3-of-simple.c
> +++ b/drivers/usb/dwc3/dwc3-of-simple.c
> @@ -133,6 +133,13 @@
> return 0;
> }
>
> +static void dwc3_of_simple_shutdown(struct platform_device *pdev)
> +{
> + struct dwc3_of_simple *simple = platform_get_drvdata(pdev);
> +
> + reset_control_assert(simple->resets);
> +}
> +
> static int __maybe_unused dwc3_of_simple_runtime_suspend(struct device
> *dev)
> {
> struct dwc3_of_simple *simple = dev_get_drvdata(dev);
> @@ -190,6 +197,7 @@
> static struct platform_driver dwc3_of_simple_driver = {
> .probe = dwc3_of_simple_probe,
> .remove = dwc3_of_simple_remove,
> + .shutdown = dwc3_of_simple_shutdown,
> .driver = {
> .name = "dwc3-of-simple",
> .of_match_table = of_dwc3_simple_match,
>
> If this patch is OK after review i can resubmit it as a pull request.
not a pull request, just send a patch using git send-email
> Should a similar change be applied to drivers/usb/dwc3/core.c ?
Is it necessary? We haven't had any bug reports regarding that. Also, if
we have reset control support in the core driver, why do we need it in
of_simple? Seems like of_simple could just rely on what core does.
--
balbi
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [linux-sunxi] [PATCH] ARM64: dts: allwinner: Add devicetree for pine H64 modelA evaluation board
From: Corentin Labbe @ 2019-08-14 13:07 UTC (permalink / raw)
To: Clément Péron
Cc: Mark Rutland, devicetree, linux-sunxi, linux-kernel, mripard,
Chen-Yu Tsai, Rob Herring, linux-arm-kernel
In-Reply-To: <CAJiuCccEQFvKemTodJbuEDzDy9j6-M4SYskxPFJ5DpsbQDnvkA@mail.gmail.com>
On Thu, Aug 08, 2019 at 04:50:35PM +0200, Clément Péron wrote:
> Hi,
>
> On Thu, 8 Aug 2019 at 10:42, Corentin Labbe <clabbe.montjoie@gmail.com> wrote:
> >
> > This patch adds the evaluation variant of the model A of the PineH64.
> > The model A has the same size of the pine64 and has a PCIE slot.
> >
> > The only devicetree difference with current pineH64, is the PHY
> > regulator.
>
> You also need to add the board in
> "Documentation/devicetree/bindings/arm/sunxi.yaml"
>
> Regards,
> Clément
>
Done, thanks
Regards
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: kexec on rk3399
From: Robin Murphy @ 2019-08-14 13:12 UTC (permalink / raw)
To: Vicente Bergas, Felipe Balbi
Cc: Matthias Brugger, Heiko Stuebner, Marc Zyngier, Catalin Marinas,
linux-usb, Will Deacon, linux-kernel, linux-rockchip,
Greg Kroah-Hartman, linux-arm-kernel
In-Reply-To: <c6993a1e-6fc2-44ab-b59e-152142e2ff4d@gmail.com>
On 14/08/2019 13:53, Vicente Bergas wrote:
> On Monday, July 22, 2019 4:31:27 PM CEST, Vicente Bergas wrote:
>> Hi, i have been running linux on rk3399 booted with kexec fine until 5.2
>> From 5.2 onwards, there are memory corruption issues as reported here:
>> http://lkml.iu.edu/hypermail/linux/kernel/1906.2/07211.html
>> kexec has been identified as the principal reason for the issues.
>>
>> It turns out that kexec has never worked reliably on this platform,
>> i was just lucky until recently.
>>
>> Please, can you provide some directions on how to debug the issue?
>
> Thank you all for your suggestions on where the issue could be.
>
> It seems that it was the USB driver.
> Now using v5.2.8 booted with kexec from v5.2.8 with a workaround and
> so far so good. It is being tested on the Sapphire board.
>
> The workaround is:
> --- a/drivers/usb/dwc3/dwc3-of-simple.c
> +++ b/drivers/usb/dwc3/dwc3-of-simple.c
> @@ -133,6 +133,13 @@
> return 0;
> }
>
> +static void dwc3_of_simple_shutdown(struct platform_device *pdev)
> +{
> + struct dwc3_of_simple *simple = platform_get_drvdata(pdev);
> +
> + reset_control_assert(simple->resets);
> +}
> +
> static int __maybe_unused dwc3_of_simple_runtime_suspend(struct device
> *dev)
> {
> struct dwc3_of_simple *simple = dev_get_drvdata(dev);
> @@ -190,6 +197,7 @@
> static struct platform_driver dwc3_of_simple_driver = {
> .probe = dwc3_of_simple_probe,
> .remove = dwc3_of_simple_remove,
> + .shutdown = dwc3_of_simple_shutdown,
> .driver = {
> .name = "dwc3-of-simple",
> .of_match_table = of_dwc3_simple_match,
>
> If this patch is OK after review i can resubmit it as a pull request.
> Should a similar change be applied to drivers/usb/dwc3/core.c ?
This particular change looks like it's implicitly specific to RK3399,
which wouldn't be ideal. Presumably if the core dwc3 driver implemented
shutdown correctly (echoing parts of dwc3_remove(), I guess) then the
glue layers shouldn't need anything special anyway.
Robin.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: kexec on rk3399
From: Vicente Bergas @ 2019-08-14 13:15 UTC (permalink / raw)
To: Felipe Balbi
Cc: Matthias Brugger, Heiko Stuebner, Marc Zyngier, Catalin Marinas,
linux-usb, Will Deacon, linux-kernel, linux-rockchip,
Greg Kroah-Hartman, Robin Murphy, linux-arm-kernel
In-Reply-To: <87v9uzaocj.fsf@gmail.com>
On Wednesday, August 14, 2019 3:06:04 PM CEST, Felipe Balbi wrote:
> Hi,
>
> Vicente Bergas <vicencb@gmail.com> writes:
>> On Monday, July 22, 2019 4:31:27 PM CEST, Vicente Bergas wrote:
>>> Hi, i have been running linux on rk3399 booted with kexec fine until 5.2
>>> From 5.2 onwards, there are memory corruption issues as reported here:
>>> http://lkml.iu.edu/hypermail/linux/kernel/1906.2/07211.html
>>> kexec has been identified as the principal reason for the issues.
>>>
>>> It turns out that kexec has never worked reliably on this platform, ...
>>
>> Thank you all for your suggestions on where the issue could be.
>>
>> It seems that it was the USB driver.
>> Now using v5.2.8 booted with kexec from v5.2.8 with a workaround and
>> so far so good. It is being tested on the Sapphire board.
>>
>> The workaround is:
>> --- a/drivers/usb/dwc3/dwc3-of-simple.c
>> +++ b/drivers/usb/dwc3/dwc3-of-simple.c
>> @@ -133,6 +133,13 @@
>> return 0;
>> }
>>
>> +static void dwc3_of_simple_shutdown(struct platform_device *pdev)
>> +{
>> + struct dwc3_of_simple *simple = platform_get_drvdata(pdev);
>> +
>> + reset_control_assert(simple->resets);
>> +}
>> +
>> static int __maybe_unused dwc3_of_simple_runtime_suspend(struct device
>> *dev)
>> {
>> struct dwc3_of_simple *simple = dev_get_drvdata(dev);
>> @@ -190,6 +197,7 @@
>> static struct platform_driver dwc3_of_simple_driver = {
>> .probe = dwc3_of_simple_probe,
>> .remove = dwc3_of_simple_remove,
>> + .shutdown = dwc3_of_simple_shutdown,
>> .driver = {
>> .name = "dwc3-of-simple",
>> .of_match_table = of_dwc3_simple_match,
>>
>> If this patch is OK after review i can resubmit it as a pull request.
>
> not a pull request, just send a patch using git send-email
>
>> Should a similar change be applied to drivers/usb/dwc3/core.c ?
>
> Is it necessary? We haven't had any bug reports regarding that. Also, if
> we have reset control support in the core driver, why do we need it in
> of_simple? Seems like of_simple could just rely on what core does.
the workaround has been tested patching only core.c with
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -1561,6 +1561,13 @@
return 0;
}
+static void dwc3_shutdown(struct platform_device *pdev)
+{
+ struct dwc3 *dwc = platform_get_drvdata(pdev);
+
+ reset_control_assert(dwc->reset);
+}
+
#ifdef CONFIG_PM
static int dwc3_core_init_for_resume(struct dwc3 *dwc)
{
@@ -1866,6 +1873,7 @@
static struct platform_driver dwc3_driver = {
.probe = dwc3_probe,
.remove = dwc3_remove,
+ .shutdown = dwc3_shutdown,
.driver = {
.name = "dwc3",
.of_match_table = of_match_ptr(of_dwc3_match),
and leaving dwc3-of-simple.c as is, the issue persisted.
Regards,
Vicenç.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] ARM64: dts: allwinner: Add devicetree for pine H64 modelA evaluation board
From: Corentin Labbe @ 2019-08-14 13:17 UTC (permalink / raw)
To: Maxime Ripard
Cc: mark.rutland, devicetree, linux-sunxi, linux-kernel, wens,
robh+dt, linux-arm-kernel
In-Reply-To: <20190812094000.ebdmhyxx7xzbevef@flea>
On Mon, Aug 12, 2019 at 11:40:00AM +0200, Maxime Ripard wrote:
> On Thu, Aug 08, 2019 at 10:42:53AM +0200, Corentin Labbe wrote:
> > This patch adds the evaluation variant of the model A of the PineH64.
> > The model A has the same size of the pine64 and has a PCIE slot.
> >
> > The only devicetree difference with current pineH64, is the PHY
> > regulator.
> >
> > Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
> > ---
> > arch/arm64/boot/dts/allwinner/Makefile | 1 +
> > .../sun50i-h6-pine-h64-modelA-eval.dts | 26 +++++++++++++++++++
> > 2 files changed, 27 insertions(+)
> > create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-modelA-eval.dts
> >
> > diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/allwinner/Makefile
> > index f6db0611cb85..9a02166cbf72 100644
> > --- a/arch/arm64/boot/dts/allwinner/Makefile
> > +++ b/arch/arm64/boot/dts/allwinner/Makefile
> > @@ -25,3 +25,4 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-orangepi-3.dtb
> > dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-orangepi-lite2.dtb
> > dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-orangepi-one-plus.dtb
> > dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64.dtb
> > +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64-modelA-eval.dtb
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-modelA-eval.dts b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-modelA-eval.dts
> > new file mode 100644
> > index 000000000000..d8ff02747efe
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-modelA-eval.dts
> > @@ -0,0 +1,26 @@
> > +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
> > +/*
> > + * Copyright (C) 2019 Corentin Labbe <clabbe.montjoie@gmail.com>
> > + */
> > +
> > +#include "sun50i-h6-pine-h64.dts"
> > +
> > +/ {
> > + model = "Pine H64 model A evaluation board";
> > + compatible = "pine64,pine-h64-modelA-eval", "allwinner,sun50i-h6";
> > +
> > + reg_gmac_3v3: gmac-3v3 {
> > + compatible = "regulator-fixed";
> > + regulator-name = "vcc-gmac-3v3";
> > + regulator-min-microvolt = <3300000>;
> > + regulator-max-microvolt = <3300000>;
> > + startup-delay-us = <100000>;
> > + gpio = <&pio 2 16 GPIO_ACTIVE_HIGH>;
> > + enable-active-high;
> > + };
> > +
> > +};
> > +
> > +&emac {
> > + phy-supply = <®_gmac_3v3>;
> > +};
>
> I might be missing some context here, but I'm pretty sure that the
> initial intent of the pine h64 DTS was to support the model A all
> along.
>
The regulator changed between modelA and B.
See this old patchset (supporting modelA) https://patchwork.kernel.org/patch/10539149/ for example.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 5/8] arm64: memory: Simplify _VA_START and _PAGE_OFFSET definitions
From: Mark Rutland @ 2019-08-14 13:18 UTC (permalink / raw)
To: Will Deacon
Cc: Steve Capper, Andrey Konovalov, Geert Uytterhoeven,
Catalin Marinas, Qian Cai, linux-arm-kernel
In-Reply-To: <20190814115959.7epzszx53bidti7m@willie-the-truck>
On Wed, Aug 14, 2019 at 01:00:00PM +0100, Will Deacon wrote:
> On Wed, Aug 14, 2019 at 12:23:39PM +0100, Mark Rutland wrote:
> > On Tue, Aug 13, 2019 at 06:01:46PM +0100, Will Deacon wrote:
> > > Rather than subtracting from -1 and then adding 1, we can simply
> > > subtract from 0.
> > >
> > > Cc: Steve Capper <steve.capper@arm.com>
> > > Signed-off-by: Will Deacon <will@kernel.org>
> > > ---
> > > arch/arm64/include/asm/memory.h | 6 ++----
> > > 1 file changed, 2 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> > > index 56be462c69ce..5552c8cba1e2 100644
> > > --- a/arch/arm64/include/asm/memory.h
> > > +++ b/arch/arm64/include/asm/memory.h
> > > @@ -44,8 +44,7 @@
> > > * VA_START - the first kernel virtual address.
> > > */
> > > #define VA_BITS (CONFIG_ARM64_VA_BITS)
> > > -#define _PAGE_OFFSET(va) (UL(0xffffffffffffffff) - \
> > > - (UL(1) << (va)) + 1)
> > > +#define _PAGE_OFFSET(va) (-(UL(1) << (va)))
> > > #define PAGE_OFFSET (_PAGE_OFFSET(VA_BITS))
> > > #define KIMAGE_VADDR (MODULES_END)
> > > #define BPF_JIT_REGION_START (KASAN_SHADOW_END)
> > > @@ -63,8 +62,7 @@
> > > #else
> > > #define VA_BITS_MIN (VA_BITS)
> > > #endif
> > > -#define _VA_START(va) (UL(0xffffffffffffffff) - \
> > > - (UL(1) << ((va) - 1)) + 1)
> > > +#define _VA_START(va) (-(UL(1) << ((va) - 1)))
> >
> > This didn't make any sense to me until I realised that we changed the
> > meaning of VA_START when flippnig the VA space. Given that, this cleanup
> > looks sound to me.
> >
> > However...
> >
> > VA_START used to be the start of the TTBR1 address space, which was what
> > the "first kernel virtual address" comment was trying to say. Now it's
> > the first non-linear kernel virtual addres, which I think is very
> > confusing.
> >
> > AFAICT, that change breaks at least:
> >
> > * is_ttbr1_addr() -- now returns false for linear map addresses
> > * ptdump_check_wx() -- now skips the linear map
> > * ptdump_init() -- initialises start_address inccorrectly.
> >
> > ... so could we please find a new name for the first non-linear address,
> > e.g. PAGE_END, and leave VA_START as the first TTBR1 address?
>
> I think VA_START becomes PAGE_END and then things like is_ttbr1_addr()
> just refer to PAGE_OFFSET instead. ptdump_init() looks ok to me, but I could
> be missing something.
Yes; you're right about ptdump_init().
> Anyway, these seem to be comments on the original patches from Steve rather
> than my fixes, so please send additional fixes on top. I'll push out an
> updated branch for you to work with...
Sure, I'll post a couple of patches momentarily...
Mark.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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