* [LINUX RFC v4 3/4] mtd: spi-nor: add stripe support
From: Naga Sureshkumar Relli @ 2016-11-30 9:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <68ca0f19-e534-3361-11f0-6566626380fe@atmel.com>
Hi Cyrille,
> I have not finished to review the whole series yet but here some first
> comments:
Thanks for reviewing these patch series.
>
> Le 27/11/2016 ? 09:33, Naga Sureshkumar Relli a ?crit :
> > This patch adds stripe support and it is needed for GQSPI parallel
> > configuration mode by:
> >
> > - Adding required parameters like stripe and shift to spi_nor
> > structure.
> > - Initializing all added parameters in spi_nor_scan()
> > - Updating read_sr() and read_fsr() for getting status from both
> > flashes
> > - Increasing page_size, sector_size, erase_size and toatal flash
> > size as and when required.
> > - Dividing address by 2
> > - Updating spi->master->flags for qspi driver to change CS
> >
> > Signed-off-by: Naga Sureshkumar Relli <nagasure@xilinx.com>
> > ---
> > Changes for v4:
> > - rename isparallel to stripe
> > Changes for v3:
> > - No change
> > Changes for v2:
> > - Splitted to separate MTD layer changes from SPI core changes
> > ---
> > drivers/mtd/spi-nor/spi-nor.c | 130
> ++++++++++++++++++++++++++++++++----------
> > include/linux/mtd/spi-nor.h | 2 +
> > 2 files changed, 103 insertions(+), 29 deletions(-)
> >
> > diff --git a/drivers/mtd/spi-nor/spi-nor.c
> > b/drivers/mtd/spi-nor/spi-nor.c index d0fc165..4252239 100644
> > --- a/drivers/mtd/spi-nor/spi-nor.c
> > +++ b/drivers/mtd/spi-nor/spi-nor.c
> > @@ -22,6 +22,7 @@
> > #include <linux/of_platform.h>
> > #include <linux/spi/flash.h>
> > #include <linux/mtd/spi-nor.h>
> > +#include <linux/spi/spi.h>
> >
> > /* Define max times to check status register before we give up. */
> >
> > @@ -89,15 +90,24 @@ static const struct flash_info
> > *spi_nor_match_id(const char *name); static int read_sr(struct
> > spi_nor *nor) {
> > int ret;
> > - u8 val;
> > + u8 val[2];
> >
> > - ret = nor->read_reg(nor, SPINOR_OP_RDSR, &val, 1);
> > - if (ret < 0) {
> > - pr_err("error %d reading SR\n", (int) ret);
> > - return ret;
> > + if (nor->stripe) {
> > + ret = nor->read_reg(nor, SPINOR_OP_RDSR, &val[0], 2);
> > + if (ret < 0) {
> > + pr_err("error %d reading SR\n", (int) ret);
> > + return ret;
> > + }
> > + val[0] |= val[1];
> Why '|' rather than '&' ?
> I guess because of the 'Write In Progress/Busy' bit: when called by
> spi_nor_sr_ready(), you want to be sure that this 'BUSY' bit is cleared on
> both memories.
>
> But what about when the Status Register is read for purpose other than
> checking the state of the 'BUSY' bit?
>
Yes you are correct, I will change this.
> What about SPI controllers supporting more than 2 memories in parallel?
>
> This solution might fit the ZynqMP controller but doesn't look so generic.
>
> > + } else {
> > + ret = nor->read_reg(nor, SPINOR_OP_RDSR, &val[0], 1);
> > + if (ret < 0) {
> > + pr_err("error %d reading SR\n", (int) ret);
> > + return ret;
> > + }
> > }
> >
> > - return val;
> > + return val[0];
> > }
> >
> > /*
> > @@ -108,15 +118,24 @@ static int read_sr(struct spi_nor *nor) static
> > int read_fsr(struct spi_nor *nor) {
> > int ret;
> > - u8 val;
> > + u8 val[2];
> >
> > - ret = nor->read_reg(nor, SPINOR_OP_RDFSR, &val, 1);
> > - if (ret < 0) {
> > - pr_err("error %d reading FSR\n", ret);
> > - return ret;
> > + if (nor->stripe) {
> > + ret = nor->read_reg(nor, SPINOR_OP_RDFSR, &val[0], 2);
> > + if (ret < 0) {
> > + pr_err("error %d reading FSR\n", ret);
> > + return ret;
> > + }
> > + val[0] &= val[1];
> Same comment here: why '&' rather than '|'?
> Surely because of the the 'READY' bit which should be set for both memories.
I will update this also.
>
> > + } else {
> > + ret = nor->read_reg(nor, SPINOR_OP_RDFSR, &val[0], 1);
> > + if (ret < 0) {
> > + pr_err("error %d reading FSR\n", ret);
> > + return ret;
> > + }
> > }
> >
> > - return val;
> > + return val[0];
> > }
> >
> > /*
> > @@ -290,9 +309,16 @@ static int spi_nor_wait_till_ready(struct spi_nor
> *nor)
> > */
> > static int erase_chip(struct spi_nor *nor) {
> > + u32 ret;
> > +
> > dev_dbg(nor->dev, " %lldKiB\n", (long long)(nor->mtd.size >> 10));
> >
> > - return nor->write_reg(nor, SPINOR_OP_CHIP_ERASE, NULL, 0);
> > + ret = nor->write_reg(nor, SPINOR_OP_CHIP_ERASE, NULL, 0);
> > + if (ret)
> > + return ret;
> > +
> > + return ret;
> > +
>
> if (ret)
> return ret;
> else
> return ret;
>
> This chunk should be removed, it doesn't ease the patch review ;)
Ok, I will remove.
>
> > }
> >
> > static int spi_nor_lock_and_prep(struct spi_nor *nor, enum
> > spi_nor_ops ops) @@ -349,7 +375,7 @@ static int
> > spi_nor_erase_sector(struct spi_nor *nor, u32 addr) static int
> > spi_nor_erase(struct mtd_info *mtd, struct erase_info *instr) {
> > struct spi_nor *nor = mtd_to_spi_nor(mtd);
> > - u32 addr, len;
> > + u32 addr, len, offset;
> > uint32_t rem;
> > int ret;
> >
> > @@ -399,9 +425,13 @@ static int spi_nor_erase(struct mtd_info *mtd,
> struct erase_info *instr)
> > /* "sector"-at-a-time erase */
> > } else {
> > while (len) {
> > +
> > write_enable(nor);
> > + offset = addr;
> > + if (nor->stripe)
> > + offset /= 2;
>
> I guess this should be /= 4 for controllers supporting 4 memories in parallel.
> Shouldn't you use nor->shift and define shift as an unsigned int instead of a
> bool?
> offset >>= nor->shift;
>
Yes we can use this shift, I will update
> Anyway, by tuning the address here in spi-nor.c rather than in the SPI
> controller driver, you impose a model to support parallel memories that
> might not be suited to other controllers.
For this ZynqMP GQSPI controller parallel configuration, globally spi-nor should know about this stripe feature
And based on that address has to change.
As I mentioned in cover letter, this controller in parallel configuration will work with even addresses only.
i.e. Before creating address format(m25p_addr2cmd) in mtd layer, spi-nor should change that address based on stripe option.
I am updating this offset based on stripe option, and stripe option will update by reading dt property in nor_scan().
So the controller which doesn't support, then the stripe will be zero.
Or Can you please suggest any other way?
>
> >
> > - ret = spi_nor_erase_sector(nor, addr);
> > + ret = spi_nor_erase_sector(nor, offset);
> > if (ret)
> > goto erase_err;
> >
> > @@ -525,6 +555,8 @@ static int stm_lock(struct spi_nor *nor, loff_t ofs,
> uint64_t len)
> > bool use_top;
> > int ret;
> >
> > + ofs = ofs >> nor->shift;
> > +
> > status_old = read_sr(nor);
> > if (status_old < 0)
> > return status_old;
> > @@ -610,6 +642,8 @@ static int stm_unlock(struct spi_nor *nor, loff_t ofs,
> uint64_t len)
> > bool use_top;
> > int ret;
> >
> > + ofs = ofs >> nor->shift;
> > +
> > status_old = read_sr(nor);
> > if (status_old < 0)
> > return status_old;
> > @@ -709,6 +743,8 @@ static int spi_nor_lock(struct mtd_info *mtd, loff_t
> ofs, uint64_t len)
> > if (ret)
> > return ret;
> >
> > + ofs = ofs >> nor->shift;
> > +
> > ret = nor->flash_lock(nor, ofs, len);
> >
> > spi_nor_unlock_and_unprep(nor, SPI_NOR_OPS_UNLOCK); @@ -
> 724,6 +760,8
> > @@ static int spi_nor_unlock(struct mtd_info *mtd, loff_t ofs, uint64_t
> len)
> > if (ret)
> > return ret;
> >
> > + ofs = ofs >> nor->shift;
> > +
> > ret = nor->flash_unlock(nor, ofs, len);
> >
> > spi_nor_unlock_and_unprep(nor, SPI_NOR_OPS_LOCK); @@ -
> 1018,6 +1056,9
> > @@ static const struct flash_info *spi_nor_read_id(struct spi_nor *nor)
> > u8 id[SPI_NOR_MAX_ID_LEN];
> > const struct flash_info *info;
> >
> > + nor->spi->master->flags &= ~(SPI_MASTER_BOTH_CS |
> > + SPI_MASTER_DATA_STRIPE);
> > +
> > tmp = nor->read_reg(nor, SPINOR_OP_RDID, id,
> SPI_NOR_MAX_ID_LEN);
> > if (tmp < 0) {
> > dev_dbg(nor->dev, "error %d reading JEDEC ID\n", tmp);
> @@ -1041,6
> > +1082,7 @@ static int spi_nor_read(struct mtd_info *mtd, loff_t from,
> > size_t len, {
> > struct spi_nor *nor = mtd_to_spi_nor(mtd);
> > int ret;
> > + u32 offset = from;
> >
> > dev_dbg(nor->dev, "from 0x%08x, len %zd\n", (u32)from, len);
> >
> > @@ -1049,7 +1091,13 @@ static int spi_nor_read(struct mtd_info *mtd,
> loff_t from, size_t len,
> > return ret;
> >
> > while (len) {
> > - ret = nor->read(nor, from, len, buf);
> > +
> > + offset = from;
> > +
> > + if (nor->stripe)
> > + offset /= 2;
> > +
> > + ret = nor->read(nor, offset, len, buf);
> > if (ret == 0) {
> > /* We shouldn't see 0-length reads */
> > ret = -EIO;
> > @@ -1161,6 +1209,7 @@ static int spi_nor_write(struct mtd_info *mtd,
> loff_t to, size_t len,
> > struct spi_nor *nor = mtd_to_spi_nor(mtd);
> > size_t page_offset, page_remain, i;
> > ssize_t ret;
> > + u32 offset;
> >
> > dev_dbg(nor->dev, "to 0x%08x, len %zd\n", (u32)to, len);
> >
> > @@ -1178,9 +1227,13 @@ static int spi_nor_write(struct mtd_info *mtd,
> loff_t to, size_t len,
> > /* the size of data remaining on the first page */
> > page_remain = min_t(size_t,
> > nor->page_size - page_offset, len - i);
> > + offset = (to + i);
> > +
> > + if (nor->stripe)
> > + offset /= 2;
> >
> > write_enable(nor);
> > - ret = nor->write(nor, to + i, page_remain, buf + i);
> > + ret = nor->write(nor, (offset), page_remain, buf + i);
> > if (ret < 0)
> > goto write_err;
> > written = ret;
> > @@ -1302,22 +1355,22 @@ static int spi_nor_check(struct spi_nor *nor)
> >
> > int spi_nor_scan(struct spi_nor *nor, const char *name, enum
> > read_mode mode) {
> > - const struct flash_info *info = NULL;
> > + struct flash_info *info = NULL;
>
> You should not remove the const and should not try to modify members of
> *info.
>
> > struct device *dev = nor->dev;
> > struct mtd_info *mtd = &nor->mtd;
> > struct device_node *np = spi_nor_get_flash_node(nor);
> > - int ret;
> > - int i;
> > + struct device_node *np_spi;
> > + int ret, i, xlnx_qspi_mode;
> >
> > ret = spi_nor_check(nor);
> > if (ret)
> > return ret;
> >
> > if (name)
> > - info = spi_nor_match_id(name);
> > + info = (struct flash_info *)spi_nor_match_id(name);
> > /* Try to auto-detect if chip name wasn't specified or not found */
> > if (!info)
> > - info = spi_nor_read_id(nor);
> > + info = (struct flash_info *)spi_nor_read_id(nor);
> > if (IS_ERR_OR_NULL(info))
> > return -ENOENT;
> >
> Both spi_nor_match_id() and spi_nor_read_id(), when they succeed, return
> a pointer to an entry of the spi_nor_ids[] array, which is located in a read-
> only memory area.
>
> Since your patch doesn't remove the const attribute of the spi_nor_ids[], I
> wonder whether it has been tested. I expect it not to work on most
> architecture.
>
> Anyway spi_nor_ids[] should remain const. Let's take the case of eXecution
> In Place (XIP) from an external memory: if spi_nor_ids[] is const, it can be
> read directly from this external (read-only) memory and we never need to
> copy the array in RAM, so we save some KB of RAM.
> This is just an example but I guess we can find other reasons to keep this
> array const.
>
> > @@ -1341,7 +1394,7 @@ int spi_nor_scan(struct spi_nor *nor, const char
> *name, enum read_mode mode)
> > */
> > dev_warn(dev, "found %s, expected %s\n",
> > jinfo->name, info->name);
> > - info = jinfo;
> > + info = (struct flash_info *)jinfo;
> > }
> > }
> >
> > @@ -1370,6 +1423,27 @@ int spi_nor_scan(struct spi_nor *nor, const char
> *name, enum read_mode mode)
> > mtd->size = info->sector_size * info->n_sectors;
> > mtd->_erase = spi_nor_erase;
> > mtd->_read = spi_nor_read;
> > +#ifdef CONFIG_OF
> > + np_spi = of_get_next_parent(np);
> > +
> > + if (of_property_read_u32(np_spi, "xlnx,qspi-mode",
> > + &xlnx_qspi_mode) < 0) {
> This really looks controller specific so should not be placed in the generic spi-
> nor.c file.
Const is removed in info struct, because to update info members based parallel configuration.
As I mentioned above, for this parallel configuration, mtd and spi-nor should know the details like
mtd->size, info->sectors, sector_size and page_size.
So during spi_nor_scan only mtd will update all these details, that's why I have added controller specific check to update those.
Can you please suggest, any other way to let mtd and spi-nor to know about this configuration without touching the core layers?
Please let me know, if I missed providing any required info.
>
> > + nor->shift = 0;
> > + nor->stripe = 0;
> > + } else if (xlnx_qspi_mode == 2) {
> > + nor->shift = 1;
> > + info->sector_size <<= nor->shift;
> > + info->page_size <<= nor->shift;
> Just don't modify *info members! :)
>
>
> > + mtd->size <<= nor->shift;
> > + nor->stripe = 1;
> > + nor->spi->master->flags |= (SPI_MASTER_BOTH_CS |
> > + SPI_MASTER_DATA_STRIPE);
> > + }
> > +#else
> > + /* Default to single */
> > + nor->shift = 0;
> > + nor->stripe = 0;
> > +#endif
> Best regards,
>
> Cyrille
Thanks,
Naga Sureshkumar Relli
^ permalink raw reply
* [PATCH v7 0/8] drm: sun8i: Add DE2 HDMI video support
From: Jean-Francois Moine @ 2016-11-30 9:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161129213650.uqcgekodq77wlmxs@lukather>
On Tue, 29 Nov 2016 22:36:50 +0100
Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
> On Tue, Nov 29, 2016 at 11:18:35AM +0100, Jean-Francois Moine wrote:
> > This patchset series adds HDMI video support to the Allwinner
> > sun8i SoCs which include the display engine 2 (DE2).
> > The driver contains the code for the A83T and H3 SoCs, and
> > some H3 boards, but it could be used/extended for other SoCs
> > (A64, H2, H5) and boards (Banana PIs, Orange PIs).
>
> Honestly, I'm getting a bit worried by the fact that you ignore
> reviews.
>
> On the important reviews that you got that are to be seen as major
> issues that block the inclusion, we have:
> - The fact that the HDMI driver is actually just a designware IP,
> and while you should use the driver that already exists, you just
> duplicated all that code.
The DW registers in the A83T and H3 are obfuscated, so, the code in
bridge/DW cannot be used as it is. There should be either a translation
table or a function to compute the register addresses.
More, it is not sure that the bridge/DW code would work with
Allwinner's SoCs. It seems that they got some schematics from
DesignWare, but, is it really the same hardware? Also, if some changes
had to be done in the bridge code, I could not check if this would
break or not the other SoCs.
Eventually, I went the same way as omap/hdmi5: different driver.
> - The fact that you ignored Rob (v6) and I (v5) comment on using OF
> graph to model the connection between the display engine and the
> TCON. Something that Laurent also pointed out in this version.
I simply use the drm function drm_of_component_probe().
If this one is in the DRM core, why should I not use it?
If it must not be used, it would be nice to mark it as deprecated and
to update the code of the drivers which are using it.
> - The fact that you ignored that you needed an HDMI connector node
> as a child of the HDMI controller. This has been reported by Rob
> (v6) and yet again in this version by Laurent.
As I don't know what is a DT 'connector', I cannot go further.
I hope Laurent will give me clearer explanations and a real example.
> - And finally the fact that we can't have several display engine in
> parallel, if needs be. This has happened in the past already on
> Allwinner SoCs, so it's definitely something we should consider in
> the DT bindings, since we can't break them.
IIRC, I proposed my driver before yours, and the DE2 is completely
different from the other display engines.
What you are telling is "add more code to already complex code and have
a big driver for all SoCs in each kernels".
I think it should be better to have small modules, each one treating
specific hardware, and to let only the needed code in the kernel memory
at startup time.
> Until those are fixed, I cannot see how this driver can be merged,
> unfortunately.
No problem. I just wanted to help people by giving the job I did on the
boards I have. My boards are working for almost one year, fine enough
for I use them as daily desktop computers. I don't want to spend one
more year for having my code in the Linux kernel: there are so much
other exciting things to do...
--
Ken ar c'henta? | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
^ permalink raw reply
* [PATCH v10 00/13] MT2701 DRM support
From: CK Hu @ 2016-11-30 8:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480070076-6196-1-git-send-email-yt.shen@mediatek.com>
Hi, YT:
On Fri, 2016-11-25 at 18:34 +0800, YT Shen wrote:
> This is MT2701 DRM support PATCH v10, based on 4.9-rc1.
> We add DSI interrupt control, transfer function for MIPI DSI panel support.
> Most codes are the same, except some register changed.
>
> For example:
> - DISP_OVL address offset changed, color format definition changed.
> - DISP_RDMA fifo size changed.
> - DISP_COLOR offset changed.
> - MIPI_TX setting changed.
>
> We add a new component DDP_COMPONENT_BLS, and the connections are updated.
> OVL -> RDMA -> COLOR -> BLS -> DSI
> RDMA -> DPI
> And we have shadow register support in MT2701.
>
> We remove dts patch from the patch series, which depends on MT2701 CCF and scpsys.
>
Some patches in this series conflict with Linux 4.9-rc7.
Once you send next patches, please base on Linux 4.9-rc7 or later
version.
Regards,
CK
> Changes since v9:
> - Split DSI patches into smaller parts
> - Use a real linux errno for return value
> - Add error handling in mtk_output_dsi_enable()
> - Remove unused changes and redundant delays
> - Add helpers and macros for configuration
> - Combine "drm/mediatek: rename macros, add chip prefix" and "drm/mediatek: add *driver_data for different hardware setting"
>
> Changes since v8:
> - enable 3 DSI interrupts only
> - move mtk_dsi_wait_for_irq_done() to the patch of irq control
> - use the name BLS in DRM driver part
> - move BLS declaration to a separate patch
> - update mtk_dsi_switch_to_cmd_mode()
> - update mtk_output_dsi_enable() and mtk_output_dsi_disable()
>
> Changes since v7:
> - Remove redundant codes
> - Move the definition of DDP_COMPONENT_BLS to patch of "drm/mediatek: update display module connections"
> - Move _dsi_irq_wait_queue into platform driver data
> - Move mtk_dsi_irq_data_clear() to patch of "drm/mediatek: add dsi interrupt control"
> - Add more descriptions in the commit messages
>
> Changes since v6:
> - Change data type of irq_data to u32
> - Rewrite mtk_dsi_host_transfer() for simplify
> - Move some MIPI_TX config to patch of "drm/mediatek: add *driver_data for different hardware settings".
> - Remove device tree from this patch series
>
> Changes since v5:
> - Remove DPI device tree and compatible string
> - Use one wait queue to handle interrupt status
> - Update the interrupt check flow and DSI_INT_ALL_BITS
> - Use same function for host read/write command
> - various fixes
>
> Changes since v4:
> - Add messages when timeout in mtk_disp_mutex_acquire()
> - Add descriptions for DISP_REG_MUTEX registers
> - Move connection settings for display modules to a separate patch
> - Remove 'mt2701-disp-wdma' because it is unused
> - Move cleaning up and renaming to a separate patch
> - Use wait_event_interruptible_timeout() to replace polling
> - Remove irq_num from mtk_dsi structure
> - Remove redundant and debug codes
>
> Changes since v3:
> - Add DSI support for MIPI DSI panels
> - Update BLS binding to PWM nodes
> - Remove ufoe device nodes
> - Remove redundant parentheses
> - Remove global variable initialization
>
> Changes since v2:
> - Rename mtk_ddp_mux_sel to mtk_ddp_sout_sel
> - Update mt2701_mtk_ddp_ext components
> - Changed to prefix naming
> - Reorder the patch series
> - Use of_device_get_match_data() to get driver private data
> - Use iopoll macros to implement mtk_disp_mutex_acquire()
> - Removed empty device tree nodes
>
> Changes since v1:
> - Removed BLS bindings and codes, which belong to pwm driver
> - Moved mtk_disp_mutex_acquire() just before mtk_crtc_ddp_config()
> - Split patch into smaller parts
> - Added const keyword to constant structure
> - Removed codes for special memory align
>
> Thanks,
> yt.shen
>
> YT Shen (11):
> drm/mediatek: add helpers for coverting from the generic components
> drm/mediatek: add *driver_data for different hardware settings
> drm/mediatek: add shadow register support
> drm/mediatek: add BLS component
> drm/mediatek: update display module connections
> drm/mediatek: cleaning up and refine
> drm/mediatek: add mipi_tx data rate check
> drm/mediatek: add dsi ulp mode control
> drm/mediatek: add dsi rxtx control
> drm/mediatek: update DSI sub driver flow for sending commands to panel
> drm/mediatek: add support for Mediatek SoC MT2701
>
> shaoming chen (2):
> drm/mediatek: add dsi interrupt control
> drm/mediatek: add dsi transfer function
>
> drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 64 +++--
> drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 39 ++-
> drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 76 +++--
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 138 ++++++---
> drivers/gpu/drm/mediatek/mtk_drm_ddp.h | 2 +
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 41 ++-
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 7 +
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 54 +++-
> drivers/gpu/drm/mediatek/mtk_drm_drv.h | 9 +
> drivers/gpu/drm/mediatek/mtk_dsi.c | 430 ++++++++++++++++++++++++----
> drivers/gpu/drm/mediatek/mtk_mipi_tx.c | 42 ++-
> 11 files changed, 737 insertions(+), 165 deletions(-)
>
^ permalink raw reply
* [PATCH 3/3] ARM: fix asm symbol exports
From: Nicolas Pitre @ 2016-11-30 8:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480495824-4151-1-git-send-email-nicolas.pitre@linaro.org>
This assumes a revert of commit 8478132a87 before being applied.
Annotate exported assembly symbols so they are properly checksummed
when modversion is selected.
Also, don't use \name with EXPORT_SYMBOL() in bitops.h. Here \name is
an assembler macro argument which is not subject to preprocessor
substitutions. And the assembler doesn't handle preprocessor macros
either. That has the effect of breaking CONFIG_TRIM_UNUSED_KSYMS=y.
Signed-off-by: Nicolas Pitre <nico@linaro.org>
---
arch/arm/boot/compressed/voidproto.h | 1 +
arch/arm/kernel/head.S | 1 +
arch/arm/kernel/smccc-call.S | 2 ++
arch/arm/lib/ashldi3.S | 5 +++--
arch/arm/lib/ashrdi3.S | 5 +++--
arch/arm/lib/bitops.h | 14 ++++++++++----
arch/arm/lib/bswapsdi2.S | 5 +++--
arch/arm/lib/changebit.S | 2 +-
arch/arm/lib/clear_user.S | 1 +
arch/arm/lib/clearbit.S | 2 +-
arch/arm/lib/copy_from_user.S | 1 +
arch/arm/lib/copy_page.S | 1 +
arch/arm/lib/copy_to_user.S | 1 +
arch/arm/lib/csumipv6.S | 1 +
arch/arm/lib/csumpartial.S | 1 +
arch/arm/lib/csumpartialcopygeneric.S | 2 ++
arch/arm/lib/div64.S | 3 ++-
arch/arm/lib/getuser.S | 2 ++
arch/arm/lib/io-readsb.S | 1 +
arch/arm/lib/io-readsl.S | 1 +
arch/arm/lib/io-readsw-armv3.S | 1 +
arch/arm/lib/io-readsw-armv4.S | 1 +
arch/arm/lib/io-writesb.S | 1 +
arch/arm/lib/io-writesl.S | 1 +
arch/arm/lib/io-writesw-armv3.S | 1 +
arch/arm/lib/io-writesw-armv4.S | 1 +
arch/arm/lib/lib1funcs.S | 17 +++++++++--------
arch/arm/lib/lshrdi3.S | 5 +++--
arch/arm/lib/memchr.S | 1 +
arch/arm/lib/memcpy.S | 4 ++++
arch/arm/lib/memmove.S | 1 +
arch/arm/lib/memset.S | 4 ++++
arch/arm/lib/memzero.S | 1 +
arch/arm/lib/muldi3.S | 5 +++--
arch/arm/lib/putuser.S | 2 ++
arch/arm/lib/setbit.S | 2 +-
arch/arm/lib/strchr.S | 1 +
arch/arm/lib/strrchr.S | 1 +
arch/arm/lib/testchangebit.S | 2 +-
arch/arm/lib/testclearbit.S | 2 +-
arch/arm/lib/testsetbit.S | 2 +-
arch/arm/lib/ucmpdi2.S | 5 +++--
arch/arm/lib/voidproto.h | 7 +++++++
43 files changed, 89 insertions(+), 31 deletions(-)
create mode 100644 arch/arm/boot/compressed/voidproto.h
create mode 100644 arch/arm/lib/voidproto.h
diff --git a/arch/arm/boot/compressed/voidproto.h b/arch/arm/boot/compressed/voidproto.h
new file mode 100644
index 0000000000..9c5f5e7e49
--- /dev/null
+++ b/arch/arm/boot/compressed/voidproto.h
@@ -0,0 +1 @@
+#define EXPORT_SYMBOL_VOIDPROTO(x) /* nothing */
diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
index f41cee4c57..e37d7bc8da 100644
--- a/arch/arm/kernel/head.S
+++ b/arch/arm/kernel/head.S
@@ -728,6 +728,7 @@ __pv_phys_pfn_offset:
__pv_offset:
.quad 0
.size __pv_offset, . -__pv_offset
+SYMBOL_CPROTO_INCLUDE(<asm/memory.h>)
EXPORT_SYMBOL(__pv_phys_pfn_offset)
EXPORT_SYMBOL(__pv_offset)
#endif
diff --git a/arch/arm/kernel/smccc-call.S b/arch/arm/kernel/smccc-call.S
index 37669e7e13..b50961de14 100644
--- a/arch/arm/kernel/smccc-call.S
+++ b/arch/arm/kernel/smccc-call.S
@@ -18,6 +18,8 @@
#include <asm/unwind.h>
#include <asm/export.h>
+SYMBOL_CPROTO_INCLUDE(<linux/arm-smccc.h>)
+
/*
* Wrap c macros in asm macros to delay expansion until after the
* SMCCC asm macro is expanded.
diff --git a/arch/arm/lib/ashldi3.S b/arch/arm/lib/ashldi3.S
index a7e7de89bd..8e4db9e1b6 100644
--- a/arch/arm/lib/ashldi3.S
+++ b/arch/arm/lib/ashldi3.S
@@ -29,6 +29,7 @@ Boston, MA 02110-1301, USA. */
#include <linux/linkage.h>
#include <asm/assembler.h>
#include <asm/export.h>
+#include "voidproto.h"
#ifdef __ARMEB__
#define al r1
@@ -53,5 +54,5 @@ ENTRY(__aeabi_llsl)
ENDPROC(__ashldi3)
ENDPROC(__aeabi_llsl)
-EXPORT_SYMBOL(__ashldi3)
-EXPORT_SYMBOL(__aeabi_llsl)
+EXPORT_SYMBOL_VOIDPROTO(__ashldi3)
+EXPORT_SYMBOL_VOIDPROTO(__aeabi_llsl)
diff --git a/arch/arm/lib/ashrdi3.S b/arch/arm/lib/ashrdi3.S
index 490336e425..e373606cd8 100644
--- a/arch/arm/lib/ashrdi3.S
+++ b/arch/arm/lib/ashrdi3.S
@@ -29,6 +29,7 @@ Boston, MA 02110-1301, USA. */
#include <linux/linkage.h>
#include <asm/assembler.h>
#include <asm/export.h>
+#include "voidproto.h"
#ifdef __ARMEB__
#define al r1
@@ -53,5 +54,5 @@ ENTRY(__aeabi_lasr)
ENDPROC(__ashrdi3)
ENDPROC(__aeabi_lasr)
-EXPORT_SYMBOL(__ashrdi3)
-EXPORT_SYMBOL(__aeabi_lasr)
+EXPORT_SYMBOL_VOIDPROTO(__ashrdi3)
+EXPORT_SYMBOL_VOIDPROTO(__aeabi_lasr)
diff --git a/arch/arm/lib/bitops.h b/arch/arm/lib/bitops.h
index df06638b32..af39eeb1a8 100644
--- a/arch/arm/lib/bitops.h
+++ b/arch/arm/lib/bitops.h
@@ -2,6 +2,16 @@
#include <asm/unwind.h>
#include <asm/export.h>
+SYMBOL_CPROTO_INCLUDE(<linux/bitops.h>)
+
+#define BITOP(name, instr) \
+ bitop name, instr; \
+ EXPORT_SYMBOL(name)
+
+#define TESTOP(name, instr, store) \
+ testop name, instr, store; \
+ EXPORT_SYMBOL(name)
+
#if __LINUX_ARM_ARCH__ >= 6
.macro bitop, name, instr
ENTRY( \name )
@@ -26,7 +36,6 @@ UNWIND( .fnstart )
bx lr
UNWIND( .fnend )
ENDPROC(\name )
-EXPORT_SYMBOL(\name )
.endm
.macro testop, name, instr, store
@@ -57,7 +66,6 @@ UNWIND( .fnstart )
2: bx lr
UNWIND( .fnend )
ENDPROC(\name )
-EXPORT_SYMBOL(\name )
.endm
#else
.macro bitop, name, instr
@@ -77,7 +85,6 @@ UNWIND( .fnstart )
ret lr
UNWIND( .fnend )
ENDPROC(\name )
-EXPORT_SYMBOL(\name )
.endm
/**
@@ -106,6 +113,5 @@ UNWIND( .fnstart )
ret lr
UNWIND( .fnend )
ENDPROC(\name )
-EXPORT_SYMBOL(\name )
.endm
#endif
diff --git a/arch/arm/lib/bswapsdi2.S b/arch/arm/lib/bswapsdi2.S
index f05f782473..7c503191db 100644
--- a/arch/arm/lib/bswapsdi2.S
+++ b/arch/arm/lib/bswapsdi2.S
@@ -1,6 +1,7 @@
#include <linux/linkage.h>
#include <asm/assembler.h>
#include <asm/export.h>
+#include "voidproto.h"
#if __LINUX_ARM_ARCH__ >= 6
ENTRY(__bswapsi2)
@@ -36,5 +37,5 @@ ENTRY(__bswapdi2)
ret lr
ENDPROC(__bswapdi2)
#endif
-EXPORT_SYMBOL(__bswapsi2)
-EXPORT_SYMBOL(__bswapdi2)
+EXPORT_SYMBOL_VOIDPROTO(__bswapsi2)
+EXPORT_SYMBOL_VOIDPROTO(__bswapdi2)
diff --git a/arch/arm/lib/changebit.S b/arch/arm/lib/changebit.S
index f402786217..4f3f77f416 100644
--- a/arch/arm/lib/changebit.S
+++ b/arch/arm/lib/changebit.S
@@ -12,4 +12,4 @@
#include "bitops.h"
.text
-bitop _change_bit, eor
+BITOP( _change_bit, eor )
diff --git a/arch/arm/lib/clear_user.S b/arch/arm/lib/clear_user.S
index b566154f5c..caaa40b85f 100644
--- a/arch/arm/lib/clear_user.S
+++ b/arch/arm/lib/clear_user.S
@@ -52,6 +52,7 @@ UNWIND(.fnend)
ENDPROC(arm_clear_user)
ENDPROC(__clear_user_std)
#ifndef CONFIG_UACCESS_WITH_MEMCPY
+SYMBOL_CPROTO_INCLUDE(<asm/uaccess.h>)
EXPORT_SYMBOL(arm_clear_user)
#endif
diff --git a/arch/arm/lib/clearbit.S b/arch/arm/lib/clearbit.S
index f6b75fb64d..444789f37a 100644
--- a/arch/arm/lib/clearbit.S
+++ b/arch/arm/lib/clearbit.S
@@ -12,4 +12,4 @@
#include "bitops.h"
.text
-bitop _clear_bit, bic
+BITOP( _clear_bit, bic )
diff --git a/arch/arm/lib/copy_from_user.S b/arch/arm/lib/copy_from_user.S
index 63e4c1ed02..b01dcb5e27 100644
--- a/arch/arm/lib/copy_from_user.S
+++ b/arch/arm/lib/copy_from_user.S
@@ -95,6 +95,7 @@ ENTRY(arm_copy_from_user)
#include "copy_template.S"
ENDPROC(arm_copy_from_user)
+SYMBOL_CPROTO_INCLUDE(<asm/uaccess.h>)
EXPORT_SYMBOL(arm_copy_from_user)
.pushsection .fixup,"ax"
diff --git a/arch/arm/lib/copy_page.S b/arch/arm/lib/copy_page.S
index d97851d4af..652d2c9acf 100644
--- a/arch/arm/lib/copy_page.S
+++ b/arch/arm/lib/copy_page.S
@@ -46,4 +46,5 @@ ENTRY(copy_page)
PLD( beq 2b )
ldmfd sp!, {r4, pc} @ 3
ENDPROC(copy_page)
+SYMBOL_CPROTO_INCLUDE(<asm/page.h>)
EXPORT_SYMBOL(copy_page)
diff --git a/arch/arm/lib/copy_to_user.S b/arch/arm/lib/copy_to_user.S
index 592c179112..8cd8500df9 100644
--- a/arch/arm/lib/copy_to_user.S
+++ b/arch/arm/lib/copy_to_user.S
@@ -101,6 +101,7 @@ WEAK(arm_copy_to_user)
ENDPROC(arm_copy_to_user)
ENDPROC(__copy_to_user_std)
#ifndef CONFIG_UACCESS_WITH_MEMCPY
+SYMBOL_CPROTO_INCLUDE(<asm/uaccess.h>)
EXPORT_SYMBOL(arm_copy_to_user)
#endif
diff --git a/arch/arm/lib/csumipv6.S b/arch/arm/lib/csumipv6.S
index 68603b5ee5..0ba2d8d7c3 100644
--- a/arch/arm/lib/csumipv6.S
+++ b/arch/arm/lib/csumipv6.S
@@ -31,4 +31,5 @@ ENTRY(__csum_ipv6_magic)
adcs r0, r0, #0
ldmfd sp!, {pc}
ENDPROC(__csum_ipv6_magic)
+SYMBOL_CPROTO_INCLUDE(<asm/checksum.h>)
EXPORT_SYMBOL(__csum_ipv6_magic)
diff --git a/arch/arm/lib/csumpartial.S b/arch/arm/lib/csumpartial.S
index 830b20e81c..86b9aa25e1 100644
--- a/arch/arm/lib/csumpartial.S
+++ b/arch/arm/lib/csumpartial.S
@@ -141,4 +141,5 @@ ENTRY(csum_partial)
bne 4b
b .Lless4
ENDPROC(csum_partial)
+SYMBOL_CPROTO_INCLUDE(<asm/checksum.h>)
EXPORT_SYMBOL(csum_partial)
diff --git a/arch/arm/lib/csumpartialcopygeneric.S b/arch/arm/lib/csumpartialcopygeneric.S
index 8b94d20e51..30beddf85f 100644
--- a/arch/arm/lib/csumpartialcopygeneric.S
+++ b/arch/arm/lib/csumpartialcopygeneric.S
@@ -10,6 +10,8 @@
#include <asm/assembler.h>
#include <asm/export.h>
+SYMBOL_CPROTO_INCLUDE(<asm/checksum.h>)
+
/*
* unsigned int
* csum_partial_copy_xxx(const char *src, char *dst, int len, int sum, )
diff --git a/arch/arm/lib/div64.S b/arch/arm/lib/div64.S
index 0c9e1c18fc..e9418ac052 100644
--- a/arch/arm/lib/div64.S
+++ b/arch/arm/lib/div64.S
@@ -16,6 +16,7 @@
#include <asm/assembler.h>
#include <asm/unwind.h>
#include <asm/export.h>
+#include "voidproto.h"
#ifdef __ARMEB__
#define xh r0
@@ -211,4 +212,4 @@ Ldiv0_64:
UNWIND(.fnend)
ENDPROC(__do_div64)
-EXPORT_SYMBOL(__do_div64)
+EXPORT_SYMBOL_VOIDPROTO(__do_div64)
diff --git a/arch/arm/lib/getuser.S b/arch/arm/lib/getuser.S
index 9d09a38e73..b755a97e53 100644
--- a/arch/arm/lib/getuser.S
+++ b/arch/arm/lib/getuser.S
@@ -33,6 +33,8 @@
#include <asm/domain.h>
#include <asm/export.h>
+SYMBOL_CPROTO_INCLUDE(<asm/uaccess.h>)
+
ENTRY(__get_user_1)
check_uaccess r0, 1, r1, r2, __get_user_bad
1: TUSER(ldrb) r2, [r0]
diff --git a/arch/arm/lib/io-readsb.S b/arch/arm/lib/io-readsb.S
index 3dff7a3a2a..899a690258 100644
--- a/arch/arm/lib/io-readsb.S
+++ b/arch/arm/lib/io-readsb.S
@@ -122,4 +122,5 @@ ENTRY(__raw_readsb)
ldmfd sp!, {r4 - r6, pc}
ENDPROC(__raw_readsb)
+SYMBOL_CPROTO_INCLUDE(<asm/io.h>)
EXPORT_SYMBOL(__raw_readsb)
diff --git a/arch/arm/lib/io-readsl.S b/arch/arm/lib/io-readsl.S
index bfd3968232..8c88bea554 100644
--- a/arch/arm/lib/io-readsl.S
+++ b/arch/arm/lib/io-readsl.S
@@ -78,4 +78,5 @@ ENTRY(__raw_readsl)
strb r3, [r1, #0]
ret lr
ENDPROC(__raw_readsl)
+SYMBOL_CPROTO_INCLUDE(<asm/io.h>)
EXPORT_SYMBOL(__raw_readsl)
diff --git a/arch/arm/lib/io-readsw-armv3.S b/arch/arm/lib/io-readsw-armv3.S
index b3af3db6ca..cc07c1da87 100644
--- a/arch/arm/lib/io-readsw-armv3.S
+++ b/arch/arm/lib/io-readsw-armv3.S
@@ -104,4 +104,5 @@ ENTRY(__raw_readsw)
ldmfd sp!, {r4, r5, r6, pc}
+SYMBOL_CPROTO_INCLUDE(<asm/io.h>)
EXPORT_SYMBOL(__raw_readsw)
diff --git a/arch/arm/lib/io-readsw-armv4.S b/arch/arm/lib/io-readsw-armv4.S
index 3c7a7a40b3..75e84cd300 100644
--- a/arch/arm/lib/io-readsw-armv4.S
+++ b/arch/arm/lib/io-readsw-armv4.S
@@ -130,4 +130,5 @@ ENTRY(__raw_readsw)
strneb ip, [r1]
ldmfd sp!, {r4, pc}
ENDPROC(__raw_readsw)
+SYMBOL_CPROTO_INCLUDE(<asm/io.h>)
EXPORT_SYMBOL(__raw_readsw)
diff --git a/arch/arm/lib/io-writesb.S b/arch/arm/lib/io-writesb.S
index fa36335944..1ab2e7dfa8 100644
--- a/arch/arm/lib/io-writesb.S
+++ b/arch/arm/lib/io-writesb.S
@@ -93,4 +93,5 @@ ENTRY(__raw_writesb)
ldmfd sp!, {r4, r5, pc}
ENDPROC(__raw_writesb)
+SYMBOL_CPROTO_INCLUDE(<asm/io.h>)
EXPORT_SYMBOL(__raw_writesb)
diff --git a/arch/arm/lib/io-writesl.S b/arch/arm/lib/io-writesl.S
index 98ed6aec0b..4df08f5998 100644
--- a/arch/arm/lib/io-writesl.S
+++ b/arch/arm/lib/io-writesl.S
@@ -66,4 +66,5 @@ ENTRY(__raw_writesl)
bne 6b
ret lr
ENDPROC(__raw_writesl)
+SYMBOL_CPROTO_INCLUDE(<asm/io.h>)
EXPORT_SYMBOL(__raw_writesl)
diff --git a/arch/arm/lib/io-writesw-armv3.S b/arch/arm/lib/io-writesw-armv3.S
index 577184c082..c643c48d7c 100644
--- a/arch/arm/lib/io-writesw-armv3.S
+++ b/arch/arm/lib/io-writesw-armv3.S
@@ -125,4 +125,5 @@ ENTRY(__raw_writesw)
strne ip, [r0]
ldmfd sp!, {r4, r5, r6, pc}
+SYMBOL_CPROTO_INCLUDE(<asm/io.h>)
EXPORT_SYMBOL(__raw_writesw)
diff --git a/arch/arm/lib/io-writesw-armv4.S b/arch/arm/lib/io-writesw-armv4.S
index e335f489d1..ec8ef93e71 100644
--- a/arch/arm/lib/io-writesw-armv4.S
+++ b/arch/arm/lib/io-writesw-armv4.S
@@ -99,4 +99,5 @@ ENTRY(__raw_writesw)
strneh ip, [r0]
ret lr
ENDPROC(__raw_writesw)
+SYMBOL_CPROTO_INCLUDE(<asm/io.h>)
EXPORT_SYMBOL(__raw_writesw)
diff --git a/arch/arm/lib/lib1funcs.S b/arch/arm/lib/lib1funcs.S
index f541bc013b..692cf3bba7 100644
--- a/arch/arm/lib/lib1funcs.S
+++ b/arch/arm/lib/lib1funcs.S
@@ -37,6 +37,7 @@ Boston, MA 02111-1307, USA. */
#include <asm/assembler.h>
#include <asm/unwind.h>
#include <asm/export.h>
+#include "voidproto.h"
.macro ARM_DIV_BODY dividend, divisor, result, curbit
@@ -239,8 +240,8 @@ UNWIND(.fnstart)
UNWIND(.fnend)
ENDPROC(__udivsi3)
ENDPROC(__aeabi_uidiv)
-EXPORT_SYMBOL(__udivsi3)
-EXPORT_SYMBOL(__aeabi_uidiv)
+EXPORT_SYMBOL_VOIDPROTO(__udivsi3)
+EXPORT_SYMBOL_VOIDPROTO(__aeabi_uidiv)
ENTRY(__umodsi3)
UNWIND(.fnstart)
@@ -259,7 +260,7 @@ UNWIND(.fnstart)
UNWIND(.fnend)
ENDPROC(__umodsi3)
-EXPORT_SYMBOL(__umodsi3)
+EXPORT_SYMBOL_VOIDPROTO(__umodsi3)
#ifdef CONFIG_ARM_PATCH_IDIV
.align 3
@@ -307,8 +308,8 @@ UNWIND(.fnstart)
UNWIND(.fnend)
ENDPROC(__divsi3)
ENDPROC(__aeabi_idiv)
-EXPORT_SYMBOL(__divsi3)
-EXPORT_SYMBOL(__aeabi_idiv)
+EXPORT_SYMBOL_VOIDPROTO(__divsi3)
+EXPORT_SYMBOL_VOIDPROTO(__aeabi_idiv)
ENTRY(__modsi3)
UNWIND(.fnstart)
@@ -333,7 +334,7 @@ UNWIND(.fnstart)
UNWIND(.fnend)
ENDPROC(__modsi3)
-EXPORT_SYMBOL(__modsi3)
+EXPORT_SYMBOL_VOIDPROTO(__modsi3)
#ifdef CONFIG_AEABI
@@ -350,7 +351,7 @@ UNWIND(.save {r0, r1, ip, lr} )
UNWIND(.fnend)
ENDPROC(__aeabi_uidivmod)
-EXPORT_SYMBOL(__aeabi_uidivmod)
+EXPORT_SYMBOL_VOIDPROTO(__aeabi_uidivmod)
ENTRY(__aeabi_idivmod)
UNWIND(.fnstart)
@@ -364,7 +365,7 @@ UNWIND(.save {r0, r1, ip, lr} )
UNWIND(.fnend)
ENDPROC(__aeabi_idivmod)
-EXPORT_SYMBOL(__aeabi_idivmod)
+EXPORT_SYMBOL_VOIDPROTO(__aeabi_idivmod)
#endif
diff --git a/arch/arm/lib/lshrdi3.S b/arch/arm/lib/lshrdi3.S
index e408339814..b12317fe99 100644
--- a/arch/arm/lib/lshrdi3.S
+++ b/arch/arm/lib/lshrdi3.S
@@ -29,6 +29,7 @@ Boston, MA 02110-1301, USA. */
#include <linux/linkage.h>
#include <asm/assembler.h>
#include <asm/export.h>
+#include "voidproto.h"
#ifdef __ARMEB__
#define al r1
@@ -53,5 +54,5 @@ ENTRY(__aeabi_llsr)
ENDPROC(__lshrdi3)
ENDPROC(__aeabi_llsr)
-EXPORT_SYMBOL(__lshrdi3)
-EXPORT_SYMBOL(__aeabi_llsr)
+EXPORT_SYMBOL_VOIDPROTO(__lshrdi3)
+EXPORT_SYMBOL_VOIDPROTO(__aeabi_llsr)
diff --git a/arch/arm/lib/memchr.S b/arch/arm/lib/memchr.S
index 44182bf686..ea6d86e195 100644
--- a/arch/arm/lib/memchr.S
+++ b/arch/arm/lib/memchr.S
@@ -25,4 +25,5 @@ ENTRY(memchr)
2: movne r0, #0
ret lr
ENDPROC(memchr)
+SYMBOL_CPROTO_INCLUDE(<linux/string.h>)
EXPORT_SYMBOL(memchr)
diff --git a/arch/arm/lib/memcpy.S b/arch/arm/lib/memcpy.S
index 1be5b6ddf3..04be16dbbd 100644
--- a/arch/arm/lib/memcpy.S
+++ b/arch/arm/lib/memcpy.S
@@ -69,5 +69,9 @@ ENTRY(memcpy)
ENDPROC(memcpy)
ENDPROC(mmiocpy)
+
+SYMBOL_CPROTO_INCLUDE(<linux/string.h>)
EXPORT_SYMBOL(memcpy)
+
+SYMBOL_CPROTO(void mmiocpy(void *, const void *, size_t))
EXPORT_SYMBOL(mmiocpy)
diff --git a/arch/arm/lib/memmove.S b/arch/arm/lib/memmove.S
index 71dcc5400d..e10ef8024e 100644
--- a/arch/arm/lib/memmove.S
+++ b/arch/arm/lib/memmove.S
@@ -226,4 +226,5 @@ ENTRY(memmove)
18: backward_copy_shift push=24 pull=8
ENDPROC(memmove)
+SYMBOL_CPROTO_INCLUDE(<linux/string.h>)
EXPORT_SYMBOL(memmove)
diff --git a/arch/arm/lib/memset.S b/arch/arm/lib/memset.S
index 7b72044cba..ea797a483f 100644
--- a/arch/arm/lib/memset.S
+++ b/arch/arm/lib/memset.S
@@ -136,5 +136,9 @@ UNWIND( .fnstart )
UNWIND( .fnend )
ENDPROC(memset)
ENDPROC(mmioset)
+
+SYMBOL_CPROTO_INCLUDE(<linux/string.h>)
EXPORT_SYMBOL(memset)
+
+SYMBOL_CPROTO(extern void mmioset(void *, unsigned int, size_t))
EXPORT_SYMBOL(mmioset)
diff --git a/arch/arm/lib/memzero.S b/arch/arm/lib/memzero.S
index 6dec26ed5b..9e1d05c79a 100644
--- a/arch/arm/lib/memzero.S
+++ b/arch/arm/lib/memzero.S
@@ -136,4 +136,5 @@ UNWIND( .fnstart )
ret lr @ 1
UNWIND( .fnend )
ENDPROC(__memzero)
+SYMBOL_CPROTO_INCLUDE(<asm/string.h>)
EXPORT_SYMBOL(__memzero)
diff --git a/arch/arm/lib/muldi3.S b/arch/arm/lib/muldi3.S
index b8f12388cc..2104660d54 100644
--- a/arch/arm/lib/muldi3.S
+++ b/arch/arm/lib/muldi3.S
@@ -13,6 +13,7 @@
#include <linux/linkage.h>
#include <asm/assembler.h>
#include <asm/export.h>
+#include "voidproto.h"
#ifdef __ARMEB__
#define xh r0
@@ -47,5 +48,5 @@ ENTRY(__aeabi_lmul)
ENDPROC(__muldi3)
ENDPROC(__aeabi_lmul)
-EXPORT_SYMBOL(__muldi3)
-EXPORT_SYMBOL(__aeabi_lmul)
+EXPORT_SYMBOL_VOIDPROTO(__muldi3)
+EXPORT_SYMBOL_VOIDPROTO(__aeabi_lmul)
diff --git a/arch/arm/lib/putuser.S b/arch/arm/lib/putuser.S
index 11de126e2e..bb6507cd06 100644
--- a/arch/arm/lib/putuser.S
+++ b/arch/arm/lib/putuser.S
@@ -33,6 +33,8 @@
#include <asm/domain.h>
#include <asm/export.h>
+SYMBOL_CPROTO_INCLUDE(<asm/uaccess.h>)
+
ENTRY(__put_user_1)
check_uaccess r0, 1, r1, ip, __put_user_bad
1: TUSER(strb) r2, [r0]
diff --git a/arch/arm/lib/setbit.S b/arch/arm/lib/setbit.S
index 618fedae4b..0b51a2a905 100644
--- a/arch/arm/lib/setbit.S
+++ b/arch/arm/lib/setbit.S
@@ -12,4 +12,4 @@
#include "bitops.h"
.text
-bitop _set_bit, orr
+BITOP( _set_bit, orr )
diff --git a/arch/arm/lib/strchr.S b/arch/arm/lib/strchr.S
index 7301f6e604..199d092ec3 100644
--- a/arch/arm/lib/strchr.S
+++ b/arch/arm/lib/strchr.S
@@ -26,4 +26,5 @@ ENTRY(strchr)
subeq r0, r0, #1
ret lr
ENDPROC(strchr)
+SYMBOL_CPROTO_INCLUDE(<linux/string.h>)
EXPORT_SYMBOL(strchr)
diff --git a/arch/arm/lib/strrchr.S b/arch/arm/lib/strrchr.S
index aaf9fd98b7..f7f261f80f 100644
--- a/arch/arm/lib/strrchr.S
+++ b/arch/arm/lib/strrchr.S
@@ -25,4 +25,5 @@ ENTRY(strrchr)
mov r0, r3
ret lr
ENDPROC(strrchr)
+SYMBOL_CPROTO_INCLUDE(<linux/string.h>)
EXPORT_SYMBOL(strrchr)
diff --git a/arch/arm/lib/testchangebit.S b/arch/arm/lib/testchangebit.S
index 4becdc3a59..fb2b429ad1 100644
--- a/arch/arm/lib/testchangebit.S
+++ b/arch/arm/lib/testchangebit.S
@@ -12,4 +12,4 @@
#include "bitops.h"
.text
-testop _test_and_change_bit, eor, str
+TESTOP( _test_and_change_bit, eor, str )
diff --git a/arch/arm/lib/testclearbit.S b/arch/arm/lib/testclearbit.S
index 918841dcce..c9bcbdf2f2 100644
--- a/arch/arm/lib/testclearbit.S
+++ b/arch/arm/lib/testclearbit.S
@@ -12,4 +12,4 @@
#include "bitops.h"
.text
-testop _test_and_clear_bit, bicne, strne
+TESTOP( _test_and_clear_bit, bicne, strne )
diff --git a/arch/arm/lib/testsetbit.S b/arch/arm/lib/testsetbit.S
index 8d1b2fe9e4..7ccaaf0861 100644
--- a/arch/arm/lib/testsetbit.S
+++ b/arch/arm/lib/testsetbit.S
@@ -12,4 +12,4 @@
#include "bitops.h"
.text
-testop _test_and_set_bit, orreq, streq
+TESTOP( _test_and_set_bit, orreq, streq )
diff --git a/arch/arm/lib/ucmpdi2.S b/arch/arm/lib/ucmpdi2.S
index 127a91af46..a13f3c911e 100644
--- a/arch/arm/lib/ucmpdi2.S
+++ b/arch/arm/lib/ucmpdi2.S
@@ -13,6 +13,7 @@
#include <linux/linkage.h>
#include <asm/assembler.h>
#include <asm/export.h>
+#include "voidproto.h"
#ifdef __ARMEB__
#define xh r0
@@ -36,7 +37,7 @@ ENTRY(__ucmpdi2)
ret lr
ENDPROC(__ucmpdi2)
-EXPORT_SYMBOL(__ucmpdi2)
+EXPORT_SYMBOL_VOIDPROTO(__ucmpdi2)
#ifdef CONFIG_AEABI
@@ -50,7 +51,7 @@ ENTRY(__aeabi_ulcmp)
ret lr
ENDPROC(__aeabi_ulcmp)
-EXPORT_SYMBOL(__aeabi_ulcmp)
+EXPORT_SYMBOL_VOIDPROTO(__aeabi_ulcmp)
#endif
diff --git a/arch/arm/lib/voidproto.h b/arch/arm/lib/voidproto.h
new file mode 100644
index 0000000000..4926f4f022
--- /dev/null
+++ b/arch/arm/lib/voidproto.h
@@ -0,0 +1,7 @@
+/*
+ * The gcc helper functions exported from assembly code are never
+ * called from C code directly, however they traditionally always had
+ * a prototype like void __symbol(void) for modversion.
+ */
+#define EXPORT_SYMBOL_VOIDPROTO(sym) \
+ SYMBOL_CPROTO(void sym(void)); EXPORT_SYMBOL(sym)
--
2.7.4
^ permalink raw reply related
* [PATCH 2/3] kbuild: make modversion for exported asm symbols more convivial
From: Nicolas Pitre @ 2016-11-30 8:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480495824-4151-1-git-send-email-nicolas.pitre@linaro.org>
Rather than having an asm-prototypes.h file where C prototypes for exported
asm symbols are centralized, let's have some macros that can be used
directly in the code where those symbols are exported for genksyms
consumption. Either the prototype is provided directly if no include
files has it, or the include file containing it is specified.
Signed-off-by: Nicolas Pitre <nico@linaro.org>
---
include/asm-generic/export.h | 15 +++++++++++++++
scripts/Makefile.build | 22 +++++++++++++++-------
2 files changed, 30 insertions(+), 7 deletions(-)
diff --git a/include/asm-generic/export.h b/include/asm-generic/export.h
index 39a19dc366..83dda5f840 100644
--- a/include/asm-generic/export.h
+++ b/include/asm-generic/export.h
@@ -84,11 +84,26 @@ KSYM(__kcrctab_\name):
#define __EXPORT_SYMBOL(sym, val, sec) ___EXPORT_SYMBOL sym, val, sec
#endif
+/* in the non genksyms case those are no-ops */
+#define SYMBOL_CPROTO(expr)
+#define SYMBOL_CPROTO_INCLUDE(file)
+
#else /* __GENKSYMS__ */
/* create a preprocessor output suitable for cmd_gensymtypes_S */
#define __EXPORT_SYMBOL(sym, val, sec) EXPORT_SYMBOL(sym)
+/*
+ * The cmd_gensymtypes_S kbuild command recognizes the following:
+ *
+ * Provide a C prototype for genksyms: SYMBOL_CPROTO(expr)
+ * example: SYMBOL_CPROTO(void foobar(int x, int y))
+ *
+ * Specify an include file that contains C prototypes for genksyms:
+ * SYMBOL_CPROTO_INCLUDE(quoted_filename)
+ * example: SYMBOL_CPROTO_INCLUDE(<linux/string.h>)
+ */
+
#endif /* __GENKSYMS__ */
#define EXPORT_SYMBOL(name) \
diff --git a/scripts/Makefile.build b/scripts/Makefile.build
index ebf6e08ae4..58ebc4b15d 100644
--- a/scripts/Makefile.build
+++ b/scripts/Makefile.build
@@ -317,24 +317,32 @@ modkern_aflags := $(KBUILD_AFLAGS_KERNEL) $(AFLAGS_KERNEL)
$(real-objs-m) : modkern_aflags := $(KBUILD_AFLAGS_MODULE) $(AFLAGS_MODULE)
$(real-objs-m:.o=.s): modkern_aflags := $(KBUILD_AFLAGS_MODULE) $(AFLAGS_MODULE)
-# .S file exports must have their C prototypes defined in asm/asm-prototypes.h
-# or a file that it includes, in order to get versioned symbols. We build a
-# dummy C file that includes asm-prototypes and the EXPORT_SYMBOL lines from
-# the .S file (with trailing ';'), and run genksyms on that, to extract vers.
+# In order to get versioned symbols, .S file exports must have their C prototypes:
+# - defined in asm/asm-prototypes.h or a file that it includes, or
+# - provided in a file specified by SYMBOL_CPROTO_INCLUDE(), or
+# - specified directly by SYMBOL_CPROTO().
+# We build a dummy C file that includes asm-prototypes and the EXPORT_SYMBOL
+# lines from the .S file (with trailing ';'), and run genksyms on that, to
+# extract vers.
#
# This is convoluted. The .S file must first be preprocessed to run guards and
# expand names, then the resulting exports must be constructed into plain
# EXPORT_SYMBOL(symbol); to build our dummy C file, and that gets preprocessed
# to make the genksyms input. See also include/asm-generic/export.h.
#
+# The -Ulinux is necessary otherwise SYMBOL_CPROTO_INCLUDE(<linux/bitops.h>)
+# is turned into #include <1/bitops.h> due to "linux" being defined to 1.
+#
# These mirror gensymtypes_c and co above, keep them in synch.
cmd_gensymtypes_S = \
( echo "\#include <linux/kernel.h>" ; \
if [ -e $(srctree)/arch/$(SRCARCH)/include/asm/asm-prototypes.h ]; \
then echo "\#include <asm/asm-prototypes.h>"; fi; \
- $(CPP) -D__GENKSYMS__ $(a_flags) $< | tr ";" "\n" | \
- sed -n -e '/EXPORT_SYMBOL(/s/$$/;/p' ) | \
- $(CPP) -D__GENKSYMS__ $(c_flags) -xc - | \
+ $(CPP) -D__GENKSYMS__ $(a_flags) -Ulinux $< | tr ";" "\n" | \
+ sed -n -e '/EXPORT_SYMBOL(/s/$$/;/p' \
+ -e 's/SYMBOL_CPROTO(\(.*\))/\1;/p' \
+ -e 's/SYMBOL_CPROTO_INCLUDE(\(.*\))/\#include \1/p' ) | \
+ $(CPP) -D__GENKSYMS__ -I$(@D) $(c_flags) -xc - | \
$(GENKSYMS) $(if $(1), -T $(2)) \
$(patsubst y,-s _,$(CONFIG_HAVE_UNDERSCORE_SYMBOL_PREFIX)) \
$(if $(KBUILD_PRESERVE),-p) \
--
2.7.4
^ permalink raw reply related
* [PATCH 1/3] kbuild: improve EXPORT_SYMBOL() parsing from asm code
From: Nicolas Pitre @ 2016-11-30 8:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480495824-4151-1-git-send-email-nicolas.pitre@linaro.org>
First, make the asm-prototypes.h presence optional. The next patch will
make it unneeded for modversion support.
Use the -D__GENKSYMS__ like we do for .c files but to expand the
EXPORT_SYMBOL macro using the preprocessor instead of a sed script.
The preprocessor output parsing is then limited to a simpler filtering
and made more robust against multiple assembly statements on a single
line.
Signed-off-by: Nicolas Pitre <nico@linaro.org>
---
include/asm-generic/export.h | 9 +++++++++
scripts/Makefile.build | 20 ++++++--------------
2 files changed, 15 insertions(+), 14 deletions(-)
diff --git a/include/asm-generic/export.h b/include/asm-generic/export.h
index 63554e9f6e..39a19dc366 100644
--- a/include/asm-generic/export.h
+++ b/include/asm-generic/export.h
@@ -28,6 +28,8 @@
#define KSYM(name) name
#endif
+#if defined(__KERNEL__) && !defined(__GENKSYMS__)
+
/*
* note on .section use: @progbits vs %progbits nastiness doesn't matter,
* since we immediately emit into those sections anyway.
@@ -82,6 +84,13 @@ KSYM(__kcrctab_\name):
#define __EXPORT_SYMBOL(sym, val, sec) ___EXPORT_SYMBOL sym, val, sec
#endif
+#else /* __GENKSYMS__ */
+
+/* create a preprocessor output suitable for cmd_gensymtypes_S */
+#define __EXPORT_SYMBOL(sym, val, sec) EXPORT_SYMBOL(sym)
+
+#endif /* __GENKSYMS__ */
+
#define EXPORT_SYMBOL(name) \
__EXPORT_SYMBOL(name, KSYM_FUNC(KSYM(name)),)
#define EXPORT_SYMBOL_GPL(name) \
diff --git a/scripts/Makefile.build b/scripts/Makefile.build
index 7675d11ee6..ebf6e08ae4 100644
--- a/scripts/Makefile.build
+++ b/scripts/Makefile.build
@@ -325,15 +325,15 @@ $(real-objs-m:.o=.s): modkern_aflags := $(KBUILD_AFLAGS_MODULE) $(AFLAGS_MODULE)
# This is convoluted. The .S file must first be preprocessed to run guards and
# expand names, then the resulting exports must be constructed into plain
# EXPORT_SYMBOL(symbol); to build our dummy C file, and that gets preprocessed
-# to make the genksyms input.
+# to make the genksyms input. See also include/asm-generic/export.h.
#
# These mirror gensymtypes_c and co above, keep them in synch.
cmd_gensymtypes_S = \
- (echo "\#include <linux/kernel.h>" ; \
- echo "\#include <asm/asm-prototypes.h>" ; \
- $(CPP) $(a_flags) $< | \
- grep "\<___EXPORT_SYMBOL\>" | \
- sed 's/.*___EXPORT_SYMBOL[[:space:]]*\([a-zA-Z0-9_]*\)[[:space:]]*,.*/EXPORT_SYMBOL(\1);/' ) | \
+ ( echo "\#include <linux/kernel.h>" ; \
+ if [ -e $(srctree)/arch/$(SRCARCH)/include/asm/asm-prototypes.h ]; \
+ then echo "\#include <asm/asm-prototypes.h>"; fi; \
+ $(CPP) -D__GENKSYMS__ $(a_flags) $< | tr ";" "\n" | \
+ sed -n -e '/EXPORT_SYMBOL(/s/$$/;/p' ) | \
$(CPP) -D__GENKSYMS__ $(c_flags) -xc - | \
$(GENKSYMS) $(if $(1), -T $(2)) \
$(patsubst y,-s _,$(CONFIG_HAVE_UNDERSCORE_SYMBOL_PREFIX)) \
@@ -363,13 +363,6 @@ cmd_as_o_S = $(CC) $(a_flags) -c -o $@ $<
else
-ASM_PROTOTYPES := $(wildcard $(srctree)/arch/$(SRCARCH)/include/asm/asm-prototypes.h)
-
-ifeq ($(ASM_PROTOTYPES),)
-cmd_as_o_S = $(CC) $(a_flags) -c -o $@ $<
-
-else
-
# versioning matches the C process described above, with difference that
# we parse asm-prototypes.h C header to get function definitions.
@@ -387,7 +380,6 @@ cmd_modversions_S = \
mv -f $(@D)/.tmp_$(@F) $@; \
fi;
endif
-endif
$(obj)/%.o: $(src)/%.S $(objtool_obj) FORCE
$(call if_changed_rule,as_o_S)
--
2.7.4
^ permalink raw reply related
* [PATCH 0/3] fix modversion for symbol exported from asm code
From: Nicolas Pitre @ 2016-11-30 8:50 UTC (permalink / raw)
To: linux-arm-kernel
This is my alternative to asm-prototypes.h for fixing modversion with
assembly symbols. This preserves the goal of not having a central list
of symbols that may get out of sync wrt the actual code.
An example usage is provided for ARM.
The asm-prototypes.h method is still available for those who might
prefer it.
Given that modversion is currently broken, I'd advocate for the first
2 patches to go into mainline now even if v4.9 is imminent. That can't
make things any worse than they are, and with this in place people may
start fixing their own architecture.
^ permalink raw reply
* [PATCH 07/12] usb: sunxi: Uses the resource-managed extcon API when registering extcon notifier
From: Maxime Ripard @ 2016-11-30 8:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480485460-2663-8-git-send-email-cw00.choi@samsung.com>
On Wed, Nov 30, 2016 at 02:57:35PM +0900, Chanwoo Choi wrote:
> This patch just uses the resource-managed extcon API when registering
> the extcon notifier.
>
> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161130/bc452c58/attachment.sig>
^ permalink raw reply
* [PATCH v2] arm64: dts: exynos: Add flash led dt node for TM2 board
From: Seung-Woo Kim @ 2016-11-30 8:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <583E8F73.2060804@samsung.com>
Hello Chanwoo,
On 2016? 11? 30? 17:36, Chanwoo Choi wrote:
> Dear Seung-Woo,
>
> I think that this patch looks good to me.
> But, When I tested this patch on my TM2 board,
> the flash turn off after some millisecond automatically.
Thank you for testing on your side. I will check on my side about the
issue, and if I find, then I will send next version.
Regards,
- Seung-Woo Kim
>
> It is strange situation. Unfortunately, I don't know the cause.
> I think that we better to check this issue for more time.
>
> Best Regards,
> Chanwoo Choi
>
> On 2016? 11? 30? 13:48, Seung-Woo Kim wrote:
>> From: Ingi Kim <ingi2.kim@samsung.com>
>>
>> This patch adds Kinetic ktd2692 flash led device node for TM2 board.
>>
>> Signed-off-by: Ingi Kim <ingi2.kim@samsung.com>
>> Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
>> ---
>> Change from v1:
>> - gpio active value is set with defined macro instead of value.
>> ---
>> arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 13 +++++++++++++
>> 1 files changed, 13 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
>> index f21bdc2..0d454aa 100644
>> --- a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
>> +++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
>> @@ -58,6 +58,19 @@
>> reg = <0x0 0x20000000 0x0 0xc0000000>;
>> };
>>
>> + camera-flash {
>> + compatible = "kinetic,ktd2692";
>> + ctrl-gpios = <&gpc0 1 GPIO_ACTIVE_HIGH>;
>> + aux-gpios = <&gpc0 2 GPIO_ACTIVE_HIGH>;
>> +
>> + flash-led {
>> + label = "ktd2692-flash";
>> + led-max-microamp = <300000>;
>> + flash-max-microamp = <1500000>;
>> + flash-max-timeout-us = <1835000>;
>> + };
>> + };
>> +
>> gpio-keys {
>> compatible = "gpio-keys";
>>
>>
>
>
--
Seung-Woo Kim
Samsung Software R&D Center
--
^ permalink raw reply
* [PATCH v2] arm64: dts: exynos: Add flash led dt node for TM2 board
From: Chanwoo Choi @ 2016-11-30 8:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480481337-3941-1-git-send-email-sw0312.kim@samsung.com>
Dear Seung-Woo,
I think that this patch looks good to me.
But, When I tested this patch on my TM2 board,
the flash turn off after some millisecond automatically.
It is strange situation. Unfortunately, I don't know the cause.
I think that we better to check this issue for more time.
Best Regards,
Chanwoo Choi
On 2016? 11? 30? 13:48, Seung-Woo Kim wrote:
> From: Ingi Kim <ingi2.kim@samsung.com>
>
> This patch adds Kinetic ktd2692 flash led device node for TM2 board.
>
> Signed-off-by: Ingi Kim <ingi2.kim@samsung.com>
> Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
> ---
> Change from v1:
> - gpio active value is set with defined macro instead of value.
> ---
> arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 13 +++++++++++++
> 1 files changed, 13 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> index f21bdc2..0d454aa 100644
> --- a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> +++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> @@ -58,6 +58,19 @@
> reg = <0x0 0x20000000 0x0 0xc0000000>;
> };
>
> + camera-flash {
> + compatible = "kinetic,ktd2692";
> + ctrl-gpios = <&gpc0 1 GPIO_ACTIVE_HIGH>;
> + aux-gpios = <&gpc0 2 GPIO_ACTIVE_HIGH>;
> +
> + flash-led {
> + label = "ktd2692-flash";
> + led-max-microamp = <300000>;
> + flash-max-microamp = <1500000>;
> + flash-max-timeout-us = <1835000>;
> + };
> + };
> +
> gpio-keys {
> compatible = "gpio-keys";
>
>
^ permalink raw reply
* [PATCH v4 1/4] [media] davinci: vpif_capture: don't lock over s_stream
From: Laurent Pinchart @ 2016-11-30 8:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161129235712.29846-2-khilman@baylibre.com>
Hi Kevin,
Thank you for the patch.
On Tuesday 29 Nov 2016 15:57:09 Kevin Hilman wrote:
> Video capture subdevs may be over I2C and may sleep during xfer, so we
> cannot do IRQ-disabled locking when calling the subdev.
>
> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
> ---
> drivers/media/platform/davinci/vpif_capture.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/media/platform/davinci/vpif_capture.c
> b/drivers/media/platform/davinci/vpif_capture.c index
> 5104cc0ee40e..9f8f41c0f251 100644
> --- a/drivers/media/platform/davinci/vpif_capture.c
> +++ b/drivers/media/platform/davinci/vpif_capture.c
> @@ -193,7 +193,10 @@ static int vpif_start_streaming(struct vb2_queue *vq,
> unsigned int count) }
> }
>
> + spin_unlock_irqrestore(&common->irqlock, flags);
> ret = v4l2_subdev_call(ch->sd, video, s_stream, 1);
> + spin_lock_irqsave(&common->irqlock, flags);
I always get anxious when I see a spinlock being released randomly with an
operation in the middle of a protected section. Looking at the code it looks
like the spinlock is abused here. irqlock should only protect the dma_queue
and should thus only be taken around the following code:
spin_lock_irqsave(&common->irqlock, flags);
/* Get the next frame from the buffer queue */
common->cur_frm = common->next_frm = list_entry(common->dma_queue.next,
struct vpif_cap_buffer, list);
/* Remove buffer from the buffer queue */
list_del(&common->cur_frm->list);
spin_unlock_irqrestore(&common->irqlock, flags);
The code that is currently protected by the lock in the start and stop
streaming functions should be protected by a mutex instead.
> +
> if (ret && ret != -ENOIOCTLCMD && ret != -ENODEV) {
> vpif_dbg(1, debug, "stream on failed in subdev\n");
> goto err;
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH v9 07/11] arm/arm64: vgic: Implement KVM_DEV_ARM_VGIC_GRP_LEVEL_INFO ioctl
From: Peter Maydell @ 2016-11-30 8:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161130082411.GA6647@cbox>
On 30 November 2016 at 08:24, Christoffer Dall
<christoffer.dall@linaro.org> wrote:
> (Peter, I thought you once argued that it was important for user space
> to be able to save/restore the state without any ordering requirements,
> but I may have misunderstood. It is still the option to add something
> like the above to the docs but also do our best to allow any ordering of
> level/config, but it becomes slightly more invasive.)
Hmm; perhaps I should think about this a bit more.
-- PMM
^ permalink raw reply
* [PATCH] arm64: dts: add zx296718's topcrm node
From: Jun Nie @ 2016-11-30 8:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480491237-5169-1-git-send-email-baoyou.xie@linaro.org>
2016-11-30 15:33 GMT+08:00 Baoyou Xie <baoyou.xie@linaro.org>:
> Enable topcrm clock node for zx296718, which is used for
> CPU's frequency change.
Please follow general rule, such as
arm64: dts: zx: brief title of your changes
>
> Furthermore, this patch adds the CPU clock phandle in CPU's node
> and uses operating-points-v2 to register operating points.
>
> So it can be used by cpufreq-dt driver.
Suggest to split clock nodes and cpu-freq nodes changes into different patches.
>
> Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
> ---
> arch/arm64/boot/dts/zte/zx296718.dtsi | 48 +++++++++++++++++++++++++++++++++++
> 1 file changed, 48 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/zte/zx296718.dtsi b/arch/arm64/boot/dts/zte/zx296718.dtsi
> index 6b239a3..f9eb37d 100644
> --- a/arch/arm64/boot/dts/zte/zx296718.dtsi
> +++ b/arch/arm64/boot/dts/zte/zx296718.dtsi
> @@ -44,6 +44,7 @@
> #include <dt-bindings/input/input.h>
> #include <dt-bindings/interrupt-controller/arm-gic.h>
> #include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/clock/zx296718-clock.h>
>
> / {
> compatible = "zte,zx296718";
> @@ -81,6 +82,8 @@
> compatible = "arm,cortex-a53","arm,armv8";
> reg = <0x0 0x0>;
> enable-method = "psci";
> + clocks = <&topcrm A53_GATE>;
> + operating-points-v2 = <&cluster0_opp>;
> };
>
> cpu1: cpu at 1 {
> @@ -88,6 +91,7 @@
> compatible = "arm,cortex-a53","arm,armv8";
> reg = <0x0 0x1>;
> enable-method = "psci";
> + operating-points-v2 = <&cluster0_opp>;
> };
>
> cpu2: cpu at 2 {
> @@ -95,6 +99,7 @@
> compatible = "arm,cortex-a53","arm,armv8";
> reg = <0x0 0x2>;
> enable-method = "psci";
> + operating-points-v2 = <&cluster0_opp>;
> };
>
> cpu3: cpu at 3 {
> @@ -102,6 +107,43 @@
> compatible = "arm,cortex-a53","arm,armv8";
> reg = <0x0 0x3>;
> enable-method = "psci";
> + operating-points-v2 = <&cluster0_opp>;
> + };
> + };
> +
> + cluster0_opp: opp_table0 {
> + compatible = "operating-points-v2";
> + opp-shared;
> +
> + opp at 1000000000 {
> + opp-hz = /bits/ 64 <500000000>;
Why frequency in opp name differ with opp-hz value?
> + opp-microvolt = <857000>;
> + clock-latency-ns = <500000>;
> + };
> + opp at 1100000000 {
> + opp-hz = /bits/ 64 <648000000>;
> + opp-microvolt = <857000>;
> + clock-latency-ns = <500000>;
> + };
> + opp at 1200000000 {
> + opp-hz = /bits/ 64 <800000000>;
> + opp-microvolt = <882000>;
> + clock-latency-ns = <500000>;
> + };
> + opp at 1300000000 {
> + opp-hz = /bits/ 64 <1000000000>;
> + opp-microvolt = <892000>;
> + clock-latency-ns = <500000>;
> + };
> + opp at 1400000000 {
> + opp-hz = /bits/ 64 <1188000000>;
> + opp-microvolt = <1009000>;
> + clock-latency-ns = <500000>;
> + };
> + opp at 1500000000 {
> + opp-hz = /bits/ 64 <1312000000>;
> + opp-microvolt = <1052000>;
> + clock-latency-ns = <500000>;
> };
I did not see frequency 1500000000 or 1312000000 in clock drivers for
A53. Please confirm whether clock driver need update or your need
revise your patch.
> };
>
> @@ -279,6 +321,12 @@
> dma-requests = <32>;
> };
>
> + topcrm: clock-controller at 01461000 {
Removing heading 0 in address of name.
> + compatible = "zte,zx296718-topcrm";
> + reg = <0x01461000 0x1000>;
> + #clock-cells = <1>;
> + };
> +
> sysctrl: sysctrl at 1463000 {
> compatible = "zte,zx296718-sysctrl", "syscon";
> reg = <0x1463000 0x1000>;
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH v9 07/11] arm/arm64: vgic: Implement KVM_DEV_ARM_VGIC_GRP_LEVEL_INFO ioctl
From: Christoffer Dall @ 2016-11-30 8:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFEAcA_1i7-ti_H_RZrTbCW2DmFPvYudKn_WFs=_XRoyKKsnbQ@mail.gmail.com>
On Wed, Nov 30, 2016 at 07:10:51AM +0000, Peter Maydell wrote:
> On 29 November 2016 at 21:09, Christoffer Dall
> <christoffer.dall@linaro.org> wrote:
> > Actually, I'm not sure what the semantics of the line level ioctl should
> > be for edge-triggered interrupts? My inclination is that it shouldn't
> > have any effect at this point, but that would mean that at this point we
> > should only set the pending variable and try to queue the interrupt if
> > the config is level. But that also means that when we set the config
> > later, we need to try to queue the interrupt, which we don't do
> > currently, because we rely on the guest not fiddling with the config of
> > an enabled interrupt.
> >
> > Could it be considered an error if user space tries to set the level for
> > an edge-triggered interrupt and therefore something we can just ignore
> > and assume that the corresponing interrupt will be configured as a
> > level-triggered one later?
>
> Userspace will always read the line-level values out and write
> them back for migration, and I'd rather not make it have to
> do cross-checks against whether the interrupt is edge or level
> triggered to see whether it should write the level values into
> the kernel. Telling the kernel the level for an edge-triggered
> interrupt should be a no-op because it doesn't have any effect
> on pending status.
>
> > In any case we probably need to clarify the ABI in terms of this
> > particular KVM_DEV_AR_VGIC_GRP_LEVEL_INFO group and how it relates to
> > the config of edge vs. level of interrupts and ordering on restore...
>
> IIRC the QEMU code restores the config first. (There's a similar
> ordering thing for GICv2 where we have to restore GICD_ICFGRn before
> GICD_ISPENDRn.)
>
So it sounds to me that we should add a note in the Documentation like
this:
diff --git a/Documentation/virtual/kvm/devices/arm-vgic-v3.txt b/Documentation/virtual/kvm/devices/arm-vgic-v3.txt
index 9348b3c..7bac20a 100644
--- a/Documentation/virtual/kvm/devices/arm-vgic-v3.txt
+++ b/Documentation/virtual/kvm/devices/arm-vgic-v3.txt
@@ -193,6 +193,11 @@ Groups:
Bit[n] indicates the status for interrupt vINTID + n.
+ Getting or setting the level info for an edge-triggered interrupt is
+ not guaranteed to work. To restore the complete state of the VGIC, the
+ configuration (edge/level) of interrupts must be restored before
+ restoring the level.
+
SGIs and any interrupt with a higher ID than the number of interrupts
supported, will be RAZ/WI. LPIs are always edge-triggered and are
therefore not supported by this interface.
Vijay, this means that the first block in your if-statement should only
set pending and queue the interrupt if the interrupt is a level
triggered one.
(Peter, I thought you once argued that it was important for user space
to be able to save/restore the state without any ordering requirements,
but I may have misunderstood. It is still the option to add something
like the above to the docs but also do our best to allow any ordering of
level/config, but it becomes slightly more invasive.)
Thanks,
-Christoffer
^ permalink raw reply related
* [PATCH v7 4/8] drm/sunxi: Add DT bindings documentation of Allwinner HDMI
From: Laurent Pinchart @ 2016-11-30 8:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161130091208.f38cd79f1cc5d27b27f3b130@free.fr>
Hi Jean-Fran?ois,
On Wednesday 30 Nov 2016 09:12:08 Jean-Francois Moine wrote:
> On Tue, 29 Nov 2016 22:10:01 +0200 Laurent Pinchart wrote:
> > On Tuesday 29 Nov 2016 21:04:55 Jean-Francois Moine wrote:
> >> On Tue, 29 Nov 2016 21:33 +0200 Laurent Pinchart wrote:
> >>>>> You need a third port for the HDMI encoder output, connected to an
> >>>>> HDMI connector DT node.
> >>>>
> >>>> I don't see what you mean. The HDMI device is both the encoder
> >>>
> >>>> and connector (as the TDA998x):
> >>> The driver might create both an encoder and a connector, but I very
> >>> much doubt that the "allwinner,sun8i-a83t-hdmi" hardware contains a
> >>> connector, unless the SoC package has an HDMI connector coming out of
> >>> it :-)
> >>>
> >>>> plane -> DE2 mixer ---> TCON -----> HDMI -----> display device
> >>>> ----- plane ------ - CRTC - - encoder \
> >>>> connector -- (HDMI cable)
> >>>> audio-controller - - audio-codec /
> >>
> >> The schema is the same as the Dove Cubox: the TDA998x is just a chip
> >> with some wires going out and the physical connector is supposed to be
> >> at the end of the wires.
> >
> > I've missed the Dove Cubox DT bindings when they were submitted.
> > Fortunately (or unfortunately for you, depending on how you look at it
> > ;-)) I've paid more attention this time.
> >
> >> Here, the HDMI pins of the SoC go to a pure hardware chip and then to
> >> the physical connector. Which software entity do you want to add?
> >
> > I don't want to add a software entity, I just want to model the connector
> > in DT as it's present in the system. Even though that's more common for
> > other bus types than HDMI (LVDS for instance) it wouldn't be
> > inconceivable to connect the HDMI signals to an on-board chim instead of
> > an HDMI connector, so the HDMI encoder output should be modelled by a
> > port and connected to a connector DT node in this case.
>
> Well, I don't see what this connector can be.
> May you give me a DT example?
Sure.
arch/arm/boot/dts/r8a7791-koelsch.dts
/* HDMI encoder */
hdmi at 39 {
compatible = "adi,adv7511w";
reg = <0x39>;
interrupt-parent = <&gpio3>;
interrupts = <29 IRQ_TYPE_LEVEL_LOW>;
adi,input-depth = <8>;
adi,input-colorspace = "rgb";
adi,input-clock = "1x";
adi,input-style = <1>;
adi,input-justification = "evenly";
ports {
#address-cells = <1>;
#size-cells = <0>;
port at 0 {
reg = <0>;
adv7511_in: endpoint {
remote-endpoint = <&du_out_rgb>;
};
};
port at 1 {
reg = <1>;
adv7511_out: endpoint {
remote-endpoint = <&hdmi_con>;
};
};
};
};
/* HDMI connector */
hdmi-out {
compatible = "hdmi-connector";
type = "a";
port {
hdmi_con: endpoint {
remote-endpoint = <&adv7511_out>;
};
};
};
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH v4 00/10] IOMMU probe deferral support
From: Marek Szyprowski @ 2016-11-30 8:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480465344-11862-1-git-send-email-sricharan@codeaurora.org>
Hi All,
On 2016-11-30 01:22, Sricharan R wrote:
> This series calls the dma ops configuration for the devices
> at a generic place so that it works for all busses.
> The dma_configure_ops for a device is now called during
> the device_attach callback just before the probe of the
> bus/driver is called. Similarly dma_deconfigure is called during
> device/driver_detach path.
>
> pci_bus_add_devices (platform/amba)(_device_create/driver_register)
> | |
> pci_bus_add_device (device_add/driver_register)
> | |
> device_attach device_initial_probe
> | |
> __device_attach_driver __device_attach_driver
> |
> driver_probe_device
> |
> really_probe
> |
> dma_configure
>
> Similarly on the device/driver_unregister path __device_release_driver is
> called which inturn calls dma_deconfigure.
>
> Took the reworked patches [2] from Robin's branch and
> rebased on top of Lorenzo's ACPI IORT ARM support series [3].
>
> Tested with platform and pci devices for probe deferral
> and reprobe on arm64 based platform. Added the patches [9,10],
> drivers: acpi: Configure acpi devices dma operation at probe time
> drivers: acpi: Handle IOMMU lookup failure with deferred probing or error
> for doing the dma ops configuration at probe time for acpi based platform
> as well. Did not have a acpi based platform to test the changes and with
> my still catching up knowledge on acpi/enumeration those two patches needs
> to be reviewed/tested more.
I've checked this patchset on my development boards: Odroid U3
(ARM/Exynos4412),
XU3 (ARM/Exynos5422) and TM2 (ARM64/Exynos5433) and my queued patches
for Exynos
IOMMU driver [1]. Besides the issue with an excessive dev_info, which
causes NULL
pointer dereference (reported in reply to patch #6), it works fine on
all those
platforms! Please add (again) my:
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
[1] https://www.spinics.net/lists/linux-samsung-soc/msg56354.html
> Previous post of this series [5].
>
> [V4]
> * Took the reworked patches [2] from Robin's branch and
> rebased on top of Lorenzo's ACPI IORT ARM support series [3].
>
> * Added the patches for moving the dma ops configuration of
> acpi based devices to probe time as well.
> [V3]
> * Removed the patch to split dma_masks/dma_ops configuration
> separately based on review comments that both masks and ops are
> required only during the device probe time.
>
> * Reworked the series based on Generic DT bindings series.
>
> * Added call to iommu's remove_device in the cleanup path for arm and
> arm64.
>
> * Removed the notifier trick in arm64 to handle early device
> registration.
>
> * Added reset of dma_ops in cleanup path for arm based on comments.
>
> * Fixed the pci_iommu_configure path and tested with PCI device as
> well.
>
> * Fixed a bug to return the correct iommu_ops from patch 7 [4] in
> last post.
>
> * Fixed few other cosmetic comments.
>
> [V2]
> * Updated the Initial post to call dma_configure/deconfigure from
> generic code
>
> * Added iommu add_device callback from of_iommu_configure path
>
> [V1]
> * Initial post from Laurent Pinchart [1]
>
> [1] http://lists.linuxfoundation.org/pipermail/iommu/2015-May/013016.html
> [2] http://www.linux-arm.org/git?p=linux-rm.git;a=shortlog;h=refs/heads/iommu/defer
> [3] https://lkml.org/lkml/2016/11/21/141
> [4] https://www.mail-archive.com/iommu at lists.linux-foundation.org/msg13940.html
> [5] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-October/460832.html
>
> Laurent Pinchart (3):
> of: dma: Move range size workaround to of_dma_get_range()
> of: dma: Make of_dma_deconfigure() public
> iommu: of: Handle IOMMU lookup failure with deferred probing or error
>
> Robin Murphy (3):
> iommu/of: Refactor of_iommu_configure() for error handling
> iommu/of: Prepare for deferred IOMMU configuration
> iommu/arm-smmu: Clean up early-probing workarounds
>
> Sricharan R (4):
> drivers: platform: Configure dma operations at probe time
> arm64: dma-mapping: Remove the notifier trick to handle early setting
> of dma_ops
> drivers: acpi: Configure acpi devices dma operation at probe time
> drivers: acpi: Handle IOMMU lookup failure with deferred probing or
> error
>
> arch/arm64/mm/dma-mapping.c | 132 ++++----------------------------------------
> drivers/acpi/arm64/iort.c | 17 +++++-
> drivers/acpi/glue.c | 6 --
> drivers/acpi/scan.c | 7 ++-
> drivers/base/dd.c | 10 ++++
> drivers/base/dma-mapping.c | 32 +++++++++++
> drivers/iommu/arm-smmu-v3.c | 35 +-----------
> drivers/iommu/arm-smmu.c | 58 +++----------------
> drivers/iommu/dma-iommu.c | 1 +
> drivers/iommu/of_iommu.c | 114 +++++++++++++++++++++++++++-----------
> drivers/of/address.c | 20 ++++++-
> drivers/of/device.c | 36 ++++++------
> drivers/of/platform.c | 10 +---
> drivers/pci/probe.c | 17 +++---
> include/acpi/acpi_bus.h | 2 +-
> include/linux/acpi.h | 7 ++-
> include/linux/dma-mapping.h | 3 +
> include/linux/of_device.h | 10 +++-
> include/linux/pci.h | 5 ++
> 19 files changed, 238 insertions(+), 284 deletions(-)
>
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* [PATCH v7 4/8] drm/sunxi: Add DT bindings documentation of Allwinner HDMI
From: Jean-Francois Moine @ 2016-11-30 8:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4502748.8rUF7ESxa4@avalon>
On Tue, 29 Nov 2016 22:10:01 +0200
Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote:
> Hi Jean-Fran?ois,
>
> On Tuesday 29 Nov 2016 21:04:55 Jean-Francois Moine wrote:
> > On Tue, 29 Nov 2016 21:33 +0200 Laurent Pinchart wrote:
> > >>> You need a third port for the HDMI encoder output, connected to an
> > >>> HDMI connector DT node.
> > >>
> > >> I don't see what you mean. The HDMI device is both the encoder
> > >> and connector (as the TDA998x):
> > >
> > > The driver might create both an encoder and a connector, but I very much
> > > doubt that the "allwinner,sun8i-a83t-hdmi" hardware contains a connector,
> > > unless the SoC package has an HDMI connector coming out of it :-)
> > >
> > >> plane -> DE2 mixer ---> TCON -----> HDMI -----> display device
> > >> ----- plane ------ - CRTC - - encoder \
> > >> connector -- (HDMI cable)
> > >> audio-controller - - audio-codec /
> >
> > The schema is the same as the Dove Cubox: the TDA998x is just a chip
> > with some wires going out and the physical connector is supposed to be
> > at the end of the wires.
>
> I've missed the Dove Cubox DT bindings when they were submitted. Fortunately
> (or unfortunately for you, depending on how you look at it ;-)) I've paid more
> attention this time.
>
> > Here, the HDMI pins of the SoC go to a pure hardware chip and then to
> > the physical connector. Which software entity do you want to add?
>
> I don't want to add a software entity, I just want to model the connector in
> DT as it's present in the system. Even though that's more common for other bus
> types than HDMI (LVDS for instance) it wouldn't be inconceivable to connect
> the HDMI signals to an on-board chim instead of an HDMI connector, so the HDMI
> encoder output should be modelled by a port and connected to a connector DT
> node in this case.
Well, I don't see what this connector can be.
May you give me a DT example?
--
Ken ar c'henta? | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
^ permalink raw reply
* [PATCH v7 0/8] drm: sun8i: Add DE2 HDMI video support
From: Laurent Pinchart @ 2016-11-30 8:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <239b60f3-3ea7-4aa7-8e8d-353e1a1d4ee5@googlegroups.com>
Hi Jernej,
On Tuesday 29 Nov 2016 15:24:25 Jernej Skrabec wrote:
> Dne torek, 29. november 2016 23.56.31 UTC+1 je oseba Laurent Pinchart
> napisala:
> > On Tuesday 29 Nov 2016 14:47:20 Jernej Skrabec wrote:
> >> Dne torek, 29. november 2016 22.37.03 UTC+1 je oseba Maxime Ripard
> > napisala:
> >>> On Tue, Nov 29, 2016 at 11:18:35AM +0100, Jean-Francois Moine wrote:
> >>>> This patchset series adds HDMI video support to the Allwinner
> >>>> sun8i SoCs which include the display engine 2 (DE2).
> >>>> The driver contains the code for the A83T and H3 SoCs, and
> >>>> some H3 boards, but it could be used/extended for other SoCs
> >>>> (A64, H2, H5) and boards (Banana PIs, Orange PIs).
> >>>
> >>> Honestly, I'm getting a bit worried by the fact that you ignore
> >>> reviews.
> >>>
> >>> On the important reviews that you got that are to be seen as major
> >>> issues that block the inclusion, we have:
> >>> - The fact that the HDMI driver is actually just a designware IP,
> >>> and while you should use the driver that already exists, you just
> >>> duplicated all that code.
> >>
> >> That might be hard thing to do. A83T fits perfectly, but H3 and newer
> >> SoCs do not. They are using completely different HDMI phy. Decoupling
> >> controller and phy code means rewritting a good portion of the code,
> >> unless some tricks are applied, like calling phy function pointers, if
> >> they are defined.
> >
> > Same HDMI TX but different HDMI TX PHY ? Kieran is working on decoupling
> > the PHY configuration code for a Renesas SoC, that might be of interest to
> > you.
>
> Exactly. I'm developing only U-Boot driver, but Jean-Francois will probably
> have more interest in this.
We'll post patches as soon as they're ready.
By the way, do you know if the H3 and newer SoCs use a different PHY from
Synopsys, or a custom PHY developed by Allwinner ?
> >> Register addresses also differ, but that can be easily solved by using
> >> undocumented magic value to restore them.
> >
> > I love that :-)
>
> Is it allowed to use magic number which was found in binary blob? I'm new in
> all this.
I don't really see a problem with that, we have many drivers in the kernel
that have been developed through reverse-engineering. You should not include
large pieces of code that have been obtained through decompilation of a
proprietary binary blob as those could be protected by copyright, but writing
to undocumented registers based on information found through usage of a binary
driver isn't a problem. (Please remember that I'm not a lawyer though)
> >>> - The fact that you ignored Rob (v6) and I (v5) comment on using OF
> >>> graph to model the connection between the display engine and the
> >>> TCON. Something that Laurent also pointed out in this version.
> >>>
> >>> - The fact that you ignored that you needed an HDMI connector node
> >>> as a child of the HDMI controller. This has been reported by Rob
> >>> (v6) and yet again in this version by Laurent.
> >>>
> >>> - And finally the fact that we can't have several display engine in
> >>> parallel, if needs be. This has happened in the past already on
> >>> Allwinner SoCs, so it's definitely something we should consider in
> >>> the DT bindings, since we can't break them.
> >>>
> >>> Until those are fixed, I cannot see how this driver can be merged,
> >>> unfortunately.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH 1/2] arm64: Correcting format specifier for printin 64 bit addresses
From: Maninder Singh @ 2016-11-30 8:03 UTC (permalink / raw)
To: linux-arm-kernel
This patch corrects format specifier for printing 64 bit addresses.
Before Patch
============
[ 68.251603] Unable to handle kernel NULL pointer dereference at virtual address 00000000
[ 68.251673] pgd = ffffffc013950000
[ 68.251782] [00000000] *pgd=0000000093e19003, *pud=0000000093e19003, *pmd=0000000000000000
After patch
===========
[ 8.565030] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
[ 8.565389] pgd = ffffffc013872000
[ 8.565553] [0000000000000000] *pgd=0000000093874003, *pud=0000000093874003, *pmd=0000000000000000
and same for user space fault.
Signed-off-by: Vaneet Narang <v.narang@samsung.com>
Signed-off-by: Maninder Singh <maninder1.s@samsung.com>
---
arch/arm64/mm/fault.c | 16 +++++++++++-----
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index a78a5c4..8cb5c93 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -77,7 +77,7 @@ void show_pte(struct mm_struct *mm, unsigned long addr)
pr_alert("pgd = %p\n", mm->pgd);
pgd = pgd_offset(mm, addr);
- pr_alert("[%08lx] *pgd=%016llx", addr, pgd_val(*pgd));
+ pr_alert("[%016lx] *pgd=%016llx", addr, pgd_val(*pgd));
do {
pud_t *pud;
@@ -177,7 +177,7 @@ static void __do_kernel_fault(struct mm_struct *mm, unsigned long addr,
* No handler, we'll have to terminate things with extreme prejudice.
*/
bust_spinlocks(1);
- pr_alert("Unable to handle kernel %s at virtual address %08lx\n",
+ pr_alert("Unable to handle kernel %s at virtual address %016lx\n",
(addr < PAGE_SIZE) ? "NULL pointer dereference" :
"paging request", addr);
@@ -198,9 +198,15 @@ static void __do_user_fault(struct task_struct *tsk, unsigned long addr,
struct siginfo si;
if (unhandled_signal(tsk, sig) && show_unhandled_signals_ratelimited()) {
- pr_info("%s[%d]: unhandled %s (%d)@0x%08lx, esr 0x%03x\n",
- tsk->comm, task_pid_nr(tsk), fault_name(esr), sig,
- addr, esr);
+ if (compat_user_mode(regs))
+ pr_info("%s[%d]: unhandled %s (%d) at 0x%08lx, esr 0x%03x\n",
+ tsk->comm, task_pid_nr(tsk), fault_name(esr), sig,
+ addr, esr);
+ else
+ pr_info("%s[%d]: unhandled %s (%d) at 0x%016lx, esr 0x%03x\n",
+ tsk->comm, task_pid_nr(tsk), fault_name(esr), sig,
+ addr, esr);
+
show_pte(tsk->mm, addr);
show_regs(regs);
}
--
1.9.1
^ permalink raw reply related
* [PATCH v10 12/13] drm/mediatek: update DSI sub driver flow for sending commands to panel
From: CK Hu @ 2016-11-30 7:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480070076-6196-13-git-send-email-yt.shen@mediatek.com>
Hi, YT:
some comments inline.
On Fri, 2016-11-25 at 18:34 +0800, YT Shen wrote:
> This patch update enable/disable flow of DSI module.
> Original flow works on there is a bridge chip: DSI -> bridge -> panel.
> In this case: DSI -> panel, the DSI sub driver flow should be updated.
> We need to initialize DSI first so that we can send commands to panel.
>
> Signed-off-by: shaoming chen <shaoming.chen@mediatek.com>
> Signed-off-by: YT Shen <yt.shen@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_dsi.c | 101 +++++++++++++++++++++++++++++--------
> 1 file changed, 80 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index ded4202..0569f2e 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -126,6 +126,10 @@
> #define CLK_HS_POST (0xff << 8)
> #define CLK_HS_EXIT (0xff << 16)
>
> +#define DSI_VM_CMD_CON 0x130
> +#define VM_CMD_EN BIT(0)
> +#define TS_VFP_EN BIT(5)
> +
> #define DSI_CMDQ0 0x180
> #define CONFIG (0xff << 0)
> #define SHORT_PACKET 0
> @@ -249,7 +253,9 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
> * mipi_ratio is mipi clk coefficient for balance the pixel clk in mipi.
> * we set mipi_ratio is 1.05.
> */
> - dsi->data_rate = dsi->vm.pixelclock * 3 * 21 / (1 * 1000 * 10);
> + dsi->data_rate = dsi->vm.pixelclock * 12 * 21;
> + dsi->data_rate /= (dsi->lanes * 1000 * 10);
This looks like a bug fix that use lanes to calculate data rate.
> + DRM_DEBUG_DRIVER("set mipitx's data rate: %dMHz\n", dsi->data_rate);
>
> ret = clk_set_rate(dsi->hs_clk, dsi->data_rate * 1000000);
> if (ret < 0) {
> @@ -333,16 +339,23 @@ static void mtk_dsi_set_mode(struct mtk_dsi *dsi)
> u32 vid_mode = CMD_MODE;
>
> if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO) {
> - vid_mode = SYNC_PULSE_MODE;
> -
> - if ((dsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST) &&
> - !(dsi->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE))
> + if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST)
> vid_mode = BURST_MODE;
> + else if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE)
> + vid_mode = SYNC_PULSE_MODE;
> + else
> + vid_mode = SYNC_EVENT_MODE;
> }
>
> writel(vid_mode, dsi->regs + DSI_MODE_CTRL);
> }
>
> +static void mtk_dsi_set_vm_cmd(struct mtk_dsi *dsi)
> +{
> + mtk_dsi_mask(dsi, DSI_VM_CMD_CON, VM_CMD_EN, VM_CMD_EN);
> + mtk_dsi_mask(dsi, DSI_VM_CMD_CON, TS_VFP_EN, TS_VFP_EN);
> +}
> +
> static void mtk_dsi_ps_control_vact(struct mtk_dsi *dsi)
> {
> struct videomode *vm = &dsi->vm;
> @@ -480,6 +493,16 @@ static void mtk_dsi_start(struct mtk_dsi *dsi)
> writel(1, dsi->regs + DSI_START);
> }
>
> +static void mtk_dsi_stop(struct mtk_dsi *dsi)
> +{
> + writel(0, dsi->regs + DSI_START);
> +}
> +
> +static void mtk_dsi_set_cmd_mode(struct mtk_dsi *dsi)
> +{
> + writel(CMD_MODE, dsi->regs + DSI_MODE_CTRL);
> +}
> +
> static void mtk_dsi_set_interrupt_enable(struct mtk_dsi *dsi)
> {
> u32 inten = LPRX_RD_RDY_INT_FLAG | CMD_DONE_INT_FLAG | VM_DONE_INT_FLAG;
> @@ -538,6 +561,19 @@ static irqreturn_t mtk_dsi_irq(int irq, void *dev_id)
> return IRQ_HANDLED;
> }
>
> +static s32 mtk_dsi_switch_to_cmd_mode(struct mtk_dsi *dsi, u8 irq_flag, u32 t)
> +{
> + mtk_dsi_irq_data_clear(dsi, irq_flag);
> + mtk_dsi_set_cmd_mode(dsi);
> +
> + if (!mtk_dsi_wait_for_irq_done(dsi, irq_flag, t)) {
> + DRM_ERROR("failed to switch cmd mode\n");
> + return -ETIME;
> + } else {
> + return 0;
> + }
> +}
> +
> static void mtk_dsi_poweroff(struct mtk_dsi *dsi)
> {
> if (WARN_ON(dsi->refcount == 0))
> @@ -546,11 +582,6 @@ static void mtk_dsi_poweroff(struct mtk_dsi *dsi)
> if (--dsi->refcount != 0)
> return;
>
> - mtk_dsi_lane0_ulp_mode_enter(dsi);
> - mtk_dsi_clk_ulp_mode_enter(dsi);
> -
> - mtk_dsi_disable(dsi);
> -
> clk_disable_unprepare(dsi->engine_clk);
> clk_disable_unprepare(dsi->digital_clk);
>
> @@ -564,13 +595,6 @@ static void mtk_output_dsi_enable(struct mtk_dsi *dsi)
> if (dsi->enabled)
> return;
>
> - if (dsi->panel) {
> - if (drm_panel_prepare(dsi->panel)) {
> - DRM_ERROR("failed to setup the panel\n");
> - return;
> - }
> - }
> -
> ret = mtk_dsi_poweron(dsi);
> if (ret < 0) {
> DRM_ERROR("failed to power on dsi\n");
> @@ -578,21 +602,43 @@ static void mtk_output_dsi_enable(struct mtk_dsi *dsi)
> }
>
> mtk_dsi_rxtx_control(dsi);
> + mtk_dsi_ps_control_vact(dsi);
> + mtk_dsi_set_vm_cmd(dsi);
Even though dsi does not directly connect to panel, you newly set vm cmd
here. This looks like a bug fix.
> + mtk_dsi_config_vdo_timing(dsi);
> + mtk_dsi_set_interrupt_enable(dsi);
>
> mtk_dsi_clk_ulp_mode_leave(dsi);
> mtk_dsi_lane0_ulp_mode_leave(dsi);
> mtk_dsi_clk_hs_mode(dsi, 0);
> - mtk_dsi_set_mode(dsi);
>
> - mtk_dsi_ps_control_vact(dsi);
> - mtk_dsi_config_vdo_timing(dsi);
> - mtk_dsi_set_interrupt_enable(dsi);
> + if (dsi->panel) {
> + if (drm_panel_prepare(dsi->panel)) {
> + DRM_ERROR("failed to prepare the panel\n");
> +
> + mtk_dsi_stop(dsi);
You never start dsi before here, why do you stop dsi here?
> + mtk_dsi_poweroff(dsi);
Refer to next comment, you may goto undo item in bottom of this
function.
> + return;
> + }
> + }
>
> mtk_dsi_set_mode(dsi);
> mtk_dsi_clk_hs_mode(dsi, 1);
>
> mtk_dsi_start(dsi);
>
> + if (dsi->panel) {
> + if (drm_panel_enable(dsi->panel)) {
> + DRM_ERROR("failed to enable the panel\n");
> +
> + if (drm_panel_unprepare(dsi->panel))
> + DRM_ERROR("failed to unprepare the panel\n");
> +
> + mtk_dsi_stop(dsi);
I think you should stop dsi before panel unprepare. Otherwise, why not
move these undo item to the bottom of this function. For example:
if (drm_panel_enable(dsi->panel)) {
DRM_ERROR("failed to enable the panel\n");
goto stop_dsi;
...
dsi->enabled = true;
return;
stop_dsi:
mtk_dsi_stop(dsi);
if (drm_panel_unprepare(dsi->panel))
DRM_ERROR("failed to unprepare the panel\n");
poweroff_dsi:
mtk_dsi_poweroff(dsi);
return;
> + mtk_dsi_poweroff(dsi);
> + return;
> + }
> + }
> +
> dsi->enabled = true;
> }
>
> @@ -608,6 +654,19 @@ static void mtk_output_dsi_disable(struct mtk_dsi *dsi)
> }
> }
>
> + mtk_dsi_stop(dsi);
Even though dsi does not directly connect to panel, you newly stop dsi
here. This looks like a bug fix.
> + if (!mtk_dsi_switch_to_cmd_mode(dsi, VM_DONE_INT_FLAG, 500)) {
ditto.
> + if (dsi->panel) {
> + if (drm_panel_unprepare(dsi->panel))
> + DRM_ERROR("failed to unprepare the panel\n");
> + }
> + }
> +
> + mtk_dsi_reset_engine(dsi);
ditto.
> + mtk_dsi_lane0_ulp_mode_enter(dsi);
> + mtk_dsi_clk_ulp_mode_enter(dsi);
> + mtk_dsi_disable(dsi);
> +
> mtk_dsi_poweroff(dsi);
>
> dsi->enabled = false;
Regards,
CK
^ permalink raw reply
* [PATCH 06/10] iommu: of: Handle IOMMU lookup failure with deferred probing or error
From: Marek Szyprowski @ 2016-11-30 7:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480465344-11862-7-git-send-email-sricharan@codeaurora.org>
Hi Sricharan and Robin,
On 2016-11-30 01:22, Sricharan R wrote:
> 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.
>
> Signed-off-by: Laurent Pichart <laurent.pinchart+renesas@ideasonboard.com>
> Signed-off-by: Sricharan R <sricharan@codeaurora.org>
> [rm: massive PCI hacks]
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> ---
> drivers/base/dma-mapping.c | 4 ++--
> drivers/iommu/dma-iommu.c | 1 +
> drivers/iommu/of_iommu.c | 5 +++--
> drivers/of/device.c | 9 +++++++--
> drivers/pci/probe.c | 6 ++++--
> include/linux/of_device.h | 9 ++++++---
> include/linux/pci.h | 4 ++--
> 7 files changed, 25 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/base/dma-mapping.c b/drivers/base/dma-mapping.c
> index b2a5629..576fdfb 100644
> --- a/drivers/base/dma-mapping.c
> +++ b/drivers/base/dma-mapping.c
> @@ -351,9 +351,9 @@ void dma_common_free_remap(void *cpu_addr, size_t size, unsigned long vm_flags)
> int dma_configure(struct device *dev)
> {
> if (dev_is_pci(dev))
> - pci_dma_configure(dev);
> + return pci_dma_configure(dev);
> else if (dev->of_node)
> - of_dma_configure(dev, dev->of_node);
> + return of_dma_configure(dev, dev->of_node);
> return 0;
> }
>
> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> index c5ab866..d2a7a46 100644
> --- a/drivers/iommu/dma-iommu.c
> +++ b/drivers/iommu/dma-iommu.c
> @@ -148,6 +148,7 @@ int iommu_dma_init_domain(struct iommu_domain *domain, dma_addr_t base,
> base_pfn = max_t(unsigned long, 1, base >> order);
> end_pfn = (base + size - 1) >> order;
>
> + dev_info(dev, "0x%llx 0x%llx, 0x%llx 0x%llx, 0x%llx 0x%llx\n", base, size, domain->geometry.aperture_start, domain->geometry.aperture_end,
This causes a NULL pointer dereference if caller passes NULL device pointer.
There is such caller in drivers/gpu/drm/exynos/exynos_drm_iommu.h.
Trivial to fix as it looks like a leftover from developement or
debugging stage.
> *dev->dma_mask, dev->coherent_dma_mask);
> /* Check the domain allows at least some access to the device... */
> if (domain->geometry.force_aperture) {
> if (base > domain->geometry.aperture_end ||
> diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
> index 349bd1d..9529d6c 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
> @@ -223,7 +224,7 @@ const struct iommu_ops *of_iommu_configure(struct device *dev,
> ops = ERR_PTR(err);
> }
>
> - return IS_ERR(ops) ? NULL : ops;
> + return ops;
> }
>
> static int __init of_iommu_init(void)
> @@ -234,7 +235,7 @@ static int __init of_iommu_init(void)
> for_each_matching_node_and_match(np, matches, &match) {
> const of_iommu_init_fn init_fn = match->data;
>
> - if (init_fn(np))
> + if (init_fn && init_fn(np))
> pr_err("Failed to initialise IOMMU %s\n",
> of_node_full_name(np));
> }
> diff --git a/drivers/of/device.c b/drivers/of/device.c
> index 1c843e2..d58595c 100644
> --- a/drivers/of/device.c
> +++ b/drivers/of/device.c
> @@ -82,7 +82,7 @@ int of_device_add(struct platform_device *ofdev)
> * can use a platform bus notifier and handle BUS_NOTIFY_ADD_DEVICE events
> * to fix up DMA configuration.
> */
> -void of_dma_configure(struct device *dev, struct device_node *np)
> +int of_dma_configure(struct device *dev, struct device_node *np)
> {
> u64 dma_addr, paddr, size;
> int ret;
> @@ -107,7 +107,7 @@ void of_dma_configure(struct device *dev, struct device_node *np)
> ret = of_dma_get_range(np, &dma_addr, &paddr, &size);
> if (ret < 0) {
> dma_addr = offset = 0;
> - size = dev->coherent_dma_mask + 1;
> + size = max(dev->coherent_dma_mask, dev->coherent_dma_mask + 1);
> } else {
> offset = PFN_DOWN(paddr - dma_addr);
> dev_dbg(dev, "dma_pfn_offset(%#08lx)\n", offset);
> @@ -129,10 +129,15 @@ void of_dma_configure(struct device *dev, struct device_node *np)
> coherent ? " " : " not ");
>
> iommu = of_iommu_configure(dev, np);
> + if (IS_ERR(iommu))
> + return PTR_ERR(iommu);
> +
> dev_dbg(dev, "device is%sbehind an iommu\n",
> iommu ? " " : " not ");
>
> arch_setup_dma_ops(dev, dma_addr, size, iommu, coherent);
> +
> + return 0;
> }
> EXPORT_SYMBOL_GPL(of_dma_configure);
>
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index 04af770..6316cae 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -1724,13 +1724,14 @@ static void pci_set_msi_domain(struct pci_dev *dev)
> * Function to update PCI devices's DMA configuration using the same
> * info from the OF node or ACPI node of host bridge's parent (if any).
> */
> -void pci_dma_configure(struct device *dev)
> +int pci_dma_configure(struct device *dev)
> {
> struct device *bridge = pci_get_host_bridge_device(to_pci_dev(dev));
> + int ret = 0;
>
> if (IS_ENABLED(CONFIG_OF) &&
> bridge->parent && bridge->parent->of_node) {
> - of_dma_configure(dev, bridge->parent->of_node);
> + ret = of_dma_configure(dev, bridge->parent->of_node);
> } else if (has_acpi_companion(bridge)) {
> struct acpi_device *adev = to_acpi_device_node(bridge->fwnode);
> enum dev_dma_attr attr = acpi_get_dma_attr(adev);
> @@ -1742,6 +1743,7 @@ void pci_dma_configure(struct device *dev)
> }
>
> pci_put_host_bridge_device(bridge);
> + return ret;
> }
>
> void pci_device_add(struct pci_dev *dev, struct pci_bus *bus)
> diff --git a/include/linux/of_device.h b/include/linux/of_device.h
> index d20a31a..6dca65c 100644
> --- a/include/linux/of_device.h
> +++ b/include/linux/of_device.h
> @@ -55,7 +55,7 @@ static inline struct device_node *of_cpu_device_node_get(int cpu)
> return of_node_get(cpu_dev->of_node);
> }
>
> -void of_dma_configure(struct device *dev, struct device_node *np);
> +int of_dma_configure(struct device *dev, struct device_node *np);
> void of_dma_deconfigure(struct device *dev);
> #else /* CONFIG_OF */
>
> @@ -99,8 +99,11 @@ static inline struct device_node *of_cpu_device_node_get(int cpu)
> {
> return NULL;
> }
> -static inline void of_dma_configure(struct device *dev, struct device_node *np)
> -{}
> +
> +static inline int of_dma_configure(struct device *dev, struct device_node *np)
> +{
> + return 0;
> +}
> static inline void of_dma_deconfigure(struct device *dev)
> {}
> #endif /* CONFIG_OF */
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index d04f651..989ca44 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -870,7 +870,7 @@ struct resource *pci_find_parent_resource(const struct pci_dev *dev,
> #define dev_is_pf(d) ((dev_is_pci(d) ? to_pci_dev(d)->is_physfn : false))
> #define dev_num_vf(d) ((dev_is_pci(d) ? pci_num_vf(to_pci_dev(d)) : 0))
>
> -void pci_dma_configure(struct device *dev);
> +int pci_dma_configure(struct device *dev);
>
> /* Generic PCI functions exported to card drivers */
>
> @@ -1604,7 +1604,7 @@ static inline struct pci_dev *pci_get_bus_and_slot(unsigned int bus,
> #define dev_is_pf(d) (false)
> #define dev_num_vf(d) (0)
>
> -static inline void pci_dma_configure(struct device *dev) { }
> +static inline int pci_dma_configure(struct device *dev) { return 0; }
>
> #endif /* CONFIG_PCI */
>
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* [PATCH] arm64: dts: add zx296718's topcrm node
From: Baoyou Xie @ 2016-11-30 7:33 UTC (permalink / raw)
To: linux-arm-kernel
Enable topcrm clock node for zx296718, which is used for
CPU's frequency change.
Furthermore, this patch adds the CPU clock phandle in CPU's node
and uses operating-points-v2 to register operating points.
So it can be used by cpufreq-dt driver.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
---
arch/arm64/boot/dts/zte/zx296718.dtsi | 48 +++++++++++++++++++++++++++++++++++
1 file changed, 48 insertions(+)
diff --git a/arch/arm64/boot/dts/zte/zx296718.dtsi b/arch/arm64/boot/dts/zte/zx296718.dtsi
index 6b239a3..f9eb37d 100644
--- a/arch/arm64/boot/dts/zte/zx296718.dtsi
+++ b/arch/arm64/boot/dts/zte/zx296718.dtsi
@@ -44,6 +44,7 @@
#include <dt-bindings/input/input.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/clock/zx296718-clock.h>
/ {
compatible = "zte,zx296718";
@@ -81,6 +82,8 @@
compatible = "arm,cortex-a53","arm,armv8";
reg = <0x0 0x0>;
enable-method = "psci";
+ clocks = <&topcrm A53_GATE>;
+ operating-points-v2 = <&cluster0_opp>;
};
cpu1: cpu at 1 {
@@ -88,6 +91,7 @@
compatible = "arm,cortex-a53","arm,armv8";
reg = <0x0 0x1>;
enable-method = "psci";
+ operating-points-v2 = <&cluster0_opp>;
};
cpu2: cpu at 2 {
@@ -95,6 +99,7 @@
compatible = "arm,cortex-a53","arm,armv8";
reg = <0x0 0x2>;
enable-method = "psci";
+ operating-points-v2 = <&cluster0_opp>;
};
cpu3: cpu at 3 {
@@ -102,6 +107,43 @@
compatible = "arm,cortex-a53","arm,armv8";
reg = <0x0 0x3>;
enable-method = "psci";
+ operating-points-v2 = <&cluster0_opp>;
+ };
+ };
+
+ cluster0_opp: opp_table0 {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp at 1000000000 {
+ opp-hz = /bits/ 64 <500000000>;
+ opp-microvolt = <857000>;
+ clock-latency-ns = <500000>;
+ };
+ opp at 1100000000 {
+ opp-hz = /bits/ 64 <648000000>;
+ opp-microvolt = <857000>;
+ clock-latency-ns = <500000>;
+ };
+ opp at 1200000000 {
+ opp-hz = /bits/ 64 <800000000>;
+ opp-microvolt = <882000>;
+ clock-latency-ns = <500000>;
+ };
+ opp at 1300000000 {
+ opp-hz = /bits/ 64 <1000000000>;
+ opp-microvolt = <892000>;
+ clock-latency-ns = <500000>;
+ };
+ opp at 1400000000 {
+ opp-hz = /bits/ 64 <1188000000>;
+ opp-microvolt = <1009000>;
+ clock-latency-ns = <500000>;
+ };
+ opp at 1500000000 {
+ opp-hz = /bits/ 64 <1312000000>;
+ opp-microvolt = <1052000>;
+ clock-latency-ns = <500000>;
};
};
@@ -279,6 +321,12 @@
dma-requests = <32>;
};
+ topcrm: clock-controller at 01461000 {
+ compatible = "zte,zx296718-topcrm";
+ reg = <0x01461000 0x1000>;
+ #clock-cells = <1>;
+ };
+
sysctrl: sysctrl at 1463000 {
compatible = "zte,zx296718-sysctrl", "syscon";
reg = <0x1463000 0x1000>;
--
2.7.4
^ permalink raw reply related
* [PATCH v9 07/11] arm/arm64: vgic: Implement KVM_DEV_ARM_VGIC_GRP_LEVEL_INFO ioctl
From: Peter Maydell @ 2016-11-30 7:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161129210901.GC15346@cbox>
On 29 November 2016 at 21:09, Christoffer Dall
<christoffer.dall@linaro.org> wrote:
> Actually, I'm not sure what the semantics of the line level ioctl should
> be for edge-triggered interrupts? My inclination is that it shouldn't
> have any effect at this point, but that would mean that at this point we
> should only set the pending variable and try to queue the interrupt if
> the config is level. But that also means that when we set the config
> later, we need to try to queue the interrupt, which we don't do
> currently, because we rely on the guest not fiddling with the config of
> an enabled interrupt.
>
> Could it be considered an error if user space tries to set the level for
> an edge-triggered interrupt and therefore something we can just ignore
> and assume that the corresponing interrupt will be configured as a
> level-triggered one later?
Userspace will always read the line-level values out and write
them back for migration, and I'd rather not make it have to
do cross-checks against whether the interrupt is edge or level
triggered to see whether it should write the level values into
the kernel. Telling the kernel the level for an edge-triggered
interrupt should be a no-op because it doesn't have any effect
on pending status.
> In any case we probably need to clarify the ABI in terms of this
> particular KVM_DEV_AR_VGIC_GRP_LEVEL_INFO group and how it relates to
> the config of edge vs. level of interrupts and ordering on restore...
IIRC the QEMU code restores the config first. (There's a similar
ordering thing for GICv2 where we have to restore GICD_ICFGRn before
GICD_ISPENDRn.)
thanks
-- PMM
^ permalink raw reply
* [RFC3 nowrap: PATCH v7 00/18] ILP32 for ARM64
From: Adam Borowski @ 2016-11-30 6:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161130050209.GB18796@yury-N73SV>
On Wed, Nov 30, 2016 at 10:32:09AM +0530, Yury Norov wrote:
> On Fri, Oct 21, 2016 at 11:32:59PM +0300, Yury Norov wrote:
> > This series enables aarch64 with ilp32 mode, and as supporting work,
> > introduces ARCH_32BIT_OFF_T configuration option that is enabled for
> > existing 32-bit architectures but disabled for new arches (so 64-bit
> > off_t is is used by new userspace).
>
> Hi all,
>
> Steve Ellcey submitted glibc patches for ILP32:
> https://www.sourceware.org/ml/libc-alpha/2016-11/msg01071.html
> It implicitly assumes that kernel clears top halves of registers for
> all syscalls in assembly entry. That patches are going to be taken.
> It it happens, we will have no choice on kernel side how to clear top
> halves anymore.
Since a while ago, there's a package "arch-test" in Debian that empirically
enumerates architectures executable by the running kernel (and loaded
binfmts), by trying small test programs for each. The list of architectures
it knows does include arm64ilp32.
For most archs the test is just {write(1, "ok\n"); _exit(0);} unless there's
some difference from baseline that should be checked for, like dmb (ARMv7)
on armhf or mtvsrd (POWER8) on ppc64el. I could scribble in the top half of
a register to test the delousing, but it's not like alternate versions of
the ABI are expected in the wild...
There's another issue: name. A stalled request to add it to dpkg's cputable
(https://bugs.debian.org/824742) uses "arm64ilp32" and "arm64ilp32be" which
are unwieldy. Even the discussion uses "ilp32" -- probably too generic.
https://wiki.linaro.org/Platform/arm64-ilp32 mentions both. I've heard
"a32" somewhere. I have no stake here (I'm on the CC list as a x32 not arm
porter...), but if you want to choose a color for this bikeshed, the time
is now.
Meow!
--
The bill declaring Jesus as the King of Poland fails to specify whether
the addition is at the top or end of the list of kings. What should the
historians do?
^ permalink raw reply
* [PATCH v10 02/13] drm/mediatek: add *driver_data for different hardware settings
From: Daniel Kurtz @ 2016-11-30 6:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480070076-6196-3-git-send-email-yt.shen@mediatek.com>
Hi YT,
On Fri, Nov 25, 2016 at 6:34 PM, YT Shen <yt.shen@mediatek.com> wrote:
>
> There are some hardware settings changed, between MT8173 & MT2701:
> DISP_OVL address offset changed, color format definition changed.
> DISP_RDMA fifo size changed.
> DISP_COLOR offset changed.
> MIPI_TX pll setting changed.
> And add prefix for mtk_ddp_main & mtk_ddp_ext & mutex_mod.
Sorry, I have not had time to thoroughly review the new patch set, but
one quick comment:
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> index 22a33ee..cfaa760 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> @@ -78,6 +78,10 @@ struct mtk_ddp_comp_funcs {
> struct drm_crtc_state *state);
> };
>
> +struct mtk_ddp_comp_driver_data {
> + unsigned int color_offset;
> +};
> +
> struct mtk_ddp_comp {
> struct clk *clk;
> void __iomem *regs;
> @@ -85,6 +89,7 @@ struct mtk_ddp_comp {
> struct device *larb_dev;
> enum mtk_ddp_comp_id id;
> const struct mtk_ddp_comp_funcs *funcs;
> + const struct mtk_ddp_comp_driver_data *data;
I want to avoid adding this generic pointer here to all mtk_ddp_comp,
since this is only used by the color component.
Instead, define color specific types:
struct mtk_disp_color_data {
unsigned int offset;
};
struct mtk_disp_color {
struct mtk_ddp_comp ddp_comp;
const struct mtk_disp_color_data *data;
};
Then, add another comp_type check and fetch the dev data in
mtk_drm_probe() or maybe mtk_ddp_comp_init().
-Dan
^ 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