* Re: [PATCH v3 0/3] ARM: dts: omap5 uevm: add LEDs, USR1 button and EEPROM
From: Tony Lindgren @ 2016-11-09 22:03 UTC (permalink / raw)
To: H. Nikolaus Schaller
Cc: Benoît Cousson, Rob Herring, Mark Rutland, Russell King,
linux-omap, devicetree, linux-kernel, letux-kernel
In-Reply-To: <cover.1475126737.git.hns@goldelico.com>
* H. Nikolaus Schaller <hns@goldelico.com> [160928 22:26]:
> Changes V3:
> * remove unit addresses from LEDs [Rob Herring]
>
> 2016-09-28 20:08:23: Changes V2:
> * fixed subject of patches to correctly tell that it is for omap5 evm
> * changed default triggers a little to create a nicer default pattern
>
> 2016-09-27 07:26:14: These patches configure
> * the EEPROM
> * the LEDs (with some default triggers)
> * the USR1 gpio button
> for the OMAP5 UEVM board.
>
> H. Nikolaus Schaller (3):
> ARM: dts: omap5 uevm: add EEPROM
> ARM: dts: omap5 uevm: add LEDs
> ARM: dts: omap5 uevm: add USR1 button
Applying all into omap-for-v4.10/dt thanks.
Tony
^ permalink raw reply
* Re: [PATCH v2 4/9] regulator: lp873x: Add support for populating input supply
From: Tony Lindgren @ 2016-11-09 21:50 UTC (permalink / raw)
To: Rob Herring
Cc: Lokesh Vutla, Linux OMAP Mailing List, Tero Kristo, Sekhar Nori,
Nishanth Menon, Device Tree Mailing List, Linux ARM Mailing List,
Lee Jones, Keerthy
In-Reply-To: <20161109182618.ajqhtffure76zfnf@rob-hp-laptop>
* Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> [161109 11:26]:
> On Wed, Nov 02, 2016 at 10:58:40AM +0530, Lokesh Vutla wrote:
> > On Monday 31 October 2016 02:11 AM, Rob Herring wrote:
> > > On Fri, Oct 21, 2016 at 04:08:36PM +0530, Lokesh Vutla wrote:
> > >> In order to have a proper topology of regulators for a platform, each
> > >> registering regulator needs to populate supply_name field for identifying
> > >> its supply's name. Add supply_name field for lp873x regulators.
> > >>
> > >> Cc: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> > >> Cc: Keerthy <j-keerthy-l0cyMroinI0@public.gmane.org>
> > >> Signed-off-by: Lokesh Vutla <lokeshvutla-l0cyMroinI0@public.gmane.org>
> > >> ---
> > >> Documentation/devicetree/bindings/mfd/lp873x.txt | 8 ++++++++
> > >> drivers/regulator/lp873x-regulator.c | 1 +
...
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Please send this patch separately to the regulator maintainer.
Thanks,
Tony
--
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 2/3] ARM64 LPC: Add missing range exception for special ISA
From: Arnd Bergmann @ 2016-11-09 21:38 UTC (permalink / raw)
To: One Thousand Gnomes
Cc: Mark Rutland, zhichang.yuan, catalin.marinas, will.deacon,
robh+dt, bhelgaas, olof, linux-arm-kernel, lorenzo.pieralisi,
linux-kernel, linuxarm, devicetree, linux-pci, linux-serial,
minyard, benh, liviu.dudau, zourongrong, john.garry,
gabriele.paoloni, zhichang.yuan02, kantyzc, xuwei5, marc.zyngier
In-Reply-To: <20161109135453.2e5402bd@lxorguk.ukuu.org.uk>
On Wednesday, November 9, 2016 1:54:53 PM CET One Thousand Gnomes wrote:
> > I think it is a relatively safe assumption that there is only one
> > ISA bridge. A lot of old drivers hardcode PIO or memory addresses
>
> It's not a safe assumption for x86 at least. There are a few systems with
> multiple ISA busses particularly older laptops with a docking station.
But do they have multiple ISA domains? There is no real harm in supporting
it, the (small) downsides I can think of are:
- a few extra cycles for the lookup, from possibly walking a linked list
to find the correct set of helpers and MMIO addresses
- making it too general could invite more people to design hardware
around the infrastructure when we really want them to stop adding
stuff like this.
Arnd
^ permalink raw reply
* Re: [PATCH v2 0/8] Support TPS65217 PMIC interrupt in DT
From: Tony Lindgren @ 2016-11-09 21:38 UTC (permalink / raw)
To: Milo Kim
Cc: bcousson-rdvid1DuHRBWk0Htik3J/w,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Lee Jones, Robert Nelson
In-Reply-To: <20161028123702.21849-1-woogyom.kim-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
* Milo Kim <woogyom.kim-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> [161028 05:38]:
> TPS65217 interrupt events include push button pressed/released, USB and AC
> voltage status change. AM335x bone based boards (like BB, BBB, BBG) have
> common PMIC interrupt pin (named NMI) of AM335x core.
>
> This patchset support interrupts in device tree file.
Applying into omap-for-v4.10/dt except the last patch I'll apply into
omap-for-v4.10/fixes-not-urgent.
Regards,
Tony
--
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/3] ARM64 LPC: LPC driver implementation on Hip06
From: Arnd Bergmann @ 2016-11-09 21:34 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Gabriele Paoloni, Yuanzhichang, mark.rutland@arm.com,
devicetree@vger.kernel.org, lorenzo.pieralisi@arm.com,
benh@kernel.crashing.org, minyard@acm.org,
catalin.marinas@arm.com, John Garry, will.deacon@arm.com,
linux-kernel@vger.kernel.org, xuwei (O), Linuxarm, olof@lixom.net,
robh+dt@kernel.org, zourongrong@gmail.com
In-Reply-To: <EE11001F9E5DDD47B7634E2F8A612F2E1F8F1A7A@lhreml507-mbx>
On Wednesday, November 9, 2016 12:10:43 PM CET Gabriele Paoloni wrote:
> > On Tuesday, November 8, 2016 11:47:09 AM CET zhichang.yuan wrote:
> > > + /*
> > > + * The first PCIBIOS_MIN_IO is reserved specifically for
> > indirectIO.
> > > + * It will separate indirectIO range from pci host bridge to
> > > + * avoid the possible PIO conflict.
> > > + * Set the indirectIO range directly here.
> > > + */
> > > + lpcdev->io_ops.start = 0;
> > > + lpcdev->io_ops.end = PCIBIOS_MIN_IO - 1;
> > > + lpcdev->io_ops.devpara = lpcdev;
> > > + lpcdev->io_ops.pfin = hisilpc_comm_in;
> > > + lpcdev->io_ops.pfout = hisilpc_comm_out;
> > > + lpcdev->io_ops.pfins = hisilpc_comm_ins;
> > > + lpcdev->io_ops.pfouts = hisilpc_comm_outs;
> >
> > I have to look at patch 2 in more detail again, after missing a few
> > review
> > rounds. I'm still a bit skeptical about hardcoding a logical I/O port
> > range here, and would hope that we can just go through the same
> > assignment of logical port ranges that we have for PCI buses,
> > decoupling
> > the bus addresses from the linux-internal ones.
>
> The point here is that we want to avoid any conflict/overlap between
> the LPC I/O space and the PCI I/O space. With the assignment above
> we make sure that LPC never interfere with PCI I/O space.
But we already abstract the PCI I/O space using dynamic registration.
There is no need to hardcode the logical address for ISA, though
I think we can hardcode the bus address to start at zero here.
Arnd
^ permalink raw reply
* Re: [PATCH V5 1/3] ARM64 LPC: Indirect ISA port IO introduced
From: Arnd Bergmann @ 2016-11-09 21:33 UTC (permalink / raw)
To: linux-arm-kernel
Cc: John Garry, mark.rutland, devicetree, lorenzo.pieralisi, benh,
minyard, gabriele.paoloni, catalin.marinas, zhichang.yuan02,
liviu.dudau, linuxarm, Will Deacon, linux-kernel, zourongrong,
bhelgaas, robh+dt, xuwei5, linux-serial, linux-pci, olof, kantyzc,
zhichang.yuan
In-Reply-To: <6dee9821-5145-2113-e391-6317e4533c06@huawei.com>
On Wednesday, November 9, 2016 11:29:46 AM CET John Garry wrote:
> On 08/11/2016 22:35, Arnd Bergmann wrote:
> > On Tuesday, November 8, 2016 4:49:49 PM CET Will Deacon wrote:
> >> On Tue, Nov 08, 2016 at 04:33:44PM +0000, John Garry wrote:
> >>> On 08/11/2016 16:12, Will Deacon wrote:
> >>>> On Tue, Nov 08, 2016 at 11:47:07AM +0800, zhichang.yuan wrote:
> >
> >>>> Is there no way to make this slightly more generic, so that it can be
> >>>> re-used elsewhere? For example, if struct extio_ops was common, then
> >>>> you could have the singleton (which maybe should be an interval tree?),
> >>>> type definition, setter function and the BUILD_EXTIO invocations
> >>>> somewhere generic, rather than squirelled away in the arch backend.
> >>>>
> >>> The concern would be that some architecture which uses generic higher-level
> >>> ISA accessor ops, but have IO space, could be affected.
> >>
> >> You're already adding a Kconfig symbol for this stuff, so you can keep
> >> that if you don't want it on other architectures. I'm just arguing that
> >> plumbing drivers directly into arch code via arm64_set_extops is not
> >> something I'm particularly fond of, especially when it looks like it
> >> could be avoided with a small amount of effort.
> >
> > Agreed, I initially suggested putting this into arch/arm64/, but there isn't
> > really a reason why it couldn't just live in lib/ with the header file
> > bits moved to include/asm-generic/io.h which we already use.
> >
>
> Right, Zhichang will check the logistics of this. The generic io.h is
> quite clean, so as long as you don't mind new build switches of this
> nature being added, it should be ok; and we'll plan on moving extio.h
> into include/asm-generic as well.
I think all we need is an #ifdef CONFIG_something around the existing
defintion, with the alternative being "extern" declarations, after that
all the interesting logic can sit in a file in lib/.
Arnd
^ permalink raw reply
* Re: [PATCH v2 0/7] soc: renesas: Identify SoC and register with the SoC bus
From: Arnd Bergmann @ 2016-11-09 21:12 UTC (permalink / raw)
To: linuxppc-dev
Cc: Geert Uytterhoeven, Mark Rutland, devicetree@vger.kernel.org,
Dirk Behme, Greg Kroah-Hartman, linux-kernel@vger.kernel.org,
Rob Herring, Linux-Renesas, linux-samsung-soc@vger.kernel.org,
Simon Horman, Yangbo Lu, Pankaj Dubey,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <CAMuHMdVrdjqWruY=dBjWP=jZuZkc=aTBTMijOyTDfZFcaD_jsA@mail.gmail.com>
On Wednesday, November 9, 2016 6:19:06 PM CET Geert Uytterhoeven wrote:
> On Wed, Nov 9, 2016 at 5:56 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Wednesday, November 9, 2016 2:34:33 PM CET Geert Uytterhoeven wrote:
> >> > And Samsung.
> >> > Shall I create the immutable branch now?
> >>
> >> Arnd: are you happy with the new patches and changes?
> >
> > I still had some comments for patch 7, but that shouldn't stop
> > you from creating a branch for the first three so everyone can
> > build on top of that.
>
> Thanks!
>
> What about patch [4/7]?
> Haven't you received it? Your address was in the To-line for all 7 patches.
Ok, I see it now, looks good. That should be included as well then.
Arnd
^ permalink raw reply
* Re: [PATCH] phy: rockchip-inno-usb2: correct 480MHz output clock stable time
From: Doug Anderson @ 2016-11-09 20:54 UTC (permalink / raw)
To: William Wu, Heiko Stübner
Cc: Kishon Vijay Abraham I,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
open list:ARM/Rockchip SoC...,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Rob Herring,
Frank Wang, 黄涛, Brian Norris, Guenter Roeck,
Matthias Kaehlcke, linux-clk
In-Reply-To: <1478523658-9400-1-git-send-email-wulf-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
Hi,
On Mon, Nov 7, 2016 at 5:00 AM, William Wu <wulf-TNX95d0MmH7DzftRWevZcw@public.gmane.org> wrote:
> We found that the system crashed due to 480MHz output clock of
> USB2 PHY was unstable after clock had been enabled by gpu module.
>
> Theoretically, 1 millisecond is a critical value for 480MHz
> output clock stable time, so we try to change the delay time
> to 1.2 millisecond to avoid this issue.
>
> Signed-off-by: William Wu <wulf-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
> ---
> drivers/phy/phy-rockchip-inno-usb2.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/phy/phy-rockchip-inno-usb2.c b/drivers/phy/phy-rockchip-inno-usb2.c
> index ecfd7d1..8f2d2b6 100644
> --- a/drivers/phy/phy-rockchip-inno-usb2.c
> +++ b/drivers/phy/phy-rockchip-inno-usb2.c
> @@ -267,7 +267,7 @@ static int rockchip_usb2phy_clk480m_enable(struct clk_hw *hw)
> return ret;
>
> /* waitting for the clk become stable */
> - mdelay(1);
> + udelay(1200);
Several people who have seen this patch have expressed concern that a
1.2 ms delay is pretty long for something that's supposed to be
"atomic" like a clk_enable(). Consider that someone might call
clk_enable() while interrupts are disabled and that a 1.2 ms interrupt
latency is not so great.
It seems like this clock should be moved to be enabled in "prepare"
and the "enable" should be a no-op. This is a functionality change,
but I don't think there are any real users for this clock at the
moment so it should be fine.
(of course, the 1 ms latency that existed before this patch was still
pretty bad, but ...)
-Doug
--
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 05/14] mmc: sdhci-msm: Update DLL reset sequence
From: Stephen Boyd @ 2016-11-09 20:43 UTC (permalink / raw)
To: Ritesh Harjani
Cc: ulf.hansson, linux-mmc, adrian.hunter, shawn.lin, devicetree,
linux-clk, david.brown, andy.gross, linux-arm-msm, georgi.djakov,
alex.lemberg, mateusz.nowak, Yuliy.Izrailov, asutoshd, kdorfman,
david.griego, stummala, venkatg, rnayak, pramod.gurav
In-Reply-To: <10d66d21-eebd-45a3-6fb7-72117d860142@codeaurora.org>
On 11/09, Ritesh Harjani wrote:
> Hi Stephen,
>
> On 11/9/2016 4:36 AM, Stephen Boyd wrote:
> >On 11/07, Ritesh Harjani wrote:
> >>
> >>diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
> >>index 42f42aa..32b0b79 100644
> >>--- a/drivers/mmc/host/sdhci-msm.c
> >>+++ b/drivers/mmc/host/sdhci-msm.c
> >>@@ -58,11 +58,17 @@
> >> #define CORE_DLL_CONFIG 0x100
> >> #define CORE_DLL_STATUS 0x108
> >>
> >>+#define CORE_DLL_CONFIG_2 0x1b4
> >>+#define CORE_FLL_CYCLE_CNT BIT(18)
> >>+#define CORE_DLL_CLOCK_DISABLE BIT(21)
> >>+
> >> #define CORE_VENDOR_SPEC 0x10c
> >> #define CORE_CLK_PWRSAVE BIT(1)
> >>
> >> #define CORE_VENDOR_SPEC_CAPABILITIES0 0x11c
> >>
> >>+#define TCXO_FREQ 19200000
> >
> >TCXO_FREQ could change based on the board. For example, IPQ has
> >it as 25 MHz.
> Actually not sure of the proper way on how to get this freq in driver
> today. We may use xo_board clock but, it is not available for all boards
> except 8996/8916 I guess.
>
> Also, there is no sdhc for IPQ board and for all other boards
> TCXO_FREQ is same where sdhci-msm driver is used. For that purpose
> this was defined here for sdhci-msm driver.
>
> Do you think in that case we should keep it this way for now and
> later change if a need arise to change the TCXO_FREQ ?
We've added xo_board (or cxo_board/pxo_board) to all the qcom
platforms upstream, so there should always be something to
reference in the dts and call clk_get_rate() on. So I would add
it to the binding as another clock and then use that instead of
hardcoding the value. That's much more flexible in case this
changes in the future.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH v6 4/4] of/fdt: mark hotpluggable memory
From: Reza Arbab @ 2016-11-09 20:15 UTC (permalink / raw)
To: Rob Herring
Cc: Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras,
Andrew Morton, Frank Rowand, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, linuxppc-dev, linux-mm@kvack.org,
devicetree@vger.kernel.org, Bharata B Rao, Nathan Fontenot,
Stewart Smith, Alistair Popple, Balbir Singh, Aneesh Kumar K.V
In-Reply-To: <CAL_JsqLmAv4Pueq9XveeWMD3Jn_o6mGUcyztx8OajBGTrEd0aQ@mail.gmail.com>
On Wed, Nov 09, 2016 at 12:12:55PM -0600, Rob Herring wrote:
>On Mon, Nov 7, 2016 at 5:44 PM, Reza Arbab <arbab@linux.vnet.ibm.com> wrote:
>> + hotpluggable = of_get_flat_dt_prop(node, "linux,hotpluggable", NULL);
>
>Memory being hotpluggable doesn't seem like a linux property to me.
>I'd drop the linux prefix. Also, this needs to be documented.
Sure, that makes sense. I'll do both in v7.
--
Reza Arbab
^ permalink raw reply
* Re: [PATCH 10/13] ARM: dts: exynos: replace to "max-frequecy" instead of "clock-freq-min-max"
From: Krzysztof Kozlowski @ 2016-11-09 20:10 UTC (permalink / raw)
To: Jaehoon Chung
Cc: Krzysztof Kozlowski, Heiko Stuebner,
linux-mmc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
ulf.hansson-QSEj5FYQhm4dnm+yROfE0A,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, shawn.lin-TNX95d0MmH7DzftRWevZcw
In-Reply-To: <72612112-3b79-8fd3-8be4-a8f60ab3b68a-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
On Mon, Nov 07, 2016 at 09:38:15AM +0900, Jaehoon Chung wrote:
> On 11/05/2016 12:04 AM, Krzysztof Kozlowski wrote:
> > On Fri, Nov 04, 2016 at 12:19:49PM +0100, Heiko Stuebner wrote:
> >> Hi Jaehoon,
> >>
> >> Am Freitag, 4. November 2016, 19:21:30 CET schrieb Jaehoon Chung:
> >>> On 11/04/2016 03:41 AM, Krzysztof Kozlowski wrote:
> >>>> On Thu, Nov 03, 2016 at 03:21:32PM +0900, Jaehoon Chung wrote:
> >>>>> In drivers/mmc/core/host.c, there is "max-frequency" property.
> >>>>> It should be same behavior. So Use the "max-frequency" instead of
> >>>>> "clock-freq-min-max".
> >>>>>
> >>>>> Signed-off-by: Jaehoon Chung <jh80.chung-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
> >>>>> ---
> >>>>>
> >>>>> arch/arm/boot/dts/exynos3250-artik5-eval.dts | 2 +-
> >>>>> arch/arm/boot/dts/exynos3250-artik5.dtsi | 2 +-
> >>>>> arch/arm/boot/dts/exynos3250-monk.dts | 2 +-
> >>>>> arch/arm/boot/dts/exynos3250-rinato.dts | 2 +-
> >>>>> 4 files changed, 4 insertions(+), 4 deletions(-)
> >>>>
> >>>> This looks totally independent to rest of patches so it can be applied
> >>>> separately without any functional impact (except lack of minimum
> >>>> frequency). Is that correct?
> >>>
> >>> You're right. I will split the patches. And will resend.
> >>> Thanks!
> >>
> >> I think what Krzysztof was asking was just if he can simply pick up this patch
> >> alone, as it does not require any of the previous changes.
> >>
> >> Same is true for the Rockchip patches I guess, so we could just take them
> >> individually into samsung/rockchip dts branches.
> >
> > Yes, I wanted to get exactly this information. I couldn't find it in
> > cover letter.
>
> In drivers/mmc/core/host.c, there already is "max-frequency" property.
> It's same functionality with "clock-freq-min-max".
> Minimum clock value can be fixed to 100K. because MMC core will check clock value from 400K to 100K.
> But max-frequency can be difference.
> If we can use "max-frequency" property, we don't need to use "clock-freq-min-max" property anymore.
> I will resend the deprecated property instead of removing "clock-freq-min-max".
>
> If you want to pick this, it's possible to pick. Then i will resend the patches without dt patches.
Thanks, applied.
Best regards,
Krzysztof
--
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] ipmi/bt-bmc: maintain a request expiry list
From: Cédric Le Goater @ 2016-11-09 19:08 UTC (permalink / raw)
To: minyard-HInyCGIudOg,
openipmi-developer-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, Joel Stanley
Cc: Rob Herring, Arnd Bergmann, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Brendan Higgins
In-Reply-To: <1e0187c4-d503-ce4a-3d4c-cf21f0bffb96-HInyCGIudOg@public.gmane.org>
On 11/09/2016 04:52 PM, Corey Minyard wrote:
> On 11/09/2016 08:30 AM, Cédric Le Goater wrote:
>> On 11/07/2016 08:04 PM, Corey Minyard wrote:
>>> On 11/02/2016 02:57 AM, Cédric Le Goater wrote:
>>>> Regarding the response expiration handling, the IPMI spec says :
>>>>
>>>> The BMC must not return a given response once the corresponding
>>>> Request-to-Response interval has passed. The BMC can ensure this
>>>> by maintaining its own internal list of outstanding requests through
>>>> the interface. The BMC could age and expire the entries in the list
>>>> by expiring the entries at an interval that is somewhat shorter than
>>>> the specified Request-to-Response interval....
>>>>
>>>> To handle such case, we maintain list of received requests using the
>>>> seq number of the BT message to identify them. The list is updated
>>>> each time a request is received and a response is sent. The expiration
>>>> of the reponses is handled at each updates but also with a timer.
>>> This looks correct, but it seems awfully complicated.
>>>
>>> Why can't you get the current time before the wait_event_interruptible()
>>> and then compare the time before you do the write? That would seem to
>>> accomplish the same thing without any lists or extra locks.
>> Well, the expiry list needs a request identifier and it is currently using
>> the Seq byte for this purpose. So the BT message needs to be read to grab
>> that byte. The request is added to a list and that involves some locking.
>>
>> When the response is written, the first matching request is removed from
>> the list and a garbage collector loop is also run. Then, as we might not
>> get any responses to run that loop, we use a timer to empty the list from
>> any expired requests.
>>
>> The read/write ops of the driver are protected with a mutex, the list and
>> the timer add their share of locking. That could have been done with RCU
>> surely but we don't really need performance in this driver.
>>
>> Caveats :
>>
>> bt_bmc_remove_request() should not be done in the writing loop though.
>> It needs a fix.
>>
>> The request identifier is currently Seq but the spec say we should use
>> Seq, NetFn, and Command or an internal Seq value as a request identifier.
>> Google is also working on an OEM/Group extension (Brendan in CC: )
>> which has a different message format. I need to look closer at what
>> should be done in this case.
>
> I'm still not sure why the list is necessary. You have a separate
> thread of execution for each writer, why not just time it in that
> thread?
No, we don't in the current design. This is only a single process
acting as a proxy and dispatching commands on dbus to other
processes doing whatever they need to do. So the request/responses
can interlace.
The current daemon already handles an expiry list but I thought it
would be better to move it in the kernel to have a better response
time. The BMC can be quite slow when busy. It seems that keeping
the logic in user space is better. So let's have it that way. Not
a problem.
> What about the following, not even compile-tested, patch? I'm
> sure my mailer will munge this up, I can send you a clean version
> if you like.
No it is ok. I will give your fix a try on our system and resend.
Thanks,
C.
> From 1a73585a9c1c74ac1d59d82f22e05b30447619a6 Mon Sep 17 00:00:00 2001
> From: Corey Minyard <cminyard-Igf4POYTYCDQT0dZR+AlfA@public.gmane.org>
> Date: Wed, 9 Nov 2016 09:07:48 -0600
> Subject: [PATCH] ipmi:bt-bmc: Fix a multi-user race, time out responses
>
> The IPMI spec says to time out responses after a given amount of
> time, so don't let a writer send something after an amount of time
> has elapsed.
>
> Also, fix a race condition in the same area where if you have two
> writers at the same time, one can get a EIO return when it should
> still be waiting its turn to send. A mutex_lock_interruptible_timeout()
> would be handy here, but it doesn't exist.
>
> Signed-off-by: Corey Minyard <cminyard-Igf4POYTYCDQT0dZR+AlfA@public.gmane.org>
> ---
> drivers/char/ipmi/bt-bmc.c | 39 ++++++++++++++++++++++++---------------
> 1 file changed, 24 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/char/ipmi/bt-bmc.c b/drivers/char/ipmi/bt-bmc.c
> index b49e613..5be94cf 100644
> --- a/drivers/char/ipmi/bt-bmc.c
> +++ b/drivers/char/ipmi/bt-bmc.c
> @@ -57,6 +57,8 @@
>
> #define BT_BMC_BUFFER_SIZE 256
>
> +#define BT_BMC_RESPONSE_JIFFIES (5 * HZ)
> +
> struct bt_bmc {
> struct device dev;
> struct miscdevice miscdev;
> @@ -190,14 +192,12 @@ static ssize_t bt_bmc_read(struct file *file, char __user *buf,
>
> WARN_ON(*ppos);
>
> - if (wait_event_interruptible(bt_bmc->queue,
> - bt_inb(bt_bmc, BT_CTRL) & BT_CTRL_H2B_ATN))
> + if (mutex_lock_interruptible(&bt_bmc->mutex))
> return -ERESTARTSYS;
>
> - mutex_lock(&bt_bmc->mutex);
> -
> - if (unlikely(!(bt_inb(bt_bmc, BT_CTRL) & BT_CTRL_H2B_ATN))) {
> - ret = -EIO;
> + if (wait_event_interruptible(bt_bmc->queue,
> + bt_inb(bt_bmc, BT_CTRL) & BT_CTRL_H2B_ATN)) {
> + ret = -ERESTARTSYS;
> goto out_unlock;
> }
>
> @@ -251,6 +251,7 @@ static ssize_t bt_bmc_write(struct file *file, const char __user *buf,
> u8 kbuffer[BT_BMC_BUFFER_SIZE];
> ssize_t ret = 0;
> ssize_t nwritten;
> + unsigned long start_jiffies = jiffies, wait_time;
>
> /*
> * send a minimum response size
> @@ -263,23 +264,31 @@ static ssize_t bt_bmc_write(struct file *file, const char __user *buf,
>
> WARN_ON(*ppos);
>
> + if (mutex_lock_interruptible(&bt_bmc->mutex))
> + return -ERESTARTSYS;
> +
> + wait_time = jiffies - start_jiffies;
> + if (wait_time >= BT_BMC_RESPONSE_TIME_JIFFIES) {
> + ret = -ETIMEDOUT;
> + goto out_unlock;
> + }
> + wait_time = BT_BMC_RESPONSE_TIME_JIFFIES - wait_time;
> +
> /*
> * There's no interrupt for clearing bmc busy so we have to
> * poll
> */
> - if (wait_event_interruptible(bt_bmc->queue,
> + ret = wait_event_interruptible_timeout(bt_bmc->queue,
> !(bt_inb(bt_bmc, BT_CTRL) &
> - (BT_CTRL_H_BUSY | BT_CTRL_B2H_ATN))))
> - return -ERESTARTSYS;
> -
> - mutex_lock(&bt_bmc->mutex);
> -
> - if (unlikely(bt_inb(bt_bmc, BT_CTRL) &
> - (BT_CTRL_H_BUSY | BT_CTRL_B2H_ATN))) {
> - ret = -EIO;
> + (BT_CTRL_H_BUSY | BT_CTRL_B2H_ATN)),
> + wait_time);
> + if (ret <= 0) {
> + if (ret == 0)
> + ret = -ETIMEDOUT;
> goto out_unlock;
> }
>
> + ret = 0;
> clr_wr_ptr(bt_bmc);
>
> while (count) {
--
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] of/irq: improve error message on irq discovery process failure
From: Guilherme G. Piccoli @ 2016-11-09 19:05 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linuxppc-dev,
Frank Rowand, linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <CAL_JsqL13-e5RGfafsLfP7EoJWTkAsuRG4mAF-t52GoDXeQS-Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 11/09/2016 04:05 PM, Rob Herring wrote:
> On Wed, Nov 9, 2016 at 8:05 AM, Guilherme G. Piccoli
> <gpiccoli-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org> wrote:
>> On PowerPC machines some PCI slots might not have Level-triggered
>> interrupts capability (also know as Level Signaled Interrupts - LSI),
>> leading of_irq_parse_pci() to complain by presenting error messages
>> on the kernel log - in this case, the properties "interrupt-map" and
>> "interrupt-map-mask" are not present on the device's node on device
>> tree.
>>
>> This patch introduces a different message for this specific case,
>> and it also reduces the level of the message from error to warning.
>> Before this patch, when an adapter was plugged in a slot without Level
>> interrupts capabilities, we saw generic error messages like this:
>>
>> [54.239] pci 002d:70:00.0: of_irq_parse_pci() failed with rc=-22
>>
>> Now, with this applied, we see the following specific message:
>>
>> [19.947] pci 0014:60:00.0: of_irq_parse_pci() gave up. The slot of this
>> device has no Level-triggered Interrupts capability.
>>
>> No functional changes were introduced.
>>
>> Signed-off-by: Guilherme G. Piccoli <gpiccoli-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
>> ---
>> drivers/of/irq.c | 5 ++++-
>> drivers/of/of_pci_irq.c | 8 +++++++-
>> 2 files changed, 11 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/of/irq.c b/drivers/of/irq.c
>> index 393fea8..1ad6882 100644
>> --- a/drivers/of/irq.c
>> +++ b/drivers/of/irq.c
>> @@ -275,7 +275,10 @@ int of_irq_parse_raw(const __be32 *addr, struct of_phandle_args *out_irq)
>> of_node_put(ipar);
>> of_node_put(newpar);
>>
>> - return -EINVAL;
>> + /* Positive non-zero return means no Level-triggered Interrupts
>> + * capability was found.
>> + */
>> + return ENOENT;
>
> It's not really a normal pattern to return positive errno values. You
> should return a negative value and check for that specific error value
> or perhaps move the print statement into this function.
Thanks Rob! I thought about it, I had the option to differentiate the
errors through the value or the sign - ended up taking the wrong way it
seems heheh
I'll send a V2 with this change.
Printing the warning inside of_irq_parse_raw() would require more
changes to the logic, it was my first choice but I changed way during
the implementation.
Cheers,
Guilherme
>
> Rob
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] of/irq: improve error message on irq discovery process failure
From: Mark Rutland @ 2016-11-09 19:04 UTC (permalink / raw)
To: Guilherme G. Piccoli
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-pci-u79uwXL29TY76Z2rM5mHXA,
frowand.list-Re5JQEeQqe8AvxtiuMwx3w,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, marc.zyngier-5wv7dgnIgG8
In-Reply-To: <1478700308-25481-1-git-send-email-gpiccoli-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
On Wed, Nov 09, 2016 at 12:05:08PM -0200, Guilherme G. Piccoli wrote:
> On PowerPC machines some PCI slots might not have Level-triggered
> interrupts capability (also know as Level Signaled Interrupts - LSI),
> leading of_irq_parse_pci() to complain by presenting error messages
> on the kernel log - in this case, the properties "interrupt-map" and
> "interrupt-map-mask" are not present on the device's node on device
> tree.
If we don't have an interrupt-map on a PCI controller, why don't we
instead log a message regarding that being missing, and give up early?
That sounds like a more generically useful error message; it's also
possible that a DT author simply forgot to add the map, and the platform
has suitable interrupts wired up.
> This patch introduces a different message for this specific case,
> and it also reduces the level of the message from error to warning.
> Before this patch, when an adapter was plugged in a slot without Level
> interrupts capabilities, we saw generic error messages like this:
>
> [54.239] pci 002d:70:00.0: of_irq_parse_pci() failed with rc=-22
>
> Now, with this applied, we see the following specific message:
>
> [19.947] pci 0014:60:00.0: of_irq_parse_pci() gave up. The slot of this
> device has no Level-triggered Interrupts capability.
Following my above example, this has gone from opaque to potentially
misleading.
Thanks,
Mark.
--
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 00/13] mmc: dw_mmc: cleans the codes for dwmmc controller
From: Heiko Stuebner @ 2016-11-09 18:55 UTC (permalink / raw)
To: Jaehoon Chung
Cc: linux-mmc, devicetree, linux-kernel, linux-arm-kernel,
linux-samsung-soc, linux-rockchip, ulf.hansson, robh+dt, krzk,
shawn.lin
In-Reply-To: <20161103062135.10697-1-jh80.chung@samsung.com>
Am Donnerstag, 3. November 2016, 15:21:22 CET schrieb Jaehoon Chung:
> This patchset is modified the some minor fixing and cleaning code.
> If needs to split the patches, i will re-send the patches.
>
> * Major changes
> - Use the cookie enum values like sdhci controller.
> - Remove the unnecessary codes and use stop_abort() by default.
> - Remove the obsoleted property "supports-highspeed"
> - Remove the "clock-freq-min-max" property. Instead, use "max-frequency"
> - Minimum clock value is set to 100K by default.
>
> Jaehoon Chung (13):
> mmc: dw_mmc: display the real register value on debugfs
> mmc: dw_mmc: fix the debug message for checking card's present
> mmc: dw_mmc: change the DW_MCI_FREQ_MIN from 400K to 100K
> mmc: dw_mmc: use the hold register when send stop command
> mmc: dw_mmc: call the dw_mci_prep_stop_abort() by default
> mmc: core: move the cookie's enum values from sdhci.h to mmc.h
> mmc: dw_mmc: use the cookie's enum values for post/pre_req()
> mmc: dw_mmc: remove the unnecessary mmc_data structure
patches 1-8 on rk3036, rk3288, rk3368 and rk3399 Rockchip platforms
Tested-by: Heiko Stuebner <heiko@sntech.de>
^ permalink raw reply
* Re: [PATCH 2/2] ASoC: axentia: tse850: add ASoC driver for the Axentia TSE-850
From: Peter Rosin @ 2016-11-09 18:54 UTC (permalink / raw)
To: Mark Brown
Cc: linux-kernel, Liam Girdwood, Rob Herring, Mark Rutland,
Jaroslav Kysela, Takashi Iwai, alsa-devel, devicetree,
Nicolas Ferre
In-Reply-To: <3d6b99e8-f19f-51fd-1676-c3a4549ec312@axentia.se>
On 2016-11-09 17:27, Peter Rosin wrote:
> On 2016-11-09 14:38, Mark Brown wrote:
>> On Tue, Nov 08, 2016 at 05:20:57PM +0100, Peter Rosin wrote:
>>> + struct snd_soc_pcm_runtime *rtd = substream->private_data;
>>> + struct device *dev = rtd->dev;
>>> + struct snd_soc_dai *cpu_dai = rtd->cpu_dai;
>>> + int dir = substream->stream != SNDRV_PCM_STREAM_PLAYBACK;
>>> + int div_id = dir ? ATMEL_SSC_RCMR_PERIOD : ATMEL_SSC_TCMR_PERIOD;
>>> + int period = snd_soc_params_to_frame_size(params) / 2 - 1;
>>
>> Please write the logic out as normal if statements for legibility. It's
>> a bit concerning that we even need this function, it looks like pretty
>> basic stuff that I'd expect the CPU DAI to just be doing - why can't
>> this be the default behaviour of the CPU DAI?
>
> I don't know and obviously don't have all the relevant HW to test
> changes. Do you want me to attempt such a change anyway?
> Adding Cc: Nicolas Ferre
Something like this, perhaps?
Cheers,
Peter
diff --git a/sound/soc/atmel/atmel_ssc_dai.c b/sound/soc/atmel/atmel_ssc_dai.c
index 16e459aedffe..059b0b63bd51 100644
--- a/sound/soc/atmel/atmel_ssc_dai.c
+++ b/sound/soc/atmel/atmel_ssc_dai.c
@@ -380,6 +380,7 @@ static void atmel_ssc_shutdown(struct snd_pcm_substream *substream,
ssc_writel(ssc_p->ssc->regs, CR, SSC_BIT(CR_SWRST));
/* Clear the SSC dividers */
ssc_p->cmr_div = ssc_p->tcmr_period = ssc_p->rcmr_period = 0;
+ ssc_p->forced_divider = 0;
}
spin_unlock_irq(&ssc_p->lock);
@@ -429,10 +430,12 @@ static int atmel_ssc_set_dai_clkdiv(struct snd_soc_dai *cpu_dai,
break;
case ATMEL_SSC_TCMR_PERIOD:
+ ssc_p->forced_divider |= BIT(ATMEL_SSC_TCMR_PERIOD);
ssc_p->tcmr_period = div;
break;
case ATMEL_SSC_RCMR_PERIOD:
+ ssc_p->forced_divider |= BIT(ATMEL_SSC_RCMR_PERIOD);
ssc_p->rcmr_period = div;
break;
@@ -459,6 +462,8 @@ static int atmel_ssc_hw_params(struct snd_pcm_substream *substream,
u32 tfmr, rfmr, tcmr, rcmr;
int ret;
int fslen, fslen_ext;
+ u32 tcmr_period;
+ u32 rcmr_period;
/*
* Currently, there is only one set of dma params for
@@ -470,6 +475,13 @@ static int atmel_ssc_hw_params(struct snd_pcm_substream *substream,
else
dir = 1;
+ tcmr_period = ssc_p->tcmr_period;
+ if (!(ssc_p->forced_divider & BIT(ATMEL_SSC_TCMR_PERIOD)))
+ tcmr_period = snd_soc_params_to_frame_size(params) / 2 - 1;
+ rcmr_period = ssc_p->rcmr_period;
+ if (!(ssc_p->forced_divider & BIT(ATMEL_SSC_RCMR_PERIOD)))
+ rcmr_period = snd_soc_params_to_frame_size(params) / 2 - 1;
+
dma_params = ssc_p->dma_params[dir];
channels = params_channels(params);
@@ -524,7 +536,7 @@ static int atmel_ssc_hw_params(struct snd_pcm_substream *substream,
fslen_ext = (bits - 1) / 16;
fslen = (bits - 1) % 16;
- rcmr = SSC_BF(RCMR_PERIOD, ssc_p->rcmr_period)
+ rcmr = SSC_BF(RCMR_PERIOD, rcmr_period)
| SSC_BF(RCMR_STTDLY, START_DELAY)
| SSC_BF(RCMR_START, SSC_START_FALLING_RF)
| SSC_BF(RCMR_CKI, SSC_CKI_RISING)
@@ -540,7 +552,7 @@ static int atmel_ssc_hw_params(struct snd_pcm_substream *substream,
| SSC_BF(RFMR_LOOP, 0)
| SSC_BF(RFMR_DATLEN, (bits - 1));
- tcmr = SSC_BF(TCMR_PERIOD, ssc_p->tcmr_period)
+ tcmr = SSC_BF(TCMR_PERIOD, tcmr_period)
| SSC_BF(TCMR_STTDLY, START_DELAY)
| SSC_BF(TCMR_START, SSC_START_FALLING_RF)
| SSC_BF(TCMR_CKI, SSC_CKI_FALLING)
@@ -606,7 +618,7 @@ static int atmel_ssc_hw_params(struct snd_pcm_substream *substream,
fslen_ext = (bits - 1) / 16;
fslen = (bits - 1) % 16;
- rcmr = SSC_BF(RCMR_PERIOD, ssc_p->rcmr_period)
+ rcmr = SSC_BF(RCMR_PERIOD, rcmr_period)
| SSC_BF(RCMR_STTDLY, START_DELAY)
| SSC_BF(RCMR_START, SSC_START_FALLING_RF)
| SSC_BF(RCMR_CKI, SSC_CKI_RISING)
@@ -623,7 +635,7 @@ static int atmel_ssc_hw_params(struct snd_pcm_substream *substream,
| SSC_BF(RFMR_LOOP, 0)
| SSC_BF(RFMR_DATLEN, (bits - 1));
- tcmr = SSC_BF(TCMR_PERIOD, ssc_p->tcmr_period)
+ tcmr = SSC_BF(TCMR_PERIOD, tcmr_period)
| SSC_BF(TCMR_STTDLY, START_DELAY)
| SSC_BF(TCMR_START, SSC_START_FALLING_RF)
| SSC_BF(TCMR_CKI, SSC_CKI_FALLING)
@@ -650,7 +662,7 @@ static int atmel_ssc_hw_params(struct snd_pcm_substream *substream,
* MCK divider, and the BCLK signal is output
* on the SSC TK line.
*/
- rcmr = SSC_BF(RCMR_PERIOD, ssc_p->rcmr_period)
+ rcmr = SSC_BF(RCMR_PERIOD, rcmr_period)
| SSC_BF(RCMR_STTDLY, 1)
| SSC_BF(RCMR_START, SSC_START_RISING_RF)
| SSC_BF(RCMR_CKI, SSC_CKI_RISING)
@@ -665,7 +677,7 @@ static int atmel_ssc_hw_params(struct snd_pcm_substream *substream,
| SSC_BF(RFMR_LOOP, 0)
| SSC_BF(RFMR_DATLEN, (bits - 1));
- tcmr = SSC_BF(TCMR_PERIOD, ssc_p->tcmr_period)
+ tcmr = SSC_BF(TCMR_PERIOD, tcmr_period)
| SSC_BF(TCMR_STTDLY, 1)
| SSC_BF(TCMR_START, SSC_START_RISING_RF)
| SSC_BF(TCMR_CKI, SSC_CKI_FALLING)
diff --git a/sound/soc/atmel/atmel_ssc_dai.h b/sound/soc/atmel/atmel_ssc_dai.h
index 80b153857a88..75194f582131 100644
--- a/sound/soc/atmel/atmel_ssc_dai.h
+++ b/sound/soc/atmel/atmel_ssc_dai.h
@@ -113,6 +113,7 @@ struct atmel_ssc_info {
unsigned short cmr_div;
unsigned short tcmr_period;
unsigned short rcmr_period;
+ unsigned int forced_divider;
struct atmel_pcm_dma_params *dma_params[2];
struct atmel_ssc_state ssc_state;
unsigned long mck_rate;
--
2.1.4
^ permalink raw reply related
* Re: [PATCH v8 3/3] fpga: Add support for Lattice iCE40 FPGAs
From: Joel Holdsworth @ 2016-11-09 18:54 UTC (permalink / raw)
To: Marek Vasut, Moritz Fischer
Cc: Alan Tull, Geert Uytterhoeven, Rob Herring, Devicetree List,
Linux Kernel Mailing List, linux-spi-u79uwXL29TY76Z2rM5mHXA,
Clifford Wolf
In-Reply-To: <a580bfa4-7852-aaf8-3a44-24da717f3d51-ynQEQJNshbs@public.gmane.org>
On 09/11/16 11:39, Marek Vasut wrote:
> On 11/09/2016 07:37 PM, Joel Holdsworth wrote:
>> On 09/11/16 05:01, Marek Vasut wrote:
>>> On 11/08/2016 06:30 PM, Joel Holdsworth wrote:
>>>>>>> On the whole, I don't think the zero-length transfers are too
>>>>>>> egregiously bad, and all the alternatives seem worse to me.
>>>>>>
>>>>>> So why not turn the CS line into GPIO and just toggle the GPIO?
>>>>>
>>>>> Does that work with *all* SPI controllers?
>>>>>
>>>>
>>>> It does not - no. See my other email.
>>>
>>> And is that line an actual CS of that lattice chip or a generic input
>>> which almost works like CS?
>>>
>>
>> I mean a generic output vs. a special CS output built into the SPI
>> master of the application processor. Take a look at how spi_set_cs(..)
>> works:
>
> No. I am asking whether the signal which is INPUT on the iCE40 side is
> really a chipselect signal for the SPI bus OR something which mostly
> behaves/looks like a chipselect but is not really a chipselect.
Oh I see. The SS_B line is the SPI SlaveSelect for the configuration port.
This is the text from the datasheet:
"SPI Slave Select. Active Low. Includes an internal weak pull-up
resistor to VCC_SPI during configuration. During configuration, the
logic level sampled on this pin deter-mines the configuration mode used
by the iCE40 device. An input when sampled at the start of
configuration. An input when in SPI Peripheral configuration mode
(SPI_SS_B = Low). An output when in Master SPI Flash configuration mode."
So yes - it is a "real" SPI chip-select line.
Joel
--
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 01/30] usb: dwc2: Deprecate g-use-dma binding
From: John Youn @ 2016-11-09 18:47 UTC (permalink / raw)
To: Felipe Balbi, John Youn, linux-usb-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Caesar Wang,
Shawn Lin, linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Russell King,
Matthias Brugger, Wei Xu, Andy Yan, Mark Rutland, Will Deacon,
Catalin Marinas, Heiko Stuebner
In-Reply-To: <87zil9gkcq.fsf-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
On 11/8/2016 11:54 PM, Felipe Balbi wrote:
>
> Hi,
>
> John Youn <John.Youn-HKixBCOQz3hWk0Htik3J/w@public.gmane.org> writes:
>> On 11/8/2016 1:12 AM, Felipe Balbi wrote:
>>>
>>> Hi,
>>>
>>> John Youn <johnyoun-HKixBCOQz3hWk0Htik3J/w@public.gmane.org> writes:
>>>> Add a vendor prefix and make the name more consistent by renaming it to
>>>> "snps,gadget-dma-enable".
>>>>
>>>> Signed-off-by: John Youn <johnyoun-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
>>>> ---
>>>> Documentation/devicetree/bindings/usb/dwc2.txt | 5 ++++-
>>>> arch/arm/boot/dts/rk3036.dtsi | 2 +-
>>>> arch/arm/boot/dts/rk3288.dtsi | 2 +-
>>>> arch/arm/boot/dts/rk3xxx.dtsi | 2 +-
>>>> arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 2 +-
>>>> arch/arm64/boot/dts/rockchip/rk3368.dtsi | 2 +-
>>>> drivers/usb/dwc2/params.c | 9 ++++++++-
>>>> drivers/usb/dwc2/pci.c | 2 +-
>>>> 8 files changed, 18 insertions(+), 8 deletions(-)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/usb/dwc2.txt b/Documentation/devicetree/bindings/usb/dwc2.txt
>>>> index 9472111..389a461 100644
>>>> --- a/Documentation/devicetree/bindings/usb/dwc2.txt
>>>> +++ b/Documentation/devicetree/bindings/usb/dwc2.txt
>>>> @@ -26,11 +26,14 @@ Refer to phy/phy-bindings.txt for generic phy consumer properties
>>>> - dr_mode: shall be one of "host", "peripheral" and "otg"
>>>> Refer to usb/generic.txt
>>>> - snps,host-dma-disable: disable host DMA mode.
>>>> -- g-use-dma: enable dma usage in gadget driver.
>>>> +- snps,gadget-dma-enable: enable gadget DMA mode.
>>>
>>> I don't see why you even have this binding. Looking through the code,
>>> you have:
>>>
>>> #define GHWCFG2_SLAVE_ONLY_ARCH 0
>>> #define GHWCFG2_EXT_DMA_ARCH 1
>>> #define GHWCFG2_INT_DMA_ARCH 2
>>>
>>> void dwc2_set_param_dma_enable(struct dwc2_hsotg *hsotg, int val)
>>> {
>>> int valid = 1;
>>>
>>> if (val > 0 && hsotg->hw_params.arch == GHWCFG2_SLAVE_ONLY_ARCH)
>>> valid = 0;
>>> if (val < 0)
>>> valid = 0;
>>>
>>> if (!valid) {
>>> if (val >= 0)
>>> dev_err(hsotg->dev,
>>> "%d invalid for dma_enable parameter. Check HW configuration.\n",
>>> val);
>>> val = hsotg->hw_params.arch != GHWCFG2_SLAVE_ONLY_ARCH;
>>> dev_dbg(hsotg->dev, "Setting dma_enable to %d\n", val);
>>> }
>>>
>>> hsotg->core_params->dma_enable = val;
>>> }
>>>
>>> which seems to hint that DMA support is discoverable. If there is DMA,
>>> why would disable it?
>>>
>>
>> Yes that's the case and I would prefer to make it discoverable and
>> enabled by default.
>>
>> But the legacy behavior has always been like this because DMA was
>> never fully implemented in the gadget driver and it was an opt-in
>> feature. Periodic support was only added recently.
>
> legacy behavior can be changed if another 'policy' makes more
> sense. IMHO, whatever can be discovered in runtime, should be enabled by
> default. That way, we force people to use it and find bugs in certain
> features.
Sounds good to me. I'll make the changes.
Regards,
John
--
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 v2 2/2] mmc: sdhci-iproc: support standard byte register accesses
From: Scott Branden @ 2016-11-09 18:43 UTC (permalink / raw)
To: Adrian Hunter, Ulf Hansson, Rob Herring, Mark Rutland, Ray Jui,
Scott Branden
Cc: BCM Kernel Feedback, linux-mmc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Srinath Mannam
In-Reply-To: <132c772b-d4b9-c4b6-2eca-0393e7c995f9-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Hi Adrian/Ulf,
Please ignore my comments in last email I sent out. The v2 patch
documentation matches the code and is good. I am confusing myself
between internal versions and external upstream versions of this code.
On 16-11-09 10:38 AM, Scott Branden wrote:
> Hi Adrian/Ulf,
>
> On 16-11-08 01:55 AM, Adrian Hunter wrote:
>> On 01/11/16 18:37, Scott Branden wrote:
>>> Add bytewise register accesses support for newer versions of IPROC
>>> SDHCI controllers.
>>> Previous sdhci-iproc versions of SDIO controllers
>>> (such as Raspberry Pi and Cygnus) only allowed for 32-bit register
>>> accesses.
>>>
>>> Signed-off-by: Srinath Mannam <srinath.mannam-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
>>> Signed-off-by: Scott Branden <scott.branden-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
>>
>> This is unchanged from V1 which I acked, so:
> I updated the binding name in the documentation but forgot to change it
> in this patch. Now that Rob has ack'd the binding documentation I will
> send out an updated patch with binding string in the code matching the
> ack'd documentation.
Ignore this - PATCH v2 is good.
>
>>
>> Acked-by: Adrian Hunter <adrian.hunter-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
>>
> With the minor change I will add your ack to the next version I send out.
>
> Thanks,
> Scott
--
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 v8 3/3] fpga: Add support for Lattice iCE40 FPGAs
From: Marek Vasut @ 2016-11-09 18:39 UTC (permalink / raw)
To: Joel Holdsworth, Moritz Fischer
Cc: Alan Tull, Geert Uytterhoeven, Rob Herring, Devicetree List,
Linux Kernel Mailing List, linux-spi, Clifford Wolf
In-Reply-To: <5828eb84-ab29-49e2-34f0-3cd7e527ca66@airwebreathe.org.uk>
On 11/09/2016 07:37 PM, Joel Holdsworth wrote:
> On 09/11/16 05:01, Marek Vasut wrote:
>> On 11/08/2016 06:30 PM, Joel Holdsworth wrote:
>>>>>> On the whole, I don't think the zero-length transfers are too
>>>>>> egregiously bad, and all the alternatives seem worse to me.
>>>>>
>>>>> So why not turn the CS line into GPIO and just toggle the GPIO?
>>>>
>>>> Does that work with *all* SPI controllers?
>>>>
>>>
>>> It does not - no. See my other email.
>>
>> And is that line an actual CS of that lattice chip or a generic input
>> which almost works like CS?
>>
>
> I mean a generic output vs. a special CS output built into the SPI
> master of the application processor. Take a look at how spi_set_cs(..)
> works:
No. I am asking whether the signal which is INPUT on the iCE40 side is
really a chipselect signal for the SPI bus OR something which mostly
behaves/looks like a chipselect but is not really a chipselect.
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/spi/spi.c?id=refs/tags/v4.9-rc4#n695
>
>
> static void spi_set_cs(struct spi_device *spi, bool enable)
> {
> if (spi->mode & SPI_CS_HIGH)
> enable = !enable;
>
> if (gpio_is_valid(spi->cs_gpio))
> gpio_set_value(spi->cs_gpio, !enable);
> else if (spi->master->set_cs)
> spi->master->set_cs(spi, !enable);
> }
>
> So on some SPI masters, spi->master->set_cs is handled separately from
> normal GPIOs. Hence why I want to use this machinery, rather than doing
> it with a GPIO.
This is not relevant. FYI: using separate GPIO as a SPI chip select has
it's own problems.
--
Best regards,
Marek Vasut
^ permalink raw reply
* Re: [PATCH v2 2/2] mmc: sdhci-iproc: support standard byte register accesses
From: Scott Branden @ 2016-11-09 18:38 UTC (permalink / raw)
To: Adrian Hunter, Ulf Hansson, Rob Herring, Mark Rutland, Ray Jui,
Scott Branden
Cc: BCM Kernel Feedback, linux-mmc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Srinath Mannam
In-Reply-To: <c94dc018-5a2d-d50b-5746-43ae7fc258ce-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Hi Adrian/Ulf,
On 16-11-08 01:55 AM, Adrian Hunter wrote:
> On 01/11/16 18:37, Scott Branden wrote:
>> Add bytewise register accesses support for newer versions of IPROC
>> SDHCI controllers.
>> Previous sdhci-iproc versions of SDIO controllers
>> (such as Raspberry Pi and Cygnus) only allowed for 32-bit register
>> accesses.
>>
>> Signed-off-by: Srinath Mannam <srinath.mannam-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
>> Signed-off-by: Scott Branden <scott.branden-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
>
> This is unchanged from V1 which I acked, so:
I updated the binding name in the documentation but forgot to change it
in this patch. Now that Rob has ack'd the binding documentation I will
send out an updated patch with binding string in the code matching the
ack'd documentation.
>
> Acked-by: Adrian Hunter <adrian.hunter-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
>
With the minor change I will add your ack to the next version I send out.
Thanks,
Scott
--
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 v8 3/3] fpga: Add support for Lattice iCE40 FPGAs
From: Joel Holdsworth @ 2016-11-09 18:37 UTC (permalink / raw)
To: Marek Vasut, Moritz Fischer
Cc: Alan Tull, Geert Uytterhoeven, Rob Herring, Devicetree List,
Linux Kernel Mailing List, linux-spi, Clifford Wolf
In-Reply-To: <f7917987-a4cb-2840-8128-07eebd242c17@denx.de>
On 09/11/16 05:01, Marek Vasut wrote:
> On 11/08/2016 06:30 PM, Joel Holdsworth wrote:
>>>>> On the whole, I don't think the zero-length transfers are too
>>>>> egregiously bad, and all the alternatives seem worse to me.
>>>>
>>>> So why not turn the CS line into GPIO and just toggle the GPIO?
>>>
>>> Does that work with *all* SPI controllers?
>>>
>>
>> It does not - no. See my other email.
>
> And is that line an actual CS of that lattice chip or a generic input
> which almost works like CS?
>
I mean a generic output vs. a special CS output built into the SPI
master of the application processor. Take a look at how spi_set_cs(..)
works:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/spi/spi.c?id=refs/tags/v4.9-rc4#n695
static void spi_set_cs(struct spi_device *spi, bool enable)
{
if (spi->mode & SPI_CS_HIGH)
enable = !enable;
if (gpio_is_valid(spi->cs_gpio))
gpio_set_value(spi->cs_gpio, !enable);
else if (spi->master->set_cs)
spi->master->set_cs(spi, !enable);
}
So on some SPI masters, spi->master->set_cs is handled separately from
normal GPIOs. Hence why I want to use this machinery, rather than doing
it with a GPIO.
Joel
^ permalink raw reply
* Re: [v16, 0/7] Fix eSDHC host version register bug
From: Ulf Hansson @ 2016-11-09 18:27 UTC (permalink / raw)
To: Yangbo Lu
Cc: Mark Rutland, Greg Kroah-Hartman, Xiaobo Xie, Minghuan Lian,
linux-clk, Qiang Zhao, Russell King, Bhupesh Sharma,
Jochen Friedrich, Claudiu Manoil,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Arnd Bergmann,
Scott Wood, Rob Herring,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-mmc,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Leo Li,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, Kumar Gala,
linuxppc-dev-uLR06cmDAlZmR6Xm/wNWPw
In-Reply-To: <1478661252-42439-1-git-send-email-yangbo.lu-3arQi8VN3Tc@public.gmane.org>
- i2c-list
On 9 November 2016 at 04:14, Yangbo Lu <yangbo.lu-3arQi8VN3Tc@public.gmane.org> wrote:
> This patchset is used to fix a host version register bug in the T4240-R1.0-R2.0
> eSDHC controller. To match the SoC version and revision, 15 previous version
> patchsets had tried many methods but all of them were rejected by reviewers.
> Such as
> - dts compatible method
> - syscon method
> - ifdef PPC method
> - GUTS driver getting SVR method
> Anrd suggested a soc_device_match method in v10, and this is the only available
> method left now. This v11 patchset introduces the soc_device_match interface in
> soc driver.
>
> The first four patches of Yangbo are to add the GUTS driver. This is used to
> register a soc device which contain soc version and revision information.
> The other three patches introduce the soc_device_match method in soc driver
> and apply it on esdhc driver to fix this bug.
>
> ---
> Changes for v15:
> - Dropped patch 'dt: bindings: update Freescale DCFG compatible'
> since the work had been done by below patch on ShawnGuo's linux tree.
> 'dt-bindings: fsl: add LS1043A/LS1046A/LS2080A compatible for SCFG
> and DCFG'
> - Fixed error code issue in guts driver
> Changes for v16:
> - Dropped patch 'powerpc/fsl: move mpc85xx.h to include/linux/fsl'
> - Added a bug-fix patch from Geert
> ---
>
> Arnd Bergmann (1):
> base: soc: introduce soc_device_match() interface
>
> Geert Uytterhoeven (1):
> base: soc: Check for NULL SoC device attributes
>
> Yangbo Lu (5):
> ARM64: dts: ls2080a: add device configuration node
> dt: bindings: move guts devicetree doc out of powerpc directory
> soc: fsl: add GUTS driver for QorIQ platforms
> MAINTAINERS: add entry for Freescale SoC drivers
> mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
>
> .../bindings/{powerpc => soc}/fsl/guts.txt | 3 +
> MAINTAINERS | 11 +-
> arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 6 +
> drivers/base/Kconfig | 1 +
> drivers/base/soc.c | 70 ++++++
> drivers/mmc/host/Kconfig | 1 +
> drivers/mmc/host/sdhci-of-esdhc.c | 20 ++
> drivers/soc/Kconfig | 3 +-
> drivers/soc/fsl/Kconfig | 18 ++
> drivers/soc/fsl/Makefile | 1 +
> drivers/soc/fsl/guts.c | 236 +++++++++++++++++++++
> include/linux/fsl/guts.h | 125 ++++++-----
> include/linux/sys_soc.h | 3 +
> 13 files changed, 447 insertions(+), 51 deletions(-)
> rename Documentation/devicetree/bindings/{powerpc => soc}/fsl/guts.txt (91%)
> create mode 100644 drivers/soc/fsl/Kconfig
> create mode 100644 drivers/soc/fsl/guts.c
>
> --
> 2.1.0.27.g96db324
>
Thanks, applied on my mmc tree for next!
I noticed that some DT compatibles weren't documented, according to
checkpatch. Please fix that asap!
Kind regards
Ulf Hansson
^ permalink raw reply
* Re: [PATCH v9 1/3] clk: qcom: Add support for SMD-RPM Clocks
From: Rob Herring @ 2016-11-09 18:26 UTC (permalink / raw)
To: Georgi Djakov
Cc: sboyd, mturquette, linux-clk, devicetree, mark.rutland,
linux-kernel, linux-arm-msm
In-Reply-To: <20161102155658.32203-2-georgi.djakov@linaro.org>
On Wed, Nov 02, 2016 at 05:56:56PM +0200, Georgi Djakov wrote:
> This adds initial support for clocks controlled by the Resource
> Power Manager (RPM) processor on some Qualcomm SoCs, which use
> the qcom_smd_rpm driver to communicate with RPM.
> Such platforms are msm8916, apq8084 and msm8974.
>
> The RPM is a dedicated hardware engine for managing the shared
> SoC resources in order to keep the lowest power profile. It
> communicates with other hardware subsystems via shared memory
> and accepts clock requests, aggregates the requests and turns
> the clocks on/off or scales them on demand.
>
> This driver is based on the codeaurora.org driver:
> https://www.codeaurora.org/cgit/quic/la/kernel/msm-3.10/tree/drivers/clk/qcom/clock-rpm.c
>
> Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
> ---
> .../devicetree/bindings/clock/qcom,rpmcc.txt | 36 ++
Acked-by: Rob Herring <robh@kernel.org>
> drivers/clk/qcom/Kconfig | 16 +
> drivers/clk/qcom/Makefile | 1 +
> drivers/clk/qcom/clk-smd-rpm.c | 571 +++++++++++++++++++++
> include/dt-bindings/clock/qcom,rpmcc.h | 45 ++
> 5 files changed, 669 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/clock/qcom,rpmcc.txt
> create mode 100644 drivers/clk/qcom/clk-smd-rpm.c
> create mode 100644 include/dt-bindings/clock/qcom,rpmcc.h
^ permalink raw reply
* Re: [PATCH v9 2/3] clk: qcom: Add support for RPM Clocks
From: Rob Herring @ 2016-11-09 18:26 UTC (permalink / raw)
To: Georgi Djakov
Cc: sboyd, mturquette, linux-clk, devicetree, mark.rutland,
linux-kernel, linux-arm-msm
In-Reply-To: <20161102155658.32203-3-georgi.djakov@linaro.org>
On Wed, Nov 02, 2016 at 05:56:57PM +0200, Georgi Djakov wrote:
> This adds initial support for clocks controlled by the Resource
> Power Manager (RPM) processor on some Qualcomm SoCs, which use
> the qcom_rpm driver to communicate with RPM.
> Such platforms are apq8064 and msm8960.
>
> Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
> ---
> .../devicetree/bindings/clock/qcom,rpmcc.txt | 1 +
Acked-by: Rob Herring <robh@kernel.org>
> drivers/clk/qcom/Kconfig | 13 +
> drivers/clk/qcom/Makefile | 1 +
> drivers/clk/qcom/clk-rpm.c | 489 +++++++++++++++++++++
> include/dt-bindings/clock/qcom,rpmcc.h | 24 +
> 5 files changed, 528 insertions(+)
> create mode 100644 drivers/clk/qcom/clk-rpm.c
^ 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