* Re: [PATCH] of: overlay: Remove else after goto
From: Frank Rowand @ 2017-11-29 9:30 UTC (permalink / raw)
To: Geert Uytterhoeven, Rob Herring, Pantelis Antoniou
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1511857593-18574-1-git-send-email-geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
On 11/28/17 03:26, Geert Uytterhoeven wrote:
> If an "if" branch is terminated by a "goto", there's no need to have an
> "else" statement and an indented block of code.
>
> Remove the "else" statement to simplify the code flow for the casual
> reviewer.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
> ---
> drivers/of/overlay.c | 25 ++++++++++---------------
> 1 file changed, 10 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/of/overlay.c b/drivers/of/overlay.c
> index 8676411bd3e6f29f..53bc9e3f0b985415 100644
> --- a/drivers/of/overlay.c
> +++ b/drivers/of/overlay.c
> @@ -580,9 +580,9 @@ static int init_overlay_changeset(struct overlay_changeset *ovcs,
> of_node_put(fragment->overlay);
> ret = -EINVAL;
> goto err_free_fragments;
> - } else {
> - cnt++;
> }
> +
> + cnt++;
> }
> }
>
> @@ -736,14 +736,12 @@ int of_overlay_apply(struct device_node *tree, int *ovcs_id)
> devicetree_state_flags |= DTSF_APPLY_FAIL;
> }
> goto err_free_overlay_changeset;
> - } else {
> - ret = __of_changeset_apply_notify(&ovcs->cset);
> - if (ret)
> - pr_err("overlay changeset entry notify error %d\n",
> - ret);
> - /* fall through */
> }
>
> + ret = __of_changeset_apply_notify(&ovcs->cset);
> + if (ret)
> + pr_err("overlay changeset entry notify error %d\n", ret);
> +
The fall through comment was removed. It is important to document that we
are intentionally continuing despite the error.
> list_add_tail(&ovcs->ovcs_list, &ovcs_list);
> *ovcs_id = ovcs->id;
>
> @@ -931,15 +929,12 @@ int of_overlay_remove(int *ovcs_id)
> if (ret_apply)
> devicetree_state_flags |= DTSF_REVERT_FAIL;
> goto out_unlock;
> - } else {
> - ret = __of_changeset_revert_notify(&ovcs->cset);
> - if (ret) {
> - pr_err("overlay changeset entry notify error %d\n",
> - ret);
> - /* fall through - changeset was reverted */
> - }
> }
>
> + ret = __of_changeset_revert_notify(&ovcs->cset);
> + if (ret)
> + pr_err("overlay changeset entry notify error %d\n", ret);
> +
And same here.
> *ovcs_id = 0;
>
> ret_tmp = overlay_notify(ovcs, OF_OVERLAY_POST_REMOVE);
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC 1/2] of: overlay: add whitelist
From: Frank Rowand @ 2017-11-29 9:25 UTC (permalink / raw)
To: Alan Tull, Rob Herring
Cc: Pantelis Antoniou, Moritz Fischer, devicetree@vger.kernel.org,
linux-kernel, linux-fpga
In-Reply-To: <CANk1AXQ756EeKDDWXT5W6T8CJqqoFR7pGNkL5BGPN8gYBneRfw@mail.gmail.com>
On 11/28/17 14:26, Alan Tull wrote:
> On Tue, Nov 28, 2017 at 9:15 AM, Rob Herring <robh@kernel.org> wrote:
>> On Mon, Nov 27, 2017 at 02:58:03PM -0600, Alan Tull wrote:
>>> Add simple whitelist. When an overlay is submitted, if any target in
>>> the overlay is not in the whitelist, the overlay is rejected. Drivers
>>> that support dynamic configuration can register their device node with:
>>>
>>> int of_add_whitelist_node(struct device_node *np)
>>>
>>> and remove themselves with:
>>>
>>> void of_remove_whitelist_node(struct device_node *np)
>>
>> I think these should be named for what they do, not how it is
>> implemented.
>
> Sure, such as of_node_overlay_enable and of_node_overlay_disable?
of_allow_overlay_on_node(), of_disallow_overlay_on_node()?
>
>>
>>>
>>> Signed-off-by: Alan Tull <atull@kernel.org>
>>> ---
>>> drivers/of/overlay.c | 73 ++++++++++++++++++++++++++++++++++++++++++++++++++++
>>> include/linux/of.h | 12 +++++++++
>>> 2 files changed, 85 insertions(+)
>>>
>>> diff --git a/drivers/of/overlay.c b/drivers/of/overlay.c
>>> index c150abb..5f952a1 100644
>>> --- a/drivers/of/overlay.c
>>> +++ b/drivers/of/overlay.c
>>> @@ -21,6 +21,7 @@
>>> #include <linux/slab.h>
>>> #include <linux/err.h>
>>> #include <linux/idr.h>
>>> +#include <linux/spinlock.h>
>>>
>>> #include "of_private.h"
>>>
>>> @@ -646,6 +647,74 @@ static void free_overlay_changeset(struct overlay_changeset *ovcs)
>>> kfree(ovcs);
>>> }
>>>
>>> +/* lock for adding/removing device nodes to the whitelist */
>>> +static spinlock_t whitelist_lock;
>>> +
>>> +static struct list_head whitelist_list = LIST_HEAD_INIT(whitelist_list);
>>> +
>>> +struct dt_overlay_whitelist {
>>> + struct device_node *np;
>>> + struct list_head node;
>>> +};
>>
>> Can't we just add a flags bit in device_node.flags? That would be much
>> simpler.
>
> Yes, much simpler. Such as:
>
> #define OF_OVERLAY_ENABLED 5 /* allow DT overlay targeting this node */
>
>>
>>> +
>>> +int of_add_whitelist_node(struct device_node *np)
>>> +{
>>> + unsigned long flags;
>>> + struct dt_overlay_whitelist *wln;
>>> +
>>> + wln = kzalloc(sizeof(*wln), GFP_KERNEL);
>>> + if (!wln)
>>> + return -ENOMEM;
>>> +
>>> + wln->np = np;
>>> +
>>> + spin_lock_irqsave(&whitelist_lock, flags);
>>> + list_add(&wln->node, &whitelist_list);
>>> + spin_unlock_irqrestore(&whitelist_lock, flags);
>>> +
>>> + return 0;
>>> +}
>>> +EXPORT_SYMBOL_GPL(of_add_whitelist_node);
>>> +
>>> +void of_remove_whitelist_node(struct device_node *np)
>>> +{
>>> + struct dt_overlay_whitelist *wln;
>>> + unsigned long flags;
>>> +
>>> + list_for_each_entry(wln, &whitelist_list, node) {
>>> + if (np == wln->np) {
>>> + spin_lock_irqsave(&whitelist_lock, flags);
>>> + list_del(&wln->node);
>>> + spin_unlock_irqrestore(&whitelist_lock, flags);
>>> + kfree(wln);
>>> + return;
>>> + }
>>> + }
>>> +}
>>> +EXPORT_SYMBOL_GPL(of_remove_whitelist_node);
>>> +
>>> +static int of_check_whitelist(struct overlay_changeset *ovcs)
>>> +{
>>> + struct dt_overlay_whitelist *wln;
>>> + struct device_node *target;
>>> + int i;
>>> +
>>> + for (i = 0; i < ovcs->count; i++) {
>>> + target = ovcs->fragments[i].target;
>>> + if (!of_node_cmp(target->name, "__symbols__"))
>>> + continue;
>>> +
>>> + list_for_each_entry(wln, &whitelist_list, node)
>>> + if (target == wln->np)
>>> + break;
>>> +
>>> + if (target != wln->np)
>>> + return -ENODEV;
>>> + }
>>> +
>>> + return 0;
>>> +}
>>> +
>>> /**
>>> * of_overlay_apply() - Create and apply an overlay changeset
>>> * @tree: Expanded overlay device tree
>>> @@ -717,6 +786,10 @@ int of_overlay_apply(struct device_node *tree, int *ovcs_id)
>>> if (ret)
>>> goto err_free_overlay_changeset;
>>>
>>> + ret = of_check_whitelist(ovcs);
>>> + if (ret)
>>> + goto err_free_overlay_changeset;
>>
>> This will break you until the next patch and breaks any other users. I
>> think this is now just the unittest as tilcdc overlay is getting
>> removed.
>>
>> You have to make this chunk the last patch in the series.
>
> I'd rather squash the two patches. In either case, the contents of
> second patch are dependent on stuff in char-misc-testing today, so it
> won't be able to apply yet on linux-next or anywhere else.
>
> Thanks
> Alan
>
>>
>> Rob
>
^ permalink raw reply
* Re: [PATCH v2 25/35] nds32: Build infrastructure
From: Arnd Bergmann @ 2017-11-29 9:25 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Greentime Hu, Greentime, Linux Kernel Mailing List, linux-arch,
Thomas Gleixner, Jason Cooper, Marc Zyngier, Rob Herring,
Networking, Vincent Chen, DTML, Al Viro, David Howells,
Will Deacon, Daniel Lezcano, linux-serial@vger.kernel.org,
Vincent Chen
In-Reply-To: <CAMuHMdViO=+-kGdXFPSW+9PsPbf3sUa5xdaJ_1C-cX2vE1G35Q@mail.gmail.com>
On Wed, Nov 29, 2017 at 10:10 AM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> Hi Arnd,
>
> On Wed, Nov 29, 2017 at 9:58 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>> On Wed, Nov 29, 2017 at 9:39 AM, Greentime Hu <green.hu@gmail.com> wrote:
>>> 2017-11-27 22:21 GMT+08:00 Arnd Bergmann <arnd@arndb.de>:
>>>> On Mon, Nov 27, 2017 at 1:28 PM, Greentime Hu <green.hu@gmail.com> wrote:
>>>>> diff --git a/arch/nds32/Kconfig.cpu b/arch/nds32/Kconfig.cpu
>>>>> +config CPU_CACHE_NONALIASING
>>>>> + bool "Non-aliasing cache"
>>>>> + help
>>>>> + If this CPU is using VIPT data cache and its cache way size is larger
>>>>> + than page size, say N. If it is using PIPT data cache, say Y.
>>>>> +
>>>>> + If unsure, say Y.
>>>>
>>>> Can you determine this from the CPU type?
>>>
>>> There is no cpu register to determine it. It also depeneds on page
>>> size and way size however page size is configurable by software.
>>> These codes are determined at compile time will be benefit to code
>>> size and performance.
>>> IMHO, I think it would be better to be determined here.
>>
>> I meant determining it at compile time from other Kconfig symbols,
>> if that's possible. Do the CPU cores each have a fixed way-size?
>> If they do, it could be done like
>>
>> menu "CPU selection"
>>
>> config CPU_N15
>> bool "AndesCore N15"
>> select CPU_CACHE_NONALIASING
>>
>> config CPU_N13
>> bool "AndesCore N15"
>> select CPU_CACHE_NONALIASING if PAGE_SIZE_16K
>>
>> ...
>>
>> endmenu
>>
>> and then you can use the same CPU_... symbols to make other decisions
>> as well, e.g. CPU specific compiler optimizations.
>
> Do you want to support multiple CPU types in a single kernel image
> (I see no "choice" statement above)?
> If yes, you may have a mix of aliasing and non-aliasing caches, so
> you may want to invert the logic, and select CPU_CACHE_ALIASING
> instead.
Right, my mistake.
Arnd
^ permalink raw reply
* Re: [RFC 0/2] of: Add whitelist
From: Frank Rowand @ 2017-11-29 9:20 UTC (permalink / raw)
To: Alan Tull, Rob Herring, Pantelis Antoniou
Cc: Moritz Fischer, devicetree, linux-kernel, linux-fpga
In-Reply-To: <1511816284-12145-1-git-send-email-atull@kernel.org>
On 11/27/17 15:58, Alan Tull wrote:
> Here's a proposal for a whitelist to lock down the dynamic device tree.
>
> For an overlay to be accepted, all of its targets are required to be
> on a target node whitelist.
>
> Currently the only way I have to get on the whitelist is calling a
> function to add a node. That works for fpga regions, but I think
> other uses will need a way of having adding specific nodes from the
> base device tree, such as by adding a property like 'allow-overlay;'
> or 'allow-overlay = "okay";' If that is acceptable, I could use some
> advice on where that particular code should go.
>
> Alan
>
> Alan Tull (2):
> of: overlay: add whitelist
> fpga: of region: add of-fpga-region to whitelist
>
> drivers/fpga/of-fpga-region.c | 9 ++++++
> drivers/of/overlay.c | 73 +++++++++++++++++++++++++++++++++++++++++++
> include/linux/of.h | 12 +++++++
> 3 files changed, 94 insertions(+)
>
The plan was to use connectors to restrict where an overlay could be applied.
I would prefer not to have multiple methods for accomplishing the same thing
unless there is a compelling reason to do so.
-Frnank
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: pinctrl: add bindings for MediaTek MT7622 SoC
From: Sean Wang @ 2017-11-29 9:14 UTC (permalink / raw)
To: Rob Herring
Cc: mark.rutland, linus.walleij, matthias.bgg, devicetree,
linux-mediatek, linux-arm-kernel, linux-gpio, linux-kernel
In-Reply-To: <20171128152055.rfhfqi4ucp6bdxsf@rob-hp-laptop>
On Tue, 2017-11-28 at 09:20 -0600, Rob Herring wrote:
> On Tue, Nov 28, 2017 at 11:49:59AM +0800, sean.wang@mediatek.com wrote:
> > From: Sean Wang <sean.wang@mediatek.com>
> >
> > Add devicetree bindings for MediaTek MT7622 pinctrl driver.
> >
> > Signed-off-by: Sean Wang <sean.wang@mediatek.com>
> > ---
> > .../devicetree/bindings/pinctrl/pinctrl-mt7622.txt | 330 +++++++++++++++++++++
> > 1 file changed, 330 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/pinctrl/pinctrl-mt7622.txt
> >
> > diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt7622.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt7622.txt
> > new file mode 100644
> > index 0000000..ce86d45
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt7622.txt
> > @@ -0,0 +1,330 @@
> > +== MediaTek MT7622 pinctrl controller ==
> > +
> > +Required properties for the root node:
> > + - compatible: Should be one of the following
> > + "mediatek,mt7622-pinctrl" for MT7622 SoC
> > + - reg: offset and length of the pinctrl space
> > +
> > + - gpio-controller: Marks the device node as a GPIO controller.
> > + - #gpio-cells: Should be two. The first cell is the pin number and the
> > + second is the GPIO flags.
> > +
> > +Please refer to pinctrl-bindings.txt in this directory for details of the
> > +common pinctrl bindings used by client devices, including the meaning of the
> > +phrase "pin configuration node".
> > +
> > +MT7622 pin configuration nodes act as a container for an arbitrary number of
> > +subnodes. Each of these subnodes represents some desired configuration for a
> > +pin, a group, or a list of pins or groups. This configuration can include the
> > +mux function to select on those pin(s)/group(s), and various pin configuration
> > +parameters, such as pull-up, slew rate, etc.
> > +
> > +We support 2 types of configuration nodes. Those nodes can be either pinmux
> > +nodes or pinconf nodes. Each configuration node can consist of multiple nodes
> > +describing the pinmux and pinconf options.
> > +
> > +The name of each subnode is no matter as long as it is unique; all subnodes
>
> s/is no matter/doesn't matter/
>
will be fixed
> > +should be enumerated and processed purely based on their content.
> > +
> > +== pinmux nodes content ==
> > +
> > +The following generic properties as defined in pinctrl-bindings.txt are valid
> > +to specify in a pinmux subnode:
> > +
> > +Required properties are:
> > + - groups: An array of strings. Each string contains the name of a group.
> > + Valid values for these names are listed below.
> > + - function: A string containing the name of the function to mux to the
> > + group. Valid values for function names are listed below.
> > +
> > +== pinconf nodes content ==
> > +
> > +The following generic properties as defined in pinctrl-bindings.txt are valid
> > +to specify in a pinconf subnode:
> > +
> > +Required properties are:
> > + - pins: An array of strings. Each string contains the name of a pin.
> > + Valid values for these names are listed below.
> > + - groups: An array of strings. Each string contains the name of a group.
> > + Valid values for these names are listed below.
> > +
> > +Optional properies are:
> > + bias-disable, bias-pull, bias-pull-down, input-enable,
> > + input-schmitt-enable, input-schmitt-disable, output-enable
> > + output-low, output-high, drive-strength, slew-rate
> > +
> > + Valid arguments for 'slew-rate' are '0' and '1' to select between slow and
> > + fast respectively.
> > + Valid arguments for 'drive-strength', 4, 8, 12, or 16 in mA.
> > +
> > +The following specific properties as defined are valid to specify in a pinconf
> > +subnode:
> > +
> > +Optional properties are:
> > + - mediatek,tdsel: Valid arguments are from 0 to 15
> > + - mediatek,rdsel: Valid arguments are from 0 to 63
>
> What are these properties controlling?
>
okay. these properties will be extended as below
Optional properties are:
- mediatek,tdsel: An integer describing the steps for output level
shifter duty cycle when asserted (high pulse width adjustment). Valid
arguments are from 0 to 15.
- mediatek,rdsel: An integer describing the steps for input level
shifter duty cycle when asserted (high pulse width adjustment). Valid
arguments are from 0 to 63.
> > +
> > +== Valid values for pins, function and groups on MT7622 ==
> > +
> > +Valid values for pins are:
> > +pins can be referenced via the pin names as the below table shown and the
> > +related physical number is also put ahead of those names which helps cross
> > +references to pins between groups to know whether pins assignment conflict
> > +happens among devices try to acquire those available pins.
> > +
> > + Pin #: Valid values for pins
> > + -----------------------------
> > + PIN 0: "GPIO_A"
> > + PIN 1: "I2S1_IN"
> > + PIN 2: "I2S1_OUT"
> > + PIN 3: "I2S_BCLK"
> > + PIN 4: "I2S_WS"
> > + PIN 5: "I2S_MCLK"
> > + PIN 6: "TXD0"
> > + PIN 7: "RXD0"
> > + PIN 8: "SPI_WP"
> > + PIN 9: "SPI_HOLD"
> > + PIN 10: "SPI_CLK"
> > + PIN 11: "SPI_MOSI"
> > + PIN 12: "SPI_MISO"
> > + PIN 13: "SPI_CS"
> > + PIN 14: "SPI_SDA"
> > + PIN 15: "SPI_SCL"
> > + PIN 16: "I2S2_IN"
> > + PIN 17: "I2S3_IN"
> > + PIN 18: "I2S4_IN"
> > + PIN 19: "I2S2_OUT"
> > + PIN 20: "I2S3_OUT"
> > + PIN 21: "I2S4_OUT"
> > + PIN 22: "GPIO_B"
> > + PIN 23: "MDC"
> > + PIN 24: "MDIO"
> > + PIN 25: "G2_TXD0"
> > + PIN 26: "G2_TXD1"
> > + PIN 27: "G2_TXD2"
> > + PIN 28: "G2_TXD3"
> > + PIN 29: "G2_TXEN"
> > + PIN 30: "G2_TXC"
> > + PIN 31: "G2_RXD0"
> > + PIN 32: "G2_RXD1"
> > + PIN 33: "G2_RXD2"
> > + PIN 34: "G2_RXD3"
> > + PIN 35: "G2_RXDV"
> > + PIN 36: "G2_RXC"
> > + PIN 37: "NCEB"
> > + PIN 38: "NWEB"
> > + PIN 39: "NREB"
> > + PIN 40: "NDL4"
> > + PIN 41: "NDL5"
> > + PIN 42: "NDL6"
> > + PIN 43: "NDL7"
> > + PIN 44: "NRB"
> > + PIN 45: "NCLE"
> > + PIN 46: "NALE"
> > + PIN 47: "NDL0"
> > + PIN 48: "NDL1"
> > + PIN 49: "NDL2"
> > + PIN 50: "NDL3"
> > + PIN 51: "MDI_TP_P0"
> > + PIN 52: "MDI_TN_P0"
> > + PIN 53: "MDI_RP_P0"
> > + PIN 54: "MDI_RN_P0"
> > + PIN 55: "MDI_TP_P1"
> > + PIN 56: "MDI_TN_P1"
> > + PIN 57: "MDI_RP_P1"
> > + PIN 58: "MDI_RN_P1"
> > + PIN 59: "MDI_RP_P2"
> > + PIN 60: "MDI_RN_P2"
> > + PIN 61: "MDI_TP_P2"
> > + PIN 62: "MDI_TN_P2"
> > + PIN 63: "MDI_TP_P3"
> > + PIN 64: "MDI_TN_P3"
> > + PIN 65: "MDI_RP_P3"
> > + PIN 66: "MDI_RN_P3"
> > + PIN 67: "MDI_RP_P4"
> > + PIN 68: "MDI_RN_P4"
> > + PIN 69: "MDI_TP_P4"
> > + PIN 70: "MDI_TN_P4"
> > + PIN 71: "SPI2_CK"
> > + PIN 72: "SPI2_DATA"
> > + PIN 73: "SPIC1_CLK"
> > + PIN 74: "SPIC1_MOSI"
> > + PIN 75: "SPIC1_MISO"
> > + PIN 76: "SPIC1_CS"
> > + PIN 77: "GPIO_D"
> > + PIN 78: "WATCHDOG"
> > + PIN 79: "RTS3_N"
> > + PIN 80: "CTS3_N"
> > + PIN 81: "TXD3"
> > + PIN 82: "RXD3"
> > + PIN 83: "PERST0_N"
> > + PIN 84: "PERST1_N"
> > + PIN 85: "WLED_N"
> > + PIN 86: "EPHY_LED0_N"
> > + PIN 87: "AUXIN0"
> > + PIN 88: "AUXIN1"
> > + PIN 89: "AUXIN2"
> > + PIN 90: "AUXIN3"
> > + PIN 91: "TXD4"
> > + PIN 92: "RXD4"
> > + PIN 93: "RTS4_IN"
> > + PIN 94: "CST4_IN"
> > + PIN 95: "PWM1"
> > + PIN 96: "PWM2"
> > + PIN 97: "PWM3"
> > + PIN 98: "PWM4"
> > + PIN 99: "PWM5"
> > + PIN 100: "PWM6"
> > + PIN 101: "PWM7"
> > + PIN 102: "GPIO_E"
> > +
> > +Valid values for function are:
> > + "emmc", "eth", "i2c", "i2s", "ir", "led", "flash", "pcie",
> > + "pwm", "sd", "spi", "tdm", "uart"
> > +
> > +Valid values for groups are:
> > +additional data is put followingly with valid value allowing us to know which
> > +applicable function and which relevant pins (in pin#) are able applied for that
> > +group.
> > +
> > + Valid value function pins (in pin#)
> > + -------------------------------------------------------------------------
> > + "emmc" "emmc" 40, 41, 42, 43, 44, 45,
> > + 47, 48, 49, 50
> > + "esw" "eth" 59, 60, 61, 62, 63, 64,
> > + 65, 66, 67, 68, 69, 70
> > + "mdc_mdio" "eth" 23, 24
> > + "gmac1" "eth" 59, 60, 61, 62, 63, 64,
> > + 65, 66, 67, 68, 69, 70
> > + "gmac2" "eth" 25, 26, 27, 28, 29, 30,
> > + 31, 32, 33, 34, 35, 36
> > + "i2c0" "i2c" 14, 15
> > + "i2c1_0" "i2c" 55, 56
> > + "i2c1_1" "i2c" 73, 74
> > + "i2c1_2" "i2c" 87, 88
> > + "i2c2_0" "i2c" 57, 58
> > + "i2c2_1" "i2c" 75, 76
> > + "i2c2_2" "i2c" 89, 90
> > + "i2s_in_bclk_ws_mclk" "i2s" 3, 4, 5
> > + "i2s1_in_data" "i2s" 1
> > + "i2s2_in_data" "i2s" 16
> > + "i2s3_in_data" "i2s" 17
> > + "i2s4_in_data" "i2s" 18
> > + "i2s_out_bclk_ws_mclk" "i2s" 3, 4, 5
> > + "i2s1_out_data" "i2s" 2
> > + "i2s2_out_data" "i2s" 19
> > + "i2s3_out_data" "i2s" 20
> > + "i2s4_out_data" "i2s" 21
> > + "ir_0_tx" "ir" 16
> > + "ir_1_tx" "ir" 59
> > + "ir_2_tx" "ir" 99
> > + "ir_0_rx" "ir" 17
> > + "ir_1_rx" "ir" 60
> > + "ir_2_rx" "ir" 100
> > + "ephy0_led" "led" 86
> > + "ephy1_led" "led" 91
> > + "ephy2_led" "led" 92
> > + "ephy3_led" "led" 93
> > + "ephy4_led" "led" 94
> > + "wled" "led" 85
> > + "par_nand" "flash" 37, 38, 39, 40, 41, 42,
> > + 43, 44, 45, 46, 47, 48,
> > + 49, 50
> > + "snfi" "flash" 8, 9, 10, 11, 12, 13
> > + "spi_nor" "flash" 8, 9, 10, 11, 12, 13
> > + "pcie0_0_waken_clkreq" "pcie" 14, 15
> > + "pcie0_1_waken_clkreq" "pcie" 79, 80
> > + "pcie1_0_waken_clkreq" "pcie" 14, 15
> > + "pcie0_pad_perst" "pcie" 83
> > + "pcie1_pad_perst" "pcie" 84
> > + "pwm_ch1_0" "pwm" 51
> > + "pwm_ch1_1" "pwm" 73
> > + "pwm_ch1_2" "pwm" 95
> > + "pwm_ch2_0" "pwm" 52
> > + "pwm_ch2_1" "pwm" 74
> > + "pwm_ch2_2" "pwm" 96
> > + "pwm_ch3_0" "pwm" 53
> > + "pwm_ch3_1" "pwm" 75
> > + "pwm_ch3_2" "pwm" 97
> > + "pwm_ch4_0" "pwm" 54
> > + "pwm_ch4_1" "pwm" 67
> > + "pwm_ch4_2" "pwm" 76
> > + "pwm_ch4_3" "pwm" 98
> > + "pwm_ch5_0" "pwm" 68
> > + "pwm_ch5_1" "pwm" 77
> > + "pwm_ch5_2" "pwm" 99
> > + "pwm_ch6_0" "pwm" 69
> > + "pwm_ch6_1" "pwm" 78
> > + "pwm_ch6_2" "pwm" 81
> > + "pwm_ch6_3" "pwm" 100
> > + "pwm_ch7_0" "pwm" 70
> > + "pwm_ch7_1" "pwm" 82
> > + "pwm_ch7_2" "pwm" 101
>
> Mixed space and tabs.
>
will be fixed
> > + "sd_0" "sd" 16, 17, 18, 19, 20, 21
> > + "sd_1" "sd" 25, 26, 27, 28, 29, 30
> > + "spic0_0" "spi" 63, 64, 65, 66
> > + "spic0_1" "spi" 79, 80, 81, 82
> > + "spic1_0" "spi" 67, 68, 69, 70
> > + "spic1_1" "spi" 73, 74, 75, 76
> > + "tdm_0_out_mclk_bclk" "tdm" 8, 9, 10
> > + "tdm_0_in_mclk_bclk_ws" "tdm" 11, 12, 13
> > + "tdm_0_out_data" "tdm" 20
> > + "tdm_0_in_data" "tdm" 21
> > + "tdm_1_out_mclk_bclk" "tdm" 57, 58, 59
> > + "tdm_1_in_mclk_bclk_ws" "tdm" 60, 61, 62
> > + "tdm_1_out_data" "tdm" 55
> > + "tdm_1_in_data" "tdm" 56
> > + "uart0_0_tx_rx" "uart" 6, 7
> > + "uart1_0_tx_rx" "uart" 55, 56
> > + "uart1_0_rts_cts" "uart" 57, 58
> > + "uart1_1_tx_rx" "uart" 73, 74
> > + "uart1_1_rts_cts" "uart" 75, 76
> > + "uart2_0_tx_rx" "uart" 3, 4
> > + "uart2_0_rts_cts" "uart" 1, 2
> > + "uart2_1_tx_rx" "uart" 51, 52
> > + "uart2_1_rts_cts" "uart" 53, 54
> > + "uart2_2_tx_rx" "uart" 59, 60
> > + "uart2_2_rts_cts" "uart" 61, 62
> > + "uart2_3_tx_rx" "uart" 95, 96
> > + "uart3_0_tx_rx" "uart" 57, 58
> > + "uart3_1_tx_rx" "uart" 81, 82
> > + "uart3_1_rts_cts" "uart" 79, 80
> > + "uart4_0_tx_rx" "uart" 61, 62
> > + "uart4_1_tx_rx" "uart" 91, 92
> > + "uart4_1_rts_cts" "uart" 93, 94
> > + "uart4_2_tx_rx" "uart" 97, 98
> > + "uart4_2_rts_cts" "uart" 95, 96
> > +
> > +Example:
> > +
> > + pio: pinctrl@10211000 {
> > + compatible = "mediatek,mt7622-pinctrl";
> > + reg = <0 0x10211000 0 0x1000>;
> > + gpio-controller;
> > + #gpio-cells = <2>;
> > +
> > + pinctrl_eth_default: eth-default {
> > + mux_mdio {
>
> s/_/-/
>
will be fixed
> > + groups = "mdc_mdio";
> > + function = "eth";
> > + drive-strength = <12>;
> > + };
> > +
> > + mux_gmac2 {
>
> ditto
>
will be fixed
> > + groups = "gmac2";
> > + function = "eth";
> > + drive-strength = <12>;
> > + };
> > +
> > + mux_esw {
will be fixed
> > + groups = "esw";
> > + function = "eth";
> > + drive-strength = <8>;
> > + };
> > +
> > + conf_mdio {
will be fixed
> > + pins = "MDC";
> > + bias-pull-up;
> > + };
> > + };
> > + };
> > --
> > 2.7.4
> >
>
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: eeprom: rename to at24.txt
From: Geert Uytterhoeven @ 2017-11-29 9:11 UTC (permalink / raw)
To: Wolfram Sang
Cc: Linux I2C, Bartosz Golaszewski, Geert Uytterhoeven, Rob Herring,
Mark Rutland, devicetree@vger.kernel.org
In-Reply-To: <20171129090442.2865-2-wsa@the-dreams.de>
CC devicetree
On Wed, Nov 29, 2017 at 10:04 AM, Wolfram Sang <wsa@the-dreams.de> wrote:
> This binding documentation is for the at24 driver, so the filename
> should reflect it. This avoids confusion because we also have an
> "eeprom" driver in Linux but it doesn't support DT even.
>
> Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
> ---
> Documentation/devicetree/bindings/eeprom/{eeprom.txt => at24.txt} | 0
> 1 file changed, 0 insertions(+), 0 deletions(-)
> rename Documentation/devicetree/bindings/eeprom/{eeprom.txt => at24.txt} (100%)
>
> diff --git a/Documentation/devicetree/bindings/eeprom/eeprom.txt b/Documentation/devicetree/bindings/eeprom/at24.txt
> similarity index 100%
> rename from Documentation/devicetree/bindings/eeprom/eeprom.txt
> rename to Documentation/devicetree/bindings/eeprom/at24.txt
Gr{oetje,eeting}s,
Geert
^ permalink raw reply
* Re: [PATCH v2 25/35] nds32: Build infrastructure
From: Geert Uytterhoeven @ 2017-11-29 9:10 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Greentime Hu, Greentime, Linux Kernel Mailing List, linux-arch,
Thomas Gleixner, Jason Cooper, Marc Zyngier, Rob Herring,
Networking, Vincent Chen, DTML, Al Viro, David Howells,
Will Deacon, Daniel Lezcano, linux-serial@vger.kernel.org,
Vincent Chen
In-Reply-To: <CAK8P3a0kvt52UTtEmE+tWHZuH_rmgTxP7+CiD9Ddwe2cJLwXTQ@mail.gmail.com>
Hi Arnd,
On Wed, Nov 29, 2017 at 9:58 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Wed, Nov 29, 2017 at 9:39 AM, Greentime Hu <green.hu@gmail.com> wrote:
>> 2017-11-27 22:21 GMT+08:00 Arnd Bergmann <arnd@arndb.de>:
>>> On Mon, Nov 27, 2017 at 1:28 PM, Greentime Hu <green.hu@gmail.com> wrote:
>>>> diff --git a/arch/nds32/Kconfig.cpu b/arch/nds32/Kconfig.cpu
>>>> +config CPU_CACHE_NONALIASING
>>>> + bool "Non-aliasing cache"
>>>> + help
>>>> + If this CPU is using VIPT data cache and its cache way size is larger
>>>> + than page size, say N. If it is using PIPT data cache, say Y.
>>>> +
>>>> + If unsure, say Y.
>>>
>>> Can you determine this from the CPU type?
>>
>> There is no cpu register to determine it. It also depeneds on page
>> size and way size however page size is configurable by software.
>> These codes are determined at compile time will be benefit to code
>> size and performance.
>> IMHO, I think it would be better to be determined here.
>
> I meant determining it at compile time from other Kconfig symbols,
> if that's possible. Do the CPU cores each have a fixed way-size?
> If they do, it could be done like
>
> menu "CPU selection"
>
> config CPU_N15
> bool "AndesCore N15"
> select CPU_CACHE_NONALIASING
>
> config CPU_N13
> bool "AndesCore N15"
> select CPU_CACHE_NONALIASING if PAGE_SIZE_16K
>
> ...
>
> endmenu
>
> and then you can use the same CPU_... symbols to make other decisions
> as well, e.g. CPU specific compiler optimizations.
Do you want to support multiple CPU types in a single kernel image
(I see no "choice" statement above)?
If yes, you may have a mix of aliasing and non-aliasing caches, so
you may want to invert the logic, and select CPU_CACHE_ALIASING
instead.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v2 25/35] nds32: Build infrastructure
From: Arnd Bergmann @ 2017-11-29 8:58 UTC (permalink / raw)
To: Greentime Hu
Cc: Greentime, Linux Kernel Mailing List, linux-arch, Thomas Gleixner,
Jason Cooper, Marc Zyngier, Rob Herring, Networking, Vincent Chen,
DTML, Al Viro, David Howells, Will Deacon, Daniel Lezcano,
linux-serial, Vincent Chen
In-Reply-To: <CAEbi=3c=hTCcUOPs+Fc10srzTFsB4MnVxgcFydz12-jH0ZXjog@mail.gmail.com>
On Wed, Nov 29, 2017 at 9:39 AM, Greentime Hu <green.hu@gmail.com> wrote:
> 2017-11-27 22:21 GMT+08:00 Arnd Bergmann <arnd@arndb.de>:
>> On Mon, Nov 27, 2017 at 1:28 PM, Greentime Hu <green.hu@gmail.com> wrote:
>>> diff --git a/arch/nds32/Kconfig.cpu b/arch/nds32/Kconfig.cpu
>>> +config CPU_CACHE_NONALIASING
>>> + bool "Non-aliasing cache"
>>> + help
>>> + If this CPU is using VIPT data cache and its cache way size is larger
>>> + than page size, say N. If it is using PIPT data cache, say Y.
>>> +
>>> + If unsure, say Y.
>>
>> Can you determine this from the CPU type?
>
> There is no cpu register to determine it. It also depeneds on page
> size and way size however page size is configurable by software.
> These codes are determined at compile time will be benefit to code
> size and performance.
> IMHO, I think it would be better to be determined here.
I meant determining it at compile time from other Kconfig symbols,
if that's possible. Do the CPU cores each have a fixed way-size?
If they do, it could be done like
menu "CPU selection"
config CPU_N15
bool "AndesCore N15"
select CPU_CACHE_NONALIASING
config CPU_N13
bool "AndesCore N15"
select CPU_CACHE_NONALIASING if PAGE_SIZE_16K
...
endmenu
and then you can use the same CPU_... symbols to make other decisions
as well, e.g. CPU specific compiler optimizations.
Arnd
^ permalink raw reply
* [PATCH 2/2] usb: mtu3: remove unused micros
From: Chunfeng Yun @ 2017-11-29 8:49 UTC (permalink / raw)
To: Greg Kroah-Hartman, Felipe Balbi
Cc: Matthias Brugger, Chunfeng Yun, linux-kernel, linux-arm-kernel,
linux-usb, linux-mediatek, devicetree
In-Reply-To: <120299c8a516acfd5b52cb1528b929b3eae5cd53.1511943941.git.chunfeng.yun@mediatek.com>
Remove unused micros of UWK_CTL1_IDDIG_*
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
---
drivers/usb/mtu3/mtu3_host.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/usb/mtu3/mtu3_host.c b/drivers/usb/mtu3/mtu3_host.c
index d237d7e..7e948c0 100644
--- a/drivers/usb/mtu3/mtu3_host.c
+++ b/drivers/usb/mtu3/mtu3_host.c
@@ -21,9 +21,6 @@
#define PERI_WK_CTRL1 0x404
#define UWK_CTL1_IS_C(x) (((x) & 0xf) << 26)
#define UWK_CTL1_IS_E BIT(25)
-#define UWK_CTL1_IDDIG_C(x) (((x) & 0xf) << 11) /* cycle debounce */
-#define UWK_CTL1_IDDIG_E BIT(10) /* enable debounce */
-#define UWK_CTL1_IDDIG_P BIT(9) /* polarity */
#define UWK_CTL1_IS_P BIT(6) /* polarity for ip sleep */
/*
--
1.9.1
^ permalink raw reply related
* [PATCH 1/2] usb: mtu3: fix error code for getting extcon device
From: Chunfeng Yun @ 2017-11-29 8:49 UTC (permalink / raw)
To: Greg Kroah-Hartman, Felipe Balbi
Cc: Matthias Brugger, Chunfeng Yun, linux-kernel, linux-arm-kernel,
linux-usb, linux-mediatek, devicetree
When failing to get extcon device, extcon_get_edev_by_phandle()
may return different error codes, but not only -EPROBE_DEFER,
so can't always return -EPROBE_DEFER, and fix it.
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
---
drivers/usb/mtu3/mtu3_plat.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/mtu3/mtu3_plat.c b/drivers/usb/mtu3/mtu3_plat.c
index 3650fd1..5b2110b 100644
--- a/drivers/usb/mtu3/mtu3_plat.c
+++ b/drivers/usb/mtu3/mtu3_plat.c
@@ -308,7 +308,7 @@ static int get_ssusb_rscs(struct platform_device *pdev, struct ssusb_mtk *ssusb)
otg_sx->edev = extcon_get_edev_by_phandle(ssusb->dev, 0);
if (IS_ERR(otg_sx->edev)) {
dev_err(ssusb->dev, "couldn't get extcon device\n");
- return -EPROBE_DEFER;
+ return PTR_ERR(otg_sx->edev);
}
}
--
1.9.1
^ permalink raw reply related
* Re: [PATCH v2 25/35] nds32: Build infrastructure
From: Greentime Hu @ 2017-11-29 8:39 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Greentime, Linux Kernel Mailing List, linux-arch, Thomas Gleixner,
Jason Cooper, Marc Zyngier, Rob Herring, Networking, Vincent Chen,
DTML, Al Viro, David Howells, Will Deacon, Daniel Lezcano,
linux-serial, Vincent Chen
In-Reply-To: <CAK8P3a1GuH2tgtC5t834-PNeUVYQxreD7seZH8sjraZFtRUWKw@mail.gmail.com>
2017-11-27 22:21 GMT+08:00 Arnd Bergmann <arnd@arndb.de>:
> On Mon, Nov 27, 2017 at 1:28 PM, Greentime Hu <green.hu@gmail.com> wrote:
>
>> diff --git a/arch/nds32/Kconfig.cpu b/arch/nds32/Kconfig.cpu
>> new file mode 100644
>> index 0000000..6b4013f
>> --- /dev/null
>> +++ b/arch/nds32/Kconfig.cpu
>> @@ -0,0 +1,131 @@
>> +comment "Processor Features"
>> +
>> +config CPU_BIG_ENDIAN
>> + bool "Big endian"
>> + def_bool n
>> +
>> +config CPU_LITTLE_ENDIAN
>> + bool "Little endian"
>> + def_bool y
>
> These must be mutually exclusive, you surely get some build error if you try to
> set both here.
>
> You can either make it a 'choice' statement to pick between the two, or you
> can make CPU_LITTLE_ENDIAN a silent option like
>
> config CPU_BIG_ENDIAN
> bool "Big endian"
>
> config CPU_LITTLE_ENDIAN
> def_bool !CPU_BIG_ENDIAN
>
Thanks. I will fix it in the next version patch.
>> +config CPU_CACHE_NONALIASING
>> + bool "Non-aliasing cache"
>> + help
>> + If this CPU is using VIPT data cache and its cache way size is larger
>> + than page size, say N. If it is using PIPT data cache, say Y.
>> +
>> + If unsure, say Y.
>
> Can you determine this from the CPU type?
There is no cpu register to determine it. It also depeneds on page
size and way size however page size is configurable by software.
These codes are determined at compile time will be benefit to code
size and performance.
IMHO, I think it would be better to be determined here.
>> +choice
>> + prompt "Memory split"
>> + depends on MMU
>> + default VMSPLIT_3G
>> + help
>> + Select the desired split between kernel and user memory.
>> +
>> + If you are not absolutely sure what you are doing, leave this
>> + option alone!
>> +
>> + config VMSPLIT_3G
>> + bool "3G/1G user/kernel split"
>> + config VMSPLIT_3G_OPT
>> + bool "3G/1G user/kernel split (for full 1G low memory)"
>> + config VMSPLIT_2G
>> + bool "2G/2G user/kernel split"
>> + config VMSPLIT_1G
>> + bool "1G/3G user/kernel split"
>> +endchoice
>
> I think you mentioned that the 1GB configuration is quite common, how
> about making VMSPLIT_3G_OPT the default here?
We use 1GB in our fpga platform, but I am not sure our customer's
config and their user space program may use bigger memory space.
Anyway, we will discuss it to decide the default value.
Thanks for your suggestion.
^ permalink raw reply
* Re: [PATCH v2 04/11] media: rkisp1: add Rockchip MIPI Synopsys DPHY driver
From: Jacob Chen @ 2017-11-29 8:38 UTC (permalink / raw)
To: Jose Abreu
Cc: Hans Verkuil, open list:ARM/Rockchip SoC..., linux-kernel,
linux-arm-kernel, Mauro Carvalho Chehab, Linux Media Mailing List,
Sakari Ailus, Hans Verkuil, Tomasz Figa, Shunqian Zheng,
Laurent Pinchart, 钟以崇, Eddie Cai, Jeffy Chen,
Allon Huang, devicetree, Heiko Stuebner, robh+dt, Joao Pinto
In-Reply-To: <66926554-86b2-1ae4-2ff2-e11ac254762e@synopsys.com>
Hi Hans,
2017-11-27 22:15 GMT+08:00 Jose Abreu <Jose.Abreu@synopsys.com>:
> ++ Joao, ++ Luis
>
> Hi Hans,
>
> We will take a look into this. Thanks for pointing this out!
>
> Best Regards,
> Jose Miguel Abreu
>
> On 27-11-2017 12:01, Hans Verkuil wrote:
>> I'm CC-ing Jose Abreu from Synopsys to this. Jose, can you or a colleague take
>> a look at this as well?
>>
>> Jacob, I have some high-level questions first:
>>
>> 1) to what extend is this code rockchip-specific as opposed to be more synopsys-generic?
See below.
>>
>> 2) I don't quite see how this works when there are two sensors. Is only one active at a
>> time? Or are they multiplexed somehow?
>>
For one mipi-rx-phy and one isp, only one sensor is active at a
time(selected by enabled media-link).
For example, a tablet with a front sensor and a rear sensor.
>> 3) Same as for the previous patch: some more comments would be welcome.
>>
>> On 11/24/2017 03:36 AM, Jacob Chen wrote:
>>> From: Jacob Chen <jacob2.chen@rock-chips.com>
>>>
>>> This commit adds a subdev driver for Rockchip MIPI Synopsys DPHY driver.
>>>
>>> The phy driver is kind of independent compare to the other parts, but i'd like
>>> to keep it in rkisp1 driver, unless people want to generalize it
>>>
>>> Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>
>>> Signed-off-by: Shunqian Zheng <zhengsq@rock-chips.com>
>>> Signed-off-by: Tomasz Figa <tfiga@chromium.org>
>>> ---
>>> drivers/media/platform/rockchip/isp1/Makefile | 1 +
>>> .../media/platform/rockchip/isp1/mipi_dphy_sy.c | 805 +++++++++++++++++++++
>>> 2 files changed, 806 insertions(+)
>>> create mode 100644 drivers/media/platform/rockchip/isp1/mipi_dphy_sy.c
>>>
>>> diff --git a/drivers/media/platform/rockchip/isp1/Makefile b/drivers/media/platform/rockchip/isp1/Makefile
>>> index 8f52f959398e..18af64853734 100644
>>> --- a/drivers/media/platform/rockchip/isp1/Makefile
>>> +++ b/drivers/media/platform/rockchip/isp1/Makefile
>>> @@ -4,4 +4,5 @@ video_rkisp1-objs += rkisp1.o \
>>> regs.o \
>>> isp_stats.o \
>>> isp_params.o \
>>> + mipi_dphy_sy.o \
>>> capture.o
>>> diff --git a/drivers/media/platform/rockchip/isp1/mipi_dphy_sy.c b/drivers/media/platform/rockchip/isp1/mipi_dphy_sy.c
>>> new file mode 100644
>>> index 000000000000..56deff2be6fd
>>> --- /dev/null
>>> +++ b/drivers/media/platform/rockchip/isp1/mipi_dphy_sy.c
>>> @@ -0,0 +1,805 @@
>>> +/*
>>> + * Rockchip MIPI Synopsys DPHY driver
>>> + *
>>> + * Copyright (C) 2017 Fuzhou Rockchip Electronics Co., Ltd.
>>> + *
>>> + * This software is available to you under a choice of one of two
>>> + * licenses. You may choose to be licensed under the terms of the GNU
>>> + * General Public License (GPL) Version 2, available from the file
>>> + * COPYING in the main directory of this source tree, or the
>>> + * OpenIB.org BSD license below:
>>> + *
>>> + * Redistribution and use in source and binary forms, with or
>>> + * without modification, are permitted provided that the following
>>> + * conditions are met:
>>> + *
>>> + * - Redistributions of source code must retain the above
>>> + * copyright notice, this list of conditions and the following
>>> + * disclaimer.
>>> + *
>>> + * - Redistributions in binary form must reproduce the above
>>> + * copyright notice, this list of conditions and the following
>>> + * disclaimer in the documentation and/or other materials
>>> + * provided with the distribution.
>>> + *
>>> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
>>> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
>>> + * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
>>> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
>>> + * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
>>> + * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
>>> + * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
>>> + * SOFTWARE.
>>> + */
>>> +
>>> +#include <linux/clk.h>
>>> +#include <linux/delay.h>
>>> +#include <linux/module.h>
>>> +#include <linux/of.h>
>>> +#include <linux/of_platform.h>
>>> +#include <linux/platform_device.h>
>>> +#include <linux/pm_runtime.h>
>>> +#include <linux/regmap.h>
>>> +#include <linux/mfd/syscon.h>
>>> +#include <media/media-entity.h>
>>> +#include <media/v4l2-ctrls.h>
>>> +#include <media/v4l2-fwnode.h>
>>> +#include <media/v4l2-subdev.h>
>>> +
>>> +#define RK3288_GRF_SOC_CON6 0x025c
>>> +#define RK3288_GRF_SOC_CON8 0x0264
>>> +#define RK3288_GRF_SOC_CON9 0x0268
>>> +#define RK3288_GRF_SOC_CON10 0x026c
>>> +#define RK3288_GRF_SOC_CON14 0x027c
>>> +#define RK3288_GRF_SOC_STATUS21 0x02d4
>>> +#define RK3288_GRF_IO_VSEL 0x0380
>>> +#define RK3288_GRF_SOC_CON15 0x03a4
>>> +
>>> +#define RK3399_GRF_SOC_CON9 0x6224
>>> +#define RK3399_GRF_SOC_CON21 0x6254
>>> +#define RK3399_GRF_SOC_CON22 0x6258
>>> +#define RK3399_GRF_SOC_CON23 0x625c
>>> +#define RK3399_GRF_SOC_CON24 0x6260
>>> +#define RK3399_GRF_SOC_CON25 0x6264
>>> +#define RK3399_GRF_SOC_STATUS1 0xe2a4
>>> +
>>> +#define CLOCK_LANE_HS_RX_CONTROL 0x34
>>> +#define LANE0_HS_RX_CONTROL 0x44
>>> +#define LANE1_HS_RX_CONTROL 0x54
>>> +#define LANE2_HS_RX_CONTROL 0x84
>>> +#define LANE3_HS_RX_CONTROL 0x94
>>> +#define HS_RX_DATA_LANES_THS_SETTLE__CONTROL 0x75
>>> +
>>> +#define HIWORD_UPDATE(val, mask, shift) \
>>> + ((val) << (shift) | (mask) << ((shift) + 16))
>>> +
>>> +enum mipi_dphy_sy_pads {
>>> + MIPI_DPHY_SY_PAD_SINK = 0,
>>> + MIPI_DPHY_SY_PAD_SOURCE,
>>> + MIPI_DPHY_SY_PADS_NUM,
>>> +};
>>> +
>>> +enum dphy_reg_id {
>>> + GRF_DPHY_RX0_TURNDISABLE = 0,
>>> + GRF_DPHY_RX0_FORCERXMODE,
>>> + GRF_DPHY_RX0_FORCETXSTOPMODE,
>>> + GRF_DPHY_RX0_ENABLE,
>>> + GRF_DPHY_RX0_TESTCLR,
>>> + GRF_DPHY_RX0_TESTCLK,
>>> + GRF_DPHY_RX0_TESTEN,
>>> + GRF_DPHY_RX0_TESTDIN,
>>> + GRF_DPHY_RX0_TURNREQUEST,
>>> + GRF_DPHY_RX0_TESTDOUT,
>>> + GRF_DPHY_TX0_TURNDISABLE,
>>> + GRF_DPHY_TX0_FORCERXMODE,
>>> + GRF_DPHY_TX0_FORCETXSTOPMODE,
>>> + GRF_DPHY_TX0_TURNREQUEST,
>>> + GRF_DPHY_TX1RX1_TURNDISABLE,
>>> + GRF_DPHY_TX1RX1_FORCERXMODE,
>>> + GRF_DPHY_TX1RX1_FORCETXSTOPMODE,
>>> + GRF_DPHY_TX1RX1_ENABLE,
>>> + GRF_DPHY_TX1RX1_MASTERSLAVEZ,
>>> + GRF_DPHY_TX1RX1_BASEDIR,
>>> + GRF_DPHY_TX1RX1_ENABLECLK,
>>> + GRF_DPHY_TX1RX1_TURNREQUEST,
>>> + GRF_DPHY_RX1_SRC_SEL,
>>> + /* rk3288 only */
>>> + GRF_CON_DISABLE_ISP,
>>> + GRF_CON_ISP_DPHY_SEL,
>>> + GRF_DSI_CSI_TESTBUS_SEL,
>>> + GRF_DVP_V18SEL,
>>> + /* below is for rk3399 only */
>>> + GRF_DPHY_RX0_CLK_INV_SEL,
>>> + GRF_DPHY_RX1_CLK_INV_SEL,
>>> +};
>>> +
>>> +struct dphy_reg {
>>> + u32 offset;
>>> + u32 mask;
>>> + u32 shift;
>>> +};
>>> +
>>> +#define PHY_REG(_offset, _width, _shift) \
>>> + { .offset = _offset, .mask = BIT(_width) - 1, .shift = _shift, }
>>> +
>>> +static const struct dphy_reg rk3399_grf_dphy_regs[] = {
>>> + [GRF_DPHY_RX0_TURNREQUEST] = PHY_REG(RK3399_GRF_SOC_CON9, 4, 0),
>>> + [GRF_DPHY_RX0_CLK_INV_SEL] = PHY_REG(RK3399_GRF_SOC_CON9, 1, 10),
>>> + [GRF_DPHY_RX1_CLK_INV_SEL] = PHY_REG(RK3399_GRF_SOC_CON9, 1, 11),
>>> + [GRF_DPHY_RX0_ENABLE] = PHY_REG(RK3399_GRF_SOC_CON21, 4, 0),
>>> + [GRF_DPHY_RX0_FORCERXMODE] = PHY_REG(RK3399_GRF_SOC_CON21, 4, 4),
>>> + [GRF_DPHY_RX0_FORCETXSTOPMODE] = PHY_REG(RK3399_GRF_SOC_CON21, 4, 8),
>>> + [GRF_DPHY_RX0_TURNDISABLE] = PHY_REG(RK3399_GRF_SOC_CON21, 4, 12),
>>> + [GRF_DPHY_TX0_FORCERXMODE] = PHY_REG(RK3399_GRF_SOC_CON22, 4, 0),
>>> + [GRF_DPHY_TX0_FORCETXSTOPMODE] = PHY_REG(RK3399_GRF_SOC_CON22, 4, 4),
>>> + [GRF_DPHY_TX0_TURNDISABLE] = PHY_REG(RK3399_GRF_SOC_CON22, 4, 8),
>>> + [GRF_DPHY_TX0_TURNREQUEST] = PHY_REG(RK3399_GRF_SOC_CON22, 4, 12),
>>> + [GRF_DPHY_TX1RX1_ENABLE] = PHY_REG(RK3399_GRF_SOC_CON23, 4, 0),
>>> + [GRF_DPHY_TX1RX1_FORCERXMODE] = PHY_REG(RK3399_GRF_SOC_CON23, 4, 4),
>>> + [GRF_DPHY_TX1RX1_FORCETXSTOPMODE] = PHY_REG(RK3399_GRF_SOC_CON23, 4, 8),
>>> + [GRF_DPHY_TX1RX1_TURNDISABLE] = PHY_REG(RK3399_GRF_SOC_CON23, 4, 12),
>>> + [GRF_DPHY_TX1RX1_TURNREQUEST] = PHY_REG(RK3399_GRF_SOC_CON24, 4, 0),
>>> + [GRF_DPHY_RX1_SRC_SEL] = PHY_REG(RK3399_GRF_SOC_CON24, 1, 4),
>>> + [GRF_DPHY_TX1RX1_BASEDIR] = PHY_REG(RK3399_GRF_SOC_CON24, 1, 5),
>>> + [GRF_DPHY_TX1RX1_ENABLECLK] = PHY_REG(RK3399_GRF_SOC_CON24, 1, 6),
>>> + [GRF_DPHY_TX1RX1_MASTERSLAVEZ] = PHY_REG(RK3399_GRF_SOC_CON24, 1, 7),
>>> + [GRF_DPHY_RX0_TESTDIN] = PHY_REG(RK3399_GRF_SOC_CON25, 8, 0),
>>> + [GRF_DPHY_RX0_TESTEN] = PHY_REG(RK3399_GRF_SOC_CON25, 1, 8),
>>> + [GRF_DPHY_RX0_TESTCLK] = PHY_REG(RK3399_GRF_SOC_CON25, 1, 9),
>>> + [GRF_DPHY_RX0_TESTCLR] = PHY_REG(RK3399_GRF_SOC_CON25, 1, 10),
>>> + [GRF_DPHY_RX0_TESTDOUT] = PHY_REG(RK3399_GRF_SOC_STATUS1, 8, 0),
>>> +};
>>> +
>>> +static const struct dphy_reg rk3288_grf_dphy_regs[] = {
>>> + [GRF_CON_DISABLE_ISP] = PHY_REG(RK3288_GRF_SOC_CON6, 1, 0),
>>> + [GRF_CON_ISP_DPHY_SEL] = PHY_REG(RK3288_GRF_SOC_CON6, 1, 1),
>>> + [GRF_DSI_CSI_TESTBUS_SEL] = PHY_REG(RK3288_GRF_SOC_CON6, 1, 14),
>>> + [GRF_DPHY_TX0_TURNDISABLE] = PHY_REG(RK3288_GRF_SOC_CON8, 4, 0),
>>> + [GRF_DPHY_TX0_FORCERXMODE] = PHY_REG(RK3288_GRF_SOC_CON8, 4, 4),
>>> + [GRF_DPHY_TX0_FORCETXSTOPMODE] = PHY_REG(RK3288_GRF_SOC_CON8, 4, 8),
>>> + [GRF_DPHY_TX1RX1_TURNDISABLE] = PHY_REG(RK3288_GRF_SOC_CON9, 4, 0),
>>> + [GRF_DPHY_TX1RX1_FORCERXMODE] = PHY_REG(RK3288_GRF_SOC_CON9, 4, 4),
>>> + [GRF_DPHY_TX1RX1_FORCETXSTOPMODE] = PHY_REG(RK3288_GRF_SOC_CON9, 4, 8),
>>> + [GRF_DPHY_TX1RX1_ENABLE] = PHY_REG(RK3288_GRF_SOC_CON9, 4, 12),
>>> + [GRF_DPHY_RX0_TURNDISABLE] = PHY_REG(RK3288_GRF_SOC_CON10, 4, 0),
>>> + [GRF_DPHY_RX0_FORCERXMODE] = PHY_REG(RK3288_GRF_SOC_CON10, 4, 4),
>>> + [GRF_DPHY_RX0_FORCETXSTOPMODE] = PHY_REG(RK3288_GRF_SOC_CON10, 4, 8),
>>> + [GRF_DPHY_RX0_ENABLE] = PHY_REG(RK3288_GRF_SOC_CON10, 4, 12),
>>> + [GRF_DPHY_RX0_TESTCLR] = PHY_REG(RK3288_GRF_SOC_CON14, 1, 0),
>>> + [GRF_DPHY_RX0_TESTCLK] = PHY_REG(RK3288_GRF_SOC_CON14, 1, 1),
>>> + [GRF_DPHY_RX0_TESTEN] = PHY_REG(RK3288_GRF_SOC_CON14, 1, 2),
>>> + [GRF_DPHY_RX0_TESTDIN] = PHY_REG(RK3288_GRF_SOC_CON14, 8, 3),
>>> + [GRF_DPHY_TX1RX1_ENABLECLK] = PHY_REG(RK3288_GRF_SOC_CON14, 1, 12),
>>> + [GRF_DPHY_RX1_SRC_SEL] = PHY_REG(RK3288_GRF_SOC_CON14, 1, 13),
>>> + [GRF_DPHY_TX1RX1_MASTERSLAVEZ] = PHY_REG(RK3288_GRF_SOC_CON14, 1, 14),
>>> + [GRF_DPHY_TX1RX1_BASEDIR] = PHY_REG(RK3288_GRF_SOC_CON14, 1, 15),
>>> + [GRF_DPHY_RX0_TURNREQUEST] = PHY_REG(RK3288_GRF_SOC_CON15, 4, 0),
>>> + [GRF_DPHY_TX1RX1_TURNREQUEST] = PHY_REG(RK3288_GRF_SOC_CON15, 4, 4),
>>> + [GRF_DPHY_TX0_TURNREQUEST] = PHY_REG(RK3288_GRF_SOC_CON15, 3, 8),
>>> + [GRF_DVP_V18SEL] = PHY_REG(RK3288_GRF_IO_VSEL, 1, 1),
>>> + [GRF_DPHY_RX0_TESTDOUT] = PHY_REG(RK3288_GRF_SOC_STATUS21, 8, 0),
>>> +};
>>> +
>>> +struct hsfreq_range {
>>> + u32 range_h;
>>> + u8 cfg_bit;
>>> +};
>>> +
>>> +struct dphy_drv_data {
>>> + const char * const *clks;
>>> + int num_clks;
>>> + const struct hsfreq_range *hsfreq_ranges;
>>> + int num_hsfreq_ranges;
>>> + const struct dphy_reg *regs;
>>> +};
>>> +
>>> +struct sensor_async_subdev {
>>> + struct v4l2_async_subdev asd;
>>> + struct v4l2_mbus_config mbus;
>>> + int lanes;
>>> +};
>>> +
>>> +#define MAX_DPHY_CLK 8
>>> +#define MAX_DPHY_SENSORS 2
>>> +
>>> +struct mipidphy_sensor {
>>> + struct v4l2_subdev *sd;
>>> + struct v4l2_mbus_config mbus;
>>> + int lanes;
>>> +};
>>> +
>>> +struct mipidphy_priv {
>>> + struct device *dev;
>>> + struct regmap *regmap_grf;
>>> + const struct dphy_reg *grf_regs;
>>> + struct clk *clks[MAX_DPHY_CLK];
>>> + const struct dphy_drv_data *drv_data;
>>> + u64 data_rate_mbps;
>>> + struct v4l2_async_notifier notifier;
>>> + struct v4l2_subdev sd;
>>> + struct media_pad pads[MIPI_DPHY_SY_PADS_NUM];
>>> + struct mipidphy_sensor sensors[MAX_DPHY_SENSORS];
>>> + int num_sensors;
>>> + bool is_streaming;
>>> +};
>>> +
>>> +static inline struct mipidphy_priv *to_dphy_priv(struct v4l2_subdev *subdev)
>>> +{
>>> + return container_of(subdev, struct mipidphy_priv, sd);
>>> +}
>>> +
>>> +static inline void write_reg(struct mipidphy_priv *priv, int index, u8 value)
>>> +{
>>> + const struct dphy_reg *reg = &priv->grf_regs[index];
>>> + unsigned int val = HIWORD_UPDATE(value, reg->mask, reg->shift);
>>> +
>>> + WARN_ON(!reg->offset);
>>> + regmap_write(priv->regmap_grf, reg->offset, val);
>>> +}
>>> +
>>> +static void mipidphy_wr_reg(struct mipidphy_priv *priv,
>>> + u8 test_code, u8 test_data)
>>> +{
>>> + /*
>>> + * With the falling edge on TESTCLK, the TESTDIN[7:0] signal content
>>> + * is latched internally as the current test code. Test data is
>>> + * programmed internally by rising edge on TESTCLK.
>>> + */
>>> + write_reg(priv, GRF_DPHY_RX0_TESTCLK, 1);
>>> + write_reg(priv, GRF_DPHY_RX0_TESTDIN, test_code);
>>> + write_reg(priv, GRF_DPHY_RX0_TESTEN, 1);
>>> + write_reg(priv, GRF_DPHY_RX0_TESTCLK, 0);
>>> + write_reg(priv, GRF_DPHY_RX0_TESTEN, 0);
>>> + write_reg(priv, GRF_DPHY_RX0_TESTDIN, test_data);
>>> + write_reg(priv, GRF_DPHY_RX0_TESTCLK, 1);
>>> +}
>>> +
It's rockchip spefic, since MIPI-DPHY-RX0 in rockchip SOC write phy
reg through grf.
The other phy, like MIPI-DPHY-TXRX0 in rockchip SOC, write phy reg like this:
https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/rockchip/dw-mipi-dsi.c#L388
>>> +static struct v4l2_subdev *get_remote_sensor(struct v4l2_subdev *sd)
>>> +{
>>> + struct media_pad *local, *remote;
>>> + struct media_entity *sensor_me;
>>> +
>>> + local = &sd->entity.pads[MIPI_DPHY_SY_PAD_SINK];
>>> + remote = media_entity_remote_pad(local);
>>> + if (!remote) {
>>> + v4l2_warn(sd, "No link between dphy and sensor\n");
>>> + return NULL;
>>> + }
>>> +
>>> + sensor_me = media_entity_remote_pad(local)->entity;
>>> + return media_entity_to_v4l2_subdev(sensor_me);
>>> +}
>>> +
>>> +static struct mipidphy_sensor *sd_to_sensor(struct mipidphy_priv *priv,
>>> + struct v4l2_subdev *sd)
>>> +{
>>> + int i;
>>> +
>>> + for (i = 0; i < priv->num_sensors; ++i)
>>> + if (priv->sensors[i].sd == sd)
>>> + return &priv->sensors[i];
>>> +
>>> + return NULL;
>>> +}
>>> +
>>> +static int mipidphy_get_sensor_data_rate(struct v4l2_subdev *sd)
>>> +{
>>> + struct mipidphy_priv *priv = to_dphy_priv(sd);
>>> + struct v4l2_subdev *sensor_sd = get_remote_sensor(sd);
>>> + struct v4l2_ctrl *link_freq;
>>> + struct v4l2_querymenu qm = { .id = V4L2_CID_LINK_FREQ, };
>>> + int ret;
>>> +
>>> + link_freq = v4l2_ctrl_find(sensor_sd->ctrl_handler, V4L2_CID_LINK_FREQ);
>>> + if (!link_freq) {
>>> + v4l2_warn(sd, "No pixel rate control in subdev\n");
>>> + return -EPIPE;
>>> + }
>>> +
>>> + qm.index = v4l2_ctrl_g_ctrl(link_freq);
>>> + ret = v4l2_querymenu(sensor_sd->ctrl_handler, &qm);
>>> + if (ret < 0) {
>>> + v4l2_err(sd, "Failed to get menu item\n");
>>> + return ret;
>>> + }
>>> +
>>> + if (!qm.value) {
>>> + v4l2_err(sd, "Invalid link_freq\n");
>>> + return -EINVAL;
>>> + }
>>> + priv->data_rate_mbps = qm.value * 2;
>>> + do_div(priv->data_rate_mbps, 1000 * 1000);
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +static int mipidphy_s_stream_start(struct v4l2_subdev *sd)
>>> +{
>>> + struct mipidphy_priv *priv = to_dphy_priv(sd);
>>> + const struct dphy_drv_data *drv_data = priv->drv_data;
>>> + const struct hsfreq_range *hsfreq_ranges = drv_data->hsfreq_ranges;
>>> + int num_hsfreq_ranges = drv_data->num_hsfreq_ranges;
>>> + struct v4l2_subdev *sensor_sd = get_remote_sensor(sd);
>>> + struct mipidphy_sensor *sensor = sd_to_sensor(priv, sensor_sd);
>>> + int i, ret, hsfreq = 0;
>>> +
>>> + if (priv->is_streaming)
>>> + return 0;
>>> +
>>> + ret = mipidphy_get_sensor_data_rate(sd);
>>> + if (ret < 0)
>>> + return ret;
>>> +
>>> + for (i = 0; i < num_hsfreq_ranges; i++) {
>>> + if (hsfreq_ranges[i].range_h >= priv->data_rate_mbps) {
>>> + hsfreq = hsfreq_ranges[i].cfg_bit;
>>> + break;
>>> + }
>>> + }
>>> +
>>> + write_reg(priv, GRF_DPHY_RX0_FORCERXMODE, 0);
>>> + write_reg(priv, GRF_DPHY_RX0_FORCETXSTOPMODE, 0);
>>> + /* Disable lan turn around, which is ignored in receive mode */
>>> + write_reg(priv, GRF_DPHY_RX0_TURNREQUEST, 0);
>>> + write_reg(priv, GRF_DPHY_RX0_TURNDISABLE, 0xf);
>>> +
>>> + write_reg(priv, GRF_DPHY_RX0_ENABLE, GENMASK(sensor->lanes - 1, 0));
>>> +
>>> + /* dphy start */
>>> + write_reg(priv, GRF_DPHY_RX0_TESTCLK, 1);
>>> + write_reg(priv, GRF_DPHY_RX0_TESTCLR, 1);
>>> + usleep_range(100, 150);
>>> + write_reg(priv, GRF_DPHY_RX0_TESTCLR, 0);
>>> + usleep_range(100, 150);
>>> +
>>> + /* set clock lane */
>>> + /* HS hsfreq_range & lane 0 settle bypass */
>>> + mipidphy_wr_reg(priv, CLOCK_LANE_HS_RX_CONTROL, 0);
>>> + /* HS RX Control of lane0 */
>>> + mipidphy_wr_reg(priv, LANE0_HS_RX_CONTROL, hsfreq << 1);
>>> + /* HS RX Control of lane1 */
>>> + mipidphy_wr_reg(priv, LANE1_HS_RX_CONTROL, 0);
>>> + /* HS RX Control of lane2 */
>>> + mipidphy_wr_reg(priv, LANE2_HS_RX_CONTROL, 0);
>>> + /* HS RX Control of lane3 */
>>> + mipidphy_wr_reg(priv, LANE3_HS_RX_CONTROL, 0);
>>> + /* HS RX Data Lanes Settle State Time Control */
>>> + mipidphy_wr_reg(priv, HS_RX_DATA_LANES_THS_SETTLE__CONTROL, 0x04);
>>> +
>>> + /* Normal operation */
>>> + mipidphy_wr_reg(priv, 0x0, 0);
>>> +
Those phy reg operations might be synopsys-generic.
>>> + priv->is_streaming = true;
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +static int mipidphy_s_stream_stop(struct v4l2_subdev *sd)
>>> +{
>>> + struct mipidphy_priv *priv = to_dphy_priv(sd);
>>> +
>>> + if (!priv->is_streaming)
>>> + return 0;
>>> +
>>> + priv->is_streaming = false;
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +static int mipidphy_s_stream(struct v4l2_subdev *sd, int on)
>>> +{
>>> + if (on)
>>> + return mipidphy_s_stream_start(sd);
>>> + else
>>> + return mipidphy_s_stream_stop(sd);
>>> +}
>>> +
>>> +static int mipidphy_g_mbus_config(struct v4l2_subdev *sd,
>>> + struct v4l2_mbus_config *config)
>>> +{
>>> + struct mipidphy_priv *priv = to_dphy_priv(sd);
>>> + struct v4l2_subdev *sensor_sd = get_remote_sensor(sd);
>>> + struct mipidphy_sensor *sensor = sd_to_sensor(priv, sensor_sd);
>>> +
>>> + *config = sensor->mbus;
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +static int mipidphy_s_power(struct v4l2_subdev *sd, int on)
>>> +{
>>> + struct mipidphy_priv *priv = to_dphy_priv(sd);
>>> +
>>> + if (on)
>>> + return pm_runtime_get_sync(priv->dev);
>>> + else
>>> + return pm_runtime_put(priv->dev);
>>> +}
>>> +
>>> +static int mipidphy_runtime_suspend(struct device *dev)
>>> +{
>>> + struct media_entity *me = dev_get_drvdata(dev);
>>> + struct v4l2_subdev *sd = media_entity_to_v4l2_subdev(me);
>>> + struct mipidphy_priv *priv = to_dphy_priv(sd);
>>> + int i, num_clks;
>>> +
>>> + num_clks = priv->drv_data->num_clks;
>>> + for (i = num_clks - 1; i >= 0; i--)
>>> + clk_disable_unprepare(priv->clks[i]);
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +static int mipidphy_runtime_resume(struct device *dev)
>>> +{
>>> + struct media_entity *me = dev_get_drvdata(dev);
>>> + struct v4l2_subdev *sd = media_entity_to_v4l2_subdev(me);
>>> + struct mipidphy_priv *priv = to_dphy_priv(sd);
>>> + int i, num_clks, ret;
>>> +
>>> + num_clks = priv->drv_data->num_clks;
>>> + for (i = 0; i < num_clks; i++) {
>>> + ret = clk_prepare_enable(priv->clks[i]);
>>> + if (ret < 0)
>>> + goto err;
>>> + }
>>> +
>>> + return 0;
>>> +err:
>>> + while (--i >= 0)
>>> + clk_disable_unprepare(priv->clks[i]);
>>> + return ret;
>>> +}
>>> +
>>> +/* dphy accepts all fmt/size from sensor */
>>> +static int mipidphy_get_set_fmt(struct v4l2_subdev *sd,
>>> + struct v4l2_subdev_pad_config *cfg,
>>> + struct v4l2_subdev_format *fmt)
>>> +{
>>> + struct v4l2_subdev *sensor = get_remote_sensor(sd);
>>> +
>>> + /*
>>> + * Do not allow format changes and just relay whatever
>>> + * set currently in the sensor.
>>> + */
>>> + return v4l2_subdev_call(sensor, pad, get_fmt, NULL, fmt);
>>> +}
>>> +
>>> +static const struct v4l2_subdev_pad_ops mipidphy_subdev_pad_ops = {
>>> + .set_fmt = mipidphy_get_set_fmt,
>>> + .get_fmt = mipidphy_get_set_fmt,
>>> +};
>>> +
>>> +static const struct v4l2_subdev_core_ops mipidphy_core_ops = {
>>> + .s_power = mipidphy_s_power,
>>> +};
>>> +
>>> +static const struct v4l2_subdev_video_ops mipidphy_video_ops = {
>>> + .g_mbus_config = mipidphy_g_mbus_config,
>> Why do you need this?
>>
>>> + .s_stream = mipidphy_s_stream,
>>> +};
>>> +
>>> +static const struct v4l2_subdev_ops mipidphy_subdev_ops = {
>>> + .core = &mipidphy_core_ops,
>>> + .video = &mipidphy_video_ops,
>>> + .pad = &mipidphy_subdev_pad_ops,
>>> +};
>>> +
>>> +/* These tables must be sorted by .range_h ascending. */
>>> +static const struct hsfreq_range rk3288_mipidphy_hsfreq_ranges[] = {
>>> + { 89, 0x00}, { 99, 0x10}, { 109, 0x20}, { 129, 0x01},
>>> + { 139, 0x11}, { 149, 0x21}, { 169, 0x02}, { 179, 0x12},
>>> + { 199, 0x22}, { 219, 0x03}, { 239, 0x13}, { 249, 0x23},
>>> + { 269, 0x04}, { 299, 0x14}, { 329, 0x05}, { 359, 0x15},
>>> + { 399, 0x25}, { 449, 0x06}, { 499, 0x16}, { 549, 0x07},
>>> + { 599, 0x17}, { 649, 0x08}, { 699, 0x18}, { 749, 0x09},
>>> + { 799, 0x19}, { 849, 0x29}, { 899, 0x39}, { 949, 0x0a},
>>> + { 999, 0x1a}
>>> +};
>>> +
>>> +static const struct hsfreq_range rk3399_mipidphy_hsfreq_ranges[] = {
>>> + { 89, 0x00}, { 99, 0x10}, { 109, 0x20}, { 129, 0x01},
>>> + { 139, 0x11}, { 149, 0x21}, { 169, 0x02}, { 179, 0x12},
>>> + { 199, 0x22}, { 219, 0x03}, { 239, 0x13}, { 249, 0x23},
>>> + { 269, 0x04}, { 299, 0x14}, { 329, 0x05}, { 359, 0x15},
>>> + { 399, 0x25}, { 449, 0x06}, { 499, 0x16}, { 549, 0x07},
>>> + { 599, 0x17}, { 649, 0x08}, { 699, 0x18}, { 749, 0x09},
>>> + { 799, 0x19}, { 849, 0x29}, { 899, 0x39}, { 949, 0x0a},
>>> + { 999, 0x1a}, {1049, 0x2a}, {1099, 0x3a}, {1149, 0x0b},
>>> + {1199, 0x1b}, {1249, 0x2b}, {1299, 0x3b}, {1349, 0x0c},
>>> + {1399, 0x1c}, {1449, 0x2c}, {1500, 0x3c}
>>> +};
>>> +
>>> +static const char * const rk3399_mipidphy_clks[] = {
>>> + "dphy-ref",
>>> + "dphy-cfg",
>>> + "grf",
>>> +};
>>> +
>>> +static const char * const rk3288_mipidphy_clks[] = {
>>> + "dphy-ref",
>>> + "pclk",
>>> +};
>>> +
>>> +static const struct dphy_drv_data rk3288_mipidphy_drv_data = {
>>> + .clks = rk3288_mipidphy_clks,
>>> + .num_clks = ARRAY_SIZE(rk3288_mipidphy_clks),
>>> + .hsfreq_ranges = rk3288_mipidphy_hsfreq_ranges,
>>> + .num_hsfreq_ranges = ARRAY_SIZE(rk3288_mipidphy_hsfreq_ranges),
>>> + .regs = rk3288_grf_dphy_regs,
>>> +};
>>> +
>>> +static const struct dphy_drv_data rk3399_mipidphy_drv_data = {
>>> + .clks = rk3399_mipidphy_clks,
>>> + .num_clks = ARRAY_SIZE(rk3399_mipidphy_clks),
>>> + .hsfreq_ranges = rk3399_mipidphy_hsfreq_ranges,
>>> + .num_hsfreq_ranges = ARRAY_SIZE(rk3399_mipidphy_hsfreq_ranges),
>>> + .regs = rk3399_grf_dphy_regs,
>>> +};
>>> +
clocks are rockchip-generic.
>>> +static const struct of_device_id rockchip_mipidphy_match_id[] = {
>>> + {
>>> + .compatible = "rockchip,rk3399-mipi-dphy",
>>> + .data = &rk3399_mipidphy_drv_data,
>>> + },
>>> + {
>>> + .compatible = "rockchip,rk3288-mipi-dphy",
>>> + .data = &rk3288_mipidphy_drv_data,
>>> + },
>>> + {}
>>> +};
>>> +MODULE_DEVICE_TABLE(of, rockchip_mipidphy_match_id);
>>> +
>>> +/* The .bound() notifier callback when a match is found */
>>> +static int
>>> +rockchip_mipidphy_notifier_bound(struct v4l2_async_notifier *notifier,
>>> + struct v4l2_subdev *sd,
>>> + struct v4l2_async_subdev *asd)
>>> +{
>>> + struct mipidphy_priv *priv = container_of(notifier,
>>> + struct mipidphy_priv,
>>> + notifier);
>>> + struct sensor_async_subdev *s_asd = container_of(asd,
>>> + struct sensor_async_subdev, asd);
>>> + struct mipidphy_sensor *sensor;
>>> +
>>> + if (priv->num_sensors == ARRAY_SIZE(priv->sensors))
>>> + return -EBUSY;
>>> +
>>> + sensor = &priv->sensors[priv->num_sensors++];
>>> + sensor->lanes = s_asd->lanes;
>>> + sensor->mbus = s_asd->mbus;
>>> + sensor->sd = sd;
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +/* The .unbind callback */
>>> +static void
>>> +rockchip_mipidphy_notifier_unbind(struct v4l2_async_notifier *notifier,
>>> + struct v4l2_subdev *sd,
>>> + struct v4l2_async_subdev *asd)
>>> +{
>>> + struct mipidphy_priv *priv = container_of(notifier,
>>> + struct mipidphy_priv,
>>> + notifier);
>>> + struct mipidphy_sensor *sensor = sd_to_sensor(priv, sd);
>>> +
>>> + sensor->sd = NULL;
>>> +}
>>> +
>>> +/* .complete() is called after all subdevices have been located */
>>> +static int
>>> +rockchip_mipidphy_notifier_complete(struct v4l2_async_notifier *notifier)
>>> +{
>>> + struct mipidphy_priv *priv = container_of(notifier,
>>> + struct mipidphy_priv,
>>> + notifier);
>>> + unsigned int pad;
>>> + int ret;
>>> + int i;
>>> +
>>> + for (i = 0; i < priv->num_sensors; ++i) {
>>> + struct mipidphy_sensor *sensor = &priv->sensors[i];
>>> +
>>> + for (pad = 0; pad < sensor->sd->entity.num_pads; pad++)
>>> + if (sensor->sd->entity.pads[pad].flags
>>> + & MEDIA_PAD_FL_SOURCE)
>>> + break;
>>> +
>>> + if (pad == sensor->sd->entity.num_pads) {
>>> + dev_err(priv->dev,
>>> + "failed to find src pad for %s\n",
>>> + sensor->sd->name);
>>> +
>>> + return -ENXIO;
>>> + }
>>> +
>>> + ret = media_create_pad_link(
>>> + &sensor->sd->entity, pad,
>>> + &priv->sd.entity, MIPI_DPHY_SY_PAD_SINK,
>>> + i ? 0 : MEDIA_LNK_FL_ENABLED);
>>> + if (ret) {
>>> + dev_err(priv->dev,
>>> + "failed to create link for %s\n",
>>> + sensor->sd->name);
>>> + return ret;
>>> + }
>>> + }
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +static const
>>> +struct v4l2_async_notifier_operationsrockchip_mipidphy_async_ops = {
>>> + .bound = rockchip_mipidphy_notifier_bound,
>>> + .unbind = rockchip_mipidphy_notifier_unbind,
>>> + .complete = rockchip_mipidphy_notifier_complete,
>>> +};
>>> +
>>> +static int rockchip_mipidphy_fwnode_parse(struct device *dev,
>>> + struct v4l2_fwnode_endpoint *vep,
>>> + struct v4l2_async_subdev *asd)
>>> +{
>>> + struct sensor_async_subdev *s_asd =
>>> + container_of(asd, struct sensor_async_subdev, asd);
>>> + struct v4l2_mbus_config *config = &s_asd->mbus;
>>> +
>>> + if (vep->bus_type != V4L2_MBUS_CSI2) {
>>> + dev_err(dev, "Only CSI2 bus type is currently supported\n");
>>> + return -EINVAL;
>>> + }
>>> +
>>> + if (vep->base.port != 0) {
>>> + dev_err(dev, "The PHY has only port 0\n");
>>> + return -EINVAL;
>>> + }
>>> +
>>> + config->type = V4L2_MBUS_CSI2;
>>> + config->flags = vep->bus.mipi_csi2.flags;
>>> + s_asd->lanes = vep->bus.mipi_csi2.num_data_lanes;
>>> +
>>> + switch (vep->bus.mipi_csi2.num_data_lanes) {
>>> + case 1:
>>> + config->flags |= V4L2_MBUS_CSI2_1_LANE;
>>> + break;
>>> + case 2:
>>> + config->flags |= V4L2_MBUS_CSI2_2_LANE;
>>> + break;
>>> + case 3:
>>> + config->flags |= V4L2_MBUS_CSI2_3_LANE;
>>> + break;
>>> + case 4:
>>> + config->flags |= V4L2_MBUS_CSI2_4_LANE;
>>> + break;
>>> + default:
>>> + return -EINVAL;
>>> + }
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +static int rockchip_mipidphy_media_init(struct mipidphy_priv *priv)
>>> +{
>>> + int ret;
>>> +
>>> + priv->pads[MIPI_DPHY_SY_PAD_SOURCE].flags =
>>> + MEDIA_PAD_FL_SOURCE | MEDIA_PAD_FL_MUST_CONNECT;
>>> + priv->pads[MIPI_DPHY_SY_PAD_SINK].flags =
>>> + MEDIA_PAD_FL_SINK | MEDIA_PAD_FL_MUST_CONNECT;
>>> +
>>> + ret = media_entity_pads_init(&priv->sd.entity,
>>> + MIPI_DPHY_SY_PADS_NUM, priv->pads);
>>> + if (ret < 0)
>>> + return ret;
>>> +
>>> + ret = v4l2_async_notifier_parse_fwnode_endpoints_by_port(
>>> + priv->dev, &priv->notifier,
>>> + sizeof(struct sensor_async_subdev), 0,
>>> + rockchip_mipidphy_fwnode_parse);
>>> + if (ret < 0)
>>> + return ret;
>>> +
>>> + if (!priv->notifier.num_subdevs)
>>> + return -ENODEV; /* no endpoint */
>>> +
>>> + priv->sd.subdev_notifier = &priv->notifier;
>>> + priv->notifier.ops = &rockchip_mipidphy_async_ops;
>>> + ret = v4l2_async_subdev_notifier_register(&priv->sd, &priv->notifier);
>>> + if (ret) {
>>> + dev_err(priv->dev,
>>> + "failed to register async notifier : %d\n", ret);
>>> + v4l2_async_notifier_cleanup(&priv->notifier);
>>> + return ret;
>>> + }
>>> +
>>> + return v4l2_async_register_subdev(&priv->sd);
>>> +}
Those code are used to pass sensor info from mipi-phy driver to isp driver.
I'm not sure if they will be helpful to the other platform.
>>> +
>>> +static int rockchip_mipidphy_probe(struct platform_device *pdev)
>>> +{
>>> + struct device *dev = &pdev->dev;
>>> + struct v4l2_subdev *sd;
>>> + struct mipidphy_priv *priv;
>>> + struct regmap *grf;
>>> + const struct of_device_id *of_id;
>>> + const struct dphy_drv_data *drv_data;
>>> + int i, ret;
>>> +
>>> + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
>>> + if (!priv)
>>> + return -ENOMEM;
>>> + priv->dev = dev;
>>> +
>>> + of_id = of_match_device(rockchip_mipidphy_match_id, dev);
>>> + if (!of_id)
>>> + return -EINVAL;
>>> +
>>> + grf = syscon_node_to_regmap(dev->parent->of_node);
>>> + if (IS_ERR(grf)) {
>>> + dev_err(dev, "Can't find GRF syscon\n");
>>> + return -ENODEV;
>>> + }
>>> + priv->regmap_grf = grf;
>>> +
>>> + drv_data = of_id->data;
>>> + for (i = 0; i < drv_data->num_clks; i++) {
>>> + priv->clks[i] = devm_clk_get(dev, drv_data->clks[i]);
>>> +
>>> + if (IS_ERR(priv->clks[i])) {
>>> + dev_err(dev, "Failed to get %s\n", drv_data->clks[i]);
>>> + return PTR_ERR(priv->clks[i]);
>>> + }
>>> + }
>>> +
>>> + priv->grf_regs = drv_data->regs;
>>> + priv->drv_data = drv_data;
>>> +
>>> + sd = &priv->sd;
>>> + v4l2_subdev_init(sd, &mipidphy_subdev_ops);
>>> + sd->flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
>>> + snprintf(sd->name, sizeof(sd->name), "rockchip-sy-mipi-dphy");
>>> + sd->dev = dev;
>>> +
>>> + platform_set_drvdata(pdev, &sd->entity);
>>> +
>>> + ret = rockchip_mipidphy_media_init(priv);
>>> + if (ret < 0)
>>> + return ret;
>>> +
>>> + pm_runtime_enable(&pdev->dev);
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +static int rockchip_mipidphy_remove(struct platform_device *pdev)
>>> +{
>>> + struct media_entity *me = platform_get_drvdata(pdev);
>>> + struct v4l2_subdev *sd = media_entity_to_v4l2_subdev(me);
>>> +
>>> + media_entity_cleanup(&sd->entity);
>>> +
>>> + pm_runtime_disable(&pdev->dev);
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +static const struct dev_pm_ops rockchip_mipidphy_pm_ops = {
>>> + SET_RUNTIME_PM_OPS(mipidphy_runtime_suspend,
>>> + mipidphy_runtime_resume, NULL)
>>> +};
>>> +
>>> +static struct platform_driver rockchip_isp_mipidphy_driver = {
>>> + .probe = rockchip_mipidphy_probe,
>>> + .remove = rockchip_mipidphy_remove,
>>> + .driver = {
>>> + .name = "rockchip-sy-mipi-dphy",
>>> + .pm = &rockchip_mipidphy_pm_ops,
>>> + .of_match_table = rockchip_mipidphy_match_id,
>>> + },
>>> +};
>>> +
>>> +module_platform_driver(rockchip_isp_mipidphy_driver);
>>> +MODULE_AUTHOR("Rockchip Camera/ISP team");
>>> +MODULE_DESCRIPTION("Rockchip MIPI DPHY driver");
>>> +MODULE_LICENSE("Dual BSD/GPL");
>>>
>> Regards,
>>
>> Hans
>
^ permalink raw reply
* Re: [PATCH v4] ARM: dts: r8a7794: Add SMP support
From: Geert Uytterhoeven @ 2017-11-29 8:30 UTC (permalink / raw)
To: Simon Horman
Cc: Geert Uytterhoeven, Magnus Damm, Linux-Renesas,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
Sergei Shtylyov
In-Reply-To: <20171129082636.zwbwetif6vuxxfww@verge.net.au>
Hi Simon,
On Wed, Nov 29, 2017 at 9:26 AM, Simon Horman <horms@verge.net.au> wrote:
> On Tue, Nov 28, 2017 at 02:39:01PM +0100, Geert Uytterhoeven wrote:
>> From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>>
>> Add the device tree node for the Advanced Power Management Unit (APMU).
>> Use the "enable-method" prop to point out that the APMU should be used
>> for the SMP support.
>>
>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
>> ---
>> Dependency 3fd45a136ff61bb5 ("ARM: shmobile: rcar-gen2: Make sure
>> CNTVOFF is initialized on CA7/15") is part of v4.15-rc1.
>
> sorry if this is a bit of a sore topic but I'd like to ask what sort of
> testing this patch has seen. Are there any regressions in the area of
> CPU hotplug, suspend to RAM and so on...
Last time I tried, CPU hotplug worked fine (on Alt).
I cannot test suspend to RAM due to remote access.
Sergei?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v4] ARM: dts: r8a7794: Add SMP support
From: Simon Horman @ 2017-11-29 8:26 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Magnus Damm, linux-renesas-soc, linux-arm-kernel, devicetree,
Sergei Shtylyov
In-Reply-To: <1511876341-8639-1-git-send-email-geert+renesas@glider.be>
On Tue, Nov 28, 2017 at 02:39:01PM +0100, Geert Uytterhoeven wrote:
> From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>
> Add the device tree node for the Advanced Power Management Unit (APMU).
> Use the "enable-method" prop to point out that the APMU should be used
> for the SMP support.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> Dependency 3fd45a136ff61bb5 ("ARM: shmobile: rcar-gen2: Make sure
> CNTVOFF is initialized on CA7/15") is part of v4.15-rc1.
Hi Geert,
sorry if this is a bit of a sore topic but I'd like to ask what sort of
testing this patch has seen. Are there any regressions in the area of
CPU hotplug, suspend to RAM and so on...
^ permalink raw reply
* RE: [PATCH v4 00/12] [dt-bindings] [media] Add document file and driver for Sony CXD2880 DVB-T2/T tuner + demodulator
From: Takiguchi, Yasunari @ 2017-11-29 8:21 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, linux-media@vger.kernel.org,
tbird20d@gmail.com, frowand.list@gmail.com, Yamamoto, Masayuki,
Nozawa, Hideki (STWN), Yonezawa, Kota, Matsumoto, Toshihiko,
Watanabe, Satoshi (SSS), Sean Young, Michael Ira Krufky,
Bird, Timothy, Takiguchi, Yasunari
In-Reply-To: <20171129053830.7900d933@recife.lan>
Dear Mauro
Thanks for your support and reply.
I understood current status.
We will wait for community's feedback.
Regards and Thanks,
Takiguchi
^ permalink raw reply
* Re: [PATCH v2] arm64: dts: renesas: r8a7795: Move nodes which have no reg property out of bus
From: Simon Horman @ 2017-11-29 8:20 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Linux-Renesas,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Magnus Damm, Arnd Bergmann, Rob Herring, Geert Uytterhoeven,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <CAMuHMdXoDNt7j-hEZmDA2BFFPUAfsi1ukZWowJ3=kTswyYMk5Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Tue, Nov 28, 2017 at 10:04:00AM +0100, Geert Uytterhoeven wrote:
> Hi Simon,
>
> On Tue, Nov 28, 2017 at 9:56 AM, Simon Horman <horms-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org> wrote:
> > On Mon, Nov 27, 2017 at 12:15:39PM +0100, Geert Uytterhoeven wrote:
> >> On Mon, Nov 27, 2017 at 12:04 PM, Simon Horman <horms-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org> wrote:
> >> > I just noticed that with this patch applied I now see:
> >> >
> >> > arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dtb: Warning (interrupts_property): Missing interrupt-parent for /pmu_a57
> >> > arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dtb: Warning (interrupts_property): Missing interrupt-parent for /pmu_a53
> >> > arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dtb: Warning (interrupts_property): Missing interrupt-parent for /pmu_a57
> >> > arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dtb: Warning (interrupts_property): Missing interrupt-parent for /pmu_a53arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dtb: Warning (interrupts_property): Missing interrupt-parent for /timer
> >> >
> >> > arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dtb: Warning (interrupts_property): Missing interrupt-parent for /timer
> >>
> >> Right, the "interrupt-parent = <&gic>;" inside the /soc node applies to child
> >> nodes of the /soc node only.
> >>
> >> You can find this in two ways:
>
> s/find/fix/
>
> >>
> >> 1. Add "interrupt-parent = <&gic>;" to the /pmu_a57 and /pmu_a53 nodes.
> >> 2. Switch those nodes from "interrupt" to "interrupts-extended", e.g. turn
> >>
> >> interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>,
> >>
> >> into
> >>
> >> interrupts-extended = <&gic GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>,
> >>
> >> The latter is what e.g. arch/arm/boot/dts/armada-375.dtsi does.
> >
> > Thanks, I took option 1 as it seems consistent with the rest of the
> > Renesas DT files. I also added it to the /timer node.
>
> Actually we recently had a discussion about this on IRC, triggered by a
> similar issue in board files (see e.g, Ethernet PHY interrupts).
>
> Given the following comment:
>
> drivers/of/irq.c: /* Try the new-style interrupts-extended first */
> drivers/of/irq.c: res = of_parse_phandle_with_args(device,
> "interrupts-extended",
>
> I think it would be better to use interrupts-extended for individual/isolated
> use outside the /soc node.
Sure, will do.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 3/5] PCI: cadence: Add host driver for Cadence PCIe controller
From: Thomas Petazzoni @ 2017-11-29 8:19 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Cyrille Pitchen, bhelgaas-hpIqsD4AKlfQT0dZR+AlfA,
kishon-l0cyMroinI0, lorenzo.pieralisi-5wv7dgnIgG8,
linux-pci-u79uwXL29TY76Z2rM5mHXA, adouglas-vna1KIf7WgpBDgjK7y7TUQ,
stelford-vna1KIf7WgpBDgjK7y7TUQ, dgary-vna1KIf7WgpBDgjK7y7TUQ,
kgopi-vna1KIf7WgpBDgjK7y7TUQ, eandrews-vna1KIf7WgpBDgjK7y7TUQ,
sureshp-vna1KIf7WgpBDgjK7y7TUQ, nsekhar-l0cyMroinI0,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, robh-DgEjT+Ai2ygdnm+yROfE0A,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171128204114.GE11228-1RhO1Y9PlrlHTL0Zs8A6p5iNqAH0jzoTYJqu5kTmcBRl57MIdRCFDg@public.gmane.org>
Hello,
On Tue, 28 Nov 2017 14:41:14 -0600, Bjorn Helgaas wrote:
> > + * struct cdns_pcie_rc_data - hardware specific data
>
> "cdns" is a weird abbreviation for "Cadence", since "Cadence" doesn't
> contain an "s".
cdns is the official Device Tree binding vendor prefix for Cadence:
$ grep Cadence Documentation/devicetree/bindings/vendor-prefixes.txt
cdns Cadence Design Systems Inc.
And it is already widely used throughout the kernel for Cadence
drivers. See drivers/watchdog/cadence_wdt.c, drivers/spi/spi-cadence.c,
drivers/i2c/busses/i2c-cadence.c, etc.
Best regards,
Thomas Petazzoni
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v1] usb: xhci: allow imod-interval to be configurable
From: Greg Kroah-Hartman @ 2017-11-29 8:09 UTC (permalink / raw)
To: Adam Wallis
Cc: Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA, Mathias Nyman,
timur-sgV2jX0FEOL9JmXXK+q4OQ, linux-usb-u79uwXL29TY76Z2rM5mHXA,
chunfeng.yun-NuS5LvNUpcJWk0Htik3J/w, Rob Herring,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Matthias Brugger,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <22b57b69-3728-d879-42c6-92e87e7c7955-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
On Tue, Nov 28, 2017 at 03:32:29PM -0500, Adam Wallis wrote:
> On 11/28/2017 2:35 PM, Greg Kroah-Hartman wrote:
> > On Tue, Nov 28, 2017 at 12:11:46PM -0500, Adam Wallis wrote:
> >> The xHCI driver currently has the IMOD set to 160, which
> >> translates to an IMOD interval of 40,000ns (160 * 250)ns
> >>
> [..]
> >> --- a/drivers/usb/host/xhci-plat.c
> >> +++ b/drivers/usb/host/xhci-plat.c
> >> @@ -23,6 +23,7 @@
> >> #include "xhci-plat.h"
> >> #include "xhci-mvebu.h"
> >> #include "xhci-rcar.h"
> >> +#include "xhci-mtk.h"
> >>
> >> static struct hc_driver __read_mostly xhci_plat_hc_driver;
> >>
> >> @@ -269,6 +270,20 @@ static int xhci_plat_probe(struct platform_device *pdev)
> >> if (device_property_read_bool(&pdev->dev, "quirk-broken-port-ped"))
> >> xhci->quirks |= XHCI_BROKEN_PORT_PED;
> >>
> >> + /* imod interval in nanoseconds */
> >> + if (device_property_read_u32(sysdev,
> >> + "imod-interval", &xhci->imod_interval))
> >> + xhci->imod_interval = 40000;
> >
> > So no matter what value you read, you set it to 40000? Or am I reading
> > this code incorrectly?
>
> I think you may be reading the code incorrectly. device_property_read_u32()
> returns 0 when the property is found and valid...and stored into
> xhci->imod_interval. When 0 is returned in this case, the default value of
> 40,000 is skipped over.
Yes, it is very hard to read :(
> > There's a good reason putting function calls inside if() is considered a
> > bad coding style :)
>
> I do not disagree with you, however, I was trying to maintain style consistency
> with the device property reads with the xhci_plat_probe function.
Ok, maybe it should all be fixed :)
> If I break that consistency, a couple of ways I might write this cleaner
>
> 1) set xhci->imod_interval to 40,000 before the call to
> device_property_read_u32. If the property exists in a firmware node, it will
> update the imod_interval value...if it does not exist, it will not update this
> value and the default will be used. In this case, I would not even check the
> return value. This method is used quite a bit in the kernel.
Sounds like a reasonable way to do it.
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 00/12] [dt-bindings] [media] Add document file and driver for Sony CXD2880 DVB-T2/T tuner + demodulator
From: Mauro Carvalho Chehab @ 2017-11-29 7:38 UTC (permalink / raw)
To: Takiguchi, Yasunari
Cc: akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
tbird20d-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
Yamamoto, Masayuki, Nozawa, Hideki (STWN), Yonezawa, Kota,
Matsumoto, Toshihiko, Watanabe, Satoshi (SSS), Sean Young,
Michael Ira Krufky, Bird, Timothy
In-Reply-To: <3e2f788b-3e4a-eb9b-eb36-2f65ffce669a-7U/KSKJipcs@public.gmane.org>
Em Wed, 22 Nov 2017 13:17:14 +0900
"Takiguchi, Yasunari" <Yasunari.Takiguchi-7U/KSKJipcs@public.gmane.org> escreveu:
Hi Takiguchi-san,
> Hi, all
>
> I sent the patch series of Sony CXD2880 DVB-T2/T tuner + demodulator driver version 4 on 13th/Oct.
> I'd like to get better understanding of current review status for our codes.
>
> Are there any comments, advices and review results for them?
October was a month crowded of trips for everybody. I had some trips in
November too, and a merge window to take care of, with ended by delaying
patch reviews. We didn't even had the time yet to finish the summit report.
Anyway, now Sean and Michael are helping with DVB patch review.
Michael/Sean, could you please take a look on this patch series?
I'll try to take a look on it myself next week.
Thanks,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 06/35] nds32: MMU fault handling and page table management
From: Greentime Hu @ 2017-11-29 7:24 UTC (permalink / raw)
To: Mark Rutland
Cc: Greentime, Linux Kernel Mailing List, Arnd Bergmann, linux-arch,
Thomas Gleixner, Jason Cooper, Marc Zyngier, Rob Herring, netdev,
Vincent Chen, DTML, Al Viro, David Howells, Will Deacon,
Daniel Lezcano, linux-serial-u79uwXL29TY76Z2rM5mHXA, Vincent Chen
In-Reply-To: <20171127135136.3gnguzaf6d52tcpd-agMKViyK24J5pKCnmE3YQBJ8xKzm50AiAL8bYrjMMd8@public.gmane.org>
Hi, Mark:
2017-11-27 21:51 GMT+08:00 Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>:
> Hi,
>
> On Mon, Nov 27, 2017 at 08:27:53PM +0800, Greentime Hu wrote:
>> +void do_page_fault(unsigned long entry, unsigned long addr,
>> + unsigned int error_code, struct pt_regs *regs)
>> +{
>
>> + /*
>> + * As per x86, we may deadlock here. However, since the kernel only
>> + * validly references user space from well defined areas of the code,
>> + * we can bug out early if this is from code which shouldn't.
>> + */
>> + if (unlikely(!down_read_trylock(&mm->mmap_sem))) {
>> + if (!user_mode(regs) &&
>> + !search_exception_tables(instruction_pointer(regs)))
>> + goto no_context;
>> +retry:
>> + down_read(&mm->mmap_sem);
>> + } else {
>> + /*
>> + * The above down_read_trylock() might have succeeded in which
>> + * case, we'll have missed the might_sleep() from down_read().
>> + */
>> + might_sleep();
>> + if (IS_ENABLED(CONFIG_DEBUG_VM)) {
>> + if (!user_mode(regs) &&
>> + !search_exception_tables(instruction_pointer(regs)))
>> + goto no_context;
>> + }
>> + }
>
>> + fault = handle_mm_fault(vma, addr, flags);
>> +
>> + /*
>> + * If we need to retry but a fatal signal is pending, handle the
>> + * signal first. We do not need to release the mmap_sem because it
>> + * would already be released in __lock_page_or_retry in mm/filemap.c.
>> + */
>> + if ((fault & VM_FAULT_RETRY) && fatal_signal_pending(current))
>> + return;
>
> I believe you can get stuck in a livelock here (with an unkillable
> task), if a uaccess primitive tries to access a region protected by a
> userfaultfd. Please see:
>
> https://lkml.kernel.org/r/1499782590-31366-1-git-send-email-mark.rutland-5wv7dgnIgG8@public.gmane.org
>
> ... for details and a test case.
>
Thanks for your teatcase and patch. It works.
I will apply it to the next version patch.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] arm: dts: ls1021a: fix the value of TMR_FIPER1
From: Shawn Guo @ 2017-11-29 6:55 UTC (permalink / raw)
To: Y.b. Lu
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Rob Herring, Mark Rutland, Russell King
In-Reply-To: <DB6PR0401MB2536A92B16A744BB51BA0197F8260-2mNvjAGDOPkZcyyZo0JLBI3W/0Ik+aLCnBOFsp37pqbUKgpGm//BTAC/G2K4zDHf@public.gmane.org>
On Fri, Nov 24, 2017 at 02:31:13AM +0000, Y.b. Lu wrote:
> Any comments?
>
> +Shawn
Please resend with me on copy.
>
> Thanks.
>
> -----Original Message-----
> From: Yangbo Lu [mailto:yangbo.lu-3arQi8VN3Tc@public.gmane.org]
> Sent: 2017年11月10日 9:59
> To: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org; Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>; Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>; Russell King <linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>
> Cc: Y.b. Lu <yangbo.lu-3arQi8VN3Tc@public.gmane.org>
> Subject: [PATCH] arm: dts: ls1021a: fix the value of TMR_FIPER1
ARM: dts: ...
>
> The timer fixed interval period pulse generator register is used to generate periodic pulses. The down count register loads the value programmed in the fixed period interval (FIPER). At every tick of the timer accumulator overflow, the counter decrements by the value of TMR_CTRL[TCLK_PERIOD]. It generates a pulse when the down counter value reaches zero. It reloads the down counter in the cycle following a pulse. To use the TMR_FIPER1 register to generate a 1 PPS event, the value
Please wrap the commit log properly.
Shawn
> (10^9 nanoseconds) - TCLK_PERIOD should be programmed.
> It should be 999999995 not 999999990 since TCLK_PERIOD is 5.
>
> Signed-off-by: Yangbo Lu <yangbo.lu-3arQi8VN3Tc@public.gmane.org>
> ---
> arch/arm/boot/dts/ls1021a.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi index 9319e1f0f1d8..10e536f338f7 100644
> --- a/arch/arm/boot/dts/ls1021a.dtsi
> +++ b/arch/arm/boot/dts/ls1021a.dtsi
> @@ -575,7 +575,7 @@
> fsl,tclk-period = <5>;
> fsl,tmr-prsc = <2>;
> fsl,tmr-add = <0xaaaaaaab>;
> - fsl,tmr-fiper1 = <999999990>;
> + fsl,tmr-fiper1 = <999999995>;
> fsl,tmr-fiper2 = <99990>;
> fsl,max-adj = <499999999>;
> };
> --
> 2.14.1
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [v2] arm: dts: ls1021a: fix the value of TMR_FIPER1
From: Yangbo Lu @ 2017-11-29 6:54 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Rob Herring, Mark Rutland, Russell King, Shawn Guo, Yangbo Lu
The timer fixed interval period pulse generator register
is used to generate periodic pulses. The down count
register loads the value programmed in the fixed period
interval (FIPER). At every tick of the timer accumulator
overflow, the counter decrements by the value of
TMR_CTRL[TCLK_PERIOD]. It generates a pulse when the down
counter value reaches zero. It reloads the down counter
in the cycle following a pulse. To use the TMR_FIPER1
register to generate a 1 PPS event, the value
(10^9 nanoseconds) - TCLK_PERIOD should be programmed.
It should be 999999995 not 999999990 since TCLK_PERIOD
is 5.
Signed-off-by: Yangbo Lu <yangbo.lu-3arQi8VN3Tc@public.gmane.org>
---
Changes for v2:
- Added Shawn into cc list.
---
arch/arm/boot/dts/ls1021a.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
index 64249726b3cb..a861a4b9e319 100644
--- a/arch/arm/boot/dts/ls1021a.dtsi
+++ b/arch/arm/boot/dts/ls1021a.dtsi
@@ -589,7 +589,7 @@
fsl,tclk-period = <5>;
fsl,tmr-prsc = <2>;
fsl,tmr-add = <0xaaaaaaab>;
- fsl,tmr-fiper1 = <999999990>;
+ fsl,tmr-fiper1 = <999999995>;
fsl,tmr-fiper2 = <99990>;
fsl,max-adj = <499999999>;
};
--
2.14.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCHi v2] dt-bindings: add device tree binding for Arm TrustZone CryptoCell crypto engine
From: Herbert Xu @ 2017-11-29 6:37 UTC (permalink / raw)
To: Gilad Ben-Yossef
Cc: Mark Rutland, devel, devicetree, linux-kernel, Rob Herring,
linux-crypto, David S. Miller, Ofir Drang
In-Reply-To: <1510812929-3937-1-git-send-email-gilad@benyossef.com>
On Thu, Nov 16, 2017 at 06:15:28AM +0000, Gilad Ben-Yossef wrote:
> The Arm TrustZone CryptoCell is a hardware security engine. This patch
> adds DT bindings for its Rich Execution Environment crypto engine.
>
> A driver supporting this device is already present in the staging tree.
>
> Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com>
> Acked-by: Rob Herring <robh@kernel.org>
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [v2,01/12] hwrng: bcm2835 - Obtain base register via resource
From: Herbert Xu @ 2017-11-29 6:30 UTC (permalink / raw)
To: Florian Fainelli
Cc: linux-kernel, Matt Mackall, Rob Herring, Mark Rutland, Ray Jui,
Scott Branden,
maintainer:BROADCOM BCM281XX/BCM11XXX/BCM216XX ARM ARCHITE...,
Eric Anholt, Stefan Wahren, PrasannaKumar Muralidharan,
Russell King, Krzysztof Kozlowski, Harald Freudenberger,
Sean Wang, Martin Kaiser, Steffen Trumtrar,
open list:HARDWARE RANDOM NUMBER GENERATOR CORE
In-Reply-To: <20171108004449.32730-2-f.fainelli@gmail.com>
On Tue, Nov 07, 2017 at 04:44:38PM -0800, Florian Fainelli wrote:
> In preparation for consolidating bcm63xx-rng into bcm2835-rng, make sure
> that we obtain the base register via platform_get_resource() since we
> need to support the non-DT enabled MIPS-based BCM63xx DSL SoCs.
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
All applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH v5 0/2] STM32 CRYP crypto driver
From: Herbert Xu @ 2017-11-29 6:29 UTC (permalink / raw)
To: Fabien Dessenne
Cc: David S . Miller, Rob Herring, Mark Rutland, Maxime Coquelin,
Alexandre Torgue, linux-crypto, devicetree, linux-arm-kernel,
linux-kernel, Benjamin Gaignard, Lionel Debieve, Ludovic Barre
In-Reply-To: <1508425830-13565-1-git-send-email-fabien.dessenne@st.com>
On Thu, Oct 19, 2017 at 05:10:28PM +0200, Fabien Dessenne wrote:
> This set of patches adds a new crypto driver for STMicroelectronics stm32 HW.
> This drivers uses the crypto API and provides with HW-enabled block cipher
> algorithms.
>
> This driver was successfully tested with tcrypt / testmgr.
>
> Changes since v5:
> -add timeout in wait_busy function
> -clear key after use
> -misc : remove unused functions, use -Exx, use dev_err
All applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ 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