* [PATCH v5 3/9] vcodec: mediatek: Add Mediatek V4L2 Video Decoder Driver
From: Tiffany Lin @ 2016-10-24 3:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161021110104.5733240e@vento.lan>
Hi Mauro,
On Fri, 2016-10-21 at 11:01 -0200, Mauro Carvalho Chehab wrote:
> Em Fri, 2 Sep 2016 20:19:54 +0800
> Tiffany Lin <tiffany.lin@mediatek.com> escreveu:
>
> > Add v4l2 layer decoder driver for MT8173
> >
> > Signed-off-by: Tiffany Lin <tiffany.lin@mediatek.com>
>
> > +int vdec_if_init(struct mtk_vcodec_ctx *ctx, unsigned int fourcc)
> > +{
> > + int ret = 0;
> > +
> > + switch (fourcc) {
> > + case V4L2_PIX_FMT_H264:
> > + case V4L2_PIX_FMT_VP8:
> > + default:
> > + return -EINVAL;
> > + }
>
> Did you ever test this driver? The above code will *always* return
> -EINVAL, with will cause vidioc_vdec_s_fmt() to always fail!
>
> I suspect that what you wanted to do, instead, is:
>
> switch (fourcc) {
> case V4L2_PIX_FMT_H264:
> case V4L2_PIX_FMT_VP8:
> break;
> default:
> return -EINVAL;
>
The original idea here is that vp8 and h264 are added in later patches.
If get this patch without later patches, it should return -EINVAL.
> Btw, this patch series has also several issues that were pointed by
> checkpatch. Please *always* run checkpatch when submitting your work.
>
> You should take a look at the Kernel documentation about how to
> submit patches, at:
> https://mchehab.fedorapeople.org/kernel_docs/process/index.html
>
> PS.: this time, I fixed the checkpatch issues for you. So, let me know
> if the patch below is OK, and I'll merge it at media upstream,
> assuming that the other patches in this series are ok.
>
I did run checkpatch, but I don't know why these issues missed.
probably I run checkpatch for all files not for patches.
I will take a look at the documentation and keep this in mind for future
upstream.
Appreciated for your help.
best regards,
Tiffany
^ permalink raw reply
* [PATCH V4 1/3] ACPI, PCI, IRQ: assign ISA IRQ directly during early boot stages
From: Sinan Kaya @ 2016-10-24 3:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161021013930.GB31044@localhost>
On 10/20/2016 9:39 PM, Bjorn Helgaas wrote:
>> These API need to bypass the acpi_irq_get_penalty function.
> I don't mind this patch, but the changelog doesn't tell me what's
> broken and why we need this fix. Apparently acpi_irq_get_penalty()
> doesn't work before ACPI is initialized, but I don't see *why* it
> wouldn't work.
I'll update the commit message as you suggested. The code doesn't work
if we apply PATCH V4 2/3 + PATCH V4 3/3 without PATCH V4 1/3 since
the caller is going to end up calling get_penalty function while ACPI
is not initialized. This happened during the debug of this regression.
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH V7 4/4] dmaengine: qcom_hidma: add MSI support for interrupts
From: Sinan Kaya @ 2016-10-24 2:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHp75Vd+u5va3kyqcapeF9JATUfv5gBnoEM_W+frDmMXs5f2Uw@mail.gmail.com>
On 10/21/2016 12:11 PM, Andy Shevchenko wrote:
>> +static void hidma_free_msis(struct hidma_dev *dmadev)
>> > +{
>> > +#ifdef CONFIG_GENERIC_MSI_IRQ_DOMAIN
> Perhaps one #ifdef and two definitions of functions?
I don't think it will make a difference. I'll have to move
#ifdef around the caller of hidma_free_msis instead which
I think is uglier.
The hidma_write_msi_msg function gets called only when
CONFIG_GENERIC_MSI_IRQ_DOMAIN is defined. If I don't put
this around the function definition, I get unused function
warning from the compiler. This is the reason why preprocessor
definition is outside of the function definition.
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH v5 23/23] phy: Add support for Qualcomm's USB HS phy
From: Peter Chen @ 2016-10-24 2:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <147707842313.25848.12479294741874867656@sboyd-linaro>
On Fri, Oct 21, 2016 at 12:33:43PM -0700, Stephen Boyd wrote:
> Quoting Peter Chen (2016-10-20 19:20:30)
> > On Thu, Oct 20, 2016 at 04:20:38PM -0700, Stephen Boyd wrote:
> > > Quoting Stephen Boyd (2016-10-17 18:56:36)
> > > > +
> > > > +static int
> > > > +qcom_usb_hs_phy_vbus_notifier(struct notifier_block *nb, unsigned long event,
> > > > + void *ptr)
> > > > +{
> > > > + struct qcom_usb_hs_phy *uphy;
> > > > + int is_host;
> > > > + u8 addr;
> > > > +
> > > > + uphy = container_of(nb, struct qcom_usb_hs_phy, vbus_notify);
> > > > + is_host = extcon_get_cable_state_(uphy->id_edev, EXTCON_USB_HOST);
> > >
> > > Please don't apply this patch. This call now deadlocks on v4.9-rc1
> > > because of how extcon_get_cable_state_() now grabs a lock that is
> > > already held here when we're inside the notifier. It's not really
> > > required that we grab the lock in extcon there, but this has exposed a
> > > flaw in the logic anyway. We don't know if the id pin is going to toggle
> > > before or after this function is called, so we should really keep track
> > > of both vbus and id state in this driver and then do the same ulpi
> > > writes from two different notifiers for both vbus and id pin. We would
> > > be duplicating work sometimes, but that's pretty much the best solution
> > > I can come up with. Otherwise it's racy.
> > >
> >
> > Why you need to care id status? If EXTCON_USB event has happened, and
> > event is true, you can set, otherwise, it is clear operation, that's
> > to say you may not need have id extcon phandle, do you think so?
> >
>
> I need to add a comment to the code here because I forgot what was going
> on.
>
> Either way, this code is pulling D+ up when we're in device mode. We
> don't want to do the pullup if we're a host, and vbus extcon only tells
> us if the cable is attached so we can't just rely on that one bit of
> information.
>
> I suppose that's not really appropriate to do via extcon though in the
> phy driver though, so I'm thinking that it should be rewritten to use
> the phy_set_mode() feature of the phy framework. Basically,
> ci_udc_pullup() will call phy_set_mode() with PHY_MODE_USB_DEVICE or
> PHY_MODE_USB_HOST and then we can set or clear these bits in the ulpi
> register space. I think that will make things simpler here and things
> like soft-connect will work better. Sound good?
I agree with you, and you may notify controller role through
phy_set_mode at the controller probe and role switch routine.
--
Best Regards,
Peter Chen
^ permalink raw reply
* [PATCH v2 3/6] arm64: dts: lg1313: DT fix s/#interrupts-cells/#interrupt-cells/
From: Chanho Min @ 2016-10-24 2:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477039877-20227-4-git-send-email-geert+renesas@glider.be>
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> v2:
> - New.
> ---
Acked-by: Chanho Min <chanho.min@lge.com>
^ permalink raw reply
* [PATCH v2 2/6] arm64: dts: lg1312: DT fix s/#interrupts-cells/#interrupt-cells/
From: Chanho Min @ 2016-10-24 1:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477039877-20227-3-git-send-email-geert+renesas@glider.be>
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Acked-by: Rob Herring <robh@kernel.org>
> ---
> v2:
> - Add Acked-by,
> - Rebased.
> ---
Acked-by: Chanho Min <chanho.min@lge.com>
^ permalink raw reply
* [RFC PATCH 01/13] pinctrl: meson: Add GXL pinctrl definitions
From: Linus Walleij @ 2016-10-24 1:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477060838-14164-2-git-send-email-narmstrong@baylibre.com>
On Fri, Oct 21, 2016 at 4:40 PM, Neil Armstrong <narmstrong@baylibre.com> wrote:
> Add support for the Amlogic Meson GXL SoC, this is a partially complete
> definition only based on the Amlogic Vendor tree.
>
> This definition differs a lot from the GXBB and needs a separate entry.
>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Looks good to me. Tell me when I may apply it, it looks orthogonal
to the rest of the patches.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 2/2] gpio: mxs: fix duplicate level interrupts
From: Linus Walleij @ 2016-10-24 0:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161021131138.10467-3-s.hauer@pengutronix.de>
On Fri, Oct 21, 2016 at 3:11 PM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> According to the reference manual level interrupts can't be acked
> using the IRQSTAT registers. The effect is that when a level interrupt
> triggers the following ack is a no-op and the same interrupt triggers
> again right after it has been unmasked after running the interrupt
> handler.
>
> The reference manual says:
>
> Status bits for pins configured as level sensitive interrupts cannot be
> cleared unless either the actual pin is in the non-interrupting state, or
> the pin has been disabled as an interrupt source by clearing its bit in
> HW_PINCTRL_PIN2IRQ.
>
> To work around the duplicated interrupts we can use the PIN2IRQ
> rather than the IRQEN registers to mask the interrupts. This
> probably does not work for the edge interrupts, so we have to split up
> the irq chip into two chip types, one for the level interrupts and
> one for the edge interrupts. We now make use of two different enable
> registers, so we have to take care to always enable the right one,
> especially during switching of the interrupt type. An easy way
> to accomplish this is to use the IRQCHIP_SET_TYPE_MASKED which
> makes sure that set_irq_type is called with masked interrupts. With this
> the flow to change the irq type is like:
>
> - core masks interrupt (using the current chip type)
> - mxs_gpio_set_irq_type() changes chip type if necessary
> - mxs_gpio_set_irq_type() unconditionally sets the enable bit in the
> now unused enable register
> - core eventually unmasks the interrupt (using the new chip type)
>
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Patch applied with Marek's review tag.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 1/2] gpio: mxs: use enable/disable regs to (un)mask irqs
From: Linus Walleij @ 2016-10-24 0:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161021131138.10467-2-s.hauer@pengutronix.de>
On Fri, Oct 21, 2016 at 3:11 PM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> The mxs gpio controller does not only have a mask register to mask
> interrupts, but also enable/disable registers. Use the enable/disable
> registers rather than the mask register. This does not have any
> advantage for now, but makes the next patch simpler.
>
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Patch applied with Marek's review tag.
Yours,
Linus Walleij
^ permalink raw reply
* [BUG] LPC32xx gpio driver broken by commit 762c2e46 in 4.9-rc1
From: Linus Walleij @ 2016-10-24 0:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476807799.10214.25.camel@localhost>
On Tue, Oct 18, 2016 at 6:23 PM, Sylvain Lemieux
<slemieux.tyco@gmail.com> wrote:
> the current LPC32xx GPIO driver is broken by commit 762c2e46
> (gpio: of: remove of_gpiochip_and_xlate() and struct gg_data).
>
> A call to "of_get_named_gpio" to retrieve the GPIO will
> always return -EINVAL, except for the first GPIO bank.
>
> Prior to this commit, the driver was working properly
> because of the side-effect of the match function called by
> "gpiochip_find" inside "of_get_named_gpiod_flags" function.
(...)
> Is there any short-term solution that can be done with
> the existing driver to keep the LPC32xx platform working
> properly in the 4.9 mainline kernel?
Masahiro, what do you think is the best course to proceed here?
Can we
- Restore the behaviour prior to the patches or
- Fix up all users or
- Do we have to revert these two patches?
I would prefer not to revert, because I liked the cleanup a lot ...
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 6/8] pinctrl: aspeed-g4: Capture SuperIO pinmux dependency
From: Andrew Jeffery @ 2016-10-24 0:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdYZPcjGuRKVL6qwof1p7ZXT4EvwzAuz59oTgp9Z5Dzixw@mail.gmail.com>
On Mon, 2016-10-24 at 00:09 +0200, Linus Walleij wrote:
> On Fri, Oct 21, 2016 at 2:33 AM, Andrew Jeffery <andrew@aj.id.au> wrote:
>
> >
> > >
> > > Patch applied for v4.10.
> > > (Tell me if I'm applying patches in wrong order or something, and
> > > I hope this doesn't clash with the fixes.)
> > Both this patch and 8/8 functionally depend on 5/8. I fetched the
> > pinctrl tree to poke around but this patch didn't appear in any of the
> > updated branches, so I'm not sure whether we have the right ordering.
> > Without it we should hit build failures from missing macro definitions.
> >
> > Have you had a chance to look over patch 5/8? Joel wasn't keen on its
> > current form, so I would appreciate your input.
> Oops backed this patch out.
>
> Will look at 5/8.
>
> Appreciate if you repost the remaining patches in the series based on
> v4.9-rc2 once it's out, and I'll rebase the pinctrl tree onto that.
>
Will do!
Andrew
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161024/f42ae859/attachment-0001.sig>
^ permalink raw reply
* [PATCH 5/8] pinctrl: aspeed: Enable capture of off-SCU pinmux state
From: Andrew Jeffery @ 2016-10-24 0:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdazJzE=Oa-0-FEYTvUk=-kPLojHY3afZKX5cpmzrUZHGQ@mail.gmail.com>
On Mon, 2016-10-24 at 00:20 +0200, Linus Walleij wrote:
> On Thu, Sep 29, 2016 at 8:45 AM, Joel Stanley <joel@jms.id.au> wrote:
> >
> > On Wed, Sep 28, 2016 at 12:20 AM, Andrew Jeffery <andrew@aj.id.au> wrote:
> >
> > >
> > > On the AST2400 and AST2500 a number of pins depend on state in one of
> > > the SIO, LPC or GFX IP blocks, so add support to at least capture what
> > > that state is. The pinctrl engine for the Aspeed SoCs doesn't try to
> > > inspect or modify the state of the off-SCU IP blocks. Instead, it logs
> > > the state requirement with the expectation that the platform
> > > designer/maintainer arranges for the appropriate configuration to be
> > > applied through the associated drivers.
> (...)
> >
> >
> > This is unfortunate.
> >
> > This patch kicks the can down the road, but doesn't solve the problem
> > for a user who wants to configure some functionality that depends on
> > the non-SCU bits. Because of this I'm not sure if we want to put it in
> > the tree.
> >
> > However, I'm not sure what a proper solution would look like. Perhaps
> > Linus can point out another SoC that has a similar problem?
> If I could only understand it.
>
> Don't you actually want to go and read a few registers on another
> IO range?
Yes. I guess the hesitation was whether we should also write those
registers so we can apply the requested function.
>
> What we generally do when pin control is spread out in a system is try
> to consolidate it, meaning expose the necessary registers on the remote
> end using syscon (drivers/mfd/syscon) so that we can easily get a handle
> on these registers withe regmap MMIO.
>
> Since regmap handles atomic access to the registers, that way we
> protect from disasters and keep the state in the hardware.
This seems like the reasonable approach if we want to read/write those
registers. The affected IO ranges correspond to:
* SuperIO Controller (SIO)
* SOC Display Controller (GFX)
* LPC Controller (LPC)
SIO and LPC both perform a mishmash of functions and so likely would
use the mfd subsystem anyway. I don't yet have any arguments against
doing it for the GFX IO space. Joel?
>
> I don't know if this is helpful. For a normal peripheral you may not want
> to put a regmap over all its registers but you prefer to ioremap it, and then
> we get the spaghetti of accessor functions to peek and poke into another
> peripherals I/O space, and that is undesireable.
I briefly experimented with the idea of accessing the other IO spaces
but it felt dirty precisely for what would have become accessor
spaghetti. So I wound up with the lame approach in this patch, which
just punts on the problem. I think the mfd/syscon approach would work
well though.
It looks like the rockchip pinctrl bindings are doing something along
the lines of what we need with the rockchip,pmu phandle property. Is it
acceptable to create three properties, a phandle to grab each regmap
for the IO spaces above?
>
> Maybe this is completely not understanding what you want to do, so
> sorry, please elaborate.
No, seems you have understood what we need to do.
> I am afraid the two of you are the only people on
> the planet who actually understand what is going on here.
>
> Also the hardware engineer who wrote the Aspeed pin controller, I would
> like to read this persons design specification, I am pretty sure it is very
> interesting.
Well, presumably this engineer knows too :) And yes, I'd like to know
what constraints existed that forced this design as a solution. I'd
like my sanity back.
>
> >
> > >
> > > -??* @reg: The register offset from base in bytes
> > > +??* @reg: Split into three fields:
> > > +??*???????31:24: IP selector
> > > +??*???????23:12: Reserved
> > > +??*???????11:0: Register offset
> That seems like unnecessary shoehorning. Is it reflecting the register layout
> of the hardware or are you trying to save bits? For the latter, let it
> go and instead
> have one member for offset and one member for selector.
It doesn't represent the register layout. But saving bits also wasn't
the motivation, more avoiding a lot of code churn in the g4/g5 drivers
to populate a new member. Maybe that's a bad motivation. I'll have more
of a think about it.
Thanks for the feedback,
Andrew
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161024/93d37a58/attachment.sig>
^ permalink raw reply
* [PATCH -next] ARM: mediatek: add terminate entry for of_device_id tables
From: weiyongjun (A) @ 2016-10-24 0:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477222977-1336-1-git-send-email-weiyj.lk@gmail.com>
> -----Original Message-----
> From: Wei Yongjun [mailto:weiyj.lk at gmail.com]
> Sent: Sunday, October 23, 2016 7:43 PM
> To: Matthias Brugger <matthias.bgg@gmail.com>; Russell King
> <linux@armlinux.org.uk>
> Cc: weiyongjun (A) <weiyongjun1@huawei.com>; linux-arm-
> kernel at lists.infradead.org; linux-mediatek at lists.infradead.org; linux-
> kernel at vger.kernel.org
> Subject: [PATCH -next] ARM: mediatek: add terminate entry for
> of_device_id tables
>
> From: Wei Yongjun <weiyongjun1@huawei.com>
>
> Make sure of_device_id tables are NULL terminated.
>
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
> ---
> arch/arm/mach-mediatek/platsmp.c | 2 ++
> 1 file changed, 2 insertions(+)
>
Sorry, this patch is not correct since mtk_tz_smp_boot_infos is used
as ARRAY_SIZE(mtk_tz_smp_boot_infos), please ignore it.
Regards,
Yongjun Wei
^ permalink raw reply
* [PATCH v2] ARM: bcm2835: Add names for the Raspberry Pi GPIO lines
From: Linus Walleij @ 2016-10-24 0:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPoCmYKrUBEdyNXt8yRMFq_aCmb8WyK-x4a7og66zfeFYX4rQg@mail.gmail.com>
On Thu, Oct 20, 2016 at 6:58 PM, Gottfried Haider
<gottfried.haider@gmail.com> wrote:
> Somewhat off topic: is it planned to add
> support for setting GENERIC_PINCONF style pull-up/pull-down resistors
> throigh the new ABI?
Not planned, as in "I will do the job" but anticipated.
I expect that someone will come up with that usecase (indeed even the
Arduino is doing it) so that we will have to support it.
It's better than inventing a separate userspace ABI for pin control
anyways.
> (The bcm28xx drivers would still need to
> converted to this as well.)
All drivers that want to support it need converting I suspect.
>>> Regarding the proposed format using the header pin numbers: From what I've
>>> seen in terms of existing educational materials, it seems the overwhelming
>>> majority ends up using GPIO numbers instead of physical pin header
>>> numbering. (e.g. [1] [2])
>>
>> What does that number mean? If you are referring to the global
>> GPIO numberspace it is obsolete and just reflecting the fact that
>> people up until now was referring to Linux-internal GPIO numbers.
>
> I am referring to the name of the various GPIO lines as per datasheet
> ("GPIO0", "GPIO1", ...). So far, I believe those matched the global
> GPIO numberspace.
Aha. Yeah that is matching somewhat by chance these days, because:
static struct gpio_chip bcm2835_gpio_chip = {
.label = MODULE_NAME,
(...)
.base = -1,
(...)
};
That means this number is dynamicallly assigned and depend on
things like probe order or another GPIO chip failing etc.
> I understand that Linux can't guarantee a certain global GPIO number -
> but I fear that the board manufacturers also might not think of the
> pin headers as something set in stone (that the can't rearrange in a
> future revision/product).
Depends on which manufacturer. For 96boards there exist a document
specifying how they should be arranged and named:
https://github.com/96boards/documentation
Rpi would be wise to come up with something similar, but I have no
high hopes. We do need standardization and interoperability, but
it is not creating itself. :/
> Would there be a reason against _naming_ the pin "GPIO0"? (even if it
> ends up with a different global, internal number)
No not if it makes electronic sense, like if the schematic or SoC
uses that name, then use that if the board maintainer likes the idea.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v3 3/6] dt-bindings: pinctrl: Deprecate sunxi pinctrl bindings
From: Linus Walleij @ 2016-10-24 0:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6aec73cd3b9d3dbf1085d042ec6c23f385a300de.1476971126.git-series.maxime.ripard@free-electrons.com>
On Thu, Oct 20, 2016 at 3:49 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> The generic pin configuration and multiplexing should be preferred now,
> even though we still support the old one.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> Acked-by: Chen-Yu Tsai <wens@csie.org>
> Acked-by: Rob Herring <robh@kernel.org>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v3 2/6] pinctrl: sunxi: Support generic binding
From: Linus Walleij @ 2016-10-24 0:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <519ec867509f8033d9235a61f7979bd698906ab5.1476971126.git-series.maxime.ripard@free-electrons.com>
On Thu, Oct 20, 2016 at 3:49 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> Our bindings are mostly irrelevant now that we have generic pinctrl
> bindings that cover exactly the same uses cases.
>
> Add support for the new ones, and obviously keep our old binding support in
> order to keep the ABI stable.
>
> Acked-by: Chen-Yu Tsai <wens@csie.org>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v5 2/4] arm64: dts: add Allwinner A64 SoC .dtsi
From: André Przywara @ 2016-10-23 23:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <eb11a71c58cd85551d9d793437db1792abd5077c.1476986335.git-series.maxime.ripard@free-electrons.com>
On 20/10/16 19:00, Maxime Ripard wrote:
Hi Maxime,
> From: Andre Przywara <andre.przywara@arm.com>
>
> The Allwinner A64 SoC is a low-cost chip with 4 ARM Cortex-A53 cores
> and the typical tablet / TV box peripherals.
> The SoC is based on the (32-bit) Allwinner H3 chip, sharing most of
> the peripherals and the memory map.
> Although the cores are proper 64-bit ones, the whole SoC is actually
> limited to 4GB (including all the supported DRAM), so we use 32-bit
> address and size cells. This has the nice feature of us being able to
> reuse the DT for 32-bit kernels as well.
> This .dtsi lists the hardware that we support so far.
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> Acked-by: Rob Herring <robh@kernel.org>
> Acked-by: Chen-Yu Tsai <wens@csie.org>
> [Maxime: Convert to CCU binding, drop the MMC support for now]
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> ---
> Documentation/devicetree/bindings/arm/sunxi.txt | 1 +-
> MAINTAINERS | 1 +-
> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 263 +++++++++++++++++-
> 3 files changed, 265 insertions(+), 0 deletions(-)
> create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>
> diff --git a/Documentation/devicetree/bindings/arm/sunxi.txt b/Documentation/devicetree/bindings/arm/sunxi.txt
> index 3975d0a0e4c2..4d6467cc2aa2 100644
> --- a/Documentation/devicetree/bindings/arm/sunxi.txt
> +++ b/Documentation/devicetree/bindings/arm/sunxi.txt
> @@ -14,4 +14,5 @@ using one of the following compatible strings:
> allwinner,sun8i-a83t
> allwinner,sun8i-h3
> allwinner,sun9i-a80
> + allwinner,sun50i-a64
> nextthing,gr8
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 1cd38a7e0064..86488e92655f 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1019,6 +1019,7 @@ L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
> S: Maintained
> N: sun[x456789]i
> F: arch/arm/boot/dts/ntc-gr8*
> +F: arch/arm64/boot/dts/allwinner/
>
> ARM/Allwinner SoC Clock Support
> M: Emilio L?pez <emilio@elopez.com.ar>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> new file mode 100644
> index 000000000000..be51024743b4
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> @@ -0,0 +1,263 @@
> +/*
> + * Copyright (C) 2016 ARM Ltd.
> + * based on the Allwinner H3 dtsi:
> + * Copyright (C) 2015 Jens Kuske <jenskuske@gmail.com>
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + * a) This file is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * This file is distributed in the hope that 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.
> + *
> + * Or, alternatively,
> + *
> + * b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +#include <dt-bindings/clock/sun50i-a64-ccu.h>
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +#include <dt-bindings/pinctrl/sun4i-a10.h>
> +#include <dt-bindings/reset/sun50i-a64-ccu.h>
> +
> +/ {
> + interrupt-parent = <&gic>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu0: cpu at 0 {
> + compatible = "arm,cortex-a53", "arm,armv8";
> + device_type = "cpu";
> + reg = <0>;
> + enable-method = "psci";
> + };
> +
> + cpu1: cpu at 1 {
> + compatible = "arm,cortex-a53", "arm,armv8";
> + device_type = "cpu";
> + reg = <1>;
> + enable-method = "psci";
> + };
> +
> + cpu2: cpu at 2 {
> + compatible = "arm,cortex-a53", "arm,armv8";
> + device_type = "cpu";
> + reg = <2>;
> + enable-method = "psci";
> + };
> +
> + cpu3: cpu at 3 {
> + compatible = "arm,cortex-a53", "arm,armv8";
> + device_type = "cpu";
> + reg = <3>;
> + enable-method = "psci";
> + };
> + };
> +
> + osc24M: osc24M_clk {
> + #clock-cells = <0>;
> + compatible = "fixed-clock";
> + clock-frequency = <24000000>;
> + clock-output-names = "osc24M";
> + };
> +
> + osc32k: osc32k_clk {
> + #clock-cells = <0>;
> + compatible = "fixed-clock";
> + clock-frequency = <32768>;
> + clock-output-names = "osc32k";
> + };
> +
> + psci {
> + compatible = "arm,psci-0.2";
> + method = "smc";
> + };
> +
> + timer {
> + compatible = "arm,armv8-timer";
> + interrupts = <GIC_PPI 13
> + (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
> + <GIC_PPI 14
> + (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
> + <GIC_PPI 11
> + (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
> + <GIC_PPI 10
> + (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
> + };
> +
> + soc {
> + compatible = "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + ccu: clock at 01c20000 {
> + compatible = "allwinner,sun50i-a64-ccu";
> + reg = <0x01c20000 0x400>;
> + clocks = <&osc24M>, <&osc32k>;
> + clock-names = "hosc", "losc";
> + #clock-cells = <1>;
> + #reset-cells = <1>;
> + };
> +
> + pio: pinctrl at 1c20800 {
> + compatible = "allwinner,sun50i-a64-pinctrl";
> + reg = <0x01c20800 0x400>;
> + interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&ccu CLK_BUS_PIO>;
> + gpio-controller;
> + #gpio-cells = <3>;
> + interrupt-controller;
> + #interrupt-cells = <3>;
> +
> + i2c1_pins: i2c1_pins {
> + allwinner,pins = "PH2", "PH3";
> + allwinner,function = "i2c1";
So as Icenowy pointed out, we are missing the drive and pull properties
here, at least as long as we don't have your patch (series) in place to
cope with that.
But if we rely on this series (which seems OK to me), shouldn't we then
use the generic properties for pins and function here as well?
Cheers,
Andre.
> + };
> +
> + uart0_pins_a: uart0 at 0 {
> + allwinner,pins = "PB8", "PB9";
> + allwinner,function = "uart0";
> + };
> + };
> +
> + uart0: serial at 1c28000 {
> + compatible = "snps,dw-apb-uart";
> + reg = <0x01c28000 0x400>;
> + interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + clocks = <&ccu CLK_BUS_UART0>;
> + resets = <&ccu RST_BUS_UART0>;
> + status = "disabled";
> + };
> +
> + uart1: serial at 1c28400 {
> + compatible = "snps,dw-apb-uart";
> + reg = <0x01c28400 0x400>;
> + interrupts = <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + clocks = <&ccu CLK_BUS_UART1>;
> + resets = <&ccu RST_BUS_UART1>;
> + status = "disabled";
> + };
> +
> + uart2: serial at 1c28800 {
> + compatible = "snps,dw-apb-uart";
> + reg = <0x01c28800 0x400>;
> + interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + clocks = <&ccu CLK_BUS_UART2>;
> + resets = <&ccu RST_BUS_UART2>;
> + status = "disabled";
> + };
> +
> + uart3: serial at 1c28c00 {
> + compatible = "snps,dw-apb-uart";
> + reg = <0x01c28c00 0x400>;
> + interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + clocks = <&ccu CLK_BUS_UART3>;
> + resets = <&ccu RST_BUS_UART3>;
> + status = "disabled";
> + };
> +
> + uart4: serial at 1c29000 {
> + compatible = "snps,dw-apb-uart";
> + reg = <0x01c29000 0x400>;
> + interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + clocks = <&ccu CLK_BUS_UART4>;
> + resets = <&ccu RST_BUS_UART4>;
> + status = "disabled";
> + };
> +
> + i2c0: i2c at 1c2ac00 {
> + compatible = "allwinner,sun6i-a31-i2c";
> + reg = <0x01c2ac00 0x400>;
> + interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&ccu CLK_BUS_I2C0>;
> + resets = <&ccu RST_BUS_I2C0>;
> + status = "disabled";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + i2c1: i2c at 1c2b000 {
> + compatible = "allwinner,sun6i-a31-i2c";
> + reg = <0x01c2b000 0x400>;
> + interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&ccu CLK_BUS_I2C1>;
> + resets = <&ccu RST_BUS_I2C1>;
> + status = "disabled";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + i2c2: i2c at 1c2b400 {
> + compatible = "allwinner,sun6i-a31-i2c";
> + reg = <0x01c2b400 0x400>;
> + interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&ccu CLK_BUS_I2C2>;
> + resets = <&ccu RST_BUS_I2C2>;
> + status = "disabled";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + gic: interrupt-controller at 1c81000 {
> + compatible = "arm,gic-400";
> + reg = <0x01c81000 0x1000>,
> + <0x01c82000 0x2000>,
> + <0x01c84000 0x2000>,
> + <0x01c86000 0x2000>;
> + interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
> + interrupt-controller;
> + #interrupt-cells = <3>;
> + };
> +
> + rtc: rtc at 1f00000 {
> + compatible = "allwinner,sun6i-a31-rtc";
> + reg = <0x01f00000 0x54>;
> + interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>;
> + };
> + };
> +};
>
^ permalink raw reply
* [PATCH 2/2] pinctrl: stm32: move gpio irqs binding to optional
From: Linus Walleij @ 2016-10-23 23:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476970012-7838-3-git-send-email-alexandre.torgue@st.com>
On Thu, Oct 20, 2016 at 3:26 PM, Alexandre TORGUE
<alexandre.torgue@st.com> wrote:
> stm32 pinctrl driver could be probed even if no interrupt controller
> is defined to manage gpio irqs. Entries related to gpio irq management
> are moved to optional.
>
> Signed-off-by: Alexandre TORGUE <alexandre.torgue@st.com>
Patch applied for fixes.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 1/2] pinctrl: stm32: remove dependency with interrupt controller
From: Linus Walleij @ 2016-10-23 23:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476970012-7838-2-git-send-email-alexandre.torgue@st.com>
On Thu, Oct 20, 2016 at 3:26 PM, Alexandre TORGUE
<alexandre.torgue@st.com> wrote:
> This patch allows to probe stm32 pinctrl driver even if no interrupt
> controller is defined to manage gpio irqs.
>
> Signed-off-by: Alexandre TORGUE <alexandre.torgue@st.com>
Patch applied for fixes.
Yours,
Linus Walleij
^ permalink raw reply
* [GIT PULL 4/4] Broadcom defconfig-arm64 changes for 4.9 (part 2)
From: Olof Johansson @ 2016-10-23 23:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <62d5c9b0-9073-c8e3-6a9f-390f381d4d9d@gmail.com>
On Sun, Oct 23, 2016 at 2:55 PM, Florian Fainelli <f.fainelli@gmail.com> wrote:
> On 09/30/2016 12:23 PM, Florian Fainelli wrote:
>> The following changes since commit 29b4817d4018df78086157ea3a55c1d9424a7cfc:
>>
>> Linux 4.8-rc1 (2016-08-07 18:18:00 -0700)
>>
>> are available in the git repository at:
>>
>> http://github.com/Broadcom/stblinux.git tags/arm-soc/for-4.9/defconfig-arm64
>>
>> for you to fetch changes up to 51e3fb1d3f514cd336faf185df73b25fca194773:
>>
>> Merge tag 'bcm2835-defconfig-64-next-2016-09-22' into defconfig-arm64/next (2016-09-30 12:02:29 -0700)
>>
>> ----------------------------------------------------------------
>> This pull request contains Broadcom ARM64-based SoCs defconfig changes for 4.9,
>> please pull the following changes:
>>
>> - Eric updates the ARMv8 defconfig to contain everything that is needed to run
>> a 64-bit kernel on the Raspberry Pi 3
>>
>> ----------------------------------------------------------------
>> Eric Anholt (1):
>> arm64: Add BCM2835 (Raspberry Pi 3) support to the defconfig
>>
>> Florian Fainelli (1):
>> Merge tag 'bcm2835-defconfig-64-next-2016-09-22' into defconfig-arm64/next
>>
>> arch/arm64/configs/defconfig | 16 ++++++++++++++++
>> 1 file changed, 16 insertions(+)
>
> Arnd, Kevin, Olof,
>
> Following Olof's response here:
>
> https://www.spinics.net/lists/arm-kernel/msg534687.html
>
> do you think we could merge these for 4.9-rcX? Let me know if I should
> send a fresh pull request for that.
Main reason to respin would be if you need to rebase due to other
changes that have gone in, or if you expect to have other material
that should be based on a 4.9-rc base.
-Olof
^ permalink raw reply
* [PATCH] pinctrl: st: don't specify default interrupt trigger
From: Linus Walleij @ 2016-10-23 23:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476774988-13484-1-git-send-email-patrice.chotard@st.com>
On Tue, Oct 18, 2016 at 9:16 AM, <patrice.chotard@st.com> wrote:
> From: Patrice Chotard <patrice.chotard@st.com>
>
> Thanks to 332e99d5ae4 which now alerts of default
> trigger usage when configuring interrupts.
>
> Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Patch applied with Peter's ACK.
Pls also look into the following: __gpio_irq_handler seems to be
doing some stuff per-IRQ that only pertains to edge-triggered IRQs.
Normally that should be handled by:
- Setting default handler to handle_bad_irq()
- Setting handler to handle_edge_irq() or handle_level_irq() in .set_type()
- Implement .irq_ack() on the irqchip and handle the edge-specific ACKing
there.
See for example drivers/gpio/gpio-pl061.c.
I am not *sure* this applies to pinctrl-st.c but please check if it provides
more elegant code. Notmally the .irq_ack() is for edge detection hardware
that allows ACKing the ege IRQ in a separate register and after that we
can raise another edge IRQ while the current IRQ is being handled.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] Revert "gpio/mvebu: convert to use irq_domain_add_simple()"
From: Linus Walleij @ 2016-10-23 23:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161019210341.GA3746@obsidianresearch.com>
On Wed, Oct 19, 2016 at 11:03 PM, Jason Gunthorpe
<jgunthorpe@obsidianresearch.com> wrote:
> From 7566f05ac445b652ba7607cc1899fed10fea1c76 Mon Sep 17 00:00:00 2001
> From: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
> Date: Wed, 19 Oct 2016 14:57:45 -0600
> Subject: [PATCH] gpio/mvebu: Use irq_domain_add_linear
>
> This fixes the irq allocation in this driver to not print:
> irq: Cannot allocate irq_descs @ IRQ34, assuming pre-allocated
> irq: Cannot allocate irq_descs @ IRQ66, assuming pre-allocated
>
> Which happens because the driver already called irq_alloc_descs()
> and so the change to use irq_domain_add_simple resulted in calling
> irq_alloc_descs() twice.
>
> Modernize the irq allocation in this driver to use the
> irq_domain_add_linear flow directly and eliminate the use of
> irq_domain_add_simple/legacy
>
> Fixes: ce931f571b6d ("gpio/mvebu: convert to use irq_domain_add_simple()")
> Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
So can I just apply this?
Gregory?
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 5/8] pinctrl: aspeed: Enable capture of off-SCU pinmux state
From: Linus Walleij @ 2016-10-23 22:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACPK8Xc7y3GtcJCVYYs-JKTqBZvqVeZaz5MUk=UX151SX1xEFw@mail.gmail.com>
On Thu, Sep 29, 2016 at 8:45 AM, Joel Stanley <joel@jms.id.au> wrote:
> On Wed, Sep 28, 2016 at 12:20 AM, Andrew Jeffery <andrew@aj.id.au> wrote:
>> On the AST2400 and AST2500 a number of pins depend on state in one of
>> the SIO, LPC or GFX IP blocks, so add support to at least capture what
>> that state is. The pinctrl engine for the Aspeed SoCs doesn't try to
>> inspect or modify the state of the off-SCU IP blocks. Instead, it logs
>> the state requirement with the expectation that the platform
>> designer/maintainer arranges for the appropriate configuration to be
>> applied through the associated drivers.
(...)
>
> This is unfortunate.
>
> This patch kicks the can down the road, but doesn't solve the problem
> for a user who wants to configure some functionality that depends on
> the non-SCU bits. Because of this I'm not sure if we want to put it in
> the tree.
>
> However, I'm not sure what a proper solution would look like. Perhaps
> Linus can point out another SoC that has a similar problem?
If I could only understand it.
Don't you actually want to go and read a few registers on another
IO range?
What we generally do when pin control is spread out in a system is try
to consolidate it, meaning expose the necessary registers on the remote
end using syscon (drivers/mfd/syscon) so that we can easily get a handle
on these registers withe regmap MMIO.
Since regmap handles atomic access to the registers, that way we
protect from disasters and keep the state in the hardware.
I don't know if this is helpful. For a normal peripheral you may not want
to put a regmap over all its registers but you prefer to ioremap it, and then
we get the spaghetti of accessor functions to peek and poke into another
peripherals I/O space, and that is undesireable.
Maybe this is completely not understanding what you want to do, so
sorry, please elaborate. I am afraid the two of you are the only people on
the planet who actually understand what is going on here.
Also the hardware engineer who wrote the Aspeed pin controller, I would
like to read this persons design specification, I am pretty sure it is very
interesting.
>> - * @reg: The register offset from base in bytes
>> + * @reg: Split into three fields:
>> + * 31:24: IP selector
>> + * 23:12: Reserved
>> + * 11:0: Register offset
That seems like unnecessary shoehorning. Is it reflecting the register layout
of the hardware or are you trying to save bits? For the latter, let it
go and instead
have one member for offset and one member for selector.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 6/8] pinctrl: aspeed-g4: Capture SuperIO pinmux dependency
From: Linus Walleij @ 2016-10-23 22:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477010011.8917.20.camel@aj.id.au>
On Fri, Oct 21, 2016 at 2:33 AM, Andrew Jeffery <andrew@aj.id.au> wrote:
>> Patch applied for v4.10.
>> (Tell me if I'm applying patches in wrong order or something, and
>> I hope this doesn't clash with the fixes.)
>
> Both this patch and 8/8 functionally depend on 5/8. I fetched the
> pinctrl tree to poke around but this patch didn't appear in any of the
> updated branches, so I'm not sure whether we have the right ordering.
> Without it we should hit build failures from missing macro definitions.
>
> Have you had a chance to look over patch 5/8? Joel wasn't keen on its
> current form, so I would appreciate your input.
Oops backed this patch out.
Will look at 5/8.
Appreciate if you repost the remaining patches in the series based on
v4.9-rc2 once it's out, and I'll rebase the pinctrl tree onto that.
Yours,
Linus Walleij
^ permalink raw reply
* [GIT PULL 4/4] Broadcom defconfig-arm64 changes for 4.9 (part 2)
From: Florian Fainelli @ 2016-10-23 21:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475263395-27653-4-git-send-email-f.fainelli@gmail.com>
On 09/30/2016 12:23 PM, Florian Fainelli wrote:
> The following changes since commit 29b4817d4018df78086157ea3a55c1d9424a7cfc:
>
> Linux 4.8-rc1 (2016-08-07 18:18:00 -0700)
>
> are available in the git repository at:
>
> http://github.com/Broadcom/stblinux.git tags/arm-soc/for-4.9/defconfig-arm64
>
> for you to fetch changes up to 51e3fb1d3f514cd336faf185df73b25fca194773:
>
> Merge tag 'bcm2835-defconfig-64-next-2016-09-22' into defconfig-arm64/next (2016-09-30 12:02:29 -0700)
>
> ----------------------------------------------------------------
> This pull request contains Broadcom ARM64-based SoCs defconfig changes for 4.9,
> please pull the following changes:
>
> - Eric updates the ARMv8 defconfig to contain everything that is needed to run
> a 64-bit kernel on the Raspberry Pi 3
>
> ----------------------------------------------------------------
> Eric Anholt (1):
> arm64: Add BCM2835 (Raspberry Pi 3) support to the defconfig
>
> Florian Fainelli (1):
> Merge tag 'bcm2835-defconfig-64-next-2016-09-22' into defconfig-arm64/next
>
> arch/arm64/configs/defconfig | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
Arnd, Kevin, Olof,
Following Olof's response here:
https://www.spinics.net/lists/arm-kernel/msg534687.html
do you think we could merge these for 4.9-rcX? Let me know if I should
send a fresh pull request for that.
Thank you!
--
Florian
^ 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