* [PATCH V2 fix 4/6] mm: mempolicy: intruduce a helper huge_nodemask()
From: Huang Shijie @ 2016-11-16 6:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479107259-2011-5-git-send-email-shijie.huang@arm.com>
This patch intruduces a new helper huge_nodemask(),
we can use it to get the node mask.
This idea of the function is from the init_nodemask_of_mempolicy():
Return true if we can succeed in extracting the node_mask
for 'bind' or 'interleave' policy or initializing the node_mask
to contain the single node for 'preferred' or 'local' policy.
Signed-off-by: Huang Shijie <shijie.huang@arm.com>
---
The previous version does not treat the MPOL_PREFERRED/MPOL_INTERLEAVE cases.
This patch adds the code to set proper node mask for
MPOL_PREFERRED/MPOL_INTERLEAVE.
---
include/linux/mempolicy.h | 8 ++++++++
mm/mempolicy.c | 47 +++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 55 insertions(+)
diff --git a/include/linux/mempolicy.h b/include/linux/mempolicy.h
index 5e5b296..7796a40 100644
--- a/include/linux/mempolicy.h
+++ b/include/linux/mempolicy.h
@@ -145,6 +145,8 @@ extern void mpol_rebind_task(struct task_struct *tsk, const nodemask_t *new,
enum mpol_rebind_step step);
extern void mpol_rebind_mm(struct mm_struct *mm, nodemask_t *new);
+extern bool huge_nodemask(struct vm_area_struct *vma,
+ unsigned long addr, nodemask_t *mask);
extern struct zonelist *huge_zonelist(struct vm_area_struct *vma,
unsigned long addr, gfp_t gfp_flags,
struct mempolicy **mpol, nodemask_t **nodemask);
@@ -261,6 +263,12 @@ static inline void mpol_rebind_mm(struct mm_struct *mm, nodemask_t *new)
{
}
+static inline bool huge_nodemask(struct vm_area_struct *vma,
+ unsigned long addr, nodemask_t *mask)
+{
+ return false;
+}
+
static inline struct zonelist *huge_zonelist(struct vm_area_struct *vma,
unsigned long addr, gfp_t gfp_flags,
struct mempolicy **mpol, nodemask_t **nodemask)
diff --git a/mm/mempolicy.c b/mm/mempolicy.c
index 6d3639e..5063a69 100644
--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@ -1800,6 +1800,53 @@ static inline unsigned interleave_nid(struct mempolicy *pol,
#ifdef CONFIG_HUGETLBFS
/*
+ * huge_nodemask(@vma, @addr, @mask)
+ * @vma: virtual memory area whose policy is sought
+ * @addr: address in @vma
+ * @mask: a nodemask pointer
+ *
+ * Return true if we can succeed in extracting the policy nodemask
+ * for 'bind' or 'interleave' policy into the argument @mask, or
+ * initializing the argument @mask to contain the single node for
+ * 'preferred' or 'local' policy.
+ */
+bool huge_nodemask(struct vm_area_struct *vma, unsigned long addr,
+ nodemask_t *mask)
+{
+ struct mempolicy *mpol;
+ bool ret = true;
+ int nid;
+
+ if (!mask)
+ return false;
+
+ mpol = get_vma_policy(vma, addr);
+
+ switch (mpol->mode) {
+ case MPOL_PREFERRED:
+ if (mpol->flags & MPOL_F_LOCAL)
+ nid = numa_node_id();
+ else
+ nid = mpol->v.preferred_node;
+ init_nodemask_of_node(mask, nid);
+ break;
+
+ case MPOL_BIND:
+ /* Fall through */
+ case MPOL_INTERLEAVE:
+ *mask = mpol->v.nodes;
+ break;
+
+ default:
+ ret = false;
+ break;
+ }
+ mpol_cond_put(mpol);
+
+ return ret;
+}
+
+/*
* huge_zonelist(@vma, @addr, @gfp_flags, @mpol)
* @vma: virtual memory area whose policy is sought
* @addr: address in @vma for shared policy lookup and interleave policy
--
2.5.5
^ permalink raw reply related
* [PATCH v2] staging: vc04_services: rework ioctl code path
From: Greg KH @ 2016-11-16 6:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479245234.28223.1.camel@crowfest.net>
On Tue, Nov 15, 2016 at 01:27:14PM -0800, Michael Zoran wrote:
> I'll see what I can do, but since this is getting closer to the
> holidays I'm planing to spend less time on this. Perhaps someone else
> may be interested in cleaning up the ioctl path?
>
> Since the old code uses obsolete kernel features, it's going to take
> some work to fix without adding any checkpatch.pl warnings.
When just moving code around, it's ok to keep the same warnings, they
can be fixed up correctly later on.
thanks,
greg k-h
^ permalink raw reply
* Default atomic_pool_size value & changing it
From: Rafał Miłecki @ 2016-11-16 6:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACna6rwQp+kzkBBOJ7Jv=AGibqA9XK2qj4pqXUnJwUGg29BpZg@mail.gmail.com>
On 15 November 2016 at 22:43, Rafa? Mi?ecki <zajec5@gmail.com> wrote:
> On 15 November 2016 at 22:37, Russell King - ARM Linux
> <linux@armlinux.org.uk> wrote:
>> On Tue, Nov 15, 2016 at 10:15:51PM +0100, Rafa? Mi?ecki wrote:
>>> I've hit problem with allocating enough coherent DMA memory. Obviously
>>> there is a limit of this memory as pointed by:
>>> [ 0.283667] DMA: preallocated 256 KiB pool for atomic coherent allocations
>>
>> This is for _atomic_ coherent allocations, not for normal coherent
>> allocations. Normal coherent allocations come from the CMA memory.
>> Make sure you have CMA enabled, and you have enough of it.
>>
>> Boot with cma=xxxMB with xxx set appropriately.
>
> Oh, that definitely sounds like worth trying
> # CONFIG_CMA is not set
> thanks for pointing it to me!
For my quick testing I silly used:
cpu_addr[i] = dma_zalloc_coherent(dev, size, &dma_addr[i], GFP_ATOMIC);
which obviously shouldn't be done in non-sleep mode and shouldn't need
GFP_ATOMIC.
I got it now, thanks again.
--
Rafa?
^ permalink raw reply
* [PATCH] clk: qoriq: added ls1012a clock configuration
From: Scott Wood @ 2016-11-16 6:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479275900-42365-1-git-send-email-yuantian.tang@nxp.com>
On Wed, 2016-11-16 at 13:58 +0800, yuantian.tang at nxp.com wrote:
> From: Tang Yuantian <Yuantian.Tang@nxp.com>
>
> Added ls1012a clock configuation information.
Do we really need the same line in the changelog twice?
>
> Signed-off-by: Tang Yuantian <yuantian.tang@nxp.com>
> ---
> ?drivers/clk/clk-qoriq.c | 19 +++++++++++++++++++
> ?1 file changed, 19 insertions(+)
>
> diff --git a/drivers/clk/clk-qoriq.c b/drivers/clk/clk-qoriq.c
> index 1bece0f..563d874 100644
> --- a/drivers/clk/clk-qoriq.c
> +++ b/drivers/clk/clk-qoriq.c
> @@ -202,6 +202,14 @@ static const struct clockgen_muxinfo ls1021a_cmux = {
> ? }
> ?};
> ?
> +static const struct clockgen_muxinfo ls1012a_cmux = {
> + {
> + [0] = { CLKSEL_VALID, CGA_PLL1, PLL_DIV1 },
> + {},
> + [2] = { CLKSEL_VALID, CGA_PLL1, PLL_DIV2 },
> + }
> +};
> +
Based on the "ls1021a_cmux" in the context it looks like this patch is
intended to apply on top of?https://patchwork.kernel.org/patch/8923541/?but I
don't see any mention of that.
> ?static const struct clockgen_muxinfo t1040_cmux = {
> ? {
> ? [0] = { CLKSEL_VALID, CGA_PLL1, PLL_DIV1 },
> @@ -482,6 +490,16 @@ static const struct clockgen_chipinfo chipinfo[] = {
> ? .pll_mask = 0x03,
> ? },
> ? {
> + .compat = "fsl,ls1012a-clockgen",
> + .cmux_groups = {
> + &ls1012a_cmux
> + },
> + .cmux_to_group = {
> + 0, -1
> + },
> + .pll_mask = 0x03,
> + },
> + {
> ? .compat = "fsl,ls1043a-clockgen",
> ? .init_periph = t2080_init_periph,
> ? .cmux_groups = {
> @@ -1284,6 +1302,7 @@ CLK_OF_DECLARE(qoriq_clockgen_2, "fsl,qoriq-clockgen-
> 2.0", clockgen_init);
> ?CLK_OF_DECLARE(qoriq_clockgen_ls1021a, "fsl,ls1021a-clockgen",
> clockgen_init);
> ?CLK_OF_DECLARE(qoriq_clockgen_ls1043a, "fsl,ls1043a-clockgen",
> clockgen_init);
> ?CLK_OF_DECLARE(qoriq_clockgen_ls2080a, "fsl,ls2080a-clockgen",
> clockgen_init);
> +CLK_OF_DECLARE(qoriq_clockgen_ls1012a, "fsl,ls1012a-clockgen",
> clockgen_init);
Please keep these lists of chips sorted (or as close as you can in the case of
the cmux structs which already have some sorting issues).
-Scott
^ permalink raw reply
* [PATCH V2 fix 5/6] mm: hugetlb: add a new function to allocate a new gigantic page
From: Huang Shijie @ 2016-11-16 6:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479107259-2011-6-git-send-email-shijie.huang@arm.com>
There are three ways we can allocate a new gigantic page:
1. When the NUMA is not enabled, use alloc_gigantic_page() to get
the gigantic page.
2. The NUMA is enabled, but the vma is NULL.
There is no memory policy we can refer to.
So create a @nodes_allowed, initialize it with init_nodemask_of_mempolicy()
or init_nodemask_of_node(). Then use alloc_fresh_gigantic_page() to get
the gigantic page.
3. The NUMA is enabled, and the vma is valid.
We can follow the memory policy of the @vma.
Get @nodes_allowed by huge_nodemask(), and use alloc_fresh_gigantic_page()
to get the gigantic page.
Signed-off-by: Huang Shijie <shijie.huang@arm.com>
---
Since the huge_nodemask() is changed, we have to change this function a little.
---
mm/hugetlb.c | 63 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 63 insertions(+)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 6995087..c33bddc 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1502,6 +1502,69 @@ int dissolve_free_huge_pages(unsigned long start_pfn, unsigned long end_pfn)
/*
* There are 3 ways this can get called:
+ *
+ * 1. When the NUMA is not enabled, use alloc_gigantic_page() to get
+ * the gigantic page.
+ *
+ * 2. The NUMA is enabled, but the vma is NULL.
+ * Create a @nodes_allowed, and use alloc_fresh_gigantic_page() to get
+ * the gigantic page.
+ *
+ * 3. The NUMA is enabled, and the vma is valid.
+ * Use the @vma's memory policy.
+ * Get @nodes_allowed by huge_nodemask(), and use alloc_fresh_gigantic_page()
+ * to get the gigantic page.
+ */
+static struct page *__hugetlb_alloc_gigantic_page(struct hstate *h,
+ struct vm_area_struct *vma, unsigned long addr, int nid)
+{
+ NODEMASK_ALLOC(nodemask_t, nodes_allowed, GFP_KERNEL | __GFP_NORETRY);
+ struct page *page = NULL;
+
+ /* Not NUMA */
+ if (!IS_ENABLED(CONFIG_NUMA)) {
+ if (nid == NUMA_NO_NODE)
+ nid = numa_mem_id();
+
+ page = alloc_gigantic_page(nid, huge_page_order(h));
+ if (page)
+ prep_compound_gigantic_page(page, huge_page_order(h));
+
+ NODEMASK_FREE(nodes_allowed);
+ return page;
+ }
+
+ /* NUMA && !vma */
+ if (!vma) {
+ if (nid == NUMA_NO_NODE) {
+ if (!init_nodemask_of_mempolicy(nodes_allowed)) {
+ NODEMASK_FREE(nodes_allowed);
+ nodes_allowed = &node_states[N_MEMORY];
+ }
+ } else if (nodes_allowed) {
+ init_nodemask_of_node(nodes_allowed, nid);
+ } else {
+ nodes_allowed = &node_states[N_MEMORY];
+ }
+
+ page = alloc_fresh_gigantic_page(h, nodes_allowed, true);
+
+ if (nodes_allowed != &node_states[N_MEMORY])
+ NODEMASK_FREE(nodes_allowed);
+
+ return page;
+ }
+
+ /* NUMA && vma */
+ if (huge_nodemask(vma, addr, nodes_allowed))
+ page = alloc_fresh_gigantic_page(h, nodes_allowed, true);
+
+ NODEMASK_FREE(nodes_allowed);
+ return page;
+}
+
+/*
+ * There are 3 ways this can get called:
* 1. With vma+addr: we use the VMA's memory policy
* 2. With !vma, but nid=NUMA_NO_NODE: We try to allocate a huge
* page from any node, and let the buddy allocator itself figure
--
2.5.5
^ permalink raw reply related
* [upstream-release] [PATCH 1/2] drivers: usb: phy: Add qoriq usb 3.0 phy driver support
From: Scott Wood @ 2016-11-16 7:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <DB5PR0401MB1925FB1FE45C15B0671E46D1F5BF0@DB5PR0401MB1925.eurprd04.prod.outlook.com>
On 11/15/2016 06:39 AM, Sriram Dash wrote:
>> From: Scott Wood
>> On 11/13/2016 11:27 PM, Sriram Dash wrote:
>>> diff --git a/Documentation/devicetree/bindings/phy/phy-qoriq-usb3.txt
>>> b/Documentation/devicetree/bindings/phy/phy-qoriq-usb3.txt
>>> new file mode 100644
>>> index 0000000..d934c80
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/phy/phy-qoriq-usb3.txt
>>> @@ -0,0 +1,36 @@
>>> +Driver for Freescale USB 3.0 PHY
>>> +
>>> +Required properties:
>>> +
>>> +- compatible : fsl,qoriq-usb3-phy
>>
>
> Hi Scott,
>
>> This is a very vague compatible. Are there versioning registers within this register
>> block?
>>
>
> There are versioning registers for the phy (1.0 and 1.1). But the current erratum
> A008751 does not require the mentioning of the version numbers. Was planning
> to take care of the versioning when there is code diversity on the basis of the
> version number.
That is not how device tree bindings work. The describe the hardware,
not the driver.
That said, is the block version sufficient to tell whether a given chip
has this erratum? If so, you don't need a special property for the
erratum. If not, what is different about the PHY that is not described
by the versioning?
In any case, it would be nice to mention the version register and its
offset in the binding, just so that it becomes part of the definition of
this compatible string, and if we come out with some QorIQ chip with a
USB3 PHY that is totally different and doesn't have that version
register, it'll be clear that it needs a different compatible.
>>> +static inline u32 qoriq_usb3_phy_readl(void __iomem *addr, u32
>>> +offset) {
>>> + return __raw_readl(addr + offset);
>>> +}
>>> +
>>> +static inline void qoriq_usb3_phy_writel(void __iomem *addr, u32 offset,
>>> + u32 data)
>>> +{
>>> + __raw_writel(data, addr + offset);
>>> +}
>>
>> Why raw? Besides missing barriers, this will cause the accesses to be native-endian
>> which is not correct.
>>
>
> The only reason for __raw_writel is to make the code faster.
Does that really matter here?
> However, shall I use writel(with both barriers and byte swap) instead
Yes, if the registers are little-endian on all chips.
> and then make appropriate changes in the value 32'h27672B2A?
Not sure what you mean here.
> In my knowledge, there are more than 5 errata in pipeline,
Then please get all of these errata described in the device tree ASAP
(unless their presence can be reliably inferred from the block version,
as discussed above).
> However, in future, if any other erratum comes up, and it has to be applied
> at any point other than during init, then the variable has to be added in
> qoriq_usb3_phy struct and the property has to be read separately.
Or if the erratum is detected by some means other than a device tree
property...
-Scott
^ permalink raw reply
* [linux-sunxi] Re: [PATCH v3 1/2] drm/bridge: dumb-vga-dac: Support a VDD regulator supply
From: Archit Taneja @ 2016-11-16 8:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v67LR4KEb0tfGkT8+TqTauNyCMq1n6mRdXsa6TUJV0xncA@mail.gmail.com>
Hi,
On 11/15/2016 08:29 AM, Chen-Yu Tsai wrote:
> Hi,
>
> On Wed, Nov 2, 2016 at 9:33 AM, Chen-Yu Tsai <wens@csie.org> wrote:
>> On Mon, Oct 31, 2016 at 2:28 PM, Rob Herring <robh@kernel.org> wrote:
>>> On Sat, Oct 29, 2016 at 07:06:10PM +0800, Chen-Yu Tsai wrote:
>>>> Some dumb VGA DACs are active components which require external power.
>>>> Add support for specifying a regulator as its power supply.
>>>>
>>>> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
>>>> ---
>>>> .../bindings/display/bridge/dumb-vga-dac.txt | 2 ++
>>>
>>> For the binding,
>>>
>>> Acked-by: Rob Herring <robh@kernel.org>
>
> Any comments on this patch from the DRM people?
A comment below.
>
> ChenYu
>
>>>
>>> One code comment below...
>>>
>>>> drivers/gpu/drm/bridge/dumb-vga-dac.c | 35 ++++++++++++++++++++++
>>>> 2 files changed, 37 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt b/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
>>>> index 003bc246a270..164cbb15f04c 100644
>>>> --- a/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
>>>> +++ b/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
>>>> @@ -16,6 +16,8 @@ graph bindings specified in Documentation/devicetree/bindings/graph.txt.
>>>> - Video port 0 for RGB input
>>>> - Video port 1 for VGA output
>>>>
>>>> +Optional properties:
>>>> +- vdd-supply: Power supply for DAC
>>>>
>>>> Example
>>>> -------
>>>> diff --git a/drivers/gpu/drm/bridge/dumb-vga-dac.c b/drivers/gpu/drm/bridge/dumb-vga-dac.c
>>>> index afec232185a7..59781e031220 100644
>>>> --- a/drivers/gpu/drm/bridge/dumb-vga-dac.c
>>>> +++ b/drivers/gpu/drm/bridge/dumb-vga-dac.c
>>>> @@ -12,6 +12,7 @@
>>>>
>>>> #include <linux/module.h>
>>>> #include <linux/of_graph.h>
>>>> +#include <linux/regulator/consumer.h>
>>>>
>>>> #include <drm/drmP.h>
>>>> #include <drm/drm_atomic_helper.h>
>>>> @@ -23,6 +24,7 @@ struct dumb_vga {
>>>> struct drm_connector connector;
>>>>
>>>> struct i2c_adapter *ddc;
>>>> + struct regulator *vdd;
>>>> };
>>>>
>>>> static inline struct dumb_vga *
>>>> @@ -124,8 +126,33 @@ static int dumb_vga_attach(struct drm_bridge *bridge)
>>>> return 0;
>>>> }
>>>>
>>>> +static void dumb_vga_enable(struct drm_bridge *bridge)
>>>> +{
>>>> + struct dumb_vga *vga = drm_bridge_to_dumb_vga(bridge);
>>>> + int ret;
>>>> +
>>>> + if (!IS_ERR(vga->vdd)) {
>>>
>>> if (IS_ERR())
>>> return;
>>>
>>> ...will save some intentation.
>>
>> I thought about that, though if someone were to add more stuff to
>> this, such as an enable GPIO, they might have to rework it. A standalone
>> block of code would be easier to work with. I'm OK either way though.
>>
>> ChenYu
>>
>>>
>>>> + ret = regulator_enable(vga->vdd);
>>>> +
>>>> + if (ret) {
>>>> + DRM_ERROR("Failed to enable vdd regulator: %d\n", ret);
>>>> + return;
>>>> + }
>>>> + }
>>>> +}
>>>> +
>>>> +static void dumb_vga_disable(struct drm_bridge *bridge)
>>>> +{
>>>> + struct dumb_vga *vga = drm_bridge_to_dumb_vga(bridge);
>>>> +
>>>> + if (!IS_ERR(vga->vdd))
>>>> + regulator_disable(vga->vdd);
>>>> +}
>>>> +
>>>> static const struct drm_bridge_funcs dumb_vga_bridge_funcs = {
>>>> .attach = dumb_vga_attach,
>>>> + .enable = dumb_vga_enable,
>>>> + .disable = dumb_vga_disable,
>>>> };
>>>>
>>>> static struct i2c_adapter *dumb_vga_retrieve_ddc(struct device *dev)
>>>> @@ -169,6 +196,14 @@ static int dumb_vga_probe(struct platform_device *pdev)
>>>> return -ENOMEM;
>>>> platform_set_drvdata(pdev, vga);
>>>>
>>>> + vga->vdd = devm_regulator_get_optional(&pdev->dev, "vdd");
>>>> + if (IS_ERR(vga->vdd)) {
>>>> + ret = PTR_ERR(vga->vdd);
>>>> + if (ret == -EPROBE_DEFER)
>>>> + return -EPROBE_DEFER;
>>>> + dev_dbg(&pdev->dev, "No vdd regulator found: %d\n", ret);
A cleaner way would be to set vga->vdd to NULL here, and do:
int ret = 0;
if (vga->vdd)
ret = regulator_enable(vga->vdd);
if (ret) {
...
return;
}
/* if a gpio is added later */
if (vga->gpio)
ret = gpiod_set_value_cansleep(vga->gpio, 1);
if (ret) {
...
return;
}
...
We don't really care what error code is contained in vga->vdd once we have
identified whether we got a regulator or not.
The same thing can be done for ddc too, but that can done left for later.
If you're okay with the suggestion, can you re-spin a patch?
Thanks,
Archit
>>>> + }
>>>> +
>>>> vga->ddc = dumb_vga_retrieve_ddc(&pdev->dev);
>>>> if (IS_ERR(vga->ddc)) {
>>>> if (PTR_ERR(vga->ddc) == -ENODEV) {
>>>> --
>>>> 2.9.3
>>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe at googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH] ARM: zynq: Fix pmu register description coding style
From: Michal Simek @ 2016-11-16 8:32 UTC (permalink / raw)
To: linux-arm-kernel
Drop the space before/after '<' and '>'; and
separate the entries to be a bit more readable.
Reported-by: Julia Cartwright <julia@ni.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
---
arch/arm/boot/dts/zynq-7000.dtsi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/zynq-7000.dtsi b/arch/arm/boot/dts/zynq-7000.dtsi
index 402b5bbe3b5b..f3ac9bfe580e 100644
--- a/arch/arm/boot/dts/zynq-7000.dtsi
+++ b/arch/arm/boot/dts/zynq-7000.dtsi
@@ -46,7 +46,8 @@
compatible = "arm,cortex-a9-pmu";
interrupts = <0 5 4>, <0 6 4>;
interrupt-parent = <&intc>;
- reg = < 0xf8891000 0x1000 0xf8893000 0x1000 >;
+ reg = <0xf8891000 0x1000>,
+ <0xf8893000 0x1000>;
};
regulator_vccpint: fixedregulator {
--
1.9.1
^ permalink raw reply related
* [2/2] dmaengine: at_xdmac: fix spurious flag status for mem2mem transfers
From: Nicolas Ferre @ 2016-11-16 8:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7fbfd098-31d8-d184-37a9-8865fdb7fb8d@denx.de>
Le 28/10/2016 ? 23:57, Marek Vasut a ?crit :
> Hi,
>
> this patch [1] should also CC stable, since it fixes MMC operation in at
> least linux 4.4 .
>
> Thanks!
>
> [1] https://patchwork.kernel.org/patch/7681201/
I did that (without putting you in copy: sorry).
https://www.spinics.net/lists/stable/msg151272.html
Thanks a lot for the heads-up Marek!
Best regards,
--
Nicolas Ferre
^ permalink raw reply
* [PATCH 1/3] arm: hisi: add ARCH_MULTI_V5 support
From: wenpan @ 2016-11-16 8:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5893354.6MrIxqzRoI@wuerfel>
Hi Martyo<
Does this confict with your patcho<\x1f If noto<
I hope this could be merged first. Besides could you tell me the link to your related patch?
Thanks,
Pan
On 2016/10/17 21:48, Arnd Bergmann wrote:
> On Monday, October 17, 2016 8:07:03 PM CEST Pan Wen wrote:
>> Add support for some HiSilicon SoCs which depend on ARCH_MULTI_V5.
>>
>> Signed-off-by: Pan Wen <wenpan@hisilicon.com>
>>
>
> Looks ok. I've added Marty Plummer to Cc, he was recently proposing
> patches for Hi3520, which I think is closely related to this one.
> Please try to work together so the patches don't conflict. It should
> be fairly straightforward since you are basically doing the same
> change here.
>
> Arnd
>
> .
>
^ permalink raw reply
* [PATCH v2 1/3] ARM: davinci: PM: rework init, support DT platforms
From: Sekhar Nori @ 2016-11-16 9:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161115195421.19983-2-khilman@baylibre.com>
On Wednesday 16 November 2016 01:24 AM, Kevin Hilman wrote:
> Remove fake platform device used for PM init. Move pdata values which
> are common across all current platforms into pm.c.
>
> Also, since PM is only used on da8xx, remove davinci_pm_init() from
> common init code, and only use in da850/omapl138 board files that are
> currently creating the fake platform_device.
>
> Suggested-by: Sekhar Nori <nsekhar@ti.com>
> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
> diff --git a/arch/arm/mach-davinci/pm.c b/arch/arm/mach-davinci/pm.c
> index 8929569b1f8a..3f1fb191c03f 100644
> --- a/arch/arm/mach-davinci/pm.c
> +++ b/arch/arm/mach-davinci/pm.c
> @@ -21,15 +21,23 @@
>
> #include <mach/common.h>
> #include <mach/da8xx.h>
> -#include "sram.h"
> +#include <mach/mux.h>
> #include <mach/pm.h>
>
> #include "clock.h"
> +#include "psc.h"
> +#include "sram.h"
>
> +#define DA850_PLL1_BASE 0x01e1a000
> #define DEEPSLEEP_SLEEPCOUNT_MASK 0xFFFF
> +#define DEEPSLEEP_SLEEPCOUNT 128
>
> static void (*davinci_sram_suspend) (struct davinci_pm_config *);
> -static struct davinci_pm_config *pdata;
> +static struct davinci_pm_config pm_config = {
> + .sleepcount = DEEPSLEEP_SLEEPCOUNT,
> + .ddrpsc_num = DA8XX_LPSC1_EMIF3C,
> +};
I added an empty line here while applying. This was pointed to by
checkpatch --strict
> +static struct davinci_pm_config *pdata = &pm_config;
And also adjusted the subject line since there is no DT support being
added in this patch anymore. New subject line:
ARM: davinci: PM: rework init, remove platform device
Applied to v4.10/cleanup
Thanks,
Sekhar
^ permalink raw reply
* [PATCH v2 2/3] ARM: davinci: PM: cleanup: remove references to pdata
From: Sekhar Nori @ 2016-11-16 9:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161115195421.19983-3-khilman@baylibre.com>
On Wednesday 16 November 2016 01:24 AM, Kevin Hilman wrote:
> Since the PM core code is no longer using a fake platform_device or
> platform_data, remove references to 'pdata'.
>
> No functional changes.
>
> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
Applied to v4.10/cleanup
Thanks,
Sekhar
^ permalink raw reply
* [PATCH v2 3/3] ARM: davinci: PM: support da8xx DT platforms
From: Sekhar Nori @ 2016-11-16 9:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161115195421.19983-4-khilman@baylibre.com>
On Wednesday 16 November 2016 01:24 AM, Kevin Hilman wrote:
> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
Added a one line description which is essentially a copy of subject line.
Applied to v4.10/soc
Thanks,
Sekhar
^ permalink raw reply
* [PATCH v2] ARM: dts: da850: add the mstpri and ddrctl nodes
From: Sekhar Nori @ 2016-11-16 9:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479207611-18028-1-git-send-email-bgolaszewski@baylibre.com>
On Tuesday 15 November 2016 04:30 PM, Bartosz Golaszewski wrote:
> Add the nodes for the MSTPRI configuration and DDR2/mDDR memory
> controller drivers to da850.dtsi.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Applied to v4.10/dt
Thanks,
Sekhar
^ permalink raw reply
* [PATCH] ARM: davinci_all_defconfig: add missing options for systemd
From: Sekhar Nori @ 2016-11-16 9:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7hshqt6fyo.fsf@baylibre.com>
On Tuesday 15 November 2016 12:34 AM, Kevin Hilman wrote:
> Sekhar Nori <nsekhar@ti.com> writes:
>
>> Some kernel configuration options required for systemd
>> support are missing in davinci_all_defconfig. Add them.
>>
>> This is based on recommendations in:
>>
>> http://cgit.freedesktop.org/systemd/systemd/tree/README
>>
>> Options which kernel enables by default (and will thus be removed
>> upon next savedefconfig update) are not included.
>>
>> Tested on OMAP-L138 LCDK board with fully up to date armv5
>> archlinux filesystem.
>>
>> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
>
> Acked-by: Kevin Hilman <khilman@baylibre.com>
Applied to v4.10/defconfig
Thanks,
Sekhar
^ permalink raw reply
* [PATCH] ARM64: dma-mapping: preallocate DMA-debug hash tables in core_initcall
From: Marek Szyprowski @ 2016-11-16 9:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CGME20161116092025eucas1p2ebaf3ead7de79130ca2656d532284e5b@eucas1p2.samsung.com>
fs_initcall is definitely too late to initialize DMA-debug hash tables,
because some drivers might get probed and use DMA mapping framework
already in core_initcall. Late initialization of DMA-debug results in
false warning about accessing memory, that was not allocated. This issue
has been observed on ARM 32bit, but the same driver can be used also on
ARM64.
This patch moves initialization of DMA-debug to core_initcall. This is
safe from the initialization perspective. dma_debug_do_init() internally
calls debugfs functions and debugfs also gets initialised at
core_initcall(), and that is earlier than arch code in the link order,
so it will get initialized just before the DMA-debug.
Reported-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
---
For more details on this issue, see the patch for ARM 32bit arch:
https://www.spinics.net/lists/arm-kernel/msg542721.html
https://www.spinics.net/lists/arm-kernel/msg542782.html
---
arch/arm64/mm/dma-mapping.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index 3f74d0d..8653426 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -538,7 +538,7 @@ static int __init dma_debug_do_init(void)
dma_debug_init(PREALLOC_DMA_DEBUG_ENTRIES);
return 0;
}
-fs_initcall(dma_debug_do_init);
+core_initcall(dma_debug_do_init);
#ifdef CONFIG_IOMMU_DMA
--
1.9.1
^ permalink raw reply related
* [PATCH 1/3] arm: hisi: add ARCH_MULTI_V5 support
From: Wei Xu @ 2016-11-16 9:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e78a288b-8bab-9441-2edb-6ec08e5103d7@hisilicon.com>
Hi Pan,
On 2016/11/16 8:56, wenpan wrote:
> Hi Marty?
> Does this confict with your patch? If not?I hope this could be merged first. Besides could you tell me the link to your related patch?
This is the link: https://patchwork.kernel.org/patch/9334743/
BR,
Wei
>
> Thanks,
> Pan
>
> On 2016/10/17 21:48, Arnd Bergmann wrote:
>> On Monday, October 17, 2016 8:07:03 PM CEST Pan Wen wrote:
>>> Add support for some HiSilicon SoCs which depend on ARCH_MULTI_V5.
>>>
>>> Signed-off-by: Pan Wen <wenpan@hisilicon.com>
>>>
>>
>> Looks ok. I've added Marty Plummer to Cc, he was recently proposing
>> patches for Hi3520, which I think is closely related to this one.
>> Please try to work together so the patches don't conflict. It should
>> be fairly straightforward since you are basically doing the same
>> change here.
>>
>> Arnd
>>
>> .
>>
>
>
> .
>
^ permalink raw reply
* [PATCH v2 2/3] soc: rockchip: add driver handling grf setup
From: Shawn Lin @ 2016-11-16 9:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161115223900.30728-3-heiko@sntech.de>
? 2016/11/16 6:38, Heiko Stuebner ??:
> The General Register Files are an area of registers containing a lot
> of single-bit settings for numerous components as well full components
> like usbphy control. Therefore all used components are accessed
> via the syscon provided by the grf nodes or from the sub-devices
> created through the simple-mfd created from the grf node.
>
> Some settings are not used by anything but will need to be set up
> according to expectations on the kernel side.
>
> Best example is the force_jtag setting, which defaults to on and
> results in the soc switching the pin-outputs between jtag and sdmmc
> automatically depending on the card-detect status. This conflicts
> heavily with how the dw_mmc driver expects to do its work and also
> with the clock-controller, which has most likely deactivated the
> jtag clock due to it being unused.
I hate force_jtag personally... :)
>
> So far the handling of this setting was living in the mach-rockchip
> code for the arm32-based rk3288 but that of course doesn't work
> for arm64 socs and would also look ugly for further arm32 socs.
yes, I did this inside the loader.... when running arm64
>
> Also always disabling this setting is quite specific to linux and
> its subsystems, other operating systems might prefer other settings,
> so that the bootloader cannot really set a sane default for all.
>
> So introduce a top-level driver for the grf that handles these
> settings that need to be a certain way but nobody cares about.
>
> Other needed settings might surface in the future and can then
> be added here, but only as a last option. Ideally general GRF
> settings should be handled in the driver needing them.
>
> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
> ---
> drivers/soc/rockchip/Kconfig | 10 ++++
> drivers/soc/rockchip/Makefile | 1 +
> drivers/soc/rockchip/grf.c | 134 ++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 145 insertions(+)
> create mode 100644 drivers/soc/rockchip/grf.c
>
> diff --git a/drivers/soc/rockchip/Kconfig b/drivers/soc/rockchip/Kconfig
> index 7140ff8..20da55d 100644
> --- a/drivers/soc/rockchip/Kconfig
> +++ b/drivers/soc/rockchip/Kconfig
> @@ -3,6 +3,16 @@ if ARCH_ROCKCHIP || COMPILE_TEST
> #
> # Rockchip Soc drivers
> #
> +
> +config ROCKCHIP_GRF
> + bool
> + default y
> + help
> + The General Register Files are a central component providing
> + special additional settings registers for a lot of soc-components.
> + In a lot of cases there also need to be default settings initialized
> + to make some of them conform to expectations of the kernel.
> +
> config ROCKCHIP_PM_DOMAINS
> bool "Rockchip generic power domain"
> depends on PM
> diff --git a/drivers/soc/rockchip/Makefile b/drivers/soc/rockchip/Makefile
> index 3d73d06..c851fa0 100644
> --- a/drivers/soc/rockchip/Makefile
> +++ b/drivers/soc/rockchip/Makefile
> @@ -1,4 +1,5 @@
> #
> # Rockchip Soc drivers
> #
> +obj-$(CONFIG_ROCKCHIP_GRF) += grf.o
> obj-$(CONFIG_ROCKCHIP_PM_DOMAINS) += pm_domains.o
> diff --git a/drivers/soc/rockchip/grf.c b/drivers/soc/rockchip/grf.c
> new file mode 100644
> index 0000000..0c85476a
> --- /dev/null
> +++ b/drivers/soc/rockchip/grf.c
> @@ -0,0 +1,134 @@
> +/*
> + * Rockchip Generic Register Files setup
> + *
> + * Copyright (c) 2016 Heiko Stuebner <heiko@sntech.de>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include <linux/err.h>
> +#include <linux/regmap.h>
> +#include <linux/mfd/syscon.h>
> +#include <linux/of_device.h>
> +#include <linux/platform_device.h>
> +#include <linux/regmap.h>
The order :)
> +
> +#define HIWORD_UPDATE(val, mask, shift) \
> + ((val) << (shift) | (mask) << ((shift) + 16))
> +
> +struct rockchip_grf_value {
> + const char *desc;
> + u32 reg;
> + u32 val;
> +};
> +
> +struct rockchip_grf_info {
> + const struct rockchip_grf_value *values;
> + int num_values;
> +};
> +
> +#define RK3036_GRF_SOC_CON0 0x140
> +
> +static const struct rockchip_grf_value rk3036_defaults[] __initconst = {
> + /*
> + * Disable auto jtag/sdmmc switching that causes issues with the
> + * clock-framework and the mmc controllers making them unreliable.
> + */
> + { "jtag switching", RK3036_GRF_SOC_CON0, HIWORD_UPDATE(0, 1, 11) },
> +};
> +
> +static const struct rockchip_grf_info rk3036_grf __initconst = {
> + .values = rk3036_defaults,
> + .num_values = ARRAY_SIZE(rk3036_defaults),
> +};
> +
> +#define RK3288_GRF_SOC_CON0 0x244
> +
> +static const struct rockchip_grf_value rk3288_defaults[] __initconst = {
> + { "jtag switching", RK3288_GRF_SOC_CON0, HIWORD_UPDATE(0, 1, 12) },
> +};
> +
> +static const struct rockchip_grf_info rk3288_grf __initconst = {
> + .values = rk3288_defaults,
> + .num_values = ARRAY_SIZE(rk3288_defaults),
> +};
> +
> +#define RK3368_GRF_SOC_CON15 0x43c
> +
> +static const struct rockchip_grf_value rk3368_defaults[] __initconst = {
> + { "jtag switching", RK3368_GRF_SOC_CON15, HIWORD_UPDATE(0, 1, 13) },
> +};
> +
> +static const struct rockchip_grf_info rk3368_grf __initconst = {
> + .values = rk3368_defaults,
> + .num_values = ARRAY_SIZE(rk3368_defaults),
> +};
> +
> +#define RK3399_GRF_SOC_CON7 0xe21c
> +
> +static const struct rockchip_grf_value rk3399_defaults[] __initconst = {
> + { "jtag switching", RK3399_GRF_SOC_CON7, HIWORD_UPDATE(0, 1, 12) },
> +};
> +
> +static const struct rockchip_grf_info rk3399_grf __initconst = {
> + .values = rk3399_defaults,
> + .num_values = ARRAY_SIZE(rk3399_defaults),
> +};
> +
> +static const struct of_device_id rockchip_grf_dt_match[] __initconst = {
> + {
> + .compatible = "rockchip,rk3036-grf",
> + .data = (void *)&rk3036_grf,
> + }, {
> + .compatible = "rockchip,rk3288-grf",
> + .data = (void *)&rk3288_grf,
> + }, {
> + .compatible = "rockchip,rk3368-grf",
> + .data = (void *)&rk3368_grf,
> + }, {
> + .compatible = "rockchip,rk3399-grf",
> + .data = (void *)&rk3399_grf,
> + },
> + { /* sentinel */ },
> +};
> +
> +static int __init rockchip_grf_init(void)
> +{
> + const struct rockchip_grf_info *grf_info;
> + const struct of_device_id *match;
> + struct device_node *np;
> + struct regmap *grf;
> + int ret, i;
> +
> + np = of_find_matching_node_and_match(NULL, rockchip_grf_dt_match, &match);
> + if (!np)
> + return -ENODEV;
> + if (!match || !match->data) {
> + pr_err("%s: missing grf data\n", __func__);
> + return -EINVAL;
> + }
> +
> + grf_info = match->data;
> +
> + grf = syscon_node_to_regmap(np);
> + if (IS_ERR(grf)) {
> + pr_err("%s: could not get grf syscon\n", __func__);
> + return PTR_ERR(grf);
> + }
> +
> + for (i = 0; i < grf_info->num_values; i++) {
> + const struct rockchip_grf_value *val = &grf_info->values[i];
> +
> + pr_debug("%s: adjusting %s in %#6x to %#10x\n", __func__,
> + val->desc, val->reg, val->val);
> + ret = regmap_write(grf, val->reg, val->val);
> + if (ret < 0)
> + pr_err("%s: write to %#6x failed with %d\n",
> + __func__, val->reg, ret);
So, when failing to do one of the settings, should we still let it goes?
Sometimes the log of postcore_initcall is easy to be neglected when
people finally find problems later but the very earlier log was missing
due to whatever reason like buffer limitation, etc.
> + }
> +
> + return 0;
> +}
> +postcore_initcall(rockchip_grf_init);
>
--
Best Regards
Shawn Lin
^ permalink raw reply
* [PATCH] drm/sun4i: Only count TCON endpoints as valid outputs
From: Chen-Yu Tsai @ 2016-11-16 9:37 UTC (permalink / raw)
To: linux-arm-kernel
The sun4i DRM driver counts the number of endpoints it found and
registers the whole DRM pipeline if any endpoints are found.
However, if the TCON and its child endpoints (LCD panels, TV encoder,
HDMI encoder, MIPI DSI encoder, etc.) aren't found, that means we
don't have any usable CRTCs, and the display pipeline is incomplete
and useless. The whole DRM display pipeline should only be registered
and enabled if there are proper outputs available.
The debug message "Queued %d outputs on pipeline %d\n" is also telling.
This patch makes the driver only count enabled TCON endpoints. If
none are found, the DRM pipeline is not used. This avoids screwing
up the simple framebuffer provided by the bootloader in cases where
we aren't able to support the display with the DRM subsystem, due
to lack of panel or bridge drivers, or just lack of progress.
Fixes: 9026e0d122ac ("drm: Add Allwinner A10 Display Engine support")
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
Hi Maxime,
This avoids DRM screwing up simplefb on my SinA31s, which does not
have the display pipeline enabled in its dts file. But the display
engine and backend are already enabled in the dtsi.
I think this is a better and proper (for the driver) fix. The
alternative would be to disable the display-engine node in the dts
by default. Last time I asked you wanted to have them enabled by
default?
It may also be possible to push the check further down, and check
against panel and encoder endpoints, but I think that complicates
things. The TCON is a necessary part of the output.
ChenYu
---
drivers/gpu/drm/sun4i/sun4i_drv.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c b/drivers/gpu/drm/sun4i/sun4i_drv.c
index c3b21865443e..3603f34901b6 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
@@ -243,9 +243,12 @@ static int sun4i_drv_add_endpoints(struct device *dev,
DRM_DEBUG_DRIVER("Adding component %s\n",
of_node_full_name(node));
component_match_add(dev, match, compare_of, node);
- count++;
}
+ /* Only count the tcon as an output */
+ if (sun4i_drv_node_is_tcon(node))
+ count++;
+
/* Inputs are listed first, then outputs */
port = of_graph_get_port_by_id(node, 1);
if (!port) {
--
2.10.2
^ permalink raw reply related
* [PATCH] drm/sun4i: tcon: Initialize regmap after enabling bus clocks
From: Chen-Yu Tsai @ 2016-11-16 9:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161116093732.12828-1-wens@csie.org>
If we attempt to read/write the TCON registers before the bus clock
is enabled, those accesses get ignored.
In practice this almost never occurs because U-boot had already enabled
the bus clock as part of its firmware provided framebuffer (simplefb).
Fixes: 9026e0d122ac ("drm: Add Allwinner A10 Display Engine support")
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
I was looking around the DRM driver and noticed this sequence was off.
---
drivers/gpu/drm/sun4i/sun4i_tcon.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index c6afb2448655..8c2db65ea229 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -506,16 +506,16 @@ static int sun4i_tcon_bind(struct device *dev, struct device *master,
return ret;
}
- ret = sun4i_tcon_init_regmap(dev, tcon);
+ ret = sun4i_tcon_init_clocks(dev, tcon);
if (ret) {
- dev_err(dev, "Couldn't init our TCON regmap\n");
+ dev_err(dev, "Couldn't init our TCON clocks\n");
goto err_assert_reset;
}
- ret = sun4i_tcon_init_clocks(dev, tcon);
+ ret = sun4i_tcon_init_regmap(dev, tcon);
if (ret) {
- dev_err(dev, "Couldn't init our TCON clocks\n");
- goto err_assert_reset;
+ dev_err(dev, "Couldn't init our TCON regmap\n");
+ goto err_free_clocks;
}
ret = sun4i_tcon_init_irq(dev, tcon);
--
2.10.2
^ permalink raw reply related
* [RFCv2 PATCH 1/5] video: add HDMI state notifier support
From: Hans Verkuil @ 2016-11-16 9:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <00ad0ddf-3e52-62e6-f863-cae6eefd08c9@xs4all.nl>
On 11/15/16 21:41, Hans Verkuil wrote:
> Hi Philipp,
>
> On 11/15/2016 07:24 PM, Philipp Zabel wrote:
>> Hi Hans,
>>
>> Am Montag, den 14.11.2016, 16:22 +0100 schrieb Hans Verkuil:
>>> From: Hans Verkuil <hans.verkuil@cisco.com>
>>>
>>> Add support for HDMI hotplug and EDID notifiers, which is used to convey
>>> information from HDMI drivers to their CEC and audio counterparts.
>>>
>>> Based on an earlier version from Russell King:
>>>
>>> https://patchwork.kernel.org/patch/9277043/
>>>
>>> The hdmi_notifier is a reference counted object containing the HDMI state
>>> of an HDMI device.
>>>
>>> When a new notifier is registered the current state will be reported to
>>> that notifier at registration time.
>>>
>>> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
>>> ---
>>> drivers/video/Kconfig | 3 +
>>> drivers/video/Makefile | 1 +
>>> drivers/video/hdmi-notifier.c | 136 ++++++++++++++++++++++++++++++++++++++++++
>>> include/linux/hdmi-notifier.h | 43 +++++++++++++
>>> 4 files changed, 183 insertions(+)
>>> create mode 100644 drivers/video/hdmi-notifier.c
>>> create mode 100644 include/linux/hdmi-notifier.h
>>>
>>> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
>>> index 3c20af9..1ee7b9f 100644
>>> --- a/drivers/video/Kconfig
>>> +++ b/drivers/video/Kconfig
>>> @@ -36,6 +36,9 @@ config VIDEOMODE_HELPERS
>>> config HDMI
>>> bool
>>>
>>> +config HDMI_NOTIFIERS
>>> + bool
>>> +
>>> if VT
>>> source "drivers/video/console/Kconfig"
>>> endif
>>> diff --git a/drivers/video/Makefile b/drivers/video/Makefile
>>> index 9ad3c17..65f5649 100644
>>> --- a/drivers/video/Makefile
>>> +++ b/drivers/video/Makefile
>>> @@ -1,5 +1,6 @@
>>> obj-$(CONFIG_VGASTATE) += vgastate.o
>>> obj-$(CONFIG_HDMI) += hdmi.o
>>> +obj-$(CONFIG_HDMI_NOTIFIERS) += hdmi-notifier.o
>>>
>>> obj-$(CONFIG_VT) += console/
>>> obj-$(CONFIG_LOGO) += logo/
>>> diff --git a/drivers/video/hdmi-notifier.c b/drivers/video/hdmi-notifier.c
>>> new file mode 100644
>>> index 0000000..c2a4f1b
>>> --- /dev/null
>>> +++ b/drivers/video/hdmi-notifier.c
>>> @@ -0,0 +1,136 @@
>>> +#include <linux/export.h>
>>> +#include <linux/hdmi-notifier.h>
>>> +#include <linux/string.h>
>>> +#include <linux/slab.h>
>>> +#include <linux/list.h>
>>> +
>>> +struct hdmi_notifiers {
>>> + struct list_head head;
>>> + struct device *dev;
>>> + struct hdmi_notifier *n;
>>> +};
>>
>> This struct is not used, can be removed.
>
> Indeed.
>
>>
>>> +static LIST_HEAD(hdmi_notifiers);
>>> +static DEFINE_MUTEX(hdmi_notifiers_lock);
>>> +
>>> +struct hdmi_notifier *hdmi_notifier_get(struct device *dev)
>>> +{
>>> + struct hdmi_notifier *n;
>>> +
>>> + mutex_lock(&hdmi_notifiers_lock);
>>> + list_for_each_entry(n, &hdmi_notifiers, head) {
>>> + if (n->dev == dev) {
>>> + mutex_unlock(&hdmi_notifiers_lock);
>>> + kref_get(&n->kref);
>>> + return n;
>>> + }
>>> + }
>>> + n = kzalloc(sizeof(*n), GFP_KERNEL);
>>> + if (!n)
>>> + goto unlock;
>>> + mutex_init(&n->lock);
>>> + BLOCKING_INIT_NOTIFIER_HEAD(&n->notifiers);
>>> + kref_init(&n->kref);
>>
>> + n->dev = dev;
>>
>> Currently n->dev is never set, so every caller of this function gets its
>> own hdmi_notifier.
>
> Oops! Well, I did say it was compile-tested only :-)
>
>>
>>> + list_add_tail(&n->head, &hdmi_notifiers);
>>> +unlock:
>>> + mutex_unlock(&hdmi_notifiers_lock);
>>> + return n;
>>> +}
>>> +EXPORT_SYMBOL_GPL(hdmi_notifier_get);
>>> +
>>> +static void hdmi_notifier_release(struct kref *kref)
>>> +{
>>> + struct hdmi_notifier *n =
>>> + container_of(kref, struct hdmi_notifier, kref);
>>> +
I also forgot to remove this notifier from the global list.
I've updated my git branch to fix this.
Hans
^ permalink raw reply
* [PATCH v2] arm64: SMMU-v2: Workaround for Cavium ThunderX erratum 28168
From: Marc Zyngier @ 2016-11-16 9:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <582B52D6.6060907@caviumnetworks.com>
On 15/11/16 18:24, David Daney wrote:
> On 11/15/2016 01:26 AM, Marc Zyngier wrote:
>> On 15/11/16 07:00, Geetha sowjanya wrote:
>>> From: Tirumalesh Chalamarla <Tirumalesh.Chalamarla@cavium.com>
>>>
>>> This patch implements Cavium ThunderX erratum 28168.
>>>
>>> PCI requires stores complete in order. Due to erratum #28168
>>> PCI-inbound MSI-X store to the interrupt controller are delivered
>>> to the interrupt controller before older PCI-inbound memory stores
>>> are committed.
>>> Doing a sync on SMMU will make sure all prior data transfers are
>>> completed before invoking ISR.
>>>
>>> Signed-off-by: Tirumalesh Chalamarla <Tirumalesh.Chalamarla@cavium.com>
>>> Signed-off-by: Geetha sowjanya <gakula@caviumnetworks.com>
> [...]
>>> --- a/drivers/irqchip/irq-gic-v3.c
>>> +++ b/drivers/irqchip/irq-gic-v3.c
>>> @@ -28,6 +28,8 @@
>>> #include <linux/of_irq.h>
>>> #include <linux/percpu.h>
>>> #include <linux/slab.h>
>>> +#include <linux/msi.h>
>>> +#include <linux/pci.h>
>>>
>>> #include <linux/irqchip.h>
>>> #include <linux/irqchip/arm-gic-common.h>
>>> @@ -736,6 +738,20 @@ static inline void gic_cpu_pm_init(void) { }
>>>
>>> #define GIC_ID_NR (1U << gic_data.rdists.id_bits)
>>>
>>> +/*
>>> + * Due to #28168 erratum in ThunderX,
>>> + * we need to make sure DMA data transfer is done before MSIX.
>>> + */
>>> +static void cavium_irq_perflow_handler(struct irq_data *data)
>>> +{
>>> + struct pci_dev *pdev;
>>> +
>>> + pdev = msi_desc_to_pci_dev(irq_data_get_msi_desc(data));
>>
>> What happens if this is not a PCI device?
>>
>>> + if ((pdev->vendor != 0x177d) &&
>>> + ((pdev->device & 0xA000) != 0xA000))
>>> + cavium_arm_smmu_tlb_sync(&pdev->dev);
>>
>> I've asked that before. What makes Cavium devices so special that they
>> are not sensitive to this bug?
>
>
> This is a heuristic for devices connected to external PCIe buses as
> opposed to on-SoC devices (which don't suffer from the erratum).
>
> In any event what would happen if we got rid of this check and ...
>
>
>>
>>> +}
>>> +
>>> static int gic_irq_domain_map(struct irq_domain *d, unsigned int irq,
>>> irq_hw_number_t hw)
>>> {
>>> @@ -773,6 +789,9 @@ static int gic_irq_domain_map(struct irq_domain *d, unsigned int irq,
>>> return -EPERM;
>>> irq_domain_set_info(d, irq, hw, chip, d->host_data,
>>> handle_fasteoi_irq, NULL, NULL);
>>> + if (cpus_have_cap(ARM64_WORKAROUND_CAVIUM_28168))
>>> + __irq_set_preflow_handler(irq,
>>> + cavium_irq_perflow_handler);
>>
>
> ... move the registration of the preflow_handler into a
> msi_domain_ops.msi_finish() handler in irq-git-v3-its-pic-msi.c?
That's the kind of thing I was angling for. You'll have to store the
device pointer into the scratchpad (we still have plenty of space there)
so that msi_finish() can have a peek.
> There we will know that it is a pci device, and can walk up the bus
> hierarchy to see if there is a Cavium PCIe root port present. If such a
> port is found, we know we are on an external Cavium PCIe bus, and can
> register the preflow_handler without having to check the device identifiers.
Something like that (though I'm unclear why other devices wouldn't see a
root port, but that's probably me lacking some PCIe foo).
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v7 04/16] drivers: iommu: make of_iommu_set/get_ops() DT agnostic
From: Lorenzo Pieralisi @ 2016-11-16 9:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <313844ca-d948-1297-84b2-669f3a7d57d2@arm.com>
Hi Joerg,
On Mon, Nov 14, 2016 at 06:25:16PM +0000, Robin Murphy wrote:
> On 14/11/16 15:52, Joerg Roedel wrote:
> > On Mon, Nov 14, 2016 at 12:00:47PM +0000, Robin Murphy wrote:
> >> If we've already made the decision to move away from bus ops, I don't
> >> see that it makes sense to deliberately introduce new dependencies on
> >> them. Besides, as it stands, this patch literally implements "tell the
> >> iommu-core which hardware-iommus exist in the system and a seperate
> >> iommu_ops ptr for each of them" straight off.
> >
> > Not sure which code you are looking at, but as I see it we have only
> > per-device iommu-ops now (with this patch). That is different from
> > having core-visible hardware-iommu instances where devices could link
> > to.
>
> The per-device IOMMU ops are already there since 57f98d2f61e1. This
> patch generalises the other end, moving the "registering an IOMMU
> instance" (i.e. iommu_fwentry) bit into the IOMMU core, from being
> OF-specific. I'd be perfectly happy if we rename iommu_fwentry to
> iommu_instance, fwnode_iommu_set_ops() to iommu_register_instance(), and
> such if that makes the design intent clearer.
I can easily make the changes Robin suggests above, I need to know
what to do with this patch it is the last blocking point for this
series and time is running out I can revert to using dev->bus to
retrieve iommu_ops (even though I do not think it makes sense given
what Robin outlines below) but I need to know please, we can't gate
an entire series for this patch that is just syntactic sugar.
Thanks !
Lorenzo
> If you'd also prefer to replace iommu_fwspec::ops with an opaque
> iommu_fwspec::iommu_instance pointer so that things are a bit more
> centralised (and users are forced to go through the API rather then call
> ops directly), I'd have no major objection either. My main point is that
> we've been deliberately putting the relevant building blocks in place -
> the of_iommu_{get,set}_ops stuff was designed from the start to
> accommodate per-instance ops, via the ops pointer *being* the instance
> token; the iommu_fwspec stuff is deliberately intended to provide
> per-device ops on top of that. The raw functionality is either there in
> iommu.c already, or moving there in patches already written, so if it
> doesn't look right all we need to focus on is making it look right.
>
> > Also the rest of iommu-core code still makes use of the per-bus ops. The
> > per-device ops are only used for the of_xlate fn-ptr.
>
> Hence my aforementioned patches intended for 4.10, directly following on
> from introducing iommu_fwspec in 4.9:
>
> http://www.mail-archive.com/iommu at lists.linux-foundation.org/msg14576.html
>
> ...the purpose being to provide a smooth transition from per-bus ops to
> per-device, per-instance ops. Apply those and we're 90% of the way there
> for OF-based IOMMU drivers (not that any of those actually need
> per-instance ops, admittedly; I did prototype it for the ARM SMMU ages
> ago, but it didn't seem worth the bother). Lorenzo's series broadens the
> scope to ACPI-based systems and moves the generically-useful parts into
> the core where we can easily build on them further if necessary. The
> major remaining work is to convert external callers of the current
> bus-dependent functions like iommu_domain_alloc(), iommu_present(), etc.
> to device-based alternatives.
>
> Robin.
^ permalink raw reply
* [PATCH net 1/3] net: phy: realtek: add eee advertisement disable options
From: Jerome Brunet @ 2016-11-16 9:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <476b72f3-5efe-3551-6c24-0e378d655a0f@gmail.com>
On Tue, 2016-11-15 at 09:03 -0800, Florian Fainelli wrote:
> On 11/15/2016 08:30 AM, Andrew Lunn wrote:
> >
> > On Tue, Nov 15, 2016 at 03:29:12PM +0100, Jerome Brunet wrote:
> > >
> > > On some platforms, energy efficient ethernet with rtl8211 devices
> > > is
> > > causing issue, like throughput drop or broken link.
> > >
> > > This was reported on the OdroidC2 (DWMAC + RTL8211F). While the
> > > issue root
> > > cause is not fully understood yet, disabling EEE advertisement
> > > prevent auto
> > > negotiation from enabling EEE.
> > >
> > > This patch provides options to disable 1000T and 100TX EEE
> > > advertisement
> > > individually for the realtek phys supporting this feature.
> >
> > Looking at the code, i don't see anything specific to RealTek
> > here. This all seems generic. So should it be in phy.c and made a
> > generic OF property which can be applied to any PHY which supports
> > EEE.
>
> Agreed.
Good point, Thanks for pointing this out.
> Just to be sure, Jerome, you did verify that with EEE no longer
> advertised, ethtool --set-eee fails, right? The point is that you may
> be
> able to disable EEE on boot, but if there is a way to re-enable it
> later
> on, we would want to disable that too.
I was focused on getting the issue out of way I did not think that
someone could try something like this :)
I just tried and it is possible to re-enable eee, though it is not
simplest thing to do: using ethtool enable eee advertisement, enable
eee, restart the autonegotiation without bringing the interface down
(otherwise the phy config kicks and disable eee again). I reckon this
is not good and I need to address this.
There two kind of PHYs supporting eee, the one advertising eee by
default (like realtek) and the one not advertising it (like micrel).
If the property is going to be generic, I see two options and I'd like
your view on this:
1) The DT provided value could be seen as "preferred" (or boot
setting), which can be cleanly changed with ethtool later on. In this
case, I guess I need to provide a way to force eee advertisement as
well to be consistent.
2) The DT provided value could forbid the advertisement of eee. In this
case I need to return an error if ethtool tries to re-enable it. Phy
with eee advertisement off by default (and not forbidden) would still
need to activate it manually with ethtool after boot. I don't see why
someone would absolutely want eee activated at boot time so I guess
this is OK.
Do you have a preference ?
Thanks for this quick feedback !
Cheers
Jerome
^ permalink raw reply
* [PATCH] mxs-auart: count FIFO overrun errors
From: Greg Kroah-Hartman @ 2016-11-16 9:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479207929.4985.25.camel@reccoware.de>
On Tue, Nov 15, 2016 at 12:05:29PM +0100, Wolfgang Ocker wrote:
> The mxs-auart driver does not count FIFO overrun errors. These errors never
> appear in /proc/tty/driver/ttyAPP. This is because the OERR status bit is
> masked by read_status_mask in the rx interrupt function, but the
> AUART_STAT_OERR bit is never set in read_status_mask. The patch enables the
> counting of overrun errors.
>
> Signed-off-by: Wolfgang Ocker <weo@reccoware.de>
> ---
> ?drivers/tty/serial/mxs-auart.c | 2 +-
> ?1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/tty/serial/mxs-auart.c b/drivers/tty/serial/mxs-auart.c
> index 770454e0dfa3..8c1c9112b3fd 100644
> --- a/drivers/tty/serial/mxs-auart.c
> +++ b/drivers/tty/serial/mxs-auart.c
> @@ -1016,7 +1016,7 @@ static void mxs_auart_settermios(struct uart_port *u,
> ? ctrl |= AUART_LINECTRL_EPS;
> ? }
> ?
> - u->read_status_mask = 0;
> + u->read_status_mask = AUART_STAT_OERR;
> ?
> ? if (termios->c_iflag & INPCK)
> ? u->read_status_mask |= AUART_STAT_PERR;
> --?
> 2.10.0
This patch is corrupted and can not be applied, what did you do here?
Please fix up and resend.
thanks,
greg k-h
^ 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