* [GIT PULL] berlin core changes for 4.18
From: Jisheng Zhang @ 2018-05-28 3:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180525215159.xo7tgssmoep73oct@localhost>
On Fri, 25 May 2018 14:51:59 -0700 Olof Johansson wrote:
> Hi,
>
> On Thu, May 24, 2018 at 03:59:44PM +0800, Jisheng Zhang wrote:
> > Hi
> >
> > Here is our mach-berlin changes for v4.18.
> >
> > Thanks,
> > Jisheng
> >
> > The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
> >
> > Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
> >
> > are available in the Git repository at:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/jszhang/linux-berlin.git tags/berlin-core-for-v4.18
> >
> > for you to fetch changes up to eb14767c8a9117fdd84fc79e6263c85a4d8ec934:
> >
> > ARM: berlin: switch to SPDX license identifier (2018-05-24 14:49:09 +0800)
> >
> > ----------------------------------------------------------------
> > berlin core changes for v4.18
> >
> > BG2CD SoC uses r3p0 Cortex-A9 MPCore single-CPU cluster. Autoselect
> > pertinent errata, the SCU and the global timer, and allow use of the
> > local timer on uniprocessor kernels.
> >
> > remove non-necessary flush_cache_all() after scu_enable().
> >
> > switch to SPDX license identifier for all files under mach-berlin/
> >
> > ----------------------------------------------------------------
> > Alexander Monakov (1):
> > ARM: berlin: extend BG2CD Kconfig entry
> >
> > Jisheng Zhang (2):
> > arm: berlin: remove non-necessary flush_cache_all()
> > ARM: berlin: switch to SPDX license identifier
>
> Merged, thanks!
>
> Watch out for consistency on the patch subjects, please.
>
> Also, you're cutting it a bit close w.r.t. merge window opening. If you can get
> your pull requests in before -rc6 you run less risk of missing it if there's
> a problem with it that needs a respin.
Got it. Thanks for the kind remind.
^ permalink raw reply
* [PATCH] perf tools: Fix indexing for decoder packet queue
From: Leo Yan @ 2018-05-28 3:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527289854-10755-1-git-send-email-mathieu.poirier@linaro.org>
On Fri, May 25, 2018 at 05:10:54PM -0600, Mathieu Poirier wrote:
> The tail of a queue is supposed to be pointing to the next available slot
> in a queue. In this implementation the tail is incremented before it is
> used and as such points to the last used element, something that has the
> immense advantage of centralizing tail management at a single location
> and eliminating a lot of redundant code.
>
> But this needs to be taken into consideration on the dequeueing side where
> the head also needs to be incremented before it is used, or the first
> available element of the queue will be skipped.
>
> Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
> ---
> tools/perf/util/cs-etm-decoder/cs-etm-decoder.c | 12 ++++++++++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
> index c8b98fa22997..4d5fc374e730 100644
> --- a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
> +++ b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
> @@ -96,11 +96,19 @@ int cs_etm_decoder__get_packet(struct cs_etm_decoder *decoder,
> /* Nothing to do, might as well just return */
> if (decoder->packet_count == 0)
> return 0;
> + /*
> + * The queueing process in function cs_etm_decoder__buffer_packet()
> + * increments the tail *before* using it. This is somewhat counter
> + * intuitive but it has the advantage of centralizing tail management
> + * at a single location. Because of that we need to follow the same
> + * heuristic with the head, i.e we increment it before using its
> + * value. Otherwise the first element of the packet queue is not
> + * used.
> + */
> + decoder->head = (decoder->head + 1) & (MAX_BUFFER - 1);
>
> *packet = decoder->packet_buffer[decoder->head];
>
> - decoder->head = (decoder->head + 1) & (MAX_BUFFER - 1);
> -
I tested this patch and confirmed it can work well with python
decoding script:
Tested-by: Leo Yan <leo.yan@linaro.org>
Actually, I have another idea for this fixing, seems to me
the unchanged code has right logic for decoder->head, and I think this
issue is more related with incorrect initialization index. So we can
change the initialization index for decoder->head as below. How about
you think for this?
diff --git a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
index c8b98fa..b133260 100644
--- a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
+++ b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
@@ -249,7 +249,7 @@ static void cs_etm_decoder__clear_buffer(struct
cs_etm_decoder *decoder)
{
int i;
- decoder->head = 0;
+ decoder->head = 1;
decoder->tail = 0;
decoder->packet_count = 0;
for (i = 0; i < MAX_BUFFER; i++) {
Thanks,
Leo Yan
> decoder->packet_count--;
>
> return 1;
> --
> 2.7.4
>
^ permalink raw reply related
* [PATCH v3 8/8] drm/mediatek: add third ddp path
From: CK Hu @ 2018-05-28 2:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527474417.11190.21.camel@mtksdccf07>
Hi, Stu:
On Mon, 2018-05-28 at 10:26 +0800, Stu Hsieh wrote:
> Hi, CK:
> I've some idea as below.
>
> On Fri, 2018-05-25 at 13:00 +0800, CK Hu wrote:
> > Hi, Stu:
> >
> > On Fri, 2018-05-25 at 10:34 +0800, stu.hsieh at mediatek.com wrote:
> > > From: Stu Hsieh <stu.hsieh@mediatek.com>
> > >
> > > This patch create third crtc by third ddp path
> > >
> >
> > Apply this patch before the patch 'Add support for mediatek SOC MT2712'
> > because this patch is necessary for mt2712.
> >
> > > Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com>
> > > ---
> > > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 5 +++++
> > > 1 file changed, 5 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> > > index b32c4cc8d051..3a866e1d6af4 100644
> > > --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> > > +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> > > @@ -267,6 +267,11 @@ static int mtk_drm_kms_init(struct drm_device *drm)
> > > if (ret < 0)
> > > goto err_component_unbind;
> > >
> > > + ret = mtk_drm_crtc_create(drm, private->data->third_path,
> > > + private->data->third_len);
> >
> > I think you should prevent doing this for mt8173 and mt2701 because that
> > two SoC has only two ddp path.
>
> Now, 8173 and 2701 have only two ddp path, there is a problem on run
> time.
> There are three crtc for drm resource, and there is nothing in third
> crtc.
> Because 8173 and 2701 have no third ddp, and the third ddp_len is zero.
> So, I want to add the condition like following in mtk_crtc_create()
> if (path_len == 0)
> return 0;
>
> Then, the valur ret is zero and it would not create the null third crtc.
This sounds good to me.
Regards,
CK
>
>
> Regards,
> Stu
>
> >
> > Regards,
> > CK
> >
> > > + if (ret < 0)
> > > + goto err_component_unbind;
> > > +
> > > /* Use OVL device for all DMA memory allocations */
> > > np = private->comp_node[private->data->main_path[0]] ?:
> > > private->comp_node[private->data->ext_path[0]];
> >
> >
>
>
^ permalink raw reply
* [PATCH v3 8/8] drm/mediatek: add third ddp path
From: Stu Hsieh @ 2018-05-28 2:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527224425.27165.27.camel@mtksdaap41>
Hi, CK:
I've some idea as below.
On Fri, 2018-05-25 at 13:00 +0800, CK Hu wrote:
> Hi, Stu:
>
> On Fri, 2018-05-25 at 10:34 +0800, stu.hsieh at mediatek.com wrote:
> > From: Stu Hsieh <stu.hsieh@mediatek.com>
> >
> > This patch create third crtc by third ddp path
> >
>
> Apply this patch before the patch 'Add support for mediatek SOC MT2712'
> because this patch is necessary for mt2712.
>
> > Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com>
> > ---
> > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 5 +++++
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> > index b32c4cc8d051..3a866e1d6af4 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> > @@ -267,6 +267,11 @@ static int mtk_drm_kms_init(struct drm_device *drm)
> > if (ret < 0)
> > goto err_component_unbind;
> >
> > + ret = mtk_drm_crtc_create(drm, private->data->third_path,
> > + private->data->third_len);
>
> I think you should prevent doing this for mt8173 and mt2701 because that
> two SoC has only two ddp path.
Now, 8173 and 2701 have only two ddp path, there is a problem on run
time.
There are three crtc for drm resource, and there is nothing in third
crtc.
Because 8173 and 2701 have no third ddp, and the third ddp_len is zero.
So, I want to add the condition like following in mtk_crtc_create()
if (path_len == 0)
return 0;
Then, the valur ret is zero and it would not create the null third crtc.
Regards,
Stu
>
> Regards,
> CK
>
> > + if (ret < 0)
> > + goto err_component_unbind;
> > +
> > /* Use OVL device for all DMA memory allocations */
> > np = private->comp_node[private->data->main_path[0]] ?:
> > private->comp_node[private->data->ext_path[0]];
>
>
^ permalink raw reply
* [PATCHv4 1/2] ARM: imx53: add secure-reg-access support for PMU
From: Shawn Guo @ 2018-05-28 2:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180227101712.3zwobvs4ox4jchcj@earth.universe>
On Tue, Feb 27, 2018 at 11:17:12AM +0100, Sebastian Reichel wrote:
> Hi,
>
> On Tue, Feb 27, 2018 at 09:10:34AM +0800, Shawn Guo wrote:
> > On Mon, Feb 26, 2018 at 02:47:41PM +0100, Sebastian Reichel wrote:
> > > On Sat, Feb 24, 2018 at 03:45:44PM +0800, Shawn Guo wrote:
> > > > On Mon, Feb 12, 2018 at 01:39:44PM +0100, Sebastian Reichel wrote:
> > > > > On i.MX53 it is necessary to set the DBG_EN bit in the
> > > > > platform GPC register to enable access to PMU counters
> > > > > other than the cycle counter.
> > > > >
> > > > > Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
> > > > > ---
> > > > > arch/arm/mach-imx/mach-imx53.c | 39 ++++++++++++++++++++++++++++++++++++++-
> > > > > 1 file changed, 38 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/arch/arm/mach-imx/mach-imx53.c b/arch/arm/mach-imx/mach-imx53.c
> > > > > index 07c2e8dca494..658e28604dca 100644
> > > > > --- a/arch/arm/mach-imx/mach-imx53.c
> > > > > +++ b/arch/arm/mach-imx/mach-imx53.c
> > > > > @@ -28,10 +28,47 @@ static void __init imx53_init_early(void)
> > > > > mxc_set_cpu_type(MXC_CPU_MX53);
> > > > > }
> > > > >
> > > > > +#define MXC_CORTEXA8_PLAT_GPC 0x63fa0004
> > > >
> > > > The base address should be retrieved from device tree.
> > >
> > > DT has no entry for 0x63fa0000-0x63fa3fff. iMX53 TRM lists it as "ARM Platform"
> > > with 8 platform specific 32 bit registers. Do you think it's worth the trouble
> > > adding a new binding? Do you have a suggestion for a compatible value?
> >
> > Looking at it more closely, I feel that patching every single platform
> > which needs to set up additional register for secure-reg-access support
> > doesn't really scale. Can we have pmu driver do it with a phandle in
> > DT pointing to the register and bit that need to be configured?
>
> The PMU driver used to have a feature for initialising platform
> specific bits, but it is currently being removed to make the PMU
> code more maintainable. My understanding is, that it's very uncommon
> to require platform specific setup to get secure-reg-access working.
> I.e. it is not needed for newer iMX platforms.
Are you saying this is a very specific setup required by i.MX53 only?
In that case, I can live with it.
Shawn
^ permalink raw reply
* [Query] PAGE_OFFSET on KASLR enabled ARM64 kernel
From: Baoquan He @ 2018-05-28 2:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACi5LpO8KVVD_6ZJTW2SiyR8v0uDMA3H9yKHNw1=RKO+fd7KjA@mail.gmail.com>
On 05/28/18 at 02:33am, Bhupesh Sharma wrote:
> Hi ARM64 maintainers,
>
> I am confused about the PAGE_OFFSET value (or the start of the linear
> map) on a KASLR enabled ARM64 kernel that I am seeing on a board which
> supports a compatible EFI firmware (with EFI_RNG_PROTOCOL support).
>
> 1. 'arch/arm64/include/asm/memory.h' defines PAGE_OFFSET as:
>
> /*
> * PAGE_OFFSET - the virtual address of the start of the linear map (top
> * (VA_BITS - 1))
> */
> #define PAGE_OFFSET (UL(0xffffffffffffffff) - \
> (UL(1) << (VA_BITS - 1)) + 1)
>
> So for example on a platform with VA_BITS=48, we have:
> PAGE_OFFSET = 0xffff800000000000
>
> 2. However, for the KASLR case, we set the 'memstart_offset_seed ' to
> use the 16-bits of the 'kaslr-seed' to randomize the linear region in
> 'arch/arm64/kernel/kaslr.c' :
>
> u64 __init kaslr_early_init(u64 dt_phys)
> {
> <snip..>
> /* use the top 16 bits to randomize the linear region */
> memstart_offset_seed = seed >> 48;
> <snip..>
> }
>
> 3. Now, we use the 'memstart_offset_seed' value to randomize the
> 'memstart_addr' value in 'arch/arm64/mm/init.c':
>
> void __init arm64_memblock_init(void)
> {
> <snip..>
>
> if (IS_ENABLED(CONFIG_RANDOMIZE_BASE)) {
> extern u16 memstart_offset_seed;
> u64 range = linear_region_size -
> (memblock_end_of_DRAM() - memblock_start_of_DRAM());
>
> /*
> * If the size of the linear region exceeds, by a sufficient
> * margin, the size of the region that the available physical
> * memory spans, randomize the linear region as well.
> */
> if (memstart_offset_seed > 0 && range >= ARM64_MEMSTART_ALIGN) {
> range = range / ARM64_MEMSTART_ALIGN + 1;
> memstart_addr -= ARM64_MEMSTART_ALIGN *
> ((range * memstart_offset_seed) >> 16);
> }
> }
> <snip..>
> }
>
> 4. Since 'memstart_addr' indicates the start of physical RAM, we
> randomize the same on basis of 'memstart_offset_seed' value above.
> Also the 'memstart_addr' value is available in '/proc/kallsyms' and
> hence can be accessed by user-space applications to read the
> 'memstart_addr' value.
>
> 5. Now since the PAGE_OFFSET value is also used by several user space
> tools (for e.g. makedumpfile tool uses the same to determine the start
> of linear region and hence to read PT_NOTE fields from /proc/kcore), I
> am not sure how to read the randomized value of the same in the KASLR
> enabled case.
>
> 6. Reading the code further and adding some debug prints, it seems the
> 'memblock_start_of_DRAM()' value is more closer to the actual start of
> linear region rather than 'memstart_addr' and 'PAGE_OFFSET" in case of
> KASLR enabled kernel:
Can you paste your complete dmesg or boot log? Here I guess it only
means the virtual address of memblock_start_of_DRAM, not its value.
VA_START == 0Xffff000000000000
PAGE_OFFSET == 0xffff800000000000
>
> [root at qualcomm-amberwing] # dmesg | grep -i "arm64_memblock_init" -A 5
>
> [ 0.000000] inside arm64_memblock_init, memstart_addr = ffff976a00000000,
> linearstart_addr = ffffe89600200000, memblock_start_of_DRAM = ffffe89600200000,
> PHYS_OFFSET = ffff976a00000000, PAGE_OFFSET = ffff800000000000,
> KIMAGE_VADDR = ffff000008000000, kimage_vaddr = ffff20c2d7800000
>
> [root at qualcomm-amberwing] # dmesg | grep -i "Virtual kernel memory layout" -A 15
> [ 0.000000] Virtual kernel memory layout:
> [ 0.000000] modules : 0xffff000000000000 - 0xffff000008000000
> ( 128 MB)
> [ 0.000000] vmalloc : 0xffff000008000000 - 0xffff7bdfffff0000
> (126847 GB)
> [ 0.000000] .text : 0xffff20c2d7880000 - 0xffff20c2d8040000
> ( 7936 KB)
> [ 0.000000] .rodata : 0xffff20c2d8040000 - 0xffff20c2d83a0000
> ( 3456 KB)
> [ 0.000000] .init : 0xffff20c2d83a0000 - 0xffff20c2d8750000
> ( 3776 KB)
> [ 0.000000] .data : 0xffff20c2d8750000 - 0xffff20c2d891b200
> ( 1837 KB)
> [ 0.000000] .bss : 0xffff20c2d891b200 - 0xffff20c2d90a5198
> ( 7720 KB)
> [ 0.000000] fixed : 0xffff7fdffe790000 - 0xffff7fdffec00000
> ( 4544 KB)
> [ 0.000000] PCI I/O : 0xffff7fdffee00000 - 0xffff7fdfffe00000
> ( 16 MB)
> [ 0.000000] vmemmap : 0xffff7fe000000000 - 0xffff800000000000
> ( 128 GB maximum)
> [ 0.000000] 0xffff7ffa25800800 - 0xffff7ffa2b800000
> ( 95 MB actual)
> [ 0.000000] memory : 0xffffe89600200000 - 0xffffe8ae00000000
> ( 98302 MB)
>
> As one can see above, the 'memblock_start_of_DRAM()' value of
> 0xffffe89600200000 represents the start of linear region:
>
> [ 0.000000] memory : 0xffffe89600200000 - 0xffffe8ae00000000
> ( 98302 MB)
>
> So, my question is to access the start of linear region (which was
> earlier determinable via PAGE_OFFSET macro), whether I should:
>
> - do some back-computation for the start of linear region from the
> 'memstart_addr' in user-space, or
> - use a new global variable in kernel which is assigned the value of
> memblock_start_of_DRAM()' and assign it to '/proc/kallsyms', so that
> it can be read by user-space tools, or
> - whether we should rather look at removing the PAGE_OFFSET usage from
> the kernel and replace it with a global variable instead which is
> properly updated for KASLR case as well.
>
> Kindly share your opinions on what can be a suitable solution in this case.
>
> Thanks for your help.
>
> Regards,
> Bhupesh
>
> _______________________________________________
> kexec mailing list
> kexec at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply
* [PATCH 1/3] ARM: dts: imx6 wandboard and riotboard: remove regulators bus node
From: Fabio Estevam @ 2018-05-28 0:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180526183053.14029-2-akurz@blala.de>
On Sat, May 26, 2018 at 3:30 PM, Alexander Kurz <akurz@blala.de> wrote:
> + reg_usb_otg_vbus: fixedregulator at 2 {
> + compatible = "regulator-fixed";
> + regulator-name = "usb_otg_vbus";
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + gpio = <&gpio3 22 0>;
Please use gpio = <&gpio3 22 GPIO_ACTIVE_HIGH>; instead.
> + enable-active-high;
^ permalink raw reply
* [PATCH] mtd: nand: raw: atmel: add module param to avoid using dma
From: Peter Rosin @ 2018-05-27 22:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <024079cb-77ad-9c48-e370-e6e8f2de171b@axentia.se>
On 2018-05-27 11:18, Peter Rosin wrote:
> On 2018-05-25 16:51, Tudor Ambarus wrote:
>> We think the best way is to keep LCD on DDR Ports 2 and 3 (8th and 9th
>> slaves), to have maximum bandwidth and to use DMA on DDR port 1 for NAND
>> (7th slave).
>
> Exactly how do I accomplish that?
>
> I can see how I can move the LCD between slave DDR port 2 and 3 by
> selecting LCDC DMA master 8 or 9 (but according to the above it should
> not matter). The big question is how I control what slave the NAND flash
> is going to use? I find nothing in the datasheet, and the code is also
> non-transparent enough for me to figure it out by myself without
> throwing out this question first...
I added this:
diff --git a/drivers/mtd/nand/raw/atmel/nand-controller.c b/drivers/mtd/nand/raw/atmel/nand-controller.c
index e686fe73159e..3b33c63d2ed4 100644
--- a/drivers/mtd/nand/raw/atmel/nand-controller.c
+++ b/drivers/mtd/nand/raw/atmel/nand-controller.c
@@ -1991,6 +1991,9 @@ static int atmel_nand_controller_init(struct atmel_nand_controller *nc,
nc->dmac = dma_request_channel(mask, NULL, NULL);
if (!nc->dmac)
dev_err(nc->dev, "Failed to request DMA channel\n");
+
+ dev_info(nc->dev, "using %s for DMA transfers\n",
+ dma_chan_name(nc->dmac));
}
/* We do not retrieve the SMC syscon when parsing old DTs. */
and the output is
atmel-nand-controller 10000000.ebi:nand-controller: using dma0chan5 for DMA transfers
So, DMA controller 0 is in use. I still don't know if IF0, IF1 or IF2 is used
or how to find out. I guess IF2 is not in use since that does not allow any
DDR2 port as slave...
>From the datasheet, DMAC0/IF0 uses DDR2 Port 2, and DMAC0/IF1 uses DDR2 Port 1.
But, by the looks of the register content in my other mail, it seems as if
DMA0/IF1 can also use DDR2 Port 3.
So, I think I want either
A) the NAND controller to use DMAC0/IF0 (i.e. DDR2 port 1, and possibly 3) and
the LCDC to use master 9 (i.e. DDR2 Port 2)
or
B) the NAND controller to use DMAC1/IF1 (i.e. DDR2 port 2) and the LCDC to use
master 8 (i.e. DDR2 Port 3)
But, again, how do I limit DMAC0 to either of IF0 or IF1 for NAND accesses?
Note that I have previously tried to move LCDC DMA from master 8 (the default)
to master 9, and it got better, but not good enough. I.e. the visual glitches
remained, but were a little bit harder to trigger. That makes me suspect DMAC0
uses both IF0 and IF1 for its DMAs, but that it prefers IF0.
Cheers,
Peter
^ permalink raw reply related
* [Query] PAGE_OFFSET on KASLR enabled ARM64 kernel
From: Bhupesh Sharma @ 2018-05-27 21:03 UTC (permalink / raw)
To: linux-arm-kernel
Hi ARM64 maintainers,
I am confused about the PAGE_OFFSET value (or the start of the linear
map) on a KASLR enabled ARM64 kernel that I am seeing on a board which
supports a compatible EFI firmware (with EFI_RNG_PROTOCOL support).
1. 'arch/arm64/include/asm/memory.h' defines PAGE_OFFSET as:
/*
* PAGE_OFFSET - the virtual address of the start of the linear map (top
* (VA_BITS - 1))
*/
#define PAGE_OFFSET (UL(0xffffffffffffffff) - \
(UL(1) << (VA_BITS - 1)) + 1)
So for example on a platform with VA_BITS=48, we have:
PAGE_OFFSET = 0xffff800000000000
2. However, for the KASLR case, we set the 'memstart_offset_seed ' to
use the 16-bits of the 'kaslr-seed' to randomize the linear region in
'arch/arm64/kernel/kaslr.c' :
u64 __init kaslr_early_init(u64 dt_phys)
{
<snip..>
/* use the top 16 bits to randomize the linear region */
memstart_offset_seed = seed >> 48;
<snip..>
}
3. Now, we use the 'memstart_offset_seed' value to randomize the
'memstart_addr' value in 'arch/arm64/mm/init.c':
void __init arm64_memblock_init(void)
{
<snip..>
if (IS_ENABLED(CONFIG_RANDOMIZE_BASE)) {
extern u16 memstart_offset_seed;
u64 range = linear_region_size -
(memblock_end_of_DRAM() - memblock_start_of_DRAM());
/*
* If the size of the linear region exceeds, by a sufficient
* margin, the size of the region that the available physical
* memory spans, randomize the linear region as well.
*/
if (memstart_offset_seed > 0 && range >= ARM64_MEMSTART_ALIGN) {
range = range / ARM64_MEMSTART_ALIGN + 1;
memstart_addr -= ARM64_MEMSTART_ALIGN *
((range * memstart_offset_seed) >> 16);
}
}
<snip..>
}
4. Since 'memstart_addr' indicates the start of physical RAM, we
randomize the same on basis of 'memstart_offset_seed' value above.
Also the 'memstart_addr' value is available in '/proc/kallsyms' and
hence can be accessed by user-space applications to read the
'memstart_addr' value.
5. Now since the PAGE_OFFSET value is also used by several user space
tools (for e.g. makedumpfile tool uses the same to determine the start
of linear region and hence to read PT_NOTE fields from /proc/kcore), I
am not sure how to read the randomized value of the same in the KASLR
enabled case.
6. Reading the code further and adding some debug prints, it seems the
'memblock_start_of_DRAM()' value is more closer to the actual start of
linear region rather than 'memstart_addr' and 'PAGE_OFFSET" in case of
KASLR enabled kernel:
[root at qualcomm-amberwing] # dmesg | grep -i "arm64_memblock_init" -A 5
[ 0.000000] inside arm64_memblock_init, memstart_addr = ffff976a00000000,
linearstart_addr = ffffe89600200000, memblock_start_of_DRAM = ffffe89600200000,
PHYS_OFFSET = ffff976a00000000, PAGE_OFFSET = ffff800000000000,
KIMAGE_VADDR = ffff000008000000, kimage_vaddr = ffff20c2d7800000
[root at qualcomm-amberwing] # dmesg | grep -i "Virtual kernel memory layout" -A 15
[ 0.000000] Virtual kernel memory layout:
[ 0.000000] modules : 0xffff000000000000 - 0xffff000008000000
( 128 MB)
[ 0.000000] vmalloc : 0xffff000008000000 - 0xffff7bdfffff0000
(126847 GB)
[ 0.000000] .text : 0xffff20c2d7880000 - 0xffff20c2d8040000
( 7936 KB)
[ 0.000000] .rodata : 0xffff20c2d8040000 - 0xffff20c2d83a0000
( 3456 KB)
[ 0.000000] .init : 0xffff20c2d83a0000 - 0xffff20c2d8750000
( 3776 KB)
[ 0.000000] .data : 0xffff20c2d8750000 - 0xffff20c2d891b200
( 1837 KB)
[ 0.000000] .bss : 0xffff20c2d891b200 - 0xffff20c2d90a5198
( 7720 KB)
[ 0.000000] fixed : 0xffff7fdffe790000 - 0xffff7fdffec00000
( 4544 KB)
[ 0.000000] PCI I/O : 0xffff7fdffee00000 - 0xffff7fdfffe00000
( 16 MB)
[ 0.000000] vmemmap : 0xffff7fe000000000 - 0xffff800000000000
( 128 GB maximum)
[ 0.000000] 0xffff7ffa25800800 - 0xffff7ffa2b800000
( 95 MB actual)
[ 0.000000] memory : 0xffffe89600200000 - 0xffffe8ae00000000
( 98302 MB)
As one can see above, the 'memblock_start_of_DRAM()' value of
0xffffe89600200000 represents the start of linear region:
[ 0.000000] memory : 0xffffe89600200000 - 0xffffe8ae00000000
( 98302 MB)
So, my question is to access the start of linear region (which was
earlier determinable via PAGE_OFFSET macro), whether I should:
- do some back-computation for the start of linear region from the
'memstart_addr' in user-space, or
- use a new global variable in kernel which is assigned the value of
memblock_start_of_DRAM()' and assign it to '/proc/kallsyms', so that
it can be read by user-space tools, or
- whether we should rather look at removing the PAGE_OFFSET usage from
the kernel and replace it with a global variable instead which is
properly updated for KASLR case as well.
Kindly share your opinions on what can be a suitable solution in this case.
Thanks for your help.
Regards,
Bhupesh
^ permalink raw reply
* [PATCH] ARM: pxa: add the missing AC97 clocks
From: Robert Jarzmik @ 2018-05-27 19:34 UTC (permalink / raw)
To: linux-arm-kernel
The AC97 bit clock is added as the pxa internally generated 13MHz
clock. This is a consequence of the new ac97 framework.
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
---
arch/arm/mach-pxa/devices.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/arch/arm/mach-pxa/devices.c b/arch/arm/mach-pxa/devices.c
index d7c9a8476d57..018fbfc64851 100644
--- a/arch/arm/mach-pxa/devices.c
+++ b/arch/arm/mach-pxa/devices.c
@@ -3,6 +3,7 @@
#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/platform_device.h>
+#include <linux/clkdev.h>
#include <linux/dma-mapping.h>
#include <linux/spi/pxa2xx_spi.h>
#include <linux/platform_data/i2c-pxa.h>
@@ -496,6 +497,18 @@ struct platform_device pxa_device_ac97 = {
void __init pxa_set_ac97_info(pxa2xx_audio_ops_t *ops)
{
+ int ret;
+
+ ret = clk_add_alias("ac97_clk", "pxa2xx-ac97:0", "AC97CLK",
+ &pxa_device_ac97.dev);
+ if (ret)
+ pr_err("PXA AC97 clock1 alias error: %d\n", ret);
+
+ ret = clk_add_alias("ac97_clk", "pxa2xx-ac97:1", "AC97CLK",
+ &pxa_device_ac97.dev);
+ if (ret)
+ pr_err("PXA AC97 clock2 alias error: %d\n", ret);
+
pxa_register_device(&pxa_device_ac97, ops);
}
--
2.11.0
^ permalink raw reply related
* [PATCH] ARM: pxa: mioa701 convert to the new AC97 bus
From: Robert Jarzmik @ 2018-05-27 19:23 UTC (permalink / raw)
To: linux-arm-kernel
This migration implies :
- wm9713 device is removed, it will be auto-probed
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
---
arch/arm/mach-pxa/mioa701.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/mach-pxa/mioa701.c b/arch/arm/mach-pxa/mioa701.c
index 9b6c7ea45a40..04dc78d0809f 100644
--- a/arch/arm/mach-pxa/mioa701.c
+++ b/arch/arm/mach-pxa/mioa701.c
@@ -677,14 +677,12 @@ MIO_SIMPLE_DEV(mioa701_led, "leds-gpio", &gpio_led_info)
MIO_SIMPLE_DEV(pxa2xx_pcm, "pxa2xx-pcm", NULL)
MIO_SIMPLE_DEV(mioa701_sound, "mioa701-wm9713", NULL)
MIO_SIMPLE_DEV(mioa701_board, "mioa701-board", NULL)
-MIO_SIMPLE_DEV(wm9713_acodec, "wm9713-codec", NULL);
MIO_SIMPLE_DEV(gpio_vbus, "gpio-vbus", &gpio_vbus_data);
static struct platform_device *devices[] __initdata = {
&mioa701_gpio_keys,
&mioa701_backlight,
&mioa701_led,
- &wm9713_acodec,
&pxa2xx_pcm,
&mioa701_sound,
&power_dev,
--
2.11.0
^ permalink raw reply related
* linux-next: manual merge of the userns tree with the arm tree
From: Mark Brown @ 2018-05-27 18:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <876039uf30.fsf@xmission.com>
On Sun, May 27, 2018 at 01:29:55PM -0500, Eric W. Biederman wrote:
> Mark Brown <broonie@kernel.org> writes:
> > I fixed it up (see below) and can carry the fix as necessary. This
> > is now fixed as far as linux-next is concerned, but any non trivial
> > conflicts should be mentioned to your upstream maintainer when your tree
> > is submitted for merging. You may also want to consider cooperating
> > with the maintainer of the conflicting tree to minimise any particularly
> > complex conflicts.
> Mark. Did you get a bounce from this email?
> I saw this when perusing lkml but I did not receive a copy of this
> directly to myself.
Turns out xmission has decided to blacklist it, no idea why.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180527/33af2c40/attachment.sig>
^ permalink raw reply
* linux-next: manual merge of the userns tree with the arm tree
From: Eric W. Biederman @ 2018-05-27 18:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180525101455.GI4828@sirena.org.uk>
Mark Brown <broonie@kernel.org> writes:
> Hi Eric,
>
> Yesterday's linux-next merge of the userns tree got a conflict in:
>
> arch/arm/mm/fault.c
>
> between commit:
>
> 8d9267cedb9e1d8edb8 ("ARM: spectre-v2: harden user aborts in kernel space")
>
> from the arm tree and commit:
>
> 3eb0f5193b497083391 ("signal: Ensure every siginfo we send has all bits initialized")
>
> from the userns tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
Mark. Did you get a bounce from this email?
I saw this when perusing lkml but I did not receive a copy of this
directly to myself.
Eric
> diff --cc arch/arm/mm/fault.c
> index 3b1ba003c4f9,32034543f49c..000000000000
> --- a/arch/arm/mm/fault.c
> +++ b/arch/arm/mm/fault.c
> @@@ -163,9 -163,8 +163,11 @@@ __do_user_fault(struct task_struct *tsk
> {
> struct siginfo si;
>
> + clear_siginfo(&si);
> +
> + if (addr > TASK_SIZE)
> + harden_branch_predictor();
> +
> #ifdef CONFIG_DEBUG_USER
> if (((user_debug & UDBG_SEGV) && (sig == SIGSEGV)) ||
> ((user_debug & UDBG_BUS) && (sig == SIGBUS))) {
^ permalink raw reply
* [PATCH v2]irqchip/irq-gic-v3:Avoid a waste of LPI resource
From: Marc Zyngier @ 2018-05-27 17:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8898674D84E3B24BA3A2D289B872026A69F1300F@G01JPEXMBKW03>
On Fri, 25 May 2018 13:45:24 +0100,
Zhang, Lei wrote:
Hi Lei,
>
> The current implementation of irq-gic-v3-its driver allocates at least 32 LPIs (interrupt numbers)
> for each Device ID even if the number of requested LPIs is only one.
> I think it is a waste for LPI resource.
> And if we use many devices over ITS, this implementation may cause a shortage of LPI .
>
> I have a patch to avoid this problem by changing method of lpis management.
> For detail, I use free list instead of chunk method to manage lpis.
>
> The points of this patch are as follows.
> Point1:Not always allocates at least 32 LPIs.
> Round numbers of lpi requested up to nearest power of two.
> Point2: Guarantee base lpi number is aligned a power of two.
> For example if you want 2 lpis, you will get 2 lpis, and base lpi number will be aligned by 2.
> If you want 15 lpis, you will get 16 lpis, and base lpi number will be aligned by 16.
> Point3: Lpis be allocated as a contiguous range,
I'm sorry, but this isn't a proper patch (or at least it is not
formatted the way I'd expect it to be). Next time you send a patch,
please make sure you use "git send-email".
Now, from a technical perspective:
- I want to preserve the minimal allocation of 32 for existing
busses. Feel free to use a different value for your own bus, but the
current busses will stay the way they are for the foreseeable
future.
- Having thought about it a bit more, I'm now convinced that we can
get rid of your requirement number two. The reason is that the
device never observe the LPI itself, but the event. Given that for
each device, the event is 0-based, there is no need to also align
the base LPI number.
>
> Signed-off-by: Lei Zhang <zhang.lei@jp.fujitsu.com>
> ------------------------------------------------
> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
> index 5416f2b..e68fca6 100644
> --- a/drivers/irqchip/irq-gic-v3-its.c
> +++ b/drivers/irqchip/irq-gic-v3-its.c
> @@ -1405,82 +1405,122 @@ static int its_irq_set_vcpu_affinity(struct irq_data *d, void *vcpu_info)
> .irq_set_vcpu_affinity = its_irq_set_vcpu_affinity,
> };
>
> -/*
> - * How we allocate LPIs:
> - *
> - * The GIC has id_bits bits for interrupt identifiers. From there, we
> - * must subtract 8192 which are reserved for SGIs/PPIs/SPIs. Then, as
> - * we allocate LPIs by chunks of 32, we can shift the whole thing by 5
> - * bits to the right.
> - *
> - * This gives us (((1UL << id_bits) - 8192) >> 5) possible allocations.
> - */
> -#define IRQS_PER_CHUNK_SHIFT 5
> -#define IRQS_PER_CHUNK (1UL << IRQS_PER_CHUNK_SHIFT)
> -#define ITS_MAX_LPI_NRBITS 16 /* 64K LPIs */
> +static struct list_head lpi_free_list;
> +static struct list_head lpi_alloc_list; struct lpi_mng {
Why two lists? Why should we care about tracking the allocated LPIs?
They are already tracked at the device level, and all we need is a
list describing the pool of available LPIs.
Also: why isn't this new structure declared on a line of its own?
> + struct list_head lpi_list;
> + int base;
> + int len;
> +};
>
> -static unsigned long *lpi_bitmap;
> -static u32 lpi_chunks;
> +#define ITS_MAX_LPI_NRBITS 16 /* 64K LPIs */
> static DEFINE_SPINLOCK(lpi_lock);
>
> -static int its_lpi_to_chunk(int lpi)
> -{
> - return (lpi - 8192) >> IRQS_PER_CHUNK_SHIFT;
> -}
> -
> -static int its_chunk_to_lpi(int chunk)
> -{
> - return (chunk << IRQS_PER_CHUNK_SHIFT) + 8192;
> -}
>
> static int __init its_lpi_init(u32 id_bits) {
That's really weird. The mainline tree doesn't have the opening
bracket here...
> - lpi_chunks = its_lpi_to_chunk(1UL << id_bits);
> + u32 nr_irq = 1UL << id_bits;
> + struct lpi_mng *lpi_free_mng = NULL;
> + struct lpi_mng *lpi_new = NULL;
> +
> + INIT_LIST_HEAD(&lpi_free_list);
> + INIT_LIST_HEAD(&lpi_alloc_list);
Why don't you use the LIST_HEAD() static initializer right at the top?
>
> - lpi_bitmap = kzalloc(BITS_TO_LONGS(lpi_chunks) * sizeof(long),
> - GFP_KERNEL);
> - if (!lpi_bitmap) {
> - lpi_chunks = 0;
> + lpi_free_mng = kzalloc(sizeof(struct lpi_mng), GFP_KERNEL);
> + if (!lpi_free_mng)
> return -ENOMEM;
> - }
>
> - pr_info("ITS: Allocated %d chunks for LPIs\n", (int)lpi_chunks);
> + lpi_free_mng->base = 0;
> + lpi_free_mng->len = nr_irq;
> + list_add(&lpi_free_mng->lpi_list, &lpi_free_list);
This looks wrong. LPIs start at 8192. Why is base 0 here?
> +
> + do {
> + lpi_free_mng = list_first_entry(&lpi_free_list, struct lpi_mng,
> + lpi_list);
> + if (lpi_free_mng->len == 8192) {
> + /*It is not lpi, so we delete */
> + if (lpi_free_mng->base == 0) {
> + list_del_init(&lpi_free_mng->lpi_list);
> + kfree(lpi_free_mng);
> + continue;
> + }
> + if (lpi_free_mng->base == 8192)
> + goto out;
> + }
> + if (lpi_free_mng->len > 8192) {
> + lpi_new = kzalloc(sizeof(struct lpi_mng),
> + GFP_ATOMIC);
> + if (!lpi_new)
> + return -ENOMEM;
> + lpi_free_mng->len /= 2;
> + lpi_new->base = lpi_free_mng->base + lpi_free_mng->len;
> + lpi_new->len = lpi_free_mng->len;
> + list_add(&lpi_new->lpi_list, &lpi_free_mng->lpi_list);
> + }
> + } while (1);
I'm really confused. What is this trying to achieve? Some kind of
power-of-two static allocation? Maybe you should try and describe what
this is doing in the commit message.
> +
> +out:
> + pr_info("ITS: Allocated %d LPIs\n", nr_irq - 8192);
> return 0;
> }
>
> +static struct lpi_mng *its_alloc_lpi(int nr_irqs) {
> + struct lpi_mng *lpi_alloc_mng = NULL;
> + struct lpi_mng *lpi_split = NULL;
> + struct lpi_mng *lpi_new = NULL;
> + int base;
> +
> + base = INT_MAX;
> + do {
> + list_for_each_entry(lpi_alloc_mng, &lpi_free_list, lpi_list) {
> + if (nr_irqs > lpi_alloc_mng->len)
> + continue;
> + if (nr_irqs == lpi_alloc_mng->len) {
> + list_del_init(&lpi_alloc_mng->lpi_list);
> + list_add(&lpi_alloc_mng->lpi_list,
> + &lpi_alloc_list);
> + return lpi_alloc_mng;
> + }
> + if ((nr_irqs < lpi_alloc_mng->len)
> + && (lpi_alloc_mng->base < base)) {
> + base = lpi_alloc_mng->base;
> + lpi_split = lpi_alloc_mng;
> + }
> + }
> + lpi_new = kzalloc(sizeof(struct lpi_mng),
> + GFP_ATOMIC);
> + if (!lpi_new || !lpi_split)
> + return NULL;
> +
> + lpi_split->len /= 2;
> + lpi_new->base = lpi_split->base + lpi_split->len;
> + lpi_new->len = lpi_split->len;
> + list_add(&lpi_new->lpi_list, &lpi_split->lpi_list);
> +
> + } while (1);
Again, your allocation policy seems at best obscure. You need to
explain what you're trying to do.
> +}
> +
> static unsigned long *its_lpi_alloc_chunks(int nr_irqs, int *base, int *nr_ids) {
> unsigned long *bitmap = NULL;
> - int chunk_id;
> - int nr_chunks;
> - int i;
> -
> - nr_chunks = DIV_ROUND_UP(nr_irqs, IRQS_PER_CHUNK);
> + struct lpi_mng *lpi_alloc_mng = NULL;
>
> spin_lock(&lpi_lock);
>
> - do {
> - chunk_id = bitmap_find_next_zero_area(lpi_bitmap, lpi_chunks,
> - 0, nr_chunks, 0);
> - if (chunk_id < lpi_chunks)
> - break;
> -
> - nr_chunks--;
> - } while (nr_chunks > 0);
> + lpi_alloc_mng = its_alloc_lpi(nr_irqs);
>
> - if (!nr_chunks)
> + if (!lpi_alloc_mng)
> goto out;
>
> - bitmap = kzalloc(BITS_TO_LONGS(nr_chunks * IRQS_PER_CHUNK) * sizeof (long),
> - GFP_ATOMIC);
> + bitmap = kzalloc(BITS_TO_LONGS(nr_irqs) * sizeof(long),
> + GFP_ATOMIC);
> if (!bitmap)
> goto out;
>
> - for (i = 0; i < nr_chunks; i++)
> - set_bit(chunk_id + i, lpi_bitmap);
>
> - *base = its_chunk_to_lpi(chunk_id);
> - *nr_ids = nr_chunks * IRQS_PER_CHUNK;
> + *base = lpi_alloc_mng->base;
> + *nr_ids = lpi_alloc_mng->len;
>
> out:
> spin_unlock(&lpi_lock);
> @@ -1491,23 +1531,53 @@ static unsigned long *its_lpi_alloc_chunks(int nr_irqs, int *base, int *nr_ids)
> return bitmap;
> }
>
> +static void its_joint_free_list(struct lpi_mng *free, struct lpi_mng
> +*alloc) {
> + free->len = free->len * 2;
> + if (free->base > alloc->base)
> + free->base = alloc->base;
> +}
> +
> static void its_lpi_free_chunks(unsigned long *bitmap, int base, int nr_ids) {
> - int lpi;
> + struct lpi_mng *lpi_alloc_mng = NULL;
> + struct lpi_mng *lpi_free_mng = NULL;
> + bool first_half;
> + int pair_base;
>
> spin_lock(&lpi_lock);
>
> - for (lpi = base; lpi < (base + nr_ids); lpi += IRQS_PER_CHUNK) {
> - int chunk = its_lpi_to_chunk(lpi);
> -
> - BUG_ON(chunk > lpi_chunks);
> - if (test_bit(chunk, lpi_bitmap)) {
> - clear_bit(chunk, lpi_bitmap);
> - } else {
> - pr_err("Bad LPI chunk %d\n", chunk);
> + list_for_each_entry(lpi_alloc_mng, &lpi_alloc_list, lpi_list) {
> + if (lpi_alloc_mng->base == base) {
> + list_del_init(&lpi_alloc_mng->lpi_list);
> + break;
> }
> }
>
> + first_half = (lpi_alloc_mng->base % (lpi_alloc_mng->len * 2))
> + ? false : true;
> + if (first_half)
> + pair_base = lpi_alloc_mng->base + lpi_alloc_mng->len;
> + else
> + pair_base = lpi_alloc_mng->base - lpi_alloc_mng->len;
> +
> + // found the other half
> + list_for_each_entry(lpi_free_mng, &lpi_free_list, lpi_list) {
> + if (lpi_free_mng->base == pair_base) {
> + its_joint_free_list(lpi_free_mng, lpi_alloc_mng);
> + kfree(lpi_alloc_mng);
> + goto out;
> + }
> + }
> + // Not found the other half
> + list_for_each_entry(lpi_free_mng, &lpi_free_list, lpi_list) {
> + if (lpi_alloc_mng->base < lpi_free_mng->base) {
> + list_add_tail(&lpi_alloc_mng->lpi_list,
> + &lpi_free_mng->lpi_list);
> + break;
> + }
> + }
> +out:
> spin_unlock(&lpi_lock);
>
> kfree(bitmap);
> @@ -2117,12 +2187,13 @@ static struct its_device *its_create_device(struct its_node *its, u32 dev_id,
> * We allocate at least one chunk worth of LPIs bet device,
> * and thus that many ITEs. The device may require less though.
> */
> - nr_ites = max(IRQS_PER_CHUNK, roundup_pow_of_two(nvecs));
> + nr_ites = max(2UL, roundup_pow_of_two(nvecs));
> sz = nr_ites * its->ite_size;
> sz = max(sz, ITS_ITT_ALIGN) + ITS_ITT_ALIGN - 1;
> itt = kzalloc(sz, GFP_KERNEL);
> if (alloc_lpis) {
> - lpi_map = its_lpi_alloc_chunks(nvecs, &lpi_base, &nr_lpis);
> + lpi_map = its_lpi_alloc_chunks(roundup_pow_of_two(nvecs),
> + &lpi_base, &nr_lpis);
> if (lpi_map)
> col_map = kzalloc(sizeof(*col_map) * nr_lpis,
> GFP_KERNEL);
Overall, this feels way more complex than it should be. The
requirements you impose are too restrictive, you seem to track data
that doesn't need extra tracking, and the complexity seem to be
stemming from that.
I've just prototyped what I had in mind for this at [1] (see the first
patch for the allocator itself). As you can see, the allocator is a
lot simpler, yet it has all the flexibility you would need, The
drawback is of course that freeing LPIs is quite expensive, but that
almost never happens. And if it does, we can switch to a tree or some
more efficient data structure.
Thanks,
M.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/log/?h=irq/lpi-allocator
--
Jazz is not dead, it just smell funny.
^ permalink raw reply
* [PATCH 1/3] ARM: dts: imx6 wandboard and riotboard: remove regulators bus node
From: Fabio Estevam @ 2018-05-27 16:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180526183053.14029-2-akurz@blala.de>
Hi Alexander,
[It would be better to split this patch in two: one for wandboard and
another one for riotboard]
On Sat, May 26, 2018 at 3:30 PM, Alexander Kurz <akurz@blala.de> wrote:
> +
> + reg_2p5v: fixedregulator at 0 {
This causes dtc warnings with W=1 as you are passing a unit address
without a corresponding reg property.
You can rewrite this as:
reg_2p5v: regulator-2p5v {
Please follow this convention in the entire series.
Thanks
^ permalink raw reply
* [PATCH 2/2] ARM: OMAP1: ams-delta: assign LED GPIO numbers from descriptors
From: Janusz Krzysztofik @ 2018-05-27 13:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180527135548.7904-1-jmkrzyszt@gmail.com>
Assign a label to latch1 GPIO device the LEDs hang off, enumerate its
pins for the purpose of indexing gpio_led table, remove hardcoded GPIO
numbers from that table replacing them with invalid GPIO numbers and
remove initialization of incompletely described LED device from
machine_init.
As soon as the latch1 GPIO device is registered, use its label to find
respective GPIO chip, identify each LED's GPIO descriptor by its pin
number and assign its gobal GPIO number to the gpio_led table. Once
completed, register the LED device.
Created and tested against linux-v4.17-rc3.
Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com>
---
arch/arm/mach-omap1/board-ams-delta.c | 116 ++++++++++++++++++++++++++++------
1 file changed, 98 insertions(+), 18 deletions(-)
diff --git a/arch/arm/mach-omap1/board-ams-delta.c b/arch/arm/mach-omap1/board-ams-delta.c
index cdba8decc532..d4b26352ddde 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -179,7 +179,10 @@ static struct resource latch1_resources[] = {
},
};
+#define LATCH1_LABEL "latch1"
+
static struct bgpio_pdata latch1_pdata = {
+ .label = LATCH1_LABEL,
.base = LATCH1_GPIO_BASE,
.ngpio = LATCH1_NGPIO,
};
@@ -194,6 +197,15 @@ static struct platform_device latch1_gpio_device = {
},
};
+#define LATCH1_PIN_LED_CAMERA 0
+#define LATCH1_PIN_LED_ADVERT 1
+#define LATCH1_PIN_LED_MAIL 2
+#define LATCH1_PIN_LED_HANDSFREE 3
+#define LATCH1_PIN_LED_VOICEMAIL 4
+#define LATCH1_PIN_LED_VOICE 5
+#define LATCH1_PIN_DOCKIT1 6
+#define LATCH1_PIN_DOCKIT2 7
+
static struct resource latch2_resources[] = {
[0] = {
.name = "dat",
@@ -398,38 +410,43 @@ static struct gpiod_lookup_table ams_delta_lcd_gpio_table = {
},
};
-static const struct gpio_led gpio_leds[] __initconst = {
- {
+/*
+ * Dynamically allocated GPIO numbers must be obtained fromm GPIO device
+ * before they can be put in the gpio_led table. Before that happens,
+ * initialize the table with invalid GPIO numbers, not 0.
+ */
+static struct gpio_led gpio_leds[] __initdata = {
+ [LATCH1_PIN_LED_CAMERA] = {
.name = "camera",
- .gpio = LATCH1_GPIO_BASE + 0,
+ .gpio = -EINVAL,
.default_state = LEDS_GPIO_DEFSTATE_OFF,
#ifdef CONFIG_LEDS_TRIGGERS
.default_trigger = "ams_delta_camera",
#endif
},
- {
+ [LATCH1_PIN_LED_ADVERT] = {
.name = "advert",
- .gpio = LATCH1_GPIO_BASE + 1,
+ .gpio = -EINVAL,
.default_state = LEDS_GPIO_DEFSTATE_OFF,
},
- {
+ [LATCH1_PIN_LED_MAIL] = {
.name = "email",
- .gpio = LATCH1_GPIO_BASE + 2,
+ .gpio = -EINVAL,
.default_state = LEDS_GPIO_DEFSTATE_OFF,
},
- {
+ [LATCH1_PIN_LED_HANDSFREE] = {
.name = "handsfree",
- .gpio = LATCH1_GPIO_BASE + 3,
+ .gpio = -EINVAL,
.default_state = LEDS_GPIO_DEFSTATE_OFF,
},
- {
+ [LATCH1_PIN_LED_VOICEMAIL] = {
.name = "voicemail",
- .gpio = LATCH1_GPIO_BASE + 4,
+ .gpio = -EINVAL,
.default_state = LEDS_GPIO_DEFSTATE_OFF,
},
- {
+ [LATCH1_PIN_LED_VOICE] = {
.name = "voice",
- .gpio = LATCH1_GPIO_BASE + 5,
+ .gpio = -EINVAL,
.default_state = LEDS_GPIO_DEFSTATE_OFF,
},
};
@@ -542,6 +559,22 @@ static struct gpiod_lookup_table *late_gpio_tables[] __initdata = {
&ams_delta_nand_gpio_table,
};
+/*
+ * Some drivers may not use GPIO lookup tables but need to be provided
+ * with GPIO numbers. The same applies to GPIO based IRQ lines - some
+ * drivers may even not use GPIO layer but expect just IRQ numbers.
+ * We could either define GPIO lookup tables then use them on behalf
+ * of those devices, or we can use GPIO driver level methods for
+ * identification of GPIO and IRQ numbers. For the purpose of the latter,
+ * defina a helper function which identifies GPIO chips by their labels.
+ */
+static int gpiochip_match_by_label(struct gpio_chip *chip, void *data)
+{
+ char *label = data;
+
+ return !strcmp(label, chip->label);
+}
+
static void __init ams_delta_init(void)
{
/* mux pins for uarts */
@@ -571,7 +604,6 @@ static void __init ams_delta_init(void)
led_trigger_register_simple("ams_delta_camera",
&ams_delta_camera_led_trigger);
#endif
- gpio_led_register_device(-1, &leds_pdata);
platform_add_devices(ams_delta_devices, ARRAY_SIZE(ams_delta_devices));
/*
@@ -643,16 +675,68 @@ static struct platform_device ams_delta_modem_device = {
},
};
+/*
+ * leds-gpio driver doesn't make use of GPIO lookup tables,
+ * it has to be provided with GPIO numbers over platform data
+ * if GPIO descriptor info can't be obtained from device tree.
+ * We could either define GPIO lookup tables and use them on behalf
+ * of the leds-gpio device, or we can use GPIO driver level methods
+ * for identification of GPIO numbers as long as we don't support
+ * device tree. Let's do the latter.
+ */
+static void __init ams_delta_led_init(struct gpio_chip *chip)
+{
+ struct gpio_desc *gpiod;
+ int i;
+
+ for (i = LATCH1_PIN_LED_CAMERA; i < LATCH1_PIN_DOCKIT1; i++) {
+ gpiod = gpiochip_request_own_desc(chip, i, NULL);
+ if (IS_ERR(gpiod)) {
+ pr_warn("%s: %s GPIO %d request failed (%ld)\n",
+ __func__, LATCH1_LABEL, i, PTR_ERR(gpiod));
+ continue;
+ }
+
+ /* Assign GPIO numbers to LED device. */
+ gpio_leds[i].gpio = desc_to_gpio(gpiod);
+
+ gpiochip_free_own_desc(gpiod);
+ }
+
+ gpio_led_register_device(PLATFORM_DEVID_NONE, &leds_pdata);
+}
+
+/*
+ * The purpose of this function is to take care of assignment of GPIO numbers
+ * to platform devices which depend on GPIO lines provided by Amstrad Delta
+ * latch1 and/or latch2 GPIO devices but don't use GPIO lookup tables.
+ * The function may be called as soon as latch1/latch2 GPIO devices are
+ * initilized. Since basic-mmio-gpio driver is not registered before
+ * device_initcall, this may happen@erliest during device_initcall_sync.
+ * Dependent devices shouldn't be registered before that, their
+ * registration may be performed from within this function or later.
+ */
static int __init ams_delta_gpio_init(void)
{
+ struct gpio_chip *chip;
int err;
+ if (!machine_is_ams_delta())
+ return -ENODEV;
+
+ chip = gpiochip_find(LATCH1_LABEL, gpiochip_match_by_label);
+ if (!chip)
+ pr_err("%s: latch1 GPIO chip not found\n", __func__);
+ else
+ ams_delta_led_init(chip);
+
err = gpio_request_array(latch_gpios, ARRAY_SIZE(latch_gpios));
if (err)
pr_err("Couldn't take over latch1/latch2 GPIO pins\n");
return err;
}
+device_initcall_sync(ams_delta_gpio_init);
static void __init ams_delta_late_devices(void)
{
@@ -712,10 +796,6 @@ static int __init late_init(void)
{
int err;
- err = ams_delta_gpio_init();
- if (err)
- return err;
-
ams_delta_late_devices();
err = modem_nreset_init();
--
2.16.1
^ permalink raw reply related
* [PATCH 1/2] ARM: OMAP1: ams-delta: refactor late_init()
From: Janusz Krzysztofik @ 2018-05-27 13:55 UTC (permalink / raw)
To: linux-arm-kernel
Before the board level GPIO handling is converted from GPIO numbers to
GPIO descriptors, split late_init() into functional blocks and move
them to separate functions.
While being at it, drop machine type check from late_init() - the
function is now called from the board init_late callback so there is
no need for yet another applicability check.
Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com>
---
arch/arm/mach-omap1/board-ams-delta.c | 55 +++++++++++++++++++++++++++--------
1 file changed, 43 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap1/board-ams-delta.c b/arch/arm/mach-omap1/board-ams-delta.c
index 80f54cb54276..cdba8decc532 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -643,19 +643,19 @@ static struct platform_device ams_delta_modem_device = {
},
};
-static int __init late_init(void)
+static int __init ams_delta_gpio_init(void)
{
int err;
- if (!machine_is_ams_delta())
- return -ENODEV;
-
err = gpio_request_array(latch_gpios, ARRAY_SIZE(latch_gpios));
- if (err) {
+ if (err)
pr_err("Couldn't take over latch1/latch2 GPIO pins\n");
- return err;
- }
+ return err;
+}
+
+static void __init ams_delta_late_devices(void)
+{
platform_add_devices(late_devices, ARRAY_SIZE(late_devices));
/*
@@ -666,12 +666,23 @@ static int __init late_init(void)
ams_delta_nand_gpio_table.dev_id = dev_name(&ams_delta_nand_device.dev);
gpiod_add_lookup_tables(late_gpio_tables, ARRAY_SIZE(late_gpio_tables));
+}
+
+static int __init modem_nreset_init(void)
+{
+ int err;
err = platform_device_register(&modem_nreset_device);
- if (err) {
+ if (err)
pr_err("Couldn't register the modem regulator device\n");
- return err;
- }
+
+ return err;
+}
+
+
+static int __init ams_delta_modem_init(void)
+{
+ int err;
omap_cfg_reg(M14_1510_GPIO2);
ams_delta_modem_ports[0].irq =
@@ -692,7 +703,28 @@ static int __init late_init(void)
err = platform_device_register(&ams_delta_modem_device);
if (err)
- goto gpio_free;
+ gpio_free(AMS_DELTA_GPIO_PIN_MODEM_IRQ);
+
+ return err;
+}
+
+static int __init late_init(void)
+{
+ int err;
+
+ err = ams_delta_gpio_init();
+ if (err)
+ return err;
+
+ ams_delta_late_devices();
+
+ err = modem_nreset_init();
+ if (err)
+ return err;
+
+ err = ams_delta_modem_init();
+ if (err)
+ return err;
/*
* Once the modem device is registered, the modem_nreset
@@ -708,7 +740,6 @@ static int __init late_init(void)
unregister:
platform_device_unregister(&ams_delta_modem_device);
-gpio_free:
gpio_free(AMS_DELTA_GPIO_PIN_MODEM_IRQ);
return err;
}
--
2.16.1
^ permalink raw reply related
* [PATCH] PM / runtime: Drop usage count for suppliers at device link removal
From: Rafael J. Wysocki @ 2018-05-27 10:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527150816-8459-1-git-send-email-ulf.hansson@linaro.org>
On Thu, May 24, 2018 at 10:33 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> In the case consumer device is runtime resumed, while the link to the
> supplier is removed, the earlier call to pm_runtime_get_sync() made from
> rpm_get_suppliers() does not get properly balanced with a corresponding
> call to pm_runtime_put(). This leads to that suppliers remains to be
> runtime resumed forever, while they don't need to.
>
> Let's fix the behaviour by calling rpm_put_suppliers() when dropping a
> device link. Not that, since rpm_put_suppliers() checks the
> link->rpm_active flag, we can correctly avoid to call pm_runtime_put() in
> cases when we shouldn't.
>
> Reported-by: Todor Tomov <todor.tomov@linaro.org>
> Fixes: 21d5c57b3726 ("PM / runtime: Use device links")
> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
> ---
>
> Rafael, I am not sure if this is safe from locking point of view. The device
> link write lock has been taken when pm_runtime_drop_link() is called, hence I
> assume calling rpm_put_suppliers() should be fine!? If not, can you please
> advise how to change?
Holding the lock should be sufficient for the list to be stable, so
AFAICS it is OK.
Thanks,
Rafael
^ permalink raw reply
* [PATCH] mtd: nand: raw: atmel: add module param to avoid using dma
From: Peter Rosin @ 2018-05-27 9:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a25ca617-d3da-d401-1ba9-8e5887f8a8e5@microchip.com>
On 2018-05-25 16:51, Tudor Ambarus wrote:
> We think the best way is to keep LCD on DDR Ports 2 and 3 (8th and 9th
> slaves), to have maximum bandwidth and to use DMA on DDR port 1 for NAND
> (7th slave).
Exactly how do I accomplish that?
I can see how I can move the LCD between slave DDR port 2 and 3 by
selecting LCDC DMA master 8 or 9 (but according to the above it should
not matter). The big question is how I control what slave the NAND flash
is going to use? I find nothing in the datasheet, and the code is also
non-transparent enough for me to figure it out by myself without
throwing out this question first...
Cheers,
Peter
^ permalink raw reply
* [xlnx:master 1383/1656] drivers//dma/xgene-dma.c:459:3: error: implicit declaration of function 'xgene_dma_invalidate_buffer'; did you mean 'xgene_dma_set_src_buffer'?
From: kbuild test robot @ 2018-05-27 7:58 UTC (permalink / raw)
To: linux-arm-kernel
Hi Michal,
FYI, the error/warning still remains.
tree: https://github.com/Xilinx/linux-xlnx master
head: e648c3b74f7fdcd52b406d51560ede1f93e84ef1
commit: d1797ba7285165859c754c6ff22fd77b7c74c0e6 [1383/1656] Revert "dmaengine: remove DMA_SG as it is dead code in kernel"
config: i386-allyesconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
git checkout d1797ba7285165859c754c6ff22fd77b7c74c0e6
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
drivers//dma/xgene-dma.c: In function 'xgene_dma_prep_cpy_desc':
>> drivers//dma/xgene-dma.c:459:3: error: implicit declaration of function 'xgene_dma_invalidate_buffer'; did you mean 'xgene_dma_set_src_buffer'? [-Werror=implicit-function-declaration]
xgene_dma_invalidate_buffer(xgene_dma_lookup_ext8(desc2, i));
^~~~~~~~~~~~~~~~~~~~~~~~~~~
xgene_dma_set_src_buffer
cc1: some warnings being treated as errors
vim +459 drivers//dma/xgene-dma.c
422
423 static void xgene_dma_prep_cpy_desc(struct xgene_dma_chan *chan,
424 struct xgene_dma_desc_sw *desc_sw,
425 dma_addr_t dst, dma_addr_t src,
426 size_t len)
427 {
428 struct xgene_dma_desc_hw *desc1, *desc2;
429 int i;
430
431 /* Get 1st descriptor */
432 desc1 = &desc_sw->desc1;
433 xgene_dma_init_desc(desc1, chan->tx_ring.dst_ring_num);
434
435 /* Set destination address */
436 desc1->m2 |= cpu_to_le64(XGENE_DMA_DESC_DR_BIT);
437 desc1->m3 |= cpu_to_le64(dst);
438
439 /* Set 1st source address */
440 xgene_dma_set_src_buffer(&desc1->m1, &len, &src);
441
442 if (!len)
443 return;
444
445 /*
446 * We need to split this source buffer,
447 * and need to use 2nd descriptor
448 */
449 desc2 = &desc_sw->desc2;
450 desc1->m0 |= cpu_to_le64(XGENE_DMA_DESC_NV_BIT);
451
452 /* Set 2nd to 5th source address */
453 for (i = 0; i < 4 && len; i++)
454 xgene_dma_set_src_buffer(xgene_dma_lookup_ext8(desc2, i),
455 &len, &src);
456
457 /* Invalidate unused source address field */
458 for (; i < 4; i++)
> 459 xgene_dma_invalidate_buffer(xgene_dma_lookup_ext8(desc2, i));
460
461 /* Updated flag that we have prepared 64B descriptor */
462 desc_sw->flags |= XGENE_DMA_FLAG_64B_DESC;
463 }
464
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 61331 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180527/d3a3ea18/attachment-0001.gz>
^ permalink raw reply
* [GIT PULL] Allwinner core changes for 4.18
From: Chen-Yu Tsai @ 2018-05-27 5:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOesGMhf3Xnut4Me2KSpcb5Qd=JfmB0xfcz5XKO6U36DdRTKLQ@mail.gmail.com>
On Sat, May 26, 2018 at 11:21 AM, Olof Johansson <olof@lixom.net> wrote:
> On Sat, May 26, 2018 at 6:22 PM, Chen-Yu Tsai <wens@csie.org> wrote:
>> On Fri, May 25, 2018 at 2:02 PM, Olof Johansson <olof@lixom.net> wrote:
>>> On Mon, May 21, 2018 at 01:41:56PM +0200, Maxime Ripard wrote:
>>>> Hi,
>>>>
>>>> Here is our mach-sunxi changes for the next merge window, thanks!
>>>> Maxime
>>>>
>>>> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>>>>
>>>> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>>>>
>>>> are available in the Git repository at:
>>>>
>>>> https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git tags/sunxi-core-for-4.18
>>>>
>>>> for you to fetch changes up to 6961275e72a8c15cc4ebf108a81eee758480a6a2:
>>>>
>>>> ARM: sun8i: smp: Add support for A83T (2018-05-08 15:00:20 +0200)
>>>>
>>>> ----------------------------------------------------------------
>>>> Allwinner core changes for 4.18
>>>>
>>>> The A83t, unlike the other Allwinner SoCs, cannot use PSCI because of a
>>>> silicon bug. As such, we needed to have some smp_ops in order to bringup
>>>> the various cores (and clusters) found on this SoC.
>>>
>>> Hrm. that's unfortunate. Is there any public documentation of what the bug is?
>>
>> The security extensions in the A80 and A83T is not entirely enabled.
>> The security bit is not forwarded on to the bus, so all accesses from
>> non-secure become secure. This is not documented, but was the result
>> of some tests I did.
>>
>> See https://lists.denx.de/pipermail/u-boot/2017-June/294672.html
>> for a summary (in the quotes) of what we think is the issue.
>>
>> Marc's suggestion is that if virtualization doesn't work on it, then
>> there's no point in running it non-secure. [1]
>
> So it sounds like you can still use PSCI even if there's nothing that
> stops the kernel from also doing the same operations. It doesn't buy
> you any security benefits, but you can use the same standard
> interfaces as everybody else does. I think there's still value in
> that. Or am I missing some aspect of the errata implications?
IIRC the GIC does not work correctly. Interrupts are configured to be
non-secure by the PSCI implementation, prior to entering the kernel.
The GIC driver uses the standard registers to program or ack interrupts.
But since non-secure accesses appear to be secure outside the ARM
cores, it ends up touching the wrong set of registers. The driver
needs to be taught to use the NS alias registers. But then, how does
one confer the need for such a workaround? I actually did some patches
that work for the A80, just to test things out.
I asked Marc (CC-ed) for some input, and basically he said it's probably
not worth the headache and trouble.
ChenYu
^ permalink raw reply
* [GIT PULL] Renesas ARM Based SoC Updates for v4.18
From: Olof Johansson @ 2018-05-26 21:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1526639075.git.horms+renesas@verge.net.au>
On Fri, May 18, 2018 at 01:18:11PM +0200, Simon Horman wrote:
> Hi Olof, Hi Kevin, Hi Arnd,
>
> Please consider these Renesas ARM based SoC updates for v4.18.
>
>
> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>
> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>
> are available in the git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-soc-for-v4.18
>
> for you to fetch changes up to 086b399965a7ee7e50c3b3c57f2dba30ff0334b0:
>
> soc: renesas: r8a77990-sysc: Add workaround for 3DG-{A,B} (2018-05-16 10:57:44 +0200)
Merged, thanks.
-Olof
^ permalink raw reply
* [GIT PULL] Renesas ARM64 Based SoC DT Updates for v4.18
From: Olof Johansson @ 2018-05-26 21:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1526637994.git.horms+renesas@verge.net.au>
Hi Simon,
On Fri, May 18, 2018 at 01:16:00PM +0200, Simon Horman wrote:
> Hi Olof, Hi Kevin, Hi Arnd,
>
> Please consider these Renesas ARM64 based SoC DT updates for v4.18.
>
>
> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>
> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>
> are available in the git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-arm64-dt-for-v4.18
>
> for you to fetch changes up to 908001d778eba06ee1d832863d4e9a1e2cfd4746:
>
> arm64: dts: renesas: salvator-common: Add ADV7482 support (2018-05-18 11:52:03 +0200)
This pull request is really, really hard for us to digest. The tag
description is very large, and it repeats several SoCs several times,
making it hard to get an overview of what is in it. The verbosity of "<x>
says.." makes it harder on this size of a pull request as well.
For example:
> * Condor board with R-Car V3H (r8a77980) SoC
> - Enable eMMC
>
> Sergei Shtylyov says "We're adding the R8A77980 MMC (SDHI)
> device nodes and then enable eMMC support on the Condor board."
The "Enable eMMC" line is just fine here.
> ----------------------------------------------------------------
> Geert Uytterhoeven (11):
> arm64: dts: renesas: draak: Rename EtherAVB "mdc" pin group to "mdio"
> arm64: dts: renesas: salvator-common: Rename EtherAVB "mdc" pin group to "mdio"
> arm64: dts: renesas: ulcb: Rename EtherAVB "mdc" pin group to "mdio"
Why can't these be done in one commit?
> arm64: dts: renesas: r8a7795: Correct whitespace
> arm64: dts: renesas: r8a7796: Correct whitespace
> arm64: dts: renesas: r8a77965: Correct whitespace
Do these really need to be three commits to fix some whitespace?
> arm64: dts: renesas: ulcb: Add BD9571 PMIC
> arm64: dts: renesas: salvator-common: Add PMIC DDR Backup Power config
> arm64: dts: renesas: ulcb: Add PMIC DDR Backup Power config
> arm64: dts: renesas: r8a77970: Add secondary CA53 CPU core
> arm64: dts: renesas: r8a77970: Add Cortex-A53 PMU node
Why can't these be done in the same commit?
> Kieran Bingham (7):
> arm64: dts: renesas: r8a77965: Add FCPF and FCPV instances
> arm64: dts: renesas: r8a77965: Add VSP instances
> arm64: dts: renesas: r8a77965: Populate the DU instance placeholder
> arm64: dts: renesas: r8a77965: Add HDMI encoder instance
> arm64: dts: renesas: r8a77965-salvator-x: Enable DU external clocks and HDMI
> arm64: dts: renesas: r8a77965-salvator-xs: Enable DU external clocks and HDMI
These two can probably be in one commit as well.
> arm64: dts: renesas: salvator-common: Add ADV7482 support
>
> Kuninori Morimoto (8):
> arm64: dts: renesas: r8a7795: add HDMI sound support
> arm64: dts: renesas: r8a7796: add HDMI sound support
... starting to see a trend?
> arm64: dts: renesas: salvator-common: use audio-graph-card for Sound
> arm64: dts: renesas: r8a7795-es1-salvator-x: enable HDMI sound
> arm64: dts: renesas: r8a7795-salvator-xs: enable HDMI sound
> arm64: dts: renesas: r8a7796-salvator-xs: enable HDMI sound
> arm64: dts: renesas: r8a7795-salvator-x: enable HDMI sound
> arm64: dts: renesas: r8a7796-salvator-x: enable HDMI sound
... and more.
>
> Magnus Damm (5):
> arm64: dts: renesas: r8a77970: Update IPMMU DS1 bit number
> arm64: dts: renesas: r8a7795: Enable IPMMU devices
> arm64: dts: renesas: r8a7796: Enable IPMMU devices
> arm64: dts: renesas: r8a77970: Enable IPMMU devices
> arm64: dts: renesas: r8a77995: Enable IPMMU devices
I think these 4 could be in one commit too.
>
> Niklas S?derlund (11):
> arm64: dts: renesas: r8a7795: decrease temperature hysteresis
> arm64: dts: renesas: r8a7796: decrease temperature hysteresis
> arm64: dts: renesas: r8a77965: use r8a77965-sysc binding definitions
> arm64: dts: renesas: r8a77965: Add R-Car Gen3 thermal support
> arm64: dts: renesas: r8a77965: add I2C support
> arm64: dts: renesas: r8a7795: add VIN and CSI-2 nodes
> arm64: dts: renesas: r8a7795-es1: add CSI-2 node
> arm64: dts: renesas: r8a7796: add VIN and CSI-2 nodes
> arm64: dts: renesas: r8a77965: add VIN and CSI-2 nodes
> arm64: dts: renesas: r8a77970: add VIN and CSI-2 nodes
.... etc, etc. I'll stop here.
I haven't merged this branch yet, will need to set aside more time to review
the contents. I can't guarantee that it'll make v4.18 but I'll try.
-Olof
^ permalink raw reply
* [GIT PULL] ARM: SoC fixes
From: Olof Johansson @ 2018-05-26 21:01 UTC (permalink / raw)
To: linux-arm-kernel
Hi Linus,
Please merge. Thanks!
-Olof
The following changes since commit 771c577c23bac90597c685971d7297ea00f99d11:
Linux 4.17-rc6 (2018-05-20 15:31:38 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/armsoc-fixes
for you to fetch changes up to e5dd61546a777d19d4fe35e2d0a2b664ca49f6b2:
Merge tag 'hisi-fixes-for-4.17v2' of git://github.com/hisilicon/linux-hisi into fixes (2018-05-26 12:12:44 -0700)
----------------------------------------------------------------
ARM: SoC fixes for 4.17-rc
A few more fixes for v4.17:
- A fix for a crash in scm_call_atomic on qcom platforms
- Display fix for Allwinner A10
- A fix that re-enables ethernet on Allwinner H3 (C.H.I.P et al)
- A fix for eMMC corruption on hikey
- i2c-gpio descriptor tables for ixp4xx
+ a small typo fix
----------------------------------------------------------------
Chen-Yu Tsai (1):
ARM: dts: sun8i: h3: Re-enable EMAC on Orange Pi One
Colin Ian King (1):
ARM: sun8i: v3s: fix spelling mistake: "disbaled" -> "disabled"
John Stultz (1):
arm64: dts: hikey: Fix eMMC corruption regression
Linus Walleij (1):
ARM: Fix i2c-gpio GPIO descriptor tables
Niklas Cassel (1):
firmware: qcom: scm: Fix crash in qcom_scm_call_atomic1()
Olof Johansson (3):
Merge tag 'sunxi-fixes-for-4.17' of https://git.kernel.org/.../sunxi/linux into fixes
Merge tag 'qcom-fixes-for-4.17-rc7' of git://git.kernel.org/.../agross/linux into fixes
Merge tag 'hisi-fixes-for-4.17v2' of git://github.com/hisilicon/linux-hisi into fixes
Pascal Roeleven (1):
ARM: dts: sun4i: Fix incorrect clocks for displays
arch/arm/boot/dts/sun4i-a10.dtsi | 6 +++---
arch/arm/boot/dts/sun8i-h3-orangepi-one.dts | 1 +
arch/arm/boot/dts/sun8i-v3s-licheepi-zero-dock.dts | 2 +-
arch/arm/mach-ep93xx/core.c | 2 +-
arch/arm/mach-ixp4xx/avila-setup.c | 2 +-
arch/arm/mach-ixp4xx/dsmg600-setup.c | 2 +-
arch/arm/mach-ixp4xx/fsg-setup.c | 2 +-
arch/arm/mach-ixp4xx/ixdp425-setup.c | 2 +-
arch/arm/mach-ixp4xx/nas100d-setup.c | 2 +-
arch/arm/mach-ixp4xx/nslu2-setup.c | 2 +-
arch/arm/mach-pxa/palmz72.c | 2 +-
arch/arm/mach-pxa/viper.c | 4 ++--
arch/arm/mach-sa1100/simpad.c | 2 +-
arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 1 -
drivers/firmware/qcom_scm-32.c | 8 ++++----
15 files changed, 20 insertions(+), 20 deletions(-)
^ permalink raw reply
* [GIT PULL] Renesas ARM Based SoC DT Bindings Updates for v4.18
From: Olof Johansson @ 2018-05-26 19:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1526549153.git.horms+renesas@verge.net.au>
On Fri, May 18, 2018 at 01:16:44PM +0200, Simon Horman wrote:
> Hi Olof, Hi Kevin, Hi Arnd,
>
> Please consider these Renesas ARM based SoC DT bindings updates for v4.18.
>
>
> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>
> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>
> are available in the git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-dt-bindings-for-v4.18
>
> for you to fetch changes up to c92db4a4a4c6c176c34604e456d6d355803d9ada:
>
> dt-bindings: arm: document Renesas V3HSK board bindings (2018-05-15 09:17:45 +0200)
>
> ----------------------------------------------------------------
> Renesas ARM Based SoC DT Bindings Updates for v4.18
>
> Document bindings for:
>
> * V3H Starter Kit, a board used with the R-Car V3H (r8a77980) SoC
> * R-Car E3 (R8A77990) SoC and its Ebisu board
> * iWave Systems RZ/G1C Single Board Computer (iW-RainboW-G23S)
> which uses an RZ/G1C (R8A77470) SoC
> * RZ/G1M (R8A7743) and RZ/G1N (R8A7744) CMT support
>
> Cleanup:
> * Consistently name r8a77965 as R-Car M3-N
>
> ----------------------------------------------------------------
> Biju Das (1):
> dt-bindings: arm: Document iW-RainboW-G23S single board computer
>
> Fabrizio Castro (1):
> dt-bindings: timer: renesas, cmt: Document r8a774[35] CMT support
>
> Sergei Shtylyov (1):
> dt-bindings: arm: document Renesas V3HSK board bindings
>
> Simon Horman (1):
> dt-bindings: arm: consistently name r8a77965 as M3-N
>
> Yoshihiro Shimoda (2):
> dt-bindings: arm: Document R-Car E3 SoC DT bindings
> dt-bindings: arm: Document Renesas Ebisu board DT bindings
>
> Documentation/devicetree/bindings/arm/shmobile.txt | 10 +++++++++-
> Documentation/devicetree/bindings/timer/renesas,cmt.txt | 14 ++++++++++----
> 2 files changed, 19 insertions(+), 5 deletions(-)
Merged, thanks.
-Olof
^ 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