* [PATCH 5/5] ARM: dts: Add LEGO MINDSTORTMS EV3 dts
From: David Lechner @ 2016-10-27 1:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b0022fad-a96e-86d4-71ba-2b803e5421fe@ti.com>
On 10/24/2016 06:58 AM, Sekhar Nori wrote:
> On Saturday 22 October 2016 12:06 AM, David Lechner wrote:
>> This adds a device tree definition file for LEGO MINDSTORMS EV3.
>
> Thanks for the patch!
>
>>
>> What is working:
>>
>> * Pin muxing
>> * MicroSD card reader
>> * UART on input port 1
>>
>> What is partially working:
>>
>> * Buttons - working after GPIO fix
>> * LEDs - working after GPIO fix
>> * Poweroff/reset - working after GPIO fix
>
> Is the GPIO fix something that will go in v4.9-rc cycle ?
>
FYI, the fix is in linux-gpio/fixes now.
^ permalink raw reply
* [PATCH v4] drm/mediatek: fixed the calc method of data rate per lane
From: Jitao Shi @ 2016-10-27 2:21 UTC (permalink / raw)
To: linux-arm-kernel
Tune dsi frame rate by pixel clock, dsi add some extra signal (i.e.
Tlpx, Ths-prepare, Ths-zero, Ths-trail,Ths-exit) when enter and exit LP
mode, those signals will cause h-time larger than normal and reduce FPS.
So need to multiply a coefficient to offset the extra signal's effect.
coefficient = ((htotal*bpp/lane_number)+Tlpx+Ths_prep+Ths_zero+
Ths_trail+Ths_exit)/(htotal*bpp/lane_number)
Signed-off-by: Jitao Shi <jitao.shi@mediatek.com>
---
Chnage since v3:
- wrapp the commit msg.
- fix alignment of some lines.
Change since v2:
- move phy timing back to dsi_phy_timconfig.
Change since v1:
- phy_timing2 and phy_timing3 refer clock cycle time.
- define values of LPX HS_PRPR HS_ZERO HS_TRAIL TA_GO TA_SURE TA_GET DA_HS_EXIT.
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 71 +++++++++++++++++++++++++-----------
1 file changed, 49 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 28b2044..5defe58 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -85,16 +85,16 @@
#define LD0_WAKEUP_EN BIT(2)
#define DSI_PHY_TIMECON0 0x110
-#define LPX (0xff << 0)
-#define HS_PRPR (0xff << 8)
-#define HS_ZERO (0xff << 16)
-#define HS_TRAIL (0xff << 24)
+#define LPX (5 << 0)
+#define HS_PRPR (6 << 8)
+#define HS_ZERO (10 << 16)
+#define HS_TRAIL (8 << 24)
#define DSI_PHY_TIMECON1 0x114
-#define TA_GO (0xff << 0)
-#define TA_SURE (0xff << 8)
-#define TA_GET (0xff << 16)
-#define DA_HS_EXIT (0xff << 24)
+#define TA_GO (20 << 0)
+#define TA_SURE (7 << 8)
+#define TA_GET (25 << 16)
+#define DA_HS_EXIT (7 << 24)
#define DSI_PHY_TIMECON2 0x118
#define CONT_DET (0xff << 0)
@@ -161,20 +161,17 @@ static void mtk_dsi_mask(struct mtk_dsi *dsi, u32 offset, u32 mask, u32 data)
static void dsi_phy_timconfig(struct mtk_dsi *dsi)
{
u32 timcon0, timcon1, timcon2, timcon3;
- unsigned int ui, cycle_time;
- unsigned int lpx;
+ u32 ui, cycle_time;
ui = 1000 / dsi->data_rate + 0x01;
cycle_time = 8000 / dsi->data_rate + 0x01;
- lpx = 5;
- timcon0 = (8 << 24) | (0xa << 16) | (0x6 << 8) | lpx;
- timcon1 = (7 << 24) | (5 * lpx << 16) | ((3 * lpx) / 2) << 8 |
- (4 * lpx);
+ timcon0 = LPX | HS_PRPR | HS_ZERO | HS_TRAIL;
+ timcon1 = 4 * LPX | (3 * LPX / 2) << 8 | 5 * LPX << 16 | DA_HS_EXIT;
timcon2 = ((NS_TO_CYCLE(0x64, cycle_time) + 0xa) << 24) |
(NS_TO_CYCLE(0x150, cycle_time) << 16);
- timcon3 = (2 * lpx) << 16 | NS_TO_CYCLE(80 + 52 * ui, cycle_time) << 8 |
- NS_TO_CYCLE(0x40, cycle_time);
+ timcon3 = NS_TO_CYCLE(0x40, cycle_time) | (2 * LPX) << 16 |
+ NS_TO_CYCLE(80 + 52 * ui, cycle_time) << 8;
writel(timcon0, dsi->regs + DSI_PHY_TIMECON0);
writel(timcon1, dsi->regs + DSI_PHY_TIMECON1);
@@ -202,19 +199,49 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
{
struct device *dev = dsi->dev;
int ret;
+ u64 bit_clock, total_bits;
+ u32 htotal, htotal_bits, bit_per_pixel, overhead_cycles, overhead_bits;
if (++dsi->refcount != 1)
return 0;
+ switch (dsi->format) {
+ case MIPI_DSI_FMT_RGB565:
+ bit_per_pixel = 16;
+ break;
+ case MIPI_DSI_FMT_RGB666_PACKED:
+ bit_per_pixel = 18;
+ break;
+ case MIPI_DSI_FMT_RGB666:
+ case MIPI_DSI_FMT_RGB888:
+ default:
+ bit_per_pixel = 24;
+ break;
+ }
/**
- * data_rate = (pixel_clock / 1000) * pixel_dipth * mipi_ratio;
- * pixel_clock unit is Khz, data_rata unit is MHz, so need divide 1000.
- * mipi_ratio is mipi clk coefficient for balance the pixel clk in mipi.
- * we set mipi_ratio is 1.05.
+ * data_rate = (pixel_clock) * bit_per_pixel * mipi_ratio / lane_num;
+ * vm.pixelclock is Khz, data_rata unit is Hz, so need to multiply 1000
+ * mipi_ratio is (htotal * byte_per_pixel / lane_num + Tlpx + Ths_prep
+ * + Thstrail + Ths_exit + Ths_zero) /
+ * (htotal * byte_per_pixel /lane_number)
*/
- dsi->data_rate = dsi->vm.pixelclock * 3 * 21 / (1 * 1000 * 10);
+ bit_clock = dsi->vm.pixelclock * 1000 * bit_per_pixel;
+ htotal = dsi->vm.hactive + dsi->vm.hback_porch + dsi->vm.hfront_porch +
+ dsi->vm.hsync_len;
+ htotal_bits = htotal * bit_per_pixel;
+
+ /**
+ * overhead = lpx + hs_prepare + hs_zero + hs_trail + hs_exit
+ */
+ overhead_cycles = LPX + (HS_PRPR >> 8) + (HS_ZERO >> 16) +
+ (HS_TRAIL >> 24) + (DA_HS_EXIT >> 24);
+ overhead_bits = overhead_cycles * dsi->lanes * 8;
+ total_bits = htotal_bits + overhead_bits;
+
+ dsi->data_rate = DIV_ROUND_UP_ULL(bit_clock * total_bits,
+ htotal_bits * dsi->lanes);
- ret = clk_set_rate(dsi->hs_clk, dsi->data_rate * 1000000);
+ ret = clk_set_rate(dsi->hs_clk, dsi->data_rate);
if (ret < 0) {
dev_err(dev, "Failed to set data rate: %d\n", ret);
goto err_refcount;
--
1.7.9.5
^ permalink raw reply related
* [PATCH] arm64: Remove pointless WARN_ON in DMA teardown
From: Sricharan @ 2016-10-27 2:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <74f5ae2ead8bb8fa9fabcf88b5962885b29eb2d5.1477505971.git.robin.murphy@arm.com>
Hi,
>
>We expect arch_teardown_dma_ops() to be called very late in a device's
>life, after it has been removed from its bus, and thus after the IOMMU
>bus notifier has run. As such, even if this funny little check did make
>sense, it's unlikely to achieve what it thinks it's trying to do anyway.
>It's a residual trace of an earlier implementation which didn't belong
>here from the start; belatedly snuff it out.
>
>Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>---
> arch/arm64/mm/dma-mapping.c | 5 -----
> 1 file changed, 5 deletions(-)
>
>diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
>index 5cd0a383b14b..290a84f3351f 100644
>--- a/arch/arm64/mm/dma-mapping.c
>+++ b/arch/arm64/mm/dma-mapping.c
>@@ -940,11 +940,6 @@ static void __iommu_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
>
> void arch_teardown_dma_ops(struct device *dev)
> {
>- struct iommu_domain *domain = iommu_get_domain_for_dev(dev);
>-
>- if (WARN_ON(domain))
>- iommu_detach_device(domain, dev);
>-
Thanks!!, clears my doubt that i had for quite sometime.
Regards,
Sricharan
^ permalink raw reply
* [PATCH 1/2] mm/memblock: prepare a capability to support memblock near alloc
From: Leizhen (ThunderTown) @ 2016-10-27 2:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026093152.GE18382@dhcp22.suse.cz>
On 2016/10/26 17:31, Michal Hocko wrote:
> On Wed 26-10-16 11:10:44, Leizhen (ThunderTown) wrote:
>>
>>
>> On 2016/10/25 21:23, Michal Hocko wrote:
>>> On Tue 25-10-16 10:59:17, Zhen Lei wrote:
>>>> If HAVE_MEMORYLESS_NODES is selected, and some memoryless numa nodes are
>>>> actually exist. The percpu variable areas and numa control blocks of that
>>>> memoryless numa nodes need to be allocated from the nearest available
>>>> node to improve performance.
>>>>
>>>> Although memblock_alloc_try_nid and memblock_virt_alloc_try_nid try the
>>>> specified nid at the first time, but if that allocation failed it will
>>>> directly drop to use NUMA_NO_NODE. This mean any nodes maybe possible at
>>>> the second time.
>>>>
>>>> To compatible the above old scene, I use a marco node_distance_ready to
>>>> control it. By default, the marco node_distance_ready is not defined in
>>>> any platforms, the above mentioned functions will work as normal as
>>>> before. Otherwise, they will try the nearest node first.
>>>
>>> I am sorry but it is absolutely unclear to me _what_ is the motivation
>>> of the patch. Is this a performance optimization, correctness issue or
>>> something else? Could you please restate what is the problem, why do you
>>> think it has to be fixed at memblock layer and describe what the actual
>>> fix is please?
>>
>> This is a performance optimization.
>
> Do you have any numbers to back the improvements?
I have not collected any performance data, but at least in theory, it's beneficial and harmless,
except make code looks a bit urly. Because all related functions are actually defined as __init,
for example:
phys_addr_t __init memblock_alloc_try_nid(
void * __init memblock_virt_alloc_try_nid(
And all related memory(percpu variables and NODE_DATA) is mostly referred at running time.
>
>> The problem is if some memoryless numa nodes are
>> actually exist, for example: there are total 4 nodes, 0,1,2,3, node 1 has no memory,
>> and the node distances is as below:
>> ---------board-------
>> | |
>> | |
>> socket0 socket1
>> / \ / \
>> / \ / \
>> node0 node1 node2 node3
>> distance[1][0] is nearer than distance[1][2] and distance[1][3]. CPUs on node1 access
>> the memory of node0 is faster than node2 or node3.
>>
>> Linux defines a lot of percpu variables, each cpu has a copy of it and most of the time
>> only to access their own percpu area. In this example, we hope the percpu area of CPUs
>> on node1 allocated from node0. But without these patches, it's not sure that.
>
> I am not familiar with the percpu allocator much so I might be
> completely missig a point but why cannot this be solved in the percpu
> allocator directly e.g. by using cpu_to_mem which should already be
> memoryless aware.
My test result told me that it can not:
[ 0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x00000011ffffffff]
[ 0.000000] Could not find start_pfn for node 1
[ 0.000000] Initmem setup node 1 [mem 0x0000000000000000-0x0000000000000000]
[ 0.000000] Initmem setup node 2 [mem 0x0000001200000000-0x00000013ffffffff]
[ 0.000000] Initmem setup node 3 [mem 0x0000001400000000-0x00000017ffffffff]
[ 14.801895] NODE_DATA(0) = 0x11ffffe500
[ 14.805749] NODE_DATA(1) = 0x11ffffca00 //(1), see below
[ 14.809602] NODE_DATA(2) = 0x13ffffe500
[ 14.813455] NODE_DATA(3) = 0x17fffe5480
[ 14.817316] cpu 0 on node0: 11fff87638
[ 14.821083] cpu 1 on node0: 11fff9c638
[ 14.824850] cpu 2 on node0: 11fffb1638
[ 14.828616] cpu 3 on node0: 11fffc6638
[ 14.832383] cpu 4 on node1: 17fff8a638 //(2), see below
[ 14.836149] cpu 5 on node1: 17fff9f638
[ 14.839912] cpu 6 on node1: 17fffb4638
[ 14.843677] cpu 7 on node1: 17fffc9638
[ 14.847444] cpu 8 on node2: 13fffa4638
[ 14.851210] cpu 9 on node2: 13fffb9638
[ 14.854976] cpu10 on node2: 13fffce638
[ 14.858742] cpu11 on node2: 13fffe3638
[ 14.862510] cpu12 on node3: 17fff36638
[ 14.866276] cpu13 on node3: 17fff4b638
[ 14.870042] cpu14 on node3: 17fff60638
[ 14.873809] cpu15 on node3: 17fff75638
(1) memblock_alloc_try_nid and with these patches, memory was allocated from node0
(2) do the same implementation as X86 and PowerPC, memory was allocated from node3:
return __alloc_bootmem_node(NODE_DATA(nid), size, align, __pa(MAX_DMA_ADDRESS));
I'm not sure how about on X86 and PowerPC, here is my test cases. Is anybody interested and
have testing environment, can you help me to execute it?
static int tst_numa_002(void)
{
int i;
for (i = 0; i < nr_node_ids; i++)
pr_info("NODE_DATA(%d) = 0x%llx\n", i, virt_to_phys(NODE_DATA(i)));
return 0;
}
static int tst_numa_003(void)
{
int cpu;
void __percpu *p;
p = __alloc_percpu(0x100, 1);
for_each_possible_cpu(cpu)
pr_info("cpu%2d on node%d: %llx\n", cpu, cpu_to_node(cpu), per_cpu_ptr_to_phys(per_cpu_ptr(p, cpu)));
free_percpu(p);
return 0;
}
>
> Generating a new API while we have means to use an existing one sounds
> just not right to me.
Yes, so I gave up to create two new functions and selected this implementation.
>
^ permalink raw reply
* [PATCH V3 5/8] iommu: of: Handle IOMMU lookup failure with deferred probing or error
From: Sricharan @ 2016-10-27 2:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f08e65b4-f755-897c-f776-40f0d6788251@arm.com>
Hi Robin,
>> From: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
>>
>> Failures to look up an IOMMU when parsing the DT iommus property need to
>> be handled separately from the .of_xlate() failures to support deferred
>> probing.
>>
>> The lack of a registered IOMMU can be caused by the lack of a driver for
>> the IOMMU, the IOMMU device probe not having been performed yet, having
>> been deferred, or having failed.
>>
>> The first case occurs when the device tree describes the bus master and
>> IOMMU topology correctly but no device driver exists for the IOMMU yet
>> or the device driver has not been compiled in. Return NULL, the caller
>> will configure the device without an IOMMU.
>>
>> The second and third cases are handled by deferring the probe of the bus
>> master device which will eventually get reprobed after the IOMMU.
>>
>> The last case is currently handled by deferring the probe of the bus
>> master device as well. A mechanism to either configure the bus master
>> device without an IOMMU or to fail the bus master device probe depending
>> on whether the IOMMU is optional or mandatory would be a good
>> enhancement.
>>
>> The current iommu framework handles pci and non-pci devices separately,
>> so taken care of both the paths in this patch. The iommu's add_device
>> callback is invoked after the master's configuration data is added in
>> xlate. This is needed because the iommu core calls add_device callback
>> during the BUS_ADD_DEVICE notifier, which is of no use now. Eventually
>> that call has to be removed.
>
>Laurent's signoff seems to have gone missing here.
Ah, preserved his authorship, but missed this. Will add it back.
>
>> Signed-off-by: Sricharan R <sricharan@codeaurora.org>
>> ---
>> drivers/iommu/of_iommu.c | 47 +++++++++++++++++++++++++++++++++++++++++++----
>> drivers/of/device.c | 7 ++++++-
>> include/linux/of_device.h | 6 ++++--
>> 3 files changed, 53 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
>> index 5b82862..1a5e28b 100644
>> --- a/drivers/iommu/of_iommu.c
>> +++ b/drivers/iommu/of_iommu.c
>> @@ -23,6 +23,7 @@
>> #include <linux/of.h>
>> #include <linux/of_iommu.h>
>> #include <linux/of_pci.h>
>> +#include <linux/pci.h>
>> #include <linux/slab.h>
>>
>> static const struct of_device_id __iommu_of_table_sentinel
>> @@ -167,12 +168,29 @@ static const struct iommu_ops
>> return NULL;
>>
>> ops = of_iommu_get_ops(iommu_spec.np);
>> +
>> + if (!ops) {
>> + const struct of_device_id *oid;
>> +
>> + oid = of_match_node(&__iommu_of_table, iommu_spec.np);
>> + ops = oid ? ERR_PTR(-EPROBE_DEFER) : NULL;
>
>It would seem even simpler and more convenient to roll this into the end
>of of_iommu_get_ops():
ok, understand. Will move this there.
>
> if (!ops && of_match_node(&__iommu_of_table, iommu_spec.np))
> ops = ERR_PTR(-EPROBE_DEFER);
>
>then just fix up the existing !ops checks to !IS_ERR(ops) appropriately.
ok.
>
>> + return ops;
>> + }
>> +
>> if (!ops || !ops->of_xlate ||
>> iommu_fwspec_init(&pdev->dev, &iommu_spec.np->fwnode, ops) ||
>> ops->of_xlate(&pdev->dev, &iommu_spec))
>> ops = NULL;
>>
>> + if (ops && ops->add_device) {
>> + ops = (ops->add_device(&pdev->dev) == 0) ? ops : NULL;
>
>This is a really obtuse way of writing
>
> if (ops->add_device(...))
> ops = NULL;
ok, will change it this way.
>
>However, given that we're now returning an ERR_PTR, it would be worth
>capturing the return value of add_device and propagating the error back
>up - if the IOMMU driver has refused one of its masters for some reason,
>it probably isn't safe to allow that device to do DMA either way, so we
>ought to prevent it probing at all.
>
ok, will return the err value instead of NULL here.
>> +
>> + if (!ops)
>> + dev_err(&pdev->dev, "Failed to setup iommu ops\n");
>
>Given the above, I think this should be more along the lines of "Device
>rejected by IOMMU: %d" with the actual error code as well. It's one of
>those "if you ever see it, you're going to have to debug it" cases, so
>the clearer the better.
>
ok, will reword the print.
>> + }
>> +
>> of_node_put(iommu_spec.np);
>> +
>> return ops;
>> }
>>
>> @@ -183,9 +201,15 @@ const struct iommu_ops *of_iommu_configure(struct device *dev,
>> struct device_node *np;
>> const struct iommu_ops *ops = NULL;
>> int idx = 0;
>> + struct device *bridge;
>> +
>> + if (dev_is_pci(dev)) {
>> + bridge = pci_get_host_bridge_device(to_pci_dev(dev));
>>
>> - if (dev_is_pci(dev))
>> - return of_pci_iommu_configure(to_pci_dev(dev), master_np);
>> + if (bridge && bridge->parent && bridge->parent->of_node)
>> + return of_pci_iommu_configure(to_pci_dev(dev),
>> + bridge->parent->of_node);
>
> else fall through to treating it as a platform device?
>
ha, surely wrong. Will correct this and move it to the of_pci_iommu_configure helper.
>...that's not right. Anyway, this is PCI-specific stuff so should be in
>the PCI-specific helper function.
>
>> + }
>>
>> /*
>> * We don't currently walk up the tree looking for a parent IOMMU.
>> @@ -198,6 +222,14 @@ const struct iommu_ops *of_iommu_configure(struct device *dev,
>> np = iommu_spec.np;
>> ops = of_iommu_get_ops(np);
>>
>> + if (!ops) {
>> + const struct of_device_id *oid;
>> +
>> + oid = of_match_node(&__iommu_of_table, np);
>> + ops = oid ? ERR_PTR(-EPROBE_DEFER) : NULL;
>> + goto err_put_node;
>> + }
>
>Same comment as above. Especially since moving it to of_iommu_get_ops()
>would obviate the duplication.
ok.
>
>> +
>> if (!ops || !ops->of_xlate ||
>> iommu_fwspec_init(dev, &np->fwnode, ops) ||
>> ops->of_xlate(dev, &iommu_spec))
>> @@ -207,11 +239,18 @@ const struct iommu_ops *of_iommu_configure(struct device *dev,
>> idx++;
>> }
>>
>> + if (ops && ops->add_device) {
>> + ops = (ops->add_device(dev) == 0) ? ops : NULL;
>> +
>> + if (!ops)
>> + dev_err(dev, "Failed to setup iommu_ops\n");
>> + }
>> +
>
>It would be nice to avoid duplicating this as well.
ok, sure, will correct.
Regards,
Sricharan
^ permalink raw reply
* [PATCH v5 3/9] drm/hisilicon/hibmc: Add support for frame buffer
From: Rongrong Zou @ 2016-10-27 3:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026125910.j6bfc4tq4gjrrmtv@phenom.ffwll.local>
? 2016/10/26 20:59, Daniel Vetter ??:
> On Wed, Oct 26, 2016 at 05:19:31PM +0800, Rongrong Zou wrote:
>> Hi Daniel,
>>
>> Thansk for reviewing!
>>
>> ? 2016/10/26 13:56, Daniel Vetter ??:
>>> On Wed, Oct 26, 2016 at 10:37:00AM +0800, Rongrong Zou wrote:
>>>> Add support for fbdev and kms fb management.
>>>>
>>>> Signed-off-by: Rongrong Zou <zourongrong@gmail.com>
>>>
>>> Small drive-by comment below.
>>>
>>>> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
>>>> index db8d80e..d41138a 100644
>>>> --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
>>>> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
>>>> @@ -20,9 +20,23 @@
>>>> #define HIBMC_DRM_DRV_H
>>>>
>>>> #include <drm/drmP.h>
>>>> +#include <drm/drm_fb_helper.h>
>>>> #include <drm/ttm/ttm_bo_driver.h>
>>>> #include <drm/drm_gem.h>
>>>>
>>>> +struct hibmc_framebuffer {
>>>> + struct drm_framebuffer fb;
>>>> + struct drm_gem_object *obj;
>>>> + bool is_fbdev_fb;
>>>> +};
>>>> +
>>>> +struct hibmc_fbdev {
>>>> + struct drm_fb_helper helper;
>>>> + struct hibmc_framebuffer fb;
>>>
>>> I wouldn't embed the single framebuffer here, but instead have a pointer
>>> and just refcount it. This here is a pattern that predates framebuffer
>>> refcounting, and it leads to plenty of surprises.
>>
>> will allocate fbdev in next patch version, thanks.
>
> Not the fbdev, the hibmc_framebuffer.
Understood, thanks.
>
>>> Maybe we should update the documentation of
>>> drm_framebuffer_unregister_private() to mention that it is deprecated? The
>>> overview doc in drm_framebuffer.c already explains that, but I guess
>>> that's not obvious enough.
>>
>> Just replace drm_framebuffer_unregister_private() with
>> drm_framebuffer_remove()?
>>
>> I found many other drivers use the following two functions in their
>> own xxx_fbdev_destroy():
>> drm_framebuffer_unregister_private(fbdev->fb);
>> drm_framebuffer_remove(fbdev->fb);
>> so the former is redundant and can be removed directly?
>
> They all embed the fb instead of having a pointer, because those drivers
> are all older than the fb refcounting support. In general good practice is
> to look at the most recently merged driver, not at all of them. Only the
> most recently one has a good chance to be up-to-date with latest best
> practices. The function to call would be drm_framebuffer_unreference(),
> and your struct above should be
>
> struct hibmc_fbdev {
> struct drm_fb_helper helper;
> struct hibmc_framebuffer *fb;
> ...
> };
>
> Note how fb is a pointer here, not an embedded struct.
And in hibmc_user_framebuffer_destroy(), it should call
kfree(hibmc_framebuffer *hibmc_fb) not kfree(drm_framebuffer *fb), thanks.
regards,
Rongrong
> -Daniel
>
>>
>>>
>>> Can you pls do that patch? And pls make sure it all looks pretty when
>>> building the docs with
>>
>> No problem, i'll send another patch later.
>>
>> Regards,
>> Rongrong
>>
>>>
>>> $ make htmldocs
>>>
>>> Thanks, Daniel
>>>
>>
>>
>>
>
^ permalink raw reply
* [PATCH v2 3/4] usb: musb: da8xx: Add DT support for the DA8xx driver
From: David Lechner @ 2016-10-27 3:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477494237-22831-4-git-send-email-abailon@baylibre.com>
On 10/26/2016 10:03 AM, Alexandre Bailon wrote:
> From: Petr Kulhavy <petr@barix.com>
>
> This adds DT support for TI DA8xx/OMAP-L1x/AM17xx/AM18xx MUSB driver
>
> Signed-off-by: Petr Kulhavy <petr@barix.com>
> Signed-off-by: Alexandre Bailon <abailon@baylibre.com>
> ---
> drivers/usb/musb/da8xx.c | 47 +++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 47 insertions(+)
>
> diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c
> index 210b7e4..bfa571d 100644
> --- a/drivers/usb/musb/da8xx.c
> +++ b/drivers/usb/musb/da8xx.c
> @@ -6,6 +6,9 @@
> * Based on the DaVinci "glue layer" code.
> * Copyright (C) 2005-2006 by Texas Instruments
> *
> + * DT support
> + * Copyright (c) 2016 Petr Kulhavy <petr@barix.com>
> + *
> * This file is part of the Inventra Controller Driver for Linux.
> *
> * The Inventra Controller Driver for Linux is free software; you
> @@ -433,6 +436,21 @@ static int da8xx_musb_exit(struct musb *musb)
> return 0;
> }
>
> +static inline u8 get_vbus_power(struct device *dev)
> +{
> + struct regulator *vbus_supply;
> + int current_uA;
> +
> + vbus_supply = regulator_get_optional(dev, "vbus");
> + if (IS_ERR(vbus_supply))
> + return 255;
> + current_uA = regulator_get_current_limit(vbus_supply);
> + regulator_put(vbus_supply);
> + if (current_uA <= 0 || current_uA > 510000)
> + return 255;
> + return current_uA / 1000 / 2;
> +}
> +
> static const struct musb_platform_ops da8xx_ops = {
> .quirks = MUSB_DMA_CPPI | MUSB_INDEXED_EP,
> .init = da8xx_musb_init,
> @@ -458,6 +476,12 @@ static const struct platform_device_info da8xx_dev_info = {
> .dma_mask = DMA_BIT_MASK(32),
> };
>
> +static const struct musb_hdrc_config da8xx_config = {
> + .ram_bits = 10,
> + .num_eps = 5,
> + .multipoint = 1,
> +};
> +
> static int da8xx_probe(struct platform_device *pdev)
> {
> struct resource musb_resources[2];
> @@ -465,7 +489,9 @@ static int da8xx_probe(struct platform_device *pdev)
> struct da8xx_glue *glue;
> struct platform_device_info pinfo;
> struct clk *clk;
> + struct device_node *np = pdev->dev.of_node;
> int ret;
> + struct resource *res;
res is not used anywhere
>
> glue = devm_kzalloc(&pdev->dev, sizeof(*glue), GFP_KERNEL);
> if (!glue)
> @@ -486,6 +512,18 @@ static int da8xx_probe(struct platform_device *pdev)
> glue->dev = &pdev->dev;
> glue->clk = clk;
>
> + if (IS_ENABLED(CONFIG_OF) && np) {
> + pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
> + if (!pdata) {
> + /* FIXME */
Why FIXME? I don't see anything that needs to be fixed here.
> + return -ENOMEM;
> + }
> +
> + pdata->config = &da8xx_config;
> + pdata->mode = musb_get_mode(&pdev->dev);
> + pdata->power = get_vbus_power(&pdev->dev);
> + }
> +
> pdata->platform_ops = &da8xx_ops;
>
> glue->usb_phy = usb_phy_generic_register();
> @@ -536,11 +574,20 @@ static int da8xx_remove(struct platform_device *pdev)
> return 0;
> }
>
Shouldn't you have #ifdef CONFIG_OF here since you are using
of_match_ptr() below?
> +static const struct of_device_id da8xx_id_table[] = {
> + {
> + .compatible = "ti,da830-musb",
> + },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, da8xx_id_table);
#endif
> +
> static struct platform_driver da8xx_driver = {
> .probe = da8xx_probe,
> .remove = da8xx_remove,
> .driver = {
> .name = "musb-da8xx",
> + .of_match_table = of_match_ptr(da8xx_id_table),
> },
> };
>
>
Tested working on LEGO MINDSTORMS EV3 using dr_mode = "peripheral" and
no vbus-supply.
Tested-By: David Lechner <david@lechnology.com>
^ permalink raw reply
* [PATCH v2 2/4] usb: musb: core: added helper function for parsing DT
From: David Lechner @ 2016-10-27 3:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477494237-22831-3-git-send-email-abailon@baylibre.com>
On 10/26/2016 10:03 AM, Alexandre Bailon wrote:
> From: Petr Kulhavy <petr@barix.com>
>
> This adds the function musb_get_mode() to get the DT property "dr_mode"
>
> Signed-off-by: Petr Kulhavy <petr@barix.com>
> Acked-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
> Signed-off-by: Alexandre Bailon <abailon@baylibre.com>
> ---
> drivers/usb/musb/musb_core.c | 19 +++++++++++++++++++
> drivers/usb/musb/musb_core.h | 5 +++++
> 2 files changed, 24 insertions(+)
>
> diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
> index 27dadc0..bba07e7 100644
> --- a/drivers/usb/musb/musb_core.c
> +++ b/drivers/usb/musb/musb_core.c
> @@ -100,6 +100,7 @@
> #include <linux/io.h>
> #include <linux/dma-mapping.h>
> #include <linux/usb.h>
> +#include <linux/usb/of.h>
>
> #include "musb_core.h"
> #include "musb_trace.h"
> @@ -130,6 +131,24 @@ static inline struct musb *dev_to_musb(struct device *dev)
> return dev_get_drvdata(dev);
> }
>
> +enum musb_mode musb_get_mode(struct device *dev)
> +{
> + enum usb_dr_mode mode;
> +
> + mode = usb_get_dr_mode(dev);
> + switch (mode) {
> + case USB_DR_MODE_HOST:
> + return MUSB_HOST;
> + case USB_DR_MODE_PERIPHERAL:
> + return MUSB_PERIPHERAL;
> + case USB_DR_MODE_OTG:
> + case USB_DR_MODE_UNKNOWN:
> + default:
> + return MUSB_OTG;
> + }
> +}
> +EXPORT_SYMBOL_GPL(musb_get_mode);
> +
> /*-------------------------------------------------------------------------*/
>
> #ifndef CONFIG_BLACKFIN
> diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
> index 2cb88a49..a406468 100644
> --- a/drivers/usb/musb/musb_core.h
> +++ b/drivers/usb/musb/musb_core.h
> @@ -617,4 +617,9 @@ static inline void musb_platform_post_root_reset_end(struct musb *musb)
> musb->ops->post_root_reset_end(musb);
> }
>
> +/* gets the "dr_mode" property from DT and converts it into musb_mode
> + * if the property is not found or not recognized returns MUSB_OTG
> + */
> +extern enum musb_mode musb_get_mode(struct device *dev);
> +
> #endif /* __MUSB_CORE_H__ */
>
Tested working on LEGO MINDSTORMS EV3 using dr_mode = "peripheral" and
no vbus-supply.
Tested-By: David Lechner <david@lechnology.com>
^ permalink raw reply
* [PATCH 1/2] ARM: dts: uniphier: add CPU clocks and OPP table for Pro5 SoC
From: Viresh Kumar @ 2016-10-27 3:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477499859-12415-1-git-send-email-yamada.masahiro@socionext.com>
On 27-10-16, 01:37, Masahiro Yamada wrote:
> Add a CPU clock to every CPU node and a CPU OPP table to use the
> generic cpufreq driver.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> ---
>
> arch/arm/boot/dts/uniphier-pro5.dtsi | 74 ++++++++++++++++++++++++++++++++++++
> 1 file changed, 74 insertions(+)
For both patches.
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
--
viresh
^ permalink raw reply
* [PATCH V3 6/8] arm: dma-mapping: Reset the device's dma_ops
From: Sricharan @ 2016-10-27 3:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a3d4533f-165d-f444-7681-141479617a18@arm.com>
Hi Robin,
>-----Original Message-----
>From: Robin Murphy [mailto:robin.murphy at arm.com]
>Sent: Wednesday, October 26, 2016 8:37 PM
>To: Sricharan R <sricharan@codeaurora.org>; will.deacon at arm.com; joro at 8bytes.org; iommu at lists.linux-foundation.org; linux-arm-
>kernel at lists.infradead.org; linux-arm-msm at vger.kernel.org; laurent.pinchart at ideasonboard.com; m.szyprowski at samsung.com;
>tfiga at chromium.org; srinivas.kandagatla at linaro.org
>Subject: Re: [PATCH V3 6/8] arm: dma-mapping: Reset the device's dma_ops
>
>On 04/10/16 18:03, Sricharan R wrote:
>> The dma_ops for the device is not getting set to NULL in
>> arch_tear_down_dma_ops and this causes an issue when the
>> device's probe gets deferred and retried. So reset the
>> dma_ops to NULL.
>
>Reviewed-by: Robin Murphy <robin.murphy@arm.com>
>
Thanks.
>This seems like it could stand independently from the rest of the series
>- might be worth rewording the commit message to more general terms,
>i.e. arch_teardown_dma_ops() being the inverse of arch_setup_dma_ops()
>thus clearing the ops set by the latter, and sending it to Russell as a
>fix in its own right.
Ok, will reword the commit log and push this separately.
Regards,
Sricharan
^ permalink raw reply
* [PATCH 2/2] arm64/numa: support HAVE_MEMORYLESS_NODES
From: Leizhen (ThunderTown) @ 2016-10-27 3:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026183614.GJ15216@arm.com>
On 2016/10/27 2:36, Will Deacon wrote:
> On Tue, Oct 25, 2016 at 10:59:18AM +0800, Zhen Lei wrote:
>> Some numa nodes may have no memory. For example:
>> 1) a node has no memory bank plugged.
>> 2) a node has no memory bank slots.
>>
>> To ensure percpu variable areas and numa control blocks of the
>> memoryless numa nodes to be allocated from the nearest available node to
>> improve performance, defined node_distance_ready. And make its value to be
>> true immediately after node distances have been initialized.
>>
>> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
>> ---
>> arch/arm64/Kconfig | 4 ++++
>> arch/arm64/include/asm/numa.h | 3 +++
>> arch/arm64/mm/numa.c | 6 +++++-
>> 3 files changed, 12 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>> index 30398db..648dd13 100644
>> --- a/arch/arm64/Kconfig
>> +++ b/arch/arm64/Kconfig
>> @@ -609,6 +609,10 @@ config NEED_PER_CPU_EMBED_FIRST_CHUNK
>> def_bool y
>> depends on NUMA
>>
>> +config HAVE_MEMORYLESS_NODES
>> + def_bool y
>> + depends on NUMA
>
> Given that patch 1 and the associated node_distance_ready stuff is all
> an unqualified performance optimisation, is there any merit in just
> enabling HAVE_MEMORYLESS_NODES in Kconfig and then optimising things as
> a separate series when you have numbers to back it up?
HAVE_MEMORYLESS_NODES is also an performance optimisation for memoryless scenario.
For example:
node0 is a memoryless node, node1 is the nearest node of node0.
We want to allocate memory from node0, normally memory manager will try node0 first, then node1.
But we have already kwown that node0 have no memory, so we can tell memory manager directly try
node1 first. So HAVE_MEMORYLESS_NODES is used to skip the memoryless nodes, don't try them.
So I think the title of this patch is misleading, I will rewrite it in V2.
Or, Do you mean separate it into a new patch?
>
> Will
>
> .
>
^ permalink raw reply
* [v12, 5/8] soc: fsl: add GUTS driver for QorIQ platforms
From: Y.B. Lu @ 2016-10-27 4:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477501566.6812.9.camel@buserror.net>
Hi Scott,
> -----Original Message-----
> From: Scott Wood [mailto:oss at buserror.net]
> Sent: Thursday, October 27, 2016 1:06 AM
> To: Y.B. Lu; linux-mmc at vger.kernel.org; ulf.hansson at linaro.org; Arnd
> Bergmann
> Cc: 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 at vger.kernel.org; linux-i2c at vger.kernel.org; iommu at lists.linux-
> foundation.org; netdev at vger.kernel.org; Mark Rutland; Rob Herring;
> Russell King; Jochen Friedrich; Joerg Roedel; Claudiu Manoil; Bhupesh
> Sharma; Qiang Zhao; Kumar Gala; Santosh Shilimkar; Leo Li; X.B. Xie; M.H.
> Lian
> Subject: Re: [v12, 5/8] soc: fsl: add GUTS driver for QorIQ platforms
>
> On Wed, 2016-09-21 at 14:57 +0800, Yangbo Lu wrote:
> > diff --git a/drivers/soc/fsl/Kconfig b/drivers/soc/fsl/Kconfig new
> > file mode 100644 index 0000000..b99764c
> > --- /dev/null
> > +++ b/drivers/soc/fsl/Kconfig
> > @@ -0,0 +1,19 @@
> > +#
> > +# Freescale SOC drivers
> > +#
> > +
> > +source "drivers/soc/fsl/qe/Kconfig"
> > +
> > +config FSL_GUTS
> > + bool "Freescale QorIQ GUTS driver"
> > + select SOC_BUS
> > + help
> > + ??The global utilities block controls power management, I/O device
> > + ??enabling, power-onreset(POR) configuration monitoring, alternate
> > + ??function selection for multiplexed signals,and clock control.
> > + ??This driver is to manage and access global utilities block.
> > + ??Initially only reading SVR and registering soc device are
> > supported.
> > + ??Other guts accesses, such as reading RCW, should eventually be
> > moved
> > + ??into this driver as well.
> > +
> > + ??If you want GUTS driver support, you should say Y here.
>
> This is user-enablable without dependencies, which means it will break
> some randconfigs. ?If this is to be enabled via select then remove the
> text after "bool".
[Lu Yangbo-B47093] Will enable it via select and remove text after 'bool'.
>
> > +/* SoC die attribute definition for QorIQ platform */ static const
> > +struct fsl_soc_die_attr fsl_soc_die[] = { #ifdef CONFIG_PPC
> > + /*
> > + ?* Power Architecture-based SoCs T Series
> > + ?*/
> > +
> > + /* Die: T4240, SoC: T4240/T4160/T4080 */
> > + { .die = "T4240",
> > + ??.svr = 0x82400000,
> > + ??.mask = 0xfff00000,
> > + },
> > + /* Die: T1040, SoC: T1040/T1020/T1042/T1022 */
> > + { .die = "T1040",
> > + ??.svr = 0x85200000,
> > + ??.mask = 0xfff00000,
> > + },
> > + /* Die: T2080, SoC: T2080/T2081 */
> > + { .die = "T2080",
> > + ??.svr = 0x85300000,
> > + ??.mask = 0xfff00000,
> > + },
> > + /* Die: T1024, SoC: T1024/T1014/T1023/T1013 */
> > + { .die = "T1024",
> > + ??.svr = 0x85400000,
> > + ??.mask = 0xfff00000,
> > + },
> > +#endif /* CONFIG_PPC */
> > +#if defined(CONFIG_ARCH_MXC) || defined(CONFIG_ARCH_LAYERSCAPE)
>
> Will this driver ever be probed on MXC? ?Why do we need these ifdefs at
> all?
[Lu Yangbo-B47093] Will remove them. In the previous version, we use too many members for soc definition, so I add #ifdef for ARCH.
CONFIG_ARCH_MXC was for ls1021a.
>
>
> > + /*
> > + ?* ARM-based SoCs LS Series
> > + ?*/
> > +
> > + /* Die: LS1043A, SoC: LS1043A/LS1023A */
> > + { .die = "LS1043A",
> > + ??.svr = 0x87920000,
> > + ??.mask = 0xffff0000,
> > + },
> > + /* Die: LS2080A, SoC: LS2080A/LS2040A/LS2085A */
> > + { .die = "LS2080A",
> > + ??.svr = 0x87010000,
> > + ??.mask = 0xff3f0000,
> > + },
> > + /* Die: LS1088A, SoC: LS1088A/LS1048A/LS1084A/LS1044A */
> > + { .die = "LS1088A",
> > + ??.svr = 0x87030000,
> > + ??.mask = 0xff3f0000,
> > + },
> > + /* Die: LS1012A, SoC: LS1012A */
> > + { .die = "LS1012A",
> > + ??.svr = 0x87040000,
> > + ??.mask = 0xffff0000,
> > + },
> > + /* Die: LS1046A, SoC: LS1046A/LS1026A */
> > + { .die = "LS1046A",
> > + ??.svr = 0x87070000,
> > + ??.mask = 0xffff0000,
> > + },
> > + /* Die: LS2088A, SoC: LS2088A/LS2048A/LS2084A/LS2044A */
> > + { .die = "LS2088A",
> > + ??.svr = 0x87090000,
> > + ??.mask = 0xff3f0000,
> > + },
> > + /* Die: LS1021A, SoC: LS1021A/LS1020A/LS1022A
> > + ?* Note: Put this die at the end in cause of incorrect
> > identification
> > + ?*/
> > + { .die = "LS1021A",
> > + ??.svr = 0x87000000,
> > + ??.mask = 0xfff00000,
> > + },
> > +#endif /* CONFIG_ARCH_MXC || CONFIG_ARCH_LAYERSCAPE */
>
> Instead of relying on ordering, add more bits to the mask so that there's
> no overlap. ?I think 0xfff70000 would work.
[Lu Yangbo-B47093] Ok, Will do that. Then we add 3 bits of 'Various Personalities' field for ls1021a die identification.
>
> > +out:
> > + kfree(soc_dev_attr.machine);
> > + kfree(soc_dev_attr.family);
> > + kfree(soc_dev_attr.soc_id);
> > + kfree(soc_dev_attr.revision);
> > + iounmap(guts->regs);
> > +out_free:
> > + kfree(guts);
> > + return ret;
> > +}
>
> Please use devm.
[Lu Yangbo-B47093] Sorry for forgetting this. Will do that and send out the new version soon.
Thanks for your comments.
>
> -Scott
^ permalink raw reply
* [PATCH V3 7/8] arm/arm64: dma-mapping: Call iommu's remove_device callback during device detach
From: Sricharan @ 2016-10-27 5:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2873304f-8b2e-b519-b3e6-d2b452b1df60@arm.com>
Hi Robin,
>> dma_deconfigure calls arch_teardown_dma_ops in the device_detach path,
>> which is called when the device gets detached from the driver.
>> When the device was added, iommu's add_device callback was used to
>> add the device in to its iommu_group and setup the device to be ready
>> to use its iommu. Similarly, call remove_device callback to remove the
>> device from the group and reset any other device's iommu configurations.
>>
>> Signed-off-by: Sricharan R <sricharan@codeaurora.org>
>> ---
>> arch/arm/mm/dma-mapping.c | 8 ++++++++
>> arch/arm64/mm/dma-mapping.c | 7 +++++++
>> 2 files changed, 15 insertions(+)
>>
>> diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
>> index b9191f0..cbe22de 100644
>> --- a/arch/arm/mm/dma-mapping.c
>> +++ b/arch/arm/mm/dma-mapping.c
>> @@ -2289,11 +2289,19 @@ static bool arm_setup_iommu_dma_ops(struct device *dev, u64 dma_base, u64 size,
>> static void arm_teardown_iommu_dma_ops(struct device *dev)
>> {
>> struct dma_iommu_mapping *mapping = to_dma_iommu_mapping(dev);
>> + const struct iommu_ops *ops;
>>
>> if (!mapping)
>> return;
>>
>> __arm_iommu_detach_device(dev);
>> +
>> + if (dev->iommu_fwspec) {
>> + ops = dev->iommu_fwspec->ops;
>> + if (ops->remove_device)
>> + ops->remove_device(dev);
>> + }
>> +
>
>Yuck. It's a little unfortunate that we have to do this at all, but I
>see why. Still, it should be done in common code, not duplicated across
>arch code, not least for symmetry with where the matching add_device
>happened (although I think of_dma_deconfigure() would suffice, I'm not
>sure we really need to add an of_iommu_deconfigure() just for this).
>
So one way is its already called via a the BUS_NOTIFY_REMOVED_DEVICE
notifier in iommu_bus_notifier. I put it here, one for symmetry and
another thinking that the remove_device callback should be done
before the dma_ops is set to NULL. If thats not required then the existing
iommu_bus_notifier itself can do the cleanup. The corresponding
add_device in that notifier is dummy now, i will add a patch to remove
that. If not the whole thing, we can add of_iommu_deconfigure as well.
>It's also broken for IOMMU drivers which rely on the
>of_iommu_configure() mechanism but have not yet been converted to use
>iommu_fwspec (Exynos, MSM, etc.)
>
I did this, because fwspec was the right way to get ops in the future,
but yes its getting broken for those which are not converted,
will have to use dev->bus->iommu_ops in those cases. Will address this
while changing the above.
Regards,
Sricharan
^ permalink raw reply
* [PATCH V3 8/8] arm64: dma-mapping: Remove the notifier trick to handle early setting of dma_ops
From: Sricharan @ 2016-10-27 5:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e4643826-3aa8-1e34-79a8-9e1fcf0fcb69@arm.com>
Hi Robin,
>On 04/10/16 18:03, Sricharan R wrote:
>> With arch_setup_dma_ops now being called late during device's probe after the
>> device's iommu is probed, the notifier trick required to handle the early
>> setup of dma_ops before the iommu group gets created is not required.
>> So removing the notifier's here.
>
>Hooray!
>
>> Signed-off-by: Sricharan R <sricharan@codeaurora.org>
>> ---
>> arch/arm64/mm/dma-mapping.c | 100 ++------------------------------------------
>> 1 file changed, 3 insertions(+), 97 deletions(-)
>>
>> diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
>> index faf4b92..eb593af 100644
>> --- a/arch/arm64/mm/dma-mapping.c
>> +++ b/arch/arm64/mm/dma-mapping.c
>> @@ -799,24 +799,6 @@ static struct dma_map_ops iommu_dma_ops = {
>> .mapping_error = iommu_dma_mapping_error,
>> };
>>
>> -/*
>> - * TODO: Right now __iommu_setup_dma_ops() gets called too early to do
>> - * everything it needs to - the device is only partially created and the
>> - * IOMMU driver hasn't seen it yet, so it can't have a group. Thus we
>> - * need this delayed attachment dance. Once IOMMU probe ordering is sorted
>> - * to move the arch_setup_dma_ops() call later, all the notifier bits below
>> - * become unnecessary, and will go away.
>> - */
>> -struct iommu_dma_notifier_data {
>> - struct list_head list;
>> - struct device *dev;
>> - const struct iommu_ops *ops;
>> - u64 dma_base;
>> - u64 size;
>> -};
>> -static LIST_HEAD(iommu_dma_masters);
>> -static DEFINE_MUTEX(iommu_dma_notifier_lock);
>> -
>> static bool do_iommu_attach(struct device *dev, const struct iommu_ops *ops,
>> u64 dma_base, u64 size)
>
>This should go as well...
ok.
>
>> {
>> @@ -837,79 +819,9 @@ static bool do_iommu_attach(struct device *dev, const struct iommu_ops *ops,
>> return true;
>> }
>>
>> -static void queue_iommu_attach(struct device *dev, const struct iommu_ops *ops,
>> - u64 dma_base, u64 size)
>> -{
>> - struct iommu_dma_notifier_data *iommudata;
>> -
>> - iommudata = kzalloc(sizeof(*iommudata), GFP_KERNEL);
>> - if (!iommudata)
>> - return;
>> -
>> - iommudata->dev = dev;
>> - iommudata->ops = ops;
>> - iommudata->dma_base = dma_base;
>> - iommudata->size = size;
>> -
>> - mutex_lock(&iommu_dma_notifier_lock);
>> - list_add(&iommudata->list, &iommu_dma_masters);
>> - mutex_unlock(&iommu_dma_notifier_lock);
>> -}
>> -
>> -static int __iommu_attach_notifier(struct notifier_block *nb,
>> - unsigned long action, void *data)
>> -{
>> - struct iommu_dma_notifier_data *master, *tmp;
>> -
>> - if (action != BUS_NOTIFY_BIND_DRIVER)
>> - return 0;
>> -
>> - mutex_lock(&iommu_dma_notifier_lock);
>> - list_for_each_entry_safe(master, tmp, &iommu_dma_masters, list) {
>> - if (data == master->dev && do_iommu_attach(master->dev,
>> - master->ops, master->dma_base, master->size)) {
>> - list_del(&master->list);
>> - kfree(master);
>> - break;
>> - }
>> - }
>> - mutex_unlock(&iommu_dma_notifier_lock);
>> - return 0;
>> -}
>> -
>> -static int __init register_iommu_dma_ops_notifier(struct bus_type *bus)
>> -{
>> - struct notifier_block *nb = kzalloc(sizeof(*nb), GFP_KERNEL);
>> - int ret;
>> -
>> - if (!nb)
>> - return -ENOMEM;
>> -
>> - nb->notifier_call = __iommu_attach_notifier;
>> -
>> - ret = bus_register_notifier(bus, nb);
>> - if (ret) {
>> - pr_warn("Failed to register DMA domain notifier; IOMMU DMA ops unavailable on bus '%s'\n",
>> - bus->name);
>> - kfree(nb);
>> - }
>> - return ret;
>> -}
>> -
>> static int __init __iommu_dma_init(void)
>> {
>> - int ret;
>> -
>> - ret = iommu_dma_init();
>> - if (!ret)
>> - ret = register_iommu_dma_ops_notifier(&platform_bus_type);
>> - if (!ret)
>> - ret = register_iommu_dma_ops_notifier(&amba_bustype);
>> -#ifdef CONFIG_PCI
>> - if (!ret)
>> - ret = register_iommu_dma_ops_notifier(&pci_bus_type);
>> -#endif
>> - return ret;
>> + return iommu_dma_init();
>> }
>> arch_initcall(__iommu_dma_init);
>>
>> @@ -920,18 +832,12 @@ static void __iommu_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
>>
>> if (!ops)
>> return;
>> - /*
>> - * TODO: As a concession to the future, we're ready to handle being
>> - * called both early and late (i.e. after bus_add_device). Once all
>> - * the platform bus code is reworked to call us late and the notifier
>> - * junk above goes away, move the body of do_iommu_attach here.
>
>...per this commment. It has no need to be a separate function once this
>is the only call site (plus it has a misleadingly inaccurate name anyway).
ya, missed to remove that function as well. Will do it in the next.
Regards,
Sricharan
^ permalink raw reply
* [PATCH v2 1/8] drm/bridge: rgb-to-vga: Support an enable GPIO
From: Archit Taneja @ 2016-10-27 6:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v64=c5PFx+qJkfPeKYFQYLYoYfWgjg49O4Es5qVjuyf5gg@mail.gmail.com>
On 10/25/2016 02:29 PM, Chen-Yu Tsai wrote:
> On Tue, Oct 25, 2016 at 4:09 PM, Archit Taneja <architt@codeaurora.org> wrote:
>> Hi,
>>
>> On 10/20/2016 09:13 AM, Chen-Yu Tsai wrote:
>>>
>>> Some rgb-to-vga bridges have an enable GPIO, either directly tied to
>>> an enable pin on the bridge IC, or indirectly controlling a power
>>> switch.
>>>
>>> Add support for it.
>>
>>
>> Does the bridge on your platform have an active/passive DAC, or is it a
>> smarter encoder chip that is capable of doing more? If so, it might be
>> good to have a separate DT compatible string to it, like what's done
>> in the patch titled:
>>
>> drm: bridge: vga-dac: Add adi,adv7123 compatible string
>>
>> so that we can switch to a different driver later if needed.
>
> The chip is GM7123. It is not configurable. It just takes the LCD RGB/SYNC
> signals and converts them to analog. The only things you can change are
> putting it into sleep mode and tweaking the output drive strength by
Is sleep mode the thing that's controlled by this gpio?
> changing the external reference resistor. The latter would be a hardware
> design decision. I would say this qualifies as "dumb".
Yeah, I agree. I'd want feedback from Laurent too, since he had comments
on the usage of the original dumb-vga-dac driver.
>
> I revisited the board schematics, and the enable GPIO actually toggles
> an external LDO regulator. So this might be better modeled as a regulator
> supply?
If you model it as a regulator, how would you toggle the GPIO on your
platform?
Looking at the chip pin out, there is a 3.3V VDD supply needed for the
chip, so it would be good to have an optional 'power' regulator supply
anyway.
Archit
>
>
> Thanks
> ChenYu
>
>>
>> Thanks,
>> Archit
>>
>>
>>>
>>> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
>>> ---
>>> .../bindings/display/bridge/dumb-vga-dac.txt | 2 ++
>>> drivers/gpu/drm/bridge/dumb-vga-dac.c | 28
>>> ++++++++++++++++++++++
>>> 2 files changed, 30 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..d3484822bf77 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:
>>> +- enable-gpios: GPIO pin to enable or disable the bridge
>>>
>>> Example
>>> -------
>>> diff --git a/drivers/gpu/drm/bridge/dumb-vga-dac.c
>>> b/drivers/gpu/drm/bridge/dumb-vga-dac.c
>>> index afec232185a7..b487e5e9b56d 100644
>>> --- a/drivers/gpu/drm/bridge/dumb-vga-dac.c
>>> +++ b/drivers/gpu/drm/bridge/dumb-vga-dac.c
>>> @@ -10,6 +10,7 @@
>>> * the License, or (at your option) any later version.
>>> */
>>>
>>> +#include <linux/gpio/consumer.h>
>>> #include <linux/module.h>
>>> #include <linux/of_graph.h>
>>>
>>> @@ -23,6 +24,7 @@ struct dumb_vga {
>>> struct drm_connector connector;
>>>
>>> struct i2c_adapter *ddc;
>>> + struct gpio_desc *enable_gpio;
>>> };
>>>
>>> static inline struct dumb_vga *
>>> @@ -124,8 +126,26 @@ 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);
>>> +
>>> + if (vga->enable_gpio)
>>> + gpiod_set_value_cansleep(vga->enable_gpio, 1);
>>> +}
>>> +
>>> +static void dumb_vga_disable(struct drm_bridge *bridge)
>>> +{
>>> + struct dumb_vga *vga = drm_bridge_to_dumb_vga(bridge);
>>> +
>>> + if (vga->enable_gpio)
>>> + gpiod_set_value_cansleep(vga->enable_gpio, 0);
>>> +}
>>> +
>>> 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 +189,14 @@ static int dumb_vga_probe(struct platform_device
>>> *pdev)
>>> return -ENOMEM;
>>> platform_set_drvdata(pdev, vga);
>>>
>>> + vga->enable_gpio = devm_gpiod_get_optional(&pdev->dev, "enable",
>>> + GPIOD_OUT_LOW);
>>> + if (IS_ERR(vga->enable_gpio)) {
>>> + ret = PTR_ERR(vga->enable_gpio);
>>> + dev_err(&pdev->dev, "failed to request GPIO: %d\n", ret);
>>> + return ret;
>>> + }
>>> +
>>> vga->ddc = dumb_vga_retrieve_ddc(&pdev->dev);
>>> if (IS_ERR(vga->ddc)) {
>>> if (PTR_ERR(vga->ddc) == -ENODEV) {
>>>
>>
>> --
>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
>> a Linux Foundation Collaborative Project
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v2 1/8] drm/bridge: rgb-to-vga: Support an enable GPIO
From: Chen-Yu Tsai @ 2016-10-27 6:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87ca071d-c396-25b3-aff4-c838c9003f94@codeaurora.org>
On Thu, Oct 27, 2016 at 2:40 PM, Archit Taneja <architt@codeaurora.org> wrote:
>
>
> On 10/25/2016 02:29 PM, Chen-Yu Tsai wrote:
>>
>> On Tue, Oct 25, 2016 at 4:09 PM, Archit Taneja <architt@codeaurora.org>
>> wrote:
>>>
>>> Hi,
>>>
>>> On 10/20/2016 09:13 AM, Chen-Yu Tsai wrote:
>>>>
>>>>
>>>> Some rgb-to-vga bridges have an enable GPIO, either directly tied to
>>>> an enable pin on the bridge IC, or indirectly controlling a power
>>>> switch.
>>>>
>>>> Add support for it.
>>>
>>>
>>>
>>> Does the bridge on your platform have an active/passive DAC, or is it a
>>> smarter encoder chip that is capable of doing more? If so, it might be
>>> good to have a separate DT compatible string to it, like what's done
>>> in the patch titled:
>>>
>>> drm: bridge: vga-dac: Add adi,adv7123 compatible string
>>>
>>> so that we can switch to a different driver later if needed.
>>
>>
>> The chip is GM7123. It is not configurable. It just takes the LCD RGB/SYNC
>> signals and converts them to analog. The only things you can change are
>> putting it into sleep mode and tweaking the output drive strength by
>
>
> Is sleep mode the thing that's controlled by this gpio?
Not on this particular board. The gpio controls the external LDO that
supplies 3.3V to VDD.
>
>> changing the external reference resistor. The latter would be a hardware
>> design decision. I would say this qualifies as "dumb".
>
>
> Yeah, I agree. I'd want feedback from Laurent too, since he had comments
> on the usage of the original dumb-vga-dac driver.
>
>>
>> I revisited the board schematics, and the enable GPIO actually toggles
>> an external LDO regulator. So this might be better modeled as a regulator
>> supply?
>
>
> If you model it as a regulator, how would you toggle the GPIO on your
> platform?
>
> Looking at the chip pin out, there is a 3.3V VDD supply needed for the
> chip, so it would be good to have an optional 'power' regulator supply
> anyway.
Yes, that it what I plan to do. I'll drop the enable-gpios property,
and add a power-supply property for the regulator.
Regards
ChenYu
>
> Archit
>
>
>>
>>
>> Thanks
>> ChenYu
>>
>>>
>>> Thanks,
>>> Archit
>>>
>>>
>>>>
>>>> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
>>>> ---
>>>> .../bindings/display/bridge/dumb-vga-dac.txt | 2 ++
>>>> drivers/gpu/drm/bridge/dumb-vga-dac.c | 28
>>>> ++++++++++++++++++++++
>>>> 2 files changed, 30 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..d3484822bf77 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:
>>>> +- enable-gpios: GPIO pin to enable or disable the bridge
>>>>
>>>> Example
>>>> -------
>>>> diff --git a/drivers/gpu/drm/bridge/dumb-vga-dac.c
>>>> b/drivers/gpu/drm/bridge/dumb-vga-dac.c
>>>> index afec232185a7..b487e5e9b56d 100644
>>>> --- a/drivers/gpu/drm/bridge/dumb-vga-dac.c
>>>> +++ b/drivers/gpu/drm/bridge/dumb-vga-dac.c
>>>> @@ -10,6 +10,7 @@
>>>> * the License, or (at your option) any later version.
>>>> */
>>>>
>>>> +#include <linux/gpio/consumer.h>
>>>> #include <linux/module.h>
>>>> #include <linux/of_graph.h>
>>>>
>>>> @@ -23,6 +24,7 @@ struct dumb_vga {
>>>> struct drm_connector connector;
>>>>
>>>> struct i2c_adapter *ddc;
>>>> + struct gpio_desc *enable_gpio;
>>>> };
>>>>
>>>> static inline struct dumb_vga *
>>>> @@ -124,8 +126,26 @@ 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);
>>>> +
>>>> + if (vga->enable_gpio)
>>>> + gpiod_set_value_cansleep(vga->enable_gpio, 1);
>>>> +}
>>>> +
>>>> +static void dumb_vga_disable(struct drm_bridge *bridge)
>>>> +{
>>>> + struct dumb_vga *vga = drm_bridge_to_dumb_vga(bridge);
>>>> +
>>>> + if (vga->enable_gpio)
>>>> + gpiod_set_value_cansleep(vga->enable_gpio, 0);
>>>> +}
>>>> +
>>>> 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 +189,14 @@ static int dumb_vga_probe(struct platform_device
>>>> *pdev)
>>>> return -ENOMEM;
>>>> platform_set_drvdata(pdev, vga);
>>>>
>>>> + vga->enable_gpio = devm_gpiod_get_optional(&pdev->dev, "enable",
>>>> + GPIOD_OUT_LOW);
>>>> + if (IS_ERR(vga->enable_gpio)) {
>>>> + ret = PTR_ERR(vga->enable_gpio);
>>>> + dev_err(&pdev->dev, "failed to request GPIO: %d\n",
>>>> ret);
>>>> + return ret;
>>>> + }
>>>> +
>>>> vga->ddc = dumb_vga_retrieve_ddc(&pdev->dev);
>>>> if (IS_ERR(vga->ddc)) {
>>>> if (PTR_ERR(vga->ddc) == -ENODEV) {
>>>>
>>>
>>> --
>>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
>>> a Linux Foundation Collaborative Project
>
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH] ARM: shmobile: select errata 798181 for SoCs with CA15 cores
From: Simon Horman @ 2016-10-27 7:00 UTC (permalink / raw)
To: linux-arm-kernel
Select ARM errata 798181 on SoCs cores affected CA15 cores.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/mach-shmobile/Kconfig | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index c48be1d332ed..6fbd9b7d2d67 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -60,6 +60,7 @@ config ARCH_R7S72100
config ARCH_R8A73A4
bool "R-Mobile APE6 (R8A73A40)"
select ARCH_RMOBILE
+ select ARM_ERRATA_798181 if SMP
select RENESAS_IRQC
config ARCH_R8A7740
@@ -70,6 +71,7 @@ config ARCH_R8A7740
config ARCH_R8A7743
bool "RZ/G1M (R8A77430)"
select ARCH_RCAR_GEN2
+ select ARM_ERRATA_798181 if SMP
config ARCH_R8A7778
bool "R-Car M1A (R8A77781)"
@@ -82,20 +84,24 @@ config ARCH_R8A7779
config ARCH_R8A7790
bool "R-Car H2 (R8A77900)"
select ARCH_RCAR_GEN2
+ select ARM_ERRATA_798181 if SMP
select I2C
config ARCH_R8A7791
bool "R-Car M2-W (R8A77910)"
select ARCH_RCAR_GEN2
+ select ARM_ERRATA_798181 if SMP
select I2C
config ARCH_R8A7792
bool "R-Car V2H (R8A77920)"
select ARCH_RCAR_GEN2
+ select ARM_ERRATA_798181 if SMP
config ARCH_R8A7793
bool "R-Car M2-N (R8A7793)"
select ARCH_RCAR_GEN2
+ select ARM_ERRATA_798181 if SMP
select I2C
config ARCH_R8A7794
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH v4 0/7] Add R8A7743/SK-RZG1M board support
From: Simon Horman @ 2016-10-27 7:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdWQegsEf_C=UGXpQiEAX0YQqy335teuvCZxBY6C=7QozA@mail.gmail.com>
On Wed, Oct 26, 2016 at 03:27:14PM +0200, Geert Uytterhoeven wrote:
> On Wed, Oct 26, 2016 at 3:23 PM, Sergei Shtylyov
> <sergei.shtylyov@cogentembedded.com> wrote:
> > On 10/26/2016 03:08 PM, Geert Uytterhoeven wrote:
> >>> Here's the set of 8 patches against Simon Horman's 'renesas.git'
> >>> repo's
> >>> 'renesas-devel-20161021-v4.9-rc1' tag. I'm adding the device tree support
> >>> for
> >>> the R8A7743-based SK-RZG1M board. The SoC is close to R8A7791 and the
> >>> board
> >>> seems identical to the R8A7791/Porter board. The device tree patches
> >>> depend on
> >>> the R8A7743 CPG/MSSR driver series just posted in order to compile and
> >>> work.
> >>
> >>
> >> They depend only on "[PATCH v3 1/2] ARM: shmobile: r8a7743: add CPG clock
> >> index macros" of that series, right?
> >>
> >> "[PATCH v3 2/2] clk: renesas: cpg-mssr: add R8A7743 support" is not
> >> needed,
> >
> > How would "clocks" props _work_ without this patch?
>
> Sorry, I was focusing too much on "compile"...
>
> Got my coke, switching brain to overdrive mode...
As we are talking about adding support for a new SoC I would be happy
to queue up code in my tree that compiles under the assumption that
in v4.10 the bits to make it run will appear in other branches.
^ permalink raw reply
* [PATCHv2] ARM: dts: socfpga: Enable QSPI on the Cyclone5 sockit
From: Steffen Trumtrar @ 2016-10-27 7:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477505112-26079-1-git-send-email-dinguyen@opensource.altera.com>
On Wed, Oct 26, 2016 at 01:05:12PM -0500, dinguyen at opensource.altera.com wrote:
> From: Dinh Nguyen <dinguyen@opensource.altera.com>
>
> Enable the QSPI node and add the flash chip.
>
> Signed-off-by: Dinh Nguyen <dinguyen@opensource.altera.com>
> ---
> v2: Remove partition entries for the SoCKIT
> ---
> arch/arm/boot/dts/socfpga_cyclone5_sockit.dts | 21 +++++++++++++++++++++
> 1 file changed, 21 insertions(+)
>
> diff --git a/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts b/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts
> index 02e22f5..2ce6736 100644
> --- a/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts
> +++ b/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts
> @@ -175,6 +175,27 @@
> status = "okay";
> };
>
> +&qspi {
> + status = "okay";
> +
> + flash: flash at 0 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "n25q256a";
Did you test if this works correctly? According to my datasheet (Rev. C)
the HPS qspi is a n25q00. The n25q256a is the other one.
Regards,
Steffen
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [PATCH] ARM: shmobile: select errata 798181 for SoCs with CA15 cores
From: Geert Uytterhoeven @ 2016-10-27 7:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477551606-6903-1-git-send-email-horms+renesas@verge.net.au>
On Thu, Oct 27, 2016 at 9:00 AM, Simon Horman
<horms+renesas@verge.net.au> wrote:
> Select ARM errata 798181 on SoCs cores affected CA15 cores.
... cores with ...
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH] arm64: defconfig: Enable DRM DU and V4L2 FCP + VSP modules
From: Simon Horman @ 2016-10-27 7:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026052422.17283.57864.sendpatchset@little-apple>
On Wed, Oct 26, 2016 at 02:24:22PM +0900, Magnus Damm wrote:
> From: Magnus Damm <damm+renesas@opensource.se>
>
> Extend the ARM64 defconfig to enable the DU DRM device as module
> together with required dependencies of V4L2 FCP and VSP modules.
>
> This enables VGA output on the r8a7795 Salvator-X board.
>
> Signed-off-by: Magnus Damm <damm+renesas@opensource.se>
Thanks, I have queued this up.
^ permalink raw reply
* [PATCH] arm64: defconfig: Enable DRM DU and V4L2 FCP + VSP modules
From: Simon Horman @ 2016-10-27 7:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161027070801.GB7706@verge.net.au>
On Thu, Oct 27, 2016 at 09:08:01AM +0200, Simon Horman wrote:
> On Wed, Oct 26, 2016 at 02:24:22PM +0900, Magnus Damm wrote:
> > From: Magnus Damm <damm+renesas@opensource.se>
> >
> > Extend the ARM64 defconfig to enable the DU DRM device as module
> > together with required dependencies of V4L2 FCP and VSP modules.
> >
> > This enables VGA output on the r8a7795 Salvator-X board.
> >
> > Signed-off-by: Magnus Damm <damm+renesas@opensource.se>
>
> Thanks, I have queued this up.
Given discussion elsewhere on enabling DU I am holding off on this for a
little; it is not queued up for now.
^ permalink raw reply
* [PATCH 1/2] mm/memblock: prepare a capability to support memblock near alloc
From: Michal Hocko @ 2016-10-27 7:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <58116954.8080908@huawei.com>
On Thu 27-10-16 10:41:24, Leizhen (ThunderTown) wrote:
>
>
> On 2016/10/26 17:31, Michal Hocko wrote:
> > On Wed 26-10-16 11:10:44, Leizhen (ThunderTown) wrote:
> >>
> >>
> >> On 2016/10/25 21:23, Michal Hocko wrote:
> >>> On Tue 25-10-16 10:59:17, Zhen Lei wrote:
> >>>> If HAVE_MEMORYLESS_NODES is selected, and some memoryless numa nodes are
> >>>> actually exist. The percpu variable areas and numa control blocks of that
> >>>> memoryless numa nodes need to be allocated from the nearest available
> >>>> node to improve performance.
> >>>>
> >>>> Although memblock_alloc_try_nid and memblock_virt_alloc_try_nid try the
> >>>> specified nid at the first time, but if that allocation failed it will
> >>>> directly drop to use NUMA_NO_NODE. This mean any nodes maybe possible at
> >>>> the second time.
> >>>>
> >>>> To compatible the above old scene, I use a marco node_distance_ready to
> >>>> control it. By default, the marco node_distance_ready is not defined in
> >>>> any platforms, the above mentioned functions will work as normal as
> >>>> before. Otherwise, they will try the nearest node first.
> >>>
> >>> I am sorry but it is absolutely unclear to me _what_ is the motivation
> >>> of the patch. Is this a performance optimization, correctness issue or
> >>> something else? Could you please restate what is the problem, why do you
> >>> think it has to be fixed at memblock layer and describe what the actual
> >>> fix is please?
> >>
> >> This is a performance optimization.
> >
> > Do you have any numbers to back the improvements?
>
> I have not collected any performance data, but at least in theory,
> it's beneficial and harmless, except make code looks a bit
> urly.
The whole memoryless area is cluttered with hacks because everybody just
adds pieces here and there to make his particular usecase work IMHO.
Adding more on top for performance reasons which are even not measured
to prove a clear win is a no go. Please step back try to think how this
could be done with an existing infrastructure we have (some cleanups
while doing that would be hugely appreciated) and if that is not
possible then explain why and why it is not feasible to fix that before
you start adding a new API.
Thanks!
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* [PATCH] ARM: shmobile: select errata 798181 for SoCs with CA15 cores
From: Magnus Damm @ 2016-10-27 7:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477551606-6903-1-git-send-email-horms+renesas@verge.net.au>
Hi Simon,
On Thu, Oct 27, 2016 at 4:00 PM, Simon Horman
<horms+renesas@verge.net.au> wrote:
> Select ARM errata 798181 on SoCs cores affected CA15 cores.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
> ---
> arch/arm/mach-shmobile/Kconfig | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
> index c48be1d332ed..6fbd9b7d2d67 100644
> --- a/arch/arm/mach-shmobile/Kconfig
> +++ b/arch/arm/mach-shmobile/Kconfig
> @@ -60,6 +60,7 @@ config ARCH_R7S72100
> config ARCH_R8A73A4
> bool "R-Mobile APE6 (R8A73A40)"
> select ARCH_RMOBILE
> + select ARM_ERRATA_798181 if SMP
> select RENESAS_IRQC
>
> config ARCH_R8A7740
> @@ -70,6 +71,7 @@ config ARCH_R8A7740
> config ARCH_R8A7743
> bool "RZ/G1M (R8A77430)"
> select ARCH_RCAR_GEN2
> + select ARM_ERRATA_798181 if SMP
>
> config ARCH_R8A7778
> bool "R-Car M1A (R8A77781)"
> @@ -82,20 +84,24 @@ config ARCH_R8A7779
> config ARCH_R8A7790
> bool "R-Car H2 (R8A77900)"
> select ARCH_RCAR_GEN2
> + select ARM_ERRATA_798181 if SMP
> select I2C
Thanks for your help.
I'm probably misunderstanding what this patch does and how the errata
effects the system, but the commit message says CA15 cores. The above
R-Car Gen1 and r8a7740 SoCs are not using CA15 - instead they use CA9.
Not sure if the errata still applies though.
So either the commit message or the list of the SoCs need to be updated.
Thanks,
/ magnus
^ permalink raw reply
* [PATCH] Revert "gpio/mvebu: convert to use irq_domain_add_simple()"
From: Gregory CLEMENT @ 2016-10-27 7:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdatYim3=tKeO-E1GazB7RV9XPdE-EBQs+FW+DrryATzRA@mail.gmail.com>
Hi Linus,
On lun., oct. 24 2016, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Wed, Oct 19, 2016 at 11:03 PM, Jason Gunthorpe
> <jgunthorpe@obsidianresearch.com> wrote:
>
>> From 7566f05ac445b652ba7607cc1899fed10fea1c76 Mon Sep 17 00:00:00 2001
>> From: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
>> Date: Wed, 19 Oct 2016 14:57:45 -0600
>> Subject: [PATCH] gpio/mvebu: Use irq_domain_add_linear
>>
>> This fixes the irq allocation in this driver to not print:
>> irq: Cannot allocate irq_descs @ IRQ34, assuming pre-allocated
>> irq: Cannot allocate irq_descs @ IRQ66, assuming pre-allocated
>>
>> Which happens because the driver already called irq_alloc_descs()
>> and so the change to use irq_domain_add_simple resulted in calling
>> irq_alloc_descs() twice.
>>
>> Modernize the irq allocation in this driver to use the
>> irq_domain_add_linear flow directly and eliminate the use of
>> irq_domain_add_simple/legacy
>>
>> Fixes: ce931f571b6d ("gpio/mvebu: convert to use irq_domain_add_simple()")
>> Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
>
> So can I just apply this?
> Gregory?
For me it's OK.
Gregory
>
> Yours,
> Linus Walleij
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ 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