* [PATCH V8 0/4] phy: USB and PCIe phy drivers for Qcom chipsets
From: Vivek Gautam @ 2017-04-06 5:51 UTC (permalink / raw)
To: kishon, robh+dt
Cc: linux-arm-kernel, linux-arm-msm, linux-kernel, linux-usb,
devicetree, mark.rutland, sboyd, bjorn.andersson,
srinivas.kandagatla, Vivek Gautam
Hi Kishon,
Here's the series with fixed checkpatch warnings/checks.
Please pick it for phy/next.
This patch series adds couple of PHY drivers for Qualcomm chipsets.
a) qcom-qusb2 phy driver: that provides High Speed USB functionality.
b) qcom-qmp phy driver: that is a combo phy providing support for
USB3, PCIe, UFS and few other controllers.
The patches are based on next branch of linux-phy tree.
These patches have been tested on Dragon board db820c hardware with
required set of dt patches.
The tested branch[3] is based on torvald's master with greg's usb/usb-next
merged. Additionally the patches to get rpm up on msm8996 are also pulled
in.
Changes since v7:
- Fixed 'checkpatch --strict' alignment warnings/checks, and
added Stephen's Reviewed-by tag.
Changes since v6:
- Rebased on phy/next and *not* including phy grouping series[4].
- qusb2-phy: addressed Stephen's comment.
- Dropped pm8994_s2 corner regulator from QUSB2 phy bindings.
- qmp-phy: none on functionality side.
Changes since v5:
- Addressed review comments from Bjorn:
- Removed instances of readl/wirtel_relaxed calls from the drivers.
Instead, using simple readl/writel. Inserting a readl after a writel
to ensure the write is through to the device.
- Replaced regulator handling with regulator_bulk_** apis. This helps
in cutting down a lot of regulator handling code.
- Fixed minor return statements.
Changes since v4:
- Addressed comment to add child nodes for qmp phy driver. Each phy lane
now has a separate child node under the main qmp node.
- Modified the clock and reset initialization and enable methods.
Different phys - pcie, usb and later ufs, have varying number of clocks
and resets that are mandatory. So adding provision for clocks and reset
lists helps in requesting all mandatory resources for individual phys
and handle their failure cases accordingly.
Changes since v3:
- Addressed review comments given by Rob and Stephen for qusb2 phy
and qmp phy bindings respectively.
- Addressed review comments given by Stephen and Bjorn for qmp phy driver.
Changes since v2:
- Addressed review comments given by Rob and Stephen for bindings.
- Addressed the review comments given by Stephen for the qusb2 and qmp
phy drivers.
Changes since v1:
- Moved device tree binding documentation to separate patches, as suggested
by Rob.
- Addressed review comment regarding qfprom accesses by qusb2 phy driver,
given by Rob.
- Addressed review comments from Kishon.
- Addressed review comments from Srinivas for QMP phy driver.
- Addressed kbuild warning.
Please see individual patches for detailed changelogs.
[1] https://patchwork.kernel.org/patch/9567767/
[2] https://patchwork.kernel.org/patch/9567779/
[3] https://github.com/vivekgautam1/linux/tree/linux-v4.11-rc5-qmp-phy-db820c
[4] https://lkml.org/lkml/2017/3/20/407
Vivek Gautam (4):
dt-bindings: phy: Add support for QUSB2 phy
phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips
dt-bindings: phy: Add support for QMP phy
phy: qcom-qmp: new qmp phy driver for qcom-chipsets
.../devicetree/bindings/phy/qcom-qmp-phy.txt | 106 ++
.../devicetree/bindings/phy/qcom-qusb2-phy.txt | 43 +
drivers/phy/Kconfig | 18 +
drivers/phy/Makefile | 2 +
drivers/phy/phy-qcom-qmp.c | 1153 ++++++++++++++++++++
drivers/phy/phy-qcom-qusb2.c | 493 +++++++++
6 files changed, 1815 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
create mode 100644 Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt
create mode 100644 drivers/phy/phy-qcom-qmp.c
create mode 100644 drivers/phy/phy-qcom-qusb2.c
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH net-next] macb: Add hardware PTP support.
From: Richard Cochran @ 2017-04-06 5:24 UTC (permalink / raw)
To: David Miller
Cc: rafalo-vna1KIf7WgpBDgjK7y7TUQ,
nicolas.ferre-AIFe0yeh4nAAvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
harinikatakamlinux-Re5JQEeQqe8AvxtiuMwx3w,
harini.katakam-gjFFaj9aHVfQT0dZR+AlfA,
Andrei.Pistirica-UWL1GkI3JZL3oGB3hsPCZA
In-Reply-To: <20170405.064303.211440601700403108.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
On Wed, Apr 05, 2017 at 06:43:03AM -0700, David Miller wrote:
> This patch does too many things at one time. Each entry in that list
> of changes above should be a separate change, all posted together as
> a group as a proper patch series.
And please start a new thread with the next posting.
Thanks,
Richard
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v6 01/23] PCI: endpoint: Add EP core layer to enable EP controller and EP functions
From: Kishon Vijay Abraham I @ 2017-04-06 5:19 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Bjorn Helgaas, Joao Pinto, linux-pci-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
hch-wEGCiKHe2LqWVfeAwA7xHQ, nsekhar-l0cyMroinI0
In-Reply-To: <20170405165254.GA17066-1RhO1Y9PlrlHTL0Zs8A6p5iNqAH0jzoTYJqu5kTmcBRl57MIdRCFDg@public.gmane.org>
Hi Bjorn,
On Wednesday 05 April 2017 10:22 PM, Bjorn Helgaas wrote:
> On Wed, Apr 05, 2017 at 02:22:21PM +0530, Kishon Vijay Abraham I wrote:
>> Introduce a new EP core layer in order to support endpoint functions in
>> linux kernel. This comprises the EPC library (Endpoint Controller Library)
>> and EPF library (Endpoint Function Library). EPC library implements
>> functions specific to an endpoint controller and EPF library implements
>> functions specific to an endpoint function.
>> ...
>
>> +/**
>> + * pci_epf_linkup() - Notify the function driver that EPC device has
>> + * established a connection with the Root Complex.
>> + * @epf: the EPF device bound to the EPC device which has established
>> + * the connection with the host
>> + *
>> + * Invoke to notify the function driver that EPC device has established
>> + * a connection with the Root Complex.
>> + */
>> +void pci_epf_linkup(struct pci_epf *epf)
>> +{
>> + if (!epf->driver)
>> + dev_WARN(&epf->dev, "epf device not bound to driver\n");
>> +
>> + epf->driver->ops->linkup(epf);
>
> I don't understand what's going on here. We warn if epf->driver is
> NULL, but the next thing we do is dereference it.
>
> For NULL pointers that are symptoms of Linux defects, I usually prefer
> not to check at all so that a dereference generates an oops and we can
> debug the problem. For NULL pointers caused by user error, we would
> generally return an error that percolates up to the user.
>
> I haven't competely wrapped my head around this endpoint support, but
> I assume a NULL pointer here would be caused by user error, not
> necessarily a Linux defect. So why would we dereference a NULL
> pointer? And what happens when we do? Is this just going to oops an
> embedded Linux running inside the endpoint? Is that the correct
> behavior?
With the new configfs directory structure, this should be a kernel error.
However the EPF layer should be independent of how it's API's are used i.e
someone can create a new sysfs/configfs structure and the value of epf->driver
might be dependent on user actions.
I think I'd prefer not to dereference NULL pointers since we anyways have a
dev_WARN for debug. I'll resend this patch with return if epf->driver is NULL.
Thanks
Kishon
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v5 3/5] drm/exynos: dsi: Fix the parse_dt function
From: Inki Dae @ 2017-04-06 4:33 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: mark.rutland, devicetree, linux-samsung-soc, Andi Shyti,
catalin.marinas, Seung Woo Kim, linux-kernel, robh+dt,
Javier Martinez Canillas, kgene, dri-devel, Sylwester Nawrocki,
will.deacon, Marek Szyprowski, Hoegeun Kwon, linux-arm-kernel, LW
In-Reply-To: <CAJKOXPd-h4QqLXJ5AYr1KgpjvROaWpVZnd9KmeeGoVRQifssbw@mail.gmail.com>
2017년 04월 05일 00:38에 Krzysztof Kozlowski 이(가) 쓴 글:
> On Tue, Mar 28, 2017 at 11:38 AM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>> On Tue, Mar 28, 2017 at 11:26 AM, Inki Dae <inki.dae@samsung.com> wrote:
>>> Merged.
>>
>> Hi,
>>
>> I do not see the tag (with DT patches) merged by you which I provided
>> to you before. These are essential for bisectability. Without them,
>> kernel bisectability is broken. Did you merged the tag somewhere?
>>
>> Best regards,
>> Krzysztof
>>
>>> Thanks,
>>> Inki Dae
>
> Inki,
>
> I still do not see the DTS tag [1] merged in your tree but you applied
> patches breaking the display. I looked at exynos-drm-next branch.
>
> We talked already about bisectability and with Hoegeun we provided
> proper solution. Hoegeun split the patchset and I sent you a stable
> tag to merge. Be aware not to apply the DTS patch because you would
> effectively duplicate it. Instead, deal like with any pull request -
> merge the tag as dependency *before* applying DRM DSI patch.
Krzysztof,
I think merging the DTS tag is not necessary because dt and drm patches will go to -next separately.
Anyway, confirmed your email just now. Seems better so did what you want.
Thanks,
Inki Dae
>
> I saw also a branch like this:
> https://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git/log/?h=exynos-drm-next-tm2
> but this is something obviously wrong. I do not know what are your
> plans to do with it, but please drop it as it brings only confusion.
>
> Best regards,
> Krzysztof
>
> [1] https://www.spinics.net/lists/arm-kernel/msg567053.html
>
>>> 2017년 03월 22일 10:36에 Hoegeun Kwon 이(가) 쓴 글:
>>>> Hi inki,
>>>>
>>>> Could you check the this patch?
>>>> For reference, patch 1/5 and 2/5 have already been applied to Krzysztof tree.
>>>>
>>>> Best regards,
>>>> Hoegeun
>>>>
> --
> 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
>
>
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH 2/3] of/fdt: introduce of_scan_flat_dt_subnodes and of_get_flat_dt_phandle
From: Nicholas Piggin @ 2017-04-06 0:38 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Rob Herring, Michael Ellerman,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linuxppc-dev,
Frank Rowand
In-Reply-To: <1491425881.4166.90.camel-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
On Thu, 06 Apr 2017 06:58:01 +1000
Benjamin Herrenschmidt <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org> wrote:
> On Wed, 2017-04-05 at 10:58 -0500, Rob Herring wrote:
> > Well, I'd like to avoid expanding usage of flat DT parsing in the
> > kernel. But you could just put this function into arch/powerpc and I'd
> > never see it, but I like that even less. Mainly, I just wanted to
> > raise the point.
> >
> > Your argument works until you need that setup in assembly code, then
> > you are in the situation that you need to either handle the setup in
> > bootloader/firmware or have an simple way to determine that condition.
>
> The main issue is that changing that is a very very invasive change in
> an extremely fragile and rather nasty area of code shared by 32 and 64-
> bit for which we don't even have easy access to all the machines to
> test with anymore :)
>
> It's probably not impossible, but it would delay the new cpu feature
> stuff that Nick is making by a lot, probably monthes, making it nearly
> impossible to get back into distros etc...
>
> So while it might be something to consider, I would definitely keep
> that as a separate unit of work to do later.
Yeah, it's no longer a "drop in" replacement for existing features
testing if we do this, which makes it hard to backport too (we will
need this for compatibility with future firmware, so it will have to
go into distro kernels.)
Given that it's quite a small addition to of/fdt code, hopefully
that gives you a reasonable justification to accept it.
If you prefer not to, that's okay, but I think we would have to carry
it in arch/powerpc at least for a time, because of the schedule we're
working to for POWER9 enablement. As a longer term item I agree with you
and Ben, it would be worth considering unflattening earlier.
Thanks,
Nick
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH V7 4/4] phy: qcom-qmp: new qmp phy driver for qcom-chipsets
From: Stephen Boyd @ 2017-04-05 22:51 UTC (permalink / raw)
To: Vivek Gautam
Cc: kishon, robh+dt, linux-arm-kernel, linux-arm-msm, linux-kernel,
linux-usb, devicetree, mark.rutland, bjorn.andersson,
srinivas.kandagatla
In-Reply-To: <1491395558-16902-5-git-send-email-vivek.gautam@codeaurora.org>
On 04/05, Vivek Gautam wrote:
> Qualcomm SOCs have QMP phy controller that provides support
> to a number of controller, viz. PCIe, UFS, and USB.
> Add a new driver, based on generic phy framework, for this
> phy controller.
>
> Signed-off-by: Vivek Gautam <vivek.gautam@codeaurora.org>
> Tested-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> ---
Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH V7 3/4] dt-bindings: phy: Add support for QMP phy
From: Stephen Boyd @ 2017-04-05 22:50 UTC (permalink / raw)
To: Vivek Gautam
Cc: kishon-l0cyMroinI0, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, mark.rutland-5wv7dgnIgG8,
bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A,
srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A
In-Reply-To: <1491395558-16902-4-git-send-email-vivek.gautam-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
On 04/05, Vivek Gautam wrote:
> Qualcomm chipsets have QMP phy controller that provides
> support to a number of controller, viz. PCIe, UFS, and USB.
> Adding dt binding information for the same.
>
> Signed-off-by: Vivek Gautam <vivek.gautam-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> ---
Reviewed-by: Stephen Boyd <sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH V7 1/4] dt-bindings: phy: Add support for QUSB2 phy
From: Stephen Boyd @ 2017-04-05 22:48 UTC (permalink / raw)
To: Vivek Gautam
Cc: kishon, robh+dt, linux-arm-kernel, linux-arm-msm, linux-kernel,
linux-usb, devicetree, mark.rutland, bjorn.andersson,
srinivas.kandagatla
In-Reply-To: <1491395558-16902-2-git-send-email-vivek.gautam@codeaurora.org>
On 04/05, Vivek Gautam wrote:
> Qualcomm chipsets have QUSB2 phy controller that provides
> HighSpeed functionality for DWC3 controller.
> Adding dt binding information for the same.
>
> Signed-off-by: Vivek Gautam <vivek.gautam@codeaurora.org>
> Acked-by: Rob Herring <robh@kernel.org>
> ---
Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH] clk: stm32h7: Add stm32h743 clock driver
From: Stephen Boyd @ 2017-04-05 22:32 UTC (permalink / raw)
To: gabriel.fernandez-qxv4g6HH51o
Cc: Rob Herring, Mark Rutland, Russell King, Maxime Coquelin,
Alexandre Torgue, Michael Turquette, Nicolas Pitre, Arnd Bergmann,
daniel.thompson-QSEj5FYQhm4dnm+yROfE0A,
andrea.merello-Re5JQEeQqe8AvxtiuMwx3w,
radoslaw.pietrzyk-Re5JQEeQqe8AvxtiuMwx3w, Lee Jones,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA, ludovic.barre-qxv4g6HH51o,
olivier.bideau-qxv4g6HH51o, amelie.delaunay-qxv4g6HH51o
In-Reply-To: <1489569810-24350-1-git-send-email-gabriel.fernandez-qxv4g6HH51o@public.gmane.org>
On 03/15, gabriel.fernandez-qxv4g6HH51o@public.gmane.org wrote:
> From: Gabriel Fernandez <gabriel.fernandez-qxv4g6HH51o@public.gmane.org>
>
> This patch enables clocks for STM32H743 boards.
Like what clocks exactly? All of them?
> diff --git a/Documentation/devicetree/bindings/clock/st,stm32h7-rcc.txt b/Documentation/devicetree/bindings/clock/st,stm32h7-rcc.txt
> new file mode 100644
> index 0000000..9d4b587
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/st,stm32h7-rcc.txt
> @@ -0,0 +1,152 @@
> +STMicroelectronics STM32H7 Reset and Clock Controller
> +=====================================================
> +
> +The RCC IP is both a reset and a clock controller.
> +
> +Please refer to clock-bindings.txt for common clock controller binding usage.
> +Please also refer to reset.txt for common reset controller binding usage.
> +
> +Required properties:
> +- compatible: Should be:
> + "st,stm32h743-rcc"
> +
> +- reg: should be register base and length as documented in the
> + datasheet
> +
> +- #reset-cells: 1, see below
> +
> +- #clock-cells : from common clock binding; shall be set to 1
> +
> +- clocks: External oscillator clock phandle
> + - high speed external clock signal (HSE)
> + - low speed external clock signal (LSE)
> + - external I2S clock (I2S_CKIN)
> +
> +- st,syscfg: phandle for pwrcfg, mandatory to disable/enable backup domain
> + write protection (RTC clock).
> +
> +- pll x node: Allow to register a pll with specific parameters.
> + Please see PLL section below.
> +
> +Example:
> +
> + rcc: rcc@58024400 {
> + #reset-cells = <1>;
> + #clock-cells = <2>
> + compatible = "st,stm32h743-rcc", "st,stm32-rcc";
> + reg = <0x58024400 0x400>;
> + clocks = <&clk_hse>, <&clk_lse>, <&clk_i2s_ckin>;
> +
> + st,syscfg = <&pwrcfg>;
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + vco1@58024430 {
> + #clock-cells = <0>;
> + compatible = "stm32,pll";
> + reg = <0>;
reg is super confusing and doesn't match unit address.
> + };
Why? Shouldn't we know this from the compatible string how many
PLLs there are and where they're located? Export the PLLs through
rcc node's clock-cells?
> +
> + vco2@58024438 {
> + #clock-cells = <0>;
> + compatible = "stm32,pll";
> + reg = <1>;
reg is super confusing and doesn't match unit address.
> + st,clock-div = <2>;
> + st,clock-mult = <40>;
> + st,frac-status = <0>;
> + st,frac = <0>;
> + st,vcosel = <1>;
> + st,pllrge = <2>;
Does this stuff change on a per-board basis? I hope none of these
properties need to be in DT.
> + };
> + };
> +
> +
> +STM32H7 PLL
> +-----------
> +
[...]
> +
> +Specifying softreset control of devices
> +=======================================
> +
> +Device nodes should specify the reset channel required in their "resets"
> +property, containing a phandle to the reset device node and an index specifying
> +which channel to use.
> +The index is the bit number within the RCC registers bank, starting from RCC
> +base address.
> +It is calculated as: index = register_offset / 4 * 32 + bit_offset.
> +Where bit_offset is the bit offset within the register.
> +
> +For example, for CRC reset:
> + crc = AHB4RSTR_offset / 4 * 32 + CRCRST_bit_offset = 0x88 / 4 * 32 + 19 = 1107
> +
> +All available preprocessor macros for reset are defined dt-bindings//mfd/stm32h7-rcc.h
One too many slashes?
> +header and can be used in device tree sources.
> +
> +example:
> +
> + timer2 {
> + resets = <&rcc STM32H7_APB1L_RESET(TIM2)>;
> + };
> diff --git a/drivers/clk/clk-stm32h7.c b/drivers/clk/clk-stm32h7.c
> new file mode 100644
> index 0000000..c8eb729
> --- /dev/null
> +++ b/drivers/clk/clk-stm32h7.c
> @@ -0,0 +1,1586 @@
> +/*
> + * Copyright (C) Gabriel Fernandez 2017
> + * Author: Gabriel Fernandez <gabriel.fernandez-qxv4g6HH51o@public.gmane.org>
> + *
> + * License terms: GPL V2.0.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along with
> + * this program. If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#include <linux/clk.h>
Is this used?
> +#include <linux/clk-provider.h>
> +#include <linux/err.h>
> +#include <linux/io.h>
> +#include <linux/mfd/syscon.h>
> +#include <linux/of.h>
> +#include <linux/of_address.h>
> +#include <linux/slab.h>
> +#include <linux/spinlock.h>
> +#include <linux/regmap.h>
> +
> +#include <dt-bindings/clock/stm32h7-clks.h>
> +
> +/* Reset Clock Control Registers */
> +#define RCC_CR 0x00
> +#define RCC_CFGR 0x10
> +#define RCC_D1CFGR 0x18
> +#define RCC_D2CFGR 0x1C
> +#define RCC_D3CFGR 0x20
> +#define RCC_PLLCKSELR 0x28
> +#define RCC_PLLCFGR 0x2C
> +#define RCC_PLL1DIVR 0x30
> +#define RCC_PLL1FRACR 0x34
> +#define RCC_PLL2DIVR 0x38
> +#define RCC_PLL2FRACR 0x3C
> +#define RCC_PLL3DIVR 0x40
> +#define RCC_PLL3FRACR 0x44
> +#define RCC_D1CCIPR 0x4C
> +#define RCC_D2CCIP1R 0x50
> +#define RCC_D2CCIP2R 0x54
> +#define RCC_D3CCIPR 0x58
> +#define RCC_BDCR 0x70
> +#define RCC_CSR 0x74
> +#define RCC_AHB3ENR 0xD4
> +#define RCC_AHB1ENR 0xD8
> +#define RCC_AHB2ENR 0xDC
> +#define RCC_AHB4ENR 0xE0
> +#define RCC_APB3ENR 0xE4
> +#define RCC_APB1LENR 0xE8
> +#define RCC_APB1HENR 0xEC
> +#define RCC_APB2ENR 0xF0
> +#define RCC_APB4ENR 0xF4
> +
> +static DEFINE_SPINLOCK(rlock);
This is super generic and will make lockdep debugging sad.
Perhaps stm32rcc_lock?
> +
> +static void __iomem *base;
> +static struct regmap *pdrm;
> +static struct clk_hw **hws;
> +
> +/* System clock parent */
> +static const char * const sys_src[] = {
> + "hsi_ck", "csi_ck", "hse_ck", "pll1_p" };
> +
> +static const char * const tracein_src[] = {
> + "hsi_ck", "csi_ck", "hse_ck", "pll1_r" };
[...]
> +
> +static unsigned long pll_fd_recalc_rate(struct clk_hw *hw,
> + unsigned long parent_rate)
> +{
> + struct stm32_pll_obj *clk_elem = to_pll(hw);
> + struct stm32_fractional_divider *fd = &clk_elem->div;
> + unsigned long m, n;
> + u32 val, mask;
> + u64 rate, rate1 = 0;
> +
> + val = clk_readl(fd->mreg);
Please don't use clk_readl() unless you need it for some reason.
> + mask = (GENMASK(fd->mwidth - 1, 0) << fd->mshift);
> + m = (val & mask) >> fd->mshift;
> +
> + val = clk_readl(fd->nreg);
> + mask = (GENMASK(fd->nwidth - 1, 0) << fd->nshift);
Useless parentheses. And isn't GENMASK supposed to take the
actual bit positions? Then we avoid overflow issues?
> + n = ((val & mask) >> fd->nshift) + 1;
> +
> + if (!n || !m)
> + return parent_rate;
> +
> + rate = (u64)parent_rate * n;
> + do_div(rate, m);
> +
> + if (pll_frac_is_enabled(hw)) {
> + val = pll_read_frac(hw);
> + rate1 = (u64) parent_rate * (u64) val;
> + do_div(rate1, (m * 8191));
> + }
> +
> + return rate + rate1;
> +}
> +
[...]
> +
> + /* Micro-controller clocks */
> + for (n = 0; n < ARRAY_SIZE(mco_clk); n++) {
> + get_cfg_composite_div(&mco_clk_cfg, &mco_clk[n], &c_cfg,
> + &rlock);
> +
> + hws[MCO_BANK + n] = clk_hw_register_composite(NULL,
> + mco_clk[n].name,
> + mco_clk[n].parent_name,
> + mco_clk[n].num_parents,
> + c_cfg.mux_hw, c_cfg.mux_ops,
> + c_cfg.div_hw, c_cfg.div_ops,
> + c_cfg.gate_hw, c_cfg.gate_ops,
> + mco_clk[n].flags);
> + }
> +
> + of_clk_add_hw_provider(np, of_clk_hw_onecell_get, clk_data);
> +
> + return;
> +
> +err_free_clks:
> + kfree(clk_data);
> +}
> +CLK_OF_DECLARE_DRIVER(stm32h7_rcc, "st,stm32h743-rcc", stm32h7_rcc_init);
Is there another driver that uses the same register space?
Nothing showing up in -next right now. Perhaps a comment should
be added to indicate the other driver.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/3] clk: qcom: Elaborate on "active" clocks in the RPM clock bindings
From: Stephen Boyd @ 2017-04-05 22:02 UTC (permalink / raw)
To: Linus Walleij
Cc: Rob Herring, Michael Turquette, linux-clk,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <CACRpkdYAT6Pw=9SjFgkQCaVN8EpSNdP61mkQSjV0FOfgQ0fZhw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 03/29, Linus Walleij wrote:
> On Wed, Mar 29, 2017 at 2:59 AM, Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> > On Wed, Mar 22, 2017 at 09:18:42AM +0100, Linus Walleij wrote:
> >> The concept of "active" clocks is just explained in a bried comment in the
> >> device driver, let's explain it a bit more in the device tree bindings
> >> so everyone understands this.
> >>
> >> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> >> Signed-off-by: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> >> ---
> >> Documentation/devicetree/bindings/clock/qcom,rpmcc.txt | 8 ++++++++
> >> 1 file changed, 8 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt b/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt
> >> index d470a0187035..cf80a00b7ff2 100644
> >> --- a/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt
> >> +++ b/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt
> >> @@ -18,6 +18,14 @@ Required properties :
> >>
> >> - #clock-cells : shall contain 1
> >>
> >> +The clock enumerators are defined in <dt-bindings/clock/qcom,rpmcc.h>
> >> +and come in pairs: FOO_CLK followed by FOO_A_CLK. The latter clock
> >> +is an "active" clock, which means that the consumer only care that the
> >> +clock is available when the system is active, i.e. not suspended. If
I would further say that "is available when the apps CPU
subsystem is active", i.e. not suspended or in deep idle. Really
it's about optimizing the idle path so we don't have to keep
things on for the CPU when it powers down. The system suspend
case can usually be handled by regular clk API calls.
> >> +it is important that the clock keeps running during system suspend,
> >> +you need to specify the non-active clock, the one not containing
> >> +*_A_* in the enumerator name.
> >> +
> >
> > Sounds like abuse as the clock id is encoding policy into it. The number
> > of clocks should be the number of inputs to a block. I wouldn't be
> > opposed to some flags for clocks, but that should be a separate cell.
>
> I'm sorry about that, but I'm just documenting what is already a fact and
> was previously just implicit in the name.
>
> I first had no idea what this *_A_* infix notation was about so after some
> reading I found a comment in the driver saying this.
>
> I guess Stephen can confirm and/or elaborate on this.
>
> Keeping them around is I guess the lesser evil (as compard to
> pulling up the deployed bindings with the roots) at this point.
>
Yes we can't really do much now that we've put the binding out
there. I guess we could have two cells and then fold that into a
custom clk_hw getter function to map the two cells to the right
clk. And then leave the original code around for backwards compat
and detect which one to register as the clk_hw provider.
Either way, that wouldn't change the consumer binding because if
they want to control the *_A_* and non *_A_* clks as individual
controls they'll list the same physical clk twice in their
'clocks' property.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/3] of/fdt: introduce of_scan_flat_dt_subnodes and of_get_flat_dt_phandle
From: Benjamin Herrenschmidt @ 2017-04-05 20:58 UTC (permalink / raw)
To: Rob Herring, Nicholas Piggin
Cc: Michael Ellerman,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linuxppc-dev,
Frank Rowand
In-Reply-To: <CAL_JsqLEvjb8S-+-JEa4ALHeCWHiR1A_4ur9kd3pBRJaFYWVKw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Wed, 2017-04-05 at 10:58 -0500, Rob Herring wrote:
> Well, I'd like to avoid expanding usage of flat DT parsing in the
> kernel. But you could just put this function into arch/powerpc and I'd
> never see it, but I like that even less. Mainly, I just wanted to
> raise the point.
>
> Your argument works until you need that setup in assembly code, then
> you are in the situation that you need to either handle the setup in
> bootloader/firmware or have an simple way to determine that condition.
The main issue is that changing that is a very very invasive change in
an extremely fragile and rather nasty area of code shared by 32 and 64-
bit for which we don't even have easy access to all the machines to
test with anymore :)
It's probably not impossible, but it would delay the new cpu feature
stuff that Nick is making by a lot, probably monthes, making it nearly
impossible to get back into distros etc...
So while it might be something to consider, I would definitely keep
that as a separate unit of work to do later.
Cheers,
Ben.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCHv3 00/10] Nokia H4+ support
From: Pavel Machek @ 2017-04-05 20:28 UTC (permalink / raw)
To: Rob Herring
Cc: Greg Kroah-Hartman, Marcel Holtmann, Sebastian Reichel,
Gustavo F. Padovan, Johan Hedberg, Samuel Thibault, Tony Lindgren,
Jiri Slaby, Mark Rutland, open list:BLUETOOTH DRIVERS,
linux-serial-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
David S. Miller
In-Reply-To: <CAL_Jsq+NU3M5yuBpK1UGgzCVvq0eABMApCqEe3_d5+tDaABsgQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1764 bytes --]
On Wed 2017-04-05 13:16:58, Rob Herring wrote:
> On Fri, Mar 31, 2017 at 8:33 AM, Greg Kroah-Hartman
> <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org> wrote:
> > On Wed, Mar 29, 2017 at 11:33:26PM +0200, Marcel Holtmann wrote:
> >> Hi Rob,
> >>
> >> >> Here is PATCHv3 for the Nokia bluetooth patchset. I addressed all comments from
> >> >> Rob and Pavel regarding the serdev patches and dropped the *.dts patches, since
> >> >> they were queued by Tony. I also changed the patch order, so that the serdev
> >> >> patches come first. All of them have Acked-by from Rob, so I think it makes
> >> >> sense to merge them to serdev subsystem (now) and provide an immutable branch
> >> >> for the bluetooth subsystem.
> >> >
> >> > Greg doesn't read cover letters generally and since the serdev patches
> >> > are Cc rather than To him, he's probably not planning to pick them up.
> >>
> >> I wonder actually if we should merge all of these via bluetooth-next
> >> tree with proper Ack from Greg. However it would be good to also get
> >> buy in from Dave for merging this ultimately through net-next.
> >
> > I don't really care where it goes. I can take the whole thing in my
> > tty/serial tree now if no one objects and I get an ack from the relevant
> > maintainers {hint...}
>
> I think it is better if it goes thru BT tree. I have another driver
> converted that is dependent on this series. There's a couple other
> serdev changes on the list too, but this shouldn't depend on them.
I believe BT tree makes sense. Still it would be nice to get Greg's
ACK ...?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH 2/3] dt-bindings: arm: amlogic: Add SoC information bindings
From: Rob Herring @ 2017-04-05 19:11 UTC (permalink / raw)
To: Neil Armstrong
Cc: Arnd Bergmann, Kevin Hilman, Carlo Caione, linux-amlogic,
Linux ARM, Linux Kernel Mailing List, devicetree@vger.kernel.org
In-Reply-To: <d263ba90-2352-5253-9704-050afcc37761@baylibre.com>
On Tue, Apr 4, 2017 at 7:49 AM, Neil Armstrong <narmstrong@baylibre.com> wrote:
> On 04/04/2017 02:26 PM, Rob Herring wrote:
>> On Tue, Apr 4, 2017 at 3:51 AM, Neil Armstrong <narmstrong@baylibre.com> wrote:
>>> On 04/03/2017 06:34 PM, Rob Herring wrote:
>>>> On Fri, Mar 31, 2017 at 04:10:30PM +0200, Neil Armstrong wrote:
>>>>> On 03/31/2017 03:44 PM, Arnd Bergmann wrote:
>>>>>> On Fri, Mar 31, 2017 at 10:47 AM, Neil Armstrong
>>>>>> <narmstrong@baylibre.com> wrote:
>>>>>>> Add bindings for the SoC information register of the Amlogic SoCs.
>>>>>>>
>>>>>>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>>>>>>> ---
>>>>>>> Documentation/devicetree/bindings/arm/amlogic.txt | 20 ++++++++++++++++++++
>>>>>>> 1 file changed, 20 insertions(+)
>>>>>>>
>>>>>>> diff --git a/Documentation/devicetree/bindings/arm/amlogic.txt b/Documentation/devicetree/bindings/arm/amlogic.txt
>>>>>>> index bfd5b55..b850985 100644
>>>>>>> --- a/Documentation/devicetree/bindings/arm/amlogic.txt
>>>>>>> +++ b/Documentation/devicetree/bindings/arm/amlogic.txt
>>>>>>> @@ -52,3 +52,23 @@ Board compatible values:
>>>>>>> - "amlogic,q201" (Meson gxm s912)
>>>>>>> - "nexbox,a95x" (Meson gxbb or Meson gxl s905x)
>>>>>>> - "nexbox,a1" (Meson gxm s912)
>>>>>>> +
>>>>>>> +Amlogic Meson GX SoCs Information
>>>>>>> +----------------------------------
>>>>>>> +
>>>>>>> +The Meson SoCs have a Product Register that allows to retrieve SoC type,
>>>>>>> +package and revision information. If present, a device node for this register
>>>>>>> +should be added.
>>>>>>> +
>>>>>>> +Required properties:
>>>>>>> + - compatible: For Meson GX SoCs, must be "amlogic,meson-gx-socinfo".
>>>>>>> + - reg: Base address and length of the register block.
>>>>>>> +
>>>>>>> +Examples
>>>>>>> +--------
>>>>>>> +
>>>>>>> + chipid@220 {
>>>>>>> + compatible = "amlogic,meson-gx-socinfo";
>>>>>>> + reg = <0x0 0x00220 0x0 0x4>;
>>>>>>> + };
>>>>>>> +
>>>>>>
>>>>>> The register location would hint that this is in the middle of some block of
>>>>>> random registers, i.e. a syscon or some unrelated device.
>>>>>>
>>>>>> Are you sure that "socinfo" is the actual name of the IP block and that
>>>>>> it only has a single 32-bit register?
>>>>>>
>>>>>> Arnd
>>>>>>
>>>>>
>>>>> Hi Arnd,
>>>>>
>>>>> I'm sorry I did not find any relevant registers in the docs or source code describing
>>>>> it in a specific block of registers, and no close enough register definitions either.
>>>>> They may be used by the secure firmware I imagine.
>>>>>
>>>>> For the register name, Amlogic refers it to "cpu_version" in their code, but it really
>>>>> gives some details on the whole SoC and package, and socinfo seems better.
>>>>
>>>> A register at address 0x220 seems a bit strange (unless there's ranges
>>>> you're not showing), but ROM code at this address would be fairly
>>>> typical. And putting version information into the ROM is also common.
>>>>
>>>> Rob
>>>>
>>>
>>> Hi Rob.
>>>
>>> Indeed it's part of a larger range :
>>> aobus: aobus@c8100000 {
>>> compatible = "simple-bus";
>>> reg = <0x0 0xc8100000 0x0 0x100000>;
>>> #address-cells = <2>;
>>> #size-cells = <2>;
>>> ranges = <0x0 0x0 0x0 0xc8100000 0x0 0x100000>;
>>>
>>>
>>> While scrubbing on the uboot source, I found a sort of block of registers dedicated to communicate with
>>> the secure firmware :
>>> AO_SEC_REG0 0x140
>>> AO_SEC_REG1 0x144
>>> AO_SEC_REG2 0x148
>>> AO_SEC_TMODE_PWD0 0x160
>>> AO_SEC_TMODE_PWD1 0x164
>>> AO_SEC_TMODE_PWD2 0x168
>>> AO_SEC_TMODE_PWD3 0x16C
>>> AO_SEC_SCRATCH 0x17C
>>> AO_SEC_JTAG_PWD0 0x180
>>> AO_SEC_JTAG_PWD1 0x184
>>> AO_SEC_JTAG_PWD2 0x188
>>> AO_SEC_JTAG_PWD3 0x18C
>>> AO_SEC_JTAG_SEC_CNTL 0x190
>>> AO_SEC_JTAG_PWD_ADDR0 0x194
>>> AO_SEC_JTAG_PWD_ADDR1 0x198
>>> AO_SEC_JTAG_PWD_ADDR2 0x19C
>>> AO_SEC_JTAG_PWD_ADDR3 0x1A0
>>> AO_SEC_SHARED_AHB_SRAM_REG0_0 0x1C0
>>> AO_SEC_SHARED_AHB_SRAM_REG0_1 0x1C4
>>> AO_SEC_SHARED_AHB_SRAM_REG0_2 0x1C8
>>> AO_SEC_SHARED_AHB_SRAM_REG1_0 0x1CC
>>> AO_SEC_SHARED_AHB_SRAM_REG1_1 0x1D0
>>> AO_SEC_SHARED_AHB_SRAM_REG1_2 0x1D4
>>> AO_SEC_SHARED_AHB_SRAM_REG2_0 0x1D8
>>> AO_SEC_SHARED_AHB_SRAM_REG2_1 0x1DC
>>> AO_SEC_SHARED_AHB_SRAM_REG2_2 0x1E0
>>> AO_SEC_SHARED_AHB_SRAM_REG3_0 0x1E4
>>> AO_SEC_SHARED_AHB_SRAM_REG3_1 0x1E8
>>> AO_SEC_SHARED_AHB_SRAM_REG3_2 0x1EC
>>> AO_SEC_AO_AHB_SRAM_REG0_0 0x1F0
>>> AO_SEC_AO_AHB_SRAM_REG0_1 0x1F4
>>> AO_SEC_AO_AHB_SRAM_REG1_0 0x1F8
>>> AO_SEC_AO_AHB_SRAM_REG1_1 0x1FC
>>> AO_SEC_SD_CFG8 0x220
>>> AO_SEC_SD_CFG9 0x224
>>> AO_SEC_SD_CFG10 0x228
>>> AO_SEC_SD_CFG11 0x22C
>>> AO_SEC_SD_CFG12 0x230
>>> AO_SEC_SD_CFG13 0x234
>>> AO_SEC_SD_CFG14 0x238
>>> AO_SEC_SD_CFG15 0x23C
>>> AO_SEC_GP_CFG0 0x240
>>> AO_SEC_GP_CFG1 0x244
>>> AO_SEC_GP_CFG2 0x248
>>> AO_SEC_GP_CFG3 0x24C
>>> AO_SEC_GP_CFG4 0x250
>>> AO_SEC_GP_CFG5 0x254
>>> AO_SEC_GP_CFG6 0x258
>>> AO_SEC_GP_CFG7 0x25C
>>> AO_SEC_GP_CFG8 0x260
>>> AO_SEC_GP_CFG9 0x264
>>> AO_SEC_GP_CFG10 0x268
>>> AO_SEC_GP_CFG11 0x26C
>>> AO_SEC_GP_CFG12 0x270
>>> AO_SEC_GP_CFG13 0x274
>>> AO_SEC_GP_CFG14 0x278
>>> AO_SEC_GP_CFG15 0x27C
>>>
>>>
>>> As you see, the register we use here is AO_SEC_SD_CFG8...
>>>
>>> Should I define all this block as simple-mfd and refer to it as a regmap ?
>>>
>>> aobus: aobus@c8100000 {
>>> compatible = "simple-bus";
>>> reg = <0x0 0xc8100000 0x0 0x100000>;
>>> #address-cells = <2>;
>>> #size-cells = <2>;
>>> ranges = <0x0 0x0 0x0 0xc8100000 0x0 0x100000>;
>>>
>>> ao_secure: ao-secure@140 {
>>> compatible = "amlogic,meson-gx-ao-secure", "simple-mfd";
>>> reg = <0x0 0x140 0x0 0x140>;
>>> };
>>> };
>>>
>>> chipid {
>>> compatible = "amlogic,meson-gx-socinfo";
>>> ao-secure = <&ao_secure>;
>>> chip-info-reg = <0xe0>;
>>
>> Why even divide it up further in DT? IMO, describing single
>> registers/address in DT is too fine grained.
>>
>> Rob
>>
>
> Rob, I don't get it.
>
> Maybe something like that ?
>
> aobus: aobus@c8100000 {
> compatible = "simple-bus";
> reg = <0x0 0xc8100000 0x0 0x100000>;
> #address-cells = <2>;
> #size-cells = <2>;
> ranges = <0x0 0x0 0x0 0xc8100000 0x0 0x100000>;
>
> ao_secure: ao-secure@140 {
> compatible = "amlogic,meson-gx-ao-secure", "simple-mfd", "simple-bus";
> reg = <0x0 0x140 0x0 0x140>;
> #address-cells = <1>;
> #size-cells = <1>;
>
> chipid@e0 {
> compatible = "amlogic,meson-gx-socinfo";
> reg = <0xe0 0x4>;
> };
> };
> };
That's somewhat better, though your addressing is wrong.
>
> Concerning the fine graining, I'm sorry but the actual information comes from a single register here...
Yes, but the only useful information here is really "0xe0". I imagine
you also want "amlogic,meson-gx-socinfo" to instantiate a driver, but
that's not a reason to put a node into DT. You can just easily have
whatever handles "amlogic,meson-gx-ao-secure" provide the version
information out of register 0xe0.
Rob
^ permalink raw reply
* Re: [RFC PATCH v2 1/4] dt-bindings: update the Allwinner GPADC device tree binding for H3
From: Icenowy Zheng @ 2017-04-05 19:11 UTC (permalink / raw)
To: Rob Herring
Cc: Zhang Rui, linux-sunxi, linux-pm, linux-kernel, linux-iio,
devicetree, Quentin Schulz, Lee Jones, Maxime Ripard,
Jonathan Cameron, linux-arm-kernel, Chen-Yu Tsai
2017年4月6日 03:04于 Rob Herring <robh@kernel.org>写道：
>
> On Tue, Apr 4, 2017 at 10:02 AM, Icenowy Zheng <icenowy@aosc.io> wrote:
> >
> >
> > 在 2017年04月04日 22:47, Rob Herring 写道:
> >>
> >> On Sun, Apr 02, 2017 at 09:33:01PM +0800, Icenowy Zheng wrote:
> >>>
> >>> Allwinner H3 features a thermal sensor like the one in A33, but has its
> >>> register re-arranged, the clock divider moved to CCU (originally the
> >>> clock divider is in ADC) and added a pair of bus clock and reset.
> >>>
> >>> Update the binding document to cover H3.
> >>>
> >>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> >>> ---
> >>> .../devicetree/bindings/mfd/sun4i-gpadc.txt | 23
> >>> ++++++++++++++++++++--
> >>> 1 file changed, 21 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt
> >>> b/Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt
> >>> index badff3611a98..7753133ca0ff 100644
> >>> --- a/Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt
> >>> +++ b/Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt
> >>> @@ -4,12 +4,20 @@ The Allwinner SoCs all have an ADC that can also act as
> >>> a thermal sensor
> >>> and sometimes as a touchscreen controller.
> >>>
> >>> Required properties:
> >>> - - compatible: "allwinner,sun8i-a33-ths",
> >>> + - compatible: must contain one of the following compatibles:
> >>> + - "allwinner,sun8i-a33-ths"
> >>> + - "allwinner,sun8i-h3-ths"
> >>> - reg: mmio address range of the chip,
> >>> - #thermal-sensor-cells: shall be 0,
> >>> - #io-channel-cells: shall be 0,
> >>>
> >>> -Example:
> >>> +Required properties for the following compatibles:
> >>> + - "allwinner,sun8i-h3-ths"
> >>> + - clocks: the bus clock and the input clock of the ADC,
> >>> + - clock-names: should be "bus" and "ths",
> >>> + - resets: the bus reset of the ADC,
> >>> +
> >>> +Example for A33:
> >>> ths: ths@01c25000 {
> >>> compatible = "allwinner,sun8i-a33-ths";
> >>> reg = <0x01c25000 0x100>;
> >>> @@ -17,6 +25,17 @@ Example:
> >>> #io-channel-cells = <0>;
> >>> };
> >>>
> >>> +Example for H3:
> >>> + ths: ths@01c25000 {
> >>
> >>
> >> adc@...
> >
> >
> > It's a thermal sensor, so I think call it THS is more appropriate
> > here. It's implemented as an ADC driver just because the internal
> > code reusing of Linux. From device tree binding view I choose to
> > call it ths.
>
> There's numerous occurrences in this file and the filename that call it an ADC.
>
> Furthermore, node names are supposed to be generic, not part #'s or
> whatever you decide to make up. So pick from adc or temperature-sensor
> as those are the standard names .
OK. I will make it :
ths: temperature-sensor@1c25000
(Calling it temperature sensor is according to the datasheet name)
>
> Rob
^ permalink raw reply
* Re: [RFC PATCH v2 1/4] dt-bindings: update the Allwinner GPADC device tree binding for H3
From: Icenowy Zheng @ 2017-04-05 19:11 UTC (permalink / raw)
To: Rob Herring
Cc: Zhang Rui, linux-sunxi, linux-pm-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Quentin Schulz, Lee Jones,
Maxime Ripard, Jonathan Cameron,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Chen-Yu Tsai
2017年4月6日 03:04于 Rob Herring <robh@kernel.org>写道：
>
> On Tue, Apr 4, 2017 at 10:02 AM, Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org> wrote:
> >
> >
> > 在 2017年04月04日 22:47, Rob Herring 写道:
> >>
> >> On Sun, Apr 02, 2017 at 09:33:01PM +0800, Icenowy Zheng wrote:
> >>>
> >>> Allwinner H3 features a thermal sensor like the one in A33, but has its
> >>> register re-arranged, the clock divider moved to CCU (originally the
> >>> clock divider is in ADC) and added a pair of bus clock and reset.
> >>>
> >>> Update the binding document to cover H3.
> >>>
> >>> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
> >>> ---
> >>> .../devicetree/bindings/mfd/sun4i-gpadc.txt | 23
> >>> ++++++++++++++++++++--
> >>> 1 file changed, 21 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt
> >>> b/Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt
> >>> index badff3611a98..7753133ca0ff 100644
> >>> --- a/Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt
> >>> +++ b/Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt
> >>> @@ -4,12 +4,20 @@ The Allwinner SoCs all have an ADC that can also act as
> >>> a thermal sensor
> >>> and sometimes as a touchscreen controller.
> >>>
> >>> Required properties:
> >>> - - compatible: "allwinner,sun8i-a33-ths",
> >>> + - compatible: must contain one of the following compatibles:
> >>> + - "allwinner,sun8i-a33-ths"
> >>> + - "allwinner,sun8i-h3-ths"
> >>> - reg: mmio address range of the chip,
> >>> - #thermal-sensor-cells: shall be 0,
> >>> - #io-channel-cells: shall be 0,
> >>>
> >>> -Example:
> >>> +Required properties for the following compatibles:
> >>> + - "allwinner,sun8i-h3-ths"
> >>> + - clocks: the bus clock and the input clock of the ADC,
> >>> + - clock-names: should be "bus" and "ths",
> >>> + - resets: the bus reset of the ADC,
> >>> +
> >>> +Example for A33:
> >>> ths: ths@01c25000 {
> >>> compatible = "allwinner,sun8i-a33-ths";
> >>> reg = <0x01c25000 0x100>;
> >>> @@ -17,6 +25,17 @@ Example:
> >>> #io-channel-cells = <0>;
> >>> };
> >>>
> >>> +Example for H3:
> >>> + ths: ths@01c25000 {
> >>
> >>
> >> adc@...
> >
> >
> > It's a thermal sensor, so I think call it THS is more appropriate
> > here. It's implemented as an ADC driver just because the internal
> > code reusing of Linux. From device tree binding view I choose to
> > call it ths.
>
> There's numerous occurrences in this file and the filename that call it an ADC.
>
> Furthermore, node names are supposed to be generic, not part #'s or
> whatever you decide to make up. So pick from adc or temperature-sensor
> as those are the standard names .
OK. I will make it :
ths: temperature-sensor@1c25000
(Calling it temperature sensor is according to the datasheet name)
>
> Rob
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [RFC PATCH v2 1/4] dt-bindings: update the Allwinner GPADC device tree binding for H3
From: Rob Herring @ 2017-04-05 19:04 UTC (permalink / raw)
To: Icenowy Zheng
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-iio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Quentin Schulz, linux-sunxi, Jonathan Cameron, Maxime Ripard,
Chen-Yu Tsai, Lee Jones, Zhang Rui,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <bdc43a73-a2d6-01ae-8113-277f7174697c-h8G6r0blFSE@public.gmane.org>
On Tue, Apr 4, 2017 at 10:02 AM, Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org> wrote:
>
>
> 在 2017年04月04日 22:47, Rob Herring 写道:
>>
>> On Sun, Apr 02, 2017 at 09:33:01PM +0800, Icenowy Zheng wrote:
>>>
>>> Allwinner H3 features a thermal sensor like the one in A33, but has its
>>> register re-arranged, the clock divider moved to CCU (originally the
>>> clock divider is in ADC) and added a pair of bus clock and reset.
>>>
>>> Update the binding document to cover H3.
>>>
>>> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
>>> ---
>>> .../devicetree/bindings/mfd/sun4i-gpadc.txt | 23
>>> ++++++++++++++++++++--
>>> 1 file changed, 21 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt
>>> b/Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt
>>> index badff3611a98..7753133ca0ff 100644
>>> --- a/Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt
>>> +++ b/Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt
>>> @@ -4,12 +4,20 @@ The Allwinner SoCs all have an ADC that can also act as
>>> a thermal sensor
>>> and sometimes as a touchscreen controller.
>>>
>>> Required properties:
>>> - - compatible: "allwinner,sun8i-a33-ths",
>>> + - compatible: must contain one of the following compatibles:
>>> + - "allwinner,sun8i-a33-ths"
>>> + - "allwinner,sun8i-h3-ths"
>>> - reg: mmio address range of the chip,
>>> - #thermal-sensor-cells: shall be 0,
>>> - #io-channel-cells: shall be 0,
>>>
>>> -Example:
>>> +Required properties for the following compatibles:
>>> + - "allwinner,sun8i-h3-ths"
>>> + - clocks: the bus clock and the input clock of the ADC,
>>> + - clock-names: should be "bus" and "ths",
>>> + - resets: the bus reset of the ADC,
>>> +
>>> +Example for A33:
>>> ths: ths@01c25000 {
>>> compatible = "allwinner,sun8i-a33-ths";
>>> reg = <0x01c25000 0x100>;
>>> @@ -17,6 +25,17 @@ Example:
>>> #io-channel-cells = <0>;
>>> };
>>>
>>> +Example for H3:
>>> + ths: ths@01c25000 {
>>
>>
>> adc@...
>
>
> It's a thermal sensor, so I think call it THS is more appropriate
> here. It's implemented as an ADC driver just because the internal
> code reusing of Linux. From device tree binding view I choose to
> call it ths.
There's numerous occurrences in this file and the filename that call it an ADC.
Furthermore, node names are supposed to be generic, not part #'s or
whatever you decide to make up. So pick from adc or temperature-sensor
as those are the standard names .
Rob
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* [PATCH 4/4] arm64: dts: hikey: add WL1835 Bluetooth device node
From: Rob Herring @ 2017-04-05 18:30 UTC (permalink / raw)
To: Marcel Holtmann, linux-bluetooth-u79uwXL29TY76Z2rM5mHXA
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Gustavo Padovan, Johan Hedberg, Mark Rutland, Wei Xu, Eyal Reizer,
Satish Patel, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170405183005.20570-1-robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
This adds the serial slave device for the WL1835 Bluetooth interface.
Signed-off-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Wei Xu <xuwei5-C8/M+/jPZTeaMJb+Lgu22Q@public.gmane.org>
Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
---
arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
index dba3c131c62c..9b4ba7169210 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
+++ b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
@@ -98,6 +98,11 @@
assigned-clocks = <&sys_ctrl HI6220_UART1_SRC>;
assigned-clock-rates = <150000000>;
status = "ok";
+
+ bluetooth {
+ compatible = "ti,wl1835-st";
+ enable-gpios = <&gpio1 7 GPIO_ACTIVE_HIGH>;
+ };
};
uart2: uart@f7112000 {
--
2.10.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 3/4] bluetooth: hci_uart: add LL protocol serdev driver support
From: Rob Herring @ 2017-04-05 18:30 UTC (permalink / raw)
To: Marcel Holtmann, linux-bluetooth-u79uwXL29TY76Z2rM5mHXA
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Gustavo Padovan, Johan Hedberg, Mark Rutland, Wei Xu, Eyal Reizer,
Satish Patel, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170405183005.20570-1-robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Turns out that the LL protocol and the TI-ST are the same thing AFAICT.
The TI-ST adds firmware loading, GPIO control, and shared access for
NFC, FM radio, etc. For now, we're only implementing what is needed for
BT. This mirrors other drivers like BCM and Intel, but uses the new
serdev bus.
The firmware loading is greatly simplified by using existing
infrastructure to send commands. It may be a bit slower than the
original code using synchronous functions, but the real bottleneck is
likely doing firmware load at 115.2kbps.
Signed-off-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Marcel Holtmann <marcel-kz+m5ild9QBg9hUCZPvPmw@public.gmane.org>
Cc: Gustavo Padovan <gustavo-THi1TnShQwVAfugRpC6u6w@public.gmane.org>
Cc: Johan Hedberg <johan.hedberg-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: linux-bluetooth-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
---
drivers/bluetooth/hci_ll.c | 261 ++++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 260 insertions(+), 1 deletion(-)
diff --git a/drivers/bluetooth/hci_ll.c b/drivers/bluetooth/hci_ll.c
index 02692fe30279..9b2054f5502d 100644
--- a/drivers/bluetooth/hci_ll.c
+++ b/drivers/bluetooth/hci_ll.c
@@ -34,20 +34,23 @@
#include <linux/sched.h>
#include <linux/types.h>
#include <linux/fcntl.h>
+#include <linux/firmware.h>
#include <linux/interrupt.h>
#include <linux/ptrace.h>
#include <linux/poll.h>
#include <linux/slab.h>
-#include <linux/tty.h>
#include <linux/errno.h>
#include <linux/string.h>
#include <linux/signal.h>
#include <linux/ioctl.h>
+#include <linux/serdev.h>
#include <linux/skbuff.h>
+#include <linux/ti_wilink_st.h>
#include <net/bluetooth/bluetooth.h>
#include <net/bluetooth/hci_core.h>
+#include <linux/gpio/consumer.h>
#include "hci_uart.h"
@@ -76,6 +79,12 @@ struct hcill_cmd {
u8 cmd;
} __packed;
+struct ll_device {
+ struct hci_uart hu;
+ struct serdev_device *serdev;
+ struct gpio_desc *enable_gpio;
+};
+
struct ll_struct {
unsigned long rx_state;
unsigned long rx_count;
@@ -136,6 +145,9 @@ static int ll_open(struct hci_uart *hu)
hu->priv = ll;
+ if (hu->serdev)
+ serdev_device_open(hu->serdev);
+
return 0;
}
@@ -164,6 +176,13 @@ static int ll_close(struct hci_uart *hu)
kfree_skb(ll->rx_skb);
+ if (hu->serdev) {
+ struct ll_device *lldev = serdev_device_get_drvdata(hu->serdev);
+ gpiod_set_value_cansleep(lldev->enable_gpio, 0);
+
+ serdev_device_close(hu->serdev);
+ }
+
hu->priv = NULL;
kfree(ll);
@@ -505,9 +524,245 @@ static struct sk_buff *ll_dequeue(struct hci_uart *hu)
return skb_dequeue(&ll->txq);
}
+#ifdef CONFIG_SERIAL_DEV_BUS
+static int read_local_version(struct hci_dev *hdev)
+{
+ int err = 0;
+ unsigned short version = 0;
+ struct sk_buff *skb;
+ struct hci_rp_read_local_version *ver;
+
+ skb = __hci_cmd_sync(hdev, HCI_OP_READ_LOCAL_VERSION, 0, NULL, HCI_INIT_TIMEOUT);
+ if (IS_ERR(skb)) {
+ bt_dev_err(hdev, "Reading TI version information failed (%ld)",
+ PTR_ERR(skb));
+ err = PTR_ERR(skb);
+ goto out;
+ }
+ if (skb->len != sizeof(*ver)) {
+ err = -EILSEQ;
+ goto out;
+ }
+
+ ver = (struct hci_rp_read_local_version *)skb->data;
+ if (le16_to_cpu(ver->manufacturer) != 13) {
+ err = -ENODEV;
+ goto out;
+ }
+
+ version = le16_to_cpu(ver->lmp_subver);
+
+out:
+ if (err) bt_dev_err(hdev, "Failed to read TI version info: %d", err);
+ kfree_skb(skb);
+ return err ? err : version;
+}
+
+/**
+ * download_firmware -
+ * internal function which parses through the .bts firmware
+ * script file intreprets SEND, DELAY actions only as of now
+ */
+static int download_firmware(struct ll_device *lldev)
+{
+ unsigned short chip, min_ver, maj_ver;
+ int version, err, len;
+ unsigned char *ptr, *action_ptr;
+ unsigned char bts_scr_name[40]; /* 40 char long bts scr name? */
+ const struct firmware *fw;
+ struct sk_buff *skb;
+ struct hci_command *cmd;
+
+ version = read_local_version(lldev->hu.hdev);
+ if (version < 0)
+ return version;
+
+ chip = (version & 0x7C00) >> 10;
+ min_ver = (version & 0x007F);
+ maj_ver = (version & 0x0380) >> 7;
+ if (version & 0x8000)
+ maj_ver |= 0x0008;
+
+ snprintf(bts_scr_name, sizeof(bts_scr_name),
+ "ti-connectivity/TIInit_%d.%d.%d.bts",
+ chip, maj_ver, min_ver);
+
+ err = request_firmware(&fw, bts_scr_name, &lldev->serdev->dev);
+ if (err || !fw->data || !fw->size) {
+ bt_dev_err(lldev->hu.hdev, "request_firmware failed(errno %d) for %s",
+ err, bts_scr_name);
+ return -EINVAL;
+ }
+ ptr = (void *)fw->data;
+ len = fw->size;
+ /* bts_header to remove out magic number and
+ * version
+ */
+ ptr += sizeof(struct bts_header);
+ len -= sizeof(struct bts_header);
+
+ while (len > 0 && ptr) {
+ bt_dev_dbg(lldev->hu.hdev, " action size %d, type %d ",
+ ((struct bts_action *)ptr)->size,
+ ((struct bts_action *)ptr)->type);
+
+ action_ptr = &(((struct bts_action *)ptr)->data[0]);
+
+ switch (((struct bts_action *)ptr)->type) {
+ case ACTION_SEND_COMMAND: /* action send */
+ bt_dev_dbg(lldev->hu.hdev, "S");
+ cmd = (struct hci_command *)action_ptr;
+ if (cmd->opcode == 0xff36) {
+ /* ignore remote change
+ * baud rate HCI VS command */
+ bt_dev_warn(lldev->hu.hdev, "change remote baud rate command in firmware");
+ break;
+ }
+ if (cmd->prefix != 1)
+ bt_dev_dbg(lldev->hu.hdev, "command type %d\n", cmd->prefix);
+
+ skb = __hci_cmd_sync(lldev->hu.hdev, cmd->opcode, cmd->plen, &cmd->speed, HCI_INIT_TIMEOUT);
+ if (IS_ERR(skb)) {
+ bt_dev_err(lldev->hu.hdev, "send command failed\n");
+ goto out_rel_fw;
+ }
+ kfree_skb(skb);
+ break;
+ case ACTION_WAIT_EVENT: /* wait */
+ /* no need to wait as command was synchronous */
+ bt_dev_dbg(lldev->hu.hdev, "W");
+ break;
+ case ACTION_DELAY: /* sleep */
+ bt_dev_info(lldev->hu.hdev, "sleep command in scr");
+ mdelay(((struct bts_action_delay *)action_ptr)->msec);
+ break;
+ }
+ len -= (sizeof(struct bts_action) +
+ ((struct bts_action *)ptr)->size);
+ ptr += sizeof(struct bts_action) +
+ ((struct bts_action *)ptr)->size;
+ }
+
+out_rel_fw:
+ /* fw download complete */
+ release_firmware(fw);
+ return err;
+}
+
+static int ll_setup(struct hci_uart *hu)
+{
+ int err, retry = 3;
+ struct ll_device *lldev;
+ struct serdev_device *serdev = hu->serdev;
+ u32 speed;
+
+ if (!serdev)
+ return 0;
+
+ lldev = serdev_device_get_drvdata(serdev);
+
+ serdev_device_set_flow_control(serdev, true);
+
+ do {
+ /* Configure BT_EN to HIGH state */
+ gpiod_set_value_cansleep(lldev->enable_gpio, 0);
+ msleep(5);
+ gpiod_set_value_cansleep(lldev->enable_gpio, 1);
+ msleep(100);
+
+ err = download_firmware(lldev);
+ if (!err)
+ break;
+
+ /* Toggle BT_EN and retry */
+ bt_dev_err(hu->hdev, "download firmware failed, retrying...");
+ } while (retry--);
+
+ if (err)
+ return err;
+
+ /* Operational speed if any */
+ if (hu->oper_speed)
+ speed = hu->oper_speed;
+ else if (hu->proto->oper_speed)
+ speed = hu->proto->oper_speed;
+ else
+ speed = 0;
+
+ if (speed) {
+ struct sk_buff *skb = __hci_cmd_sync(hu->hdev, 0xff36, sizeof(speed), &speed, HCI_INIT_TIMEOUT);
+ if (!IS_ERR(skb)) {
+ kfree_skb(skb);
+ serdev_device_set_baudrate(serdev, speed);
+ }
+ }
+
+ return 0;
+}
+
+static const struct hci_uart_proto llp;
+
+static int hci_ti_probe(struct serdev_device *serdev)
+{
+ struct hci_uart *hu;
+ struct ll_device *lldev;
+ u32 max_speed = 3000000;
+
+ lldev = devm_kzalloc(&serdev->dev, sizeof(struct ll_device), GFP_KERNEL);
+ if (!lldev)
+ return -ENOMEM;
+ hu = &lldev->hu;
+
+ serdev_device_set_drvdata(serdev, lldev);
+ lldev->serdev = hu->serdev = serdev;
+
+ lldev->enable_gpio = devm_gpiod_get_optional(&serdev->dev, "enable", GPIOD_OUT_LOW);
+ if (IS_ERR(lldev->enable_gpio))
+ return PTR_ERR(lldev->enable_gpio);
+
+ of_property_read_u32(serdev->dev.of_node, "max-speed", &max_speed);
+ hci_uart_set_speeds(hu, 115200, max_speed);
+
+ return hci_uart_register_device(hu, &llp);
+}
+
+static void hci_ti_remove(struct serdev_device *serdev)
+{
+ struct ll_device *lldev = serdev_device_get_drvdata(serdev);
+ struct hci_uart *hu = &lldev->hu;
+ struct hci_dev *hdev = hu->hdev;
+
+ cancel_work_sync(&hu->write_work);
+
+ hci_unregister_dev(hdev);
+ hci_free_dev(hdev);
+ hu->proto->close(hu);
+}
+
+static const struct of_device_id hci_ti_of_match[] = {
+ { .compatible = "ti,wl1831-st" },
+ { .compatible = "ti,wl1835-st" },
+ { .compatible = "ti,wl1837-st" },
+ {},
+};
+MODULE_DEVICE_TABLE(of, hci_ti_of_match);
+
+static struct serdev_device_driver hci_ti_drv = {
+ .driver = {
+ .name = "hci-ti",
+ .of_match_table = of_match_ptr(hci_ti_of_match),
+ },
+ .probe = hci_ti_probe,
+ .remove = hci_ti_remove,
+};
+#else
+#define ll_setup NULL
+#endif
+
static const struct hci_uart_proto llp = {
.id = HCI_UART_LL,
.name = "LL",
+ .setup = ll_setup,
.open = ll_open,
.close = ll_close,
.recv = ll_recv,
@@ -518,10 +773,14 @@ static const struct hci_uart_proto llp = {
int __init ll_init(void)
{
+ serdev_device_driver_register(&hci_ti_drv);
+
return hci_uart_register_proto(&llp);
}
int __exit ll_deinit(void)
{
+ serdev_device_driver_unregister(&hci_ti_drv);
+
return hci_uart_unregister_proto(&llp);
}
--
2.10.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 2/4] bluetooth: hci_uart: remove unused hci_uart_init_tty
From: Rob Herring @ 2017-04-05 18:30 UTC (permalink / raw)
To: Marcel Holtmann, linux-bluetooth-u79uwXL29TY76Z2rM5mHXA
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Gustavo Padovan, Johan Hedberg, Mark Rutland, Wei Xu, Eyal Reizer,
Satish Patel, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170405183005.20570-1-robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
There are no users of hci_uart_init_tty, so remove it.
Signed-off-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Marcel Holtmann <marcel-kz+m5ild9QBg9hUCZPvPmw@public.gmane.org>
Cc: Gustavo Padovan <gustavo-THi1TnShQwVAfugRpC6u6w@public.gmane.org>
Cc: Johan Hedberg <johan.hedberg-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: linux-bluetooth-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
---
drivers/bluetooth/hci_ldisc.c | 19 -------------------
drivers/bluetooth/hci_uart.h | 1 -
2 files changed, 20 deletions(-)
diff --git a/drivers/bluetooth/hci_ldisc.c b/drivers/bluetooth/hci_ldisc.c
index 17bcbc13623f..cec4438ede01 100644
--- a/drivers/bluetooth/hci_ldisc.c
+++ b/drivers/bluetooth/hci_ldisc.c
@@ -319,25 +319,6 @@ void hci_uart_set_speeds(struct hci_uart *hu, unsigned int init_speed,
hu->oper_speed = oper_speed;
}
-void hci_uart_init_tty(struct hci_uart *hu)
-{
- struct tty_struct *tty = hu->tty;
- struct ktermios ktermios;
-
- /* Bring the UART into a known 8 bits no parity hw fc state */
- ktermios = tty->termios;
- ktermios.c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP |
- INLCR | IGNCR | ICRNL | IXON);
- ktermios.c_oflag &= ~OPOST;
- ktermios.c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN);
- ktermios.c_cflag &= ~(CSIZE | PARENB);
- ktermios.c_cflag |= CS8;
- ktermios.c_cflag |= CRTSCTS;
-
- /* tty_set_termios() return not checked as it is always 0 */
- tty_set_termios(tty, &ktermios);
-}
-
void hci_uart_set_baudrate(struct hci_uart *hu, unsigned int speed)
{
struct tty_struct *tty = hu->tty;
diff --git a/drivers/bluetooth/hci_uart.h b/drivers/bluetooth/hci_uart.h
index 1b41c661bbb8..2b05e557fad0 100644
--- a/drivers/bluetooth/hci_uart.h
+++ b/drivers/bluetooth/hci_uart.h
@@ -114,7 +114,6 @@ int hci_uart_register_device(struct hci_uart *hu, const struct hci_uart_proto *p
int hci_uart_tx_wakeup(struct hci_uart *hu);
int hci_uart_init_ready(struct hci_uart *hu);
-void hci_uart_init_tty(struct hci_uart *hu);
void hci_uart_set_baudrate(struct hci_uart *hu, unsigned int speed);
void hci_uart_set_flow_control(struct hci_uart *hu, bool enable);
void hci_uart_set_speeds(struct hci_uart *hu, unsigned int init_speed,
--
2.10.1
^ permalink raw reply related
* [PATCH 1/4] dt-bindings: net: Add TI WiLink shared transport binding
From: Rob Herring @ 2017-04-05 18:30 UTC (permalink / raw)
To: Marcel Holtmann, linux-bluetooth
Cc: linux-arm-kernel, Gustavo Padovan, Johan Hedberg, Mark Rutland,
Wei Xu, Eyal Reizer, Satish Patel, netdev, devicetree
In-Reply-To: <20170405183005.20570-1-robh@kernel.org>
Add serial slave device binding for the TI WiLink series of Bluetooth/FM/GPS
devices.
Signed-off-by: Rob Herring <robh@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: netdev@vger.kernel.org
Cc: devicetree@vger.kernel.org
---
.../devicetree/bindings/net/ti,wilink-st.txt | 35 ++++++++++++++++++++++
1 file changed, 35 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/ti,wilink-st.txt
diff --git a/Documentation/devicetree/bindings/net/ti,wilink-st.txt b/Documentation/devicetree/bindings/net/ti,wilink-st.txt
new file mode 100644
index 000000000000..cbad73a84ac4
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/ti,wilink-st.txt
@@ -0,0 +1,35 @@
+TI WiLink 7/8 (wl12xx/wl18xx) Shared Transport BT/FM/GPS devices
+
+TI WiLink devices have a UART interface for providing Bluetooth, FM radio,
+and GPS over what's called "shared transport". The shared transport is
+standard BT HCI protocol with additional channels for the other functions.
+
+These devices also have a separate WiFi interface as described in
+wireless/ti,wlcore.txt.
+
+This bindings follows the UART slave device binding in
+../serial/slave-device.txt.
+
+Required properties:
+ - compatible: should be one of the following:
+ "ti,wl1271-st"
+ "ti,wl1273-st"
+ "ti,wl1831-st"
+ "ti,wl1835-st"
+ "ti,wl1837-st"
+
+Optional properties:
+ - enable-gpios : GPIO signal controlling enabling of BT. Active high.
+ - vio-supply : Vio input supply (1.8V)
+ - vbat-supply : Vbat input supply (2.9-4.8V)
+
+Example:
+
+&serial0 {
+ compatible = "ns16550a";
+ ...
+ bluetooth {
+ compatible = "ti,wl1835-st";
+ enable-gpios = <&gpio1 7 GPIO_ACTIVE_HIGH>;
+ };
+};
--
2.10.1
^ permalink raw reply related
* [PATCH 0/4] TI Bluetooth serdev support
From: Rob Herring @ 2017-04-05 18:30 UTC (permalink / raw)
To: Marcel Holtmann, linux-bluetooth
Cc: linux-arm-kernel, Gustavo Padovan, Johan Hedberg, Mark Rutland,
Wei Xu, Eyal Reizer, Satish Patel, netdev, devicetree
This series adds serdev support to the HCI LL protocol used on TI BT
modules and enables support on HiKey board with with the WL1835 module.
With this the custom TI UIM daemon and btattach are no longer needed.
The series is available on this git branch[1]. Patch 2 is just clean-up
and can be applied independently. Patch 3 is dependent on the series
"Nokia H4+ support". I'd suggest both series are merged thru the BT tree.
Rob
[1] git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git ti-bluetooth
Rob Herring (4):
dt-bindings: net: Add TI WiLink shared transport binding
bluetooth: hci_uart: remove unused hci_uart_init_tty
bluetooth: hci_uart: add LL protocol serdev driver support
arm64: dts: hikey: add WL1835 Bluetooth device node
.../devicetree/bindings/net/ti,wilink-st.txt | 35 +++
arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 5 +
drivers/bluetooth/hci_ldisc.c | 19 --
drivers/bluetooth/hci_ll.c | 261 ++++++++++++++++++++-
drivers/bluetooth/hci_uart.h | 1 -
5 files changed, 300 insertions(+), 21 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/ti,wilink-st.txt
^ permalink raw reply
* Re: [PATCHv3 00/10] Nokia H4+ support
From: Rob Herring @ 2017-04-05 18:16 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Marcel Holtmann, Sebastian Reichel, Gustavo F. Padovan,
Johan Hedberg, Samuel Thibault, Pavel Machek, Tony Lindgren,
Jiri Slaby, Mark Rutland, open list:BLUETOOTH DRIVERS,
linux-serial@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, David S. Miller
In-Reply-To: <20170331133353.GA32267@kroah.com>
On Fri, Mar 31, 2017 at 8:33 AM, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Wed, Mar 29, 2017 at 11:33:26PM +0200, Marcel Holtmann wrote:
>> Hi Rob,
>>
>> >> Here is PATCHv3 for the Nokia bluetooth patchset. I addressed all comments from
>> >> Rob and Pavel regarding the serdev patches and dropped the *.dts patches, since
>> >> they were queued by Tony. I also changed the patch order, so that the serdev
>> >> patches come first. All of them have Acked-by from Rob, so I think it makes
>> >> sense to merge them to serdev subsystem (now) and provide an immutable branch
>> >> for the bluetooth subsystem.
>> >
>> > Greg doesn't read cover letters generally and since the serdev patches
>> > are Cc rather than To him, he's probably not planning to pick them up.
>>
>> I wonder actually if we should merge all of these via bluetooth-next
>> tree with proper Ack from Greg. However it would be good to also get
>> buy in from Dave for merging this ultimately through net-next.
>
> I don't really care where it goes. I can take the whole thing in my
> tty/serial tree now if no one objects and I get an ack from the relevant
> maintainers {hint...}
I think it is better if it goes thru BT tree. I have another driver
converted that is dependent on this series. There's a couple other
serdev changes on the list too, but this shouldn't depend on them.
Rob
^ permalink raw reply
* Re: [PATCH v6 17/39] platform: add video-multiplexer subdevice driver
From: Pavel Machek @ 2017-04-05 18:05 UTC (permalink / raw)
To: Lucas Stach
Cc: mark.rutland, andrew-ct.chen, minghsiu.tsai, nick, songjun.wu,
hverkuil, shuah, devel, markus.heiser, Steve Longerbeam,
robert.jarzmik, linux, geert, Steve Longerbeam, p.zabel,
linux-media, devicetree, sakari.ailus, arnd, Sascha Hauer,
tiffany.lin, bparrot, laurent.pinchart+renesas, horms+renesas,
mchehab, linux-arm-kernel, niklas.soderlund+renesas, gregkh,
linux-kernel, robh+dt, jean-christophe.trotin, kernel
In-Reply-To: <1491393519.2904.40.camel@pengutronix.de>
[-- Attachment #1.1: Type: text/plain, Size: 1220 bytes --]
On Wed 2017-04-05 13:58:39, Lucas Stach wrote:
> Am Mittwoch, den 05.04.2017, 13:18 +0200 schrieb Pavel Machek:
> > Hi!
> >
> > > + * video stream multiplexer controlled via gpio or syscon
> > > + *
> > > + * Copyright (C) 2013 Pengutronix, Sascha Hauer <kernel@pengutronix.de>
> > > + * Copyright (C) 2016 Pengutronix, Philipp Zabel <kernel@pengutronix.de>
> >
> > This is actually quite interesting. Same email address for two
> > people...
> >
> > Plus, I believe this wants to say that copyright is with Pengutronix,
> > not Sascha and Philipp. In that case you probably want to list
> > copyright and authors separately?
> >
> Nope, copyright doesn't get transferred to the employer within the rules
> of the German "Urheberrecht", but stays at the original author of the
> code.
Ok, then I guess it should be
Copyright (C) 2013 Sascha Hauer
Work sponsored by Pengutronix, use <kernel@pengutronix.de> as contact address
or something? I know license change is not on the table, but I guess
it is good to get legal stuff right.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
[-- Attachment #2: Type: text/plain, Size: 169 bytes --]
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
^ permalink raw reply
* Re: [PATCH v4] of/pci: Fix memory leak in of_pci_get_host_bridge_resources
From: kbuild test robot @ 2017-04-05 17:39 UTC (permalink / raw)
Cc: kbuild-all-JC7UmRfGjtg, linux-pci-u79uwXL29TY76Z2rM5mHXA,
robh-DgEjT+Ai2ygdnm+yROfE0A, toshi.kani-ZPxbGqLxI0U,
shawn.lin-TNX95d0MmH7DzftRWevZcw,
briannorris-F7+t8E8rja9g9hUCZPvPmw,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
dianders-F7+t8E8rja9g9hUCZPvPmw, bhelgaas-hpIqsD4AKlfQT0dZR+AlfA,
dtor-F7+t8E8rja9g9hUCZPvPmw, Jeffy Chen,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Frank Rowand
In-Reply-To: <1491358521-17834-2-git-send-email-jeffy.chen-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2915 bytes --]
Hi Jeffy,
[auto build test ERROR on pci/next]
[also build test ERROR on v4.11-rc5 next-20170405]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Jeffy-Chen/of-pci-Fix-memory-leak-in-of_pci_get_host_bridge_resources/20170406-005941
base: https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git next
config: x86_64-lkp (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
drivers//pci/bus.c: In function 'pci_add_resource_offset':
>> drivers//pci/bus.c:36:2: error: expected ';' before 'entry'
entry->offset = offset;
^~~~~
vim +36 drivers//pci/bus.c
0efd5aab Bjorn Helgaas 2012-02-23 20 void pci_add_resource_offset(struct list_head *resources, struct resource *res,
0efd5aab Bjorn Helgaas 2012-02-23 21 resource_size_t offset)
45ca9e97 Bjorn Helgaas 2011-10-28 22 {
14d76b68 Jiang Liu 2015-02-05 23 struct resource_entry *entry;
45ca9e97 Bjorn Helgaas 2011-10-28 24
fa904d0d Jeffy Chen 2017-04-05 25 entry = resource_list_create_entry(NULL, 0);
14d76b68 Jiang Liu 2015-02-05 26 if (!entry) {
0efd5aab Bjorn Helgaas 2012-02-23 27 printk(KERN_ERR "PCI: can't add host bridge window %pR\n", res);
45ca9e97 Bjorn Helgaas 2011-10-28 28 return;
45ca9e97 Bjorn Helgaas 2011-10-28 29 }
45ca9e97 Bjorn Helgaas 2011-10-28 30
fa904d0d Jeffy Chen 2017-04-05 31 if (res->flags & IORESOURCE_AUTO)
fa904d0d Jeffy Chen 2017-04-05 32 *entry->res = *res;
fa904d0d Jeffy Chen 2017-04-05 33 else
fa904d0d Jeffy Chen 2017-04-05 34 entry->res = res
fa904d0d Jeffy Chen 2017-04-05 35
14d76b68 Jiang Liu 2015-02-05 @36 entry->offset = offset;
14d76b68 Jiang Liu 2015-02-05 37 resource_list_add_tail(entry, resources);
0efd5aab Bjorn Helgaas 2012-02-23 38 }
0efd5aab Bjorn Helgaas 2012-02-23 39 EXPORT_SYMBOL(pci_add_resource_offset);
0efd5aab Bjorn Helgaas 2012-02-23 40
0efd5aab Bjorn Helgaas 2012-02-23 41 void pci_add_resource(struct list_head *resources, struct resource *res)
0efd5aab Bjorn Helgaas 2012-02-23 42 {
0efd5aab Bjorn Helgaas 2012-02-23 43 pci_add_resource_offset(resources, res, 0);
45ca9e97 Bjorn Helgaas 2011-10-28 44 }
:::::: The code at line 36 was first introduced by commit
:::::: 14d76b68f2819a1d0b50236a7e9e9f2ea69869d9 PCI: Use common resource list management code instead of private implementation
:::::: TO: Jiang Liu <jiang.liu-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
:::::: CC: Rafael J. Wysocki <rafael.j.wysocki-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 25168 bytes --]
^ permalink raw reply
* Re: [PATCH v4] of/pci: Fix memory leak in of_pci_get_host_bridge_resources
From: kbuild test robot @ 2017-04-05 17:36 UTC (permalink / raw)
Cc: kbuild-all, linux-pci, robh, toshi.kani, shawn.lin, briannorris,
linux-kernel, dianders, bhelgaas, dtor, Jeffy Chen, devicetree,
Rob Herring, Frank Rowand
In-Reply-To: <1491358521-17834-2-git-send-email-jeffy.chen@rock-chips.com>
[-- Attachment #1: Type: text/plain, Size: 4036 bytes --]
Hi Jeffy,
[auto build test ERROR on pci/next]
[also build test ERROR on v4.11-rc5 next-20170405]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Jeffy-Chen/of-pci-Fix-memory-leak-in-of_pci_get_host_bridge_resources/20170406-005941
base: https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git next
config: i386-randconfig-n0-04051821 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
drivers//of/of_pci.c: In function 'of_pci_get_host_bridge_resources':
>> drivers//of/of_pci.c:215:30: error: incompatible type for argument 2 of 'pci_add_resource'
pci_add_resource(resources, res);
^~~
In file included from include/linux/of_pci.h:4:0,
from drivers//of/of_pci.c:8:
include/linux/pci.h:1152:6: note: expected 'struct resource *' but argument is of type 'struct resource'
void pci_add_resource(struct list_head *resources, struct resource *res);
^~~~~~~~~~~~~~~~
>> drivers//of/of_pci.c:261:9: error: invalid type argument of '->' (have 'struct resource')
res->start - range.pci_addr);
^~
>> drivers//of/of_pci.c:260:38: error: incompatible type for argument 2 of 'pci_add_resource_offset'
pci_add_resource_offset(resources, res,
^~~
In file included from include/linux/of_pci.h:4:0,
from drivers//of/of_pci.c:8:
include/linux/pci.h:1153:6: note: expected 'struct resource *' but argument is of type 'struct resource'
void pci_add_resource_offset(struct list_head *resources, struct resource *res,
^~~~~~~~~~~~~~~~~~~~~~~
vim +/pci_add_resource +215 drivers//of/of_pci.c
209 } else {
210 if (res.end > res.start + bus_max)
211 res.end = res.start + bus_max;
212 }
213
214 res.flags |= IORESOURCE_AUTO;
> 215 pci_add_resource(resources, res);
216
217 /* Check for ranges property */
218 err = of_pci_range_parser_init(&parser, dev);
219 if (err)
220 goto parse_failed;
221
222 pr_debug("Parsing ranges property...\n");
223 for_each_of_pci_range(&parser, &range) {
224 /* Read next ranges element */
225 if ((range.flags & IORESOURCE_TYPE_BITS) == IORESOURCE_IO)
226 snprintf(range_type, 4, " IO");
227 else if ((range.flags & IORESOURCE_TYPE_BITS) == IORESOURCE_MEM)
228 snprintf(range_type, 4, "MEM");
229 else
230 snprintf(range_type, 4, "err");
231 pr_info(" %s %#010llx..%#010llx -> %#010llx\n", range_type,
232 range.cpu_addr, range.cpu_addr + range.size - 1,
233 range.pci_addr);
234
235 /*
236 * If we failed translation or got a zero-sized region
237 * then skip this range
238 */
239 if (range.cpu_addr == OF_BAD_ADDR || range.size == 0)
240 continue;
241
242 err = of_pci_range_to_resource(&range, dev, &res);
243 if (err)
244 continue;
245
246 if (resource_type(&res) == IORESOURCE_IO) {
247 if (!io_base) {
248 pr_err("I/O range found for %s. Please provide an io_base pointer to save CPU base address\n",
249 dev->full_name);
250 err = -EINVAL;
251 goto parse_failed;
252 }
253 if (*io_base != (resource_size_t)OF_BAD_ADDR)
254 pr_warn("More than one I/O resource converted for %s. CPU base address for old range lost!\n",
255 dev->full_name);
256 *io_base = range.cpu_addr;
257 }
258
259 res.flags |= IORESOURCE_AUTO;
> 260 pci_add_resource_offset(resources, res,
> 261 res->start - range.pci_addr);
262 }
263
264 return 0;
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 25202 bytes --]
^ 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