* 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
* Re: [patches] Re: [PATCH] dt-bindings: Add a RISC-V SBI firmware node
From: Jonathan Neuschäfer @ 2017-11-21 20:08 UTC (permalink / raw)
To: Palmer Dabbelt
Cc: robh-DgEjT+Ai2ygdnm+yROfE0A, j.neuschaefer-hi6Y0CQ0nG0,
mark.rutland-5wv7dgnIgG8, devicetree-u79uwXL29TY76Z2rM5mHXA,
patches-q3qR2WxjNRFS9aJRtSZj7A,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <mhng-dadf76d9-0823-4fc8-9177-1772629573b6@palmer-si-x1c4>
[-- Attachment #1: Type: text/plain, Size: 792 bytes --]
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.
Thanks,
Jonathan Neuschäfer
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] usb: xhci: add relaxed timing quirk bit
From: Rob Herring @ 2017-11-21 20:06 UTC (permalink / raw)
To: Adam Wallis
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: <f200ce55-ac67-02f9-4dbf-7a3ba5b52b39-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
On Tue, Nov 21, 2017 at 1:49 PM, Adam Wallis <awallis-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> wrote:
> On 11/21/2017 2:11 PM, Rob Herring wrote:
>> On Tue, Nov 21, 2017 at 12:18:09PM -0500, Adam Wallis wrote:
>>> Certain systems may run with CPUs at a very slow frequency. This
>>> patch adds a quirk bit that can be used to relax certain timings, etc.
>>>
>>> This quirk might be needed for other fields in the future, but
>>> initially, it will be used only on the IRQ control register to allow
>>> firmare to control the value of the register. This can prevent an
>>
>> s/firmare/firmware/
>>
>
> Thanks, good catch.
>
>> By firmware control, you mean the register is initialized on boot and
>> then not touched by the kernel? What if the XHCI block is reset? Not
>> sure if that's possible.
>>
>>> "interrupt storm" effect on certain systems.
>>
>> So now we have 2 ways to deal with this? The existing MediaTek quirk and
>> now this one.
>
> I do agree that 2 different ways to deal with it is not ideal. I also think that
> having one hard-coded value (and one alternate for MTK) is also not ideal.
Agreed.
>>
>> I think you should change the existing quirk to a value and set the
>> value based on compatible strings.
>
> 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.
> 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?
It would only be hardcoded per compatible which should be per SoC. Do
you need per board/device tuning? If so, use a property.
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: RFC: Copying Device Tree File into reserved area of VMLINUX before deployment
From: Ulf Samuelsson @ 2017-11-21 20:03 UTC (permalink / raw)
To: Rob Herring, Frank Rowand; +Cc: LKML, devicetree@vger.kernel.org
In-Reply-To: <CAL_JsqJZbBDcp_GCNjW8mpPTi2Gv9J5bkbb5co0wRFxYf4aPpw@mail.gmail.com>
On 2017-11-21 18:09, Rob Herring wrote:
> On Mon, Nov 20, 2017 at 3:39 PM, Frank Rowand <frowand.list@gmail.com> wrote:
>> Hi Ulf, Rob,
>>
>> On 11/20/17 15:19, Ulf Samuelsson wrote:
>>>
>>>
>>> On 2017-11-20 05:32, Frank Rowand wrote:
>>>> Hi Ulf,
>>>>
>>>>
>>>> On 11/19/17 23:23, Frank Rowand wrote:
>>>>> adding devicetree list, devicetree maintainers
>>>>>
>>>>> On 11/18/17 12:59, Ulf Samuelsson wrote:
>>>>>> I noticed when checking out the OpenWRT support for the board that they have a method to avoid having to pass the device tree address to the kernel, and can thus boot device tree based kernels with U-boots that
>>>>>> does not support device trees.
>>>>>>
>>>>>> Is this something that would be considered useful for including in mainstream:
>>>>>>
>>>>>> BACKGROUND:
>>>>>> Trying to load a yocto kernel into a MIPS target (MT7620A based),
>>>>>> and the U-Boot is more than stupid.
>>>>>> Does not support the "run" command as an example.
>>>>>> They modified the U-Boot MAGIC Word to complicate things.
>>>>>> The U-Boot is not configured to use device tree files.
>>>>>> The board runs a 2.6 kernel right now.
>>>>>>
>>>>>> Several attempts by me a and others to rebuild U-Boot according to
>>>>>> the H/W vendors source code and build instructions results in a
>>>>>> bricked unit. Bricked units cannot be recovered.
>>>>
>>>> Hopefully you have brought this to the attention of the vendor. U-Boot
>>>> is GPL v2 (or in some ways possibly GPL v2 or later), so if you can not
>>>> build U-Boot that is equivalent to the binary U-Boot they shipped, the
>>>> vendor may want to ensure that they are shipping the proper source and
>>>> build instructions.
>>>>
>>>
>>> I am not the one in contact with the H/W vendor.
>>> The U-boot is pretty old, and from comments from those
>>> in contact with them, the U-Boot knowledge at the H/W vendor
>>> is minimal at best.
>>> It might even be that they program an U-boot where the upgrade of the U-boot is broken...
>>>
>>>
>>>>
>>>>>> Not my choice of H/W, so I cannot change it.
>>>>>>
>>>>>>
>>>>>> ===================================================================
>>>>>> OPENWRT:
>>>>>> I noticed when checking out the OpenWRT support for the board that
>>>>>> they have a method to avoid having to pass the device tree address
>>>>>> to the kernel, and can thus boot device tree based kernels with
>>>>>> U-boots that does not support device trees.
>>>>>>
>>>>>> What they do is to reserve 16 kB of kernel space, and tag it with
>>>>>> an ASCII string "OWRTDTB:". After the kernel and dtb is built, a
>>>>>> utility "patch-dtb" will update the vmlinux binary, copying in the
>>>>>> device tree file.
>>>>>>
>>>>>> ===================================================================
>>>>>> It would be useful to me, and I could of course patch the
>>>>>> mainstream kernel, but first I would like to check if this is of
>>>>>> interest for mainstream.
>>>>
>>>> Not in this form. Hard coding a fixed size area in the boot image
>>>> to contain the FDT (aka DTB) is a non-starter.
>>>
>>> OK, Is it the fixed size, which is a problem?
>>
>> Yes, it is the fixed size which is a problem.
>>
>>> Is generally combining an image with a DTB into a single file also a non-starter?
>>
>> Can you jump in here Rob? My understanding is that CONFIG_ARM_APPENDED_DTB,
>> which is the ARM based solution that Mark mentioned, was envisioned as a
>> temporary stop gap until boot loaders could add devicetree support. I don't
>> know if there is a desire to limit this approach or to remove it in the
>> future.
>
> Yes, but I doubt we'll ever remove it. Most android devices use it (or
> the multiple appended dtb stuff Qcom did) and there's out of tree
> patches to do appended dtb on arm64. However, arm64 is a done a bit
> differently in that the bootloader has to find the dtb rather than the
> kernel (or really the decompressor). The purpose for arm64 is people
> like the single kernel+dtb image, not legacy bootloader support as DT
> support was there from day 1.
>
> Another option is to do what's called an impedance matcher like this[1].
>
>> I'm not sure why this feature should not be permanently supported. I'm being
>> cautious, just in case I'm overlooking or missing an important issue, thus
>> asking for Rob's input. I do know that this feature does not advance the
>> desires of people who want a single kernel (single boot image?) that runs on
>> many different systems, instead of a boot image that is unique to each
>> target platform. But I don't see why that desire precludes also having
>> an option to have a target specific boot image.
>
> MIPS already supports built-in dtbs which is an in-kernel way to get
> the dtb rather than the decompressor. The addition in this case is
> just putting in a dummy dtb and putting in the real dtb later. I'm not
> sure what MIPS image header looks like, but seems like it should be
> possible to have the "built-in dtb" point to an appended dtb and just
> update sizes in the image file. Then you don't have the fixed size.
>
> But now that I finished writing this, I see there is already appended
> DTB support in MIPS.
I just managed to complete a build using yocto where I made the
following changes.
I build the dtbs before linking the uImage.
I add some configuration variables, which define
* if the dtb should be included
* which dtb file should be included
uImage always gziped
Checking the resulting uImage, shows that the ".appended_dtb" section
now contains the dtb file.
I have not loaded it into a board yet, but the default init seems to
check if there is a U-boot header in the ".appended_dtb" section.
My bootloader has a custom MAGIC so loading still won't work.
>
> Rob
>
> [1] https://github.com/zonque/pxa-impedance-matcher
>
--
Best Regards
Ulf Samuelsson
^ permalink raw reply
* Re: [PATCH v3 2/4] [media] dt-bindings: Document BCM283x CSI2/CCP2 receiver
From: Rob Herring @ 2017-11-21 19:58 UTC (permalink / raw)
To: Eric Anholt
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: <877euje8mc.fsf@anholt.net>
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:
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 1/2] usb: xhci: add relaxed timing quirk bit
From: Adam Wallis @ 2017-11-21 19:49 UTC (permalink / raw)
To: Rob Herring
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Greg Kroah-Hartman, Mathias Nyman,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Mark Rutland,
timur-sgV2jX0FEOL9JmXXK+q4OQ
In-Reply-To: <20171121191103.5oczqvrlo4gtwjqc@rob-hp-laptop>
On 11/21/2017 2:11 PM, Rob Herring wrote:
> On Tue, Nov 21, 2017 at 12:18:09PM -0500, Adam Wallis wrote:
>> Certain systems may run with CPUs at a very slow frequency. This
>> patch adds a quirk bit that can be used to relax certain timings, etc.
>>
>> This quirk might be needed for other fields in the future, but
>> initially, it will be used only on the IRQ control register to allow
>> firmare to control the value of the register. This can prevent an
>
> s/firmare/firmware/
>
Thanks, good catch.
> By firmware control, you mean the register is initialized on boot and
> then not touched by the kernel? What if the XHCI block is reset? Not
> sure if that's possible.
>
>> "interrupt storm" effect on certain systems.
>
> So now we have 2 ways to deal with this? The existing MediaTek quirk and
> now this one.
I do agree that 2 different ways to deal with it is not ideal. I also think that
having one hard-coded value (and one alternate for MTK) is also not ideal.
>
> I think you should change the existing quirk to a value and set the
> value based on compatible strings.
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"? If you mean this, where do you recommend I store the
desired IRQ_CONTROL value - in struct xhci_hcd ?
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.
>
>> Signed-off-by: Adam Wallis <awallis-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
>> ---
>> Documentation/devicetree/bindings/usb/usb-xhci.txt | 1 +
>> drivers/usb/host/xhci.c | 25 +++++++++++++++-------
>> drivers/usb/host/xhci.h | 1 +
>> 3 files changed, 19 insertions(+), 8 deletions(-)
Thanks for the feedback Rob.
Adam
--
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: [PATCH v3 2/4] [media] dt-bindings: Document BCM283x CSI2/CCP2 receiver
From: Eric Anholt @ 2017-11-21 19:26 UTC (permalink / raw)
To: Dave Stevenson, Rob Herring
Cc: Stefan Wahren, Mauro Carvalho Chehab,
linux-media-u79uwXL29TY76Z2rM5mHXA, Sakari Ailus, Hans Verkuil,
linux-rpi-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CAAoAYcM0m6Z8hUDn+FuNb-O28geAYJqHWrhKPDP_Jvh2P-YE3A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 6120 bytes --]
Dave Stevenson <dave.stevenson-FnsA7b+Nu9XbIbC87yuRow@public.gmane.org> writes:
> Hi Rob
>
> On 27 September 2017 at 22:51, Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.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-eS4NqCHxEME@public.gmane.org> wrote:
>>> > Hi Dave,
>>> >
>>> >> Dave Stevenson <dave.stevenson-FnsA7b+Nu9XbIbC87yuRow@public.gmane.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-FnsA7b+Nu9XbIbC87yuRow@public.gmane.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?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] usb: xhci: add relaxed timing quirk bit
From: Rob Herring @ 2017-11-21 19:11 UTC (permalink / raw)
To: Adam Wallis
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Greg Kroah-Hartman, Mathias Nyman,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Mark Rutland,
timur-sgV2jX0FEOL9JmXXK+q4OQ
In-Reply-To: <1511284690-3878-2-git-send-email-awallis-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
On Tue, Nov 21, 2017 at 12:18:09PM -0500, Adam Wallis wrote:
> Certain systems may run with CPUs at a very slow frequency. This
> patch adds a quirk bit that can be used to relax certain timings, etc.
>
> This quirk might be needed for other fields in the future, but
> initially, it will be used only on the IRQ control register to allow
> firmare to control the value of the register. This can prevent an
s/firmare/firmware/
By firmware control, you mean the register is initialized on boot and
then not touched by the kernel? What if the XHCI block is reset? Not
sure if that's possible.
> "interrupt storm" effect on certain systems.
So now we have 2 ways to deal with this? The existing MediaTek quirk and
now this one.
I think you should change the existing quirk to a value and set the
value based on compatible strings.
> Signed-off-by: Adam Wallis <awallis-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> ---
> Documentation/devicetree/bindings/usb/usb-xhci.txt | 1 +
> drivers/usb/host/xhci.c | 25 +++++++++++++++-------
> drivers/usb/host/xhci.h | 1 +
> 3 files changed, 19 insertions(+), 8 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/3] spi: xilinx: Add support for xlnx,axi-quad-spi-1.00.a
From: Rob Herring @ 2017-11-21 18:38 UTC (permalink / raw)
To: Ricardo Ribalda Delgado
Cc: linux-spi-u79uwXL29TY76Z2rM5mHXA, Mark Brown,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171121090904.6901-2-ricardo.ribalda-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Tue, Nov 21, 2017 at 10:09:03AM +0100, Ricardo Ribalda Delgado wrote:
> The driver has been successfully tested with Xilinx's core
> axi-quad-spi-1.0.0a. Documented on DS843:
>
> https://www.xilinx.com/support/documentation/ip_documentation/axi_quad_spi/v1_00_a/ds843_axi_quad_spi.pdf
>
> Cc: Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> Documentation/devicetree/bindings/spi/spi-xilinx.txt | 2 +-
> drivers/spi/spi-xilinx.c | 1 +
> 2 files changed, 2 insertions(+), 1 deletion(-)
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" 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 5/5] dt-bindings: pinctrl: deprecate 'microchip,irq-active-high' property
From: Rob Herring @ 2017-11-21 18:37 UTC (permalink / raw)
To: Phil Reid; +Cc: linus.walleij, mark.rutland, sre, linux-gpio, devicetree
In-Reply-To: <1511252491-79952-6-git-send-email-preid@electromag.com.au>
On Tue, Nov 21, 2017 at 04:21:31PM +0800, Phil Reid wrote:
> The irq output polarity can be determined from the 'interrupts'
> configuration. So 'microchip,irq-active-high' is not required.
>
> Signed-off-by: Phil Reid <preid@electromag.com.au>
> ---
> Documentation/devicetree/bindings/pinctrl/pinctrl-mcp23s08.txt | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v3 2/5] dt-bindings: pinctrl: mcp23s08: add documentation for drive-open-drain
From: Rob Herring @ 2017-11-21 18:37 UTC (permalink / raw)
To: Phil Reid
Cc: linus.walleij-QSEj5FYQhm4dnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
sre-DgEjT+Ai2ygdnm+yROfE0A, linux-gpio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1511252491-79952-3-git-send-email-preid-qgqNFa1JUf/o2iN0hyhwsIdd74u8MsAO@public.gmane.org>
On Tue, Nov 21, 2017 at 04:21:28PM +0800, Phil Reid wrote:
> This flag set the mcp23s08 device irq type to open drain active low.
>
> Signed-off-by: Phil Reid <preid-qgqNFa1JUf/o2iN0hyhwsIdd74u8MsAO@public.gmane.org>
> ---
> Documentation/devicetree/bindings/pinctrl/pinctrl-mcp23s08.txt | 2 ++
> 1 file changed, 2 insertions(+)
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 04/12] dt-bindings: fsi: Add P9 OCC hwmon device documentation
From: Rob Herring @ 2017-11-21 18:36 UTC (permalink / raw)
To: Eddie James
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-hwmon-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA, linux-0h96xk9xTtrk1uMJSBkQmQ,
jdelvare-IBi9RG/b67k, corbet-T1hC0tSOHrs,
mark.rutland-5wv7dgnIgG8, joel-U3u1mxZcP9KHXe+LvDLADg,
Edward A. James
In-Reply-To: <1511222021-562-5-git-send-email-eajames-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
On Mon, Nov 20, 2017 at 05:53:33PM -0600, Eddie James wrote:
> From: "Edward A. James" <eajames-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
>
> Document the bindings for the FSI-based OCC hwmon device.
>
> Signed-off-by: Edward A. James <eajames-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
> ---
> .../devicetree/bindings/fsi/ibm,p9-occ-hwmon.txt | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/fsi/ibm,p9-occ-hwmon.txt
>
> diff --git a/Documentation/devicetree/bindings/fsi/ibm,p9-occ-hwmon.txt b/Documentation/devicetree/bindings/fsi/ibm,p9-occ-hwmon.txt
> new file mode 100644
> index 0000000..086b1eb
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/fsi/ibm,p9-occ-hwmon.txt
> @@ -0,0 +1,16 @@
> +Device-tree bindings for FSI-based On-Chip Controller hwmon device
> +------------------------------------------------------------------
> +
> +Required properties:
> + - compatible = "ibm,p9-occ-hwmon";
> +
> +Examples:
> +
> + occ@1 {
> + compatible = "ibm,p9-occ";
> + reg = <1>;
> +
> + occ-hwmon@1 {
Missing reg property or need to drop the unit-address.
> + compatible = "ibm,p9-occ-hmwon";
> + }
Missing ;
> + };
> --
> 1.8.3.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 v3 03/12] dt-bindings: i2c: Add P8 OCC hwmon device documentation
From: Rob Herring @ 2017-11-21 18:34 UTC (permalink / raw)
To: Eddie James
Cc: linux-kernel, linux-hwmon, devicetree, linux-doc, linux, jdelvare,
corbet, mark.rutland, joel, Edward A. James
In-Reply-To: <1511222021-562-4-git-send-email-eajames@linux.vnet.ibm.com>
On Mon, Nov 20, 2017 at 05:53:32PM -0600, Eddie James wrote:
> From: "Edward A. James" <eajames@us.ibm.com>
>
> Document the bindings for I2C-based OCC hwmon device.
>
> Signed-off-by: Edward A. James <eajames@us.ibm.com>
> ---
> .../devicetree/bindings/i2c/ibm,p8-occ-hwmon.txt | 25 ++++++++++++++++++++++
> 1 file changed, 25 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/i2c/ibm,p8-occ-hwmon.txt
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v2] clk: qoriq: add more divider clocks support
From: Rob Herring @ 2017-11-21 18:30 UTC (permalink / raw)
To: andy.tang; +Cc: mturquette, sboyd, mark.rutland, linux-clk, devicetree
In-Reply-To: <20171121061300.23464-1-andy.tang@nxp.com>
On Tue, Nov 21, 2017 at 02:13:00PM +0800, andy.tang@nxp.com wrote:
> From: Yuantian Tang <andy.tang@nxp.com>
>
> More divider clocks are needed by IP. So enlarge the PLL divider
> array to accommodate more divider clocks.
>
> Signed-off-by: Tang Yuantian <andy.tang@nxp.com>
> ---
> v2:
> - fix a logical error
>
> Documentation/devicetree/bindings/clock/qoriq-clock.txt | 1 +
Please add acks when posting new versions.
> drivers/clk/clk-qoriq.c | 9 ++++++++-
> 2 files changed, 9 insertions(+), 1 deletion(-)
^ permalink raw reply
* Re: [PATCH 3/6] arm: dts: marvell: Add missing #phy-cells to usb-nop-xceiv
From: Rob Herring @ 2017-11-21 18:29 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
arm-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org
Cc: Jason Cooper, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth
In-Reply-To: <20171109222614.5719-3-robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
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.
>
> arch/arm/boot/dts/armada-385-db-ap.dts | 1 +
> arch/arm/boot/dts/armada-385-linksys.dtsi | 1 +
> arch/arm/boot/dts/armada-385-synology-ds116.dts | 2 ++
> arch/arm/boot/dts/armada-388-gp.dts | 2 ++
> 4 files changed, 6 insertions(+)
--
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 05/20] firmware: arm_scmi: add scmi protocol bus to enumerate protocol devices
From: Sudeep Holla @ 2017-11-21 18:04 UTC (permalink / raw)
To: ALKML, LKML, DTML, Arnd Bergmann
Cc: Sudeep Holla, Roy Franz, Harb Abdulhamid, Nishanth Menon, Loc Ho,
Ryan Harkin, Jassi Brar
In-Reply-To: <1509720477-18936-6-git-send-email-sudeep.holla-5wv7dgnIgG8@public.gmane.org>
Hi Arnd,
On 03/11/17 14:47, Sudeep Holla wrote:
> The SCMI specification encompasses various protocols. However, not every
> protocol has to be present on a given platform/implementation as not
> every protocol is relevant for it.
>
> Furthermore, the platform chooses which protocols it exposes to a given
> agent. The only protocol that must be implemented is the base protocol.
> The base protocol is used by an agent to discover which protocols are
> available to it.
>
> In order to enumerate the discovered implemented protocols, this patch
> adds support for a separate scmi protocol bus. It also adds mechanism to
> register support for different protocols.
>
> Cc: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
Extremely sorry to both during merge window, but just wanted to check if
you can spare sometime reviewing these SCMI patches. I know it's too
early for v4.16 but with holiday period ahead, thought of checking so
that I won't miss v4.16
--
Regards,
Sudeep
--
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-21 17:41 UTC (permalink / raw)
Cc: patches, j.neuschaefer, mark.rutland, robh+dt, devicetree,
linux-kernel
In-Reply-To: <20171121010843.4nmndskaoslqcyyh@latitude>
On Mon, 20 Nov 2017 17:08:44 PST (-0800), j.neuschaefer@gmx.net wrote:
> On Mon, Nov 20, 2017 at 01:28:01PM -0800, Palmer Dabbelt wrote:
>> > > @@ -0,0 +1,20 @@
>> > > +RISC-V Supervisor Binary Interface (SBI)
>> > > +
>> > > +The RISC-V privileged ISA specification mandates the presence of a supervisor
>> > > +binary interface that performs some operations which might otherwise require
>> > > +particularly complicated instructions. This interface includes
>> > > +inter-processor interrupts, TLB flushes, i-cache and TLB shootdowns, a
>> > > +console, and power management.
>> > > +
>> > > +Required properties:
>> > > +- compatible: must contain one of the following
>> > > + * "riscv,sbi" for the SBI defined by the privileged specification of the
>> > > + system.
>> >
>> > "of the system" seems to imply that different RISC-V systems (different
>> > RISC-V implementations) can have different privileged specifications.
>>
>> Actually, that was intentional -- I wrote it this way because different
>> RISC-V systems do have different privileged specifications. The RISC-V
>> specifications aren't frozen in time, they're just guaranteed to be
>> compatible in the future. For example, the user ISA document has been
>> updated multiple times (the C spec, eliminating some unspecified behavior)
>> and will continue to be updated (V and other extensions, the memory model).
>> The privileged spec will be updated in a compatible way just like the user
>> spec will be -- I know there's at least hypervisor support in the works, and
>> I saw some things to remove undefined behavior go past as well.
>>
>> In a similar fashion, the ABI and SBI will continue to evolve. For example,
>> we'll probably add new system calls to extend the user ABI and new hyper
>> calls to extend the SBI.
>
> My problem with the wording was that the OS somehow has to know which
> version and variant of the SBI it is talking to -- either through
> in-band communication (an SBI call to request SBI information, etc.), or
> through devicetree or similar mechanisms.
The idea here is that rather than checking for a version of the SBI, you just
check for various features as you need them.
^ permalink raw reply
* Re: [patches] Re: [PATCH] dt-bindings: Add an enable method to RISC-V
From: Palmer Dabbelt @ 2017-11-21 17:41 UTC (permalink / raw)
To: robh-DgEjT+Ai2ygdnm+yROfE0A
Cc: mark.rutland-5wv7dgnIgG8, devicetree-u79uwXL29TY76Z2rM5mHXA,
patches-q3qR2WxjNRFS9aJRtSZj7A,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171120214709.oss7rrtijw2cyjmw@rob-hp-laptop>
On Mon, 20 Nov 2017 13:47:09 PST (-0800), robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org wrote:
> On Mon, Nov 20, 2017 at 11:50:22AM -0800, Palmer Dabbelt wrote:
>> RISC-V doesn't currently specify a mechanism for enabling or disabling
>> CPUs. Instead, we assume that all CPUs are enabled on boot, and if
>> someone wants to save power we instead put a CPU to sleep via a WFI
>> loop.
>>
>> This patch adds "enable-method" to the RISC-V CPU binding, which
>> currently only has the value "none". This allows us to change the
>> enable method in the future.
>
> I think "none" should just be no cpu-enable-method property.
I'm OK with that.
--
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-21 17:37 UTC (permalink / raw)
To: robh, j.neuschaefer; +Cc: mark.rutland, devicetree, patches, linux-kernel
In-Reply-To: <20171120214520.dcaqvyncojwefmgt@rob-hp-laptop>
On Mon, 20 Nov 2017 13:45:20 PST (-0800), robh@kernel.org wrote:
> On Mon, Nov 20, 2017 at 11:50:00AM -0800, Palmer Dabbelt wrote:
>> The RISC-V privileged ISA mandates the presence of an SBI, but there's
>> no reason not to put it in the device tree. This would allow us to
>> possibly remove the SBI later.
>
> If it is mandatory, then it should not be in DT. DT is not a driver
> instantiation mechanism.
>
> If your ISA can vary, I'd recommend you make that discoverable. DT is
> for what we failed to make discoverable.
OK, that makes sense. Since this the presence of an SBI is mandated by the ISA
there's no way to discover it (just like there's no way to discover a load
instruction). For extensibility reasons you can, of course, determine which
SBI calls are implemented, but this mechanism assumes you have something
running to catch the SBI calls on the other end (SBI calls are just system
calls from the Linux). I think the original goal here was to avoid an SBI
entirely, which isn't something the ISA is designed for.
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. One option that wouldn't require a device tree node would be to have
Linux boot in machine mode (where the SBI implementation lives on systems
without a hypervisor, if you've got a hypervisor then I assume the SBI isn't a
problem) and then provide its own SBI implementation. This wouldn't impose any
additional burden: if there's no SBI then Linux will need to start in machine
mode because that's where you need to be in order to do the things the SBI
implementation needs to go. This will be awkward to implement, but having a
device tree entry won't help with any of that.
I think the right thing to do here is just not define a device tree entry.
^ permalink raw reply
* [PATCH 2/2] usb: host: xhci-plat: check relaxed timing quirk bit
From: Adam Wallis @ 2017-11-21 17:18 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Greg Kroah-Hartman, Rob Herring, Mathias Nyman,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Mark Rutland
Cc: timur-sgV2jX0FEOL9JmXXK+q4OQ
In-Reply-To: <1511284690-3878-1-git-send-email-awallis-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
Check sysdev to see if the relaxed timing quirk ("quirk-relaxed-timing")
is set.
Signed-off-by: Adam Wallis <awallis-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
---
drivers/usb/host/xhci-plat.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 09f164f..ea221f3 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -266,6 +266,9 @@ static int xhci_plat_probe(struct platform_device *pdev)
if (device_property_read_bool(sysdev, "usb3-lpm-capable"))
xhci->quirks |= XHCI_LPM_SUPPORT;
+ if (device_property_read_bool(sysdev, "quirk-relaxed-timing"))
+ xhci->quirks |= XHCI_RELAXED_TIMING_QUIRK;
+
if (device_property_read_bool(&pdev->dev, "quirk-broken-port-ped"))
xhci->quirks |= XHCI_BROKEN_PORT_PED;
--
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 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
^ permalink raw reply related
* [PATCH 1/2] usb: xhci: add relaxed timing quirk bit
From: Adam Wallis @ 2017-11-21 17:18 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Greg Kroah-Hartman, Rob Herring, Mathias Nyman,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Mark Rutland
Cc: timur-sgV2jX0FEOL9JmXXK+q4OQ
In-Reply-To: <1511284690-3878-1-git-send-email-awallis-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
Certain systems may run with CPUs at a very slow frequency. This
patch adds a quirk bit that can be used to relax certain timings, etc.
This quirk might be needed for other fields in the future, but
initially, it will be used only on the IRQ control register to allow
firmare to control the value of the register. This can prevent an
"interrupt storm" effect on certain systems.
Signed-off-by: Adam Wallis <awallis-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
---
Documentation/devicetree/bindings/usb/usb-xhci.txt | 1 +
drivers/usb/host/xhci.c | 25 +++++++++++++++-------
drivers/usb/host/xhci.h | 1 +
3 files changed, 19 insertions(+), 8 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt b/Documentation/devicetree/bindings/usb/usb-xhci.txt
index ae6e484..af2faa24 100644
--- a/Documentation/devicetree/bindings/usb/usb-xhci.txt
+++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt
@@ -29,6 +29,7 @@ Optional properties:
- usb2-lpm-disable: indicate if we don't want to enable USB2 HW LPM
- usb3-lpm-capable: determines if platform is USB3 LPM capable
- quirk-broken-port-ped: set if the controller has broken port disable mechanism
+ - quirk-relaxed-timing: allows firmware to relax timing on certain registers
Example:
usb@f0931000 {
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 327ba8b..e14a204 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -582,16 +582,25 @@ int xhci_run(struct usb_hcd *hcd)
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
"ERST deq = 64'h%0lx", (long unsigned int) temp_64);
- xhci_dbg_trace(xhci, trace_xhci_dbg_init,
- "// Set the interrupt modulation register");
- temp = readl(&xhci->ir_set->irq_control);
- temp &= ~ER_IRQ_INTERVAL_MASK;
/*
- * the increment interval is 8 times as much as that defined
- * in xHCI spec on MTK's controller
+ * Systems with slow CPUs may not be able to tolerate
+ * agressive interrupt timing that silicon can tolerate. The
+ * XHCI_RELAXED_TIMING will allow firmware to set the IRQ
+ * Control field.
*/
- temp |= (u32) ((xhci->quirks & XHCI_MTK_HOST) ? 20 : 160);
- writel(temp, &xhci->ir_set->irq_control);
+ if (!(xhci->quirks & XHCI_RELAXED_TIMING_QUIRK)) {
+ xhci_dbg_trace(xhci, trace_xhci_dbg_init,
+ "// Set the interrupt modulation register");
+ temp = readl(&xhci->ir_set->irq_control);
+ temp &= ~ER_IRQ_INTERVAL_MASK;
+
+ /*
+ * the increment interval is 8 times as much as that defined
+ * in xHCI spec on MTK's controller
+ */
+ temp |= (u32) ((xhci->quirks & XHCI_MTK_HOST) ? 20 : 160);
+ writel(temp, &xhci->ir_set->irq_control);
+ }
/* Set the HCD state before we enable the irqs */
temp = readl(&xhci->op_regs->command);
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index 99a014a..6d451be 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1823,6 +1823,7 @@ struct xhci_hcd {
/* Reserved. It was XHCI_U2_DISABLE_WAKE */
#define XHCI_ASMEDIA_MODIFY_FLOWCONTROL (1 << 28)
#define XHCI_HW_LPM_DISABLE (1 << 29)
+#define XHCI_RELAXED_TIMING_QUIRK (1 << 30)
unsigned int num_active_eps;
unsigned int limit_active_eps;
--
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 related
* [PATCH 0/2] usb: xhci: addition of timing quirk
From: Adam Wallis @ 2017-11-21 17:18 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Greg Kroah-Hartman, Rob Herring, Mathias Nyman,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Mark Rutland
Cc: timur-sgV2jX0FEOL9JmXXK+q4OQ
On systems that allow CPUs to run at an extremely reduced frequency,
it is possible to create an "interrupt" storm by USB settings that are not
ideal at these speeds. This patch series introduces a quirk bit that currently
only touches the Interrupt Control register but might be used in the future
with other similar registers. This change allows for firmware (or scripts)
to set these registers as required in place of using hard-coded values
which might not be ideal for all platforms.
Adam Wallis (2):
usb: xhci: add relaxed timing quirk bit
usb: host: xhci-plat: check relaxed timing quirk bit
Documentation/devicetree/bindings/usb/usb-xhci.txt | 1 +
drivers/usb/host/xhci-plat.c | 3 +++
drivers/usb/host/xhci.c | 25 +++++++++++++++-------
drivers/usb/host/xhci.h | 1 +
4 files changed, 22 insertions(+), 8 deletions(-)
--
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 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
^ permalink raw reply
* Re: RFC: Copying Device Tree File into reserved area of VMLINUX before deployment
From: Rob Herring @ 2017-11-21 17:09 UTC (permalink / raw)
To: Frank Rowand; +Cc: linux-kernel, LKML, devicetree@vger.kernel.org
In-Reply-To: <0e54f9f0-1226-7f2e-3143-ea4e450058e6@gmail.com>
On Mon, Nov 20, 2017 at 3:39 PM, Frank Rowand <frowand.list@gmail.com> wrote:
> Hi Ulf, Rob,
>
> On 11/20/17 15:19, Ulf Samuelsson wrote:
>>
>>
>> On 2017-11-20 05:32, Frank Rowand wrote:
>>> Hi Ulf,
>>>
>>>
>>> On 11/19/17 23:23, Frank Rowand wrote:
>>>> adding devicetree list, devicetree maintainers
>>>>
>>>> On 11/18/17 12:59, Ulf Samuelsson wrote:
>>>>> I noticed when checking out the OpenWRT support for the board that they have a method to avoid having to pass the device tree address to the kernel, and can thus boot device tree based kernels with U-boots that
>>>>> does not support device trees.
>>>>>
>>>>> Is this something that would be considered useful for including in mainstream:
>>>>>
>>>>> BACKGROUND:
>>>>> Trying to load a yocto kernel into a MIPS target (MT7620A based),
>>>>> and the U-Boot is more than stupid.
>>>>> Does not support the "run" command as an example.
>>>>> They modified the U-Boot MAGIC Word to complicate things.
>>>>> The U-Boot is not configured to use device tree files.
>>>>> The board runs a 2.6 kernel right now.
>>>>>
>>>>> Several attempts by me a and others to rebuild U-Boot according to
>>>>> the H/W vendors source code and build instructions results in a
>>>>> bricked unit. Bricked units cannot be recovered.
>>>
>>> Hopefully you have brought this to the attention of the vendor. U-Boot
>>> is GPL v2 (or in some ways possibly GPL v2 or later), so if you can not
>>> build U-Boot that is equivalent to the binary U-Boot they shipped, the
>>> vendor may want to ensure that they are shipping the proper source and
>>> build instructions.
>>>
>>
>> I am not the one in contact with the H/W vendor.
>> The U-boot is pretty old, and from comments from those
>> in contact with them, the U-Boot knowledge at the H/W vendor
>> is minimal at best.
>> It might even be that they program an U-boot where the upgrade of the U-boot is broken...
>>
>>
>>>
>>>>> Not my choice of H/W, so I cannot change it.
>>>>>
>>>>>
>>>>> ===================================================================
>>>>> OPENWRT:
>>>>> I noticed when checking out the OpenWRT support for the board that
>>>>> they have a method to avoid having to pass the device tree address
>>>>> to the kernel, and can thus boot device tree based kernels with
>>>>> U-boots that does not support device trees.
>>>>>
>>>>> What they do is to reserve 16 kB of kernel space, and tag it with
>>>>> an ASCII string "OWRTDTB:". After the kernel and dtb is built, a
>>>>> utility "patch-dtb" will update the vmlinux binary, copying in the
>>>>> device tree file.
>>>>>
>>>>> ===================================================================
>>>>> It would be useful to me, and I could of course patch the
>>>>> mainstream kernel, but first I would like to check if this is of
>>>>> interest for mainstream.
>>>
>>> Not in this form. Hard coding a fixed size area in the boot image
>>> to contain the FDT (aka DTB) is a non-starter.
>>
>> OK, Is it the fixed size, which is a problem?
>
> Yes, it is the fixed size which is a problem.
>
>> Is generally combining an image with a DTB into a single file also a non-starter?
>
> Can you jump in here Rob? My understanding is that CONFIG_ARM_APPENDED_DTB,
> which is the ARM based solution that Mark mentioned, was envisioned as a
> temporary stop gap until boot loaders could add devicetree support. I don't
> know if there is a desire to limit this approach or to remove it in the
> future.
Yes, but I doubt we'll ever remove it. Most android devices use it (or
the multiple appended dtb stuff Qcom did) and there's out of tree
patches to do appended dtb on arm64. However, arm64 is a done a bit
differently in that the bootloader has to find the dtb rather than the
kernel (or really the decompressor). The purpose for arm64 is people
like the single kernel+dtb image, not legacy bootloader support as DT
support was there from day 1.
Another option is to do what's called an impedance matcher like this[1].
> I'm not sure why this feature should not be permanently supported. I'm being
> cautious, just in case I'm overlooking or missing an important issue, thus
> asking for Rob's input. I do know that this feature does not advance the
> desires of people who want a single kernel (single boot image?) that runs on
> many different systems, instead of a boot image that is unique to each
> target platform. But I don't see why that desire precludes also having
> an option to have a target specific boot image.
MIPS already supports built-in dtbs which is an in-kernel way to get
the dtb rather than the decompressor. The addition in this case is
just putting in a dummy dtb and putting in the real dtb later. I'm not
sure what MIPS image header looks like, but seems like it should be
possible to have the "built-in dtb" point to an appended dtb and just
update sizes in the image file. Then you don't have the fixed size.
But now that I finished writing this, I see there is already appended
DTB support in MIPS.
Rob
[1] https://github.com/zonque/pxa-impedance-matcher
^ permalink raw reply
* Re: [PATCH v3 4/5] pinctrl: mcp23s08: configure irq polarity using irq data
From: Sebastian Reichel @ 2017-11-21 16:30 UTC (permalink / raw)
To: Alexander Stein
Cc: Phil Reid, robh+dt, linus.walleij, mark.rutland, linux-gpio,
devicetree
In-Reply-To: <2197074.iKMxQHLgca@ws-stein>
[-- Attachment #1: Type: text/plain, Size: 3694 bytes --]
Hi,
On Tue, Nov 21, 2017 at 05:04:51PM +0100, Alexander Stein wrote:
> Hi,
>
> On Tuesday, November 21, 2017, 4:21:42 PM CET Sebastian Reichel wrote:
> >[...]
> > --------------------------------------------
> > gpio: host-gpio {
> > random-properties;
> > }
> >
> > inv: line-inverter {
> > /*
> > * configure the gpio controller input to be active low
> > * and the inverter interrupt output to be active low
> > */
> > interrupts = <&gpio ACTIVE_LOW>;
> > };
> >
> > mcp23xxx {
> > random-properties;
> >
> > /*
> > * configure the chip interrupt output to be active high
> > * and the inverter interrupt input to be active high
> > */
> > interrupts = <&inv ACTIVE_HIGH>;
> > }
> > --------------------------------------------
> >
> > versus
> >
> > --------------------------------------------
> > gpio: host-gpio {
> > random-properties;
> > }
> >
> > mcp23xxx {
> > random-properties;
> >
> > /* configure host interrupt input pin to be active low */
> > interrupts = <&gpio ACTIVE_LOW>;
> >
> > /* configure chip interrupt output pin to be active high */
> > microchip,irq-active-high;
> > }
> > --------------------------------------------
> >
> > I think this is something, that Rob should comment on. Obviously at
> > least in the mainline kernel nobody implemented the first solution
> > (since there is no fitting interrupt-invert driver), but there are
> > a few instances of the second variant. On the other hand the first
> > solution describes the hardware more detailed.
> >
> > > And if someone is relying on that implicit behaviour are we allowed
> > > to break things? Probably ok with this one as it's currently not possible
> > > due to code patch 1 removes.
> > >
> > > If we need to model the invert to get the patches accepted I look into that.
> > > I don't actually need it for my system as I can set open-drain with overrides
> > > the active-high control on this device, while have active high irq consumer.
> > > :)
> >
> > IMHO the explicit line-inverter is a bit over-engineered and
> > implicit line-inverter is enough, but I'm fine with both solutions.
> > I think the DT binding maintainers should comment on this though,
> > since it's pretty much a core decision about interrupt specifiers.
>
> Once you have a hardware, where one of several IRQ users is not attached to the
> inverter you need this inverter node anyway, caused by the mixed polarities.
> Also some IRQ controllers, like ARM GIC, only support rising edge interrupts
> (also level high).
>
> This might get important if there are dedicated IRQ pads connected to several
> users.
Both binding formats support this use-case as far as I can tell.
Since you seem to understand how it looks like with the inverter
node here is an example without it:
irqctrl: irq-controller {
random-properties;
}
mcp23xxx0 {
random-properties;
/*
* configure host interrupt input pin to be active high, since
* nothing else is supported by the interrupt controller
*/
interrupts = <&irqctrl ACTIVE_HIGH>;
/*
* configure chip interrupt output pin to be active low due to
* line invert
*/
microchip,irq-active-high;
}
mcp23xxx1 {
random-properties;
/*
* shared irq, see description from other chip
*/
interrupts = <&irqctrl ACTIVE_HIGH>;
/*
* configure chip interrupt output pin to be active high, since
* it's routed through the line invert
*/
/* microchip,irq-active-high; */
}
-- Sebastian
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [v5 RESEND 02/17] mfd: madera: Add DT bindings for Cirrus Logic Madera codecs
From: Richard Fitzgerald @ 2017-11-21 16:14 UTC (permalink / raw)
To: Rob Herring, Richard Fitzgerald
Cc: gnurou, alsa-devel, jason, devicetree, linus.walleij, patches,
linux-kernel, linux-gpio, broonie, tglx, lee.jones
In-Reply-To: <20171120184622.yor2xemxbbvicmmi@rob-hp-laptop>
Sorry all, I don't know what's gone wrong here. The acks are there on my
computer and I double-checked before I sent but somewhere all the acks
have been stripped.
When I've figured out what went wrong I'll re-send the chain with the acks.
On 20/11/17 18:46, Rob Herring wrote:
> On Mon, Nov 20, 2017 at 02:10:36PM +0000, Richard Fitzgerald wrote:
>> From: Richard Fitzgerald <rf@opensource.wolfsonmicro.com>
>>
>> Specification of the bindings for the parent MFD driver component
>> of the Cirrus Logic Madera codec drivers.
>>
>> Note that although the interrupt controller and GPIO are child
>> drivers their required bindings are trivial, mandatory, and exist
>> within the parent MFD node so are documented here.
>>
>> Signed-off-by: Richard Fitzgerald <rf@opensource.wolfsonmicro.com>
>> ---
>> Documentation/devicetree/bindings/mfd/madera.txt | 102 +++++++++++++++++++++++
>> 1 file changed, 102 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/mfd/madera.txt
> Please add acks when posting new versions.
>
> Rob
^ 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