* Re: [PATCH v6 3/6] dt-bindings: clock: renesas,rzn1-clocks: document RZ/N1 clock driver
From: Rob Herring @ 2018-05-23 15:42 UTC (permalink / raw)
To: M P
Cc: Michel Pollet, open list:MEDIA DRIVERS FOR RENESAS - FCP,
Simon Horman, Phil Edworthy, Michel Pollet, Magnus Damm,
Mark Rutland, Michael Turquette, Stephen Boyd, Geert Uytterhoeven,
devicetree, linux-kernel@vger.kernel.org, linux-clk
In-Reply-To: <CAMMfpEwn3+fCZZZ8ADNxjun+jzNSnH+8xPcA8OUS_jPUJ-o6LA@mail.gmail.com>
On Wed, May 23, 2018 at 1:52 AM, M P <buserror@gmail.com> wrote:
> Hi Rob,
>
> On Tue, 22 May 2018 at 17:09, Rob Herring <robh@kernel.org> wrote:
>
>> On Tue, May 22, 2018 at 11:01:23AM +0100, Michel Pollet wrote:
>> > The Renesas RZ/N1 Family (Part #R9A06G0xx) requires a driver
>> > to provide the SoC clock infrastructure for Linux.
>> >
>> > This documents the driver bindings.
>> >
>> > Signed-off-by: Michel Pollet <michel.pollet@bp.renesas.com>
>> > ---
>> > .../bindings/clock/renesas,rzn1-clocks.txt | 44
> ++++++++++++++++++++++
>> > 1 file changed, 44 insertions(+)
>> > create mode 100644
> Documentation/devicetree/bindings/clock/renesas,rzn1-clocks.txt
>> >
>> > diff --git
> a/Documentation/devicetree/bindings/clock/renesas,rzn1-clocks.txt
> b/Documentation/devicetree/bindings/clock/renesas,rzn1-clocks.txt
>> > new file mode 100644
>> > index 0000000..0c41137
>> > --- /dev/null
>> > +++ b/Documentation/devicetree/bindings/clock/renesas,rzn1-clocks.txt
>> > @@ -0,0 +1,44 @@
>> > +* Renesas RZ/N1 Clock Driver
>> > +
>> > +This driver provides the clock infrastructure used by all the other
> drivers.
>
>> Bindings document h/w not drivers.
>
>> > +
>> > +One of the 'special' feature of this infrastructure is that Linux
> doesn't
>
>> Bindings are not just for Linux.
>
>> > +necessary 'own' all the clocks on the SoC, some other OS runs on
>> > +the Cortex-M3 core and that OS can access and claim it's own clocks.
>
>> How is this relevant to the binding?
>
> Well you just said it, if the binding is not just for linux, it's probably
> a good idea to mention it somewhere since I can promise you it's *not*
> documented in the hardware manual. Whatever this binding is for, it's
> relevant to point out it is different from the other clock drivers in the
> same directory... ?
That's not an uncommon issue (sometimes it's secure world that owns
the clocks, not even a different processor). I'm just not sure what I
do with this information. It doesn't tell me which clocks are owned by
the M3 or not.
>> > +
>> > +Required Properties:
>> > +
>> > + - compatible: Must be
>> > + - "renesas,r9a06g032-clocks" for the RZ/N1D
>> > + and "renesas,rzn1-clocks" as a fallback.
>
>> Is "clocks" how the chip reference manual refers to this block?
>
> No, the block is called 'sysctrl' and has tons of other stuff in there.
> I've tried multiple times to get a 'sysctrl' driver in the previous
> versions of the patch, in various shape or form, and I can't because I'd be
> supposed to 'document' binding for stuff that has no code, no purpose, no
> testing, and have all wildly different topics. So, after some more
> lengthily discussion with Geert, we've decided to make the 'primary'
> feature of that block (clocks) as a driver, and see from there onward.
If you are referring to Geert's reply on v4, then this is not how I
interpreted it. I understood it as make the clock driver bind to the
sysctrl node and the clock driver can register other functions like
reset. Then later if you need multiple drivers, you can make an MFD
driver that binds to the sysctrl node and creates child devices to
bind sub-drivers (like clocks) to. But the DT doesn't change in the
process wrt clocks.
You don't have to have a driver for everything, but the binding should
be as complete as possible and done in an extendable way. The way you
have done it now is not. I can already see that at some point you will
want to break things and do something like this:
{
compatible = "renesas,r9a06g032-sysctrl";
...
{
compatible = "renesas,r9a06g032-clocks";
...
};
};
Which is likely wrong because there's no need to have a child node
like that. The parent node can be the clock provider (and any other
provider). There are cases when child nodes do make sense, but we need
a more complete binding to make that decision. Evolving it one feature
at a time doesn't work.
Rob
^ permalink raw reply
* Re: [PATCH v11 0/2] Kryo CPU scaling driver
From: Sudeep Holla @ 2018-05-23 15:41 UTC (permalink / raw)
To: Ilia Lin
Cc: vireshk, nm, sboyd, robh, mark.rutland, rjw, linux-pm, devicetree,
linux-kernel, Sudeep Holla
In-Reply-To: <f53d6035-d409-4535-9dd0-03baedc9b4a8@email.android.com>
On Wed, May 23, 2018 at 06:34:06PM +0300, Ilia Lin wrote:
> It may be merged alone safely. However to actually work, it needs a clock
> driver as well, and the OPP tables in tue device tree. Those are submitted now
> 8n 2 separate series. This is in order to provide each maintainer with domain
> specific series, as per Viresh's suggestion.
I understand that. I was trying to get overall structure to better understand
how it all glue together in the system(just for self education).
--
Regards,
Sudeep
^ permalink raw reply
* Re: [PATCH v3 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings
From: Mark Brown @ 2018-05-23 15:40 UTC (permalink / raw)
To: Doug Anderson
Cc: David Collins, Liam Girdwood, Rob Herring, Mark Rutland,
linux-arm-msm, Linux ARM, devicetree, LKML, Rajendra Nayak,
Stephen Boyd
In-Reply-To: <CAD=FV=XfPkpGD32MfTfcw02wQ+QetpUhY=P299uhpX6pY_iEvg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1721 bytes --]
On Wed, May 23, 2018 at 08:23:22AM -0700, Doug Anderson wrote:
> Hi,
>
> On Wed, May 23, 2018 at 1:29 AM, Mark Brown <broonie@kernel.org> wrote:
>
> > It's arguable either way - you could say that the client gets to specify
> > a safe range at all times or you could say that the machine constraints
> > should cover all cases where the hardware is idling. Of course RPMh
> > is missing anything like the machine constraints (as we can see from all
> > the fixing up of undesirable hard coding we have to do) so it's kind of
> > pushed towards the first case.
> OK, fair enough. If others all agree that it's OK to make requests
> about the voltage of a disabled regulator then I won't stand in the
> way. I guess it does call into question the whole idea of caching /
> not sending the voltage until the first enable because it means
> there's no way for the client to use this feature until they've
> enabled / disabled the regulator once. If you think of it as invalid
> to adjust the voltage of a disabled regulator then the caching
> argument is super clean, but once you say that you should normally be
It's got to be valid to think about the voltage of a disabled regulator
since drivers want to be able make sure that the regulator gets enabled
with a sensible config. With most hardware this is really easy since
you can just look at the status reported by the hardware but the RPM
makes this hard since there's so much write only stuff in there.
> able to do it it feels more like a hacky workaround. ...but I suppose
> that's what we've got to live with...
These RPM systems are always going to have problems of some kind
unfortunately unless the interface changes.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v3 0/7] Add support for QCA8334 switch
From: Florian Fainelli @ 2018-05-23 15:39 UTC (permalink / raw)
To: Michal Vokáč, netdev
Cc: linux-kernel, devicetree, vivien.didelot, andrew, mark.rutland,
robh+dt, davem, michal.vokac
In-Reply-To: <1527056424-14528-1-git-send-email-michal.vokac@ysoft.com>
On 05/22/2018 11:20 PM, Michal Vokáč wrote:
> This series basically adds support for a QCA8334 ethernet switch to the
> qca8k driver. It is a four-port variant of the already supported seven
> port QCA8337. Register map is the same for the whole familly and all chips
> have the same device ID.
>
> Major part of this series enhances the CPU port setting. Currently the CPU
> port is not set to any sensible defaults compatible with the xGMII
> interface. This series forces the CPU port to its maximum bandwidth and
> also allows to adjust the new defaults using fixed-link device tree
> sub-node.
>
> Alongside these changes I fixed two checkpatch warnings regarding SPDX and
> redundant parentheses.
Looks great, thanks Michal! Do you have any features or things you are
working on that would be added later to the driver?
>
> Changes in v3:
> - Rebased on latest net-next/master.
> - Corrected fixed-link documentation.
>
> Michal Vokáč (7):
> net: dsa: qca8k: Add QCA8334 binding documentation
> net: dsa: qca8k: Add support for QCA8334 switch
> net: dsa: qca8k: Enable RXMAC when bringing up a port
> net: dsa: qca8k: Force CPU port to its highest bandwidth
> net: dsa: qca8k: Allow overwriting CPU port setting
> net: dsa: qca8k: Replace GPL boilerplate by SPDX
> net: dsa: qca8k: Remove redundant parentheses
>
> .../devicetree/bindings/net/dsa/qca8k.txt | 23 +++++++-
> drivers/net/dsa/qca8k.c | 64 ++++++++++++++++++----
> drivers/net/dsa/qca8k.h | 7 ++-
> 3 files changed, 79 insertions(+), 15 deletions(-)
>
--
Florian
^ permalink raw reply
* Re: [PATCH net-next v3 2/7] net: dsa: qca8k: Add support for QCA8334 switch
From: Florian Fainelli @ 2018-05-23 15:38 UTC (permalink / raw)
To: Michal Vokáč, netdev
Cc: linux-kernel, devicetree, vivien.didelot, andrew, mark.rutland,
robh+dt, davem, michal.vokac
In-Reply-To: <1527056424-14528-3-git-send-email-michal.vokac@ysoft.com>
On 05/22/2018 11:20 PM, Michal Vokáč wrote:
> Add support for the four-port variant of the Qualcomm QCA833x switch.
>
> Signed-off-by: Michal Vokáč <michal.vokac@ysoft.com>
> Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* Re: [PATCH net-next v3 1/7] net: dsa: qca8k: Add QCA8334 binding documentation
From: Florian Fainelli @ 2018-05-23 15:37 UTC (permalink / raw)
To: Michal Vokáč, netdev
Cc: linux-kernel, devicetree, vivien.didelot, andrew, mark.rutland,
robh+dt, davem, michal.vokac
In-Reply-To: <1527056424-14528-2-git-send-email-michal.vokac@ysoft.com>
On 05/22/2018 11:20 PM, Michal Vokáč wrote:
> Add support for the four-port variant of the Qualcomm QCA833x switch.
>
> The CPU port default link settings can be reconfigured using
> a fixed-link sub-node.
>
> Signed-off-by: Michal Vokáč <michal.vokac@ysoft.com>
> Reviewed-by: Rob Herring <robh@kernel.org>
> Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* Re: [PATCH v11 0/2] Kryo CPU scaling driver
From: Ilia Lin @ 2018-05-23 15:34 UTC (permalink / raw)
To: Sudeep Holla
Cc: vireshk, nm, sboyd, robh, mark.rutland, rjw, linux-pm, devicetree,
linux-kernel
In-Reply-To: <b4c28b51-ecd5-649b-e8fa-e5ce1bbb3139@arm.com>
[-- Attachment #1: Type: text/html, Size: 297 bytes --]
^ permalink raw reply
* Re: [PATCH v3 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings
From: Doug Anderson @ 2018-05-23 15:23 UTC (permalink / raw)
To: Mark Brown
Cc: David Collins, Liam Girdwood, Rob Herring, Mark Rutland,
linux-arm-msm, Linux ARM, devicetree, LKML, Rajendra Nayak,
Stephen Boyd
In-Reply-To: <20180523082908.GB4828@sirena.org.uk>
Hi,
On Wed, May 23, 2018 at 1:29 AM, Mark Brown <broonie@kernel.org> wrote:
> It's arguable either way - you could say that the client gets to specify
> a safe range at all times or you could say that the machine constraints
> should cover all cases where the hardware is idling. Of course RPMh
> is missing anything like the machine constraints (as we can see from all
> the fixing up of undesirable hard coding we have to do) so it's kind of
> pushed towards the first case.
OK, fair enough. If others all agree that it's OK to make requests
about the voltage of a disabled regulator then I won't stand in the
way. I guess it does call into question the whole idea of caching /
not sending the voltage until the first enable because it means
there's no way for the client to use this feature until they've
enabled / disabled the regulator once. If you think of it as invalid
to adjust the voltage of a disabled regulator then the caching
argument is super clean, but once you say that you should normally be
able to do it it feels more like a hacky workaround. ...but I suppose
that's what we've got to live with...
-Doug
^ permalink raw reply
* Re: [PATCH v6 4/5] arm64: dts: sdm845: Add serial console support
From: Doug Anderson @ 2018-05-23 15:13 UTC (permalink / raw)
To: Rajendra Nayak
Cc: Karthikeyan Ramasubramanian, Jonathan Corbet, Andy Gross,
David Brown, Rob Herring, Mark Rutland, Wolfram Sang, linux-doc,
linux-arm-msm, devicetree, linux-i2c, Evan Green, acourbot,
Stephen Boyd, Bjorn Andersson
In-Reply-To: <ebe4515d-a26f-a825-0353-666b0b5ad9f5@codeaurora.org>
Rajendra,
On Tue, May 22, 2018 at 11:30 PM, Rajendra Nayak <rnayak@codeaurora.org> wrote:
>
>
> On 03/30/2018 10:38 PM, Karthikeyan Ramasubramanian wrote:
>> From: Rajendra Nayak <rnayak@codeaurora.org>
>>
>> Add the qup uart node and geni se instance needed to
>> support the serial console on the MTP.
>>
>> Signed-off-by: Rajendra Nayak <rnayak@codeaurora.org>
>> Signed-off-by: Karthikeyan Ramasubramanian <kramasub@codeaurora.org>
>> ---
>
> Andy, is it possible to pull this one in for 4.18?
> Sorry, I only realized we somehow missed this after looking at your pull request.
>
> This is the only patch that prevents linux-next from booting up my sdm845 MTP
> to a minimal console shell.
It was in Andy's tree but then got dropped. Unfortunately the clock
bindings didn't land early enough so it's a bit difficult to land any
device tree changes that use the clock bindings until the next kernel
revision...
-Doug
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: cpufreq: Introduce QCOM CPUFREQ FW bindings
From: Sudeep Holla @ 2018-05-23 15:13 UTC (permalink / raw)
To: Taniya Das, linux-kernel, linux-pm, Stephen Boyd, robh
Cc: Rafael J. Wysocki, Viresh Kumar, Sudeep Holla, Rajendra Nayak,
Amit Nischal, devicetree, skannan, amit.kucheria
In-Reply-To: <1526751291-17873-2-git-send-email-tdas@codeaurora.org>
On 19/05/18 18:34, Taniya Das wrote:
> Add QCOM cpufreq firmware device bindings for Qualcomm Technology Inc's
> SoCs. This is required for managing the cpu frequency transitions which are
> controlled by firmware.
>
> Signed-off-by: Taniya Das <tdas@codeaurora.org>
> ---
> .../bindings/cpufreq/cpufreq-qcom-fw.txt | 68 ++++++++++++++++++++++
> 1 file changed, 68 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-fw.txt
>
> diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-fw.txt b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-fw.txt
> new file mode 100644
> index 0000000..bc912f4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-fw.txt
> @@ -0,0 +1,68 @@
> +Qualcomm Technologies, Inc. CPUFREQ Bindings
> +
> +CPUFREQ FW is a hardware engine used by some Qualcomm Technologies, Inc. (QTI)
> +SoCs to manage frequency in hardware. It is capable of controlling frequency
> +for multiple clusters.
> +
> +Properties:
> +- compatible
> + Usage: required
> + Value type: <string>
> + Definition: must be "qcom,cpufreq-fw".
> +
If the firmware is referred with some other name, better to use that
than cpufreq
> +Note that #address-cells, #size-cells, and ranges shall be present to ensure
> +the cpufreq can address a freq-domain registers.
> +
> +A freq-domain sub-node would be defined for the cpus with the following
> +properties:
> +
> +- compatible:
> + Usage: required
> + Value type: <string>
> + Definition: must be "cpufreq".
> +
> +- reg
> + Usage: required
> + Value type: <prop-encoded-array>
> + Definition: Addresses and sizes for the memory of the perf_base
> + , lut_base and en_base.
Can you explicitly define each one of them ? Either here or in reg-names.
> +- reg-names
> + Usage: required
> + Value type: <stringlist>
> + Definition: Address names. Must be "perf_base", "lut_base",
> + "en_base".
> + Must be specified in the same order as the
> + corresponding addresses are specified in the reg
> + property.
> +
> +- qcom,cpulist
> + Usage: required
> + Value type: <phandles of CPU>
> + Definition: List of related cpu handles which are under a cluster.
> +
As already mentioned by Rob and Viresh, better to align with OPP style
to avoid phandle list of CPUs.
Also I see similar bindings for devfreq, can't they be aligned ?
E.g. lut_base here while it's ftbl_base in devfreq.
--
Regards,
Sudeep
[1] https://lkml.org/lkml/2018/5/18/136
^ permalink raw reply
* Re: [PATCH v2 2/5] gpio: syscon: Add gpio-syscon for rockchip
From: Heiko Stübner @ 2018-05-23 15:12 UTC (permalink / raw)
To: Rob Herring
Cc: Levin Du, open list:ARM/Rockchip SoC..., Wayne Chou, devicetree,
Linus Walleij, linux-kernel@vger.kernel.org,
open list:GPIO SUBSYSTEM, Mark Rutland,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <CAL_Jsq+_QEBWdxW=J4oVGWeokc-+nMzxzX_pgCayaxg-ehivfQ@mail.gmail.com>
Hi Rob, Levin,
sorry for being late to the party.
Am Mittwoch, 23. Mai 2018, 16:43:07 CEST schrieb Rob Herring:
> On Tue, May 22, 2018 at 9:02 PM, Levin Du <djw@t-chip.com.cn> wrote:
> > On 2018-05-23 2:02 AM, Rob Herring wrote:
> >> On Fri, May 18, 2018 at 11:52:05AM +0800, djw@t-chip.com.cn wrote:
> >>> From: Levin Du <djw@t-chip.com.cn>
> >>>
> >>> Some GPIOs sit in the GRF_SOC_CON registers of Rockchip SoCs,
> >>> which do not belong to the general pinctrl.
> >>>
> >>> Adding gpio-syscon support makes controlling regulator or
> >>> LED using these special pins very easy by reusing existing
> >>> drivers, such as gpio-regulator and led-gpio.
> >>>
> >>> Signed-off-by: Levin Du <djw@t-chip.com.cn>
> >>>
> >>> ---
> >>>
> >>> Changes in v2:
> >>> - Rename gpio_syscon10 to gpio_mute in doc
> >>>
> >>> Changes in v1:
> >>> - Refactured for general gpio-syscon usage for Rockchip SoCs.
> >>> - Add doc rockchip,gpio-syscon.txt
> >>>
> >>> .../bindings/gpio/rockchip,gpio-syscon.txt | 41
> >>>
> >>> ++++++++++++++++++++++
> >>>
> >>> drivers/gpio/gpio-syscon.c | 30
> >>>
> >>> ++++++++++++++++
> >>>
> >>> 2 files changed, 71 insertions(+)
> >>> create mode 100644
> >>>
> >>> Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt
> >>>
> >>> diff --git
> >>> a/Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt
> >>> b/Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt
> >>> new file mode 100644
> >>> index 0000000..b1b2a67
> >>> --- /dev/null
> >>> +++ b/Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt
> >>> @@ -0,0 +1,41 @@
> >>> +* Rockchip GPIO support for GRF_SOC_CON registers
> >>> +
> >>> +Required properties:
> >>> +- compatible: Should contain "rockchip,gpio-syscon".
> >>> +- gpio-controller: Marks the device node as a gpio controller.
> >>> +- #gpio-cells: Should be two. The first cell is the pin number and
> >>> + the second cell is used to specify the gpio polarity:
> >>> + 0 = Active high,
> >>> + 1 = Active low.
> >>
> >> There's no need for this child node. Just make the parent node a gpio
> >> controller.
> >>
> >> Rob
> >
> > Hi Rob, it is not clear to me. Do you suggest that the grf node should be
> > a
> > gpio controller,
> > like below?
> >
> > + grf: syscon at ff100000 {
> > + compatible = "rockchip,gpio-syscon", "rockchip,rk3328-grf",
> > "syscon", "simple-mfd";
>
> Yes, but drop "rockchip,gpio-syscon" and "simple-mfd".
I would disagree quite a bit here. The grf are the "general register files",
a bunch of registers used for quite a lot of things, and so it seems
among other users, also a gpio-controller for some more random pins
not controlled through the regular gpio controllers.
For a more fully stocked grf, please see
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/rk3288.dtsi#n855
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/rockchip/rk3399.dtsi#n1338
So the gpio controller should definitly also be a subnode.
The gpio in question is called "mute", so I'd think the gpio-syscon driver
should just define a "rockchip,rk3328-gpio-mute" compatible and contain
all the register voodoo in the driver itself and not define it in the dt.
So it should probably look like
grf: syscon at ff100000 {
compatible = "rockchip,rk3328-grf", "syscon", "simple-mfd";
[all the other syscon sub-devices]
gpio_mute: gpio-mute {
compatible = "rockchip,rk3328-gpio-mute";
gpio-controller;
#gpio-cells = <2>;
};
[more other syscon sub-devices]
};
Heiko
> > + //...
> > + gpio-controller;
> > + #gpio-cells = <2>;
> > + gpio,syscon-dev = <&grf 0x0428 0>;
>
> And drop this. It may be used in the kernel, but it is not a
> documented property.
>
> > + };
> >
> > or just reserve the following case in the doc?
> >
> > + grf: syscon at ff100000 {
> > + compatible = "rockchip,rk3328-grf", "syscon", "simple-mfd";
> > + //...
> > + };
> > +
> > + gpio_mute: gpio-mute {
> > + compatible = "rockchip,gpio-syscon";
> > + gpio-controller;
> > + #gpio-cells = <2>;
> > + gpio,syscon-dev = <&grf 0x0428 0>;
> > + };
> >
> >
> > Thanks
> > Levin
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe devicetree" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [v4 07/11] dt-bindings: hwmon: Add documents for PECI hwmon client drivers
From: Rob Herring @ 2018-05-23 15:11 UTC (permalink / raw)
To: Jae Hyun Yoo
Cc: Mark Rutland, Haiyue Wang, Vernon Mauery, James Feist, devicetree,
linux-kernel@vger.kernel.org, Andrew Jeffery, Arnd Bergmann,
Jason M Biils, Joel Stanley
In-Reply-To: <a05b44a2-ecc8-b028-4308-47d88523a6f1@linux.intel.com>
On Tue, May 22, 2018 at 12:18 PM, Jae Hyun Yoo
<jae.hyun.yoo@linux.intel.com> wrote:
> On 5/22/2018 9:42 AM, Rob Herring wrote:
>>
>> On Mon, May 21, 2018 at 12:59:05PM -0700, Jae Hyun Yoo wrote:
>>>
>>> This commit adds dt-bindings documents for PECI hwmon client drivers.
>>>
>>> Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
>>> Reviewed-by: Haiyue Wang <haiyue.wang@linux.intel.com>
>>> Reviewed-by: James Feist <james.feist@linux.intel.com>
>>> Reviewed-by: Vernon Mauery <vernon.mauery@linux.intel.com>
>>> Cc: Andrew Jeffery <andrew@aj.id.au>
>>> Cc: Arnd Bergmann <arnd@arndb.de>
>>> Cc: Jason M Biils <jason.m.bills@linux.intel.com>
>>> Cc: Joel Stanley <joel@jms.id.au>
>>> ---
>>> .../bindings/hwmon/peci-cputemp.txt | 23 ++++++++++++++++++
>>> .../bindings/hwmon/peci-dimmtemp.txt | 24 +++++++++++++++++++
>>> 2 files changed, 47 insertions(+)
>>> create mode 100644
>>> Documentation/devicetree/bindings/hwmon/peci-cputemp.txt
>>> create mode 100644
>>> Documentation/devicetree/bindings/hwmon/peci-dimmtemp.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/hwmon/peci-cputemp.txt
>>> b/Documentation/devicetree/bindings/hwmon/peci-cputemp.txt
>>> new file mode 100644
>>> index 000000000000..2f59aee12d9e
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/hwmon/peci-cputemp.txt
>>> @@ -0,0 +1,23 @@
>>> +Bindings for Intel PECI (Platform Environment Control Interface) cputemp
>>> driver.
>>> +
>>> +Required properties:
>>> +- compatible : Should be "intel,peci-cputemp".
>>> +- reg : Should contain address of a client CPU. Address range of
>>> CPU
>>> + clients is starting from 0x30 based on PECI specification.
>>> +
>>> +Example:
>>> + peci-bus@0 {
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> + < more properties >
>>> +
>>> + peci-cputemp@30 {
>>> + compatible = "intel,peci-cputemp";
>>> + reg = <0x30>;
>>> + };
>>
>>
>> [...]
>>
>>> + peci-dimmtemp@30 {
>>> + compatible = "intel,peci-dimmtemp";
>>> + reg = <0x30>;
>>> + };
>>
>>
>> As I said in the prior version, 2 nodes at the same address is wrong.
>>
>> Rob
>>
>
> In PECI bus, there is one and only bus host (adapter) and multiple
> clients on a PECI bus, and PECI spec doesn't allow multiple originators
> so only the host device can originate message.
Yes, I get that. A single host still has to address slave devices.
> In this implementation,
> all message transactions on a bus from client driver modules and user
> space will be serialized well in the PECI core bus driver so bus
> occupation and traffic arbitration will be managed well in the PECI core
> bus driver even in case of a bus has 2 client drivers at the same
> address. I'm sure that this implementation doesn't make that kind of
> problem to OS.
Multiple clients to a single device is common, but that is a software
problem and doesn't belong in DT.
I don't think there is a single other case in the kernel where
multiple drivers can bind to the same device at a given bus address.
That is why we have things like MFD. Though in this case, why can't
one hwmon driver register multiple hwmon devices (cpu and dimm temps)?
Rob
^ permalink raw reply
* Re: [PATCH/RFC v4 2/4] usb: gadget: udc: renesas_usb3: Add register of usb role switch
From: Rob Herring @ 2018-05-23 15:00 UTC (permalink / raw)
To: Yoshihiro Shimoda
Cc: gregkh@linuxfoundation.org, mark.rutland@arm.com,
heikki.krogerus@linux.intel.com, hdegoede@redhat.com,
andy.shevchenko@gmail.com, linux-usb@vger.kernel.org,
linux-renesas-soc@vger.kernel.org, devicetree@vger.kernel.org
In-Reply-To: <OSBPR01MB229367114CFC1AC30C0430E4D86B0@OSBPR01MB2293.jpnprd01.prod.outlook.com>
On Wed, May 23, 2018 at 1:52 AM, Yoshihiro Shimoda
<yoshihiro.shimoda.uh@renesas.com> wrote:
> Hi Rob,
>
> Thank you for the review!
>
>> From: Rob Herring, Sent: Wednesday, May 23, 2018 2:13 AM
>>
>> On Tue, May 22, 2018 at 09:01:07PM +0900, Yoshihiro Shimoda wrote:
>> > This patch adds role switch support for R-Car SoCs into the USB 3.0
>> > peripheral driver. Some R-Car SoCs (e.g. R-Car H3) have USB 3.0
>> > dual-role device controller which has the USB 3.0 xHCI host and
>> > Renesas USB 3.0 peripheral.
>> >
>> > Unfortunately, the mode change register contains the USB 3.0 peripheral
>> > controller side only. So, the USB 3.0 peripheral driver (renesas_usb3)
>> > manages this register now. However, in peripheral mode, the host
>> > should stop. Also the host hardware needs to reinitialize its own
>> > registers when the mode changes from peripheral to host mode.
>> > Otherwise, the host cannot work correctly (e.g. detect a device as
>> > high-speed).
>> >
>> > To achieve this by a driver, this role switch driver manages
>> > the mode change register and attach/release the xhci-plat driver.
>> >
>> > Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
>> > ---
>> > .../devicetree/bindings/usb/renesas_usb3.txt | 15 ++++
>>
>> Please split bindings to a separate patch.
>
> Oops. I got it.
>
>> > drivers/usb/gadget/udc/Kconfig | 1 +
>> > drivers/usb/gadget/udc/renesas_usb3.c | 82 ++++++++++++++++++++++
>> > 3 files changed, 98 insertions(+)
>> >
>> > diff --git a/Documentation/devicetree/bindings/usb/renesas_usb3.txt
>> b/Documentation/devicetree/bindings/usb/renesas_usb3.txt
>> > index 2c071bb5..f6105aa 100644
>> > --- a/Documentation/devicetree/bindings/usb/renesas_usb3.txt
>> > +++ b/Documentation/devicetree/bindings/usb/renesas_usb3.txt
>> > @@ -19,6 +19,9 @@ Required properties:
>> > Optional properties:
>> > - phys: phandle + phy specifier pair
>> > - phy-names: must be "usb"
>> > + - The connection to a usb3.0 host node needs by using OF graph bindings for
>> > + usb role switch.
>> > + - port@0 = USB3.0 host port.
>>
>> On the host side, this might conflict with the USB connector binding.
>>
>> I would either make sure this can work with the connector binding by
>> having 2 endpoints on the HS or SS port or just use the 'companion'
>> property defined in usb-generic.txt.
>
> I don't understand the first one now... This means the renesas_usb3 should follow
> USB connector binding and have 2 endpoints for the usb role switch to avoid
> the conflict like below?
> - port1@0: Super Speed (SS), present in SS capable connectors (from usb-connector.txt).
> - port1@1: USB3.0 host port.
I'm confused, SS and USB3.0 are the same essentially. It would be:
port@1/endpoint@0: SS host port
port@1/endpoint@1: SS device port
> About the 'companion' in usb-generic.txt, the property intends to be used for EHCI or host side
> like the commit log [1]. If there is accept to use 'companion' for this patch, I think it will
> be simple to achieve this role switch feature. However, in last month, I submitted a similar patch [2]
> that has "renesas,host" property, but I got reply from Andy [3] and Heikki [4]. So, I'm
> trying to improve the device connection framework [5] now.
I think this case is rare enough that we don't need a general solution
using OF graph, so I'm fine with a simple, single property to link the
2 nodes. Either reusing "companion" or "renesas,host" is fine by me.
Rob
>
> [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/Documentation/devicetree/bindings/usb/generic.txt?h=v4.17-rc6&id=5095cb89c62acc78b4cfaeb9a4072979d010510a
>
> [2]
> https://www.spinics.net/lists/linux-usb/msg167773.html
>
> [3]
> https://www.spinics.net/lists/linux-usb/msg167780.html
>
> [4]
> https://www.spinics.net/lists/linux-usb/msg167806.html
>
> [5]
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/driver-api/device_connection.rst
>
> Best regards,
> Yoshihiro Shimoda
>
>> Rob
^ permalink raw reply
* Re: [PATCH V3 8/8] dt-bindings: stm32: add compatible for syscon
From: Rob Herring @ 2018-05-23 14:47 UTC (permalink / raw)
To: Christophe ROULLIER
Cc: mark.rutland@arm.com, mcoquelin.stm32@gmail.com, Alexandre TORGUE,
Peppe CAVALLARO, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, netdev@vger.kernel.org,
andrew@lunn.ch
In-Reply-To: <4f6941a0-4b41-f2db-52b1-d45aa7287fa2@st.com>
On Wed, May 23, 2018 at 4:32 AM, Christophe ROULLIER
<christophe.roullier@st.com> wrote:
> On 05/22/2018 07:22 PM, Rob Herring wrote:
>> On Mon, May 21, 2018 at 10:07:26AM +0200, Christophe Roullier wrote:
>>> This patch describes syscon DT bindings.
>>>
>>> Signed-off-by: Christophe Roullier <christophe.roullier@st.com>
>>> ---
>>> Documentation/devicetree/bindings/arm/stm32.txt | 5 +++++
>>> 1 file changed, 5 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/arm/stm32.txt b/Documentation/devicetree/bindings/arm/stm32.txt
>>> index 6808ed9..e46ebad 100644
>>> --- a/Documentation/devicetree/bindings/arm/stm32.txt
>>> +++ b/Documentation/devicetree/bindings/arm/stm32.txt
>>> @@ -8,3 +8,8 @@ using one of the following compatible strings:
>>> st,stm32f746
>>> st,stm32h743
>>> st,stm32mp157
>>> +
>>> +Required nodes:
>>> +- syscon: the soc bus node must have a system controller node pointing to the
>>> + global control registers, with the compatible string
>>> + "st,stm32mp157-syscfg", "syscon";
>>
>> Please don't mix soc/board bindings with other nodes. So perhaps
>> stm32-syscon.txt.
>>
>> Rob
>>
>
> Hi Rob,
>
> Is it ok for you with this tree file:
Yes, one nit below.
>
> Documentation/devicetree/bindings/arm/stm32/stm32.txt
> Documentation/devicetree/bindings/arm/stm32/stm32-syscon.txt
> With stm32-syscon.txt:
>
> ---------------------------------------------------
> STMicroelectronics STM32 Platforms System Controller
>
> Properties:
> - compatible : should contain two values. First value must be :
> - " st,stm32mp157-syscfg " - for stm32mp157 based SoCs,
> second value must be always "syscon".
> - reg : offset and length of the register set.
>
> Example:
> syscfg: system-config@50020000 {
syscon@...
> compatible = "st,stm32mp157-syscfg", "syscon";
> reg = <0x50020000 0x400>;
> };
> ---------------------------------------------------
>
> Do we need to update also all MCU family (stm32f4, stm32h7, stm32f7)
> property to be coherent ?
Yes, if they all have the same or similar syscfg block.
>
> Thanks for your feedback.
>
> Christophe.
>
^ permalink raw reply
* Re: [PATCH v2 1/3] input: touchscreen: edt-ft5x06: don't make device a wakeup source by default
From: Rob Herring @ 2018-05-23 14:45 UTC (permalink / raw)
To: Daniel Mack
Cc: Mark Rutland, devicetree, Dmitry Torokhov, Sascha Hauer,
linux-input, Fabio Estevam, Shawn Guo,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <52c1cd13-3386-8f70-aaf2-e5f4b19fd1e6@zonque.org>
On Wed, May 23, 2018 at 3:27 AM, Daniel Mack <daniel@zonque.org> wrote:
> On Tuesday, May 22, 2018 07:54 PM, Rob Herring wrote:
>>
>> On Thu, May 17, 2018 at 11:05:50AM +0200, Daniel Mack wrote:
>>>
>>> Allow configuring the device as wakeup source through device properties,
>>> as
>>> not all platforms want to wake up on touch screen activity.
>>>
>>> The I2C core automatically reads the "wakeup-source" DT property to
>>> configure a device's wakeup capability, and board supports files can set
>>> I2C_CLIENT_WAKE in the flags.
>>
>>
>> This will break wake-up on working systems. Looks like mostly i.MX, but
>> there's one AM437x board. If that board doesn't care, then it is up to
>> Shawn.
>
>
> I added the property to the dts files, but as Dmitry pointed out, I missed
> some. Sorry for that.
Just adding the property to dts files doesn't fix the compatibility
problem. If a user uses an existing dtb (before this change) with a
new kernel (after this change), then wakeup will stop working.
Rob
^ permalink raw reply
* Re: [PATCH v2 2/5] gpio: syscon: Add gpio-syscon for rockchip
From: Rob Herring @ 2018-05-23 14:43 UTC (permalink / raw)
To: Levin Du
Cc: open list:ARM/Rockchip SoC..., Wayne Chou, Heiko Stuebner,
devicetree, Linus Walleij, linux-kernel@vger.kernel.org,
open list:GPIO SUBSYSTEM, Mark Rutland,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <6ffb43dc-55a5-14eb-eb18-3a731cdaf424@t-chip.com.cn>
On Tue, May 22, 2018 at 9:02 PM, Levin Du <djw@t-chip.com.cn> wrote:
> On 2018-05-23 2:02 AM, Rob Herring wrote:
>>
>> On Fri, May 18, 2018 at 11:52:05AM +0800, djw@t-chip.com.cn wrote:
>>>
>>> From: Levin Du <djw@t-chip.com.cn>
>>>
>>> Some GPIOs sit in the GRF_SOC_CON registers of Rockchip SoCs,
>>> which do not belong to the general pinctrl.
>>>
>>> Adding gpio-syscon support makes controlling regulator or
>>> LED using these special pins very easy by reusing existing
>>> drivers, such as gpio-regulator and led-gpio.
>>>
>>> Signed-off-by: Levin Du <djw@t-chip.com.cn>
>>>
>>> ---
>>>
>>> Changes in v2:
>>> - Rename gpio_syscon10 to gpio_mute in doc
>>>
>>> Changes in v1:
>>> - Refactured for general gpio-syscon usage for Rockchip SoCs.
>>> - Add doc rockchip,gpio-syscon.txt
>>>
>>> .../bindings/gpio/rockchip,gpio-syscon.txt | 41
>>> ++++++++++++++++++++++
>>> drivers/gpio/gpio-syscon.c | 30
>>> ++++++++++++++++
>>> 2 files changed, 71 insertions(+)
>>> create mode 100644
>>> Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt
>>>
>>> diff --git
>>> a/Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt
>>> b/Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt
>>> new file mode 100644
>>> index 0000000..b1b2a67
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt
>>> @@ -0,0 +1,41 @@
>>> +* Rockchip GPIO support for GRF_SOC_CON registers
>>> +
>>> +Required properties:
>>> +- compatible: Should contain "rockchip,gpio-syscon".
>>> +- gpio-controller: Marks the device node as a gpio controller.
>>> +- #gpio-cells: Should be two. The first cell is the pin number and
>>> + the second cell is used to specify the gpio polarity:
>>> + 0 = Active high,
>>> + 1 = Active low.
>>
>> There's no need for this child node. Just make the parent node a gpio
>> controller.
>>
>> Rob
>
> Hi Rob, it is not clear to me. Do you suggest that the grf node should be a
> gpio controller,
> like below?
>
> + grf: syscon at ff100000 {
> + compatible = "rockchip,gpio-syscon", "rockchip,rk3328-grf",
> "syscon", "simple-mfd";
Yes, but drop "rockchip,gpio-syscon" and "simple-mfd".
> + //...
> + gpio-controller;
> + #gpio-cells = <2>;
> + gpio,syscon-dev = <&grf 0x0428 0>;
And drop this. It may be used in the kernel, but it is not a
documented property.
> + };
>
> or just reserve the following case in the doc?
>
> + grf: syscon at ff100000 {
> + compatible = "rockchip,rk3328-grf", "syscon", "simple-mfd";
> + //...
> + };
> +
> + gpio_mute: gpio-mute {
> + compatible = "rockchip,gpio-syscon";
> + gpio-controller;
> + #gpio-cells = <2>;
> + gpio,syscon-dev = <&grf 0x0428 0>;
> + };
>
>
> Thanks
> Levin
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2] PM / devfreq: Add support for QCOM devfreq firmware
From: Rob Herring @ 2018-05-23 14:39 UTC (permalink / raw)
To: Saravana Kannan
Cc: MyungJoo Ham, Kyungmin Park, Chanwoo Choi, Mark Rutland,
Rajendra Nayak, Amit Kucheria, linux-pm, devicetree,
linux-kernel@vger.kernel.org
In-Reply-To: <5B0461D1.1050900@codeaurora.org>
On Tue, May 22, 2018 at 1:30 PM, Saravana Kannan <skannan@codeaurora.org> wrote:
> On 05/22/2018 11:08 AM, Rob Herring wrote:
>>
>> On Fri, May 18, 2018 at 12:52:40AM -0700, Saravana Kannan wrote:
>>>
>>> The firmware present in some QCOM chipsets offloads the steps necessary
>>> for
>>> changing the frequency of some devices (Eg: L3). This driver implements
>>> the
>>> devfreq interface for this firmware so that various governors could be
>>> used
>>> to scale the frequency of these devices.
>>>
>>> Each client (say cluster 0 and cluster 1) that wants to vote for a
>>> particular device's frequency (say, L3 frequency) is represented as a
>>> separate voter device (qcom,devfreq-fw-voter) that's a child of the
>>> firmware device (qcom,devfreq-fw).
>>>
>>> Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
>>> ---
>>> .../bindings/devfreq/devfreq-qcom-fw.txt | 41 +++
>>> drivers/devfreq/Kconfig | 14 +
>>> drivers/devfreq/Makefile | 1 +
>>> drivers/devfreq/devfreq_qcom_fw.c | 330
>>> +++++++++++++++++++++
>>> 4 files changed, 386 insertions(+)
>>> create mode 100644
>>> Documentation/devicetree/bindings/devfreq/devfreq-qcom-fw.txt
>>> create mode 100644 drivers/devfreq/devfreq_qcom_fw.c
>>>
>>> diff --git
>>> a/Documentation/devicetree/bindings/devfreq/devfreq-qcom-fw.txt
>>> b/Documentation/devicetree/bindings/devfreq/devfreq-qcom-fw.txt
>>> new file mode 100644
>>> index 0000000..f882a0b
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/devfreq/devfreq-qcom-fw.txt
>>> @@ -0,0 +1,41 @@
>>> +QCOM Devfreq firmware device
>>> +
>>> +Some Qualcomm Technologies, Inc. (QTI) chipsets have a firmware that
>>> +offloads the steps for frequency switching. It provides a table of
>>> +supported frequencies and a register to request one of the supported
>>> +freqencies.
>>> +
>>> +The qcom,devfreq-fw represents this firmware as a device. Sometimes,
>>> +multiple entities want to vote on the frequency request that is sent to
>>> the
>>> +firmware. The qcom,devfreq-fw-voter represents these voters as child
>>> +devices of the corresponding qcom,devfreq-fw device.
>>> +
>>> +Required properties:
>>> +- compatible: Must be "qcom,devfreq-fw" or
>>> "qcom,devfreq-fw-voter"
>>
>>
>> No versions of firmware?
>
>
> Sure, I can add a v1. Right now the interface has always been identical. I
> thought if it changed in the future I'll add -v2.
Sounds like you are making up version numbers. If you don't have real
h/w or firmware version numbers, then use an SoC specific compatible
string.
>>> +Only for qcom,devfreq-fw:
>>> +- reg: Pairs of physical base addresses and region sizes
>>> of
>>> + memory mapped registers.
>>
>>
>> Registers? Is this firmware or h/w block?
>
>
> It's a HW block that has its own firmware.
So you have 2 things that could change: the h/w interface and the
firmware version. Make sure the compatible string(s) is specific
enough for the OS to know the exact combination.
>>> +- reg-names: Names of the bases for the above registers.
>>> + Required register regions are:
>>> + - "en-base": address of register to check if the
>>> + firmware is enabled.
>>> + - "ftbl-base": address region for the frequency
>>> + table.
>>> + - "perf-base": address of register to request a
>>> + frequency.
>>> +
>>> +Example:
>>> +
>>> + qcom,devfreq-l3 {
>>> + compatible = "qcom,devfreq-fw";
>>> + reg-names = "en-base", "ftbl-base", "perf-base";
>>> + reg = <0x18321000 0x4>, <0x18321110 0x600>, <0x18321920
>>> 0x4>;
>>> +
>>> + qcom,cpu0-l3 {
>>> + compatible = "qcom,devfreq-fw-voter";
>>
>>
>> There's no point in these nodes. They don't have any properties or
>> resources.
>
>
> These nodes decide how many voters this device supports. Each voter would be
> a devfreq node that will have its own governor set. For example, one of them
> would use this governor:
> http://lkml.iu.edu/hypermail/linux/kernel/1805.2/02474.html
>
> You can also attach different devfreq-event devices to each one of these
> voter devices based on what events you want to use for scaling each voter.
> So, the devices are definitely needed in the larger context.
Sorry, I still don't understand.
Rob
^ permalink raw reply
* Re: [PATCH RFC 00/24] Lima DRM driver
From: Qiang Yu @ 2018-05-23 14:27 UTC (permalink / raw)
To: Christian König
Cc: Simon Shields, devicetree, Connor Abbott, Marek Vasut,
Neil Armstrong, Andrei Paulau, dri-devel, Vasily Khoruzhick,
Erico Nunes
In-Reply-To: <c1b1b4e9-f4bd-7244-fd34-f4b4bc5d006e@amd.com>
On Wed, May 23, 2018 at 10:19 PM, Christian König
<christian.koenig@amd.com> wrote:
> Am 23.05.2018 um 16:13 schrieb Qiang Yu:
>>
>> On Wed, May 23, 2018 at 9:59 PM, Christian König
>> <christian.koenig@amd.com> wrote:
>>>
>>> Am 23.05.2018 um 15:52 schrieb Qiang Yu:
>>>>
>>>> On Wed, May 23, 2018 at 5:29 PM, Christian König
>>>> <ckoenig.leichtzumerken@gmail.com> wrote:
>>>>>
>>>>> Am 18.05.2018 um 11:27 schrieb Qiang Yu:
>>>>>>
>>>>>> Kernel DRM driver for ARM Mali 400/450 GPUs.
>>>>>>
>>>>>> This implementation mainly take amdgpu DRM driver as reference.
>>>>>>
>>>>>> - Mali 4xx GPUs have two kinds of processors GP and PP. GP is for
>>>>>> OpenGL vertex shader processing and PP is for fragment shader
>>>>>> processing. Each processor has its own MMU so prcessors work in
>>>>>> virtual address space.
>>>>>> - There's only one GP but multiple PP (max 4 for mali 400 and 8
>>>>>> for mali 450) in the same mali 4xx GPU. All PPs are grouped
>>>>>> togather to handle a single fragment shader task divided by
>>>>>> FB output tiled pixels. Mali 400 user space driver is
>>>>>> responsible for assign target tiled pixels to each PP, but mali
>>>>>> 450 has a HW module called DLBU to dynamically balance each
>>>>>> PP's load.
>>>>>> - User space driver allocate buffer object and map into GPU
>>>>>> virtual address space, upload command stream and draw data with
>>>>>> CPU mmap of the buffer object, then submit task to GP/PP with
>>>>>> a register frame indicating where is the command stream and misc
>>>>>> settings.
>>>>>> - There's no command stream validation/relocation due to each user
>>>>>> process has its own GPU virtual address space. GP/PP's MMU switch
>>>>>> virtual address space before running two tasks from different
>>>>>> user process. Error or evil user space code just get MMU fault
>>>>>> or GP/PP error IRQ, then the HW/SW will be recovered.
>>>>>> - Use TTM as MM. TTM_PL_TT type memory is used as the content of
>>>>>> lima buffer object which is allocated from TTM page pool. all
>>>>>> lima buffer object gets pinned with TTM_PL_FLAG_NO_EVICT when
>>>>>> allocation, so there's no buffer eviction and swap for now. We
>>>>>> need reverse engineering to see if and how GP/PP support MMU
>>>>>> fault recovery (continue execution). Otherwise we have to
>>>>>> pin/unpin each envolved buffer when task creation/deletion.
>>>>>
>>>>>
>>>>> Well pinning all memory is usually a no-go for upstreaming. But since
>>>>> you
>>>>> are already using the drm_sched for GPU task scheduling why are you
>>>>> actually
>>>>> needing this?
>>>>>
>>>>> The scheduler should take care of signaling all fences when the
>>>>> hardware
>>>>> is
>>>>> done with it's magic and that is enough for TTM to note that a buffer
>>>>> object
>>>>> is movable again (e.g. unpin them).
>>>>
>>>> Please correct me if I'm wrong.
>>>
>>>
>>> Well, you are wrong :)
>>>
>>>> One way to implement eviction/swap is like this:
>>>> call validation on each buffers involved in a task, but this won't
>>>> prevent it from
>>>> eviction/swap when executing, so a GPU MMU fault may happen and in the
>>>> handler we need to recover the buffer evicted/swapped.
>>>>
>>>> Another way is pin/unpin buffers evolved when task create/free.
>>>>
>>>> First way is better when memory load is low and second way is better
>>>> when
>>>> memory load is high. First way also need less memory.
>>>>
>>>> So I'd prefer first way but due to the GPU MMU fault
>>>> HW op need reverse engineering, I have to pin all buffers now. After
>>>> the HW op is clear, I can choose one way to implement.
>>>
>>>
>>> The general approach is:
>>> 1.) Lock all BOs
>>> 2.) Validate all BOs
>>> 3.) Add the fence
>>> 4.) Unlock the BOs
>>
>> This is the task prepare process, right?
>
>
> Yes.
>
>>> BOs can't be evicted while they are locked
>>
>> During the task prepare stage, they're locked, but after task queued, they
>> get unlocked and be evictable?
>
>
> Yes, the fence you added to the BO prevents TTM from evicting the BO until
> the fence signaled.
>
>>
>>> and since you already add the
>>> fence that should be perfectly sufficient to prevent it from being
>>> evicted
>>> until your operation is completed.
>>
>> You mean I have to explicitly pin it with TTM_PL_FLAG_NO_EVICT
>> when task creation or TTM will check buffer's reservation object and
>> won't evict it if see a fence?
>
>
> The second. You *don't* have to explicitly pin it with TTM_PL_FLAG_NO_EVICT
> as long as you always add the correct fence with your command submissions.
>
> When evicting something TTM will take a look at the fences assigned to the
> BO and either don't evict it at all or wait for all fences to be completed
> before doing so.
>
> When you need to update some internal state or flush caches or stuff like
> that when a BO is evicted TTM also has callbacks for this.
Oh, thanks for clearing this for me, it makes my life easier.
Regards,
Qiang
>
> Regards,
> Christian.
>
>
>>
>> Regards,
>> Qiang
>>
>>> Using the MMU is certainly be better in general, but usually only
>>> optional
>>> and a pain in the ass to get working. We have that in amdgpu for quite a
>>> while as well now and still don't use it because of that.
>>>
>>> Regards,
>>> Christian.
>>>
>>>
>>>> Regards,
>>>> Qiang
>>>>
>>>>> Christian.
>>>>>
>>>>>
>>>>>> - Use drm_sched for GPU task schedule. Each OpenGL context should
>>>>>> have a lima context object in the kernel to distinguish tasks
>>>>>> from different user. drm_sched gets task from each lima context
>>>>>> in a fair way.
>>>>>>
>>>>>> Not implemented:
>>>>>> - Dump buffer support
>>>>>> - Power management
>>>>>> - Performance counter
>>>>>>
>>>>>> This patch serial just pack a pair of .c/.h files in each patch.
>>>>>> For whole history of this driver's development, see:
>>>>>> https://github.com/yuq/linux-lima/commits/lima-4.17-rc4
>>>>>>
>>>>>> Mesa driver is still in development and not ready for daily usage,
>>>>>> but can run some simple tests like kmscube and glamrk2, see:
>>>>>> https://github.com/yuq/mesa-lima
>>>>>>
>>>>>> Andrei Paulau (1):
>>>>>> arm64/dts: add switch-delay for meson mali
>>>>>>
>>>>>> Lima Project Developers (10):
>>>>>> drm/lima: add mali 4xx GPU hardware regs
>>>>>> drm/lima: add lima core driver
>>>>>> drm/lima: add GPU device functions
>>>>>> drm/lima: add PMU related functions
>>>>>> drm/lima: add PP related functions
>>>>>> drm/lima: add MMU related functions
>>>>>> drm/lima: add GPU virtual memory space handing
>>>>>> drm/lima: add GEM related functions
>>>>>> drm/lima: add GEM Prime related functions
>>>>>> drm/lima: add makefile and kconfig
>>>>>>
>>>>>> Qiang Yu (12):
>>>>>> dt-bindings: add switch-delay property for mali-utgard
>>>>>> arm64/dts: add switch-delay for meson mali
>>>>>> Revert "drm: Nerf the preclose callback for modern drivers"
>>>>>> drm/lima: add lima uapi header
>>>>>> drm/lima: add L2 cache functions
>>>>>> drm/lima: add GP related functions
>>>>>> drm/lima: add BCAST related function
>>>>>> drm/lima: add DLBU related functions
>>>>>> drm/lima: add TTM subsystem functions
>>>>>> drm/lima: add buffer object functions
>>>>>> drm/lima: add GPU schedule using DRM_SCHED
>>>>>> drm/lima: add context related functions
>>>>>>
>>>>>> Simon Shields (1):
>>>>>> ARM: dts: add gpu node to exynos4
>>>>>>
>>>>>> .../bindings/gpu/arm,mali-utgard.txt | 4 +
>>>>>> arch/arm/boot/dts/exynos4.dtsi | 33 ++
>>>>>> arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 1 +
>>>>>> .../boot/dts/amlogic/meson-gxl-mali.dtsi | 1 +
>>>>>> drivers/gpu/drm/Kconfig | 2 +
>>>>>> drivers/gpu/drm/Makefile | 1 +
>>>>>> drivers/gpu/drm/drm_file.c | 8 +-
>>>>>> drivers/gpu/drm/lima/Kconfig | 9 +
>>>>>> drivers/gpu/drm/lima/Makefile | 19 +
>>>>>> drivers/gpu/drm/lima/lima_bcast.c | 65 +++
>>>>>> drivers/gpu/drm/lima/lima_bcast.h | 34 ++
>>>>>> drivers/gpu/drm/lima/lima_ctx.c | 143 +++++
>>>>>> drivers/gpu/drm/lima/lima_ctx.h | 51 ++
>>>>>> drivers/gpu/drm/lima/lima_device.c | 407 ++++++++++++++
>>>>>> drivers/gpu/drm/lima/lima_device.h | 136 +++++
>>>>>> drivers/gpu/drm/lima/lima_dlbu.c | 75 +++
>>>>>> drivers/gpu/drm/lima/lima_dlbu.h | 37 ++
>>>>>> drivers/gpu/drm/lima/lima_drv.c | 466
>>>>>> ++++++++++++++++
>>>>>> drivers/gpu/drm/lima/lima_drv.h | 77 +++
>>>>>> drivers/gpu/drm/lima/lima_gem.c | 459
>>>>>> ++++++++++++++++
>>>>>> drivers/gpu/drm/lima/lima_gem.h | 41 ++
>>>>>> drivers/gpu/drm/lima/lima_gem_prime.c | 66 +++
>>>>>> drivers/gpu/drm/lima/lima_gem_prime.h | 31 ++
>>>>>> drivers/gpu/drm/lima/lima_gp.c | 293 +++++++++++
>>>>>> drivers/gpu/drm/lima/lima_gp.h | 34 ++
>>>>>> drivers/gpu/drm/lima/lima_l2_cache.c | 98 ++++
>>>>>> drivers/gpu/drm/lima/lima_l2_cache.h | 32 ++
>>>>>> drivers/gpu/drm/lima/lima_mmu.c | 154 ++++++
>>>>>> drivers/gpu/drm/lima/lima_mmu.h | 34 ++
>>>>>> drivers/gpu/drm/lima/lima_object.c | 120 +++++
>>>>>> drivers/gpu/drm/lima/lima_object.h | 87 +++
>>>>>> drivers/gpu/drm/lima/lima_pmu.c | 85 +++
>>>>>> drivers/gpu/drm/lima/lima_pmu.h | 30 ++
>>>>>> drivers/gpu/drm/lima/lima_pp.c | 418
>>>>>> +++++++++++++++
>>>>>> drivers/gpu/drm/lima/lima_pp.h | 37 ++
>>>>>> drivers/gpu/drm/lima/lima_regs.h | 304 +++++++++++
>>>>>> drivers/gpu/drm/lima/lima_sched.c | 497
>>>>>> ++++++++++++++++++
>>>>>> drivers/gpu/drm/lima/lima_sched.h | 126 +++++
>>>>>> drivers/gpu/drm/lima/lima_ttm.c | 409 ++++++++++++++
>>>>>> drivers/gpu/drm/lima/lima_ttm.h | 44 ++
>>>>>> drivers/gpu/drm/lima/lima_vm.c | 312 +++++++++++
>>>>>> drivers/gpu/drm/lima/lima_vm.h | 73 +++
>>>>>> include/drm/drm_drv.h | 23 +-
>>>>>> include/uapi/drm/lima_drm.h | 195 +++++++
>>>>>> 44 files changed, 5565 insertions(+), 6 deletions(-)
>>>>>> create mode 100644 drivers/gpu/drm/lima/Kconfig
>>>>>> create mode 100644 drivers/gpu/drm/lima/Makefile
>>>>>> create mode 100644 drivers/gpu/drm/lima/lima_bcast.c
>>>>>> create mode 100644 drivers/gpu/drm/lima/lima_bcast.h
>>>>>> create mode 100644 drivers/gpu/drm/lima/lima_ctx.c
>>>>>> create mode 100644 drivers/gpu/drm/lima/lima_ctx.h
>>>>>> create mode 100644 drivers/gpu/drm/lima/lima_device.c
>>>>>> create mode 100644 drivers/gpu/drm/lima/lima_device.h
>>>>>> create mode 100644 drivers/gpu/drm/lima/lima_dlbu.c
>>>>>> create mode 100644 drivers/gpu/drm/lima/lima_dlbu.h
>>>>>> create mode 100644 drivers/gpu/drm/lima/lima_drv.c
>>>>>> create mode 100644 drivers/gpu/drm/lima/lima_drv.h
>>>>>> create mode 100644 drivers/gpu/drm/lima/lima_gem.c
>>>>>> create mode 100644 drivers/gpu/drm/lima/lima_gem.h
>>>>>> create mode 100644 drivers/gpu/drm/lima/lima_gem_prime.c
>>>>>> create mode 100644 drivers/gpu/drm/lima/lima_gem_prime.h
>>>>>> create mode 100644 drivers/gpu/drm/lima/lima_gp.c
>>>>>> create mode 100644 drivers/gpu/drm/lima/lima_gp.h
>>>>>> create mode 100644 drivers/gpu/drm/lima/lima_l2_cache.c
>>>>>> create mode 100644 drivers/gpu/drm/lima/lima_l2_cache.h
>>>>>> create mode 100644 drivers/gpu/drm/lima/lima_mmu.c
>>>>>> create mode 100644 drivers/gpu/drm/lima/lima_mmu.h
>>>>>> create mode 100644 drivers/gpu/drm/lima/lima_object.c
>>>>>> create mode 100644 drivers/gpu/drm/lima/lima_object.h
>>>>>> create mode 100644 drivers/gpu/drm/lima/lima_pmu.c
>>>>>> create mode 100644 drivers/gpu/drm/lima/lima_pmu.h
>>>>>> create mode 100644 drivers/gpu/drm/lima/lima_pp.c
>>>>>> create mode 100644 drivers/gpu/drm/lima/lima_pp.h
>>>>>> create mode 100644 drivers/gpu/drm/lima/lima_regs.h
>>>>>> create mode 100644 drivers/gpu/drm/lima/lima_sched.c
>>>>>> create mode 100644 drivers/gpu/drm/lima/lima_sched.h
>>>>>> create mode 100644 drivers/gpu/drm/lima/lima_ttm.c
>>>>>> create mode 100644 drivers/gpu/drm/lima/lima_ttm.h
>>>>>> create mode 100644 drivers/gpu/drm/lima/lima_vm.c
>>>>>> create mode 100644 drivers/gpu/drm/lima/lima_vm.h
>>>>>> create mode 100644 include/uapi/drm/lima_drm.h
>>>>>>
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v2 11/16] irqchip/irq-mvebu-icu: add support for System Error Interrupts (SEI)
From: Marc Zyngier @ 2018-05-23 14:23 UTC (permalink / raw)
To: Miquel Raynal, Thomas Gleixner, Jason Cooper, Catalin Marinas,
Will Deacon, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth
Cc: Rob Herring, Mark Rutland, devicetree, linux-arm-kernel,
Thomas Petazzoni, Antoine Tenart, Maxime Chevallier, Nadav Haklai,
Haim Boot, Hanna Hawa, linux-kernel
In-Reply-To: <20180522094042.24770-12-miquel.raynal@bootlin.com>
On 22/05/18 10:40, Miquel Raynal wrote:
> An SEI driver provides an MSI domain through which it is possible to
> raise SEIs.
>
> Handle the NSR probe function in a more generic way to support other
> type of interrupts (ie. the SEIs).
>
> For clarity we do not use tree IRQ domains for now but linear ones
> instead, allocating the 207 ICU lines for each interrupt group.
What's the rational for not using trees? Because that's effectively a
100% overhead...
> Reallocating an ICU slot is prevented by the use of an ICU-wide bitmap.
>
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> ---
> drivers/irqchip/irq-mvebu-icu.c | 126 ++++++++++++++++++++++++++++++++++------
> 1 file changed, 108 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/irqchip/irq-mvebu-icu.c b/drivers/irqchip/irq-mvebu-icu.c
> index 977e47b2716f..6ad6236d6ff1 100644
> --- a/drivers/irqchip/irq-mvebu-icu.c
> +++ b/drivers/irqchip/irq-mvebu-icu.c
> @@ -28,6 +28,10 @@
> #define ICU_SETSPI_NSR_AH 0x14
> #define ICU_CLRSPI_NSR_AL 0x18
> #define ICU_CLRSPI_NSR_AH 0x1c
> +#define ICU_SET_SEI_AL 0x50
> +#define ICU_SET_SEI_AH 0x54
> +#define ICU_CLR_SEI_AL 0x58
> +#define ICU_CLR_SEI_AH 0x5C
> #define ICU_INT_CFG(x) (0x100 + 4 * (x))
> #define ICU_INT_ENABLE BIT(24)
> #define ICU_IS_EDGE BIT(28)
> @@ -38,12 +42,28 @@
> #define ICU_SATA0_ICU_ID 109
> #define ICU_SATA1_ICU_ID 107
>
> +struct mvebu_icu_subset_data {
> + unsigned int icu_group;
> + unsigned int offset_set_ah;
> + unsigned int offset_set_al;
> + unsigned int offset_clr_ah;
> + unsigned int offset_clr_al;
> +};
> +
> struct mvebu_icu {
> struct irq_chip irq_chip;
> struct regmap *regmap;
> struct device *dev;
> - atomic_t initialized;
> bool legacy_bindings;
> + /* Lock on interrupt allocations/releases */
> + spinlock_t msi_lock;
> + DECLARE_BITMAP(msi_bitmap, ICU_MAX_IRQS);
> +};
> +
> +struct mvebu_icu_msi_data {
> + struct mvebu_icu *icu;
> + atomic_t initialized;
> + const struct mvebu_icu_subset_data *subset_data;
> };
>
> struct mvebu_icu_irq_data {
> @@ -76,16 +96,25 @@ static struct mvebu_icu *mvebu_icu_dev_get_drvdata(struct platform_device *pdev)
> return icu;
> }
>
> -static void mvebu_icu_init(struct mvebu_icu *icu, struct msi_msg *msg)
> +static void mvebu_icu_init(struct mvebu_icu *icu, struct irq_domain *d,
> + struct msi_msg *msg)
> {
> - if (atomic_cmpxchg(&icu->initialized, false, true))
> + struct mvebu_icu_msi_data *msi_data = platform_msi_get_host_data(d);
> + const struct mvebu_icu_subset_data *subset = msi_data->subset_data;
> +
> + if (atomic_cmpxchg(&msi_data->initialized, false, true))
> + return;
> +
> + /* Set 'SET' ICU SPI message address in AP */
> + regmap_write(icu->regmap, subset->offset_set_ah, msg[0].address_hi);
> + regmap_write(icu->regmap, subset->offset_set_al, msg[0].address_lo);
> +
> + if (subset->icu_group != ICU_GRP_NSR)
> return;
>
> - /* Set Clear/Set ICU SPI message address in AP */
> - regmap_write(icu->regmap, ICU_SETSPI_NSR_AH, msg[0].address_hi);
> - regmap_write(icu->regmap, ICU_SETSPI_NSR_AL, msg[0].address_lo);
> - regmap_write(icu->regmap, ICU_CLRSPI_NSR_AH, msg[1].address_hi);
> - regmap_write(icu->regmap, ICU_CLRSPI_NSR_AL, msg[1].address_lo);
> + /* Set 'CLEAR' ICU SPI message address in AP (level-MSI only) */
> + regmap_write(icu->regmap, subset->offset_clr_ah, msg[1].address_hi);
> + regmap_write(icu->regmap, subset->offset_clr_al, msg[1].address_lo);
> }
>
> static void mvebu_icu_write_msg(struct msi_desc *desc, struct msi_msg *msg)
> @@ -96,8 +125,8 @@ static void mvebu_icu_write_msg(struct msi_desc *desc, struct msi_msg *msg)
> unsigned int icu_int;
>
> if (msg->address_lo || msg->address_hi) {
> - /* One off initialization */
> - mvebu_icu_init(icu, msg);
> + /* One off initialization per domain */
> + mvebu_icu_init(icu, d->domain, msg);
> /* Configure the ICU with irq number & type */
> icu_int = msg->data | ICU_INT_ENABLE;
> if (icu_irqd->type & IRQ_TYPE_EDGE_RISING)
> @@ -131,7 +160,8 @@ static int
> mvebu_icu_irq_domain_translate(struct irq_domain *d, struct irq_fwspec *fwspec,
> unsigned long *hwirq, unsigned int *type)
> {
> - struct mvebu_icu *icu = platform_msi_get_host_data(d);
> + struct mvebu_icu_msi_data *msi_data = platform_msi_get_host_data(d);
> + struct mvebu_icu *icu = msi_data->icu;
> unsigned int param_count = icu->legacy_bindings ? 3 : 2;
>
> /* Check the count of the parameters in dt */
> @@ -172,7 +202,9 @@ mvebu_icu_irq_domain_alloc(struct irq_domain *domain, unsigned int virq,
> int err;
> unsigned long hwirq;
> struct irq_fwspec *fwspec = args;
> - struct mvebu_icu *icu = platform_msi_get_host_data(domain);
> + struct mvebu_icu_msi_data *msi_data =
> + platform_msi_get_host_data(domain);
> + struct mvebu_icu *icu = msi_data->icu;
> struct mvebu_icu_irq_data *icu_irqd;
>
> icu_irqd = kmalloc(sizeof(*icu_irqd), GFP_KERNEL);
> @@ -186,16 +218,22 @@ mvebu_icu_irq_domain_alloc(struct irq_domain *domain, unsigned int virq,
> goto free_irqd;
> }
>
> + spin_lock(&icu->msi_lock);
> + err = bitmap_allocate_region(icu->msi_bitmap, hwirq, 0);
> + spin_unlock(&icu->msi_lock);
This (and the freeing counterpart) could deserve a couple of helpers.
> + if (err < 0)
> + goto free_irqd;
> +
> if (icu->legacy_bindings)
> icu_irqd->icu_group = fwspec->param[0];
> else
> - icu_irqd->icu_group = ICU_GRP_NSR;
> + icu_irqd->icu_group = msi_data->subset_data->icu_group;
> icu_irqd->icu = icu;
>
> err = platform_msi_domain_alloc(domain, virq, nr_irqs);
> if (err) {
> dev_err(icu->dev, "failed to allocate ICU interrupt in parent domain\n");
> - goto free_irqd;
> + goto free_bitmap;
> }
>
> /* Make sure there is no interrupt left pending by the firmware */
> @@ -214,6 +252,10 @@ mvebu_icu_irq_domain_alloc(struct irq_domain *domain, unsigned int virq,
>
> free_msi:
> platform_msi_domain_free(domain, virq, nr_irqs);
> +free_bitmap:
> + spin_lock(&icu->msi_lock);
> + bitmap_release_region(icu->msi_bitmap, hwirq, 0);
> + spin_unlock(&icu->msi_lock);
> free_irqd:
> kfree(icu_irqd);
> return err;
> @@ -223,12 +265,19 @@ static void
> mvebu_icu_irq_domain_free(struct irq_domain *domain, unsigned int virq,
> unsigned int nr_irqs)
> {
> + struct mvebu_icu_msi_data *msi_data =
> + platform_msi_get_host_data(domain);
> + struct mvebu_icu *icu = msi_data->icu;
> struct irq_data *d = irq_get_irq_data(virq);
> struct mvebu_icu_irq_data *icu_irqd = d->chip_data;
>
> kfree(icu_irqd);
>
> platform_msi_domain_free(domain, virq, nr_irqs);
> +
> + spin_lock(&icu->msi_lock);
> + bitmap_release_region(icu->msi_bitmap, d->hwirq, 0);
> + spin_unlock(&icu->msi_lock);
> }
>
> static const struct irq_domain_ops mvebu_icu_domain_ops = {
> @@ -239,14 +288,29 @@ static const struct irq_domain_ops mvebu_icu_domain_ops = {
>
> static int mvebu_icu_subset_probe(struct platform_device *pdev)
> {
> + const struct mvebu_icu_subset_data *subset;
> + struct mvebu_icu_msi_data *msi_data;
> struct device_node *msi_parent_dn;
> struct irq_domain *irq_domain;
> struct mvebu_icu *icu;
>
> + msi_data = devm_kzalloc(&pdev->dev, sizeof(*msi_data), GFP_KERNEL);
> + if (!msi_data)
> + return -ENOMEM;
> +
> icu = mvebu_icu_dev_get_drvdata(pdev);
> if (IS_ERR(icu))
> return PTR_ERR(icu);
>
> + subset = of_device_get_match_data(&pdev->dev);
> + if (!subset) {
> + dev_err(&pdev->dev, "Could not retrieve subset data\n");
> + return -EINVAL;
> + }
> +
> + msi_data->icu = icu;
> + msi_data->subset_data = subset;
> +
> pdev->dev.msi_domain = of_msi_get_domain(&pdev->dev, pdev->dev.of_node,
> DOMAIN_BUS_PLATFORM_MSI);
> if (!pdev->dev.msi_domain)
> @@ -259,7 +323,7 @@ static int mvebu_icu_subset_probe(struct platform_device *pdev)
> irq_domain = platform_msi_create_device_domain(&pdev->dev, ICU_MAX_IRQS,
> mvebu_icu_write_msg,
> &mvebu_icu_domain_ops,
> - icu);
> + msi_data);
> if (!irq_domain) {
> dev_err(&pdev->dev, "Failed to create ICU MSI domain\n");
> return -ENOMEM;
> @@ -268,9 +332,30 @@ static int mvebu_icu_subset_probe(struct platform_device *pdev)
> return 0;
> }
>
> +static const struct mvebu_icu_subset_data mvebu_icu_nsr_subset_data = {
> + .icu_group = ICU_GRP_NSR,
> + .offset_set_ah = ICU_SETSPI_NSR_AH,
> + .offset_set_al = ICU_SETSPI_NSR_AL,
> + .offset_clr_ah = ICU_CLRSPI_NSR_AH,
> + .offset_clr_al = ICU_CLRSPI_NSR_AL,
> +};
> +
> +static const struct mvebu_icu_subset_data mvebu_icu_sei_subset_data = {
> + .icu_group = ICU_GRP_SEI,
> + .offset_set_ah = ICU_SET_SEI_AH,
> + .offset_set_al = ICU_SET_SEI_AL,
> + .offset_clr_ah = ICU_CLR_SEI_AH,
> + .offset_clr_al = ICU_CLR_SEI_AL,
I thought SEI was edge only, given what you do in mvebu_icu_init.
Confused...
> +};
> +
> static const struct of_device_id mvebu_icu_subset_of_match[] = {
> {
> .compatible = "marvell,cp110-icu-nsr",
> + .data = &mvebu_icu_nsr_subset_data,
> + },
> + {
> + .compatible = "marvell,cp110-icu-sei",
> + .data = &mvebu_icu_sei_subset_data,
> },
> {},
> };
> @@ -317,6 +402,8 @@ static int mvebu_icu_probe(struct platform_device *pdev)
> if (IS_ERR(icu->regmap))
> return PTR_ERR(icu->regmap);
>
> + spin_lock_init(&icu->msi_lock);
> +
> icu->irq_chip.name = devm_kasprintf(&pdev->dev, GFP_KERNEL,
> "ICU.%x",
> (unsigned int)res->start);
> @@ -341,7 +428,7 @@ static int mvebu_icu_probe(struct platform_device *pdev)
> #endif
>
> /*
> - * Clean all ICU interrupts with type SPI_NSR, required to
> + * Clean all ICU interrupts of type NSR and SEI, required to
> * avoid unpredictable SPI assignments done by firmware.
> */
> for (i = 0 ; i < ICU_MAX_IRQS ; i++) {
> @@ -350,7 +437,8 @@ static int mvebu_icu_probe(struct platform_device *pdev)
> regmap_read(icu->regmap, ICU_INT_CFG(i), &icu_int);
> icu_grp = icu_int >> ICU_GROUP_SHIFT;
>
> - if (icu_grp == ICU_GRP_NSR)
> + if (icu_grp == ICU_GRP_NSR ||
> + (icu_grp == ICU_GRP_SEI && !icu->legacy_bindings))
> regmap_write(icu->regmap, ICU_INT_CFG(i), 0);
> }
>
> @@ -363,7 +451,9 @@ static int mvebu_icu_probe(struct platform_device *pdev)
> }
>
> static const struct of_device_id mvebu_icu_of_match[] = {
> - { .compatible = "marvell,cp110-icu", },
> + {
> + .compatible = "marvell,cp110-icu",
> + },
> {},
> };
>
>
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* Re: [PATCH RFC 00/24] Lima DRM driver
From: Christian König @ 2018-05-23 14:19 UTC (permalink / raw)
To: Qiang Yu
Cc: Simon Shields, devicetree, Connor Abbott, Marek Vasut,
Neil Armstrong, Andrei Paulau, dri-devel, Vasily Khoruzhick,
Erico Nunes
In-Reply-To: <CAKGbVbuSd2FkLCShYkk+nW8xeU=4rBM1NDxROi=HRhFWc929Zw@mail.gmail.com>
Am 23.05.2018 um 16:13 schrieb Qiang Yu:
> On Wed, May 23, 2018 at 9:59 PM, Christian König
> <christian.koenig@amd.com> wrote:
>> Am 23.05.2018 um 15:52 schrieb Qiang Yu:
>>> On Wed, May 23, 2018 at 5:29 PM, Christian König
>>> <ckoenig.leichtzumerken@gmail.com> wrote:
>>>> Am 18.05.2018 um 11:27 schrieb Qiang Yu:
>>>>> Kernel DRM driver for ARM Mali 400/450 GPUs.
>>>>>
>>>>> This implementation mainly take amdgpu DRM driver as reference.
>>>>>
>>>>> - Mali 4xx GPUs have two kinds of processors GP and PP. GP is for
>>>>> OpenGL vertex shader processing and PP is for fragment shader
>>>>> processing. Each processor has its own MMU so prcessors work in
>>>>> virtual address space.
>>>>> - There's only one GP but multiple PP (max 4 for mali 400 and 8
>>>>> for mali 450) in the same mali 4xx GPU. All PPs are grouped
>>>>> togather to handle a single fragment shader task divided by
>>>>> FB output tiled pixels. Mali 400 user space driver is
>>>>> responsible for assign target tiled pixels to each PP, but mali
>>>>> 450 has a HW module called DLBU to dynamically balance each
>>>>> PP's load.
>>>>> - User space driver allocate buffer object and map into GPU
>>>>> virtual address space, upload command stream and draw data with
>>>>> CPU mmap of the buffer object, then submit task to GP/PP with
>>>>> a register frame indicating where is the command stream and misc
>>>>> settings.
>>>>> - There's no command stream validation/relocation due to each user
>>>>> process has its own GPU virtual address space. GP/PP's MMU switch
>>>>> virtual address space before running two tasks from different
>>>>> user process. Error or evil user space code just get MMU fault
>>>>> or GP/PP error IRQ, then the HW/SW will be recovered.
>>>>> - Use TTM as MM. TTM_PL_TT type memory is used as the content of
>>>>> lima buffer object which is allocated from TTM page pool. all
>>>>> lima buffer object gets pinned with TTM_PL_FLAG_NO_EVICT when
>>>>> allocation, so there's no buffer eviction and swap for now. We
>>>>> need reverse engineering to see if and how GP/PP support MMU
>>>>> fault recovery (continue execution). Otherwise we have to
>>>>> pin/unpin each envolved buffer when task creation/deletion.
>>>>
>>>> Well pinning all memory is usually a no-go for upstreaming. But since you
>>>> are already using the drm_sched for GPU task scheduling why are you
>>>> actually
>>>> needing this?
>>>>
>>>> The scheduler should take care of signaling all fences when the hardware
>>>> is
>>>> done with it's magic and that is enough for TTM to note that a buffer
>>>> object
>>>> is movable again (e.g. unpin them).
>>> Please correct me if I'm wrong.
>>
>> Well, you are wrong :)
>>
>>> One way to implement eviction/swap is like this:
>>> call validation on each buffers involved in a task, but this won't
>>> prevent it from
>>> eviction/swap when executing, so a GPU MMU fault may happen and in the
>>> handler we need to recover the buffer evicted/swapped.
>>>
>>> Another way is pin/unpin buffers evolved when task create/free.
>>>
>>> First way is better when memory load is low and second way is better when
>>> memory load is high. First way also need less memory.
>>>
>>> So I'd prefer first way but due to the GPU MMU fault
>>> HW op need reverse engineering, I have to pin all buffers now. After
>>> the HW op is clear, I can choose one way to implement.
>>
>> The general approach is:
>> 1.) Lock all BOs
>> 2.) Validate all BOs
>> 3.) Add the fence
>> 4.) Unlock the BOs
> This is the task prepare process, right?
Yes.
>> BOs can't be evicted while they are locked
> During the task prepare stage, they're locked, but after task queued, they
> get unlocked and be evictable?
Yes, the fence you added to the BO prevents TTM from evicting the BO
until the fence signaled.
>
>> and since you already add the
>> fence that should be perfectly sufficient to prevent it from being evicted
>> until your operation is completed.
> You mean I have to explicitly pin it with TTM_PL_FLAG_NO_EVICT
> when task creation or TTM will check buffer's reservation object and
> won't evict it if see a fence?
The second. You *don't* have to explicitly pin it with
TTM_PL_FLAG_NO_EVICT as long as you always add the correct fence with
your command submissions.
When evicting something TTM will take a look at the fences assigned to
the BO and either don't evict it at all or wait for all fences to be
completed before doing so.
When you need to update some internal state or flush caches or stuff
like that when a BO is evicted TTM also has callbacks for this.
Regards,
Christian.
>
> Regards,
> Qiang
>
>> Using the MMU is certainly be better in general, but usually only optional
>> and a pain in the ass to get working. We have that in amdgpu for quite a
>> while as well now and still don't use it because of that.
>>
>> Regards,
>> Christian.
>>
>>
>>> Regards,
>>> Qiang
>>>
>>>> Christian.
>>>>
>>>>
>>>>> - Use drm_sched for GPU task schedule. Each OpenGL context should
>>>>> have a lima context object in the kernel to distinguish tasks
>>>>> from different user. drm_sched gets task from each lima context
>>>>> in a fair way.
>>>>>
>>>>> Not implemented:
>>>>> - Dump buffer support
>>>>> - Power management
>>>>> - Performance counter
>>>>>
>>>>> This patch serial just pack a pair of .c/.h files in each patch.
>>>>> For whole history of this driver's development, see:
>>>>> https://github.com/yuq/linux-lima/commits/lima-4.17-rc4
>>>>>
>>>>> Mesa driver is still in development and not ready for daily usage,
>>>>> but can run some simple tests like kmscube and glamrk2, see:
>>>>> https://github.com/yuq/mesa-lima
>>>>>
>>>>> Andrei Paulau (1):
>>>>> arm64/dts: add switch-delay for meson mali
>>>>>
>>>>> Lima Project Developers (10):
>>>>> drm/lima: add mali 4xx GPU hardware regs
>>>>> drm/lima: add lima core driver
>>>>> drm/lima: add GPU device functions
>>>>> drm/lima: add PMU related functions
>>>>> drm/lima: add PP related functions
>>>>> drm/lima: add MMU related functions
>>>>> drm/lima: add GPU virtual memory space handing
>>>>> drm/lima: add GEM related functions
>>>>> drm/lima: add GEM Prime related functions
>>>>> drm/lima: add makefile and kconfig
>>>>>
>>>>> Qiang Yu (12):
>>>>> dt-bindings: add switch-delay property for mali-utgard
>>>>> arm64/dts: add switch-delay for meson mali
>>>>> Revert "drm: Nerf the preclose callback for modern drivers"
>>>>> drm/lima: add lima uapi header
>>>>> drm/lima: add L2 cache functions
>>>>> drm/lima: add GP related functions
>>>>> drm/lima: add BCAST related function
>>>>> drm/lima: add DLBU related functions
>>>>> drm/lima: add TTM subsystem functions
>>>>> drm/lima: add buffer object functions
>>>>> drm/lima: add GPU schedule using DRM_SCHED
>>>>> drm/lima: add context related functions
>>>>>
>>>>> Simon Shields (1):
>>>>> ARM: dts: add gpu node to exynos4
>>>>>
>>>>> .../bindings/gpu/arm,mali-utgard.txt | 4 +
>>>>> arch/arm/boot/dts/exynos4.dtsi | 33 ++
>>>>> arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 1 +
>>>>> .../boot/dts/amlogic/meson-gxl-mali.dtsi | 1 +
>>>>> drivers/gpu/drm/Kconfig | 2 +
>>>>> drivers/gpu/drm/Makefile | 1 +
>>>>> drivers/gpu/drm/drm_file.c | 8 +-
>>>>> drivers/gpu/drm/lima/Kconfig | 9 +
>>>>> drivers/gpu/drm/lima/Makefile | 19 +
>>>>> drivers/gpu/drm/lima/lima_bcast.c | 65 +++
>>>>> drivers/gpu/drm/lima/lima_bcast.h | 34 ++
>>>>> drivers/gpu/drm/lima/lima_ctx.c | 143 +++++
>>>>> drivers/gpu/drm/lima/lima_ctx.h | 51 ++
>>>>> drivers/gpu/drm/lima/lima_device.c | 407 ++++++++++++++
>>>>> drivers/gpu/drm/lima/lima_device.h | 136 +++++
>>>>> drivers/gpu/drm/lima/lima_dlbu.c | 75 +++
>>>>> drivers/gpu/drm/lima/lima_dlbu.h | 37 ++
>>>>> drivers/gpu/drm/lima/lima_drv.c | 466 ++++++++++++++++
>>>>> drivers/gpu/drm/lima/lima_drv.h | 77 +++
>>>>> drivers/gpu/drm/lima/lima_gem.c | 459 ++++++++++++++++
>>>>> drivers/gpu/drm/lima/lima_gem.h | 41 ++
>>>>> drivers/gpu/drm/lima/lima_gem_prime.c | 66 +++
>>>>> drivers/gpu/drm/lima/lima_gem_prime.h | 31 ++
>>>>> drivers/gpu/drm/lima/lima_gp.c | 293 +++++++++++
>>>>> drivers/gpu/drm/lima/lima_gp.h | 34 ++
>>>>> drivers/gpu/drm/lima/lima_l2_cache.c | 98 ++++
>>>>> drivers/gpu/drm/lima/lima_l2_cache.h | 32 ++
>>>>> drivers/gpu/drm/lima/lima_mmu.c | 154 ++++++
>>>>> drivers/gpu/drm/lima/lima_mmu.h | 34 ++
>>>>> drivers/gpu/drm/lima/lima_object.c | 120 +++++
>>>>> drivers/gpu/drm/lima/lima_object.h | 87 +++
>>>>> drivers/gpu/drm/lima/lima_pmu.c | 85 +++
>>>>> drivers/gpu/drm/lima/lima_pmu.h | 30 ++
>>>>> drivers/gpu/drm/lima/lima_pp.c | 418 +++++++++++++++
>>>>> drivers/gpu/drm/lima/lima_pp.h | 37 ++
>>>>> drivers/gpu/drm/lima/lima_regs.h | 304 +++++++++++
>>>>> drivers/gpu/drm/lima/lima_sched.c | 497
>>>>> ++++++++++++++++++
>>>>> drivers/gpu/drm/lima/lima_sched.h | 126 +++++
>>>>> drivers/gpu/drm/lima/lima_ttm.c | 409 ++++++++++++++
>>>>> drivers/gpu/drm/lima/lima_ttm.h | 44 ++
>>>>> drivers/gpu/drm/lima/lima_vm.c | 312 +++++++++++
>>>>> drivers/gpu/drm/lima/lima_vm.h | 73 +++
>>>>> include/drm/drm_drv.h | 23 +-
>>>>> include/uapi/drm/lima_drm.h | 195 +++++++
>>>>> 44 files changed, 5565 insertions(+), 6 deletions(-)
>>>>> create mode 100644 drivers/gpu/drm/lima/Kconfig
>>>>> create mode 100644 drivers/gpu/drm/lima/Makefile
>>>>> create mode 100644 drivers/gpu/drm/lima/lima_bcast.c
>>>>> create mode 100644 drivers/gpu/drm/lima/lima_bcast.h
>>>>> create mode 100644 drivers/gpu/drm/lima/lima_ctx.c
>>>>> create mode 100644 drivers/gpu/drm/lima/lima_ctx.h
>>>>> create mode 100644 drivers/gpu/drm/lima/lima_device.c
>>>>> create mode 100644 drivers/gpu/drm/lima/lima_device.h
>>>>> create mode 100644 drivers/gpu/drm/lima/lima_dlbu.c
>>>>> create mode 100644 drivers/gpu/drm/lima/lima_dlbu.h
>>>>> create mode 100644 drivers/gpu/drm/lima/lima_drv.c
>>>>> create mode 100644 drivers/gpu/drm/lima/lima_drv.h
>>>>> create mode 100644 drivers/gpu/drm/lima/lima_gem.c
>>>>> create mode 100644 drivers/gpu/drm/lima/lima_gem.h
>>>>> create mode 100644 drivers/gpu/drm/lima/lima_gem_prime.c
>>>>> create mode 100644 drivers/gpu/drm/lima/lima_gem_prime.h
>>>>> create mode 100644 drivers/gpu/drm/lima/lima_gp.c
>>>>> create mode 100644 drivers/gpu/drm/lima/lima_gp.h
>>>>> create mode 100644 drivers/gpu/drm/lima/lima_l2_cache.c
>>>>> create mode 100644 drivers/gpu/drm/lima/lima_l2_cache.h
>>>>> create mode 100644 drivers/gpu/drm/lima/lima_mmu.c
>>>>> create mode 100644 drivers/gpu/drm/lima/lima_mmu.h
>>>>> create mode 100644 drivers/gpu/drm/lima/lima_object.c
>>>>> create mode 100644 drivers/gpu/drm/lima/lima_object.h
>>>>> create mode 100644 drivers/gpu/drm/lima/lima_pmu.c
>>>>> create mode 100644 drivers/gpu/drm/lima/lima_pmu.h
>>>>> create mode 100644 drivers/gpu/drm/lima/lima_pp.c
>>>>> create mode 100644 drivers/gpu/drm/lima/lima_pp.h
>>>>> create mode 100644 drivers/gpu/drm/lima/lima_regs.h
>>>>> create mode 100644 drivers/gpu/drm/lima/lima_sched.c
>>>>> create mode 100644 drivers/gpu/drm/lima/lima_sched.h
>>>>> create mode 100644 drivers/gpu/drm/lima/lima_ttm.c
>>>>> create mode 100644 drivers/gpu/drm/lima/lima_ttm.h
>>>>> create mode 100644 drivers/gpu/drm/lima/lima_vm.c
>>>>> create mode 100644 drivers/gpu/drm/lima/lima_vm.h
>>>>> create mode 100644 include/uapi/drm/lima_drm.h
>>>>>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: cpufreq: Introduce QCOM CPUFREQ FW bindings
From: Rob Herring @ 2018-05-23 14:18 UTC (permalink / raw)
To: Viresh Kumar
Cc: Taniya Das, Rafael J. Wysocki, linux-kernel@vger.kernel.org,
linux-pm, Stephen Boyd, Rajendra Nayak, Amit Nischal, devicetree,
Saravana Kannan, Amit Kucheria
In-Reply-To: <20180523054846.zn7gftt6aqyibd26@vireshk-i7>
On Wed, May 23, 2018 at 12:48 AM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> On 22-05-18, 14:31, Rob Herring wrote:
>> On Sat, May 19, 2018 at 11:04:50PM +0530, Taniya Das wrote:
>> > + freq-domain-0 {
>> > + compatible = "cpufreq";
>> > + reg = <0x17d43920 0x4>,
>> > + <0x17d43110 0x500>,
>> > + <0x17d41000 0x4>;
>> > + reg-names = "perf_base", "lut_base", "en_base";
>> > + qcom,cpulist = <&CPU0 &CPU1 &CPU2 &CPU3>;
>
> I was thinking, can't we add platform specific properties in the CPU
> nodes ? If yes, then we can point the phandle of fw node from the CPUs
> and this awkward list can go away.
Yes, that's fine. That would be more like OPP binding in that the CPU
points to the OPP table rather than the OPP pointing to the CPUs.
With that, you can get rid of the child nodes completely. Just make
the parent reg property N sets of 3 addresses for N domains.
Rob
^ permalink raw reply
* Re: [RESEND PATCH 2/5] mtd: rawnand: add NVIDIA Tegra NAND Flash controller driver
From: Boris Brezillon @ 2018-05-23 14:18 UTC (permalink / raw)
To: Stefan Agner
Cc: dwmw2, computersforpeace, marek.vasut, robh+dt, mark.rutland,
thierry.reding, mturquette, sboyd, dev, miquel.raynal, richard,
marcel, krzk, digetx, benjamin.lindqvist, jonathanh, pdeschrijver,
pgaikwad, mirza.krak, linux-mtd, linux-tegra, devicetree,
linux-kernel, linux-clk
In-Reply-To: <86fdf19ec92b732709732fb60199f16488b4b727.1526990589.git.stefan@agner.ch>
Hi Stefan,
On Tue, 22 May 2018 14:07:06 +0200
Stefan Agner <stefan@agner.ch> wrote:
> +
> +struct tegra_nand {
> + void __iomem *regs;
> + struct clk *clk;
> + struct gpio_desc *wp_gpio;
> +
> + struct nand_chip chip;
> + struct device *dev;
> +
> + struct completion command_complete;
> + struct completion dma_complete;
> + bool last_read_error;
> +
> + dma_addr_t data_dma;
> + void *data_buf;
> + dma_addr_t oob_dma;
> + void *oob_buf;
> +
> + int cur_chip;
> +};
This struct should be split in 2 structures: one representing the NAND
controller and one representing the NAND chip:
struct tegra_nand_controller {
struct nand_hw_control base;
void __iomem *regs;
struct clk *clk;
struct device *dev;
struct completion command_complete;
struct completion dma_complete;
bool last_read_error;
int cur_chip;
};
struct tegra_nand {
struct nand_chip base;
dma_addr_t data_dma;
void *data_buf;
dma_addr_t oob_dma;
void *oob_buf;
};
> +
> +static inline struct tegra_nand *to_tegra_nand(struct mtd_info *mtd)
> +{
> + struct nand_chip *chip = mtd_to_nand(mtd);
> +
> + return nand_get_controller_data(chip);
then you can just do:
return container_of(chip, struct tegra_nand, base);
> +}
> +
> +static int tegra_nand_ooblayout_16_ecc(struct mtd_info *mtd, int section,
> + struct mtd_oob_region *oobregion)
> +{
> + if (section > 0)
> + return -ERANGE;
> +
> + oobregion->offset = 4;
> + oobregion->length = 4;
> +
> + return 0;
> +}
> +
> +static int tegra_nand_ooblayout_16_free(struct mtd_info *mtd, int section,
> + struct mtd_oob_region *oobregion)
> +{
> + if (section > 0)
> + return -ERANGE;
> +
> + oobregion->offset = 8;
> + oobregion->length = 8;
> +
> + return 0;
> +}
...
> +
> +static int tegra_nand_ooblayout_224_ecc(struct mtd_info *mtd, int section,
> + struct mtd_oob_region *oobregion)
> +{
> + if (section > 0)
> + return -ERANGE;
> +
> + oobregion->offset = 4;
> + oobregion->length = 144;
> +
> + return 0;
> +}
> +
> +static int tegra_nand_ooblayout_224_free(struct mtd_info *mtd, int section,
> + struct mtd_oob_region *oobregion)
> +{
> + if (section > 0)
> + return -ERANGE;
> +
> + oobregion->offset = 148;
> + oobregion->length = 76;
> +
> + return 0;
> +}
> +
> +static const struct mtd_ooblayout_ops tegra_nand_oob_224_ops = {
> + .ecc = tegra_nand_ooblayout_224_ecc,
> + .free = tegra_nand_ooblayout_224_free,
> +};
> +
I'm pretty sure we can find a pattern here to avoid defining a new
mtd_ooblayout_ops for each OOB size.
> +static irqreturn_t tegra_nand_irq(int irq, void *data)
> +{
> + struct tegra_nand *nand = data;
> + u32 isr, dma;
> +
> + isr = readl(nand->regs + ISR);
> + dma = readl(nand->regs + DMA_CTRL);
> + dev_dbg(nand->dev, "isr %08x\n", isr);
> +
> + if (!isr && !(dma & DMA_CTRL_IS_DONE))
> + return IRQ_NONE;
> +
> + if (isr & ISR_CORRFAIL_ERR)
> + nand->last_read_error = true;
> +
> + if (isr & ISR_CMD_DONE)
> + complete(&nand->command_complete);
> +
> + if (isr & ISR_UND)
> + dev_dbg(nand->dev, "FIFO underrun\n");
> +
> + if (isr & ISR_OVR)
> + dev_dbg(nand->dev, "FIFO overrun\n");
> +
> + /* handle DMA interrupts */
> + if (dma & DMA_CTRL_IS_DONE) {
> + writel(dma, nand->regs + DMA_CTRL);
> + complete(&nand->dma_complete);
> + }
> +
> + /* clear interrupts */
> + writel(isr, nand->regs + ISR);
> +
> + return IRQ_HANDLED;
> +}
> +
> +static int tegra_nand_cmd(struct nand_chip *chip,
> + const struct nand_subop *subop)
> +{
> + const struct nand_op_instr *instr;
> + const struct nand_op_instr *instr_data_in = NULL;
> + struct mtd_info *mtd = nand_to_mtd(chip);
> + struct tegra_nand *nand = to_tegra_nand(mtd);
> + unsigned int op_id = -1, trfr_in_sz = 0, trfr_out_sz = 0, offset = 0;
> + bool first_cmd = true;
> + bool force8bit;
> + u32 cmd = 0;
> + u32 value;
> +
> + for (op_id = 0; op_id < subop->ninstrs; op_id++) {
> + unsigned int naddrs, i;
> + const u8 *addrs;
> + u32 addr1 = 0, addr2 = 0;
> +
> + instr = &subop->instrs[op_id];
> +
> + switch (instr->type) {
> + case NAND_OP_CMD_INSTR:
> + if (first_cmd) {
> + cmd |= CMD_CLE;
> + writel(instr->ctx.cmd.opcode, nand->regs + CMD_1);
> + } else {
> + cmd |= CMD_SEC_CMD;
> + writel(instr->ctx.cmd.opcode, nand->regs + CMD_2);
> + }
> + first_cmd = false;
> + break;
> + case NAND_OP_ADDR_INSTR:
> + offset = nand_subop_get_addr_start_off(subop, op_id);
> + naddrs = nand_subop_get_num_addr_cyc(subop, op_id);
> + addrs = &instr->ctx.addr.addrs[offset];
> +
> + cmd |= CMD_ALE | CMD_ALE_SIZE(naddrs);
> + for (i = 0; i < min_t(unsigned int, 4, naddrs); i++)
> + addr1 |= *addrs++ << (8 * i);
> + naddrs -= i;
> + for (i = 0; i < min_t(unsigned int, 4, naddrs); i++)
> + addr2 |= *addrs++ << (8 * i);
> + writel(addr1, nand->regs + ADDR_1);
> + writel(addr2, nand->regs + ADDR_2);
> + break;
> +
> + case NAND_OP_DATA_IN_INSTR:
> + trfr_in_sz = nand_subop_get_data_len(subop, op_id);
> + offset = nand_subop_get_data_start_off(subop, op_id);
> +
> + cmd |= CMD_TRANS_SIZE(trfr_in_sz) | CMD_PIO | CMD_RX | CMD_A_VALID;
> +
> + instr_data_in = instr;
> + break;
> +
> + case NAND_OP_DATA_OUT_INSTR:
> + trfr_out_sz = nand_subop_get_data_len(subop, op_id);
> + offset = nand_subop_get_data_start_off(subop, op_id);
> + trfr_out_sz = min_t(size_t, trfr_out_sz, 4);
> +
> + cmd |= CMD_TRANS_SIZE(trfr_out_sz) | CMD_PIO | CMD_TX | CMD_A_VALID;
> +
> + memcpy(&value, instr->ctx.data.buf.out + offset, trfr_out_sz);
> + writel(value, nand->regs + RESP);
> +
> + break;
> + case NAND_OP_WAITRDY_INSTR:
> + cmd |= CMD_RBSY_CHK;
> + break;
> +
> + }
> + }
> +
> +
> + cmd |= CMD_GO | CMD_CE(nand->cur_chip);
> + writel(cmd, nand->regs + CMD);
> + wait_for_completion(&nand->command_complete);
> +
> + if (instr_data_in) {
> + u32 value;
> + size_t n = min_t(size_t, trfr_in_sz, 4);
> +
> + value = readl(nand->regs + RESP);
> + memcpy(instr_data_in->ctx.data.buf.in + offset, &value, n);
> + }
> +
> + return 0;
> +}
> +
> +static const struct nand_op_parser tegra_nand_op_parser = NAND_OP_PARSER(
> + NAND_OP_PARSER_PATTERN(tegra_nand_cmd,
> + NAND_OP_PARSER_PAT_CMD_ELEM(true),
> + NAND_OP_PARSER_PAT_ADDR_ELEM(true, 8),
> + NAND_OP_PARSER_PAT_CMD_ELEM(true),
> + NAND_OP_PARSER_PAT_WAITRDY_ELEM(true)),
> + NAND_OP_PARSER_PATTERN(tegra_nand_cmd,
> + NAND_OP_PARSER_PAT_DATA_OUT_ELEM(false, 4)),
> + NAND_OP_PARSER_PATTERN(tegra_nand_cmd,
> + NAND_OP_PARSER_PAT_CMD_ELEM(true),
> + NAND_OP_PARSER_PAT_ADDR_ELEM(true, 8),
> + NAND_OP_PARSER_PAT_CMD_ELEM(true),
> + NAND_OP_PARSER_PAT_WAITRDY_ELEM(true),
> + NAND_OP_PARSER_PAT_DATA_IN_ELEM(true, 4)),
> + );
> +
> +static int tegra_nand_exec_op(struct nand_chip *chip,
> + const struct nand_operation *op,
> + bool check_only)
> +{
> + return nand_op_parser_exec_op(chip, &tegra_nand_op_parser, op,
> + check_only);
> +}
Missing empty line here.
> +static void tegra_nand_select_chip(struct mtd_info *mtd, int chip)
> +{
> + struct tegra_nand *nand = to_tegra_nand(mtd);
> +
> + nand->cur_chip = chip;
> +}
...
> +
> +static void tegra_nand_setup_chiptiming(struct tegra_nand *nand)
> +{
> + struct nand_chip *chip = &nand->chip;
> + int mode;
> +
> + mode = onfi_get_async_timing_mode(chip);
> + if (mode == ONFI_TIMING_MODE_UNKNOWN)
> + mode = chip->onfi_timing_mode_default;
> + else
> + mode = fls(mode);
> +
> + tegra_nand_setup_timing(nand, mode);
Hm, you shouldn't do that. Let the core select the timing mode for you,
and just implement the ->setup_data_interface() hook.
> +}
> +
> +static int tegra_nand_probe(struct platform_device *pdev)
> +{
> + struct reset_control *rst;
> + struct tegra_nand *nand;
> + struct nand_chip *chip;
> + struct mtd_info *mtd;
> + struct resource *res;
> + unsigned long value;
> + int irq, err = 0;
> +
> + nand = devm_kzalloc(&pdev->dev, sizeof(*nand), GFP_KERNEL);
> + if (!nand)
> + return -ENOMEM;
> +
> + nand->dev = &pdev->dev;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + nand->regs = devm_ioremap_resource(&pdev->dev, res);
> + if (IS_ERR(nand->regs))
> + return PTR_ERR(nand->regs);
> +
> + irq = platform_get_irq(pdev, 0);
> + err = devm_request_irq(&pdev->dev, irq, tegra_nand_irq, 0,
> + dev_name(&pdev->dev), nand);
> + if (err)
> + return err;
> +
> + rst = devm_reset_control_get(&pdev->dev, "nand");
> + if (IS_ERR(rst))
> + return PTR_ERR(rst);
> +
> + nand->clk = devm_clk_get(&pdev->dev, "nand");
> + if (IS_ERR(nand->clk))
> + return PTR_ERR(nand->clk);
> +
> + nand->wp_gpio = gpiod_get_optional(&pdev->dev, "wp-gpios",
> + GPIOD_OUT_HIGH);
> + if (IS_ERR(nand->wp_gpio))
> + return PTR_ERR(nand->wp_gpio);
> +
> + err = clk_prepare_enable(nand->clk);
> + if (err)
> + return err;
> +
> + reset_control_assert(rst);
> + udelay(2);
> + reset_control_deassert(rst);
> +
> + value = HWSTATUS_RDSTATUS_MASK(1) | HWSTATUS_RDSTATUS_VALUE(0) |
> + HWSTATUS_RBSY_MASK(NAND_STATUS_READY) |
> + HWSTATUS_RBSY_VALUE(NAND_STATUS_READY);
> + writel(NAND_CMD_STATUS, nand->regs + HWSTATUS_CMD);
> + writel(value, nand->regs + HWSTATUS_MASK);
> +
> + init_completion(&nand->command_complete);
> + init_completion(&nand->dma_complete);
> +
> + /* clear interrupts */
> + value = readl(nand->regs + ISR);
> + writel(value, nand->regs + ISR);
> +
> + writel(DMA_CTRL_IS_DONE, nand->regs + DMA_CTRL);
> +
> + /* enable interrupts */
> + value = IER_UND | IER_OVR | IER_CMD_DONE | IER_ECC_ERR | IER_GIE;
> + writel(value, nand->regs + IER);
> +
> + /* reset config */
> + writel(0, nand->regs + CFG);
> +
> + chip = &nand->chip;
> + mtd = nand_to_mtd(chip);
> +
> + mtd->dev.parent = &pdev->dev;
> + mtd->name = "tegra_nand";
> + mtd->owner = THIS_MODULE;
> +
> + nand_set_flash_node(chip, pdev->dev.of_node);
> + nand_set_controller_data(chip, nand);
> +
> + chip->options = NAND_NO_SUBPAGE_WRITE;
> + chip->exec_op = tegra_nand_exec_op;
> + chip->select_chip = tegra_nand_select_chip;
> + tegra_nand_setup_timing(nand, 0);
> +
> + err = nand_scan_ident(mtd, 1, NULL);
> + if (err)
> + goto err_disable_clk;
> +
> + if (chip->bbt_options & NAND_BBT_USE_FLASH)
> + chip->bbt_options |= NAND_BBT_NO_OOB;
> +
> + nand->data_buf = dmam_alloc_coherent(&pdev->dev, mtd->writesize,
> + &nand->data_dma, GFP_KERNEL);
> + if (!nand->data_buf) {
> + err = -ENOMEM;
> + goto err_disable_clk;
> + }
> +
> + nand->oob_buf = dmam_alloc_coherent(&pdev->dev, mtd->oobsize,
> + &nand->oob_dma, GFP_KERNEL);
> + if (!nand->oob_buf) {
> + err = -ENOMEM;
> + goto err_disable_clk;
> + }
> +
> + chip->ecc.mode = NAND_ECC_HW;
> + chip->ecc.size = 512;
> + chip->ecc.read_page = tegra_nand_read_page;
> + chip->ecc.write_page = tegra_nand_write_page;
I'd like to have raw accessors implemented here.
That was just a quick review focusing mainly on architectural issues so
that you can start working on a v2.
Regards,
Boris
^ permalink raw reply
* Re: [PATCH RFC 00/24] Lima DRM driver
From: Qiang Yu @ 2018-05-23 14:13 UTC (permalink / raw)
To: Christian König
Cc: Simon Shields, devicetree, Connor Abbott, Marek Vasut,
Neil Armstrong, Andrei Paulau, dri-devel, Vasily Khoruzhick,
Erico Nunes
In-Reply-To: <ec001286-973f-d3ef-b41c-c634c93ede3e@amd.com>
On Wed, May 23, 2018 at 9:59 PM, Christian König
<christian.koenig@amd.com> wrote:
> Am 23.05.2018 um 15:52 schrieb Qiang Yu:
>>
>> On Wed, May 23, 2018 at 5:29 PM, Christian König
>> <ckoenig.leichtzumerken@gmail.com> wrote:
>>>
>>> Am 18.05.2018 um 11:27 schrieb Qiang Yu:
>>>>
>>>> Kernel DRM driver for ARM Mali 400/450 GPUs.
>>>>
>>>> This implementation mainly take amdgpu DRM driver as reference.
>>>>
>>>> - Mali 4xx GPUs have two kinds of processors GP and PP. GP is for
>>>> OpenGL vertex shader processing and PP is for fragment shader
>>>> processing. Each processor has its own MMU so prcessors work in
>>>> virtual address space.
>>>> - There's only one GP but multiple PP (max 4 for mali 400 and 8
>>>> for mali 450) in the same mali 4xx GPU. All PPs are grouped
>>>> togather to handle a single fragment shader task divided by
>>>> FB output tiled pixels. Mali 400 user space driver is
>>>> responsible for assign target tiled pixels to each PP, but mali
>>>> 450 has a HW module called DLBU to dynamically balance each
>>>> PP's load.
>>>> - User space driver allocate buffer object and map into GPU
>>>> virtual address space, upload command stream and draw data with
>>>> CPU mmap of the buffer object, then submit task to GP/PP with
>>>> a register frame indicating where is the command stream and misc
>>>> settings.
>>>> - There's no command stream validation/relocation due to each user
>>>> process has its own GPU virtual address space. GP/PP's MMU switch
>>>> virtual address space before running two tasks from different
>>>> user process. Error or evil user space code just get MMU fault
>>>> or GP/PP error IRQ, then the HW/SW will be recovered.
>>>> - Use TTM as MM. TTM_PL_TT type memory is used as the content of
>>>> lima buffer object which is allocated from TTM page pool. all
>>>> lima buffer object gets pinned with TTM_PL_FLAG_NO_EVICT when
>>>> allocation, so there's no buffer eviction and swap for now. We
>>>> need reverse engineering to see if and how GP/PP support MMU
>>>> fault recovery (continue execution). Otherwise we have to
>>>> pin/unpin each envolved buffer when task creation/deletion.
>>>
>>>
>>> Well pinning all memory is usually a no-go for upstreaming. But since you
>>> are already using the drm_sched for GPU task scheduling why are you
>>> actually
>>> needing this?
>>>
>>> The scheduler should take care of signaling all fences when the hardware
>>> is
>>> done with it's magic and that is enough for TTM to note that a buffer
>>> object
>>> is movable again (e.g. unpin them).
>>
>> Please correct me if I'm wrong.
>
>
> Well, you are wrong :)
>
>> One way to implement eviction/swap is like this:
>> call validation on each buffers involved in a task, but this won't
>> prevent it from
>> eviction/swap when executing, so a GPU MMU fault may happen and in the
>> handler we need to recover the buffer evicted/swapped.
>>
>> Another way is pin/unpin buffers evolved when task create/free.
>>
>> First way is better when memory load is low and second way is better when
>> memory load is high. First way also need less memory.
>>
>> So I'd prefer first way but due to the GPU MMU fault
>> HW op need reverse engineering, I have to pin all buffers now. After
>> the HW op is clear, I can choose one way to implement.
>
>
> The general approach is:
> 1.) Lock all BOs
> 2.) Validate all BOs
> 3.) Add the fence
> 4.) Unlock the BOs
This is the task prepare process, right?
>
> BOs can't be evicted while they are locked
During the task prepare stage, they're locked, but after task queued, they
get unlocked and be evictable?
> and since you already add the
> fence that should be perfectly sufficient to prevent it from being evicted
> until your operation is completed.
You mean I have to explicitly pin it with TTM_PL_FLAG_NO_EVICT
when task creation or TTM will check buffer's reservation object and
won't evict it if see a fence?
Regards,
Qiang
>
> Using the MMU is certainly be better in general, but usually only optional
> and a pain in the ass to get working. We have that in amdgpu for quite a
> while as well now and still don't use it because of that.
>
> Regards,
> Christian.
>
>
>>
>> Regards,
>> Qiang
>>
>>> Christian.
>>>
>>>
>>>> - Use drm_sched for GPU task schedule. Each OpenGL context should
>>>> have a lima context object in the kernel to distinguish tasks
>>>> from different user. drm_sched gets task from each lima context
>>>> in a fair way.
>>>>
>>>> Not implemented:
>>>> - Dump buffer support
>>>> - Power management
>>>> - Performance counter
>>>>
>>>> This patch serial just pack a pair of .c/.h files in each patch.
>>>> For whole history of this driver's development, see:
>>>> https://github.com/yuq/linux-lima/commits/lima-4.17-rc4
>>>>
>>>> Mesa driver is still in development and not ready for daily usage,
>>>> but can run some simple tests like kmscube and glamrk2, see:
>>>> https://github.com/yuq/mesa-lima
>>>>
>>>> Andrei Paulau (1):
>>>> arm64/dts: add switch-delay for meson mali
>>>>
>>>> Lima Project Developers (10):
>>>> drm/lima: add mali 4xx GPU hardware regs
>>>> drm/lima: add lima core driver
>>>> drm/lima: add GPU device functions
>>>> drm/lima: add PMU related functions
>>>> drm/lima: add PP related functions
>>>> drm/lima: add MMU related functions
>>>> drm/lima: add GPU virtual memory space handing
>>>> drm/lima: add GEM related functions
>>>> drm/lima: add GEM Prime related functions
>>>> drm/lima: add makefile and kconfig
>>>>
>>>> Qiang Yu (12):
>>>> dt-bindings: add switch-delay property for mali-utgard
>>>> arm64/dts: add switch-delay for meson mali
>>>> Revert "drm: Nerf the preclose callback for modern drivers"
>>>> drm/lima: add lima uapi header
>>>> drm/lima: add L2 cache functions
>>>> drm/lima: add GP related functions
>>>> drm/lima: add BCAST related function
>>>> drm/lima: add DLBU related functions
>>>> drm/lima: add TTM subsystem functions
>>>> drm/lima: add buffer object functions
>>>> drm/lima: add GPU schedule using DRM_SCHED
>>>> drm/lima: add context related functions
>>>>
>>>> Simon Shields (1):
>>>> ARM: dts: add gpu node to exynos4
>>>>
>>>> .../bindings/gpu/arm,mali-utgard.txt | 4 +
>>>> arch/arm/boot/dts/exynos4.dtsi | 33 ++
>>>> arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 1 +
>>>> .../boot/dts/amlogic/meson-gxl-mali.dtsi | 1 +
>>>> drivers/gpu/drm/Kconfig | 2 +
>>>> drivers/gpu/drm/Makefile | 1 +
>>>> drivers/gpu/drm/drm_file.c | 8 +-
>>>> drivers/gpu/drm/lima/Kconfig | 9 +
>>>> drivers/gpu/drm/lima/Makefile | 19 +
>>>> drivers/gpu/drm/lima/lima_bcast.c | 65 +++
>>>> drivers/gpu/drm/lima/lima_bcast.h | 34 ++
>>>> drivers/gpu/drm/lima/lima_ctx.c | 143 +++++
>>>> drivers/gpu/drm/lima/lima_ctx.h | 51 ++
>>>> drivers/gpu/drm/lima/lima_device.c | 407 ++++++++++++++
>>>> drivers/gpu/drm/lima/lima_device.h | 136 +++++
>>>> drivers/gpu/drm/lima/lima_dlbu.c | 75 +++
>>>> drivers/gpu/drm/lima/lima_dlbu.h | 37 ++
>>>> drivers/gpu/drm/lima/lima_drv.c | 466 ++++++++++++++++
>>>> drivers/gpu/drm/lima/lima_drv.h | 77 +++
>>>> drivers/gpu/drm/lima/lima_gem.c | 459 ++++++++++++++++
>>>> drivers/gpu/drm/lima/lima_gem.h | 41 ++
>>>> drivers/gpu/drm/lima/lima_gem_prime.c | 66 +++
>>>> drivers/gpu/drm/lima/lima_gem_prime.h | 31 ++
>>>> drivers/gpu/drm/lima/lima_gp.c | 293 +++++++++++
>>>> drivers/gpu/drm/lima/lima_gp.h | 34 ++
>>>> drivers/gpu/drm/lima/lima_l2_cache.c | 98 ++++
>>>> drivers/gpu/drm/lima/lima_l2_cache.h | 32 ++
>>>> drivers/gpu/drm/lima/lima_mmu.c | 154 ++++++
>>>> drivers/gpu/drm/lima/lima_mmu.h | 34 ++
>>>> drivers/gpu/drm/lima/lima_object.c | 120 +++++
>>>> drivers/gpu/drm/lima/lima_object.h | 87 +++
>>>> drivers/gpu/drm/lima/lima_pmu.c | 85 +++
>>>> drivers/gpu/drm/lima/lima_pmu.h | 30 ++
>>>> drivers/gpu/drm/lima/lima_pp.c | 418 +++++++++++++++
>>>> drivers/gpu/drm/lima/lima_pp.h | 37 ++
>>>> drivers/gpu/drm/lima/lima_regs.h | 304 +++++++++++
>>>> drivers/gpu/drm/lima/lima_sched.c | 497
>>>> ++++++++++++++++++
>>>> drivers/gpu/drm/lima/lima_sched.h | 126 +++++
>>>> drivers/gpu/drm/lima/lima_ttm.c | 409 ++++++++++++++
>>>> drivers/gpu/drm/lima/lima_ttm.h | 44 ++
>>>> drivers/gpu/drm/lima/lima_vm.c | 312 +++++++++++
>>>> drivers/gpu/drm/lima/lima_vm.h | 73 +++
>>>> include/drm/drm_drv.h | 23 +-
>>>> include/uapi/drm/lima_drm.h | 195 +++++++
>>>> 44 files changed, 5565 insertions(+), 6 deletions(-)
>>>> create mode 100644 drivers/gpu/drm/lima/Kconfig
>>>> create mode 100644 drivers/gpu/drm/lima/Makefile
>>>> create mode 100644 drivers/gpu/drm/lima/lima_bcast.c
>>>> create mode 100644 drivers/gpu/drm/lima/lima_bcast.h
>>>> create mode 100644 drivers/gpu/drm/lima/lima_ctx.c
>>>> create mode 100644 drivers/gpu/drm/lima/lima_ctx.h
>>>> create mode 100644 drivers/gpu/drm/lima/lima_device.c
>>>> create mode 100644 drivers/gpu/drm/lima/lima_device.h
>>>> create mode 100644 drivers/gpu/drm/lima/lima_dlbu.c
>>>> create mode 100644 drivers/gpu/drm/lima/lima_dlbu.h
>>>> create mode 100644 drivers/gpu/drm/lima/lima_drv.c
>>>> create mode 100644 drivers/gpu/drm/lima/lima_drv.h
>>>> create mode 100644 drivers/gpu/drm/lima/lima_gem.c
>>>> create mode 100644 drivers/gpu/drm/lima/lima_gem.h
>>>> create mode 100644 drivers/gpu/drm/lima/lima_gem_prime.c
>>>> create mode 100644 drivers/gpu/drm/lima/lima_gem_prime.h
>>>> create mode 100644 drivers/gpu/drm/lima/lima_gp.c
>>>> create mode 100644 drivers/gpu/drm/lima/lima_gp.h
>>>> create mode 100644 drivers/gpu/drm/lima/lima_l2_cache.c
>>>> create mode 100644 drivers/gpu/drm/lima/lima_l2_cache.h
>>>> create mode 100644 drivers/gpu/drm/lima/lima_mmu.c
>>>> create mode 100644 drivers/gpu/drm/lima/lima_mmu.h
>>>> create mode 100644 drivers/gpu/drm/lima/lima_object.c
>>>> create mode 100644 drivers/gpu/drm/lima/lima_object.h
>>>> create mode 100644 drivers/gpu/drm/lima/lima_pmu.c
>>>> create mode 100644 drivers/gpu/drm/lima/lima_pmu.h
>>>> create mode 100644 drivers/gpu/drm/lima/lima_pp.c
>>>> create mode 100644 drivers/gpu/drm/lima/lima_pp.h
>>>> create mode 100644 drivers/gpu/drm/lima/lima_regs.h
>>>> create mode 100644 drivers/gpu/drm/lima/lima_sched.c
>>>> create mode 100644 drivers/gpu/drm/lima/lima_sched.h
>>>> create mode 100644 drivers/gpu/drm/lima/lima_ttm.c
>>>> create mode 100644 drivers/gpu/drm/lima/lima_ttm.h
>>>> create mode 100644 drivers/gpu/drm/lima/lima_vm.c
>>>> create mode 100644 drivers/gpu/drm/lima/lima_vm.h
>>>> create mode 100644 include/uapi/drm/lima_drm.h
>>>>
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [RFC 12/13] ARM: dts: ti: add dra71-evm FIT description file
From: Rob Herring @ 2018-05-23 14:13 UTC (permalink / raw)
To: Tero Kristo
Cc: Mark Rutland, devicetree, Tom Rini, Tony Lindgren,
Russell King - ARM Linux, Frank Rowand, Mills, William,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <243730d3-e7f3-584d-b5dd-491c2700cf11@ti.com>
On Wed, May 23, 2018 at 12:55 AM, Tero Kristo <t-kristo@ti.com> wrote:
> On 22/05/18 23:01, Rob Herring wrote:
>>
>> On Mon, May 21, 2018 at 09:57:54AM +0300, Tero Kristo wrote:
>>>
>>> On 17/04/18 17:49, Tony Lindgren wrote:
>>>>
>>>> * Tero Kristo <t-kristo@ti.com> [180417 09:36]:
>>>>>
>>>>> In typical setup, you can boot a large number of different configs via:
>>>>>
>>>>> bootm 0x82000000#dra71-evm#nand#lcd-auo-g101evn01.0
>>>>>
>>>>> ... assuming the configs were named like that, and assuming they would
>>>>> be
>>>>> compatible with each other. The am57xx-evm example provided is better,
>>>>> as
>>>>> you can chain the different cameras to the available evm configs.
>>>>
>>>>
>>>> Why not just do it in the bootloader to put together the dtb?
>>>>
>>>> Then for external devices, you could just pass info on the
>>>> kernel cmdline with lcd=foo camera=bar if they cannot be
>>>> detected over I2C.
>>>
>>>
>>> (Added Linux ARM list to CC, this was not part of the original delivery.)
>>>
>>> Ok trying to resurrect this thread a bit. Is there any kind of consensus
>>> how
>>> things like this should be handled? Should we add the DT overlay files to
>>> kernel tree or not?
>>
>>
>> IMO, yes.
>>
>>> Should we add any kind of build infra to kernel tree, and at what level
>>> would this be? Just DT overlay file building support, and drop the FIT
>>> build
>>> support as was proposed in this RFC series or...?
>>
>>
>> I think I mentioned this already, but I expect that this is going to
>> cause a number of conversions of dtsi + dtsi -> dtb into base dts and
>> overlay(s) dts files. In doing so, we still need to be able to build the
>> original, full dtb.
>
>
> So you mean like breaking apart the existing .dts files? Are there any plans
> to get that done (I know the android folks talk about this but I don't like
> their idea.) If we do the split, how are we going to determine which dts +
> overlay files are required to get a specific DTB done? I actually wrote a
> tool for this purpose which parses the FIT image configurations and
> generates plain dtb files out of the info there if needed, but assuming FIT
> is abandoned then what...?
There aren't any plans that I'm aware of. I'm just assuming there are
some cases in the tree. It would just be some additional build rules:
board-kit.dtb: soc-som.dtb expansion-board.dtbo
fdtoverlay -o $@ -i $^
We'd need to come up with some way to express the input and output
files in a kbuild way. Perhaps similar to how multiple module files
are done.
Even if you are adding new platforms, having the above would still be
good. It captures what base the overlays apply to and tests that
applying actually works (rather than leaving that for the user to do
in the bootloader). FIT images also have or need that information, so
perhaps we can define a format that works as input for both kbuild and
FIT images.
>>> U-boot can obviously parse the base DTB + overlay DTB:s into a single
>>> DTB,
>>> but this is somewhat clumsy approach and is relatively error prone to get
>>> it
>>> right.
>>
>>
>> Why? How is the kernel better?
>
>
> I am mostly speaking about runtime applying of the overlays. If done build
> time, it is obviously on same level. If you apply the base DTS + overlays
> from u-boot prompt, it is not too much fun, and if there are any failures it
> just won't work, but don't really tell you why not.
Runtime, but still at boot time, right?
How is the kernel going to have better error handling? Is libfdt error
handling worse than the kernel's overlay code?
I do think we need to standardize how we tell bootloaders what
overlays to apply. I expect that we'll do that as part of EBBR spec[1]
though that is not part of the immediate focus.
Rob
[1] https://github.com/ARM-software/ebbr
^ permalink raw reply
* Re: [PATCH v2 4/7] Bluetooth: Add new quirk for non-persistent setup settings
From: Sean Wang @ 2018-05-23 14:09 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Mark Rutland, devicetree, Johan Hedberg, LKML, BlueZ development,
Rob Herring, linux-mediatek, linux-arm-kernel
In-Reply-To: <B82BB5F4-E197-4915-A543-C5FF9A5A41F1@holtmann.org>
On Wed, 2018-05-23 at 14:31 +0200, Marcel Holtmann wrote:
> Hi Sean,
>
> >>
> >> [ ... ]
> >>
> >>>> - if (hci_dev_test_flag(hdev, HCI_SETUP)) {
> >>>> + if (hci_dev_test_flag(hdev, HCI_SETUP) ||
> >>>> + test_bit(HCI_QUIRK_NON_PERSISTENT_SETUP, &hdev->quirks)) {
> >>>> hci_sock_dev_event(hdev, HCI_DEV_SETUP);
> >>>
> >>> I am not 100% sure that we want to send the HCI_DEV_SETUP event also multiple times. That is a userspace change that I would need to think about. We need to check create_monitor_event() and see what the btmon trace for this looks like. Can you send me a btmon -w trace.log when this change is active.
> >>>
> >>> Regards
> >>>
> >>> Marcel
> >>>
> >>
> >> Sure, I'll send you the trace.log with the change is active.
> >>
> >> Sean
> >>
> >
> >
> > Attached trace.log was captured when I inputted commands power on and
> > then off in bluetoothctl.
>
> the trace.log is somehow mangled. Something is not fully correct. Can you read it with btmon -r trace.log?
>
> Regards
>
> Marcel
>
Yes, I can read it with btmon -r trace.log.
I post it as plain text as below
Bluetooth monitor ver 5.37
= Note: Linux version 4.16.0-rc1+ (aarch64) 0.641494
= Note: Bluetooth subsystem version 2.22 0.641502
= New Index: 00:00:46:76:22:01 (BR/EDR,UART,hci0) [hci0] 0.641505
* Unknown packet (code 14 len 30) 0.641509
01 00 00 00 02 00 01 0e 00 01 00 00 00 10 62 6c ..............bl
75 65 74 6f 6f 74 68 64 00 00 00 00 00 00 uetoothd......
* Unknown packet (code 14 len 30) 0.641592
02 00 00 00 02 00 01 0e 00 01 00 00 00 10 62 74 ..............bt
6d 6f 6e 00 00 00 00 00 00 00 00 00 00 00 mon...........
* Unknown packet (code 16 len 7) [hci0] 6.536771
01 00 00 00 05 00 01 .......
= Open Index: 00:00:46:76:22:01 [hci0] 6.717019
= Index Info: 00:00:46:76:22:01 (MediaTek, Inc.) [hci0] 6.717030
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.741093
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.742088
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.743102
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.744105
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.745109
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.746104
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.747097
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.748090
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.749078
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.750070
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.751061
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.752054
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.753046
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.754038
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.755031
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.756025
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.757013
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.758006
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.758999
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.759991
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.760983
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.761975
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.762963
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.763956
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.764948
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.765941
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.766933
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.767926
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.768919
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.769914
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.770909
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.771908
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.772904
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.773898
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.774892
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.775890
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.776882
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.777877
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.778871
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.779869
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.780864
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.781858
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.782852
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.783850
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.784845
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.785839
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.786833
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.787831
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.788826
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.789820
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.790814
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.791813
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.792809
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.793803
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.794798
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.795797
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.796791
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.797786
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.798779
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.799778
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.800774
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.801769
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.802763
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.803761
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.804755
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.805749
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.806743
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.807741
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.808737
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.809731
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.810725
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.811725
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.812719
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.813714
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.814708
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.815705
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.816378
02 01 01 00 00 .....
< HCI Command: Vendor (0x3f|0x006f) plen 5 [hci0] 6.816413
01 07 01 00 04 .....
> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.816536
02 07 01 00 00 .....
< HCI Command: Vendor (0x3f|0x006f) plen 6 [hci0] 8.845071
01 06 02 00 00 01 ......
> HCI Event: Unknown (0xe4) plen 5 [hci0] 8.923456
02 06 01 00 00 .....
< HCI Command: Reset (0x03|0x0003) plen 0 [hci0] 10.861118
> HCI Event: Command Complete (0x0e) plen 4 [hci0] 10.865763
Reset (0x03|0x0003) ncmd 1
Status: Success (0x00)
< HCI Command: Read Local Supported Fe.. (0x04|0x0003) plen 0 [hci0] 10.865805
> HCI Event: Command Complete (0x0e) plen 12 [hci0] 10.865965
Read Local Supported Features (0x04|0x0003) ncmd 1
Status: Success (0x00)
Features: 0xbf 0x3e 0x8d 0xfe 0xdb 0xff 0x7b 0x87
3 slot packets
5 slot packets
Encryption
Slot offset
Timing accuracy
Role switch
Sniff mode
Power control requests
Channel quality driven data rate (CQDDR)
SCO link
HV2 packets
HV3 packets
CVSD synchronous data
Power control
Transparent synchronous data
Broadcast Encryption
Enhanced Data Rate ACL 2 Mbps mode
Enhanced Data Rate ACL 3 Mbps mode
Enhanced inquiry scan
Interlaced inquiry scan
Interlaced page scan
RSSI with inquiry results
Extended SCO link (EV3 packets)
EV4 packets
EV5 packets
AFH capable slave
AFH classification slave
LE Supported (Controller)
3-slot Enhanced Data Rate ACL packets
5-slot Enhanced Data Rate ACL packets
Sniff subrating
Pause encryption
AFH capable master
AFH classification master
Enhanced Data Rate eSCO 2 Mbps mode
Enhanced Data Rate eSCO 3 Mbps mode
3-slot Enhanced Data Rate eSCO packets
Extended Inquiry Response
Simultaneous LE and BR/EDR (Controller)
Secure Simple Pairing
Encapsulated PDU
Erroneous Data Reporting
Non-flushable Packet Boundary Flag
Link Supervision Timeout Changed Event
Inquiry TX Power Level
Enhanced Power Control
Extended features
< HCI Command: Read Local Version Info.. (0x04|0x0001) plen 0 [hci0] 10.865987
> HCI Event: Vendor (0xff) plen 9 [hci0] 10.866259
29 19 09 17 20 48 07 11 00 )... H...
> HCI Event: Command Complete (0x0e) plen 12 [hci0] 10.866372
Read Local Version Information (0x04|0x0001) ncmd 1
Status: Success (0x00)
HCI version: Bluetooth 4.2 (0x08) - Revision 4359 (0x1107)
LMP version: Bluetooth 4.2 (0x08) - Subversion 2329 (0x0919)
Manufacturer: MediaTek, Inc. (70)
< HCI Command: Read BD ADDR (0x04|0x0009) plen 0 [hci0] 10.866391
> HCI Event: Command Complete (0x0e) plen 10 [hci0] 10.866539
Read BD ADDR (0x04|0x0009) ncmd 1
Status: Success (0x00)
Address: 00:00:46:76:22:01 (OLIVETTI NORTH AMERICA)
< HCI Command: Read Buffer Size (0x04|0x0005) plen 0 [hci0] 10.866609
> HCI Event: Command Complete (0x0e) plen 11 [hci0] 10.866754
Read Buffer Size (0x04|0x0005) ncmd 1
Status: Success (0x00)
ACL MTU: 1021 ACL max packet: 8
SCO MTU: 184 SCO max packet: 1
< HCI Command: Read Class of Device (0x03|0x0023) plen 0 [hci0] 10.866775
> HCI Event: Command Complete (0x0e) plen 7 [hci0] 10.866920
Read Class of Device (0x03|0x0023) ncmd 1
Status: Success (0x00)
Class: 0x001f00
Major class: Uncategorized, specific device code not specified
Minor class: 0x00
< HCI Command: Read Local Name (0x03|0x0014) plen 0 [hci0] 10.866939
> HCI Event: Command Complete (0x0e) plen 252 [hci0] 10.867256
Read Local Name (0x03|0x0014) ncmd 1
Status: Success (0x00)
Name: MTK MT7622 #1
< HCI Command: Read Voice Setting (0x03|0x0025) plen 0 [hci0] 10.867308
> HCI Event: Command Complete (0x0e) plen 6 [hci0] 10.867447
Read Voice Setting (0x03|0x0025) ncmd 1
Status: Success (0x00)
Setting: 0x0060
Input Coding: Linear
Input Data Format: 2's complement
Input Sample Size: 16-bit
# of bits padding at MSB: 0
Air Coding Format: CVSD
< HCI Command: Read Number of Supporte.. (0x03|0x0038) plen 0 [hci0] 10.867474
> HCI Event: Command Complete (0x0e) plen 5 [hci0] 10.867611
Read Number of Supported IAC (0x03|0x0038) ncmd 1
Status: Success (0x00)
Number of IAC: 4
< HCI Command: Read Current IAC LAP (0x03|0x0039) plen 0 [hci0] 10.867678
> HCI Event: Command Complete (0x0e) plen 8 [hci0] 10.867865
Read Current IAC LAP (0x03|0x0039) ncmd 1
Status: Success (0x00)
Number of IAC: 1
Access code: 0x9e8b33 (General Inquiry)
< HCI Command: Set Event Filter (0x03|0x0005) plen 1 [hci0] 10.867890
Type: Clear All Filters (0x00)
> HCI Event: Command Complete (0x0e) plen 4 [hci0] 10.868033
Set Event Filter (0x03|0x0005) ncmd 1
Status: Success (0x00)
< HCI Command: Write Connection Accept.. (0x03|0x0016) plen 2 [hci0] 10.868054
Timeout: 20000.000 msec (0x7d00)
> HCI Event: Command Complete (0x0e) plen 4 [hci0] 10.868235
Write Connection Accept Timeout (0x03|0x0016) ncmd 1
Status: Success (0x00)
< HCI Command: LE Read Buffer Size (0x08|0x0002) plen 0 [hci0] 10.868262
> HCI Event: Command Complete (0x0e) plen 7 [hci0] 10.868392
LE Read Buffer Size (0x08|0x0002) ncmd 1
Status: Success (0x00)
Data packet length: 251
Num data packets: 8
< HCI Command: LE Read Local Supported.. (0x08|0x0003) plen 0 [hci0] 10.868413
> HCI Event: Command Complete (0x0e) plen 12 [hci0] 10.868587
LE Read Local Supported Features (0x08|0x0003) ncmd 1
Status: Success (0x00)
Features: 0xfd 0x00 0x00 0x00 0x00 0x00 0x00 0x00
LE Encryption
Extended Reject Indication
Slave-initiated Features Exchange
LE Ping
LE Data Packet Length Extension
LL Privacy
Extended Scanner Filter Policies
< HCI Command: LE Read Supported States (0x08|0x001c) plen 0 [hci0] 10.868646
> HCI Event: Command Complete (0x0e) plen 12 [hci0] 10.868787
LE Read Supported States (0x08|0x001c) ncmd 1
Status: Success (0x00)
States: 0x000000001fffffff
Non-connectable Advertising State
Scannable Advertising State
Connectable Advertising State
High Duty Cycle Directed Advertising State
Passive Scanning State
Active Scanning State
Initiating State
and Connection State (Master Role)
Connection State (Slave Role)
Non-connectable Advertising State
and Passive Scanning State
Scannable Advertising State
and Passive Scanning State
Connectable Advertising State
and Passive Scanning State
High Duty Cycle Directed Advertising State
and Passive Scanning State
Non-connectable Advertising State
and Active Scanning State
Scannable Advertising State
and Active Scanning State
Connectable Advertising State
and Active Scanning State
High Duty Cycle Directed Advertising State
and Active Scanning State
Non-connectable Advertising State
and Initiating State
Scannable Advertising State
and Initiating State
Non-connectable Advertising State
and Connection State (Master Role)
Scannable Advertising State
and Connection State (Master Role)
Non-connectable Advertising State
and Connection State (Slave Role)
Scannable Advertising State
and Connection State (Slave Role)
Passive Scanning State
and Initiating State
Active Scanning State
and Initiating State
Passive Scanning State
and Connection State (Master Role)
Active Scanning State
and Connection State (Master Role)
Passive Scanning State
and Connection State (Slave Role)
Active Scanning State
and Connection State (Slave Role)
Initiating State
and Connection State (Master Role)
and Master Role & Master Role
< HCI Command: Read Local Supported Co.. (0x04|0x0002) plen 0 [hci0] 10.868807
> HCI Event: Command Complete (0x0e) plen 68 [hci0] 10.868985
Read Local Supported Commands (0x04|0x0002) ncmd 1
Status: Success (0x00)
Commands: 176 entries
Inquiry (Octet 0 - Bit 0)
Inquiry Cancel (Octet 0 - Bit 1)
Periodic Inquiry Mode (Octet 0 - Bit 2)
Exit Periodic Inquiry Mode (Octet 0 - Bit 3)
Create Connection (Octet 0 - Bit 4)
Disconnect (Octet 0 - Bit 5)
Add SCO Connection (Octet 0 - Bit 6)
Create Connection Cancel (Octet 0 - Bit 7)
Accept Connection Request (Octet 1 - Bit 0)
Reject Connection Request (Octet 1 - Bit 1)
Link Key Request Reply (Octet 1 - Bit 2)
Link Key Request Negative Reply (Octet 1 - Bit 3)
PIN Code Request Reply (Octet 1 - Bit 4)
PIN Code Request Negative Reply (Octet 1 - Bit 5)
Change Connection Packet Type (Octet 1 - Bit 6)
Authentication Requested (Octet 1 - Bit 7)
Set Connection Encryption (Octet 2 - Bit 0)
Change Connection Link Key (Octet 2 - Bit 1)
Master Link Key (Octet 2 - Bit 2)
Remote Name Request (Octet 2 - Bit 3)
Remote Name Request Cancel (Octet 2 - Bit 4)
Read Remote Supported Features (Octet 2 - Bit 5)
Read Remote Extended Features (Octet 2 - Bit 6)
Read Remote Version Information (Octet 2 - Bit 7)
Read Clock Offset (Octet 3 - Bit 0)
Read LMP Handle (Octet 3 - Bit 1)
Sniff Mode (Octet 4 - Bit 2)
Exit Sniff Mode (Octet 4 - Bit 3)
QoS Setup (Octet 4 - Bit 6)
Role Discovery (Octet 4 - Bit 7)
Switch Role (Octet 5 - Bit 0)
Read Link Policy Settings (Octet 5 - Bit 1)
Write Link Policy Settings (Octet 5 - Bit 2)
Read Default Link Policy Settings (Octet 5 - Bit 3)
Write Default Link Policy Settings (Octet 5 - Bit 4)
Flow Specification (Octet 5 - Bit 5)
Set Event Mask (Octet 5 - Bit 6)
Reset (Octet 5 - Bit 7)
Set Event Filter (Octet 6 - Bit 0)
Flush (Octet 6 - Bit 1)
Read PIN Type (Octet 6 - Bit 2)
Write PIN Type (Octet 6 - Bit 3)
Create New Unit Key (Octet 6 - Bit 4)
Read Stored Link Key (Octet 6 - Bit 5)
Write Stored Link Key (Octet 6 - Bit 6)
Delete Stored Link Key (Octet 6 - Bit 7)
Write Local Name (Octet 7 - Bit 0)
Read Local Name (Octet 7 - Bit 1)
Read Connection Accept Timeout (Octet 7 - Bit 2)
Write Connection Accept Timeout (Octet 7 - Bit 3)
Read Page Timeout (Octet 7 - Bit 4)
Write Page Timeout (Octet 7 - Bit 5)
Read Scan Enable (Octet 7 - Bit 6)
Write Scan Enable (Octet 7 - Bit 7)
Read Page Scan Activity (Octet 8 - Bit 0)
Write Page Scan Activity (Octet 8 - Bit 1)
Read Inquiry Scan Activity (Octet 8 - Bit 2)
Write Inquiry Scan Activity (Octet 8 - Bit 3)
Read Authentication Enable (Octet 8 - Bit 4)
Write Authentication Enable (Octet 8 - Bit 5)
Read Encryption Mode (Octet 8 - Bit 6)
Write Encryption Mode (Octet 8 - Bit 7)
Read Class of Device (Octet 9 - Bit 0)
Write Class of Device (Octet 9 - Bit 1)
Read Voice Setting (Octet 9 - Bit 2)
Write Voice Setting (Octet 9 - Bit 3)
Read Automatic Flush Timeout (Octet 9 - Bit 4)
Write Automatic Flush Timeout (Octet 9 - Bit 5)
Read Num Broadcast Retransmissions (Octet 9 - Bit 6)
Write Num Broadcast Retransmissions (Octet 9 - Bit 7)
Read Transmit Power Level (Octet 10 - Bit 2)
Read Sync Flow Control Enable (Octet 10 - Bit 3)
Write Sync Flow Control Enable (Octet 10 - Bit 4)
Set Controller To Host Flow Control (Octet 10 - Bit 5)
Host Buffer Size (Octet 10 - Bit 6)
Host Number of Completed Packets (Octet 10 - Bit 7)
Read Link Supervision Timeout (Octet 11 - Bit 0)
Write Link Supervision Timeout (Octet 11 - Bit 1)
Read Number of Supported IAC (Octet 11 - Bit 2)
Read Current IAC LAP (Octet 11 - Bit 3)
Write Current IAC LAP (Octet 11 - Bit 4)
Read Page Scan Mode (Octet 11 - Bit 7)
Write Page Scan Mode (Octet 12 - Bit 0)
Set AFH Host Channel Classification (Octet 12 - Bit 1)
Read Inquiry Scan Type (Octet 12 - Bit 4)
Write Inquiry Scan Type (Octet 12 - Bit 5)
Read Inquiry Mode (Octet 12 - Bit 6)
Write Inquiry Mode (Octet 12 - Bit 7)
Read Page Scan Type (Octet 13 - Bit 0)
Write Page Scan Type (Octet 13 - Bit 1)
Read AFH Channel Assessment Mode (Octet 13 - Bit 2)
Write AFH Channel Assessment Mode (Octet 13 - Bit 3)
Read Local Version Information (Octet 14 - Bit 3)
Read Local Supported Features (Octet 14 - Bit 5)
Read Local Extended Features (Octet 14 - Bit 6)
Read Buffer Size (Octet 14 - Bit 7)
Read Country Code (Octet 15 - Bit 0)
Read BD ADDR (Octet 15 - Bit 1)
Read Failed Contact Counter (Octet 15 - Bit 2)
Reset Failed Contact Counter (Octet 15 - Bit 3)
Read Link Quality (Octet 15 - Bit 4)
Read RSSI (Octet 15 - Bit 5)
Read AFH Channel Map (Octet 15 - Bit 6)
Read Clock (Octet 15 - Bit 7)
Read Loopback Mode (Octet 16 - Bit 0)
Write Loopback Mode (Octet 16 - Bit 1)
Enable Device Under Test Mode (Octet 16 - Bit 2)
Setup Synchronous Connection (Octet 16 - Bit 3)
Accept Synchronous Connection Request (Octet 16 - Bit 4)
Reject Synchronous Connection Request (Octet 16 - Bit 5)
Read Extended Inquiry Response (Octet 17 - Bit 0)
Write Extended Inquiry Response (Octet 17 - Bit 1)
Refresh Encryption Key (Octet 17 - Bit 2)
Sniff Subrating (Octet 17 - Bit 4)
Read Simple Pairing Mode (Octet 17 - Bit 5)
Write Simple Pairing Mode (Octet 17 - Bit 6)
Read Local OOB Data (Octet 17 - Bit 7)
Read Inquiry Response TX Power Level (Octet 18 - Bit 0)
Write Inquiry Transmit Power Level (Octet 18 - Bit 1)
Read Default Erroneous Data Reporting (Octet 18 - Bit 2)
Write Default Erroneous Data Reporting (Octet 18 - Bit 3)
IO Capability Request Reply (Octet 18 - Bit 7)
User Confirmation Request Reply (Octet 19 - Bit 0)
User Confirmation Request Neg Reply (Octet 19 - Bit 1)
User Passkey Request Reply (Octet 19 - Bit 2)
User Passkey Request Negative Reply (Octet 19 - Bit 3)
Remote OOB Data Request Reply (Octet 19 - Bit 4)
Write Simple Pairing Debug Mode (Octet 19 - Bit 5)
Enhanced Flush (Octet 19 - Bit 6)
Remote OOB Data Request Neg Reply (Octet 19 - Bit 7)
Send Keypress Notification (Octet 20 - Bit 2)
IO Capability Request Negative Reply (Octet 20 - Bit 3)
Read Encryption Key Size (Octet 20 - Bit 4)
Set Event Mask Page 2 (Octet 22 - Bit 2)
Read Enhanced Transmit Power Level (Octet 24 - Bit 0)
Enhanced Setup Synchronous Connection (Octet 29 - Bit 3)
Enhanced Accept Synchronous Connection Request (Octet 29 - Bit 4)
Read Local Supported Codecs (Octet 29 - Bit 5)
Set Triggered Clock Capture (Octet 30 - Bit 5)
Truncated Page (Octet 30 - Bit 6)
Truncated Page Cancel (Octet 30 - Bit 7)
Set Connectionless Slave Broadcast (Octet 31 - Bit 0)
Start Synchronization Train (Octet 31 - Bit 2)
Set Reserved LT_ADDR (Octet 31 - Bit 4)
Delete Reserved LT_ADDR (Octet 31 - Bit 5)
Set Connectionless Slave Broadcast Data (Octet 31 - Bit 6)
Read Synchronization Train Parameters (Octet 31 - Bit 7)
Write Synchronization Train Parameters (Octet 32 - Bit 0)
Remote OOB Extended Data Request Reply (Octet 32 - Bit 1)
Read Authenticated Payload Timeout (Octet 32 - Bit 4)
Write Authenticated Payload Timeout (Octet 32 - Bit 5)
Read Local OOB Extended Data (Octet 32 - Bit 6)
Write Secure Connections Test Mode (Octet 32 - Bit 7)
Read Extended Page Timeout (Octet 33 - Bit 0)
Write Extended Page Timeout (Octet 33 - Bit 1)
Read Extended Inquiry Length (Octet 33 - Bit 2)
Write Extended Inquiry Length (Octet 33 - Bit 3)
LE Set Data Length (Octet 33 - Bit 6)
LE Read Suggested Default Data Length (Octet 33 - Bit 7)
LE Write Suggested Default Data Length (Octet 34 - Bit 0)
LE Read Local P-256 Public Key (Octet 34 - Bit 1)
LE Generate DHKey (Octet 34 - Bit 2)
LE Add Device To Resolving List (Octet 34 - Bit 3)
LE Remove Device From Resolving List (Octet 34 - Bit 4)
LE Clear Resolving List (Octet 34 - Bit 5)
LE Read Resolving List Size (Octet 34 - Bit 6)
LE Read Peer Resolvable Address (Octet 34 - Bit 7)
LE Read Local Resolvable Address (Octet 35 - Bit 0)
LE Set Address Resolution Enable (Octet 35 - Bit 1)
LE Set Resolvable Private Address Timeout (Octet 35 - Bit 2)
LE Read Maximum Data Length (Octet 35 - Bit 3)
Octet 35 - Bit 4
Octet 35 - Bit 5
Octet 35 - Bit 6
Octet 35 - Bit 7
Octet 36 - Bit 0
< HCI Command: Write Simple Pairing Mode (0x03|0x0056) plen 1 [hci0] 10.869023
Mode: Enabled (0x01)
> HCI Event: Command Complete (0x0e) plen 4 [hci0] 10.869185
Write Simple Pairing Mode (0x03|0x0056) ncmd 1
Status: Success (0x00)
< HCI Command: Write Inquiry Mode (0x03|0x0045) plen 1 [hci0] 10.869239
Mode: Inquiry Result with RSSI or Extended Inquiry Result (0x02)
> HCI Event: Command Complete (0x0e) plen 4 [hci0] 10.869371
Write Inquiry Mode (0x03|0x0045) ncmd 1
Status: Success (0x00)
< HCI Command: Read Inquiry Response T.. (0x03|0x0058) plen 0 [hci0] 10.869396
> HCI Event: Command Complete (0x0e) plen 5 [hci0] 10.869552
Read Inquiry Response TX Power Level (0x03|0x0058) ncmd 1
Status: Success (0x00)
TX power: -1 dBm
< HCI Command: Read Local Extended Fea.. (0x04|0x0004) plen 1 [hci0] 10.869572
Page: 1
> HCI Event: Command Complete (0x0e) plen 14 [hci0] 10.869729
Read Local Extended Features (0x04|0x0004) ncmd 1
Status: Success (0x00)
Page: 1/2
Features: 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00
Secure Simple Pairing (Host Support)
< HCI Command: Set Event Mask (0x03|0x0001) plen 8 [hci0] 10.869783
Mask: 0x3dbff807fffbffff
Inquiry Complete
Inquiry Result
Connection Complete
Connection Request
Disconnection Complete
Authentication Complete
Remote Name Request Complete
Encryption Change
Change Connection Link Key Complete
Master Link Key Complete
Read Remote Supported Features Complete
Read Remote Version Information Complete
QoS Setup Complete
Command Complete
Command Status
Hardware Error
Flush Occurred
Role Change
Mode Change
Return Link Keys
PIN Code Request
Link Key Request
Link Key Notification
Loopback Command
Data Buffer Overflow
Max Slots Change
Read Clock Offset Complete
Connection Packet Type Changed
QoS Violation
Page Scan Mode Change
Page Scan Repetition Mode Change
Flow Specification Complete
Inquiry Result with RSSI
Read Remote Extended Features Complete
Synchronous Connection Complete
Synchronous Connection Changed
Sniff Subrating
Extended Inquiry Result
Encryption Key Refresh Complete
IO Capability Request
IO Capability Request Reply
User Confirmation Request
User Passkey Request
Remote OOB Data Request
Simple Pairing Complete
Link Supervision Timeout Changed
Enhanced Flush Complete
User Passkey Notification
Keypress Notification
Remote Host Supported Features Notification
LE Meta
> HCI Event: Command Complete (0x0e) plen 4 [hci0] 10.869921
Set Event Mask (0x03|0x0001) ncmd 1
Status: Success (0x00)
< HCI Command: Read Stored Link Key (0x03|0x000d) plen 7 [hci0] 10.869947
Address: 00:00:00:00:00:00 (OUI 00-00-00)
Read all: 0x01
> HCI Event: Command Complete (0x0e) plen 8 [hci0] 10.870129
Read Stored Link Key (0x03|0x000d) ncmd 1
Status: Success (0x00)
Max num keys: 4
Num keys: 0
< HCI Command: Write Default Link Poli.. (0x02|0x000f) plen 2 [hci0] 10.870148
Link policy: 0x0005
Enable Role Switch
Enable Sniff Mode
> HCI Event: Command Complete (0x0e) plen 4 [hci0] 10.870310
Write Default Link Policy Settings (0x02|0x000f) ncmd 1
Status: Success (0x00)
< HCI Command: Read Page Scan Activity (0x03|0x001b) plen 0 [hci0] 10.870331
> HCI Event: Command Complete (0x0e) plen 8 [hci0] 10.870485
Read Page Scan Activity (0x03|0x001b) ncmd 1
Status: Success (0x00)
Interval: 1280.000 msec (0x0800)
Window: 11.250 msec (0x0012)
< HCI Command: Read Page Scan Type (0x03|0x0046) plen 0 [hci0] 10.870504
> HCI Event: Command Complete (0x0e) plen 5 [hci0] 10.870652
Read Page Scan Type (0x03|0x0046) ncmd 1
Status: Success (0x00)
Type: Standard Scan (0x00)
< HCI Command: LE Set Event Mask (0x08|0x0001) plen 8 [hci0] 10.870671
Mask: 0x0000000000000980
LE Read Local P-256 Public Key Complete
LE Generate DHKey Complete
Unknown mask (0x0000000000000800)
> HCI Event: Command Complete (0x0e) plen 4 [hci0] 10.870839
LE Set Event Mask (0x08|0x0001) ncmd 1
Status: Success (0x00)
< HCI Command: Write LE Host Supported (0x03|0x006d) plen 2 [hci0] 10.870859
Supported: 0x01
Simultaneous: 0x00
> HCI Event: Command Complete (0x0e) plen 4 [hci0] 10.871028
Write LE Host Supported (0x03|0x006d) ncmd 1
Status: Success (0x00)
< HCI Command: Read Local Extended Fea.. (0x04|0x0004) plen 1 [hci0] 10.871059
Page: 2
> HCI Event: Command Complete (0x0e) plen 14 [hci0] 10.871201
Read Local Extended Features (0x04|0x0004) ncmd 1
Status: Success (0x00)
Page: 2/2
Features: 0x25 0x0b 0x00 0x00 0x00 0x00 0x00 0x00
Connectionless Slave Broadcast - Master
Synchronization Train
Generalized interlaced scan
Secure Connections (Controller Support)
Ping
Train nudging
< HCI Command: Delete Stored Link Key (0x03|0x0012) plen 7 [hci0] 10.871240
Address: 00:00:00:00:00:00 (OUI 00-00-00)
Delete all: 0x01
> HCI Event: Command Complete (0x0e) plen 6 [hci0] 10.871384
Delete Stored Link Key (0x03|0x0012) ncmd 1
Status: Success (0x00)
Num keys: 0
< HCI Command: Set Event Mask Page 2 (0x03|0x0063) plen 8 [hci0] 10.871403
Mask: 0x0000000000b0c000
Triggered Clock Capture
Synchronization Train Complete
Slave Page Response Timeout
Connectionless Slave Broadcast Channel Map Change
Authenticated Payload Timeout Expired
> HCI Event: Command Complete (0x0e) plen 4 [hci0] 10.871566
Set Event Mask Page 2 (0x03|0x0063) ncmd 1
Status: Success (0x00)
< HCI Command: Read Local Supported Co.. (0x04|0x000b) plen 0 [hci0] 10.871599
> HCI Event: Command Complete (0x0e) plen 8 [hci0] 10.871750
Read Local Supported Codecs (0x04|0x000b) ncmd 1
Status: Success (0x00)
Number of supported codecs: 2
Codec: CVSD (0x02)
Codec: Transparent (0x03)
Number of vendor codecs: 0
< HCI Command: Read Synchronization Tr.. (0x03|0x0077) plen 0 [hci0] 10.871769
> HCI Event: Command Complete (0x0e) plen 11 [hci0] 10.871928
Read Synchronization Train Parameters (0x03|0x0077) ncmd 1
Status: Success (0x00)
Interval: 0.000 msec (0x0000)
Timeout: 0.000 msec (0x00000000)
Service data: 0x00
< HCI Command: Write Secure Connection.. (0x03|0x007a) plen 1 [hci0] 10.871947
Support: Enabled (0x01)
> HCI Event: Command Complete (0x0e) plen 4 [hci0] 10.872098
Write Secure Connections Host Support (0x03|0x007a) ncmd 1
Status: Success (0x00)
< HCI Command: Unknown (0x08|0x0031) plen 3 [hci0] 10.872156
03 00 00 ...
> HCI Event: Command Complete (0x0e) plen 4 [hci0] 10.872322
Unknown (0x08|0x0031) ncmd 1
Status: Success (0x00)
= Index Info: 00:00:46:76:22:01 (MediaTek, Inc.) [hci0] 10.872361
< HCI Command: LE Set Scan Response D.. (0x08|0x0009) plen 32 [hci0] 10.872431
Length: 10
Name (complete): builder
> HCI Event: Command Complete (0x0e) plen 4 [hci0] 10.872606
LE Set Scan Response Data (0x08|0x0009) ncmd 1
Status: Success (0x00)
< HCI Command: Write Scan Enable (0x03|0x001a) plen 1 [hci0] 10.872627
Scan enable: Page Scan (0x02)
> HCI Event: Command Complete (0x0e) plen 4 [hci0] 10.872819
Write Scan Enable (0x03|0x001a) ncmd 1
Status: Success (0x00)
< HCI Command: Write Class of Device (0x03|0x0024) plen 3 [hci0] 10.872841
Class: 0x000000
Major class: Miscellaneous
Minor class: 0x00
> HCI Event: Command Complete (0x0e) plen 4 [hci0] 10.873036
Write Class of Device (0x03|0x0024) ncmd 1
Status: Success (0x00)
* Unknown packet (code 17 len 9) [hci0] 10.873069
02 00 00 00 07 00 00 00 00 .........
* Unknown packet (code 17 len 9) [hci0] 10.873069
01 00 00 00 07 00 00 00 00 .........
< HCI Command: Write Local Name (0x03|0x0013) plen 248 [hci0] 10.873096
Name: builder
> HCI Event: Command Complete (0x0e) plen 4 [hci0] 10.873446
Write Local Name (0x03|0x0013) ncmd 1
Status: Success (0x00)
< HCI Command: Write Extended Inquir.. (0x03|0x0052) plen 241 [hci0] 10.873470
FEC: Not required (0x00)
Name (complete): builder
TX power: -1 dBm
Device ID: USB Implementer's Forum assigned (0x0002)
Vendor: Linux Foundation (0x1d6b)
Product: 0x0246
Version: 5.2.11 (0x052b)
16-bit Service UUIDs (complete): 4 entries
Generic Access Profile (0x1800)
Generic Attribute Profile (0x1801)
A/V Remote Control (0x110e)
A/V Remote Control Target (0x110c)
> HCI Event: Command Complete (0x0e) plen 4 [hci0] 10.873857
Write Extended Inquiry Response (0x03|0x0052) ncmd 1
Status: Success (0x00)
* Unknown packet (code 17 len 13) [hci0] 10.873903
01 00 00 00 01 00 05 00 00 d1 0a 00 00 .............
* Unknown packet (code 17 len 10) [hci0] 10.873913
02 00 00 00 06 00 d1 0a 00 00 ..........
* Unknown packet (code 16 len 7) [hci0] 17.803939
01 00 00 00 05 00 00 .......
< HCI Command: Write Scan Enable (0x03|0x001a) plen 1 [hci0] 17.803983
Scan enable: No Scans (0x00)
> HCI Event: Command Complete (0x0e) plen 4 [hci0] 17.804233
Write Scan Enable (0x03|0x001a) ncmd 1
Status: Success (0x00)
< HCI Command: Vendor (0x3f|0x006f) plen 6 [hci0] 17.804282
01 06 02 00 00 00 ......
> HCI Event: Unknown (0xe4) plen 5 [hci0] 17.804636
02 06 01 00 00 .....
* Unknown packet (code 17 len 13) [hci0] 17.811580
01 00 00 00 01 00 05 00 00 d0 0a 00 00 .............
* Unknown packet (code 17 len 10) [hci0] 17.811596
02 00 00 00 06 00 d0 0a 00 00 ..........
= Close Index: 00:00:46:76:22:01 [hci0] 17.811625
^ 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