* [PATCH v2 2/2] mm: hugetlb: support gigantic surplus pages
From: Huang Shijie @ 2016-11-10 7:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161109165549.1cf320c5@thinkpad>
On Wed, Nov 09, 2016 at 04:55:49PM +0100, Gerald Schaefer wrote:
> > index 9fdfc24..5dbfd62 100644
> > --- a/mm/hugetlb.c
> > +++ b/mm/hugetlb.c
> > @@ -1095,6 +1095,9 @@ static struct page *alloc_gigantic_page(int nid, unsigned int order)
> > unsigned long ret, pfn, flags;
> > struct zone *z;
> >
> > + if (nid == NUMA_NO_NODE)
> > + nid = numa_mem_id();
> > +
>
> Now counter.sh works (on s390) w/o the lockdep warning. However, it looks
Good news to me :)
We have found the root cause of the s390 issue.
> like this change will now result in inconsistent behavior compared to the
> normal sized hugepages, regarding surplus page allocation. Setting nid to
> numa_mem_id() means that only the node of the current CPU will be considered
> for allocating a gigantic page, as opposed to just "preferring" the current
> node in the normal size case (__hugetlb_alloc_buddy_huge_page() ->
> alloc_pages_node()) with a fallback to using other nodes.
Yes.
>
> I am not really familiar with NUMA, and I might be wrong here, but if
> this is true then gigantic pages, which may be hard allocate at runtime
> in general, will be even harder to find (as surplus pages) because you
> only look on the current node.
Okay, I will try to fix this in the next version.
>
> I honestly do not understand why alloc_gigantic_page() needs a nid
> parameter at all, since it looks like it will only be called from
> alloc_fresh_gigantic_page_node(), which in turn is only called
> from alloc_fresh_gigantic_page() in a "for_each_node" loop (at least
> before your patch).
>
> Now it could be an option to also use alloc_fresh_gigantic_page()
> in your patch, instead of directly calling alloc_gigantic_page(),
Yes, a good suggestion. But I need to do some change to the
alloc_fresh_gigantic_page().
Thanks
Huang Shijie
^ permalink raw reply
* [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on Hip06
From: zhichang.yuan @ 2016-11-10 6:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2825537.ADCNsGqGxn@wuerfel>
Hi, Arnd,
On 2016/11/10 5:34, Arnd Bergmann wrote:
> 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.
Do you means that we can pick up the maximal I/O address from all children's
device resources??
Thanks,
Zhichang
>
> Arnd
>
> .
>
^ permalink raw reply
* [PATCH V5 2/3] ARM64 LPC: Add missing range exception for special ISA
From: zhichang.yuan @ 2016-11-10 6:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161109165044.GE10219@e106497-lin.cambridge.arm.com>
Hi,Liviu,
Thanks for your comments!
On 2016/11/10 0:50, liviu.dudau at arm.com wrote:
> On Wed, Nov 09, 2016 at 04:16:17PM +0000, Gabriele Paoloni wrote:
>> Hi Liviu
>>
>> Thanks for reviewing
>>
>
> [removed some irrelevant part of discussion, avoid crazy formatting]
>
>>>> +/**
>>>> + * addr_is_indirect_io - check whether the input taddr is for
>>> indirectIO.
>>>> + * @taddr: the io address to be checked.
>>>> + *
>>>> + * Returns 1 when taddr is in the range; otherwise return 0.
>>>> + */
>>>> +int addr_is_indirect_io(u64 taddr)
>>>> +{
>>>> + if (arm64_extio_ops->start > taddr || arm64_extio_ops->end <
>>> taddr)
>>>
>>> start >= taddr ?
>>
>> Nope... if (taddr < arm64_extio_ops->start || taddr > arm64_extio_ops->end)
>> then taddr is outside the range [start; end] and will return 0; otherwise
>> it will return 1...
>
> Oops, sorry, did not pay attention to the returned value. The check is
> correct as it is, no need to change then.
>
>>
>>>
>>>> + return 0;
>>>> +
>>>> + return 1;
>>>> +}
>>>>
>>>> BUILD_EXTIO(b, u8)
>>>>
>>>> diff --git a/drivers/of/address.c b/drivers/of/address.c
>>>> index 02b2903..cc2a05d 100644
>>>> --- a/drivers/of/address.c
>>>> +++ b/drivers/of/address.c
>>>> @@ -479,6 +479,50 @@ static int of_empty_ranges_quirk(struct
>>> device_node *np)
>>>> return false;
>>>> }
>>>>
>>>> +
>>>> +/*
>>>> + * of_isa_indirect_io - get the IO address from some isa reg
>>> property value.
>>>> + * For some isa/lpc devices, no ranges property in ancestor node.
>>>> + * The device addresses are described directly in their regs
>>> property.
>>>> + * This fixup function will be called to get the IO address of
>>> isa/lpc
>>>> + * devices when the normal of_translation failed.
>>>> + *
>>>> + * @parent: points to the parent dts node;
>>>> + * @bus: points to the of_bus which can be used to parse
>>> address;
>>>> + * @addr: the address from reg property;
>>>> + * @na: the address cell counter of @addr;
>>>> + * @presult: store the address paresed from @addr;
>>>> + *
>>>> + * return 1 when successfully get the I/O address;
>>>> + * 0 will return for some failures.
>>>
>>> Bah, you are returning a signed int, why 0 for failure? Return a
>>> negative value with
>>> error codes. Otherwise change the return value into a bool.
>>
>> Yes we'll move to bool
>>
>>>
>>>> + */
>>>> +static int of_get_isa_indirect_io(struct device_node *parent,
>>>> + struct of_bus *bus, __be32 *addr,
>>>> + int na, u64 *presult)
>>>> +{
>>>> + unsigned int flags;
>>>> + unsigned int rlen;
>>>> +
>>>> + /* whether support indirectIO */
>>>> + if (!indirect_io_enabled())
>>>> + return 0;
>>>> +
>>>> + if (!of_bus_isa_match(parent))
>>>> + return 0;
>>>> +
>>>> + flags = bus->get_flags(addr);
>>>> + if (!(flags & IORESOURCE_IO))
>>>> + return 0;
>>>> +
>>>> + /* there is ranges property, apply the normal translation
>>> directly. */
>>>
>>> s/there is ranges/if we have a 'ranges'/
>>
>> Thanks for spotting this
>>
>>>
>>>> + if (of_get_property(parent, "ranges", &rlen))
>>>> + return 0;
>>>> +
>>>> + *presult = of_read_number(addr + 1, na - 1);
>>>> + /* this fixup is only valid for specific I/O range. */
>>>> + return addr_is_indirect_io(*presult);
>>>> +}
>>>> +
>>>> static int of_translate_one(struct device_node *parent, struct
>>> of_bus *bus,
>>>> struct of_bus *pbus, __be32 *addr,
>>>> int na, int ns, int pna, const char *rprop)
>>>> @@ -595,6 +639,15 @@ static u64 __of_translate_address(struct
>>> device_node *dev,
>>>> result = of_read_number(addr, na);
>>>> break;
>>>> }
>>>> + /*
>>>> + * For indirectIO device which has no ranges property, get
>>>> + * the address from reg directly.
>>>> + */
>>>> + if (of_get_isa_indirect_io(dev, bus, addr, na, &result)) {
>>>> + pr_debug("isa indirectIO matched(%s)..addr =
>>> 0x%llx\n",
>>>> + of_node_full_name(dev), result);
>>>> + break;
>>>> + }
>>>>
>>>> /* Get new parent bus and counts */
>>>> pbus = of_match_bus(parent);
>>>> @@ -688,8 +741,9 @@ static int __of_address_to_resource(struct
>>> device_node *dev,
>>>> if (taddr == OF_BAD_ADDR)
>>>> return -EINVAL;
>>>> memset(r, 0, sizeof(struct resource));
>>>> - if (flags & IORESOURCE_IO) {
>>>> + if (flags & IORESOURCE_IO && taddr >= PCIBIOS_MIN_IO) {
>>>> unsigned long port;
>>>> +
>>>> port = pci_address_to_pio(taddr);
>>>> if (port == (unsigned long)-1)
>>>> return -EINVAL;
>>>> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
>>>> index ba34907..1a08511 100644
>>>> --- a/drivers/pci/pci.c
>>>> +++ b/drivers/pci/pci.c
>>>> @@ -3263,7 +3263,7 @@ int __weak pci_register_io_range(phys_addr_t
>>> addr, resource_size_t size)
>>>>
>>>> #ifdef PCI_IOBASE
>>>> struct io_range *range;
>>>> - resource_size_t allocated_size = 0;
>>>> + resource_size_t allocated_size = PCIBIOS_MIN_IO;
>>>>
>>>> /* check if the range hasn't been previously recorded */
>>>> spin_lock(&io_range_lock);
>>>> @@ -3312,7 +3312,7 @@ phys_addr_t pci_pio_to_address(unsigned long
>>> pio)
>>>>
>>>> #ifdef PCI_IOBASE
>>>> struct io_range *range;
>>>> - resource_size_t allocated_size = 0;
>>>> + resource_size_t allocated_size = PCIBIOS_MIN_IO;
>>>
>>> Have you checked that pci_pio_to_address still returns valid values
>>> after this? I know that
>>> you are trying to take into account PCIBIOS_MIN_IO limit when
>>> allocating reserving the IO ranges,
>>> but the values added in the io_range_list are still starting from zero,
>>> no from PCIBIOS_MIN_IO,
>>
>> I think you're wrong here as in pci_address_to_pio we have:
>> + resource_size_t offset = PCIBIOS_MIN_IO;
>>
>> This should be enough to guarantee that the PIOs start at
>> PCIBIOS_MIN_IO...right?
>
> I don't think you can guarantee that the pio value that gets passed into
> pci_pio_to_address() always comes from a previously returned value by
> pci_address_to_pio(). Maybe you can add a check in pci_pio_to_address()
>
> if (pio < PCIBIOS_MIN_IO)
> return address;
>
> to avoid adding more checks in the list_for_each_entry() loop.
>
I will register some ranges to the list and test it later.
But from my understanding, pci_pio_to_address() should can return the right
original physical address.
According to the algorithm, the output PIO ranges are consecutive? just like this:
input pio of pci_pio_to_address()
|
V
|----------------|--------------------------|------|-----------|
^
|
allocated_size is here
The change of this patch just make the start PIO from ZERO to PCIBIOS_MIN_IO.
in pci_pio_to_address(), for one input pio which fall into any PIO segment, the
return address will be:
address = range->start + pio - allocated_size;
Since allocated_size is the total range size of all IO ranges before the one
where pio belong, then (pio - allocated_size) is the offset to the range start,
So....
Thanks!
Zhichang
> Best regards,
> Liviu
>
>>
>>
>>> so the calculation of the address in this function could return
>>> negative values casted to pci_addr_t.
>>>
>>> Maybe you want to adjust the range->start value in
>>> pci_register_io_range() as well to have it
>>> offset by PCIBIOS_MIN_IO as well.
>>>
>>> Best regards,
>>> Liviu
>>>
>>>>
>>>> if (pio > IO_SPACE_LIMIT)
>>>> return address;
>>>> @@ -3335,7 +3335,7 @@ unsigned long __weak
>>> pci_address_to_pio(phys_addr_t address)
>>>> {
>>>> #ifdef PCI_IOBASE
>>>> struct io_range *res;
>>>> - resource_size_t offset = 0;
>>>> + resource_size_t offset = PCIBIOS_MIN_IO;
>>>> unsigned long addr = -1;
>>>>
>>>> spin_lock(&io_range_lock);
>>>> diff --git a/include/linux/of_address.h b/include/linux/of_address.h
>>>> index 3786473..deec469 100644
>>>> --- a/include/linux/of_address.h
>>>> +++ b/include/linux/of_address.h
>>>> @@ -24,6 +24,23 @@ struct of_pci_range {
>>>> #define for_each_of_pci_range(parser, range) \
>>>> for (; of_pci_range_parser_one(parser, range);)
>>>>
>>>> +
>>>> +#ifndef indirect_io_enabled
>>>> +#define indirect_io_enabled indirect_io_enabled
>>>> +static inline bool indirect_io_enabled(void)
>>>> +{
>>>> + return false;
>>>> +}
>>>> +#endif
>>>> +
>>>> +#ifndef addr_is_indirect_io
>>>> +#define addr_is_indirect_io addr_is_indirect_io
>>>> +static inline int addr_is_indirect_io(u64 taddr)
>>>> +{
>>>> + return 0;
>>>> +}
>>>> +#endif
>>>> +
>>>> /* Translate a DMA address from device space to CPU space */
>>>> extern u64 of_translate_dma_address(struct device_node *dev,
>>>> const __be32 *in_addr);
>>>> diff --git a/include/linux/pci.h b/include/linux/pci.h
>>>> index 0e49f70..7f6bbb6 100644
>>>> --- a/include/linux/pci.h
>>>> +++ b/include/linux/pci.h
>>>> @@ -2130,4 +2130,12 @@ static inline bool pci_ari_enabled(struct
>>> pci_bus *bus)
>>>> /* provide the legacy pci_dma_* API */
>>>> #include <linux/pci-dma-compat.h>
>>>>
>>>> +/*
>>>> + * define this macro here to refrain from compilation error for some
>>>> + * platforms. Please keep this macro at the end of this header file.
>>>> + */
>>>> +#ifndef PCIBIOS_MIN_IO
>>>> +#define PCIBIOS_MIN_IO 0
>>>> +#endif
>>>> +
>>>> #endif /* LINUX_PCI_H */
>>>> --
>>>> 1.9.1
>>>>
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-pci"
>>> in
>>>> the body of a message to majordomo at vger.kernel.org
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCH 1/10] clk: sunxi-ng: multiplier: Add fractionnal support
From: Chen-Yu Tsai @ 2016-11-10 6:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b3d3436c03e0597de205f674061892dbc9498a7e.1478625788.git-series.maxime.ripard@free-electrons.com>
On Wed, Nov 9, 2016 at 1:23 AM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Nit: Typo in the subject ("fractional"). Maybe mention what clock on what SoC
needs this in the commit message?
Otherwise,
Acked-by: Chen-Yu Tsai <wens@csie.org>
> ---
> drivers/clk/sunxi-ng/ccu_mult.c | 8 ++++++++
> drivers/clk/sunxi-ng/ccu_mult.h | 2 ++
> 2 files changed, 10 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/clk/sunxi-ng/ccu_mult.c b/drivers/clk/sunxi-ng/ccu_mult.c
> index 678b6cb49f01..826302464650 100644
> --- a/drivers/clk/sunxi-ng/ccu_mult.c
> +++ b/drivers/clk/sunxi-ng/ccu_mult.c
> @@ -75,6 +75,9 @@ static unsigned long ccu_mult_recalc_rate(struct clk_hw *hw,
> unsigned long val;
> u32 reg;
>
> + if (ccu_frac_helper_is_enabled(&cm->common, &cm->frac))
> + return ccu_frac_helper_read_rate(&cm->common, &cm->frac);
> +
> reg = readl(cm->common.base + cm->common.reg);
> val = reg >> cm->mult.shift;
> val &= (1 << cm->mult.width) - 1;
> @@ -102,6 +105,11 @@ static int ccu_mult_set_rate(struct clk_hw *hw, unsigned long rate,
> unsigned long flags;
> u32 reg;
>
> + if (ccu_frac_helper_has_rate(&cm->common, &cm->frac, rate))
> + return ccu_frac_helper_set_rate(&cm->common, &cm->frac, rate);
> + else
> + ccu_frac_helper_disable(&cm->common, &cm->frac);
> +
> ccu_mux_helper_adjust_parent_for_prediv(&cm->common, &cm->mux, -1,
> &parent_rate);
>
> diff --git a/drivers/clk/sunxi-ng/ccu_mult.h b/drivers/clk/sunxi-ng/ccu_mult.h
> index c1a2134bdc71..bd2e38b5a32a 100644
> --- a/drivers/clk/sunxi-ng/ccu_mult.h
> +++ b/drivers/clk/sunxi-ng/ccu_mult.h
> @@ -2,6 +2,7 @@
> #define _CCU_MULT_H_
>
> #include "ccu_common.h"
> +#include "ccu_frac.h"
> #include "ccu_mux.h"
>
> struct ccu_mult_internal {
> @@ -23,6 +24,7 @@ struct ccu_mult_internal {
> struct ccu_mult {
> u32 enable;
>
> + struct ccu_frac_internal frac;
> struct ccu_mult_internal mult;
> struct ccu_mux_internal mux;
> struct ccu_common common;
> --
> git-series 0.8.11
^ permalink raw reply
* [PATCH] ASoC: sun4i-codec: fix semicolon.cocci warnings
From: Chen-Yu Tsai @ 2016-11-10 6:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161109163518.GA42508@lkp-nex06.lkp.intel.com>
On Thu, Nov 10, 2016 at 12:35 AM, kbuild test robot
<fengguang.wu@intel.com> wrote:
> sound/soc/sunxi/sun4i-codec.c:1339:2-3: Unneeded semicolon
>
>
> Remove unneeded semicolon.
>
> Generated by: scripts/coccinelle/misc/semicolon.cocci
>
> CC: Chen-Yu Tsai <wens@csie.org>
> Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
Acked-by: Chen-Yu Tsai <wens@csie.org>
Sorry about the screw up.
> ---
>
> sun4i-codec.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- a/sound/soc/sunxi/sun4i-codec.c
> +++ b/sound/soc/sunxi/sun4i-codec.c
> @@ -1336,7 +1336,7 @@ static int sun4i_codec_probe(struct plat
> dev_err(&pdev->dev, "Failed to get reset control\n");
> return PTR_ERR(scodec->rst);
> }
> - };
> + }
>
> scodec->gpio_pa = devm_gpiod_get_optional(&pdev->dev, "allwinner,pa",
> GPIOD_OUT_LOW);
^ permalink raw reply
* [PATCH v4] regulator: lp873x: Add support for populating input supply
From: Lokesh Vutla @ 2016-11-10 5:29 UTC (permalink / raw)
To: linux-arm-kernel
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.
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
---
Changes since v3:
- Applied Rob's ack.
- Sending this patch separately so that this can be merged via Regulator tree.
- Link to v3: https://patchwork.kernel.org/patch/9408545/
Documentation/devicetree/bindings/mfd/lp873x.txt | 8 ++++++++
drivers/regulator/lp873x-regulator.c | 1 +
2 files changed, 9 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/lp873x.txt b/Documentation/devicetree/bindings/mfd/lp873x.txt
index 52766c2..ae9cf39 100644
--- a/Documentation/devicetree/bindings/mfd/lp873x.txt
+++ b/Documentation/devicetree/bindings/mfd/lp873x.txt
@@ -7,6 +7,9 @@ Required properties:
- #gpio-cells: Should be two. The first cell is the pin number and
the second cell is used to specify flags.
See ../gpio/gpio.txt for more information.
+ - xxx-in-supply: Phandle to parent supply node of each regulator
+ populated under regulators node. xxx can be
+ buck0, buck1, ldo0 or ldo1.
- regulators: List of child nodes that specify the regulator
initialization data.
Example:
@@ -17,6 +20,11 @@ pmic: lp8733 at 60 {
gpio-controller;
#gpio-cells = <2>;
+ buck0-in-supply = <&vsys_3v3>;
+ buck1-in-supply = <&vsys_3v3>;
+ ldo0-in-supply = <&vsys_3v3>;
+ ldo1-in-supply = <&vsys_3v3>;
+
regulators {
lp8733_buck0: buck0 {
regulator-name = "lp8733-buck0";
diff --git a/drivers/regulator/lp873x-regulator.c b/drivers/regulator/lp873x-regulator.c
index e504b91..70e3df6 100644
--- a/drivers/regulator/lp873x-regulator.c
+++ b/drivers/regulator/lp873x-regulator.c
@@ -24,6 +24,7 @@
[_id] = { \
.desc = { \
.name = _name, \
+ .supply_name = _of "-in", \
.id = _id, \
.of_match = of_match_ptr(_of), \
.regulators_node = of_match_ptr("regulators"),\
--
2.10.1
^ permalink raw reply related
* [PATCH v1] mtk-vcodec: add index check in decoder vidioc_qbuf.
From: Wu-Cheng Li @ 2016-11-10 5:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478755445-23494-1-git-send-email-wuchengli@chromium.org>
From: Wu-Cheng Li <wuchengli@google.com>
vb2_qbuf will check the buffer index. If a driver overrides
vidioc_qbuf and use the buffer index, the driver needs to check
the index.
Signed-off-by: Wu-Cheng Li <wuchengli@chromium.org>
---
drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
index 0520919..0746592 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
@@ -533,6 +533,10 @@ static int vidioc_vdec_qbuf(struct file *file, void *priv,
}
vq = v4l2_m2m_get_vq(ctx->m2m_ctx, buf->type);
+ if (buf->index >= vq->num_buffers) {
+ mtk_v4l2_debug(1, "buffer index %d out of range", buf->index);
+ return -EINVAL;
+ }
vb = vq->bufs[buf->index];
vb2_v4l2 = container_of(vb, struct vb2_v4l2_buffer, vb2_buf);
mtkbuf = container_of(vb2_v4l2, struct mtk_video_dec_buf, vb);
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* [PATCH v1] mtk-vcodec: add index check in decoder vidioc_qbuf
From: Wu-Cheng Li @ 2016-11-10 5:24 UTC (permalink / raw)
To: linux-arm-kernel
From: Wu-Cheng Li <wuchengli@google.com>
This patch adds a buffer index check in decoder vidioc_qbuf.
Wu-Cheng Li (1):
mtk-vcodec: add index check in decoder vidioc_qbuf.
drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c | 4 ++++
1 file changed, 4 insertions(+)
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply
* [v16, 0/7] Fix eSDHC host version register bug
From: Scott Wood @ 2016-11-10 5:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <DB6PR0401MB25369DEFDDDED2A96851259EF8B80@DB6PR0401MB2536.eurprd04.prod.outlook.com>
On Thu, 2016-11-10 at 04:11 +0000, Y.B. Lu wrote:
> >
> > -----Original Message-----
> > From: Y.B. Lu
> > Sent: Thursday, November 10, 2016 12:06 PM
> > To: 'Scott Wood'; Ulf Hansson
> > Cc: linux-mmc; Arnd Bergmann; linuxppc-dev at lists.ozlabs.org;
> > devicetree at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux-
> > kernel at vger.kernel.org; linux-clk; iommu at lists.linux-foundation.org;
> > netdev at vger.kernel.org; Greg Kroah-Hartman; Mark Rutland; Rob Herring;
> > Russell King; Jochen Friedrich; Joerg Roedel; Claudiu Manoil; Bhupesh
> > Sharma; Qiang Zhao; Kumar Gala; Leo Li; X.B. Xie; M.H. Lian
> > Subject: RE: [v16, 0/7] Fix eSDHC host version register bug
> >
> > >
> > > -----Original Message-----
> > > From: linux-mmc-owner at vger.kernel.org [mailto:linux-mmc-
> > > owner at vger.kernel.org] On Behalf Of Scott Wood
> > > Sent: Thursday, November 10, 2016 11:55 AM
> > > To: Ulf Hansson; Y.B. Lu
> > > Cc: linux-mmc; Arnd Bergmann; linuxppc-dev at lists.ozlabs.org;
> > > devicetree at vger.kernel.org; linux-arm-kernel at lists.infradead.org;
> > > linux- kernel at vger.kernel.org; linux-clk;
> > > iommu at lists.linux-foundation.org; netdev at vger.kernel.org; Greg
> > > Kroah-Hartman; Mark Rutland; Rob Herring; Russell King; Jochen
> > > Friedrich; Joerg Roedel; Claudiu Manoil; Bhupesh Sharma; Qiang Zhao;
> > > Kumar Gala; Leo Li; X.B. Xie; M.H. Lian
> > > Subject: Re: [v16, 0/7] Fix eSDHC host version register bug
> > >
> > > On Wed, 2016-11-09 at 19:27 +0100, Ulf Hansson wrote:
> > > >
> > > > - i2c-list
> > > >
> > > > On 9 November 2016 at 04:14, Yangbo Lu <yangbo.lu@nxp.com> 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!
> > > They are documented, in fsl/guts.txt (the file moved in patch 2/7):
> > > >
> > > > ?- compatible : Should define the compatible device type for
> > > > ???global-utilities.
> > > > ???Possible compatibles:
> > > > ????????"fsl,qoriq-device-config-1.0"
> > > > ????????"fsl,qoriq-device-config-2.0"
> > > > ????????"fsl,<chip>-device-config"
> > > > ????????"fsl,<chip>-guts"
> > > Checkpatch doesn't understand compatibles defined in such a way.
> > [Lu Yangbo-B47093] You're right, Scott. I dropped DT patch 'dt: bindings:
> > update Freescale DCFG compatible '
> > which fixed un-doc issue since Shaohui had done this on Shawn Guo's tree.
> > https://git.kernel.org/cgit/linux/kernel/git/shawnguo/linux.git/commit/?h
> > =imx/dt64&id=981034a2bfcaff5c95dafde24d7abfe7f9025c19
> >
> > Thanks.
> [Lu Yangbo-B47093] Both 'fsl,<chip>-guts' and 'fsl,<chip>-dcfg' would have
> no un-doc issue after Shaohui's patch are pulled :)
I don't follow. ?The link above points to a patch that addresses -dcfg and
-scfg, not -device-config or -guts -- and it also doesn't do it in a manner
that checkpatch will understand.
In any case, I wouldn't call this an "un-doc issue" -- it is documented -- but
rather a checkpatch-friendliness issue.
-Scott
^ permalink raw reply
* [PATCH] drivers: mfd: ti_am335x_tscadc: increase ADC ref clock to 24MHz
From: Vignesh R @ 2016-11-10 5:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <D0AA78D0-9562-4E4D-A949-A771289D7570@gmail.com>
Hi,
On Thursday 10 November 2016 05:23 AM, John Syne wrote:
> OK, then back to my original question. Given that these DT properties are supported in the driver
>
Below properties are supported by only by ti_am3335x_adc driver and not
ti_am335x_tsc driver. As author of this patch pointed out in another
reply, there is no need to change step-opendelay for tsc. AFAIK, I don't
see a use case where these values needs to be tweaked for tsc channels,
therefore it does not make sense to be DT properties.
> shouldn?t the following be added to am33xx.dtsi and am4372.dtsi?
Its totally upto board dts files to allocate channels for tsc and adc.
So, how could these be added to dtsi files?
> ti,chan-step-avg = <0x16 0x16 0x16 0x16 0x16 0x16 0x16>;
> ti,chan-step-opendelay = <0x500 0x500 0x500 0x500 0x500 0x500 0x500>;
> ti,chan-step-sampledelay = <0x0 0x0 0x0 0x0 0x0 0x0 0x0>;
>
> Regards,
> John
>>
>> --
>> Regards
>> Vignesh
>
--
Regards
Vignesh
^ permalink raw reply
* [PATCH fpga 2/9] fpga zynq: Check the bitstream for validity
From: Jason Gunthorpe @ 2016-11-10 4:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <17912798-e55d-253f-42fc-c7287d067e00@gmail.com>
On Wed, Nov 09, 2016 at 04:04:07PM -0800, Joshua Clayton wrote:
> > + if (!zynq_fpga_has_sync(buf, count)) {
> > + dev_err(priv->dev,
> > + "Invalid bitstream, could not find a sync word. Bitstream must be a byte swaped .bin file\n");
> Nitpick: byte swaped is a misspelling...
oops, sure.
> and I'm not sure I like the second half of this message. Maybe
> something like "Bitstream must be lsb first" (if that is what is
> meant).
I intended it to be a recipe to follow, not a specification. It
literally means take the .bin file and dword byte swap it to make it
work with the driver.
Describing it as LSB first would be consistent with UG470, but I doubt
many people know Xilinx tools emit the bitstream in 32 bit MSB format
and probably even fewer people know that the relavent difference
between .bit and .bin boils down to the alignment of the sync word -
which is why I prefered the recipe style..
Jason
^ permalink raw reply
* [PATCH v3 0/3] modversions: Fix CRC mangling under CONFIG_RELOCATABLE=y
From: Michael Ellerman @ 2016-11-10 4:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu8Yc9rUacE70mvZSR92g1OY6LYyN6zrd--omwZVqwg3TA@mail.gmail.com>
Ard Biesheuvel <ard.biesheuvel@linaro.org> writes:
> On 27 October 2016 at 17:27, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>> This series is a followup to the single patch 'modversions: treat symbol
>> CRCs as 32 bit quantities on 64 bit archs', of which two versions have
>> been sent out so far [0][1]
>>
>> As pointed out by Michael, GNU ld behaves a bit differently between arm64
>> and PowerPC64, and where the former gets rid of all runtime relocations
>> related to CRCs, the latter is not as easily convinced.
>>
>> Patch #1 fixes the issue where CRCs are corrupted by the runtime relocation
>> routines for 32-bit PowerPC, for which the original fix was effectively
>> reverted by commit 0e0ed6406e61 ("powerpc/modules: Module CRC relocation fix
>> causes perf issues")
>>
>> Patch #2 adds handling of R_PPC64_ADDR32 relocations against the NULL .dynsym
>> symbol entry to the PPC64 runtime relocation routines, so it is prepared to
>> deal with CRCs being emitted as 32-bit quantities.
>>
>> Patch #3 is the original patch from the v1 and v2 submissions.
>>
>> Changes since v2:
>> - added #1 and #2
>> - updated #3 to deal with CRC entries being emitted from assembler
>> - added Rusty's ack (#3)
>>
>> Branch can be found here:
>> https://git.kernel.org/cgit/linux/kernel/git/ardb/linux.git/log/?h=kcrctab-reloc
>>
>> [0] http://marc.info/?l=linux-kernel&m=147652300207369&w=2
>> [1] http://marc.info/?l=linux-kernel&m=147695629614409&w=2
>
> Ping?
Sorry, you didn't cc linuxppc-dev, so it's not in my patchwork list
which tends to mean I miss it.
Will try and test and get back to you.
cheers
^ permalink raw reply
* [v16, 0/7] Fix eSDHC host version register bug
From: Y.B. Lu @ 2016-11-10 4:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478750114.21746.4.camel@buserror.net>
> -----Original Message-----
> From: Y.B. Lu
> Sent: Thursday, November 10, 2016 12:06 PM
> To: 'Scott Wood'; Ulf Hansson
> Cc: linux-mmc; Arnd Bergmann; linuxppc-dev at lists.ozlabs.org;
> devicetree at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux-
> kernel at vger.kernel.org; linux-clk; iommu at lists.linux-foundation.org;
> netdev at vger.kernel.org; Greg Kroah-Hartman; Mark Rutland; Rob Herring;
> Russell King; Jochen Friedrich; Joerg Roedel; Claudiu Manoil; Bhupesh
> Sharma; Qiang Zhao; Kumar Gala; Leo Li; X.B. Xie; M.H. Lian
> Subject: RE: [v16, 0/7] Fix eSDHC host version register bug
>
> > -----Original Message-----
> > From: linux-mmc-owner at vger.kernel.org [mailto:linux-mmc-
> > owner at vger.kernel.org] On Behalf Of Scott Wood
> > Sent: Thursday, November 10, 2016 11:55 AM
> > To: Ulf Hansson; Y.B. Lu
> > Cc: linux-mmc; Arnd Bergmann; linuxppc-dev at lists.ozlabs.org;
> > devicetree at vger.kernel.org; linux-arm-kernel at lists.infradead.org;
> > linux- kernel at vger.kernel.org; linux-clk;
> > iommu at lists.linux-foundation.org; netdev at vger.kernel.org; Greg
> > Kroah-Hartman; Mark Rutland; Rob Herring; Russell King; Jochen
> > Friedrich; Joerg Roedel; Claudiu Manoil; Bhupesh Sharma; Qiang Zhao;
> > Kumar Gala; Leo Li; X.B. Xie; M.H. Lian
> > Subject: Re: [v16, 0/7] Fix eSDHC host version register bug
> >
> > On Wed, 2016-11-09 at 19:27 +0100, Ulf Hansson wrote:
> > > - i2c-list
> > >
> > > On 9 November 2016 at 04:14, Yangbo Lu <yangbo.lu@nxp.com> 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!
> >
> > They are documented, in fsl/guts.txt (the file moved in patch 2/7):
> > > ?- compatible : Should define the compatible device type for
> > > ???global-utilities.
> > > ???Possible compatibles:
> > > ????????"fsl,qoriq-device-config-1.0"
> > > ????????"fsl,qoriq-device-config-2.0"
> > > ????????"fsl,<chip>-device-config"
> > > ????????"fsl,<chip>-guts"
> >
> > Checkpatch doesn't understand compatibles defined in such a way.
>
> [Lu Yangbo-B47093] You're right, Scott. I dropped DT patch 'dt: bindings:
> update Freescale DCFG compatible '
> which fixed un-doc issue since Shaohui had done this on Shawn Guo's tree.
> https://git.kernel.org/cgit/linux/kernel/git/shawnguo/linux.git/commit/?h
> =imx/dt64&id=981034a2bfcaff5c95dafde24d7abfe7f9025c19
>
> Thanks.
[Lu Yangbo-B47093] Both 'fsl,<chip>-guts' and 'fsl,<chip>-dcfg' would have no un-doc issue after Shaohui's patch are pulled :)
>
> >
> > -Scott
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-mmc"
> > in the body of a message to majordomo at vger.kernel.org More majordomo
> > info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [v16, 0/7] Fix eSDHC host version register bug
From: Y.B. Lu @ 2016-11-10 4:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478750114.21746.4.camel@buserror.net>
> -----Original Message-----
> From: linux-mmc-owner at vger.kernel.org [mailto:linux-mmc-
> owner at vger.kernel.org] On Behalf Of Scott Wood
> Sent: Thursday, November 10, 2016 11:55 AM
> To: Ulf Hansson; Y.B. Lu
> Cc: linux-mmc; Arnd Bergmann; linuxppc-dev at lists.ozlabs.org;
> devicetree at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux-
> kernel at vger.kernel.org; linux-clk; iommu at lists.linux-foundation.org;
> netdev at vger.kernel.org; Greg Kroah-Hartman; Mark Rutland; Rob Herring;
> Russell King; Jochen Friedrich; Joerg Roedel; Claudiu Manoil; Bhupesh
> Sharma; Qiang Zhao; Kumar Gala; Leo Li; X.B. Xie; M.H. Lian
> Subject: Re: [v16, 0/7] Fix eSDHC host version register bug
>
> On Wed, 2016-11-09 at 19:27 +0100, Ulf Hansson wrote:
> > - i2c-list
> >
> > On 9 November 2016 at 04:14, Yangbo Lu <yangbo.lu@nxp.com> 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!
>
> They are documented, in fsl/guts.txt (the file moved in patch 2/7):
> > ?- compatible : Should define the compatible device type for
> > ???global-utilities.
> > ???Possible compatibles:
> > ????????"fsl,qoriq-device-config-1.0"
> > ????????"fsl,qoriq-device-config-2.0"
> > ????????"fsl,<chip>-device-config"
> > ????????"fsl,<chip>-guts"
>
> Checkpatch doesn't understand compatibles defined in such a way.
[Lu Yangbo-B47093] You're right, Scott. I dropped DT patch 'dt: bindings: update Freescale DCFG compatible '
which fixed un-doc issue since Shaohui had done this on Shawn Guo's tree.
https://git.kernel.org/cgit/linux/kernel/git/shawnguo/linux.git/commit/?h=imx/dt64&id=981034a2bfcaff5c95dafde24d7abfe7f9025c19
Thanks.
>
> -Scott
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majordomo at vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [v16, 0/7] Fix eSDHC host version register bug
From: Scott Wood @ 2016-11-10 3:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPDyKFrcAN_pqgtGaUanfB2zh97zGcL23m5VDtJ3g==NJeRrfA@mail.gmail.com>
On Wed, 2016-11-09 at 19:27 +0100, Ulf Hansson wrote:
> - i2c-list
>
> On 9 November 2016 at 04:14, Yangbo Lu <yangbo.lu@nxp.com> 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!
They are documented, in fsl/guts.txt (the file moved in patch 2/7):
> ?- compatible : Should define the compatible device type for
> ???global-utilities.
> ???Possible compatibles:
> ????????"fsl,qoriq-device-config-1.0"
> ????????"fsl,qoriq-device-config-2.0"
> ????????"fsl,<chip>-device-config"
> ????????"fsl,<chip>-guts"
Checkpatch doesn't understand compatibles defined in such a way.
-Scott
^ permalink raw reply
* [PATCH] arm64: dts: Add ARM PMU node for exynos7
From: Alim Akhtar @ 2016-11-10 3:30 UTC (permalink / raw)
To: linux-arm-kernel
This patch adds ARM Performance Monitor Unit dt node for exynos7.
PMU provides various statistics on the operation of the CPU and
memory system at runtime, which are very useful when debugging or
profiling code. This enables the same.
Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
---
arch/arm64/boot/dts/exynos/exynos7.dtsi | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/exynos/exynos7.dtsi b/arch/arm64/boot/dts/exynos/exynos7.dtsi
index e0d0d01..53ce4be 100644
--- a/arch/arm64/boot/dts/exynos/exynos7.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos7.dtsi
@@ -472,6 +472,14 @@
status = "disabled";
};
+ arm-pmu {
+ compatible = "arm,cortex-a57-pmu", "arm,armv8-pmuv3";
+ interrupts = <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 58 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 59 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
timer {
compatible = "arm,armv8-timer";
interrupts = <GIC_PPI 13
--
1.7.10.4
^ permalink raw reply related
* [PATCH v2 01/30] usb: dwc2: Deprecate g-use-dma binding
From: John Youn @ 2016-11-10 3:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1478748145.git.johnyoun@synopsys.com>
This is not needed as the gadget now fully supports DMA and it can
autodetect it. This was initially added because gadget DMA mode was only
partially implemented so could not be automatically enabled.
Signed-off-by: John Youn <johnyoun@synopsys.com>
---
Documentation/devicetree/bindings/usb/dwc2.txt | 4 +++-
arch/arm/boot/dts/rk3036.dtsi | 1 -
arch/arm/boot/dts/rk3288.dtsi | 1 -
arch/arm/boot/dts/rk3xxx.dtsi | 1 -
arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 1 -
arch/arm64/boot/dts/rockchip/rk3368.dtsi | 1 -
drivers/usb/dwc2/core.h | 4 +---
drivers/usb/dwc2/params.c | 17 ++++++++++++++---
drivers/usb/dwc2/pci.c | 1 -
9 files changed, 18 insertions(+), 13 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/dwc2.txt b/Documentation/devicetree/bindings/usb/dwc2.txt
index 9472111..389bb13 100644
--- a/Documentation/devicetree/bindings/usb/dwc2.txt
+++ b/Documentation/devicetree/bindings/usb/dwc2.txt
@@ -26,11 +26,13 @@ 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.
- g-rx-fifo-size: size of rx fifo size in gadget mode.
- g-np-tx-fifo-size: size of non-periodic tx fifo size in gadget mode.
- g-tx-fifo-size: size of periodic tx fifo per endpoint (except ep0) in gadget mode.
+Deprecated properties:
+- g-use-dma: gadget DMA mode is automatically detected
+
Example:
usb at 101c0000 {
diff --git a/arch/arm/boot/dts/rk3036.dtsi b/arch/arm/boot/dts/rk3036.dtsi
index a935523..7c2dc19 100644
--- a/arch/arm/boot/dts/rk3036.dtsi
+++ b/arch/arm/boot/dts/rk3036.dtsi
@@ -204,7 +204,6 @@
g-np-tx-fifo-size = <16>;
g-rx-fifo-size = <275>;
g-tx-fifo-size = <256 128 128 64 64 32>;
- g-use-dma;
status = "disabled";
};
diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 17ec2e2..74a749c 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -596,7 +596,6 @@
g-np-tx-fifo-size = <16>;
g-rx-fifo-size = <275>;
g-tx-fifo-size = <256 128 128 64 64 32>;
- g-use-dma;
phys = <&usbphy0>;
phy-names = "usb2-phy";
status = "disabled";
diff --git a/arch/arm/boot/dts/rk3xxx.dtsi b/arch/arm/boot/dts/rk3xxx.dtsi
index e15beb3..8fbd3c8 100644
--- a/arch/arm/boot/dts/rk3xxx.dtsi
+++ b/arch/arm/boot/dts/rk3xxx.dtsi
@@ -181,7 +181,6 @@
g-np-tx-fifo-size = <16>;
g-rx-fifo-size = <275>;
g-tx-fifo-size = <256 128 128 64 64 32>;
- g-use-dma;
phys = <&usbphy0>;
phy-names = "usb2-phy";
status = "disabled";
diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
index 17839db..e0ea603 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
@@ -747,7 +747,6 @@
clocks = <&sys_ctrl HI6220_USBOTG_HCLK>;
clock-names = "otg";
dr_mode = "otg";
- g-use-dma;
g-rx-fifo-size = <512>;
g-np-tx-fifo-size = <128>;
g-tx-fifo-size = <128 128 128 128 128 128>;
diff --git a/arch/arm64/boot/dts/rockchip/rk3368.dtsi b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
index 0fcb214..df231c4 100644
--- a/arch/arm64/boot/dts/rockchip/rk3368.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
@@ -537,7 +537,6 @@
g-np-tx-fifo-size = <16>;
g-rx-fifo-size = <275>;
g-tx-fifo-size = <256 128 128 64 64 32>;
- g-use-dma;
status = "disabled";
};
diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index a1075ad..f8c97f5 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -418,9 +418,7 @@ enum dwc2_ep0_state {
* needed.
* 0 - No (default)
* 1 - Yes
- * @g_dma: If true, enables dma usage on the device. This
- * setting is not auto-detected. It must be
- * explicitly enabled (default: false).
+ * @g_dma: Enables gadget dma usage (default: autodetect).
* @g_rx_fifo_size: The periodic rx fifo size for the device, in
* DWORDS from 16-32768 (default: 2048 if
* possible, otherwise autodetect).
diff --git a/drivers/usb/dwc2/params.c b/drivers/usb/dwc2/params.c
index 2eb79e8..74c3728 100644
--- a/drivers/usb/dwc2/params.c
+++ b/drivers/usb/dwc2/params.c
@@ -1086,6 +1086,19 @@ static void dwc2_set_param_tx_fifo_sizes(struct dwc2_hsotg *hsotg)
}
}
+static void dwc2_set_gadget_dma(struct dwc2_hsotg *hsotg)
+{
+ struct dwc2_hw_params *hw = &hsotg->hw_params;
+ struct dwc2_core_params *p = &hsotg->params;
+ bool dma_capable = !(hw->arch == GHWCFG2_SLAVE_ONLY_ARCH);
+
+ /* Buffer DMA */
+ dwc2_set_param_bool(hsotg, &p->g_dma,
+ false, "gadget-dma",
+ true, false,
+ dma_capable);
+}
+
/**
* dwc2_set_parameters() - Set all core parameters.
*
@@ -1161,9 +1174,7 @@ static void dwc2_set_parameters(struct dwc2_hsotg *hsotg,
(hsotg->dr_mode == USB_DR_MODE_OTG)) {
dev_dbg(hsotg->dev, "Setting peripheral device properties\n");
- dwc2_set_param_bool(hsotg, &p->g_dma, true, "g-use-dma",
- false, false,
- dma_capable);
+ dwc2_set_gadget_dma(hsotg);
/*
* The values for g_rx_fifo_size (2048) and
diff --git a/drivers/usb/dwc2/pci.c b/drivers/usb/dwc2/pci.c
index b3f3b58..a23329e 100644
--- a/drivers/usb/dwc2/pci.c
+++ b/drivers/usb/dwc2/pci.c
@@ -67,7 +67,6 @@ static int dwc2_pci_quirks(struct pci_dev *pdev, struct platform_device *dwc2)
if (pdev->vendor == PCI_VENDOR_ID_SYNOPSYS &&
pdev->device == PCI_PRODUCT_ID_HAPS_HSOTG) {
struct property_entry properties[] = {
- PROPERTY_ENTRY_BOOL("g-use-dma"),
{ },
};
--
2.10.0
^ permalink raw reply related
* [PATCH v2 00/30] usb: dwc2: Gadget descriptor DMA and IOT
From: John Youn @ 2016-11-10 3:27 UTC (permalink / raw)
To: linux-arm-kernel
This series implements gadget-side descriptor DMA for the DWC_hsotg
controller.
It also includes support for DWC USB IOT controllers which use the
descriptor DMA mode of operation exclusively. These are two new
device-only USB controller IPs based on DWC_hsotg.
Tested on HAPS platform with:
* HSOTG IP version 3.30a
* FS/LS IOT IP version 1.00a
* HS IOT IP version 1.00a
v2:
* Remove the DMA 'enable' bindings and make them autodetected.
* Add DMA 'disable' bindings to override.
* Separate out commit to add '__packed' attribute.
* Don't print errors on -ENOMEM.
* Remove unnecessary GFP_ATOMIC flags.
* Remove unnecessary patch removing a WARN_ON.
* Reorganize and clarify BNA interrupt.
* Fix issue with enabling STSPHSERCVD interrupt.
Regards,
John
John Youn (4):
usb: dwc2: Deprecate g-use-dma binding
usb: dwc2: Update DMA descriptor structure
usb: dwc2: Make the DMA descriptor structure packed
usb: dwc2: Add bindings to disable gadget DMA modes
Vahram Aharonyan (23):
usb: dwc2: gadget: Add descriptor DMA parameter
usb: dwc2: gadget: Add DMA descriptor status quadlet fields
usb: dwc2: gadget: Add DMA descriptor chains for EP 0
usb: dwc2: host: Rename MAX_DMA_DESC_SIZE to HOST_DMA_NBYTES_LIMIT
usb: dwc2: gadget: Transfer length limit checking for DDMA
usb: dwc2: gadget: Add DDMA chain pointers to dwc2_hsotg_ep structure
usb: dwc2: gadget: Add DDMA chain fill and parse functions
usb: dwc2: gadget: EP 0 specific DDMA programming
usb: dwc2: gadget: DDMA transfer start and complete
usb: dwc2: gadget: Fixes for StsPhseRcvd interrupt
usb: dwc2: gadget: Start DDMA IN status phase in StsPhseRcvd handler
usb: dwc2: gadget: Enable descriptor DMA mode
usb: dwc2: gadget: Add DDMA isoc related fields to dwc2_hsotg_ep
usb: dwc2: gadget: Fill isoc descriptor and start transfer in DDMA
usb: dwc2: gadget: Add completions for DDMA isoc transfers
usb: dwc2: gadget: In DDMA keep incompISOOUT and incompISOIN masked
usb: dwc2: gadget: Add start and complete calls for DDMA ISOC
usb: dwc2: gadget: Enable the BNA interrupt
usb: dwc2: gadget: Adjust ISOC OUT request's actual len for DDMA
usb: dwc2: gadget: For DDMA parse setup only after SetUp interrupt
usb: dwc2: gadget: Correct dwc2_hsotg_ep_stop_xfr() function
usb: dwc2: gadget: Disable enabled HW endpoint in
dwc2_hsotg_ep_disable
usb: dwc2: Add support of dedicated full-speed PHY interface
Vardan Mikayelyan (3):
usb: dwc2: gadget: Add IOT device IDs, configure core accordingly
usb: dwc2: gadget: Program ep0_mps for LS
usb: dwc2: gadget: Add new core parameter for low speed
Documentation/devicetree/bindings/usb/dwc2.txt | 6 +-
arch/arm/boot/dts/rk3036.dtsi | 1 -
arch/arm/boot/dts/rk3288.dtsi | 1 -
arch/arm/boot/dts/rk3xxx.dtsi | 1 -
arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 1 -
arch/arm64/boot/dts/rockchip/rk3368.dtsi | 1 -
drivers/usb/dwc2/core.h | 50 +-
drivers/usb/dwc2/gadget.c | 968 ++++++++++++++++++++++---
drivers/usb/dwc2/hcd.c | 12 +-
drivers/usb/dwc2/hcd.h | 2 +-
drivers/usb/dwc2/hcd_ddma.c | 52 +-
drivers/usb/dwc2/hw.h | 48 +-
drivers/usb/dwc2/params.c | 45 +-
drivers/usb/dwc2/pci.c | 1 -
14 files changed, 1023 insertions(+), 166 deletions(-)
--
2.10.0
^ permalink raw reply
* [PATCH v2 2/6] mfd: dt: Add bindings for the Aspeed SoC Display Controller (GFX)
From: Joel Stanley @ 2016-11-10 3:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161109182630.tg3puvwurgx6iinw@rob-hp-laptop>
On Thu, Nov 10, 2016 at 4:56 AM, Rob Herring <robh@kernel.org> wrote:
> On Thu, Nov 03, 2016 at 01:07:57AM +1030, Andrew Jeffery wrote:
>> The Aspeed SoC Display Controller is presented as a syscon device to
>> arbitrate access by display and pinmux drivers. Video pinmux
>> configuration on fifth generation SoCs depends on bits in both the
>> System Control Unit and the Display Controller.
>>
>> Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
>> ---
>> Documentation/devicetree/bindings/mfd/aspeed-gfx.txt | 17 +++++++++++++++++
>
> The register space can't be split to 2 nodes?
Do you mean splitting the GFX IP and enable register into two nodes?
We can't. Pinmux needs to check bit 6 and 7 in GFX064, which is in the
middle the IP block:
GFX060: CRT Control Register I
GFX064: CRT Control Register II
GFX068: CRT Status Register
GFX06C: CRT Misc Setting Register
>> +The Aspeed SoC Display Controller primarily does as its name suggests, but also
>> +participates in pinmux requests on the g5 SoCs. It is therefore considered a
>> +syscon device.
>> +
>> +Required properties:
>> +- compatible: "aspeed,ast2500-gfx", "syscon"
>
> I think perhaps we should drop the syscon here and the driver should
> just register as a syscon.
We want the regmap to be present whenever the GFX driver or pinmux is
loaded. If we register it in pinmux but chose to not build in that
driver, we lack the regmap. Same for the case where a user builds in
the GFX driver and not pinmux. I think this means we want the syscon
compatible string, unless my understanding is wrong?
Cheers,
Joel
^ permalink raw reply
* [PATCH] phy: rockchip-inno-usb2: correct 480MHz output clock stable time
From: wlf @ 2016-11-10 2:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAD=FV=VC15_QAs7+DOoqCeWrU6-qqnUku2SSPFLOvLanu8xL3g@mail.gmail.com>
Hi Doug,
? 2016?11?10? 04:54, Doug Anderson ??:
> Hi,
>
> On Mon, Nov 7, 2016 at 5:00 AM, William Wu <wulf@rock-chips.com> 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@rock-chips.com>
>> ---
>> 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 ...)
Thanks a lot for your suggestion.
I agree with you. clk_enable() will call spin_lock_irqsave() to disable
interrupt, and we add
more than 1ms in clk_enable may cause big latency.
And according to clk_prepare() description:
In a simple case, clk_prepare can be used instead of clk_enable to
ungate a clk if the
operation may sleep. One example is a clk which is accessed over I2c.
So maybe we can remove the clock to clk_prepare.
Hi Heiko, Frank,
What do you think of it?
Best regards,
wulf
>
> -Doug
>
>
>
^ permalink raw reply
* [PATCH 1/3] ipmi/bt-bmc: change compatible node to 'aspeed, ast2400-ibt-bmc'
From: Joel Stanley @ 2016-11-10 2:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2278270.0oJqDfoDd9@wuerfel>
On Thu, Nov 10, 2016 at 2:39 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Tuesday, November 8, 2016 12:15:57 PM CET Corey Minyard wrote:
>> On 11/08/2016 09:52 AM, C?dric Le Goater wrote:
>> > O
>> snip
>>
>> >>>> While we're modifying the binding, should we add a compat string for
>> >>>> the ast2500?
>> >>> Well, if the change in this patch is fine for all, may be we can add
>> >>> the ast2500 compat string in a followup patch ?
>> >> Sounds good to me.
>> > OK. So, how do we proceed with this patch ? Who would include it in its
>> > tree ?
>>
>> I don't have anything for 4.9 at the moment. Arnd, if you have
>> something, can
>> you take this? Otherwise I will.
>>
>> And I guess I should add:
>>
>> Acked-by: Corey Minyard <cminyard@mvista.com>
>
> Thanks, I've added it to my todo folder.
>
> Olof, if you do fixes before I do, please pick up this patch with
> Corey's Ack.
Thank you!
Acked-by: Joel Stanley <joel@jms.id.au>
Cheers,
Joel
^ permalink raw reply
* [PATCH 3/3] ipmi/bt-bmc: add a sysfs file to configure a maximum response time
From: Joel Stanley @ 2016-11-10 2:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7e7e5cde-341a-ecca-9c9c-b41695703b08@acm.org>
On Thu, Nov 10, 2016 at 2:34 AM, Corey Minyard <minyard@acm.org> wrote:
> On 11/09/2016 08:42 AM, C?dric Le Goater wrote:
>> The patch raises a few questions on the "BT Interface Capabilities" :
>>
>> - should we use sysfs or a specific ioctl to configure the driver ?
>
>
> I should probably say sysfs, but really I don't care. The hard part about
> ioctls is the compat, and there shouldn't be any compat issues with this
> interface. An ioctl is probably easier, especially if you add an ioctl for
> the header size thing I talked about in the previous email.
>
> The only thing that matters to the driver is the timeout. If you want to
> make the timeout per fd, then it will have to be an ioctl.
I vote for an ioctl as it's simpler for userspace.
In another driver we use on the BMCs we have a character device and a
few sysfs files for configuration. This means userspace needs to
discover and open > 1 fd, which is annoying.
Cheers,
Joel
>> - should the driver handle directly the response to the "Get BT
>> Interface Capabilities" command ?
>
>
> That probably belongs in userspace. The only reason I can think of
> to have it in the driver would be so the host driver can fetch it if the
> BMC userspace is down, but I can't see how that's a good idea.
>
> Hope my wishy-washy answer helps :-).
^ permalink raw reply
* [arm-soc:to-build 12/13] drivers/block/rbd.c:3690:5: warning: 'struct_v' may be used uninitialized in this function
From: kbuild test robot @ 2016-11-10 2:44 UTC (permalink / raw)
To: linux-arm-kernel
tree: https://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git to-build
head: 694200c14d09069de036d1b4269b582b3118f575
commit: 3becf66c6faa12e51bd6d97df3706c8bef1b65d6 [12/13] Kbuild: enable -Wmaybe-uninitialized warnings by default
config: xtensa-allmodconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 4.9.0
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 3becf66c6faa12e51bd6d97df3706c8bef1b65d6
# save the attached .config to linux build tree
make.cross ARCH=xtensa
Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings
All warnings (new ones prefixed by >>):
drivers/block/rbd.c: In function 'rbd_watch_cb':
>> drivers/block/rbd.c:3690:5: warning: 'struct_v' may be used uninitialized in this function [-Wmaybe-uninitialized]
if (struct_v >= 2) {
^
drivers/block/rbd.c:3759:5: note: 'struct_v' was declared here
u8 struct_v;
^
vim +/struct_v +3690 drivers/block/rbd.c
ed95b21a Ilya Dryomov 2016-08-12 3674 } else {
ed95b21a Ilya Dryomov 2016-08-12 3675 down_read(&rbd_dev->lock_rwsem);
ed95b21a Ilya Dryomov 2016-08-12 3676 }
ed95b21a Ilya Dryomov 2016-08-12 3677
ed95b21a Ilya Dryomov 2016-08-12 3678 if (!__rbd_is_lock_owner(rbd_dev))
ed95b21a Ilya Dryomov 2016-08-12 3679 wake_requests(rbd_dev, false);
ed95b21a Ilya Dryomov 2016-08-12 3680 up_read(&rbd_dev->lock_rwsem);
ed95b21a Ilya Dryomov 2016-08-12 3681 }
ed95b21a Ilya Dryomov 2016-08-12 3682
ed95b21a Ilya Dryomov 2016-08-12 3683 static bool rbd_handle_request_lock(struct rbd_device *rbd_dev, u8 struct_v,
ed95b21a Ilya Dryomov 2016-08-12 3684 void **p)
ed95b21a Ilya Dryomov 2016-08-12 3685 {
ed95b21a Ilya Dryomov 2016-08-12 3686 struct rbd_client_id my_cid = rbd_get_cid(rbd_dev);
ed95b21a Ilya Dryomov 2016-08-12 3687 struct rbd_client_id cid = { 0 };
ed95b21a Ilya Dryomov 2016-08-12 3688 bool need_to_send;
ed95b21a Ilya Dryomov 2016-08-12 3689
ed95b21a Ilya Dryomov 2016-08-12 @3690 if (struct_v >= 2) {
ed95b21a Ilya Dryomov 2016-08-12 3691 cid.gid = ceph_decode_64(p);
ed95b21a Ilya Dryomov 2016-08-12 3692 cid.handle = ceph_decode_64(p);
ed95b21a Ilya Dryomov 2016-08-12 3693 }
ed95b21a Ilya Dryomov 2016-08-12 3694
ed95b21a Ilya Dryomov 2016-08-12 3695 dout("%s rbd_dev %p cid %llu-%llu\n", __func__, rbd_dev, cid.gid,
ed95b21a Ilya Dryomov 2016-08-12 3696 cid.handle);
ed95b21a Ilya Dryomov 2016-08-12 3697 if (rbd_cid_equal(&cid, &my_cid))
ed95b21a Ilya Dryomov 2016-08-12 3698 return false;
:::::: The code at line 3690 was first introduced by commit
:::::: ed95b21a4b0a71ef89306cdeb427d53cc9cb343f rbd: support for exclusive-lock feature
:::::: TO: Ilya Dryomov <idryomov@gmail.com>
:::::: CC: Ilya Dryomov <idryomov@gmail.com>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 47027 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161110/0247dbdf/attachment-0001.gz>
^ permalink raw reply
* [PATCH V6 2/3] ACPI: Add support for ResourceSource/IRQ domain mapping
From: Hanjun Guo @ 2016-11-10 2:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477687696-1509-3-git-send-email-agustinv@codeaurora.org>
Hi Marc, Rafael, Lorenzo,
Since we agreed to add a probe deferral if we failed to get irq
resources which mirroring the DT does (patch 1 in this patch set),
I think the last blocker to make things work both for Agustin and
me [1] is this patch, which makes the interrupt producer and consumer
work in ACPI, we have two different solution for one thing, we'd happy
to work together for one solution, could you give some suggestions
please?
[1]: https://mail-archive.com/linux-kernel at vger.kernel.org/msg1257419.html
Agustin, I have some comments below.
On 2016/10/29 4:48, Agustin Vega-Frias wrote:
> This allows irqchip drivers to associate an ACPI DSDT device to
> an IRQ domain and provides support for using the ResourceSource
> in Extended IRQ Resources to find the domain and map the IRQs
> specified on that domain.
>
> Signed-off-by: Agustin Vega-Frias <agustinv@codeaurora.org>
> ---
> drivers/acpi/Makefile | 1 +
> drivers/acpi/irqdomain.c | 119 +++++++++++++++++++++++++++++++++++++++++++++++
Could we just reuse the gsi.c and not introduce a new
file, probably we can change the gsi.c to irqdomain.c
or something similar, then reuse the code in gsi.c.
Thanks
Hanjun
> drivers/acpi/resource.c | 21 +++++----
> include/linux/acpi.h | 25 ++++++++++
> 4 files changed, 157 insertions(+), 9 deletions(-)
> create mode 100644 drivers/acpi/irqdomain.c
>
> diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
> index 9ed0878..880401b 100644
> --- a/drivers/acpi/Makefile
> +++ b/drivers/acpi/Makefile
> @@ -57,6 +57,7 @@ acpi-$(CONFIG_ACPI_PROCFS_POWER) += cm_sbs.o
> acpi-y += acpi_lpat.o
> acpi-$(CONFIG_ACPI_GENERIC_GSI) += gsi.o
> acpi-$(CONFIG_ACPI_WATCHDOG) += acpi_watchdog.o
> +acpi-$(CONFIG_IRQ_DOMAIN) += irqdomain.o
>
> # These are (potentially) separate modules
>
> diff --git a/drivers/acpi/irqdomain.c b/drivers/acpi/irqdomain.c
> new file mode 100644
> index 0000000..11d3658
> --- /dev/null
> +++ b/drivers/acpi/irqdomain.c
> @@ -0,0 +1,119 @@
> +/*
> + * ACPI ResourceSource/IRQ domain mapping support
> + *
> + * Copyright (c) 2016, The Linux Foundation. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only version 2 as published by the Free Software Foundation.
> + *
> + * This program 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.
> + */
> +#include <linux/acpi.h>
> +#include <linux/irq.h>
> +#include <linux/irqdomain.h>
> +
> +/**
> + * acpi_irq_domain_register_irq() - Register the mapping for an IRQ produced
> + * by the given acpi_resource_source to a
> + * Linux IRQ number
> + * @source: IRQ source
> + * @hwirq: Hardware IRQ number
> + * @trigger: trigger type of the IRQ number to be mapped
> + * @polarity: polarity of the IRQ to be mapped
> + *
> + * Returns: a valid linux IRQ number on success
> + * -ENODEV if the given acpi_resource_source cannot be found
> + * -EPROBE_DEFER if the IRQ domain has not been registered
> + * -EINVAL for all other errors
> + */
> +int acpi_irq_domain_register_irq(const struct acpi_resource_source *source,
> + u32 hwirq, int trigger, int polarity)
> +{
> + struct irq_fwspec fwspec;
> + struct acpi_device *device;
> + acpi_handle handle;
> + acpi_status status;
> + int ret;
> +
> + /* An empty acpi_resource_source means it is a GSI */
> + if (!source->string_length)
> + return acpi_register_gsi(NULL, hwirq, trigger, polarity);
> +
> + status = acpi_get_handle(NULL, source->string_ptr, &handle);
> + if (ACPI_FAILURE(status))
> + return -ENODEV;
> +
> + device = acpi_bus_get_acpi_device(handle);
> + if (!device)
> + return -ENODEV;
> +
> + if (irq_find_matching_fwnode(&device->fwnode, DOMAIN_BUS_ANY) == NULL) {
> + ret = -EPROBE_DEFER;
> + goto out_put_device;
> + }
> +
> + fwspec.fwnode = &device->fwnode;
> + fwspec.param[0] = hwirq;
> + fwspec.param[1] = acpi_dev_get_irq_type(trigger, polarity);
> + fwspec.param_count = 2;
> +
> + ret = irq_create_fwspec_mapping(&fwspec);
> +
> +out_put_device:
> + acpi_bus_put_acpi_device(device);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(acpi_irq_domain_register_irq);
> +
> +/**
> + * acpi_irq_domain_unregister_irq() - Delete the mapping for an IRQ produced
> + * by the given acpi_resource_source to a
> + * Linux IRQ number
> + * @source: IRQ source
> + * @hwirq: Hardware IRQ number
> + *
> + * Returns: 0 on success
> + * -ENODEV if the given acpi_resource_source cannot be found
> + * -EINVAL for all other errors
> + */
> +int acpi_irq_domain_unregister_irq(const struct acpi_resource_source *source,
> + u32 hwirq)
> +{
> + struct irq_domain *domain;
> + struct acpi_device *device;
> + acpi_handle handle;
> + acpi_status status;
> + int ret = 0;
> +
> + if (!source->string_length) {
> + acpi_unregister_gsi(hwirq);
> + return 0;
> + }
> +
> + status = acpi_get_handle(NULL, source->string_ptr, &handle);
> + if (ACPI_FAILURE(status))
> + return -ENODEV;
> +
> + device = acpi_bus_get_acpi_device(handle);
> + if (!device)
> + return -ENODEV;
> +
> + domain = irq_find_matching_fwnode(&device->fwnode, DOMAIN_BUS_ANY);
> + if (!domain) {
> + ret = -EINVAL;
> + goto out_put_device;
> + }
> +
> + irq_dispose_mapping(irq_find_mapping(domain, hwirq));
> +
> +out_put_device:
> + acpi_bus_put_acpi_device(device);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(acpi_irq_domain_unregister_irq);
> diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
> index 4beda15..ccb6f4f 100644
> --- a/drivers/acpi/resource.c
> +++ b/drivers/acpi/resource.c
> @@ -381,14 +381,15 @@ static void acpi_dev_irqresource_disabled(struct resource *res, u32 gsi)
> res->flags = IORESOURCE_IRQ | IORESOURCE_DISABLED | IORESOURCE_UNSET;
> }
>
> -static void acpi_dev_get_irqresource(struct resource *res, u32 gsi,
> +static void acpi_dev_get_irqresource(struct resource *res, u32 hwirq,
> + const struct acpi_resource_source *source,
> u8 triggering, u8 polarity, u8 shareable,
> bool legacy)
> {
> int irq, p, t;
>
> - if (!valid_IRQ(gsi)) {
> - acpi_dev_irqresource_disabled(res, gsi);
> + if ((source->string_length == 0) && !valid_IRQ(hwirq)) {
> + acpi_dev_irqresource_disabled(res, hwirq);
> return;
> }
>
> @@ -402,25 +403,25 @@ static void acpi_dev_get_irqresource(struct resource *res, u32 gsi,
> * using extended IRQ descriptors we take the IRQ configuration
> * from _CRS directly.
> */
> - if (legacy && !acpi_get_override_irq(gsi, &t, &p)) {
> + if (legacy && !acpi_get_override_irq(hwirq, &t, &p)) {
> u8 trig = t ? ACPI_LEVEL_SENSITIVE : ACPI_EDGE_SENSITIVE;
> u8 pol = p ? ACPI_ACTIVE_LOW : ACPI_ACTIVE_HIGH;
>
> if (triggering != trig || polarity != pol) {
> - pr_warning("ACPI: IRQ %d override to %s, %s\n", gsi,
> - t ? "level" : "edge", p ? "low" : "high");
> + pr_warn("ACPI: IRQ %d override to %s, %s\n", hwirq,
> + t ? "level" : "edge", p ? "low" : "high");
> triggering = trig;
> polarity = pol;
> }
> }
>
> res->flags = acpi_dev_irq_flags(triggering, polarity, shareable);
> - irq = acpi_register_gsi(NULL, gsi, triggering, polarity);
> + irq = acpi_irq_domain_register_irq(source, hwirq, triggering, polarity);
> if (irq >= 0) {
> res->start = irq;
> res->end = irq;
> } else {
> - acpi_dev_irqresource_disabled(res, gsi);
> + acpi_dev_irqresource_disabled(res, hwirq);
> }
> }
>
> @@ -446,6 +447,7 @@ static void acpi_dev_get_irqresource(struct resource *res, u32 gsi,
> bool acpi_dev_resource_interrupt(struct acpi_resource *ares, int index,
> struct resource *res)
> {
> + const struct acpi_resource_source dummy = { 0, 0, NULL };
> struct acpi_resource_irq *irq;
> struct acpi_resource_extended_irq *ext_irq;
>
> @@ -460,7 +462,7 @@ bool acpi_dev_resource_interrupt(struct acpi_resource *ares, int index,
> acpi_dev_irqresource_disabled(res, 0);
> return false;
> }
> - acpi_dev_get_irqresource(res, irq->interrupts[index],
> + acpi_dev_get_irqresource(res, irq->interrupts[index], &dummy,
> irq->triggering, irq->polarity,
> irq->sharable, true);
> break;
> @@ -471,6 +473,7 @@ bool acpi_dev_resource_interrupt(struct acpi_resource *ares, int index,
> return false;
> }
> acpi_dev_get_irqresource(res, ext_irq->interrupts[index],
> + &ext_irq->resource_source,
> ext_irq->triggering, ext_irq->polarity,
> ext_irq->sharable, false);
> break;
> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
> index 40213c4..ce30a12 100644
> --- a/include/linux/acpi.h
> +++ b/include/linux/acpi.h
> @@ -321,6 +321,31 @@ void acpi_set_irq_model(enum acpi_irq_model_id model,
> */
> void acpi_unregister_gsi (u32 gsi);
>
> +#ifdef CONFIG_IRQ_DOMAIN
> +
> +int acpi_irq_domain_register_irq(const struct acpi_resource_source *source,
> + u32 hwirq, int trigger, int polarity);
> +int acpi_irq_domain_unregister_irq(const struct acpi_resource_source *source,
> + u32 hwirq);
> +
> +#else
> +
> +static inline int acpi_irq_domain_register_irq(
> + const struct acpi_resource_source *source, u32 hwirq, int trigger,
> + int polarity)
> +{
> + return acpi_register_gsi(NULL, hwirq, trigger, polarity);
> +}
> +
> +static inline int acpi_irq_domain_unregister_irq(
> + const struct acpi_resource_source *source, u32 hwirq)
> +{
> + acpi_unregister_gsi(hwirq);
> + return 0;
> +}
> +
> +#endif /* CONFIG_IRQ_DOMAIN */
> +
> struct pci_dev;
>
> int acpi_pci_irq_enable (struct pci_dev *dev);
>
^ permalink raw reply
* [PATCH 4/4] dts: arm64: enable mmc3 for supporting sdio feature
From: Yingjoe Chen @ 2016-11-10 2:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478585341-6749-5-git-send-email-yong.mao@mediatek.com>
On Tue, 2016-11-08 at 14:09 +0800, Yong Mao wrote:
> From: yong mao <yong.mao@mediatek.com>
>
> Add description of mmc3 for supporting sdio feature
>
> Signed-off-by: Yong Mao <yong.mao@mediatek.com>
> Signed-off-by: Chaotian Jing <chaotian.jing@mediatek.com>
> ---
> arch/arm64/boot/dts/mediatek/mt8173-evb.dts | 82 +++++++++++++++++++++++++++
> 1 file changed, 82 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
> index 2a7f731..4dbd299 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
> +++ b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
> @@ -43,6 +43,14 @@
> enable-active-high;
> };
>
> + sdio_fixed_3v3: fixedregulator at 0 {
This should be regulator at 1 instead of fixedregulator.
> + compatible = "regulator-fixed";
> + regulator-name = "3V3";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + gpio = <&pio 85 GPIO_ACTIVE_HIGH>;
> + };
> +
> connector {
> compatible = "hdmi-connector";
> label = "hdmi";
> @@ -139,6 +147,25 @@
> vqmmc-supply = <&mt6397_vmc_reg>;
> };
>
> +&mmc3 {
> + status = "okay";
> + pinctrl-names = "default", "state_uhs";
> + pinctrl-0 = <&mmc3_pins_default>;
> + pinctrl-1 = <&mmc3_pins_uhs>;
> + bus-width = <4>;
> + max-frequency = <200000000>;
> + cap-sd-highspeed;
> + sd-uhs-sdr50;
> + sd-uhs-sdr104;
> + sdr104-clk-delay = <5>;
> + keep-power-in-suspend;
> + enable-sdio-wakeup;
> + cap-sdio-irq;
> + vmmc-supply = <&sdio_fixed_3v3>;
> + vqmmc-supply = <&mt6397_vgp3_reg>;
> + non-removable;
> +};
> +
> &pio {
> disp_pwm0_pins: disp_pwm0_pins {
> pins1 {
> @@ -197,6 +224,36 @@
> };
> };
>
> + mmc3_pins_default: mmc3default {
Please keep nodes in &pio sorted, move this one after mmc1_pins_uhs.
> + pins_dat {
> + pinmux = <MT8173_PIN_22_MSDC3_DAT0__FUNC_MSDC3_DAT0>,
> + <MT8173_PIN_23_MSDC3_DAT1__FUNC_MSDC3_DAT1>,
> + <MT8173_PIN_24_MSDC3_DAT2__FUNC_MSDC3_DAT2>,
> + <MT8173_PIN_25_MSDC3_DAT3__FUNC_MSDC3_DAT3>;
> + input-enable;
> + drive-strength = <MTK_DRIVE_8mA>;
> + bias-pull-up = <MTK_PUPD_SET_R1R0_10>;
> + };
> +
> + pins_cmd {
> + pinmux = <MT8173_PIN_27_MSDC3_CMD__FUNC_MSDC3_CMD>;
> + input-enable;
> + drive-strength = <MTK_DRIVE_8mA>;
> + bias-pull-up = <MTK_PUPD_SET_R1R0_10>;
> + };
> +
> + pins_clk {
> + pinmux = <MT8173_PIN_26_MSDC3_CLK__FUNC_MSDC3_CLK>;
> + bias-pull-down;
> + drive-strength = <MTK_DRIVE_8mA>;
> + };
> +
> + pins_pdn {
> + pinmux = <MT8173_PIN_85_AUD_DAT_MOSI__FUNC_GPIO85>;
> + output-low;
> + };
This one is used in regulator, not really an mmc pin.
Also, you don't need to add node for gpio usage, request_gpio will set
mode for you.
So please remove pins_pdn node.
> + };
> +
> mmc0_pins_uhs: mmc0 {
> pins_cmd_dat {
> pinmux = <MT8173_PIN_57_MSDC0_DAT0__FUNC_MSDC0_DAT0>,
> @@ -243,6 +300,31 @@
> bias-pull-down = <MTK_PUPD_SET_R1R0_10>;
> };
> };
> +
> + mmc3_pins_uhs: mmc3 {
Please keep nodes in &pio sorted, move this one after mmc1_pins_uhs.
Joe.C
> + pins_dat {
> + pinmux = <MT8173_PIN_22_MSDC3_DAT0__FUNC_MSDC3_DAT0>,
> + <MT8173_PIN_23_MSDC3_DAT1__FUNC_MSDC3_DAT1>,
> + <MT8173_PIN_24_MSDC3_DAT2__FUNC_MSDC3_DAT2>,
> + <MT8173_PIN_25_MSDC3_DAT3__FUNC_MSDC3_DAT3>;
> + input-enable;
> + drive-strength = <MTK_DRIVE_8mA>;
> + bias-pull-up = <MTK_PUPD_SET_R1R0_10>;
> + };
> +
> + pins_cmd {
> + pinmux = <MT8173_PIN_27_MSDC3_CMD__FUNC_MSDC3_CMD>;
> + input-enable;
> + drive-strength = <MTK_DRIVE_8mA>;
> + bias-pull-up = <MTK_PUPD_SET_R1R0_10>;
> + };
> +
> + pins_clk {
> + pinmux = <MT8173_PIN_26_MSDC3_CLK__FUNC_MSDC3_CLK>;
> + drive-strength = <MTK_DRIVE_8mA>;
> + bias-pull-down = <MTK_PUPD_SET_R1R0_10>;
> + };
> + };
> };
>
> &pwm0 {
^ 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