* [PATCH] drm/sun4i: Fix error handling
From: Maxime Ripard @ 2016-11-02 18:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c15282b4-e88a-06b1-527d-96aedce8b7eb@wanadoo.fr>
Hi,
On Sun, Oct 30, 2016 at 12:53:02PM +0100, Christophe JAILLET wrote:
> BTW, memory allocation in 'sun4i_layers_init()' looks spurious, especially
> the use of 'layer' in the for loop.
> Just my 2 cents.
What do you mean by it's spurious?
> I also forgot to say that we could propagate the error code returned by
> sun4i_layers_init instead of returning -EINVAL unconditionally
Indeed. Can you send a patch for that?
Thanks,
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161102/4e98b055/attachment.sig>
^ permalink raw reply
* [PATCH] ARM: DT: stm32: move dma translation to board files
From: Bruno Herrera @ 2016-11-02 18:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFvLkMSViXggGr0Set0qnQan_+bXUNzJx5WtZHP-Jyje=ZzDVw@mail.gmail.com>
On Wed, Nov 2, 2016 at 4:05 PM, Rados?aw Pietrzyk
<radoslaw.pietrzyk@gmail.com> wrote:
> Have you tried with
>
> sdio {
> ...
> compatible = "arm,primecell";
> arm,primecell-periphid = <id_to_define>;
> ...
> }
>
> This should register proper amba device and give it an ID you wish.
I'm using this:
sdio: sdio at 40012c00 {
compatible = "arm,pl18x", "arm,primecell";
arm,primecell-periphid = <0x00480181>;
reg = <0x40012c00 0x400>;
dmas = <&dma2 6 4 0x10400 0x3>, /* Logical - DevToMem */
<&dma2 3 4 0x10400 0x3>; /* Logical - MemToDev */
dma-names = "rx", "tx";
clocks = <&rcc 0 171>;
clock-names = "apb_pclk";
interrupts = <49>;
status = "disabled";
};
And on the driver side I added this:
/* STM32 variants */
{
.id = 0x00480181,
.mask = 0xf0ffffff,
.data = &variant_stm32f4x9,
},
My .id field is the .id from variant_ux500 plus one (and what I
believe is not valid).
And I cannot read the ID from STM32 IP because it always return zero.
Maybe someone from ST(@Alex) can get the real ID. ;)
>
> 2016-11-02 17:07 GMT+01:00 Bruno Herrera <bruherrera@gmail.com>:
>>
>> Hi
>>
>> On Wed, Nov 2, 2016 at 12:32 PM, Alexandre Torgue
>> <alexandre.torgue@st.com> wrote:
>> > Hi
>> >
>> > On 10/31/2016 07:58 PM, Rados?aw Pietrzyk wrote:
>> >>
>> >> I think wlcore driver searches dma-ranges in its parent that's why sdio
>> >> node needs it.
>> >
>> >
>> > Yes I agree. In this case it is needed as you have subnode in sdio node.
>> > So IMO empty dma-ranges could be removed from ethernet and usb node, but
>> > kept in future sdio subnode.
>>
>> Now it is clear.
>>
>> >
>> > Bruno,
>> > Do you plan to push sdio support ?
>>
>> Yes I do, but I'm not sure how long it will take. The I had to
>> change(and hack) the mmci code because I could not get the ID from
>> STM32 SDIO IP.
>> My current WIP is at @
>>
>> https://github.com/mcoquelin-stm32/afboot-stm32/pull/4#issuecomment-247571615
>> I know Andrea Merello is also working on that (and he probably has a
>> more complete patch).
>>
>> >
>> >
>> >
>> >>
>> >> 2016-10-31 17:41 GMT+01:00 Bruno Herrera <bruherrera@gmail.com
>> >> <mailto:bruherrera@gmail.com>>:
>> >>
>> >> On Mon, Oct 31, 2016 at 12:14 PM, Rados?aw Pietrzyk
>> >> <radoslaw.pietrzyk at gmail.com <mailto:radoslaw.pietrzyk@gmail.com>>
>> >> wrote:
>> >> > This is weird because dma ddresses are recalculated using
>> >> parent's
>> >> > dma-ranges property and soc already has it so there should be
>> >> absolutely no
>> >> > problem.
>> >>
>> >> These are my DTS and DTSI file.
>> >> >
>> >> > 2016-10-31 11:27 GMT+01:00 Bruno Herrera <bruherrera@gmail.com
>> >> <mailto:bruherrera@gmail.com>>:
>> >> >>
>> >> >> On Fri, Oct 28, 2016 at 5:09 AM, Rados?aw Pietrzyk
>> >> >> <radoslaw.pietrzyk@gmail.com
>> >> <mailto:radoslaw.pietrzyk@gmail.com>> wrote:
>> >> >> > Have you defined your sdio node within soc node ?
>> >> >>
>> >> >> It is in the SOC node of the DSTI file.
>> >> >>
>> >> >> >
>> >> >> > 2016-10-27 14:57 GMT+02:00 Bruno Herrera <bruherrera@gmail.com
>> >> <mailto:bruherrera@gmail.com>>:
>> >> >> >>
>> >> >> >> Hi Alex,
>> >> >> >>
>> >> >> >> On Thu, Oct 27, 2016 at 10:21 AM, Alexandre Torgue
>> >> >> >> <alexandre.torgue at st.com <mailto:alexandre.torgue@st.com>>
>> >> wrote:
>> >> >> >> > Hi Bruno,
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > On 10/27/2016 12:43 PM, Bruno Herrera wrote:
>> >> >> >> >>
>> >> >> >> >> Hi Alex,
>> >> >> >> >>
>> >> >> >> >> On Wed, Oct 26, 2016 at 7:09 AM, Alexandre Torgue
>> >> >> >> >> <alexandre.torgue at st.com <mailto:alexandre.torgue@st.com>>
>> >> wrote:
>> >> >> >> >>>
>> >> >> >> >>> Hi Bruno,
>> >> >> >> >>>
>> >> >> >> >>> On 10/25/2016 11:06 PM, Bruno Herrera wrote:
>> >> >> >> >>>>
>> >> >> >> >>>>
>> >> >> >> >>>> Hi Alexandre,
>> >> >> >> >>>>
>> >> >> >> >>>>>
>> >> >> >> >>>>> stm32f469-disco and stm32f429-eval boards use SDRAM
>> >> start address
>> >> >> >> >>>>> remapping
>> >> >> >> >>>>> (to @0) to boost performances. A DMA translation
>> >> through
>> >> >> >> >>>>> "dma-ranges"
>> >> >> >> >>>>> property was needed for other masters than the M4 CPU.
>> >> >> >> >>>>> stm32f429-disco doesn't use remapping so doesn't need
>> >> this DMA
>> >> >> >> >>>>> translation.
>> >> >> >> >>>>> This patches moves this DMA translation definition from
>> >> stm32f429
>> >> >> >> >>>>> soc
>> >> >> >> >>>>> file
>> >> >> >> >>>>> to board files.
>> >> >> >> >>>>>
>> >> >> >> >>>>> Signed-off-by: Alexandre TORGUE
>> >> <alexandre.torgue@st.com
>> >> <mailto:alexandre.torgue@st.com>>
>> >>
>> >> >> >> >>>>>
>> >> >> >> >>>>> diff --git a/arch/arm/boot/dts/stm32429i-eval.dts
>> >> >> >> >>>>> b/arch/arm/boot/dts/stm32429i-eval.dts
>> >> >> >> >>>>> index 13c7cd2..a763c15 100644
>> >> >> >> >>>>> --- a/arch/arm/boot/dts/stm32429i-eval.dts
>> >> >> >> >>>>> +++ b/arch/arm/boot/dts/stm32429i-eval.dts
>> >> >> >> >>>>> @@ -82,6 +82,10 @@
>> >> >> >> >>>>> };
>> >> >> >> >>>>> };
>> >> >> >> >>>>>
>> >> >> >> >>>>> + soc {
>> >> >> >> >>>>> + dma-ranges = <0xc0000000 0x0
>> >> 0x10000000>;
>> >> >> >> >>>>> + };
>> >> >> >> >>>>> +
>> >> >> >> >>>>> usbotg_hs_phy: usbphy {
>> >> >> >> >>>>> #phy-cells = <0>;
>> >> >> >> >>>>> compatible = "usb-nop-xceiv";
>> >> >> >> >>>>
>> >> >> >> >>>>
>> >> >> >> >>>>
>> >> >> >> >>>> Shouldn't also the peripheral dma-ranges property move
>> >> to
>> >> board
>> >> >> >> >>>> specific
>> >> >> >> >>>> too?
>> >> >> >> >>>> I had this patch for while but I didn't had the time to
>> >> submit:
>> >> >> >> >>>
>> >> >> >> >>>
>> >> >> >> >>>
>> >> >> >> >>> Well spot I forgot it. Actually, discussing with Arnd
>> >> ysterday on
>> >> >> >> >>> IIRC,
>> >> >> >> >>> empty dma-ranges is not needed. Can you test on your side
>> >> by
>> >> >> >> >>> removing
>> >> >> >> >>> dma-ranges in usb node please ?
>> >> >> >> >>
>> >> >> >> >> Unfortunately will take a time for me to set up this
>> >> environment on
>> >> >> >> >> the STM32F4-EVAL board.
>> >> >> >> >> And on the discovery boards we dont have this scenario.
>> >> That was the
>> >> >> >> >> main reason I did not submit the patch right away.
>> >> >> >> >> My conclusion and I might be wrong but is based on the my
>> >> tests with
>> >> >> >> >> SDIO device at STM32F469I-DISCO board.
>> >> >> >> >>
>> >> >> >> >> I started this issue as discussion at ST Forum but Maxime
>> >> gave me
>> >> >> >> >> the
>> >> >> >> >> hint.
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >>
>> >>
>> >>
>> >> https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=https%3a%2f%2fmy%2est%2ecom%2fpublic%2fSTe2ecommunities%2fmcu%2fLists%2fcortex_mx_stm32%2fDMA2%20and%20SYSCFG_MEMRMP%20relationship&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B¤tviews=44
>> >>
>> >>
>> >> <https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=https%3a%2f%2fmy%2est%2ecom%2fpublic%2fSTe2ecommunities%2fmcu%2fLists%2fcortex_mx_stm32%2fDMA2%20and%20SYSCFG_MEMRMP%20relationship&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B¤tviews=44>
>> >> >> >> >>
>> >> >> >> >>> I will push a v2 by removing empty dma-ranges if tests
>> >> are
>> >> ok in
>> >> >> >> >>> your
>> >> >> >> >>> side.
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >> From my understating/conclusion is: when empty
>> >> property(dma-ranges)
>> >> >> >> >> is
>> >> >> >> >> the device node, the mapping will be taken in
>> >> consideration
>> >> when
>> >> >> >> >> using
>> >> >> >> >> DMA otherwise the mapping is ignored.
>> >> >> >> >> And in the SDIO case it is needed for DEV->MEM(SDRAM) and
>> >> >> >> >> MEM(SDRAM)->DEV. If it is not the case for the devices in
>> >> question
>> >> >> >> >> so
>> >> >> >> >> I suppose it can work without the property.
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > For sure translation has to be done but I'm not sure that
>> >> an
>> >> empty
>> >> >> >> > "dma-ranges" is needed in device node to activate it. For
>> >> Ethernet
>> >> >> >> > empty
>> >> >> >> > "dma-ranges" is not needed. I will try with usb.
>> >> >> >>
>> >> >> >> In the case of SDIO it is needed. As example this is my
>> >> working SDIO
>> >> >> >> node:
>> >> >> >>
>> >> >> >> sdio: sdio at 40012c00 {
>> >> >> >> compatible = "arm,pl18x", "arm,primecell";
>> >> >> >> arm,primecell-periphid = <0x00480181>;
>> >> >> >> reg = <0x40012c00 0x400>;
>> >> >> >> dmas = <&dma2 6 4 0x10400 0x3>, /* Logical - DevToMem */
>> >> >> >> <&dma2 3 4 0x10400 0x3>; /* Logical - MemToDev */
>> >> >> >> dma-names = "rx", "tx";
>> >> >> >> clocks = <&rcc 0 171>;
>> >> >> >> clock-names = "apb_pclk";
>> >> >> >> interrupts = <49>;
>> >> >> >> status = "disabled";
>> >> >> >> };
>> >> >> >>
>> >> >> >> &sdio {
>> >> >> >> status = "okay";
>> >> >> >> vmmc-supply = <&wlan_en>;
>> >> >> >> bus-width = <4>;
>> >> >> >> max-frequency = <24000000>;
>> >> >> >> pinctrl-names = "default";
>> >> >> >> pinctrl-0 = <&sdio_pins>;
>> >> >> >> ti,non-removable;
>> >> >> >> ti,needs-special-hs-handling;
>> >> >> >> dma-ranges;
>> >> >> >> cap-power-off-card;
>> >> >> >> keep-power-in-suspend;
>> >> >> >>
>> >> >> >> #address-cells = <1>;
>> >> >> >> #size-cells = <0>;
>> >> >> >> wlcore: wlcore at 0 {
>> >> >> >> compatible = "ti,wl1835";
>> >> >> >> reg = <2>;
>> >> >> >> interrupt-parent = <&gpioa>;
>> >> >> >> interrupts = <8 IRQ_TYPE_EDGE_RISING>;
>> >> >> >> };
>> >> >> >> };
>> >> >> >>
>> >> >> >> >
>> >> >> >> > alex
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >>
>> >> >> >> >>>
>> >> >> >> >>> Thanks in advance
>> >> >> >> >>> Alex
>> >> >> >> >>>
>> >> >> >> >>>
>> >> >> >> >>>>
>> >> >> >> >>>> Author: Bruno Herrera <bruherrera@gmail.com
>> >> <mailto:bruherrera@gmail.com>>
>> >>
>> >> >> >> >>>> Date: Sun Oct 16 14:50:00 2016 -0200
>> >> >> >> >>>>
>> >> >> >> >>>> ARM: DT: STM32: Use dma-ranges property per board
>> >> not
>> >> at dtsi
>> >> >> >> >>>> file
>> >> >> >> >>>>
>> >> >> >> >>>> diff --git a/arch/arm/boot/dts/stm32429i-eval.dts
>> >> >> >> >>>> b/arch/arm/boot/dts/stm32429i-eval.dts
>> >> >> >> >>>> index 6bfc595..2a22a82 100644
>> >> >> >> >>>> --- a/arch/arm/boot/dts/stm32429i-eval.dts
>> >> >> >> >>>> +++ b/arch/arm/boot/dts/stm32429i-eval.dts
>> >> >> >> >>>> @@ -52,6 +52,10 @@
>> >> >> >> >>>> model = "STMicroelectronics STM32429i-EVAL
>> >> board";
>> >> >> >> >>>> compatible = "st,stm32429i-eval",
>> >> "st,stm32f429";
>> >> >> >> >>>>
>> >> >> >> >>>> + soc {
>> >> >> >> >>>> + dma-ranges = <0xC0000000 0x0
>> >> 0x10000000>;
>> >> >> >> >>>> + };
>> >> >> >> >>>> +
>> >> >> >> >>>> chosen {
>> >> >> >> >>>> bootargs = "root=/dev/ram
>> >> rdinit=/linuxrc";
>> >> >> >> >>>> stdout-path = "serial0:115200n8";
>> >> >> >> >>>> @@ -96,6 +100,7 @@
>> >> >> >> >>>>
>> >> >> >> >>>> ðernet0 {
>> >> >> >> >>>> status = "okay";
>> >> >> >> >>>> + dma-ranges;
>> >> >> >> >>>> pinctrl-0 = <ðernet0_mii>;
>> >> >> >> >>>> pinctrl-names = "default";
>> >> >> >> >>>> phy-mode = "mii-id";
>> >> >> >> >>>> @@ -116,6 +121,7 @@
>> >> >> >> >>>> };
>> >> >> >> >>>>
>> >> >> >> >>>> &usbotg_hs {
>> >> >> >> >>>> + dma-ranges;
>> >> >> >> >>>> dr_mode = "host";
>> >> >> >> >>>> phys = <&usbotg_hs_phy>;
>> >> >> >> >>>> phy-names = "usb2-phy";
>> >> >> >> >>>> diff --git a/arch/arm/boot/dts/stm32f429.dtsi
>> >> >> >> >>>> b/arch/arm/boot/dts/stm32f429.dtsi
>> >> >> >> >>>> index 7d624a2..697a133 100644
>> >> >> >> >>>> --- a/arch/arm/boot/dts/stm32f429.dtsi
>> >> >> >> >>>> +++ b/arch/arm/boot/dts/stm32f429.dtsi
>> >> >> >> >>>> @@ -59,7 +59,6 @@
>> >> >> >> >>>> };
>> >> >> >> >>>>
>> >> >> >> >>>> soc {
>> >> >> >> >>>> - dma-ranges = <0xc0000000 0x0
>> >> 0x10000000>;
>> >> >> >> >>>>
>> >> >> >> >>>> timer2: timer at 40000000 {
>> >> >> >> >>>> compatible = "st,stm32-timer";
>> >> >> >> >>>> @@ -472,13 +471,11 @@
>> >> >> >> >>>> st,syscon = <&syscfg 0x4>;
>> >> >> >> >>>> snps,pbl = <8>;
>> >> >> >> >>>> snps,mixed-burst;
>> >> >> >> >>>> - dma-ranges;
>> >> >> >> >>>> status = "disabled";
>> >> >> >> >>>> };
>> >> >> >> >>>>
>> >> >> >> >>>> usbotg_hs: usb at 40040000 {
>> >> >> >> >>>> compatible = "snps,dwc2";
>> >> >> >> >>>> - dma-ranges;
>> >> >> >> >>>> reg = <0x40040000 0x40000>;
>> >> >> >> >>>> interrupts = <77>;
>> >> >> >> >>>> clocks = <&rcc 0 29>;
>> >> >> >> >>>>
>> >> >> >> >>>>
>> >> >> >> >>>>> diff --git a/arch/arm/boot/dts/stm32f429.dtsi
>> >> >> >> >>>>> b/arch/arm/boot/dts/stm32f429.dtsi
>> >> >> >> >>>>> index 0596d60..3a1cfdd 100644
>> >> >> >> >>>>> --- a/arch/arm/boot/dts/stm32f429.dtsi
>> >> >> >> >>>>> +++ b/arch/arm/boot/dts/stm32f429.dtsi
>> >> >> >> >>>>> @@ -59,8 +59,6 @@
>> >> >> >> >>>>> };
>> >> >> >> >>>>>
>> >> >> >> >>>>> soc {
>> >> >> >> >>>>> - dma-ranges = <0xc0000000 0x0
>> >> 0x10000000>;
>> >> >> >> >>>>> -
>> >> >> >> >>>>> timer2: timer at 40000000 {
>> >> >> >> >>>>> compatible = "st,stm32-timer";
>> >> >> >> >>>>> reg = <0x40000000 0x400>;
>> >> >> >> >>>>> diff --git a/arch/arm/boot/dts/stm32f469-disco.dts
>> >> >> >> >>>>> b/arch/arm/boot/dts/stm32f469-disco.dts
>> >> >> >> >>>>> index 9e73656..c2213c0 100644
>> >> >> >> >>>>> --- a/arch/arm/boot/dts/stm32f469-disco.dts
>> >> >> >> >>>>> +++ b/arch/arm/boot/dts/stm32f469-disco.dts
>> >> >> >> >>>>> @@ -64,6 +64,10 @@
>> >> >> >> >>>>> aliases {
>> >> >> >> >>>>> serial0 = &usart3;
>> >> >> >> >>>>> };
>> >> >> >> >>>>> +
>> >> >> >> >>>>> + soc {
>> >> >> >> >>>>> + dma-ranges = <0xc0000000 0x0
>> >> 0x10000000>;
>> >> >> >> >>>>> + };
>> >> >> >> >>>>> };
>> >> >> >> >>>>>
>> >> >> >> >>>>> &clk_hse {
>> >> >> >> >>>>> --
>> >> >> >> >>>>
>> >> >> >> >>>>
>> >> >> >> >>>>
>> >> >> >> >>>>
>> >> >> >> >>>> Br.,
>> >> >> >> >>>> Bruno
>> >> >> >> >>>>
>> >> >> >> >>>
>> >> >> >> >
>> >> >> >>
>> >> >> >> _______________________________________________
>> >> >> >> linux-arm-kernel mailing list
>> >> >> >> linux-arm-kernel at lists.infradead.org
>> >> <mailto:linux-arm-kernel@lists.infradead.org>
>> >> >> >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>> >> <http://lists.infradead.org/mailman/listinfo/linux-arm-kernel>
>> >> >> >
>> >> >> >
>> >> >
>> >> >
>> >>
>> >>
>> >
>
>
^ permalink raw reply
* [PATCH v7 RESEND 1/2] ASoC: samsung: Add DT bindings documentation for TM2 sound subsystem
From: Krzysztof Kozlowski @ 2016-11-02 18:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478102558-12524-1-git-send-email-s.nawrocki@samsung.com>
On Wed, Nov 02, 2016 at 05:02:37PM +0100, Sylwester Nawrocki wrote:
> This patch adds DT binding documentation for Exnos5433 based TM2
> and TM2E boards sound subsystem.
>
> Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
> Acked-by: Rob Herring <robh@kernel.org>
> ---
> Changes since v5:
> - none.
>
> Changes since v4:
> - indentation changes.
>
> Changes since v2:
> - none.
>
> Changes since initial version:
> - dropped clocks, clock-names properties, instead properties from
> the CODEC node will be used,
> - property renames: 'samsung,model' -> 'model', 'samsung,i2s-controller'
> -> 'i2s-controller', 'samsung,speaker-amplifier' -> 'audio-amplifier',
> - added 'audio-codec' property.
> ---
> .../bindings/sound/samsung,tm2-audio.txt | 38 ++++++++++++++++++++++
> 1 file changed, 38 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/sound/samsung,tm2-audio.txt
>
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] ARM: DT: stm32: move dma translation to board files
From: Bruno Herrera @ 2016-11-02 18:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <edf05ad5-924d-87d8-fd8d-57e8e0a72052@st.com>
On Wed, Nov 2, 2016 at 2:14 PM, Alexandre Torgue
<alexandre.torgue@st.com> wrote:
>
>
> On 11/02/2016 05:07 PM, Bruno Herrera wrote:
>>
>> Hi
>>
>> On Wed, Nov 2, 2016 at 12:32 PM, Alexandre Torgue
>> <alexandre.torgue@st.com> wrote:
>>>
>>> Hi
>>>
>>> On 10/31/2016 07:58 PM, Rados?aw Pietrzyk wrote:
>>>>
>>>>
>>>> I think wlcore driver searches dma-ranges in its parent that's why sdio
>>>> node needs it.
>>>
>>>
>>>
>>> Yes I agree. In this case it is needed as you have subnode in sdio node.
>>> So IMO empty dma-ranges could be removed from ethernet and usb node, but
>>> kept in future sdio subnode.
>>
>>
>> Now it is clear.
>
> Nice. Can I add your tested-by ?
>
Sure
>>
>>>
>>> Bruno,
>>> Do you plan to push sdio support ?
>>
>>
>> Yes I do, but I'm not sure how long it will take. The I had to
>> change(and hack) the mmci code because I could not get the ID from
>> STM32 SDIO IP.
>> My current WIP is at @
>>
>> https://github.com/mcoquelin-stm32/afboot-stm32/pull/4#issuecomment-247571615
>> I know Andrea Merello is also working on that (and he probably has a
>> more complete patch).
>>
>>>
>>>
>>>
>>>>
>>>> 2016-10-31 17:41 GMT+01:00 Bruno Herrera <bruherrera@gmail.com
>>>> <mailto:bruherrera@gmail.com>>:
>>>>
>>>> On Mon, Oct 31, 2016 at 12:14 PM, Rados?aw Pietrzyk
>>>> <radoslaw.pietrzyk at gmail.com <mailto:radoslaw.pietrzyk@gmail.com>>
>>>> wrote:
>>>> > This is weird because dma ddresses are recalculated using parent's
>>>> > dma-ranges property and soc already has it so there should be
>>>> absolutely no
>>>> > problem.
>>>>
>>>> These are my DTS and DTSI file.
>>>> >
>>>> > 2016-10-31 11:27 GMT+01:00 Bruno Herrera <bruherrera@gmail.com
>>>> <mailto:bruherrera@gmail.com>>:
>>>> >>
>>>> >> On Fri, Oct 28, 2016 at 5:09 AM, Rados?aw Pietrzyk
>>>> >> <radoslaw.pietrzyk@gmail.com
>>>> <mailto:radoslaw.pietrzyk@gmail.com>> wrote:
>>>> >> > Have you defined your sdio node within soc node ?
>>>> >>
>>>> >> It is in the SOC node of the DSTI file.
>>>> >>
>>>> >> >
>>>> >> > 2016-10-27 14:57 GMT+02:00 Bruno Herrera <bruherrera@gmail.com
>>>> <mailto:bruherrera@gmail.com>>:
>>>> >> >>
>>>> >> >> Hi Alex,
>>>> >> >>
>>>> >> >> On Thu, Oct 27, 2016 at 10:21 AM, Alexandre Torgue
>>>> >> >> <alexandre.torgue at st.com <mailto:alexandre.torgue@st.com>>
>>>> wrote:
>>>> >> >> > Hi Bruno,
>>>> >> >> >
>>>> >> >> >
>>>> >> >> > On 10/27/2016 12:43 PM, Bruno Herrera wrote:
>>>> >> >> >>
>>>> >> >> >> Hi Alex,
>>>> >> >> >>
>>>> >> >> >> On Wed, Oct 26, 2016 at 7:09 AM, Alexandre Torgue
>>>> >> >> >> <alexandre.torgue at st.com <mailto:alexandre.torgue@st.com>>
>>>> wrote:
>>>> >> >> >>>
>>>> >> >> >>> Hi Bruno,
>>>> >> >> >>>
>>>> >> >> >>> On 10/25/2016 11:06 PM, Bruno Herrera wrote:
>>>> >> >> >>>>
>>>> >> >> >>>>
>>>> >> >> >>>> Hi Alexandre,
>>>> >> >> >>>>
>>>> >> >> >>>>>
>>>> >> >> >>>>> stm32f469-disco and stm32f429-eval boards use SDRAM
>>>> start address
>>>> >> >> >>>>> remapping
>>>> >> >> >>>>> (to @0) to boost performances. A DMA translation through
>>>> >> >> >>>>> "dma-ranges"
>>>> >> >> >>>>> property was needed for other masters than the M4 CPU.
>>>> >> >> >>>>> stm32f429-disco doesn't use remapping so doesn't need
>>>> this DMA
>>>> >> >> >>>>> translation.
>>>> >> >> >>>>> This patches moves this DMA translation definition from
>>>> stm32f429
>>>> >> >> >>>>> soc
>>>> >> >> >>>>> file
>>>> >> >> >>>>> to board files.
>>>> >> >> >>>>>
>>>> >> >> >>>>> Signed-off-by: Alexandre TORGUE <alexandre.torgue@st.com
>>>> <mailto:alexandre.torgue@st.com>>
>>>>
>>>> >> >> >>>>>
>>>> >> >> >>>>> diff --git a/arch/arm/boot/dts/stm32429i-eval.dts
>>>> >> >> >>>>> b/arch/arm/boot/dts/stm32429i-eval.dts
>>>> >> >> >>>>> index 13c7cd2..a763c15 100644
>>>> >> >> >>>>> --- a/arch/arm/boot/dts/stm32429i-eval.dts
>>>> >> >> >>>>> +++ b/arch/arm/boot/dts/stm32429i-eval.dts
>>>> >> >> >>>>> @@ -82,6 +82,10 @@
>>>> >> >> >>>>> };
>>>> >> >> >>>>> };
>>>> >> >> >>>>>
>>>> >> >> >>>>> + soc {
>>>> >> >> >>>>> + dma-ranges = <0xc0000000 0x0
>>>> 0x10000000>;
>>>> >> >> >>>>> + };
>>>> >> >> >>>>> +
>>>> >> >> >>>>> usbotg_hs_phy: usbphy {
>>>> >> >> >>>>> #phy-cells = <0>;
>>>> >> >> >>>>> compatible = "usb-nop-xceiv";
>>>> >> >> >>>>
>>>> >> >> >>>>
>>>> >> >> >>>>
>>>> >> >> >>>> Shouldn't also the peripheral dma-ranges property move to
>>>> board
>>>> >> >> >>>> specific
>>>> >> >> >>>> too?
>>>> >> >> >>>> I had this patch for while but I didn't had the time to
>>>> submit:
>>>> >> >> >>>
>>>> >> >> >>>
>>>> >> >> >>>
>>>> >> >> >>> Well spot I forgot it. Actually, discussing with Arnd
>>>> ysterday on
>>>> >> >> >>> IIRC,
>>>> >> >> >>> empty dma-ranges is not needed. Can you test on your side
>>>> by
>>>> >> >> >>> removing
>>>> >> >> >>> dma-ranges in usb node please ?
>>>> >> >> >>
>>>> >> >> >> Unfortunately will take a time for me to set up this
>>>> environment on
>>>> >> >> >> the STM32F4-EVAL board.
>>>> >> >> >> And on the discovery boards we dont have this scenario.
>>>> That was the
>>>> >> >> >> main reason I did not submit the patch right away.
>>>> >> >> >> My conclusion and I might be wrong but is based on the my
>>>> tests with
>>>> >> >> >> SDIO device at STM32F469I-DISCO board.
>>>> >> >> >>
>>>> >> >> >> I started this issue as discussion at ST Forum but Maxime
>>>> gave me
>>>> >> >> >> the
>>>> >> >> >> hint.
>>>> >> >> >>
>>>> >> >> >>
>>>> >> >> >>
>>>> >> >> >>
>>>> >> >> >>
>>>>
>>>>
>>>> https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=https%3a%2f%2fmy%2est%2ecom%2fpublic%2fSTe2ecommunities%2fmcu%2fLists%2fcortex_mx_stm32%2fDMA2%20and%20SYSCFG_MEMRMP%20relationship&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B¤tviews=44
>>>>
>>>>
>>>> <https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=https%3a%2f%2fmy%2est%2ecom%2fpublic%2fSTe2ecommunities%2fmcu%2fLists%2fcortex_mx_stm32%2fDMA2%20and%20SYSCFG_MEMRMP%20relationship&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B¤tviews=44>
>>>> >> >> >>
>>>> >> >> >>> I will push a v2 by removing empty dma-ranges if tests are
>>>> ok in
>>>> >> >> >>> your
>>>> >> >> >>> side.
>>>> >> >> >>
>>>> >> >> >>
>>>> >> >> >> From my understating/conclusion is: when empty
>>>> property(dma-ranges)
>>>> >> >> >> is
>>>> >> >> >> the device node, the mapping will be taken in consideration
>>>> when
>>>> >> >> >> using
>>>> >> >> >> DMA otherwise the mapping is ignored.
>>>> >> >> >> And in the SDIO case it is needed for DEV->MEM(SDRAM) and
>>>> >> >> >> MEM(SDRAM)->DEV. If it is not the case for the devices in
>>>> question
>>>> >> >> >> so
>>>> >> >> >> I suppose it can work without the property.
>>>> >> >> >
>>>> >> >> >
>>>> >> >> > For sure translation has to be done but I'm not sure that an
>>>> empty
>>>> >> >> > "dma-ranges" is needed in device node to activate it. For
>>>> Ethernet
>>>> >> >> > empty
>>>> >> >> > "dma-ranges" is not needed. I will try with usb.
>>>> >> >>
>>>> >> >> In the case of SDIO it is needed. As example this is my
>>>> working SDIO
>>>> >> >> node:
>>>> >> >>
>>>> >> >> sdio: sdio at 40012c00 {
>>>> >> >> compatible = "arm,pl18x", "arm,primecell";
>>>> >> >> arm,primecell-periphid = <0x00480181>;
>>>> >> >> reg = <0x40012c00 0x400>;
>>>> >> >> dmas = <&dma2 6 4 0x10400 0x3>, /* Logical - DevToMem */
>>>> >> >> <&dma2 3 4 0x10400 0x3>; /* Logical - MemToDev */
>>>> >> >> dma-names = "rx", "tx";
>>>> >> >> clocks = <&rcc 0 171>;
>>>> >> >> clock-names = "apb_pclk";
>>>> >> >> interrupts = <49>;
>>>> >> >> status = "disabled";
>>>> >> >> };
>>>> >> >>
>>>> >> >> &sdio {
>>>> >> >> status = "okay";
>>>> >> >> vmmc-supply = <&wlan_en>;
>>>> >> >> bus-width = <4>;
>>>> >> >> max-frequency = <24000000>;
>>>> >> >> pinctrl-names = "default";
>>>> >> >> pinctrl-0 = <&sdio_pins>;
>>>> >> >> ti,non-removable;
>>>> >> >> ti,needs-special-hs-handling;
>>>> >> >> dma-ranges;
>>>> >> >> cap-power-off-card;
>>>> >> >> keep-power-in-suspend;
>>>> >> >>
>>>> >> >> #address-cells = <1>;
>>>> >> >> #size-cells = <0>;
>>>> >> >> wlcore: wlcore at 0 {
>>>> >> >> compatible = "ti,wl1835";
>>>> >> >> reg = <2>;
>>>> >> >> interrupt-parent = <&gpioa>;
>>>> >> >> interrupts = <8 IRQ_TYPE_EDGE_RISING>;
>>>> >> >> };
>>>> >> >> };
>>>> >> >>
>>>> >> >> >
>>>> >> >> > alex
>>>> >> >> >
>>>> >> >> >
>>>> >> >> >>
>>>> >> >> >>>
>>>> >> >> >>> Thanks in advance
>>>> >> >> >>> Alex
>>>> >> >> >>>
>>>> >> >> >>>
>>>> >> >> >>>>
>>>> >> >> >>>> Author: Bruno Herrera <bruherrera@gmail.com
>>>> <mailto:bruherrera@gmail.com>>
>>>>
>>>> >> >> >>>> Date: Sun Oct 16 14:50:00 2016 -0200
>>>> >> >> >>>>
>>>> >> >> >>>> ARM: DT: STM32: Use dma-ranges property per board not
>>>> at dtsi
>>>> >> >> >>>> file
>>>> >> >> >>>>
>>>> >> >> >>>> diff --git a/arch/arm/boot/dts/stm32429i-eval.dts
>>>> >> >> >>>> b/arch/arm/boot/dts/stm32429i-eval.dts
>>>> >> >> >>>> index 6bfc595..2a22a82 100644
>>>> >> >> >>>> --- a/arch/arm/boot/dts/stm32429i-eval.dts
>>>> >> >> >>>> +++ b/arch/arm/boot/dts/stm32429i-eval.dts
>>>> >> >> >>>> @@ -52,6 +52,10 @@
>>>> >> >> >>>> model = "STMicroelectronics STM32429i-EVAL
>>>> board";
>>>> >> >> >>>> compatible = "st,stm32429i-eval", "st,stm32f429";
>>>> >> >> >>>>
>>>> >> >> >>>> + soc {
>>>> >> >> >>>> + dma-ranges = <0xC0000000 0x0 0x10000000>;
>>>> >> >> >>>> + };
>>>> >> >> >>>> +
>>>> >> >> >>>> chosen {
>>>> >> >> >>>> bootargs = "root=/dev/ram
>>>> rdinit=/linuxrc";
>>>> >> >> >>>> stdout-path = "serial0:115200n8";
>>>> >> >> >>>> @@ -96,6 +100,7 @@
>>>> >> >> >>>>
>>>> >> >> >>>> ðernet0 {
>>>> >> >> >>>> status = "okay";
>>>> >> >> >>>> + dma-ranges;
>>>> >> >> >>>> pinctrl-0 = <ðernet0_mii>;
>>>> >> >> >>>> pinctrl-names = "default";
>>>> >> >> >>>> phy-mode = "mii-id";
>>>> >> >> >>>> @@ -116,6 +121,7 @@
>>>> >> >> >>>> };
>>>> >> >> >>>>
>>>> >> >> >>>> &usbotg_hs {
>>>> >> >> >>>> + dma-ranges;
>>>> >> >> >>>> dr_mode = "host";
>>>> >> >> >>>> phys = <&usbotg_hs_phy>;
>>>> >> >> >>>> phy-names = "usb2-phy";
>>>> >> >> >>>> diff --git a/arch/arm/boot/dts/stm32f429.dtsi
>>>> >> >> >>>> b/arch/arm/boot/dts/stm32f429.dtsi
>>>> >> >> >>>> index 7d624a2..697a133 100644
>>>> >> >> >>>> --- a/arch/arm/boot/dts/stm32f429.dtsi
>>>> >> >> >>>> +++ b/arch/arm/boot/dts/stm32f429.dtsi
>>>> >> >> >>>> @@ -59,7 +59,6 @@
>>>> >> >> >>>> };
>>>> >> >> >>>>
>>>> >> >> >>>> soc {
>>>> >> >> >>>> - dma-ranges = <0xc0000000 0x0 0x10000000>;
>>>> >> >> >>>>
>>>> >> >> >>>> timer2: timer at 40000000 {
>>>> >> >> >>>> compatible = "st,stm32-timer";
>>>> >> >> >>>> @@ -472,13 +471,11 @@
>>>> >> >> >>>> st,syscon = <&syscfg 0x4>;
>>>> >> >> >>>> snps,pbl = <8>;
>>>> >> >> >>>> snps,mixed-burst;
>>>> >> >> >>>> - dma-ranges;
>>>> >> >> >>>> status = "disabled";
>>>> >> >> >>>> };
>>>> >> >> >>>>
>>>> >> >> >>>> usbotg_hs: usb at 40040000 {
>>>> >> >> >>>> compatible = "snps,dwc2";
>>>> >> >> >>>> - dma-ranges;
>>>> >> >> >>>> reg = <0x40040000 0x40000>;
>>>> >> >> >>>> interrupts = <77>;
>>>> >> >> >>>> clocks = <&rcc 0 29>;
>>>> >> >> >>>>
>>>> >> >> >>>>
>>>> >> >> >>>>> diff --git a/arch/arm/boot/dts/stm32f429.dtsi
>>>> >> >> >>>>> b/arch/arm/boot/dts/stm32f429.dtsi
>>>> >> >> >>>>> index 0596d60..3a1cfdd 100644
>>>> >> >> >>>>> --- a/arch/arm/boot/dts/stm32f429.dtsi
>>>> >> >> >>>>> +++ b/arch/arm/boot/dts/stm32f429.dtsi
>>>> >> >> >>>>> @@ -59,8 +59,6 @@
>>>> >> >> >>>>> };
>>>> >> >> >>>>>
>>>> >> >> >>>>> soc {
>>>> >> >> >>>>> - dma-ranges = <0xc0000000 0x0
>>>> 0x10000000>;
>>>> >> >> >>>>> -
>>>> >> >> >>>>> timer2: timer at 40000000 {
>>>> >> >> >>>>> compatible = "st,stm32-timer";
>>>> >> >> >>>>> reg = <0x40000000 0x400>;
>>>> >> >> >>>>> diff --git a/arch/arm/boot/dts/stm32f469-disco.dts
>>>> >> >> >>>>> b/arch/arm/boot/dts/stm32f469-disco.dts
>>>> >> >> >>>>> index 9e73656..c2213c0 100644
>>>> >> >> >>>>> --- a/arch/arm/boot/dts/stm32f469-disco.dts
>>>> >> >> >>>>> +++ b/arch/arm/boot/dts/stm32f469-disco.dts
>>>> >> >> >>>>> @@ -64,6 +64,10 @@
>>>> >> >> >>>>> aliases {
>>>> >> >> >>>>> serial0 = &usart3;
>>>> >> >> >>>>> };
>>>> >> >> >>>>> +
>>>> >> >> >>>>> + soc {
>>>> >> >> >>>>> + dma-ranges = <0xc0000000 0x0
>>>> 0x10000000>;
>>>> >> >> >>>>> + };
>>>> >> >> >>>>> };
>>>> >> >> >>>>>
>>>> >> >> >>>>> &clk_hse {
>>>> >> >> >>>>> --
>>>> >> >> >>>>
>>>> >> >> >>>>
>>>> >> >> >>>>
>>>> >> >> >>>>
>>>> >> >> >>>> Br.,
>>>> >> >> >>>> Bruno
>>>> >> >> >>>>
>>>> >> >> >>>
>>>> >> >> >
>>>> >> >>
>>>> >> >> _______________________________________________
>>>> >> >> linux-arm-kernel mailing list
>>>> >> >> linux-arm-kernel at lists.infradead.org
>>>> <mailto:linux-arm-kernel@lists.infradead.org>
>>>> >> >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>>> <http://lists.infradead.org/mailman/listinfo/linux-arm-kernel>
>>>> >> >
>>>> >> >
>>>> >
>>>> >
>>>>
>>>>
>>>
>
^ permalink raw reply
* [PATCH v2 2/4] ARM: dts: sun8i: Add SPI controller node in H3
From: Maxime Ripard @ 2016-11-02 18:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161028065412.23008-3-woogyom.kim@gmail.com>
1;4600;0c
On Fri, Oct 28, 2016 at 03:54:10PM +0900, Milo Kim wrote:
> H3 SPI subsystem is almost same as A31 SPI except buffer size, so those
> DT properties are reusable.
>
> Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
> Cc: Chen-Yu Tsai <wens@csie.org>
> Signed-off-by: Milo Kim <woogyom.kim@gmail.com>
Applied both, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161102/ea817932/attachment.sig>
^ permalink raw reply
* [PATCH v5 3/7] net: phy: broadcom: Add BCM54810 PHY entry
From: Andrew Lunn @ 2016-11-02 18:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478106488-11779-4-git-send-email-jon.mason@broadcom.com>
On Wed, Nov 02, 2016 at 01:08:04PM -0400, Jon Mason wrote:
> The BCM54810 PHY requires some semi-unique configuration, which results
> in some additional configuration in addition to the standard config.
> Also, some users of the BCM54810 require the PHY lanes to be swapped.
> Since there is no way to detect this, add a device tree query to see if
> it is applicable.
>
> Inspired-by: Vikas Soni <vsoni@broadcom.com>
> Signed-off-by: Jon Mason <jon.mason@broadcom.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* [PATCH] drm/sun4i: Add a few formats
From: Maxime Ripard @ 2016-11-02 18:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v65SqkU-7W4+JnnnF+RzJO_0-TRq+DykJRf9og1wGc4azQ@mail.gmail.com>
On Sat, Oct 29, 2016 at 06:25:46PM +0800, Chen-Yu Tsai wrote:
> On Thu, Oct 27, 2016 at 10:35 PM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
> > Hi,
> >
> > On Tue, Oct 25, 2016 at 08:42:26AM +0800, Chen-Yu Tsai wrote:
> >> On Mon, Oct 24, 2016 at 10:40 PM, Maxime Ripard
> >> <maxime.ripard@free-electrons.com> wrote:
> >> > Hi,
> >> >
> >> > On Fri, Oct 21, 2016 at 11:15:32AM +0800, Chen-Yu Tsai wrote:
> >> >> On Tue, Oct 18, 2016 at 4:46 PM, Maxime Ripard
> >> >> <maxime.ripard@free-electrons.com> wrote:
> >> >> > The planes can do more than what was previously exposed. Add support for
> >> >> > them.
> >> >> >
> >> >> > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> >> >> > ---
> >> >> > drivers/gpu/drm/sun4i/sun4i_backend.c | 20 ++++++++++++++++++++
> >> >> > drivers/gpu/drm/sun4i/sun4i_layer.c | 6 ++++++
> >> >> > 2 files changed, 26 insertions(+)
> >> >> >
> >> >> > diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c b/drivers/gpu/drm/sun4i/sun4i_backend.c
> >> >> > index afb7ddf660ef..b184a476a480 100644
> >> >> > --- a/drivers/gpu/drm/sun4i/sun4i_backend.c
> >> >> > +++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
> >> >> > @@ -96,6 +96,22 @@ static int sun4i_backend_drm_format_to_layer(struct drm_plane *plane,
> >> >> > *mode = SUN4I_BACKEND_LAY_FBFMT_ARGB8888;
> >> >> > break;
> >> >> >
> >> >> > + case DRM_FORMAT_ARGB4444:
> >> >> > + *mode = SUN4I_BACKEND_LAY_FBFMT_ARGB4444;
> >> >> > + break;
> >> >> > +
> >> >> > + case DRM_FORMAT_ARGB1555:
> >> >> > + *mode = SUN4I_BACKEND_LAY_FBFMT_ARGB1555;
> >> >> > + break;
> >> >> > +
> >> >> > + case DRM_FORMAT_RGBA5551:
> >> >> > + *mode = SUN4I_BACKEND_LAY_FBFMT_RGBA5551;
> >> >> > + break;
> >> >> > +
> >> >> > + case DRM_FORMAT_RGBA4444:
> >> >> > + *mode = SUN4I_BACKEND_LAY_FBFMT_RGBA4444;
> >> >>
> >> >> The A20 manual only lists ARGB4444, not RGBA4444. There might be
> >> >> some discrepancy here. We can deal with them
> >> >
> >> > Hmm, yes, that's weird. But I guess this would be part of porting it
> >> > to the A20.
> >> >
> >> >> Also there are some more formats missing from the list, could you
> >> >> add them as well?
> >> >
> >> > Which one do you refer to?
> >>
> >> RGB556 and RGB655.
> >
> > These formats are not supported by Linux yet though.
>
> I see. Sorry for the noise.
>
> Acked-by: Chen-Yu Tsai <wens@csie.org>
Applied with a more verbose commit log.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161102/5e496141/attachment.sig>
^ permalink raw reply
* [PATCH v1] ARM:dmaengine:sun6i:fix the uninitialized value for v_lli
From: Maxime Ripard @ 2016-11-02 18:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161102053112.GA8109@arx-xi>
On Wed, Nov 02, 2016 at 01:31:12PM +0800, Axl-zhang wrote:
> dma_pool_alloc does not initialize the value of the newly allocated
> block for the v_lli, and the uninitilize value make the tests failed
> which is on pine64 with dmatest.
> we can fix it just change the "|=" to "=" for the v_lli->cfg.
>
> Signed-off-by: Hao Zhang <hao5781286@gmail.com>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161102/9194dd7d/attachment.sig>
^ permalink raw reply
* [PATCH] iommu: arm-smmu: Set SMTNMB_TLBEN in ACR to enable caching of bypass entries
From: Nipun Gupta @ 2016-11-02 19:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d1c89f6f-1b7a-6180-a376-27505d3b6c9f@arm.com>
Hi Robin,
> -----Original Message-----
> From: Robin Murphy [mailto:robin.murphy at arm.com]
> Sent: Wednesday, November 02, 2016 16:51
> To: Nipun Gupta <nipun.gupta@nxp.com>; will.deacon at arm.com; linux-arm-
> kernel at lists.infradead.org; iommu at lists.linux-foundation.org
> Cc: Stuart Yoder <stuart.yoder@nxp.com>
> Subject: Re: [PATCH] iommu: arm-smmu: Set SMTNMB_TLBEN in ACR to enable
> caching of bypass entries
>
> Hi Nipun,
>
> On 02/11/16 13:35, Nipun Gupta wrote:
> > The SMTNMB_TLBEN in the Auxiliary Configuration Register (ACR)
> > provides an option to enable the updation of TLB in case of bypass
> > transactions due to no stream match in the stream match table. This
> > reduces the latencies of the subsequent transactions with the same stream-id
> which bypasses the SMMU.
> > This provides a significant performance benefit for certain networking
> > workloads.
>
> ...at the cost of increased TLB contention against other workloads.
> However, in the general case we'd expect the system to be fully described, so if
> there aren't any unmatched Stream IDs there hopefully shouldn't be an impact
> to leaving this switched on. I'd be interested to see some actual performance
> numbers, though - you already know my opinion about unsubstantiated quotes
> from the MMU-500 TRM.
With this change we have seen substantial performance improvement of ~9-10%
with DPDK l3fwd application (http://dpdk.org/doc/guides/sample_app_ug/l3_forward.html)
on NXP's LS2088a platform (single core as well as multi-core). Also, with ODP reflector application
(loopback mode - NXP in-house) we have seen 5% improvement in performance on
LS1088 platform.
W.r.t. the read latencies, they are reduced to avg. ~50 platform cycles from avg. ~140
platform cycles per memory read transactions which follow this bypass path (on LS2088
with DPDK l3fwd application).
(Apologies, I cannot share the DPDK/ODP exact performance numbers on the mailing list).
>
> > Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
> > ---
> > drivers/iommu/arm-smmu.c | 21 +++++++++++++++------
> > 1 file changed, 15 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c index
> > ce2a9d4..7010a5c 100644
> > --- a/drivers/iommu/arm-smmu.c
> > +++ b/drivers/iommu/arm-smmu.c
> > @@ -246,6 +246,7 @@ enum arm_smmu_s2cr_privcfg {
> >
> > #define ARM_MMU500_ACTLR_CPRE (1 << 1)
> >
> > +#define ACR_SMTNMB_TLBEN (1 << 8)
>
> ACR is entirely implementation-defined, so there are no generic field names.
> Please follow the naming convention handily demonstrated in the subsequent
> context line.
>
> > #define ARM_MMU500_ACR_CACHE_LOCK (1 << 26)
>
> Actually, can we also please keep these in descending order of bit position like
> everything else?
>
> > #define CB_PAR_F (1 << 0)
> > @@ -1569,18 +1570,26 @@ static void arm_smmu_device_reset(struct
> arm_smmu_device *smmu)
> > for (i = 0; i < smmu->num_mapping_groups; ++i)
> > arm_smmu_write_sme(smmu, i);
> >
> > + /* Get the major rev required for configuring ACR */
>
> That comment is nonsense.
>
> > + reg = readl_relaxed(gr0_base + ARM_SMMU_GR0_ID7);
> > + major = (reg >> ID7_MAJOR_SHIFT) & ID7_MAJOR_MASK;
> > +
> > /*
> > * Before clearing ARM_MMU500_ACTLR_CPRE, need to
> > * clear CACHE_LOCK bit of ACR first. And, CACHE_LOCK
> > * bit is only present in MMU-500r2 onwards.
> > */
> > - reg = readl_relaxed(gr0_base + ARM_SMMU_GR0_ID7);
> > - major = (reg >> ID7_MAJOR_SHIFT) & ID7_MAJOR_MASK;
> > - if ((smmu->model == ARM_MMU500) && (major >= 2)) {
> > - reg = readl_relaxed(gr0_base + ARM_SMMU_GR0_sACR);
> > + reg = readl_relaxed(gr0_base + ARM_SMMU_GR0_sACR);
> > + if ((smmu->model == ARM_MMU500) && (major >= 2))
> > reg &= ~ARM_MMU500_ACR_CACHE_LOCK;
> > - writel_relaxed(reg, gr0_base + ARM_SMMU_GR0_sACR);
> > - }
> > +
> > + /*
> > + * Set the SMTNMB_TLBEN in ACR so that the transactions which
> > + * bypass with SMMU due to no stream match found in the SMR table
> > + * are updated in the TLB's.
>
> Or simply, e.g. "Allow unmatched Stream IDs to allocate bypass TLB entries for
> reduced latency". It's already clear from the code what bit's being set where, we
> only need to remember *why*.
>
> > + */
> > + reg |= ACR_SMTNMB_TLBEN;
> > + writel_relaxed(reg, gr0_base + ARM_SMMU_GR0_sACR);
>
> Are you sure it's perfectly fine to set that implementation-defined bit on any
> SMMU implementation other than the two-and-a-half ARM Ltd. ones which
> happen to share the same meaning? I'm certainly not.
>
> The correct flow would be something like this:
>
> if (smmu->model == ARM_MMU500) {
> reg = readl_relaxed(gr0_base + ARM_SMMU_GR0_ID7);
> major = (reg >> ID7_MAJOR_SHIFT) & ID7_MAJOR_MASK;
> reg = readl_relaxed(gr0_base + ARM_SMMU_GR0_sACR);
> if (major >= 2)
> reg &= ~ARM_MMU500_ACR_CACHE_LOCK;
> reg |= ACR_SMTNMB_TLBEN;
> writel_relaxed(reg, gr0_base + ARM_SMMU_GR0_sACR);
> }
>
> The shape of the current code avoids an extra level of indentation, but once you
> have to have the nested conditional anyway, it might as well all be predicated
> appropriately.
>
Thank you for providing the useful comments. I would incorporate them all in next version :).
Regards,
Nipun
> Robin.
>
> > /* Make sure all context banks are disabled and clear CB_FSR */
> > for (i = 0; i < smmu->num_context_banks; ++i) {
> >
^ permalink raw reply
* [PATCH v5 4/7] Documentation: devicetree: net: add NS2 bindings to amac
From: Sergei Shtylyov @ 2016-11-02 19:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161102172456.GA11881@broadcom.com>
On 11/02/2016 08:24 PM, Jon Mason wrote:
>>> Clean-up the documentation to the bgmac-amac driver, per suggestion by
>>> Rob Herring, and add details for NS2 support.
>>>
>>> Signed-off-by: Jon Mason <jon.mason@broadcom.com>
>>> ---
>>> Documentation/devicetree/bindings/net/brcm,amac.txt | 16 +++++++++++-----
>>> 1 file changed, 11 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/net/brcm,amac.txt b/Documentation/devicetree/bindings/net/brcm,amac.txt
>>> index ba5ecc1..2fefa1a 100644
>>> --- a/Documentation/devicetree/bindings/net/brcm,amac.txt
>>> +++ b/Documentation/devicetree/bindings/net/brcm,amac.txt
>>> @@ -2,11 +2,17 @@ Broadcom AMAC Ethernet Controller Device Tree Bindings
>>> -------------------------------------------------------------
>>>
>>> Required properties:
>>> - - compatible: "brcm,amac" or "brcm,nsp-amac"
>>> - - reg: Address and length of the GMAC registers,
>>> - Address and length of the GMAC IDM registers
>>> - - reg-names: Names of the registers. Must have both "amac_base" and
>>> - "idm_base"
>>> + - compatible: "brcm,amac"
>>> + "brcm,nsp-amac"
>>> + "brcm,ns2-amac"
>>> + - reg: Address and length of the register set for the device. It
>>> + contains the information of registers in the same order as
>>> + described by reg-names
>>> + - reg-names: Names of the registers.
>>> + "amac_base": Address and length of the GMAC registers
>>> + "idm_base": Address and length of the GMAC IDM registers
>>> + "nicpm_base": Address and length of the NIC Port Manager
>>> + registers (required for Northstar2)
>>
>> Why this "_base" suffix? It looks redundant...
>
> Yes. Rob Herring pointed out the same thing. It is ugly, but follows
> the existing binding.
Sorry, I didn't realize you're reformatting the existing bindings while
adding some new text...
> Thanks,
> Jon
MBR, Sergei
^ permalink raw reply
* [RFC][PATCH] arm64: Add support for CONFIG_DEBUG_VIRTUAL
From: Laura Abbott @ 2016-11-02 20:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu8GjehaCrKv2CQbPRg_r6mK3vtFnsuHAJyDkS2n8STEkA@mail.gmail.com>
On 10/29/2016 02:39 AM, Ard Biesheuvel wrote:
> On 28 October 2016 at 23:07, Laura Abbott <labbott@redhat.com> wrote:
>>>>> diff --git a/arch/arm64/mm/physaddr.c b/arch/arm64/mm/physaddr.c
>>>>> new file mode 100644
>>>>> index 0000000..6c271e2
>>>>> --- /dev/null
>>>>> +++ b/arch/arm64/mm/physaddr.c
>>>>> @@ -0,0 +1,17 @@
>>>>> +#include <linux/mm.h>
>>>>> +
>>>>> +#include <asm/memory.h>
>>>>> +
>>>>> +unsigned long __virt_to_phys(unsigned long x)
>>>>> +{
>>>>> + phys_addr_t __x = (phys_addr_t)x;
>>>>> +
>>>>> + if (__x & BIT(VA_BITS - 1)) {
>>>>> + /* The bit check ensures this is the right range */
>>>>> + return (__x & ~PAGE_OFFSET) + PHYS_OFFSET;
>>>>> + } else {
>>>>> + VIRTUAL_BUG_ON(x < kimage_vaddr || x > (unsigned long)_end);
>>>>
>>>>
>>>> IIUC, in (3) you were asking if the last check should be '>' or '>='?
>>>>
>>>> To match high_memory, I suspect the latter, as _end doesn't fall within
>>>> the mapped virtual address space.
>>>>
>>>
>>> I was actually concerned about if _end would be correct with KASLR.
>>> Ard confirmed that it gets fixed up to be correct. I'll change the
>>> check to check for >=.
>>>
>>
>> While testing this, I found two places with __pa(_end) to get bounds,
>> one in arm64 code and one in memblock code. x86 gets away with this
>> because memblock is actually __pa_symbol and x86 does image placement
>> different and can check against the maximum image size. I think
>> including _end in __pa_symbol but excluding it from the generic
>> __virt_to_phys makes sense. It's a bit nicer than doing _end - 1 +
>> 1 everywhere.
>>
>
> Could we redefine __pa_symbol() under CONFIG_DEBUG_VIRTUAL to
> something that checks (x >= kimage_vaddr + TEXT_OFFSET || x <=
> (unsigned long)_end), i.e., reject linear virtual addresses? (Assuming
> my understanding of the meaning of __pa_symbol() is correct)
>
Yes, that's going to be my approach. I originally prototyped this
with just x >= kimage_vaddr but kimage_vaddr + TEXT_OFFSET is
a tighter bound.
Thanks,
Laura
^ permalink raw reply
* [RFC PATCH v2 1/1] PCI/ACPI: xgene: Add ECAM quirk for X-Gene PCIe controller
From: Duc Dang @ 2016-11-02 20:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161102165329.GB10528@bhelgaas-glaptop.roam.corp.google.com>
On Wed, Nov 2, 2016 at 9:53 AM, Bjorn Helgaas <helgaas@kernel.org> wrote:
>
> Hi Duc,
>
> On Tue, Oct 25, 2016 at 06:24:32PM -0700, Duc Dang wrote:
> > PCIe controllers in X-Gene SoCs is not ECAM compliant: software
> > needs to configure additional controller's register to address
> > device at bus:dev:function.
> >
> > This patch depends on "ECAM quirks handling for ARM64 platforms"
> > series (http://www.spinics.net/lists/arm-kernel/msg530692.html,
> > the series was also modified by Bjorn) to address the limitation
> > above for X-Gene PCIe controller.
> >
> > The quirk will only be applied for X-Gene PCIe MCFG table with
> > OEM revison 1, 2, 3 or 4 (PCIe controller v1 and v2 on X-Gene SoCs).
>
> The quirks here contain some hard-coded address space consumed by
> ECAM. The ECAM quirk itself is not a generic description of that
> address space in the sense of a PCI BAR or an ACPI _CRS method, i.e.,
> the quirk description is not enough to keep other parts of the kernel
> from treating the address space as "available".
Your concern here is the controller register region that I declared as
hard-coded array of resource (xgene_vx_csr_res) is not owned by the
root bridge? So unlike DT case where kernel discovers and knows
exactly who owns this resource (and we can also use
platform_get_resource to get the resource); in ACPI case with ECAM
quirk, kernel knows who requests this resource but does not know who
owns it? Do I understand correctly?
>
> Can you add a note here in the changelog about how you are describing
> this space generically? The standard solution is a PNP0C02 device
> with _CRS that describes it.
>
> It would be ideal if you could open a bugzilla at bugzilla.kernel.org
> and attach there a dmesg log, /proc/iomem contents, and DSDT. This
> would show both the generic PNP0C02 piece and the ECAM quirk piece.
We don't have PNP0C02 device in our ACPI Table. Do you want me add a
PNP0C02 device into our firmware and check/document the difference in
/proc/iomem output?
>
> BTW, I did refresh and re-push the pci/ecam-v6 branch where I'm
> collecting this stuff, so if you want to rebase your patch on top of
> that and test it, that would be great.
Thanks, I will definitely do that.
>
> > Signed-off-by: Duc Dang <dhdang@apm.com>
> > ---
> > v2 changes:
> > 1. Get rid of pci-xgene-ecam.c file and fold quirk code into pci-xgene.c
> > 2. Redefine fixup array for X-Gene
> > 3. Use devm_ioremap_resource to map csr_base
> >
> > drivers/acpi/pci_mcfg.c | 30 ++++++++
> > drivers/pci/host/pci-xgene.c | 165 ++++++++++++++++++++++++++++++++++++++++++-
> > include/linux/pci-ecam.h | 5 ++
> > 3 files changed, 197 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
> > index bb2c508..9dfc937 100644
> > --- a/drivers/acpi/pci_mcfg.c
> > +++ b/drivers/acpi/pci_mcfg.c
> > @@ -96,6 +96,36 @@ struct mcfg_fixup {
> > THUNDER_ECAM_MCFG(2, 12),
> > THUNDER_ECAM_MCFG(2, 13),
> > #endif
> > +#ifdef CONFIG_PCI_XGENE
> > +#define XGENE_V1_ECAM_MCFG(rev, seg) \
> > + {"APM ", "XGENE ", rev, seg, MCFG_BUS_ANY, \
> > + &xgene_v1_pcie_ecam_ops }
> > +#define XGENE_V2_1_ECAM_MCFG(rev, seg) \
> > + {"APM ", "XGENE ", rev, seg, MCFG_BUS_ANY, \
> > + &xgene_v2_1_pcie_ecam_ops }
> > +#define XGENE_V2_2_ECAM_MCFG(rev, seg) \
> > + {"APM ", "XGENE ", rev, seg, MCFG_BUS_ANY, \
> > + &xgene_v2_2_pcie_ecam_ops }
> > +
> > + /* X-Gene SoC with v1 PCIe controller */
> > + XGENE_V1_ECAM_MCFG(1, 0),
> > + XGENE_V1_ECAM_MCFG(1, 1),
> > + XGENE_V1_ECAM_MCFG(1, 2),
> > + XGENE_V1_ECAM_MCFG(1, 3),
> > + XGENE_V1_ECAM_MCFG(1, 4),
> > + XGENE_V1_ECAM_MCFG(2, 0),
> > + XGENE_V1_ECAM_MCFG(2, 1),
> > + XGENE_V1_ECAM_MCFG(2, 2),
> > + XGENE_V1_ECAM_MCFG(2, 3),
> > + XGENE_V1_ECAM_MCFG(2, 4),
> > + /* X-Gene SoC with v2.1 PCIe controller */
> > + XGENE_V2_1_ECAM_MCFG(3, 0),
> > + XGENE_V2_1_ECAM_MCFG(3, 1),
> > + /* X-Gene SoC with v2.2 PCIe controller */
> > + XGENE_V2_2_ECAM_MCFG(4, 0),
> > + XGENE_V2_2_ECAM_MCFG(4, 1),
> > + XGENE_V2_2_ECAM_MCFG(4, 2),
> > +#endif
> > };
> >
> > static char mcfg_oem_id[ACPI_OEM_ID_SIZE];
> > diff --git a/drivers/pci/host/pci-xgene.c b/drivers/pci/host/pci-xgene.c
> > index 1de23d7..d6aa642 100644
> > --- a/drivers/pci/host/pci-xgene.c
> > +++ b/drivers/pci/host/pci-xgene.c
> > @@ -27,6 +27,8 @@
> > #include <linux/of_irq.h>
> > #include <linux/of_pci.h>
> > #include <linux/pci.h>
> > +#include <linux/pci-acpi.h>
> > +#include <linux/pci-ecam.h>
> > #include <linux/platform_device.h>
> > #include <linux/slab.h>
> >
> > @@ -64,6 +66,7 @@
> > /* PCIe IP version */
> > #define XGENE_PCIE_IP_VER_UNKN 0
> > #define XGENE_PCIE_IP_VER_1 1
> > +#define XGENE_PCIE_IP_VER_2 2
> >
> > struct xgene_pcie_port {
> > struct device_node *node;
> > @@ -97,7 +100,15 @@ static inline u32 pcie_bar_low_val(u32 addr, u32 flags)
> > */
> > static void __iomem *xgene_pcie_get_cfg_base(struct pci_bus *bus)
> > {
> > - struct xgene_pcie_port *port = bus->sysdata;
> > + struct pci_config_window *cfg;
> > + struct xgene_pcie_port *port;
> > +
> > + if (acpi_disabled)
> > + port = bus->sysdata;
> > + else {
> > + cfg = bus->sysdata;
> > + port = cfg->priv;
> > + }
> >
> > if (bus->number >= (bus->primary + 1))
> > return port->cfg_base + AXI_EP_CFG_ACCESS;
> > @@ -111,10 +122,18 @@ static void __iomem *xgene_pcie_get_cfg_base(struct pci_bus *bus)
> > */
> > static void xgene_pcie_set_rtdid_reg(struct pci_bus *bus, uint devfn)
> > {
> > - struct xgene_pcie_port *port = bus->sysdata;
> > + struct pci_config_window *cfg;
> > + struct xgene_pcie_port *port;
> > unsigned int b, d, f;
> > u32 rtdid_val = 0;
> >
> > + if (acpi_disabled)
> > + port = bus->sysdata;
> > + else {
> > + cfg = bus->sysdata;
> > + port = cfg->priv;
> > + }
> > +
> > b = bus->number;
> > d = PCI_SLOT(devfn);
> > f = PCI_FUNC(devfn);
> > @@ -158,7 +177,15 @@ static void __iomem *xgene_pcie_map_bus(struct pci_bus *bus, unsigned int devfn,
> > static int xgene_pcie_config_read32(struct pci_bus *bus, unsigned int devfn,
> > int where, int size, u32 *val)
> > {
> > - struct xgene_pcie_port *port = bus->sysdata;
> > + struct pci_config_window *cfg;
> > + struct xgene_pcie_port *port;
> > +
> > + if (acpi_disabled)
> > + port = bus->sysdata;
> > + else {
> > + cfg = bus->sysdata;
> > + port = cfg->priv;
> > + }
> >
> > if (pci_generic_config_read32(bus, devfn, where & ~0x3, 4, val) !=
> > PCIBIOS_SUCCESSFUL)
> > @@ -189,6 +216,138 @@ static int xgene_pcie_config_read32(struct pci_bus *bus, unsigned int devfn,
> > .write = pci_generic_config_write32,
> > };
> >
> > +#ifdef CONFIG_ACPI
> > +static struct resource xgene_v1_csr_res[] = {
> > + [0] = DEFINE_RES_MEM(0x1f2b0000UL, SZ_64K),
> > + [1] = DEFINE_RES_MEM(0x1f2c0000UL, SZ_64K),
> > + [2] = DEFINE_RES_MEM(0x1f2d0000UL, SZ_64K),
> > + [3] = DEFINE_RES_MEM(0x1f500000UL, SZ_64K),
> > + [4] = DEFINE_RES_MEM(0x1f510000UL, SZ_64K),
> > +};
> > +
> > +static int xgene_v1_pcie_ecam_init(struct pci_config_window *cfg)
> > +{
> > + struct acpi_device *adev = to_acpi_device(cfg->parent);
> > + struct acpi_pci_root *root = acpi_driver_data(adev);
> > + struct device *dev = cfg->parent;
> > + struct xgene_pcie_port *port;
> > + struct resource *csr;
> > +
> > + port = devm_kzalloc(dev, sizeof(*port), GFP_KERNEL);
> > + if (!port)
> > + return -ENOMEM;
> > +
> > + csr = &xgene_v1_csr_res[root->segment];
> > + port->csr_base = devm_ioremap_resource(dev, csr);
> > + if (IS_ERR(port->csr_base)) {
> > + kfree(port);
> > + return -ENOMEM;
> > + }
> > +
> > + port->cfg_base = cfg->win;
> > + port->version = XGENE_PCIE_IP_VER_1;
> > +
> > + cfg->priv = port;
> > +
> > + return 0;
> > +}
> > +
> > +struct pci_ecam_ops xgene_v1_pcie_ecam_ops = {
> > + .bus_shift = 16,
> > + .init = xgene_v1_pcie_ecam_init,
> > + .pci_ops = {
> > + .map_bus = xgene_pcie_map_bus,
> > + .read = xgene_pcie_config_read32,
> > + .write = pci_generic_config_write,
> > + }
> > +};
> > +
> > +static struct resource xgene_v2_1_csr_res[] = {
> > + [0] = DEFINE_RES_MEM(0x1f2b0000UL, SZ_64K),
> > + [1] = DEFINE_RES_MEM(0x1f2c0000UL, SZ_64K),
> > +};
> > +
> > +static int xgene_v2_1_pcie_ecam_init(struct pci_config_window *cfg)
> > +{
> > + struct acpi_device *adev = to_acpi_device(cfg->parent);
> > + struct acpi_pci_root *root = acpi_driver_data(adev);
> > + struct device *dev = cfg->parent;
> > + struct xgene_pcie_port *port;
> > + struct resource *csr;
> > +
> > + port = devm_kzalloc(dev, sizeof(*port), GFP_KERNEL);
> > + if (!port)
> > + return -ENOMEM;
> > +
> > + csr = &xgene_v2_1_csr_res[root->segment];
> > + port->csr_base = devm_ioremap_resource(dev, csr);
> > + if (IS_ERR(port->csr_base)) {
> > + kfree(port);
> > + return -ENOMEM;
> > + }
> > +
> > + port->cfg_base = cfg->win;
> > + port->version = XGENE_PCIE_IP_VER_2;
> > +
> > + cfg->priv = port;
> > +
> > + return 0;
> > +}
> > +
> > +struct pci_ecam_ops xgene_v2_1_pcie_ecam_ops = {
> > + .bus_shift = 16,
> > + .init = xgene_v2_1_pcie_ecam_init,
> > + .pci_ops = {
> > + .map_bus = xgene_pcie_map_bus,
> > + .read = xgene_pcie_config_read32,
> > + .write = pci_generic_config_write,
> > + }
> > +};
> > +
> > +static struct resource xgene_v2_2_csr_res[] = {
> > + [0] = DEFINE_RES_MEM(0x1f2b0000UL, SZ_64K),
> > + [1] = DEFINE_RES_MEM(0x1f500000UL, SZ_64K),
> > + [2] = DEFINE_RES_MEM(0x1f2d0000UL, SZ_64K),
> > +};
> > +
> > +static int xgene_v2_2_pcie_ecam_init(struct pci_config_window *cfg)
> > +{
> > + struct acpi_device *adev = to_acpi_device(cfg->parent);
> > + struct acpi_pci_root *root = acpi_driver_data(adev);
> > + struct device *dev = cfg->parent;
> > + struct xgene_pcie_port *port;
> > + struct resource *csr;
> > +
> > + port = devm_kzalloc(dev, sizeof(*port), GFP_KERNEL);
> > + if (!port)
> > + return -ENOMEM;
> > +
> > + csr = &xgene_v2_2_csr_res[root->segment];
> > + port->csr_base = devm_ioremap_resource(dev, csr);
> > + if (IS_ERR(port->csr_base)) {
> > + kfree(port);
> > + return -ENOMEM;
> > + }
> > +
> > + port->cfg_base = cfg->win;
> > + port->version = XGENE_PCIE_IP_VER_2;
> > +
> > + cfg->priv = port;
> > +
> > + return 0;
> > +}
> > +
> > +struct pci_ecam_ops xgene_v2_2_pcie_ecam_ops = {
> > + .bus_shift = 16,
> > + .init = xgene_v2_2_pcie_ecam_init,
> > + .pci_ops = {
> > + .map_bus = xgene_pcie_map_bus,
> > + .read = xgene_pcie_config_read32,
> > + .write = pci_generic_config_write,
> > + }
> > +};
> > +#endif
> > +
> > static u64 xgene_pcie_set_ib_mask(struct xgene_pcie_port *port, u32 addr,
> > u32 flags, u64 size)
> > {
> > diff --git a/include/linux/pci-ecam.h b/include/linux/pci-ecam.h
> > index 35f0e81..40da3e7 100644
> > --- a/include/linux/pci-ecam.h
> > +++ b/include/linux/pci-ecam.h
> > @@ -65,6 +65,11 @@ void __iomem *pci_ecam_map_bus(struct pci_bus *bus, unsigned int devfn,
> > #ifdef CONFIG_PCI_HOST_THUNDER_ECAM
> > extern struct pci_ecam_ops pci_thunder_ecam_ops;
> > #endif
> > +#ifdef CONFIG_PCI_XGENE
> > +extern struct pci_ecam_ops xgene_v1_pcie_ecam_ops;
> > +extern struct pci_ecam_ops xgene_v2_1_pcie_ecam_ops;
> > +extern struct pci_ecam_ops xgene_v2_2_pcie_ecam_ops;
> > +#endif
> >
> > #ifdef CONFIG_PCI_HOST_GENERIC
> > /* for DT-based PCI controllers that support ECAM */
> > --
> > 1.9.1
> >
Regards,
Duc Dang.
^ permalink raw reply
* [PATCH 1/1] KVM: ARM64: Fix the issues when PMCCFILTR is configured
From: Wei Huang @ 2016-11-02 20:55 UTC (permalink / raw)
To: linux-arm-kernel
KVM calls kvm_pmu_set_counter_event_type() when PMCCFILTR is configured.
But this function can't deals with PMCCFILTR correctly because the evtCount
bit of PMCCFILTR, which is reserved 0, conflits with the SW_INCR event
type of other PMXEVTYPER<n> registers. To fix it, when eventsel == 0, KVM
shouldn't return immediately, but instead it needs to check further if
select_idx is ARMV8_PMU_CYCLE_IDX.
Another issue is that KVM shouldn't copy the eventsel bits of PMCCFILTER
directly to attr.config. Istead it shoudl convert the request to
perf_event of type 0x11 (i.e. the "cpu cycle" event type).
Signed-off-by: Wei Huang <wei@redhat.com>
---
virt/kvm/arm/pmu.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
index 6e9c40e..13cc812 100644
--- a/virt/kvm/arm/pmu.c
+++ b/virt/kvm/arm/pmu.c
@@ -379,7 +379,8 @@ void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
eventsel = data & ARMV8_PMU_EVTYPE_EVENT;
/* Software increment event does't need to be backed by a perf event */
- if (eventsel == ARMV8_PMU_EVTYPE_EVENT_SW_INCR)
+ if (eventsel == ARMV8_PMU_EVTYPE_EVENT_SW_INCR &&
+ select_idx != ARMV8_PMU_CYCLE_IDX)
return;
memset(&attr, 0, sizeof(struct perf_event_attr));
@@ -391,7 +392,7 @@ void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
attr.exclude_kernel = data & ARMV8_PMU_EXCLUDE_EL1 ? 1 : 0;
attr.exclude_hv = 1; /* Don't count EL2 events */
attr.exclude_host = 1; /* Don't count host events */
- attr.config = eventsel;
+ attr.config = (select_idx == ARMV8_PMU_CYCLE_IDX) ? 0x011 : eventsel;
counter = kvm_pmu_get_counter_value(vcpu, select_idx);
/* The initial sample period (overflow count) of an event. */
--
2.7.4
^ permalink raw reply related
* Use of GICv3/ITS with PCIe host-generic driver - resizing ITS MAPD?
From: Marc Zyngier @ 2016-11-02 20:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CY1PR07MB2506C9B4133B1CE185AD0260D8A00@CY1PR07MB2506.namprd07.prod.outlook.com>
On Wed, Nov 02 2016 at 09:36:14 AM, Alan Douglas <adouglas@cadence.com> wrote:
> Hi Marc,
>
>> > When setting up bus 0, the ITS device is created, and
>> > its_build_map_cmd() sets the size of the ITS MAPD based on the number
>> > of interrupts claimed by bus 0. When subsequent buses are enumerated,
>> > the ITS device will be reused, however we do not increase the number
>> > of supported interrupts to allow for the additional interrupts claimed
>> > by the additional devices being enumerated. (This can be seen in
>> > its_msi_prepare(), which is called for each device which has MSI/MSI-X
>> > enabled, and will reuse an existing ITS. )
>>
>> Am I right in understanding that all the PCIe devices in your system end-up
>> aliasing to the same RequesterID? If so, that's a major issue. The ITS is
>> designed so that each device exposes its *own* RID, and have its own
>> Interrupt Translation Table (ITT).
>>
>> In your case, you seem to first discover the root port, which is not upstream
>> of anything, so it doesn't alias with anything at that point. We allocate the
>> corresponding ITT, and it's all fine. Until we start probing the rest, and ugly
>> things happen.
>>
> Yes, your understanding is correct. I will dig into this a bit
> further to see what is wrong then send an update. I suspect my DTS
> msi mapping.
Right. That would explain a lot of what you're seeing. In general, and
unless you have some funky remapping going on, you're better off having
a very straightforward msi-map property in your RC node (such as example
#1 in Documentation/devicetree/bindings/pci/pci-msi.txt).
Thanks,
M.
--
Jazz is not dead. It just smells funny.
^ permalink raw reply
* [PATCHv2 0/6] CONFIG_DEBUG_VIRTUAL for arm64
From: Laura Abbott @ 2016-11-02 21:00 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
This is v2 of the series to add CONFIG_DEBUG_VIRTUAL support from arm64. This
has been split out into a number of patches:
Patch #1 Adds ARCH_HAS_DEBUG_VIRTUAL to avoid the need for adding arch
dependencies for DEBUG_VIRTUAL. This touches arch/x86/Kconfig
Patch #2 Cleans up cma to not rely on __pa_nodebug and have an #ifdef inline
in the function.
Patch #3 Adjust some macros in arm64 memory.h to be under __ASSEMBLY__
protection
Patch #4 Adds a cast for virt_to_pfn since __virt_to_phys for DEBUG_VIRTUAL no
longer has a cast.
Patch #5 Switches to using __pa_symbol for _end to avoid erroneously triggering
a bounds error with the debugging.
Patch #6 is the actual implementation of DEBUG_VIRTUAL. The biggest change from
the RFCv1 is the addition of __phys_addr_symbol. This is to handle several
places where the physical address of _end is needed. x86 avoids this problem by
doing its bounds check based on the entire possible image space which is well
beyond where _end would end up.
There are a few dependencies outside of arm64, so I don't know if
it will be easier for this to eventually go through arm64 or the mm tree.
Thanks,
Laura
Laura Abbott (6):
lib/Kconfig.debug: Add ARCH_HAS_DEBUG_VIRTUAL
mm/cma: Cleanup highmem check
arm64: Move some macros under #ifndef __ASSEMBLY__
arm64: Add cast for virt_to_pfn
arm64: Use __pa_symbol for _end
arm64: Add support for CONFIG_DEBUG_VIRTUAL
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm/memory.h | 50 ++++++++++++++++++++++++-----------------
arch/arm64/mm/Makefile | 2 ++
arch/arm64/mm/init.c | 4 ++--
arch/arm64/mm/physaddr.c | 34 ++++++++++++++++++++++++++++
arch/x86/Kconfig | 1 +
lib/Kconfig.debug | 5 ++++-
mm/cma.c | 15 +++++--------
8 files changed, 79 insertions(+), 33 deletions(-)
create mode 100644 arch/arm64/mm/physaddr.c
--
2.10.1
^ permalink raw reply
* [PATCHv2 1/6] lib/Kconfig.debug: Add ARCH_HAS_DEBUG_VIRTUAL
From: Laura Abbott @ 2016-11-02 21:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161102210054.16621-1-labbott@redhat.com>
DEBUG_VIRTUAL currently depends on DEBUG_KERNEL && X86. arm64 is getting
the same support. Rather than add a list of architectures, switch this
to ARCH_HAS_DEBUG_VIRTUAL and let architectures select it as
appropriate.
Suggested-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Laura Abbott <labbott@redhat.com>
---
arch/x86/Kconfig | 1 +
lib/Kconfig.debug | 5 ++++-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index bada636..f533321 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -23,6 +23,7 @@ config X86
select ARCH_CLOCKSOURCE_DATA
select ARCH_DISCARD_MEMBLOCK
select ARCH_HAS_ACPI_TABLE_UPGRADE if ACPI
+ select ARCH_HAS_DEBUG_VIRTUAL
select ARCH_HAS_DEVMEM_IS_ALLOWED
select ARCH_HAS_ELF_RANDOMIZE
select ARCH_HAS_FAST_MULTIPLIER
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index b01e547..5050530 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -603,9 +603,12 @@ config DEBUG_VM_PGFLAGS
If unsure, say N.
+config ARCH_HAS_DEBUG_VIRTUAL
+ bool
+
config DEBUG_VIRTUAL
bool "Debug VM translations"
- depends on DEBUG_KERNEL && X86
+ depends on DEBUG_KERNEL && ARCH_HAS_DEBUG_VIRTUAL
help
Enable some costly sanity checks in virtual to page code. This can
catch mistakes with virt_to_page() and friends.
--
2.10.1
^ permalink raw reply related
* [PATCHv2 2/6] mm/cma: Cleanup highmem check
From: Laura Abbott @ 2016-11-02 21:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161102210054.16621-1-labbott@redhat.com>
6b101e2a3ce4 ("mm/CMA: fix boot regression due to physical address of
high_memory") added checks to use __pa_nodebug on x86 since
CONFIG_DEBUG_VIRTUAL complains about high_memory not being linearlly
mapped. arm64 is now getting support for CONFIG_DEBUG_VIRTUAL as well.
Rather than add an explosion of arches to the #ifdef, switch to an
alternate method to calculate the physical start of highmem using
the page before highmem starts. This avoids the need for the #ifdef and
extra __pa_nodebug calls.
Signed-off-by: Laura Abbott <labbott@redhat.com>
---
mm/cma.c | 15 +++++----------
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/mm/cma.c b/mm/cma.c
index 384c2cb..71a2ec1 100644
--- a/mm/cma.c
+++ b/mm/cma.c
@@ -235,18 +235,13 @@ int __init cma_declare_contiguous(phys_addr_t base,
phys_addr_t highmem_start;
int ret = 0;
-#ifdef CONFIG_X86
/*
- * high_memory isn't direct mapped memory so retrieving its physical
- * address isn't appropriate. But it would be useful to check the
- * physical address of the highmem boundary so it's justifiable to get
- * the physical address from it. On x86 there is a validation check for
- * this case, so the following workaround is needed to avoid it.
+ * We can't use __pa(high_memory) directly, since high_memory
+ * isn't a valid direct map VA, and DEBUG_VIRTUAL will (validly)
+ * complain. Find the boundary by adding one to the last valid
+ * address.
*/
- highmem_start = __pa_nodebug(high_memory);
-#else
- highmem_start = __pa(high_memory);
-#endif
+ highmem_start = __pa(high_memory - 1) + 1;
pr_debug("%s(size %pa, base %pa, limit %pa alignment %pa)\n",
__func__, &size, &base, &limit, &alignment);
--
2.10.1
^ permalink raw reply related
* [PATCHv2 3/6] arm64: Move some macros under #ifndef __ASSEMBLY__
From: Laura Abbott @ 2016-11-02 21:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161102210054.16621-1-labbott@redhat.com>
Several macros for various x_to_y exist outside the bounds of an
__ASSEMBLY__ guard. Move them in preparation for support for
CONFIG_DEBUG_VIRTUAL.
Signed-off-by: Laura Abbott <labbott@redhat.com>
---
arch/arm64/include/asm/memory.h | 38 +++++++++++++++++++-------------------
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
index b71086d..b4d2b32 100644
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -102,25 +102,6 @@
#endif
/*
- * Physical vs virtual RAM address space conversion. These are
- * private definitions which should NOT be used outside memory.h
- * files. Use virt_to_phys/phys_to_virt/__pa/__va instead.
- */
-#define __virt_to_phys(x) ({ \
- phys_addr_t __x = (phys_addr_t)(x); \
- __x & BIT(VA_BITS - 1) ? (__x & ~PAGE_OFFSET) + PHYS_OFFSET : \
- (__x - kimage_voffset); })
-
-#define __phys_to_virt(x) ((unsigned long)((x) - PHYS_OFFSET) | PAGE_OFFSET)
-#define __phys_to_kimg(x) ((unsigned long)((x) + kimage_voffset))
-
-/*
- * Convert a page to/from a physical address
- */
-#define page_to_phys(page) (__pfn_to_phys(page_to_pfn(page)))
-#define phys_to_page(phys) (pfn_to_page(__phys_to_pfn(phys)))
-
-/*
* Memory types available.
*/
#define MT_DEVICE_nGnRnE 0
@@ -182,6 +163,25 @@ extern u64 kimage_voffset;
#define PHYS_PFN_OFFSET (PHYS_OFFSET >> PAGE_SHIFT)
/*
+ * Physical vs virtual RAM address space conversion. These are
+ * private definitions which should NOT be used outside memory.h
+ * files. Use virt_to_phys/phys_to_virt/__pa/__va instead.
+ */
+#define __virt_to_phys(x) ({ \
+ phys_addr_t __x = (phys_addr_t)(x); \
+ __x & BIT(VA_BITS - 1) ? (__x & ~PAGE_OFFSET) + PHYS_OFFSET : \
+ (__x - kimage_voffset); })
+
+#define __phys_to_virt(x) ((unsigned long)((x) - PHYS_OFFSET) | PAGE_OFFSET)
+#define __phys_to_kimg(x) ((unsigned long)((x) + kimage_voffset))
+
+/*
+ * Convert a page to/from a physical address
+ */
+#define page_to_phys(page) (__pfn_to_phys(page_to_pfn(page)))
+#define phys_to_page(phys) (pfn_to_page(__phys_to_pfn(phys)))
+
+/*
* Note: Drivers should NOT use these. They are the wrong
* translation for translating DMA addresses. Use the driver
* DMA support - see dma-mapping.h.
--
2.10.1
^ permalink raw reply related
* [PATCHv2 4/6] arm64: Add cast for virt_to_pfn
From: Laura Abbott @ 2016-11-02 21:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161102210054.16621-1-labbott@redhat.com>
virt_to_pfn lacks a cast at the top level. Don't rely on __virt_to_phys
and explicitly cast to unsigned long.
Signed-off-by: Laura Abbott <labbott@redhat.com>
---
arch/arm64/include/asm/memory.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
index b4d2b32..d773e2c 100644
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -204,7 +204,7 @@ static inline void *phys_to_virt(phys_addr_t x)
#define __pa(x) __virt_to_phys((unsigned long)(x))
#define __va(x) ((void *)__phys_to_virt((phys_addr_t)(x)))
#define pfn_to_kaddr(pfn) __va((pfn) << PAGE_SHIFT)
-#define virt_to_pfn(x) __phys_to_pfn(__virt_to_phys(x))
+#define virt_to_pfn(x) __phys_to_pfn(__virt_to_phys((unsigned long)(x)))
/*
* virt_to_page(k) convert a _valid_ virtual address to struct page *
--
2.10.1
^ permalink raw reply related
* [PATCHv2 5/6] arm64: Use __pa_symbol for _end
From: Laura Abbott @ 2016-11-02 21:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161102210054.16621-1-labbott@redhat.com>
__pa_symbol is technically the marco that should be used for kernel
symbols. Switch to this as a pre-requisite for DEBUG_VIRTUAL.
Signed-off-by: Laura Abbott <labbott@redhat.com>
---
arch/arm64/mm/init.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 212c4d1..3236eb0 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -209,8 +209,8 @@ void __init arm64_memblock_init(void)
* linear mapping. Take care not to clip the kernel which may be
* high in memory.
*/
- memblock_remove(max_t(u64, memstart_addr + linear_region_size, __pa(_end)),
- ULLONG_MAX);
+ memblock_remove(max_t(u64, memstart_addr + linear_region_size,
+ __pa_symbol(_end)), ULLONG_MAX);
if (memstart_addr + linear_region_size < memblock_end_of_DRAM()) {
/* ensure that memstart_addr remains sufficiently aligned */
memstart_addr = round_up(memblock_end_of_DRAM() - linear_region_size,
--
2.10.1
^ permalink raw reply related
* [PATCHv2 6/6] arm64: Add support for CONFIG_DEBUG_VIRTUAL
From: Laura Abbott @ 2016-11-02 21:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161102210054.16621-1-labbott@redhat.com>
x86 has an option CONFIG_DEBUG_VIRTUAL to do additional checks
on virt_to_phys calls. The goal is to catch users who are calling
virt_to_phys on non-linear addresses immediately. As features
such as CONFIG_VMAP_STACK get enabled for arm64, this becomes
increasingly important. Add checks to catch bad virt_to_phys
usage.
Signed-off-by: Laura Abbott <labbott@redhat.com>
---
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm/memory.h | 12 +++++++++++-
arch/arm64/mm/Makefile | 2 ++
arch/arm64/mm/physaddr.c | 34 ++++++++++++++++++++++++++++++++++
4 files changed, 48 insertions(+), 1 deletion(-)
create mode 100644 arch/arm64/mm/physaddr.c
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 969ef88..83b95bc 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -6,6 +6,7 @@ config ARM64
select ACPI_MCFG if ACPI
select ACPI_SPCR_TABLE if ACPI
select ARCH_CLOCKSOURCE_DATA
+ select ARCH_HAS_DEBUG_VIRTUAL
select ARCH_HAS_DEVMEM_IS_ALLOWED
select ARCH_HAS_ACPI_TABLE_UPGRADE if ACPI
select ARCH_HAS_ELF_RANDOMIZE
diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
index d773e2c..eac3dbb 100644
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -167,11 +167,19 @@ extern u64 kimage_voffset;
* private definitions which should NOT be used outside memory.h
* files. Use virt_to_phys/phys_to_virt/__pa/__va instead.
*/
-#define __virt_to_phys(x) ({ \
+#define __virt_to_phys_nodebug(x) ({ \
phys_addr_t __x = (phys_addr_t)(x); \
__x & BIT(VA_BITS - 1) ? (__x & ~PAGE_OFFSET) + PHYS_OFFSET : \
(__x - kimage_voffset); })
+#ifdef CONFIG_DEBUG_VIRTUAL
+extern unsigned long __virt_to_phys(unsigned long x);
+extern unsigned long __phys_addr_symbol(unsigned long x);
+#else
+#define __virt_to_phys(x) __virt_to_phys_nodebug(x)
+#define __phys_addr_symbol __pa
+#endif
+
#define __phys_to_virt(x) ((unsigned long)((x) - PHYS_OFFSET) | PAGE_OFFSET)
#define __phys_to_kimg(x) ((unsigned long)((x) + kimage_voffset))
@@ -202,6 +210,8 @@ static inline void *phys_to_virt(phys_addr_t x)
* Drivers should NOT use these either.
*/
#define __pa(x) __virt_to_phys((unsigned long)(x))
+#define __pa_symbol(x) __phys_addr_symbol(RELOC_HIDE((unsigned long)(x), 0))
+#define __pa_nodebug(x) __virt_to_phys_nodebug((unsigned long)(x))
#define __va(x) ((void *)__phys_to_virt((phys_addr_t)(x)))
#define pfn_to_kaddr(pfn) __va((pfn) << PAGE_SHIFT)
#define virt_to_pfn(x) __phys_to_pfn(__virt_to_phys((unsigned long)(x)))
diff --git a/arch/arm64/mm/Makefile b/arch/arm64/mm/Makefile
index 54bb209..377f4ab 100644
--- a/arch/arm64/mm/Makefile
+++ b/arch/arm64/mm/Makefile
@@ -5,6 +5,8 @@ obj-y := dma-mapping.o extable.o fault.o init.o \
obj-$(CONFIG_HUGETLB_PAGE) += hugetlbpage.o
obj-$(CONFIG_ARM64_PTDUMP) += dump.o
obj-$(CONFIG_NUMA) += numa.o
+CFLAGS_physaddr.o := -DTEXT_OFFSET=$(TEXT_OFFSET)
+obj-$(CONFIG_DEBUG_VIRTUAL) += physaddr.o
obj-$(CONFIG_KASAN) += kasan_init.o
KASAN_SANITIZE_kasan_init.o := n
diff --git a/arch/arm64/mm/physaddr.c b/arch/arm64/mm/physaddr.c
new file mode 100644
index 0000000..874c782
--- /dev/null
+++ b/arch/arm64/mm/physaddr.c
@@ -0,0 +1,34 @@
+#include <linux/mm.h>
+
+#include <asm/memory.h>
+
+unsigned long __virt_to_phys(unsigned long x)
+{
+ phys_addr_t __x = (phys_addr_t)x;
+
+ if (__x & BIT(VA_BITS - 1)) {
+ /*
+ * The linear kernel range starts in the middle of the virtual
+ * adddress space. Testing the top bit for the start of the
+ * region is a sufficient check.
+ */
+ return (__x & ~PAGE_OFFSET) + PHYS_OFFSET;
+ } else {
+ VIRTUAL_BUG_ON(x < kimage_vaddr || x >= (unsigned long)_end);
+ return (__x - kimage_voffset);
+ }
+}
+EXPORT_SYMBOL(__virt_to_phys);
+
+unsigned long __phys_addr_symbol(unsigned long x)
+{
+ phys_addr_t __x = (phys_addr_t)x;
+
+ /*
+ * This is intentionally different than above to be a tighter check
+ * for symbols.
+ */
+ VIRTUAL_BUG_ON(x < kimage_vaddr + TEXT_OFFSET || x > (unsigned long) _end);
+ return (__x - kimage_voffset);
+}
+EXPORT_SYMBOL(__phys_addr_symbol);
--
2.10.1
^ permalink raw reply related
* [PATCH] arm64: errata: Check for --fix-cortex-a53-843419 and --fix-cortex-a53
From: Will Deacon @ 2016-11-02 21:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161031194414.61287-1-code@mmayer.net>
On Mon, Oct 31, 2016 at 12:44:14PM -0700, Markus Mayer wrote:
> From: Markus Mayer <mmayer@broadcom.com>
>
> The new errata check leads to a warning with some older versions of the
> linker that do know how to work around the errata, but still use the
> original name of the command line option: --fix-cortex-a53. The commit
> in question that changed the name of the option can be found at [1].
> It looks like only "gold" is affected by this rename. Traditional "ld"
> isn't. (There, the argument was always called --fix-cortex-a53-843419.)
>
> To allow older versions of gold to properly handle the erratum if they
> can, check whether ld supports the old name of this option in addition
> to checking the new one.
>
> [1] https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commitdiff;h=7a2a1c793578a8468604e661dda025ecb8d0bd20;hp=cfbf0e3c5b637d66b2b1aeadecae9c187b825b2f
>
> Signed-off-by: Markus Mayer <mmayer@broadcom.com>
If newer versions of gold accept the correct option name, why do we care?
Will
^ permalink raw reply
* [PATCH] arm64: errata: Check for --fix-cortex-a53-843419 and --fix-cortex-a53
From: Markus Mayer @ 2016-11-02 21:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161102210331.GJ22791@arm.com>
On 2 November 2016 at 14:03, Will Deacon <will.deacon@arm.com> wrote:
> On Mon, Oct 31, 2016 at 12:44:14PM -0700, Markus Mayer wrote:
>> From: Markus Mayer <mmayer@broadcom.com>
>>
>> The new errata check leads to a warning with some older versions of the
>> linker that do know how to work around the errata, but still use the
>> original name of the command line option: --fix-cortex-a53. The commit
>> in question that changed the name of the option can be found at [1].
>> It looks like only "gold" is affected by this rename. Traditional "ld"
>> isn't. (There, the argument was always called --fix-cortex-a53-843419.)
>>
>> To allow older versions of gold to properly handle the erratum if they
>> can, check whether ld supports the old name of this option in addition
>> to checking the new one.
>>
>> [1] https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commitdiff;h=7a2a1c793578a8468604e661dda025ecb8d0bd20;hp=cfbf0e3c5b637d66b2b1aeadecae9c187b825b2f
>>
>> Signed-off-by: Markus Mayer <mmayer@broadcom.com>
>
> If newer versions of gold accept the correct option name, why do we care?
Because Documentation/Changes states that the minimum requirement for
binutils is 2.12. Right now, that is not really true. And not
everybody can always use the newest toolchain, for various reasons.
The question I am asking is: What do we have to lose by supporting both options?
Thanks,
-Markus
^ permalink raw reply
* [PATCH v3 11/14] ACPI: irq: introduce interrupt producer
From: Hanjun Guo @ 2016-11-02 21:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c403c4099fd5dcfcebb6b7ff5a51b915@codeaurora.org>
Hi Agustin,
Sorry for the late reply, on travailing for now.
On 10/29/2016 03:32 AM, agustinv at codeaurora.org wrote:
> Hey Hanjun,
>
> On 2016-10-25 11:09, Hanjun Guo wrote:
>> From: Hanjun Guo <hanjun.guo@linaro.org>
>>
>> In ACPI 6.1 spec, section 19.6.62, Interrupt Resource Descriptor Macro,
>>
>> Interrupt (ResourceUsage, EdgeLevel, ActiveLevel, Shared,
>> ResourceSourceIndex, ResourceSource, DescriptorName)
>> { InterruptList } => Buffer
>>
>> For the arguement ResourceUsage and DescriptorName, which means:
>>
>> ResourceUsage describes whether the device consumes the specified
>> interrupt ( ResourceConsumer ) or produces it for use by a child
>> device ( ResourceProducer ).
>> If nothing is specified, then ResourceConsumer is assumed.
>>
>> DescriptorName evaluates to a name string which refers to the
>> entire resource descriptor.
>>
>> So it can be used for devices connecting to a specific interrupt
>> prodcucer instead of the main interrupt controller in MADT. In the
>> real world, we have irqchip such as mbi-gen which connecting to
>> a group of wired interrupts and then issue msi to the ITS, devices
>> connecting to such interrupt controller fit this scope.
>>
>> For now the irq for ACPI only pointer to the main interrupt
>> controller's irqdomain, for devices not connecting to those
>> irqdomains, which need to present its irq parent, we can use
>> following ASL code to represent it:
>>
>> Interrupt(ResourceConsumer,..., "\_SB.IRQP") {12,14,....}
>>
>> then we can parse the interrupt producer with the full
>> path name "\_SB.IRQP".
>>
>> In order to do that, we introduce a pointer interrupt_producer
>> in struct acpi_device, and fill it when scanning irq resources
>> for acpi device if it specifies the interrupt producer.
>>
>> But for now when parsing the resources for acpi devices, we don't
>> pass the acpi device for acpi_walk_resoures() in drivers/acpi/resource.c,
>> so introduce a adev in struct res_proc_context to pass it as a context
>> to scan the interrupt resources, then finally pass to acpi_register_gsi()
>> to find its interrupt producer to get the virq from diffrent domains.
>>
>> With steps above ready, rework acpi_register_gsi() to get other
>> interrupt producer if devices not connecting to main interrupt
>> controller.
>>
>> Since we often pass NULL to acpi_register_gsi() and there is no interrupt
>> producer for devices connect to gicd on ARM or io-apic on X86, so it will
>> use the default irqdomain for those deivces and no functional changes to
>> those devices.
>>
>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>> Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
>> Cc: Marc Zyngier <marc.zyngier@arm.com>
>> Cc: Agustin Vega-Frias <agustinv@codeaurora.org>
>> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
>> ---
>> drivers/acpi/gsi.c | 10 ++++--
>> drivers/acpi/resource.c | 85
>> ++++++++++++++++++++++++++++++++++---------------
>> include/acpi/acpi_bus.h | 1 +
>> 3 files changed, 68 insertions(+), 28 deletions(-)
>>
>> diff --git a/drivers/acpi/gsi.c b/drivers/acpi/gsi.c
>> index ee9e0f2..29ee547 100644
>> --- a/drivers/acpi/gsi.c
>> +++ b/drivers/acpi/gsi.c
>> @@ -55,13 +55,19 @@ int acpi_register_gsi(struct device *dev, u32 gsi,
>> int trigger,
>> int polarity)
>> {
>> struct irq_fwspec fwspec;
>> + struct acpi_device *adev = dev ? to_acpi_device(dev) : NULL;
>>
>> - if (WARN_ON(!acpi_gsi_domain_id)) {
>> + if (adev && &adev->fwnode && adev->interrupt_producer)
>> + /* devices in DSDT connecting to spefic interrupt producer */
>> + fwspec.fwnode = adev->interrupt_producer;
>> + else if (acpi_gsi_domain_id)
>> + /* devices connecting to gicd in default */
>> + fwspec.fwnode = acpi_gsi_domain_id;
>> + else {
>> pr_warn("GSI: No registered irqchip, giving up\n");
>> return -EINVAL;
>> }
>>
>> - fwspec.fwnode = acpi_gsi_domain_id;
>> fwspec.param[0] = gsi;
>> fwspec.param[1] = acpi_dev_get_irq_type(trigger, polarity);
>> fwspec.param_count = 2;
>> diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
>> index 56241eb..f1371cf 100644
>> --- a/drivers/acpi/resource.c
>> +++ b/drivers/acpi/resource.c
>> @@ -381,7 +381,7 @@ static void acpi_dev_irqresource_disabled(struct
>> resource *res, u32 gsi)
>> res->flags = IORESOURCE_IRQ | IORESOURCE_DISABLED |
>> IORESOURCE_UNSET;
>> }
>>
>> -static void acpi_dev_get_irqresource(struct resource *res, u32 gsi,
>> +static void acpi_dev_get_irqresource(struct acpi_device *adev, struct
>> resource *res, u32 gsi,
>> u8 triggering, u8 polarity, u8 shareable,
>> bool legacy)
>> {
>> @@ -415,7 +415,7 @@ static void acpi_dev_get_irqresource(struct
>> resource *res, u32 gsi,
>> }
>>
>> res->flags = acpi_dev_irq_flags(triggering, polarity, shareable);
>> - irq = acpi_register_gsi(NULL, gsi, triggering, polarity);
>> + irq = acpi_register_gsi(&adev->dev, gsi, triggering, polarity);
>> if (irq >= 0) {
>> res->start = irq;
>> res->end = irq;
>> @@ -424,27 +424,9 @@ static void acpi_dev_get_irqresource(struct
>> resource *res, u32 gsi,
>> }
>> }
>>
>> -/**
>> - * acpi_dev_resource_interrupt - Extract ACPI interrupt resource
>> information.
>> - * @ares: Input ACPI resource object.
>> - * @index: Index into the array of GSIs represented by the resource.
>> - * @res: Output generic resource object.
>> - *
>> - * Check if the given ACPI resource object represents an interrupt
>> resource
>> - * and @index does not exceed the resource's interrupt count (true is
>> returned
>> - * in that case regardless of the results of the other checks)). If
>> that's the
>> - * case, register the GSI corresponding to @index from the array of
>> interrupts
>> - * represented by the resource and populate the generic resource
>> object pointed
>> - * to by @res accordingly. If the registration of the GSI is not
>> successful,
>> - * IORESOURCE_DISABLED will be set it that object's flags.
>> - *
>> - * Return:
>> - * 1) false with res->flags setting to zero: not the expected
>> resource type
>> - * 2) false with IORESOURCE_DISABLED in res->flags: valid unassigned
>> resource
>> - * 3) true: valid assigned resource
>> - */
>> -bool acpi_dev_resource_interrupt(struct acpi_resource *ares, int index,
>> - struct resource *res)
>> +static bool __acpi_dev_resource_interrupt(struct acpi_device *adev,
>> + struct acpi_resource *ares, int index,
>> + struct resource *res)
>> {
>> struct acpi_resource_irq *irq;
>> struct acpi_resource_extended_irq *ext_irq;
>> @@ -460,7 +442,7 @@ bool acpi_dev_resource_interrupt(struct
>> acpi_resource *ares, int index,
>> acpi_dev_irqresource_disabled(res, 0);
>> return false;
>> }
>> - acpi_dev_get_irqresource(res, irq->interrupts[index],
>> + acpi_dev_get_irqresource(adev, res, irq->interrupts[index],
>> irq->triggering, irq->polarity,
>> irq->sharable, true);
>> break;
>> @@ -470,7 +452,31 @@ bool acpi_dev_resource_interrupt(struct
>> acpi_resource *ares, int index,
>> acpi_dev_irqresource_disabled(res, 0);
>> return false;
>> }
>> - acpi_dev_get_irqresource(res, ext_irq->interrupts[index],
>> +
>> + /*
>> + * It's a interrupt consumer device and connecting to specfic
>> + * interrupt controller. For now, we only support connecting
>> + * interrupts to one irq controller for a single device
>> + */
>> + if (ext_irq->producer_consumer == ACPI_CONSUMER
>> + && ext_irq->resource_source.string_length != 0
>> + && !adev->interrupt_producer) {
>> + acpi_status status;
>> + acpi_handle handle;
>> + struct acpi_device *device;
>> +
>> + status = acpi_get_handle(NULL,
>> ext_irq->resource_source.string_ptr, &handle);
>> + if (ACPI_FAILURE(status))
>> + return false;
>> +
>> + device = acpi_bus_get_acpi_device(handle);
>> + if (!device)
>> + return false;
>> +
>> + adev->interrupt_producer = &device->fwnode;
>
> You are missing an 'acpi_bus_put_acpi_device(device)' call here.
good catch!
>
> Besides that, this approach will not work in the case where a device
> wants to consume interrupts from multiple controllers since you are
> forcing adev->interrupt_producer to be the first resource_source
> found.
Yes, you are right, and it's in the comment of the code, we
can fix that to add some extra code.
>
> That's the reason I was advocating dynamic lookup (see [1]).
>
> I am about to submit V6 of my series where I also address the probe
> ordering issues by enabling re-initialization of platform_device
> resources when the resource was marked disabled due to the domain
> nor being there during ACPI bus scan.
I will take a deep look for your v6 patch set, probably we can
work together to get things down.
Thanks
Hanjun
^ permalink raw reply
* [PATCH] ARM: socfpga: updates for socfpga_defconfig
From: Dinh Nguyen @ 2016-11-02 21:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478044484-2331-1-git-send-email-atull@opensource.altera.com>
On 11/01/2016 06:54 PM, Alan Tull wrote:
> This patch enables the following in the
> socfpga_defconfig:
>
> +CONFIG_OF_OVERLAY=y
> Enable support for Device Tree Overlays
>
> +CONFIG_FPGA_REGION=y
> Enable device tree overlay support for FPGA
> programming
>
> +CONFIG_FPGA_MGR_SOCFPGA_A10=y
> Enable partial reconfiguration for Altera
> Arria 10 FPGA
>
> +CONFIG_FPGA_BRIDGE=y
> Enable the FPGA Bridges framework
>
> +CONFIG_SOCFPGA_FPGA_BRIDGE=y
> Enable support for SoCFPGA hardware
> bridges
>
> +CONFIG_ALTERA_FREEZE_BRIDGE=y
> Enable support for the Altera Soft IP
> Freeze bridges
>
> Signed-off-by: Alan Tull <atull@opensource.altera.com>
> ---
> arch/arm/configs/socfpga_defconfig | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/arm/configs/socfpga_defconfig b/arch/arm/configs/socfpga_defconfig
> index f5b9bc5..18d3ec1 100644
> --- a/arch/arm/configs/socfpga_defconfig
> +++ b/arch/arm/configs/socfpga_defconfig
> @@ -54,6 +54,7 @@ CONFIG_DEVTMPFS_MOUNT=y
Applied!
Thanks,
Dinh
^ 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