* Re: [PATCH] dt-bindings: eeprom: at24: Fix list of page sizes for writing
From: Wolfram Sang @ 2020-05-15 9:36 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Bartosz Golaszewski, Rob Herring, linux-i2c, devicetree
In-Reply-To: <20200515092755.GC2077@ninjato>
[-- Attachment #1: Type: text/plain, Size: 664 bytes --]
On Fri, May 15, 2020 at 11:27:55AM +0200, Wolfram Sang wrote:
> On Tue, May 12, 2020 at 02:24:47PM +0200, Geert Uytterhoeven wrote:
> > "258" is an odd power-of-two ;-)
> > Obviously this is a typo, and the intended value is "256".
> >
> > Fixes: 7f3bf4203774013b ("dt-bindings: at24: convert the binding document to yaml")
> > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
>
> Since I have a PR for Linus pending anyhow, I step ahead and apply it to
> my tree. Hope this is fine for everyone. Applied to for-current, thanks!
Brown paper bag, please. This is in -next only, so I rather leave it for
Rob because of the dependencies.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [Linux-stm32] [PATCH v3 3/5] ARM: dts: stm32: enable ltdc binding with ili9341 on stm32429-disco board
From: Benjamin GAIGNARD @ 2020-05-15 9:34 UTC (permalink / raw)
To: dillon min
Cc: Alexandre TORGUE,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Daniel Vetter, Dave Airlie, Linus Walleij, linux-clk,
linux-kernel@vger.kernel.org, open list:DRM PANEL DRIVERS,
linux-stm32@st-md-mailman.stormreply.com, Stephen Boyd,
Rob Herring, thierry.reding@gmail.com, Maxime Coquelin,
Sam Ravnborg, Michael Turquette, Linux ARM
In-Reply-To: <CAL9mu0L6d2V5qypPfOSeMdhc=DdHkcsaF4GysNG-vfDe5npkhw@mail.gmail.com>
On 5/15/20 11:24 AM, dillon min wrote:
> Hi Benjamin,
>
> thanks for reply.
>
> On Fri, May 15, 2020 at 4:31 PM Benjamin GAIGNARD
> <benjamin.gaignard@st.com> wrote:
>>
>>
>> On 5/14/20 3:07 PM, dillon min wrote:
>>> Hi Alexandre,
>>>
>>> On Thu, May 14, 2020 at 8:53 PM Alexandre Torgue
>>> <alexandre.torgue@st.com> wrote:
>>>>
>>>> On 5/14/20 10:24 AM, Linus Walleij wrote:
>>>>> On Tue, May 12, 2020 at 9:04 AM <dillon.minfei@gmail.com> wrote:
>>>>>
>>>>>> From: dillon min <dillon.minfei@gmail.com>
>>>>>>
>>>>>> Enable the ltdc & ili9341 on stm32429-disco board.
>>>>>>
>>>>>> Signed-off-by: dillon min <dillon.minfei@gmail.com>
>>>>> This mostly looks good but...
>>>>>
>>>>>> +&spi5 {
>>>>>> + status = "okay";
>>>>>> + pinctrl-0 = <&spi5_pins>;
>>>>>> + pinctrl-names = "default";
>>>>>> + #address-cells = <1>;
>>>>>> + #size-cells = <0>;
>>>>>> + cs-gpios = <&gpioc 2 GPIO_ACTIVE_LOW>;
>>>>>> + dmas = <&dma2 3 2 0x400 0x0>,
>>>>>> + <&dma2 4 2 0x400 0x0>;
>>>>>> + dma-names = "rx", "tx";
>>>>> These DMA assignments seem to be SoC things and should
>>>>> rather be in the DTS(I) file where &spi5 is defined, right?
>>>>> stm32f429.dtsi I suppose?
>>>> I agree with Linus, DMA have to be defined in SoC dtsi. And if a board
>>>> doesn't want to use it, we use the "delete-property".
>>> Yes, will move to Soc dtsi in next submits.
>>>
>>> i'm working on write a v4l2-m2m driver for dma2d of stm32 to support
>>> pixel conversion
>>> alpha blending between foreground and background graphics.
>>>
>>> as you know, some soc's engineer trying to add this function to drm system.
>>>
>>> do you know st's planning about soc's hardware accelerator driver on stm32mp?
>>> such as chrom-art, will add to drm subsystem via ioctl to access, or to v4l2,
>> On stm32mp we do not plan to use chrom-art in drm or v4l2 because it
>> does fit
>> with userland way of working. We use the GPU to do conversion, scaling,
>> blending
>> and composition in only one go.
>> As explain here [1] DRM subsytem it isn't a solution and v4l2-m2m isn't
>> used in any
>> mainline compositors like Weston or android surfaceflinger.
>>
>> Benjamin
>>
> After check stm32mp's datasheets, they don't have chrom-art ip inside. sorry for
> didn't check it yet.
>
> for stm32h7 series with chrom-art, jpeg hardware accelerator inside.
> does st has plan to
> setup a driver to support it ? i prefer v4l2-m2m should be easier to
> implement it.
> co work with dcmi, fbdev.
ST doesn't plan to create a driver for chrom-art because nothing in
mainline
userland could use it.
Benjamin
>
> thanks.
>
> best regards.
>
> Dillon
>> [1]
>> https://www.phoronix.com/scan.php?page=news_item&px=Linux-DRM-No-2D-Accel-API
>>> thanks.
>>>
>>>>> It is likely the same no matter which device is using spi5.
>>>>>
>>>>> Yours,
>>>>> Linus Walleij
>>>>>
>>> _______________________________________________
>>> Linux-stm32 mailing list
>>> Linux-stm32@st-md-mailman.stormreply.com
>>> https://st-md-mailman.stormreply.com/mailman/listinfo/linux-stm32
^ permalink raw reply
* Re: [PATCH v2] arm: dts: Move am33xx and am43xx mmc nodes to sdhci-omap driver
From: Faiz Abbas @ 2020-05-15 9:34 UTC (permalink / raw)
To: Tony Lindgren, Keerthy
Cc: linux-kernel, devicetree, linux-omap, robh+dt, bcousson,
Tomi Valkeinen
In-Reply-To: <20200513162327.GM37466@atomide.com>
Hi Tony,
On 13/05/20 9:53 pm, Tony Lindgren wrote:
> * Faiz Abbas <faiz_abbas@ti.com> [200512 13:39]:
>> Move mmc nodes to be compatible with the sdhci-omap driver. The following
>> modifications are required for omap_hsmmc specific properties:
>>
>> ti,non-removable: convert to the generic mmc non-removable
>> ti,needs-special-reset: co-opted into the sdhci-omap driver
>> ti,dual-volt: removed. Legacy property not used in am335x or am43xx
>> ti,needs-special-hs-handling: removed. Legacy property not used in am335x
>> or am43xx
>>
>> Also since the sdhci-omap driver does not support runtime PM, explicitly
>> disable the mmc3 instance in the dtsi.
>>
>> Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
>> ---
>>
>> v2: Rebased to latest mainline where all kernel dependancies have been merged.
>>
>> Suspend/Resume is now supported in the sdhci-omap driver.
>
> Great, thanks for updating it.
>
> Keerthy, care to test for am3 and am4?
>
Suspend/resume on am43xx-gpevm is broken right now in mainline and the regression looks
like it is caused by the display subsystem. I have reported this to Tomi and
its being investigated.
Meanwhile I have tested this patch with display configs disabled and Keerthy's
suspend/resume tests pass on both am3 and am4.
Thanks,
Faiz
^ permalink raw reply
* Re: [RFC][PATCH 3/4] dma-buf: cma_heap: Extend logic to export CMA regions tagged with "linux,cma-heap"
From: Brian Starkey @ 2020-05-15 9:32 UTC (permalink / raw)
To: Rob Herring
Cc: John Stultz, Robin Murphy, lkml, Sumit Semwal, Andrew F. Davis,
Benjamin Gaignard, Liam Mark, Pratik Patel, Laura Abbott,
Chenbo Feng, Alistair Strachan, Sandeep Patil, Hridya Valsaraju,
Christoph Hellwig, Marek Szyprowski, Andrew Morton,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
dri-devel, linux-mm, nd
In-Reply-To: <CAL_Jsq+V-YA9B7i+9U0as3oXNC=HLPHmZ2NrPzNJu5CXpvD3tg@mail.gmail.com>
On Thu, May 14, 2020 at 09:52:35AM -0500, Rob Herring wrote:
> On Wed, May 13, 2020 at 5:44 AM Brian Starkey <brian.starkey@arm.com> wrote:
> >
> > Hi Rob,
> >
> > On Tue, May 12, 2020 at 11:37:14AM -0500, Rob Herring wrote:
> > > On Mon, May 04, 2020 at 10:06:28AM +0100, Brian Starkey wrote:
> > > > On Fri, May 01, 2020 at 12:01:40PM -0700, John Stultz wrote:
> > > > > On Fri, May 1, 2020 at 4:08 AM Robin Murphy <robin.murphy@arm.com> wrote:
> > > > > >
> > > > > > On 2020-05-01 11:21 am, Brian Starkey wrote:
> > > > > > > Hi John,
> > > > > > >
> > > > > > > On Fri, May 01, 2020 at 07:39:48AM +0000, John Stultz wrote:
> > > > > > >> This patch reworks the cma_heap initialization so that
> > > > > > >> we expose both the default CMA region and any CMA regions
> > > > > > >> tagged with "linux,cma-heap" in the device-tree.
> > > > > > >>
> > > > > > >> Cc: Rob Herring <robh+dt@kernel.org>
> > > > > > >> Cc: Sumit Semwal <sumit.semwal@linaro.org>
> > > > > > >> Cc: "Andrew F. Davis" <afd@ti.com>
> > > > > > >> Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org>
> > > > > > >> Cc: Liam Mark <lmark@codeaurora.org>
> > > > > > >> Cc: Pratik Patel <pratikp@codeaurora.org>
> > > > > > >> Cc: Laura Abbott <labbott@redhat.com>
> > > > > > >> Cc: Brian Starkey <Brian.Starkey@arm.com>
> > > > > > >> Cc: Chenbo Feng <fengc@google.com>
> > > > > > >> Cc: Alistair Strachan <astrachan@google.com>
> > > > > > >> Cc: Sandeep Patil <sspatil@google.com>
> > > > > > >> Cc: Hridya Valsaraju <hridya@google.com>
> > > > > > >> Cc: Christoph Hellwig <hch@lst.de>
> > > > > > >> Cc: Marek Szyprowski <m.szyprowski@samsung.com>
> > > > > > >> Cc: Robin Murphy <robin.murphy@arm.com>
> > > > > > >> Cc: Andrew Morton <akpm@linux-foundation.org>
> > > > > > >> Cc: devicetree@vger.kernel.org
> > > > > > >> Cc: dri-devel@lists.freedesktop.org
> > > > > > >> Cc: linux-mm@kvack.org
> > > > > > >> Signed-off-by: John Stultz <john.stultz@linaro.org>
> > > > > > >> ---
> > > > > > >> drivers/dma-buf/heaps/cma_heap.c | 18 +++++++++---------
> > > > > > >> 1 file changed, 9 insertions(+), 9 deletions(-)
> > > > > > >>
> > > > > > >> diff --git a/drivers/dma-buf/heaps/cma_heap.c b/drivers/dma-buf/heaps/cma_heap.c
> > > > > > >> index 626cf7fd033a..dd154e2db101 100644
> > > > > > >> --- a/drivers/dma-buf/heaps/cma_heap.c
> > > > > > >> +++ b/drivers/dma-buf/heaps/cma_heap.c
> > > > > > >> @@ -141,6 +141,11 @@ static int __add_cma_heap(struct cma *cma, void *data)
> > > > > > >> {
> > > > > > >> struct cma_heap *cma_heap;
> > > > > > >> struct dma_heap_export_info exp_info;
> > > > > > >> + struct cma *default_cma = dev_get_cma_area(NULL);
> > > > > > >> +
> > > > > > >> + /* We only add the default heap and explicitly tagged heaps */
> > > > > > >> + if (cma != default_cma && !cma_dma_heap_enabled(cma))
> > > > > > >> + return 0;
> > > > > > >
> > > > > > > Thinking about the pl111 thread[1], I'm wondering if we should also
> > > > > > > let drivers call this directly to expose their CMA pools, even if they
> > > > > > > aren't tagged for dma-heaps in DT. But perhaps that's too close to
> > > > > > > policy.
> > > > > >
> > > > > > That sounds much like what my first thoughts were - apologies if I'm
> > > > > > wildly off-base here, but as far as I understand:
> > > > > >
> > > > > > - Device drivers know whether they have their own "memory-region" or not.
> > > > > > - Device drivers already have to do *something* to participate in dma-buf.
> > > > > > - Device drivers know best how they make use of both the above.
> > > > > > - Therefore couldn't it be left to drivers to choose whether to register
> > > > > > their CMA regions as heaps, without having to mess with DT at all?
> > >
> > > +1, but I'm biased toward any solution not using DT. :)
> > >
> > > > > I guess I'm not opposed to this. But I guess I'd like to see some more
> > > > > details? You're thinking the pl111 driver would add the
> > > > > "memory-region" node itself?
> > > > >
> > > > > Assuming that's the case, my only worry is what if that memory-region
> > > > > node isn't a CMA area, but instead something like a carveout? Does the
> > > > > driver need to parse enough of the dt to figure out where to register
> > > > > the region as a heap?
> > > >
> > > > My thinking was more like there would already be a reserved-memory
> > > > node in DT for the chunk of memory, appropriately tagged so that it
> > > > gets added as a CMA region.
> > > >
> > > > The device's node would have "memory-region=<&blah>;" and would use
> > > > of_reserved_mem_device_init() to link up dev->cma_area to the
> > > > corresponding cma region.
> > > >
> > > > So far, that's all in-place already. The bit that's missing is
> > > > exposing that dev->cma_area to userspace as a dma_heap - so we could
> > > > just have "int cma_heap_add(struct cma *cma)" or "int
> > > > cma_heap_dev_add(struct device *dev)" or something exported for
> > > > drivers to expose their device-assigned cma region if they wanted to.
> > > >
> > > > I don't think this runs into the lifetime problems of generalised
> > > > heaps-as-modules either, because the CMA region will never go away
> > > > even if the driver does.
> > > >
> > > > Alongside that, I do think the completely DT-driven approach can be
> > > > useful too - because there may be regions which aren't associated with
> > > > any specific device driver, that we want exported as heaps.
> > >
> > > And they are associated with the hardware description rather than the
> > > userspace environment?
> >
> > I'm not sure how to answer that. We already have CMA regions being
> > created from device-tree, so we're only talking about explicitly
> > exposing those to userspace.
>
> It's easier to argue that how much CMA memory a system/device needs is
> h/w description as that's more a function of devices and frame sizes.
> But exposing to userspace or not is an OS architecture decision. It's
> not really any different than a kernel vs. userspace driver question.
> What's exposed by UIO or spi-dev is purely a kernel thing.
>
> > Are you thinking that userspace should be deciding whether they get
> > exposed or not? I don't know how userspace would discover them in
> > order to make that decision.
>
> Or perhaps the kernel should be deciding. Expose to userspace what the
> kernel doesn't need or drivers decide?
If not via device-tree how would the kernel make that decision? For
regions which get "claimed" by a device/driver, obviously that driver
can make the decision, and I totally think we should provide a way for
them to expose it.
But for something like a shared pool amongst the media subsystem,
there may not be any specific single device/driver - and creating a
dummy driver with the sole purpose of exposing the heap doesn't seem
like an improvement over a simple "linux,cma-heap".
Cheers,
-Brian
>
> It's hard to argue against 1 new property. It's death by a 1000 cuts though.
>
> Rob
^ permalink raw reply
* Re: [PATCH v4 3/9] usb: dwc3: Increase timeout for CmdAct cleared by device controller
From: Felipe Balbi @ 2020-05-15 9:31 UTC (permalink / raw)
To: Jun Li
Cc: John Stultz, lkml, Yu Chen, Greg Kroah-Hartman, Rob Herring,
Mark Rutland, ShuFan Lee, Heikki Krogerus, Suzuki K Poulose,
Chunfeng Yun, Hans de Goede, Andy Shevchenko, Valentin Schneider,
Jack Pham, Linux USB List,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
peter.chen, Li Jun, Thinh Nguyen
In-Reply-To: <CAKgpwJXfWv5=MDqBCADhe2iXf6eiP0GQ13Bwo9fkuU5kGO7dsw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1204 bytes --]
Hi,
Jun Li <lijun.kernel@gmail.com> writes:
>> @@ -397,12 +407,18 @@ int dwc3_send_gadget_ep_cmd(struct dwc3_ep *dep, unsigned cmd,
>> dwc3_gadget_ep_get_transfer_index(dep);
>> }
>>
>> - if (saved_config) {
>> + if (saved_hs_config) {
>> reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0));
>> - reg |= saved_config;
>> + reg |= saved_hs_config;
>> dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg);
>> }
>>
>> + if (saved_ss_config) {
>> + reg = dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(0));
>> + reg |= saved_ss_config;
>> + dwc3_writel(dwc->regs, DWC3_GUSB3PIPECTL(0), reg);
>> + }
>> +
>> return ret;
>> }
>
> Unfortunately this way can't work, once the SS PHY enters P3, disable
> suspend_en can't force SS PHY exit P3, unless do this at the very beginning
> to prevent SS PHY entering P3(e.g. add "snps,dis_u3_susphy_quirk" for test).
It sounds like you have a quirky PHY. If that's the case, then you
probably need to use the flag you mentioned above. Please verify with
that.
--
balbi
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply
* [PATCH v6 1/2] dt-bindings: usb: qcom,dwc3: Convert USB DWC3 bindings
From: Sandeep Maheswaram @ 2020-05-15 9:29 UTC (permalink / raw)
To: Andy Gross, Bjorn Andersson, Greg Kroah-Hartman, Rob Herring,
Mark Rutland, Felipe Balbi, Stephen Boyd, Doug Anderson,
Matthias Kaehlcke
Cc: linux-arm-msm, linux-usb, devicetree, linux-kernel, Manu Gautam,
Sandeep Maheswaram
In-Reply-To: <1589534960-6973-1-git-send-email-sanm@codeaurora.org>
Convert USB DWC3 bindings to DT schema format using json-schema.
Signed-off-by: Sandeep Maheswaram <sanm@codeaurora.org>
---
.../devicetree/bindings/usb/qcom,dwc3.txt | 104 -------------
.../devicetree/bindings/usb/qcom,dwc3.yaml | 162 +++++++++++++++++++++
2 files changed, 162 insertions(+), 104 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/usb/qcom,dwc3.txt
create mode 100644 Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
diff --git a/Documentation/devicetree/bindings/usb/qcom,dwc3.txt b/Documentation/devicetree/bindings/usb/qcom,dwc3.txt
deleted file mode 100644
index fbdd017..0000000
--- a/Documentation/devicetree/bindings/usb/qcom,dwc3.txt
+++ /dev/null
@@ -1,104 +0,0 @@
-Qualcomm SuperSpeed DWC3 USB SoC controller
-
-Required properties:
-- compatible: Compatible list, contains
- "qcom,dwc3"
- "qcom,msm8996-dwc3" for msm8996 SOC.
- "qcom,msm8998-dwc3" for msm8998 SOC.
- "qcom,sdm845-dwc3" for sdm845 SOC.
-- reg: Offset and length of register set for QSCRATCH wrapper
-- power-domains: specifies a phandle to PM domain provider node
-- clocks: A list of phandle + clock-specifier pairs for the
- clocks listed in clock-names
-- clock-names: Should contain the following:
- "core" Master/Core clock, have to be >= 125 MHz for SS
- operation and >= 60MHz for HS operation
- "mock_utmi" Mock utmi clock needed for ITP/SOF generation in
- host mode. Its frequency should be 19.2MHz.
- "sleep" Sleep clock, used for wakeup when USB3 core goes
- into low power mode (U3).
-
-Optional clocks:
- "iface" System bus AXI clock.
- Not present on "qcom,msm8996-dwc3" compatible.
- "cfg_noc" System Config NOC clock.
- Not present on "qcom,msm8996-dwc3" compatible.
-- assigned-clocks: Should be:
- MOCK_UTMI_CLK
- MASTER_CLK
-- assigned-clock-rates: Should be:
- 19.2Mhz (192000000) for MOCK_UTMI_CLK
- >=125Mhz (125000000) for MASTER_CLK in SS mode
- >=60Mhz (60000000) for MASTER_CLK in HS mode
-
-Optional properties:
-- resets: Phandle to reset control that resets core and wrapper.
-- interrupts: specifies interrupts from controller wrapper used
- to wakeup from low power/susepnd state. Must contain
- one or more entry for interrupt-names property
-- interrupt-names: Must include the following entries:
- - "hs_phy_irq": The interrupt that is asserted when a
- wakeup event is received on USB2 bus
- - "ss_phy_irq": The interrupt that is asserted when a
- wakeup event is received on USB3 bus
- - "dm_hs_phy_irq" and "dp_hs_phy_irq": Separate
- interrupts for any wakeup event on DM and DP lines
-- qcom,select-utmi-as-pipe-clk: if present, disable USB3 pipe_clk requirement.
- Used when dwc3 operates without SSPHY and only
- HS/FS/LS modes are supported.
-
-Required child node:
-A child node must exist to represent the core DWC3 IP block. The name of
-the node is not important. The content of the node is defined in dwc3.txt.
-
-Phy documentation is provided in the following places:
-Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt - USB3 QMP PHY
-Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml - USB2 QUSB2 PHY
-
-Example device nodes:
-
- hs_phy: phy@100f8800 {
- compatible = "qcom,qusb2-v2-phy";
- ...
- };
-
- ss_phy: phy@100f8830 {
- compatible = "qcom,qmp-v3-usb3-phy";
- ...
- };
-
- usb3_0: usb30@a6f8800 {
- compatible = "qcom,dwc3";
- reg = <0xa6f8800 0x400>;
- #address-cells = <1>;
- #size-cells = <1>;
- ranges;
-
- interrupts = <0 131 0>, <0 486 0>, <0 488 0>, <0 489 0>;
- interrupt-names = "hs_phy_irq", "ss_phy_irq",
- "dm_hs_phy_irq", "dp_hs_phy_irq";
-
- clocks = <&gcc GCC_USB30_PRIM_MASTER_CLK>,
- <&gcc GCC_USB30_PRIM_MOCK_UTMI_CLK>,
- <&gcc GCC_USB30_PRIM_SLEEP_CLK>;
- clock-names = "core", "mock_utmi", "sleep";
-
- assigned-clocks = <&gcc GCC_USB30_PRIM_MOCK_UTMI_CLK>,
- <&gcc GCC_USB30_PRIM_MASTER_CLK>;
- assigned-clock-rates = <19200000>, <133000000>;
-
- resets = <&gcc GCC_USB30_PRIM_BCR>;
- reset-names = "core_reset";
- power-domains = <&gcc USB30_PRIM_GDSC>;
- qcom,select-utmi-as-pipe-clk;
-
- dwc3@10000000 {
- compatible = "snps,dwc3";
- reg = <0x10000000 0xcd00>;
- interrupts = <0 205 0x4>;
- phys = <&hs_phy>, <&ss_phy>;
- phy-names = "usb2-phy", "usb3-phy";
- dr_mode = "host";
- };
- };
-
diff --git a/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml b/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
new file mode 100644
index 0000000..074d3cc
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
@@ -0,0 +1,162 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/qcom,dwc3.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SuperSpeed DWC3 USB SoC controller
+
+maintainers:
+ - Manu Gautam <mgautam@codeaurora.org>
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - qcom,msm8996-dwc3
+ - qcom,msm8998-dwc3
+ - qcom,sdm845-dwc3
+ - const: qcom,dwc3
+
+ reg:
+ description: Offset and length of register set for QSCRATCH wrapper
+ maxItems: 1
+
+ "#address-cells":
+ enum: [ 1, 2 ]
+
+ "#size-cells":
+ enum: [ 1, 2 ]
+
+ ranges: true
+
+ power-domains:
+ description: specifies a phandle to PM domain provider node
+ maxItems: 1
+
+ clocks:
+ description:
+ A list of phandle and clock-specifier pairs for the clocks
+ listed in clock-names.
+ items:
+ - description: System Config NOC clock.
+ - description: Master/Core clock, has to be >= 125 MHz
+ for SS operation and >= 60MHz for HS operation.
+ - description: System bus AXI clock.
+ - description: Mock utmi clock needed for ITP/SOF generation
+ in host mode. Its frequency should be 19.2MHz.
+ - description: Sleep clock, used for wakeup when
+ USB3 core goes into low power mode (U3).
+
+ clock-names:
+ items:
+ - const: cfg_noc
+ - const: core
+ - const: iface
+ - const: mock_utmi
+ - const: sleep
+
+ assigned-clocks:
+ items:
+ - description: Phandle and clock specifier of MOCK_UTMI_CLK.
+ - description: Phandle and clock specifoer of MASTER_CLK.
+
+ assigned-clock-rates:
+ items:
+ - description: Must be 19.2MHz (19200000).
+ - description: Must be >= 60 MHz in HS mode, >= 125 MHz in SS mode.
+ resets:
+ maxItems: 1
+
+ interrupts:
+ items:
+ - description: The interrupt that is asserted
+ when a wakeup event is received on USB2 bus.
+ - description: The interrupt that is asserted
+ when a wakeup event is received on USB3 bus.
+ - description: Wakeup event on DM line.
+ - description: Wakeup event on DP line.
+
+ interrupt-names:
+ items:
+ - const: hs_phy_irq
+ - const: ss_phy_irq
+ - const: dm_hs_phy_irq
+ - const: dp_hs_phy_irq
+
+ qcom,select-utmi-as-pipe-clk:
+ description:
+ If present, disable USB3 pipe_clk requirement.
+ Used when dwc3 operates without SSPHY and only
+ HS/FS/LS modes are supported.
+ type: boolean
+
+# Required child node:
+
+patternProperties:
+ "^dwc3@[0-9a-f]+$":
+ type: object
+ description:
+ A child node must exist to represent the core DWC3 IP block
+ The content of the node is defined in dwc3.txt.
+
+required:
+ - compatible
+ - reg
+ - "#address-cells"
+ - "#size-cells"
+ - ranges
+ - power-domains
+ - clocks
+ - clock-names
+ - interrupts
+ - interrupt-names
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,gcc-sdm845.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ usb@a6f8800 {
+ compatible = "qcom,sdm845-dwc3", "qcom,dwc3";
+ reg = <0 0x0a6f8800 0 0x400>;
+
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ clocks = <&gcc GCC_CFG_NOC_USB3_PRIM_AXI_CLK>,
+ <&gcc GCC_USB30_PRIM_MASTER_CLK>,
+ <&gcc GCC_AGGRE_USB3_PRIM_AXI_CLK>,
+ <&gcc GCC_USB30_PRIM_MOCK_UTMI_CLK>,
+ <&gcc GCC_USB30_PRIM_SLEEP_CLK>;
+ clock-names = "cfg_noc", "core", "iface", "mock_utmi",
+ "sleep";
+
+ assigned-clocks = <&gcc GCC_USB30_PRIM_MOCK_UTMI_CLK>,
+ <&gcc GCC_USB30_PRIM_MASTER_CLK>;
+ assigned-clock-rates = <19200000>, <150000000>;
+
+ interrupts = <GIC_SPI 131 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 486 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 488 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 489 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "hs_phy_irq", "ss_phy_irq",
+ "dm_hs_phy_irq", "dp_hs_phy_irq";
+
+ power-domains = <&gcc USB30_PRIM_GDSC>;
+
+ resets = <&gcc GCC_USB30_PRIM_BCR>;
+
+ dwc3@a600000 {
+ compatible = "snps,dwc3";
+ reg = <0 0x0a600000 0 0xcd00>;
+ interrupts = <GIC_SPI 133 IRQ_TYPE_LEVEL_HIGH>;
+ iommus = <&apps_smmu 0x740 0>;
+ snps,dis_u2_susphy_quirk;
+ snps,dis_enblslpm_quirk;
+ phys = <&usb_1_hsphy>, <&usb_1_ssphy>;
+ phy-names = "usb2-phy", "usb3-phy";
+ };
+ };
+
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply related
* [PATCH v6 0/2] Add USB DWC3 support for SC7180
From: Sandeep Maheswaram @ 2020-05-15 9:29 UTC (permalink / raw)
To: Andy Gross, Bjorn Andersson, Greg Kroah-Hartman, Rob Herring,
Mark Rutland, Felipe Balbi, Stephen Boyd, Doug Anderson,
Matthias Kaehlcke
Cc: linux-arm-msm, linux-usb, devicetree, linux-kernel, Manu Gautam,
Sandeep Maheswaram
Converting dt binding to yaml.
Adding compatible for SC7180 in dt bindings.
Changes in v6:
Addressed the comments from Stephen on interrupts.
Added ranges property and dropped maxItems field for assigned-clock-rates.
Changes in v5:
Addressed the comments from Stephen in yaml file.
Changes in v4:
Addressed the comments from Doug in yaml file.
Changes in v3:
Dropped the patch for adding the compatible in dwc3 driver from the series.
Addressed the comments from Doug in yaml file.
Changes in v2:
Sorted the compatible in dwc3 driver.
Converted dt binding to yaml.
Added compatible in yaml.
Sandeep Maheswaram (2):
dt-bindings: usb: qcom,dwc3: Convert USB DWC3 bindings
dt-bindings: usb: qcom,dwc3: Add compatible for SC7180
.../devicetree/bindings/usb/qcom,dwc3.txt | 104 -------------
.../devicetree/bindings/usb/qcom,dwc3.yaml | 163 +++++++++++++++++++++
2 files changed, 163 insertions(+), 104 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/usb/qcom,dwc3.txt
create mode 100644 Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply
* [PATCH v6 2/2] dt-bindings: usb: qcom,dwc3: Add compatible for SC7180
From: Sandeep Maheswaram @ 2020-05-15 9:29 UTC (permalink / raw)
To: Andy Gross, Bjorn Andersson, Greg Kroah-Hartman, Rob Herring,
Mark Rutland, Felipe Balbi, Stephen Boyd, Doug Anderson,
Matthias Kaehlcke
Cc: linux-arm-msm, linux-usb, devicetree, linux-kernel, Manu Gautam,
Sandeep Maheswaram
In-Reply-To: <1589534960-6973-1-git-send-email-sanm@codeaurora.org>
Add compatible for SC7180 in usb dwc3 bindings.
Signed-off-by: Sandeep Maheswaram <sanm@codeaurora.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Acked-by: Rob Herring <robh@kernel.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
---
Documentation/devicetree/bindings/usb/qcom,dwc3.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml b/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
index 074d3cc..1a2bb6f 100644
--- a/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
+++ b/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
@@ -16,6 +16,7 @@ properties:
- enum:
- qcom,msm8996-dwc3
- qcom,msm8998-dwc3
+ - qcom,sc7180-dwc3
- qcom,sdm845-dwc3
- const: qcom,dwc3
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply related
* Re: [PATCH 5/5] PCI: uniphier: Add error message when failed to get phy
From: Kunihiko Hayashi @ 2020-05-15 9:28 UTC (permalink / raw)
To: Bjorn Helgaas, Lorenzo Pieralisi, Jingoo Han, Gustavo Pimentel,
Rob Herring, Masahiro Yamada
Cc: linux-pci, devicetree, linux-arm-kernel, linux-kernel,
Masami Hiramatsu, Jassi Brar
In-Reply-To: <202005151454.wRtXzaiY%lkp@intel.com>
On 2020/05/15 15:51, kbuild test robot wrote:
> Hi Kunihiko,
>
> I love your patch! Perhaps something to improve:
>
> [auto build test WARNING on pci/next]
> [also build test WARNING on robh/for-next v5.7-rc5 next-20200514]
> [if your patch is applied to the wrong git tree, please drop us a note to help
> improve the system. BTW, we also suggest to use '--base' option to specify the
> base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
>
> url: https://github.com/0day-ci/linux/commits/Kunihiko-Hayashi/PCI-uniphier-Add-features-for-UniPhier-PCIe-host-controller/20200515-125031
> base: https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git next
> config: i386-allyesconfig (attached as .config)
> compiler: gcc-7 (Ubuntu 7.5.0-6ubuntu2) 7.5.0
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=i386
>
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kbuild test robot <lkp@intel.com>
>
> All warnings (new ones prefixed by >>, old ones prefixed by <<):
>
> In file included from include/linux/device.h:15:0,
> from include/linux/pci.h:37,
> from drivers/pci/controller/dwc/pcie-uniphier.c:18:
> drivers/pci/controller/dwc/pcie-uniphier.c: In function 'uniphier_pcie_probe':
>>> drivers/pci/controller/dwc/pcie-uniphier.c:470:16: warning: format '%d' expects argument of type 'int', but argument 3 has type 'long int' [-Wformat=]
> dev_err(dev, "Failed to get phy (%d)n", PTR_ERR(priv->phy));
> ^
> include/linux/dev_printk.h:19:22: note: in definition of macro 'dev_fmt'
> #define dev_fmt(fmt) fmt
> ^~~
>>> drivers/pci/controller/dwc/pcie-uniphier.c:470:3: note: in expansion of macro 'dev_err'
> dev_err(dev, "Failed to get phy (%d)n", PTR_ERR(priv->phy));
> ^~~~~~~
This should be fixed. I'll fix it in v2.
Thanks,
---
Best Regards
Kunihiko Hayashi
^ permalink raw reply
* Re: [PATCH] dt-bindings: eeprom: at24: Fix list of page sizes for writing
From: Wolfram Sang @ 2020-05-15 9:27 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Bartosz Golaszewski, Rob Herring, linux-i2c, devicetree
In-Reply-To: <20200512122450.20205-1-geert+renesas@glider.be>
[-- Attachment #1: Type: text/plain, Size: 473 bytes --]
On Tue, May 12, 2020 at 02:24:47PM +0200, Geert Uytterhoeven wrote:
> "258" is an odd power-of-two ;-)
> Obviously this is a typo, and the intended value is "256".
>
> Fixes: 7f3bf4203774013b ("dt-bindings: at24: convert the binding document to yaml")
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Since I have a PR for Linus pending anyhow, I step ahead and apply it to
my tree. Hope this is fine for everyone. Applied to for-current, thanks!
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [Linux-stm32] [PATCH v3 3/5] ARM: dts: stm32: enable ltdc binding with ili9341 on stm32429-disco board
From: dillon min @ 2020-05-15 9:24 UTC (permalink / raw)
To: Benjamin GAIGNARD
Cc: Alexandre TORGUE,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Daniel Vetter, Dave Airlie, Linus Walleij, linux-clk,
linux-kernel@vger.kernel.org, open list:DRM PANEL DRIVERS,
linux-stm32@st-md-mailman.stormreply.com, Stephen Boyd,
Rob Herring, thierry.reding@gmail.com, Maxime Coquelin,
Sam Ravnborg, Michael Turquette, Linux ARM
In-Reply-To: <818b93b4-4431-8338-cd90-ed125ecac615@st.com>
Hi Benjamin,
thanks for reply.
On Fri, May 15, 2020 at 4:31 PM Benjamin GAIGNARD
<benjamin.gaignard@st.com> wrote:
>
>
>
> On 5/14/20 3:07 PM, dillon min wrote:
> > Hi Alexandre,
> >
> > On Thu, May 14, 2020 at 8:53 PM Alexandre Torgue
> > <alexandre.torgue@st.com> wrote:
> >>
> >>
> >> On 5/14/20 10:24 AM, Linus Walleij wrote:
> >>> On Tue, May 12, 2020 at 9:04 AM <dillon.minfei@gmail.com> wrote:
> >>>
> >>>> From: dillon min <dillon.minfei@gmail.com>
> >>>>
> >>>> Enable the ltdc & ili9341 on stm32429-disco board.
> >>>>
> >>>> Signed-off-by: dillon min <dillon.minfei@gmail.com>
> >>> This mostly looks good but...
> >>>
> >>>> +&spi5 {
> >>>> + status = "okay";
> >>>> + pinctrl-0 = <&spi5_pins>;
> >>>> + pinctrl-names = "default";
> >>>> + #address-cells = <1>;
> >>>> + #size-cells = <0>;
> >>>> + cs-gpios = <&gpioc 2 GPIO_ACTIVE_LOW>;
> >>>> + dmas = <&dma2 3 2 0x400 0x0>,
> >>>> + <&dma2 4 2 0x400 0x0>;
> >>>> + dma-names = "rx", "tx";
> >>> These DMA assignments seem to be SoC things and should
> >>> rather be in the DTS(I) file where &spi5 is defined, right?
> >>> stm32f429.dtsi I suppose?
> >> I agree with Linus, DMA have to be defined in SoC dtsi. And if a board
> >> doesn't want to use it, we use the "delete-property".
> > Yes, will move to Soc dtsi in next submits.
> >
> > i'm working on write a v4l2-m2m driver for dma2d of stm32 to support
> > pixel conversion
> > alpha blending between foreground and background graphics.
> >
> > as you know, some soc's engineer trying to add this function to drm system.
> >
> > do you know st's planning about soc's hardware accelerator driver on stm32mp?
> > such as chrom-art, will add to drm subsystem via ioctl to access, or to v4l2,
> On stm32mp we do not plan to use chrom-art in drm or v4l2 because it
> does fit
> with userland way of working. We use the GPU to do conversion, scaling,
> blending
> and composition in only one go.
> As explain here [1] DRM subsytem it isn't a solution and v4l2-m2m isn't
> used in any
> mainline compositors like Weston or android surfaceflinger.
>
> Benjamin
>
After check stm32mp's datasheets, they don't have chrom-art ip inside. sorry for
didn't check it yet.
for stm32h7 series with chrom-art, jpeg hardware accelerator inside.
does st has plan to
setup a driver to support it ? i prefer v4l2-m2m should be easier to
implement it.
co work with dcmi, fbdev.
thanks.
best regards.
Dillon
> [1]
> https://www.phoronix.com/scan.php?page=news_item&px=Linux-DRM-No-2D-Accel-API
> >
> > thanks.
> >
> >>> It is likely the same no matter which device is using spi5.
> >>>
> >>> Yours,
> >>> Linus Walleij
> >>>
> > _______________________________________________
> > Linux-stm32 mailing list
> > Linux-stm32@st-md-mailman.stormreply.com
> > https://st-md-mailman.stormreply.com/mailman/listinfo/linux-stm32
^ permalink raw reply
* Re: [PATCH 01/10] spi: dw: Add support for polled operation via no IRQ specified in DT
From: Lars Povlsen @ 2020-05-15 9:11 UTC (permalink / raw)
To: Serge Semin
Cc: Mark Brown, Serge Semin, Lars Povlsen, SoC Team,
Microchip Linux Driver Support, linux-spi, devicetree,
linux-kernel, linux-arm-kernel, Alexandre Belloni,
Andy Shevchenko
In-Reply-To: <20200514130407.guyk3r4ltjvszy5s@mobilestation>
Serge Semin writes:
> Hi Mark
>
> On Wed, May 13, 2020 at 03:20:50PM +0100, Mark Brown wrote:
>> On Wed, May 13, 2020 at 04:00:22PM +0200, Lars Povlsen wrote:
>> > With this change a SPI controller can be added without having a IRQ
>> > associated, and causing all transfers to be polled. For SPI controllers
>> > without DMA, this can significantly improve performance by less
>> > interrupt handling overhead.
>>
>> This overlaps substantially with some work that Serge Semin (CCed) has
>> in progress, please coordinate with him.
>
> Thanks for copying me these mails. I haven't been Cc'ed in the series and
> hasn't been subscribed to the SPI mailing list, so I would have definitely
> missed that.
>
> I would like to coordinate my efforts with Lars. I'll have the patchset reviewed
> soon in addition providing my comments/suggestions of how to make it useful for
> both mine and Lars solution.
Serge - thanks for taking on this.
Note that my primary concern now is to get Sparx5 upstreamed. The
mem_ops (or dirmap) and polled mode are both performance enhancements,
which can be pulled from my series if it creates too much noise. I can
then add the necessary on top of your work/current kernel at a later
time.
> One thing I can tell about the mem_ops he implemented, is that they aren't
> mem_ops, but dirmap (as you remember it's also implemented in my code, but with
> alignment specific), and the exec_mem_op partly consists of a code, which belong
> to the supports_op() callback. The rest of my comments will be inlined in the
> patches.
>
> -Sergey
--
Lars Povlsen,
Microchip
^ permalink raw reply
* [PATCH v2] arm64: dts: qcom: apq8016-sbc-d3: Add Qualcomm APQ8016 SBC + D3Camera mezzanine
From: Robert Foss @ 2020-05-15 9:08 UTC (permalink / raw)
To: Vinod Koul, Bjorn Andersson, linux-arm-msm, devicetree,
linux-kernel
Cc: Rob Herring, Nicolas Dechesne, Robert Foss
Add device treee support for the Qualcomm APQ8016 SBC, otherwise known as
the Dragonboard 410c with the D3Camera mezzanine expansion board.
The D3Camera mezzanine ships in a kit with a OmniVision 5640 sensor module,
which is what this DT targets.
Signed-off-by: Robert Foss <robert.foss@linaro.org>
---
Changes since v1:
- Vinod: Changed license to GPL+BSD
- Vinod: Changed copyright year to 2020
- Nico: Changed name of mezzanine to d3camera
arch/arm64/boot/dts/qcom/Makefile | 1 +
.../boot/dts/qcom/apq8016-sbc-d3camera.dts | 45 +++++++++++++++++++
2 files changed, 46 insertions(+)
create mode 100644 arch/arm64/boot/dts/qcom/apq8016-sbc-d3camera.dts
diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
index cc103f7020fd..3f95b522694e 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -1,5 +1,6 @@
# SPDX-License-Identifier: GPL-2.0
dtb-$(CONFIG_ARCH_QCOM) += apq8016-sbc.dtb
+dtb-$(CONFIG_ARCH_QCOM) += apq8016-sbc-d3camera.dtb
dtb-$(CONFIG_ARCH_QCOM) += apq8096-db820c.dtb
dtb-$(CONFIG_ARCH_QCOM) += apq8096-ifc6640.dtb
dtb-$(CONFIG_ARCH_QCOM) += ipq6018-cp01-c1.dtb
diff --git a/arch/arm64/boot/dts/qcom/apq8016-sbc-d3camera.dts b/arch/arm64/boot/dts/qcom/apq8016-sbc-d3camera.dts
new file mode 100644
index 000000000000..752e5ec47499
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/apq8016-sbc-d3camera.dts
@@ -0,0 +1,45 @@
+// SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause
+/*
+ * Copyright (c) 2020, The Linux Foundation. All rights reserved.
+ */
+
+/dts-v1/;
+
+#include "apq8016-sbc.dtsi"
+
+/ {
+ model = "Qualcomm Technologies, Inc. APQ 8016 SBC w/ D3Camera Mezzanine";
+ compatible = "qcom,apq8016-sbc", "qcom,apq8016", "qcom,sbc";
+};
+
+&cci_i2c0 {
+ /delete-node/ camera_rear@3b;
+
+ camera_rear@76 {
+ compatible = "ovti,ov5640";
+ reg = <0x76>;
+
+ enable-gpios = <&msmgpio 34 GPIO_ACTIVE_HIGH>;
+ reset-gpios = <&msmgpio 35 GPIO_ACTIVE_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&camera_rear_default>;
+
+ clocks = <&gcc GCC_CAMSS_MCLK0_CLK>;
+ clock-names = "xclk";
+ clock-frequency = <23880000>;
+
+ vdddo-supply = <&camera_vdddo_1v8>;
+ vdda-supply = <&camera_vdda_2v8>;
+ vddd-supply = <&camera_vddd_1v5>;
+
+ status = "ok";
+
+ port {
+ ov5640_ep: endpoint {
+ clock-lanes = <1>;
+ data-lanes = <0 2>;
+ remote-endpoint = <&csiphy0_ep>;
+ };
+ };
+ };
+};
--
2.25.1
^ permalink raw reply related
* Re: [PATCH v4 06/10] dt-bindings: mtd: update STM32 FMC2 NAND controller documentation
From: Christophe Kerello @ 2020-05-15 9:02 UTC (permalink / raw)
To: Rob Herring
Cc: Miquèl Raynal, Richard Weinberger, Vignesh R, Mark Rutland,
Greg Kroah-Hartman, Boris Brezillon, MTD Maling List,
linux-kernel@vger.kernel.org, linux-stm32, devicetree,
Marek Vašut
In-Reply-To: <CAL_JsqLTyDHBHncrQqtPdkCNgKDkEbp+ts7BOeqWmGv64kcAsg@mail.gmail.com>
Hi Rob,
On 5/14/20 7:55 PM, Rob Herring wrote:
> On Thu, May 14, 2020 at 11:35 AM Christophe Kerello
> <christophe.kerello@st.com> wrote:
>>
>> Hi Rob,
>>
>> On 5/14/20 5:00 PM, Rob Herring wrote:
>>> On Wed, May 06, 2020 at 11:11:15AM +0200, Christophe Kerello wrote:
>>>> These bindings can be used on SOCs where the FMC2 NAND controller is
>>>> in standalone. In case that the FMC2 embeds 2 controllers (an external
>>>> bus controller and a raw NAND controller), the register base and the
>>>> clock will be defined in the parent node. It is the reason why the
>>>> register base address and the clock are now optional.
>>>>
>>>> Signed-off-by: Christophe Kerello <christophe.kerello@st.com>
>>>> ---
>>>> .../devicetree/bindings/mtd/st,stm32-fmc2-nand.yaml | 19 ++++++++++---------
>>>> 1 file changed, 10 insertions(+), 9 deletions(-)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/mtd/st,stm32-fmc2-nand.yaml b/Documentation/devicetree/bindings/mtd/st,stm32-fmc2-nand.yaml
>>>> index b059267..68fac1a 100644
>>>> --- a/Documentation/devicetree/bindings/mtd/st,stm32-fmc2-nand.yaml
>>>> +++ b/Documentation/devicetree/bindings/mtd/st,stm32-fmc2-nand.yaml
>>>> @@ -18,13 +18,15 @@ properties:
>>>>
>>>> reg:
>>>> items:
>>>> - - description: Registers
>>>> + - description: Registers (optional)
>>>
>>> The only thing that can be optional are the last entries. You have to do
>>> a 'oneOf' with 6 entries and 7 entries.
>>
>> Ok, so the way to describe the reg property in my case should be:
>> reg:
>> oneOf:
>> - description: FMC2 embeds the NFC controller in standalone.
>> items:
>> - description: Registers
>> - description: Chip select 0 data
>> - description: Chip select 0 command
>> - description: Chip select 0 address space
>> - description: Chip select 1 data
>> - description: Chip select 1 command
>> - description: Chip select 1 address space
>>
>> - description: FMC2 embeds the NFC controller and the EBI
>> controller.
>> items:
>> - description: Chip select 0 data
>> - description: Chip select 0 command
>> - description: Chip select 0 address space
>> - description: Chip select 1 data
>> - description: Chip select 1 command
>> - description: Chip select 1 address space
>>
>>>
>>> And where's your new compatible string for this different h/w?
>>
>> From NFC controller point of view, it is the same HW.
>
> That's what everyone says until they have some quirk or integration
> difference to handle.
>
>> In the case that we have 2 controllers embedded, the register base is
>> shared.
>> The NFC driver will check at probe time the compatible string of its
>> parent node.
>> In case that it is "st,stm32mp1-fmc2-ebi", then the driver will find the
>> register base in the parent node (EBI node), otherwise it will find it
>> in the NFC node.
>> Is it better to have 2 compatible strings (one for each reg description)
>> than checking the parent's compatible string and have only one
>> compatible string?
>
> Why not just put the register base into the child node too? While
> overlapping 'reg' regions for siblings is bad, it's fine for child
> nodes. I guess since there are chip selects for the child nodes that
> may not work here.
>
> It doesn't hurt to have another compatible. You can always make the
> old one a fallback. With different compatibles you can make sure reg
> has the right number of entries.
>
> Rob
>
I will add a new compatible string to handle the reg property.
It will be part of v5.
Regards,
Christophe Kerello.
^ permalink raw reply
* Re: [PATCH v1 0/4] Optimize fw_devlink parsing
From: Saravana Kannan @ 2020-05-15 8:52 UTC (permalink / raw)
To: Greg Kroah-Hartman, Rafael J. Wysocki, Rob Herring, Frank Rowand,
Len Brown
Cc: Android Kernel Team, LKML,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
ACPI Devel Maling List, Ji Luo
In-Reply-To: <20200515053500.215929-1-saravanak@google.com>
On Thu, May 14, 2020 at 10:35 PM Saravana Kannan <saravanak@google.com> wrote:
>
> When fw_devlink is enabled on hardware with a large number of device
> tree nodes, the initial device addition done in
> of_platform_default_populate_init() can be very inefficient. This is
> because most devices will fail to find all their suppliers when they are
> added and will keep trying to parse their device tree nodes and link to
> any newly added devices
>
> This was an item on my TODO list that I'm finally getting around to. On
> hardware I'm testing on, this saved 1.216 _seconds_!
Correction. It went from 1.216 _seconds_ to 61 _milliseconds_! So
about 95% reduction in time.
-Saravana
^ permalink raw reply
* Re: [PATCH v1 1/2] MIPS: ath79: ar9331_dpt_module: update led nodes
From: Thomas Bogendoerfer @ 2020-05-15 8:10 UTC (permalink / raw)
To: Oleksij Rempel
Cc: Rob Herring, devicetree, linux-kernel, linux-mips,
Pengutronix Kernel Team
In-Reply-To: <20200510060324.25134-1-o.rempel@pengutronix.de>
On Sun, May 10, 2020 at 08:03:23AM +0200, Oleksij Rempel wrote:
> Fit led nodes to the latest naming schema.
>
> Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
> ---
> arch/mips/boot/dts/qca/ar9331_dpt_module.dts | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
both patches applied to mips-next.
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea. [ RFC1925, 2.3 ]
^ permalink raw reply
* Re: [Linux-stm32] [PATCH v3 3/5] ARM: dts: stm32: enable ltdc binding with ili9341 on stm32429-disco board
From: Benjamin GAIGNARD @ 2020-05-15 8:31 UTC (permalink / raw)
To: dillon min, Alexandre TORGUE
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Daniel Vetter, Dave Airlie, Linus Walleij, linux-clk,
linux-kernel@vger.kernel.org, open list:DRM PANEL DRIVERS,
linux-stm32@st-md-mailman.stormreply.com, Stephen Boyd,
Rob Herring, thierry.reding@gmail.com, Maxime Coquelin,
Sam Ravnborg, Michael Turquette, Linux ARM
In-Reply-To: <CAL9mu0Jt_xwo5pJfcx6G3grBuOaxLXvakpEjiB4gV3=bkiq2fg@mail.gmail.com>
On 5/14/20 3:07 PM, dillon min wrote:
> Hi Alexandre,
>
> On Thu, May 14, 2020 at 8:53 PM Alexandre Torgue
> <alexandre.torgue@st.com> wrote:
>>
>>
>> On 5/14/20 10:24 AM, Linus Walleij wrote:
>>> On Tue, May 12, 2020 at 9:04 AM <dillon.minfei@gmail.com> wrote:
>>>
>>>> From: dillon min <dillon.minfei@gmail.com>
>>>>
>>>> Enable the ltdc & ili9341 on stm32429-disco board.
>>>>
>>>> Signed-off-by: dillon min <dillon.minfei@gmail.com>
>>> This mostly looks good but...
>>>
>>>> +&spi5 {
>>>> + status = "okay";
>>>> + pinctrl-0 = <&spi5_pins>;
>>>> + pinctrl-names = "default";
>>>> + #address-cells = <1>;
>>>> + #size-cells = <0>;
>>>> + cs-gpios = <&gpioc 2 GPIO_ACTIVE_LOW>;
>>>> + dmas = <&dma2 3 2 0x400 0x0>,
>>>> + <&dma2 4 2 0x400 0x0>;
>>>> + dma-names = "rx", "tx";
>>> These DMA assignments seem to be SoC things and should
>>> rather be in the DTS(I) file where &spi5 is defined, right?
>>> stm32f429.dtsi I suppose?
>> I agree with Linus, DMA have to be defined in SoC dtsi. And if a board
>> doesn't want to use it, we use the "delete-property".
> Yes, will move to Soc dtsi in next submits.
>
> i'm working on write a v4l2-m2m driver for dma2d of stm32 to support
> pixel conversion
> alpha blending between foreground and background graphics.
>
> as you know, some soc's engineer trying to add this function to drm system.
>
> do you know st's planning about soc's hardware accelerator driver on stm32mp?
> such as chrom-art, will add to drm subsystem via ioctl to access, or to v4l2,
On stm32mp we do not plan to use chrom-art in drm or v4l2 because it
does fit
with userland way of working. We use the GPU to do conversion, scaling,
blending
and composition in only one go.
As explain here [1] DRM subsytem it isn't a solution and v4l2-m2m isn't
used in any
mainline compositors like Weston or android surfaceflinger.
Benjamin
[1]
https://www.phoronix.com/scan.php?page=news_item&px=Linux-DRM-No-2D-Accel-API
>
> thanks.
>
>>> It is likely the same no matter which device is using spi5.
>>>
>>> Yours,
>>> Linus Walleij
>>>
> _______________________________________________
> Linux-stm32 mailing list
> Linux-stm32@st-md-mailman.stormreply.com
> https://st-md-mailman.stormreply.com/mailman/listinfo/linux-stm32
^ permalink raw reply
* Re: [PATCH v1] arm64: dts: qcom: apq8016-sbc-d3: Add Qualcomm APQ8016 SBC + D3 mezzanine
From: Robert Foss @ 2020-05-15 8:31 UTC (permalink / raw)
To: Vinod Koul
Cc: Andy Gross, Bjorn Andersson, Rob Herring, linux-arm-msm,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linux-kernel
In-Reply-To: <20200514172223.GF14092@vkoul-mobl>
On Thu, 14 May 2020 at 19:22, Vinod Koul <vkoul@kernel.org> wrote:
>
> On 22-04-20, 13:10, Robert Foss wrote:
> > Add device treee support for the Qualcomm APQ8016 SBC, otherwise known as
> > the Dragonboard 410c with the D3 mezzanine expansion board.
> >
> > The D3 mezzanine ships in a kit with a OmniVision 5640 sensor module,
> > which is what this DT targets.
> >
> > Signed-off-by: Robert Foss <robert.foss@linaro.org>
> > ---
> > arch/arm64/boot/dts/qcom/Makefile | 1 +
> > arch/arm64/boot/dts/qcom/apq8016-sbc-d3.dts | 45 +++++++++++++++++++++
> > 2 files changed, 46 insertions(+)
> > create mode 100644 arch/arm64/boot/dts/qcom/apq8016-sbc-d3.dts
> >
> > diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
> > index cc103f7020fd..025362471929 100644
> > --- a/arch/arm64/boot/dts/qcom/Makefile
> > +++ b/arch/arm64/boot/dts/qcom/Makefile
> > @@ -1,5 +1,6 @@
> > # SPDX-License-Identifier: GPL-2.0
> > dtb-$(CONFIG_ARCH_QCOM) += apq8016-sbc.dtb
> > +dtb-$(CONFIG_ARCH_QCOM) += apq8016-sbc-d3.dtb
> > dtb-$(CONFIG_ARCH_QCOM) += apq8096-db820c.dtb
> > dtb-$(CONFIG_ARCH_QCOM) += apq8096-ifc6640.dtb
> > dtb-$(CONFIG_ARCH_QCOM) += ipq6018-cp01-c1.dtb
> > diff --git a/arch/arm64/boot/dts/qcom/apq8016-sbc-d3.dts b/arch/arm64/boot/dts/qcom/apq8016-sbc-d3.dts
> > new file mode 100644
> > index 000000000000..1b85adeeada1
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/qcom/apq8016-sbc-d3.dts
> > @@ -0,0 +1,45 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
>
> Dual BSD + GPL please
Thanks.
>
> > +/*
> > + * Copyright (c) 2015, The Linux Foundation. All rights reserved.
>
> we are in 2020 now :)
Maybe I should fix that.
I'll change the name of the d3 mezzanine to d3camera as well.
>
> > + */
> > +
> > +/dts-v1/;
> > +
> > +#include "apq8016-sbc.dtsi"
> > +
> > +/ {
> > + model = "Qualcomm Technologies, Inc. APQ 8016 SBC w/ D3 Mezzanine";
> > + compatible = "qcom,apq8016-sbc", "qcom,apq8016", "qcom,sbc";
> > +};
> > +
> > +&cci_i2c0 {
> > + /delete-node/ camera_rear@3b;
> > +
> > + camera_rear@76 {
> > + compatible = "ovti,ov5640";
> > + reg = <0x76>;
> > +
> > + enable-gpios = <&msmgpio 34 GPIO_ACTIVE_HIGH>;
> > + reset-gpios = <&msmgpio 35 GPIO_ACTIVE_LOW>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&camera_rear_default>;
> > +
> > + clocks = <&gcc GCC_CAMSS_MCLK0_CLK>;
> > + clock-names = "xclk";
> > + clock-frequency = <23880000>;
> > +
> > + vdddo-supply = <&camera_vdddo_1v8>;
> > + vdda-supply = <&camera_vdda_2v8>;
> > + vddd-supply = <&camera_vddd_1v5>;
> > +
> > + status = "ok";
> > +
> > + port {
> > + ov5640_ep: endpoint {
> > + clock-lanes = <1>;
> > + data-lanes = <0 2>;
> > + remote-endpoint = <&csiphy0_ep>;
> > + };
> > + };
> > + };
> > +};
> > --
> > 2.25.1
>
> --
> ~Vinod
^ permalink raw reply
* Re: [PATCH 3/4] dt-binding: phy: ti,omap-usb2: Add quirk to disable charger detection
From: Roger Quadros @ 2020-05-15 8:30 UTC (permalink / raw)
To: kishon; +Cc: robh+dt, b-liu, devicetree, vigneshr, nsekhar
In-Reply-To: <20200515080518.26870-4-rogerq@ti.com>
Hi,
On 15/05/2020 11:05, Roger Quadros wrote:
> Add "ti,dis-chg-det-quirk" property to disable the USB2_PHY Charger Detect
> logic.
On second thoughts I think it is better to use soc_device_match instead of DT property
as we are not going to have separate DT for SR1.0 vs SR2.0.
cheers,
-roger
>
> Signed-off-by: Roger Quadros <rogerq@ti.com>
> ---
> Documentation/devicetree/bindings/phy/ti,omap-usb2.yaml | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/phy/ti,omap-usb2.yaml b/Documentation/devicetree/bindings/phy/ti,omap-usb2.yaml
> index ecfb28f714ea..ec3e85a17bfa 100644
> --- a/Documentation/devicetree/bindings/phy/ti,omap-usb2.yaml
> +++ b/Documentation/devicetree/bindings/phy/ti,omap-usb2.yaml
> @@ -54,6 +54,11 @@ properties:
> (deprecated) phandle of the control module used by PHY driver
> to power on the PHY. Use syscon-phy-power instead.
>
> + ti,dis-chg-det-quirk:
> + description:
> + if present, driver will disable charger detection logic.
> + type: boolean
> +
> required:
> - compatible
> - reg
>
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
^ permalink raw reply
* Re: [PATCH v4 5/5] drm/sun4i: mixer: Call of_dma_configure if there's an IOMMU
From: Paul Kocialkowski @ 2020-05-15 8:15 UTC (permalink / raw)
To: Maxime Ripard
Cc: Joerg Roedel, Chen-Yu Tsai, Maxime Ripard, Mark Rutland,
Rob Herring, Frank Rowand, devicetree, iommu, linux-arm-kernel
In-Reply-To: <9a4daf438dd3f2fe07afb23688bfb793a0613d7d.1589378833.git-series.maxime@cerno.tech>
[-- Attachment #1: Type: text/plain, Size: 2069 bytes --]
Hi,
On Wed 13 May 20, 16:07, Maxime Ripard wrote:
> The main DRM device is actually a virtual device so it doesn't have the
> iommus property, which is instead on the DMA masters, in this case the
> mixers.
>
> Add a call to of_dma_configure with the mixers DT node but on the DRM
> virtual device to configure it in the same way than the mixers.
Although I'm not very familiar with the DMA API, this looks legit to me and
matches what's already done in sun4i_backend for the interconnect. So:
Reviewed-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Cheers,
Paul
> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> ---
> drivers/gpu/drm/sun4i/sun8i_mixer.c | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c b/drivers/gpu/drm/sun4i/sun8i_mixer.c
> index 56cc037fd312..cc4fb916318f 100644
> --- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
> +++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
> @@ -363,6 +363,19 @@ static int sun8i_mixer_bind(struct device *dev, struct device *master,
> mixer->engine.ops = &sun8i_engine_ops;
> mixer->engine.node = dev->of_node;
>
> + if (of_find_property(dev->of_node, "iommus", NULL)) {
> + /*
> + * This assume we have the same DMA constraints for
> + * all our the mixers in our pipeline. This sounds
> + * bad, but it has always been the case for us, and
> + * DRM doesn't do per-device allocation either, so we
> + * would need to fix DRM first...
> + */
> + ret = of_dma_configure(drm->dev, dev->of_node, true);
> + if (ret)
> + return ret;
> + }
> +
> /*
> * While this function can fail, we shouldn't do anything
> * if this happens. Some early DE2 DT entries don't provide
> --
> git-series 0.9.1
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [RESEND PATCH v8 3/3] phy: intel: Add driver support for ComboPhy
From: Dilip Kota @ 2020-05-15 8:13 UTC (permalink / raw)
To: linux-kernel, kishon, vkoul, devicetree
Cc: robh, andriy.shevchenko, cheol.yong.kim, chuanhua.lei, qi-ming.wu,
yixin.zhu, Dilip Kota
In-Reply-To: <cover.1589530082.git.eswara.kota@linux.intel.com>
ComboPhy subsystem provides PHYs for various
controllers like PCIe, SATA and EMAC.
Signed-off-by: Dilip Kota <eswara.kota@linux.intel.com>
---
Changes on v8:
As per PHY Maintainer's request add description for doing register access
through regmap in comments.
Changes on v7:
Use device_node_to_regmap instead of fwnode_to_regmap
Changes on v6:
No changes
Changes on v5:
Add changes as per inputs from Andy and Rob:
DT node uses phy-mode values as defined in "include/dt-bindings/phy/phy.h",
add changes to handle it.
ComboPhy no longer has children nodes, and children node properties(reset)
moved to parent node, so do the code changes accordingly.
Add _xlate() function to pass the appropriate phy handle.
Fix couple of nitpicks.
Changes on v4:
Address review comments
Remove dependency on OF config
Update copyright to 2019-2020
Define register macro PAD_DIS_CFG instead of const variable inside function.
Improve the error prints, and error returns.
Call put_device(dev), for get_dev_from_fwnode()
Move platform_set_drvdata() at the end of the probe().
Correct alignment in phy_ops intel_cbphy_ops.
Correct commented lines with proper vocabulary and punctuation.
Add/remove commas for the required constant arrays and enums.
Remove in driver:
linux/kernel.h, not required
macros: PCIE_PHY_MPLLA_CTRL, PCIE_PHY_MPLLB_CTRL
temp variable u32 prop;
Change function names:
intel_cbphy_iphy_dt_parse() -> intel_cbphy_iphy_fwnode_parse()
intel_cbphy_dt_sanity_check() -> intel_cbphy_sanity_check()
intel_cbphy_dt_parse() -> intel_cbphy_fwnode_parse()
Changes on v3:
Remove intel_iphy_names
Remove struct phy in struct intel_cbphy_iphy
Imporve if conditions logic
Use fwnode_to_regmap()
Call devm_of_platform_populate() to populate child nodes
Fix reset sequence during phy_init
Add SoC specific compatible "intel,combophy-lgm"
Add description for enums
Remove default case in switch {} intel_cbphy_set_mode() as it
never happens.
Use mutex_lock to synchronise combophy initialization across
two phys.
Change init_cnt to u32 datatype as it is within mutex lock.
Correct error handling of
fwnode_property_read_u32_array(fwnode, "intel,phy-mode", ...)
drivers/phy/intel/Kconfig | 14 +
drivers/phy/intel/Makefile | 1 +
drivers/phy/intel/phy-intel-combo.c | 632 ++++++++++++++++++++++++++++++++++++
3 files changed, 647 insertions(+)
create mode 100644 drivers/phy/intel/phy-intel-combo.c
diff --git a/drivers/phy/intel/Kconfig b/drivers/phy/intel/Kconfig
index 4ea6a8897cd7..3b40eb7b4fb4 100644
--- a/drivers/phy/intel/Kconfig
+++ b/drivers/phy/intel/Kconfig
@@ -2,6 +2,20 @@
#
# Phy drivers for Intel Lightning Mountain(LGM) platform
#
+config PHY_INTEL_COMBO
+ bool "Intel ComboPHY driver"
+ depends on X86 || COMPILE_TEST
+ depends on OF && HAS_IOMEM
+ select MFD_SYSCON
+ select GENERIC_PHY
+ select REGMAP
+ help
+ Enable this to support Intel ComboPhy.
+
+ This driver configures ComboPhy subsystem on Intel gateway
+ chipsets which provides PHYs for various controllers, EMAC,
+ SATA and PCIe.
+
config PHY_INTEL_EMMC
tristate "Intel EMMC PHY driver"
select GENERIC_PHY
diff --git a/drivers/phy/intel/Makefile b/drivers/phy/intel/Makefile
index 6b876a75599d..233d530dadde 100644
--- a/drivers/phy/intel/Makefile
+++ b/drivers/phy/intel/Makefile
@@ -1,2 +1,3 @@
# SPDX-License-Identifier: GPL-2.0
+obj-$(CONFIG_PHY_INTEL_COMBO) += phy-intel-combo.o
obj-$(CONFIG_PHY_INTEL_EMMC) += phy-intel-emmc.o
diff --git a/drivers/phy/intel/phy-intel-combo.c b/drivers/phy/intel/phy-intel-combo.c
new file mode 100644
index 000000000000..4bc1276ecf23
--- /dev/null
+++ b/drivers/phy/intel/phy-intel-combo.c
@@ -0,0 +1,632 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Intel Combo-PHY driver
+ *
+ * Copyright (C) 2019-2020 Intel Corporation.
+ */
+
+#include <linux/bitfield.h>
+#include <linux/clk.h>
+#include <linux/iopoll.h>
+#include <linux/mfd/syscon.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/of.h>
+#include <linux/phy/phy.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/reset.h>
+
+#include <dt-bindings/phy/phy.h>
+
+#define PCIE_PHY_GEN_CTRL 0x00
+#define PCIE_PHY_CLK_PAD BIT(17)
+
+#define PAD_DIS_CFG 0x174
+
+#define PCS_XF_ATE_OVRD_IN_2 0x3008
+#define ADAPT_REQ_MSK GENMASK(5, 4)
+
+#define PCS_XF_RX_ADAPT_ACK 0x3010
+#define RX_ADAPT_ACK_BIT BIT(0)
+
+#define CR_ADDR(addr, lane) (((addr) + (lane) * 0x100) << 2)
+#define REG_COMBO_MODE(x) ((x) * 0x200)
+#define REG_CLK_DISABLE(x) ((x) * 0x200 + 0x124)
+
+#define COMBO_PHY_ID(x) ((x)->parent->id)
+#define PHY_ID(x) ((x)->id)
+
+#define CLK_100MHZ 100000000
+#define CLK_156_25MHZ 156250000
+
+static const unsigned long intel_iphy_clk_rates[] = {
+ CLK_100MHZ, CLK_156_25MHZ, CLK_100MHZ,
+};
+
+enum {
+ PHY_0,
+ PHY_1,
+ PHY_MAX_NUM
+};
+
+/*
+ * Clock Register bit fields to enable clocks
+ * for ComboPhy according to the mode.
+ */
+enum intel_phy_mode {
+ PHY_PCIE_MODE = 0,
+ PHY_XPCS_MODE,
+ PHY_SATA_MODE,
+};
+
+/* ComboPhy mode Register values */
+enum intel_combo_mode {
+ PCIE0_PCIE1_MODE = 0,
+ PCIE_DL_MODE,
+ RXAUI_MODE,
+ XPCS0_XPCS1_MODE,
+ SATA0_SATA1_MODE,
+};
+
+enum aggregated_mode {
+ PHY_SL_MODE,
+ PHY_DL_MODE,
+};
+
+struct intel_combo_phy;
+
+struct intel_cbphy_iphy {
+ struct phy *phy;
+ struct intel_combo_phy *parent;
+ struct reset_control *app_rst;
+ u32 id;
+};
+
+struct intel_combo_phy {
+ struct device *dev;
+ struct clk *core_clk;
+ unsigned long clk_rate;
+ void __iomem *app_base;
+ void __iomem *cr_base;
+ struct regmap *syscfg;
+ struct regmap *hsiocfg;
+ u32 id;
+ u32 bid;
+ struct reset_control *phy_rst;
+ struct reset_control *core_rst;
+ struct intel_cbphy_iphy iphy[PHY_MAX_NUM];
+ enum intel_phy_mode phy_mode;
+ enum aggregated_mode aggr_mode;
+ u32 init_cnt;
+ struct mutex lock;
+};
+
+static int intel_cbphy_iphy_enable(struct intel_cbphy_iphy *iphy, bool set)
+{
+ struct intel_combo_phy *cbphy = iphy->parent;
+ u32 mask = BIT(cbphy->phy_mode * 2 + iphy->id);
+ u32 val;
+
+ /* Register: 0 is enable, 1 is disable */
+ val = set ? 0 : mask;
+
+ return regmap_update_bits(cbphy->hsiocfg, REG_CLK_DISABLE(cbphy->bid),
+ mask, val);
+}
+
+static int intel_cbphy_pcie_refclk_cfg(struct intel_cbphy_iphy *iphy, bool set)
+{
+ struct intel_combo_phy *cbphy = iphy->parent;
+ u32 mask = BIT(cbphy->id * 2 + iphy->id);
+ u32 val;
+
+ /* Register: 0 is enable, 1 is disable */
+ val = set ? 0 : mask;
+
+ return regmap_update_bits(cbphy->syscfg, PAD_DIS_CFG, mask, val);
+}
+
+static inline void combo_phy_w32_off_mask(void __iomem *base, unsigned int reg,
+ u32 mask, u32 val)
+{
+ u32 reg_val;
+
+ reg_val = readl(base + reg);
+ reg_val &= ~mask;
+ reg_val |= FIELD_PREP(mask, val);
+ writel(reg_val, base + reg);
+}
+
+static int intel_cbphy_iphy_cfg(struct intel_cbphy_iphy *iphy,
+ int (*phy_cfg)(struct intel_cbphy_iphy *))
+{
+ struct intel_combo_phy *cbphy = iphy->parent;
+ int ret;
+
+ ret = phy_cfg(iphy);
+ if (ret)
+ return ret;
+
+ if (cbphy->aggr_mode != PHY_DL_MODE)
+ return 0;
+
+ return phy_cfg(&cbphy->iphy[PHY_1]);
+}
+
+static int intel_cbphy_pcie_en_pad_refclk(struct intel_cbphy_iphy *iphy)
+{
+ struct intel_combo_phy *cbphy = iphy->parent;
+ int ret;
+
+ ret = intel_cbphy_pcie_refclk_cfg(iphy, true);
+ if (ret) {
+ dev_err(cbphy->dev, "Failed to enable PCIe pad refclk\n");
+ return ret;
+ }
+
+ if (cbphy->init_cnt)
+ return 0;
+
+ combo_phy_w32_off_mask(cbphy->app_base, PCIE_PHY_GEN_CTRL,
+ PCIE_PHY_CLK_PAD, 0);
+
+ /* Delay for stable clock PLL */
+ usleep_range(50, 100);
+
+ return 0;
+}
+
+static int intel_cbphy_pcie_dis_pad_refclk(struct intel_cbphy_iphy *iphy)
+{
+ struct intel_combo_phy *cbphy = iphy->parent;
+ int ret;
+
+ ret = intel_cbphy_pcie_refclk_cfg(iphy, false);
+ if (ret) {
+ dev_err(cbphy->dev, "Failed to disable PCIe pad refclk\n");
+ return ret;
+ }
+
+ if (cbphy->init_cnt)
+ return 0;
+
+ combo_phy_w32_off_mask(cbphy->app_base, PCIE_PHY_GEN_CTRL,
+ PCIE_PHY_CLK_PAD, 1);
+
+ return 0;
+}
+
+static int intel_cbphy_set_mode(struct intel_combo_phy *cbphy)
+{
+ enum aggregated_mode aggr = cbphy->aggr_mode;
+ struct device *dev = cbphy->dev;
+ enum intel_combo_mode cb_mode;
+ enum intel_phy_mode mode;
+ int ret;
+
+ mode = cbphy->phy_mode;
+
+ switch (mode) {
+ case PHY_PCIE_MODE:
+ cb_mode = (aggr == PHY_DL_MODE) ? PCIE_DL_MODE : PCIE0_PCIE1_MODE;
+ break;
+
+ case PHY_XPCS_MODE:
+ cb_mode = (aggr == PHY_DL_MODE) ? RXAUI_MODE : XPCS0_XPCS1_MODE;
+ break;
+
+ case PHY_SATA_MODE:
+ if (aggr == PHY_DL_MODE) {
+ dev_err(dev, "Mode:%u not support dual lane!\n", mode);
+ return -EINVAL;
+ }
+
+ cb_mode = SATA0_SATA1_MODE;
+ break;
+ }
+
+ ret = regmap_write(cbphy->hsiocfg, REG_COMBO_MODE(cbphy->bid), cb_mode);
+ if (ret)
+ dev_err(dev, "Failed to set ComboPhy mode: %d\n", ret);
+
+ return ret;
+}
+
+static void intel_cbphy_rst_assert(struct intel_combo_phy *cbphy)
+{
+ reset_control_assert(cbphy->core_rst);
+ reset_control_assert(cbphy->phy_rst);
+}
+
+static void intel_cbphy_rst_deassert(struct intel_combo_phy *cbphy)
+{
+ reset_control_deassert(cbphy->core_rst);
+ reset_control_deassert(cbphy->phy_rst);
+ /* Delay to ensure reset process is done */
+ usleep_range(10, 20);
+}
+
+static int intel_cbphy_iphy_power_on(struct intel_cbphy_iphy *iphy)
+{
+ struct intel_combo_phy *cbphy = iphy->parent;
+ int ret;
+
+ if (!cbphy->init_cnt) {
+ ret = clk_prepare_enable(cbphy->core_clk);
+ if (ret) {
+ dev_err(cbphy->dev, "Clock enable failed!\n");
+ return ret;
+ }
+
+ ret = clk_set_rate(cbphy->core_clk, cbphy->clk_rate);
+ if (ret) {
+ dev_err(cbphy->dev, "Clock freq set to %lu failed!\n",
+ cbphy->clk_rate);
+ goto clk_err;
+ }
+
+ intel_cbphy_rst_assert(cbphy);
+ intel_cbphy_rst_deassert(cbphy);
+ ret = intel_cbphy_set_mode(cbphy);
+ if (ret)
+ goto clk_err;
+ }
+
+ ret = intel_cbphy_iphy_enable(iphy, true);
+ if (ret) {
+ dev_err(cbphy->dev, "Failed enabling PHY core\n");
+ goto clk_err;
+ }
+
+ ret = reset_control_deassert(iphy->app_rst);
+ if (ret) {
+ dev_err(cbphy->dev, "PHY(%u:%u) reset deassert failed!\n",
+ COMBO_PHY_ID(iphy), PHY_ID(iphy));
+ goto clk_err;
+ }
+
+ /* Delay to ensure reset process is done */
+ udelay(1);
+
+ return 0;
+
+clk_err:
+ clk_disable_unprepare(cbphy->core_clk);
+
+ return ret;
+}
+
+static int intel_cbphy_iphy_power_off(struct intel_cbphy_iphy *iphy)
+{
+ struct intel_combo_phy *cbphy = iphy->parent;
+ int ret;
+
+ ret = reset_control_assert(iphy->app_rst);
+ if (ret) {
+ dev_err(cbphy->dev, "PHY(%u:%u) reset assert failed!\n",
+ COMBO_PHY_ID(iphy), PHY_ID(iphy));
+ return ret;
+ }
+
+ ret = intel_cbphy_iphy_enable(iphy, false);
+ if (ret) {
+ dev_err(cbphy->dev, "Failed disabling PHY core\n");
+ return ret;
+ }
+
+ if (cbphy->init_cnt)
+ return 0;
+
+ clk_disable_unprepare(cbphy->core_clk);
+ intel_cbphy_rst_assert(cbphy);
+
+ return 0;
+}
+
+static int intel_cbphy_init(struct phy *phy)
+{
+ struct intel_cbphy_iphy *iphy = phy_get_drvdata(phy);
+ struct intel_combo_phy *cbphy = iphy->parent;
+ int ret;
+
+ mutex_lock(&cbphy->lock);
+ ret = intel_cbphy_iphy_cfg(iphy, intel_cbphy_iphy_power_on);
+ if (ret)
+ goto err;
+
+ if (cbphy->phy_mode == PHY_PCIE_MODE) {
+ ret = intel_cbphy_iphy_cfg(iphy, intel_cbphy_pcie_en_pad_refclk);
+ if (ret)
+ goto err;
+ }
+
+ cbphy->init_cnt++;
+
+err:
+ mutex_unlock(&cbphy->lock);
+
+ return ret;
+}
+
+static int intel_cbphy_exit(struct phy *phy)
+{
+ struct intel_cbphy_iphy *iphy = phy_get_drvdata(phy);
+ struct intel_combo_phy *cbphy = iphy->parent;
+ int ret;
+
+ mutex_lock(&cbphy->lock);
+ cbphy->init_cnt--;
+ if (cbphy->phy_mode == PHY_PCIE_MODE) {
+ ret = intel_cbphy_iphy_cfg(iphy, intel_cbphy_pcie_dis_pad_refclk);
+ if (ret)
+ goto err;
+ }
+
+ ret = intel_cbphy_iphy_cfg(iphy, intel_cbphy_iphy_power_off);
+
+err:
+ mutex_unlock(&cbphy->lock);
+
+ return ret;
+}
+
+static int intel_cbphy_calibrate(struct phy *phy)
+{
+ struct intel_cbphy_iphy *iphy = phy_get_drvdata(phy);
+ struct intel_combo_phy *cbphy = iphy->parent;
+ void __iomem *cr_base = cbphy->cr_base;
+ int val, ret, id;
+
+ if (cbphy->phy_mode != PHY_XPCS_MODE)
+ return 0;
+
+ id = PHY_ID(iphy);
+
+ /* trigger auto RX adaptation */
+ combo_phy_w32_off_mask(cr_base, CR_ADDR(PCS_XF_ATE_OVRD_IN_2, id),
+ ADAPT_REQ_MSK, 3);
+ /* Wait RX adaptation to finish */
+ ret = readl_poll_timeout(cr_base + CR_ADDR(PCS_XF_RX_ADAPT_ACK, id),
+ val, val & RX_ADAPT_ACK_BIT, 10, 5000);
+ if (ret)
+ dev_err(cbphy->dev, "RX Adaptation failed!\n");
+ else
+ dev_dbg(cbphy->dev, "RX Adaptation success!\n");
+
+ /* Stop RX adaptation */
+ combo_phy_w32_off_mask(cr_base, CR_ADDR(PCS_XF_ATE_OVRD_IN_2, id),
+ ADAPT_REQ_MSK, 0);
+
+ return ret;
+}
+
+static int intel_cbphy_fwnode_parse(struct intel_combo_phy *cbphy)
+{
+ struct device *dev = cbphy->dev;
+ struct platform_device *pdev = to_platform_device(dev);
+ struct fwnode_handle *fwnode = dev_fwnode(dev);
+ struct fwnode_reference_args ref;
+ int ret;
+ u32 val;
+
+ cbphy->core_clk = devm_clk_get(dev, NULL);
+ if (IS_ERR(cbphy->core_clk)) {
+ ret = PTR_ERR(cbphy->core_clk);
+ if (ret != -EPROBE_DEFER)
+ dev_err(dev, "Get clk failed:%d!\n", ret);
+ return ret;
+ }
+
+ cbphy->core_rst = devm_reset_control_get_optional(dev, "core");
+ if (IS_ERR(cbphy->core_rst)) {
+ ret = PTR_ERR(cbphy->core_rst);
+ if (ret != -EPROBE_DEFER)
+ dev_err(dev, "Get core reset control err: %d!\n", ret);
+ return ret;
+ }
+
+ cbphy->phy_rst = devm_reset_control_get_optional(dev, "phy");
+ if (IS_ERR(cbphy->phy_rst)) {
+ ret = PTR_ERR(cbphy->phy_rst);
+ if (ret != -EPROBE_DEFER)
+ dev_err(dev, "Get PHY reset control err: %d!\n", ret);
+ return ret;
+ }
+
+ cbphy->iphy[0].app_rst = devm_reset_control_get_optional(dev, "iphy0");
+ if (IS_ERR(cbphy->iphy[0].app_rst)) {
+ ret = PTR_ERR(cbphy->iphy[0].app_rst);
+ if (ret != -EPROBE_DEFER)
+ dev_err(dev, "Get phy0 reset control err: %d!\n", ret);
+ return ret;
+ }
+
+ cbphy->iphy[1].app_rst = devm_reset_control_get_optional(dev, "iphy1");
+ if (IS_ERR(cbphy->iphy[1].app_rst)) {
+ ret = PTR_ERR(cbphy->iphy[1].app_rst);
+ if (ret != -EPROBE_DEFER)
+ dev_err(dev, "Get phy1 reset control err: %d!\n", ret);
+ return ret;
+ }
+
+ cbphy->app_base = devm_platform_ioremap_resource_byname(pdev, "app");
+ if (IS_ERR(cbphy->app_base))
+ return PTR_ERR(cbphy->app_base);
+
+ cbphy->cr_base = devm_platform_ioremap_resource_byname(pdev, "core");
+ if (IS_ERR(cbphy->cr_base))
+ return PTR_ERR(cbphy->cr_base);
+
+ /*
+ * syscfg and hsiocfg variables stores the handle of the registers set
+ * in which ComboPhy subsytem specific registers are subset. Using
+ * Register map framework to access the registers set.
+ */
+ ret = fwnode_property_get_reference_args(fwnode, "intel,syscfg", NULL,
+ 1, 0, &ref);
+ if (ret < 0)
+ return ret;
+
+ cbphy->id = ref.args[0];
+ cbphy->syscfg = device_node_to_regmap(to_of_node(ref.fwnode));
+ fwnode_handle_put(ref.fwnode);
+
+ ret = fwnode_property_get_reference_args(fwnode, "intel,hsio", NULL, 1,
+ 0, &ref);
+ if (ret < 0)
+ return ret;
+
+ cbphy->bid = ref.args[0];
+ cbphy->hsiocfg = device_node_to_regmap(to_of_node(ref.fwnode));
+ fwnode_handle_put(ref.fwnode);
+
+ ret = fwnode_property_read_u32_array(fwnode, "intel,phy-mode", &val, 1);
+ if (ret)
+ return ret;
+
+ switch (val) {
+ case PHY_TYPE_PCIE:
+ cbphy->phy_mode = PHY_PCIE_MODE;
+ break;
+
+ case PHY_TYPE_SATA:
+ cbphy->phy_mode = PHY_SATA_MODE;
+ break;
+
+ case PHY_TYPE_XPCS:
+ cbphy->phy_mode = PHY_XPCS_MODE;
+ break;
+
+ default:
+ dev_err(dev, "Invalid PHY mode: %u\n", val);
+ return -EINVAL;
+ }
+
+ cbphy->clk_rate = intel_iphy_clk_rates[cbphy->phy_mode];
+
+ if (fwnode_property_present(fwnode, "intel,aggregation"))
+ cbphy->aggr_mode = PHY_DL_MODE;
+ else
+ cbphy->aggr_mode = PHY_SL_MODE;
+
+ return 0;
+}
+
+static const struct phy_ops intel_cbphy_ops = {
+ .init = intel_cbphy_init,
+ .exit = intel_cbphy_exit,
+ .calibrate = intel_cbphy_calibrate,
+ .owner = THIS_MODULE,
+};
+
+static struct phy *intel_cbphy_xlate(struct device *dev,
+ struct of_phandle_args *args)
+{
+ struct intel_combo_phy *cbphy = dev_get_drvdata(dev);
+ u32 iphy_id;
+
+ if (args->args_count < 1) {
+ dev_err(dev, "Invalid number of arguments\n");
+ return ERR_PTR(-EINVAL);
+ }
+
+ iphy_id = args->args[0];
+ if (iphy_id >= PHY_MAX_NUM) {
+ dev_err(dev, "Invalid phy instance %d\n", iphy_id);
+ return ERR_PTR(-EINVAL);
+ }
+
+ if (cbphy->aggr_mode == PHY_DL_MODE && iphy_id == PHY_1) {
+ dev_err(dev, "Invalid. ComboPhy is in Dual lane mode %d\n", iphy_id);
+ return ERR_PTR(-EINVAL);
+ }
+
+ return cbphy->iphy[iphy_id].phy;
+}
+
+static int intel_cbphy_create(struct intel_combo_phy *cbphy)
+{
+ struct phy_provider *phy_provider;
+ struct device *dev = cbphy->dev;
+ struct intel_cbphy_iphy *iphy;
+ int i;
+
+ for (i = 0; i < PHY_MAX_NUM; i++) {
+ iphy = &cbphy->iphy[i];
+ iphy->parent = cbphy;
+ iphy->id = i;
+
+ /* In dual lane mode skip phy creation for the second phy */
+ if (cbphy->aggr_mode == PHY_DL_MODE && iphy->id == PHY_1)
+ continue;
+
+ iphy->phy = devm_phy_create(dev, NULL, &intel_cbphy_ops);
+ if (IS_ERR(iphy->phy)) {
+ dev_err(dev, "PHY[%u:%u]: create PHY instance failed!\n",
+ COMBO_PHY_ID(iphy), PHY_ID(iphy));
+
+ return PTR_ERR(iphy->phy);
+ }
+
+ phy_set_drvdata(iphy->phy, iphy);
+ }
+
+ dev_set_drvdata(dev, cbphy);
+ phy_provider = devm_of_phy_provider_register(dev, intel_cbphy_xlate);
+ if (IS_ERR(phy_provider))
+ dev_err(dev, "Register PHY provider failed!\n");
+
+ return PTR_ERR_OR_ZERO(phy_provider);
+}
+
+static int intel_cbphy_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct intel_combo_phy *cbphy;
+ int ret;
+
+ cbphy = devm_kzalloc(dev, sizeof(*cbphy), GFP_KERNEL);
+ if (!cbphy)
+ return -ENOMEM;
+
+ cbphy->dev = dev;
+ cbphy->init_cnt = 0;
+ mutex_init(&cbphy->lock);
+ ret = intel_cbphy_fwnode_parse(cbphy);
+ if (ret)
+ return ret;
+
+ platform_set_drvdata(pdev, cbphy);
+
+ return intel_cbphy_create(cbphy);
+}
+
+static int intel_cbphy_remove(struct platform_device *pdev)
+{
+ struct intel_combo_phy *cbphy = platform_get_drvdata(pdev);
+
+ intel_cbphy_rst_assert(cbphy);
+ clk_disable_unprepare(cbphy->core_clk);
+ return 0;
+}
+
+static const struct of_device_id of_intel_cbphy_match[] = {
+ { .compatible = "intel,combo-phy" },
+ { .compatible = "intel,combophy-lgm" },
+ {}
+};
+
+static struct platform_driver intel_cbphy_driver = {
+ .probe = intel_cbphy_probe,
+ .remove = intel_cbphy_remove,
+ .driver = {
+ .name = "intel-combo-phy",
+ .of_match_table = of_intel_cbphy_match,
+ }
+};
+
+module_platform_driver(intel_cbphy_driver);
+
+MODULE_DESCRIPTION("Intel Combo-phy driver");
+MODULE_LICENSE("GPL v2");
--
2.11.0
^ permalink raw reply related
* [RESEND PATCH v8 2/3] dt-bindings: phy: Add YAML schemas for Intel ComboPhy
From: Dilip Kota @ 2020-05-15 8:13 UTC (permalink / raw)
To: linux-kernel, kishon, vkoul, devicetree
Cc: robh, andriy.shevchenko, cheol.yong.kim, chuanhua.lei, qi-ming.wu,
yixin.zhu, Dilip Kota
In-Reply-To: <cover.1589530082.git.eswara.kota@linux.intel.com>
ComboPhy subsystem provides PHY support to various
controllers, viz. PCIe, SATA and EMAC.
Adding YAML schemas for the same.
Signed-off-by: Dilip Kota <eswara.kota@linux.intel.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
Changes on v8:
No Change.
Changes on v7:
No Change.
Changes on v6:
Add Reviewed-by: Rob Herring <robh@kernel.org>
.../devicetree/bindings/phy/intel,combo-phy.yaml | 101 +++++++++++++++++++++
1 file changed, 101 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/intel,combo-phy.yaml
diff --git a/Documentation/devicetree/bindings/phy/intel,combo-phy.yaml b/Documentation/devicetree/bindings/phy/intel,combo-phy.yaml
new file mode 100644
index 000000000000..347d0cdfb80d
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/intel,combo-phy.yaml
@@ -0,0 +1,101 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/intel,combo-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Intel ComboPhy Subsystem
+
+maintainers:
+ - Dilip Kota <eswara.kota@linux.intel.com>
+
+description: |
+ Intel Combophy subsystem supports PHYs for PCIe, EMAC and SATA
+ controllers. A single Combophy provides two PHY instances.
+
+properties:
+ $nodename:
+ pattern: "combophy(@.*|-[0-9a-f])*$"
+
+ compatible:
+ items:
+ - const: intel,combophy-lgm
+ - const: intel,combo-phy
+
+ clocks:
+ maxItems: 1
+
+ reg:
+ items:
+ - description: ComboPhy core registers
+ - description: PCIe app core control registers
+
+ reg-names:
+ items:
+ - const: core
+ - const: app
+
+ resets:
+ maxItems: 4
+
+ reset-names:
+ items:
+ - const: phy
+ - const: core
+ - const: iphy0
+ - const: iphy1
+
+ intel,syscfg:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description: Chip configuration registers handle and ComboPhy instance id
+
+ intel,hsio:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description: HSIO registers handle and ComboPhy instance id on NOC
+
+ intel,aggregation:
+ type: boolean
+ description: |
+ Specify the flag to configure ComboPHY in dual lane mode.
+
+ intel,phy-mode:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: |
+ Mode of the two phys in ComboPhy.
+ See dt-bindings/phy/phy.h for values.
+
+ "#phy-cells":
+ const: 1
+
+required:
+ - compatible
+ - clocks
+ - reg
+ - reg-names
+ - intel,syscfg
+ - intel,hsio
+ - intel,phy-mode
+ - "#phy-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/phy/phy.h>
+ combophy@d0a00000 {
+ compatible = "intel,combophy-lgm", "intel,combo-phy";
+ clocks = <&cgu0 1>;
+ #phy-cells = <1>;
+ reg = <0xd0a00000 0x40000>,
+ <0xd0a40000 0x1000>;
+ reg-names = "core", "app";
+ resets = <&rcu0 0x50 6>,
+ <&rcu0 0x50 17>,
+ <&rcu0 0x50 23>,
+ <&rcu0 0x50 24>;
+ reset-names = "phy", "core", "iphy0", "iphy1";
+ intel,syscfg = <&sysconf 0>;
+ intel,hsio = <&hsiol 0>;
+ intel,phy-mode = <PHY_TYPE_PCIE>;
+ intel,aggregation;
+ };
--
2.11.0
^ permalink raw reply related
* [RESEND PATCH v8 1/3] dt-bindings: phy: Add PHY_TYPE_XPCS definition
From: Dilip Kota @ 2020-05-15 8:13 UTC (permalink / raw)
To: linux-kernel, kishon, vkoul, devicetree
Cc: robh, andriy.shevchenko, cheol.yong.kim, chuanhua.lei, qi-ming.wu,
yixin.zhu, Dilip Kota
In-Reply-To: <cover.1589530082.git.eswara.kota@linux.intel.com>
Add definition for Ethernet PCS phy type.
Signed-off-by: Dilip Kota <eswara.kota@linux.intel.com>
Acked-by: Rob Herring <robh@kernel.org>
---
Changes on v8:
No Change
Changes on v7:
No Change
Changes on v6:
Add Acked-by: Rob Herring <robh@kernel.org>
include/dt-bindings/phy/phy.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/dt-bindings/phy/phy.h b/include/dt-bindings/phy/phy.h
index 1f3f866fae7b..3727ef72138b 100644
--- a/include/dt-bindings/phy/phy.h
+++ b/include/dt-bindings/phy/phy.h
@@ -17,5 +17,6 @@
#define PHY_TYPE_USB3 4
#define PHY_TYPE_UFS 5
#define PHY_TYPE_DP 6
+#define PHY_TYPE_XPCS 7
#endif /* _DT_BINDINGS_PHY */
--
2.11.0
^ permalink raw reply related
* [RESEND PATCH v8 0/3] Add Intel ComboPhy driver
From: Dilip Kota @ 2020-05-15 8:13 UTC (permalink / raw)
To: linux-kernel, kishon, vkoul, devicetree
Cc: robh, andriy.shevchenko, cheol.yong.kim, chuanhua.lei, qi-ming.wu,
yixin.zhu, Dilip Kota
This patch series adds Intel ComboPhy driver, respective yaml schemas
Changes on v8:
As per PHY Maintainer's request add description in comments for doing
register access through register map framework.
Changes on v7:
As per System control driver maintainer's inputs remove
fwnode_to_regmap() definition and use device_node_get_regmap()
Changes on v6:
Rebase patches on the latest maintainer's branch
https://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git/?h=phy-for-5.7
Dilip Kota (3):
dt-bindings: phy: Add PHY_TYPE_XPCS definition
dt-bindings: phy: Add YAML schemas for Intel ComboPhy
phy: intel: Add driver support for ComboPhy
.../devicetree/bindings/phy/intel,combo-phy.yaml | 101 ++++
drivers/phy/intel/Kconfig | 14 +
drivers/phy/intel/Makefile | 1 +
drivers/phy/intel/phy-intel-combo.c | 632 +++++++++++++++++++++
include/dt-bindings/phy/phy.h | 1 +
5 files changed, 749 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/intel,combo-phy.yaml
create mode 100644 drivers/phy/intel/phy-intel-combo.c
--
2.11.0
^ permalink raw reply
* Re: [PATCH v8 3/3] phy: intel: Add driver support for ComboPhy
From: Dilip Kota @ 2020-05-15 8:05 UTC (permalink / raw)
To: Vinod Koul
Cc: linux-kernel, kishon, devicetree, robh, andriy.shevchenko,
cheol.yong.kim, chuanhua.lei, qi-ming.wu, yixin.zhu
In-Reply-To: <20200515073959.GM333670@vkoul-mobl>
On 5/15/2020 3:39 PM, Vinod Koul wrote:
> On 15-05-20, 12:30, Dilip Kota wrote:
>> ComboPhy subsystem provides PHYs for various
>> controllers like PCIe, SATA and EMAC.
>>
>> Signed-off-by: Dilip Kota <eswara.kota@linux.intel.com>
>> ---
>> Changes on v8:
>> As per PHY Maintainer's request add description for doing register access
>> through regmap in comments.
> I dont see any comments below, and my script tells me this is *same* as
> v7, did you send the wrong version?
My bad. I missed the git add step and sent patch series.
Will resend the patch series.
Regards,
Dilip
>
>> Changes on v7:
>> Use device_node_to_regmap instead of fwnode_to_regmap
>>
>> Changes on v6:
>> No changes
>>
>> Changes on v5:
>> Add changes as per inputs from Andy and Rob:
>> DT node uses phy-mode values as defined in "include/dt-bindings/phy/phy.h",
>> add changes to handle it.
>> ComboPhy no longer has children nodes, and children node properties(reset)
>> moved to parent node, so do the code changes accordingly.
>> Add _xlate() function to pass the appropriate phy handle.
>> Fix couple of nitpicks.
>>
>> Changes on v4:
>> Address review comments
>> Remove dependency on OF config
>> Update copyright to 2019-2020
>> Define register macro PAD_DIS_CFG instead of const variable inside function.
>> Improve the error prints, and error returns.
>> Call put_device(dev), for get_dev_from_fwnode()
>> Move platform_set_drvdata() at the end of the probe().
>> Correct alignment in phy_ops intel_cbphy_ops.
>> Correct commented lines with proper vocabulary and punctuation.
>> Add/remove commas for the required constant arrays and enums.
>> Remove in driver:
>> linux/kernel.h, not required
>> macros: PCIE_PHY_MPLLA_CTRL, PCIE_PHY_MPLLB_CTRL
>> temp variable u32 prop;
>> Change function names:
>> intel_cbphy_iphy_dt_parse() -> intel_cbphy_iphy_fwnode_parse()
>> intel_cbphy_dt_sanity_check() -> intel_cbphy_sanity_check()
>> intel_cbphy_dt_parse() -> intel_cbphy_fwnode_parse()
>>
>> Changes on v3:
>> Remove intel_iphy_names
>> Remove struct phy in struct intel_cbphy_iphy
>> Imporve if conditions logic
>> Use fwnode_to_regmap()
>> Call devm_of_platform_populate() to populate child nodes
>> Fix reset sequence during phy_init
>> Add SoC specific compatible "intel,combophy-lgm"
>> Add description for enums
>> Remove default case in switch {} intel_cbphy_set_mode() as it
>> never happens.
>> Use mutex_lock to synchronise combophy initialization across
>> two phys.
>> Change init_cnt to u32 datatype as it is within mutex lock.
>> Correct error handling of
>> fwnode_property_read_u32_array(fwnode, "intel,phy-mode", ...)
>>
>> drivers/phy/intel/Kconfig | 14 +
>> drivers/phy/intel/Makefile | 1 +
>> drivers/phy/intel/phy-intel-combo.c | 627 ++++++++++++++++++++++++++++++++++++
>> 3 files changed, 642 insertions(+)
>> create mode 100644 drivers/phy/intel/phy-intel-combo.c
>>
>> diff --git a/drivers/phy/intel/Kconfig b/drivers/phy/intel/Kconfig
>> index 4ea6a8897cd7..3b40eb7b4fb4 100644
>> --- a/drivers/phy/intel/Kconfig
>> +++ b/drivers/phy/intel/Kconfig
>> @@ -2,6 +2,20 @@
>> #
>> # Phy drivers for Intel Lightning Mountain(LGM) platform
>> #
>> +config PHY_INTEL_COMBO
>> + bool "Intel ComboPHY driver"
>> + depends on X86 || COMPILE_TEST
>> + depends on OF && HAS_IOMEM
>> + select MFD_SYSCON
>> + select GENERIC_PHY
>> + select REGMAP
>> + help
>> + Enable this to support Intel ComboPhy.
>> +
>> + This driver configures ComboPhy subsystem on Intel gateway
>> + chipsets which provides PHYs for various controllers, EMAC,
>> + SATA and PCIe.
>> +
>> config PHY_INTEL_EMMC
>> tristate "Intel EMMC PHY driver"
>> select GENERIC_PHY
>> diff --git a/drivers/phy/intel/Makefile b/drivers/phy/intel/Makefile
>> index 6b876a75599d..233d530dadde 100644
>> --- a/drivers/phy/intel/Makefile
>> +++ b/drivers/phy/intel/Makefile
>> @@ -1,2 +1,3 @@
>> # SPDX-License-Identifier: GPL-2.0
>> +obj-$(CONFIG_PHY_INTEL_COMBO) += phy-intel-combo.o
>> obj-$(CONFIG_PHY_INTEL_EMMC) += phy-intel-emmc.o
>> diff --git a/drivers/phy/intel/phy-intel-combo.c b/drivers/phy/intel/phy-intel-combo.c
>> new file mode 100644
>> index 000000000000..04ad595e21e4
>> --- /dev/null
>> +++ b/drivers/phy/intel/phy-intel-combo.c
>> @@ -0,0 +1,627 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Intel Combo-PHY driver
>> + *
>> + * Copyright (C) 2019-2020 Intel Corporation.
>> + */
>> +
>> +#include <linux/bitfield.h>
>> +#include <linux/clk.h>
>> +#include <linux/iopoll.h>
>> +#include <linux/mfd/syscon.h>
>> +#include <linux/module.h>
>> +#include <linux/mutex.h>
>> +#include <linux/of.h>
>> +#include <linux/phy/phy.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/regmap.h>
>> +#include <linux/reset.h>
>> +
>> +#include <dt-bindings/phy/phy.h>
>> +
>> +#define PCIE_PHY_GEN_CTRL 0x00
>> +#define PCIE_PHY_CLK_PAD BIT(17)
>> +
>> +#define PAD_DIS_CFG 0x174
>> +
>> +#define PCS_XF_ATE_OVRD_IN_2 0x3008
>> +#define ADAPT_REQ_MSK GENMASK(5, 4)
>> +
>> +#define PCS_XF_RX_ADAPT_ACK 0x3010
>> +#define RX_ADAPT_ACK_BIT BIT(0)
>> +
>> +#define CR_ADDR(addr, lane) (((addr) + (lane) * 0x100) << 2)
>> +#define REG_COMBO_MODE(x) ((x) * 0x200)
>> +#define REG_CLK_DISABLE(x) ((x) * 0x200 + 0x124)
>> +
>> +#define COMBO_PHY_ID(x) ((x)->parent->id)
>> +#define PHY_ID(x) ((x)->id)
>> +
>> +#define CLK_100MHZ 100000000
>> +#define CLK_156_25MHZ 156250000
>> +
>> +static const unsigned long intel_iphy_clk_rates[] = {
>> + CLK_100MHZ, CLK_156_25MHZ, CLK_100MHZ,
>> +};
>> +
>> +enum {
>> + PHY_0,
>> + PHY_1,
>> + PHY_MAX_NUM
>> +};
>> +
>> +/*
>> + * Clock Register bit fields to enable clocks
>> + * for ComboPhy according to the mode.
>> + */
>> +enum intel_phy_mode {
>> + PHY_PCIE_MODE = 0,
>> + PHY_XPCS_MODE,
>> + PHY_SATA_MODE,
>> +};
>> +
>> +/* ComboPhy mode Register values */
>> +enum intel_combo_mode {
>> + PCIE0_PCIE1_MODE = 0,
>> + PCIE_DL_MODE,
>> + RXAUI_MODE,
>> + XPCS0_XPCS1_MODE,
>> + SATA0_SATA1_MODE,
>> +};
>> +
>> +enum aggregated_mode {
>> + PHY_SL_MODE,
>> + PHY_DL_MODE,
>> +};
>> +
>> +struct intel_combo_phy;
>> +
>> +struct intel_cbphy_iphy {
>> + struct phy *phy;
>> + struct intel_combo_phy *parent;
>> + struct reset_control *app_rst;
>> + u32 id;
>> +};
>> +
>> +struct intel_combo_phy {
>> + struct device *dev;
>> + struct clk *core_clk;
>> + unsigned long clk_rate;
>> + void __iomem *app_base;
>> + void __iomem *cr_base;
>> + struct regmap *syscfg;
>> + struct regmap *hsiocfg;
>> + u32 id;
>> + u32 bid;
>> + struct reset_control *phy_rst;
>> + struct reset_control *core_rst;
>> + struct intel_cbphy_iphy iphy[PHY_MAX_NUM];
>> + enum intel_phy_mode phy_mode;
>> + enum aggregated_mode aggr_mode;
>> + u32 init_cnt;
>> + struct mutex lock;
>> +};
>> +
>> +static int intel_cbphy_iphy_enable(struct intel_cbphy_iphy *iphy, bool set)
>> +{
>> + struct intel_combo_phy *cbphy = iphy->parent;
>> + u32 mask = BIT(cbphy->phy_mode * 2 + iphy->id);
>> + u32 val;
>> +
>> + /* Register: 0 is enable, 1 is disable */
>> + val = set ? 0 : mask;
>> +
>> + return regmap_update_bits(cbphy->hsiocfg, REG_CLK_DISABLE(cbphy->bid),
>> + mask, val);
>> +}
>> +
>> +static int intel_cbphy_pcie_refclk_cfg(struct intel_cbphy_iphy *iphy, bool set)
>> +{
>> + struct intel_combo_phy *cbphy = iphy->parent;
>> + u32 mask = BIT(cbphy->id * 2 + iphy->id);
>> + u32 val;
>> +
>> + /* Register: 0 is enable, 1 is disable */
>> + val = set ? 0 : mask;
>> +
>> + return regmap_update_bits(cbphy->syscfg, PAD_DIS_CFG, mask, val);
>> +}
>> +
>> +static inline void combo_phy_w32_off_mask(void __iomem *base, unsigned int reg,
>> + u32 mask, u32 val)
>> +{
>> + u32 reg_val;
>> +
>> + reg_val = readl(base + reg);
>> + reg_val &= ~mask;
>> + reg_val |= FIELD_PREP(mask, val);
>> + writel(reg_val, base + reg);
>> +}
>> +
>> +static int intel_cbphy_iphy_cfg(struct intel_cbphy_iphy *iphy,
>> + int (*phy_cfg)(struct intel_cbphy_iphy *))
>> +{
>> + struct intel_combo_phy *cbphy = iphy->parent;
>> + int ret;
>> +
>> + ret = phy_cfg(iphy);
>> + if (ret)
>> + return ret;
>> +
>> + if (cbphy->aggr_mode != PHY_DL_MODE)
>> + return 0;
>> +
>> + return phy_cfg(&cbphy->iphy[PHY_1]);
>> +}
>> +
>> +static int intel_cbphy_pcie_en_pad_refclk(struct intel_cbphy_iphy *iphy)
>> +{
>> + struct intel_combo_phy *cbphy = iphy->parent;
>> + int ret;
>> +
>> + ret = intel_cbphy_pcie_refclk_cfg(iphy, true);
>> + if (ret) {
>> + dev_err(cbphy->dev, "Failed to enable PCIe pad refclk\n");
>> + return ret;
>> + }
>> +
>> + if (cbphy->init_cnt)
>> + return 0;
>> +
>> + combo_phy_w32_off_mask(cbphy->app_base, PCIE_PHY_GEN_CTRL,
>> + PCIE_PHY_CLK_PAD, 0);
>> +
>> + /* Delay for stable clock PLL */
>> + usleep_range(50, 100);
>> +
>> + return 0;
>> +}
>> +
>> +static int intel_cbphy_pcie_dis_pad_refclk(struct intel_cbphy_iphy *iphy)
>> +{
>> + struct intel_combo_phy *cbphy = iphy->parent;
>> + int ret;
>> +
>> + ret = intel_cbphy_pcie_refclk_cfg(iphy, false);
>> + if (ret) {
>> + dev_err(cbphy->dev, "Failed to disable PCIe pad refclk\n");
>> + return ret;
>> + }
>> +
>> + if (cbphy->init_cnt)
>> + return 0;
>> +
>> + combo_phy_w32_off_mask(cbphy->app_base, PCIE_PHY_GEN_CTRL,
>> + PCIE_PHY_CLK_PAD, 1);
>> +
>> + return 0;
>> +}
>> +
>> +static int intel_cbphy_set_mode(struct intel_combo_phy *cbphy)
>> +{
>> + enum aggregated_mode aggr = cbphy->aggr_mode;
>> + struct device *dev = cbphy->dev;
>> + enum intel_combo_mode cb_mode;
>> + enum intel_phy_mode mode;
>> + int ret;
>> +
>> + mode = cbphy->phy_mode;
>> +
>> + switch (mode) {
>> + case PHY_PCIE_MODE:
>> + cb_mode = (aggr == PHY_DL_MODE) ? PCIE_DL_MODE : PCIE0_PCIE1_MODE;
>> + break;
>> +
>> + case PHY_XPCS_MODE:
>> + cb_mode = (aggr == PHY_DL_MODE) ? RXAUI_MODE : XPCS0_XPCS1_MODE;
>> + break;
>> +
>> + case PHY_SATA_MODE:
>> + if (aggr == PHY_DL_MODE) {
>> + dev_err(dev, "Mode:%u not support dual lane!\n", mode);
>> + return -EINVAL;
>> + }
>> +
>> + cb_mode = SATA0_SATA1_MODE;
>> + break;
>> + }
>> +
>> + ret = regmap_write(cbphy->hsiocfg, REG_COMBO_MODE(cbphy->bid), cb_mode);
>> + if (ret)
>> + dev_err(dev, "Failed to set ComboPhy mode: %d\n", ret);
>> +
>> + return ret;
>> +}
>> +
>> +static void intel_cbphy_rst_assert(struct intel_combo_phy *cbphy)
>> +{
>> + reset_control_assert(cbphy->core_rst);
>> + reset_control_assert(cbphy->phy_rst);
>> +}
>> +
>> +static void intel_cbphy_rst_deassert(struct intel_combo_phy *cbphy)
>> +{
>> + reset_control_deassert(cbphy->core_rst);
>> + reset_control_deassert(cbphy->phy_rst);
>> + /* Delay to ensure reset process is done */
>> + usleep_range(10, 20);
>> +}
>> +
>> +static int intel_cbphy_iphy_power_on(struct intel_cbphy_iphy *iphy)
>> +{
>> + struct intel_combo_phy *cbphy = iphy->parent;
>> + int ret;
>> +
>> + if (!cbphy->init_cnt) {
>> + ret = clk_prepare_enable(cbphy->core_clk);
>> + if (ret) {
>> + dev_err(cbphy->dev, "Clock enable failed!\n");
>> + return ret;
>> + }
>> +
>> + ret = clk_set_rate(cbphy->core_clk, cbphy->clk_rate);
>> + if (ret) {
>> + dev_err(cbphy->dev, "Clock freq set to %lu failed!\n",
>> + cbphy->clk_rate);
>> + goto clk_err;
>> + }
>> +
>> + intel_cbphy_rst_assert(cbphy);
>> + intel_cbphy_rst_deassert(cbphy);
>> + ret = intel_cbphy_set_mode(cbphy);
>> + if (ret)
>> + goto clk_err;
>> + }
>> +
>> + ret = intel_cbphy_iphy_enable(iphy, true);
>> + if (ret) {
>> + dev_err(cbphy->dev, "Failed enabling PHY core\n");
>> + goto clk_err;
>> + }
>> +
>> + ret = reset_control_deassert(iphy->app_rst);
>> + if (ret) {
>> + dev_err(cbphy->dev, "PHY(%u:%u) reset deassert failed!\n",
>> + COMBO_PHY_ID(iphy), PHY_ID(iphy));
>> + goto clk_err;
>> + }
>> +
>> + /* Delay to ensure reset process is done */
>> + udelay(1);
>> +
>> + return 0;
>> +
>> +clk_err:
>> + clk_disable_unprepare(cbphy->core_clk);
>> +
>> + return ret;
>> +}
>> +
>> +static int intel_cbphy_iphy_power_off(struct intel_cbphy_iphy *iphy)
>> +{
>> + struct intel_combo_phy *cbphy = iphy->parent;
>> + int ret;
>> +
>> + ret = reset_control_assert(iphy->app_rst);
>> + if (ret) {
>> + dev_err(cbphy->dev, "PHY(%u:%u) reset assert failed!\n",
>> + COMBO_PHY_ID(iphy), PHY_ID(iphy));
>> + return ret;
>> + }
>> +
>> + ret = intel_cbphy_iphy_enable(iphy, false);
>> + if (ret) {
>> + dev_err(cbphy->dev, "Failed disabling PHY core\n");
>> + return ret;
>> + }
>> +
>> + if (cbphy->init_cnt)
>> + return 0;
>> +
>> + clk_disable_unprepare(cbphy->core_clk);
>> + intel_cbphy_rst_assert(cbphy);
>> +
>> + return 0;
>> +}
>> +
>> +static int intel_cbphy_init(struct phy *phy)
>> +{
>> + struct intel_cbphy_iphy *iphy = phy_get_drvdata(phy);
>> + struct intel_combo_phy *cbphy = iphy->parent;
>> + int ret;
>> +
>> + mutex_lock(&cbphy->lock);
>> + ret = intel_cbphy_iphy_cfg(iphy, intel_cbphy_iphy_power_on);
>> + if (ret)
>> + goto err;
>> +
>> + if (cbphy->phy_mode == PHY_PCIE_MODE) {
>> + ret = intel_cbphy_iphy_cfg(iphy, intel_cbphy_pcie_en_pad_refclk);
>> + if (ret)
>> + goto err;
>> + }
>> +
>> + cbphy->init_cnt++;
>> +
>> +err:
>> + mutex_unlock(&cbphy->lock);
>> +
>> + return ret;
>> +}
>> +
>> +static int intel_cbphy_exit(struct phy *phy)
>> +{
>> + struct intel_cbphy_iphy *iphy = phy_get_drvdata(phy);
>> + struct intel_combo_phy *cbphy = iphy->parent;
>> + int ret;
>> +
>> + mutex_lock(&cbphy->lock);
>> + cbphy->init_cnt--;
>> + if (cbphy->phy_mode == PHY_PCIE_MODE) {
>> + ret = intel_cbphy_iphy_cfg(iphy, intel_cbphy_pcie_dis_pad_refclk);
>> + if (ret)
>> + goto err;
>> + }
>> +
>> + ret = intel_cbphy_iphy_cfg(iphy, intel_cbphy_iphy_power_off);
>> +
>> +err:
>> + mutex_unlock(&cbphy->lock);
>> +
>> + return ret;
>> +}
>> +
>> +static int intel_cbphy_calibrate(struct phy *phy)
>> +{
>> + struct intel_cbphy_iphy *iphy = phy_get_drvdata(phy);
>> + struct intel_combo_phy *cbphy = iphy->parent;
>> + void __iomem *cr_base = cbphy->cr_base;
>> + int val, ret, id;
>> +
>> + if (cbphy->phy_mode != PHY_XPCS_MODE)
>> + return 0;
>> +
>> + id = PHY_ID(iphy);
>> +
>> + /* trigger auto RX adaptation */
>> + combo_phy_w32_off_mask(cr_base, CR_ADDR(PCS_XF_ATE_OVRD_IN_2, id),
>> + ADAPT_REQ_MSK, 3);
>> + /* Wait RX adaptation to finish */
>> + ret = readl_poll_timeout(cr_base + CR_ADDR(PCS_XF_RX_ADAPT_ACK, id),
>> + val, val & RX_ADAPT_ACK_BIT, 10, 5000);
>> + if (ret)
>> + dev_err(cbphy->dev, "RX Adaptation failed!\n");
>> + else
>> + dev_dbg(cbphy->dev, "RX Adaptation success!\n");
>> +
>> + /* Stop RX adaptation */
>> + combo_phy_w32_off_mask(cr_base, CR_ADDR(PCS_XF_ATE_OVRD_IN_2, id),
>> + ADAPT_REQ_MSK, 0);
>> +
>> + return ret;
>> +}
>> +
>> +static int intel_cbphy_fwnode_parse(struct intel_combo_phy *cbphy)
>> +{
>> + struct device *dev = cbphy->dev;
>> + struct platform_device *pdev = to_platform_device(dev);
>> + struct fwnode_handle *fwnode = dev_fwnode(dev);
>> + struct fwnode_reference_args ref;
>> + int ret;
>> + u32 val;
>> +
>> + cbphy->core_clk = devm_clk_get(dev, NULL);
>> + if (IS_ERR(cbphy->core_clk)) {
>> + ret = PTR_ERR(cbphy->core_clk);
>> + if (ret != -EPROBE_DEFER)
>> + dev_err(dev, "Get clk failed:%d!\n", ret);
>> + return ret;
>> + }
>> +
>> + cbphy->core_rst = devm_reset_control_get_optional(dev, "core");
>> + if (IS_ERR(cbphy->core_rst)) {
>> + ret = PTR_ERR(cbphy->core_rst);
>> + if (ret != -EPROBE_DEFER)
>> + dev_err(dev, "Get core reset control err: %d!\n", ret);
>> + return ret;
>> + }
>> +
>> + cbphy->phy_rst = devm_reset_control_get_optional(dev, "phy");
>> + if (IS_ERR(cbphy->phy_rst)) {
>> + ret = PTR_ERR(cbphy->phy_rst);
>> + if (ret != -EPROBE_DEFER)
>> + dev_err(dev, "Get PHY reset control err: %d!\n", ret);
>> + return ret;
>> + }
>> +
>> + cbphy->iphy[0].app_rst = devm_reset_control_get_optional(dev, "iphy0");
>> + if (IS_ERR(cbphy->iphy[0].app_rst)) {
>> + ret = PTR_ERR(cbphy->iphy[0].app_rst);
>> + if (ret != -EPROBE_DEFER)
>> + dev_err(dev, "Get phy0 reset control err: %d!\n", ret);
>> + return ret;
>> + }
>> +
>> + cbphy->iphy[1].app_rst = devm_reset_control_get_optional(dev, "iphy1");
>> + if (IS_ERR(cbphy->iphy[1].app_rst)) {
>> + ret = PTR_ERR(cbphy->iphy[1].app_rst);
>> + if (ret != -EPROBE_DEFER)
>> + dev_err(dev, "Get phy1 reset control err: %d!\n", ret);
>> + return ret;
>> + }
>> +
>> + cbphy->app_base = devm_platform_ioremap_resource_byname(pdev, "app");
>> + if (IS_ERR(cbphy->app_base))
>> + return PTR_ERR(cbphy->app_base);
>> +
>> + cbphy->cr_base = devm_platform_ioremap_resource_byname(pdev, "core");
>> + if (IS_ERR(cbphy->cr_base))
>> + return PTR_ERR(cbphy->cr_base);
>> +
>> + ret = fwnode_property_get_reference_args(fwnode, "intel,syscfg", NULL,
>> + 1, 0, &ref);
>> + if (ret < 0)
>> + return ret;
>> +
>> + cbphy->id = ref.args[0];
>> + cbphy->syscfg = device_node_to_regmap(to_of_node(ref.fwnode));
>> + fwnode_handle_put(ref.fwnode);
>> +
>> + ret = fwnode_property_get_reference_args(fwnode, "intel,hsio", NULL, 1,
>> + 0, &ref);
>> + if (ret < 0)
>> + return ret;
>> +
>> + cbphy->bid = ref.args[0];
>> + cbphy->hsiocfg = device_node_to_regmap(to_of_node(ref.fwnode));
>> + fwnode_handle_put(ref.fwnode);
>> +
>> + ret = fwnode_property_read_u32_array(fwnode, "intel,phy-mode", &val, 1);
>> + if (ret)
>> + return ret;
>> +
>> + switch (val) {
>> + case PHY_TYPE_PCIE:
>> + cbphy->phy_mode = PHY_PCIE_MODE;
>> + break;
>> +
>> + case PHY_TYPE_SATA:
>> + cbphy->phy_mode = PHY_SATA_MODE;
>> + break;
>> +
>> + case PHY_TYPE_XPCS:
>> + cbphy->phy_mode = PHY_XPCS_MODE;
>> + break;
>> +
>> + default:
>> + dev_err(dev, "Invalid PHY mode: %u\n", val);
>> + return -EINVAL;
>> + }
>> +
>> + cbphy->clk_rate = intel_iphy_clk_rates[cbphy->phy_mode];
>> +
>> + if (fwnode_property_present(fwnode, "intel,aggregation"))
>> + cbphy->aggr_mode = PHY_DL_MODE;
>> + else
>> + cbphy->aggr_mode = PHY_SL_MODE;
>> +
>> + return 0;
>> +}
>> +
>> +static const struct phy_ops intel_cbphy_ops = {
>> + .init = intel_cbphy_init,
>> + .exit = intel_cbphy_exit,
>> + .calibrate = intel_cbphy_calibrate,
>> + .owner = THIS_MODULE,
>> +};
>> +
>> +static struct phy *intel_cbphy_xlate(struct device *dev,
>> + struct of_phandle_args *args)
>> +{
>> + struct intel_combo_phy *cbphy = dev_get_drvdata(dev);
>> + u32 iphy_id;
>> +
>> + if (args->args_count < 1) {
>> + dev_err(dev, "Invalid number of arguments\n");
>> + return ERR_PTR(-EINVAL);
>> + }
>> +
>> + iphy_id = args->args[0];
>> + if (iphy_id >= PHY_MAX_NUM) {
>> + dev_err(dev, "Invalid phy instance %d\n", iphy_id);
>> + return ERR_PTR(-EINVAL);
>> + }
>> +
>> + if (cbphy->aggr_mode == PHY_DL_MODE && iphy_id == PHY_1) {
>> + dev_err(dev, "Invalid. ComboPhy is in Dual lane mode %d\n", iphy_id);
>> + return ERR_PTR(-EINVAL);
>> + }
>> +
>> + return cbphy->iphy[iphy_id].phy;
>> +}
>> +
>> +static int intel_cbphy_create(struct intel_combo_phy *cbphy)
>> +{
>> + struct phy_provider *phy_provider;
>> + struct device *dev = cbphy->dev;
>> + struct intel_cbphy_iphy *iphy;
>> + int i;
>> +
>> + for (i = 0; i < PHY_MAX_NUM; i++) {
>> + iphy = &cbphy->iphy[i];
>> + iphy->parent = cbphy;
>> + iphy->id = i;
>> +
>> + /* In dual lane mode skip phy creation for the second phy */
>> + if (cbphy->aggr_mode == PHY_DL_MODE && iphy->id == PHY_1)
>> + continue;
>> +
>> + iphy->phy = devm_phy_create(dev, NULL, &intel_cbphy_ops);
>> + if (IS_ERR(iphy->phy)) {
>> + dev_err(dev, "PHY[%u:%u]: create PHY instance failed!\n",
>> + COMBO_PHY_ID(iphy), PHY_ID(iphy));
>> +
>> + return PTR_ERR(iphy->phy);
>> + }
>> +
>> + phy_set_drvdata(iphy->phy, iphy);
>> + }
>> +
>> + dev_set_drvdata(dev, cbphy);
>> + phy_provider = devm_of_phy_provider_register(dev, intel_cbphy_xlate);
>> + if (IS_ERR(phy_provider))
>> + dev_err(dev, "Register PHY provider failed!\n");
>> +
>> + return PTR_ERR_OR_ZERO(phy_provider);
>> +}
>> +
>> +static int intel_cbphy_probe(struct platform_device *pdev)
>> +{
>> + struct device *dev = &pdev->dev;
>> + struct intel_combo_phy *cbphy;
>> + int ret;
>> +
>> + cbphy = devm_kzalloc(dev, sizeof(*cbphy), GFP_KERNEL);
>> + if (!cbphy)
>> + return -ENOMEM;
>> +
>> + cbphy->dev = dev;
>> + cbphy->init_cnt = 0;
>> + mutex_init(&cbphy->lock);
>> + ret = intel_cbphy_fwnode_parse(cbphy);
>> + if (ret)
>> + return ret;
>> +
>> + platform_set_drvdata(pdev, cbphy);
>> +
>> + return intel_cbphy_create(cbphy);
>> +}
>> +
>> +static int intel_cbphy_remove(struct platform_device *pdev)
>> +{
>> + struct intel_combo_phy *cbphy = platform_get_drvdata(pdev);
>> +
>> + intel_cbphy_rst_assert(cbphy);
>> + clk_disable_unprepare(cbphy->core_clk);
>> + return 0;
>> +}
>> +
>> +static const struct of_device_id of_intel_cbphy_match[] = {
>> + { .compatible = "intel,combo-phy" },
>> + { .compatible = "intel,combophy-lgm" },
>> + {}
>> +};
>> +
>> +static struct platform_driver intel_cbphy_driver = {
>> + .probe = intel_cbphy_probe,
>> + .remove = intel_cbphy_remove,
>> + .driver = {
>> + .name = "intel-combo-phy",
>> + .of_match_table = of_intel_cbphy_match,
>> + }
>> +};
>> +
>> +module_platform_driver(intel_cbphy_driver);
>> +
>> +MODULE_DESCRIPTION("Intel Combo-phy driver");
>> +MODULE_LICENSE("GPL v2");
>> --
>> 2.11.0
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox