* Re: [PATCH v6 6/9] dt-bindings: counter: Document stm32 quadrature encoder
From: Rob Herring @ 2018-05-18 16:28 UTC (permalink / raw)
To: Benjamin Gaignard
Cc: William Breathitt Gray, Mark Rutland, devicetree,
Benjamin Gaignard, linux-iio, linux-kernel@vger.kernel.org,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Fabrice Gasnier, Jonathan Cameron
In-Reply-To: <CA+M3ks4vjE5JMmLjjPnf6ffD9QYSUmSyrpO+yxADT_8WqAA3Tg@mail.gmail.com>
On Thu, May 17, 2018 at 08:59:40PM +0200, Benjamin Gaignard wrote:
> 2018-05-17 18:23 GMT+02:00 Rob Herring <robh+dt@kernel.org>:
> > On Wed, May 16, 2018 at 12:51 PM, William Breathitt Gray
> > <vilhelm.gray@gmail.com> wrote:
> >> From: Benjamin Gaignard <benjamin.gaignard@st.com>
> >
> > v6? Where's v1-v5?
> >
> >> Add bindings for STM32 Timer quadrature encoder.
> >> It is a sub-node of STM32 Timer which implement the
> >> counter part of the hardware.
> >>
> >> Cc: Rob Herring <robh+dt@kernel.org>
> >> Cc: Mark Rutland <mark.rutland@arm.com>
> >> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
> >> Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
> >> ---
> >> .../bindings/counter/stm32-timer-cnt.txt | 26 +++++++++++++++++++
> >> .../devicetree/bindings/mfd/stm32-timers.txt | 7 +++++
> >> 2 files changed, 33 insertions(+)
> >> create mode 100644 Documentation/devicetree/bindings/counter/stm32-timer-cnt.txt
> >>
> >> diff --git a/Documentation/devicetree/bindings/counter/stm32-timer-cnt.txt b/Documentation/devicetree/bindings/counter/stm32-timer-cnt.txt
> >> new file mode 100644
> >> index 000000000000..377728128bef
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/counter/stm32-timer-cnt.txt
> >> @@ -0,0 +1,26 @@
> >> +STMicroelectronics STM32 Timer quadrature encoder
> >> +
> >> +STM32 Timer provides quadrature encoder counter mode to detect
> >
> > 'mode' does not sound like a sub-block of the timers block.
>
> quadrature encoding is one of the counting modes of this hardware
> block which is enable to count on other signals/triggers
You don't need a child node and compatible to set a mode.
> >> +angular position and direction of rotary elements,
> >> +from IN1 and IN2 input signals.
> >> +
> >> +Must be a sub-node of an STM32 Timer device tree node.
> >> +See ../mfd/stm32-timers.txt for details about the parent node.
> >> +
> >> +Required properties:
> >> +- compatible: Must be "st,stm32-timer-counter".
> >> +- pinctrl-names: Set to "default".
> >> +- pinctrl-0: List of phandles pointing to pin configuration nodes,
> >> + to set IN1/IN2 pins in mode of operation for Low-Power
> >> + Timer input on external pin.
> >> +
> >> +Example:
> >> + timers@40010000 {
> >> + compatible = "st,stm32-timers";
> >> + ...
> >> + counter {
> >> + compatible = "st,stm32-timer-counter";
> >
> > Is there only 1? How is the counter addressed?
>
> Yes there is only one counter per hardware block.
> Counter is addressed like the two others sub-nodes and the details
> about parent mode are describe in stm32-timers.txt
> Should I add them here too ? so example will be like that:
No, you should drop the child node and add pinctrl to the parent.
Any other functions this block has that you plan on adding? Please make
bindings as complete as possible, not what you currently have drivers
for.
> timers@40010000 {
> #address-cells = <1>;
> #size-cells = <0>;
> compatible = "st,stm32-timers";
> reg = <0x40010000 0x400>;
> clocks = <&rcc 0 160>;
> clock-names = "int";
> counter {
> compatible = "st,stm32-timer-counter";
> pinctrl-names = "default";
> pinctrl-0 = <&tim1_in_pins>;
> };
> };
>
> Benjamin
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5 2/4] Documentation: bindings: add phy_config for Rockchip USB Type-C PHY
From: Heiko Stuebner @ 2018-05-18 16:24 UTC (permalink / raw)
To: Lin Huang
Cc: devicetree, airlied, briannorris, dianders, linux-kernel,
linux-rockchip, robh+dt, dri-devel, zyw, daniel.vetter,
linux-arm-kernel
In-Reply-To: <1526548680-2552-2-git-send-email-hl@rock-chips.com>
Am Donnerstag, 17. Mai 2018, 11:17:58 CEST schrieb Lin Huang:
> If want to do training outside DP Firmware, need phy voltage swing
> and pre_emphasis value.
>
> Signed-off-by: Lin Huang <hl@rock-chips.com>
> ---
> Changes in v2:
> - None
> Changes in v3:
> - modify property description and add this property to Example
> Change in v4:
> - None
> Change in v5:
> - None
>
> .../devicetree/bindings/phy/phy-rockchip-typec.txt | 29 +++++++++++++++++++++-
> 1 file changed, 28 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt b/Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt
> index 960da7f..af298f2 100644
> --- a/Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt
> +++ b/Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt
> @@ -17,7 +17,8 @@ Required properties:
>
> Optional properties:
> - extcon : extcon specifier for the Power Delivery
> -
> + - rockchip,phy_config : A list of voltage swing(mv) and pre-emphasis
> + (dB) pairs.
mv -> mV I'd think.
This needs a bit more explanation please. Especially as the multiple "0 0"
lines in the examples suggest some deeper ordering requirements.
Like the 3 blocks of 4 entries as can be seen in the default config in
patch3. The binding should definitly describe what these are.
> Required nodes : a sub-node is required for each port the phy provides.
> The sub-node name is used to identify dp or usb3 port,
> and shall be the following entries:
> @@ -50,6 +51,19 @@ Example:
> <&cru SRST_P_UPHY0_TCPHY>;
> reset-names = "uphy", "uphy-pipe", "uphy-tcphy";
>
> + rockchip,phy_config =<0x2a 0x00
> + 0x1f 0x15
> + 0x14 0x22
> + 0x02 0x2b
> + 0x21 0x00
> + 0x12 0x15
> + 0x02 0x22
> + 0 0
> + 0x15 0x00
> + 0x00 0x15
> + 0 0
> + 0 0>;
I don't think they should be hex-values, as according to the doc above
these are values in mV and dB .
Heiko
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Applied "ASoC: ssm2305: fix header layout" to the asoc tree
From: Mark Brown @ 2018-05-18 16:10 UTC (permalink / raw)
To: Marco Felsch
Cc: mark.rutland, devicetree, alsa-devel, lars, lgirdwood, robh+dt,
broonie, kernel
In-Reply-To: <20180518095506.28875-1-m.felsch@pengutronix.de>
The patch
ASoC: ssm2305: fix header layout
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From d460a2ea24db8b99eb7485ecccb453764e7d6b13 Mon Sep 17 00:00:00 2001
From: Marco Felsch <m.felsch@pengutronix.de>
Date: Fri, 18 May 2018 11:55:06 +0200
Subject: [PATCH] ASoC: ssm2305: fix header layout
Make C-header and SPDX-License-Identifier header uniform.
Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
sound/soc/codecs/ssm2305.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/sound/soc/codecs/ssm2305.c b/sound/soc/codecs/ssm2305.c
index 39d8b01cd852..2968959c4b75 100644
--- a/sound/soc/codecs/ssm2305.c
+++ b/sound/soc/codecs/ssm2305.c
@@ -1,9 +1,9 @@
// SPDX-License-Identifier: GPL-2.0
-/*
- * Analog Devices SSM2305 Amplifier Driver
- *
- * Copyright (C) 2018 Pengutronix, Marco Felsch <kernel@pengutronix.de>
- */
+//
+// Analog Devices SSM2305 Amplifier Driver
+//
+// Copyright (C) 2018 Pengutronix, Marco Felsch <kernel@pengutronix.de>
+//
#include <linux/gpio/consumer.h>
#include <linux/module.h>
--
2.17.0
^ permalink raw reply related
* Re: [PATCH v5 06/12] media: dt-bindings: add bindings for i.MX7 media driver
From: Philipp Zabel @ 2018-05-18 16:08 UTC (permalink / raw)
To: Rui Miguel Silva, mchehab, sakari.ailus, Steve Longerbeam,
Rob Herring
Cc: devel, devicetree, Greg Kroah-Hartman, Ryan Harkin, Fabio Estevam,
Shawn Guo, linux-clk, linux-media
In-Reply-To: <20180518092806.3829-7-rui.silva@linaro.org>
On Fri, 2018-05-18 at 10:28 +0100, Rui Miguel Silva wrote:
> Add bindings documentation for i.MX7 media drivers.
>
> Signed-off-by: Rui Miguel Silva <rui.silva@linaro.org>
> ---
> .../devicetree/bindings/media/imx7.txt | 125 ++++++++++++++++++
> 1 file changed, 125 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/imx7.txt
>
> diff --git a/Documentation/devicetree/bindings/media/imx7.txt b/Documentation/devicetree/bindings/media/imx7.txt
> new file mode 100644
> index 000000000000..a26372630377
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/imx7.txt
> @@ -0,0 +1,125 @@
> +Freescale i.MX7 Media Video Device
> +==================================
> +
> +mipi_csi2 node
> +--------------
> +
> +This is the device node for the MIPI CSI-2 receiver core in i.MX7 SoC. It is
> +compatible with previous version of Samsung D-phy.
> +
> +Required properties:
> +
> +- compatible : "fsl,imx7-mipi-csi2";
> +- reg : base address and length of the register set for the device;
> +- interrupts : should contain MIPI CSIS interrupt;
> +- clocks : list of clock specifiers, see
> + Documentation/devicetree/bindings/clock/clock-bindings.txt for details;
> +- clock-names : must contain "pclk", "wrap" and "phy" entries, matching
> + entries in the clock property;
> +- power-domains : a phandle to the power domain, see
> + Documentation/devicetree/bindings/power/power_domain.txt for details.
> +- reset-names : should include following entry "mrst";
> +- resets : a list of phandle, should contain reset entry of
> + reset-names;
> +- phy-supply : from the generic phy bindings, a phandle to a regulator that
> + provides power to MIPI CSIS core;
> +- bus-width : maximum number of data lanes supported (SoC specific);
> +
> +Optional properties:
> +
> +- clock-frequency : The IP's main (system bus) clock frequency in Hz, default
> + value when this property is not specified is 166 MHz;
Could this be obtained from one of the clock inputs via clk_get_rate?
regards
Philipp
^ permalink raw reply
* Re: [PATCH v5 4/4] drm/rockchip: support dp training outside dp firmware
From: Sean Paul @ 2018-05-18 15:36 UTC (permalink / raw)
To: Heiko Stuebner
Cc: devicetree, hl, open list:ARM/Rockchip SoC..., David Airlie,
Brian Norris, Doug Anderson, Linux Kernel, Rob Herring, dri-devel,
Chris Zhong, Daniel Vetter, Kishon Vijay Abraham I,
linux-arm-kernel
In-Reply-To: <11928313.3EhRqhFFHB@phil>
On Fri, May 18, 2018 at 10:52:17AM +0200, Heiko Stuebner wrote:
> Am Freitag, 18. Mai 2018, 03:45:46 CEST schrieb Brian Norris:
> > On Thu, May 17, 2018 at 6:41 PM, hl <hl@rock-chips.com> wrote:
> > > On Thursday, May 17, 2018 09:51 PM, Sean Paul wrote:
> > >> On Thu, May 17, 2018 at 05:18:00PM +0800, Lin Huang wrote:
> > >>> DP firmware uses fixed phy config values to do training, but some
> > >>> boards need to adjust these values to fit for their unique hardware
> > >>> design. So get phy config values from dts and use software link training
> > >>> instead of relying on firmware, if software training fail, keep firmware
> > >>> training as a fallback if sw training fails.
> > >>>
> > >>> Signed-off-by: Chris Zhong <zyw@rock-chips.com>
> > >>> Signed-off-by: Lin Huang <hl@rock-chips.com>
> > >>> ---
> > >>> Changes in v2:
> > >>> - update patch following Enric suggest
> > >>> Changes in v3:
> > >>> - use variable fw_training instead sw_training_success
> > >>> - base on DP SPCE, if training fail use lower link rate to retry training
> > >>> Changes in v4:
> > >>> - improve cdn_dp_get_lower_link_rate() and cdn_dp_software_train_link() follow Sean suggest
> > >>> Changes in v5:
> > >>> - fix some whitespcae issue
> > >>>
> > >>> drivers/gpu/drm/rockchip/Makefile | 3 +-
> > >>> drivers/gpu/drm/rockchip/cdn-dp-core.c | 24 +-
> > >>> drivers/gpu/drm/rockchip/cdn-dp-core.h | 2 +
> > >>> drivers/gpu/drm/rockchip/cdn-dp-link-training.c | 420 ++++++++++++++++++++++++
> > >>> drivers/gpu/drm/rockchip/cdn-dp-reg.c | 31 +-
> > >>> drivers/gpu/drm/rockchip/cdn-dp-reg.h | 38 ++-
> > >>> 6 files changed, 505 insertions(+), 13 deletions(-)
> > >>> create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-link-training.c
> > >>>
> > ...
> > >>> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-link-training.c b/drivers/gpu/drm/rockchip/cdn-dp-link-training.c
> > >>> new file mode 100644
> > >>> index 0000000..73c3290
> > >>> --- /dev/null
> > >>> +++ b/drivers/gpu/drm/rockchip/cdn-dp-link-training.c
> > >>> @@ -0,0 +1,420 @@
> > >>> +// SPDX-License-Identifier: GPL-2.0
> > >>> +/*
> > >>> + * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
> > >>> + * Author: Chris Zhong <zyw@rock-chips.com>
> > >>> + */
> > >>> +
> > >>> +#include <linux/device.h>
> > >>> +#include <linux/delay.h>
> > >>> +#include <linux/phy/phy.h>
> > >>> +#include <soc/rockchip/rockchip_phy_typec.h>
> > >>> +
> > >>> +#include "cdn-dp-core.h"
> > >>> +#include "cdn-dp-reg.h"
> > >>> +
> > >>> +static void cdn_dp_set_signal_levels(struct cdn_dp_device *dp)
> > >>> +{
> > >>> + struct cdn_dp_port *port = dp->port[dp->active_port];
> > >>> + struct rockchip_typec_phy *tcphy = phy_get_drvdata(port->phy);
> > >>
> > >> You ignored Brian's comment on the previous patch:
> > >> This is still antithetical to the PHY framework; you're assuming that
> > >> this is a particular type of PHY here.
> > >>
> > >> FWIW, the mediatek drm driver also assumes a certain PHY type. A quick grep of
> > >> drivers/ shows that the only other non-phy/ driver using this function
> > >> (pinctrl-tegra-xusb.c) also casts it.
> > >>
> > >> Sean
> > >
> > > Thanks Sean, except phy framework have new API to handle it, i have not
> > > idea how to do it in a better way.
> >
> > Well, if Mediatek can do it for their MIPI and HDMI, then maybe we just do it...
>
> I'd think so too. This is in Rockchip-specific code so it will always be
> possible to easily get the soc-type and thus phy-type, if that combination
> really changes down the road.
>
So in the absence of a better solution, and with prior art,
Reviewed-by: Sean Paul <seanpaul@chromium.org>
We just need some eyes on the dt and phy changes in this set. Heiko, can you
help out with that?
Sean
>
> Heiko
>
>
--
Sean Paul, Software Engineer, Google / Chromium OS
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v10 25/27] ARM: davinci: add device tree support to timer
From: David Lechner @ 2018-05-18 15:35 UTC (permalink / raw)
To: Sekhar Nori, linux-clk, devicetree, linux-arm-kernel
Cc: Michael Turquette, Stephen Boyd, Rob Herring, Mark Rutland,
Kevin Hilman, Bartosz Golaszewski, Adam Ford, linux-kernel
In-Reply-To: <c7064bee-d385-4496-c19e-1b72853b01f1@ti.com>
On 05/18/2018 01:05 AM, Sekhar Nori wrote:
> On Thursday 17 May 2018 08:39 PM, David Lechner wrote:
>> On 05/17/2018 09:35 AM, Sekhar Nori wrote:
>>> Hi David,
>>>
>>> On Wednesday 09 May 2018 10:56 PM, David Lechner wrote:
>>>> This adds device tree support to the davinci timer so that when clocks
>>>> are moved to device tree, the timer will still work.
>>>>
>>>> Signed-off-by: David Lechner <david@lechnology.com>
>>>> ---
>>>
>>>> +static int __init of_davinci_timer_init(struct device_node *np)
>>>> +{
>>>> + struct clk *clk;
>>>> +
>>>> + clk = of_clk_get(np, 0);
>>>> + if (IS_ERR(clk)) {
>>>> + struct of_phandle_args clkspec;
>>>> +
>>>> + /*
>>>> + * Fall back to using ref_clk if the actual clock is not
>>>> + * available. There will be problems later if the real clock
>>>> + * source is disabled.
>>>> + */
>>>> +
>>>> + pr_warn("%s: falling back to ref_clk\n", __func__);
>>>> +
>>>> + clkspec.np = of_find_node_by_name(NULL, "ref_clk");
>>>> + if (IS_ERR(clkspec.np)) {
>>>> + pr_err("%s: No clock available for timer!\n", __func__);
>>>> + return PTR_ERR(clkspec.np);
>>>> + }
>>>> + clk = of_clk_get_from_provider(&clkspec);
>>>> + of_node_put(clkspec.np);
>>>> + }
>>>
>>> Do we need this error path now?
>>>
>>> Thanks,
>>> Sekhar
>>>
>>
>> No, not really.
>
> Then lets just print an error and return the error number.
>
OK. FYI, timer_probe() prints the error if we return and error, so
I will just return the error.
^ permalink raw reply
* Re: [PATCH v9 07/11] arm64: kexec_file: add crash dump support
From: Rob Herring @ 2018-05-18 15:35 UTC (permalink / raw)
To: James Morse
Cc: AKASHI Takahiro, catalin.marinas, will.deacon, dhowells, vgoyal,
herbert, davem, dyoung, bhe, arnd, ard.biesheuvel, bhsharma,
kexec, linux-arm-kernel, linux-kernel, devicetree
In-Reply-To: <0aba6388-8a73-d371-7b92-3594639eb27e@arm.com>
On Tue, May 15, 2018 at 06:12:59PM +0100, James Morse wrote:
> Hi guys,
>
> (CC: +RobH, devicetree list)
Thanks.
> On 25/04/18 07:26, AKASHI Takahiro wrote:
> > Enabling crash dump (kdump) includes
> > * prepare contents of ELF header of a core dump file, /proc/vmcore,
> > using crash_prepare_elf64_headers(), and
> > * add two device tree properties, "linux,usable-memory-range" and
> > "linux,elfcorehdr", which represent repsectively a memory range
> > to be used by crash dump kernel and the header's location
BTW, I intend to move existing parsing these out of the arch code.
Please don't add more DT handling to arch/ unless it is *really* arch
specific. I'd assume that the next arch to add kexec support will use
these bindings instead of the powerpc way.
> kexec_file_load() on arm64 needs to be able to create a prop encoded array to
> the FDT, but there doesn't appear to be a libfdt helper to do this.
>
> Akashi's code below adds fdt_setprop_range() to the arch code, and duplicates
> bits of libfdt_internal.h to do the work.
>
> How should this be done? I'm assuming this is something we need a new API in
> libfdt.h for. How do these come about, and is there an interim step we can use
> until then?
Submit patches to upstream dtc and then we can pull it in. Ahead of that
you can add it to drivers/of/fdt.c (or maybe fdt_address.c because
that's really what this is dealing with).
libfdt has only recently gained the beginnings of address handling.
>
> Thanks!
>
> James
>
> > diff --git a/arch/arm64/kernel/machine_kexec_file.c b/arch/arm64/kernel/machine_kexec_file.c
> > index 37c0a9dc2e47..ec674f4d267c 100644
> > --- a/arch/arm64/kernel/machine_kexec_file.c
> > +++ b/arch/arm64/kernel/machine_kexec_file.c
> > @@ -76,6 +81,78 @@ int arch_kexec_walk_mem(struct kexec_buf *kbuf,
> > return ret;
> > }
> >
> > +static int __init arch_kexec_file_init(void)
> > +{
> > + /* Those values are used later on loading the kernel */
> > + __dt_root_addr_cells = dt_root_addr_cells;
> > + __dt_root_size_cells = dt_root_size_cells;
I intend to make dt_root_*_cells private, so don't add another user
outside of drivers/of/.
> > +
> > + return 0;
> > +}
> > +late_initcall(arch_kexec_file_init);
> > +
> > +#define FDT_ALIGN(x, a) (((x) + (a) - 1) & ~((a) - 1))
> > +#define FDT_TAGALIGN(x) (FDT_ALIGN((x), FDT_TAGSIZE))
> > +
> > +static int fdt_prop_len(const char *prop_name, int len)
> > +{
> > + return (strlen(prop_name) + 1) +
> > + sizeof(struct fdt_property) +
> > + FDT_TAGALIGN(len);
> > +}
> > +
> > +static bool cells_size_fitted(unsigned long base, unsigned long size)
I can't imagine this would happen. However, when this is moved to
drivers/of/ or dtc, these need to be u64 types to work on 32-bit.
> > +{
> > + /* if *_cells >= 2, cells can hold 64-bit values anyway */
> > + if ((__dt_root_addr_cells == 1) && (base >= (1ULL << 32)))
> > + return false;
> > +
> > + if ((__dt_root_size_cells == 1) && (size >= (1ULL << 32)))
> > + return false;
> > +
> > + return true;
> > +}
> > +
> > +static void fill_property(void *buf, u64 val64, int cells)
> > +{
> > + u32 val32;
This should be a __be32 or fdt32 type. So should buf.
> > +
> > + if (cells == 1) {
> > + val32 = cpu_to_fdt32((u32)val64);
> > + memcpy(buf, &val32, sizeof(val32));
> > + } else {
> > + memset(buf, 0, cells * sizeof(u32) - sizeof(u64));
> > + buf += cells * sizeof(u32) - sizeof(u64);
> > +
> > + val64 = cpu_to_fdt64(val64);
> > + memcpy(buf, &val64, sizeof(val64));
Look how of_read_number() is implemented. You should be able to do
something similar here looping and avoiding the if/else.
> > + }
> > +}
> > +
> > +static int fdt_setprop_range(void *fdt, int nodeoffset, const char *name,
> > + unsigned long addr, unsigned long size)
A very generic sounding function, but really only works on addresses in
children of the root node.
> > +{
> > + void *buf, *prop;
> > + size_t buf_size;
> > + int result;
> > +
> > + buf_size = (__dt_root_addr_cells + __dt_root_size_cells) * sizeof(u32);
> > + prop = buf = vmalloc(buf_size);
This can go on the stack instead (and would be required to to work in
libfdt).
> > + if (!buf)
> > + return -ENOMEM;
> > +
> > + fill_property(prop, addr, __dt_root_addr_cells);
> > + prop += __dt_root_addr_cells * sizeof(u32);
> > +
> > + fill_property(prop, size, __dt_root_size_cells);
> > +
> > + result = fdt_setprop(fdt, nodeoffset, name, buf, buf_size);
> > +
> > + vfree(buf);
> > +
> > + return result;
> > +}
> > +
> > static int setup_dtb(struct kimage *image,
> > unsigned long initrd_load_addr, unsigned long initrd_len,
> > char *cmdline, unsigned long cmdline_len,
> > @@ -88,10 +165,26 @@ static int setup_dtb(struct kimage *image,
> > int range_len;
> > int ret;
> >
> > + /* check ranges against root's #address-cells and #size-cells */
> > + if (image->type == KEXEC_TYPE_CRASH &&
> > + (!cells_size_fitted(image->arch.elf_load_addr,
> > + image->arch.elf_headers_sz) ||
> > + !cells_size_fitted(crashk_res.start,
> > + crashk_res.end - crashk_res.start + 1))) {
> > + pr_err("Crash memory region doesn't fit into DT's root cell sizes.\n");
> > + ret = -EINVAL;
> > + goto out_err;
> > + }
> > +
> > /* duplicate dt blob */
> > buf_size = fdt_totalsize(initial_boot_params);
> > range_len = (__dt_root_addr_cells + __dt_root_size_cells) * sizeof(u32);
> >
> > + if (image->type == KEXEC_TYPE_CRASH)
> > + buf_size += fdt_prop_len("linux,elfcorehdr", range_len)
> > + + fdt_prop_len("linux,usable-memory-range",
> > + range_len);
> > +
> > if (initrd_load_addr)
> > buf_size += fdt_prop_len("linux,initrd-start", sizeof(u64))
> > + fdt_prop_len("linux,initrd-end", sizeof(u64));
> > @@ -113,6 +206,23 @@ static int setup_dtb(struct kimage *image,
> > if (nodeoffset < 0)
> > goto out_err;
> >
> > + if (image->type == KEXEC_TYPE_CRASH) {
> > + /* add linux,elfcorehdr */
> > + ret = fdt_setprop_range(buf, nodeoffset, "linux,elfcorehdr",
> > + image->arch.elf_load_addr,
> > + image->arch.elf_headers_sz);
> > + if (ret)
> > + goto out_err;
> > +
> > + /* add linux,usable-memory-range */
> > + ret = fdt_setprop_range(buf, nodeoffset,
> > + "linux,usable-memory-range",
> > + crashk_res.start,
> > + crashk_res.end - crashk_res.start + 1);
> > + if (ret)
> > + goto out_err;
> > + }
> > +
> > /* add bootargs */
> > if (cmdline) {
> > ret = fdt_setprop(buf, nodeoffset, "bootargs",
>
^ permalink raw reply
* Re: [PATCH v2 12/26] drm/sun4i: Add support for multiple DW HDMI PHY clock parents
From: Jernej Škrabec @ 2018-05-18 15:34 UTC (permalink / raw)
To: Maxime Ripard
Cc: Jagan Teki, Chen-Yu Tsai, Icenowy Zheng, Rob Herring,
Mark Rutland, Catalin Marinas, Will Deacon, David Airlie,
dri-devel, Michael Turquette, Stephen Boyd, linux-clk,
Michael Trimarchi, linux-arm-kernel, devicetree, linux-kernel,
linux-sunxi
In-Reply-To: <20180518152651.lfymc3kj7npj5tww@flea>
Hi,
Dne petek, 18. maj 2018 ob 17:26:51 CEST je Maxime Ripard napisal(a):
> On Fri, May 18, 2018 at 04:46:41PM +0200, Jernej Škrabec wrote:
> > > And this is a bit sloppy, since if phy_clk_num == 3, you won't try to
> > > lookup pll-2 either.
> >
> > It is highly unlikely this will be higher than 2, at least for this HDMI
> > PHY, since it has only 1 bit reserved for parent selection. But since I
> > have to fix it, I'll add ">= 2"
>
> If we're only going to have two parents at most, ever, why don't we
> had just a single other boolean. This would be less intrusive, and we
> wouldn't have to check for those corner cases.
That works for me too. And since it's only the code, it can always be reworked
if there is the need.
Best regards,
Jernej
>
> > BTW, I'll resend fixed version of this patch for my R40 HDMI series, since
> > there is nothing to hold it back, unlike for this.
>
> Awesome, thanks!
> Maxime
>
> --
> Maxime Ripard, Bootlin (formerly Free Electrons)
> Embedded Linux and Kernel engineering
> https://bootlin.com
^ permalink raw reply
* Re: [PATCH v6 1/2] media: ov2680: dt: Add bindings for OV2680
From: Rui Miguel Silva @ 2018-05-18 15:27 UTC (permalink / raw)
To: Rob Herring
Cc: Rui Miguel Silva, mchehab, sakari.ailus, hverkuil, linux-media,
Fabio Estevam, Ryan Harkin, devicetree
In-Reply-To: <20180518141830.GA14547@rob-hp-laptop>
Hi Rob,
On Fri 18 May 2018 at 14:18, Rob Herring wrote:
> On Wed, May 09, 2018 at 03:31:58PM +0100, Rui Miguel Silva
> wrote:
>> Add device tree binding documentation for the OV2680 camera
>> sensor.
>>
>> CC: devicetree@vger.kernel.org
>> Signed-off-by: Rui Miguel Silva <rui.silva@linaro.org>
>> ---
>> .../devicetree/bindings/media/i2c/ov2680.txt | 46
>> +++++++++++++++++++
>> 1 file changed, 46 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/media/i2c/ov2680.txt
>
> Please add acks/reviewed bys on new versions.
I have add this to the cover letter [0]:
- Removed Rob Herring Reviewed-by tag, since bindings have changed
since his
ack.
But only now I notice that I did not CC the devicetree list for
the all
series, but only for this particular patch. Sorry about that.
---
Cheers,
Rui
[0]: https://www.spinics.net/lists/linux-media/msg133942.html
^ permalink raw reply
* Re: [PATCH v2 12/26] drm/sun4i: Add support for multiple DW HDMI PHY clock parents
From: Maxime Ripard @ 2018-05-18 15:26 UTC (permalink / raw)
To: Jernej Škrabec
Cc: Jagan Teki, Chen-Yu Tsai, Icenowy Zheng, Rob Herring,
Mark Rutland, Catalin Marinas, Will Deacon, David Airlie,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW, Michael Turquette,
Stephen Boyd, linux-clk-u79uwXL29TY76Z2rM5mHXA, Michael Trimarchi,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <4909574.Q3IFWM0xt6@jernej-laptop>
[-- Attachment #1: Type: text/plain, Size: 1151 bytes --]
On Fri, May 18, 2018 at 04:46:41PM +0200, Jernej Škrabec wrote:
> > And this is a bit sloppy, since if phy_clk_num == 3, you won't try to
> > lookup pll-2 either.
>
> It is highly unlikely this will be higher than 2, at least for this HDMI PHY,
> since it has only 1 bit reserved for parent selection. But since I have to fix
> it, I'll add ">= 2"
If we're only going to have two parents at most, ever, why don't we
had just a single other boolean. This would be less intrusive, and we
wouldn't have to check for those corner cases.
> BTW, I'll resend fixed version of this patch for my R40 HDMI series, since
> there is nothing to hold it back, unlike for this.
Awesome, thanks!
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.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: 833 bytes --]
^ permalink raw reply
* [PATCH] arm64: dts: specify 1.8V EMMC capabilities for bcm958742k
From: Scott Branden @ 2018-05-18 15:21 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Catalin Marinas, Will Deacon,
Florian Fainelli
Cc: devicetree, BCM Kernel Feedback, linux-kernel, linux-arm-kernel,
Scott Branden
Specify 1.8V EMMC capabilities for bcm958742k board to indicate support
for UHS mode.
Fixes: d4b4aba6be8a ("arm64: dts: Initial DTS files for Broadcom Stingray SOC")
Signed-off-by: Scott Branden <scott.branden@broadcom.com>
---
arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts b/arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts
index eb6f08c..77efa28 100644
--- a/arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts
+++ b/arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts
@@ -43,6 +43,10 @@
enet-phy-lane-swap;
};
+&sdio0 {
+ mmc-ddr-1_8v;
+};
+
&uart2 {
status = "okay";
};
--
2.5.0
^ permalink raw reply related
* Re: [PATCH v2 12/26] drm/sun4i: Add support for multiple DW HDMI PHY clock parents
From: Sergey Suloev @ 2018-05-18 15:21 UTC (permalink / raw)
To: Jernej Škrabec
Cc: Mark Rutland, devicetree, Michael Trimarchi, Maxime Ripard,
Catalin Marinas, Michael Turquette, Will Deacon, linux-kernel,
dri-devel, Chen-Yu Tsai, David Airlie, linux-sunxi, Rob Herring,
Jagan Teki, Stephen Boyd, linux-clk, linux-arm-kernel,
Icenowy Zheng
In-Reply-To: <3135535.HuDyCXIRmt@jernej-laptop>
Hi, Jernej,
On 05/18/2018 06:15 PM, Jernej Škrabec wrote:
> Hi,
>
> Dne petek, 18. maj 2018 ob 17:09:40 CEST je Sergey Suloev napisal(a):
>> Hi, guys,
>>
>> On 05/18/2018 05:46 PM, Jernej Škrabec wrote:
>>> Hi,
>>>
>>> Dne petek, 18. maj 2018 ob 12:01:16 CEST je Maxime Ripard napisal(a):
>>>> On Fri, May 18, 2018 at 03:15:22PM +0530, Jagan Teki wrote:
>>>>> From: Jernej Skrabec <jernej.skrabec@siol.net>
>>>>>
>>>>> Some SoCs with DW HDMI have multiple possible clock parents, like A64
>>>>> and R40.
>>>>>
>>>>> Expand HDMI PHY clock driver to support second clock parent.
>>>>>
>>>>> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
>>>>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
>>>>> ---
>>>>> Changes for v2:
>>>>> - new patch
>>>>>
>>>>> drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 9 ++-
>>>>> drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 33 ++++++++---
>>>>> drivers/gpu/drm/sun4i/sun8i_hdmi_phy_clk.c | 89
>>>>> ++++++++++++++++++++++-------- 3 files changed, 96 insertions(+), 35
>>>>> deletions(-)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
>>>>> b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h index 79154f0f674a..303189d6602c
>>>>> 100644
>>>>> --- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
>>>>> +++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
>>>>> @@ -98,7 +98,8 @@
>>>>>
>>>>> #define SUN8I_HDMI_PHY_PLL_CFG1_LDO2_EN BIT(29)
>>>>> #define SUN8I_HDMI_PHY_PLL_CFG1_LDO1_EN BIT(28)
>>>>> #define SUN8I_HDMI_PHY_PLL_CFG1_HV_IS_33 BIT(27)
>>>>>
>>>>> -#define SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL BIT(26)
>>>>> +#define SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL_MSK BIT(26)
>>>>> +#define SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL_SHIFT 26
>>>>>
>>>>> #define SUN8I_HDMI_PHY_PLL_CFG1_PLLEN BIT(25)
>>>>> #define SUN8I_HDMI_PHY_PLL_CFG1_LDO_VSET(x) ((x) << 22)
>>>>> #define SUN8I_HDMI_PHY_PLL_CFG1_UNKNOWN(x) ((x) << 20)
>>>>>
>>>>> @@ -146,7 +147,7 @@
>>>>>
>>>>> struct sun8i_hdmi_phy;
>>>>>
>>>>> struct sun8i_hdmi_phy_variant {
>>>>>
>>>>> - bool has_phy_clk;
>>>>> + int phy_clk_num;
>>>>>
>>>>> void (*phy_init)(struct sun8i_hdmi_phy *phy);
>>>>> void (*phy_disable)(struct dw_hdmi *hdmi,
>>>>>
>>>>> struct sun8i_hdmi_phy *phy);
>>>>>
>>>>> @@ -160,6 +161,7 @@ struct sun8i_hdmi_phy {
>>>>>
>>>>> struct clk *clk_mod;
>>>>> struct clk *clk_phy;
>>>>> struct clk *clk_pll0;
>>>>>
>>>>> + struct clk *clk_pll1;
>>>>>
>>>>> unsigned int rcal;
>>>>> struct regmap *regs;
>>>>> struct reset_control *rst_phy;
>>>>>
>>>>> @@ -188,6 +190,7 @@ void sun8i_hdmi_phy_remove(struct sun8i_dw_hdmi
>>>>> *hdmi);
>>>>>
>>>>> void sun8i_hdmi_phy_init(struct sun8i_hdmi_phy *phy);
>>>>> const struct dw_hdmi_phy_ops *sun8i_hdmi_phy_get_ops(void);
>>>>>
>>>>> -int sun8i_phy_clk_create(struct sun8i_hdmi_phy *phy, struct device
>>>>> *dev);
>>>>> +int sun8i_phy_clk_create(struct sun8i_hdmi_phy *phy, struct device
>>>>> *dev,
>>>>> + int clk_num);
>>>>>
>>>>> #endif /* _SUN8I_DW_HDMI_H_ */
>>>>>
>>>>> diff --git a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
>>>>> b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c index
>>>>> 5a52fc489a9d..0eadf087fc46
>>>>> 100644
>>>>> --- a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
>>>>> +++ b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
>>>>> @@ -183,7 +183,13 @@ static int sun8i_hdmi_phy_config_h3(struct dw_hdmi
>>>>> *hdmi,>
>>>>>
>>>>> regmap_update_bits(phy->regs, SUN8I_HDMI_PHY_ANA_CFG1_REG,
>>>>>
>>>>> SUN8I_HDMI_PHY_ANA_CFG1_TXEN_MASK, 0);
>>>>>
>>>>> - regmap_write(phy->regs, SUN8I_HDMI_PHY_PLL_CFG1_REG, pll_cfg1_init);
>>>>> + /*
>>>>> + * NOTE: We have to be careful not to overwrite PHY parent
>>>>> + * clock selection bit and clock divider.
>>>>> + */
>>>>> + regmap_update_bits(phy->regs, SUN8I_HDMI_PHY_PLL_CFG1_REG,
>>>>> + (u32)~SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL_MSK,
>>>>> + pll_cfg1_init);
>>>>>
>>>>> regmap_update_bits(phy->regs, SUN8I_HDMI_PHY_PLL_CFG2_REG,
>>>>>
>>>>> (u32)~SUN8I_HDMI_PHY_PLL_CFG2_PREDIV_MSK,
>>>>> pll_cfg2_init);
>>>>>
>>>>> @@ -232,7 +238,7 @@ static int sun8i_hdmi_phy_config(struct dw_hdmi
>>>>> *hdmi,
>>>>> void *data,>
>>>>>
>>>>> regmap_update_bits(phy->regs, SUN8I_HDMI_PHY_DBG_CTRL_REG,
>>>>>
>>>>> SUN8I_HDMI_PHY_DBG_CTRL_POL_MASK, val);
>>>>>
>>>>> - if (phy->variant->has_phy_clk)
>>>>> + if (phy->variant->phy_clk_num)
>>>>>
>>>>> clk_set_rate(phy->clk_phy, mode->crtc_clock * 1000);
>>>>>
>>>>> return phy->variant->phy_config(hdmi, phy, mode->crtc_clock * 1000);
>>>>>
>>>>> @@ -393,7 +399,7 @@ static const struct sun8i_hdmi_phy_variant
>>>>> sun8i_a83t_hdmi_phy = {>
>>>>>
>>>>> };
>>>>>
>>>>> static const struct sun8i_hdmi_phy_variant sun8i_h3_hdmi_phy = {
>>>>>
>>>>> - .has_phy_clk = true,
>>>>> + .phy_clk_num = 1,
>>>>>
>>>>> .phy_init = &sun8i_hdmi_phy_init_h3,
>>>>> .phy_disable = &sun8i_hdmi_phy_disable_h3,
>>>>> .phy_config = &sun8i_hdmi_phy_config_h3,
>>>>>
>>>>> @@ -464,7 +470,7 @@ int sun8i_hdmi_phy_probe(struct sun8i_dw_hdmi *hdmi,
>>>>> struct device_node *node)>
>>>>>
>>>>> goto err_put_clk_bus;
>>>>>
>>>>> }
>>>>>
>>>>> - if (phy->variant->has_phy_clk) {
>>>>> + if (phy->variant->phy_clk_num) {
>>>>>
>>>>> phy->clk_pll0 = of_clk_get_by_name(node, "pll-0");
>>>>> if (IS_ERR(phy->clk_pll0)) {
>>>>>
>>>>> dev_err(dev, "Could not get pll-0 clock\n");
>>>>>
>>>>> @@ -472,7 +478,16 @@ int sun8i_hdmi_phy_probe(struct sun8i_dw_hdmi
>>>>> *hdmi,
>>>>> struct device_node *node)>
>>>>>
>>>>> goto err_put_clk_mod;
>>>>>
>>>>> }
>>>>>
>>>>> - ret = sun8i_phy_clk_create(phy, dev);
>>>>> + if (phy->variant->phy_clk_num) {
>>>>> + phy->clk_pll1 = of_clk_get_by_name(node, "pll-1");
>>>>> + if (IS_ERR(phy->clk_pll1)) {
>>>>> + dev_err(dev, "Could not get pll-1 clock\n");
>>>>> + ret = PTR_ERR(phy->clk_pll1);
>>>>> + goto err_put_clk_mod;
>>>>> + }
>>>>> + }
>>>>> +
>>>> You have a bug here. If phy_clk_num == 1, you'll still try to lookup
>>>> pll-1.
>>> This is actually WIP patch taken from my github. This issue was fixed
>>> already locally on disk. I thought Jagan will not use it until SRAM C
>>> patches land.>
>>>> And this is a bit sloppy, since if phy_clk_num == 3, you won't try to
>>>> lookup pll-2 either.
>>> It is highly unlikely this will be higher than 2, at least for this HDMI
>>> PHY, since it has only 1 bit reserved for parent selection. But since I
>>> have to fix it, I'll add ">= 2"
>>>
>>>>> + ret = sun8i_phy_clk_create(phy, dev, phy->variant->phy_clk_num);
>>>>>
>>>>> if (ret) {
>>>>>
>>>>> dev_err(dev, "Couldn't create the PHY clock\n");
>>>>> goto err_put_clk_pll0;
>>>>>
>>>>> @@ -515,8 +530,8 @@ int sun8i_hdmi_phy_probe(struct sun8i_dw_hdmi *hdmi,
>>>>> struct device_node *node)>
>>>>>
>>>>> err_put_rst_phy:
>>>>> reset_control_put(phy->rst_phy);
>>>>>
>>>>> err_put_clk_pll0:
>>>>> - if (phy->variant->has_phy_clk)
>>>>> - clk_put(phy->clk_pll0);
>>>>> + clk_put(phy->clk_pll0);
>>>>> + clk_put(phy->clk_pll1);
>>>>>
>>>>> err_put_clk_mod:
>>>>> clk_put(phy->clk_mod);
>>>>>
>>>>> err_put_clk_bus:
>>>>> @@ -536,8 +551,8 @@ void sun8i_hdmi_phy_remove(struct sun8i_dw_hdmi
>>>>> *hdmi)
>>>>>
>>>>> reset_control_put(phy->rst_phy);
>>>>>
>>>>> - if (phy->variant->has_phy_clk)
>>>>> - clk_put(phy->clk_pll0);
>>>>> + clk_put(phy->clk_pll0);
>>>>> + clk_put(phy->clk_pll1);
>>>>>
>>>>> clk_put(phy->clk_mod);
>>>>> clk_put(phy->clk_bus);
>>>>>
>>>>> }
>>>>>
>>>>> diff --git a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy_clk.c
>>>>> b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy_clk.c index
>>>>> faea449812f8..85b12fc96dbc 100644
>>>>> --- a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy_clk.c
>>>>> +++ b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy_clk.c
>>>>> @@ -22,29 +22,36 @@ static int sun8i_phy_clk_determine_rate(struct
>>>>> clk_hw
>>>>> *hw,>
>>>>>
>>>>> {
>>>>>
>>>>> unsigned long rate = req->rate;
>>>>> unsigned long best_rate = 0;
>>>>>
>>>>> - struct clk_hw *parent;
>>>>> + struct clk_hw *best_parent = NULL;
>>>>> + struct clk_hw *parent = NULL;
>>>>>
>>>>> int best_div = 1;
>>>>>
>>>>> - int i;
>>>>> + int i, p;
>>>>>
>>>>> - parent = clk_hw_get_parent(hw);
>>>>> -
>>>>> - for (i = 1; i <= 16; i++) {
>>>>> - unsigned long ideal = rate * i;
>>>>> - unsigned long rounded;
>>>>> -
>>>>> - rounded = clk_hw_round_rate(parent, ideal);
>>>>> -
>>>>> - if (rounded == ideal) {
>>>>> - best_rate = rounded;
>>>>> - best_div = i;
>>>>> - break;
>>>>> - }
>>>>> + for (p = 0; p < clk_hw_get_num_parents(hw); p++) {
>>>>> + parent = clk_hw_get_parent_by_index(hw, p);
>>>>> + if (!parent)
>>>>> + continue;
>>>>>
>>>>> - if (!best_rate ||
>>>>> - abs(rate - rounded / i) <
>>>>> - abs(rate - best_rate / best_div)) {
>>>>> - best_rate = rounded;
>>>>> - best_div = i;
>>>>> + for (i = 1; i <= 16; i++) {
>>>>> + unsigned long ideal = rate * i;
>>>>> + unsigned long rounded;
>>>>> +
>>>>> + rounded = clk_hw_round_rate(parent, ideal);
>>>>> +
>>>>> + if (rounded == ideal) {
>>>>> + best_rate = rounded;
>>>>> + best_div = i;
>>>>> + best_parent = parent;
>>>>> + break;
>>>>> + }
>>>>> +
>>>>> + if (!best_rate ||
>>>>> + abs(rate - rounded / i) <
>>>>> + abs(rate - best_rate / best_div)) {
>>>>> + best_rate = rounded;
>>>>> + best_div = i;
>>>>> + best_parent = parent;
>>>>> + }
>>>>>
>>>>> }
>>>>>
>>>>> }
>>>>>
>>>>> @@ -95,22 +102,58 @@ static int sun8i_phy_clk_set_rate(struct clk_hw
>>>>> *hw,
>>>>> unsigned long rate,>
>>>>>
>>>>> return 0;
>>>>>
>>>>> }
>>>>>
>>>>> +static u8 sun8i_phy_clk_get_parent(struct clk_hw *hw)
>>>>> +{
>>>>> + struct sun8i_phy_clk *priv = hw_to_phy_clk(hw);
>>>>> + u32 reg;
>>>>> +
>>>>> + regmap_read(priv->phy->regs, SUN8I_HDMI_PHY_PLL_CFG1_REG, ®);
>>>>> + reg = (reg & SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL_MSK) >>
>>>>> + SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL_SHIFT;
>>>>> +
>>>>> + return reg;
>>>>> +}
>>>>> +
>>>>> +static int sun8i_phy_clk_set_parent(struct clk_hw *hw, u8 index)
>>>>> +{
>>>>> + struct sun8i_phy_clk *priv = hw_to_phy_clk(hw);
>>>>> +
>>>>> + if (index > 1)
>>>>> + return -EINVAL;
>>>>> +
>>>>> + regmap_update_bits(priv->phy->regs, SUN8I_HDMI_PHY_PLL_CFG1_REG,
>>>>> + SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL_MSK,
>>>>> + index << SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL_SHIFT);
>>>>> +
>>>>> + return 0;
>>>>> +}
>>>>> +
>>>> The DT bindings changes and the clk changes should be part of separate
>>>> patches.
>>> By DT bindings changes you mean code which reads DT and not DT
>>> documentation, right?
>>>
>>> Ok, I'll split it.
>>>
>>> BTW, I'll resend fixed version of this patch for my R40 HDMI series, since
>>> there is nothing to hold it back, unlike for this.
>>>
>>> Best regards,
>>> Jernej
>>>
>>>
>>>
>>> _______________________________________________
>>> linux-arm-kernel mailing list
>>> linux-arm-kernel@lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>> you have been talking about SRAM patches, required for A64 DE2, for
>> about a half a year.
>> May I ask you to explain in a couple of words why they are so important ?
>> I am really curious because I have DE2 already working on my A64 without
>> those magic patches..
>>
> You probably have HDMI enabled in U-Boot, right? If you disable that driver in
> U-Boot, Linux driver shouldn't work anymore. There is consensus that Linux A64
> DE2 driver shouldn't rely on U-Boot setting bits. Those SRAM C patches will
> probably also affect how DT DE2 entries are written, especially if it will be
> implemented as a bus, as once proposed by Icenowy.
>
> Best regards,
> Jernej
>
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
thanks, got it. yes , I think U-Boot is handing this for me. And I am
not using the "bus way".
^ permalink raw reply
* Re: [PATCH v2 12/26] drm/sun4i: Add support for multiple DW HDMI PHY clock parents
From: Jernej Škrabec @ 2018-05-18 15:15 UTC (permalink / raw)
To: Sergey Suloev
Cc: Maxime Ripard, Mark Rutland, devicetree, David Airlie,
Catalin Marinas, Michael Turquette, linux-sunxi, Will Deacon,
linux-kernel, dri-devel, Stephen Boyd, Chen-Yu Tsai, Rob Herring,
Jagan Teki, Michael Trimarchi, linux-clk, linux-arm-kernel,
Icenowy Zheng
In-Reply-To: <824c6989-7930-86dc-1195-494580f6cb38@orpaltech.com>
Hi,
Dne petek, 18. maj 2018 ob 17:09:40 CEST je Sergey Suloev napisal(a):
> Hi, guys,
>
> On 05/18/2018 05:46 PM, Jernej Škrabec wrote:
> > Hi,
> >
> > Dne petek, 18. maj 2018 ob 12:01:16 CEST je Maxime Ripard napisal(a):
> >> On Fri, May 18, 2018 at 03:15:22PM +0530, Jagan Teki wrote:
> >>> From: Jernej Skrabec <jernej.skrabec@siol.net>
> >>>
> >>> Some SoCs with DW HDMI have multiple possible clock parents, like A64
> >>> and R40.
> >>>
> >>> Expand HDMI PHY clock driver to support second clock parent.
> >>>
> >>> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> >>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> >>> ---
> >>> Changes for v2:
> >>> - new patch
> >>>
> >>> drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 9 ++-
> >>> drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 33 ++++++++---
> >>> drivers/gpu/drm/sun4i/sun8i_hdmi_phy_clk.c | 89
> >>> ++++++++++++++++++++++-------- 3 files changed, 96 insertions(+), 35
> >>> deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
> >>> b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h index 79154f0f674a..303189d6602c
> >>> 100644
> >>> --- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
> >>> +++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
> >>> @@ -98,7 +98,8 @@
> >>>
> >>> #define SUN8I_HDMI_PHY_PLL_CFG1_LDO2_EN BIT(29)
> >>> #define SUN8I_HDMI_PHY_PLL_CFG1_LDO1_EN BIT(28)
> >>> #define SUN8I_HDMI_PHY_PLL_CFG1_HV_IS_33 BIT(27)
> >>>
> >>> -#define SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL BIT(26)
> >>> +#define SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL_MSK BIT(26)
> >>> +#define SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL_SHIFT 26
> >>>
> >>> #define SUN8I_HDMI_PHY_PLL_CFG1_PLLEN BIT(25)
> >>> #define SUN8I_HDMI_PHY_PLL_CFG1_LDO_VSET(x) ((x) << 22)
> >>> #define SUN8I_HDMI_PHY_PLL_CFG1_UNKNOWN(x) ((x) << 20)
> >>>
> >>> @@ -146,7 +147,7 @@
> >>>
> >>> struct sun8i_hdmi_phy;
> >>>
> >>> struct sun8i_hdmi_phy_variant {
> >>>
> >>> - bool has_phy_clk;
> >>> + int phy_clk_num;
> >>>
> >>> void (*phy_init)(struct sun8i_hdmi_phy *phy);
> >>> void (*phy_disable)(struct dw_hdmi *hdmi,
> >>>
> >>> struct sun8i_hdmi_phy *phy);
> >>>
> >>> @@ -160,6 +161,7 @@ struct sun8i_hdmi_phy {
> >>>
> >>> struct clk *clk_mod;
> >>> struct clk *clk_phy;
> >>> struct clk *clk_pll0;
> >>>
> >>> + struct clk *clk_pll1;
> >>>
> >>> unsigned int rcal;
> >>> struct regmap *regs;
> >>> struct reset_control *rst_phy;
> >>>
> >>> @@ -188,6 +190,7 @@ void sun8i_hdmi_phy_remove(struct sun8i_dw_hdmi
> >>> *hdmi);
> >>>
> >>> void sun8i_hdmi_phy_init(struct sun8i_hdmi_phy *phy);
> >>> const struct dw_hdmi_phy_ops *sun8i_hdmi_phy_get_ops(void);
> >>>
> >>> -int sun8i_phy_clk_create(struct sun8i_hdmi_phy *phy, struct device
> >>> *dev);
> >>> +int sun8i_phy_clk_create(struct sun8i_hdmi_phy *phy, struct device
> >>> *dev,
> >>> + int clk_num);
> >>>
> >>> #endif /* _SUN8I_DW_HDMI_H_ */
> >>>
> >>> diff --git a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
> >>> b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c index
> >>> 5a52fc489a9d..0eadf087fc46
> >>> 100644
> >>> --- a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
> >>> +++ b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
> >>> @@ -183,7 +183,13 @@ static int sun8i_hdmi_phy_config_h3(struct dw_hdmi
> >>> *hdmi,>
> >>>
> >>> regmap_update_bits(phy->regs, SUN8I_HDMI_PHY_ANA_CFG1_REG,
> >>>
> >>> SUN8I_HDMI_PHY_ANA_CFG1_TXEN_MASK, 0);
> >>>
> >>> - regmap_write(phy->regs, SUN8I_HDMI_PHY_PLL_CFG1_REG, pll_cfg1_init);
> >>> + /*
> >>> + * NOTE: We have to be careful not to overwrite PHY parent
> >>> + * clock selection bit and clock divider.
> >>> + */
> >>> + regmap_update_bits(phy->regs, SUN8I_HDMI_PHY_PLL_CFG1_REG,
> >>> + (u32)~SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL_MSK,
> >>> + pll_cfg1_init);
> >>>
> >>> regmap_update_bits(phy->regs, SUN8I_HDMI_PHY_PLL_CFG2_REG,
> >>>
> >>> (u32)~SUN8I_HDMI_PHY_PLL_CFG2_PREDIV_MSK,
> >>> pll_cfg2_init);
> >>>
> >>> @@ -232,7 +238,7 @@ static int sun8i_hdmi_phy_config(struct dw_hdmi
> >>> *hdmi,
> >>> void *data,>
> >>>
> >>> regmap_update_bits(phy->regs, SUN8I_HDMI_PHY_DBG_CTRL_REG,
> >>>
> >>> SUN8I_HDMI_PHY_DBG_CTRL_POL_MASK, val);
> >>>
> >>> - if (phy->variant->has_phy_clk)
> >>> + if (phy->variant->phy_clk_num)
> >>>
> >>> clk_set_rate(phy->clk_phy, mode->crtc_clock * 1000);
> >>>
> >>> return phy->variant->phy_config(hdmi, phy, mode->crtc_clock * 1000);
> >>>
> >>> @@ -393,7 +399,7 @@ static const struct sun8i_hdmi_phy_variant
> >>> sun8i_a83t_hdmi_phy = {>
> >>>
> >>> };
> >>>
> >>> static const struct sun8i_hdmi_phy_variant sun8i_h3_hdmi_phy = {
> >>>
> >>> - .has_phy_clk = true,
> >>> + .phy_clk_num = 1,
> >>>
> >>> .phy_init = &sun8i_hdmi_phy_init_h3,
> >>> .phy_disable = &sun8i_hdmi_phy_disable_h3,
> >>> .phy_config = &sun8i_hdmi_phy_config_h3,
> >>>
> >>> @@ -464,7 +470,7 @@ int sun8i_hdmi_phy_probe(struct sun8i_dw_hdmi *hdmi,
> >>> struct device_node *node)>
> >>>
> >>> goto err_put_clk_bus;
> >>>
> >>> }
> >>>
> >>> - if (phy->variant->has_phy_clk) {
> >>> + if (phy->variant->phy_clk_num) {
> >>>
> >>> phy->clk_pll0 = of_clk_get_by_name(node, "pll-0");
> >>> if (IS_ERR(phy->clk_pll0)) {
> >>>
> >>> dev_err(dev, "Could not get pll-0 clock\n");
> >>>
> >>> @@ -472,7 +478,16 @@ int sun8i_hdmi_phy_probe(struct sun8i_dw_hdmi
> >>> *hdmi,
> >>> struct device_node *node)>
> >>>
> >>> goto err_put_clk_mod;
> >>>
> >>> }
> >>>
> >>> - ret = sun8i_phy_clk_create(phy, dev);
> >>> + if (phy->variant->phy_clk_num) {
> >>> + phy->clk_pll1 = of_clk_get_by_name(node, "pll-1");
> >>> + if (IS_ERR(phy->clk_pll1)) {
> >>> + dev_err(dev, "Could not get pll-1 clock\n");
> >>> + ret = PTR_ERR(phy->clk_pll1);
> >>> + goto err_put_clk_mod;
> >>> + }
> >>> + }
> >>> +
> >>
> >> You have a bug here. If phy_clk_num == 1, you'll still try to lookup
> >> pll-1.
> >
> > This is actually WIP patch taken from my github. This issue was fixed
> > already locally on disk. I thought Jagan will not use it until SRAM C
> > patches land.>
> >> And this is a bit sloppy, since if phy_clk_num == 3, you won't try to
> >> lookup pll-2 either.
> >
> > It is highly unlikely this will be higher than 2, at least for this HDMI
> > PHY, since it has only 1 bit reserved for parent selection. But since I
> > have to fix it, I'll add ">= 2"
> >
> >>> + ret = sun8i_phy_clk_create(phy, dev, phy->variant->phy_clk_num);
> >>>
> >>> if (ret) {
> >>>
> >>> dev_err(dev, "Couldn't create the PHY clock\n");
> >>> goto err_put_clk_pll0;
> >>>
> >>> @@ -515,8 +530,8 @@ int sun8i_hdmi_phy_probe(struct sun8i_dw_hdmi *hdmi,
> >>> struct device_node *node)>
> >>>
> >>> err_put_rst_phy:
> >>> reset_control_put(phy->rst_phy);
> >>>
> >>> err_put_clk_pll0:
> >>> - if (phy->variant->has_phy_clk)
> >>> - clk_put(phy->clk_pll0);
> >>> + clk_put(phy->clk_pll0);
> >>> + clk_put(phy->clk_pll1);
> >>>
> >>> err_put_clk_mod:
> >>> clk_put(phy->clk_mod);
> >>>
> >>> err_put_clk_bus:
> >>> @@ -536,8 +551,8 @@ void sun8i_hdmi_phy_remove(struct sun8i_dw_hdmi
> >>> *hdmi)
> >>>
> >>> reset_control_put(phy->rst_phy);
> >>>
> >>> - if (phy->variant->has_phy_clk)
> >>> - clk_put(phy->clk_pll0);
> >>> + clk_put(phy->clk_pll0);
> >>> + clk_put(phy->clk_pll1);
> >>>
> >>> clk_put(phy->clk_mod);
> >>> clk_put(phy->clk_bus);
> >>>
> >>> }
> >>>
> >>> diff --git a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy_clk.c
> >>> b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy_clk.c index
> >>> faea449812f8..85b12fc96dbc 100644
> >>> --- a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy_clk.c
> >>> +++ b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy_clk.c
> >>> @@ -22,29 +22,36 @@ static int sun8i_phy_clk_determine_rate(struct
> >>> clk_hw
> >>> *hw,>
> >>>
> >>> {
> >>>
> >>> unsigned long rate = req->rate;
> >>> unsigned long best_rate = 0;
> >>>
> >>> - struct clk_hw *parent;
> >>> + struct clk_hw *best_parent = NULL;
> >>> + struct clk_hw *parent = NULL;
> >>>
> >>> int best_div = 1;
> >>>
> >>> - int i;
> >>> + int i, p;
> >>>
> >>> - parent = clk_hw_get_parent(hw);
> >>> -
> >>> - for (i = 1; i <= 16; i++) {
> >>> - unsigned long ideal = rate * i;
> >>> - unsigned long rounded;
> >>> -
> >>> - rounded = clk_hw_round_rate(parent, ideal);
> >>> -
> >>> - if (rounded == ideal) {
> >>> - best_rate = rounded;
> >>> - best_div = i;
> >>> - break;
> >>> - }
> >>> + for (p = 0; p < clk_hw_get_num_parents(hw); p++) {
> >>> + parent = clk_hw_get_parent_by_index(hw, p);
> >>> + if (!parent)
> >>> + continue;
> >>>
> >>> - if (!best_rate ||
> >>> - abs(rate - rounded / i) <
> >>> - abs(rate - best_rate / best_div)) {
> >>> - best_rate = rounded;
> >>> - best_div = i;
> >>> + for (i = 1; i <= 16; i++) {
> >>> + unsigned long ideal = rate * i;
> >>> + unsigned long rounded;
> >>> +
> >>> + rounded = clk_hw_round_rate(parent, ideal);
> >>> +
> >>> + if (rounded == ideal) {
> >>> + best_rate = rounded;
> >>> + best_div = i;
> >>> + best_parent = parent;
> >>> + break;
> >>> + }
> >>> +
> >>> + if (!best_rate ||
> >>> + abs(rate - rounded / i) <
> >>> + abs(rate - best_rate / best_div)) {
> >>> + best_rate = rounded;
> >>> + best_div = i;
> >>> + best_parent = parent;
> >>> + }
> >>>
> >>> }
> >>>
> >>> }
> >>>
> >>> @@ -95,22 +102,58 @@ static int sun8i_phy_clk_set_rate(struct clk_hw
> >>> *hw,
> >>> unsigned long rate,>
> >>>
> >>> return 0;
> >>>
> >>> }
> >>>
> >>> +static u8 sun8i_phy_clk_get_parent(struct clk_hw *hw)
> >>> +{
> >>> + struct sun8i_phy_clk *priv = hw_to_phy_clk(hw);
> >>> + u32 reg;
> >>> +
> >>> + regmap_read(priv->phy->regs, SUN8I_HDMI_PHY_PLL_CFG1_REG, ®);
> >>> + reg = (reg & SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL_MSK) >>
> >>> + SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL_SHIFT;
> >>> +
> >>> + return reg;
> >>> +}
> >>> +
> >>> +static int sun8i_phy_clk_set_parent(struct clk_hw *hw, u8 index)
> >>> +{
> >>> + struct sun8i_phy_clk *priv = hw_to_phy_clk(hw);
> >>> +
> >>> + if (index > 1)
> >>> + return -EINVAL;
> >>> +
> >>> + regmap_update_bits(priv->phy->regs, SUN8I_HDMI_PHY_PLL_CFG1_REG,
> >>> + SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL_MSK,
> >>> + index << SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL_SHIFT);
> >>> +
> >>> + return 0;
> >>> +}
> >>> +
> >>
> >> The DT bindings changes and the clk changes should be part of separate
> >> patches.
> >
> > By DT bindings changes you mean code which reads DT and not DT
> > documentation, right?
> >
> > Ok, I'll split it.
> >
> > BTW, I'll resend fixed version of this patch for my R40 HDMI series, since
> > there is nothing to hold it back, unlike for this.
> >
> > Best regards,
> > Jernej
> >
> >
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
> you have been talking about SRAM patches, required for A64 DE2, for
> about a half a year.
> May I ask you to explain in a couple of words why they are so important ?
> I am really curious because I have DE2 already working on my A64 without
> those magic patches..
>
You probably have HDMI enabled in U-Boot, right? If you disable that driver in
U-Boot, Linux driver shouldn't work anymore. There is consensus that Linux A64
DE2 driver shouldn't rely on U-Boot setting bits. Those SRAM C patches will
probably also affect how DT DE2 entries are written, especially if it will be
implemented as a bus, as once proposed by Icenowy.
Best regards,
Jernej
^ permalink raw reply
* Re: [PATCH 1/5] dt-bindings: pinctrl: document the STMFX pinctrl bindings
From: Amelie DELAUNAY @ 2018-05-18 15:13 UTC (permalink / raw)
To: Lee Jones, Linus Walleij
Cc: Mark Rutland, Rob Herring, Alexandre TORGUE,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Russell King, linux-kernel@vger.kernel.org,
open list:GPIO SUBSYSTEM, Maxime Coquelin, Linux ARM
In-Reply-To: <20180518135237.GQ5130@dell>
On 05/18/2018 03:52 PM, Lee Jones wrote:
> On Fri, 18 May 2018, Amelie DELAUNAY wrote:
>
>> On 05/17/2018 08:36 AM, Lee Jones wrote:
>>> On Wed, 16 May 2018, Amelie DELAUNAY wrote:
>>>
>>>>
>>>>
>>>> On 05/16/2018 04:20 PM, Linus Walleij wrote:
>>>>> On Wed, May 9, 2018 at 9:56 AM, Amelie DELAUNAY <amelie.delaunay@st.com> wrote:
>>>>>
>>>>>> Indeed, stmfx has other functions than GPIO. But, after comments done
>>>>>> here: [1] and there: [2], it has been decided to move MFD parent/GPIO
>>>>>> child drivers into a single PINCTRL/GPIO driver because of the following
>>>>>> reasons:
>>>>>> - Other stmfx functions (IDD measurement and TouchScreen controller) are
>>>>>> not used on any of the boards using an stmfx and supported by Linux, so
>>>>>> no way to test these functions, and no need to maintain them while they
>>>>>> are not being used.
>>>>>> - But, in the case a new board will use more than GPIO function on
>>>>>> stmfx, the actual implementation allow to easily extract common init
>>>>>> part of stmfx and put it in an MFD driver.
>>>>>>
>>>>>> So I could remove gpio sub-node and put its contents in stmfx node and
>>>>>> keep single PINCTRL/GPIO driver for the time being.
>>>>>> Please advise,
>>>>>
>>>>> I would normally advice to use the right modeling from the start, create
>>>>> the MFD driver and spawn the devices from there. It is confusing
>>>>> if the layout of the driver(s) doesn't really match the layout of the
>>>>> hardware.
>>>>>
>>>>> I understand that it is a pain to write new MFD drivers to get your
>>>>> things going and it would be "nice to get this working really quick
>>>>> now" but in my experience it is better to do it right from the start.
>>>>>
>>>>
>>>> Hi Linus,
>>>>
>>>> Thanks for your advice. I understand the point.
>>>> So, the right modeling would be to:
>>>> - create an MFD driver with the common init part of stmfx
>>>> - remove all common init part of stmfx-pinctrl driver and keep only all
>>>> gpio/pinctrl functions.
>>>>
>>>> I will not develop the other stmfx functions (IDD measurement driver and
>>>> TouchScreen controller driver) because, as explained ealier, they are
>>>> not used on any of the boards using an stmfx and supported by Linux, so
>>>> no way to test these functions, and no need to maintain them while they
>>>> are not being used.
>>>>
>>>> Lee, are you OK with that ?
>>>
>>> I missed a lot of this conversation I think, but from what I've read,
>>> it sounds fine.
>>>
>>
>> I summarize the situation:
>> - I still don't have an official datasheet for STMFX device which could
>> justify the use of an MFD driver;
>> - the MFD driver will contain the STMFX chip initialization stuff such
>> as regmap initialization (regmap structure will be shared with the
>> child), chip initialization, global interrupt management;
>> - there will be only one child (GPIO/PINCTRL node) for the time being.
>>
>> So, is "MFD driver + GPIO/PINCTRL driver" the right modeling, and does
>> it still sound fine after this summary ? :)
>
> It is starting to sound like there will only ever be one child device,
> which starts to cross the line into "this is not an MFD" (M = Multi)
> territory.
>
... for the time being. So, Linus, Lee, is it possible to find common
ground ?
^ permalink raw reply
* Re: [PATCH v3 3/3] arm64: dts: renesas: draak: Describe HDMI input
From: Laurent Pinchart @ 2018-05-18 15:13 UTC (permalink / raw)
To: Jacopo Mondi
Cc: niklas.soderlund, horms, geert, magnus.damm, robh+dt,
linux-renesas-soc, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <1526654878-11143-4-git-send-email-jacopo+renesas@jmondi.org>
Hi Jacopo,
Thank you for the patch.
On Friday, 18 May 2018 17:47:58 EEST Jacopo Mondi wrote:
> Describe HDMI input connector and ADV7612 HDMI decoder installed on
> R-Car Gen3 Draak board.
>
> The video signal routing to the HDMI decoder to the video input interface
> VIN4 is multiplexed with CVBS input path, and enabled/disabled through
> on-board switches SW-49, SW-50, SW-51 and SW-52.
>
> As the default board switches configuration connects CVBS input to VIN4,
> leave the HDMI decoder unconnected in DTS.
>
> Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> v2 -> v3:
> - Add comment on HDMI output port about the shared CVBS/HDMI video path
> - Add Niklas' R-b tag
> ---
> arch/arm64/boot/dts/renesas/r8a77995-draak.dts | 48 +++++++++++++++++++++++
> 1 file changed, 48 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts index 95745fc..1e475a4
> 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> +++ b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> @@ -59,6 +59,17 @@
> };
> };
>
> + hdmi-in {
> + compatible = "hdmi-connector";
> + type = "a";
> +
> + port {
> + hdmi_con_in: endpoint {
> + remote-endpoint = <&adv7612_in>;
> + };
> + };
> + };
> +
> memory@48000000 {
> device_type = "memory";
> /* first 128MB is reserved for secure area. */
> @@ -176,6 +187,43 @@
> };
> };
> };
> +
> + hdmi-decoder@4c {
> + compatible = "adi,adv7612";
> + reg = <0x4c>;
> + default-input = <0>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> +
> + adv7612_in: endpoint {
> + remote-endpoint = <&hdmi_con_in>;
> + };
> + };
> +
> + port@2 {
> + reg = <2>;
> +
> + /*
> + * The VIN4 video input path is shared between
> + * CVBS and HDMI inputs through SW[49-54]
> + * switches.
> + *
> + * CVBS is the default selection, leave HDMI
> + * not connected here.
> + */
> + adv7612_out: endpoint {
> + pclk-sample = <0>;
> + hsync-active = <0>;
> + vsync-active = <0>;
> + };
> + };
> + };
> + };
> };
>
> &i2c1 {
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v3 2/3] arm64: dts: renesas: draak: Describe CVBS input
From: Laurent Pinchart @ 2018-05-18 15:12 UTC (permalink / raw)
To: Jacopo Mondi
Cc: niklas.soderlund, horms, geert, magnus.damm, robh+dt,
linux-renesas-soc, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <1526654878-11143-3-git-send-email-jacopo+renesas@jmondi.org>
Hi Jacopo,
Thank you for the patch.
On Friday, 18 May 2018 17:47:57 EEST Jacopo Mondi wrote:
> Describe CVBS video input through analog video decoder ADV7180
> connected to video input interface VIN4.
>
> The video input signal path is shared with HDMI video input, and
> selected by on-board switches SW-53 and SW-54 with CVBS input selected
> by the default switches configuration.
>
> Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
>
> ---
> v2 -> v3:
> - Add comment to describe the shared input video path
> - Add my SoB and Niklas' R-b tags
> ---
> arch/arm64/boot/dts/renesas/r8a77995-draak.dts | 42 +++++++++++++++++++++++
> 1 file changed, 42 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts index 9d73de8..95745fc
> 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> +++ b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> @@ -142,6 +142,11 @@
> groups = "usb0";
> function = "usb0";
> };
> +
> + vin4_pins_cvbs: vin4 {
> + groups = "vin4_data8", "vin4_sync", "vin4_clk";
> + function = "vin4";
> + };
> };
>
> &i2c0 {
> @@ -154,6 +159,23 @@
> reg = <0x50>;
> pagesize = <8>;
> };
> +
> + analog-video@20 {
> + compatible = "adi,adv7180";
> + reg = <0x20>;
> +
> + port {
The adv7180 DT bindings document the output port as 3 or 6 (respectively for
the CP and ST versions of the chip). You should thus number the port. Apart
from that the patch looks good.
> + /*
> + * The VIN4 video input path is shared between
> + * CVBS and HDMI inputs through SW[49-54] switches.
> + *
> + * CVBS is the default selection, link it to VIN4 here.
> + */
> + adv7180_out: endpoint {
> + remote-endpoint = <&vin4_in>;
> + };
> + };
> + };
> };
>
> &i2c1 {
> @@ -246,3 +268,23 @@
> timeout-sec = <60>;
> status = "okay";
> };
> +
> +&vin4 {
> + pinctrl-0 = <&vin4_pins_cvbs>;
> + pinctrl-names = "default";
> +
> + status = "okay";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> +
> + vin4_in: endpoint {
> + remote-endpoint = <&adv7180_out>;
> + };
> + };
> + };
> +};
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v6 1/2] dt: bindings: lm3601x: Introduce the lm3601x driver
From: Rob Herring @ 2018-05-18 15:11 UTC (permalink / raw)
To: Dan Murphy
Cc: mark.rutland, jacek.anaszewski, pavel, devicetree, linux-kernel,
linux-leds
In-Reply-To: <20180515154352.20263-1-dmurphy@ti.com>
On Tue, May 15, 2018 at 10:43:51AM -0500, Dan Murphy wrote:
> Introduce the device tree bindings for the lm3601x
> family of LED torch, flash and IR drivers.
>
> Signed-off-by: Dan Murphy <dmurphy@ti.com>
> ---
>
> v6 - Removed multiple led child nodes, fixed example to display micro ranges
> for corresponding child nodes and added led-sources to define the current driver -
> https://patchwork.kernel.org/patch/10392121/
>
> v5 - No changes - https://patchwork.kernel.org/patch/10391743/
> v4 - Added " " around "=", changed strobe to flash on label, removed "support and
> register" comment and change ir lable to ir:torch - See v2 patchworks for comments
> v3 - Removed wildcard compatible - https://patchwork.kernel.org/patch/10386241/
> v2 - No changes - https://patchwork.kernel.org/patch/10384587/
>
> .../devicetree/bindings/leds/leds-lm3601x.txt | 47 +++++++++++++++++++
> 1 file changed, 47 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/leds/leds-lm3601x.txt
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 12/26] drm/sun4i: Add support for multiple DW HDMI PHY clock parents
From: Sergey Suloev @ 2018-05-18 15:09 UTC (permalink / raw)
To: Jernej Škrabec, Maxime Ripard
Cc: Mark Rutland, devicetree, David Airlie, Catalin Marinas,
Michael Turquette, linux-sunxi, Will Deacon, linux-kernel,
dri-devel, Stephen Boyd, Chen-Yu Tsai, Rob Herring, Jagan Teki,
Michael Trimarchi, linux-clk, linux-arm-kernel, Icenowy Zheng
In-Reply-To: <4909574.Q3IFWM0xt6@jernej-laptop>
Hi, guys,
On 05/18/2018 05:46 PM, Jernej Škrabec wrote:
> Hi,
>
> Dne petek, 18. maj 2018 ob 12:01:16 CEST je Maxime Ripard napisal(a):
>> On Fri, May 18, 2018 at 03:15:22PM +0530, Jagan Teki wrote:
>>> From: Jernej Skrabec <jernej.skrabec@siol.net>
>>>
>>> Some SoCs with DW HDMI have multiple possible clock parents, like A64
>>> and R40.
>>>
>>> Expand HDMI PHY clock driver to support second clock parent.
>>>
>>> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
>>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
>>> ---
>>> Changes for v2:
>>> - new patch
>>>
>>> drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 9 ++-
>>> drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 33 ++++++++---
>>> drivers/gpu/drm/sun4i/sun8i_hdmi_phy_clk.c | 89
>>> ++++++++++++++++++++++-------- 3 files changed, 96 insertions(+), 35
>>> deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
>>> b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h index 79154f0f674a..303189d6602c
>>> 100644
>>> --- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
>>> +++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
>>> @@ -98,7 +98,8 @@
>>>
>>> #define SUN8I_HDMI_PHY_PLL_CFG1_LDO2_EN BIT(29)
>>> #define SUN8I_HDMI_PHY_PLL_CFG1_LDO1_EN BIT(28)
>>> #define SUN8I_HDMI_PHY_PLL_CFG1_HV_IS_33 BIT(27)
>>>
>>> -#define SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL BIT(26)
>>> +#define SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL_MSK BIT(26)
>>> +#define SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL_SHIFT 26
>>>
>>> #define SUN8I_HDMI_PHY_PLL_CFG1_PLLEN BIT(25)
>>> #define SUN8I_HDMI_PHY_PLL_CFG1_LDO_VSET(x) ((x) << 22)
>>> #define SUN8I_HDMI_PHY_PLL_CFG1_UNKNOWN(x) ((x) << 20)
>>>
>>> @@ -146,7 +147,7 @@
>>>
>>> struct sun8i_hdmi_phy;
>>>
>>> struct sun8i_hdmi_phy_variant {
>>>
>>> - bool has_phy_clk;
>>> + int phy_clk_num;
>>>
>>> void (*phy_init)(struct sun8i_hdmi_phy *phy);
>>> void (*phy_disable)(struct dw_hdmi *hdmi,
>>>
>>> struct sun8i_hdmi_phy *phy);
>>>
>>> @@ -160,6 +161,7 @@ struct sun8i_hdmi_phy {
>>>
>>> struct clk *clk_mod;
>>> struct clk *clk_phy;
>>> struct clk *clk_pll0;
>>>
>>> + struct clk *clk_pll1;
>>>
>>> unsigned int rcal;
>>> struct regmap *regs;
>>> struct reset_control *rst_phy;
>>>
>>> @@ -188,6 +190,7 @@ void sun8i_hdmi_phy_remove(struct sun8i_dw_hdmi
>>> *hdmi);
>>>
>>> void sun8i_hdmi_phy_init(struct sun8i_hdmi_phy *phy);
>>> const struct dw_hdmi_phy_ops *sun8i_hdmi_phy_get_ops(void);
>>>
>>> -int sun8i_phy_clk_create(struct sun8i_hdmi_phy *phy, struct device *dev);
>>> +int sun8i_phy_clk_create(struct sun8i_hdmi_phy *phy, struct device *dev,
>>> + int clk_num);
>>>
>>> #endif /* _SUN8I_DW_HDMI_H_ */
>>>
>>> diff --git a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
>>> b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c index 5a52fc489a9d..0eadf087fc46
>>> 100644
>>> --- a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
>>> +++ b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
>>> @@ -183,7 +183,13 @@ static int sun8i_hdmi_phy_config_h3(struct dw_hdmi
>>> *hdmi,>
>>> regmap_update_bits(phy->regs, SUN8I_HDMI_PHY_ANA_CFG1_REG,
>>>
>>> SUN8I_HDMI_PHY_ANA_CFG1_TXEN_MASK, 0);
>>>
>>> - regmap_write(phy->regs, SUN8I_HDMI_PHY_PLL_CFG1_REG, pll_cfg1_init);
>>> + /*
>>> + * NOTE: We have to be careful not to overwrite PHY parent
>>> + * clock selection bit and clock divider.
>>> + */
>>> + regmap_update_bits(phy->regs, SUN8I_HDMI_PHY_PLL_CFG1_REG,
>>> + (u32)~SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL_MSK,
>>> + pll_cfg1_init);
>>>
>>> regmap_update_bits(phy->regs, SUN8I_HDMI_PHY_PLL_CFG2_REG,
>>>
>>> (u32)~SUN8I_HDMI_PHY_PLL_CFG2_PREDIV_MSK,
>>> pll_cfg2_init);
>>>
>>> @@ -232,7 +238,7 @@ static int sun8i_hdmi_phy_config(struct dw_hdmi *hdmi,
>>> void *data,>
>>> regmap_update_bits(phy->regs, SUN8I_HDMI_PHY_DBG_CTRL_REG,
>>>
>>> SUN8I_HDMI_PHY_DBG_CTRL_POL_MASK, val);
>>>
>>> - if (phy->variant->has_phy_clk)
>>> + if (phy->variant->phy_clk_num)
>>>
>>> clk_set_rate(phy->clk_phy, mode->crtc_clock * 1000);
>>>
>>> return phy->variant->phy_config(hdmi, phy, mode->crtc_clock * 1000);
>>>
>>> @@ -393,7 +399,7 @@ static const struct sun8i_hdmi_phy_variant
>>> sun8i_a83t_hdmi_phy = {>
>>> };
>>>
>>> static const struct sun8i_hdmi_phy_variant sun8i_h3_hdmi_phy = {
>>>
>>> - .has_phy_clk = true,
>>> + .phy_clk_num = 1,
>>>
>>> .phy_init = &sun8i_hdmi_phy_init_h3,
>>> .phy_disable = &sun8i_hdmi_phy_disable_h3,
>>> .phy_config = &sun8i_hdmi_phy_config_h3,
>>>
>>> @@ -464,7 +470,7 @@ int sun8i_hdmi_phy_probe(struct sun8i_dw_hdmi *hdmi,
>>> struct device_node *node)>
>>> goto err_put_clk_bus;
>>>
>>> }
>>>
>>> - if (phy->variant->has_phy_clk) {
>>> + if (phy->variant->phy_clk_num) {
>>>
>>> phy->clk_pll0 = of_clk_get_by_name(node, "pll-0");
>>> if (IS_ERR(phy->clk_pll0)) {
>>>
>>> dev_err(dev, "Could not get pll-0 clock\n");
>>>
>>> @@ -472,7 +478,16 @@ int sun8i_hdmi_phy_probe(struct sun8i_dw_hdmi *hdmi,
>>> struct device_node *node)>
>>> goto err_put_clk_mod;
>>>
>>> }
>>>
>>> - ret = sun8i_phy_clk_create(phy, dev);
>>> + if (phy->variant->phy_clk_num) {
>>> + phy->clk_pll1 = of_clk_get_by_name(node, "pll-1");
>>> + if (IS_ERR(phy->clk_pll1)) {
>>> + dev_err(dev, "Could not get pll-1 clock\n");
>>> + ret = PTR_ERR(phy->clk_pll1);
>>> + goto err_put_clk_mod;
>>> + }
>>> + }
>>> +
>> You have a bug here. If phy_clk_num == 1, you'll still try to lookup
>> pll-1.
> This is actually WIP patch taken from my github. This issue was fixed already
> locally on disk. I thought Jagan will not use it until SRAM C patches land.
>
>> And this is a bit sloppy, since if phy_clk_num == 3, you won't try to
>> lookup pll-2 either.
> It is highly unlikely this will be higher than 2, at least for this HDMI PHY,
> since it has only 1 bit reserved for parent selection. But since I have to fix
> it, I'll add ">= 2"
>
>>> + ret = sun8i_phy_clk_create(phy, dev, phy->variant->phy_clk_num);
>>>
>>> if (ret) {
>>>
>>> dev_err(dev, "Couldn't create the PHY clock\n");
>>> goto err_put_clk_pll0;
>>>
>>> @@ -515,8 +530,8 @@ int sun8i_hdmi_phy_probe(struct sun8i_dw_hdmi *hdmi,
>>> struct device_node *node)>
>>> err_put_rst_phy:
>>> reset_control_put(phy->rst_phy);
>>>
>>> err_put_clk_pll0:
>>> - if (phy->variant->has_phy_clk)
>>> - clk_put(phy->clk_pll0);
>>> + clk_put(phy->clk_pll0);
>>> + clk_put(phy->clk_pll1);
>>>
>>> err_put_clk_mod:
>>> clk_put(phy->clk_mod);
>>>
>>> err_put_clk_bus:
>>> @@ -536,8 +551,8 @@ void sun8i_hdmi_phy_remove(struct sun8i_dw_hdmi *hdmi)
>>>
>>> reset_control_put(phy->rst_phy);
>>>
>>> - if (phy->variant->has_phy_clk)
>>> - clk_put(phy->clk_pll0);
>>> + clk_put(phy->clk_pll0);
>>> + clk_put(phy->clk_pll1);
>>>
>>> clk_put(phy->clk_mod);
>>> clk_put(phy->clk_bus);
>>>
>>> }
>>>
>>> diff --git a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy_clk.c
>>> b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy_clk.c index
>>> faea449812f8..85b12fc96dbc 100644
>>> --- a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy_clk.c
>>> +++ b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy_clk.c
>>> @@ -22,29 +22,36 @@ static int sun8i_phy_clk_determine_rate(struct clk_hw
>>> *hw,>
>>> {
>>>
>>> unsigned long rate = req->rate;
>>> unsigned long best_rate = 0;
>>>
>>> - struct clk_hw *parent;
>>> + struct clk_hw *best_parent = NULL;
>>> + struct clk_hw *parent = NULL;
>>>
>>> int best_div = 1;
>>>
>>> - int i;
>>> + int i, p;
>>>
>>> - parent = clk_hw_get_parent(hw);
>>> -
>>> - for (i = 1; i <= 16; i++) {
>>> - unsigned long ideal = rate * i;
>>> - unsigned long rounded;
>>> -
>>> - rounded = clk_hw_round_rate(parent, ideal);
>>> -
>>> - if (rounded == ideal) {
>>> - best_rate = rounded;
>>> - best_div = i;
>>> - break;
>>> - }
>>> + for (p = 0; p < clk_hw_get_num_parents(hw); p++) {
>>> + parent = clk_hw_get_parent_by_index(hw, p);
>>> + if (!parent)
>>> + continue;
>>>
>>> - if (!best_rate ||
>>> - abs(rate - rounded / i) <
>>> - abs(rate - best_rate / best_div)) {
>>> - best_rate = rounded;
>>> - best_div = i;
>>> + for (i = 1; i <= 16; i++) {
>>> + unsigned long ideal = rate * i;
>>> + unsigned long rounded;
>>> +
>>> + rounded = clk_hw_round_rate(parent, ideal);
>>> +
>>> + if (rounded == ideal) {
>>> + best_rate = rounded;
>>> + best_div = i;
>>> + best_parent = parent;
>>> + break;
>>> + }
>>> +
>>> + if (!best_rate ||
>>> + abs(rate - rounded / i) <
>>> + abs(rate - best_rate / best_div)) {
>>> + best_rate = rounded;
>>> + best_div = i;
>>> + best_parent = parent;
>>> + }
>>>
>>> }
>>>
>>> }
>>>
>>> @@ -95,22 +102,58 @@ static int sun8i_phy_clk_set_rate(struct clk_hw *hw,
>>> unsigned long rate,>
>>> return 0;
>>>
>>> }
>>>
>>> +static u8 sun8i_phy_clk_get_parent(struct clk_hw *hw)
>>> +{
>>> + struct sun8i_phy_clk *priv = hw_to_phy_clk(hw);
>>> + u32 reg;
>>> +
>>> + regmap_read(priv->phy->regs, SUN8I_HDMI_PHY_PLL_CFG1_REG, ®);
>>> + reg = (reg & SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL_MSK) >>
>>> + SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL_SHIFT;
>>> +
>>> + return reg;
>>> +}
>>> +
>>> +static int sun8i_phy_clk_set_parent(struct clk_hw *hw, u8 index)
>>> +{
>>> + struct sun8i_phy_clk *priv = hw_to_phy_clk(hw);
>>> +
>>> + if (index > 1)
>>> + return -EINVAL;
>>> +
>>> + regmap_update_bits(priv->phy->regs, SUN8I_HDMI_PHY_PLL_CFG1_REG,
>>> + SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL_MSK,
>>> + index << SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL_SHIFT);
>>> +
>>> + return 0;
>>> +}
>>> +
>> The DT bindings changes and the clk changes should be part of separate
>> patches.
> By DT bindings changes you mean code which reads DT and not DT documentation,
> right?
>
> Ok, I'll split it.
>
> BTW, I'll resend fixed version of this patch for my R40 HDMI series, since
> there is nothing to hold it back, unlike for this.
>
> Best regards,
> Jernej
>
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
you have been talking about SRAM patches, required for A64 DE2, for
about a half a year.
May I ask you to explain in a couple of words why they are so important ?
I am really curious because I have DE2 already working on my A64 without
those magic patches..
Thanks,
Sergey
^ permalink raw reply
* Re: [PATCH 14/17] dt-bindings/interrupt-controller: add description for Marvell SEI node
From: Miquel Raynal @ 2018-05-18 14:48 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Rutland, Andrew Lunn, Jason Cooper, devicetree, Marc Zyngier,
Catalin Marinas, Gregory Clement, Haim Boot, Will Deacon,
Maxime Chevallier, Nadav Haklai, Antoine Tenart, Thomas Petazzoni,
Thomas Gleixner, Hanna Hawa,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Sebastian Hesselbarth
In-Reply-To: <CAL_JsqJ51riH+9Any7Bc6DN0Dx+WJdDAvOQ1gJCXTTUW0EUWsQ@mail.gmail.com>
Hi Rob,
On Mon, 30 Apr 2018 09:09:10 -0500, Rob Herring <robh@kernel.org> wrote:
> On Sat, Apr 28, 2018 at 5:48 AM, Miquel Raynal
> <miquel.raynal@bootlin.com> wrote:
> > Hi Rob,
> >
> > On Fri, 27 Apr 2018 15:50:32 -0500, Rob Herring <robh@kernel.org> wrote:
> >
> >> On Sat, Apr 21, 2018 at 03:55:34PM +0200, Miquel Raynal wrote:
> >> > Describe the SEI (System Error Interrupt) controller driver. The
> >> > controller is part of the GIC. It aggregates two types of interrupts,
> >> > wired and MSIs from respectively the AP and the CPs, into a single SPI
> >> > interrupt.
> >> >
> >> > Suggested-by: Haim Boot <hayim@marvell.com>
> >> > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> >> > ---
> >> > .../bindings/interrupt-controller/marvell,sei.txt | 54 ++++++++++++++++++++++
> >> > 1 file changed, 54 insertions(+)
> >> > create mode 100644 Documentation/devicetree/bindings/interrupt-controller/marvell,sei.txt
> >> >
> >> > diff --git a/Documentation/devicetree/bindings/interrupt-controller/marvell,sei.txt b/Documentation/devicetree/bindings/interrupt-controller/marvell,sei.txt
> >> > new file mode 100644
> >> > index 000000000000..a246d59552b1
> >> > --- /dev/null
> >> > +++ b/Documentation/devicetree/bindings/interrupt-controller/marvell,sei.txt
> >> > @@ -0,0 +1,54 @@
> >> > +Marvell SEI (System Error Interrupt) Controller
> >> > +-----------------------------------------------
> >> > +
> >> > +Marvell SEI (System Error Interrupt) controller is an interrupt aggregator.
> >> > +It receives interrupts from several sources and aggregates them to a single
> >> > +interrupt line (an SPI) on the primary interrupt controller.
> >> > +
> >> > +The IRQ chip can handle up to 64 SEIs, a set comes from the AP and is
> >> > +wired while a second set comes from the CPs by the mean of MSIs. Each
> >> > +'domain' is represented as a subnode.
> >> > +
> >> > +Required properties:
> >> > +
> >> > +- compatible: should be "marvell,armada-8k-sei".
> >> > +- reg: SEI registers location and length.
> >> > +- interrupts: identifies the parent IRQ that will be triggered.
> >> > +- #address-cells: should be '1', represents the position of the first
> >> > + IRQ of a given type in the SEI range.
> >> > +- #size-cells: should be '1', represents the number of a given type of
> >> > + IRQs.
> >> > +
> >> > +Child node 'sei-wired-controller' required properties:
> >> > +
> >> > +- reg: the range of wired interrupts.
> >> > +- #interrupt-cells: number of cells to define an SEI wired interrupt
> >> > + coming from the AP, should be 1. The cell is the IRQ
> >> > + number.
> >> > +- interrupt-controller: identifies the node as an interrupt controller.
> >> > +
> >> > +Child node 'sei-msi-controller' required properties:
> >> > +
> >> > +- reg: the range of non-wired interrupts triggered by way of MSIs.
> >> > +- msi-controller: identifies the node as an MSI controller.
> >> > +
> >> > +Example:
> >> > +
> >> > + sei: sei@3f0200 {
> >> > + compatible = "marvell,armada-8k-sei";
> >> > + reg = <0x3f0200 0x40>;
> >> > + interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>;
> >> > + #address-cells = <1>;
> >> > + #size-cells = <1>;
> >> > +
> >> > + sei_wired_controller: sei-wired-controller@0 {
> >> > + reg = <0 21>;
> >>
> >> Using interrupt numbers in reg is strange.
> >
> > I thought the reg property was the one to choose here, I can of course
> > change it, what would you suggest?
> >
> >>
> >> > + #interrupt-cells = <1>;
> >> > + interrupt-controller;
> >> > + };
> >> > +
> >> > + sei_msi_controller: sei-msi-controller@21 {
> >> > + reg = <21 43>;
> >> > + msi-controller;
> >>
> >> Can't the parent be both an interrupt-controller and msi-controller?
I would prefer to describe how the hardware is split in two
sub-controllers. And to answer the question: no, the parent cannot be
both and interrupt-controller and an msi-controller.
> >
> > We need to know which one aggregates interrupts, which one receives
> > MSIs and most importantly which interrupt is what (within the 64
> > that are handled by the SEI).
>
> You mean that 0-20 are wired and 21-63 are msi? "marvell,msi-base =
> <21>;" in the parent would be sufficient for that though you may want
> something more flexible to have multiple ranges.
Absolutely, I would like something more flexible.
>
> It looks like there may already be similar bindings. See
> 'msi-available-ranges" and "{al,arm},msi-base-spi".
If you are ok, I will use a new property named 'marvell,sei-ranges'
instead of the reg property which is indeed more explicit.
Thanks,
Miquèl
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v3 3/3] arm64: dts: renesas: draak: Describe HDMI input
From: Jacopo Mondi @ 2018-05-18 14:47 UTC (permalink / raw)
To: niklas.soderlund, laurent.pinchart, horms, geert, magnus.damm,
robh+dt
Cc: Jacopo Mondi, linux-renesas-soc, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <1526654878-11143-1-git-send-email-jacopo+renesas@jmondi.org>
Describe HDMI input connector and ADV7612 HDMI decoder installed on
R-Car Gen3 Draak board.
The video signal routing to the HDMI decoder to the video input interface
VIN4 is multiplexed with CVBS input path, and enabled/disabled through
on-board switches SW-49, SW-50, SW-51 and SW-52.
As the default board switches configuration connects CVBS input to VIN4,
leave the HDMI decoder unconnected in DTS.
Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
---
v2 -> v3:
- Add comment on HDMI output port about the shared CVBS/HDMI video path
- Add Niklas' R-b tag
---
arch/arm64/boot/dts/renesas/r8a77995-draak.dts | 48 ++++++++++++++++++++++++++
1 file changed, 48 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
index 95745fc..1e475a4 100644
--- a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
@@ -59,6 +59,17 @@
};
};
+ hdmi-in {
+ compatible = "hdmi-connector";
+ type = "a";
+
+ port {
+ hdmi_con_in: endpoint {
+ remote-endpoint = <&adv7612_in>;
+ };
+ };
+ };
+
memory@48000000 {
device_type = "memory";
/* first 128MB is reserved for secure area. */
@@ -176,6 +187,43 @@
};
};
};
+
+ hdmi-decoder@4c {
+ compatible = "adi,adv7612";
+ reg = <0x4c>;
+ default-input = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ adv7612_in: endpoint {
+ remote-endpoint = <&hdmi_con_in>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+
+ /*
+ * The VIN4 video input path is shared between
+ * CVBS and HDMI inputs through SW[49-54]
+ * switches.
+ *
+ * CVBS is the default selection, leave HDMI
+ * not connected here.
+ */
+ adv7612_out: endpoint {
+ pclk-sample = <0>;
+ hsync-active = <0>;
+ vsync-active = <0>;
+ };
+ };
+ };
+ };
};
&i2c1 {
--
2.7.4
^ permalink raw reply related
* [PATCH v3 2/3] arm64: dts: renesas: draak: Describe CVBS input
From: Jacopo Mondi @ 2018-05-18 14:47 UTC (permalink / raw)
To: niklas.soderlund, laurent.pinchart, horms, geert, magnus.damm,
robh+dt
Cc: Jacopo Mondi, linux-renesas-soc, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <1526654878-11143-1-git-send-email-jacopo+renesas@jmondi.org>
Describe CVBS video input through analog video decoder ADV7180
connected to video input interface VIN4.
The video input signal path is shared with HDMI video input, and
selected by on-board switches SW-53 and SW-54 with CVBS input selected
by the default switches configuration.
Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
---
v2 -> v3:
- Add comment to describe the shared input video path
- Add my SoB and Niklas' R-b tags
---
arch/arm64/boot/dts/renesas/r8a77995-draak.dts | 42 ++++++++++++++++++++++++++
1 file changed, 42 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
index 9d73de8..95745fc 100644
--- a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
@@ -142,6 +142,11 @@
groups = "usb0";
function = "usb0";
};
+
+ vin4_pins_cvbs: vin4 {
+ groups = "vin4_data8", "vin4_sync", "vin4_clk";
+ function = "vin4";
+ };
};
&i2c0 {
@@ -154,6 +159,23 @@
reg = <0x50>;
pagesize = <8>;
};
+
+ analog-video@20 {
+ compatible = "adi,adv7180";
+ reg = <0x20>;
+
+ port {
+ /*
+ * The VIN4 video input path is shared between
+ * CVBS and HDMI inputs through SW[49-54] switches.
+ *
+ * CVBS is the default selection, link it to VIN4 here.
+ */
+ adv7180_out: endpoint {
+ remote-endpoint = <&vin4_in>;
+ };
+ };
+ };
};
&i2c1 {
@@ -246,3 +268,23 @@
timeout-sec = <60>;
status = "okay";
};
+
+&vin4 {
+ pinctrl-0 = <&vin4_pins_cvbs>;
+ pinctrl-names = "default";
+
+ status = "okay";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ vin4_in: endpoint {
+ remote-endpoint = <&adv7180_out>;
+ };
+ };
+ };
+};
--
2.7.4
^ permalink raw reply related
* [PATCH v3 1/3] dt-bindings: media: rcar-vin: Add R8A77995 support
From: Jacopo Mondi @ 2018-05-18 14:47 UTC (permalink / raw)
To: niklas.soderlund, laurent.pinchart, horms, geert, magnus.damm,
robh+dt
Cc: Jacopo Mondi, linux-renesas-soc, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <1526654878-11143-1-git-send-email-jacopo+renesas@jmondi.org>
Add compatible string for R-Car D3 R8A7795 to list of SoCs supported by
rcar-vin driver.
Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
Acked-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
---
Documentation/devicetree/bindings/media/rcar_vin.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt b/Documentation/devicetree/bindings/media/rcar_vin.txt
index a19517e1..5c6f2a7 100644
--- a/Documentation/devicetree/bindings/media/rcar_vin.txt
+++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
@@ -22,6 +22,7 @@ on Gen3 platforms to a CSI-2 receiver.
- "renesas,vin-r8a7795" for the R8A7795 device
- "renesas,vin-r8a7796" for the R8A7796 device
- "renesas,vin-r8a77970" for the R8A77970 device
+ - "renesas,vin-r8a77995" for the R8A77995 device
- "renesas,rcar-gen2-vin" for a generic R-Car Gen2 or RZ/G1 compatible
device.
--
2.7.4
^ permalink raw reply related
* [PATCH v3 0/3] arm64: dts: Draak: Enable video inputs and VIN4
From: Jacopo Mondi @ 2018-05-18 14:47 UTC (permalink / raw)
To: niklas.soderlund, laurent.pinchart, horms, geert, magnus.damm,
robh+dt
Cc: Jacopo Mondi, linux-renesas-soc, devicetree, linux-arm-kernel,
linux-kernel
Hello,
this series enables HDMI, CVBS and VIN4 for R8A77995 Draak board.
Compared to v2, I have added review tags and a missing Signed-off-by line.
Two small comments added to Draak DTS to describe the shared video input path
between CVBS and HDMI. As in v2, CVBS is the default video input and thus is
connected to VIN in DTS.
Switching to HDMI is shown in the patch on top of the following branch:
git://jmondi.org/linux d3/media-master/salvator-x-dts_csi2/d3-hdmi
Simon: once the series this one depends on [1] has been accepted, I guess this
one is ready to get in, right?
The series has been developed on top of media-master tree but applies cleanly
on top of latest renesas-driver.
Thanks
j
[1] [PATCH v3 0/9] rcar-vin: Add support for parallel input on Gen3
v2 -> v3:
- Add comment to CVBS and HDMI inputs
- Add missing Signed-off-by to [2/3]
- Add Niklas' tag
Jacopo Mondi (3):
dt-bindings: media: rcar-vin: Add R8A77995 support
arm64: dts: renesas: draak: Describe CVBS input
arm64: dts: renesas: draak: Describe HDMI input
.../devicetree/bindings/media/rcar_vin.txt | 1 +
arch/arm64/boot/dts/renesas/r8a77995-draak.dts | 90 ++++++++++++++++++++++
2 files changed, 91 insertions(+)
--
2.7.4
^ permalink raw reply
* Re: [PATCH v2 12/26] drm/sun4i: Add support for multiple DW HDMI PHY clock parents
From: Jernej Škrabec @ 2018-05-18 14:46 UTC (permalink / raw)
To: Maxime Ripard
Cc: Jagan Teki, Chen-Yu Tsai, Icenowy Zheng, Rob Herring,
Mark Rutland, Catalin Marinas, Will Deacon, David Airlie,
dri-devel, Michael Turquette, Stephen Boyd, linux-clk,
Michael Trimarchi, linux-arm-kernel, devicetree, linux-kernel,
linux-sunxi
In-Reply-To: <20180518100116.4bf2qcffg7ekxa7u@flea>
Hi,
Dne petek, 18. maj 2018 ob 12:01:16 CEST je Maxime Ripard napisal(a):
> On Fri, May 18, 2018 at 03:15:22PM +0530, Jagan Teki wrote:
> > From: Jernej Skrabec <jernej.skrabec@siol.net>
> >
> > Some SoCs with DW HDMI have multiple possible clock parents, like A64
> > and R40.
> >
> > Expand HDMI PHY clock driver to support second clock parent.
> >
> > Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> > Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> > ---
> > Changes for v2:
> > - new patch
> >
> > drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 9 ++-
> > drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 33 ++++++++---
> > drivers/gpu/drm/sun4i/sun8i_hdmi_phy_clk.c | 89
> > ++++++++++++++++++++++-------- 3 files changed, 96 insertions(+), 35
> > deletions(-)
> >
> > diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
> > b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h index 79154f0f674a..303189d6602c
> > 100644
> > --- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
> > +++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
> > @@ -98,7 +98,8 @@
> >
> > #define SUN8I_HDMI_PHY_PLL_CFG1_LDO2_EN BIT(29)
> > #define SUN8I_HDMI_PHY_PLL_CFG1_LDO1_EN BIT(28)
> > #define SUN8I_HDMI_PHY_PLL_CFG1_HV_IS_33 BIT(27)
> >
> > -#define SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL BIT(26)
> > +#define SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL_MSK BIT(26)
> > +#define SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL_SHIFT 26
> >
> > #define SUN8I_HDMI_PHY_PLL_CFG1_PLLEN BIT(25)
> > #define SUN8I_HDMI_PHY_PLL_CFG1_LDO_VSET(x) ((x) << 22)
> > #define SUN8I_HDMI_PHY_PLL_CFG1_UNKNOWN(x) ((x) << 20)
> >
> > @@ -146,7 +147,7 @@
> >
> > struct sun8i_hdmi_phy;
> >
> > struct sun8i_hdmi_phy_variant {
> >
> > - bool has_phy_clk;
> > + int phy_clk_num;
> >
> > void (*phy_init)(struct sun8i_hdmi_phy *phy);
> > void (*phy_disable)(struct dw_hdmi *hdmi,
> >
> > struct sun8i_hdmi_phy *phy);
> >
> > @@ -160,6 +161,7 @@ struct sun8i_hdmi_phy {
> >
> > struct clk *clk_mod;
> > struct clk *clk_phy;
> > struct clk *clk_pll0;
> >
> > + struct clk *clk_pll1;
> >
> > unsigned int rcal;
> > struct regmap *regs;
> > struct reset_control *rst_phy;
> >
> > @@ -188,6 +190,7 @@ void sun8i_hdmi_phy_remove(struct sun8i_dw_hdmi
> > *hdmi);
> >
> > void sun8i_hdmi_phy_init(struct sun8i_hdmi_phy *phy);
> > const struct dw_hdmi_phy_ops *sun8i_hdmi_phy_get_ops(void);
> >
> > -int sun8i_phy_clk_create(struct sun8i_hdmi_phy *phy, struct device *dev);
> > +int sun8i_phy_clk_create(struct sun8i_hdmi_phy *phy, struct device *dev,
> > + int clk_num);
> >
> > #endif /* _SUN8I_DW_HDMI_H_ */
> >
> > diff --git a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
> > b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c index 5a52fc489a9d..0eadf087fc46
> > 100644
> > --- a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
> > +++ b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
> > @@ -183,7 +183,13 @@ static int sun8i_hdmi_phy_config_h3(struct dw_hdmi
> > *hdmi,>
> > regmap_update_bits(phy->regs, SUN8I_HDMI_PHY_ANA_CFG1_REG,
> >
> > SUN8I_HDMI_PHY_ANA_CFG1_TXEN_MASK, 0);
> >
> > - regmap_write(phy->regs, SUN8I_HDMI_PHY_PLL_CFG1_REG, pll_cfg1_init);
> > + /*
> > + * NOTE: We have to be careful not to overwrite PHY parent
> > + * clock selection bit and clock divider.
> > + */
> > + regmap_update_bits(phy->regs, SUN8I_HDMI_PHY_PLL_CFG1_REG,
> > + (u32)~SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL_MSK,
> > + pll_cfg1_init);
> >
> > regmap_update_bits(phy->regs, SUN8I_HDMI_PHY_PLL_CFG2_REG,
> >
> > (u32)~SUN8I_HDMI_PHY_PLL_CFG2_PREDIV_MSK,
> > pll_cfg2_init);
> >
> > @@ -232,7 +238,7 @@ static int sun8i_hdmi_phy_config(struct dw_hdmi *hdmi,
> > void *data,>
> > regmap_update_bits(phy->regs, SUN8I_HDMI_PHY_DBG_CTRL_REG,
> >
> > SUN8I_HDMI_PHY_DBG_CTRL_POL_MASK, val);
> >
> > - if (phy->variant->has_phy_clk)
> > + if (phy->variant->phy_clk_num)
> >
> > clk_set_rate(phy->clk_phy, mode->crtc_clock * 1000);
> >
> > return phy->variant->phy_config(hdmi, phy, mode->crtc_clock * 1000);
> >
> > @@ -393,7 +399,7 @@ static const struct sun8i_hdmi_phy_variant
> > sun8i_a83t_hdmi_phy = {>
> > };
> >
> > static const struct sun8i_hdmi_phy_variant sun8i_h3_hdmi_phy = {
> >
> > - .has_phy_clk = true,
> > + .phy_clk_num = 1,
> >
> > .phy_init = &sun8i_hdmi_phy_init_h3,
> > .phy_disable = &sun8i_hdmi_phy_disable_h3,
> > .phy_config = &sun8i_hdmi_phy_config_h3,
> >
> > @@ -464,7 +470,7 @@ int sun8i_hdmi_phy_probe(struct sun8i_dw_hdmi *hdmi,
> > struct device_node *node)>
> > goto err_put_clk_bus;
> >
> > }
> >
> > - if (phy->variant->has_phy_clk) {
> > + if (phy->variant->phy_clk_num) {
> >
> > phy->clk_pll0 = of_clk_get_by_name(node, "pll-0");
> > if (IS_ERR(phy->clk_pll0)) {
> >
> > dev_err(dev, "Could not get pll-0 clock\n");
> >
> > @@ -472,7 +478,16 @@ int sun8i_hdmi_phy_probe(struct sun8i_dw_hdmi *hdmi,
> > struct device_node *node)>
> > goto err_put_clk_mod;
> >
> > }
> >
> > - ret = sun8i_phy_clk_create(phy, dev);
> > + if (phy->variant->phy_clk_num) {
> > + phy->clk_pll1 = of_clk_get_by_name(node, "pll-1");
> > + if (IS_ERR(phy->clk_pll1)) {
> > + dev_err(dev, "Could not get pll-1 clock\n");
> > + ret = PTR_ERR(phy->clk_pll1);
> > + goto err_put_clk_mod;
> > + }
> > + }
> > +
>
> You have a bug here. If phy_clk_num == 1, you'll still try to lookup
> pll-1.
This is actually WIP patch taken from my github. This issue was fixed already
locally on disk. I thought Jagan will not use it until SRAM C patches land.
>
> And this is a bit sloppy, since if phy_clk_num == 3, you won't try to
> lookup pll-2 either.
It is highly unlikely this will be higher than 2, at least for this HDMI PHY,
since it has only 1 bit reserved for parent selection. But since I have to fix
it, I'll add ">= 2"
>
> > + ret = sun8i_phy_clk_create(phy, dev, phy->variant->phy_clk_num);
> >
> > if (ret) {
> >
> > dev_err(dev, "Couldn't create the PHY clock\n");
> > goto err_put_clk_pll0;
> >
> > @@ -515,8 +530,8 @@ int sun8i_hdmi_phy_probe(struct sun8i_dw_hdmi *hdmi,
> > struct device_node *node)>
> > err_put_rst_phy:
> > reset_control_put(phy->rst_phy);
> >
> > err_put_clk_pll0:
> > - if (phy->variant->has_phy_clk)
> > - clk_put(phy->clk_pll0);
> > + clk_put(phy->clk_pll0);
> > + clk_put(phy->clk_pll1);
> >
> > err_put_clk_mod:
> > clk_put(phy->clk_mod);
> >
> > err_put_clk_bus:
> > @@ -536,8 +551,8 @@ void sun8i_hdmi_phy_remove(struct sun8i_dw_hdmi *hdmi)
> >
> > reset_control_put(phy->rst_phy);
> >
> > - if (phy->variant->has_phy_clk)
> > - clk_put(phy->clk_pll0);
> > + clk_put(phy->clk_pll0);
> > + clk_put(phy->clk_pll1);
> >
> > clk_put(phy->clk_mod);
> > clk_put(phy->clk_bus);
> >
> > }
> >
> > diff --git a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy_clk.c
> > b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy_clk.c index
> > faea449812f8..85b12fc96dbc 100644
> > --- a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy_clk.c
> > +++ b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy_clk.c
> > @@ -22,29 +22,36 @@ static int sun8i_phy_clk_determine_rate(struct clk_hw
> > *hw,>
> > {
> >
> > unsigned long rate = req->rate;
> > unsigned long best_rate = 0;
> >
> > - struct clk_hw *parent;
> > + struct clk_hw *best_parent = NULL;
> > + struct clk_hw *parent = NULL;
> >
> > int best_div = 1;
> >
> > - int i;
> > + int i, p;
> >
> > - parent = clk_hw_get_parent(hw);
> > -
> > - for (i = 1; i <= 16; i++) {
> > - unsigned long ideal = rate * i;
> > - unsigned long rounded;
> > -
> > - rounded = clk_hw_round_rate(parent, ideal);
> > -
> > - if (rounded == ideal) {
> > - best_rate = rounded;
> > - best_div = i;
> > - break;
> > - }
> > + for (p = 0; p < clk_hw_get_num_parents(hw); p++) {
> > + parent = clk_hw_get_parent_by_index(hw, p);
> > + if (!parent)
> > + continue;
> >
> > - if (!best_rate ||
> > - abs(rate - rounded / i) <
> > - abs(rate - best_rate / best_div)) {
> > - best_rate = rounded;
> > - best_div = i;
> > + for (i = 1; i <= 16; i++) {
> > + unsigned long ideal = rate * i;
> > + unsigned long rounded;
> > +
> > + rounded = clk_hw_round_rate(parent, ideal);
> > +
> > + if (rounded == ideal) {
> > + best_rate = rounded;
> > + best_div = i;
> > + best_parent = parent;
> > + break;
> > + }
> > +
> > + if (!best_rate ||
> > + abs(rate - rounded / i) <
> > + abs(rate - best_rate / best_div)) {
> > + best_rate = rounded;
> > + best_div = i;
> > + best_parent = parent;
> > + }
> >
> > }
> >
> > }
> >
> > @@ -95,22 +102,58 @@ static int sun8i_phy_clk_set_rate(struct clk_hw *hw,
> > unsigned long rate,>
> > return 0;
> >
> > }
> >
> > +static u8 sun8i_phy_clk_get_parent(struct clk_hw *hw)
> > +{
> > + struct sun8i_phy_clk *priv = hw_to_phy_clk(hw);
> > + u32 reg;
> > +
> > + regmap_read(priv->phy->regs, SUN8I_HDMI_PHY_PLL_CFG1_REG, ®);
> > + reg = (reg & SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL_MSK) >>
> > + SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL_SHIFT;
> > +
> > + return reg;
> > +}
> > +
> > +static int sun8i_phy_clk_set_parent(struct clk_hw *hw, u8 index)
> > +{
> > + struct sun8i_phy_clk *priv = hw_to_phy_clk(hw);
> > +
> > + if (index > 1)
> > + return -EINVAL;
> > +
> > + regmap_update_bits(priv->phy->regs, SUN8I_HDMI_PHY_PLL_CFG1_REG,
> > + SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL_MSK,
> > + index << SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL_SHIFT);
> > +
> > + return 0;
> > +}
> > +
>
> The DT bindings changes and the clk changes should be part of separate
> patches.
By DT bindings changes you mean code which reads DT and not DT documentation,
right?
Ok, I'll split it.
BTW, I'll resend fixed version of this patch for my R40 HDMI series, since
there is nothing to hold it back, unlike for this.
Best regards,
Jernej
^ permalink raw reply
* Re: [PATCH v7 1/2] dt-bindings: Documentation for qcom, llcc
From: Rob Herring @ 2018-05-18 14:33 UTC (permalink / raw)
To: Rishabh Bhatnagar
Cc: linux-arm-kernel, linux-arm-msm, devicetree, linux-kernel,
linux-arm, tsoni, ckadabi, evgreen
In-Reply-To: <1526492623-20527-2-git-send-email-rishabhb@codeaurora.org>
On Wed, May 16, 2018 at 10:43:42AM -0700, Rishabh Bhatnagar wrote:
> Documentation for last level cache controller device tree bindings,
> client bindings usage examples.
>
> Signed-off-by: Channagoud Kadabi <ckadabi@codeaurora.org>
> Signed-off-by: Rishabh Bhatnagar <rishabhb@codeaurora.org>
> ---
> .../devicetree/bindings/arm/msm/qcom,llcc.txt | 26 ++++++++++++++++++++++
> 1 file changed, 26 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/msm/qcom,llcc.txt
Other than the node name discussed in v6,
Reviewed-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