* Re: [PATCH v3 1/9] mm: Introduce new vm_insert_range API
From: Souptick Joarder @ 2018-12-07 21:48 UTC (permalink / raw)
To: robin.murphy
Cc: Michal Hocko, Heiko Stuebner, Peter Zijlstra, dri-devel,
linux-kernel, Linux-MM, linux1394-devel, Marek Szyprowski,
Stephen Rothwell, oleksandr_andrushchenko, joro,
Russell King - ARM Linux, Matthew Wilcox, airlied,
linux-arm-kernel, linux-rockchip, treding, linux-media, Kees Cook,
pawel, Rik van Riel, iommu, rppt, Boris Ostrovsky, mchehab,
iamjoonsoo.kim, vbabka, Juergen Gross, hjc, xen-devel,
Kyungmin Park, stefanr, Andrew Morton, Kirill A. Shutemov
In-Reply-To: <67495f8f-2092-e42d-321e-5216c346513f@arm.com>
On Sat, Dec 8, 2018 at 2:40 AM Robin Murphy <robin.murphy@arm.com> wrote:
>
> On 2018-12-07 7:28 pm, Souptick Joarder wrote:
> > On Fri, Dec 7, 2018 at 10:41 PM Matthew Wilcox <willy@infradead.org> wrote:
> >>
> >> On Fri, Dec 07, 2018 at 03:34:56PM +0000, Robin Murphy wrote:
> >>>> +int vm_insert_range(struct vm_area_struct *vma, unsigned long addr,
> >>>> + struct page **pages, unsigned long page_count)
> >>>> +{
> >>>> + unsigned long uaddr = addr;
> >>>> + int ret = 0, i;
> >>>
> >>> Some of the sites being replaced were effectively ensuring that vma and
> >>> pages were mutually compatible as an initial condition - would it be worth
> >>> adding something here for robustness, e.g.:
> >>>
> >>> + if (page_count != vma_pages(vma))
> >>> + return -ENXIO;
> >>
> >> I think we want to allow this to be used to populate part of a VMA.
> >> So perhaps:
> >>
> >> if (page_count > vma_pages(vma))
> >> return -ENXIO;
> >
> > Ok, This can be added.
> >
> > I think Patch [2/9] is the only leftover place where this
> > check could be removed.
>
> Right, 9/9 could also have relied on my stricter check here, but since
> it's really testing whether it actually managed to allocate vma_pages()
> worth of pages earlier, Matthew's more lenient version won't help for
> that one.
(Why privcmd_buf_mmap() doesn't clean up and return an error
> as soon as that allocation loop fails, without taking the mutex under
> which it still does a bunch more pointless work to only undo it again,
> is a mind-boggling mystery, but that's not our problem here...)
I think some clean up can be done here in a separate patch.
_______________________________________________
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 1/4] dt-bindings: pinctrl: Add devicetree bindings for MT6797 SoC Pinctrl
From: Sean Wang @ 2018-12-07 21:42 UTC (permalink / raw)
To: olof
Cc: Linus Walleij, linux-kernel, robh+dt, linux-gpio, arm,
linux-mediatek, amit.kucheria, Manivannan Sadhasivam,
Matthias Brugger, linux-arm-kernel
In-Reply-To: <CAOesGMhcBXLRRKdOMdq3Bg8fOGX6F0gWMJ3zzg0jW9bg9VeW7A@mail.gmail.com>
Hi Olof,
I'm a guy from MediaTek.
Thanks for your input and we will get these bad things to be better.
On Fri, Dec 7, 2018 at 10:42 AM Olof Johansson <olof@lixom.net> wrote:
>
> On Wed, Dec 5, 2018 at 4:01 AM Linus Walleij <linus.walleij@linaro.org> wrote:
> >
> > On Mon, Dec 3, 2018 at 2:08 AM Matthias Brugger <matthias.bgg@gmail.com> wrote:
> > > On 15/11/2018 11:04, Linus Walleij wrote:
> > > > On Wed, Nov 7, 2018 at 6:49 PM Manivannan Sadhasivam
> > > > <manivannan.sadhasivam@linaro.org> wrote:
> > > >
> > > >> Add devicetree bindings for Mediatek MT6797 SoC Pin Controller.
> > > >>
> > > >> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> > > >
> > > > Patch applied.
> > > >
> > >
> > > Could you provide a stable tree for me, so that I can take the dts parts?
> > > I just realized that my build is broken because of the missing dt-bindings
> > > header file.
> >
> > Since I pulled other changes on top it is too late for me to put that
> > in an immutable branch and merge into my tree separately,
> > you would have to pull in the whole "devel" branch from the
> > pin control tree.
> >
> > What we sometimes do is simply apply the *EXACT* same patch
> > to two git trees. Git will cope with that as long as they are
> > absolutely *IDENTICAL*. (The patch will appear twice in the
> > git log with different hashes but they will merge without
> > problems, a bit unelegant but it works.)
> >
> > So in your situation I would extract this patch from the pinctrl
> > tree:
> > https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git/commit/?h=devel&id=95d2f00657ad4c2c3eacd8a871a7aa022c3fe7d9
> > and apply it with some notice to the maintainers about
> > the situation.
> >
> > ARM SoC folks: agreed?
>
> So, applying the patches in parallel is fine, but this made me look at
> the actual patches and file contents, and they seem to be a bit messy.
>
I've also noticed the messy thing so we've changed these doable SoCs
to using generic pinctrl bindings like MT7622 and MT7629 to get rid of
the big header. And for the other SoCs, they still tend to keep vendor
binding because of historical reasons, the related board makers
preferences and it is indeed a little hard to change what these people
used to.
> This feedback is more to the MT maintainers/developers than you, Linus
> (obviously):
>
> These header files are huge, and they're inconsistent in the way they
> define these constants:
>
> include/dt-bindings/pinctrl/mt7623-pinfunc.h:
> #define MT7623_PIN_21_PCM_TX_FUNC_GPIO21 (MTK_PIN_NO(21) | 0)
> #define MT7623_PIN_21_PCM_TX_FUNC_PCM_TX (MTK_PIN_NO(21) | 1)
> #define MT7623_PIN_21_PCM_TX_FUNC_MRG_TX (MTK_PIN_NO(21) | 2)
> #define MT7623_PIN_21_PCM_TX_FUNC_MRG_RX (MTK_PIN_NO(21) | 3)
> #define MT7623_PIN_21_PCM_TX_FUNC_PCM_RX (MTK_PIN_NO(21) | 4)
> #define MT7623_PIN_21_PCM_TX_FUNC_CONN_DSP_JMS (MTK_PIN_NO(21) | 5)
> #define MT7623_PIN_21_PCM_TX_FUNC_AP_PCM_TX (MTK_PIN_NO(21) | 6)
>
> include/dt-bindings/pinctrl/mt6397-pinfunc.h:
> #define MT6397_PIN_24_ROW4__FUNC_GPIO24 (MTK_PIN_NO(24) | 0)
> #define MT6397_PIN_24_ROW4__FUNC_ROW4 (MTK_PIN_NO(24) | 1)
> #define MT6397_PIN_24_ROW4__FUNC_EINT22_1X (MTK_PIN_NO(24) | 2)
> #define MT6397_PIN_24_ROW4__FUNC_SCL2_3X (MTK_PIN_NO(24) | 3)
> #define MT6397_PIN_24_ROW4__FUNC_TEST_IN15 (MTK_PIN_NO(24) | 6)
> #define MT6397_PIN_24_ROW4__FUNC_TEST_OUT15 (MTK_PIN_NO(24) | 7)
>
> include/dt-bindings/pinctrl/mt6797-pinfunc.h:
> #define MT6797_GPIO34__FUNC_GPIO34 (MTK_PIN_NO(34) | 0)
> #define MT6797_GPIO34__FUNC_CMFLASH (MTK_PIN_NO(34) | 1)
> #define MT6797_GPIO34__FUNC_CLKM0 (MTK_PIN_NO(34) | 2)
> #define MT6797_GPIO34__FUNC_UDI_NTRST (MTK_PIN_NO(34) | 3)
> #define MT6797_GPIO34__FUNC_SCP_JTAG_TRSTN (MTK_PIN_NO(34) | 4)
> #define MT6797_GPIO34__FUNC_CONN_MCU_TRST_B (MTK_PIN_NO(34) | 5)
> #define MT6797_GPIO34__FUNC_MD_UTXD0 (MTK_PIN_NO(34) | 6)
> #define MT6797_GPIO34__FUNC_C2K_DM_JTINTP (MTK_PIN_NO(34) | 7)
>
> So, is it a pin or a GPIO and why does 6797 use different naming
> scheme?
They all stand for the pin and list all the functions which the pin
can be switched to.
MT6797 is the first mtk pinctrl driver not contributed by mediatek people,
we will try to fix these confusing things and should be careful
keeping the naming be uniform in the future.
> Why do some of them have __FUNC and some _FUNC?Why do some
> have the non-gpio function as part of the name and some do not?
>
ditto, we will try to fix and keep the naming be uniform
> Also, "pin 24 row 4 func row4"? Seems to have very limited value to
> describe it in that manner, it's just overly verbose without adding
> information.
All the function names for a pin totally are same (copied) with
hardware document describes. That means it's default function of the
pin the hardware provides.
>
> Some other SoCs tend to use a pinctrl specifier that is two-cell <pin
> function> instead of trying to pack them into one integer.
I'm not the initial developer for the vendor binding. but I guessed
the initial thought trying to pack them into one integer can decrease
the risk of inconsistency between pin and function, especially
there're more than some hundred pins and functions present on SoC.
> That seems
> a lot more practical, especially since the base GPIO function seems to
> generically be '0'. So the pin number would go in the first cell, and
> the function in the second.
>
> Finally, I don't see how the header file is used in the code at all?
>
> The main idea behind the dt bindings header files is that they would
> provide shared constants between the DT and the driver in the kernel.
> If the constants are never used (i.e. they're just register values,
> like today), then there's no need to merge the dt header with the
> driver at all, it should go with the DT contents instead.
Yes, it should be better to go with DT contents, not be the interface
between DT and driver. These pin names are totally the same with these
pin names shown on the schematic diagram, so it works more like
providing an easy to remember text to allow people configure its pin
easier while crossing reference schematic diagram.
> So, for
> example, if you used something like a format of <pin function>
> properties, the header file could contain both the string
> representation of the function for debug, as well as the values, all
> derived from one place. Today all you have string representations for
> is "func0".."func15" through mtk_gpio_functions[]. Seems like an
> improvement all around?
>
>
> -Olof
_______________________________________________
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 v11 8/8] interconnect: sdm845: Fix build failure after cmd_db API change
From: Doug Anderson @ 2018-12-07 21:29 UTC (permalink / raw)
To: quentin.perret
Cc: Mark Rutland, sanjayc, maxime.ripard, Michael Turquette,
daidavid1, Bjorn Andersson, Saravana Kannan, abailon,
Lorenzo Pieralisi, Vincent Guittot, seansw, Kevin Hilman,
Evan Green, ksitaraman, devicetree, Arnd Bergmann, linux-pm,
linux-arm-msm, Andy Gross, Rob Herring, linux-tegra, Linux ARM,
Greg Kroah-Hartman, Rafael J. Wysocki, LKML, Amit Kucheria,
Thierry Reding, Olof Johansson, Georgi Djakov
In-Reply-To: <20181207171437.qmtacurmqg53zzkl@queper01-lin>
Hi,
On Fri, Dec 7, 2018 at 9:14 AM Quentin Perret <quentin.perret@arm.com> wrote:
>
> On Friday 07 Dec 2018 at 18:47:22 (+0200), Georgi Djakov wrote:
> > Hi Quentin,
> >
> > On 12/7/18 18:27, Quentin Perret wrote:
> > > Hi Georgi,
> > >
> > > On Friday 07 Dec 2018 at 17:29:17 (+0200), Georgi Djakov wrote:
> > >> Recently the cmd_db_read_aux_data() function was changed to avoid using
> > >> memcpy and return a pointer instead. Update the code to the new API and
> > >> fix the build failure.
> > >>
> > >> Fixes: ed3cafa79ea7 ("soc: qcom: cmd-db: Stop memcpy()ing in cmd_db_read_aux_data()")
> > >> Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
> > >> ---
> > >> drivers/interconnect/qcom/sdm845.c | 26 ++++++++++++++------------
> > >
> > > IIUC this file is introduced by patch 5. Should the fix be squashed
> > > into patch 5 directly ? Just to keep things bisectable.
> >
> > The reason why i have split it as a separate change is because as a
> > separate change it would be easier to review & test for the people who
> > are already familiar with the rest of the series.
> >
> > Another minor reason is that a separate patch will also make the life a
> > bit easier for some people who are back-porting this to kernels using
> > the older version of the cmd_db API.
> >
> > The commit that changed the cmd_db API is not yet in mainline, but in
> > linux-next. I am not sure what is preferred in this case?
>
> Not sure either but I guess that will depend who gets merged first ...
> If that's the cmd_db change, then you'll need to squash your fix in
> patch 5. If your series goes first, then the fix needs to be applied to
> the cmb_db change.
>
> I personally don't mind either way as long as we don't break bisection :-)
My $0.02 is that anyone downstream picking this will also be picking
the cmd db change, so I'd suggest squashing as suggested by Quentin.
Maybe you can do that and post a v12? Since it sounded like Greg was
about ready to land [1] maybe we shouldn't wait too long till doing
it?
...unfortunately I guess we need to figure out how this will actually
land. Greg can't pick the series up directly since it won't compile
without the cmd-db change. ...so we need to do one of the following:
1. Feed it through a tree that goes through arm-soc (Andy's tree or
arm-soc directly) so you'll have commit ed3cafa79ea7 ("soc: qcom:
cmd-db: Stop memcpy()ing in cmd_db_read_aux_data()").
2. Greg could also merge in Andy's pull request
(https://patchwork.kernel.org/patch/10710447/), but you'll get some
unrelated patches too.
3. Wait until next year and we have the next -rc1 to get this merged.
...it seems like #1 would be the least painful option, but obviously
others would have to be OK w/ it.
[1] https://lkml.kernel.org/r/20181206145547.GA7884@kroah.com
-Doug
_______________________________________________
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 v2 15/15] arm64: dts: allwinner: a64: Add Video Engine node
From: Jernej Škrabec @ 2018-12-07 21:22 UTC (permalink / raw)
To: linux-sunxi, paul.kocialkowski
Cc: devel, devicetree, Sakari Ailus, Maxime Ripard, linux-kernel,
Hans Verkuil, Chen-Yu Tsai, Rob Herring, Thomas Petazzoni,
Mark Rutland, Mauro Carvalho Chehab, linux-arm-kernel,
linux-media
In-Reply-To: <20181205092444.29497-16-paul.kocialkowski@bootlin.com>
Hi!
Dne sreda, 05. december 2018 ob 10:24:44 CET je Paul Kocialkowski napisal(a):
> This adds the Video Engine node for the A64. Since it can map the whole
> DRAM range, there is no particular need for a reserved memory node
> (unlike platforms preceding the A33).
>
> Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
> ---
> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi index
> 8557d52c7c99..8d024c10d7cb 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> @@ -397,6 +397,17 @@
> };
> };
>
> + video-codec@1c0e000 {
> + compatible = "allwinner,sun50i-h5-video-engine";
You meant A64 instead of H5, right?
Best regards,
Jernej
> + reg = <0x01c0e000 0x1000>;
> + clocks = <&ccu CLK_BUS_VE>, <&ccu CLK_VE>,
> + <&ccu CLK_DRAM_VE>;
> + clock-names = "ahb", "mod", "ram";
> + resets = <&ccu RST_BUS_VE>;
> + interrupts = <GIC_SPI 58 IRQ_TYPE_LEVEL_HIGH>;
> + allwinner,sram = <&ve_sram 1>;
> + };
> +
> mmc0: mmc@1c0f000 {
> compatible = "allwinner,sun50i-a64-mmc";
> reg = <0x01c0f000 0x1000>;
_______________________________________________
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 4/9] drm/rockchip/rockchip_drm_gem.c: Convert to use vm_insert_range
From: Robin Murphy @ 2018-12-07 21:19 UTC (permalink / raw)
To: Souptick Joarder
Cc: Michal Hocko, Heiko Stuebner, linux-rockchip, airlied, hjc,
Matthew Wilcox, linux-kernel, Linux-MM, dri-devel, Andrew Morton,
linux-arm-kernel
In-Reply-To: <CAFqt6zbMbvB1ckwhSsBATrq5M-HQ6qk95sCWCoTTFFnwzBAnng@mail.gmail.com>
On 2018-12-07 8:30 pm, Souptick Joarder wrote:
> On Fri, Dec 7, 2018 at 8:20 PM Robin Murphy <robin.murphy@arm.com> wrote:
>>
>> On 06/12/2018 18:42, Souptick Joarder wrote:
>>> Convert to use vm_insert_range() to map range of kernel
>>> memory to user vma.
>>>
>>> Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com>
>>> Tested-by: Heiko Stuebner <heiko@sntech.de>
>>> Acked-by: Heiko Stuebner <heiko@sntech.de>
>>> ---
>>> drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 20 ++------------------
>>> 1 file changed, 2 insertions(+), 18 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
>>> index a8db758..2cb83bb 100644
>>> --- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
>>> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
>>> @@ -221,26 +221,10 @@ static int rockchip_drm_gem_object_mmap_iommu(struct drm_gem_object *obj,
>>> struct vm_area_struct *vma)
>>> {
>>> struct rockchip_gem_object *rk_obj = to_rockchip_obj(obj);
>>> - unsigned int i, count = obj->size >> PAGE_SHIFT;
>>> unsigned long user_count = vma_pages(vma);
>>> - unsigned long uaddr = vma->vm_start;
>>> - unsigned long offset = vma->vm_pgoff;
>>> - unsigned long end = user_count + offset;
>>> - int ret;
>>> -
>>> - if (user_count == 0)
>>> - return -ENXIO;
>>> - if (end > count)
>>> - return -ENXIO;
>>>
>>> - for (i = offset; i < end; i++) {
>>> - ret = vm_insert_page(vma, uaddr, rk_obj->pages[i]);
>>> - if (ret)
>>> - return ret;
>>> - uaddr += PAGE_SIZE;
>>> - }
>>> -
>>> - return 0;
>>> + return vm_insert_range(vma, vma->vm_start, rk_obj->pages,
>>> + user_count);
>>
>> We're losing vm_pgoff handling here, which given the implication in
>> 57de50af162b, may well be a regression for at least some combination of
>> GPU and userspace driver (I assume that commit was in the context of
>> some version of the Arm Mali driver, possibly on RK3288).
>
> In commit 57de50af162b, vma->vm_pgoff = 0 for GEM mmap handler context
> and removing it from common path which means if call stack looks like
> rockchip_gem_mmap_buf() -> rockchip_drm_gem_object_mmap() ->
> rockchip_drm_gem_object_mmap_iommu(), then we might have a non zero
> vma->vm_pgoff context which is not handled.
>
> This is the problem you are pointing ? right ?
Exactly - if unconditionally zeroing the offset in the PRIME mmap() path
was a problem, then the implication is that there are callers of that
path who expect the offset to be honoured here.
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: [PATCH v3 1/9] mm: Introduce new vm_insert_range API
From: Robin Murphy @ 2018-12-07 21:10 UTC (permalink / raw)
To: Souptick Joarder, Matthew Wilcox
Cc: Michal Hocko, Heiko Stuebner, Peter Zijlstra, dri-devel,
linux-kernel, Linux-MM, linux1394-devel, Marek Szyprowski,
Stephen Rothwell, oleksandr_andrushchenko, joro,
Russell King - ARM Linux, iommu, airlied, linux-arm-kernel,
linux-rockchip, treding, linux-media, Kees Cook, pawel,
Rik van Riel, rppt, Boris Ostrovsky, mchehab, iamjoonsoo.kim,
vbabka, Juergen Gross, hjc, xen-devel, Kyungmin Park, stefanr,
Andrew Morton, Kirill A. Shutemov
In-Reply-To: <CAFqt6zYCWOK-uS85GqCzcgT=+YKn1nBrRPq+M9y6eJjmXEKH+g@mail.gmail.com>
On 2018-12-07 7:28 pm, Souptick Joarder wrote:
> On Fri, Dec 7, 2018 at 10:41 PM Matthew Wilcox <willy@infradead.org> wrote:
>>
>> On Fri, Dec 07, 2018 at 03:34:56PM +0000, Robin Murphy wrote:
>>>> +int vm_insert_range(struct vm_area_struct *vma, unsigned long addr,
>>>> + struct page **pages, unsigned long page_count)
>>>> +{
>>>> + unsigned long uaddr = addr;
>>>> + int ret = 0, i;
>>>
>>> Some of the sites being replaced were effectively ensuring that vma and
>>> pages were mutually compatible as an initial condition - would it be worth
>>> adding something here for robustness, e.g.:
>>>
>>> + if (page_count != vma_pages(vma))
>>> + return -ENXIO;
>>
>> I think we want to allow this to be used to populate part of a VMA.
>> So perhaps:
>>
>> if (page_count > vma_pages(vma))
>> return -ENXIO;
>
> Ok, This can be added.
>
> I think Patch [2/9] is the only leftover place where this
> check could be removed.
Right, 9/9 could also have relied on my stricter check here, but since
it's really testing whether it actually managed to allocate vma_pages()
worth of pages earlier, Matthew's more lenient version won't help for
that one. (Why privcmd_buf_mmap() doesn't clean up and return an error
as soon as that allocation loop fails, without taking the mutex under
which it still does a bunch more pointless work to only undo it again,
is a mind-boggling mystery, but that's not our problem here...)
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: [PATCH v4 2/6] arm64: add basic DTS for i.MX8MQ
From: Abel Vesa @ 2018-12-07 21:07 UTC (permalink / raw)
To: Lucas Stach
Cc: Aisheng Dong, Rob Herring, devicetree@vger.kernel.org,
patchwork-lst@pengutronix.de, dl-linux-imx, kernel@pengutronix.de,
Fabio Estevam, Shawn Guo, linux-arm-kernel@lists.infradead.org
In-Reply-To: <1544200612.3709.111.camel@pengutronix.de>
On Fri, Dec 07, 2018 at 05:36:52PM +0100, Lucas Stach wrote:
> Hi Abel,
>
> Am Freitag, den 07.12.2018, 16:17 +0000 schrieb Abel Vesa:
> > On Fri, Nov 16, 2018 at 05:25:24PM -0600, Rob Herring wrote:
> >
> > > > +
> > > > + clk_ext1: clock-ext1 {
> > > > + compatible = "fixed-clock";
> > > > + #clock-cells = <0>;
> > > > + clock-frequency = <133000000>;
> > > > + clock-output-names = "clk_ext1";
> > > > + };
> > > > +
> > > > + clk_ext2: clock-ext2 {
> > > > + compatible = "fixed-clock";
> > > > + #clock-cells = <0>;
> > > > + clock-frequency = <133000000>;
> > > > + clock-output-names = "clk_ext2";
> > > > + };
> > > > +
> > > > + clk_ext3: clock-ext3 {
> > > > + compatible = "fixed-clock";
> > > > + #clock-cells = <0>;
> > > > + clock-frequency = <133000000>;
> > > > + clock-output-names = "clk_ext3";
> > > > + };
> > > > +
> > > > + clk_ext4: clock-ext4 {
> > > > + compatible = "fixed-clock";
> > > > + #clock-cells = <0>;
> > > > + clock-frequency= <133000000>;
> > > > + clock-output-names = "clk_ext4";
> > > > + };
> > >
> > > This is really 4 independent clocks or is 1 clock connected to 4
> > > sinks?
> >
> > According to the RM, yes, there are 4 independent clocks. Here is a
> > link to the rm:
> >
> > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.nxp.com%2Fwebapp%2FDownload%3FcolCode%3DIMX8MEVKBHUG&data=02%7C01%7Cabel.vesa%40nxp.com%7C303f3053feb94a3c1c9f08d65c623255%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636797974154936811&sdata=CuJSqDl1WiL%2Bc%2B4wYnr3ssDDpH3DorYIzLN87PNHVh4%3D&reserved=0 (page 829)
> >
> > Unfortunately, the old link (which worked without login) does not
> > work anymore.
>
> It's really 4 clock inputs to the SoC, but they may actually be
> connected to the same clock source on the board. So I really wonder if
> we should even put this into the base SoC DT, but rather push this into
> individual board DTs.
Hmm, it's part of the SoC, right ? So I would keep it in the dtsi rather than
having it duplicated into every new dts.
>
> Regards,
> Lucas
--
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: OMAP4430 SDP with KS8851: very slow networking
From: Tony Lindgren @ 2018-12-07 20:55 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: netdev, Grygorii Strashko, linux-omap, linux-arm-kernel
In-Reply-To: <20181207192731.GB9507@n2100.armlinux.org.uk>
* Russell King - ARM Linux <linux@armlinux.org.uk> [181207 19:27]:
> You mentioned that edge mode didn't work as well as level mode on
> duovero smsc controller, I think this may help to solve the same
> issue but for edge IRQs - we need a mask_ack_irq function to avoid
> acking while the edge interrupt is masked. Let me know if that
> lowers the smsc ping latency while in edge mode.
Looks like smsc edge interrupt is still producing varying
ping latencies with this. Seems like the mas_ack_irq is
a nice improvment though.
Regards,
Tony
_______________________________________________
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 1/2] drivers: amba: Updates to component identification for driver matching.
From: Mathieu Poirier @ 2018-12-07 20:44 UTC (permalink / raw)
To: Mike Leach
Cc: coresight, suzuki.poulose, linux, linux-arm-kernel, linux-kernel
In-Reply-To: <20181206000226.2507-2-mike.leach@linaro.org>
Good day Mike,
On Thu, Dec 06, 2018 at 12:02:25AM +0000, Mike Leach wrote:
> The CoreSight specification (ARM IHI 0029E), updates the ID register
> requirements for components on an AMBA bus, to cover both traditional
> ARM Primecell type devices, and newer CoreSight and other components.
>
> The Peripheral ID (PID) / Component ID (CID) pair is extended in certain
> cases to uniquely identify components. CoreSight components related to
> a single function can share Peripheral ID values, and must be further
> identified using a Unique Component Identifier (UCI). e.g. the ETM, CTI,
> PMU and Debug hardware of the A35 all share the same PID.
>
> Bits 15:12 of the CID are defined to be the device class.
> Class 0xF remains for PrimeCell and legacy components.
> Class 0x9 defines the component as CoreSight (CORESIGHT_CID above)
> Class 0x0, 0x1, 0xB, 0xE define components that do not have driver support
> at present.
> Class 0x2-0x8,0xA and 0xD-0xD are presently reserved.
>
> The specification futher defines which classes of device use the standard
> CID/PID pair, and when additional ID registers are required.
>
> The patches provide an update of amba_device and matching code to handle
> the additional registers required for the Class 0x9 (CoreSight) UCI.
> The *data pointer in the amba_id is used by the driver to provide extended
> ID register values for matching.
>
> CoreSight components where PID/CID pair is currently sufficient for
> unique identification need not provide this additional information.
>
> Signed-off-by: Mike Leach <mike.leach@linaro.org>
I am good with this patch but can't take it until Russell gives me the thumbs
up. He may also decide to take it in his tree, in which case:
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Russell, let me know that is the easiest for you.
Thanks,
Mathieu
> ---
> drivers/amba/bus.c | 45 +++++++++++++++++++++++++++++++++-------
> include/linux/amba/bus.h | 32 ++++++++++++++++++++++++++++
> 2 files changed, 69 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/amba/bus.c b/drivers/amba/bus.c
> index 41b706403ef7..524296a0eba0 100644
> --- a/drivers/amba/bus.c
> +++ b/drivers/amba/bus.c
> @@ -26,19 +26,36 @@
>
> #define to_amba_driver(d) container_of(d, struct amba_driver, drv)
>
> -static const struct amba_id *
> -amba_lookup(const struct amba_id *table, struct amba_device *dev)
> +/* called on periphid match and class 0x9 coresight device. */
> +static int
> +amba_cs_uci_id_match(const struct amba_id *table, struct amba_device *dev)
> {
> int ret = 0;
> + struct amba_cs_uci_id *uci;
> +
> + uci = table->data;
>
> + /* no table data - return match on periphid */
> + if (!uci)
> + return 1;
> +
> + /* test against read devtype and masked devarch value */
> + ret = (dev->uci.devtype == uci->devtype) &&
> + ((dev->uci.devarch & uci->devarch_mask) == uci->devarch);
> + return ret;
> +}
> +
> +static const struct amba_id *
> +amba_lookup(const struct amba_id *table, struct amba_device *dev)
> +{
> while (table->mask) {
> - ret = (dev->periphid & table->mask) == table->id;
> - if (ret)
> - break;
> + if (((dev->periphid & table->mask) == table->id) &&
> + ((dev->cid != CORESIGHT_CID) ||
> + (amba_cs_uci_id_match(table, dev))))
> + return table;
> table++;
> }
> -
> - return ret ? table : NULL;
> + return NULL;
> }
>
> static int amba_match(struct device *dev, struct device_driver *drv)
> @@ -399,10 +416,22 @@ static int amba_device_try_add(struct amba_device *dev, struct resource *parent)
> cid |= (readl(tmp + size - 0x10 + 4 * i) & 255) <<
> (i * 8);
>
> + if (cid == CORESIGHT_CID) {
> + /* set the base to the start of the last 4k block */
> + void __iomem *csbase = tmp + size - 4096;
> +
> + dev->uci.devarch =
> + readl(csbase + UCI_REG_DEVARCH_OFFSET);
> + dev->uci.devtype =
> + readl(csbase + UCI_REG_DEVTYPE_OFFSET) & 0xff;
> + }
> +
> amba_put_disable_pclk(dev);
>
> - if (cid == AMBA_CID || cid == CORESIGHT_CID)
> + if (cid == AMBA_CID || cid == CORESIGHT_CID) {
> dev->periphid = pid;
> + dev->cid = cid;
> + }
>
> if (!dev->periphid)
> ret = -ENODEV;
> diff --git a/include/linux/amba/bus.h b/include/linux/amba/bus.h
> index d143c13bed26..8c0f392e4da2 100644
> --- a/include/linux/amba/bus.h
> +++ b/include/linux/amba/bus.h
> @@ -25,6 +25,36 @@
> #define AMBA_CID 0xb105f00d
> #define CORESIGHT_CID 0xb105900d
>
> +/*
> + * CoreSight Architecture specification updates the ID specification
> + * for components on the AMBA bus. (ARM IHI 0029E)
> + *
> + * Bits 15:12 of the CID are the device class.
> + *
> + * Class 0xF remains for PrimeCell and legacy components. (AMBA_CID above)
> + * Class 0x9 defines the component as CoreSight (CORESIGHT_CID above)
> + * Class 0x0, 0x1, 0xB, 0xE define components that do not have driver support
> + * at present.
> + * Class 0x2-0x8,0xA and 0xD-0xD are presently reserved.
> + *
> + * Remaining CID bits stay as 0xb105-00d
> + */
> +
> +/*
> + * Class 0x9 components use additional values to form a Unique Component
> + * Identifier (UCI), where peripheral ID values are identical for different
> + * components. Passed to the amba bus code from the component driver via
> + * the amba_id->data pointer.
> + */
> +struct amba_cs_uci_id {
> + unsigned int devarch;
> + unsigned int devarch_mask;
> + unsigned int devtype;
> +};
> +
> +#define UCI_REG_DEVTYPE_OFFSET 0xFCC
> +#define UCI_REG_DEVARCH_OFFSET 0xFBC
> +
> struct clk;
>
> struct amba_device {
> @@ -32,6 +62,8 @@ struct amba_device {
> struct resource res;
> struct clk *pclk;
> unsigned int periphid;
> + unsigned int cid;
> + struct amba_cs_uci_id uci;
> unsigned int irq[AMBA_NR_IRQS];
> char *driver_override;
> };
> --
> 2.19.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: [GIT PULL] Allwinner clock changes for 4.21
From: Stephen Boyd @ 2018-12-07 20:41 UTC (permalink / raw)
To: Maxime Ripard, Mike Turquette, Stephen Boyd
Cc: Maxime Ripard, Chen-Yu Tsai, linux-clk, linux-arm-kernel
In-Reply-To: <20181207150158.vvfpjcxjikjjyj5m@flea>
Quoting Maxime Ripard (2018-12-07 07:01:58)
> Hi Mike, Stephen,
>
> Please pull our usual changes for the next merge window.
>
> Thanks!
> Maxime
>
> The following changes since commit 651022382c7f8da46cb4872a545ee1da6d097d2a:
>
> Linux 4.20-rc1 (2018-11-04 15:37:52 -0800)
>
> are available in the Git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git tags/sunxi-clk-for-4.21
>
> for you to fetch changes up to 6e6da2039c82271dd873b9ad2b902a692a7dd554:
>
> clk: sunxi-ng: a33: Set CLK_SET_RATE_PARENT for all audio module clocks (2018-12-05 12:08:20 +0100)
>
Thanks. Pulled into clk-next.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] ARM: shmobile: Fix R-Car Gen2 regulator quirk
From: Marek Vasut @ 2018-12-07 20:28 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Geert Uytterhoeven, Kuninori Morimoto, Yoshihiro Shimoda,
linux-renesas-soc, Wolfram Sang, Simon Horman, Marek Vasut
The quirk code currently detects all compatible I2C chips with a shared
IRQ line on all I2C busses, adds them into a list, and registers a bus
notifier. For every chip for which the bus notifier triggers, the quirk
code performs I2C transfer on that I2C bus for all addresses in the list.
The problem is that this may generate transfers to non-existing chips on
systems with multiple I2C busses.
This patch adds a check to verify that the I2C bus to which the chip with
shared IRQ is attached to matches the I2C bus of the chip which triggered
the bus notifier and only starts the I2C transfer if they match.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Cc: Simon Horman <horms+renesas@verge.net.au>
Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>
Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Cc: linux-renesas-soc@vger.kernel.org
---
arch/arm/mach-shmobile/regulator-quirk-rcar-gen2.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/mach-shmobile/regulator-quirk-rcar-gen2.c b/arch/arm/mach-shmobile/regulator-quirk-rcar-gen2.c
index d4774d8ff997..f78e5348bd4c 100644
--- a/arch/arm/mach-shmobile/regulator-quirk-rcar-gen2.c
+++ b/arch/arm/mach-shmobile/regulator-quirk-rcar-gen2.c
@@ -40,6 +40,7 @@
struct regulator_quirk {
struct list_head list;
const struct of_device_id *id;
+ struct device_node *np;
struct of_phandle_args irq_args;
struct i2c_msg i2c_msg;
bool shared; /* IRQ line is shared */
@@ -102,6 +103,9 @@ static int regulator_quirk_notify(struct notifier_block *nb,
if (!pos->shared)
continue;
+ if (pos->np->parent != client->dev.parent->of_node)
+ continue;
+
dev_info(&client->dev, "clearing %s@0x%02x interrupts\n",
pos->id->compatible, pos->i2c_msg.addr);
@@ -167,6 +171,7 @@ static int __init rcar_gen2_regulator_quirk(void)
memcpy(&quirk->i2c_msg, id->data, sizeof(quirk->i2c_msg));
quirk->id = id;
+ quirk->np = np;
quirk->i2c_msg.addr = addr;
ret = of_irq_parse_one(np, 0, argsa);
--
2.18.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: [PATCH v3 4/9] drm/rockchip/rockchip_drm_gem.c: Convert to use vm_insert_range
From: Souptick Joarder @ 2018-12-07 20:30 UTC (permalink / raw)
To: robin.murphy
Cc: Michal Hocko, Heiko Stuebner, linux-rockchip, airlied, hjc,
Matthew Wilcox, linux-kernel, Linux-MM, dri-devel, Andrew Morton,
linux-arm-kernel
In-Reply-To: <ca1779ea-7a87-971c-24c4-4a1c77a72e92@arm.com>
On Fri, Dec 7, 2018 at 8:20 PM Robin Murphy <robin.murphy@arm.com> wrote:
>
> On 06/12/2018 18:42, Souptick Joarder wrote:
> > Convert to use vm_insert_range() to map range of kernel
> > memory to user vma.
> >
> > Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com>
> > Tested-by: Heiko Stuebner <heiko@sntech.de>
> > Acked-by: Heiko Stuebner <heiko@sntech.de>
> > ---
> > drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 20 ++------------------
> > 1 file changed, 2 insertions(+), 18 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
> > index a8db758..2cb83bb 100644
> > --- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
> > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
> > @@ -221,26 +221,10 @@ static int rockchip_drm_gem_object_mmap_iommu(struct drm_gem_object *obj,
> > struct vm_area_struct *vma)
> > {
> > struct rockchip_gem_object *rk_obj = to_rockchip_obj(obj);
> > - unsigned int i, count = obj->size >> PAGE_SHIFT;
> > unsigned long user_count = vma_pages(vma);
> > - unsigned long uaddr = vma->vm_start;
> > - unsigned long offset = vma->vm_pgoff;
> > - unsigned long end = user_count + offset;
> > - int ret;
> > -
> > - if (user_count == 0)
> > - return -ENXIO;
> > - if (end > count)
> > - return -ENXIO;
> >
> > - for (i = offset; i < end; i++) {
> > - ret = vm_insert_page(vma, uaddr, rk_obj->pages[i]);
> > - if (ret)
> > - return ret;
> > - uaddr += PAGE_SIZE;
> > - }
> > -
> > - return 0;
> > + return vm_insert_range(vma, vma->vm_start, rk_obj->pages,
> > + user_count);
>
> We're losing vm_pgoff handling here, which given the implication in
> 57de50af162b, may well be a regression for at least some combination of
> GPU and userspace driver (I assume that commit was in the context of
> some version of the Arm Mali driver, possibly on RK3288).
In commit 57de50af162b, vma->vm_pgoff = 0 for GEM mmap handler context
and removing it from common path which means if call stack looks like
rockchip_gem_mmap_buf() -> rockchip_drm_gem_object_mmap() ->
rockchip_drm_gem_object_mmap_iommu(), then we might have a non zero
vma->vm_pgoff context which is not handled.
This is the problem you are pointing ? right ?
_______________________________________________
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 2/2] mm/sparse: add common helper to mark all memblocks present
From: Andrew Morton @ 2018-12-07 19:56 UTC (permalink / raw)
To: Logan Gunthorpe
Cc: linux-arch, Albert Ou, Arnd Bergmann, linux-sh, Palmer Dabbelt,
linux-kernel, Stephen Bates, linux-mm, Michal Hocko,
Vlastimil Babka, linux-riscv, Christoph Hellwig, linux-arm-kernel,
Oscar Salvador
In-Reply-To: <71168447-7470-d2ba-d30e-200ff6202b35@deltatee.com>
On Thu, 6 Dec 2018 10:40:31 -0700 Logan Gunthorpe <logang@deltatee.com> wrote:
> Hey Andrew,
>
> On 2018-11-07 1:12 p.m., Andrew Morton wrote:
> > Acked-by: Andrew Morton <akpm@linux-foundation.org>
> >
> > I can grab both patches and shall sneak them into 4.20-rcX, but feel
> > free to merge them into some git tree if you'd prefer. If I see them
> > turn up in linux-next I shall drop my copy.
>
> Just wanted to check if you are still planning to get these patches into
> 4.20-rcX. It would really help us if you can do this seeing we then
> won't have to delay a cycle and can target the riscv sparsemem code for
> 4.21.
>
Ah, OK, I assumed that it would be merged via an arm tree.
I moved
mm-introduce-common-struct_page_max_shift-define.patch
mm-sparse-add-common-helper-to-mark-all-memblocks-present.patch
to head-of-queue. Shall send to Linus next week.
_______________________________________________
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/2] meson: Fix IRQ trigger type
From: Jerome Brunet @ 2018-12-07 19:58 UTC (permalink / raw)
To: Emiliano Ingrassia, Carlo Caione, Martin Blumenstingl
Cc: mark.rutland, devicetree, khilman, robh+dt, linux-amlogic,
linux-arm-kernel
In-Reply-To: <20181207182845.GA3779@ingrassia.epigenesys.com>
On Fri, 2018-12-07 at 19:28 +0100, Emiliano Ingrassia wrote:
> On Fri, Dec 07, 2018 at 11:49:15AM +0100, Jerome Brunet wrote:
> > On Thu, 2018-12-06 at 19:51 +0100, Emiliano Ingrassia wrote:
> > > Hi Carlo,
> > >
> > > I keep running tests with packet generator,
> > > using nload to show bandwidth usage.
> > >
> > > Here is my test results with packet generators
> > > both running on laptop and board with rate 1 Gbps.
> >
> > Testing in UDP is unlikely to give us clear picture of anything for this
> > sort
> > of fixes.
> >
>
> Why? Would you mind to explain your reasoning?
Because we have no idea why packet are lost in UDP
>
> > All your test seems in show it the fact the Amlogic SoC usually prioritize
> > the
> > TX traffic over RX, which is something we've known about for a while.
> >
>
> Is that normal
Yes
> and/or acceptable?
Free software, Free world .. you are free to (try to) do something about it.
>
> > It would be helpful if you could provide TCP figures with a traffic
> > generator
> > we can all share an inspect, such as iperf3
> >
> > Finally, Your test do not show the original issue regarding EEE. So the
> > work
> > around we put (yes, it was never considered a solution) for it should not
> > be
> > kept IHMO. Your numbers for EEE may be due to the way the traffic is
> > generated
> > and the PHY entering LPI and taking a bit of time to exit it. Again UDP is
> > not
> > very helpful to characterize this.
> >
>
> Did you read my email entirely
Yes I did (and I'm starting to regret it)
> or just kidding me?
I don't know what you hope accomplish with that can, but you can be sure it
won't help.
>
> TEST 3 clearly shows that the issue regarding EEE is still there
> with both patches applied.
TEST 3 clearly shows nothing. Once gain with Tx priority and UDP, no
conclusion can be made from your test
>
> My comment about TEST 3 (same results as TEST 2):
> "Simple ping test from laptop to board shows a packet loss
> of 90% and more while no packet loss achieved pinging
> the laptop from the board."
>
> I definitively advice against the second patch (the part regarding
> 32 bit Meson SoC).
>
> About the first one, still no evidence that is needed on Meson8b SoC.
> And I'm saying it because I tested both patches on real hardware,
> not just guessing!
LOL. What are you trying to imply exactly ?
>
> Furthermore, as Martin reported in one of the previous mail,
> even Amlogic's buildroot kernel uses an edge rising IRQ type
> for the Meson8b MAC.
As far any other amlogic MAC ... And I think we pointed out that every other
dwmac users out there uses LEVEL, which makes a lot more sense and is stable.
> Other evidence that is not so clear
> the need for the first patch on 32 bit Meson SoC.
Not an evidence at all, no difference between the 32bit and 64bit arch.
>
> > > TEST 0: no patch applied.
> > >
> > > 1) Start packet generator on laptop:
> > >
> > > | incoming traffic | outgoing traffic
> > > =====================================================
> > > nload (board) | ~940 Mbps | 0 Mbps
> > > -----------------------------------------------------
> > > nload (laptop)| 0 Mbps | ~940 Mbps
> > > =====================================================
> > >
> > > 2) Start packet generator on board:
> > >
> > > | incoming traffic | outgoing traffic
> > > ==============+===================+==================
> > > nload (board) | ~460 Mbps | ~256 Mbps
> > > --------------+-------------------+------------------
> > > nload (laptop)| ~256 Mbps | ~940 Mbps
> > > =====================================================
> > >
> > > 3) Stop packet generator on laptop:
> > >
> > > | incoming traffic | outgoing traffic
> > > =====================================================
> > > nload (board) | 0 Mbps | ~940 Mbps
> > > -----------------------------------------------------
> > > nload (laptop)| ~940 Mbps | 0 Mbps
> > > =====================================================
> > >
> > > 4) Restart packet generator on laptop:
> > >
> > > | incoming traffic | outgoing traffic
> > > =====================================================
> > > nload (board) | ~0 Mbps | ~940 Mbps
> > > -----------------------------------------------------
> > > nload (laptop)| ~940 Mbps | ~940 Mbps
> > > =====================================================
> > >
> > > In the last case the "ifconfig" statistics about RX packets
> > > remain fixed which probably indicates that the incoming traffic
> > > to the board is effectively being dropped.
> > >
> > > The eth0 interrupt counter keeps incrementing.
> > > Simple ping test works correctly.
> > >
> > >
> > > TEST 1: IRQ type patch applied
> > >
> > > Same results as TEST 0.
> > >
> > >
> > > TEST 2: eee-broken-1000t flag removed
> > >
> > > 1) Start packet generator on laptop:
> > >
> > > | incoming traffic | outgoing traffic
> > > =====================================================
> > > nload (board) | ~3Mbps | 0 Mbps
> > > -----------------------------------------------------
> > > nload (laptop)| 0 Mbps | ~940 Mbps
> > > =====================================================
> > >
> > > 2) Start packet generator on board:
> > >
> > > | incoming traffic | outgoing traffic
> > > ==============+===================+==================
> > > nload (board) | ~0 Mbps | ~940 Mbps
> > > --------------+-------------------+------------------
> > > nload (laptop)| ~940 Mbps | ~940 Mbps
> > > =====================================================
> > >
> > > 3) Stop packet generator on laptop:
> > >
> > > | incoming traffic | outgoing traffic
> > > =====================================================
> > > nload (board) | 0 Mbps | ~940 Mbps
> > > -----------------------------------------------------
> > > nload (laptop)| ~940 Mbps | 0 Mbps
> > > =====================================================
> > >
> > > 4) Restart packet generator on laptop:
> > >
> > > | incoming traffic | outgoing traffic
> > > =====================================================
> > > nload (board) | ~0 Mbps | ~940 Mbps
> > > -----------------------------------------------------
> > > nload (laptop)| ~940 Mbps | ~940 Mbps
> > > =====================================================
> > >
> > > In the first case the "ifconfig" statistics about RX packets
> > > are incremented consistently with the incoming traffic value
> > > showed by the nload (board side).
> > >
> > > In the last case the "ifconfig" statistics about RX packets
> > > remain fixed which probably indicates that the incoming traffic
> > > to the board is effectively being dropped.
> > >
> > > The eth0 interrupt counter keeps incrementing.
> > > Simple ping test from laptop to board shows a packet loss
> > > of 90% and more while no packet loss achieved pinging
> > > the laptop from the board.
> > >
> > >
> > > TEST 3: both patches applied.
> > >
> > > Same results as TEST 2.
> > >
> > >
> > > From the results obtained from these tests,
> > > which are more accurate than the previous one,
> > > I can say that the second patch (remove eee-broken-1000t flag)
> > > should NOT be applied.
> > >
> > > About the first one (change MAC IRQ type), I would like
> > > to do other tests with other tools like iperf3.
> > > With these results only, I would say to not apply it
> > > because nothing changed but if your stress test failed on
> > > long running and this patch fix it I would like to test it more deeply.
> > >
> > > As final thought, the conducted tests clearly show that if the board
> > > transmits at full rate, all the incoming traffic is dropped.
> > > I think that this behaviour should be fixed but don't know if
> > > it depends on the driver or device tree description.
> > > I'll keep investigating.
> > >
> > > Regards,
> > >
> > > Emiliano
> > >
> > > On Thu, Dec 06, 2018 at 04:52:28PM +0100, Emiliano Ingrassia wrote:
> > > > Hi Carlo,
> > > >
> > > > thanks for the answer.
> > > >
> > > > On Thu, Dec 06, 2018 at 01:17:58PM +0000, Carlo Caione wrote:
> > > > > On Thu, 2018-12-06 at 13:43 +0100, Emiliano Ingrassia wrote:
> > > > > > Hi all,
> > > > >
> > > > > Hi Emiliano,
> > > > >
> > > > > > thank you for involving me.
> > > > > >
> > > > > > I applied Carlo's patches[0] on a kernel vanilla 4.19.6
> > > > > > and tested it with kernel packet generator, monitoring
> > > > > > bandwidth usage with "nload".
> > > > > >
> > > > > > All tests were conducted on an Odroid-C1+ Rev. 0.4-20150930 board
> > > > > > with a short ethernet cable directly attached to a laptop with
> > > > > > 1G ethernet interface, with "nload" running on the board.
> > > > > >
> > > > > > The tests I performed are composed by the following steps:
> > > > > >
> > > > > > 1) Start packet generator with "rate 1000M" on laptop;
> > > > > >
> > > > > > 2) Keep packet generator active on the laptop and
> > > > > > start the packet generator on the board with "rate 1000M";
> > > > > >
> > > > > > 3) Stop both packet generators;
> > > > > >
> > > > > > 4) Start packet generator on the board;
> > > > > >
> > > > > > 5) Keep packet generator active on the board and
> > > > > > start the packet generator on the laptop.
> > > > >
> > > > > out of curiosity: why do you expect to see something different from
> > > > > point (2)?
> > > > >
> > > >
> > > > I did not expect it indeed, I tried and got different results.
> > > >
> > > > > > Test results without Carlo's patches applied:
> > > > > >
> > > > > > 1) "nload" shows an incoming traffic of ~950Mbps;
> > > > > >
> > > > > > 2) "nload" shows an incoming traffic of ~400Mbps
> > > > > > and an outgoing traffic of ~250Mbps;
> > > > > >
> > > > > > 3) "nload" shows 0Mbps both for incoming and outgoing traffic;
> > > > > >
> > > > > > 4) "nload" shows an outgoing traffic of ~950Mbps from the board;
> > > > > >
> > > > > > 5) "nload" shows incoming traffic of 0Mbps
> > > > > > and an outgoing traffic of ~950Mbps.
> > > > > >
> > > > > > Applying only the first patch (change mac IRQ type) I got the same
> > > > > > results.
> > > > >
> > > > > This is expected. The change in the IRQ type is solving an issue
> > > > > that
> > > > > you can see if the run a stress test involving multiple components
> > > > > for
> > > > > several hours.
> > > > >
> > > >
> > > > OK, did you use "stress-ng" tool for tests?
> > > >
> > > > > > Applying only the second patch (drop eee-broken-1000t) I got the
> > > > > > same
> > > > > > results!
> > > > >
> > > > > I am a bit confused here. Wasn't the eee-broken-1000t added to fix a
> > > > > problem with the ethernet? Are you suggesting that for some reason
> > > > > you
> > > > > cannot reproduce anymore the problem for which the quirk was
> > > > > introduced?
> > > > >
> > > >
> > > > Problems without the "eee-broken-1000t" flags were experimented
> > > > one and a half years ago on a Amlogic development kernel from [0],
> > > > probably a 4.14 version.
> > > > Many patches about Meson8b SoC, dwmac-meson8b and dwmac driver
> > > > were introduced so yes, the "eee-broken-1000t" was added
> > > > to fix a problem with the ethernet (one and a half years ago),
> > > > but new tests are needed to say if it still necessary.
> > > >
> > > > > > With both patches applied I got the same results but with an
> > > > > > incoming
> > > > > > traffic
> > > > > > of ~3Mbps on the board.
> > > > >
> > > > > On all the tests and immediately from the start of the tests?
> > > > >
> > > >
> > > > Yes, in all the 5 steps immediately from the start.
> > > >
> > > > I also tried to execute "nload" on both sides to see the bandwidth
> > > > usage.
> > > >
> > > > With bot patches applied, after starting kernel packet generator
> > > > on my laptop with 1Gbps rate, "nload" on the laptop side shows me
> > > > an outgoing traffic of ~940Mbps while "nload" on the board side shows
> > > > me an incoming traffic of ~3Mbps.
> > > >
> > > > Also consider that a pinging test from my laptop to the board shows
> > > > a packet loss of about 90%.
> > > >
> > > > > When you hit the problem con you check in /proc/interrupts if you
> > > > > see
> > > > > the IRQ counter for the eth0 incrementing or not?
> > > > >
> > > >
> > > > The eth0 IRQ counter is incremented during the test.
> > > >
> > > > > Cheers,
> > > > >
> > > > > --
> > > > > Carlo Caione
> > > > >
> > > > >
> > > >
> > > > I would like to conduct other tests with iperf3 to be sure about
> > > > the obtained results. What do you think?
> > > > Should I apply your patches on the latest Amlogic development kernel?
> > > >
> > > > Regards,
> > > >
> > > > Emiliano
> > > >
> > > > [0]
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic.git/
> > >
> > > Cheers,
> > >
> > > Emiliano
> > >
> > > _______________________________________________
> > > linux-amlogic mailing list
> > > linux-amlogic@lists.infradead.org
> > > http://lists.infradead.org/mailman/listinfo/linux-amlogic
_______________________________________________
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 1/7] mm: mmap: Allow for "high" userspace addresses
From: Andrew Morton @ 2018-12-07 19:56 UTC (permalink / raw)
To: Steve Capper
Cc: suzuki.poulose, catalin.marinas, ard.biesheuvel, will.deacon,
linux-mm, jcm, linux-arm-kernel
In-Reply-To: <20181206225042.11548-2-steve.capper@arm.com>
On Thu, 6 Dec 2018 22:50:36 +0000 Steve Capper <steve.capper@arm.com> wrote:
> This patch adds support for "high" userspace addresses that are
> optionally supported on the system and have to be requested via a hint
> mechanism ("high" addr parameter to mmap).
>
> Architectures such as powerpc and x86 achieve this by making changes to
> their architectural versions of arch_get_unmapped_* functions. However,
> on arm64 we use the generic versions of these functions.
>
> Rather than duplicate the generic arch_get_unmapped_* implementations
> for arm64, this patch instead introduces two architectural helper macros
> and applies them to arch_get_unmapped_*:
> arch_get_mmap_end(addr) - get mmap upper limit depending on addr hint
> arch_get_mmap_base(addr, base) - get mmap_base depending on addr hint
>
> If these macros are not defined in architectural code then they default
> to (TASK_SIZE) and (base) so should not introduce any behavioural
> changes to architectures that do not define them.
>
> Signed-off-by: Steve Capper <steve.capper@arm.com>
> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
Acked-by: Andrew Morton <akpm@linux-foundation.org>
_______________________________________________
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 v2] arm: dts: qcom: msm8998: Fixup clock to use xo_board
From: Stephen Boyd @ 2018-12-07 19:47 UTC (permalink / raw)
To: Andy Gross, linux-arm-msm; +Cc: Andy Gross, linux-arm-kernel, Bjorn Andersson
In-Reply-To: <1544209088-25602-1-git-send-email-andy.gross@linaro.org>
Quoting Andy Gross (2018-12-07 10:58:08)
> This patch sets the msm8998 xo clock name back to xo_board. Recent
> clock tree changes fixed the clock tree and the change to the xo name
> is causing issues where msm8998 boards do not boot properly. Let's
> change it back and leave the xo label on it.
>
> Fixes: 634da3307b08 (arm64: dts: qcom: msm8998: correct xo clock name)
> Signed-off-by: Andy Gross <andy.gross@linaro.org>
> ---
Reviewed-by: Stephen Boyd <sboyd@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [Freedreno] [PATCH] drm/msm/a6xx: Add support for an interconnect path
From: Rob Clark @ 2018-12-07 19:35 UTC (permalink / raw)
To: freedreno, linux-arm-msm, Douglas Anderson, dri-devel,
Linux Kernel Mailing List, Georgi Djakov,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20181207180712.GC20602@jcrouse-lnx.qualcomm.com>
On Fri, Dec 7, 2018 at 1:07 PM Jordan Crouse <jcrouse@codeaurora.org> wrote:
>
> On Fri, Dec 07, 2018 at 10:06:56AM -0700, Jordan Crouse wrote:
> > Try to get the interconnect path for the GPU and vote for the maximum
> > bandwidth to support all frequencies. This is needed for performance.
> > Later we will want to scale the bandwidth based on the frequency to
> > also optimize for power but that will require some device tree
> > infrastructure that does not yet exist.
> >
> > v3: Use macros and change port string per Georgi Djakov
>
> Rob had asked earlier if it would be appropriate and/or possible to merge this
> with the generic interconnect patches and with his blessing I would like to
> renew that request. This should merge cleanly against tip of tree and it would
> be nice to get this support in at the same time that the base patches go in.
>
Acked-by: Rob Clark <robdclark@gmail.com>
for landing this via Georgi's tree.. that seems easier than having to
do a 2nd late pull-req for drm to get the driver parts merged..
BR,
-R
> Jordan
>
> > Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
> > ---
> > drivers/gpu/drm/msm/Kconfig | 1 +
> > drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 20 ++++++++++++++++++++
> > drivers/gpu/drm/msm/adreno/adreno_gpu.c | 9 +++++++++
> > drivers/gpu/drm/msm/msm_gpu.h | 3 +++
> > 4 files changed, 33 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig
> > index 843a9d40c05e..990c4350f0c4 100644
> > --- a/drivers/gpu/drm/msm/Kconfig
> > +++ b/drivers/gpu/drm/msm/Kconfig
> > @@ -5,6 +5,7 @@ config DRM_MSM
> > depends on ARCH_QCOM || (ARM && COMPILE_TEST)
> > depends on OF && COMMON_CLK
> > depends on MMU
> > + depends on INTERCONNECT || !INTERCONNECT
> > select QCOM_MDT_LOADER if ARCH_QCOM
> > select REGULATOR
> > select DRM_KMS_HELPER
> > diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> > index 546599a7ab05..f37a9bfe5c30 100644
> > --- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> > +++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> > @@ -2,6 +2,7 @@
> > /* Copyright (c) 2017-2018 The Linux Foundation. All rights reserved. */
> >
> > #include <linux/clk.h>
> > +#include <linux/interconnect.h>
> > #include <linux/pm_opp.h>
> > #include <soc/qcom/cmd-db.h>
> >
> > @@ -63,6 +64,9 @@ static bool a6xx_gmu_gx_is_on(struct a6xx_gmu *gmu)
> >
> > static void __a6xx_gmu_set_freq(struct a6xx_gmu *gmu, int index)
> > {
> > + struct a6xx_gpu *a6xx_gpu = container_of(gmu, struct a6xx_gpu, gmu);
> > + struct adreno_gpu *adreno_gpu = &a6xx_gpu->base;
> > + struct msm_gpu *gpu = &adreno_gpu->base;
> > int ret;
> >
> > gmu_write(gmu, REG_A6XX_GMU_DCVS_ACK_OPTION, 0);
> > @@ -85,6 +89,12 @@ static void __a6xx_gmu_set_freq(struct a6xx_gmu *gmu, int index)
> > dev_err(gmu->dev, "GMU set GPU frequency error: %d\n", ret);
> >
> > gmu->freq = gmu->gpu_freqs[index];
> > +
> > + /*
> > + * Eventually we will want to scale the path vote with the frequency but
> > + * for now leave it at max so that the performance is nominal.
> > + */
> > + icc_set(gpu->icc_path, 0, MBps_to_icc(7216));
> > }
> >
> > void a6xx_gmu_set_freq(struct msm_gpu *gpu, unsigned long freq)
> > @@ -680,6 +690,8 @@ int a6xx_gmu_reset(struct a6xx_gpu *a6xx_gpu)
> >
> > int a6xx_gmu_resume(struct a6xx_gpu *a6xx_gpu)
> > {
> > + struct adreno_gpu *adreno_gpu = &a6xx_gpu->base;
> > + struct msm_gpu *gpu = &adreno_gpu->base;
> > struct a6xx_gmu *gmu = &a6xx_gpu->gmu;
> > int status, ret;
> >
> > @@ -695,6 +707,9 @@ int a6xx_gmu_resume(struct a6xx_gpu *a6xx_gpu)
> > if (ret)
> > goto out;
> >
> > + /* Set the bus quota to a reasonable value for boot */
> > + icc_set(gpu->icc_path, 0, MBps_to_icc(3072));
> > +
> > a6xx_gmu_irq_enable(gmu);
> >
> > /* Check to see if we are doing a cold or warm boot */
> > @@ -735,6 +750,8 @@ bool a6xx_gmu_isidle(struct a6xx_gmu *gmu)
> >
> > int a6xx_gmu_stop(struct a6xx_gpu *a6xx_gpu)
> > {
> > + struct adreno_gpu *adreno_gpu = &a6xx_gpu->base;
> > + struct msm_gpu *gpu = &adreno_gpu->base;
> > struct a6xx_gmu *gmu = &a6xx_gpu->gmu;
> > u32 val;
> >
> > @@ -781,6 +798,9 @@ int a6xx_gmu_stop(struct a6xx_gpu *a6xx_gpu)
> > /* Tell RPMh to power off the GPU */
> > a6xx_rpmh_stop(gmu);
> >
> > + /* Remove the bus vote */
> > + icc_set(gpu->icc_path, 0, 0);
> > +
> > clk_bulk_disable_unprepare(gmu->nr_clocks, gmu->clocks);
> >
> > pm_runtime_put_sync(gmu->dev);
> > diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> > index 93d70f4a2154..7403ade9aabc 100644
> > --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> > +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> > @@ -18,6 +18,7 @@
> > */
> >
> > #include <linux/ascii85.h>
> > +#include <linux/interconnect.h>
> > #include <linux/kernel.h>
> > #include <linux/pm_opp.h>
> > #include <linux/slab.h>
> > @@ -695,6 +696,11 @@ static int adreno_get_pwrlevels(struct device *dev,
> >
> > DBG("fast_rate=%u, slow_rate=27000000", gpu->fast_rate);
> >
> > + /* Check for an interconnect path for the bus */
> > + gpu->icc_path = of_icc_get(dev, "gfx-mem");
> > + if (IS_ERR(gpu->icc_path))
> > + gpu->icc_path = NULL;
> > +
> > return 0;
> > }
> >
> > @@ -733,10 +739,13 @@ int adreno_gpu_init(struct drm_device *drm, struct platform_device *pdev,
> >
> > void adreno_gpu_cleanup(struct adreno_gpu *adreno_gpu)
> > {
> > + struct msm_gpu *gpu = &adreno_gpu->base;
> > unsigned int i;
> >
> > for (i = 0; i < ARRAY_SIZE(adreno_gpu->info->fw); i++)
> > release_firmware(adreno_gpu->fw[i]);
> >
> > + icc_put(gpu->icc_path);
> > +
> > msm_gpu_cleanup(&adreno_gpu->base);
> > }
> > diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
> > index f82bac086666..12fc5b1cb39d 100644
> > --- a/drivers/gpu/drm/msm/msm_gpu.h
> > +++ b/drivers/gpu/drm/msm/msm_gpu.h
> > @@ -19,6 +19,7 @@
> > #define __MSM_GPU_H__
> >
> > #include <linux/clk.h>
> > +#include <linux/interconnect.h>
> > #include <linux/regulator/consumer.h>
> >
> > #include "msm_drv.h"
> > @@ -119,6 +120,8 @@ struct msm_gpu {
> > struct clk *ebi1_clk, *core_clk, *rbbmtimer_clk;
> > uint32_t fast_rate;
> >
> > + struct icc_path *icc_path;
> > +
> > /* Hang and Inactivity Detection:
> > */
> > #define DRM_MSM_INACTIVE_PERIOD 66 /* in ms (roughly four frames) */
> > --
> > 2.18.0
> >
> > _______________________________________________
> > Freedreno mailing list
> > Freedreno@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/freedreno
>
> --
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL] arm64 fixes for 4.20-rc6
From: Catalin Marinas @ 2018-12-07 18:35 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Will Deacon, linux-kernel, linux-arm-kernel
Hi Linus,
Please pull the arm64 fix below. Thanks.
The following changes since commit 2595646791c319cadfdbf271563aac97d0843dc7:
Linux 4.20-rc5 (2018-12-02 15:07:55 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux tags/arm64-fixes
for you to fetch changes up to b4aecf78083d8c6424657c1746c7c3de6e61669f:
arm64: hibernate: Avoid sending cross-calling with interrupts disabled (2018-12-07 15:52:39 +0000)
----------------------------------------------------------------
- Avoid sending IPIs with interrupts disabled
----------------------------------------------------------------
Will Deacon (1):
arm64: hibernate: Avoid sending cross-calling with interrupts disabled
arch/arm64/kernel/hibernate.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--
Catalin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: OMAP4430 SDP with KS8851: very slow networking
From: Russell King - ARM Linux @ 2018-12-07 19:27 UTC (permalink / raw)
To: Tony Lindgren; +Cc: netdev, Grygorii Strashko, linux-omap, linux-arm-kernel
In-Reply-To: <20181207190312.GT6707@atomide.com>
On Fri, Dec 07, 2018 at 11:03:12AM -0800, Tony Lindgren wrote:
> * Tony Lindgren <tony@atomide.com> [181207 18:14]:
> > Hi,
> >
> > * Russell King - ARM Linux <linux@armlinux.org.uk> [181207 18:01]:
> > > Hi Tony,
> > >
> > > You know most of what's been going on from IRC, but here's the patch
> > > which gets me:
> > >
> > > 1) working interrupts for networking
> > > 2) solves the stuck-wakeup problem
> > >
> > > It also contains some of the debug bits I added.
> >
> > This is excellent news :) Will test today.
>
> Yes your patch seems to work great based on brief testing :)
>
> > > I think what this means is that we should strip out ec0daae685b2
> > > ("gpio: omap: Add level wakeup handling for omap4 based SoCs").
> >
> > Yes the only reason for the wakeup quirk was the stuck wakeup
> > state seen on omap4, it can be just dropped if this works.
> > Adding Grygorii to Cc too.
>
> I'll post a partial revert for commit ec0daae685b2 ("gpio: omap:
> Add level wakeup handling for omap4 based SoCs") shortly.
Hi,
You mentioned that edge mode didn't work as well as level mode on
duovero smsc controller, I think this may help to solve the same
issue but for edge IRQs - we need a mask_ack_irq function to avoid
acking while the edge interrupt is masked. Let me know if that
lowers the smsc ping latency while in edge mode.
Thanks.
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 3d021f648c5d..b1ad6098e894 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -11,7 +11,7 @@
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
-
+#define DEBUG
#include <linux/init.h>
#include <linux/module.h>
#include <linux/interrupt.h>
@@ -366,10 +366,14 @@ static inline void omap_set_gpio_trigger(struct gpio_bank *bank, int gpio,
trigger & IRQ_TYPE_LEVEL_LOW);
omap_gpio_rmw(base, bank->regs->leveldetect1, gpio_bit,
trigger & IRQ_TYPE_LEVEL_HIGH);
+ /*
+ * We need the edge detect enabled for the idle mode detection
+ * to function on OMAP4430.
+ */
omap_gpio_rmw(base, bank->regs->risingdetect, gpio_bit,
- trigger & IRQ_TYPE_EDGE_RISING);
+ trigger & (IRQ_TYPE_EDGE_RISING | IRQ_TYPE_LEVEL_HIGH));
omap_gpio_rmw(base, bank->regs->fallingdetect, gpio_bit,
- trigger & IRQ_TYPE_EDGE_FALLING);
+ trigger & (IRQ_TYPE_EDGE_FALLING | IRQ_TYPE_LEVEL_LOW));
bank->context.leveldetect0 =
readl_relaxed(bank->base + bank->regs->leveldetect0);
@@ -899,6 +903,19 @@ static void omap_gpio_mask_irq(struct irq_data *d)
raw_spin_unlock_irqrestore(&bank->lock, flags);
}
+static void omap_gpio_mask_ack_irq(struct irq_data *d)
+{
+ struct gpio_bank *bank = omap_irq_data_get_bank(d);
+ unsigned offset = d->hwirq;
+ unsigned long flags;
+
+ raw_spin_lock_irqsave(&bank->lock, flags);
+ omap_clear_gpio_irqstatus(bank, offset);
+ omap_set_gpio_irqenable(bank, offset, 0);
+ omap_set_gpio_triggering(bank, offset, IRQ_TYPE_NONE);
+ raw_spin_unlock_irqrestore(&bank->lock, flags);
+}
+
static void omap_gpio_unmask_irq(struct irq_data *d)
{
struct gpio_bank *bank = omap_irq_data_get_bank(d);
@@ -910,14 +927,16 @@ static void omap_gpio_unmask_irq(struct irq_data *d)
if (trigger)
omap_set_gpio_triggering(bank, offset, trigger);
+ omap_set_gpio_irqenable(bank, offset, 1);
+
/* For level-triggered GPIOs, the clearing must be done after
- * the HW source is cleared, thus after the handler has run */
- if (bank->level_mask & BIT(offset)) {
- omap_set_gpio_irqenable(bank, offset, 0);
+ * the HW source is cleared, thus after the handler has run.
+ * OMAP4 needs this done _after_ enabing the interrupt to clear
+ * the wakeup status.
+ */
+ if (bank->level_mask & BIT(offset))
omap_clear_gpio_irqstatus(bank, offset);
- }
- omap_set_gpio_irqenable(bank, offset, 1);
raw_spin_unlock_irqrestore(&bank->lock, flags);
}
@@ -1377,6 +1396,7 @@ static int omap_gpio_probe(struct platform_device *pdev)
irqc->irq_startup = omap_gpio_irq_startup,
irqc->irq_shutdown = omap_gpio_irq_shutdown,
+ irqc->irq_mask_ack = omap_gpio_mask_ack_irq,
irqc->irq_ack = omap_gpio_ack_irq,
irqc->irq_mask = omap_gpio_mask_irq,
irqc->irq_unmask = omap_gpio_unmask_irq,
@@ -1520,6 +1540,10 @@ static void omap_gpio_idle(struct gpio_bank *bank, bool may_lose_context)
struct device *dev = bank->chip.parent;
u32 l1 = 0, l2 = 0;
+ dev_dbg(dev, "%s(): ld 0x%08x 0x%08x we 0x%08x\n", __func__,
+ bank->context.leveldetect0, bank->context.leveldetect1,
+ bank->context.wake_en);
+
if (bank->funcs.idle_enable_level_quirk)
bank->funcs.idle_enable_level_quirk(bank);
@@ -1553,6 +1577,10 @@ static void omap_gpio_idle(struct gpio_bank *bank, bool may_lose_context)
bank->get_context_loss_count(dev);
omap_gpio_dbck_disable(bank);
+
+ dev_dbg(dev, "%s(): ld 0x%08x 0x%08x we 0x%08x\n", __func__,
+ bank->context.leveldetect0, bank->context.leveldetect1,
+ bank->context.wake_en);
}
static void omap_gpio_init_context(struct gpio_bank *p);
@@ -1563,6 +1591,10 @@ static void omap_gpio_unidle(struct gpio_bank *bank)
u32 l = 0, gen, gen0, gen1;
int c;
+ dev_dbg(dev, "%s(): ld 0x%08x 0x%08x we 0x%08x\n", __func__,
+ bank->context.leveldetect0, bank->context.leveldetect1,
+ bank->context.wake_en);
+
/*
* On the first resume during the probe, the context has not
* been initialised and so initialise it now. Also initialise
@@ -1648,6 +1680,10 @@ static void omap_gpio_unidle(struct gpio_bank *bank)
}
bank->workaround_enabled = false;
+
+ dev_dbg(dev, "%s(): ld 0x%08x 0x%08x we 0x%08x\n", __func__,
+ bank->context.leveldetect0, bank->context.leveldetect1,
+ bank->context.wake_en);
}
static void omap_gpio_init_context(struct gpio_bank *p)
@@ -1720,6 +1756,7 @@ static int __maybe_unused omap_gpio_runtime_suspend(struct device *dev)
error = -EBUSY;
goto unlock;
}
+ dev_dbg(dev, "%s()\n", __func__);
omap_gpio_idle(bank, true);
bank->is_suspended = true;
unlock:
@@ -1741,6 +1778,7 @@ static int __maybe_unused omap_gpio_runtime_resume(struct device *dev)
error = -EBUSY;
goto unlock;
}
+ dev_dbg(dev, "%s()\n", __func__);
omap_gpio_unidle(bank);
bank->is_suspended = false;
unlock:
@@ -1827,8 +1865,8 @@ static const struct omap_gpio_platform_data omap4_pdata = {
.regs = &omap4_gpio_regs,
.bank_width = 32,
.dbck_flag = true,
- .quirks = OMAP_GPIO_QUIRK_IDLE_REMOVE_TRIGGER |
- OMAP_GPIO_QUIRK_DEFERRED_WKUP_EN,
+ .quirks = OMAP_GPIO_QUIRK_IDLE_REMOVE_TRIGGER /* |
+ OMAP_GPIO_QUIRK_DEFERRED_WKUP_EN */,
};
static const struct of_device_id omap_gpio_match[] = {
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
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: [PATCH v3 1/9] mm: Introduce new vm_insert_range API
From: Souptick Joarder @ 2018-12-07 19:28 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Michal Hocko, Heiko Stuebner, Peter Zijlstra, dri-devel,
linux-kernel, Linux-MM, linux1394-devel, Marek Szyprowski,
Stephen Rothwell, oleksandr_andrushchenko, joro,
Russell King - ARM Linux, iommu, airlied, linux-arm-kernel,
linux-rockchip, treding, linux-media, Kees Cook, pawel,
Rik van Riel, rppt, Boris Ostrovsky, mchehab, iamjoonsoo.kim,
vbabka, Juergen Gross, hjc, xen-devel, Kyungmin Park, stefanr,
Andrew Morton, robin.murphy, Kirill A. Shutemov
In-Reply-To: <20181207171116.GA29923@bombadil.infradead.org>
On Fri, Dec 7, 2018 at 10:41 PM Matthew Wilcox <willy@infradead.org> wrote:
>
> On Fri, Dec 07, 2018 at 03:34:56PM +0000, Robin Murphy wrote:
> > > +int vm_insert_range(struct vm_area_struct *vma, unsigned long addr,
> > > + struct page **pages, unsigned long page_count)
> > > +{
> > > + unsigned long uaddr = addr;
> > > + int ret = 0, i;
> >
> > Some of the sites being replaced were effectively ensuring that vma and
> > pages were mutually compatible as an initial condition - would it be worth
> > adding something here for robustness, e.g.:
> >
> > + if (page_count != vma_pages(vma))
> > + return -ENXIO;
>
> I think we want to allow this to be used to populate part of a VMA.
> So perhaps:
>
> if (page_count > vma_pages(vma))
> return -ENXIO;
Ok, This can be added.
I think Patch [2/9] is the only leftover place where this
check could be removed.
_______________________________________________
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 v2] arm: dts: qcom: msm8998: Fixup clock to use xo_board
From: Jeffrey Hugo @ 2018-12-07 19:23 UTC (permalink / raw)
To: Andy Gross, linux-arm-msm; +Cc: Stephen Boyd, linux-arm-kernel, Bjorn Andersson
In-Reply-To: <1544209088-25602-1-git-send-email-andy.gross@linaro.org>
On 12/7/2018 11:58 AM, Andy Gross wrote:
> This patch sets the msm8998 xo clock name back to xo_board. Recent
> clock tree changes fixed the clock tree and the change to the xo name
> is causing issues where msm8998 boards do not boot properly. Let's
> change it back and leave the xo label on it.
>
> Fixes: 634da3307b08 (arm64: dts: qcom: msm8998: correct xo clock name)
> Signed-off-by: Andy Gross <andy.gross@linaro.org>
Looks good to me. Seems fine according to a quick test. Feel free to
put on a reviewed-by, acked, or whatever tag you'd like to have from me.
--
Jeffrey Hugo
Qualcomm Datacenter Technologies as an affiliate of Qualcomm
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
_______________________________________________
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 v6 8/8] mfd: axp20x: Add supported cells for AXP803
From: Lee Jones @ 2018-12-07 19:22 UTC (permalink / raw)
To: Vasily Khoruzhick
Cc: Mark Rutland, devicetree, quentin.schulz, linux-pm, Maxime Ripard,
Sebastian Reichel, linux-kernel, Chen-Yu Tsai, Rob Herring,
Oskari Lemmela, arm-linux
In-Reply-To: <CA+E=qVe5gau_9A6WsdqDaEJwdJ7EyQ=UcNu0JJV3v=hKAFU7GQ@mail.gmail.com>
On Fri, 07 Dec 2018, Vasily Khoruzhick wrote:
> On Fri, Dec 7, 2018 at 8:40 AM Lee Jones <lee.jones@linaro.org> wrote:
>
> > My OCD-dar is going crazy.
> >
> > Why haven't you used the same alignment as is already there?
> >
> > If it starts to run over 80-chars then bring the others back.
> >
> > Also why is there a single liner shoved in the middle of the
> > multi-line entries? Please move the singles to the top or the
> > bottom.
>
> Hi Lee,
>
> Could you please reformat it in the way that makes your OCD-dar happy?
> It would be really nice to get
I'm afraid not, for a multitude of reasons.
The most important of which surround testing.
> AC and battery support for APX8x3 merged -- it'll make Pinebook and
> Teres-I pretty well supported by mainline kernel.
That's great. A worthy cause indeed. So I'm sure you guys will want
to turn the patch around in short order so that it's applied in time
for the next merge window.
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
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/3] iio: adc: Allow selection of Exynos ADC on S5PV210
From: Paweł Chmiel @ 2018-12-07 19:11 UTC (permalink / raw)
To: jic23
Cc: mark.rutland, linux-iio, xc-racer2, pmeerw, freeman.liu,
marcus.folkesson, lars, krzk, linux-samsung-soc, kgene, geert,
pawel.mikolaj.chmiel, devicetree, smohanad, vilhelm.gray, robh+dt,
linux-arm-kernel, baolin.wang, rdunlap, arnaud.pouliquen,
linux-kernel, broonie, knaack.h, eugen.hristev
In-Reply-To: <20181207191136.5464-1-pawel.mikolaj.chmiel@gmail.com>
From: Jonathan Bakker <xc-racer2@live.ca>
Make it possible to use Exynos ADC driver on S5PV210 based devices.
Signed-off-by: Jonathan Bakker <xc-racer2@live.ca>
Signed-off-by: Paweł Chmiel <pawel.mikolaj.chmiel@gmail.com>
---
drivers/iio/adc/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index a52fea8749a9..20e126ff030e 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -274,7 +274,7 @@ config EP93XX_ADC
config EXYNOS_ADC
tristate "Exynos ADC driver support"
- depends on ARCH_EXYNOS || ARCH_S3C24XX || ARCH_S3C64XX || (OF && COMPILE_TEST)
+ depends on ARCH_EXYNOS || ARCH_S3C24XX || ARCH_S3C64XX || ARCH_S5PV210 || (OF && COMPILE_TEST)
depends on HAS_IOMEM
help
Core support for the ADC block found in the Samsung EXYNOS series
--
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 related
* [PATCH 1/3] iio: adc: exynos-adc: Add S5PV210 variant
From: Paweł Chmiel @ 2018-12-07 19:11 UTC (permalink / raw)
To: jic23
Cc: mark.rutland, linux-iio, xc-racer2, pmeerw, freeman.liu,
marcus.folkesson, lars, krzk, linux-samsung-soc, kgene, geert,
pawel.mikolaj.chmiel, devicetree, smohanad, vilhelm.gray, robh+dt,
linux-arm-kernel, baolin.wang, rdunlap, arnaud.pouliquen,
linux-kernel, broonie, knaack.h, eugen.hristev
In-Reply-To: <20181207191136.5464-1-pawel.mikolaj.chmiel@gmail.com>
From: Jonathan Bakker <xc-racer2@live.ca>
S5PV210's ADC variant is almost the same as v1 except that it has 10
channels and doesn't require the pmu register
Signed-off-by: Jonathan Bakker <xc-racer2@live.ca>
Signed-off-by: Paweł Chmiel <pawel.mikolaj.chmiel@gmail.com>
---
drivers/iio/adc/exynos_adc.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
index f10443f92e4c..fa2d2b5767f3 100644
--- a/drivers/iio/adc/exynos_adc.c
+++ b/drivers/iio/adc/exynos_adc.c
@@ -115,6 +115,7 @@
#define MAX_ADC_V2_CHANNELS 10
#define MAX_ADC_V1_CHANNELS 8
#define MAX_EXYNOS3250_ADC_CHANNELS 2
+#define MAX_S5PV210_ADC_CHANNELS 10
/* Bit definitions common for ADC_V1 and ADC_V2 */
#define ADC_CON_EN_START (1u << 0)
@@ -282,6 +283,16 @@ static const struct exynos_adc_data exynos_adc_v1_data = {
.start_conv = exynos_adc_v1_start_conv,
};
+static const struct exynos_adc_data exynos_adc_s5pv210_data = {
+ .num_channels = MAX_S5PV210_ADC_CHANNELS,
+ .mask = ADC_DATX_MASK, /* 12 bit ADC resolution */
+
+ .init_hw = exynos_adc_v1_init_hw,
+ .exit_hw = exynos_adc_v1_exit_hw,
+ .clear_irq = exynos_adc_v1_clear_irq,
+ .start_conv = exynos_adc_v1_start_conv,
+};
+
static void exynos_adc_s3c2416_start_conv(struct exynos_adc *info,
unsigned long addr)
{
@@ -478,6 +489,9 @@ static const struct of_device_id exynos_adc_match[] = {
}, {
.compatible = "samsung,s3c6410-adc",
.data = &exynos_adc_s3c64xx_data,
+ }, {
+ .compatible = "samsung,s5pv210-adc",
+ .data = &exynos_adc_s5pv210_data,
}, {
.compatible = "samsung,exynos-adc-v1",
.data = &exynos_adc_v1_data,
--
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 related
* [PATCH 0/3] iio: adc: exynos-adc: Add support for S5PV210
From: Paweł Chmiel @ 2018-12-07 19:11 UTC (permalink / raw)
To: jic23
Cc: mark.rutland, linux-iio, xc-racer2, pmeerw, freeman.liu,
marcus.folkesson, lars, krzk, linux-samsung-soc, kgene, geert,
pawel.mikolaj.chmiel, devicetree, smohanad, vilhelm.gray, robh+dt,
linux-arm-kernel, baolin.wang, rdunlap, arnaud.pouliquen,
linux-kernel, broonie, knaack.h, eugen.hristev
This patchset adds support for S5PV210 adc variant to exynos-adc driver.
Jonathan Bakker (3):
iio: adc: exynos-adc: Add S5PV210 variant
iio: adc: Allow selection of Exynos ADC on S5PV210
dt-bindings: iio: adc: exynos-adc: Add S5PV210 variant
.../bindings/iio/adc/samsung,exynos-adc.txt | 4 +++-
drivers/iio/adc/Kconfig | 2 +-
drivers/iio/adc/exynos_adc.c | 14 ++++++++++++++
3 files changed, 18 insertions(+), 2 deletions(-)
--
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
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