* Re: [PATCH 0/5] Meson GXL and GXM USB support
From: Rob Herring @ 2016-11-30 22:22 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, kishon-l0cyMroinI0,
khilman-rdvid1DuHRBWk0Htik3J/w, carlo-KA+7E9HrN00dnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, narmstrong-rdvid1DuHRBWk0Htik3J/w
In-Reply-To: <CAFBinCAA_JEtr_0Ze0thoRaEKMnWQMKcPxJ8y88zkWAAhuxsMw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Sun, Nov 27, 2016 at 11:42:02PM +0100, Martin Blumenstingl wrote:
> Hello Kishon,
>
> On Sat, Nov 26, 2016 at 3:56 PM, Martin Blumenstingl
> <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote:
> > USB support on GXL and GXM differs a lot from Meson8b and GXBB:
> > The most obvious change is that GXL and GXM now have one dwc3
> > controller and one dwc2 controller (instead of two dwc2 controllers).
> > With that there are also new USB PHYs.
> >
> > Due to lack of hardware I was only able to test this on a board with
> > GXM, but as far as I understand the hardware my preparations should be
> > correct (so it should also work on GXL).
> >
> > dwc2 will probably stay unused on most GXM devices since it's limited
> > to device mode via some dwc2 hardware configuration register.
> >
> > dwc3 is probably used on all devices, even if there is more than just
> > one USB port. dwc3 has a built-in USB2 hub - on GXL this hub has two
> > ports enabled, while on GXM there are three ports enabled (see below
This hub is an actual USB hub? If so, then you should probably model the
USB bus topology (which we have a binding definition for).
> > for lsusb output). There are no USB3 ports enabled in the dwc3 hardware
> > configuration, meaning that the SoC is limited to high-speed mode.
> > On my GXM device the dwc3 hardware configuration forces it into "host
> > only" mode.
> >
> > The SoCs contain two PHY blocks: one USB3 PHY and up to four USB2 PHYs
> > (on GXM there are only three enabled, but the registers should support
> > up to four).
> > The USB3 PHY also handles the OTG interrupts, but since dwc3's hardware
> > configuration enforces "host only" mode I was not able to test this. It
> > simply takes care of an interrupt and then notifies all related PHYs
> > about the new mode.
> > The USB2 PHY block is a bit different: I created one PHY driver which
> > spans all "PHY ports" because the handling is a bit tricky. It turns
> > out that for each available USB port in dwc3's hub the corresponding
> > PHY must be enabled (even if there is no physical port - in my case
> > port 3 is not connected to anything, but disabling the PHY breaks
> > ports 1 and 2 as well).
> > I decided not not pass the USB2 PHYs directly to dwc3 due to three
> > reasons: 1. the USB3 PHY (which holds a reference to all relevant
> > USB2 PHY ports) controls the mode of the USB2 PHY ports (since both
> > are used with the same controller and thus it makes sense to keep the
> > mode consistent across all ports) 2. the dwc3 driver does not support
> > passing multiple USB2 PHYs (only one USB2 and one USB3 PHY can be
> > passed to it) 3. it is similar to how the vendor reference driver
> > manages the PHYs. Please note that this coupling is not a fixed, this
> > is all configurable via devicetree (so if the third USB2 PHY has to
> > be passed two the dwc2 controller then this is still possible by
> > just moving on PHY reference in the .dts).
> after not staring at my own code for 24 hours I realized this:
> (I went through quite a few iterations before getting these drivers to work)
> I'm basically re-modelling an "USB PHY hub" with my USB3 PHY driver
> (there's one "upstream" PHY interface which is passed to dwc3 and
> multiple downstream PHYs, each for one port on dwc3's internal hub).
> With this approach I could split each of the the USB2s into separate
> nodes again (instead of one devicetree node with #phy-cells = <1>) as
> the USB3 PHY is taking care of that special "we have to enable all
> ports or no port will be usable".
>
> We could go even one step further: why implement this in the Meson GXL
> specific PHY driver - why not implement a generic "phy-hub" driver
> (which would be valid whenever the PHY controller has to manage
> multiple PHYs at once, but wants to keep them all in a consistent
> state).
> The devicetree could look like this:
> usb2_phy_hub: phy@0 {
> compatible = "phy-hub";
> phys = <&other_phy1>, <&other_phy 2>;
> };
>
> &dwc3 {
> phys = <&usb2_phy_hub>, <&usb3_phy0>;
> phy-names = "usb2-phy", "usb3-phy";
> };
I'm okay with a hub if it is modeled as a USB hub. Here though, it
looks like you are just trying to group things which doesn't need to be
in DT.
>
> The generic phy-hub driver would then implement all phy_ops callbacks
> and pass then to each of it's downstream PHYs.
You can have generic drivers without a generic binding.
> That's just what came into my head - please let me know what you think
> of this or share your ideas on how to approach this!
>
> > The coupling of the USB2 and USB3 PHYs is the reason why I sent the
> > two drivers in one patch, even though they are handling different IP
> > blocks (different registers, etc.).
> >
> > Unfortunately there are no datasheets available for any of these PHYs.
> > Both drivers were written by reading the reference drivers provided by
> > Amlogic and analyzing the registers on the kernel that was shipped with
> > my board.
> >
> > As a last note: the dwc3 driver currently only explicitly enables the
> > first USB port "DWC3_GUSB2PHYCFG(0)" in the internal hub. The hardware
> > seems to enable the other two (DWC3_GUSB2PHYCFG(1) and
> > DWC3_GUSB2PHYCFG(2)) automatically. I will ask the dwc3 maintainers if
> > changes to dwc3 are desired any how these should look like, but for now
> > it's working fine even without changes there.
> >
> > lsusb output on GXM for the dwc3 hub:
> > Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> > ...
> > Hub Port Status:
> > Port 1: 0000.0100 power
> > Port 2: 0000.0100 power
> > Port 3: 0000.0100 power
> >
> > NOTE: The devicetree changes depend on my previous series:
> > "[PATCH 0/2] minor GXL and GXM improvements" - see [0]
> >
> > NOTE2: This series depends on an upstream dwc3/xhci-plat DMA fix
> > (special thanks to Arnd Bergmann and Sriram Dash for fixing that):
> > "[PATCH v5 0/6] inherit dma configuration from parent dev" - see [1]
> >
> > I have a tree with all dependencies applied available at [2] if
> > someone wants a quick way to test this (I don't take any responsibility
> > if anything explodes though).
> >
> > [0] http://lists.infradead.org/pipermail/linux-amlogic/2016-November/001665.html
> > [1] http://marc.info/?l=linux-usb&m=147938307209685&w=2
> > [2] https://github.com/xdarklight/linux/commits/meson-gx-integration-4.10-20161126
> >
> > Martin Blumenstingl (5):
> > Documentation: dt-bindings: Add documentation for Meson GXL USB2/3
> > PHYs
> > phy: meson: add USB2 and USB3 PHY support for Meson GXL
> > arm64: dts: meson-gxl: add USB support
> > ARM64: dts: meson-gxm: add GXM specific USB configuration
> > ARM64: dts: meson-gx-p23x-q20x: enable USB on P23x and Q20x boards
> >
> > .../devicetree/bindings/phy/meson-gxl-usb2-phy.txt | 25 ++
> > .../devicetree/bindings/phy/meson-gxl-usb3-phy.txt | 27 ++
> > .../arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi | 12 +
> > arch/arm64/boot/dts/amlogic/meson-gxl.dtsi | 49 +++
> > .../arm64/boot/dts/amlogic/meson-gxm-s912-q200.dts | 17 +
> > arch/arm64/boot/dts/amlogic/meson-gxm.dtsi | 10 +
> > drivers/phy/Kconfig | 13 +
> > drivers/phy/Makefile | 2 +
> > drivers/phy/phy-meson-gxl-usb2.c | 374 ++++++++++++++++++++
> > drivers/phy/phy-meson-gxl-usb3.c | 377 +++++++++++++++++++++
> > 10 files changed, 906 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/phy/meson-gxl-usb2-phy.txt
> > create mode 100644 Documentation/devicetree/bindings/phy/meson-gxl-usb3-phy.txt
> > create mode 100644 drivers/phy/phy-meson-gxl-usb2.c
> > create mode 100644 drivers/phy/phy-meson-gxl-usb3.c
> >
> > --
> > 2.10.2
> >
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 4/6] net: ethernet: ti: cpts: add ptp pps support
From: Richard Cochran @ 2016-11-30 22:17 UTC (permalink / raw)
To: Grygorii Strashko
Cc: Murali Karicheri, Wingman Kwok, David S. Miller, netdev,
Mugunthan V N, Sekhar Nori, linux-kernel, linux-omap, Rob Herring,
devicetree
In-Reply-To: <875d4cc2-8a47-b06d-fb46-0cacc28dbaee@ti.com>
On Wed, Nov 30, 2016 at 02:43:57PM -0600, Grygorii Strashko wrote:
> > In order to produce the PPS edge correctly, you would have to adjust
> > the comparison value whenever cc.mult changes,
>
> yes. And that is done in cpts_ptp_adjfreq()
> if (cpts->ts_comp_enabled)
> cpts->ts_comp_one_sec_cycs = cpts_cc_ns2cyc(cpts, NSEC_PER_SEC);
> ^^^ re-calculate reload value for
>
> cpts_ts_comp_settime(cpts, ns);
> ^^^ adjust the ts_comp
And it races with the pulse itself. You forgot about this part:
> @@ -172,14 +232,31 @@ static int cpts_ptp_adjfreq(struct ptp_clock_info *ptp, s32 ppb)
> adj *= ppb;
> diff = div_u64(adj, 1000000000ULL);
>
> + mutex_lock(&cpts->ptp_clk_mutex);
> +
> spin_lock_irqsave(&cpts->lock, flags);
> + if (cpts->ts_comp_enabled) {
> + cpts_ts_comp_disable(cpts);
Sorry, but this is a train wreck.
> > but of course this is unworkable.
> >
>
> Sry, but this is questionable - code for pps comes from TI internal
> branches (SDK releases) where it survived for a pretty long time.
That doesn't mean the code is any good. If you adjust at the right
moment, then no pulse occurs at all!
> I'm, of course, agree that without HW support for freq adjustment
> this PPS feature is not super precise and has some limitation,
> but that is what we agree to live with.
I do NOT agree to live with this. I am one who is going to have to
explain to the world why their beagle bone PPS sucks.
Thanks,
Richard
^ permalink raw reply
* Re: [PATCH V6 08/10] PM / OPP: Allow platform specific custom set_opp() callbacks
From: Stephen Boyd @ 2016-11-30 22:04 UTC (permalink / raw)
To: Viresh Kumar
Cc: Rafael Wysocki, Viresh Kumar, Nishanth Menon, linaro-kernel,
linux-pm, Vincent Guittot, robh, d-gerlach, broonie, devicetree
In-Reply-To: <152e4a2c876449f3e47c206f5120cafdfd48b976.1480481312.git.viresh.kumar@linaro.org>
On 11/30, Viresh Kumar wrote:
> The generic set_opp() handler isn't sufficient for platforms with
> complex DVFS. For example, some TI platforms have multiple regulators
> for a CPU device. The order in which various supplies need to be
> programmed is only known to the platform code and its best to leave it
> to it.
>
> This patch implements APIs to register platform specific set_opp()
> callback.
>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> Tested-by: Dave Gerlach <d-gerlach@ti.com>
>
> ---
Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
So this one has the same set/put problem the other APIs has?
Presumably we're going to need to fix and change the API that is
introduced here. Wouldn't it be better to do that first though?
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH 01/10] doc: DT: camss: Binding document for Qualcomm Camera subsystem driver
From: Rob Herring @ 2016-11-30 22:03 UTC (permalink / raw)
To: Todor Tomov
Cc: mchehab, laurent.pinchart+renesas, hans.verkuil, javier,
s.nawrocki, linux-media, linux-kernel, mark.rutland, devicetree,
bjorn.andersson, srinivas.kandagatla
In-Reply-To: <1480085813-28235-1-git-send-email-todor.tomov@linaro.org>
On Fri, Nov 25, 2016 at 04:56:53PM +0200, Todor Tomov wrote:
> Add DT binding document for Qualcomm Camera subsystem driver.
>
> Signed-off-by: Todor Tomov <todor.tomov@linaro.org>
> ---
> .../devicetree/bindings/media/qcom,camss.txt | 196 +++++++++++++++++++++
> 1 file changed, 196 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/qcom,camss.txt
>
> diff --git a/Documentation/devicetree/bindings/media/qcom,camss.txt b/Documentation/devicetree/bindings/media/qcom,camss.txt
> new file mode 100644
> index 0000000..76ad89a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/qcom,camss.txt
> @@ -0,0 +1,196 @@
> +Qualcomm Camera Subsystem
> +
> +* Properties
> +
> +- compatible:
> + Usage: required
> + Value type: <stringlist>
> + Definition: Should contain:
> + - "qcom,8x16-camss"
Don't use wildcards in compatible strings. One string per SoC.
> +- reg:
> + Usage: required
> + Value type: <prop-encoded-array>
> + Definition: Register ranges as listed in the reg-names property.
> +- reg-names:
> + Usage: required
> + Value type: <stringlist>
> + Definition: Should contain the following entries:
> + - "csiphy0"
> + - "csiphy0_clk_mux"
> + - "csiphy1"
> + - "csiphy1_clk_mux"
> + - "csid0"
> + - "csid1"
> + - "ispif"
> + - "csi_clk_mux"
> + - "vfe0"
Kind of looks like the phy's should be separate nodes since each phy has
its own register range, irq, clocks, etc.
> +- interrupts:
> + Usage: required
> + Value type: <prop-encoded-array>
> + Definition: Interrupts as listed in the interrupt-names property.
> +- interrupt-names:
> + Usage: required
> + Value type: <stringlist>
> + Definition: Should contain the following entries:
> + - "csiphy0"
> + - "csiphy1"
> + - "csid0"
> + - "csid1"
> + - "ispif"
> + - "vfe0"
> +- power-domains:
> + Usage: required
> + Value type: <prop-encoded-array>
> + Definition: A phandle and power domain specifier pairs to the
> + power domain which is responsible for collapsing
> + and restoring power to the peripheral.
> +- clocks:
> + Usage: required
> + Value type: <prop-encoded-array>
> + Definition: A list of phandle and clock specifier pairs as listed
> + in clock-names property.
> +- clock-names:
> + Usage: required
> + Value type: <stringlist>
> + Definition: Should contain the following entries:
> + - "camss_top_ahb_clk"
> + - "ispif_ahb_clk"
> + - "csiphy0_timer_clk"
> + - "csiphy1_timer_clk"
> + - "csi0_ahb_clk"
> + - "csi0_clk"
> + - "csi0_phy_clk"
> + - "csi0_pix_clk"
> + - "csi0_rdi_clk"
> + - "csi1_ahb_clk"
> + - "csi1_clk"
> + - "csi1_phy_clk"
> + - "csi1_pix_clk"
> + - "csi1_rdi_clk"
> + - "camss_ahb_clk"
> + - "camss_vfe_vfe_clk"
> + - "camss_csi_vfe_clk"
> + - "iface_clk"
> + - "bus_clk"
> +- vdda-supply:
> + Usage: required
> + Value type: <phandle>
> + Definition: A phandle to voltage supply for CSI2.
> +- iommus:
> + Usage: required
> + Value type: <prop-encoded-array>
> + Definition: A list of phandle and IOMMU specifier pairs.
> +
> +* Nodes
> +
> +- ports:
> + Usage: required
> + Definition: As described in video-interfaces.txt in same directory.
> + Properties:
> + - reg:
> + Usage: required
> + Value type: <u32>
> + Definition: Selects CSI2 PHY interface - PHY0 or PHY1.
> + Endpoint node properties:
> + - clock-lanes:
> + Usage: required
> + Value type: <u32>
> + Definition: The clock lane.
> + - data-lanes:
> + Usage: required
> + Value type: <prop-encoded-array>
> + Definition: An array of data lanes.
> + - qcom,settle-cnt:
This should go in phy node ideally.
> + Usage: required
> + Value type: <u32>
> + Definition: The settle count parameter for CSI PHY.
> +
> +* An Example
> +
> + camss: camss@1b00000 {
> + compatible = "qcom,8x16-camss";
> + reg = <0x1b0ac00 0x200>,
> + <0x1b00030 0x4>,
> + <0x1b0b000 0x200>,
> + <0x1b00038 0x4>,
> + <0x1b08000 0x100>,
> + <0x1b08400 0x100>,
> + <0x1b0a000 0x500>,
> + <0x1b00020 0x10>,
> + <0x1b10000 0x1000>;
> + reg-names = "csiphy0",
> + "csiphy0_clk_mux",
> + "csiphy1",
> + "csiphy1_clk_mux",
> + "csid0",
> + "csid1",
> + "ispif",
> + "csi_clk_mux",
> + "vfe0";
> + interrupts = <GIC_SPI 78 0>,
> + <GIC_SPI 79 0>,
> + <GIC_SPI 51 0>,
> + <GIC_SPI 52 0>,
> + <GIC_SPI 55 0>,
> + <GIC_SPI 57 0>;
> + interrupt-names = "csiphy0",
> + "csiphy1",
> + "csid0",
> + "csid1",
> + "ispif",
> + "vfe0";
> + power-domains = <&gcc VFE_GDSC>;
> + clocks = <&gcc GCC_CAMSS_TOP_AHB_CLK>,
> + <&gcc GCC_CAMSS_ISPIF_AHB_CLK>,
> + <&gcc GCC_CAMSS_CSI0PHYTIMER_CLK>,
> + <&gcc GCC_CAMSS_CSI1PHYTIMER_CLK>,
> + <&gcc GCC_CAMSS_CSI0_AHB_CLK>,
> + <&gcc GCC_CAMSS_CSI0_CLK>,
> + <&gcc GCC_CAMSS_CSI0PHY_CLK>,
> + <&gcc GCC_CAMSS_CSI0PIX_CLK>,
> + <&gcc GCC_CAMSS_CSI0RDI_CLK>,
> + <&gcc GCC_CAMSS_CSI1_AHB_CLK>,
> + <&gcc GCC_CAMSS_CSI1_CLK>,
> + <&gcc GCC_CAMSS_CSI1PHY_CLK>,
> + <&gcc GCC_CAMSS_CSI1PIX_CLK>,
> + <&gcc GCC_CAMSS_CSI1RDI_CLK>,
> + <&gcc GCC_CAMSS_AHB_CLK>,
> + <&gcc GCC_CAMSS_VFE0_CLK>,
> + <&gcc GCC_CAMSS_CSI_VFE0_CLK>,
> + <&gcc GCC_CAMSS_VFE_AHB_CLK>,
> + <&gcc GCC_CAMSS_VFE_AXI_CLK>;
> + clock-names = "camss_top_ahb_clk",
> + "ispif_ahb_clk",
> + "csiphy0_timer_clk",
> + "csiphy1_timer_clk",
> + "csi0_ahb_clk",
> + "csi0_clk",
> + "csi0_phy_clk",
> + "csi0_pix_clk",
> + "csi0_rdi_clk",
> + "csi1_ahb_clk",
> + "csi1_clk",
> + "csi1_phy_clk",
> + "csi1_pix_clk",
> + "csi1_rdi_clk",
> + "camss_ahb_clk",
> + "camss_vfe_vfe_clk",
> + "camss_csi_vfe_clk",
> + "iface_clk",
> + "bus_clk";
> + vdda-supply = <&pm8916_l2>;
> + iommus = <&apps_iommu 3>;
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + port@0 {
> + reg = <0>;
> + csiphy0_ep: endpoint {
> + clock-lanes = <1>;
> + data-lanes = <0 2>;
> + qcom,settle-cnt = <0xe>;
> + remote-endpoint = <&ov5645_ep>;
> + };
> + };
> + };
> + };
> --
> 1.9.1
>
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: usb: add DT binding for s3c2410 USB OHCI controller
From: Rob Herring @ 2016-11-30 21:53 UTC (permalink / raw)
To: Sergio Prado
Cc: gregkh, mark.rutland, stern, kgene, krzk, javier, linux-usb,
devicetree, linux-kernel, linux-arm-kernel, linux-samsung-soc
In-Reply-To: <1480085249-25014-2-git-send-email-sergio.prado@e-labworks.com>
On Fri, Nov 25, 2016 at 12:47:28PM -0200, Sergio Prado wrote:
> Adds the device tree bindings description for Samsung S3C2410 and
> compatible USB OHCI controller.
>
> Signed-off-by: Sergio Prado <sergio.prado@e-labworks.com>
> ---
> .../devicetree/bindings/usb/s3c2410-usb.txt | 22 ++++++++++++++++++++++
> 1 file changed, 22 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/usb/s3c2410-usb.txt
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v3 4/4] [media] dt-bindings: add TI VPIF documentation
From: Sakari Ailus @ 2016-11-30 21:48 UTC (permalink / raw)
To: Rob Herring
Cc: Kevin Hilman, linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Hans Verkuil, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Sekhar Nori, Axel Haslam, Bartosz Gołaszewski,
Alexandre Bailon, David Lechner, g.liakhovetski-Mmb7MZpHnFY,
laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw
In-Reply-To: <CAL_JsqJ3wJnNa=bVN+UT4A-J5XC0jdyGAgWzROScRDLy6T8xHw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi Rob and Kevin,
On Tue, Nov 29, 2016 at 08:41:44AM -0600, Rob Herring wrote:
> On Mon, Nov 28, 2016 at 4:30 PM, Kevin Hilman <khilman-rdvid1DuHRBWk0Htik3J/w@public.gmane.org> wrote:
> > Hi Rob,
> >
> > Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> writes:
> >
> >> On Tue, Nov 22, 2016 at 07:52:44AM -0800, Kevin Hilman wrote:
> >>> Signed-off-by: Kevin Hilman <khilman-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> >>> ---
> >>> .../bindings/media/ti,da850-vpif-capture.txt | 65 ++++++++++++++++++++++
> >>> .../devicetree/bindings/media/ti,da850-vpif.txt | 8 +++
> >>> 2 files changed, 73 insertions(+)
> >>> create mode 100644 Documentation/devicetree/bindings/media/ti,da850-vpif-capture.txt
> >>> create mode 100644 Documentation/devicetree/bindings/media/ti,da850-vpif.txt
> >>>
> >>> diff --git a/Documentation/devicetree/bindings/media/ti,da850-vpif-capture.txt b/Documentation/devicetree/bindings/media/ti,da850-vpif-capture.txt
> >>> new file mode 100644
> >>> index 000000000000..c447ac482c1d
> >>> --- /dev/null
> >>> +++ b/Documentation/devicetree/bindings/media/ti,da850-vpif-capture.txt
> >>> @@ -0,0 +1,65 @@
> >>> +Texas Instruments VPIF Capture
> >>> +------------------------------
> >>> +
> >>> +The TI Video Port InterFace (VPIF) capture component is the primary
> >>> +component for video capture on the DA850 family of TI DaVinci SoCs.
> >>> +
> >>> +TI Document number reference: SPRUH82C
> >>> +
> >>> +Required properties:
> >>> +- compatible: must be "ti,da850-vpif-capture"
> >>> +- reg: physical base address and length of the registers set for the device;
> >>> +- interrupts: should contain IRQ line for the VPIF
> >>> +
> >>> +VPIF capture has a 16-bit parallel bus input, supporting 2 8-bit
> >>> +channels or a single 16-bit channel. It should contain at least one
> >>> +port child node with child 'endpoint' node. Please refer to the
> >>> +bindings defined in
> >>> +Documentation/devicetree/bindings/media/video-interfaces.txt.
> >>> +
> >>> +Example using 2 8-bit input channels, one of which is connected to an
> >>> +I2C-connected TVP5147 decoder:
> >>> +
> >>> + vpif_capture: video-capture@0x00217000 {
> >>> + reg = <0x00217000 0x1000>;
> >>> + interrupts = <92>;
> >>> +
> >>> + port {
> >>> + vpif_ch0: endpoint@0 {
> >>> + reg = <0>;
> >>> + bus-width = <8>;
> >>> + remote-endpoint = <&composite>;
> >>> + };
> >>> +
> >>> + vpif_ch1: endpoint@1 {
> >>
> >> I think probably channels here should be ports rather than endpoints.
> >> AIUI, having multiple endpoints is for cases like a mux or 1 to many
> >> connections. There's only one data flow, but multiple sources or sinks.
> >
> > Looking at this closer... , I used an endpoint because it's bascially a
> > 16-bit parallel bus, that can be configured as (up to) 2 8-bit
> > "channels. So, based on the video-interfaces.txt doc, I configured this
> > as a single port, with (up to) 2 endpoints. That also allows me to
> > connect output of the decoder directly, using the remote-endpoint
> > property.
> >
> > So I guess I'm not fully understanding your suggestion.
>
> NM, looks like video-interfaces.txt actually spells out this case and
> defines doing it as you did.
It's actually the first time I read that portion (at least so that I could
remember) of video-interfaces.txt. I'm not sure if anyone has implemented
that previously, nor how we ended up with the text. The list archive could
probably tell. Cc Guennadi who wrote it. :-) I couldn't immediately find DT
source with this arrangement.
In case of splitting the port into two parallel interfaces, how do you
determine which wires belong to which endpoint? I guess they'd be particular
sets of wires but as there's just a single port it isn't defined by the
port.
--
Regards,
Sakari Ailus
e-mail: sakari.ailus-X3B1VOXEql0@public.gmane.org XMPP: sailus-PCDdDYkjdNMDXYZnReoRVg@public.gmane.org
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 1/7] net: dt-bindings: add RGMII TX delay configuration to meson8b-dwmac
From: Rob Herring @ 2016-11-30 21:44 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, khilman-rdvid1DuHRBWk0Htik3J/w,
mark.rutland-5wv7dgnIgG8,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
alexandre.torgue-qxv4g6HH51o, peppe.cavallaro-qxv4g6HH51o,
will.deacon-5wv7dgnIgG8, catalin.marinas-5wv7dgnIgG8,
carlo-KA+7E9HrN00dnm+yROfE0A, f.fainelli-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <20161125130156.17879-2-martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
On Fri, Nov 25, 2016 at 02:01:50PM +0100, Martin Blumenstingl wrote:
> This allows configuring the RGMII TX clock delay. The RGMII clock is
> generated by underlying hardware of the the Meson 8b / GXBB DWMAC glue.
> The configuration depends on the actual hardware (no delay may be
> needed due to the design of the actual circuit, the PHY might add this
> delay, etc.).
>
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
> ---
> Documentation/devicetree/bindings/net/meson-dwmac.txt | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/meson-dwmac.txt b/Documentation/devicetree/bindings/net/meson-dwmac.txt
> index 89e62dd..f8bc540 100644
> --- a/Documentation/devicetree/bindings/net/meson-dwmac.txt
> +++ b/Documentation/devicetree/bindings/net/meson-dwmac.txt
> @@ -25,6 +25,20 @@ Required properties on Meson8b and newer:
> - "clkin0" - first parent clock of the internal mux
> - "clkin1" - second parent clock of the internal mux
>
> +Optional properties on Meson8b and newer:
> +- amlogic,tx-delay-ns: The internal RGMII TX clock delay (provided
> + by this driver) in nanoseconds. Allowed values
> + are: 0ns, 2ns, 4ns, 6ns.
> + This must be configured when the phy-mode is
> + "rgmii" (typically a value of 2ns is used in
> + this case).
> + When phy-mode is set to "rgmii-id" or
> + "rgmii-txid" the TX clock delay is already
> + provided by the PHY. In that case this
> + property should be set to 0ns (which disables
> + the TX clock delay in the MAC to prevent the
> + clock from going off because both PHY and MAC
> + are adding a delay).
What's the default? Why can't no property mean 0ns delay?
>
> Example for Meson6:
>
> --
> 2.10.2
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] dt-bindings: document how to setup rockchip timers as clocksource
From: Alexander Kochetkov @ 2016-11-30 21:40 UTC (permalink / raw)
To: Rob Herring
Cc: mark.rutland, wxt, daniel.lezcano, huangtao, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel
In-Reply-To: <20161130213006.p6totahjga7546s6@rob-hp-laptop>
> 1 дек. 2016 г., в 0:30, Rob Herring <robh@kernel.org> написал(а):
>
> 1st and 2nd are ambiguous. Plus this is an OS implementation detail that
> doesn't belong in the binding.
>
>> +If you want to bind specific timer as clockevent (i.e. one from alive subsystem)
>> +and specific timer as clocksource, you can number the timers in "aliases" node.
>
> No.
>
> Use and/or describe what are the features of a timer to make the
> decision. There has to be some reason you care which one. One has an
> interrupt and the other doesn't. One is always on. Etc.
Thank you, Rob.
Eventually I abandoned this decision.
I left only one patch, which you confirmed recently.
And sorry for making noise with duplicate patches.
Alexander.
^ permalink raw reply
* Re: [PATCH 2/2] dt-bindings: Add DT bindings info for FlexRM mailbox driver
From: Rob Herring @ 2016-11-30 21:38 UTC (permalink / raw)
To: Anup Patel
Cc: Jassi Brar, Mark Rutland, Ray Jui, Scott Branden, Pramod KUMAR,
Rob Rice, devicetree, linux-kernel, linux-arm-kernel,
bcm-kernel-feedback-list
In-Reply-To: <1480048551-3285-3-git-send-email-anup.patel@broadcom.com>
On Fri, Nov 25, 2016 at 10:05:51AM +0530, Anup Patel wrote:
> This patch adds device tree bindings document for the FlexRM
> mailbox driver.
Bindings document h/w, not drivers.
>
> Reviewed-by: Ray Jui <ray.jui@broadcom.com>
> Reviewed-by: Scott Branden <scott.branden@broadcom.com>
> Signed-off-by: Anup Patel <anup.patel@broadcom.com>
> ---
> .../bindings/mailbox/brcm,flexrm-mbox.txt | 60 ++++++++++++++++++++++
> 1 file changed, 60 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mailbox/brcm,flexrm-mbox.txt
>
> diff --git a/Documentation/devicetree/bindings/mailbox/brcm,flexrm-mbox.txt b/Documentation/devicetree/bindings/mailbox/brcm,flexrm-mbox.txt
> new file mode 100644
> index 0000000..7969b1c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mailbox/brcm,flexrm-mbox.txt
> @@ -0,0 +1,60 @@
> +Broadcom FlexRM Mailbox Driver
h/w
> +===============================
> +The Broadcom FlexRM ring manager provides a set of rings which can be
> +used to submit work to offload engines. An SoC may have multiple FlexRM
> +hardware blocks. There is one device tree entry per block. The FlexRM
> +mailbox drivers creates a mailbox instance using FlexRM rings where
> +each mailbox channel is a separate FlexRM ring.
> +
> +Required properties:
> +--------------------
> +- compatible: Should be "brcm,flexrm-mbox"
Sounds generic. Add SoC specific compatible strings please.
> +- reg: Specifies base physical address and size of the FlexRM
> + ring registers
> +- msi-parent: Phandles (and potential Device IDs) to MSI controllers
> + The FlexRM engine will send MSIs (instead of wired
> + interrupts) to CPU. There is one MSI for each FlexRM ring.
One ring is one h/w block, right? How many instances is not really
relevant.
> + Refer devicetree/bindings/interrupt-controller/msi.txt
> +- #mbox-cells: Specifies the number of cells needed to encode a mailbox
> + channel. This should be 3.
> +
> + The 1st cell is the mailbox channel number.
> +
> + The 2nd cell contains MSI completion threshold. This is the
> + number of completion messages for which FlexRM will inject
> + one MSI interrupt to CPU.
> +
> + The 3nd cell contains MSI timer value representing time for
> + which FlexRM will wait to accumulate N completion messages
> + where N is the value specified by 2nd cell above. If FlexRM
> + does not get required number of completion messages in time
> + specified by this cell then it will inject one MSI interrupt
> + to CPU provided atleast one completion message is available.
> +
> +Optional properties:
> +--------------------
> +- dma-coherent: Present if DMA operations made by the FlexRM engine (such
> + as DMA descriptor access, access to buffers pointed by DMA
> + descriptors and read/write pointer updates to DDR) are
> + cache coherent with the CPU.
> +
> +Example:
> +--------
> +crypto_mbox: mbox@67000000 {
> + compatible = "brcm,flexrm-mbox";
> + reg = <0x67000000 0x200000>;
> + msi-parent = <&gic_its 0x7f00>;
> + #mbox-cells = <3>;
> +};
> +
> +crypto_client {
Is this a h/w block or purely a driver on top of the mailbox? The latter
doesn't belong in DT.
> + ...
> + mboxes = <&crypto_mbox 0 0x1 0xffff>,
> + <&crypto_mbox 1 0x1 0xffff>,
> + <&crypto_mbox 16 0x1 0xffff>,
> + <&crypto_mbox 17 0x1 0xffff>,
> + <&crypto_mbox 30 0x1 0xffff>,
> + <&crypto_mbox 31 0x1 0xffff>;
> + };
> + ...
> +};
> --
> 2.7.4
>
^ permalink raw reply
* Re: [PATCH] dt-bindings: document how to setup rockchip timers as clocksource
From: Rob Herring @ 2016-11-30 21:30 UTC (permalink / raw)
To: Alexander Kochetkov
Cc: mark.rutland-5wv7dgnIgG8, wxt-TNX95d0MmH7DzftRWevZcw,
daniel.lezcano-QSEj5FYQhm4dnm+yROfE0A,
huangtao-TNX95d0MmH7DzftRWevZcw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1480025536-6837-1-git-send-email-al.kochet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Fri, Nov 25, 2016 at 01:12:16AM +0300, Alexander Kochetkov wrote:
> The patch describes how to setup rockchip timers in device tree
> so they can be used as clocksource.
>
> I'm going to implement this feature.
>
> Signed-off-by: Alexander Kochetkov <al.kochet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> .../bindings/timer/rockchip,rk-timer.txt | 35 +++++++++++++++++++-
> 1 file changed, 34 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/timer/rockchip,rk-timer.txt b/Documentation/devicetree/bindings/timer/rockchip,rk-timer.txt
> index 7bc9691..15f8fed 100644
> --- a/Documentation/devicetree/bindings/timer/rockchip,rk-timer.txt
> +++ b/Documentation/devicetree/bindings/timer/rockchip,rk-timer.txt
> @@ -16,7 +16,18 @@ Required properties:
> - clock-names : must include the following entries:
> "timer", "pclk"
>
> -Example:
> +Note:
> +If device tree contain only one timer, than the timer will be intialized
> +as clockevent provider. If device tree contain two timers, than first timer
> +will be initialized as clockevent provider and second one as clocksource.
1st and 2nd are ambiguous. Plus this is an OS implementation detail that
doesn't belong in the binding.
> +If you want to bind specific timer as clockevent (i.e. one from alive subsystem)
> +and specific timer as clocksource, you can number the timers in "aliases" node.
No.
Use and/or describe what are the features of a timer to make the
decision. There has to be some reason you care which one. One has an
interrupt and the other doesn't. One is always on. Etc.
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] dt-bindings: clarify compatible field usage for rockchip timers
From: Rob Herring @ 2016-11-30 21:25 UTC (permalink / raw)
To: Alexander Kochetkov
Cc: mark.rutland-5wv7dgnIgG8, wxt-TNX95d0MmH7DzftRWevZcw,
daniel.lezcano-QSEj5FYQhm4dnm+yROfE0A,
huangtao-TNX95d0MmH7DzftRWevZcw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1480025455-6797-1-git-send-email-al.kochet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Fri, Nov 25, 2016 at 01:10:55AM +0300, Alexander Kochetkov wrote:
> rk3036 dtsi file already use compatible field as
> "rockchip,rk3036-timer", "rockchip,rk3288-timer".
>
> The patch clearly shows how that filed should be used on other chips.
>
> Signed-off-by: Alexander Kochetkov <al.kochet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> .../bindings/timer/rockchip,rk-timer.txt | 12 +++++++++---
> 1 file changed, 9 insertions(+), 3 deletions(-)
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 3/7] PWM: add pwm-stm32 DT bindings
From: Rob Herring @ 2016-11-30 21:20 UTC (permalink / raw)
To: Benjamin Gaignard
Cc: mark.rutland, devicetree, lars, alexandre.torgue, linux-pwm,
linux-iio, linus.walleij, arnaud.pouliquen, linux-kernel,
thierry.reding, linux-arm-kernel, pmeerw, knaack.h, gerald.baeza,
fabrice.gasnier, lee.jones, linaro-kernel, jic23,
Benjamin Gaignard
In-Reply-To: <1480000463-9625-4-git-send-email-benjamin.gaignard@st.com>
On Thu, Nov 24, 2016 at 04:14:19PM +0100, Benjamin Gaignard wrote:
> Define bindings for pwm-stm32
>
> version 2:
> - use parameters instead of compatible of handle the hardware configuration
>
> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
> ---
> .../devicetree/bindings/pwm/pwm-stm32.txt | 37 ++++++++++++++++++++++
> 1 file changed, 37 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/pwm/pwm-stm32.txt
>
> diff --git a/Documentation/devicetree/bindings/pwm/pwm-stm32.txt b/Documentation/devicetree/bindings/pwm/pwm-stm32.txt
> new file mode 100644
> index 0000000..36263f0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pwm/pwm-stm32.txt
> @@ -0,0 +1,37 @@
> +STMicroelectronics PWM driver bindings for STM32
> +
> +Must be a sub-node of STM32 general purpose timer driver
> +
> +Required parameters:
> +- compatible: Must be "st,stm32-pwm"
> +- pinctrl-names: Set to "default".
> +- pinctrl-0: List of phandles pointing to pin configuration nodes
> + for PWM module.
> + For Pinctrl properties, please refer to [1].
> +
> +Optional parameters:
> +- st,breakinput: Set if the hardware have break input capabilities
> +- st,breakinput-polarity: Set break input polarity. Default is 0
> + The value define the active polarity:
> + - 0 (active LOW)
> + - 1 (active HIGH)
> +- st,pwm-num-chan: Number of available PWM channels. Default is 0.
> +- st,32bits-counter: Set if the hardware have a 32 bits counter
> +- st,complementary: Set if the hardware have complementary output channels
What does complementary mean here?
> +
> +[1] Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
> +
> +Example:
> + gptimer1: gptimer1@40010000 {
timer@...
> + compatible = "st,stm32-gptimer";
> + reg = <0x40010000 0x400>;
> + clocks = <&rcc 0 160>;
> + clock-names = "clk_int";
> +
> + pwm1@0 {
pwm {
Is there more than one?
> + compatible = "st,stm32-pwm";
> + st,pwm-num-chan = <4>;
> + st,breakinput;
> + st,complementary;
> + };
> + };
> --
> 1.9.1
>
^ permalink raw reply
* Re: [PATCH] rtc: add support for EPSON TOYOCOM RTC-7301SF/DG
From: Alexandre Belloni @ 2016-11-30 21:01 UTC (permalink / raw)
To: Akinobu Mita
Cc: rtc-linux-/JYPxA39Uh5TLH3MbocFFw,
devicetree-u79uwXL29TY76Z2rM5mHXA, Alessandro Zummo
In-Reply-To: <1472396118-13424-1-git-send-email-akinobu.mita-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Hi,
Sorry for the very late review!
It seems mostly fine for me, two small comments:
On 28/08/2016 at 23:55:18 +0900, Akinobu Mita wrote :
> diff --git a/drivers/rtc/rtc-r7301.c b/drivers/rtc/rtc-r7301.c
> new file mode 100644
> index 0000000..b1be281
> --- /dev/null
> +++ b/drivers/rtc/rtc-r7301.c
> @@ -0,0 +1,458 @@
> +/*
> + * EPSON TOYOCOM RTC-7301SF/DG Driver
> + *
> + * Copyright (c) 2016 Akinobu Mita <akinobu.mita-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> + *
> + * Based on rtc-rp5c01.c
> + *
> + * Datasheet: http://www5.epsondevice.com/en/products/parallel/rtc7301sf.html
> + */
> +
> +#include <linux/io.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/delay.h>
> +#include <linux/regmap.h>
> +#include <linux/platform_device.h>
> +#include <linux/rtc.h>
> +
> +#define DRV_NAME "rtc-r7301"
> +
> +enum {
> + RTC7301_1_SEC = 0x0, /* Bank 0 and Band 1 */
> + RTC7301_10_SEC = 0x1, /* Bank 0 and Band 1 */
> + RTC7301_AE = BIT(3),
> + RTC7301_1_MIN = 0x2, /* Bank 0 and Band 1 */
> + RTC7301_10_MIN = 0x3, /* Bank 0 and Band 1 */
> + RTC7301_1_HOUR = 0x4, /* Bank 0 and Band 1 */
> + RTC7301_10_HOUR = 0x5, /* Bank 0 and Band 1 */
> + RTC7301_DAY_OF_WEEK = 0x6, /* Bank 0 and Band 1 */
> + RTC7301_1_DAY = 0x7, /* Bank 0 and Band 1 */
> + RTC7301_10_DAY = 0x8, /* Bank 0 and Band 1 */
> + RTC7301_1_MONTH = 0x9, /* Bank 0 */
> + RTC7301_10_MONTH = 0xa, /* Bank 0 */
> + RTC7301_1_YEAR = 0xb, /* Bank 0 */
> + RTC7301_10_YEAR = 0xc, /* Bank 0 */
> + RTC7301_100_YEAR = 0xd, /* Bank 0 */
> + RTC7301_1000_YEAR = 0xe, /* Bank 0 */
> + RTC7301_ALARM_CONTROL = 0xe, /* Bank 1 */
> + RTC7301_ALARM_CONTROL_AIE = BIT(0),
> + RTC7301_ALARM_CONTROL_AF = BIT(1),
> + RTC7301_TIMER_CONTROL = 0xe, /* Bank 2 */
> + RTC7301_ALARM_CONTROL_TIE = BIT(0),
> + RTC7301_ALARM_CONTROL_TF = BIT(1),
> + RTC7301_CONTROL = 0xf, /* All banks */
> + RTC7301_CONTROL_BUSY = BIT(0),
> + RTC7301_CONTROL_STOP = BIT(1),
> + RTC7301_CONTROL_BANK_SEL_0 = BIT(2),
> + RTC7301_CONTROL_BANK_SEL_1 = BIT(3),
> +};
> +
Any particular reason why you use an enum instead of the usual #define?
[...]
> +static void rtc7301_init(struct rtc7301_priv *priv)
> +{
> + unsigned long flags;
> +
> + spin_lock_irqsave(&priv->lock, flags);
> +
> + rtc7301_select_bank(priv, 1);
> + rtc7301_alarm_irq(priv, false);
> +
If the RTC is battery backed, it may still run with the core power off
and maybe someone will actually expect the alarm to trigger at a later
time.
I don't mind much as you are probably the only user anyway.
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
---
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [PATCH v2 4/9] clk: stm32f4: Add lcd-tft clock
From: Rob Herring @ 2016-11-30 20:53 UTC (permalink / raw)
To: gabriel.fernandez
Cc: Mark Rutland, devicetree, daniel.thompson, radoslaw.pietrzyk,
Alexandre Torgue, Arnd Bergmann, Nicolas Pitre, andrea.merello,
Michael Turquette, olivier.bideau, Stephen Boyd, Russell King,
linux-kernel, ludovic.barre, Maxime Coquelin, amelie.delaunay,
linux-clk, linux-arm-kernel, kernel
In-Reply-To: <1479998749-20358-5-git-send-email-gabriel.fernandez@st.com>
On Thu, Nov 24, 2016 at 03:45:44PM +0100, gabriel.fernandez@st.com wrote:
> From: Gabriel Fernandez <gabriel.fernandez@st.com>
>
> This patch introduces lcd-tft clock for stm32f4 soc.
>
> Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
> ---
> .../devicetree/bindings/clock/st,stm32-rcc.txt | 1 +
> drivers/clk/clk-stm32f4.c | 118 +++++++++++++++++++++
> include/dt-bindings/clock/stm32f4-clock.h | 3 +-
> 3 files changed, 121 insertions(+), 1 deletion(-)
> diff --git a/include/dt-bindings/clock/stm32f4-clock.h b/include/dt-bindings/clock/stm32f4-clock.h
> index 56b8e10..1be4a3a 100644
> --- a/include/dt-bindings/clock/stm32f4-clock.h
> +++ b/include/dt-bindings/clock/stm32f4-clock.h
> @@ -27,7 +27,8 @@
> #define CLK_RTC 5
> #define PLL_VCO_I2S 6
> #define PLL_VCO_SAI 7
> +#define CLK_LCD 8
>
> -#define END_PRIMARY_CLK 8
> +#define END_PRIMARY_CLK 9
Do you really need this? Having this change could cause compatibility
problems between dtb and kernel versions.
Please restructure the patch series and put all of the binding changes
including this header into a single patch. Incrementally add s/w
features, not h/w.
Rob
^ permalink raw reply
* Re: Re: [RFC PATCH] ARM: dts: sun8i: add simplefb node for H3
From: Maxime Ripard @ 2016-11-30 20:52 UTC (permalink / raw)
To: Jernej Škrabec
Cc: Jean-Francois Moine, Icenowy Zheng,
devicetree-u79uwXL29TY76Z2rM5mHXA, wens-jdAy2FN1RRM, linux-kernel,
linux-sunxi, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <185067972.ij8nq5Ea6J@jernej-laptop>
[-- Attachment #1: Type: text/plain, Size: 1658 bytes --]
On Wed, Nov 30, 2016 at 09:41:26PM +0100, Jernej Škrabec wrote:
> > > > > The only
> > > > > code left from you is for DE2. HDMI stuff is basically copied from
> > > > > Rockhip
> > > > > driver (including EDID reading), TCON code is now reverted to the same
> > > > > as
> > > > > it is in sunxi_display.c. I think it is worth to take a look at EDID
> > > > > code
> > > > > and compare it.
> > > >
> > > > So is the TCON of DE 2.0 identical to the original TCON?
> > > >
> > > > If so, we should reuse sun4i-tcon ...
> > >
> > > Well, TCON is splitted in two parts (two base addresses), one for HDMI and
> > > one for TV. However, register offsets are same as before, so I guess
> > > driver reusage make sense. I think that there are few additional
> > > registers, but they can be ignored for simplefb.
> >
> > The TCON1 of the H3 is not usable (no ckock). Analog TV has its own
> > clock and I/O area.
> >
>
> True, H3 user manual can be misleading sometimes. But this doesn't change the
> fact that TCON0 has same register offsets with same meaning.
Then yes, we should definitely share the drivers too. So, in the end,
the only thing that is actually new is the display-engine?
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH v2 2/9] clk: stm32f4: Add PLL_I2S & PLL_SAI for STM32F429/469 boards
From: Rob Herring @ 2016-11-30 20:48 UTC (permalink / raw)
To: gabriel.fernandez
Cc: Mark Rutland, devicetree, daniel.thompson, radoslaw.pietrzyk,
Alexandre Torgue, Arnd Bergmann, Nicolas Pitre, andrea.merello,
Michael Turquette, olivier.bideau, Stephen Boyd, Russell King,
linux-kernel, ludovic.barre, Maxime Coquelin, amelie.delaunay,
linux-clk, linux-arm-kernel, kernel
In-Reply-To: <1479998749-20358-3-git-send-email-gabriel.fernandez@st.com>
On Thu, Nov 24, 2016 at 03:45:42PM +0100, gabriel.fernandez@st.com wrote:
> From: Gabriel Fernandez <gabriel.fernandez@st.com>
>
> This patch introduces PLL_I2S and PLL_SAI.
> Vco clock of these PLLs can be modify by DT (only n multiplicator,
> m divider is still fixed by the boot-loader).
> Each PLL has 3 dividers. PLL should be off when we modify the rate.
>
> Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
> ---
> .../devicetree/bindings/clock/st,stm32-rcc.txt | 2 +
> drivers/clk/clk-stm32f4.c | 342 ++++++++++++++++++++-
> include/dt-bindings/clock/stm32f4-clock.h | 4 +-
> 3 files changed, 332 insertions(+), 16 deletions(-)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 1/9] clk: stm32f4: Update DT bindings documentation
From: Rob Herring @ 2016-11-30 20:47 UTC (permalink / raw)
To: gabriel.fernandez
Cc: Mark Rutland, Russell King, Maxime Coquelin, Alexandre Torgue,
Michael Turquette, Stephen Boyd, Nicolas Pitre, Arnd Bergmann,
daniel.thompson, andrea.merello, radoslaw.pietrzyk, devicetree,
linux-arm-kernel, linux-kernel, linux-clk, kernel, ludovic.barre,
olivier.bideau, amelie.delaunay
In-Reply-To: <1479998749-20358-2-git-send-email-gabriel.fernandez@st.com>
On Thu, Nov 24, 2016 at 03:45:41PM +0100, gabriel.fernandez@st.com wrote:
> From: Gabriel Fernandez <gabriel.fernandez@st.com>
>
> Creation of dt include file for specific stm32f4 clocks.
> These specific clocks are not derived from system clock (SYSCLOCK)
> We should use index 1 to use these clocks in DT.
> e.g. <&rcc 1 CLK_LSI>
>
> Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
> ---
> .../devicetree/bindings/clock/st,stm32-rcc.txt | 8 ++++++
> drivers/clk/clk-stm32f4.c | 9 +++++--
> include/dt-bindings/clock/stm32f4-clock.h | 31 ++++++++++++++++++++++
> 3 files changed, 46 insertions(+), 2 deletions(-)
> create mode 100644 include/dt-bindings/clock/stm32f4-clock.h
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v3 2/2] dt-bindings: power: add bindings for sbs-charger
From: Rob Herring @ 2016-11-30 20:45 UTC (permalink / raw)
To: Nicolas Saenz Julienne
Cc: sre, mark.rutland, linux-kernel, devicetree, linux-pm
In-Reply-To: <1479990823-25841-3-git-send-email-nicolas.saenz@prodys.net>
On Thu, Nov 24, 2016 at 01:33:43PM +0100, Nicolas Saenz Julienne wrote:
> Adds device tree documentation for SBS charger compilant devices as defined
> here: http://sbs-forum.org/specs/sbc110.pdf
>
> Signed-off-by: Nicolas Saenz Julienne <nicolas.saenz@prodys.net>
> ---
> v2 -> v3:
> - add part number as compatible
>
> .../bindings/power/supply/sbs_sbs-charger.txt | 24 ++++++++++++++++++++++
> 1 file changed, 24 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/power/supply/sbs_sbs-charger.txt
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v28 9/9] Documentation: dt: chosen properties for arm64 kdump
From: Rob Herring @ 2016-11-30 20:44 UTC (permalink / raw)
To: Catalin Marinas
Cc: mark.rutland-5wv7dgnIgG8, devicetree-u79uwXL29TY76Z2rM5mHXA,
geoff-wEGCiKHe2LqWVfeAwA7xHQ,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, will.deacon-5wv7dgnIgG8,
AKASHI Takahiro, james.morse-5wv7dgnIgG8,
bauerman-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8,
dyoung-H+wXaHxf7aLQT0dZR+AlfA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20161124171413.GE7452-M2fw3Uu6cmfZROr8t4l/smS4ubULX0JqMm0uRHvK7Nw@public.gmane.org>
On Thu, Nov 24, 2016 at 05:14:13PM +0000, Catalin Marinas wrote:
> On Thu, Nov 24, 2016 at 06:59:44PM +0900, AKASHI Takahiro wrote:
> > From: James Morse <james.morse-5wv7dgnIgG8@public.gmane.org>
> >
> > Add documentation for
> > linux,crashkernel-base and crashkernel-size,
> > linux,usable-memory-range
> > linux,elfcorehdr
> > used by arm64 kdump to decribe the kdump reserved area, and
> > the elfcorehdr's location within it.
> >
> > Signed-off-by: James Morse <james.morse-5wv7dgnIgG8@public.gmane.org>
> > [takahiro.akashi-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org: added "linux,crashkernel-base" and "-size" ]
> > Signed-off-by: AKASHI Takahiro <takahiro.akashi-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> > Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> > Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> > Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
>
> Rob, Mark, are you ok with this patch?
I'm leaving this one to Mark.
Rob
^ permalink raw reply
* Re: [PATCH 4/6] net: ethernet: ti: cpts: add ptp pps support
From: Grygorii Strashko @ 2016-11-30 20:43 UTC (permalink / raw)
To: Richard Cochran, Murali Karicheri, Wingman Kwok
Cc: David S. Miller, netdev, Mugunthan V N, Sekhar Nori, linux-kernel,
linux-omap, Rob Herring, devicetree
In-Reply-To: <20161130184511.GB8209@netboy>
On 11/30/2016 12:45 PM, Richard Cochran wrote:
> On Mon, Nov 28, 2016 at 05:04:26PM -0600, Grygorii Strashko wrote:
>> +static cycle_t cpts_cc_ns2cyc(struct cpts *cpts, u64 nsecs)
>> +{
>> + cycle_t cyc = (nsecs << cpts->cc.shift) + nsecs;
>> +
>> + do_div(cyc, cpts->cc.mult);
>> +
>> + return cyc;
>> +}
>
> So you set the comparison value once per second, based on cc.mult.
> But when the clock is being actively synchronized, user space calls to
> clock_adjtimex() will change cc.mult. This can happen several times
> per second, depending on the PTP Sync rate.
>
Right.
> In order to produce the PPS edge correctly, you would have to adjust
> the comparison value whenever cc.mult changes,
yes. And that is done in cpts_ptp_adjfreq()
if (cpts->ts_comp_enabled)
cpts->ts_comp_one_sec_cycs = cpts_cc_ns2cyc(cpts, NSEC_PER_SEC);
^^^ re-calculate reload value for
cpts_ts_comp_settime(cpts, ns);
^^^ adjust the ts_comp
> but of course this is unworkable.
>
Sry, but this is questionable - code for pps comes from TI internal
branches (SDK releases) where it survived for a pretty long time.
I'm, of course, agree that without HW support for freq adjustment
this PPS feature is not super precise and has some limitation,
but that is what we agree to live with.
Murali, do you have any comments regarding usability of SW
freq freq adjustment approach?
> So I'll have to say NAK for this patch.
>
:)
--
regards,
-grygorii
^ permalink raw reply
* Re: Re: [RFC PATCH] ARM: dts: sun8i: add simplefb node for H3
From: Jernej Škrabec @ 2016-11-30 20:41 UTC (permalink / raw)
To: Jean-Francois Moine
Cc: Icenowy Zheng, devicetree-u79uwXL29TY76Z2rM5mHXA,
wens-jdAy2FN1RRM, linux-kernel, linux-sunxi,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20161130203724.a390595df0199ed19069f91d-GANU6spQydw@public.gmane.org>
Dne sreda, 30. november 2016 ob 20:37:24 CET je Jean-Francois Moine
napisal(a):
> On Wed, 30 Nov 2016 20:14:11 +0100
>
> Jernej Škrabec <jernej.skrabec-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > Dne četrtek, 01. december 2016 ob 03:03:14 CET je Icenowy Zheng
napisal(a):
> > > 2016年12月1日 02:49于 Jernej Skrabec <jernej.skrabec-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>写道：
> > >
> > > > Hi Jean-François,
> > > >
> > > > Dne sreda, 30. november 2016 10.35.08 UTC+1 je oseba Jean-François
> > > > Moine
> >
> > napisala:
> > > >> On Tue, 29 Nov 2016 22:59:32 +0100
> > > >>
> > > >> Maxime Ripard <maxime...-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> > > >> > > > I'm still not sure which pipeline should I use.
> > > >> > > >
> > > >> > > > And, it seems that HDMI Slow Clock is not needed?
> > > >> > > >
> > > >> > > > (seems that it's only for EDID, but simplefb won't use EDID)
> > > >> > >
> > > >> > > So, I don't see how this may work.
> > > >> > > How can the u-boot know the resolutions of the HDMI display
> > > >> > > device?
> > > >> > >
> > > >> > > In other words: I have a new H3 board with the last u-boot and
> > > >> > > kernel.
> > > >> > > I plug my (rather old or brand new) HDMI display device.
> > > >> > > After powering on the system, I hope to get something on the
> > > >> > > screen.
> > > >> > > How?
> > > >> >
> > > >> > If it works like the driver for the first display engine in U-Boot,
> > > >> > it
> > > >> > will use the preferred mode reported by the EDID, and will fallback
> > > >> > to
> > > >> > 1024x768 if it cannot access it.
> > > >>
> > > >> Icenowy wrote: "simplefb won't use EDID"
> > > >>
> > > >> Then, if it is like in the kernel, the 1024x768 mode is VGA. It does
> > > >> not work with HDMI (different timings).
> > > >
> > > > U-Boot driver now accept any timings recommended by EDID. So far it
> > > > was tested with at least following resolutions:
> > > > - 1920x1080 @ 60 Hz
> > > > - 1280x1024 @ 60 Hz
> > > > - 1280x800 @ 60 Hz (slight clock difference)
> > > > - 800x480 (not sure about frame rate)
> > > > - 3840x2160 @ 30 Hz (4K)
> > >
> > > I tested on 1024x600 (If my memory is right, it's @ 60Hz)
> > >
> > > > and nobody complained so far. I'm pretty sure 1024x768 would work.
>
> Check the timings offered by the DRM core.
I'm not really familiar with DRM code, but my Linux laptop happily works with
1024x768 @ 75 Hz and other non CEA resolutions through HDMI, so I guess it
should be possible here too. Isn't function drm_add_edid_modes() designed
exactly for that?
Anyway, this is off topic for simplefb. Simplefb driver will just take over
framebuffer set up by U-Boot with some additional info like width, height,
pitch... It doesn't have to deal with HW directly.
>
> > > >> > Maybe it would be worth exchanging on the EDID code that has been
> > > >> > done
> > > >> > for the u-boot driver too, so that it can be fixed in your driver.
> > > >>
> > > >> The u-boot got my code, and, up to now, I could not fix the random or
> > > >> permanent failures of EDID reading in some boards.
> > > >
> > > > I only have one OPi2, but as I said, EDID always worked for me.
>
> Happy guy!
>
> > > > The only
> > > > code left from you is for DE2. HDMI stuff is basically copied from
> > > > Rockhip
> > > > driver (including EDID reading), TCON code is now reverted to the same
> > > > as
> > > > it is in sunxi_display.c. I think it is worth to take a look at EDID
> > > > code
> > > > and compare it.
> > >
> > > So is the TCON of DE 2.0 identical to the original TCON?
> > >
> > > If so, we should reuse sun4i-tcon ...
> >
> > Well, TCON is splitted in two parts (two base addresses), one for HDMI and
> > one for TV. However, register offsets are same as before, so I guess
> > driver reusage make sense. I think that there are few additional
> > registers, but they can be ignored for simplefb.
>
> The TCON1 of the H3 is not usable (no ckock). Analog TV has its own
> clock and I/O area.
>
True, H3 user manual can be misleading sometimes. But this doesn't change the
fact that TCON0 has same register offsets with same meaning.
> --
> Ken ar c'hentañ | ** Breizh ha Linux atav! **
> Jef | http://moinejf.free.fr/
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [PATCH 1/4] bindings: net: stmmac: correct note about TSO
From: Rob Herring @ 2016-11-30 20:41 UTC (permalink / raw)
To: Niklas Cassel
Cc: Mark Rutland, David S. Miller, Giuseppe CAVALLARO,
Alexandre TORGUE, Phil Reid, Niklas Cassel, Eric Engestrom,
netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1479911066-19752-1-git-send-email-niklass-VrBV9hrLPhE@public.gmane.org>
On Wed, Nov 23, 2016 at 03:24:25PM +0100, Niklas Cassel wrote:
> From: Niklas Cassel <niklas.cassel-VrBV9hrLPhE@public.gmane.org>
>
> snps,tso was previously placed under AXI BUS Mode parameters,
> suggesting that the property should be in the stmmac-axi-config node.
>
> TSO (TCP Segmentation Offloading) has nothing to do with AXI BUS Mode
> parameters, and the parser actually expects it to be in the root node,
> not in the stmmac-axi-config.
>
> Also added a note about snps,tso only being available on GMAC4 and newer.
>
> Signed-off-by: Niklas Cassel <niklas.cassel-VrBV9hrLPhE@public.gmane.org>
> ---
> Documentation/devicetree/bindings/net/stmmac.txt | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] can: rcar_canfd: Correct order of interrupt specifiers
From: Rob Herring @ 2016-11-30 20:38 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Wolfgang Grandegger, Marc Kleine-Budde, Ramesh Shanmugasundaram,
Chris Paterson, linux-can, netdev, devicetree, linux-renesas-soc
In-Reply-To: <1479908686-14028-1-git-send-email-geert+renesas@glider.be>
On Wed, Nov 23, 2016 at 02:44:46PM +0100, Geert Uytterhoeven wrote:
> According to both DTS (example and actual files), and Linux driver code,
> the first interrupt specifier should be the Channel interrupt, while the
> second interrupt specifier should be the Global interrupt.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> Documentation/devicetree/bindings/net/can/rcar_canfd.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 3/3] arm64: dts: r8a7796: Add CAN FD support
From: Rob Herring @ 2016-11-30 20:37 UTC (permalink / raw)
To: Chris Paterson
Cc: Simon Horman, Wolfgang Grandegger, Marc Kleine-Budde, Magnus Damm,
Mark Rutland, Ramesh Shanmugasundaram,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-can-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1479903288-2009-1-git-send-email-chris.paterson2-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
On Wed, Nov 23, 2016 at 12:14:48PM +0000, Chris Paterson wrote:
> Adds CAN FD controller node for r8a7796.
>
> Based on a patch for r8a7795 by Ramesh Shanmugasundaram.
>
> Signed-off-by: Chris Paterson <chris.paterson2-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
> ---
> .../devicetree/bindings/net/can/rcar_canfd.txt | 12 ++++++-----
> arch/arm64/boot/dts/renesas/r8a7796.dtsi | 24 ++++++++++++++++++++++
> 2 files changed, 31 insertions(+), 5 deletions(-)
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/3] arm64: dts: r8a7796: Add CAN support
From: Rob Herring @ 2016-11-30 20:36 UTC (permalink / raw)
To: Chris Paterson
Cc: Simon Horman, Wolfgang Grandegger, Marc Kleine-Budde, Magnus Damm,
Mark Rutland, Ramesh Shanmugasundaram, linux-renesas-soc,
devicetree, linux-arm-kernel, linux-can
In-Reply-To: <1479903279-1950-1-git-send-email-chris.paterson2@renesas.com>
On Wed, Nov 23, 2016 at 12:14:39PM +0000, Chris Paterson wrote:
> Adds CAN controller nodes for r8a7796.
>
> Based on a patch for r8a7795 by Ramesh Shanmugasundaram.
>
> Signed-off-by: Chris Paterson <chris.paterson2@renesas.com>
> ---
> .../devicetree/bindings/net/can/rcar_can.txt | 12 +++++----
> arch/arm64/boot/dts/renesas/r8a7796.dtsi | 30 ++++++++++++++++++++++
> 2 files changed, 37 insertions(+), 5 deletions(-)
Acked-by: Rob Herring <robh@kernel.org>
^ 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