* [PATCH v6 2/9] drm/fb-cma-helper: Add drm_fb_cma_get_gem_addr()
From: Yannick Fertre @ 2017-04-14 8:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492157455-2283-1-git-send-email-yannick.fertre@st.com>
Add function drm_fb_cma_get_gem_addr() which return the physical address
of framebuffer (1st pixel). This function will usually be called by plane
callback (atomic_update).
Signed-off-by: Yannick Fertre <yannick.fertre@st.com>
---
drivers/gpu/drm/drm_fb_cma_helper.c | 27 +++++++++++++++++++++++++++
include/drm/drm_fb_cma_helper.h | 4 ++++
2 files changed, 31 insertions(+)
diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c b/drivers/gpu/drm/drm_fb_cma_helper.c
index 50abd1f..d2b77b0 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -260,6 +260,33 @@ struct drm_gem_cma_object *drm_fb_cma_get_gem_obj(struct drm_framebuffer *fb,
EXPORT_SYMBOL_GPL(drm_fb_cma_get_gem_obj);
/**
+ * drm_fb_cma_get_gem_addr() - Get physical address for framebuffer
+ * @fb: The framebuffer
+ * @state: Which state of drm plane
+ * @plane: Which plane
+ * Return the CMA GEM address for given framebuffer.
+ *
+ * This function will usually be called from the PLANE callback functions.
+ */
+dma_addr_t drm_fb_cma_get_gem_addr(struct drm_framebuffer *fb,
+ struct drm_plane_state *state,
+ unsigned int plane)
+{
+ struct drm_fb_cma *fb_cma = to_fb_cma(fb);
+ dma_addr_t paddr;
+
+ if (plane >= 4)
+ return 0;
+
+ paddr = fb_cma->obj[plane]->paddr + fb->offsets[plane];
+ paddr += fb->format->cpp[plane] * (state->src_x >> 16);
+ paddr += fb->pitches[plane] * (state->src_y >> 16);
+
+ return paddr;
+}
+EXPORT_SYMBOL_GPL(drm_fb_cma_get_gem_addr);
+
+/**
* drm_fb_cma_prepare_fb() - Prepare CMA framebuffer
* @plane: Which plane
* @state: Plane state attach fence to
diff --git a/include/drm/drm_fb_cma_helper.h b/include/drm/drm_fb_cma_helper.h
index a5ecc0a..199a63f 100644
--- a/include/drm/drm_fb_cma_helper.h
+++ b/include/drm/drm_fb_cma_helper.h
@@ -41,6 +41,10 @@ struct drm_framebuffer *drm_fb_cma_create(struct drm_device *dev,
struct drm_gem_cma_object *drm_fb_cma_get_gem_obj(struct drm_framebuffer *fb,
unsigned int plane);
+dma_addr_t drm_fb_cma_get_gem_addr(struct drm_framebuffer *fb,
+ struct drm_plane_state *state,
+ unsigned int plane);
+
int drm_fb_cma_prepare_fb(struct drm_plane *plane,
struct drm_plane_state *state);
--
1.9.1
^ permalink raw reply related
* [PATCH v6 1/9] drm/cma: Update DEFINE_DRM_GEM_CMA_FOPS to add get_unmapped_area
From: Yannick Fertre @ 2017-04-14 8:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492157455-2283-1-git-send-email-yannick.fertre@st.com>
Missing field get_unmapped_area which is necessary with device without MMU
Signed-off-by: Yannick Fertre <yannick.fertre@st.com>
---
include/drm/drm_gem_cma_helper.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/drm/drm_gem_cma_helper.h b/include/drm/drm_gem_cma_helper.h
index f962d33..7320b14 100644
--- a/include/drm/drm_gem_cma_helper.h
+++ b/include/drm/drm_gem_cma_helper.h
@@ -50,6 +50,7 @@ struct drm_gem_cma_object {
.read = drm_read,\
.llseek = noop_llseek,\
.mmap = drm_gem_cma_mmap,\
+ .get_unmapped_area = drm_gem_cma_get_unmapped_area,\
}
/* free GEM object */
--
1.9.1
^ permalink raw reply related
* [PATCH v6 0/9] STM32 LCD-TFT display controller
From: Yannick Fertre @ 2017-04-14 8:10 UTC (permalink / raw)
To: linux-arm-kernel
Version 6:
- Add patch on MAINTAINERS file to add Philippe Cornu & myself.
- Update driver stm to remove uneccessary functions called.
Version 5:
- Add patch on drm_gem_cma_helper.h to udapte DEFINE_DRM_GEM_CMA_FOPS.
- Add patch on drm_fb_cma_helper to add new function to get physical address.
- Solve some typos & update ltdc driver including last remarks of Eric Anholt
- Update commits of config patches.
Version 4:
- Update "ampire,am-480272h3tmqw-t01h.txt" binding with more details on gpios.
- Update ltdc.c. Remove regmap, solve some typo & warnings.
Version 3:
- Update "st,stm32-ltdc.txt" binding.
- Add a commit to "ARM: configs: stm32: ADD LDTC support" patch.
Version 2:
- Rename driver directory from st to stm.
- Rename compatiblity from st,ltdc to st,stm32-ltdc.
- Remove compatibility st,display-subsystem.
- Rename driver from st-drm to stm-drm.
- Rework probe sequence & remove display-subsystem part.
- I keep clock name which is necessary for devm_regmap_init_mmio_clk call.
Version 1:
- Initial commit
The purpose of this set of patches is to add a new driver for stm32f429.
This driver was developed and tested on evaluation board stm32429i.
Stm32f4 is a MCU platform which don't have MMU so the last patches developed
by Benjamin Gaignard regarding "DRM: allow to use mmuless devices"
are necessary.
The board stm429i embeds a Ampire AM-480272H3TMQW-T01H screen.
A new simple panel am-480272h3tmqw-t01h have been added to support it.
Yannick Fertre (9):
drm/cma: Update DEFINE_DRM_GEM_CMA_FOPS to add get_unmapped_area
drm/fb-cma-helper: Add drm_fb_cma_get_gem_addr()
dt-bindings: display: Add STM32 LTDC driver
drm/stm: Add STM32 LTDC driver
[media] add maintainers for DRM STM driver
ARM: dts: stm32: Add ltdc support on stm32f429 MCU
ARM: dts: stm32: Enable ltdc & simple panel on stm32f429-Eval board
ARM: configs: stm32: Add DRM support in STM32 defconfig
ARM: configs: stm32: Add simple panel support in STM32 defconfig
.../devicetree/bindings/display/st,stm32-ltdc.txt | 36 +
MAINTAINERS | 9 +
arch/arm/boot/dts/stm32429i-eval.dts | 59 +
arch/arm/boot/dts/stm32f429.dtsi | 12 +-
arch/arm/configs/stm32_defconfig | 3 +
drivers/gpu/drm/Kconfig | 2 +
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/drm_fb_cma_helper.c | 27 +
drivers/gpu/drm/stm/Kconfig | 16 +
drivers/gpu/drm/stm/Makefile | 7 +
drivers/gpu/drm/stm/drv.c | 221 ++++
drivers/gpu/drm/stm/ltdc.c | 1161 ++++++++++++++++++++
drivers/gpu/drm/stm/ltdc.h | 40 +
include/drm/drm_fb_cma_helper.h | 4 +
include/drm/drm_gem_cma_helper.h | 1 +
15 files changed, 1598 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/display/st,stm32-ltdc.txt
create mode 100644 drivers/gpu/drm/stm/Kconfig
create mode 100644 drivers/gpu/drm/stm/Makefile
create mode 100644 drivers/gpu/drm/stm/drv.c
create mode 100644 drivers/gpu/drm/stm/ltdc.c
create mode 100644 drivers/gpu/drm/stm/ltdc.h
--
1.9.1
^ permalink raw reply
* [GIT PULL v2] ARM: at91: DT for 4.12
From: Alexandre Belloni @ 2017-04-14 8:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170410163557.qocx3bvz5s5gcnkw@piout.net>
Arnd, Olof,
As you didn't seem to have taken the previous version, I've folded a
late minute fix in Peter's patch. IF that is not OK, I'll sent the fix
later.
The following changes since commit c1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201:
Linux 4.11-rc1 (2017-03-05 12:59:56 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git tags/at91-ab-4.12-dt
for you to fetch changes up to d3df1ec06353e51fc44563d2e7e18d42811af290:
ARM: dts: at91: sama5d3_xplained: not all ADC channels are available (2017-04-14 09:38:51 +0200)
----------------------------------------------------------------
DT for 4.12:
- Add SFRBU on sama5d2
- DT improvements for sama5d2_xplained, sama5d3_xplained, at91sam9x5ek and
Axentia TSE-850
----------------------------------------------------------------
Alexandre Belloni (2):
ARM: dts: at91: sama5d2: add sfrbu
ARM: dts: at91: sama5d2_xplained: enable RTC wakeup
Boris Brezillon (1):
ARM: dts: at91: Fix matrix compatible
Cristian Birsan (1):
ARM: dts: at91: Disable SPI on at91sam9x5ek to allow MCI1 to work.
Ludovic Desroches (2):
ARM: dts: at91: sama5d3_xplained: fix ADC vref
ARM: dts: at91: sama5d3_xplained: not all ADC channels are available
Peter Rosin (1):
ARM: dts: at91: add envelope detector mux to the Axentia TSE-850
.../devicetree/bindings/arm/atmel-at91.txt | 3 ++-
arch/arm/boot/dts/at91-sama5d2_xplained.dts | 1 +
arch/arm/boot/dts/at91-sama5d3_xplained.dts | 5 ++--
arch/arm/boot/dts/at91-tse850-3.dts | 29 +++++++++++++++++++++-
arch/arm/boot/dts/at91sam9261.dtsi | 2 +-
arch/arm/boot/dts/at91sam9x5ek.dtsi | 2 +-
arch/arm/boot/dts/sama5d2.dtsi | 5 ++++
7 files changed, 40 insertions(+), 7 deletions(-)
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH] arm: dma: fix sharing of coherent DMA memory without struct page
From: Marek Szyprowski @ 2017-04-14 7:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3afd77e5-2a98-42fd-b5c9-cbf4c32baa4f@osg.samsung.com>
Hi Shuah,
On 2017-04-11 00:50, Shuah Khan wrote:
> On 04/06/2017 06:01 AM, Marek Szyprowski wrote:
>> On 2017-04-05 18:02, Shuah Khan wrote:
>>> When coherent DMA memory without struct page is shared, importer
>>> fails to find the page and runs into kernel page fault when it
>>> tries to dmabuf_ops_attach/map_sg/map_page the invalid page found
>>> in the sg_table. Please see www.spinics.net/lists/stable/msg164204.html
>>> for more information on this problem.
>>>
>>> This solution allows coherent DMA memory without struct page to be
>>> shared by providing a way for the exporter to tag the DMA buffer as
>>> a special buffer without struct page association and passing the
>>> information in sg_table to the importer. This information is used
>>> in attach/map_sg to avoid cleaning D-cache and mapping.
>>>
>>> The details of the change are:
>>>
>>> Framework:
>>> - Add a new dma_attrs field to struct scatterlist.
>>> - Add a new DMA_ATTR_DEV_COHERENT_NOPAGE attribute to clearly identify
>>> Coherent memory without struct page.
>>> - Add a new dma_check_dev_coherent() interface to check if memory is
>>> the device coherent area. There is no way to tell where the memory
>>> returned by dma_alloc_attrs() came from.
>>>
>>> Exporter logic:
>>> - Add logic to vb2_dc_alloc() to call dma_check_dev_coherent() and set
>>> DMA_ATTR_DEV_COHERENT_NOPAGE based the results of the check. This is
>>> done in the exporter context.
>>> - Add logic to arm_dma_get_sgtable() to identify memory without struct
>>> page using DMA_ATTR_DEV_COHERENT_NOPAGE attribute. If this attr is
>>> set, arm_dma_get_sgtable() will set page as the cpu_addr and update
>>> dma_address and dma_attrs fields in struct scatterlist for this sgl.
>>> This is done in exporter context when buffer is exported. With this
>>> Note: This change is made on top of Russell King's patch that added
>>> !pfn_valid(pfn) check to arm_dma_get_sgtable() to error out on invalid
>>> pages. Coherent memory without struct page will trigger this error.
>>>
>>> Importer logic:
>>> - Add logic to vb2_dc_dmabuf_ops_attach() to identify memory without
>>> struct page using DMA_ATTR_DEV_COHERENT_NOPAGE attribute when it copies
>>> the sg_table from the exporter. It will copy dma_attrs and dma_address
>>> fields. With this logic, dmabuf_ops_attach will no longer trip on an
>>> invalid page.
>>> - Add logic to arm_dma_map_sg() to avoid mapping the page when sg_table
>>> has DMA_ATTR_DEV_COHERENT_NOPAGE buffer.
>>> - Add logic to arm_dma_unmap_sg() to do nothing for sg entries with
>>> DMA_ATTR_DEV_COHERENT_NOPAGE attribute.
>>>
>>> Without this change the following use-case that runs into kernel
>>> pagefault when importer tries to attach the exported buffer.
>>>
>>> With this change it works: (what a relief after watching pagefaults for
>>> weeks!!)
>>>
>>> gst-launch-1.0 filesrc location=~/GH3_MOV_HD.mp4 ! qtdemux ! h264parse ! v4l2video4dec capture-io-mode=dmabuf ! v4l2video7convert output-io-mode=dmabuf-import ! kmssink force-modesetting=true
>>>
>>> I am sending RFC patch to get feedback on the approach and see if I missed
>>> anything.
>> Frankly, once You decided to hack around dma-buf and issues with coherent,
>> carved out memory, it might be a bit better to find the ultimate solution
>> instead of the another hack. Please note that it will still not allow to
>> share a buffer allocated from carved-out memory and a device, which is
>> behind IOMMU.
> With your patch s5p-mfc patch series does address the problem for this
> use-case for 4.12 onwards. However I am still concerned about prior
> release and this pagefault is bad.
Right. It should simply fail with error code instead of pagefault.
> Invalid page test partially solves the problem. Would it helpful to
> at least prevent the pagfault with a definitive test. Please see my
> response to Russell. Let me know your thoughts on that.
>
>> I thought a bit about this and the current shape of dma-buf code.
>>
>> IMHO the proper way of solving all those issues would be to replace
>> dma-buf internal representation of the memory from struct scatter_list
>> to pfn array. This would really solve the problem of buffers which
>> cannot be properly represented by scatter lists/struct pages and would
>> even allow sharing buffers between all kinds of devices. Scatter-lists
>> are also quite over-engineered structures to represent a single buffer
>> (pfn array is a bit more compact representation). Also there is a lots
>> of buggy code which use scatter-list in a bit creative way (like
>> assuming that each page maps to a single scatter list entry for
>> example). The only missing piece, required for such change would be
>> extending DMA-mapping with dma_map_pfn() interface.
> I agree with you on scatterlists being clumsy. Changing over to pfn array
> could simplify things. I am exploring a slightly different option that
> might not require too many changes. I will respond with concrete ideas
> later on this week.
It looks that a similar issue is being worked on, see the following thread:
https://lkml.org/lkml/2017/4/13/710
>> This would be however quite large task, especially taking into account
>> all current users of DMA-buf framework...
> Yeah it will be a large task.
Maybe once scatterlist are switched to pfns, changing dmabuf internal
memory representation to pfn array might be much easier.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* [PATCH 4/4] net: macb: Add macb_ptp to compilation chain
From: Richard Cochran @ 2017-04-14 7:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492090798-16253-1-git-send-email-rafalo@cadence.com>
On Thu, Apr 13, 2017 at 02:39:58PM +0100, Rafal Ozieblo wrote:
> Add macb_ptp.c to Makefile.
> In case that macb is compiled as a module, it has been renamed to
> cadence-macb.ko to avoid naming confusion in Makefile.
Renaming modules will break user's modpobe scripts.
Why not keep macb.ko as the build product and rename macb.c to
macb_main.c instead?
Thanks,
Richard
^ permalink raw reply
* [PATCH 1/4] net: macb: Add support for PTP timestamps in DMA descriptors
From: Richard Cochran @ 2017-04-14 7:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492090439-11793-1-git-send-email-rafalo@cadence.com>
On Thu, Apr 13, 2017 at 02:33:59PM +0100, Rafal Ozieblo wrote:
> @@ -1921,9 +1972,13 @@ static void macb_configure_dma(struct macb *bp)
> dmacfg &= ~GEM_BIT(TXCOEN);
>
> #ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT
> - if (bp->hw_dma_cap == HW_DMA_CAP_64B)
> + if (bp->hw_dma_cap & HW_DMA_CAP_64B)
> dmacfg |= GEM_BIT(ADDR64);
> #endif
> +#ifdef CONFIG_MACB_USE_HWSTAMP
> + if (bp->hw_dma_cap & HW_DMA_CAP_PTP)
> + dmacfg |= GEM_BIT(RXEXT) | GEM_BIT(TXEXT);
> +#endif
> netdev_dbg(bp->dev, "Cadence configure DMA with 0x%08x\n",
> dmacfg);
> gem_writel(bp, DMACFG, dmacfg);
> @@ -1971,14 +2026,15 @@ static void macb_init_hw(struct macb *bp)
> /* Initialize TX and RX buffers */
> macb_writel(bp, RBQP, lower_32_bits(bp->rx_ring_dma));
> #ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT
> - if (bp->hw_dma_cap == HW_DMA_CAP_64B)
> + if (bp->hw_dma_cap & HW_DMA_CAP_64B)
> macb_writel(bp, RBQPH, upper_32_bits(bp->rx_ring_dma));
> #endif
> for (q = 0, queue = bp->queues; q < bp->num_queues; ++q, ++queue) {
> queue_writel(queue, TBQP, lower_32_bits(queue->tx_ring_dma));
> #ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT
> - if (bp->hw_dma_cap == HW_DMA_CAP_64B)
> - queue_writel(queue, TBQPH, upper_32_bits(queue->tx_ring_dma));
> + if (bp->hw_dma_cap & HW_DMA_CAP_64B)
> + queue_writel(queue, TBQPH,
> + upper_32_bits(queue->tx_ring_dma));
Align arg3 with arg1 please.
> #endif
>
> /* Enable interrupts */
> @@ -2579,6 +2635,18 @@ static void macb_configure_caps(struct macb *bp,
> dcfg = gem_readl(bp, DCFG2);
> if ((dcfg & (GEM_BIT(RX_PKT_BUFF) | GEM_BIT(TX_PKT_BUFF))) == 0)
> bp->caps |= MACB_CAPS_FIFO_MODE;
> + /* if HWSTAMP is configure and gem has the capability */
This comment is redundant. We can see that clearly in the code already.
> +#ifdef CONFIG_MACB_USE_HWSTAMP
> + bp->ptp_hw_support = false;
No need to clear this again. (The struct was cleared after
allocation, right?)
> + if (gem_has_ptp(bp)) {
Why not drop the #idef:
if (IS_ENABLED(CONFIG_MACB_USE_HWSTAMP) && gem_has_ptp(bp)) ...
> + if (!GEM_BFEXT(TSU, gem_readl(bp, DCFG5)))
> + pr_err("GEM doesn't support hardware ptp.\n");
> + else {
> + pr_emerg("rozieblo: ptp_hw_support = true");
pr_emerg?
> + bp->ptp_hw_support = true;
> + }
Proper if/else CodingStyle please.
> + }
> +#endif
> }
>
> dev_dbg(&bp->pdev->dev, "Cadence caps 0x%08x\n", bp->caps);
> @@ -2716,7 +2784,7 @@ static int macb_init(struct platform_device *pdev)
> queue->IMR = GEM_IMR(hw_q - 1);
> queue->TBQP = GEM_TBQP(hw_q - 1);
> #ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT
> - if (bp->hw_dma_cap == HW_DMA_CAP_64B)
> + if (bp->hw_dma_cap & HW_DMA_CAP_64B)
> queue->TBQPH = GEM_TBQPH(hw_q - 1);
> #endif
> } else {
> @@ -2727,7 +2795,7 @@ static int macb_init(struct platform_device *pdev)
> queue->IMR = MACB_IMR;
> queue->TBQP = MACB_TBQP;
> #ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT
> - if (bp->hw_dma_cap == HW_DMA_CAP_64B)
> + if (bp->hw_dma_cap & HW_DMA_CAP_64B)
> queue->TBQPH = MACB_TBQPH;
> #endif
> }
> @@ -3307,19 +3375,24 @@ static int macb_probe(struct platform_device *pdev)
> bp->wol |= MACB_WOL_HAS_MAGIC_PACKET;
> device_init_wakeup(&pdev->dev, bp->wol & MACB_WOL_HAS_MAGIC_PACKET);
>
> -#ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT
> - if (GEM_BFEXT(DAW64, gem_readl(bp, DCFG6))) {
> - dma_set_mask(&pdev->dev, DMA_BIT_MASK(44));
> - bp->hw_dma_cap = HW_DMA_CAP_64B;
> - } else
> - bp->hw_dma_cap = HW_DMA_CAP_32B;
> -#endif
> -
> spin_lock_init(&bp->lock);
>
> /* setup capabilities */
> macb_configure_caps(bp, macb_config);
>
> +#ifdef MACB_EXT_DESC
> + bp->hw_dma_cap = HW_DMA_CAP_32B;
> +#endif
> +#ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT
> + if (GEM_BFEXT(DAW64, gem_readl(bp, DCFG6))) {
> + dma_set_mask(&pdev->dev, DMA_BIT_MASK(44));
> + bp->hw_dma_cap |= HW_DMA_CAP_64B;
> + }
> +#endif
> +#ifdef CONFIG_MACB_USE_HWSTAMP
> + if (bp->ptp_hw_support)
> + bp->hw_dma_cap |= HW_DMA_CAP_PTP;
So bp->ptp_hw_support is a waste of storage. You can test for
(!GEM_BFEXT(TSU, gem_readl(bp, DCFG5))) directly here, or return a
flag from macb_configure_caps(), or set the hw_dma_cap flag in that
function, ...
> +#endif
> platform_set_drvdata(pdev, dev);
>
> dev->irq = platform_get_irq(pdev, 0);
> @@ -954,8 +972,12 @@ struct macb {
> u32 wol;
>
> struct macb_ptp_info *ptp_info; /* macb-ptp interface */
> -#ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT
> - enum macb_hw_dma_cap hw_dma_cap;
> +#ifdef MACB_EXT_DESC
> + uint8_t hw_dma_cap;
> +#endif
> +
> +#ifdef CONFIG_MACB_USE_HWSTAMP
> + bool ptp_hw_support;
Remove this, please.
Thanks,
Richard
> #endif
> };
>
> --
> 2.4.5
>
^ permalink raw reply
* [PATCH 3/4] net: macb: Add hardware PTP support
From: kbuild test robot @ 2017-04-14 7:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492090763-15686-1-git-send-email-rafalo@cadence.com>
Hi Rafal,
[auto build test ERROR on net-next/master]
[also build test ERROR on v4.11-rc6 next-20170413]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Rafal-Ozieblo/net-macb-Add-support-for-PTP-timestamps-in-DMA-descriptors/20170414-001330
config: arm64-defconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm64
Note: the linux-review/Rafal-Ozieblo/net-macb-Add-support-for-PTP-timestamps-in-DMA-descriptors/20170414-001330 HEAD 3b878618e04f866388fd62f6c44752e50b15658a builds fine.
It only hurts bisectibility.
All errors (new ones prefixed by >>):
drivers/built-in.o: In function `gem_ptp_do_rxstamp':
>> drivers/net/ethernet/cadence/macb.h:1108: undefined reference to `gem_ptp_rxstamp'
drivers/net/ethernet/cadence/macb.h:1108:(.text+0x264604): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `gem_ptp_rxstamp'
drivers/built-in.o: In function `gem_ptp_do_txstamp':
>> drivers/net/ethernet/cadence/macb.h:1100: undefined reference to `gem_ptp_txstamp'
drivers/net/ethernet/cadence/macb.h:1100:(.text+0x266564): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `gem_ptp_txstamp'
drivers/built-in.o: In function `macb_interrupt':
>> drivers/net/ethernet/cadence/macb.c:1332: undefined reference to `macb_ptp_int'
drivers/net/ethernet/cadence/macb.c:1332:(.text+0x2666ac): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `macb_ptp_int'
drivers/built-in.o:(.data+0x93fc8): undefined reference to `gem_ptp_init'
drivers/built-in.o:(.data+0x93fd0): undefined reference to `gem_ptp_remove'
drivers/built-in.o:(.data+0x93ff0): undefined reference to `gem_get_hwtst'
drivers/built-in.o:(.data+0x93ff8): undefined reference to `gem_set_hwtst'
vim +1108 drivers/net/ethernet/cadence/macb.h
1094 void macb_ptp_int(struct macb_queue *queue, u32 status);
1095 static inline int gem_ptp_do_txstamp(struct macb_queue *queue, struct sk_buff *skb, struct macb_dma_desc *desc)
1096 {
1097 if (queue->bp->tstamp_config.tx_type == TSTAMP_DISABLED)
1098 return -ENOTSUPP;
1099
> 1100 return gem_ptp_txstamp(queue, skb, desc);
1101 }
1102
1103 static inline void gem_ptp_do_rxstamp(struct macb *bp, struct sk_buff *skb, struct macb_dma_desc *desc)
1104 {
1105 if (bp->tstamp_config.rx_filter == TSTAMP_DISABLED)
1106 return;
1107
> 1108 gem_ptp_rxstamp(bp, skb, desc);
1109 }
1110 int gem_get_hwtst(struct net_device *dev, struct ifreq *rq);
1111 int gem_set_hwtst(struct net_device *dev, struct ifreq *ifr, int cmd);
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 34537 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170414/343318b5/attachment-0001.gz>
^ permalink raw reply
* [Bug] VCHIQ functional test broken
From: Rabin Vincent @ 2017-04-14 7:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170413222915.GF17774@n2100.armlinux.org.uk>
On Thu, Apr 13, 2017 at 11:29:15PM +0100, Russell King - ARM Linux wrote:
> > 00a19f3e25c0c40e0ec77f52d4841d23ad269169 is the first bad commit
> > commit 00a19f3e25c0c40e0ec77f52d4841d23ad269169
> > Author: Rabin Vincent <rabinv@axis.com>
> > Date: Tue Nov 8 09:21:19 2016 +0100
> >
> > ARM: 8627/1: avoid cache flushing in flush_dcache_page()
> >
> > When the data cache is PIPT or VIPT non-aliasing, and cache operations
> > are broadcast by the hardware, we can always postpone the flush in
> > flush_dcache_page(). A similar change was done for ARM64 in commit
> > b5b6c9e9149d ("arm64: Avoid cache flushing in flush_dcache_page()").
> >
> > Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
> > Signed-off-by: Rabin Vincent <rabinv@axis.com>
> > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> >
> > It seems that staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm
> > relies on the behavior of flush_dcache_page before this patch get
> > applied. Any advices to fix this issues are appreciated.
>
> Any ideas why this causes a problem for this driver? From what I can see,
> it doesn't make use of flush_dcache_page().
The driver's create_pagelist() uses get_free_pages(), and
get_free_pages() calls flush_dcache_page().
The problem is that the driver fails to flush the pages which it
acquires via get_free_pages(). It's clear that the driver needs to do
it, since there is a flush in the is_vmalloc_addr() path in the same
function. The driver probably worked earlier because of the unecessary
flush in flush_dcache_page() which existed before this patch, but the
purpose of that flush was not DMA coherency and it was never guaranteed
that it would flush all the way to the point that devices could see the
data.
See radeon_ttm_tt_pin_userptr() in drivers/gpu/drm/radeon/radeon_ttm.c
for an example of how a driver can ensure cache coherency using the DMA
mapping API if it intends to DMA from/to pages acquired by
get_free_pages().
The rest of the driver should also be converted to the DMA mapping API
instead of abusing the API's private functions (dmac_map_area etc.)
^ permalink raw reply
* [PATCH 1/3] dt-bindings: Add support for samsung s6e3ha2 edge panel binding
From: Andrzej Hajda @ 2017-04-14 7:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492147179-7824-2-git-send-email-hoegeun.kwon@samsung.com>
Hi Hoegeun,
On 14.04.2017 07:19, Hoegeun Kwon wrote:
> The Samsung s6e3ha2 edge is a 5.65" 1600x2560 AMOLED panel connected
> using MIPI-DSI interfaces.
As I wrote in discussion about s6e3ha2, there is no edge version of
s6e3ha2, it is just different panel: s6e3hf2, or more precisely IC driver.
[1]: https://lkml.org/lkml/2017/1/9/159
>
> Signed-off-by: Hoegeun Kwon <hoegeun.kwon@samsung.com>
> ---
> .../bindings/display/panel/samsung,s6e3ha2-e.txt | 28 ++++++++++++++++++++++
> 1 file changed, 28 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2-e.txt
>
> diff --git a/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2-e.txt b/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2-e.txt
> new file mode 100644
> index 0000000..09c65f6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2-e.txt
> @@ -0,0 +1,28 @@
> +Samsung S6E3HA2 5.65" 1600x2560 AMOLED panel
> +
> +Required properties:
> + - compatible: "samsung,s6e3ha2-e"
I think "samsung,s6e3hf2" should be then used, I guess it could be even
simpler to just add new compatible string to samsung,s6e3ha2.txt binding
with some comments, as these panels are of the same family.
Regards
Andrzej
> + - reg: the virtual channel number of a DSI peripheral
> + - vdd3-supply: I/O voltage supply
> + - vci-supply: voltage supply for analog circuits
> + - reset-gpios: a GPIO spec for the reset pin (active low)
> + - enable-gpios: a GPIO spec for the panel enable pin (active high)
> +
> +Optional properties:
> + - te-gpios: a GPIO spec for the tearing effect synchronization signal
> + gpio pin (active high)
> +
> +Example:
> +&dsi {
> + ...
> +
> + panel at 0 {
> + compatible = "samsung,s6e3ha2-e";
> + reg = <0>;
> + vdd3-supply = <&ldo27_reg>;
> + vci-supply = <&ldo28_reg>;
> + reset-gpios = <&gpg0 0 GPIO_ACTIVE_LOW>;
> + enable-gpios = <&gpf1 5 GPIO_ACTIVE_HIGH>;
> + te-gpios = <&gpf1 3 GPIO_ACTIVE_HIGH>;
> + };
> +};
^ permalink raw reply
* [PATCH v3 7/8] arm64: exception: handle asynchronous SError interrupt
From: Xie XiuQi @ 2017-04-14 7:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170413105131.GD24027@leverpostej>
Hi Mark,
Thanks for your comments.
On 2017/4/13 18:51, Mark Rutland wrote:
> Hi,
>
> On Thu, Mar 30, 2017 at 06:31:07PM +0800, Xie XiuQi wrote:
>> diff --git a/arch/arm64/include/asm/esr.h b/arch/arm64/include/asm/esr.h
>> index f20c64a..22f9c90 100644
>> --- a/arch/arm64/include/asm/esr.h
>> +++ b/arch/arm64/include/asm/esr.h
>> @@ -106,6 +106,20 @@
>> #define ESR_ELx_AR (UL(1) << 14)
>> #define ESR_ELx_CM (UL(1) << 8)
>>
>> +#define ESR_Elx_DFSC_SEI (0x11)
>
> We should probably have a definition for the uncategorized DFSC value,
> too.
>
Will do, thanks.
How about "#define ESR_Elx_DFSC_UNCATEGORIZED (0)" ?
> [...]
>
>> index 43512d4..d8a7306 100644
>> --- a/arch/arm64/kernel/entry.S
>> +++ b/arch/arm64/kernel/entry.S
>> @@ -69,7 +69,14 @@
>> #define BAD_FIQ 2
>> #define BAD_ERROR 3
>>
>> + .arch_extension ras
>
> Generally, arch_extension is a warning sign that code isn't going to
> work with contemporary assemblers, which we likely need to support.
>
>> +
>> .macro kernel_entry, el, regsize = 64
>> +#ifdef CONFIG_ARM64_ESB
>> + .if \el == 0
>> + esb
>
> Here, I think that we'll need to macro this such that we can build with
> existing toolchains.
>
> e.g. in <asm/assembler.h> we need something like:
>
> #define HINT_IMM_ESB 16
>
> .macro ESB
> hint #HINT_IMM_ESB
> .endm
>
Good, thanks for your suggestion. I'll use this macro in next versin.
>> + .endif
>> +#endif
>> sub sp, sp, #S_FRAME_SIZE
>> .if \regsize == 32
>> mov w0, w0 // zero upper 32 bits of x0
>> @@ -208,6 +215,7 @@ alternative_else_nop_endif
>> #endif
>>
>> .if \el == 0
>> + msr daifset, #0xF // Set flags
>
> Elsewhere in head.S we use helpers to fiddle with DAIF bits.
>
> Please be consistent with that. Add an enable_all macro if we need one.
OK, I'll do it refer to head.S.
>
>> ldr x23, [sp, #S_SP] // load return stack pointer
>> msr sp_el0, x23
>> #ifdef CONFIG_ARM64_ERRATUM_845719
>> @@ -226,6 +234,15 @@ alternative_else_nop_endif
>>
>> msr elr_el1, x21 // set up the return data
>> msr spsr_el1, x22
>> +
>> +#ifdef CONFIG_ARM64_ESB
>> + .if \el == 0
>> + esb // Error Synchronization Barrier
>> + mrs x21, disr_el1 // Check for deferred error
>
> We'll need an <asm/sysreg.h> definition for this register. With that, we
> can use mrs_s here.
OK, thanks.
>
>> + tbnz x21, #31, el1_sei
>> + .endif
>> +#endif
>> +
>> ldp x0, x1, [sp, #16 * 0]
>> ldp x2, x3, [sp, #16 * 1]
>> ldp x4, x5, [sp, #16 * 2]
>> @@ -318,7 +335,7 @@ ENTRY(vectors)
>> ventry el1_sync_invalid // Synchronous EL1t
>> ventry el1_irq_invalid // IRQ EL1t
>> ventry el1_fiq_invalid // FIQ EL1t
>> - ventry el1_error_invalid // Error EL1t
>> + ventry el1_error // Error EL1t
>>
>> ventry el1_sync // Synchronous EL1h
>> ventry el1_irq // IRQ EL1h
>> @@ -328,7 +345,7 @@ ENTRY(vectors)
>> ventry el0_sync // Synchronous 64-bit EL0
>> ventry el0_irq // IRQ 64-bit EL0
>> ventry el0_fiq_invalid // FIQ 64-bit EL0
>> - ventry el0_error_invalid // Error 64-bit EL0
>> + ventry el0_error // Error 64-bit EL0
>>
>> #ifdef CONFIG_COMPAT
>> ventry el0_sync_compat // Synchronous 32-bit EL0
>> @@ -508,12 +525,31 @@ el1_preempt:
>> ret x24
>> #endif
>>
>> + .align 6
>> +el1_error:
>> + kernel_entry 1
>> +el1_sei:
>> + /*
>> + * asynchronous SError interrupt from kernel
>> + */
>> + mov x0, sp
>> + mrs x1, esr_el1
>
> I don't think this is correct if we branched here from kernel_exit.
> Surely we want the DISR_EL1 value, and ESR_EL1 is unrelated?
Yes, indeed. I'll change it in next version.
>
>> + mov x2, #1 // exception level of SEI generated
>> + b do_sei
>
> You don't need to figure out the EL here. In do_sei() we can determine
> the exception level from the regs (e.g. using user_mode(regs)).
Yes, you're right. I'll fix it.
>
>> +ENDPROC(el1_error)
>> +
>> +
>> /*
>> * EL0 mode handlers.
>> */
>> .align 6
>> el0_sync:
>> kernel_entry 0
>> +#ifdef CONFIG_ARM64_ESB
>> + mrs x26, disr_el1
>> + tbnz x26, #31, el0_sei // check DISR.A
>> + msr daifclr, #0x4 // unmask SEI
>> +#endif
>
> Why do we duplicate this across the EL0 handlers, rather than making it
> common in the el0 kernel_entry code?
It's different between el0_sync and el0_irq. If sei come from el0_sync,
the context is the same process, so we could just return to user space
after do_sei, instead of continue the syscall. The process may be killed
very likely, it's not necessary to continue the system call.
However, if sei come from el0_irq, in the irq context which is not related
the current process, we should continue the irq handler after do_sei.
So I think we should handle these two situation differently. If I'm wrong,
please correct me, Thanks.
>
>> mrs x25, esr_el1 // read the syndrome register
>> lsr x24, x25, #ESR_ELx_EC_SHIFT // exception class
>> cmp x24, #ESR_ELx_EC_SVC64 // SVC in 64-bit state
>> @@ -688,8 +724,38 @@ el0_inv:
>> ENDPROC(el0_sync)
>>
>> .align 6
>> +el0_error:
>> + kernel_entry 0
>> +el0_sei:
>> + /*
>> + * asynchronous SError interrupt from userspace
>> + */
>> + ct_user_exit
>> + mov x0, sp
>> + mrs x1, esr_el1
>
> As with el1_sei, I don't think this is correct if we branched to
> el0_sei. As far as I am aware, ESR_EL1 will contain whatever exception
> we took, and the value we want is in DISR_EL1.
Will fix, thanks.
>
>> + mov x2, #0
>
> This EL parameter can go.
>
>> + bl do_sei
>> + b ret_to_user
>> +ENDPROC(el0_error)
>> +
>> + .align 6
>> el0_irq:
>> kernel_entry 0
>> +#ifdef CONFIG_ARM64_ESB
>> + mrs x26, disr_el1
>> + tbz x26, #31, el0_irq_naked // check DISR.A
>> +
>> + mov x0, sp
>> + mrs x1, esr_el1
>> + mov x2, 0
>> +
>> + /*
>> + * The SEI generated at EL0 is not affect this irq context,
>> + * so after sei handler, we continue process this irq.
>> + */
>> + bl do_sei
>> + msr daifclr, #0x4 // unmask SEI
>
> This rough pattern is duplicated several times across the EL0 entry
> paths. I think it should be made common.
I agree, I'll do it in next version, thanks.
>
>> +#endif
>> el0_irq_naked:
>> enable_dbg
>> #ifdef CONFIG_TRACE_IRQFLAGS
>> diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
>> index b6d6727..99be6d8 100644
>> --- a/arch/arm64/kernel/traps.c
>> +++ b/arch/arm64/kernel/traps.c
>> @@ -643,6 +643,34 @@ asmlinkage void bad_mode(struct pt_regs *regs, int reason, unsigned int esr)
>> handler[reason], smp_processor_id(), esr,
>> esr_get_class_string(esr));
>>
>> + die("Oops - bad mode", regs, 0);
>> + local_irq_disable();
>> + panic("bad mode");
>> +}
>> +
>> +static const char *sei_context[] = {
>> + "userspace", /* EL0 */
>> + "kernel", /* EL1 */
>> +};
>
> This should go. It's only used in one place, and would be clearer with
> the strings inline. More on that below.
>
OK, thanks.
>> +
>> +static const char *sei_severity[] = {
>
> Please name this for what it actually represents:
>
> static const char *esr_aet_str[] = {
>
>> + [0 ... ESR_ELx_AET_MAX] = "Unknown",
>
> For consistency with esr_class_str, please make this:
>
> [0 ... ESR_ELx_AET_MAX] = "UNRECOGNIZED AET",
>
> ... which makes it clear that this isn't some AET value which reports an
> "Unknown" status.
>
OK, thanks.
>> + [ESR_ELx_AET_UC] = "Uncontainable",
>> + [ESR_ELx_AET_UEU] = "Unrecoverable",
>> + [ESR_ELx_AET_UEO] = "Restartable",
>> + [ESR_ELx_AET_UER] = "Recoverable",
>> + [ESR_ELx_AET_CE] = "Corrected",
>> +};
>> +
>> +DEFINE_PER_CPU(int, sei_in_process);
>
> A previous patch added definition of this.
>
I'll remote it, thanks.
>> +asmlinkage void do_sei(struct pt_regs *regs, unsigned int esr, int el)
>> +{
>> + int aet = ESR_ELx_AET(esr);
>
> The AET field is only valid when the DFSC is 0b010001, so we need to
> check that before we interpret AET.
>
Will fix.
>> + console_verbose();
>> +
>> + pr_crit("Asynchronous SError interrupt detected on CPU%d, %s, %s\n",
>> + smp_processor_id(), sei_context[el], sei_severity[aet]);
>
> We should dump the full ESR_ELx value, regardless of what automated
> decoding we do, so that we have a chance of debugging issues in the
> field.
>
> It would also be nice to align with how bad_mode reports this today.
> Please make this:
>
> pr_crit("SError detected on CPU%d while in %s mode: code: 0x%08x -- %s\n",
> smp_processor_id(), user_mode(regs) ? "user" : "kernel",
> esr, esr_aet_str[aet]);
>
> ... though it might be best to dump the raw SPSR rather than trying to
> say user/kernel, so that we can distinguish EL1/EL2 with VHE, etc.
>
OK, I'll modify in next version.
>> +
>> /*
>> * In firmware first mode, we could assume firmware will only generate one
>> * of cper records at a time. There is no risk for one cpu to parse ghes table.
>> @@ -653,9 +681,31 @@ asmlinkage void bad_mode(struct pt_regs *regs, int reason, unsigned int esr)
>> this_cpu_dec(sei_in_process);
>> }
>>
>> - die("Oops - bad mode", regs, 0);
>> + if (el == 0 && IS_ENABLED(CONFIG_ARM64_ESB) &&
>
> Please use user_mode(regs), and get rid of the el parameter to this
> function entirely.
>
Will fix.
>> + cpus_have_cap(ARM64_HAS_RAS_EXTN)) {
>> + siginfo_t info;
>> + void __user *pc = (void __user *)instruction_pointer(regs);
>> +
>> + if (aet >= ESR_ELx_AET_UEO)
>> + return;
>
> We need to check the DFSC first, and 0b111 is a reserved value (which
> the ARM ARM doesn't define the recoverability of), so I don't think this
> is correct.
>
> We should probably test the DSFC, then switch on the AET value, so as to
> handle only the cases we are aware of.
Will fix.
>
>> +
>> + if (aet == ESR_ELx_AET_UEU) {
>> + info.si_signo = SIGILL;
>> + info.si_errno = 0;
>> + info.si_code = ILL_ILLOPC;
>> + info.si_addr = pc;
>
> An unrecoverable error is not necessarily a particular bad instruction,
> so I'm not sure this makes sense.
>
Generally, a SEI is generated when PE consumes an uncorrectable error.
So, may be we could send a SIGBUS instead.
I'm not sure too. Any other suggestion?
> Thanks,
> Mark.
>
> .
>
--
Thanks,
Xie XiuQi
^ permalink raw reply
* [PATCH 3/4] net: macb: Add hardware PTP support
From: kbuild test robot @ 2017-04-14 6:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492090763-15686-1-git-send-email-rafalo@cadence.com>
Hi Rafal,
[auto build test ERROR on net-next/master]
[also build test ERROR on v4.11-rc6 next-20170413]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Rafal-Ozieblo/net-macb-Add-support-for-PTP-timestamps-in-DMA-descriptors/20170414-001330
config: arm-at91_dt_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm
Note: the linux-review/Rafal-Ozieblo/net-macb-Add-support-for-PTP-timestamps-in-DMA-descriptors/20170414-001330 HEAD 3b878618e04f866388fd62f6c44752e50b15658a builds fine.
It only hurts bisectibility.
All errors (new ones prefixed by >>):
drivers/built-in.o: In function `macb_interrupt':
>> kfifo_buf.c:(.text+0xeabd8): undefined reference to `macb_ptp_int'
>> kfifo_buf.c:(.text+0xeac6c): undefined reference to `gem_ptp_txstamp'
drivers/built-in.o: In function `gem_rx':
>> kfifo_buf.c:(.text+0xebbd8): undefined reference to `gem_ptp_rxstamp'
>> drivers/built-in.o:(.data+0xa5e0): undefined reference to `gem_ptp_init'
>> drivers/built-in.o:(.data+0xa5e4): undefined reference to `gem_ptp_remove'
>> drivers/built-in.o:(.data+0xa5f4): undefined reference to `gem_get_hwtst'
>> drivers/built-in.o:(.data+0xa5f8): undefined reference to `gem_set_hwtst'
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 22468 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170414/7e8e6b3b/attachment-0001.gz>
^ permalink raw reply
* [PATCH RFC 0/5] *** SPI Slave mode support ***
From: Jiada Wang @ 2017-04-14 5:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdUm=90ddNWM5KWqT+W0hqZ-QO6vPHj5OisbYquDYq1ZmA@mail.gmail.com>
Hello Geert
On 04/13/2017 12:47 PM, Geert Uytterhoeven wrote:
> On Thu, Apr 13, 2017 at 2:59 PM, Mark Brown<broonie@kernel.org> wrote:
>> On Thu, Apr 13, 2017 at 05:13:59AM -0700, jiada_wang at mentor.com wrote:
>>> From: Jiada Wang<jiada_wang@mentor.com>
>>>
>>> v1:
>>> add Slave mode support in SPI core
>>> spidev create slave device when SPI controller work in slave mode
>>> spi-imx support to work in slave mode
>> Adding Geert who also had a series doing this in progress that was
>> getting very near to being merged.
> Thank you!
>
> Actually my plan is to fix the last remaining issues and resubmit for v4.13.
I noticed your patch set for SPI slave support,
(I am sure you can find out some of the change
in this patch set is based on your work).
we have similar requirement to add slave mode support to ecspi IP on
imx6 Soc.
Our use case is to use spidev as an interface to communicate with
external SPI master devices.
meanwhile the SPI bus controller can also act as master device to send
data to other
SPI slave devices on the board.
I found in your implementation, SPI bus controller is limited to either
work in master mode or
slave mode, is there any reasoning to not configure SPI mode based on
SPI devices use case?
Thanks,
Jiada
> References:
> - v2: https://lkml.org/lkml/2016/9/12/1065
> - v1: https://lkml.org/lkml/2016/6/22/423
>
> BTW Jiada, what's your use case? Just spidev?
>
> Thx!
>
> 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] ARM: multi_v7_defconfig: Enable more drivers for LS1021A
From: Alison Wang @ 2017-04-14 5:29 UTC (permalink / raw)
To: linux-arm-kernel
This patch enables more drivers for LS1021A, such as FlexCAN, IFC, SATA,
DCU, RTC, CAAM and Virtualization.
Signed-off-by: Alison Wang <alison.wang@nxp.com>
---
arch/arm/configs/multi_v7_defconfig | 24 ++++++++++++++++++++++--
1 file changed, 22 insertions(+), 2 deletions(-)
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 8f6167e..f7124af 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -174,6 +174,7 @@ CONFIG_CAN_AT91=m
CONFIG_CAN_RCAR=m
CONFIG_CAN_XILINXCAN=y
CONFIG_CAN_MCP251X=y
+CONFIG_CAN_FLEXCAN=y
CONFIG_NET_DSA_BCM_SF2=m
CONFIG_B53=m
CONFIG_B53_SPI_DRIVER=m
@@ -199,19 +200,27 @@ CONFIG_SUNXI_RSB=y
CONFIG_MTD=y
CONFIG_MTD_CMDLINE_PARTS=y
CONFIG_MTD_BLOCK=y
+CONFIG_MTD_CFI=y
+CONFIG_MTD_CFI_ADV_OPTIONS=y
+CONFIG_MTD_CFI_GEOMETRY=y
+CONFIG_MTD_CFI_INTELEXT=y
+CONFIG_MTD_CFI_STAA=y
CONFIG_MTD_M25P80=y
+CONFIG_MTD_DATAFLASH=y
+CONFIG_MTD_SST25L=y
CONFIG_MTD_NAND=y
CONFIG_MTD_NAND_DENALI_DT=y
CONFIG_MTD_NAND_ATMEL=y
CONFIG_MTD_NAND_BRCMNAND=y
CONFIG_MTD_NAND_VF610_NFC=y
CONFIG_MTD_NAND_DAVINCI=y
+CONFIG_MTD_NAND_FSL_IFC=y
CONFIG_MTD_SPI_NOR=y
CONFIG_SPI_FSL_QUADSPI=m
CONFIG_MTD_UBI=y
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_RAM=y
-CONFIG_BLK_DEV_RAM_SIZE=65536
+CONFIG_BLK_DEV_RAM_SIZE=262144
CONFIG_VIRTIO_BLK=y
CONFIG_AD525X_DPOT=y
CONFIG_AD525X_DPOT_I2C=y
@@ -233,6 +242,9 @@ CONFIG_AHCI_ST=y
CONFIG_AHCI_IMX=y
CONFIG_AHCI_SUNXI=y
CONFIG_AHCI_TEGRA=y
+CONFIG_AHCI_QORIQ=y
+CONFIG_SATA_SIL24=y
+CONFIG_CHR_DEV_SG=y
CONFIG_SATA_HIGHBANK=y
CONFIG_SATA_MV=y
CONFIG_SATA_RCAR=y
@@ -266,6 +278,7 @@ CONFIG_BROADCOM_PHY=y
CONFIG_ICPLUS_PHY=y
CONFIG_REALTEK_PHY=y
CONFIG_MICREL_PHY=y
+CONFIG_NATIONAL_PHY=y
CONFIG_FIXED_PHY=y
CONFIG_USB_PEGASUS=y
CONFIG_USB_RTL8152=m
@@ -359,7 +372,7 @@ CONFIG_I2C_DIGICOLOR=m
CONFIG_I2C_EMEV2=m
CONFIG_I2C_GPIO=m
CONFIG_I2C_EXYNOS5=y
-CONFIG_I2C_IMX=m
+CONFIG_I2C_IMX=y
CONFIG_I2C_MV64XXX=y
CONFIG_I2C_RIIC=y
CONFIG_I2C_RK3X=y
@@ -609,6 +622,9 @@ CONFIG_DRM_PANEL_SAMSUNG_S6E8AA0=m
CONFIG_DRM_PANEL_SIMPLE=y
CONFIG_DRM_STI=m
CONFIG_DRM_VC4=y
+CONFIG_DRM_FSL_DCU=y
+CONFIG_DRM_SII902X=y
+CONFIG_LOGO=y
CONFIG_FB_ARMCLCD=y
CONFIG_FB_EFI=y
CONFIG_FB_WM8505=y
@@ -756,6 +772,7 @@ CONFIG_RTC_CLASS=y
CONFIG_RTC_DRV_AC100=y
CONFIG_RTC_DRV_AS3722=y
CONFIG_RTC_DRV_DS1307=y
+CONFIG_RTC_DRV_DS3232=y
CONFIG_RTC_DRV_HYM8563=m
CONFIG_RTC_DRV_MAX8907=y
CONFIG_RTC_DRV_MAX8998=m
@@ -956,8 +973,11 @@ CONFIG_CRYPTO_GHASH_ARM_CE=m
CONFIG_CRYPTO_DEV_ATMEL_AES=m
CONFIG_CRYPTO_DEV_ATMEL_TDES=m
CONFIG_CRYPTO_DEV_ATMEL_SHA=m
+CONFIG_CRYPTO_DEV_FSL_CAAM=m
CONFIG_VIDEO_VIVID=m
CONFIG_VIRTIO=y
CONFIG_VIRTIO_PCI=y
CONFIG_VIRTIO_PCI_LEGACY=y
CONFIG_VIRTIO_MMIO=y
+CONFIG_VIRTUALIZATION=y
+CONFIG_VHOST_NET=y
--
2.1.0.27.g96db324
^ permalink raw reply related
* [PATCH 3/3] arm64: dts: exynos: Add support for S6E3HA2 edge panel device on TM2e board
From: Hoegeun Kwon @ 2017-04-14 5:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492147179-7824-1-git-send-email-hoegeun.kwon@samsung.com>
This patch add the panel device tree node for S6E3HA2 edge display
controller to TM2e dts.
Signed-off-by: Hoegeun Kwon <hoegeun.kwon@samsung.com>
---
arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts b/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts
index 694717a..79f22f7 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts
@@ -52,6 +52,18 @@
assigned-clock-rates = <278000000>, <400000000>;
};
+&dsi {
+ panel at 0 {
+ compatible = "samsung,s6e3ha2-e";
+ reg = <0>;
+ vdd3-supply = <&ldo27_reg>;
+ vci-supply = <&ldo28_reg>;
+ reset-gpios = <&gpg0 0 GPIO_ACTIVE_LOW>;
+ enable-gpios = <&gpf1 5 GPIO_ACTIVE_HIGH>;
+ te-gpios = <&gpf1 3 GPIO_ACTIVE_HIGH>;
+ };
+};
+
&ldo31_reg {
regulator-name = "TSP_VDD_1.8V_AP";
regulator-min-microvolt = <1800000>;
--
1.9.1
^ permalink raw reply related
* [PATCH 2/3] drm/panel: s6e3ha2: Add support for S6eHEA2 edge panel on TM2e board
From: Hoegeun Kwon @ 2017-04-14 5:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492147179-7824-1-git-send-email-hoegeun.kwon@samsung.com>
This patch considers edge type of panel on TM2e board and The panel
has 1600x2560 resolution in 5.65" physical panel in the TM2e device.
This identify panel type with compatibility string, also invoke
display mode that matches the type. So add the check code for default
compatibility and edge type and select the drm_display_mode of default
and edge type.
Signed-off-by: Hoegeun Kwon <hoegeun.kwon@samsung.com>
---
drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c | 62 ++++++++++++++++++++++++---
1 file changed, 56 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c b/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
index 4cc08d7..b4a064a 100644
--- a/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
+++ b/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
@@ -16,6 +16,7 @@
#include <drm/drm_panel.h>
#include <linux/backlight.h>
#include <linux/gpio/consumer.h>
+#include <linux/of_device.h>
#include <linux/regulator/consumer.h>
#define S6E3HA2_MIN_BRIGHTNESS 0
@@ -218,6 +219,16 @@
0x1d, 0x1e, 0x1f, 0x20, 0x21
};
+enum s6e3ha2_type {
+ DEFAULT_TYPE,
+ EDGE_TYPE,
+};
+
+struct s6e3ha2_panel_desc {
+ const struct drm_display_mode *mode;
+ enum s6e3ha2_type type;
+};
+
struct s6e3ha2 {
struct device *dev;
struct drm_panel panel;
@@ -226,6 +237,8 @@ struct s6e3ha2 {
struct regulator_bulk_data supplies[2];
struct gpio_desc *reset_gpio;
struct gpio_desc *enable_gpio;
+
+ const struct s6e3ha2_panel_desc *desc;
};
static int s6e3ha2_dcs_write(struct s6e3ha2 *ctx, const void *data, size_t len)
@@ -283,11 +296,19 @@ static int s6e3ha2_single_dsi_set(struct s6e3ha2 *ctx)
static int s6e3ha2_freq_calibration(struct s6e3ha2 *ctx)
{
s6e3ha2_dcs_write_seq_static(ctx, 0xfd, 0x1c);
+ if (ctx->desc->type == EDGE_TYPE)
+ s6e3ha2_dcs_write_seq_static(ctx, 0xf2, 0x67, 0x40, 0xc5);
s6e3ha2_dcs_write_seq_static(ctx, 0xfe, 0x20, 0x39);
s6e3ha2_dcs_write_seq_static(ctx, 0xfe, 0xa0);
s6e3ha2_dcs_write_seq_static(ctx, 0xfe, 0x20);
- s6e3ha2_dcs_write_seq_static(ctx, 0xce, 0x03, 0x3b, 0x12, 0x62, 0x40,
- 0x80, 0xc0, 0x28, 0x28, 0x28, 0x28, 0x39, 0xc5);
+
+ if (ctx->desc->type == DEFAULT_TYPE)
+ s6e3ha2_dcs_write_seq_static(ctx, 0xce, 0x03, 0x3b, 0x12, 0x62,
+ 0x40, 0x80, 0xc0, 0x28, 0x28, 0x28, 0x28, 0x39, 0xc5);
+ else
+ s6e3ha2_dcs_write_seq_static(ctx, 0xce, 0x03, 0x3b, 0x14, 0x6d,
+ 0x40, 0x80, 0xc0, 0x28, 0x28, 0x28, 0x28, 0x39, 0xc5);
+
return 0;
}
@@ -597,16 +618,41 @@ static int s6e3ha2_enable(struct drm_panel *panel)
.flags = 0,
};
+static const struct s6e3ha2_panel_desc samsung_s6e3ha2_tm2 = {
+ .mode = &default_mode,
+ .type = DEFAULT_TYPE,
+};
+
+static const struct drm_display_mode edge_mode = {
+ .clock = 247856,
+ .hdisplay = 1600,
+ .hsync_start = 1600 + 1,
+ .hsync_end = 1600 + 1 + 1,
+ .htotal = 1600 + 1 + 1 + 1,
+ .vdisplay = 2560,
+ .vsync_start = 2560 + 1,
+ .vsync_end = 2560 + 1 + 1,
+ .vtotal = 2560 + 1 + 1 + 15,
+ .vrefresh = 60,
+ .flags = 0,
+};
+
+static const struct s6e3ha2_panel_desc samsung_s6e3ha2_tm2e = {
+ .mode = &edge_mode,
+ .type = EDGE_TYPE,
+};
+
static int s6e3ha2_get_modes(struct drm_panel *panel)
{
struct drm_connector *connector = panel->connector;
+ struct s6e3ha2 *ctx = container_of(panel, struct s6e3ha2, panel);
struct drm_display_mode *mode;
- mode = drm_mode_duplicate(panel->drm, &default_mode);
+ mode = drm_mode_duplicate(panel->drm, ctx->desc->mode);
if (!mode) {
DRM_ERROR("failed to add mode %ux%ux@%u\n",
- default_mode.hdisplay, default_mode.vdisplay,
- default_mode.vrefresh);
+ ctx->desc->mode->hdisplay, ctx->desc->mode->vdisplay,
+ ctx->desc->mode->vrefresh);
return -ENOMEM;
}
@@ -642,6 +688,7 @@ static int s6e3ha2_probe(struct mipi_dsi_device *dsi)
mipi_dsi_set_drvdata(dsi, ctx);
ctx->dev = dev;
+ ctx->desc = of_device_get_match_data(dev);
dsi->lanes = 4;
dsi->format = MIPI_DSI_FMT_RGB888;
@@ -717,7 +764,10 @@ static int s6e3ha2_remove(struct mipi_dsi_device *dsi)
}
static const struct of_device_id s6e3ha2_of_match[] = {
- { .compatible = "samsung,s6e3ha2" },
+ { .compatible = "samsung,s6e3ha2",
+ .data = &samsung_s6e3ha2_tm2 },
+ { .compatible = "samsung,s6e3ha2-e",
+ .data = &samsung_s6e3ha2_tm2e },
{ }
};
MODULE_DEVICE_TABLE(of, s6e3ha2_of_match);
--
1.9.1
^ permalink raw reply related
* [PATCH 1/3] dt-bindings: Add support for samsung s6e3ha2 edge panel binding
From: Hoegeun Kwon @ 2017-04-14 5:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492147179-7824-1-git-send-email-hoegeun.kwon@samsung.com>
The Samsung s6e3ha2 edge is a 5.65" 1600x2560 AMOLED panel connected
using MIPI-DSI interfaces.
Signed-off-by: Hoegeun Kwon <hoegeun.kwon@samsung.com>
---
.../bindings/display/panel/samsung,s6e3ha2-e.txt | 28 ++++++++++++++++++++++
1 file changed, 28 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2-e.txt
diff --git a/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2-e.txt b/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2-e.txt
new file mode 100644
index 0000000..09c65f6
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2-e.txt
@@ -0,0 +1,28 @@
+Samsung S6E3HA2 5.65" 1600x2560 AMOLED panel
+
+Required properties:
+ - compatible: "samsung,s6e3ha2-e"
+ - reg: the virtual channel number of a DSI peripheral
+ - vdd3-supply: I/O voltage supply
+ - vci-supply: voltage supply for analog circuits
+ - reset-gpios: a GPIO spec for the reset pin (active low)
+ - enable-gpios: a GPIO spec for the panel enable pin (active high)
+
+Optional properties:
+ - te-gpios: a GPIO spec for the tearing effect synchronization signal
+ gpio pin (active high)
+
+Example:
+&dsi {
+ ...
+
+ panel at 0 {
+ compatible = "samsung,s6e3ha2-e";
+ reg = <0>;
+ vdd3-supply = <&ldo27_reg>;
+ vci-supply = <&ldo28_reg>;
+ reset-gpios = <&gpg0 0 GPIO_ACTIVE_LOW>;
+ enable-gpios = <&gpf1 5 GPIO_ACTIVE_HIGH>;
+ te-gpios = <&gpf1 3 GPIO_ACTIVE_HIGH>;
+ };
+};
--
1.9.1
^ permalink raw reply related
* [PATCH 0/3] Add support for the S6E3HA2 edge panel on TM2e board
From: Hoegeun Kwon @ 2017-04-14 5:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CGME20170414051958epcas5p379f82e72e9239fdea0b99de88c4c39f1@epcas5p3.samsung.com>
The purpose of this patch is add support for S6E3HA2 edge AMOLED panel
on the TM2e board. The panel has 1600x2560 resolution in 5.65"
physical panel in the TM2e device.
The S6E3HA2 edge panel(5.65") is simliar to the previous S6E3HA2
panel(5.7"), but resolution and some command message are different. So
it can be distinguished as a compatiblitiy string.
Best regards,
Hoegeun
Hoegeun Kwon (3):
dt-bindings: Add support for samsung s6e3ha2 edge panel binding
drm/panel: s6e3ha2: Add support for S6eHEA2 edge panel on TM2e board
arm64: dts: exynos: Add support for S6E3HA2 edge panel device on TM2e
board
.../bindings/display/panel/samsung,s6e3ha2-e.txt | 28 ++++++++++
arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts | 12 +++++
drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c | 62 +++++++++++++++++++---
3 files changed, 96 insertions(+), 6 deletions(-)
create mode 100644 Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2-e.txt
--
1.9.1
^ permalink raw reply
* [PATCH 2/2] hwrng: mtk: Add driver for hardware random generator on MT7623 SoC
From: PrasannaKumar Muralidharan @ 2017-04-14 4:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492142296.6147.19.camel@mtkswgap22>
On 14 April 2017 at 09:28, Sean Wang <sean.wang@mediatek.com> wrote:
>
> Hi PrasannaKumar,
>
> Add my comments inline
>
>>
>> Use readl_poll_timeout_atomic's return value or -EIO instead of
>> !!ready. This will simplify mtk_rng_read.
>>
>
> !!ready provided is in order to let blocking/non-blocking case could
> share same code path. And readl_poll_timeout_atomic only handles
> blocking case.
Missed this point. Makes sense. My previous comment about return value
in mtk_rng_read is invalid as I based it on a wrong assumption.
>
>> > +static int mtk_rng_read(struct hwrng *rng, void *buf, size_t max, bool wait)
>> > +{
>> > + struct mtk_rng *priv = to_mtk_rng(rng);
>> > + int retval = 0;
>> > +
>> > + while (max >= sizeof(u32)) {
>> > + if (!mtk_rng_wait_ready(rng, wait))
>> > + break;
>> > +
>> > + *(u32 *)buf = readl(priv->base + RNG_DATA);
>> > + retval += sizeof(u32);
>> > + buf += sizeof(u32);
>> > + max -= sizeof(u32);
>> > + }
>> > +
>> > + if (unlikely(wait && max))
>> > + dev_warn(priv->dev, "timeout might be not properly set\n");
>>
>> Is this really necessary? Better to choose proper timeout than
>> providing this warning message. In rare cases if the timeout could
>> occur due to some reason (may be a hardware fault) print appropriate
>> warning message.
>
> It is good, I will choose the proper timeout and remove the log in the
> next one.
>
>>
>> > + return retval || !wait ? retval : -EIO;
>> > +}
>>
>> Set retavl to mtk_rng_wait_ready and return retval.
>>
>
> Maybe i didn't get your points exactly. Adding some explanation about
> thoughts here.
>
> "return retval || !wait ? retval : -EIO;" I use can also help handling
> the both cases in one line which i think is elegant enough.
>
> And retval is accumulated with each round if some data's existing in
> hardware, so we don't return the value from mtk_rng_wait_ready().
retval can be 0 only when mkt_rng_wait_ready fails, returning 0 when
wait is true is confusing. Expected return value when 0 bytes is read
from device and wait is true is not clearly documented.
"return retval || !wait ? retval : -EIO;" is also fine.
Overall the code looks good to me. You can add:
Reviewed-by: PrasannaKumar Muralidharan <prasannatsmkumar@gmail.com>.
Regards,
PrasannaKumar
^ permalink raw reply
* [PATCH 1/2] phy: qcom-usb-hs: Replace the extcon API
From: Kishon Vijay Abraham I @ 2017-04-14 4:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <58F01B29.10304@samsung.com>
hi Chanwoo,
On Friday 14 April 2017 06:13 AM, Chanwoo Choi wrote:
> Hi Kishon,
>
> On 2017? 04? 13? 20:47, Kishon Vijay Abraham I wrote:
>> Hi Chanwoo,
>>
>> On Tuesday 28 March 2017 10:08 AM, Chanwoo Choi wrote:
>>> This patch uses the resource-managed extcon API for extcon_register_notifier()
>>> and replaces the deprecated extcon API as following:
>>> - (deprecated) extcon_get_cable_state_() -> extcon_get_state()
>>>
>>> Cc: Kishon Vijay Abraham I <kishon@ti.com>
>>> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
>>
>> I've missed merging this patch for the next merge window. If you want to take
>> this yourself.
>> Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
>
> I already posted the pull-request to GregKH for extcon subsystem.
> So, if possible, I hope you handle these patches.
> Even if these patches are not merged to 4.12-rc1, I'm ok.
> Just I want to handle them on your tree for next time.
Sure, I'll take them then.
Thanks
Kishon
>
>>
>> Thanks
>> Kishon
>>> ---
>>> drivers/phy/phy-qcom-usb-hs.c | 14 +++-----------
>>> 1 file changed, 3 insertions(+), 11 deletions(-)
>>>
>>> diff --git a/drivers/phy/phy-qcom-usb-hs.c b/drivers/phy/phy-qcom-usb-hs.c
>>> index 94dfbfd739c3..f630fa553b7d 100644
>>> --- a/drivers/phy/phy-qcom-usb-hs.c
>>> +++ b/drivers/phy/phy-qcom-usb-hs.c
>>> @@ -156,12 +156,12 @@ static int qcom_usb_hs_phy_power_on(struct phy *phy)
>>> }
>>>
>>> if (uphy->vbus_edev) {
>>> - state = extcon_get_cable_state_(uphy->vbus_edev, EXTCON_USB);
>>> + state = extcon_get_state(uphy->vbus_edev, EXTCON_USB);
>>> /* setup initial state */
>>> qcom_usb_hs_phy_vbus_notifier(&uphy->vbus_notify, state,
>>> uphy->vbus_edev);
>>> - ret = extcon_register_notifier(uphy->vbus_edev, EXTCON_USB,
>>> - &uphy->vbus_notify);
>>> + ret = devm_extcon_register_notifier(&ulpi->dev, uphy->vbus_edev,
>>> + EXTCON_USB, &uphy->vbus_notify);
>>> if (ret)
>>> goto err_ulpi;
>>> }
>>> @@ -180,16 +180,8 @@ static int qcom_usb_hs_phy_power_on(struct phy *phy)
>>>
>>> static int qcom_usb_hs_phy_power_off(struct phy *phy)
>>> {
>>> - int ret;
>>> struct qcom_usb_hs_phy *uphy = phy_get_drvdata(phy);
>>>
>>> - if (uphy->vbus_edev) {
>>> - ret = extcon_unregister_notifier(uphy->vbus_edev, EXTCON_USB,
>>> - &uphy->vbus_notify);
>>> - if (ret)
>>> - return ret;
>>> - }
>>> -
>>> regulator_disable(uphy->v3p3);
>>> regulator_disable(uphy->v1p8);
>>> clk_disable_unprepare(uphy->sleep_clk);
>>>
>>
>>
>>
>
>
^ permalink raw reply
* [PATCH 2/2] hwrng: mtk: Add driver for hardware random generator on MT7623 SoC
From: Sean Wang @ 2017-04-14 3:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANc+2y4Oj-sbSKnsTSK+kRYNewp7Pj0fEk_=dqULxWG08L77Eg@mail.gmail.com>
Hi PrasannaKumar,
Add my comments inline
On Thu, 2017-04-13 at 14:09 +0530, PrasannaKumar Muralidharan wrote:
> Hi Sean,
>
> Mostly looks good, have few minor comments.
>
> On 13 April 2017 at 12:35, <sean.wang@mediatek.com> wrote:
> > +static bool mtk_rng_wait_ready(struct hwrng *rng, bool wait)
> > +{
> > + struct mtk_rng *priv = to_mtk_rng(rng);
> > + int ready;
> > +
> > + ready = readl(priv->base + RNG_CTRL) & RNG_READY;
> > + if (!ready && wait)
> > + readl_poll_timeout_atomic(priv->base + RNG_CTRL, ready,
> > + ready & RNG_READY, USEC_POLL,
> > + TIMEOUT_POLL);
> > + return !!ready;
> > +}
>
> Use readl_poll_timeout_atomic's return value or -EIO instead of
> !!ready. This will simplify mtk_rng_read.
>
!!ready provided is in order to let blocking/non-blocking case could
share same code path. And readl_poll_timeout_atomic only handles
blocking case.
> > +static int mtk_rng_read(struct hwrng *rng, void *buf, size_t max, bool wait)
> > +{
> > + struct mtk_rng *priv = to_mtk_rng(rng);
> > + int retval = 0;
> > +
> > + while (max >= sizeof(u32)) {
> > + if (!mtk_rng_wait_ready(rng, wait))
> > + break;
> > +
> > + *(u32 *)buf = readl(priv->base + RNG_DATA);
> > + retval += sizeof(u32);
> > + buf += sizeof(u32);
> > + max -= sizeof(u32);
> > + }
> > +
> > + if (unlikely(wait && max))
> > + dev_warn(priv->dev, "timeout might be not properly set\n");
>
> Is this really necessary? Better to choose proper timeout than
> providing this warning message. In rare cases if the timeout could
> occur due to some reason (may be a hardware fault) print appropriate
> warning message.
It is good, I will choose the proper timeout and remove the log in the
next one.
>
> > + return retval || !wait ? retval : -EIO;
> > +}
>
> Set retavl to mtk_rng_wait_ready and return retval.
>
Maybe i didn't get your points exactly. Adding some explanation about
thoughts here.
"return retval || !wait ? retval : -EIO;" I use can also help handling
the both cases in one line which i think is elegant enough.
And retval is accumulated with each round if some data's existing in
hardware, so we don't return the value from mtk_rng_wait_ready().
> Regards,
> Prasanna
thanks for all your reviewing and suggestion
Sean
^ permalink raw reply
* [PATCH 8/8] ARM: dts: imx7d-sdb: Enable PCIe peripheral
From: Shawn Guo @ 2017-04-14 3:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170413133242.5068-9-andrew.smirnov@gmail.com>
On Thu, Apr 13, 2017 at 06:32:42AM -0700, Andrey Smirnov wrote:
> Enable PCIe peripheral on this board.
>
> Cc: yurovsky at gmail.com
> Cc: Sascha Hauer <kernel@pengutronix.de>
> Cc: Fabio Estevam <fabio.estevam@nxp.com>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Russell King <linux@armlinux.org.uk>
> Cc: devicetree at vger.kernel.org
> Cc: linux-kernel at vger.kernel.org
> Cc: linux-arm-kernel at lists.infradead.org
> Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
> ---
> arch/arm/boot/dts/imx7d-sdb.dts | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx7d-sdb.dts b/arch/arm/boot/dts/imx7d-sdb.dts
> index e0ff276..f77e26a 100644
> --- a/arch/arm/boot/dts/imx7d-sdb.dts
> +++ b/arch/arm/boot/dts/imx7d-sdb.dts
> @@ -352,6 +352,13 @@
> };
> };
>
> +&pcie {
> + pinctrl-names = "default";
> + reset-gpio = <&gpio_spi 1 GPIO_ACTIVE_LOW>;
> + disable-gpio = <&gpio_spi 0 GPIO_ACTIVE_LOW>;
I do not see this disable-gpio is documented or supported.
Shawn
> + status = "okay";
> +};
> +
> &pwm1 {
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_pwm1>;
> --
> 2.9.3
>
^ permalink raw reply
* [PATCH 6/8] ARM: dts: imx7d-sdb: Add GPIO expander node
From: Shawn Guo @ 2017-04-14 3:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170413133242.5068-7-andrew.smirnov@gmail.com>
On Thu, Apr 13, 2017 at 06:32:40AM -0700, Andrey Smirnov wrote:
> Add node for U38, a 74LV595PW serial-in shift register that acts as a
> GPIO expander on the board.
>
> Cc: yurovsky at gmail.com
> Cc: Sascha Hauer <kernel@pengutronix.de>
> Cc: Fabio Estevam <fabio.estevam@nxp.com>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Russell King <linux@armlinux.org.uk>
> Cc: devicetree at vger.kernel.org
> Cc: linux-kernel at vger.kernel.org
> Cc: linux-arm-kernel at lists.infradead.org
> Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
> ---
> arch/arm/boot/dts/imx7d-sdb.dts | 32 ++++++++++++++++++++++++++++++++
> 1 file changed, 32 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx7d-sdb.dts b/arch/arm/boot/dts/imx7d-sdb.dts
> index 5be01a1..e0ff276 100644
> --- a/arch/arm/boot/dts/imx7d-sdb.dts
> +++ b/arch/arm/boot/dts/imx7d-sdb.dts
> @@ -52,6 +52,30 @@
> reg = <0x80000000 0x80000000>;
> };
>
> + spi4 {
> + compatible = "spi-gpio";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_spi1>;
> + status = "okay";
The 'status' is not needed in this case.
> + gpio-sck = <&gpio1 13 0>;
> + gpio-mosi = <&gpio1 9 0>;
> + cs-gpios = <&gpio1 12 0>;
> + num-chipselects = <1>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + gpio_spi: gpio_spi at 0 {
gpio-expander might be a better node name?
> + compatible = "fairchild,74hc595";
> + gpio-controller;
> + #gpio-cells = <2>;
> + reg = <0>;
> + registers-number = <1>;
> + /* Enable PERI_3V3, SENSOR_RST_B and HDMI_RST*/
> + registers-default = /bits/ 8 <0x74>;
I do not see this property is documented or supported by kernel.
> + spi-max-frequency = <100000>;
> + };
> + };
> +
> regulators {
> compatible = "simple-bus";
> #address-cells = <1>;
> @@ -642,5 +666,13 @@
> fsl,pins = <
> MX7D_PAD_LPSR_GPIO1_IO01__PWM1_OUT 0x110b0
> >;
> +
> + pinctrl_spi1: spi1grp {
> + fsl,pins = <
> + MX7D_PAD_GPIO1_IO09__GPIO1_IO9 0x59
> + MX7D_PAD_GPIO1_IO12__GPIO1_IO12 0x59
> + MX7D_PAD_GPIO1_IO13__GPIO1_IO13 0x59
> + >;
> + };
> };
> };
> --
> 2.9.3
>
^ permalink raw reply
* [PATCH 4/8] ARM: dts: imx7s: Add node for GPC
From: Shawn Guo @ 2017-04-14 3:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170413133242.5068-5-andrew.smirnov@gmail.com>
On Thu, Apr 13, 2017 at 06:32:38AM -0700, Andrey Smirnov wrote:
> Add node for GPC and specify as a parent interrupt controller for SoC bus.
>
> Cc: yurovsky at gmail.com
> Cc: Sascha Hauer <kernel@pengutronix.de>
> Cc: Fabio Estevam <fabio.estevam@nxp.com>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Russell King <linux@armlinux.org.uk>
> Cc: devicetree at vger.kernel.org
> Cc: linux-kernel at vger.kernel.org
> Cc: linux-arm-kernel at lists.infradead.org
> Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
> ---
> arch/arm/boot/dts/imx7s.dtsi | 27 ++++++++++++++++++++++++++-
> 1 file changed, 26 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
> index 8fee299..1a7058f 100644
> --- a/arch/arm/boot/dts/imx7s.dtsi
> +++ b/arch/arm/boot/dts/imx7s.dtsi
> @@ -42,6 +42,7 @@
> */
>
> #include <dt-bindings/clock/imx7d-clock.h>
> +#include <dt-bindings/power/imx7-power.h>
> #include <dt-bindings/gpio/gpio.h>
> #include <dt-bindings/input/input.h>
> #include <dt-bindings/interrupt-controller/arm-gic.h>
> @@ -119,7 +120,7 @@
> #address-cells = <1>;
> #size-cells = <1>;
> compatible = "simple-bus";
> - interrupt-parent = <&intc>;
> + interrupt-parent = <&gpc>;
> ranges;
>
> funnel at 30041000 {
> @@ -301,6 +302,7 @@
> interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
> #interrupt-cells = <3>;
> interrupt-controller;
> + interrupt-parent = <&intc>;
> reg = <0x31001000 0x1000>,
> <0x31002000 0x2000>,
> <0x31004000 0x2000>,
> @@ -309,6 +311,7 @@
>
> timer {
> compatible = "arm,armv7-timer";
> + interrupt-parent = <&intc>;
> interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
> <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
> <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
> @@ -564,6 +567,28 @@
> interrupts = <GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>;
> #reset-cells = <1>;
> };
> +
> + gpc: gpc at 303a0000 {
> + compatible = "fsl,imx7d-gpc";
> + reg = <0x303a0000 0x10000>;
> + interrupt-controller;
> + interrupts = <GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>;
> + #interrupt-cells = <3>;
> + interrupt-parent = <&intc>;
> + #power-domain-cells = <1>;
> +
> + pgc {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + pgc_pcie_phy: pgc-pcie-phy-domain {
The node name should be something generic and has a unit-address when
there is a 'reg' property in the node.
> + #power-domain-cells = <0>;
> +
Drop this newline.
Shawn
> + reg = <IMX7_POWER_DOMAIN_PCIE_PHY>;
> + power-supply = <®_1p0d>;
> + };
> + };
> + };
> };
>
> aips2: aips-bus at 30400000 {
> --
> 2.9.3
>
^ permalink raw reply
* [PATCH 2/2] hwrng: mtk: Add driver for hardware random generator on MT7623 SoC
From: Sean Wang @ 2017-04-14 3:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170413110643.GA413@Red>
Hi Corentin,
I all agree and appreciate your careful reviewing.
They will be added into the next one.
Sean
On Thu, 2017-04-13 at 13:06 +0200, Corentin Labbe wrote:
> Hello
>
> I have some minor comment below:
>
> On Thu, Apr 13, 2017 at 03:05:08PM +0800, sean.wang at mediatek.com wrote:
> > From: Sean Wang <sean.wang@mediatek.com>
> >
> > This patch adds support for hardware random generator on MT7623 SoC
> > and should also work on other similar Mediatek SoCs. Currently,
> > the driver is already tested successfully with rng-tools.
> >
> > Signed-off-by: Sean Wang <sean.wang@mediatek.com>
> > ---
> > drivers/char/hw_random/Kconfig | 16 +++-
> > drivers/char/hw_random/Makefile | 2 +-
> > drivers/char/hw_random/mtk-rng.c | 174 +++++++++++++++++++++++++++++++++++++++
> > 3 files changed, 190 insertions(+), 2 deletions(-)
> > create mode 100644 drivers/char/hw_random/mtk-rng.c
> >
> > diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig
> > index 0cafe08..af782ce 100644
> > --- a/drivers/char/hw_random/Kconfig
> > +++ b/drivers/char/hw_random/Kconfig
> > @@ -419,10 +419,24 @@ config HW_RANDOM_CAVIUM
> > Generator hardware found on Cavium SoCs.
> >
> > To compile this driver as a module, choose M here: the
> > - module will be called cavium_rng.
> > + module will be called mtk-rng.
>
> Unwanted change
>
> >
> > If unsure, say Y.
> >
> > +config HW_RANDOM_MTK
> > + tristate "Mediatek Random Number Generator support"
> > + depends on HW_RANDOM
> > + depends on ARCH_MEDIATEK || COMPILE_TEST
> > + default y
> > + ---help---
> > + This driver provides kernel-side support for the Random Number
> > + Generator hardware found on Mediatek SoCs.
> > +
> > + To compile this driver as a module, choose M here. the
> > + module will be called mtk-rng.
> > +
> > + If unsure, say Y.
> > +
> > endif # HW_RANDOM
> >
> > config UML_RANDOM
> > diff --git a/drivers/char/hw_random/Makefile b/drivers/char/hw_random/Makefile
> > index 5f52b1e..68be716 100644
> > --- a/drivers/char/hw_random/Makefile
> > +++ b/drivers/char/hw_random/Makefile
> > @@ -1,7 +1,6 @@
> > #
> > # Makefile for HW Random Number Generator (RNG) device drivers.
> > #
> > -
>
> Another unwanted change
>
> > obj-$(CONFIG_HW_RANDOM) += rng-core.o
> > rng-core-y := core.o
> > obj-$(CONFIG_HW_RANDOM_TIMERIOMEM) += timeriomem-rng.o
> > @@ -36,3 +35,4 @@ obj-$(CONFIG_HW_RANDOM_STM32) += stm32-rng.o
> > obj-$(CONFIG_HW_RANDOM_PIC32) += pic32-rng.o
> > obj-$(CONFIG_HW_RANDOM_MESON) += meson-rng.o
> > obj-$(CONFIG_HW_RANDOM_CAVIUM) += cavium-rng.o cavium-rng-vf.o
> > +obj-$(CONFIG_HW_RANDOM_MTK) += mtk-rng.o
> > diff --git a/drivers/char/hw_random/mtk-rng.c b/drivers/char/hw_random/mtk-rng.c
> > new file mode 100644
> > index 0000000..6561ee0
> > --- /dev/null
> > +++ b/drivers/char/hw_random/mtk-rng.c
> > @@ -0,0 +1,174 @@
> > +/*
> > + * Driver for Mediatek Hardware Random Number Generator
> > + *
> > + * Copyright (C) 2017 Sean Wang <sean.wang@mediatek.com>
> > + *
> > + * This program is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU General Public License as
> > + * published by the Free Software Foundation; either version 2 of
> > + * the License, or (at your option) any later version.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > + * GNU General Public License for more details.
> > + */
> > +#define MTK_RNG_DEV KBUILD_MODNAME
> > +
> > +#include <linux/clk.h>
> > +#include <linux/delay.h>
> > +#include <linux/err.h>
> > +#include <linux/hw_random.h>
> > +#include <linux/io.h>
> > +#include <linux/iopoll.h>
> > +#include <linux/kernel.h>
> > +#include <linux/module.h>
> > +#include <linux/of.h>
> > +#include <linux/platform_device.h>
> > +
> > +#define USEC_POLL 2
> > +#define TIMEOUT_POLL 20
> > +
> > +#define RNG_CTRL 0x00
> > +#define RNG_EN BIT(0)
> > +#define RNG_READY BIT(31)
>
> Keep only one space between define and name
>
> > +
> > +#define RNG_DATA 0x08
> > +
> > +#define to_mtk_rng(p) container_of(p, struct mtk_rng, rng)
> > +
> > +struct mtk_rng {
> > + struct device *dev;
> > + void __iomem *base;
> > + struct clk *clk;
> > + struct hwrng rng;
> > +};
> > +
> > +static int mtk_rng_init(struct hwrng *rng)
> > +{
> > + struct mtk_rng *priv = to_mtk_rng(rng);
> > + u32 val;
> > + int err;
> > +
> > + err = clk_prepare_enable(priv->clk);
> > + if (err)
> > + return err;
> > +
> > + val = readl(priv->base + RNG_CTRL);
> > + val |= RNG_EN;
> > + writel(val, priv->base + RNG_CTRL);
> > +
> > + return 0;
> > +}
> > +
> > +static void mtk_rng_cleanup(struct hwrng *rng)
> > +{
> > + struct mtk_rng *priv = to_mtk_rng(rng);
> > + u32 val;
> > +
> > + val = readl(priv->base + RNG_CTRL);
> > + val &= ~RNG_EN;
> > + writel(val, priv->base + RNG_CTRL);
> > +
> > + clk_disable_unprepare(priv->clk);
> > +}
> > +
> > +static bool mtk_rng_wait_ready(struct hwrng *rng, bool wait)
> > +{
> > + struct mtk_rng *priv = to_mtk_rng(rng);
> > + int ready;
> > +
> > + ready = readl(priv->base + RNG_CTRL) & RNG_READY;
> > + if (!ready && wait)
> > + readl_poll_timeout_atomic(priv->base + RNG_CTRL, ready,
> > + ready & RNG_READY, USEC_POLL,
> > + TIMEOUT_POLL);
> > + return !!ready;
> > +}
> > +
> > +static int mtk_rng_read(struct hwrng *rng, void *buf, size_t max, bool wait)
> > +{
> > + struct mtk_rng *priv = to_mtk_rng(rng);
> > + int retval = 0;
> > +
> > + while (max >= sizeof(u32)) {
> > + if (!mtk_rng_wait_ready(rng, wait))
> > + break;
> > +
> > + *(u32 *)buf = readl(priv->base + RNG_DATA);
> > + retval += sizeof(u32);
> > + buf += sizeof(u32);
> > + max -= sizeof(u32);
> > + }
> > +
> > + if (unlikely(wait && max))
> > + dev_warn(priv->dev, "timeout might be not properly set\n");
> > +
> > + return retval || !wait ? retval : -EIO;
> > +}
> > +
> > +static int mtk_rng_probe(struct platform_device *pdev)
> > +{
> > + struct resource *res;
> > + int ret;
> > + struct mtk_rng *priv;
> > +
> > + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > + if (!res) {
> > + dev_err(&pdev->dev, "no iomem resource\n");
> > + return -ENXIO;
> > + }
> > +
> > + priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
> > + if (!priv)
> > + return -ENOMEM;
> > +
> > + priv->dev = &pdev->dev;
> > + priv->rng.name = pdev->name;
> > + priv->rng.init = mtk_rng_init;
> > + priv->rng.cleanup = mtk_rng_cleanup;
> > + priv->rng.read = mtk_rng_read;
> > +
> > + priv->clk = devm_clk_get(&pdev->dev, "rng");
> > + if (IS_ERR(priv->clk)) {
> > + ret = PTR_ERR(priv->clk);
> > + dev_err(&pdev->dev, "no clock for device: %d\n", ret);
> > + return ret;
> > + }
> > +
> > + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>
> You get that resource twice
>
> Regards
> Corentin Labbe
^ 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