* [PATCH v27 1/9] memblock: add memblock_cap_memory_range()
From: AKASHI Takahiro @ 2016-11-17 5:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161116163015.GM7928@arm.com>
Will,
On Wed, Nov 16, 2016 at 04:30:15PM +0000, Will Deacon wrote:
> Hi Akashi,
>
> On Mon, Nov 14, 2016 at 02:55:16PM +0900, AKASHI Takahiro wrote:
> > On Fri, Nov 11, 2016 at 11:19:04AM +0800, Dennis Chen wrote:
> > > On Fri, Nov 11, 2016 at 11:50:50AM +0900, AKASHI Takahiro wrote:
> > > > On Thu, Nov 10, 2016 at 05:27:20PM +0000, Will Deacon wrote:
> > > > > On Wed, Nov 02, 2016 at 01:51:53PM +0900, AKASHI Takahiro wrote:
> > > > > > +void __init memblock_cap_memory_range(phys_addr_t base, phys_addr_t size)
> > > > > > +{
> > > > > > + int start_rgn, end_rgn;
> > > > > > + int i, ret;
> > > > > > +
> > > > > > + if (!size)
> > > > > > + return;
> > > > > > +
> > > > > > + ret = memblock_isolate_range(&memblock.memory, base, size,
> > > > > > + &start_rgn, &end_rgn);
> > > > > > + if (ret)
> > > > > > + return;
> > > > > > +
> > > > > > + /* remove all the MAP regions */
> > > > > > + for (i = memblock.memory.cnt - 1; i >= end_rgn; i--)
> > > > > > + if (!memblock_is_nomap(&memblock.memory.regions[i]))
> > > > > > + memblock_remove_region(&memblock.memory, i);
> > > > > > +
> > > > > > + for (i = start_rgn - 1; i >= 0; i--)
> > > > > > + if (!memblock_is_nomap(&memblock.memory.regions[i]))
> > > > > > + memblock_remove_region(&memblock.memory, i);
> > > > > > +
> > > > > > + /* truncate the reserved regions */
> > > > > > + memblock_remove_range(&memblock.reserved, 0, base);
> > > > > > + memblock_remove_range(&memblock.reserved,
> > > > > > + base + size, (phys_addr_t)ULLONG_MAX);
> > > > > > +}
> > > > >
> > > > > This duplicates a bunch of the logic in memblock_mem_limit_remove_map. Can
> > > > > you not implement that in terms of your new, more general, function? e.g.
> > > > > by passing base == 0, and size == limit?
> > > >
> > > > Obviously it's possible.
> > > > I actually talked to Dennis before about merging them,
> > > > but he was against my idea.
> > > >
> > > Oops! I thought we have reached agreement in the thread:http://lists.infradead.org/pipermail/linux-arm-kernel/2016-July/442817.html
> > > So feel free to do that as Will'll do
> >
> > OK, but I found that the two functions have a bit different semantics
> > in clipping memory range, in particular, when the range [base,base+size)
> > goes across several regions with a gap.
> > (This does not happen in my arm64 kdump, though.)
> > That is, 'limit' in memblock_mem_limit_remove_map() means total size of
> > available memory, while 'size' in memblock_cap_memory_range() indicates
> > the size of _continuous_ memory range.
>
> I thought limit was just a physical address, and then
No, it's not.
> memblock_mem_limit_remove_map operated on the end of the nearest memblock?
No, but "max_addr" returned by __find_max_addr() is a physical address
and the end address of memory of "limit" size in total.
> You could leave the __find_max_addr call in memblock_mem_limit_remove_map,
> given that I don't think you need/want it for memblock_cap_memory_range.
>
> > So I added an extra argument, exact, to a common function to specify
> > distinct behaviors. Confusing? Please see the patch below.
>
> Oh yikes, this certainly wasn't what I had in mind! My observation was
> just that memblock_mem_limit_remove_map(limit) does:
>
>
> 1. memblock_isolate_range(limit - limit+ULLONG_MAX)
> 2. memblock_remove_region(all non-nomap regions in the isolated region)
> 3. truncate reserved regions to limit
>
> and your memblock_cap_memory_range(base, size) does:
>
> 1. memblock_isolate_range(base - base+size)
> 2, memblock_remove_region(all non-nomap regions above and below the
> isolated region)
> 3. truncate reserved regions around the isolated region
>
> so, assuming we can invert the isolation in one of the cases, then they
> could share the same underlying implementation.
Please see my simplified patch below which would explain what I meant.
(Note that the size is calculated by 'max_addr - 0'.)
> I'm probably just missing something here, because the patch you've ended
> up with is far more involved than I anticipated...
I hope that it will meet almost your anticipation.
Thanks,
-Takahiro AKASHI
>
> Will
===8<===
diff --git a/mm/memblock.c b/mm/memblock.c
index 7608bc3..fea1688 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -1514,11 +1514,37 @@ void __init memblock_enforce_memory_limit(phys_addr_t limit)
(phys_addr_t)ULLONG_MAX);
}
+void __init memblock_cap_memory_range(phys_addr_t base, phys_addr_t size)
+{
+ int start_rgn, end_rgn;
+ int i, ret;
+
+ if (!size)
+ return;
+
+ ret = memblock_isolate_range(&memblock.memory, base, size,
+ &start_rgn, &end_rgn);
+ if (ret)
+ return;
+
+ /* remove all the MAP regions */
+ for (i = memblock.memory.cnt - 1; i >= end_rgn; i--)
+ if (!memblock_is_nomap(&memblock.memory.regions[i]))
+ memblock_remove_region(&memblock.memory, i);
+
+ for (i = start_rgn - 1; i >= 0; i--)
+ if (!memblock_is_nomap(&memblock.memory.regions[i]))
+ memblock_remove_region(&memblock.memory, i);
+
+ /* truncate the reserved regions */
+ memblock_remove_range(&memblock.reserved, 0, base);
+ memblock_remove_range(&memblock.reserved,
+ base + size, (phys_addr_t)ULLONG_MAX);
+}
+
void __init memblock_mem_limit_remove_map(phys_addr_t limit)
{
- struct memblock_type *type = &memblock.memory;
phys_addr_t max_addr;
- int i, ret, start_rgn, end_rgn;
if (!limit)
return;
@@ -1529,19 +1555,7 @@ void __init memblock_mem_limit_remove_map(phys_addr_t limit)
if (max_addr == (phys_addr_t)ULLONG_MAX)
return;
- ret = memblock_isolate_range(type, max_addr, (phys_addr_t)ULLONG_MAX,
- &start_rgn, &end_rgn);
- if (ret)
- return;
-
- /* remove all the MAP regions above the limit */
- for (i = end_rgn - 1; i >= start_rgn; i--) {
- if (!memblock_is_nomap(&type->regions[i]))
- memblock_remove_region(type, i);
- }
- /* truncate the reserved regions */
- memblock_remove_range(&memblock.reserved, max_addr,
- (phys_addr_t)ULLONG_MAX);
+ memblock_cap_memory_range(0, max_addr);
}
static int __init_memblock memblock_search(struct memblock_type *type, phys_addr_t addr)
^ permalink raw reply related
* [PATCH v5] drm/mediatek: fixed the calc method of data rate per lane
From: CK Hu @ 2016-11-17 5:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479266454-31892-1-git-send-email-jitao.shi@mediatek.com>
Hi, Jitao:
On Wed, 2016-11-16 at 11:20 +0800, Jitao Shi wrote:
> Tune dsi frame rate by pixel clock, dsi add some extra signal (i.e.
> Tlpx, Ths-prepare, Ths-zero, Ths-trail,Ths-exit) when enter and exit LP
> mode, those signals will cause h-time larger than normal and reduce FPS.
> So need to multiply a coefficient to offset the extra signal's effect.
> coefficient = ((htotal*bpp/lane_number)+Tlpx+Ths_prep+Ths_zero+
> Ths_trail+Ths_exit)/(htotal*bpp/lane_number)
>
> Signed-off-by: Jitao Shi <jitao.shi@mediatek.com>
It looks good to me.
But this patch conflict with [1] which is one patch of MT2701 series. I
want to apply MT2701 patches first, so please help to refine this patch
based on MT2701 patches.
[1] https://patchwork.kernel.org/patch/9422821/
Regards,
CK
> ---
> Change since v4:
> - tune the calc comment more clear.
> - define the phy timings as constants.
>
> Chnage since v3:
> - wrapp the commit msg.
> - fix alignment of some lines.
>
> Change since v2:
> - move phy timing back to dsi_phy_timconfig.
>
> Change since v1:
> - phy_timing2 and phy_timing3 refer clock cycle time.
> - define values of LPX HS_PRPR HS_ZERO HS_TRAIL TA_GO TA_SURE TA_GET DA_HS_EXIT.
> ---
>
^ permalink raw reply
* [RFC PATCH] mfd: dt: Add Aspeed LPC binding
From: Andrew Jeffery @ 2016-11-17 6:06 UTC (permalink / raw)
To: linux-arm-kernel
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
---
I'd like to start a discussion about how to handle the LPC register space in
the Aspeed SoC. There are a number of issues, largely concerned with the layout
of the registers but also with the fact that LPC register state is used by the
pinmux to determine some pin functionality.
So the register layout is problematic. Registers for what I think are coherent
pieces of functionality functionality are littered through the layout: Post
Code Control registers (PCCR) are interleaved with LPC Host Controller
registers (LHCR) which are interleaved with Host Interface Controller registers
(HICR) which are segmented by LPC Snoop registers. It seems appropriate that
the whole thing is represented as an MFD syscon, with the alternative being
writing several distinct drivers that map some number of resources to access
all of their registers.
The disadvantage of not representing the LPC space as a syscon is the LPC Host
Controller driver will need to provide accessor functions for the pinmux
driver. Pinmux also depends on bits in the Display Controller, and would need
similar accessors provided there. The idea of using syscon regmaps removes the
need to write these accessors. If the changes between the AST2400 and AST2500
are anything to go by, the pinmux complexity of the SoCs will only increase
which will likely lead to the spread of these accessor functions.
Yet another option would be to only expose the LPC Host Controller as a syscon
instead of the whole LPC register space. I feel this is a little distasteful
as the LHCRs are not in contiguous memory space; as mentioned above they are
separated (seemingly randomly) by a PCCR. We could specify the LPC Host
Controller as a syscon and provide multiple resources: The syscon
implementation consumes the first resource which is what we desire here for use
with pinmux, but the driver would be left to map any subsequent resources. That
feels odd to me, but I'm interested in arguments for it.
We could also map the LPC Host Controller syscon across the offending PCCR, but
then any driver developed for the Post Code Controller would have to take a
reference to the LPC Host Controller regmap. I feel like we might wind up with
a syscon phandle spaghetti across the LPC controller if we use that approach.
Finally, the LPC registers can be divided in two: one set for H8S/2168
compatible LPC functionality, and the rest for Aspeed-specific registers.
Division in two is required if we are going to throw a regmap over the LPC
space as the H8S/2168 registers are 1-byte wide, whilst the Aspeed LPC
registers are 4-bytes. As far as I can tell we can treat them as separate
functionality without any loss; if there is a cross-over in configuration we
can have each phandle the other in the devicetree.
The final complication is the iBT device sits in the Aspeed-specific part of
the LPC controller and has an upstream driver that isn't regmap-capable.
Describing the LPC controller as a syscon will require some changes there, but
I think we can make it work without too much trouble.
What is the recommended approach to managing such hardware?
Cheers,
Andrew
PS: I sent a devicetree binding document out for the LPC Host Controller as
part of a recent pinmux series[1]. As it stands the example in the document
doesn't cover the all the registers relevant to the LPC Host Controller, which
was a motivation for trying to sort the problem out properly.
[1] https://www.spinics.net/lists/arm-kernel/msg540084.html
.../devicetree/bindings/mfd/aspeed-lpc.txt | 28 ++++++++++++++++++++++
1 file changed, 28 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
diff --git a/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt b/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
new file mode 100644
index 000000000000..36c8a9e08dc6
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
@@ -0,0 +1,28 @@
+* Device tree bindings for the Aspeed LPC Controller
+
+The Aspeed LPC controller contains registers for a variety of functions. Not
+all registers for a function are contiguous, and some registers are referenced
+by functions outside the LPC controller.
+
+Note that this is separate from the H8S/2168 compatible register set occupying
+the start of the LPC controller address space.
+
+Some significant functions in the LPC controller:
+
+* LPC Host Controller
+* Host Interface Controller
+* iBT Controller
+* SuperIO Scratch registers
+
+Required properties:
+- compatible: "aspeed,ast2500-lpc", "syscon"
+- reg: contains offset/length value of the Aspeed-specific LPC
+ memory region.
+
+Example:
+
+lpc: lpc at 1e7890a0 {
+ compatible = "aspeed,ast2500-lpc", "syscon";
+ reg = <0x1e789080 0x1e0>;
+};
+
--
2.9.3
^ permalink raw reply related
* [PATCH fpga 4/9] fpga zynq: Check for errors after completing DMA
From: Moritz Fischer @ 2016-11-17 6:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478732303-13718-5-git-send-email-jgunthorpe@obsidianresearch.com>
Hi Jason,
couple of minor things inline below:
On Wed, Nov 9, 2016 at 2:58 PM, Jason Gunthorpe
<jgunthorpe@obsidianresearch.com> wrote:
> The completion did not check the interrupt status to see if any error
> bits were asserted, check error bits and dump some registers if things
> went wrong.
>
> A few fixes are needed to make this work, the IXR_ERROR_FLAGS_MASK was
> wrong, it included the done bits, which shows a bug in mask/unmask_irqs
> which were using the wrong bits, simplify all of this stuff.
>
> Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
> ---
> drivers/fpga/zynq-fpga.c | 55 +++++++++++++++++++++++++++---------------------
> 1 file changed, 31 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/fpga/zynq-fpga.c b/drivers/fpga/zynq-fpga.c
> index 40cf0feaca7c..3ffc5fcc3072 100644
> --- a/drivers/fpga/zynq-fpga.c
> +++ b/drivers/fpga/zynq-fpga.c
> @@ -89,7 +89,7 @@
> #define IXR_D_P_DONE_MASK BIT(12)
> /* FPGA programmed */
> #define IXR_PCFG_DONE_MASK BIT(2)
> -#define IXR_ERROR_FLAGS_MASK 0x00F0F860
> +#define IXR_ERROR_FLAGS_MASK 0x00F0C860
True. Ouch.
> #define IXR_ALL_MASK 0xF8F7F87F
>
> /* Miscellaneous constant values */
> @@ -144,23 +144,10 @@ static inline u32 zynq_fpga_read(const struct zynq_fpga_priv *priv,
> readl_poll_timeout(priv->io_base + addr, val, cond, sleep_us, \
> timeout_us)
>
> -static void zynq_fpga_mask_irqs(struct zynq_fpga_priv *priv)
> +static inline void zynq_fpga_set_irq_mask(struct zynq_fpga_priv *priv,
> + u32 enable)
> {
> - u32 intr_mask;
> -
> - intr_mask = zynq_fpga_read(priv, INT_MASK_OFFSET);
> - zynq_fpga_write(priv, INT_MASK_OFFSET,
> - intr_mask | IXR_DMA_DONE_MASK | IXR_ERROR_FLAGS_MASK);
> -}
> -
> -static void zynq_fpga_unmask_irqs(struct zynq_fpga_priv *priv)
> -{
> - u32 intr_mask;
> -
> - intr_mask = zynq_fpga_read(priv, INT_MASK_OFFSET);
> - zynq_fpga_write(priv, INT_MASK_OFFSET,
> - intr_mask
> - & ~(IXR_D_P_DONE_MASK | IXR_ERROR_FLAGS_MASK));
> + zynq_fpga_write(priv, INT_MASK_OFFSET, ~enable);
Not a fan of this ~enable here. Function name indicates you're doing
the opposite
(see below comment).
> }
>
> static irqreturn_t zynq_fpga_isr(int irq, void *data)
> @@ -168,7 +155,7 @@ static irqreturn_t zynq_fpga_isr(int irq, void *data)
> struct zynq_fpga_priv *priv = data;
>
> /* disable DMA and error IRQs */
> - zynq_fpga_mask_irqs(priv);
> + zynq_fpga_set_irq_mask(priv, 0);
>
> complete(&priv->dma_done);
>
> @@ -314,6 +301,7 @@ static int zynq_fpga_ops_write(struct fpga_manager *mgr,
> const char *buf, size_t count)
> {
> struct zynq_fpga_priv *priv;
> + const char *why;
> int err;
> char *kbuf;
> dma_addr_t dma_addr;
> @@ -337,7 +325,7 @@ static int zynq_fpga_ops_write(struct fpga_manager *mgr,
> reinit_completion(&priv->dma_done);
>
> /* enable DMA and error IRQs */
> - zynq_fpga_unmask_irqs(priv);
> + zynq_fpga_set_irq_mask(priv, IXR_D_P_DONE_MASK | IXR_ERROR_FLAGS_MASK);
I find the naming here confusing. This sets ~(IXR_D_P_DONE_MASK |
IXR_ERROR_FLAGS_MASK)
as mask value, to enable the D_P_DONE and error IRQs yet the function
name indicates the opposite.
>
> /* the +1 in the src addr is used to hold off on DMA_DONE IRQ
> * until both AXI and PCAP are done ...
> @@ -352,16 +340,35 @@ static int zynq_fpga_ops_write(struct fpga_manager *mgr,
> intr_status = zynq_fpga_read(priv, INT_STS_OFFSET);
> zynq_fpga_write(priv, INT_STS_OFFSET, intr_status);
>
> + if (intr_status & IXR_ERROR_FLAGS_MASK) {
> + why = "DMA reported error";
> + err = -EIO;
> + goto out_report;
> + }
> +
> if (!((intr_status & IXR_D_P_DONE_MASK) == IXR_D_P_DONE_MASK)) {
> - dev_err(priv->dev, "Error configuring FPGA\n");
> - err = -EFAULT;
> + why = "DMA did not complete";
> + err = -EIO;
> + goto out_report;
> }
>
> + err = 0;
> + goto out_clk;
> +
> +out_report:
> + dev_err(priv->dev,
> + "%s: INT_STS:0x%x CTRL:0x%x LOCK:0x%x INT_MASK:0x%x STATUS:0x%x MCTRL:0x%x\n",
> + why,
> + intr_status,
> + zynq_fpga_read(priv, CTRL_OFFSET),
> + zynq_fpga_read(priv, LOCK_OFFSET),
> + zynq_fpga_read(priv, INT_MASK_OFFSET),
> + zynq_fpga_read(priv, STATUS_OFFSET),
> + zynq_fpga_read(priv, MCTRL_OFFSET));
> +out_clk:
> clk_disable(priv->clk);
> -
Personally found it more readable with newline.
> out_free:
> dma_free_coherent(priv->dev, count, kbuf, dma_addr);
> -
Same here.
> return err;
> }
>
> @@ -475,7 +482,7 @@ static int zynq_fpga_probe(struct platform_device *pdev)
> /* unlock the device */
> zynq_fpga_write(priv, UNLOCK_OFFSET, UNLOCK_MASK);
>
> - zynq_fpga_write(priv, INT_MASK_OFFSET, 0xFFFFFFFF);
> + zynq_fpga_set_irq_mask(priv, 0);
> zynq_fpga_write(priv, INT_STS_OFFSET, IXR_ALL_MASK);
> err = devm_request_irq(dev, priv->irq, zynq_fpga_isr, 0, dev_name(dev),
> priv);
> --
> 2.1.4
>
Thanks,
Moritz
^ permalink raw reply
* [PATCH v10 01/11] remoteproc: st_slim_rproc: add a slimcore rproc driver
From: Bjorn Andersson @ 2016-11-17 6:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161114051854.GW3000@localhost>
On Sun 13 Nov 21:18 PST 2016, Vinod Koul wrote:
> On Mon, Nov 07, 2016 at 01:57:35PM +0000, Peter Griffin wrote:
> > >
> > > As you now make changes to the entire remoteproc Kconfig file, rather
> > > than simply add a Kconfig symbol we can't bring this in via Vinod's tree
> > > without providing Linus with a messy merge conflict.
> > >
> > > So the remoteproc parts now has to go through my tree.
> >
> > OK, I think the best approach is for Vinod to create an immutable
> > branch with the entire fdma series on, and then both of you merge that branch into
> > your respective trees.
>
> my topic/st_fdma is immutable branch. You cna merge it, if you need a signed
> tag, please do let me know
>
Hi Vinod,
It looks like you reverted the wrong Kconfig fix, the one I objected to
was the change in drivers/remoteproc, not the one in drivers/dma.
The ST_FMDA depends on functions exposed by REMOTEPROC and
ST_SLIM_REMOTEPROC, the latter in turn depends on REMOTEPROC, which you
guys made user selectable - and as such should not be selected - but I
think we should move forward and get everything merged and then we can
go back and figure out how this should be addressed (or left alone?).
I have merged "topic/st_fdma" into rproc-next, so that I can fix up the
now broken drivers/remoteproc/Kconfig.
We do however both need to revert the revert or there will be link
errors if you build the dma driver with remoteproc=n. If you do this I
can merge the topic once more and we'll keep the set of changes in sync.
Regards,
Bjorn
^ permalink raw reply
* [PATCH v7 0/7] Add DRM driver for Hisilicon Hibmc
From: Xinliang Liu @ 2016-11-17 7:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479303831-74134-1-git-send-email-zourongrong@gmail.com>
Hi Rongrong,
Thanks for your hard work.
For this whole series patches:
Reviewed-by: Xinliang Liu <xinliang.liu@linaro.org>
Thanks,
-xinliang
On 16 November 2016 at 21:43, Rongrong Zou <zourongrong@gmail.com> wrote:
> This patch set adds a new drm driver for Hisilicon Hibmc. Hibmc is a
> BMC SoC with a display controller intergrated, usually it is used on
> server for Out-of-band management purpose. In this patch set, we just
> support basic function for Hibmc display subsystem. Hibmc display
> subsystem is connected to host CPU by PCIe as blow:
>
> +----------+ +----------+
> | | PCIe | Hibmc |
> |host CPU( |<----->| display |
> |arm64,x86)| |subsystem |
> +----------+ +----------+
>
> Hardware Detail for Hibmc display subsystem
> -----------
>
> The display subsystem of Hibmc is show as bellow:
> +----+ +----+ +----+ +--------+
> | | | | | | | |
> | FB |----->| DE |----->|VDAC|---->|external|
> | | | | | | | VGA |
> +----+ +----+ +----+ +--------+
>
> -DE(Display Engine) is the display controller.
> -VDAC(Video Digital-to-Analog converter) converts the RGB diaital data
> stream from DE to VGA analog signals.
>
> Change History
> ------------
> Changes in v7:
> -remove hibmc_drm_power.c/hibmc_drm_power.h, move the functions to
> hibmc_drm_drv.c.
> -remove hibmc_drm_de.h and move the struct defined in head file to
> hibmc_drm_de.c.
> -plane is initialized inside crtc, not in hibmc_kms_init().
> -connector is initialized inside encoder, not in hibmc_kms_init().
> -remove plane/crtc/encoder/connector from hibmc_drm_private struct.
> -call drm_atomic_helper_suspend/resume in hibmc_pm_suspend/resume.
> -remove these empty stubs because caller will do NULL check.
> hibmc_plane_atomic_disable
> hibmc_crtc_atomic_check
> hibmc_encoder_disable
> hibmc_encoder_enable
> hibmc_encoder_atomic_check
> -clean up in all error paths of creating driver-private framebuffer.
>
> Changes in v6:
> -remove the embedded framebuffer and use a pointer of hibmc_framebuffer
> instead.
> -remove the deprecated drm_framebuffer_unregister_private(),
> drm_framebuffer_unreference() will be called in hibmc_fbdev_destroy().
> -uninstall irq in hibmc_unload().
>
> Changes in v5:
> -rebase on v4.9-rc2.
> -replace drm_fb_helper_set_suspend with drm_fb_helper_set_suspend_unlocked.
> and remove redundant console_lock and console_unlock.
>
> Changes in v4:
> -remove unused include files, and include header file when it is needed.
> -remove unused FLAG in Kconfig: DRM_GEM_CMA_HELPER/DRM_KMS_CMA_HELPER.
> -remove drm_helper_disable_unused_functions, since we use DRIVER_ATOMIC.
>
> Changes in v3:
> -enable KMS, in v2, only fbdev is enabled.
> -management video memory with ttm.
> -add vblank interrupt.
> -remove drm_connector_register_all() and drm_connector_unregister_all().
> -I have a basic test with igt.
>
> Changes in v2:
> -Remove self-defined macros for bit operations.
> -Remove unused register.
> -Replace those deprecated functions with new version of them.
> -use drm_connector_register_all() to register connector after
> drm_dev_register().
>
> The patch v2 is at
> https://lists.freedesktop.org/archives/dri-devel/2016-May/108661.html
>
> Rongrong Zou (7):
> drm/hisilicon/hibmc: Add hisilicon hibmc drm master driver
> drm/hisilicon/hibmc: Add video memory management
> drm/hisilicon/hibmc: Add support for frame buffer
> drm/hisilicon/hibmc: Add support for display engine
> drm/hisilicon/hibmc: Add support for VDAC
> drm/hisilicon/hibmc: Add support for vblank interrupt
> MAINTAINERS: Update HISILICON DRM entries
>
> MAINTAINERS | 1 +
> drivers/gpu/drm/hisilicon/Kconfig | 1 +
> drivers/gpu/drm/hisilicon/Makefile | 1 +
> drivers/gpu/drm/hisilicon/hibmc/Kconfig | 9 +
> drivers/gpu/drm/hisilicon/hibmc/Makefile | 4 +
> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c | 477 ++++++++++++++++++
> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 456 ++++++++++++++++++
> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 114 +++++
> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c | 267 +++++++++++
> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_regs.h | 196 ++++++++
> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c | 147 ++++++
> drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c | 558 ++++++++++++++++++++++
> 12 files changed, 2231 insertions(+)
> create mode 100644 drivers/gpu/drm/hisilicon/hibmc/Kconfig
> create mode 100644 drivers/gpu/drm/hisilicon/hibmc/Makefile
> create mode 100644 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
> create mode 100644 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
> create mode 100644 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
> create mode 100644 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c
> create mode 100644 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_regs.h
> create mode 100644 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
> create mode 100644 drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c
>
> --
> 1.9.1
>
^ permalink raw reply
* wdt, gpio: move arch_initcall into subsys_initcall ?
From: Heiko Schocher @ 2016-11-17 7:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ee9824b8-f09f-3817-8893-8121c9fb9eb1@roeck-us.net>
Hello Guenter, Vladimir,
Sorry for the late response, but I was "on the road" ...
Am 15.11.2016 um 14:46 schrieb Guenter Roeck:
> On 11/15/2016 03:32 AM, Vladimir Zapolskiy wrote:
>> On 11/15/2016 01:10 PM, Vladimir Zapolskiy wrote:
>>> Hello Heiko,
>>>
>>> On 11/15/2016 12:20 PM, Heiko Schocher wrote:
>>>> Hello,
>>>>
>>>> commit e188cbf7564f: "gpio: mxc: shift gpio_mxc_init() to subsys_initcall level"
>>>> moves the gpio initialization of the mxc gpio driver
>>>> from the arch_initcall level into subsys_initcall level.
>>>>
>>>> This leads now on mxc boards, which use a gpio wdt driver
>>>> and the CONFIG_GPIO_WATCHDOG_ARCH_INITCALL option enabled,
>>>> to unwanted driver probe deferrals during kernel boot.
>>>>
>>>> I see this currently on an imx6 based board (which has unfortunately
>>>> 3 WDT: imx6 internal (disabled), gpio wdt and da9063 WDT ...).
>>>>
>>>> Also a side effect from above commit is, that the da9063 WDT driver
>>>> is now probed before the gpio WDT driver ... so /dev/watchdog now
>>>> does not point to the gpio_wdt, instead it points to the da9063 WDT.
>>>>
>>>> So there are 2 solutions possible:
>>>>
>>>> - add a CONFIG_GPIO_MCX_ARCH_INITCALL option
>>>> in drivers/gpio/gpio-mxc.c like for the gpio_wdt.c driver?
>>>
>>> in my opinion this is overly heavy solution and it might be
>>> better to avoid it if possible.
>>>
>>> I would rather prefer to reconsider GPIO_WATCHDOG_ARCH_INITCALL
>>> usage in the watchdog driver.
>>>
>>> Moreover adding this proposed GPIO_MCX_ARCH_INITCALL to call
>>> the driver on arch level will result in deferring the GPIO driver.
>>>
>>>> But how can we guarantee, that first the gpio driver and then
>>>> the gpio_wdt driver gets probed?
>>>>
>>>> - move the arch_initcall in gpio_wdt.c into a subsys_initcall
>>>> (Tested this, and the probe dereferral messages are gone ...)
>>>>
>>>> But this may results in problems on boards, which needs an early
>>>> trigger on an gpio wdt ...
>>>
>>> The level of "earliness" can not be defined in absolute time value
>>> in any case, why decreasing the init level of the watchdog driver
>>> to subsys level can cause problems? For that there should exist
>>> some kind of a dependency on IC or PCB hardware level, can you
>>> name it please?
On the current problem, there is no dependency on PCB, but I know
of watchdogs triggered through a gpio pin, which must triggered < 1 second
and subsys_initcall is too late for this. I think, this was the reason
for introducing the CONFIG_GPIO_WATCHDOG_ARCH_INITCALL option ...
>>> Also please note that more than a half of all GPIO drivers settle
>>> on subsys or later initcall level, this means that there is
>>> an expected GPIO watchdog driver deferral for all of them.
>>
>> Please find two more late notes though.
>>
>>> I propose to send two patches for review:
>>>
>>> 1. remove GPIO_WATCHDOG_ARCH_INITCALL option completely and decouple
>>> module_platform_driver() into arch_initcall() and module_exit()
>>> unconditionally.
>>>
>>> 2. change arch_initcall() in the watchdog driver to subsys_initcall().
>>> This change removes probe deferrals on boot, when the driver is
>>> used with the most of the GPIO controllers.
>>
>> Alternatively commit 5e53c8ed813d ("watchdog: gpio_wdt: Add option for
>> early registration") can be reverted and then module_platform_driver()
>> is decoupled into subsys_initcall() and module_exit() as its replacement.
>>
> Sure, only the reason for that was that there are situations where
> subsys_initcall() was too late. Also, when using arch_initcall() only,
> we get deferrals again, which is apparently hated by many and a reason
> for all those "avoid probe deferrals" patches.
Exactly. And I wonder, if this boards, who need this early trigger,
work with current kernel ? (Or this boards use a gpio driver, which is
not in subsys_initcall level ...)
>> And also please note that since quite many GPIO controller drivers
>> live on initcall levels after subsys_initcall(), the solution won't
>> let to avoid watchdog driver deferrals totally, this should be accepted.
>>
> ... except for others it isn't, and we are back to square one.
>
> GPIO_WATCHDOG_ARCH_INITCALL was intended to be only used in situations
> where needed. Why is it used here in the first place if that is not
> the case ?
Heh, good question ...
"/dev/watchdog" is in systemd hard-coded, see:
https://github.com/systemd/systemd/blob/dd8352659c9428b196706d04399eec106a8917ed/src/shared/watchdog.c#L86
http://0pointer.de/blog/projects/watchdog.html
https://www.freedesktop.org/software/systemd/man/systemd-system.conf.html
We have 2 WDT driver enabled on the board (GPIO WDT and the DA9063 WDT).
If both WDTs are in the subsys_initall level, first the da9063 wdt
gets probed, and so "/dev/watchdog" points to the da9063 wdt, but
we want to use the GPIO wdt as "/dev/watchdog" device.
Now, why not simple disabling the da9063 wdt ?
We could not disable the da9063 wdt functionallity, because we need
for a clean reboot that the da9063_wdt_restart() is called in the
restart sequence ... which is registered in the wdt driver:
static const struct watchdog_ops da9063_watchdog_ops = {
[...]
.restart = da9063_wdt_restart,
};
Is there a possbility to register this restart function may somewhere
else? It seems, that this is not a WDT functionallity ...
bye,
Heiko
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply
* [PATCH next] arm64: remove "SMP: Total of %d processors activated." message
From: Kefeng Wang @ 2016-11-17 7:32 UTC (permalink / raw)
To: linux-arm-kernel
There is a common SMP boot message in generic code on all arches,
kill "SMP: Total of %d processors activated." in smp_cpus_done()
on arm64.
Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
---
Boot message on qemu.
[ 0.375116] smp: Brought up 1 node, 8 CPUs
[ 0.383749] SMP: Total of 8 processors activated.
arch/arm64/kernel/smp.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index cb87234..9db4a95 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -428,7 +428,6 @@ static void __init hyp_mode_check(void)
void __init smp_cpus_done(unsigned int max_cpus)
{
- pr_info("SMP: Total of %d processors activated.\n", num_online_cpus());
setup_cpu_features();
hyp_mode_check();
apply_alternatives_all();
--
1.7.12.4
^ permalink raw reply related
* [PATCH v3 6/9] mtd: spi-nor: Support R/W for S25FS-S family flash
From: Krzeminski, Marcin (Nokia - PL/Wroclaw) @ 2016-11-17 7:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161116171058.GA21300@Cayman.am.freescale.net>
> -----Original Message-----
> From: Han Xu [mailto:xhnjupt at gmail.com]
> Sent: Wednesday, November 16, 2016 6:11 PM
> To: Krzeminski, Marcin (Nokia - PL/Wroclaw)
> <marcin.krzeminski@nokia.com>
> Cc: Yunhui Cui <B56489@freescale.com>; Yunhui Cui <yunhui.cui@nxp.com>;
> David Woodhouse <dwmw2@infradead.org>; linux-kernel at vger.kernel.org;
> linux-mtd at lists.infradead.org; han.xu at freescale.com; Brian Norris
> <computersforpeace@gmail.com>; jagannadh.teki at gmail.com; linux-arm-
> kernel at lists.infradead.org; Yao Yuan <yao.yuan@nxp.com>
> Subject: Re: [PATCH v3 6/9] mtd: spi-nor: Support R/W for S25FS-S family
> flash
>
> On Thu, Sep 15, 2016 at 06:50:55AM +0000, Krzeminski, Marcin (Nokia -
> PL/Wroclaw) wrote:
> > Hello,
> >
> > > -----Original Message-----
> > > From: linux-mtd [mailto:linux-mtd-bounces at lists.infradead.org] On
> > > Behalf Of Han Xu
> > > Sent: Wednesday, September 14, 2016 9:49 PM
> > > To: Yunhui Cui <B56489@freescale.com>
> > > Cc: Yunhui Cui <yunhui.cui@nxp.com>; David Woodhouse
> > > <dwmw2@infradead.org>; linux-kernel at vger.kernel.org; linux-
> > > mtd at lists.infradead.org; han.xu at freescale.com; Brian Norris
> > > <computersforpeace@gmail.com>; jagannadh.teki at gmail.com; linux-
> arm-
> > > kernel at lists.infradead.org; Yao Yuan <yao.yuan@nxp.com>
> > > Subject: Re: [PATCH v3 6/9] mtd: spi-nor: Support R/W for S25FS-S
> > > family flash
> > >
> > > On Thu, Aug 18, 2016 at 2:38 AM, Yunhui Cui <B56489@freescale.com>
> > > wrote:
> > > > From: Yunhui Cui <yunhui.cui@nxp.com>
> > > >
> > > > With the physical sectors combination, S25FS-S family flash
> > > > requires some special operations for read/write functions.
> > > >
> > > > Signed-off-by: Yunhui Cui <yunhui.cui@nxp.com>
> > > > ---
> > > > drivers/mtd/spi-nor/spi-nor.c | 56
> > > > +++++++++++++++++++++++++++++++++++++++++++
> > > > 1 file changed, 56 insertions(+)
> > > >
> > > > diff --git a/drivers/mtd/spi-nor/spi-nor.c
> > > > b/drivers/mtd/spi-nor/spi-nor.c index d0fc165..495d0bb 100644
> > > > --- a/drivers/mtd/spi-nor/spi-nor.c
> > > > +++ b/drivers/mtd/spi-nor/spi-nor.c
> > > > @@ -39,6 +39,10 @@
> > > >
> > > > #define SPI_NOR_MAX_ID_LEN 6
> > > > #define SPI_NOR_MAX_ADDR_WIDTH 4
> > > > +/* Added for S25FS-S family flash */
> > > > +#define SPINOR_CONFIG_REG3_OFFSET 0x800004
> > > > +#define CR3V_4KB_ERASE_UNABLE 0x8 #define
> > > > +SPINOR_S25FS_FAMILY_EXT_JEDEC 0x81
> > > >
> > > > struct flash_info {
> > > > char *name;
> > > > @@ -78,6 +82,7 @@ struct flash_info { };
> > > >
> > > > #define JEDEC_MFR(info) ((info)->id[0])
> > > > +#define EXT_JEDEC(info) ((info)->id[5])
> > > >
> > > > static const struct flash_info *spi_nor_match_id(const char
> > > > *name);
> > > >
> > > > @@ -899,6 +904,7 @@ static const struct flash_info spi_nor_ids[] = {
> > > > */
> > > > { "s25sl032p", INFO(0x010215, 0x4d00, 64 * 1024, 64,
> > > SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> > > > { "s25sl064p", INFO(0x010216, 0x4d00, 64 * 1024, 128,
> > > > SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> > > > + { "s25fs256s1", INFO6(0x010219, 0x4d0181, 64 * 1024, 512,
> > > > + 0)},
> > > > { "s25fl256s0", INFO(0x010219, 0x4d00, 256 * 1024, 128, 0) },
> > > > { "s25fl256s1", INFO(0x010219, 0x4d01, 64 * 1024, 512,
> > > SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> > > > { "s25fl512s", INFO(0x010220, 0x4d00, 256 * 1024, 256,
> > > > SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) }, @@ -1036,6
> +1042,50
> > > @@ static const struct flash_info *spi_nor_read_id(struct spi_nor
> > > *nor)
> > > > return ERR_PTR(-ENODEV);
> > > > }
> > > >
> > > > +/*
> > > > + * The S25FS-S family physical sectors may be configured as a
> > > > + * hybrid combination of eight 4-kB parameter sectors
> > > > + * at the top or bottom of the address space with all
> > > > + * but one of the remaining sectors being uniform size.
> > > > + * The Parameter Sector Erase commands (20h or 21h) must
> > > > + * be used to erase the 4-kB parameter sectors individually.
> > > > + * The Sector (uniform sector) Erase commands (D8h or DCh)
> > > > + * must be used to erase any of the remaining
> > > > + * sectors, including the portion of highest or lowest address
> > > > + * sector that is not overlaid by the parameter sectors.
> > > > + * The uniform sector erase command has no effect on parameter
> > > sectors.
> > > > + */
> > > > +static int spansion_s25fs_disable_4kb_erase(struct spi_nor *nor) {
> > > > + u32 cr3v_addr = SPINOR_CONFIG_REG3_OFFSET;
> > > > + u8 cr3v = 0x0;
> > > > + int ret = 0x0;
> > > > +
> > > > + nor->cmd_buf[2] = cr3v_addr >> 16;
> > > > + nor->cmd_buf[1] = cr3v_addr >> 8;
> > > > + nor->cmd_buf[0] = cr3v_addr >> 0;
> > > > +
> > > > + ret = nor->read_reg(nor, SPINOR_OP_SPANSION_RDAR, &cr3v, 1);
> > > > + if (ret)
> > > > + return ret;
> > > > + if (cr3v & CR3V_4KB_ERASE_UNABLE)
> > > > + return 0;
> > > > + ret = nor->write_reg(nor, SPINOR_OP_WREN, NULL, 0);
> > > > + if (ret)
> > > > + return ret;
> > > > + cr3v = CR3V_4KB_ERASE_UNABLE;
> > > > + nor->program_opcode = SPINOR_OP_SPANSION_WRAR;
> > > > + nor->write(nor, cr3v_addr, 1, &cr3v);
> > > > +
> > > > + ret = nor->read_reg(nor, SPINOR_OP_SPANSION_RDAR, &cr3v, 1);
> > > > + if (ret)
> > > > + return ret;
> > > > + if (!(cr3v & CR3V_4KB_ERASE_UNABLE))
> > > > + return -EPERM;
> > > > +
> > > > + return 0;
> > > > +}
> > > > +
> > > > static int spi_nor_read(struct mtd_info *mtd, loff_t from, size_t len,
> > > > size_t *retlen, u_char *buf) { @@ -1361,6
> > > > +1411,12 @@ int spi_nor_scan(struct spi_nor *nor, const char
> > > > +*name,
> > > enum read_mode mode)
> > > > spi_nor_wait_till_ready(nor);
> > > > }
> > > >
> > > > + if (EXT_JEDEC(info) == SPINOR_S25FS_FAMILY_EXT_JEDEC) {
> > > > + ret = spansion_s25fs_disable_4kb_erase(nor);
> > > > + if (ret)
> > > > + return ret;
> > > > + }
> > > > +
> > > > if (!mtd->name)
> > > > mtd->name = dev_name(dev);
> > > > mtd->priv = nor;
> > > > --
> > > > 2.1.0.27.g96db324
> > > >
> > > >
> > > Hi Brian, I will ack this change but still feel it's kind of hacking code.
> > >
> > > Acked-by: Han xu <han.xu@nxp.com>
> >
> > I am new on the list so I am not sure if this topic has been discussed.
> > Generally our product functionality relay on those 4KiB sectors.
> > I know that this hack is already in u-boot, but if you mainstream this
> > you will force users of those 4KiB sectors to do hack the hack...
> > I believe the proper solution here is to use erase regions
> > functionality, I send and RFS about that some time ago.
>
> Do you mind to send me a link for reference?
>
Han,
Sorry, It seem I have not posted erase region changes (only those regarding DUAL/QUAD I/O).
Generally, in this flash you need to create 3 erase regions (because in FS-S family support only
4KiB erase on parameters sector - eg. 1.2.2.4 in S25FS512S). In my case regions are:
1. 0-32KiB (8*4KiB) - 4K_ERASE (0x20/0x21)
2. 32 - 256 - SE_CMD (0xd8/0xdc)
3. Rest of the flash SE_CMD (0xd8/0xdc)
To erase whole flash you can also use CHIP_ERASE_CMD (0x60/0xC7) command, you just
need to add one more mtd partition that will cover whole flash.
Thanks,
Marcin
> Sincerely,
> Han XU
>
> >
> > Thanks,
> > Marcin
> >
> > > > ______________________________________________________
> > > > Linux MTD discussion mailing list
> > > > http://lists.infradead.org/mailman/listinfo/linux-mtd/
> > >
> > >
> > >
> > > --
> > > Sincerely,
> > >
> > > Han XU
> > >
> > > ______________________________________________________
> > > Linux MTD discussion mailing list
> > > http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply
* ILP32 for ARM64 - testing with lmbench
From: Zhangjian (Bamvor) @ 2016-11-17 7:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <266952F2-53F5-4D5E-83F0-6C8203092F67@linaro.org>
Hi, Maxim
On 2016/11/17 13:02, Maxim Kuvyrkov wrote:
> Hi Bamvor,
>
> I'm surprised that you see this much difference from ILP32 patches on SPEC CPU2006int at all. The SPEC CPU2006 benchmarks spend almost no time in the kernel syscalls. I can imagine memory, TLB, and cache handling in the kernel could affect CPU2006 benchmarks. Do ILP32 patches touch code in those areas?
>
> Other than that, it would be interesting to check what the variance is between the 3 iterations of benchmark runs. Could you check what relative standard deviation is between the 3 iterations -- (STDEV(RUN1, RUN2, RUN3) / RUNselected)?
>
> For reference, in my [non-ILP32] benchmarking I see 1.1% for 401.bzip2, 0.8% for 429.mcf, 0.2% for 456.hmmer, and 0.1% for 462.libquantum.
Here is my result:
ILP32_merged ILP32_unmerged
401.bzip2 0.31% 0.26%
429.mcf 1.61% 1.36%
456.hmmer 1.37% 1.57%
462.libquantum 0.29% 0.28%
Regards
Bamvor
>
> --
> Maxim Kuvyrkov
> www.linaro.org
>
>
>
>> On Nov 17, 2016, at 7:28 AM, Zhangjian (Bamvor) <bamvor.zhangjian@huawei.com> wrote:
>>
>> Hi, all
>>
>> I test specint of aarch64 LP64 when aarch32 el0 disable/enabled respectively
>> and compare with ILP32 unmerged kernel(4.8-rc6) in our arm64 board. I found
>> that difference(ILP32 disabled/ILP32 unmerged) is bigger when aarch32 el0 is
>> enabled, compare with aarch32 el0 disabled kernel. And bzip2, mcg, hmmer,
>> libquantum are the top four differences[1]. Note that bigger is better in
>> specint test.
>>
>> In order to make sure the above results, I retest these four testcases in
>> reportable way(reference the command in the end). The result[2] show that
>> libquantum decrease -2.09% after ILP32 enabled and aarch32 on. I think it is in
>> significant.
>>
>> The result of lmbench is not stable in my board. I plan to dig it later.
>>
>> [1] The following test result is tested through --size=ref --iterations=3.
>> 1.1 Test when aarch32_el0 is enabled.
>> ILP32 disabled base line
>> 400.perlbench 100.00% 100%
>> 401.bzip2 99.35% 100%
>> 403.gcc 100.26% 100%
>> 429.mcf 102.75% 100%
>> 445.gobmk 100.00% 100%
>> 456.hmmer 95.66% 100%
>> 458.sjeng 100.00% 100%
>> 462.libquantum 100.00% 100%
>> 471.omnetpp 100.59% 100%
>> 473.astar 99.66% 100%
>> 483.xalancbmk 99.10% 100%
>>
>> 1.2 Test when aarch32_el0 is disabled
>> ILP32 disabled base line
>> 400.perlbench 100.22% 100%
>> 401.bzip2 100.95% 100%
>> 403.gcc 100.20% 100%
>> 429.mcf 100.76% 100%
>> 445.gobmk 100.36% 100%
>> 456.hmmer 97.94% 100%
>> 458.sjeng 99.73% 100%
>> 462.libquantum 98.72% 100%
>> 471.omnetpp 100.86% 100%
>> 473.astar 99.15% 100%
>> 483.xalancbmk 100.08% 100%
>>
>> [2] The following test result is tested through: runspec --config=my.cfg --size=test,train,ref --noreportable --tune=base,peak --iterations=3 bzip2 mcf hmmer libquantum
>> 2.1 Test when aarch32_el0 is enabled.
>> ILP32_enabled base line
>> 401.bzip2 100.82% 100%
>> 429.mcf 100.18% 100%
>> 456.hmmer 99.64% 100%
>> 462.libquantum 97.91% 100%
>>
>> Regards
>>
>> Bamvor
>>
>> On 2016/10/28 20:46, Yury Norov wrote:
>>> [Add Steve Ellcey, thanks for testing on ThunderX]
>>>
>>> Lmbench-3.0-a9 testing is performed on ThunderX machine to check that
>>> ILP32 series does not add performance regressions for LP64. Test
>>> summary is in the table below. Our measurements doesn't show
>>> significant performance regression of LP64 if ILP32 code is merged,
>>> both enabled or disabled.
>>>
>>> ILP32 enabled ILP32 disabled Standard Kernel
>>> null syscall 0.1066 0.1121 0.1121
>>> 95.09% 100.00%
>>>
>>> stat 1.3947 1.3814 1.3864
>>> 100.60% 99.64%
>>>
>>> fstat 0.4459 0.4344 0.4524
>>> 98.56% 96.02%
>>>
>>> open/close 4.0606 4.0411 4.0453
>>> 100.38% 99.90%
>>>
>>> read 0.4819 0.5014 0.5014
>>> 96.11% 100.00%
>>>
>>> Tested with linux 4.8 because 4.9-rc1 is not fixed yet for ThunderX.
>>> Other system details below.
>>>
>>> Yury.
>>>
>>> ubuntu at crb6:~$ uname -a
>>> Linux crb6 4.8.0+ #3 SMP Thu Oct 27 11:01:32 PDT 2016 aarch64 aarch64 aarch64 GNU/Linux
>>>
>>> ubuntu at crb6:~$ cat /proc/meminfo
>>> MemTotal: 132011948 kB
>>> MemFree: 131442672 kB
>>> MemAvailable: 130695764 kB
>>> Buffers: 15696 kB
>>> Cached: 88088 kB
>>> SwapCached: 0 kB
>>> Active: 82760 kB
>>> Inactive: 41336 kB
>>> Active(anon): 20880 kB
>>> Inactive(anon): 8576 kB
>>> Active(file): 61880 kB
>>> Inactive(file): 32760 kB
>>> Unevictable: 0 kB
>>> Mlocked: 0 kB
>>> SwapTotal: 128920572 kB
>>> SwapFree: 128920572 kB
>>> Dirty: 0 kB
>>> Writeback: 0 kB
>>> AnonPages: 20544 kB
>>> Mapped: 19780 kB
>>> Shmem: 9060 kB
>>> Slab: 78804 kB
>>> SReclaimable: 27372 kB
>>> SUnreclaim: 51432 kB
>>> KernelStack: 8336 kB
>>> PageTables: 820 kB
>>> NFS_Unstable: 0 kB
>>> Bounce: 0 kB
>>> WritebackTmp: 0 kB
>>> CommitLimit: 194926544 kB
>>> Committed_AS: 256324 kB
>>> VmallocTotal: 135290290112 kB
>>> VmallocUsed: 0 kB
>>> VmallocChunk: 0 kB
>>> AnonHugePages: 0 kB
>>> ShmemHugePages: 0 kB
>>> ShmemPmdMapped: 0 kB
>>> CmaTotal: 0 kB
>>> CmaFree: 0 kB
>>> HugePages_Total: 0
>>> HugePages_Free: 0
>>> HugePages_Rsvd: 0
>>> HugePages_Surp: 0
>>> Hugepagesize: 2048 kB
>>>
>>> ubuntu at crb6:~$ cat /proc/cpuinfo
>>> processor : 0
>>> BogoMIPS : 200.00
>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>> CPU implementer : 0x43
>>> CPU architecture: 8
>>> CPU variant : 0x1
>>> CPU part : 0x0a1
>>> CPU revision : 0
>>>
>>> processor : 1
>>> BogoMIPS : 200.00
>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>> CPU implementer : 0x43
>>> CPU architecture: 8
>>> CPU variant : 0x1
>>> CPU part : 0x0a1
>>> CPU revision : 0
>>>
>>> processor : 2
>>> BogoMIPS : 200.00
>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>> CPU implementer : 0x43
>>> CPU architecture: 8
>>> CPU variant : 0x1
>>> CPU part : 0x0a1
>>> CPU revision : 0
>>>
>>> processor : 3
>>> BogoMIPS : 200.00
>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>> CPU implementer : 0x43
>>> CPU architecture: 8
>>> CPU variant : 0x1
>>> CPU part : 0x0a1
>>> CPU revision : 0
>>>
>>> processor : 4
>>> BogoMIPS : 200.00
>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>> CPU implementer : 0x43
>>> CPU architecture: 8
>>> CPU variant : 0x1
>>> CPU part : 0x0a1
>>> CPU revision : 0
>>>
>>> processor : 5
>>> BogoMIPS : 200.00
>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>> CPU implementer : 0x43
>>> CPU architecture: 8
>>> CPU variant : 0x1
>>> CPU part : 0x0a1
>>> CPU revision : 0
>>>
>>> processor : 6
>>> BogoMIPS : 200.00
>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>> CPU implementer : 0x43
>>> CPU architecture: 8
>>> CPU variant : 0x1
>>> CPU part : 0x0a1
>>> CPU revision : 0
>>>
>>> processor : 7
>>> BogoMIPS : 200.00
>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>> CPU implementer : 0x43
>>> CPU architecture: 8
>>> CPU variant : 0x1
>>> CPU part : 0x0a1
>>> CPU revision : 0
>>>
>>> processor : 8
>>> BogoMIPS : 200.00
>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>> CPU implementer : 0x43
>>> CPU architecture: 8
>>> CPU variant : 0x1
>>> CPU part : 0x0a1
>>> CPU revision : 0
>>>
>>> processor : 9
>>> BogoMIPS : 200.00
>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>> CPU implementer : 0x43
>>> CPU architecture: 8
>>> CPU variant : 0x1
>>> CPU part : 0x0a1
>>> CPU revision : 0
>>>
>>> processor : 10
>>> BogoMIPS : 200.00
>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>> CPU implementer : 0x43
>>> CPU architecture: 8
>>> CPU variant : 0x1
>>> CPU part : 0x0a1
>>> CPU revision : 0
>>>
>>> processor : 11
>>> BogoMIPS : 200.00
>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>> CPU implementer : 0x43
>>> CPU architecture: 8
>>> CPU variant : 0x1
>>> CPU part : 0x0a1
>>> CPU revision : 0
>>>
>>> processor : 12
>>> BogoMIPS : 200.00
>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>> CPU implementer : 0x43
>>> CPU architecture: 8
>>> CPU variant : 0x1
>>> CPU part : 0x0a1
>>> CPU revision : 0
>>>
>>> processor : 13
>>> BogoMIPS : 200.00
>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>> CPU implementer : 0x43
>>> CPU architecture: 8
>>> CPU variant : 0x1
>>> CPU part : 0x0a1
>>> CPU revision : 0
>>>
>>> processor : 14
>>> BogoMIPS : 200.00
>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>> CPU implementer : 0x43
>>> CPU architecture: 8
>>> CPU variant : 0x1
>>> CPU part : 0x0a1
>>> CPU revision : 0
>>>
>>> processor : 15
>>> BogoMIPS : 200.00
>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>> CPU implementer : 0x43
>>> CPU architecture: 8
>>> CPU variant : 0x1
>>> CPU part : 0x0a1
>>> CPU revision : 0
>>>
>>> processor : 16
>>> BogoMIPS : 200.00
>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>> CPU implementer : 0x43
>>> CPU architecture: 8
>>> CPU variant : 0x1
>>> CPU part : 0x0a1
>>> CPU revision : 0
>>>
>>> processor : 17
>>> BogoMIPS : 200.00
>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>> CPU implementer : 0x43
>>> CPU architecture: 8
>>> CPU variant : 0x1
>>> CPU part : 0x0a1
>>> CPU revision : 0
>>>
>>> processor : 18
>>> BogoMIPS : 200.00
>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>> CPU implementer : 0x43
>>> CPU architecture: 8
>>> CPU variant : 0x1
>>> CPU part : 0x0a1
>>> CPU revision : 0
>>>
>>> processor : 19
>>> BogoMIPS : 200.00
>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>> CPU implementer : 0x43
>>> CPU architecture: 8
>>> CPU variant : 0x1
>>> CPU part : 0x0a1
>>> CPU revision : 0
>>>
>>> processor : 20
>>> BogoMIPS : 200.00
>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>> CPU implementer : 0x43
>>> CPU architecture: 8
>>> CPU variant : 0x1
>>> CPU part : 0x0a1
>>> CPU revision : 0
>>>
>>> processor : 21
>>> BogoMIPS : 200.00
>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>> CPU implementer : 0x43
>>> CPU architecture: 8
>>> CPU variant : 0x1
>>> CPU part : 0x0a1
>>> CPU revision : 0
>>>
>>> processor : 22
>>> BogoMIPS : 200.00
>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>> CPU implementer : 0x43
>>> CPU architecture: 8
>>> CPU variant : 0x1
>>> CPU part : 0x0a1
>>> CPU revision : 0
>>>
>>> processor : 23
>>> BogoMIPS : 200.00
>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>> CPU implementer : 0x43
>>> CPU architecture: 8
>>> CPU variant : 0x1
>>> CPU part : 0x0a1
>>> CPU revision : 0
>>>
>>> processor : 24
>>> BogoMIPS : 200.00
>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>> CPU implementer : 0x43
>>> CPU architecture: 8
>>> CPU variant : 0x1
>>> CPU part : 0x0a1
>>> CPU revision : 0
>>>
>>> processor : 25
>>> BogoMIPS : 200.00
>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>> CPU implementer : 0x43
>>> CPU architecture: 8
>>> CPU variant : 0x1
>>> CPU part : 0x0a1
>>> CPU revision : 0
>>>
>>> processor : 26
>>> BogoMIPS : 200.00
>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>> CPU implementer : 0x43
>>> CPU architecture: 8
>>> CPU variant : 0x1
>>> CPU part : 0x0a1
>>> CPU revision : 0
>>>
>>> processor : 27
>>> BogoMIPS : 200.00
>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>> CPU implementer : 0x43
>>> CPU architecture: 8
>>> CPU variant : 0x1
>>> CPU part : 0x0a1
>>> CPU revision : 0
>>>
>>> processor : 28
>>> BogoMIPS : 200.00
>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>> CPU implementer : 0x43
>>> CPU architecture: 8
>>> CPU variant : 0x1
>>> CPU part : 0x0a1
>>> CPU revision : 0
>>>
>>> processor : 29
>>> BogoMIPS : 200.00
>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>> CPU implementer : 0x43
>>> CPU architecture: 8
>>> CPU variant : 0x1
>>> CPU part : 0x0a1
>>> CPU revision : 0
>>>
>>> processor : 30
>>> BogoMIPS : 200.00
>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>> CPU implementer : 0x43
>>> CPU architecture: 8
>>> CPU variant : 0x1
>>> CPU part : 0x0a1
>>> CPU revision : 0
>>>
>>> processor : 31
>>> BogoMIPS : 200.00
>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>> CPU implementer : 0x43
>>> CPU architecture: 8
>>> CPU variant : 0x1
>>> CPU part : 0x0a1
>>> CPU revision : 0
>>>
>>> processor : 32
>>> BogoMIPS : 200.00
>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>> CPU implementer : 0x43
>>> CPU architecture: 8
>>> CPU variant : 0x1
>>> CPU part : 0x0a1
>>> CPU revision : 0
>>>
>>> processor : 33
>>> BogoMIPS : 200.00
>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>> CPU implementer : 0x43
>>> CPU architecture: 8
>>> CPU variant : 0x1
>>> CPU part : 0x0a1
>>> CPU revision : 0
>>>
>>> processor : 34
>>> BogoMIPS : 200.00
>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>> CPU implementer : 0x43
>>> CPU architecture: 8
>>> CPU variant : 0x1
>>> CPU part : 0x0a1
>>> CPU revision : 0
>>>
>>> processor : 35
>>> BogoMIPS : 200.00
>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>> CPU implementer : 0x43
>>> CPU architecture: 8
>>> CPU variant : 0x1
>>> CPU part : 0x0a1
>>> CPU revision : 0
>>>
>>> processor : 36
>>> BogoMIPS : 200.00
>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>> CPU implementer : 0x43
>>> CPU architecture: 8
>>> CPU variant : 0x1
>>> CPU part : 0x0a1
>>> CPU revision : 0
>>>
>>> processor : 37
>>> BogoMIPS : 200.00
>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>> CPU implementer : 0x43
>>> CPU architecture: 8
>>> CPU variant : 0x1
>>> CPU part : 0x0a1
>>> CPU revision : 0
>>>
>>> processor : 38
>>> BogoMIPS : 200.00
>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>> CPU implementer : 0x43
>>> CPU architecture: 8
>>> CPU variant : 0x1
>>> CPU part : 0x0a1
>>> CPU revision : 0
>>>
>>> processor : 39
>>> BogoMIPS : 200.00
>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>> CPU implementer : 0x43
>>> CPU architecture: 8
>>> CPU variant : 0x1
>>> CPU part : 0x0a1
>>> CPU revision : 0
>>>
>>> processor : 40
>>> BogoMIPS : 200.00
>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>> CPU implementer : 0x43
>>> CPU architecture: 8
>>> CPU variant : 0x1
>>> CPU part : 0x0a1
>>> CPU revision : 0
>>>
>>> processor : 41
>>> BogoMIPS : 200.00
>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>> CPU implementer : 0x43
>>> CPU architecture: 8
>>> CPU variant : 0x1
>>> CPU part : 0x0a1
>>> CPU revision : 0
>>>
>>> processor : 42
>>> BogoMIPS : 200.00
>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>> CPU implementer : 0x43
>>> CPU architecture: 8
>>> CPU variant : 0x1
>>> CPU part : 0x0a1
>>> CPU revision : 0
>>>
>>> processor : 43
>>> BogoMIPS : 200.00
>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>> CPU implementer : 0x43
>>> CPU architecture: 8
>>> CPU variant : 0x1
>>> CPU part : 0x0a1
>>> CPU revision : 0
>>>
>>> processor : 44
>>> BogoMIPS : 200.00
>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>> CPU implementer : 0x43
>>> CPU architecture: 8
>>> CPU variant : 0x1
>>> CPU part : 0x0a1
>>> CPU revision : 0
>>>
>>> processor : 45
>>> BogoMIPS : 200.00
>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>> CPU implementer : 0x43
>>> CPU architecture: 8
>>> CPU variant : 0x1
>>> CPU part : 0x0a1
>>> CPU revision : 0
>>>
>>> processor : 46
>>> BogoMIPS : 200.00
>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>> CPU implementer : 0x43
>>> CPU architecture: 8
>>> CPU variant : 0x1
>>> CPU part : 0x0a1
>>> CPU revision : 0
>>>
>>> processor : 47
>>> BogoMIPS : 200.00
>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>> CPU implementer : 0x43
>>> CPU architecture: 8
>>> CPU variant : 0x1
>>> CPU part : 0x0a1
>>> CPU revision : 0
>>>
>>
>
^ permalink raw reply
* [PATCH v4 1/2] drm/bridge: dumb-vga-dac: Support a VDD regulator supply
From: Archit Taneja @ 2016-11-17 7:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161116154232.872-2-wens@csie.org>
Hi,
Thanks for the patch.
On 11/16/2016 09:12 PM, Chen-Yu Tsai wrote:
> Some dumb VGA DACs are active components which require external power.
> Add support for specifying a regulator as its power supply.
>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> Acked-by: Rob Herring <robh@kernel.org>
> ---
> .../bindings/display/bridge/dumb-vga-dac.txt | 2 ++
> drivers/gpu/drm/bridge/dumb-vga-dac.c | 35 ++++++++++++++++++++++
> 2 files changed, 37 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt b/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
> index 003bc246a270..164cbb15f04c 100644
> --- a/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
> +++ b/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
> @@ -16,6 +16,8 @@ graph bindings specified in Documentation/devicetree/bindings/graph.txt.
> - Video port 0 for RGB input
> - Video port 1 for VGA output
>
> +Optional properties:
> +- vdd-supply: Power supply for DAC
>
> Example
> -------
> diff --git a/drivers/gpu/drm/bridge/dumb-vga-dac.c b/drivers/gpu/drm/bridge/dumb-vga-dac.c
> index afec232185a7..15b549f94307 100644
> --- a/drivers/gpu/drm/bridge/dumb-vga-dac.c
> +++ b/drivers/gpu/drm/bridge/dumb-vga-dac.c
> @@ -12,6 +12,7 @@
>
> #include <linux/module.h>
> #include <linux/of_graph.h>
> +#include <linux/regulator/consumer.h>
>
> #include <drm/drmP.h>
> #include <drm/drm_atomic_helper.h>
> @@ -23,6 +24,7 @@ struct dumb_vga {
> struct drm_connector connector;
>
> struct i2c_adapter *ddc;
> + struct regulator *vdd;
> };
>
> static inline struct dumb_vga *
> @@ -124,8 +126,32 @@ static int dumb_vga_attach(struct drm_bridge *bridge)
> return 0;
> }
>
> +static void dumb_vga_enable(struct drm_bridge *bridge)
> +{
> + struct dumb_vga *vga = drm_bridge_to_dumb_vga(bridge);
> + int ret = 0;
> +
> + if (vga->vdd)
> + ret = regulator_enable(vga->vdd);
> +
> + if (ret) {
> + DRM_ERROR("Failed to enable vdd regulator: %d\n", ret);
> + return;
We don't need this return for now. If you're okay with it, can I fix this
and queue to misc?
Thanks,
Archit
> + }
> +}
> +
> +static void dumb_vga_disable(struct drm_bridge *bridge)
> +{
> + struct dumb_vga *vga = drm_bridge_to_dumb_vga(bridge);
> +
> + if (vga->vdd)
> + regulator_disable(vga->vdd);
> +}
> +
> static const struct drm_bridge_funcs dumb_vga_bridge_funcs = {
> .attach = dumb_vga_attach,
> + .enable = dumb_vga_enable,
> + .disable = dumb_vga_disable,
> };
>
> static struct i2c_adapter *dumb_vga_retrieve_ddc(struct device *dev)
> @@ -169,6 +195,15 @@ static int dumb_vga_probe(struct platform_device *pdev)
> return -ENOMEM;
> platform_set_drvdata(pdev, vga);
>
> + vga->vdd = devm_regulator_get_optional(&pdev->dev, "vdd");
> + if (IS_ERR(vga->vdd)) {
> + ret = PTR_ERR(vga->vdd);
> + if (ret == -EPROBE_DEFER)
> + return -EPROBE_DEFER;
> + vga->vdd = NULL;
> + dev_dbg(&pdev->dev, "No vdd regulator found: %d\n", ret);
> + }
> +
> vga->ddc = dumb_vga_retrieve_ddc(&pdev->dev);
> if (IS_ERR(vga->ddc)) {
> if (PTR_ERR(vga->ddc) == -ENODEV) {
>
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v4 1/2] drm/bridge: dumb-vga-dac: Support a VDD regulator supply
From: Chen-Yu Tsai @ 2016-11-17 7:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <31b8b5b9-9621-286a-7649-cc999ab020da@codeaurora.org>
On Thu, Nov 17, 2016 at 3:48 PM, Archit Taneja <architt@codeaurora.org> wrote:
> Hi,
>
> Thanks for the patch.
>
>
> On 11/16/2016 09:12 PM, Chen-Yu Tsai wrote:
>>
>> Some dumb VGA DACs are active components which require external power.
>> Add support for specifying a regulator as its power supply.
>>
>> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
>> Acked-by: Rob Herring <robh@kernel.org>
>> ---
>> .../bindings/display/bridge/dumb-vga-dac.txt | 2 ++
>> drivers/gpu/drm/bridge/dumb-vga-dac.c | 35
>> ++++++++++++++++++++++
>> 2 files changed, 37 insertions(+)
>>
>> diff --git
>> a/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
>> b/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
>> index 003bc246a270..164cbb15f04c 100644
>> --- a/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
>> +++ b/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
>> @@ -16,6 +16,8 @@ graph bindings specified in
>> Documentation/devicetree/bindings/graph.txt.
>> - Video port 0 for RGB input
>> - Video port 1 for VGA output
>>
>> +Optional properties:
>> +- vdd-supply: Power supply for DAC
>>
>> Example
>> -------
>> diff --git a/drivers/gpu/drm/bridge/dumb-vga-dac.c
>> b/drivers/gpu/drm/bridge/dumb-vga-dac.c
>> index afec232185a7..15b549f94307 100644
>> --- a/drivers/gpu/drm/bridge/dumb-vga-dac.c
>> +++ b/drivers/gpu/drm/bridge/dumb-vga-dac.c
>> @@ -12,6 +12,7 @@
>>
>> #include <linux/module.h>
>> #include <linux/of_graph.h>
>> +#include <linux/regulator/consumer.h>
>>
>> #include <drm/drmP.h>
>> #include <drm/drm_atomic_helper.h>
>> @@ -23,6 +24,7 @@ struct dumb_vga {
>> struct drm_connector connector;
>>
>> struct i2c_adapter *ddc;
>> + struct regulator *vdd;
>> };
>>
>> static inline struct dumb_vga *
>> @@ -124,8 +126,32 @@ static int dumb_vga_attach(struct drm_bridge *bridge)
>> return 0;
>> }
>>
>> +static void dumb_vga_enable(struct drm_bridge *bridge)
>> +{
>> + struct dumb_vga *vga = drm_bridge_to_dumb_vga(bridge);
>> + int ret = 0;
>> +
>> + if (vga->vdd)
>> + ret = regulator_enable(vga->vdd);
>> +
>> + if (ret) {
>> + DRM_ERROR("Failed to enable vdd regulator: %d\n", ret);
>> + return;
>
>
> We don't need this return for now. If you're okay with it, can I fix this
> and queue to misc?
Yes, please!
Thanks
ChenYu
>
> Thanks,
> Archit
>
>
>> + }
>> +}
>> +
>> +static void dumb_vga_disable(struct drm_bridge *bridge)
>> +{
>> + struct dumb_vga *vga = drm_bridge_to_dumb_vga(bridge);
>> +
>> + if (vga->vdd)
>> + regulator_disable(vga->vdd);
>> +}
>> +
>> static const struct drm_bridge_funcs dumb_vga_bridge_funcs = {
>> .attach = dumb_vga_attach,
>> + .enable = dumb_vga_enable,
>> + .disable = dumb_vga_disable,
>> };
>>
>> static struct i2c_adapter *dumb_vga_retrieve_ddc(struct device *dev)
>> @@ -169,6 +195,15 @@ static int dumb_vga_probe(struct platform_device
>> *pdev)
>> return -ENOMEM;
>> platform_set_drvdata(pdev, vga);
>>
>> + vga->vdd = devm_regulator_get_optional(&pdev->dev, "vdd");
>> + if (IS_ERR(vga->vdd)) {
>> + ret = PTR_ERR(vga->vdd);
>> + if (ret == -EPROBE_DEFER)
>> + return -EPROBE_DEFER;
>> + vga->vdd = NULL;
>> + dev_dbg(&pdev->dev, "No vdd regulator found: %d\n", ret);
>> + }
>> +
>> vga->ddc = dumb_vga_retrieve_ddc(&pdev->dev);
>> if (IS_ERR(vga->ddc)) {
>> if (PTR_ERR(vga->ddc) == -ENODEV) {
>>
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH 1/2] dt-bindings: ahci-fsl-qoriq: added explanation for reg-names
From: yuantian.tang at nxp.com @ 2016-11-17 7:59 UTC (permalink / raw)
To: linux-arm-kernel
From: Tang Yuantian <Yuantian.Tang@nxp.com>
Added explanation for reg-names to make it more clear.
Signed-off-by: Tang Yuantian <yuantian.tang@nxp.com>
---
Documentation/devicetree/bindings/ata/ahci-fsl-qoriq.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/ata/ahci-fsl-qoriq.txt b/Documentation/devicetree/bindings/ata/ahci-fsl-qoriq.txt
index fc33ca0..80cf10c 100644
--- a/Documentation/devicetree/bindings/ata/ahci-fsl-qoriq.txt
+++ b/Documentation/devicetree/bindings/ata/ahci-fsl-qoriq.txt
@@ -10,6 +10,8 @@ Required properties:
Optional properties:
- dma-coherent: Enable AHCI coherent DMA operation.
- reg-names: register area names when there are more than 1 register area.
+ example: 'ahci' is for sata controller register.
+ 'sata-ecc' is for sata ecc register.
Examples:
sata at 3200000 {
--
2.1.0.27.g96db324
^ permalink raw reply related
* [PATCH 2/2] arm64: dts: updated sata node on ls1046a dts
From: yuantian.tang at nxp.com @ 2016-11-17 7:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479369560-9188-1-git-send-email-yuantian.tang@nxp.com>
From: Tang Yuantian <Yuantian.Tang@nxp.com>
On ls1046a soc, sata ecc should be disabled. So added sata ecc
register address so that driver can get this information.
Signed-off-by: Tang Yuantian <yuantian.tang@nxp.com>
---
arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
index 38806ca..88aaaf1 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
@@ -507,7 +507,9 @@
sata: sata at 3200000 {
compatible = "fsl,ls1046a-ahci";
- reg = <0x0 0x3200000 0x0 0x10000>;
+ reg = <0x0 0x3200000 0x0 0x10000>,
+ <0x0 0x20140520 0x0 0x4>;
+ reg-names = "ahci", "sata-ecc";
interrupts = <GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clockgen 4 1>;
};
--
2.1.0.27.g96db324
^ permalink raw reply related
* [PATCH] crypto: sun4i-ss: support the Security System PRNG
From: Corentin Labbe @ 2016-11-17 8:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANc+2y63p1b5ATDY0oU4nLckk9CJhSs3CXGHy=NwoXn_awP9aA@mail.gmail.com>
On Tue, Oct 18, 2016 at 09:39:17PM +0530, PrasannaKumar Muralidharan wrote:
> Hi Corentin,
>
> I have a few minor comments.
>
> On 18 October 2016 at 18:04, Corentin Labbe <clabbe.montjoie@gmail.com> wrote:
> > From: LABBE Corentin <clabbe.montjoie@gmail.com>
> >
> > The Security System have a PRNG.
> > This patch add support for it as an hwrng.
> >
> > Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
> > ---
> > drivers/crypto/Kconfig | 8 ++++
> > drivers/crypto/sunxi-ss/Makefile | 1 +
> > drivers/crypto/sunxi-ss/sun4i-ss-core.c | 14 +++++++
> > drivers/crypto/sunxi-ss/sun4i-ss-hwrng.c | 70 ++++++++++++++++++++++++++++++++
> > drivers/crypto/sunxi-ss/sun4i-ss.h | 8 ++++
> > 5 files changed, 101 insertions(+)
> > create mode 100644 drivers/crypto/sunxi-ss/sun4i-ss-hwrng.c
> >
> > diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
> > index 4d2b81f..38f7aca 100644
> > --- a/drivers/crypto/Kconfig
> > +++ b/drivers/crypto/Kconfig
> > @@ -538,6 +538,14 @@ config CRYPTO_DEV_SUN4I_SS
> > To compile this driver as a module, choose M here: the module
> > will be called sun4i-ss.
> >
> > +config CRYPTO_DEV_SUN4I_SS_PRNG
> > + bool "Support for Allwinner Security System PRNG"
> > + depends on CRYPTO_DEV_SUN4I_SS
> > + select HW_RANDOM
> > + help
> > + This driver provides kernel-side support for the Pseudo-Random
> > + Number Generator found in the Security System.
> > +
> > config CRYPTO_DEV_ROCKCHIP
> > tristate "Rockchip's Cryptographic Engine driver"
> > depends on OF && ARCH_ROCKCHIP
> > diff --git a/drivers/crypto/sunxi-ss/Makefile b/drivers/crypto/sunxi-ss/Makefile
> > index 8f4c7a2..ca049ee 100644
> > --- a/drivers/crypto/sunxi-ss/Makefile
> > +++ b/drivers/crypto/sunxi-ss/Makefile
> > @@ -1,2 +1,3 @@
> > obj-$(CONFIG_CRYPTO_DEV_SUN4I_SS) += sun4i-ss.o
> > sun4i-ss-y += sun4i-ss-core.o sun4i-ss-hash.o sun4i-ss-cipher.o
> > +sun4i-ss-$(CONFIG_CRYPTO_DEV_SUN4I_SS_PRNG) += sun4i-ss-hwrng.o
> > diff --git a/drivers/crypto/sunxi-ss/sun4i-ss-core.c b/drivers/crypto/sunxi-ss/sun4i-ss-core.c
> > index 3ac6c6c..fa739de 100644
> > --- a/drivers/crypto/sunxi-ss/sun4i-ss-core.c
> > +++ b/drivers/crypto/sunxi-ss/sun4i-ss-core.c
> > @@ -359,6 +359,16 @@ static int sun4i_ss_probe(struct platform_device *pdev)
> > }
> > }
> > platform_set_drvdata(pdev, ss);
> > +
> > +#ifdef CONFIG_CRYPTO_DEV_SUN4I_SS_PRNG
> > + /* Voluntarily made the PRNG optional */
> > + err = sun4i_ss_hwrng_register(&ss->hwrng);
> > + if (!err)
> > + dev_info(ss->dev, "sun4i-ss PRNG loaded");
> > + else
> > + dev_err(ss->dev, "sun4i-ss PRNG failed");
> > +#endif
> > +
> > return 0;
> > error_alg:
> > i--;
> > @@ -386,6 +396,10 @@ static int sun4i_ss_remove(struct platform_device *pdev)
> > int i;
> > struct sun4i_ss_ctx *ss = platform_get_drvdata(pdev);
> >
> > +#ifdef CONFIG_CRYPTO_DEV_SUN4I_SS_PRNG
> > + sun4i_ss_hwrng_remove(&ss->hwrng);
> > +#endif
> > +
> > for (i = 0; i < ARRAY_SIZE(ss_algs); i++) {
> > switch (ss_algs[i].type) {
> > case CRYPTO_ALG_TYPE_ABLKCIPHER:
> > diff --git a/drivers/crypto/sunxi-ss/sun4i-ss-hwrng.c b/drivers/crypto/sunxi-ss/sun4i-ss-hwrng.c
> > new file mode 100644
> > index 0000000..95fadb7
> > --- /dev/null
> > +++ b/drivers/crypto/sunxi-ss/sun4i-ss-hwrng.c
> > @@ -0,0 +1,70 @@
> > +#include "sun4i-ss.h"
> > +
> > +static int sun4i_ss_hwrng_init(struct hwrng *hwrng)
> > +{
> > + struct sun4i_ss_ctx *ss;
> > +
> > + ss = container_of(hwrng, struct sun4i_ss_ctx, hwrng);
> > + get_random_bytes(ss->seed, SS_SEED_LEN);
> > +
> > + return 0;
> > +}
> > +
> > +static int sun4i_ss_hwrng_read(struct hwrng *hwrng, void *buf,
> > + size_t max, bool wait)
> > +{
> > + int i;
> > + u32 v;
> > + u32 *data = buf;
> > + const u32 mode = SS_OP_PRNG | SS_PRNG_CONTINUE | SS_ENABLED;
> > + size_t len;
> > + struct sun4i_ss_ctx *ss;
> > +
> > + ss = container_of(hwrng, struct sun4i_ss_ctx, hwrng);
> > + len = min_t(size_t, SS_DATA_LEN, max);
> > +
> > + spin_lock_bh(&ss->slock);
>
> Is spin_lock_bh really required here? I could see it is being used in
> sun4i-ss-hash.c but could not find any comment/info about the need.
>
No for sun4i-ss-hwrng it seems not required and work perfecly without _bh
> > + writel(mode, ss->base + SS_CTL);
> > +
> > + /* write the seed */
> > + for (i = 0; i < SS_SEED_LEN / 4; i++)
> > + writel(ss->seed[i], ss->base + SS_KEY0 + i * 4);
> > + writel(mode | SS_PRNG_START, ss->base + SS_CTL);
> > +
> > + /* Read the random data */
> > + readsl(ss->base + SS_TXFIFO, data, len / 4);
> > +
> > + if (len % 4 > 0) {
> > + v = readl(ss->base + SS_TXFIFO);
> > + memcpy(data + len / 4, &v, len % 4);
> > + }
>
> hwrng core asks for "rng_buffer_size()" of data which is a multiple of
> 4. So len % 4 will be 0. I think the above check is not required. Feel
> free to correct if I am wrong.
>
Agree, I removed that in v2
Thanks
Corentin Labbe
^ permalink raw reply
* [PATCH] crypto: sun4i-ss: support the Security System PRNG
From: Corentin Labbe @ 2016-11-17 8:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1722218.eZlGktOxfL@tauon.atsec.com>
On Tue, Oct 18, 2016 at 04:24:22PM +0200, Stephan Mueller wrote:
> Am Dienstag, 18. Oktober 2016, 14:34:27 CEST schrieb Corentin Labbe:
>
> Hi Corentin,
>
> > diff --git a/drivers/crypto/sunxi-ss/sun4i-ss-hwrng.c
> > b/drivers/crypto/sunxi-ss/sun4i-ss-hwrng.c new file mode 100644
> > index 0000000..95fadb7
> > --- /dev/null
> > +++ b/drivers/crypto/sunxi-ss/sun4i-ss-hwrng.c
> > @@ -0,0 +1,70 @@
> > +#include "sun4i-ss.h"
> > +
> > +static int sun4i_ss_hwrng_init(struct hwrng *hwrng)
> > +{
> > + struct sun4i_ss_ctx *ss;
> > +
> > + ss = container_of(hwrng, struct sun4i_ss_ctx, hwrng);
> > + get_random_bytes(ss->seed, SS_SEED_LEN);
>
> Is it wise to call get_random_bytes once in the init function and never
> thereafter?
>
> This init function may be called during boot time of the kernel at which the
> input_pool may not yet have received sufficient amounts of entropy.
>
> What about registering a callback with add_random_ready_callback and seed
> again when sufficient entropy was collected?
>
Seed again, or just do not seed (and so return -EAGAIN for read() function) until ready_callback ?
Thanks
Corentin Labbe
^ permalink raw reply
* [PATCH] crypto: sun4i-ss: support the Security System PRNG
From: Stephan Mueller @ 2016-11-17 8:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161117080748.GB25394@Red>
Am Donnerstag, 17. November 2016, 09:07:48 CET schrieb Corentin Labbe:
Hi Corentin,
>
> Seed again, or just do not seed (and so return -EAGAIN for read() function)
> until ready_callback ?
This is your choice. But for the start sequence, you should not simply rely on
get_random_bytes.
For the DRBG in crypto/drbg.c we seed with get_random_bytes and the Jitter RNG
in case the input_pool is not fully seeded. The reseed trigger is reduced to
50 DRBG requests, i.e. after 50 requests, the DRBG again reseeds from
get_random_bytes / Jitter RNG. This is continued until the input_pool has been
sufficiently seeded (i.e. the registered callback is triggered). At that
point, another get_random_bytes call is made, the Jitter RNG is deactivated
and the reseed threshold is set to the common value.
Ciao
Stephan
^ permalink raw reply
* [PATCH] pinctrl: nomadik: split up and comments MC0 pins
From: Linus Walleij @ 2016-11-17 8:47 UTC (permalink / raw)
To: linux-arm-kernel
When debugging it helps to see exactly which pin goes where,
so make it very detailed.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
drivers/pinctrl/nomadik/pinctrl-nomadik-db8500.c | 23 +++++++++++++++++------
1 file changed, 17 insertions(+), 6 deletions(-)
diff --git a/drivers/pinctrl/nomadik/pinctrl-nomadik-db8500.c b/drivers/pinctrl/nomadik/pinctrl-nomadik-db8500.c
index 8392083514fb..af4814479eb0 100644
--- a/drivers/pinctrl/nomadik/pinctrl-nomadik-db8500.c
+++ b/drivers/pinctrl/nomadik/pinctrl-nomadik-db8500.c
@@ -379,13 +379,24 @@ static const unsigned msp0txrx_a_1_pins[] = { DB8500_PIN_AC4, DB8500_PIN_AC3 };
static const unsigned msp0tfstck_a_1_pins[] = { DB8500_PIN_AF3, DB8500_PIN_AE3 };
static const unsigned msp0rfsrck_a_1_pins[] = { DB8500_PIN_AD3, DB8500_PIN_AD4 };
/* Basic pins of the MMC/SD card 0 interface */
-static const unsigned mc0_a_1_pins[] = { DB8500_PIN_AC2, DB8500_PIN_AC1,
- DB8500_PIN_AB4, DB8500_PIN_AA3, DB8500_PIN_AA4, DB8500_PIN_AB2,
- DB8500_PIN_Y4, DB8500_PIN_Y2, DB8500_PIN_AA2, DB8500_PIN_AA1 };
+static const unsigned mc0_a_1_pins[] = { DB8500_PIN_AC2, /* MC0_CMDDIR */
+ DB8500_PIN_AC1, /* MC0_DAT0DIR */
+ DB8500_PIN_AB4, /* MC0_DAT2DIR */
+ DB8500_PIN_AA3, /* MC0_FBCLK */
+ DB8500_PIN_AA4, /* MC0_CLK */
+ DB8500_PIN_AB2, /* MC0_CMD */
+ DB8500_PIN_Y4, /* MC0_DAT0 */
+ DB8500_PIN_Y2, /* MC0_DAT1 */
+ DB8500_PIN_AA2, /* MC0_DAT2 */
+ DB8500_PIN_AA1 /* MC0_DAT3 */
+};
/* Often only 4 bits are used, then these are not needed (only used for MMC) */
-static const unsigned mc0_dat47_a_1_pins[] = { DB8500_PIN_W2, DB8500_PIN_W3,
- DB8500_PIN_V3, DB8500_PIN_V2};
-static const unsigned mc0dat31dir_a_1_pins[] = { DB8500_PIN_AB3 };
+static const unsigned mc0_dat47_a_1_pins[] = { DB8500_PIN_W2, /* MC0_DAT4 */
+ DB8500_PIN_W3, /* MC0_DAT5 */
+ DB8500_PIN_V3, /* MC0_DAT6 */
+ DB8500_PIN_V2 /* MC0_DAT7 */
+};
+static const unsigned mc0dat31dir_a_1_pins[] = { DB8500_PIN_AB3 }; /* MC0_DAT31DIR */
/* MSP1 can only be on these pins, but TXD and RXD can be flipped */
static const unsigned msp1txrx_a_1_pins[] = { DB8500_PIN_AF2, DB8500_PIN_AG2 };
static const unsigned msp1_a_1_pins[] = { DB8500_PIN_AE1, DB8500_PIN_AE2 };
--
2.7.4
^ permalink raw reply related
* [PATCH] pinctrl: sunxi: fix theoretical uninitialized variable access
From: Linus Walleij @ 2016-11-17 9:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161116203358.midi7vmaqirpywtt@lukather>
On Wed, Nov 16, 2016 at 9:33 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> On Wed, Nov 16, 2016 at 03:18:18PM +0100, Arnd Bergmann wrote:
>> gcc warns about a way that it could use an uninitialized variable:
>>
>> drivers/pinctrl/sunxi/pinctrl-sunxi.c: In function 'sunxi_pinctrl_init':
>> drivers/pinctrl/sunxi/pinctrl-sunxi.c:1191:8: error: 'best_div' may be used uninitialized in this function [-Werror=maybe-uninitialized]
>>
>> This cannot really happen except if 'freq' is UINT_MAX and 'clock' is
>> zero, and both of these are forbidden. To shut up the warning anyway,
>> this changes the logic to initialize the return code to the first
>> divider value before looking at the others.
>>
>> Fixes: 7c926492d38a ("pinctrl: sunxi: Add support for interrupt debouncing")
>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
> Thanks for that patch.
>
> Just out of curiosity, which gcc gives those warnings? I have 6.2 and
> it didn't output anything..
Context: Arnd re-enabled -Werror=maybe-uninitialized
in the kernel build and this kind of stuff started to appear so
it needs to be fixed up.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v2 2/3] soc: rockchip: add driver handling grf setup
From: Heiko Stuebner @ 2016-11-17 9:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a01a1a8c-b01b-4335-b69c-bb99dec9d6d6@rock-chips.com>
Am Donnerstag, 17. November 2016, 09:38:11 CET schrieb Shawn Lin:
> Hi Heiko,
>
> ? 2016/11/16 17:58, Heiko Stuebner ??:
> > Hi Shawn,
> >
> > Am Mittwoch, 16. November 2016, 17:33:21 CET schrieb Shawn Lin:
> >> ? 2016/11/16 6:38, Heiko Stuebner ??:
> >>> The General Register Files are an area of registers containing a lot
> >>> of single-bit settings for numerous components as well full components
> >>> like usbphy control. Therefore all used components are accessed
> >>> via the syscon provided by the grf nodes or from the sub-devices
> >>> created through the simple-mfd created from the grf node.
>
> ----8<----------------
> [...]
>
> >>> + for (i = 0; i < grf_info->num_values; i++) {
> >>> + const struct rockchip_grf_value *val = &grf_info->values[i];
> >>> +
> >>> + pr_debug("%s: adjusting %s in %#6x to %#10x\n", __func__,
> >>> + val->desc, val->reg, val->val);
> >>> + ret = regmap_write(grf, val->reg, val->val);
> >>> + if (ret < 0)
> >>> + pr_err("%s: write to %#6x failed with %d\n",
> >>> + __func__, val->reg, ret);
> >>
> >> So, when failing to do one of the settings, should we still let it goes?
> >> Sometimes the log of postcore_initcall is easy to be neglected when
> >> people finally find problems later but the very earlier log was missing
> >> due to whatever reason like buffer limitation, etc.
> >
> > I expect errors here to be very rare. I.e. Doug thought that regmap might
> > return errors if we write outside the mapped region, which would mean
> > someone really messed up in this core component or a core-element of the
> > dts. But in general the GRF is always a mmio-regmap, so there won't be
> > any i2c/spi/ whatever errors possible.
>
> I was just thinking about the scalability that in the future some of the
> GRF settings may depend on genpd or clock even if they are only a
> mmio-regmap but they don't belong to the general pd/clock for GRF, for
> instance, some of the PHYs' or controller's cap(like emmc) settings.
>
> But, IIRC, you suggested this driver shouldn't be a catchall, and we
> now ask the drivers of controllers and phys to take over this, so I
> guess we won't put those settings here ever. :)
>
> Thanks for explaining this.
correct, it should never become a catchall as things like those phy-subdevices
that need runtime handling should definitly be handled in their respective
drivers.
So far we're also always starting with all clocks and power-domains being on,
so settings should always succeed as we're only active during early boot here.
We'll simply have to reevaluate if some new soc begins to boot with some
needed clocks/power-domains being off.
Heiko
^ permalink raw reply
* [PATCH v3 6/9] mtd: spi-nor: Support R/W for S25FS-S family flash
From: Yao Yuan @ 2016-11-17 9:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AM4PR0701MB2130273C90BE0EE615382718FEB10@AM4PR0701MB2130.eurprd07.prod.outlook.com>
On Thu, Nov 17, 2016 at 06:50:55AM +0000, Krzeminski, Marcin (Nokia - PL/Wroclaw) wrote:
> > > > On Thu, Aug 18, 2016 at 2:38 AM, Yunhui Cui <B56489@freescale.com>
> > > > wrote:
> > > > > From: Yunhui Cui <yunhui.cui@nxp.com>
> > > > >
> > > > > With the physical sectors combination, S25FS-S family flash
> > > > > requires some special operations for read/write functions.
> > > > >
> > > > > Signed-off-by: Yunhui Cui <yunhui.cui@nxp.com>
> > > > > ---
> > > > > drivers/mtd/spi-nor/spi-nor.c | 56
> > > > > +++++++++++++++++++++++++++++++++++++++++++
> > > > > 1 file changed, 56 insertions(+)
> > > > >
> > > > > diff --git a/drivers/mtd/spi-nor/spi-nor.c
> > > > > b/drivers/mtd/spi-nor/spi-nor.c index d0fc165..495d0bb 100644
> > > > > --- a/drivers/mtd/spi-nor/spi-nor.c
> > > > > +++ b/drivers/mtd/spi-nor/spi-nor.c
> > > > > @@ -39,6 +39,10 @@
> > > > >
> > > > > #define SPI_NOR_MAX_ID_LEN 6
> > > > > #define SPI_NOR_MAX_ADDR_WIDTH 4
> > > > > +/* Added for S25FS-S family flash */
> > > > > +#define SPINOR_CONFIG_REG3_OFFSET 0x800004
> > > > > +#define CR3V_4KB_ERASE_UNABLE 0x8 #define
> > > > > +SPINOR_S25FS_FAMILY_EXT_JEDEC 0x81
> > > > >
> > > > > struct flash_info {
> > > > > char *name;
> > > > > @@ -78,6 +82,7 @@ struct flash_info { };
> > > > >
> > > > > #define JEDEC_MFR(info) ((info)->id[0])
> > > > > +#define EXT_JEDEC(info) ((info)->id[5])
> > > > >
> > > > > static const struct flash_info *spi_nor_match_id(const char
> > > > > *name);
> > > > >
> > > > > @@ -899,6 +904,7 @@ static const struct flash_info spi_nor_ids[] = {
> > > > > */
> > > > > { "s25sl032p", INFO(0x010215, 0x4d00, 64 * 1024, 64,
> > > > SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> > > > > { "s25sl064p", INFO(0x010216, 0x4d00, 64 * 1024, 128,
> > > > > SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> > > > > + { "s25fs256s1", INFO6(0x010219, 0x4d0181, 64 * 1024,
> > > > > + 512, 0)},
> > > > > { "s25fl256s0", INFO(0x010219, 0x4d00, 256 * 1024, 128, 0) },
> > > > > { "s25fl256s1", INFO(0x010219, 0x4d01, 64 * 1024, 512,
> > > > SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> > > > > { "s25fl512s", INFO(0x010220, 0x4d00, 256 * 1024, 256,
> > > > > SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) }, @@ -1036,6
> > +1042,50
> > > > @@ static const struct flash_info *spi_nor_read_id(struct spi_nor
> > > > *nor)
> > > > > return ERR_PTR(-ENODEV); }
> > > > >
> > > > > +/*
> > > > > + * The S25FS-S family physical sectors may be configured as a
> > > > > + * hybrid combination of eight 4-kB parameter sectors
> > > > > + * at the top or bottom of the address space with all
> > > > > + * but one of the remaining sectors being uniform size.
> > > > > + * The Parameter Sector Erase commands (20h or 21h) must
> > > > > + * be used to erase the 4-kB parameter sectors individually.
> > > > > + * The Sector (uniform sector) Erase commands (D8h or DCh)
> > > > > + * must be used to erase any of the remaining
> > > > > + * sectors, including the portion of highest or lowest address
> > > > > + * sector that is not overlaid by the parameter sectors.
> > > > > + * The uniform sector erase command has no effect on parameter
> > > > sectors.
> > > > > + */
> > > > > +static int spansion_s25fs_disable_4kb_erase(struct spi_nor *nor) {
> > > > > + u32 cr3v_addr = SPINOR_CONFIG_REG3_OFFSET;
> > > > > + u8 cr3v = 0x0;
> > > > > + int ret = 0x0;
> > > > > +
> > > > > + nor->cmd_buf[2] = cr3v_addr >> 16;
> > > > > + nor->cmd_buf[1] = cr3v_addr >> 8;
> > > > > + nor->cmd_buf[0] = cr3v_addr >> 0;
> > > > > +
> > > > > + ret = nor->read_reg(nor, SPINOR_OP_SPANSION_RDAR, &cr3v, 1);
> > > > > + if (ret)
> > > > > + return ret;
> > > > > + if (cr3v & CR3V_4KB_ERASE_UNABLE)
> > > > > + return 0;
> > > > > + ret = nor->write_reg(nor, SPINOR_OP_WREN, NULL, 0);
> > > > > + if (ret)
> > > > > + return ret;
> > > > > + cr3v = CR3V_4KB_ERASE_UNABLE;
> > > > > + nor->program_opcode = SPINOR_OP_SPANSION_WRAR;
> > > > > + nor->write(nor, cr3v_addr, 1, &cr3v);
> > > > > +
> > > > > + ret = nor->read_reg(nor, SPINOR_OP_SPANSION_RDAR, &cr3v, 1);
> > > > > + if (ret)
> > > > > + return ret;
> > > > > + if (!(cr3v & CR3V_4KB_ERASE_UNABLE))
> > > > > + return -EPERM;
> > > > > +
> > > > > + return 0;
> > > > > +}
> > > > > +
> > > > > static int spi_nor_read(struct mtd_info *mtd, loff_t from, size_t len,
> > > > > size_t *retlen, u_char *buf) { @@
> > > > > -1361,6
> > > > > +1411,12 @@ int spi_nor_scan(struct spi_nor *nor, const char
> > > > > +*name,
> > > > enum read_mode mode)
> > > > > spi_nor_wait_till_ready(nor);
> > > > > }
> > > > >
> > > > > + if (EXT_JEDEC(info) == SPINOR_S25FS_FAMILY_EXT_JEDEC) {
> > > > > + ret = spansion_s25fs_disable_4kb_erase(nor);
> > > > > + if (ret)
> > > > > + return ret;
> > > > > + }
> > > > > +
> > > > > if (!mtd->name)
> > > > > mtd->name = dev_name(dev);
> > > > > mtd->priv = nor;
> > > > > --
> > > > > 2.1.0.27.g96db324
> > > > >
> > > > >
> > > > Hi Brian, I will ack this change but still feel it's kind of hacking code.
> > > >
> > > > Acked-by: Han xu <han.xu@nxp.com>
> > >
> > > I am new on the list so I am not sure if this topic has been discussed.
> > > Generally our product functionality relay on those 4KiB sectors.
> > > I know that this hack is already in u-boot, but if you mainstream
> > > this you will force users of those 4KiB sectors to do hack the hack...
> > > I believe the proper solution here is to use erase regions
> > > functionality, I send and RFS about that some time ago.
> >
> > Do you mind to send me a link for reference?
> >
> Han,
>
> Sorry, It seem I have not posted erase region changes (only those regarding
> DUAL/QUAD I/O).
> Generally, in this flash you need to create 3 erase regions (because in FS-S
> family support only 4KiB erase on parameters sector - eg. 1.2.2.4 in S25FS512S).
> In my case regions are:
> 1. 0-32KiB (8*4KiB) - 4K_ERASE (0x20/0x21) 2. 32 - 256 - SE_CMD (0xd8/0xdc) 3.
> Rest of the flash SE_CMD (0xd8/0xdc)
>
> To erase whole flash you can also use CHIP_ERASE_CMD (0x60/0xC7) command,
> you just need to add one more mtd partition that will cover whole flash.
>
Hi Krzeminski,
Do you think is there any great advantages for enable 4KB?
Because for NXP(Freescale) QSPI controller, there is only support max to 16 groups command.
So It's hard to give 3 groups command just for erase (0x21,0xdc and 0xc7).
So we have to disable the 4kb erase and only use 256kbytes in this patch.
^ permalink raw reply
* [RFC PATCH] mfd: dt: Add Aspeed LPC binding
From: Arnd Bergmann @ 2016-11-17 9:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161117060633.3837-1-andrew@aj.id.au>
On Thursday, November 17, 2016 4:36:33 PM CET Andrew Jeffery wrote:
> Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
> ---
>
> I'd like to start a discussion about how to handle the LPC register space in
> the Aspeed SoC. There are a number of issues, largely concerned with the layout
> of the registers but also with the fact that LPC register state is used by the
> pinmux to determine some pin functionality.
...
>
> What is the recommended approach to managing such hardware?
Can you clarify which side of the LPC bus this is? We are currently having
a discussion for how to integrate the LPC master on an ARM64 server that
uses LPC to access an Aspeed LPC slave. For this one we want to use the
traditional ISA DT binding.
I'm guessing that you are interesting in the other side here, for mapping
the registers of the LPC slave on the Aspeed BMC, but that's not clear from
your email, as I'm assuming that the same chip has both master and slave
interfaces.
Arnd
^ permalink raw reply
* [PATCH v4 1/2] drm/bridge: dumb-vga-dac: Support a VDD regulator supply
From: Archit Taneja @ 2016-11-17 9:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v668A-hFnWy22_DarSSZ6TkvH5=WH-UvaXOFQJBqyKzPXw@mail.gmail.com>
On 11/17/2016 01:25 PM, Chen-Yu Tsai wrote:
> On Thu, Nov 17, 2016 at 3:48 PM, Archit Taneja <architt@codeaurora.org> wrote:
>> Hi,
>>
>> Thanks for the patch.
>>
>>
>> On 11/16/2016 09:12 PM, Chen-Yu Tsai wrote:
>>>
>>> Some dumb VGA DACs are active components which require external power.
>>> Add support for specifying a regulator as its power supply.
>>>
>>> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
>>> Acked-by: Rob Herring <robh@kernel.org>
>>> ---
>>> .../bindings/display/bridge/dumb-vga-dac.txt | 2 ++
>>> drivers/gpu/drm/bridge/dumb-vga-dac.c | 35
>>> ++++++++++++++++++++++
>>> 2 files changed, 37 insertions(+)
>>>
>>> diff --git
>>> a/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
>>> b/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
>>> index 003bc246a270..164cbb15f04c 100644
>>> --- a/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
>>> +++ b/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
>>> @@ -16,6 +16,8 @@ graph bindings specified in
>>> Documentation/devicetree/bindings/graph.txt.
>>> - Video port 0 for RGB input
>>> - Video port 1 for VGA output
>>>
>>> +Optional properties:
>>> +- vdd-supply: Power supply for DAC
>>>
>>> Example
>>> -------
>>> diff --git a/drivers/gpu/drm/bridge/dumb-vga-dac.c
>>> b/drivers/gpu/drm/bridge/dumb-vga-dac.c
>>> index afec232185a7..15b549f94307 100644
>>> --- a/drivers/gpu/drm/bridge/dumb-vga-dac.c
>>> +++ b/drivers/gpu/drm/bridge/dumb-vga-dac.c
>>> @@ -12,6 +12,7 @@
>>>
>>> #include <linux/module.h>
>>> #include <linux/of_graph.h>
>>> +#include <linux/regulator/consumer.h>
>>>
>>> #include <drm/drmP.h>
>>> #include <drm/drm_atomic_helper.h>
>>> @@ -23,6 +24,7 @@ struct dumb_vga {
>>> struct drm_connector connector;
>>>
>>> struct i2c_adapter *ddc;
>>> + struct regulator *vdd;
>>> };
>>>
>>> static inline struct dumb_vga *
>>> @@ -124,8 +126,32 @@ static int dumb_vga_attach(struct drm_bridge *bridge)
>>> return 0;
>>> }
>>>
>>> +static void dumb_vga_enable(struct drm_bridge *bridge)
>>> +{
>>> + struct dumb_vga *vga = drm_bridge_to_dumb_vga(bridge);
>>> + int ret = 0;
>>> +
>>> + if (vga->vdd)
>>> + ret = regulator_enable(vga->vdd);
>>> +
>>> + if (ret) {
>>> + DRM_ERROR("Failed to enable vdd regulator: %d\n", ret);
>>> + return;
>>
>>
>> We don't need this return for now. If you're okay with it, can I fix this
>> and queue to misc?
>
> Yes, please!
pushed to drm-misc.
Thanks,
Archit
>
> Thanks
> ChenYu
>
>>
>> Thanks,
>> Archit
>>
>>
>>> + }
>>> +}
>>> +
>>> +static void dumb_vga_disable(struct drm_bridge *bridge)
>>> +{
>>> + struct dumb_vga *vga = drm_bridge_to_dumb_vga(bridge);
>>> +
>>> + if (vga->vdd)
>>> + regulator_disable(vga->vdd);
>>> +}
>>> +
>>> static const struct drm_bridge_funcs dumb_vga_bridge_funcs = {
>>> .attach = dumb_vga_attach,
>>> + .enable = dumb_vga_enable,
>>> + .disable = dumb_vga_disable,
>>> };
>>>
>>> static struct i2c_adapter *dumb_vga_retrieve_ddc(struct device *dev)
>>> @@ -169,6 +195,15 @@ static int dumb_vga_probe(struct platform_device
>>> *pdev)
>>> return -ENOMEM;
>>> platform_set_drvdata(pdev, vga);
>>>
>>> + vga->vdd = devm_regulator_get_optional(&pdev->dev, "vdd");
>>> + if (IS_ERR(vga->vdd)) {
>>> + ret = PTR_ERR(vga->vdd);
>>> + if (ret == -EPROBE_DEFER)
>>> + return -EPROBE_DEFER;
>>> + vga->vdd = NULL;
>>> + dev_dbg(&pdev->dev, "No vdd regulator found: %d\n", ret);
>>> + }
>>> +
>>> vga->ddc = dumb_vga_retrieve_ddc(&pdev->dev);
>>> if (IS_ERR(vga->ddc)) {
>>> if (PTR_ERR(vga->ddc) == -ENODEV) {
>>>
>>
>> --
>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
>> a Linux Foundation Collaborative Project
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v3 6/9] mtd: spi-nor: Support R/W for S25FS-S family flash
From: Krzeminski, Marcin (Nokia - PL/Wroclaw) @ 2016-11-17 9:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <DB6PR0401MB24077A46D3FC5147DC4C69D989B10@DB6PR0401MB2407.eurprd04.prod.outlook.com>
> -----Original Message-----
> From: Yao Yuan [mailto:yao.yuan at nxp.com]
> Sent: Thursday, November 17, 2016 10:14 AM
> To: Krzeminski, Marcin (Nokia - PL/Wroclaw)
> <marcin.krzeminski@nokia.com>; Han Xu <xhnjupt@gmail.com>
> Cc: David Woodhouse <dwmw2@infradead.org>; linux-
> kernel at vger.kernel.org; linux-mtd at lists.infradead.org;
> han.xu at freescale.com; Brian Norris <computersforpeace@gmail.com>;
> jagannadh.teki at gmail.com; linux-arm-kernel at lists.infradead.org
> Subject: RE: [PATCH v3 6/9] mtd: spi-nor: Support R/W for S25FS-S family
> flash
>
> On Thu, Nov 17, 2016 at 06:50:55AM +0000, Krzeminski, Marcin (Nokia -
> PL/Wroclaw) wrote:
> > > > > On Thu, Aug 18, 2016 at 2:38 AM, Yunhui Cui
> > > > > <B56489@freescale.com>
> > > > > wrote:
> > > > > > From: Yunhui Cui <yunhui.cui@nxp.com>
> > > > > >
> > > > > > With the physical sectors combination, S25FS-S family flash
> > > > > > requires some special operations for read/write functions.
> > > > > >
> > > > > > Signed-off-by: Yunhui Cui <yunhui.cui@nxp.com>
> > > > > > ---
> > > > > > drivers/mtd/spi-nor/spi-nor.c | 56
> > > > > > +++++++++++++++++++++++++++++++++++++++++++
> > > > > > 1 file changed, 56 insertions(+)
> > > > > >
> > > > > > diff --git a/drivers/mtd/spi-nor/spi-nor.c
> > > > > > b/drivers/mtd/spi-nor/spi-nor.c index d0fc165..495d0bb 100644
> > > > > > --- a/drivers/mtd/spi-nor/spi-nor.c
> > > > > > +++ b/drivers/mtd/spi-nor/spi-nor.c
> > > > > > @@ -39,6 +39,10 @@
> > > > > >
> > > > > > #define SPI_NOR_MAX_ID_LEN 6
> > > > > > #define SPI_NOR_MAX_ADDR_WIDTH 4
> > > > > > +/* Added for S25FS-S family flash */
> > > > > > +#define SPINOR_CONFIG_REG3_OFFSET 0x800004
> > > > > > +#define CR3V_4KB_ERASE_UNABLE 0x8 #define
> > > > > > +SPINOR_S25FS_FAMILY_EXT_JEDEC 0x81
> > > > > >
> > > > > > struct flash_info {
> > > > > > char *name;
> > > > > > @@ -78,6 +82,7 @@ struct flash_info { };
> > > > > >
> > > > > > #define JEDEC_MFR(info) ((info)->id[0])
> > > > > > +#define EXT_JEDEC(info) ((info)->id[5])
> > > > > >
> > > > > > static const struct flash_info *spi_nor_match_id(const char
> > > > > > *name);
> > > > > >
> > > > > > @@ -899,6 +904,7 @@ static const struct flash_info spi_nor_ids[] = {
> > > > > > */
> > > > > > { "s25sl032p", INFO(0x010215, 0x4d00, 64 * 1024,
> > > > > > 64,
> > > > > SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> > > > > > { "s25sl064p", INFO(0x010216, 0x4d00, 64 * 1024,
> > > > > > 128, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> > > > > > + { "s25fs256s1", INFO6(0x010219, 0x4d0181, 64 * 1024,
> > > > > > + 512, 0)},
> > > > > > { "s25fl256s0", INFO(0x010219, 0x4d00, 256 * 1024, 128, 0) },
> > > > > > { "s25fl256s1", INFO(0x010219, 0x4d01, 64 * 1024,
> > > > > > 512,
> > > > > SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> > > > > > { "s25fl512s", INFO(0x010220, 0x4d00, 256 * 1024,
> > > > > > 256, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) }, @@ -1036,6
> > > +1042,50
> > > > > @@ static const struct flash_info *spi_nor_read_id(struct
> > > > > spi_nor
> > > > > *nor)
> > > > > > return ERR_PTR(-ENODEV); }
> > > > > >
> > > > > > +/*
> > > > > > + * The S25FS-S family physical sectors may be configured as a
> > > > > > + * hybrid combination of eight 4-kB parameter sectors
> > > > > > + * at the top or bottom of the address space with all
> > > > > > + * but one of the remaining sectors being uniform size.
> > > > > > + * The Parameter Sector Erase commands (20h or 21h) must
> > > > > > + * be used to erase the 4-kB parameter sectors individually.
> > > > > > + * The Sector (uniform sector) Erase commands (D8h or DCh)
> > > > > > + * must be used to erase any of the remaining
> > > > > > + * sectors, including the portion of highest or lowest
> > > > > > +address
> > > > > > + * sector that is not overlaid by the parameter sectors.
> > > > > > + * The uniform sector erase command has no effect on
> > > > > > +parameter
> > > > > sectors.
> > > > > > + */
> > > > > > +static int spansion_s25fs_disable_4kb_erase(struct spi_nor *nor) {
> > > > > > + u32 cr3v_addr = SPINOR_CONFIG_REG3_OFFSET;
> > > > > > + u8 cr3v = 0x0;
> > > > > > + int ret = 0x0;
> > > > > > +
> > > > > > + nor->cmd_buf[2] = cr3v_addr >> 16;
> > > > > > + nor->cmd_buf[1] = cr3v_addr >> 8;
> > > > > > + nor->cmd_buf[0] = cr3v_addr >> 0;
> > > > > > +
> > > > > > + ret = nor->read_reg(nor, SPINOR_OP_SPANSION_RDAR,
> &cr3v, 1);
> > > > > > + if (ret)
> > > > > > + return ret;
> > > > > > + if (cr3v & CR3V_4KB_ERASE_UNABLE)
> > > > > > + return 0;
> > > > > > + ret = nor->write_reg(nor, SPINOR_OP_WREN, NULL, 0);
> > > > > > + if (ret)
> > > > > > + return ret;
> > > > > > + cr3v = CR3V_4KB_ERASE_UNABLE;
> > > > > > + nor->program_opcode = SPINOR_OP_SPANSION_WRAR;
> > > > > > + nor->write(nor, cr3v_addr, 1, &cr3v);
> > > > > > +
> > > > > > + ret = nor->read_reg(nor, SPINOR_OP_SPANSION_RDAR,
> &cr3v, 1);
> > > > > > + if (ret)
> > > > > > + return ret;
> > > > > > + if (!(cr3v & CR3V_4KB_ERASE_UNABLE))
> > > > > > + return -EPERM;
> > > > > > +
> > > > > > + return 0;
> > > > > > +}
> > > > > > +
> > > > > > static int spi_nor_read(struct mtd_info *mtd, loff_t from, size_t
> len,
> > > > > > size_t *retlen, u_char *buf) { @@
> > > > > > -1361,6
> > > > > > +1411,12 @@ int spi_nor_scan(struct spi_nor *nor, const char
> > > > > > +*name,
> > > > > enum read_mode mode)
> > > > > > spi_nor_wait_till_ready(nor);
> > > > > > }
> > > > > >
> > > > > > + if (EXT_JEDEC(info) == SPINOR_S25FS_FAMILY_EXT_JEDEC) {
> > > > > > + ret = spansion_s25fs_disable_4kb_erase(nor);
> > > > > > + if (ret)
> > > > > > + return ret;
> > > > > > + }
> > > > > > +
> > > > > > if (!mtd->name)
> > > > > > mtd->name = dev_name(dev);
> > > > > > mtd->priv = nor;
> > > > > > --
> > > > > > 2.1.0.27.g96db324
> > > > > >
> > > > > >
> > > > > Hi Brian, I will ack this change but still feel it's kind of hacking code.
> > > > >
> > > > > Acked-by: Han xu <han.xu@nxp.com>
> > > >
> > > > I am new on the list so I am not sure if this topic has been discussed.
> > > > Generally our product functionality relay on those 4KiB sectors.
> > > > I know that this hack is already in u-boot, but if you mainstream
> > > > this you will force users of those 4KiB sectors to do hack the hack...
> > > > I believe the proper solution here is to use erase regions
> > > > functionality, I send and RFS about that some time ago.
> > >
> > > Do you mind to send me a link for reference?
> > >
> > Han,
> >
> > Sorry, It seem I have not posted erase region changes (only those
> > regarding DUAL/QUAD I/O).
> > Generally, in this flash you need to create 3 erase regions (because
> > in FS-S family support only 4KiB erase on parameters sector - eg. 1.2.2.4 in
> S25FS512S).
> > In my case regions are:
> > 1. 0-32KiB (8*4KiB) - 4K_ERASE (0x20/0x21) 2. 32 - 256 - SE_CMD
> (0xd8/0xdc) 3.
> > Rest of the flash SE_CMD (0xd8/0xdc)
> >
> > To erase whole flash you can also use CHIP_ERASE_CMD (0x60/0xC7)
> > command, you just need to add one more mtd partition that will cover
> whole flash.
> >
>
> Hi Krzeminski,
>
> Do you think is there any great advantages for enable 4KB?
> Because for NXP(Freescale) QSPI controller, there is only support max to 16
> groups command.
>
> So It's hard to give 3 groups command just for erase (0x21,0xdc and 0xc7).
> So we have to disable the 4kb erase and only use 256kbytes in this patch.
>
Yes, if you disable parameters sector in spi-nor framework you will disable it
for all spi-nor clients not only for NXP QSPI controller. There are users (at
least me) that relay on parameters sector functionality. This patch will brake it.
Thanks,
Marcin
^ permalink raw reply
* [PATCH] pinctrl: sunxi: fix theoretical uninitialized variable access
From: Arnd Bergmann @ 2016-11-17 9:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdYk25q9P5sErnfHcH49BT43vCCDihsZNEsf-6Gvpq+Pww@mail.gmail.com>
On Thursday, November 17, 2016 10:08:28 AM CET Linus Walleij wrote:
> On Wed, Nov 16, 2016 at 9:33 PM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
>
> > On Wed, Nov 16, 2016 at 03:18:18PM +0100, Arnd Bergmann wrote:
> >> gcc warns about a way that it could use an uninitialized variable:
> >>
> >> drivers/pinctrl/sunxi/pinctrl-sunxi.c: In function 'sunxi_pinctrl_init':
> >> drivers/pinctrl/sunxi/pinctrl-sunxi.c:1191:8: error: 'best_div' may be used uninitialized in this function [-Werror=maybe-uninitialized]
> >>
> >> This cannot really happen except if 'freq' is UINT_MAX and 'clock' is
> >> zero, and both of these are forbidden. To shut up the warning anyway,
> >> this changes the logic to initialize the return code to the first
> >> divider value before looking at the others.
> >>
> >> Fixes: 7c926492d38a ("pinctrl: sunxi: Add support for interrupt debouncing")
> >> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> >
> > Thanks for that patch.
> >
> > Just out of curiosity, which gcc gives those warnings? I have 6.2 and
> > it didn't output anything..
>
> Context: Arnd re-enabled -Werror=maybe-uninitialized
> in the kernel build and this kind of stuff started to appear so
> it needs to be fixed up.
Right, it was disabled from linux-4.8-rc1 to linux-4.9-rc4 and is now back
in the default builds when using gcc-4.9 or higher. You should get the
warning if you test with linux-next or -rc4.
Arnd
^ 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