* [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¤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: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] 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
* [PATCH v5 6/7] net: ethernet: bgmac: add NS2 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 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>
---
drivers/net/ethernet/broadcom/bgmac-platform.c | 56 +++++++++++++++++++++++++-
drivers/net/ethernet/broadcom/bgmac.c | 3 ++
drivers/net/ethernet/broadcom/bgmac.h | 1 +
3 files changed, 58 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bgmac-platform.c b/drivers/net/ethernet/broadcom/bgmac-platform.c
index aed5dc5..fce63cf 100644
--- a/drivers/net/ethernet/broadcom/bgmac-platform.c
+++ b/drivers/net/ethernet/broadcom/bgmac-platform.c
@@ -14,12 +14,21 @@
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
#include <linux/bcma/bcma.h>
+#include <linux/brcmphy.h>
#include <linux/etherdevice.h>
#include <linux/of_address.h>
#include <linux/of_mdio.h>
#include <linux/of_net.h>
#include "bgmac.h"
+#define NICPM_IOMUX_CTRL 0x00000008
+
+#define NICPM_IOMUX_CTRL_INIT_VAL 0x3196e000
+#define NICPM_IOMUX_CTRL_SPD_SHIFT 10
+#define NICPM_IOMUX_CTRL_SPD_10M 0
+#define NICPM_IOMUX_CTRL_SPD_100M 1
+#define NICPM_IOMUX_CTRL_SPD_1000M 2
+
static u32 platform_bgmac_read(struct bgmac *bgmac, u16 offset)
{
return readl(bgmac->plat.base + offset);
@@ -87,12 +96,46 @@ static void platform_bgmac_cmn_maskset32(struct bgmac *bgmac, u16 offset,
WARN_ON(1);
}
+static void bgmac_nicpm_speed_set(struct net_device *net_dev)
+{
+ struct bgmac *bgmac = netdev_priv(net_dev);
+ u32 val;
+
+ if (!bgmac->plat.nicpm_base)
+ return;
+
+ val = NICPM_IOMUX_CTRL_INIT_VAL;
+ switch (bgmac->net_dev->phydev->speed) {
+ default:
+ netdev_err(net_dev, "Unsupported speed. Defaulting to 1000Mb\n");
+ case SPEED_1000:
+ val |= NICPM_IOMUX_CTRL_SPD_1000M << NICPM_IOMUX_CTRL_SPD_SHIFT;
+ break;
+ case SPEED_100:
+ val |= NICPM_IOMUX_CTRL_SPD_100M << NICPM_IOMUX_CTRL_SPD_SHIFT;
+ break;
+ case SPEED_10:
+ val |= NICPM_IOMUX_CTRL_SPD_10M << NICPM_IOMUX_CTRL_SPD_SHIFT;
+ break;
+ }
+
+ writel(val, bgmac->plat.nicpm_base + NICPM_IOMUX_CTRL);
+
+ bgmac_adjust_link(bgmac->net_dev);
+}
+
static int platform_phy_connect(struct bgmac *bgmac)
{
struct phy_device *phy_dev;
- phy_dev = of_phy_get_and_connect(bgmac->net_dev, bgmac->dev->of_node,
- bgmac_adjust_link);
+ if (bgmac->plat.nicpm_base)
+ phy_dev = of_phy_get_and_connect(bgmac->net_dev,
+ bgmac->dev->of_node,
+ bgmac_nicpm_speed_set);
+ else
+ phy_dev = of_phy_get_and_connect(bgmac->net_dev,
+ bgmac->dev->of_node,
+ bgmac_adjust_link);
if (!phy_dev) {
dev_err(bgmac->dev, "Phy connect failed\n");
return -ENODEV;
@@ -182,6 +225,14 @@ static int bgmac_probe(struct platform_device *pdev)
if (IS_ERR(bgmac->plat.idm_base))
return PTR_ERR(bgmac->plat.idm_base);
+ regs = platform_get_resource_byname(pdev, IORESOURCE_MEM, "nicpm_base");
+ if (regs) {
+ bgmac->plat.nicpm_base = devm_ioremap_resource(&pdev->dev,
+ regs);
+ if (IS_ERR(bgmac->plat.nicpm_base))
+ return PTR_ERR(bgmac->plat.nicpm_base);
+ }
+
bgmac->read = platform_bgmac_read;
bgmac->write = platform_bgmac_write;
bgmac->idm_read = platform_bgmac_idm_read;
@@ -213,6 +264,7 @@ static int bgmac_remove(struct platform_device *pdev)
static const struct of_device_id bgmac_of_enet_match[] = {
{.compatible = "brcm,amac",},
{.compatible = "brcm,nsp-amac",},
+ {.compatible = "brcm,ns2-amac",},
{},
};
diff --git a/drivers/net/ethernet/broadcom/bgmac.c b/drivers/net/ethernet/broadcom/bgmac.c
index 4584958..a805cc8 100644
--- a/drivers/net/ethernet/broadcom/bgmac.c
+++ b/drivers/net/ethernet/broadcom/bgmac.c
@@ -1082,6 +1082,9 @@ static void bgmac_enable(struct bgmac *bgmac)
/* http://bcm-v4.sipsolutions.net/mac-gbit/gmac/chipinit */
static void bgmac_chip_init(struct bgmac *bgmac)
{
+ /* Clear any erroneously pending interrupts */
+ bgmac_write(bgmac, BGMAC_INT_STATUS, ~0);
+
/* 1 interrupt per received frame */
bgmac_write(bgmac, BGMAC_INT_RECV_LAZY, 1 << BGMAC_IRL_FC_SHIFT);
diff --git a/drivers/net/ethernet/broadcom/bgmac.h b/drivers/net/ethernet/broadcom/bgmac.h
index ea52ac3..b1820ea 100644
--- a/drivers/net/ethernet/broadcom/bgmac.h
+++ b/drivers/net/ethernet/broadcom/bgmac.h
@@ -463,6 +463,7 @@ struct bgmac {
struct {
void *base;
void *idm_base;
+ void *nicpm_base;
} plat;
struct {
struct bcma_device *core;
--
2.7.4
^ permalink raw reply related
* [PATCH v5 5/7] net: ethernet: bgmac: device tree phy enablement
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>
Change the bgmac driver to allow for phy's defined by the device tree
Signed-off-by: Jon Mason <jon.mason@broadcom.com>
---
drivers/net/ethernet/broadcom/bgmac-bcma.c | 48 ++++++++++++++++++++++++
drivers/net/ethernet/broadcom/bgmac-platform.c | 48 +++++++++++++++++++++++-
drivers/net/ethernet/broadcom/bgmac.c | 52 ++------------------------
drivers/net/ethernet/broadcom/bgmac.h | 7 ++++
4 files changed, 105 insertions(+), 50 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bgmac-bcma.c b/drivers/net/ethernet/broadcom/bgmac-bcma.c
index c16ec3a..3e3efde 100644
--- a/drivers/net/ethernet/broadcom/bgmac-bcma.c
+++ b/drivers/net/ethernet/broadcom/bgmac-bcma.c
@@ -80,6 +80,50 @@ static void bcma_bgmac_cmn_maskset32(struct bgmac *bgmac, u16 offset, u32 mask,
bcma_maskset32(bgmac->bcma.cmn, offset, mask, set);
}
+static int bcma_phy_connect(struct bgmac *bgmac)
+{
+ struct phy_device *phy_dev;
+ char bus_id[MII_BUS_ID_SIZE + 3];
+
+ /* Connect to the PHY */
+ snprintf(bus_id, sizeof(bus_id), PHY_ID_FMT, bgmac->mii_bus->id,
+ bgmac->phyaddr);
+ phy_dev = phy_connect(bgmac->net_dev, bus_id, bgmac_adjust_link,
+ PHY_INTERFACE_MODE_MII);
+ if (IS_ERR(phy_dev)) {
+ dev_err(bgmac->dev, "PHY connecton failed\n");
+ return PTR_ERR(phy_dev);
+ }
+
+ return 0;
+}
+
+static int bcma_phy_direct_connect(struct bgmac *bgmac)
+{
+ struct fixed_phy_status fphy_status = {
+ .link = 1,
+ .speed = SPEED_1000,
+ .duplex = DUPLEX_FULL,
+ };
+ struct phy_device *phy_dev;
+ int err;
+
+ phy_dev = fixed_phy_register(PHY_POLL, &fphy_status, -1, NULL);
+ if (!phy_dev || IS_ERR(phy_dev)) {
+ dev_err(bgmac->dev, "Failed to register fixed PHY device\n");
+ return -ENODEV;
+ }
+
+ err = phy_connect_direct(bgmac->net_dev, phy_dev, bgmac_adjust_link,
+ PHY_INTERFACE_MODE_MII);
+ if (err) {
+ dev_err(bgmac->dev, "Connecting PHY failed\n");
+ return err;
+ }
+
+ return err;
+}
+
static const struct bcma_device_id bgmac_bcma_tbl[] = {
BCMA_CORE(BCMA_MANUF_BCM, BCMA_CORE_4706_MAC_GBIT,
BCMA_ANY_REV, BCMA_ANY_CLASS),
@@ -275,6 +319,10 @@ static int bgmac_probe(struct bcma_device *core)
bgmac->cco_ctl_maskset = bcma_bgmac_cco_ctl_maskset;
bgmac->get_bus_clock = bcma_bgmac_get_bus_clock;
bgmac->cmn_maskset32 = bcma_bgmac_cmn_maskset32;
+ if (bgmac->mii_bus)
+ bgmac->phy_connect = bcma_phy_connect;
+ else
+ bgmac->phy_connect = bcma_phy_direct_connect;
err = bgmac_enet_probe(bgmac);
if (err)
diff --git a/drivers/net/ethernet/broadcom/bgmac-platform.c b/drivers/net/ethernet/broadcom/bgmac-platform.c
index be52f27..aed5dc5 100644
--- a/drivers/net/ethernet/broadcom/bgmac-platform.c
+++ b/drivers/net/ethernet/broadcom/bgmac-platform.c
@@ -16,6 +16,7 @@
#include <linux/bcma/bcma.h>
#include <linux/etherdevice.h>
#include <linux/of_address.h>
+#include <linux/of_mdio.h>
#include <linux/of_net.h>
#include "bgmac.h"
@@ -86,6 +87,46 @@ static void platform_bgmac_cmn_maskset32(struct bgmac *bgmac, u16 offset,
WARN_ON(1);
}
+static int platform_phy_connect(struct bgmac *bgmac)
+{
+ struct phy_device *phy_dev;
+
+ phy_dev = of_phy_get_and_connect(bgmac->net_dev, bgmac->dev->of_node,
+ bgmac_adjust_link);
+ if (!phy_dev) {
+ dev_err(bgmac->dev, "Phy connect failed\n");
+ return -ENODEV;
+ }
+
+ return 0;
+}
+
+static int platform_phy_direct_connect(struct bgmac *bgmac)
+{
+ struct fixed_phy_status fphy_status = {
+ .link = 1,
+ .speed = SPEED_1000,
+ .duplex = DUPLEX_FULL,
+ };
+ struct phy_device *phy_dev;
+ int err;
+
+ phy_dev = fixed_phy_register(PHY_POLL, &fphy_status, -1, NULL);
+ if (!phy_dev || IS_ERR(phy_dev)) {
+ dev_err(bgmac->dev, "Failed to register fixed PHY device\n");
+ return -ENODEV;
+ }
+
+ err = phy_connect_direct(bgmac->net_dev, phy_dev, bgmac_adjust_link,
+ PHY_INTERFACE_MODE_MII);
+ if (err) {
+ dev_err(bgmac->dev, "Connecting PHY failed\n");
+ return err;
+ }
+
+ return err;
+}
+
static int bgmac_probe(struct platform_device *pdev)
{
struct device_node *np = pdev->dev.of_node;
@@ -102,7 +143,6 @@ static int bgmac_probe(struct platform_device *pdev)
/* Set the features of the 4707 family */
bgmac->feature_flags |= BGMAC_FEAT_CLKCTLST;
bgmac->feature_flags |= BGMAC_FEAT_NO_RESET;
- bgmac->feature_flags |= BGMAC_FEAT_FORCE_SPEED_2500;
bgmac->feature_flags |= BGMAC_FEAT_CMDCFG_SR_REV4;
bgmac->feature_flags |= BGMAC_FEAT_TX_MASK_SETUP;
bgmac->feature_flags |= BGMAC_FEAT_RX_MASK_SETUP;
@@ -151,6 +191,12 @@ static int bgmac_probe(struct platform_device *pdev)
bgmac->cco_ctl_maskset = platform_bgmac_cco_ctl_maskset;
bgmac->get_bus_clock = platform_bgmac_get_bus_clock;
bgmac->cmn_maskset32 = platform_bgmac_cmn_maskset32;
+ if (of_parse_phandle(np, "phy-handle", 0)) {
+ bgmac->phy_connect = platform_phy_connect;
+ } else {
+ bgmac->phy_connect = platform_phy_direct_connect;
+ bgmac->feature_flags |= BGMAC_FEAT_FORCE_SPEED_2500;
+ }
return bgmac_enet_probe(bgmac);
}
diff --git a/drivers/net/ethernet/broadcom/bgmac.c b/drivers/net/ethernet/broadcom/bgmac.c
index 856379c..4584958 100644
--- a/drivers/net/ethernet/broadcom/bgmac.c
+++ b/drivers/net/ethernet/broadcom/bgmac.c
@@ -1388,7 +1388,7 @@ static const struct ethtool_ops bgmac_ethtool_ops = {
* MII
**************************************************/
-static void bgmac_adjust_link(struct net_device *net_dev)
+void bgmac_adjust_link(struct net_device *net_dev)
{
struct bgmac *bgmac = netdev_priv(net_dev);
struct phy_device *phy_dev = net_dev->phydev;
@@ -1411,50 +1411,7 @@ static void bgmac_adjust_link(struct net_device *net_dev)
phy_print_status(phy_dev);
}
}
-
-static int bgmac_phy_connect_direct(struct bgmac *bgmac)
-{
- struct fixed_phy_status fphy_status = {
- .link = 1,
- .speed = SPEED_1000,
- .duplex = DUPLEX_FULL,
- };
- struct phy_device *phy_dev;
- int err;
-
- phy_dev = fixed_phy_register(PHY_POLL, &fphy_status, -1, NULL);
- if (!phy_dev || IS_ERR(phy_dev)) {
- dev_err(bgmac->dev, "Failed to register fixed PHY device\n");
- return -ENODEV;
- }
-
- err = phy_connect_direct(bgmac->net_dev, phy_dev, bgmac_adjust_link,
- PHY_INTERFACE_MODE_MII);
- if (err) {
- dev_err(bgmac->dev, "Connecting PHY failed\n");
- return err;
- }
-
- return err;
-}
-
-static int bgmac_phy_connect(struct bgmac *bgmac)
-{
- struct phy_device *phy_dev;
- char bus_id[MII_BUS_ID_SIZE + 3];
-
- /* Connect to the PHY */
- snprintf(bus_id, sizeof(bus_id), PHY_ID_FMT, bgmac->mii_bus->id,
- bgmac->phyaddr);
- phy_dev = phy_connect(bgmac->net_dev, bus_id, &bgmac_adjust_link,
- PHY_INTERFACE_MODE_MII);
- if (IS_ERR(phy_dev)) {
- dev_err(bgmac->dev, "PHY connecton failed\n");
- return PTR_ERR(phy_dev);
- }
-
- return 0;
-}
+EXPORT_SYMBOL_GPL(bgmac_adjust_link);
int bgmac_enet_probe(struct bgmac *info)
{
@@ -1507,10 +1464,7 @@ int bgmac_enet_probe(struct bgmac *info)
netif_napi_add(net_dev, &bgmac->napi, bgmac_poll, BGMAC_WEIGHT);
- if (!bgmac->mii_bus)
- err = bgmac_phy_connect_direct(bgmac);
- else
- err = bgmac_phy_connect(bgmac);
+ err = bgmac_phy_connect(bgmac);
if (err) {
dev_err(bgmac->dev, "Cannot connect to phy\n");
goto err_dma_free;
diff --git a/drivers/net/ethernet/broadcom/bgmac.h b/drivers/net/ethernet/broadcom/bgmac.h
index 80836b4..ea52ac3 100644
--- a/drivers/net/ethernet/broadcom/bgmac.h
+++ b/drivers/net/ethernet/broadcom/bgmac.h
@@ -513,10 +513,12 @@ struct bgmac {
u32 (*get_bus_clock)(struct bgmac *bgmac);
void (*cmn_maskset32)(struct bgmac *bgmac, u16 offset, u32 mask,
u32 set);
+ int (*phy_connect)(struct bgmac *bgmac);
};
int bgmac_enet_probe(struct bgmac *info);
void bgmac_enet_remove(struct bgmac *bgmac);
+void bgmac_adjust_link(struct net_device *net_dev);
struct mii_bus *bcma_mdio_mii_register(struct bcma_device *core, u8 phyaddr);
void bcma_mdio_mii_unregister(struct mii_bus *mii_bus);
@@ -583,4 +585,9 @@ static inline void bgmac_set(struct bgmac *bgmac, u16 offset, u32 set)
{
bgmac_maskset(bgmac, offset, ~0, set);
}
+
+static inline int bgmac_phy_connect(struct bgmac *bgmac)
+{
+ return bgmac->phy_connect(bgmac);
+}
#endif /* _BGMAC_H */
--
2.7.4
^ permalink raw reply related
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