Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [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 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] 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 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 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] 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&currentviews=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&currentviews=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 @@
>>>>     >> >> >>>>
>>>>     >> >> >>>>  &ethernet0 {
>>>>     >> >> >>>>         status = "okay";
>>>>     >> >> >>>> +       dma-ranges;
>>>>     >> >> >>>>         pinctrl-0       = <&ethernet0_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: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&currentviews=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&currentviews=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 @@
>> >>     >> >> >>>>
>> >>     >> >> >>>>  &ethernet0 {
>> >>     >> >> >>>>         status = "okay";
>> >>     >> >> >>>> +       dma-ranges;
>> >>     >> >> >>>>         pinctrl-0       = <&ethernet0_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] 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 V2 2/2] ARM: dts: add new compatible stream for i.MX6QP mmdc
From: Frank Li @ 2016-11-02 18:00 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1478109604-18323-1-git-send-email-Frank.Li@nxp.com>

mmdc of i.MX6QP are little difference with i.MX6Q.
added new compatible stream fsl,imx6qp-mmdc

Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
No change for this patch.
suspend resume code need fsl,imx6q-mmdc

 arch/arm/boot/dts/imx6qp.dtsi | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/imx6qp.dtsi b/arch/arm/boot/dts/imx6qp.dtsi
index 886dbf2..e0fdd0f 100644
--- a/arch/arm/boot/dts/imx6qp.dtsi
+++ b/arch/arm/boot/dts/imx6qp.dtsi
@@ -85,5 +85,12 @@
 		pcie: pcie at 0x01000000 {
 			compatible = "fsl,imx6qp-pcie", "snps,dw-pcie";
 		};
+
+		aips-bus at 02100000 {
+			mmdc0: mmdc at 021b0000 { /* MMDC0 */
+				compatible = "fsl,imx6qp-mmdc", "fsl,imx6q-mmdc";
+				reg = <0x021b0000 0x4000>;
+			};
+		};
 	};
 };
-- 
2.5.2

^ permalink raw reply related

* [PATCH v2 1/2] ARM: imx: mmdc perf function support i.MX6QP
From: Frank Li @ 2016-11-02 18:00 UTC (permalink / raw)
  To: linux-arm-kernel

i.MX6QP added new reigster bit PROFILE_SEL in MADPCR0.
need set it at perf start.

Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
V1 to V2: remove fsl_mmdc_devtype

 arch/arm/mach-imx/mmdc.c | 38 ++++++++++++++++++++++++++++++++------
 1 file changed, 32 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-imx/mmdc.c b/arch/arm/mach-imx/mmdc.c
index d82d14c..032cbe0 100644
--- a/arch/arm/mach-imx/mmdc.c
+++ b/arch/arm/mach-imx/mmdc.c
@@ -44,6 +44,7 @@
 #define DBG_RST			0x2
 #define PRF_FRZ			0x4
 #define CYC_OVF			0x8
+#define PROFILE_SEL		0x10
 
 #define MMDC_MADPCR0	0x410
 #define MMDC_MADPSR0	0x418
@@ -55,10 +56,29 @@
 
 #define MMDC_NUM_COUNTERS	6
 
+#define FSL_MMDC_QUIRK_PROFILE_SEL	0x1
+
 #define to_mmdc_pmu(p) container_of(p, struct mmdc_pmu, pmu)
 
 static int ddr_type;
 
+struct fsl_mmdc_devtype_data {
+	int driver_data;
+};
+
+static struct fsl_mmdc_devtype_data imx6q_data = {
+};
+
+static struct fsl_mmdc_devtype_data imx6qp_data = {
+	.driver_data = FSL_MMDC_QUIRK_PROFILE_SEL,
+};
+
+static const struct of_device_id imx_mmdc_dt_ids[] = {
+	{ .compatible = "fsl,imx6q-mmdc", .data = (void *)&imx6q_data},
+	{ .compatible = "fsl,imx6qp-mmdc", .data = (void *)&imx6qp_data},
+	{ /* sentinel */ }
+};
+
 #ifdef CONFIG_PERF_EVENTS
 
 static DEFINE_IDA(mmdc_ida);
@@ -83,6 +103,7 @@ struct mmdc_pmu {
 	struct device *dev;
 	struct perf_event *mmdc_events[MMDC_NUM_COUNTERS];
 	struct hlist_node node;
+	struct fsl_mmdc_devtype_data *devtype_data;
 };
 
 /*
@@ -307,6 +328,7 @@ static void mmdc_pmu_event_start(struct perf_event *event, int flags)
 	struct mmdc_pmu *pmu_mmdc = to_mmdc_pmu(event->pmu);
 	struct hw_perf_event *hwc = &event->hw;
 	void __iomem *mmdc_base, *reg;
+	int val;
 
 	mmdc_base = pmu_mmdc->mmdc_base;
 	reg = mmdc_base + MMDC_MADPCR0;
@@ -321,7 +343,12 @@ static void mmdc_pmu_event_start(struct perf_event *event, int flags)
 	local64_set(&hwc->prev_count, 0);
 
 	writel(DBG_RST, reg);
-	writel(DBG_EN, reg);
+
+	val = DBG_EN;
+	if (pmu_mmdc->devtype_data->driver_data & FSL_MMDC_QUIRK_PROFILE_SEL)
+		val |= PROFILE_SEL;
+
+	writel(val, reg);
 }
 
 static int mmdc_pmu_event_add(struct perf_event *event, int flags)
@@ -436,6 +463,8 @@ static int imx_mmdc_perf_init(struct platform_device *pdev, void __iomem *mmdc_b
 	char *name;
 	int mmdc_num;
 	int ret;
+	const struct of_device_id *of_id =
+		of_match_device(imx_mmdc_dt_ids, &pdev->dev);
 
 	pmu_mmdc = kzalloc(sizeof(*pmu_mmdc), GFP_KERNEL);
 	if (!pmu_mmdc) {
@@ -450,6 +479,8 @@ static int imx_mmdc_perf_init(struct platform_device *pdev, void __iomem *mmdc_b
 		name = devm_kasprintf(&pdev->dev,
 				GFP_KERNEL, "mmdc%d", mmdc_num);
 
+	pmu_mmdc->devtype_data = (struct fsl_mmdc_devtype_data *)of_id->data;
+
 	hrtimer_init(&pmu_mmdc->hrtimer, CLOCK_MONOTONIC,
 			HRTIMER_MODE_REL);
 	pmu_mmdc->hrtimer.function = mmdc_pmu_timer_handler;
@@ -524,11 +555,6 @@ int imx_mmdc_get_ddr_type(void)
 	return ddr_type;
 }
 
-static const struct of_device_id imx_mmdc_dt_ids[] = {
-	{ .compatible = "fsl,imx6q-mmdc", },
-	{ /* sentinel */ }
-};
-
 static struct platform_driver imx_mmdc_driver = {
 	.driver		= {
 		.name	= "imx-mmdc",
-- 
2.5.2

^ permalink raw reply related

* [PATCH] drm/sun4i: Fix error handling
From: Maxime Ripard @ 2016-11-02 17:57 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161030084926.15303-1-christophe.jaillet@wanadoo.fr>

On Sun, Oct 30, 2016 at 09:49:26AM +0100, Christophe JAILLET wrote:
> 'sun4i_layers_init()' returns an error pointer in case of error, not
> NULL. So test it with IS_ERR.
> 
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>

Applied, 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/a688de85/attachment.sig>

^ permalink raw reply

* [PATCH v7] spi: sun4i: Allow transfers larger than FIFO size
From: Maxime Ripard @ 2016-11-02 17:47 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161027224712.GY25322@sirena.org.uk>

Hi Mark,

On Thu, Oct 27, 2016 at 11:47:12PM +0100, Mark Brown wrote:
> > > If the concern from the previous reviews to do with not using DMA is
> > > there some reason it's hard to do DMA?
> 
> > I think just like Alexandru that it is orthogonal. But to really
> > answer, no, it's not difficult. There's just been some fundamental
> > disagreement on whether DMA was supposed to be optional or not that
> > stalled everything I guess.
> 
> Oh, I seem to remember some patches adding DMA support that were doing
> some strange special snowflake thing with ignoring errors now that I
> think about it but that's not this one...  why did nobody ever follow up
> on those?

I have no idea. I think last time we discussed this was last
July. Especially with this in now, there's probably no rush anyway.

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/b6ac813a/attachment.sig>

^ permalink raw reply

* [PATCH v5 2/7] Documentation: devicetree: add PHY lane swap binding
From: Andrew Lunn @ 2016-11-02 17:39 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1478106488-11779-3-git-send-email-jon.mason@broadcom.com>

On Wed, Nov 02, 2016 at 01:08:03PM -0400, Jon Mason wrote:
> Add the documentation for PHY lane swapping.  This is a boolean entry to
> notify the phy device drivers that the TX/RX lanes need to be swapped.
> 
> Signed-off-by: Jon Mason <jon.mason@broadcom.com>

Reviewed-by: Andrew Lunn <andrew@lunn.ch>

    Andrew

^ permalink raw reply

* [PATCH] iommu/arm-smmu: Check that iommu_fwspecs are ours
From: Robin Murphy @ 2016-11-02 17:31 UTC (permalink / raw)
  To: linux-arm-kernel

We seem to have forgotten to check that iommu_fwspecs actually belong to
us before we go ahead and dereference their private data. Oops.

Fixes: 021bb8420d44 ("iommu/arm-smmu: Wire up generic configuration support")
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
 drivers/iommu/arm-smmu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index ef978db2bb54..ef0f8d635a3b 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -1390,7 +1390,7 @@ static int arm_smmu_add_device(struct device *dev)
 		fwspec = dev->iommu_fwspec;
 		if (ret)
 			goto out_free;
-	} else if (fwspec) {
+	} else if (fwspec && fwspec->ops == &arm_smmu_ops) {
 		smmu = arm_smmu_get_by_node(to_of_node(fwspec->iommu_fwnode));
 	} else {
 		return -ENODEV;
-- 
2.10.2.dirty

^ permalink raw reply related

* [PATCH v5 4/7] Documentation: devicetree: net: add NS2 bindings to amac
From: Jon Mason @ 2016-11-02 17:24 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <ab064a45-0172-fa28-4ac6-0d3159a26506@cogentembedded.com>

On Wed, Nov 02, 2016 at 08:18:51PM +0300, Sergei Shtylyov wrote:
> Hello.
> 
> On 11/02/2016 08:08 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.

Thanks,
Jon


> 
> [...]
> 
> MBR, Sergei
> 

^ permalink raw reply

* [PATCH v5 4/7] Documentation: devicetree: net: add NS2 bindings to amac
From: Sergei Shtylyov @ 2016-11-02 17:18 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1478106488-11779-5-git-send-email-jon.mason@broadcom.com>

Hello.

On 11/02/2016 08:08 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...

[...]

MBR, Sergei

^ permalink raw reply

* [PATCH v5 7/7] arm64: dts: NS2: add AMAC ethernet support
From: Florian Fainelli @ 2016-11-02 17:17 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1478106488-11779-8-git-send-email-jon.mason@broadcom.com>

On 11/02/2016 10:08 AM, Jon Mason wrote:
> Add support for the AMAC ethernet to the Broadcom Northstar2 SoC device
> tree
> 
> Signed-off-by: Jon Mason <jon.mason@broadcom.com>

Provided that the binding is satisfactory, I will take this one via
ARM64-SoC.
-- 
Florian

^ permalink raw reply

* [PATCH v5 6/7] net: ethernet: bgmac: add NS2 support
From: Florian Fainelli @ 2016-11-02 17:17 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1478106488-11779-7-git-send-email-jon.mason@broadcom.com>

On 11/02/2016 10:08 AM, Jon Mason wrote:
> Add support for the variant of amac hardware present in the Broadcom
> Northstar2 based SoCs.  Northstar2 requires an additional register to be
> configured with the port speed/duplexity (NICPM).  This can be added to
> the link callback to hide it from the instances that do not use this.
> Also, clearing of the pending interrupts on init is required due to
> observed issues on some platforms.
> 
> Signed-off-by: Jon Mason <jon.mason@broadcom.com>

Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
-- 
Florian

^ permalink raw reply

* [PATCH v5 5/7] net: ethernet: bgmac: device tree phy enablement
From: Florian Fainelli @ 2016-11-02 17:16 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1478106488-11779-6-git-send-email-jon.mason@broadcom.com>

On 11/02/2016 10:08 AM, Jon Mason wrote:
> Change the bgmac driver to allow for phy's defined by the device tree
> 
> Signed-off-by: Jon Mason <jon.mason@broadcom.com>

Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
-- 
Florian

^ permalink raw reply

* [PATCH v5 4/7] Documentation: devicetree: net: add NS2 bindings to amac
From: Florian Fainelli @ 2016-11-02 17:13 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1478106488-11779-5-git-send-email-jon.mason@broadcom.com>

On 11/02/2016 10:08 AM, 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>

Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
-- 
Florian

^ permalink raw reply

* [PATCH v5 3/7] net: phy: broadcom: Add BCM54810 PHY entry
From: Florian Fainelli @ 2016-11-02 17:12 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1478106488-11779-4-git-send-email-jon.mason@broadcom.com>

On 11/02/2016 10:08 AM, 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: Florian Fainelli <f.fainelli@gmail.com>
-- 
Florian

^ permalink raw reply

* [PATCH v5 2/7] Documentation: devicetree: add PHY lane swap binding
From: Florian Fainelli @ 2016-11-02 17:11 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1478106488-11779-3-git-send-email-jon.mason@broadcom.com>

On 11/02/2016 10:08 AM, Jon Mason wrote:
> Add the documentation for PHY lane swapping.  This is a boolean entry to
> notify the phy device drivers that the TX/RX lanes need to be swapped.
> 
> Signed-off-by: Jon Mason <jon.mason@broadcom.com>

Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
-- 
Florian

^ permalink raw reply

* [PATCH v5 1/7] net: phy: broadcom: add bcm54xx_auxctl_read
From: Florian Fainelli @ 2016-11-02 17:11 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1478106488-11779-2-git-send-email-jon.mason@broadcom.com>

On 11/02/2016 10:08 AM, Jon Mason wrote:
> Add a helper function to read the AUXCTL register for the BCM54xx.  This
> mirrors the bcm54xx_auxctl_write function already present in the code.
> 
> Signed-off-by: Jon Mason <jon.mason@broadcom.com>

Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
-- 
Florian

^ permalink raw reply

* [PATCH v5 7/7] arm64: dts: NS2: add AMAC ethernet support
From: Jon Mason @ 2016-11-02 17:08 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1478106488-11779-1-git-send-email-jon.mason@broadcom.com>

Add support for the AMAC ethernet to the Broadcom Northstar2 SoC device
tree

Signed-off-by: Jon Mason <jon.mason@broadcom.com>
---
 arch/arm64/boot/dts/broadcom/ns2-svk.dts |  5 +++++
 arch/arm64/boot/dts/broadcom/ns2.dtsi    | 12 ++++++++++++
 2 files changed, 17 insertions(+)

diff --git a/arch/arm64/boot/dts/broadcom/ns2-svk.dts b/arch/arm64/boot/dts/broadcom/ns2-svk.dts
index 2d7872a..2e4d90d 100644
--- a/arch/arm64/boot/dts/broadcom/ns2-svk.dts
+++ b/arch/arm64/boot/dts/broadcom/ns2-svk.dts
@@ -56,6 +56,10 @@
 	};
 };
 
+&enet {
+	status = "ok";
+};
+
 &pci_phy0 {
 	status = "ok";
 };
@@ -172,6 +176,7 @@
 &mdio_mux_iproc {
 	mdio at 10 {
 		gphy0: eth-phy at 10 {
+			enet-phy-lane-swap;
 			reg = <0x10>;
 		};
 	};
diff --git a/arch/arm64/boot/dts/broadcom/ns2.dtsi b/arch/arm64/boot/dts/broadcom/ns2.dtsi
index d95dc40..773ed59 100644
--- a/arch/arm64/boot/dts/broadcom/ns2.dtsi
+++ b/arch/arm64/boot/dts/broadcom/ns2.dtsi
@@ -191,6 +191,18 @@
 
 		#include "ns2-clock.dtsi"
 
+		enet: ethernet at 61000000 {
+			compatible = "brcm,ns2-amac";
+			reg = <0x61000000 0x1000>,
+			      <0x61090000 0x1000>,
+			      <0x61030000 0x100>;
+			reg-names = "amac_base", "idm_base", "nicpm_base";
+			interrupts = <GIC_SPI 341 IRQ_TYPE_LEVEL_HIGH>;
+			phy-handle = <&gphy0>;
+			phy-mode = "rgmii";
+			status = "disabled";
+		};
+
 		dma0: dma at 61360000 {
 			compatible = "arm,pl330", "arm,primecell";
 			reg = <0x61360000 0x1000>;
-- 
2.7.4

^ permalink raw reply related


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox