* Re: [PATCH 3/6] arm: dts: marvell: Add missing #phy-cells to usb-nop-xceiv
From: Andrew Lunn @ 2017-11-21 20:09 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
arm-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, Jason Cooper,
Gregory Clement, Sebastian Hesselbarth
In-Reply-To: <CAL_JsqJhq7TqdaS+i8yk8rRJM0hH2hyk8eybXsnR0D8QoncXZg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Tue, Nov 21, 2017 at 12:29:48PM -0600, Rob Herring wrote:
> On Thu, Nov 9, 2017 at 4:26 PM, Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> > "usb-nop-xceiv" is using the phy binding, but is missing #phy-cells
> > property. This is probably because the binding was the precursor to the phy
> > binding.
> >
> > Fixes the following warning in Marvell dts files:
> >
> > Warning (phys_property): Missing property '#phy-cells' in node ...
> >
> > Signed-off-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> > Cc: Jason Cooper <jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org>
> > Cc: Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>
> > Cc: Gregory Clement <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> > Cc: Sebastian Hesselbarth <sebastian.hesselbarth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > ---
> > Please apply to Marvell tree.
>
> Ping.
>
> Arnd, can you apply if you'd like the warnings fixed and Marvell
> maintainers don't respond.
Hi Rob
Patches submitted a week before the merge window opens are generally
deferred to the next cycle. I expect that once -rc1 is out, Gregory
will pick up this patch.
Andrew
--
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
* [bbb-overlays] Fixing overlay configfs for v4.14
From: Geert Uytterhoeven @ 2017-11-21 20:24 UTC (permalink / raw)
To: Pantelis Antoniou
Cc: Frank Rowand, devicetree, linux-renesas-soc, linux-kernel,
Geert Uytterhoeven
Hi Pantelis,
Using overlay configfs on v4.14 requires two fixes, both due to commit
d1651b03c2df75db ("of: overlay: add overlay symbols to live device
tree"):
1. As the symbols were added to the ovinfo[] array without calling
of_fill_overlay_info(), the new of_overlay_info.info field (added by
your bbb-overlays patches) is not set up, causing a NULL pointer
dereference.
As calling of_fill_overlay_info() is not appropriate here, the patch
below fixes this by filling it in manually. Feel free to fold into
"of: overlay: add per overlay sysfs attributes".
2. "of: overlay: Pick up label symbols from overlays." must be
reverted, else loading overlays fails with:
OF: changeset: add_property failed @/__symbols__/...
OF: Error applying changeset (-17)
I've updated my topic/overlays and topic/renesas-overlays branches in
https://git.kernel.org/cgit/linux/kernel/git/geert/renesas-drivers.git
accordingly.
diff --git a/drivers/of/overlay.c b/drivers/of/overlay.c
index afa681014e19e3da..3cb6ae9ecb998d5e 100644
--- a/drivers/of/overlay.c
+++ b/drivers/of/overlay.c
@@ -569,6 +569,7 @@ static int of_build_overlay_info(struct of_overlay *ov,
if (node) {
ovinfo[cnt].overlay = node;
ovinfo[cnt].target = of_find_node_by_path("/__symbols__");
+ ovinfo[cnt].info = of_node_get(node);
ovinfo[cnt].is_symbols_node = 1;
if (!ovinfo[cnt].target) {
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 related
* Re: [PATCH v3 1/3] leds: core: Introduce generic pattern interface
From: Jacek Anaszewski @ 2017-11-21 20:33 UTC (permalink / raw)
To: Bjorn Andersson, Richard Purdie, Pavel Machek
Cc: linux-kernel, linux-leds, linux-arm-msm, Rob Herring,
Mark Rutland, devicetree, Fenglin Wu
In-Reply-To: <20171115071345.24331-2-bjorn.andersson@linaro.org>
Hi Bjorn,
I have one general remark below.
On 11/15/2017 08:13 AM, Bjorn Andersson wrote:
> Some LED controllers have support for autonomously controlling
> brightness over time, according to some preprogrammed pattern or
> function.
>
> This adds a new optional operator that LED class drivers can implement
> if they support such functionality as well as a new device attribute to
> configure the pattern for a given LED.
>
> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> ---
>
> Changes since v2:
> - None
>
> Changes since v1:
> - New patch, based on discussions following v1
>
> Documentation/ABI/testing/sysfs-class-led | 20 ++++
> drivers/leds/led-class.c | 150 ++++++++++++++++++++++++++++++
> include/linux/leds.h | 21 +++++
> 3 files changed, 191 insertions(+)
>
> diff --git a/Documentation/ABI/testing/sysfs-class-led b/Documentation/ABI/testing/sysfs-class-led
> index 5f67f7ab277b..74a7f5b1f89b 100644
> --- a/Documentation/ABI/testing/sysfs-class-led
> +++ b/Documentation/ABI/testing/sysfs-class-led
> @@ -61,3 +61,23 @@ Description:
> gpio and backlight triggers. In case of the backlight trigger,
> it is useful when driving a LED which is intended to indicate
> a device in a standby like state.
> +
> +What: /sys/class/leds/<led>/pattern
> +Date: July 2017
> +KernelVersion: 4.14
> +Description:
> + Specify a pattern for the LED, for LED hardware that support
> + altering the brightness as a function of time.
> +
> + The pattern is given by a series of tuples, of brightness and
> + duration (ms). The LED is expected to traverse the series and
> + each brightness value for the specified duration.
> +
> + Additionally a repeat marker ":|" can be appended to the
> + series, which should cause the pattern to be repeated
> + endlessly.
> +
> + As LED hardware might have different capabilities and precision
> + the requested pattern might be slighly adjusted by the driver
> + and the resulting pattern of such operation should be returned
> + when this file is read.
I'd prefer to implement this file in a trigger, similarly to
ledtrig-timer's delay_on/delay_off files.
The trigger would use new pattern ops instead of blink_set(). This way
we will not make the pattern interface fixed once for good. It will be
possible to implement in the future other types of pattern triggers
accepting other pattern formats.
In order to avoid the need for implementing software fallback a new
mechanism would have to be added for checking whether given LED class
driver supports selected type of pattern trigger and fail on write to
triggers file if not. Drivers could just set the relevant flag to be
defined in linux/leds.h
Best regards,
Jacek Anaszewski
> diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
> index b0e2d55acbd6..bd630e2ae967 100644
> --- a/drivers/leds/led-class.c
> +++ b/drivers/leds/led-class.c
> @@ -74,6 +74,154 @@ static ssize_t max_brightness_show(struct device *dev,
> }
> static DEVICE_ATTR_RO(max_brightness);
>
> +static ssize_t pattern_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + struct led_classdev *led_cdev = dev_get_drvdata(dev);
> + struct led_pattern *pattern;
> + size_t offset = 0;
> + size_t count;
> + bool repeat;
> + size_t i;
> + int n;
> +
> + if (!led_cdev->pattern_get)
> + return -EOPNOTSUPP;
> +
> + pattern = led_cdev->pattern_get(led_cdev, &count, &repeat);
> + if (IS_ERR_OR_NULL(pattern))
> + return PTR_ERR(pattern);
> +
> + for (i = 0; i < count; i++) {
> + n = snprintf(buf + offset, PAGE_SIZE - offset, "%d %d",
> + pattern[i].brightness, pattern[i].delta_t);
> +
> + if (offset + n >= PAGE_SIZE)
> + goto err_nospc;
> +
> + offset += n;
> +
> + if (i < count - 1)
> + buf[offset++] = ' ';
> + }
> +
> + if (repeat) {
> + if (offset + 4 >= PAGE_SIZE)
> + goto err_nospc;
> +
> + memcpy(buf + offset, " :|", 3);
> + offset += 3;
> + }
> +
> + if (offset + 1 >= PAGE_SIZE)
> + goto err_nospc;
> +
> + buf[offset++] = '\n';
> +
> + kfree(pattern);
> + return offset;
> +
> +err_nospc:
> + kfree(pattern);
> + return -ENOSPC;
> +}
> +
> +static ssize_t pattern_store(struct device *dev,
> + struct device_attribute *attr,
> + const char *buf, size_t size)
> +{
> + struct led_classdev *led_cdev = dev_get_drvdata(dev);
> + struct led_pattern *pattern = NULL;
> + unsigned long val;
> + char *sbegin;
> + char *elem;
> + char *s;
> + int len = 0;
> + int ret = 0;
> + bool odd = true;
> + bool repeat = false;
> +
> + s = sbegin = kstrndup(buf, size, GFP_KERNEL);
> + if (!s)
> + return -ENOMEM;
> +
> + /* Trim trailing newline */
> + s[strcspn(s, "\n")] = '\0';
> +
> + /* If the remaining string is empty, clear the pattern */
> + if (!s[0]) {
> + ret = led_cdev->pattern_clear(led_cdev);
> + goto out;
> + }
> +
> + pattern = kcalloc(size, sizeof(*pattern), GFP_KERNEL);
> + if (!pattern) {
> + ret = -ENOMEM;
> + goto out;
> + }
> +
> + /* Parse out the brightness & delta_t touples and check for repeat */
> + while ((elem = strsep(&s, " ")) != NULL) {
> + if (!strcmp(elem, ":|")) {
> + repeat = true;
> + break;
> + }
> +
> + ret = kstrtoul(elem, 10, &val);
> + if (ret)
> + goto out;
> +
> + if (odd) {
> + pattern[len].brightness = val;
> + } else {
> + /* Ensure we don't have any delta_t == 0 */
> + if (!val) {
> + ret = -EINVAL;
> + goto out;
> + }
> +
> + pattern[len].delta_t = val;
> + len++;
> + }
> +
> + odd = !odd;
> + }
> +
> + /*
> + * Fail if we didn't find any data points or last data point was partial
> + */
> + if (!len || !odd) {
> + ret = -EINVAL;
> + goto out;
> + }
> +
> + ret = led_cdev->pattern_set(led_cdev, pattern, len, repeat);
> +
> +out:
> + kfree(pattern);
> + kfree(sbegin);
> + return ret < 0 ? ret : size;
> +}
> +
> +static DEVICE_ATTR_RW(pattern);
> +
> +static umode_t led_class_attrs_mode(struct kobject *kobj,
> + struct attribute *attr,
> + int index)
> +{
> + struct device *dev = container_of(kobj, struct device, kobj);
> + struct led_classdev *led_cdev = dev_get_drvdata(dev);
> +
> + if (attr == &dev_attr_brightness.attr)
> + return attr->mode;
> + if (attr == &dev_attr_max_brightness.attr)
> + return attr->mode;
> + if (attr == &dev_attr_pattern.attr && led_cdev->pattern_set)
> + return attr->mode;
> +
> + return 0;
> +}
> +
> #ifdef CONFIG_LEDS_TRIGGERS
> static DEVICE_ATTR(trigger, 0644, led_trigger_show, led_trigger_store);
> static struct attribute *led_trigger_attrs[] = {
> @@ -88,11 +236,13 @@ static const struct attribute_group led_trigger_group = {
> static struct attribute *led_class_attrs[] = {
> &dev_attr_brightness.attr,
> &dev_attr_max_brightness.attr,
> + &dev_attr_pattern.attr,
> NULL,
> };
>
> static const struct attribute_group led_group = {
> .attrs = led_class_attrs,
> + .is_visible = led_class_attrs_mode,
> };
>
> static const struct attribute_group *led_groups[] = {
> diff --git a/include/linux/leds.h b/include/linux/leds.h
> index bf6db4fe895b..584c79ff5bb5 100644
> --- a/include/linux/leds.h
> +++ b/include/linux/leds.h
> @@ -33,6 +33,8 @@ enum led_brightness {
> LED_FULL = 255,
> };
>
> +struct led_pattern;
> +
> struct led_classdev {
> const char *name;
> enum led_brightness brightness;
> @@ -88,6 +90,15 @@ struct led_classdev {
> unsigned long *delay_on,
> unsigned long *delay_off);
>
> + int (*pattern_set)(struct led_classdev *led_cdev,
> + struct led_pattern *pattern, int len,
> + bool repeat);
> +
> + int (*pattern_clear)(struct led_classdev *led_cdev);
> +
> + struct led_pattern *(*pattern_get)(struct led_classdev *led_cdev,
> + size_t *len, bool *repeat);
> +
> struct device *dev;
> const struct attribute_group **groups;
>
> @@ -446,4 +457,14 @@ static inline void led_classdev_notify_brightness_hw_changed(
> struct led_classdev *led_cdev, enum led_brightness brightness) { }
> #endif
>
> +/**
> + * struct led_pattern - brigheness value in a pattern
> + * @delta_t: delay until next entry, in milliseconds
> + * @brightness: brightness at time = 0
> + */
> +struct led_pattern {
> + int delta_t;
> + int brightness;
> +};
> +
> #endif /* __LINUX_LEDS_H_INCLUDED */
>
^ permalink raw reply
* Re: [PATCH 3/6] arm: dts: marvell: Add missing #phy-cells to usb-nop-xceiv
From: Arnd Bergmann @ 2017-11-21 20:45 UTC (permalink / raw)
To: Andrew Lunn
Cc: Rob Herring, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
arm-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, Jason Cooper,
Gregory Clement, Sebastian Hesselbarth
In-Reply-To: <20171121200922.GD30040-g2DYL2Zd6BY@public.gmane.org>
On Tue, Nov 21, 2017 at 9:09 PM, Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org> wrote:
> On Tue, Nov 21, 2017 at 12:29:48PM -0600, Rob Herring wrote:
>> On Thu, Nov 9, 2017 at 4:26 PM, Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>> > "usb-nop-xceiv" is using the phy binding, but is missing #phy-cells
>> > property. This is probably because the binding was the precursor to the phy
>> > binding.
>> >
>> > Fixes the following warning in Marvell dts files:
>> >
>> > Warning (phys_property): Missing property '#phy-cells' in node ...
>> >
>> > Signed-off-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>> > Cc: Jason Cooper <jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org>
>> > Cc: Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>
>> > Cc: Gregory Clement <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
>> > Cc: Sebastian Hesselbarth <sebastian.hesselbarth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> > ---
>> > Please apply to Marvell tree.
>>
>> Ping.
>>
>> Arnd, can you apply if you'd like the warnings fixed and Marvell
>> maintainers don't respond.
>
> Hi Rob
>
> Patches submitted a week before the merge window opens are generally
> deferred to the next cycle. I expect that once -rc1 is out, Gregory
> will pick up this patch.
These are real bugfixes, I want them in 4.15, since we now get a
loud warning for them. I'd rather not shut up that warning because
it's not a false-positive.
Arnd
--
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 v3 2/4] [media] dt-bindings: Document BCM283x CSI2/CCP2 receiver
From: Eric Anholt @ 2017-11-21 20:54 UTC (permalink / raw)
To: Rob Herring
Cc: Dave Stevenson, Stefan Wahren, Mauro Carvalho Chehab,
linux-media@vger.kernel.org, Sakari Ailus, Hans Verkuil,
moderated list:BROADCOM BCM2835 ARM ARCHITECTURE,
devicetree@vger.kernel.org
In-Reply-To: <CAL_JsqJ51jd8nkYAKvLUEf8n7+eJsd8JxW-8YJ6gfx1_Y1LzdA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 7212 bytes --]
Rob Herring <robh@kernel.org> writes:
> On Tue, Nov 21, 2017 at 1:26 PM, Eric Anholt <eric@anholt.net> wrote:
>> Dave Stevenson <dave.stevenson@raspberrypi.org> writes:
>>
>>> Hi Rob
>>>
>>> On 27 September 2017 at 22:51, Rob Herring <robh@kernel.org> wrote:
>>>> On Fri, Sep 22, 2017 at 05:07:22PM +0100, Dave Stevenson wrote:
>>>>> Hi Stefan
>>>>>
>>>>> On 22 September 2017 at 07:45, Stefan Wahren <stefan.wahren@i2se.com> wrote:
>>>>> > Hi Dave,
>>>>> >
>>>>> >> Dave Stevenson <dave.stevenson@raspberrypi.org> hat am 20. September 2017 um 18:07 geschrieben:
>>>>> >>
>>>>> >>
>>>>> >> Document the DT bindings for the CSI2/CCP2 receiver peripheral
>>>>> >> (known as Unicam) on BCM283x SoCs.
>>>>> >>
>>>>> >> Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.org>
>>>>> >> ---
>>>>> >>
>>>>> >> Changes since v2
>>>>> >> - Removed all references to Linux drivers.
>>>>> >> - Reworded section about disabling the firmware driver.
>>>>> >> - Renamed clock from "lp_clock" to "lp" in description and example.
>>>>> >> - Referred to video-interfaces.txt and stated requirements on remote-endpoint
>>>>> >> and data-lanes.
>>>>> >> - Corrected typo in example from csi to csi1.
>>>>> >> - Removed unnecessary #address-cells and #size-cells in example.
>>>>> >> - Removed setting of status from the example.
>>>>> >>
>>>>> >> .../devicetree/bindings/media/bcm2835-unicam.txt | 85 ++++++++++++++++++++++
>>>>> >> 1 file changed, 85 insertions(+)
>>>>> >> create mode 100644 Documentation/devicetree/bindings/media/bcm2835-unicam.txt
>>>>> >>
>>>>> >> diff --git a/Documentation/devicetree/bindings/media/bcm2835-unicam.txt b/Documentation/devicetree/bindings/media/bcm2835-unicam.txt
>>>>> >> new file mode 100644
>>>>> >> index 0000000..7714fb3
>>>>> >> --- /dev/null
>>>>> >> +++ b/Documentation/devicetree/bindings/media/bcm2835-unicam.txt
>>>>> >> @@ -0,0 +1,85 @@
>>>>> >> +Broadcom BCM283x Camera Interface (Unicam)
>>>>> >> +------------------------------------------
>>>>> >> +
>>>>> >> +The Unicam block on BCM283x SoCs is the receiver for either
>>>>> >> +CSI-2 or CCP2 data from image sensors or similar devices.
>>>>> >> +
>>>>> >> +The main platform using this SoC is the Raspberry Pi family of boards.
>>>>> >> +On the Pi the VideoCore firmware can also control this hardware block,
>>>>> >> +and driving it from two different processors will cause issues.
>>>>> >> +To avoid this, the firmware checks the device tree configuration
>>>>> >> +during boot. If it finds device tree nodes called csi0 or csi1 then
>>>>> >> +it will stop the firmware accessing the block, and it can then
>>>>> >> +safely be used via the device tree binding.
>>>>> >> +
>>>>> >> +Required properties:
>>>>> >> +===================
>>>>> >> +- compatible : must be "brcm,bcm2835-unicam".
>>>>> >> +- reg : physical base address and length of the register sets for the
>>>>> >> + device.
>>>>> >> +- interrupts : should contain the IRQ line for this Unicam instance.
>>>>> >> +- clocks : list of clock specifiers, corresponding to entries in
>>>>> >> + clock-names property.
>>>>> >> +- clock-names : must contain an "lp" entry, matching entries in the
>>>>> >> + clocks property.
>>>>> >> +
>>>>> >> +Unicam supports a single port node. It should contain one 'port' child node
>>>>> >> +with child 'endpoint' node. Please refer to the bindings defined in
>>>>> >> +Documentation/devicetree/bindings/media/video-interfaces.txt.
>>>>> >> +
>>>>> >> +Within the endpoint node the "remote-endpoint" and "data-lanes" properties
>>>>> >> +are mandatory.
>>>>> >> +Data lane reordering is not supported so the data lanes must be in order,
>>>>> >> +starting at 1. The number of data lanes should represent the number of
>>>>> >> +usable lanes for the hardware block. That may be limited by either the SoC or
>>>>> >> +how the platform presents the interface, and the lower value must be used.
>>>>> >> +
>>>>> >> +Lane reordering is not supported on the clock lane either, so the optional
>>>>> >> +property "clock-lane" will implicitly be <0>.
>>>>> >> +Similarly lane inversion is not supported, therefore "lane-polarities" will
>>>>> >> +implicitly be <0 0 0 0 0>.
>>>>> >> +Neither of these values will be checked.
>>>>> >> +
>>>>> >> +Example:
>>>>> >> + csi1: csi1@7e801000 {
>>>>> >> + compatible = "brcm,bcm2835-unicam";
>>>>> >> + reg = <0x7e801000 0x800>,
>>>>> >> + <0x7e802004 0x4>;
>>>>> >
>>>>> > sorry, i didn't noticed this before. I'm afraid this is using a small range of the CMI. Are there possible other users of this range? Does it make sense to handle this by a separate clock driver?
>>>>>
>>>>> CMI (Clock Manager Image) consists of a total of 4 registers.
>>>>> 0x7e802000 is CMI_CAM0, with only bits 0-5 used for gating and
>>>>> inversion of the clock and data lanes (2 data lanes available on
>>>>> CAM0).
>>>>> 0x7e802004 is CMI_CAM1, with only bits 0-9 used for gating and
>>>>> inversion of the clock and data lanes (4 data lanes available on
>>>>> CAM1).
>>>>> 0x7e802008 is CMI_CAMTEST which I have no documentation or drivers for.
>>>>> 0x7e802010 is CMI_USBCTL. Only bit 6 is documented and is a reset. The
>>>>> default value is the required value. Nothing touches it that I can
>>>>> find.
>>>>>
>>>>> The range listed only covers the one register associated with that
>>>>> Unicam instance, so no other users. The other two aren't touched.
>>>>> Do 16 active register bits solely for camera clock gating really
>>>>> warrant a full clock driver?
>>>>
>>>> You should describe all the registers in DT, not just what the driver
>>>> (currently) uses.
>>>
>>> I'm not clear what you're asking for here.
>>>
>>> This binding is for the Unicam block, not for CMI (Clock Manager
>>> Imaging). In order for a Unicam instance to work, it needs to enable
>>> the relevant clock gating via 1 CMI register, and it will only ever be
>>> one register.
>>
>> Rob, the CMI just a small bit of glue required by the crossing of a
>> power domain in a unicam instance, and the two unicam instances in this
>> HW have their CMI regs next to each other. It's not really a separate
>> block, and I think describing the unicam's CMI reg in the unicam binding
>> is appropriate.
>>
>> What would you need from Dave to ack this binding?
>
> Sorry, had started to reply on this and got distracted.
>
> I guess since there seems to be only 1 other bit that could possibly
> be used (CMI_USBCTL) it is fine like this. However, my concern would
> be if the CMI registers are integrated in a different way in some
> future chip that has the same unicam instances. Or just if the
> register bits are rearranged. Those are not an uncommon occurrence.
> You would have to provide access to those registers in some other way.
> It can be dealt with, but then you have to support both cases in the
> driver. If you all are fine with that, then:
The bigisland chips match bcm2835. For capri the lane enables are
shifted down by two and the clock is up at bit 20. That would be
trivial to handle based on the compatible string, except that we can't
talk to capri's hardware from ARM anyway :(
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply
* Re: [PATCH 3/6] arm: dts: marvell: Add missing #phy-cells to usb-nop-xceiv
From: Andrew Lunn @ 2017-11-21 20:56 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
arm-DgEjT+Ai2ygdnm+yROfE0A, Jason Cooper, Gregory Clement,
Sebastian Hesselbarth
In-Reply-To: <20171109222614.5719-3-robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
On Thu, Nov 09, 2017 at 04:26:11PM -0600, Rob Herring wrote:
> "usb-nop-xceiv" is using the phy binding, but is missing #phy-cells
> property. This is probably because the binding was the precursor to the phy
> binding.
>
> Fixes the following warning in Marvell dts files:
>
> Warning (phys_property): Missing property '#phy-cells' in node ...
>
> Signed-off-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Reviewed-by: Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>
Andrew
--
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 v3 2/3] leds: Add driver for Qualcomm LPG
From: Jacek Anaszewski @ 2017-11-21 22:00 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Richard Purdie, Pavel Machek, linux-kernel, linux-leds,
linux-arm-msm, Rob Herring, Mark Rutland, devicetree, Fenglin Wu
In-Reply-To: <20171120211033.GZ28761@minitux>
On 11/20/2017 10:10 PM, Bjorn Andersson wrote:
> On Sun 19 Nov 13:36 PST 2017, Jacek Anaszewski wrote:
>
>> Hi Bjorn,
>>
>> Thanks for the patch. Please refer to my comments in the code.
>>
>> On 11/15/2017 08:13 AM, Bjorn Andersson wrote:
> [..]
>>> diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
>>> index 52ea34e337cd..ccc3aa4b2474 100644
>>> --- a/drivers/leds/Kconfig
>>> +++ b/drivers/leds/Kconfig
>>> @@ -651,6 +651,13 @@ config LEDS_POWERNV
>>> To compile this driver as a module, choose 'm' here: the module
>>> will be called leds-powernv.
>>>
>>> +config LEDS_QCOM_LPG
>>> + tristate "LED support for Qualcomm LPG"
>>> + depends on LEDS_CLASS
>>
>> You were mentioning that this driver is for a MFD child block,
>> so we should probably depend on the parent MFD driver?
>>
>
> There's no build time dependency between the two, so it's not strictly
> necessary.
>
> Adding a dependency on MFD_SPMI_PMIC would indirectly add a dependency
> on ARCH_QCOM, which limit build testing and stop some static code
> checkers to check the driver.
>
> So, unless you strongly object I would prefer not to mention the MFD.
>
>>> + help
>>> + This option enables support for the Light Pulse Generator found in a
>>> + wide variety of Qualcomm PMICs.
>>> +
> [..]
>>> diff --git a/drivers/leds/leds-qcom-lpg.c b/drivers/leds/leds-qcom-lpg.c
> [..]
>>> +#define LPG_PATTERN_CONFIG_REG 0x40
>>> +#define LPG_SIZE_CLK_REG 0x41
>>> +#define LPG_PREDIV_CLK_REG 0x42
>>> +#define PWM_TYPE_CONFIG_REG 0x43
>>> +#define PWM_VALUE_REG 0x44
>>> +#define PWM_ENABLE_CONTROL_REG 0x46
>>> +#define PWM_SYNC_REG 0x47
>>> +#define LPG_RAMP_DURATION_REG 0x50
>>> +#define LPG_HI_PAUSE_REG 0x52
>>> +#define LPG_LO_PAUSE_REG 0x54
>>> +#define LPG_HI_IDX_REG 0x56
>>> +#define LPG_LO_IDX_REG 0x57
>>> +#define PWM_SEC_ACCESS_REG 0xd0
>>> +#define PWM_DTEST_REG(x) (0xe2 + (x) - 1)
>>> +
>>> +#define TRI_LED_SRC_SEL 0x45
>>> +#define TRI_LED_EN_CTL 0x46
>>> +#define TRI_LED_ATC_CTL 0x47
>>> +
>>> +#define LPG_LUT_REG(x) (0x40 + (x) * 2)
>>> +#define RAMP_CONTROL_REG 0xc8
>>
>> Please add QCOM_ namespacing prefix to the macros.
>> At least PWM prefix is reserved for pwm subsystem.
>>
>
> Will fix.
>
> [..]
>>> +static void lpg_calc_freq(struct lpg_channel *chan, unsigned int period_us)
>>> +{
>>> + int n, m, clk, div;
>>> + int best_m, best_div, best_clk;
>>> + unsigned int last_err, cur_err, min_err;
>>> + unsigned int tmp_p, period_n;
>>> +
>>> + if (period_us == chan->period_us)
>>> + return;
>>> +
>>> + /* PWM Period / N */
>>> + if (period_us < ((unsigned int)(-1) / NSEC_PER_USEC)) {
>>> + period_n = (period_us * NSEC_PER_USEC) >> 6;
>>> + n = 6;
>>> + } else {
>>> + period_n = (period_us >> 9) * NSEC_PER_USEC;
>>> + n = 9;
>>> + }
>>
>> Please provide macros for 6 and 9 magic numbers.
>>
>
> They really aren't magic numbers, they represent the number of bits of
> resolution, referred to as "size" in the rest of the driver.
>
> I'll replace "n" with "pwm_size" to clarify this. Ok?
OK.
> [..]
>>> +static void lpg_apply_freq(struct lpg_channel *chan)
>>> +{
>>> + unsigned long val;
>>> + struct lpg *lpg = chan->lpg;
>>> +
>>> + if (!chan->enabled)
>>> + return;
>>> +
>>> + /* Clock register values are off-by-one from lpg_clk_table */
>>> + val = chan->clk + 1;
>>> +
>>> + if (chan->pwm_size == 9)
>>> + val |= lpg->data->pwm_9bit_mask;
>>> +
>>> + regmap_write(lpg->map, chan->base + LPG_SIZE_CLK_REG, val);
>>> +
>>> + val = chan->pre_div << 5 | chan->pre_div_exp;
>>> + regmap_write(lpg->map, chan->base + LPG_PREDIV_CLK_REG, val);
>>
>> Please provide macros for 5 and 9.
>>
>
> 5 definitely deserves a macro.
>
> 9 is, as above, the number of bits of resolution (or "size of the pwm").
> Is there a name different than "pwm_size" that would make this more
> obvious?
pwm_res_bits or maybe you could use directly the register bit field
name from the documentation?
> [..]
>>> +static void lpg_brightness_set(struct led_classdev *cdev,
>>> + enum led_brightness value)
>>> +{
> [..]
>>> + /* Trigger start of ramp generator(s) */
>>> + if (lut_mask)
>>> + lpg_lut_sync(lpg, lut_mask);
>>
>> We need some synchronization while changing device state in
>> few steps, to prevent troubles when we are preempted by other
>> process in the middle. spin_lock() in this case since it seems
>> that we are not going to sleep while accessing device registers.
>>
>
> You're right, we need to protect the TRILED during the read-modify-write
> of the enable bits and we also need a lock around the allocation of bits
> in the LUT block. Will fix this.
>
> As far as I can see the framework is expected to protect me from
> concurrent accesses on the same LED though.
Access from sysfs is synchronized but LED subsystem API can be
called from atomic context (e.g. from hard/soft irqs), which
entails issues for drivers that sleep while setting brightness -
proper locking method has to be chosen in the driver (mutex or
spin_lock).
That's why brightness_set_blocking op was provided for drivers
sleeping on brightness setting - they can safely use mutex_lock
and the rest using spin_lock implement old brightness_set.
Before introduction of brightness_set_blocking op drivers had
to use workqueue on their own, now this is handled by the LED core.
The mutex protection in LED class sysfs interface accessors was
introduced rather to allow for locking LED subsystem sysfs interface
when v4l2-flash device controls a flash LED.
> [..]
>>> +static int lpg_add_led(struct lpg *lpg, struct device_node *np)
>>> +{
>>> + struct lpg_led *led;
>>> + const char *state;
>>> + int sources;
>>> + int size;
>>> + u32 chan;
>>> + int ret;
>>> + int i;
>>> +
>>> + sources = of_property_count_u32_elems(np, "led-sources");
>>> + if (sources <= 0) {
>>> + dev_err(lpg->dev, "invalid led-sources of %s\n",
>>> + np->name);
>>> + return -EINVAL;
>>> + }
>>> +
>>> + size = sizeof(*led) + sources * sizeof(struct lpg_channel*);
>>
>> To fix checkpatch.pl complaint:
>>
>> s/lpg_channel*/lpg_channel */
>>
>
> Sorry, will fix.
>
>>> + led = devm_kzalloc(lpg->dev, size, GFP_KERNEL);
>>> + if (!led)
>>> + return -ENOMEM;
>>> +
>>> + led->lpg = lpg;
>>> + led->num_channels = sources;
>>> +
>>> + for (i = 0; i < sources; i++) {
>>> + ret = of_property_read_u32_index(np, "led-sources",
>>> + i, &chan);
>>> + if (ret || !chan || chan > lpg->num_channels) {
>>> + dev_err(lpg->dev,
>>> + "invalid led-sources of %s\n",
>>> + np->name);
>>> + return -EINVAL;
>>> + }
>>> +
>>> + led->channels[i] = &lpg->channels[chan - 1];
>>> +
>>> + led->channels[i]->in_use = true;
>>> + }
>>> +
>>> + /* Use label else node name */
>>> + led->cdev.name = of_get_property(np, "label", NULL) ? : np->name;
>>
>> Documentation/leds/leds-class.txt states that LED class device name
>> pattern is devicename:colour:function.
>>
>> This is not explicitly stated in the common LED DT bindings, but label
>> should be prepended with devicename by the driver.
>
> I was under the impression that "devicename" referred to the board name,
> but I presume then that this refer to the name of the "LED hardware"?
Right.
>
>> Not all LED class drivers adhere to this rule and we have some mess in
>> this area currently, but we will fix it soon I hope.
>>
>
> I presume the default name should be built on the form of
> dev_name(dev)::of_node->name then?
>
> Unfortunately I can't find a single driver that does this, so please
> let me know the format you would like and I'll update the driver with
> this.
Currently the best approach is shown in the drivers/leds/leds-as3645a.c
I believe, i.e. in case label is absent, devicename is taken from the
parent DT node and function from per-LED child DT node. Please also
refer to the patch [0], which improves the code present in mainline
but has not been applied yet due to some flash LED controller related
decisions to be taken yet.
[0] https://patchwork.linuxtv.org/patch/44275/
--
Best regards,
Jacek Anaszewski
^ permalink raw reply
* Re: [PATCH v3 2/3] leds: Add driver for Qualcomm LPG
From: Jacek Anaszewski @ 2017-11-21 22:01 UTC (permalink / raw)
To: Pavel Machek, Bjorn Andersson
Cc: Richard Purdie, linux-kernel, linux-leds, linux-arm-msm,
Rob Herring, Mark Rutland, devicetree, Fenglin Wu
In-Reply-To: <20171120232211.GC13906@amd>
On 11/21/2017 12:22 AM, Pavel Machek wrote:
> On Mon 2017-11-20 13:10:33, Bjorn Andersson wrote:
>> On Sun 19 Nov 13:36 PST 2017, Jacek Anaszewski wrote:
>>
>>> Hi Bjorn,
>>>
>>> Thanks for the patch. Please refer to my comments in the code.
>>>
>>> On 11/15/2017 08:13 AM, Bjorn Andersson wrote:
>> [..]
>>>> diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
>>>> index 52ea34e337cd..ccc3aa4b2474 100644
>>>> --- a/drivers/leds/Kconfig
>>>> +++ b/drivers/leds/Kconfig
>>>> @@ -651,6 +651,13 @@ config LEDS_POWERNV
>>>> To compile this driver as a module, choose 'm' here: the module
>>>> will be called leds-powernv.
>>>>
>>>> +config LEDS_QCOM_LPG
>>>> + tristate "LED support for Qualcomm LPG"
>>>> + depends on LEDS_CLASS
>>>
>>> You were mentioning that this driver is for a MFD child block,
>>> so we should probably depend on the parent MFD driver?
>>>
>>
>> There's no build time dependency between the two, so it's not strictly
>> necessary.
>>
>> Adding a dependency on MFD_SPMI_PMIC would indirectly add a dependency
>> on ARCH_QCOM, which limit build testing and stop some static code
>> checkers to check the driver.
>>
>> So, unless you strongly object I would prefer not to mention the
>> MFD.
>
> OTOH, this way even users that can't have qualcom LPG are asked the
> question.
>
> So right way is depends on LEdS_CLASS && (BUILD_TEST || MFD_SPMI_PMIC).
Ack.
--
Best regards,
Jacek Anaszewski
^ permalink raw reply
* Re: [PATCH 1/2] usb: xhci: add relaxed timing quirk bit
From: Adam Wallis @ 2017-11-22 0:07 UTC (permalink / raw)
To: Rob Herring
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Greg Kroah-Hartman, Mathias Nyman, Linux USB List,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Mark Rutland,
Timur Tabi
In-Reply-To: <CAL_JsqLZgnTTEiLXD8ZOK-0qd58i16e7h_-2yjHN+zRFfqvH4Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 11/21/2017 3:06 PM, Rob Herring wrote:
[..]
>> I like where you are going with this. Are you saying that I could read for a
>> device property read from firmware (for DTB or ACPI) like DWC3 does for
>> "snps,hird-threshold"?
>
> Is that for the same thing? If so, drop the vendor prefix and use
> that. Otherwise, a separate property should really be something that
> is per board rather than per SoC.
I don't think that's exactly the same property, but it's the same idea I would
prefer to go with. That way, an integer can be passed in via the firmware tables.
>
>> If you mean this, where do you recommend I store the
>> desired IRQ_CONTROL value - in struct xhci_hcd ?
>
> No idea.
>
>> Or by "compatible" strings, did you mean storing hard-coded values in the
>> of_device_id usb_xhci_of_match[] array? This would still be hard-coding (which I
>> would like to avoid) and also would not work for the ACPI case.
>
> ACPI has match tables too?
>
Yes, you can use DSD in a way that is similar to OF properties
> It would only be hardcoded per compatible which should be per SoC. Do
> you need per board/device tuning? If so, use a property.
>
The reason why I think it should dynamic via firmware tables is that
* It's much less invasive for vendors to update their DT tables if they need to
adjust on a per device/controller/family/etc basis then to adjust a properties
table in xhci-plat
* This would lead to less polluting in xhci-plat code
> Rob
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
I will provide an updated proposed patch sometime this week. I also hope to get
some feedback from Mathias to see what he prefers.
Thanks again for the feedback Rob.
--
Adam Wallis
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.
--
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: [patches] Re: [PATCH] dt-bindings: Add a RISC-V SBI firmware node
From: Palmer Dabbelt @ 2017-11-22 0:36 UTC (permalink / raw)
Cc: robh-DgEjT+Ai2ygdnm+yROfE0A, j.neuschaefer-hi6Y0CQ0nG0,
mark.rutland-5wv7dgnIgG8, devicetree-u79uwXL29TY76Z2rM5mHXA,
patches-q3qR2WxjNRFS9aJRtSZj7A,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171121200832.d55khzcufo2owcff@latitude>
On Tue, 21 Nov 2017 12:08:32 PST (-0800), j.neuschaefer-hi6Y0CQ0nG0@public.gmane.org wrote:
> On Tue, Nov 21, 2017 at 09:37:02AM -0800, Palmer Dabbelt wrote:
> [...]
>> This isn't really a big deal to me, as I'm only interested in RISC-V
>> systems, but there's been some pushback on the concept of an SBI so it
>> seemed like a simple way to allow people to build non-SBI (and there for not
>> really RISC-V) systems.
>
> For those reading along: I suggested the /firmware/sbi node to Palmer,
> because I'm interested in such "not really RISC-V" systems, (because it
> makes the firmware's job easier to not implement the SBI — speaking with
> my coreboot hat, here.)
>
>> One option that wouldn't require a device tree node
>> would be to have Linux boot in machine mode [...] and then provide its
>> own SBI implementation.
>
> I think this can work.
OK, sounds good!
--
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] arm64: dts: ls1088a: Add USB support
From: Yinbo Zhu @ 2017-11-22 1:32 UTC (permalink / raw)
To: Shawn Guo
Cc: Rob Herring, Mark Rutland, Catalin Marinas ), Will Deacon ),
Harninder Rai, Raghav Dogra, Ashish Kumar, Andy Tang,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
open list
In-Reply-To: <AM3PR04MB12515DB71B8ACF7422A20244E9280-f56W/S9L6NR31AIMYRlgnc9NdZoXdze2vxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
Hi
-----Original Message-----
From: Yinbo Zhu
Sent: Tuesday, November 14, 2017 4:00 PM
To: 'Shawn Guo' <shawnguo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: 'Rob Herring' <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>; 'Mark Rutland' <mark.rutland-AbSShOkvfpQ@public.gmane.orgm>; 'Catalin Marinas )' <catalin.marinas-5wv7dgnIgG8@public.gmane.org>; 'Will Deacon )' <will.deacon-5wv7dgnIgG8@public.gmane.org>; Harninder Rai <harninder.rai-3arQi8VN3Tc@public.gmane.org>; 'Raghav Dogra' <raghav.dogra-3arQi8VN3Tc@public.gmane.org>; Ashish Kumar <ashish.kumar-3arQi8VN3Tc@public.gmane.org>; Andy Tang <andy.tang@nxp.com>; 'open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS' <devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>; 'linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org' <linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>; 'open list' <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: RE: [PATCH v2] arm64: dts: ls1088a: Add USB support
-----Original Message-----
From: Yinbo Zhu
Sent: Tuesday, October 24, 2017 5:15 PM
To: Shawn Guo <shawnguo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>; Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>; Catalin Marinas ) <catalin.marinas-5wv7dgnIgG8@public.gmane.org>; Will Deacon ) <will.deacon@arm.com>; Harninder Rai <harninder.rai-3arQi8VN3Tc@public.gmane.org>; Raghav Dogra <raghav.dogra@nxp.com>; Ashish Kumar <ashish.kumar-3arQi8VN3Tc@public.gmane.org>; Andy Tang <andy.tang-3arQi8VN3Tc@public.gmane.org>; open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS <devicetree@vger.kernel.org>; linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org; open list <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH v2] arm64: dts: ls1088a: Add USB support
-----Original Message-----
From: Shawn Guo [mailto:shawnguo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org]
Sent: Friday, September 22, 2017 2:55 PM
To: Yinbo Zhu <yinbo.zhu-3arQi8VN3Tc@public.gmane.org>
Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>; Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>; Catalin Marinas ) <catalin.marinas-5wv7dgnIgG8@public.gmane.org>; Will Deacon ) <will.deacon@arm.com>; Harninder Rai <harninder.rai-3arQi8VN3Tc@public.gmane.org>; Raghav Dogra <raghav.dogra@nxp.com>; Ashish Kumar <ashish.kumar-3arQi8VN3Tc@public.gmane.org>; Andy Tang <andy.tang-3arQi8VN3Tc@public.gmane.org>; open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS <devicetree@vger.kernel.org>; linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org; open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] arm64: dts: ls1088a: Add USB support
On Wed, Sep 13, 2017 at 05:10:09PM +0800, yinbo.zhu-3arQi8VN3Tc@public.gmane.org wrote:
> From: "yinbo.zhu" <yinbo.zhu-3arQi8VN3Tc@public.gmane.org>
>
> Fix the issue that usb is not detected on ls1088ardb
>It's not really about fixing issue but adding support.
The patch had been tested on upstream 4.14 code, it can fix the issue.
>
> Signed-off-by: yinbo.zhu <yinbo.zhu-3arQi8VN3Tc@public.gmane.org>
> Signed-off-by: Ran Wang <ran.wang_1-3arQi8VN3Tc@public.gmane.org>
> ---
>You should better have a version history here to tell what's changed between version.
>I will add a version history on next v3 patch
Hi,
I had modified the code as v4 version,
https://patchwork.kernel.org/patch/10027393/
please check.
Thanks,
BRs
> arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts | 8 ++++++++
> arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 20 ++++++++++++++++++++
> 2 files changed, 28 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts
> b/arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts
> index 213abb72de93..6c3c3bc4b681 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts
> @@ -118,6 +118,14 @@
> status = "okay";
> };
>
> +&usb0 {
> + status = "okay";
> +};
> +
> +&usb1 {
> + status = "okay";
> +};
> +
> &esdhc {
>Please sort these labeled nodes alphabetically.
>Shawn
> status = "okay";
> };
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> index c144d06a6e33..c23fede8cf5d 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> @@ -359,6 +359,26 @@
> status = "disabled";
> };
>
> + usb0: usb3@3100000 {
> + compatible = "snps,dwc3";
> + reg = <0x0 0x3100000 0x0 0x10000>;
> + interrupts = <0 80 IRQ_TYPE_LEVEL_HIGH>;
> + dr_mode = "host";
> + snps,quirk-frame-length-adjustment = <0x20>;
> + snps,dis_rxdet_inp3_quirk;
> + status = "disabled";
> + };
> +
> + usb1: usb3@3110000 {
> + compatible = "snps,dwc3";
> + reg = <0x0 0x3110000 0x0 0x10000>;
> + interrupts = <0 81 IRQ_TYPE_LEVEL_HIGH>;
> + dr_mode = "host";
> + snps,quirk-frame-length-adjustment = <0x20>;
> + snps,dis_rxdet_inp3_quirk;
> + status = "disabled";
> + };
> +
> sata: sata@3200000 {
> compatible = "fsl,ls1088a-ahci";
> reg = <0x0 0x3200000 0x0 0x10000>,
> --
> 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
* Re: [PATCH v2 1/3] media: V3s: Add support for Allwinner CSI.
From: Yong @ 2017-11-22 1:33 UTC (permalink / raw)
To: Maxime Ripard
Cc: Mauro Carvalho Chehab, Rob Herring, Mark Rutland, Chen-Yu Tsai,
Greg Kroah-Hartman, David S. Miller, Hans Verkuil, Arnd Bergmann,
Hugues Fruchet, Yannick Fertre, Philipp Zabel, Benoit Parrot,
Benjamin Gaignard, Jean-Christophe Trotin,
Ramesh Shanmugasundaram, Minghsiu Tsai, Krzysztof Kozlowski,
Robert Jarzmik, linux-media-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-sun
In-Reply-To: <20171121154827.5a35xa6zlqrrvkxx-ZC1Zs529Oq4@public.gmane.org>
On Tue, 21 Nov 2017 16:48:27 +0100
Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> Hi,
>
> On Thu, Jul 27, 2017 at 01:01:35PM +0800, Yong Deng wrote:
> > Allwinner V3s SoC have two CSI module. CSI0 is used for MIPI interface
> > and CSI1 is used for parallel interface. This is not documented in
> > datasheet but by testing and guess.
> >
> > This patch implement a v4l2 framework driver for it.
> >
> > Currently, the driver only support the parallel interface. MIPI-CSI2,
> > ISP's support are not included in this patch.
> >
> > Signed-off-by: Yong Deng <yong.deng-+3dxTMOEIRNWk0Htik3J/w@public.gmane.org>
>
> Thanks again for this driver.
>
> It seems like at least this iteration is behaving in a weird way with
> DMA transfers for at least YU12 and NV12 (and I would assume YV12).
>
> Starting a transfer of multiple frames in either of these formats,
> using either ffmpeg (ffmpeg -f v4l2 -video_size 640x480 -framerate 30
> -i /dev/video0 output.mkv) or yavta (yavta -c80 -p -F --skip 0 -f NV12
> -s 640x480 $(media-c tl -e 'sun6i-csi')) will end up in a panic.
>
> The panic seems to be generated with random data going into parts of
> the kernel memory, the pattern being in my case something like
> 0x8287868a which is very odd (always around 0x88)
>
> It turns out that when you cover the sensor, the values change to
> around 0x28, so it really seems like it's pixels that have been copied
> there.
>
> I've looked quickly at the DMA setup, and it seems reasonable to
> me. Do you have the same issue on your side? Have you been able to
> test those formats using your hardware?
I had tested the following formats with BT1120 input:
V4L2_PIX_FMT_NV12 -> NV12
V4L2_PIX_FMT_NV21 -> NV21
V4L2_PIX_FMT_NV16 -> NV16
V4L2_PIX_FMT_NV61 -> NV61
V4L2_PIX_FMT_YUV420 -> YU12
V4L2_PIX_FMT_YVU420 -> YV12
V4L2_PIX_FMT_YUV422P -> 422P
And they all work fine.
>
> Given that they all are planar formats and YUYV and the likes work
> just fine, maybe we can leave them aside for now?
V4L2_PIX_FMT_YUV422P and V4L2_PIX_FMT_YUYV is OK, and V4L2_PIX_FMT_NV12
is bad? It's really weird.
What's your input bus code format, type and width?
>
> Thanks!
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
Thanks,
Yong
^ permalink raw reply
* Re: [PATCH 1/5] checks: add a string checks for label, bootargs and stdout-path
From: David Gibson @ 2017-11-22 3:12 UTC (permalink / raw)
To: Rob Herring
Cc: Devicetree Compiler,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <CAL_JsqJUpgBC1awgTZgz3pwhYUL02ES=E-ogqVONxDFjg8eSag-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1793 bytes --]
On Mon, Nov 20, 2017 at 11:26:49AM -0600, Rob Herring wrote:
> On Sun, Nov 19, 2017 at 6:09 PM, David Gibson
> <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org> wrote:
> > On Fri, Nov 17, 2017 at 08:45:11AM -0600, Rob Herring wrote:
> >> Add more string property checks for label, bootargs, and stdout-path.
> >
> > Where does 'label' appear? I'm not immediately recalling it as a
> > property with global meaning.
>
> It's documented in DT spec/ePAPR. It can be anywhere. It's the
> property for the human readable identifiers such as the label on
> ethernet ports, serial ports, LEDs, etc.
Ah, ok. I'd completely forgotten about that one. Ok, that's a fine
check then.
> > bootargs and stdout-path are from /chosen of course. I have some
> > mixed feelings about whether it's reasonable to check it's a string
> > everywhere, rather than specifically just in /chosen.
>
> We don't really want to see the same property names with different
> meanings.
Hm. As a rule of thumb, yes, but I don't know that it's super
important for properties that aren't very common. Even then /chosen
is really special.
> I think checking the location is a separate check. You've
> generally suggested splitting up tests rather than have all in one
> tests. Not sure if we should check known properties only appear in
> chosen or that chosen only has known properties (assuming we can
> enumerate that list. Maybe we allow things like "linux,*").
I think for now a better approach would be to add one or more checks
specifically to validate the /chosen node.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [RFCv2 PATCH 01/36] iommu: Keep track of processes and PASIDs
From: Bob Liu @ 2017-11-22 3:15 UTC (permalink / raw)
To: Jean-Philippe Brucker, linux-arm-kernel, linux-pci, linux-acpi,
devicetree, iommu
Cc: joro, robh+dt, mark.rutland, catalin.marinas, will.deacon,
lorenzo.pieralisi, hanjun.guo, sudeep.holla, rjw, lenb,
robin.murphy, bhelgaas, alex.williamson, tn, thunder.leizhen,
xieyisheng1, gabriele.paoloni, nwatters, okaya, rfranz, dwmw2,
jacob.jun.pan, yi.l.liu, ashok.raj, robdclark
In-Reply-To: <20171006133203.22803-2-jean-philippe.brucker@arm.com>
Hey Jean,
On 2017/10/6 21:31, Jean-Philippe Brucker wrote:
> IOMMU drivers need a way to bind Linux processes to devices. This is used
> for Shared Virtual Memory (SVM), where devices support paging. In that
> mode, DMA can directly target virtual addresses of a process.
>
> Introduce boilerplate code for allocating process structures and binding
> them to devices. Four operations are added to IOMMU drivers:
>
> * process_alloc, process_free: to create an iommu_process structure and
> perform architecture-specific operations required to grab the process
> (for instance on ARM SMMU, pin down the CPU ASID). There is a single
> iommu_process structure per Linux process.
>
I'm a bit confused here.
The original meaning of iommu_domain is a virtual addrspace defined by a set of io page table.
(fix me if I misunderstood).
Then what's the meaning of iommu_domain and iommu_process after introducing iommu_process?
Could you consider document these concepts?
Thanks,
Liubo
^ permalink raw reply
* Re: [PATCH 4/5] checks: check for #{size,address}-cells without child nodes
From: David Gibson @ 2017-11-22 3:18 UTC (permalink / raw)
To: Rob Herring
Cc: Devicetree Compiler,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <CAL_JsqJoiBvD-QE5bgk5ob3qc65ar371xWxx-1D+fKGh7+P=Zw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2217 bytes --]
On Mon, Nov 20, 2017 at 10:22:53AM -0600, Rob Herring wrote:
> On Sun, Nov 19, 2017 at 6:14 PM, David Gibson
> <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org> wrote:
> > On Fri, Nov 17, 2017 at 08:45:14AM -0600, Rob Herring wrote:
> >> nodes with a 'reg' property nor a ranges property.
> >>
> >> An exception may be an overlay that adds nodes, but this case would
> >> need
> >
> > Sentence doesn't seem finished..
>
> It was there until I rebased. Since the line started with #, git dropped it...
>
> "#{size,address}-cells in the overlay to properly compile already."
Ah, right.
> > In any case, I'm not sure this is a good idea. It's not uncommon to
> > have bus bridge nodes that ought to have a well defined #address and
> > #size cells, but just don't happen to have any plugged devices yet.
> > An overlay that adds nodes is one possibility, but a bus where the
> > children can be probed is another.
>
> Wouldn't an overlay without #{size,address}-cells have warnings from
> avoid_default_addr_size?
Well, yes. The checks are pretty much designed for whole trees and
don't work well on overlays at the moment. That's a rather more
substantial change to fix.
> As long as there are no child nodes, the check is not run.
Ah! Sorry, I missed that. Objection withdrawn in that case.
> So we're
> limited to false positives if we have a mixture of nodes with and
> without unit addresses and only the nodes without unit addresses are
> populated. I have seen this with PCI hosts with an interrupt
> controller child node.
Sounds like an incorrect representation if the intrrupt controller
doesn't have a PCI config space presence.
> In general, I'm struggling with how to have tests that check for
> things that we generally want to avoid, but we still allow exceptions.
> Some of these may be things we want to avoid in new bindings, but
> wouldn't fix for existing cases. Another example is things that
> were/are valid for OF, but not FDT.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ 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-22 4:17 UTC (permalink / raw)
To: 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,
Mauro Carvalho Chehab
Cc: tbird20d-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
Yamamoto, Masayuki, Nozawa, Hideki (STWN), Yonezawa, Kota,
Matsumoto, Toshihiko, Watanabe, Satoshi (SSS),
yasunari.takiguchi-7U/KSKJipcs
In-Reply-To: <67ca63fc-4675-8a97-e43e-6336bbc9fada-7U/KSKJipcs@public.gmane.org>
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?
Regards,
Takiguchi
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/5] media: dt-bindings: Add bindings for TDA1997X
From: Sakari Ailus @ 2017-11-22 7:36 UTC (permalink / raw)
To: Tim Harvey
Cc: devicetree, alsa-devel, Rob Herring, linux-kernel, Hans Verkuil,
Mauro Carvalho Chehab, Philipp Zabel, Steve Longerbeam, shawnguo,
linux-media
In-Reply-To: <1510253136-14153-3-git-send-email-tharvey@gateworks.com>
Hi Tim,
On Thu, Nov 09, 2017 at 10:45:33AM -0800, Tim Harvey wrote:
> Cc: Rob Herring <robh@kernel.org>
> Signed-off-by: Tim Harvey <tharvey@gateworks.com>
> ---
> v3:
> - fix typo
>
> v2:
> - add vendor prefix and remove _ from vidout-portcfg
> - remove _ from labels
> - remove max-pixel-rate property
> - describe and provide example for single output port
> - update to new audio port bindings
> ---
> .../devicetree/bindings/media/i2c/tda1997x.txt | 179 +++++++++++++++++++++
> 1 file changed, 179 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/i2c/tda1997x.txt
>
> diff --git a/Documentation/devicetree/bindings/media/i2c/tda1997x.txt b/Documentation/devicetree/bindings/media/i2c/tda1997x.txt
> new file mode 100644
> index 0000000..dd37f14
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/i2c/tda1997x.txt
> @@ -0,0 +1,179 @@
> +Device-Tree bindings for the NXP TDA1997x HDMI receiver
> +
> +The TDA19971/73 are HDMI video receivers.
> +
> +The TDA19971 Video port output pins can be used as follows:
> + - RGB 8bit per color (24 bits total): R[11:4] B[11:4] G[11:4]
> + - YUV444 8bit per color (24 bits total): Y[11:4] Cr[11:4] Cb[11:4]
> + - YUV422 semi-planar 8bit per component (16 bits total): Y[11:4] CbCr[11:4]
> + - YUV422 semi-planar 10bit per component (20 bits total): Y[11:2] CbCr[11:2]
> + - YUV422 semi-planar 12bit per component (24 bits total): - Y[11:0] CbCr[11:0]
> + - YUV422 BT656 8bit per component (8 bits total): YCbCr[11:4] (2-cycles)
> + - YUV422 BT656 10bit per component (10 bits total): YCbCr[11:2] (2-cycles)
> + - YUV422 BT656 12bit per component (12 bits total): YCbCr[11:0] (2-cycles)
> +
> +The TDA19973 Video port output pins can be used as follows:
> + - RGB 12bit per color (36 bits total): R[11:0] B[11:0] G[11:0]
> + - YUV444 12bit per color (36 bits total): Y[11:0] Cb[11:0] Cr[11:0]
> + - YUV422 semi-planar 12bit per component (24 bits total): Y[11:0] CbCr[11:0]
> + - YUV422 BT656 12bit per component (12 bits total): YCbCr[11:0] (2-cycles)
> +
> +The Video port output pins are mapped via 4-bit 'pin groups' allowing
> +for a variety of connection possibilities including swapping pin order within
> +pin groups. The video_portcfg device-tree property consists of register mapping
> +pairs which map a chip-specific VP output register to a 4-bit pin group. If
> +the pin group needs to be bit-swapped you can use the *_S pin-group defines.
> +
> +Required Properties:
> + - compatible :
> + - "nxp,tda19971" for the TDA19971
> + - "nxp,tda19973" for the TDA19973
> + - reg : I2C slave address
> + - interrupts : The interrupt number
> + - DOVDD-supply : Digital I/O supply
> + - DVDD-supply : Digital Core supply
> + - AVDD-supply : Analog supply
> + - nxp,vidout-portcfg : array of pairs mapping VP output pins to pin groups.
> +
> +Optional Properties:
> + - nxp,audout-format : DAI bus format: "i2s" or "spdif".
> + - nxp,audout-width : width of audio output data bus (1-4).
> + - nxp,audout-layout : data layout (0=AP0 used, 1=AP0/AP1/AP2/AP3 used).
> + - nxp,audout-mclk-fs : Multiplication factor between stream rate and codec
> + mclk.
> +
> +The device node must contain one 'port' child node for its digital output
> +video port, in accordance with the video interface bindings defined in
> +Documentation/devicetree/bindings/media/video-interfaces.txt.
Could you add that this port has one endpoint node as well? (Unless you
support multiple, that is.)
> +
> +Optional Endpoint Properties:
> + The following three properties are defined in video-interfaces.txt and
> + are valid for source endpoints only:
Transmitters? Don't you have an endpoint only in the port representing the
transmitter?
> + - hsync-active: Horizontal synchronization polarity. Defaults to active high.
> + - vsync-active: Vertical synchronization polarity. Defaults to active high.
> + - data-active: Data polarity. Defaults to active high.
> +
> +Examples:
> + - VP[15:0] connected to IMX6 CSI_DATA[19:4] for 16bit YUV422
> + 16bit I2S layout0 with a 128*fs clock (A_WS, AP0, A_CLK pins)
> + hdmi-receiver@48 {
> + compatible = "nxp,tda19971";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_tda1997x>;
> + reg = <0x48>;
> + interrupt-parent = <&gpio1>;
> + interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
> + DOVDD-supply = <®_3p3v>;
> + AVDD-supply = <®_1p8v>;
> + DVDD-supply = <®_1p8v>;
> + /* audio */
> + #sound-dai-cells = <0>;
> + nxp,audout-format = "i2s";
> + nxp,audout-layout = <0>;
> + nxp,audout-width = <16>;
> + nxp,audout-mclk-fs = <128>;
> + /*
> + * The 8bpp YUV422 semi-planar mode outputs CbCr[11:4]
> + * and Y[11:4] across 16bits in the same pixclk cycle.
> + */
> + nxp,vidout-portcfg =
> + /* Y[11:8]<->VP[15:12]<->CSI_DATA[19:16] */
> + < TDA1997X_VP24_V15_12 TDA1997X_G_Y_11_8 >,
> + /* Y[7:4]<->VP[11:08]<->CSI_DATA[15:12] */
> + < TDA1997X_VP24_V11_08 TDA1997X_G_Y_7_4 >,
> + /* CbCc[11:8]<->VP[07:04]<->CSI_DATA[11:8] */
> + < TDA1997X_VP24_V07_04 TDA1997X_R_CR_CBCR_11_8 >,
> + /* CbCr[7:4]<->VP[03:00]<->CSI_DATA[7:4] */
> + < TDA1997X_VP24_V03_00 TDA1997X_R_CR_CBCR_7_4 >;
> +
> + port {
> + tda1997x_to_ipu1_csi0_mux: endpoint {
> + remote-endpoint = <&ipu1_csi0_mux_from_parallel_sensor>;
> + bus-width = <16>;
> + hsync-active = <1>;
> + vsync-active = <1>;
> + data-active = <1>;
> + };
> + };
> + };
> + - VP[15:8] connected to IMX6 CSI_DATA[19:12] for 8bit BT656
> + 16bit I2S layout0 with a 128*fs clock (A_WS, AP0, A_CLK pins)
> + hdmi-receiver@48 {
> + compatible = "nxp,tda19971";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_tda1997x>;
> + reg = <0x48>;
> + interrupt-parent = <&gpio1>;
> + interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
> + DOVDD-supply = <®_3p3v>;
> + AVDD-supply = <®_1p8v>;
> + DVDD-supply = <®_1p8v>;
> + /* audio */
> + #sound-dai-cells = <0>;
> + nxp,audout-format = "i2s";
> + nxp,audout-layout = <0>;
> + nxp,audout-width = <16>;
> + nxp,audout-mclk-fs = <128>;
> + /*
> + * The 8bpp YUV422 semi-planar mode outputs CbCr[11:4]
> + * and Y[11:4] across 16bits in the same pixclk cycle.
> + */
> + nxp,vidout-portcfg =
> + /* Y[11:8]<->VP[15:12]<->CSI_DATA[19:16] */
> + < TDA1997X_VP24_V15_12 TDA1997X_G_Y_11_8 >,
> + /* Y[7:4]<->VP[11:08]<->CSI_DATA[15:12] */
> + < TDA1997X_VP24_V11_08 TDA1997X_G_Y_7_4 >,
> + /* CbCc[11:8]<->VP[07:04]<->CSI_DATA[11:8] */
> + < TDA1997X_VP24_V07_04 TDA1997X_R_CR_CBCR_11_8 >,
> + /* CbCr[7:4]<->VP[03:00]<->CSI_DATA[7:4] */
> + < TDA1997X_VP24_V03_00 TDA1997X_R_CR_CBCR_7_4 >;
> +
> + port {
> + tda1997x_to_ipu1_csi0_mux: endpoint {
> + remote-endpoint = <&ipu1_csi0_mux_from_parallel_sensor>;
> + bus-width = <16>;
> + hsync-active = <1>;
> + vsync-active = <1>;
> + data-active = <1>;
> + };
> + };
> + };
> + - VP[15:8] connected to IMX6 CSI_DATA[19:12] for 8bit BT656
> + 16bit I2S layout0 with a 128*fs clock (A_WS, AP0, A_CLK pins)
> + hdmi-receiver@48 {
> + compatible = "nxp,tda19971";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_tda1997x>;
> + reg = <0x48>;
> + interrupt-parent = <&gpio1>;
> + interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
> + DOVDD-supply = <®_3p3v>;
> + AVDD-supply = <®_1p8v>;
> + DVDD-supply = <®_1p8v>;
> + /* audio */
> + #sound-dai-cells = <0>;
> + nxp,audout-format = "i2s";
> + nxp,audout-layout = <0>;
> + nxp,audout-width = <16>;
> + nxp,audout-mclk-fs = <128>;
> + /*
> + * The 8bpp BT656 mode outputs YCbCr[11:4] across 8bits over
> + * 2 pixclk cycles.
> + */
> + nxp,vidout-portcfg =
> + /* YCbCr[11:8]<->VP[15:12]<->CSI_DATA[19:16] */
> + < TDA1997X_VP24_V15_12 TDA1997X_R_CR_CBCR_11_8 >,
> + /* YCbCr[7:4]<->VP[11:08]<->CSI_DATA[15:12] */
> + < TDA1997X_VP24_V11_08 TDA1997X_R_CR_CBCR_7_4 >,
> +
> + port {
> + tda1997x_to_ipu1_csi0_mux: endpoint {
> + remote-endpoint = <&ipu1_csi0_mux_from_parallel_sensor>;
> + bus-width = <16>;
> + hsync-active = <1>;
> + vsync-active = <1>;
> + data-active = <1>;
> + };
> + };
> + };
> +
> --
> 2.7.4
>
--
Sakari Ailus
e-mail: sakari.ailus@iki.fi
^ permalink raw reply
* Re: [PATCH v2 1/3] media: V3s: Add support for Allwinner CSI.
From: Maxime Ripard @ 2017-11-22 9:45 UTC (permalink / raw)
To: Yong
Cc: Mauro Carvalho Chehab, Rob Herring, Mark Rutland, Chen-Yu Tsai,
Greg Kroah-Hartman, David S. Miller, Hans Verkuil, Arnd Bergmann,
Hugues Fruchet, Yannick Fertre, Philipp Zabel, Benoit Parrot,
Benjamin Gaignard, Jean-Christophe Trotin,
Ramesh Shanmugasundaram, Minghsiu Tsai, Krzysztof Kozlowski,
Robert Jarzmik, linux-media-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171122093306.d30fe641f269d62daa1f66b4-+3dxTMOEIRNWk0Htik3J/w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2444 bytes --]
Hi,
On Wed, Nov 22, 2017 at 09:33:06AM +0800, Yong wrote:
> > On Thu, Jul 27, 2017 at 01:01:35PM +0800, Yong Deng wrote:
> > > Allwinner V3s SoC have two CSI module. CSI0 is used for MIPI interface
> > > and CSI1 is used for parallel interface. This is not documented in
> > > datasheet but by testing and guess.
> > >
> > > This patch implement a v4l2 framework driver for it.
> > >
> > > Currently, the driver only support the parallel interface. MIPI-CSI2,
> > > ISP's support are not included in this patch.
> > >
> > > Signed-off-by: Yong Deng <yong.deng-+3dxTMOEIRNWk0Htik3J/w@public.gmane.org>
> >
> > Thanks again for this driver.
> >
> > It seems like at least this iteration is behaving in a weird way with
> > DMA transfers for at least YU12 and NV12 (and I would assume YV12).
> >
> > Starting a transfer of multiple frames in either of these formats,
> > using either ffmpeg (ffmpeg -f v4l2 -video_size 640x480 -framerate 30
> > -i /dev/video0 output.mkv) or yavta (yavta -c80 -p -F --skip 0 -f NV12
> > -s 640x480 $(media-c tl -e 'sun6i-csi')) will end up in a panic.
> >
> > The panic seems to be generated with random data going into parts of
> > the kernel memory, the pattern being in my case something like
> > 0x8287868a which is very odd (always around 0x88)
> >
> > It turns out that when you cover the sensor, the values change to
> > around 0x28, so it really seems like it's pixels that have been copied
> > there.
> >
> > I've looked quickly at the DMA setup, and it seems reasonable to
> > me. Do you have the same issue on your side? Have you been able to
> > test those formats using your hardware?
>
> I had tested the following formats with BT1120 input:
> V4L2_PIX_FMT_NV12 -> NV12
> V4L2_PIX_FMT_NV21 -> NV21
> V4L2_PIX_FMT_NV16 -> NV16
> V4L2_PIX_FMT_NV61 -> NV61
> V4L2_PIX_FMT_YUV420 -> YU12
> V4L2_PIX_FMT_YVU420 -> YV12
> V4L2_PIX_FMT_YUV422P -> 422P
> And they all work fine.
Ok, that's good to know.
> > Given that they all are planar formats and YUYV and the likes work
> > just fine, maybe we can leave them aside for now?
>
> V4L2_PIX_FMT_YUV422P and V4L2_PIX_FMT_YUYV is OK, and V4L2_PIX_FMT_NV12
> is bad? It's really weird.
>
> What's your input bus code format, type and width?
The sensor is an ov5640, so the MBUS code for the bus is
MEDIA_BUS_FMT_YUYV8_2X8.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH v2 2/6] dt-bindings: Add vendor prefix for Solomon Goldentek Display Corporation
From: Neil Armstrong @ 2017-11-22 11:02 UTC (permalink / raw)
To: shawnguo, kernel, fabio.estevam
Cc: Neil Armstrong, linux-arm-kernel, linux-kernel, devicetree
In-Reply-To: <1511348560-28505-1-git-send-email-narmstrong@baylibre.com>
Solomon Goldentek Display Corporation is a Taiwanese LCD/LCM manufacturer.
Company Site: http://www.goldentek.com.tw
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 0994bdd..b0d3bef 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -305,6 +305,7 @@ seagate Seagate Technology PLC
semtech Semtech Corporation
sensirion Sensirion AG
sff Small Form Factor Committee
+sgd Solomon Goldentek Display Corporation
sgx SGX Sensortech
sharp Sharp Corporation
shimafuji Shimafuji Electric, Inc.
--
2.7.4
^ permalink raw reply related
* [PATCH v2 3/6] devicetree/bindings: display: Add bindings for SGD GKTW70SDAE4SE Panel
From: Neil Armstrong @ 2017-11-22 11:02 UTC (permalink / raw)
To: shawnguo, kernel, fabio.estevam
Cc: Neil Armstrong, linux-arm-kernel, linux-kernel, devicetree
In-Reply-To: <1511348560-28505-1-git-send-email-narmstrong@baylibre.com>
The GKTW70SDAE4SE is an LVDS display panel.
Their bindings are modelled on the the LVDS panel bindings.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
.../bindings/display/panel/sgd,gktw70sdae4se.txt | 41 ++++++++++++++++++++++
1 file changed, 41 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/panel/sgd,gktw70sdae4se.txt
diff --git a/Documentation/devicetree/bindings/display/panel/sgd,gktw70sdae4se.txt b/Documentation/devicetree/bindings/display/panel/sgd,gktw70sdae4se.txt
new file mode 100644
index 0000000..d06644b
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/sgd,gktw70sdae4se.txt
@@ -0,0 +1,41 @@
+Solomon Goldentek Display GKTW70SDAE4SE LVDS Display Panel
+==========================================================
+
+The GKTW70SDAE4SE is a 7" WVGA TFT-LCD display panel.
+
+These DT bindings follow the LVDS panel bindings defined in panel-lvds.txt
+with the following device-specific properties.
+
+Required properties:
+
+- compatible: Shall contain "sgd,gktw70sdae4se" and "panel-lvds", in that order.
+
+Example
+-------
+
+panel {
+ compatible = "sgd,gktw70sdae4se", "panel-lvds";
+
+ width-mm = <153>;
+ height-mm = <86>;
+
+ data-mapping = "jeida-18";
+
+ panel-timing {
+ clock-frequency = <32000000>;
+ hactive = <800>;
+ vactive = <480>;
+ hback-porch = <39>;
+ hfront-porch = <39>;
+ vback-porch = <29>;
+ vfront-porch = <13>;
+ hsync-len = <47>;
+ vsync-len = <2>;
+ };
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&lvds_encoder>;
+ };
+ };
+};
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] ARM: dts: bcm283x: Fix fifo size for EP 6,7
From: Stefan Wahren @ 2017-11-22 11:21 UTC (permalink / raw)
To: Minas Harutyunyan
Cc: Phil Elwell, John Youn, Eric Anholt, Rob Herring,
linux-usb-u79uwXL29TY76Z2rM5mHXA, Florian Fainelli, Mark Rutland,
linux-rpi-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <410670D7E743164D87FA6160E7907A560113A41084-ouFQeoKRuQ8bQ7k9MBbv4fufCSb+aD3WLzEdoUbNIic@public.gmane.org>
Hi Minas,
> Minas Harutyunyan <Minas.Harutyunyan-HKixBCOQz3hWk0Htik3J/w@public.gmane.org> hat am 21. November 2017 um 13:02 geschrieben:
>
> Hi Stefan,
>
> We have prepared patch for this issue in July-August'17.
> Find attached 2 patch files. Please apply patches and test. If issue
> gone, we will send these patches to LKML by regular flow.
thanks, but the first patch doesn't apply. My version see below, i hope i didn't break anything.
Unfortunately after applying both patches the issue still persists (EP 1-7 fifo size to 512) and the EP 1-7 TX total size increases from 3776 to 3792. I will follow my u-boot theory ...
>From 12fcc090bc7588275c1d942009676cb3fa5129f2 Mon Sep 17 00:00:00 2001
From: Gevorg Sahakyan <sahakyan-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
Date: Wed, 22 Nov 2017 11:15:16 +0100
Subject: [PATCH] usb: dwc2: Fix TxFIFO setup issue
In host mode reading from DPTXSIZn returning invalid value(0) in
dwc2_check_param_tx_fifo_sizes function.
Added g_tx_fifo_size array in dwc2_hw_params structure in which stored
power on reset valus of DPTXSIZn registers in device mode (forced to
device).
Updated dwc2_get_hwparams function to write DPTXFSIZn to array.
Modyfied dwc2_check_param_tx_fifo_sizes function accordingly.
Change-Id: I61d3db753b1bc06f0f2caf40df350a09655f18fd
Signed-off-by: Gevorg Sahakyan <sahakyan-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
Signed-off-by: Stefan Wahren <stefan.wahren-eS4NqCHxEME@public.gmane.org>
---
drivers/usb/dwc2/core.h | 1 +
drivers/usb/dwc2/params.c | 11 +++++++++--
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 8367d4f..47e9092 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -587,6 +587,7 @@ struct dwc2_hw_params {
unsigned utmi_phy_data_width:2;
u32 snpsid;
u32 dev_ep_dirs;
+ u32 g_tx_fifo_size[MAX_EPS_CHANNELS];
};
/* Size of control and EP0 buffers */
diff --git a/drivers/usb/dwc2/params.c b/drivers/usb/dwc2/params.c
index a3ffe97..04f1868 100644
--- a/drivers/usb/dwc2/params.c
+++ b/drivers/usb/dwc2/params.c
@@ -469,8 +469,7 @@ static void dwc2_check_param_tx_fifo_sizes(struct dwc2_hsotg *hsotg)
}
for (fifo = 1; fifo <= fifo_count; fifo++) {
- dptxfszn = (dwc2_readl(hsotg->regs + DPTXFSIZN(fifo)) &
- FIFOSIZE_DEPTH_MASK) >> FIFOSIZE_DEPTH_SHIFT;
+ dptxfszn = hsotg->hw_params.g_tx_fifo_size[fifo];
if (hsotg->params.g_tx_fifo_size[fifo] < min ||
hsotg->params.g_tx_fifo_size[fifo] > dptxfszn) {
@@ -617,6 +616,7 @@ int dwc2_get_hwparams(struct dwc2_hsotg *hsotg)
{
struct dwc2_hw_params *hw = &hsotg->hw_params;
unsigned int width;
+ int fifo, fifo_count;
u32 hwcfg1, hwcfg2, hwcfg3, hwcfg4;
u32 grxfsiz;
@@ -705,6 +705,13 @@ int dwc2_get_hwparams(struct dwc2_hsotg *hsotg)
hw->rx_fifo_size = (grxfsiz & GRXFSIZ_DEPTH_MASK) >>
GRXFSIZ_DEPTH_SHIFT;
+ fifo_count = dwc2_hsotg_tx_fifo_count(hsotg);
+
+ for (fifo = 1; fifo <= fifo_count; fifo++) {
+ u32 val = dwc2_readl(hsotg->regs + DPTXFSIZN(fifo));
+ hw->g_tx_fifo_size[fifo] = (val & FIFOSIZE_DEPTH_MASK) >>
+ FIFOSIZE_DEPTH_SHIFT;
+ }
return 0;
}
--
2.7.4
--
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
* [PATCH 0/8] add UniPhier audio system support
From: Katsuhiro Suzuki @ 2017-11-22 11:43 UTC (permalink / raw)
To: Mark Brown, alsa-devel, Rob Herring, devicetree, Masahiro Yamada
Cc: Masami Hiramatsu, Jassi Brar, linux-arm-kernel, linux-kernel,
Katsuhiro Suzuki
This series adds support for Socionext audio system for
UniPhier LD11/LD20 SoCs. This driver supports I2S output
for Line-In, Line-Out and S/PDIF output.
UniPhier AIO DAI driver provides sound devices such as I2S, S/PDIF.
Since the AIO has mixed register map for those I/Os, it is hard to
split register areas for each sound devices.
UniPhier EVEA is a codec core for Line-In, Line-Out. Since this core
is only in internal of UniPhier series SoC, this driver works
independently but only UniPhier SoC can use it.
Katsuhiro Suzuki (8):
ASoC: spdif: Add S32_LE support for S/PDIF dummy codec drivers
ASoC: uniphier: add DT bindings documentation for UniPhier EVEA
ASoC: uniphier: add DT bindings documentation for UniPhier AIO
ASoC: uniphier: add support for UniPhier EVEA codec
ASoC: uniphier: add support for UniPhier AIO driver
ASoC: uniphier: add support for UniPhier LD11/LD20 AIO driver
MAINTAINERS: add entries for UniPhier ASoC sound drivers
arm64: dts: uniphier: add sound node for UniPhier
.../devicetree/bindings/sound/uniphier,aio.txt | 36 ++
.../devicetree/bindings/sound/uniphier,evea.txt | 26 +
MAINTAINERS | 6 +
.../boot/dts/socionext/uniphier-ld11-global.dts | 72 +++
arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi | 31 +
.../boot/dts/socionext/uniphier-ld20-global.dts | 72 +++
arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi | 35 ++
sound/soc/Kconfig | 1 +
sound/soc/Makefile | 1 +
sound/soc/codecs/spdif_receiver.c | 5 +-
sound/soc/codecs/spdif_transmitter.c | 5 +-
sound/soc/uniphier/Kconfig | 34 +
sound/soc/uniphier/Makefile | 8 +
sound/soc/uniphier/aio-core.c | 368 +++++++++++
sound/soc/uniphier/aio-dma.c | 266 ++++++++
sound/soc/uniphier/aio-ld11.c | 343 ++++++++++
sound/soc/uniphier/aio-regctrl.c | 699 +++++++++++++++++++++
sound/soc/uniphier/aio-regctrl.h | 495 +++++++++++++++
sound/soc/uniphier/aio.h | 261 ++++++++
sound/soc/uniphier/evea.c | 567 +++++++++++++++++
20 files changed, 3327 insertions(+), 4 deletions(-)
create mode 100644 Documentation/devicetree/bindings/sound/uniphier,aio.txt
create mode 100644 Documentation/devicetree/bindings/sound/uniphier,evea.txt
create mode 100644 sound/soc/uniphier/Kconfig
create mode 100644 sound/soc/uniphier/Makefile
create mode 100644 sound/soc/uniphier/aio-core.c
create mode 100644 sound/soc/uniphier/aio-dma.c
create mode 100644 sound/soc/uniphier/aio-ld11.c
create mode 100644 sound/soc/uniphier/aio-regctrl.c
create mode 100644 sound/soc/uniphier/aio-regctrl.h
create mode 100644 sound/soc/uniphier/aio.h
create mode 100644 sound/soc/uniphier/evea.c
--
2.15.0
^ permalink raw reply
* [PATCH 1/8] ASoC: spdif: Add S32_LE support for S/PDIF dummy codec drivers
From: Katsuhiro Suzuki @ 2017-11-22 11:43 UTC (permalink / raw)
To: Mark Brown, alsa-devel, Rob Herring, devicetree, Masahiro Yamada
Cc: Katsuhiro Suzuki, Jassi Brar, linux-arm-kernel, Masami Hiramatsu,
linux-kernel
In-Reply-To: <20171122114321.29196-1-suzuki.katsuhiro@socionext.com>
AIO on UniPhier can output S/PDIF where no codec is needed.
This patch adds S32_LE support for dummy codec drivers.
If one S/PDIF controller has its own limitation, its CPU DAI driver should
set the supported format by its own circumstance, since the soc-pcm driver
will use the intersection of cpu_dai's formats and codec_dai's formats.
Signed-off-by: Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com>
---
sound/soc/codecs/spdif_receiver.c | 5 +++--
sound/soc/codecs/spdif_transmitter.c | 5 +++--
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/sound/soc/codecs/spdif_receiver.c b/sound/soc/codecs/spdif_receiver.c
index 7acd05140a81..c8fd6367f6c0 100644
--- a/sound/soc/codecs/spdif_receiver.c
+++ b/sound/soc/codecs/spdif_receiver.c
@@ -34,10 +34,11 @@ static const struct snd_soc_dapm_route dir_routes[] = {
#define STUB_RATES SNDRV_PCM_RATE_8000_192000
#define STUB_FORMATS (SNDRV_PCM_FMTBIT_S16_LE | \
SNDRV_PCM_FMTBIT_S20_3LE | \
- SNDRV_PCM_FMTBIT_S24_LE | \
+ SNDRV_PCM_FMTBIT_S24_LE | \
+ SNDRV_PCM_FMTBIT_S32_LE | \
SNDRV_PCM_FMTBIT_IEC958_SUBFRAME_LE)
-static const struct snd_soc_codec_driver soc_codec_spdif_dir = {
+static struct snd_soc_codec_driver soc_codec_spdif_dir = {
.component_driver = {
.dapm_widgets = dir_widgets,
.num_dapm_widgets = ARRAY_SIZE(dir_widgets),
diff --git a/sound/soc/codecs/spdif_transmitter.c b/sound/soc/codecs/spdif_transmitter.c
index 063a64ff82d3..037aa1d45559 100644
--- a/sound/soc/codecs/spdif_transmitter.c
+++ b/sound/soc/codecs/spdif_transmitter.c
@@ -27,7 +27,8 @@
#define STUB_RATES SNDRV_PCM_RATE_8000_192000
#define STUB_FORMATS (SNDRV_PCM_FMTBIT_S16_LE | \
SNDRV_PCM_FMTBIT_S20_3LE | \
- SNDRV_PCM_FMTBIT_S24_LE)
+ SNDRV_PCM_FMTBIT_S24_LE | \
+ SNDRV_PCM_FMTBIT_S32_LE)
static const struct snd_soc_dapm_widget dit_widgets[] = {
SND_SOC_DAPM_OUTPUT("spdif-out"),
@@ -37,7 +38,7 @@ static const struct snd_soc_dapm_route dit_routes[] = {
{ "spdif-out", NULL, "Playback" },
};
-static const struct snd_soc_codec_driver soc_codec_spdif_dit = {
+static struct snd_soc_codec_driver soc_codec_spdif_dit = {
.component_driver = {
.dapm_widgets = dit_widgets,
.num_dapm_widgets = ARRAY_SIZE(dit_widgets),
--
2.15.0
^ permalink raw reply related
* [PATCH 2/8] ASoC: uniphier: add DT bindings documentation for UniPhier EVEA
From: Katsuhiro Suzuki @ 2017-11-22 11:43 UTC (permalink / raw)
To: Mark Brown, alsa-devel, Rob Herring, devicetree, Masahiro Yamada
Cc: Katsuhiro Suzuki, Jassi Brar, linux-arm-kernel, Masami Hiramatsu,
linux-kernel
In-Reply-To: <20171122114321.29196-1-suzuki.katsuhiro@socionext.com>
This patch adds DT binding documentation for UniPhier EVEA
that is SoC inner sound codec of UniPhier series.
Signed-off-by: Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com>
---
.../devicetree/bindings/sound/uniphier,evea.txt | 26 ++++++++++++++++++++++
1 file changed, 26 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/uniphier,evea.txt
diff --git a/Documentation/devicetree/bindings/sound/uniphier,evea.txt b/Documentation/devicetree/bindings/sound/uniphier,evea.txt
new file mode 100644
index 000000000000..3f31b235f18b
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/uniphier,evea.txt
@@ -0,0 +1,26 @@
+Socionext EVEA - UniPhier SoC internal codec driver
+
+Required properties:
+- compatible : should be "socionext,uniphier-evea".
+- reg : offset and length of the register set for the device.
+- clock-names : should include following entries:
+ "evea", "exiv"
+- clocks : a list of phandle, should contain an entry for each
+ entries in clock-names.
+- reset-names : should include following entries:
+ "evea", "exiv", "adamv"
+- resets : a list of phandle, should contain reset entries of
+ reset-names.
+- #sound-dai-cells: should be 1.
+
+Example:
+
+ codec {
+ compatible = "socionext,uniphier-evea";
+ reg = <0x57900000 0x1000>;
+ clock-names = "evea", "exiv";
+ clocks = <&sys_clk 41>, <&sys_clk 42>;
+ reset-names = "evea", "exiv", "adamv";
+ resets = <&sys_rst 41>, <&sys_rst 42>, <&adamv_rst 0>;
+ #sound-dai-cells = <1>;
+ };
--
2.15.0
^ permalink raw reply related
* [PATCH 3/8] ASoC: uniphier: add DT bindings documentation for UniPhier AIO
From: Katsuhiro Suzuki @ 2017-11-22 11:43 UTC (permalink / raw)
To: Mark Brown, alsa-devel, Rob Herring, devicetree, Masahiro Yamada
Cc: Katsuhiro Suzuki, Jassi Brar, linux-arm-kernel, Masami Hiramatsu,
linux-kernel
In-Reply-To: <20171122114321.29196-1-suzuki.katsuhiro@socionext.com>
This patch adds DT binding documentation for UniPhier
AIO audio subsystem.
Signed-off-by: Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com>
---
.../devicetree/bindings/sound/uniphier,aio.txt | 36 ++++++++++++++++++++++
1 file changed, 36 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/uniphier,aio.txt
diff --git a/Documentation/devicetree/bindings/sound/uniphier,aio.txt b/Documentation/devicetree/bindings/sound/uniphier,aio.txt
new file mode 100644
index 000000000000..73f6c27ae4f7
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/uniphier,aio.txt
@@ -0,0 +1,36 @@
+Socionext UniPhier SoC audio driver
+
+The Socionext UniPhier audio subsystem consists of I2S and S/PDIF blocks in
+the same register space.
+
+Required properties:
+- compatible : should be one of the following:
+ "socionext,uniphier-ld11-aio"
+ "socionext,uniphier-ld20-aio"
+- reg : offset and length of the register set for the device.
+- interrupts : should contain I2S or S/PDIF interrupt.
+- pinctrl-names : should be "default".
+- pinctrl-0 : defined I2S signal pins for an external codec chip.
+- clock-names : should include following entries:
+ "aio"
+- clocks : a list of phandle, should contain an entry for each
+ entry in clock-names.
+- reset-names : should include following entries:
+ "aio"
+- resets : a list of phandle, should contain an entry for each
+ entry in reset-names.
+- #sound-dai-cells: should be 1.
+
+Example:
+ audio {
+ compatible = "socionext,uniphier-ld20-aio";
+ reg = <0x56000000 0x80000>;
+ interrupts = <0 144 4>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_aout>;
+ clock-names = "aio";
+ clocks = <&sys_clk 40>;
+ reset-names = "aio";
+ resets = <&sys_rst 40>;
+ #sound-dai-cells = <1>;
+ };
--
2.15.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox