* [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 1/3] arm64:add missing CONFIG_STRICT_KERNEL_RWX for mark_rodata_ro
From: nixiaoming @ 2018-05-28 3:33 UTC (permalink / raw)
To: linux-arm-kernel
Signed-off-by: nixiaoming <nixiaoming@huawei.com>
---
arch/arm64/mm/mmu.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 2dbb2c9..849f326 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -491,6 +491,7 @@ static void __init map_mem(pgd_t *pgdp)
#endif
}
+#ifdef CONFIG_STRICT_KERNEL_RWX
void mark_rodata_ro(void)
{
unsigned long section_size;
@@ -505,6 +506,7 @@ void mark_rodata_ro(void)
debug_checkwx();
}
+#endif
static void __init map_kernel_segment(pgd_t *pgdp, void *va_start, void *va_end,
pgprot_t prot, struct vm_struct *vma,
--
2.10.1
^ permalink raw reply related
* [PATCH v2 2/5] gpio: syscon: Add gpio-syscon for rockchip
From: Levin @ 2018-05-28 3:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2373122.g04ZbCo5Dh@phil>
On 2018-05-24 8:18 PM, Heiko Stuebner wrote:
> Hi Levin,
>
> Am Donnerstag, 24. Mai 2018, 03:59:36 CEST schrieb Levin Du:
>> Hi all, I'd like to quote reply of Robin Murphy at
>> http://lists.infradead.org/pipermail/linux-rockchip/2018-May/020619.html
>>
>>> I would suggest s/pin number/bit number in the associated GRF register/
>>> here. At least in this RK3328 case there's only one pin, which isn't
>>> numbered, and if you naively considered it pin 0 of this 'bank' you'd
>>> already have the wrong number. Since we're dealing with the "random
>>> SoC-specific controls" region of the GRF as opposed to the
>>> relatively-consistent and organised pinmux parts, I don't think we
>>> should rely on any assumptions about how things are laid out.
>>>
>>> I was initially going to suggest a more specific compatible string as
>>> well, but on reflection I think the generic "rockchip,gpio-syscon" for
>>> basic "flip this single GRF bit" functionality actually is the right way
>>> to go. In the specific RK3328 GPIO_MUTE case, there look to be 4 bits in
>>> total related to this pin - the enable, value, and some pull controls
>>> (which I assume apply when the output is disabled) - if at some point in
>>> future we *did* want to start explicitly controlling the rest of them
>>> too, then would be a good time to define a separate
>>> "rockchip,rk3328-gpio-mute" binding (and probably a dedicated driver)
>>> for that specialised functionality, independently of this basic one.
>>
>> Shall we go the generic "rockchip,gpio-syscon" way, or the specific
>> "rockchip,rk3328-gpio-mute" way? I prefer the former one.
>>
>> The property of "gpio,syscon-dev" in gpio-syscon driver should be
>> documented.
>> Since the gpio controller is defined in the dtsi file, which inevitably
>> contains voodoo
>> register addresses. But at the board level dts file, there won't be more
>> register
>> addresses.
> Past experience shows that the GRF is not really suitable for
> generalization, as it's more of a dumping ground where chip designers
> can put everything that's left over. This is especially true for
> GRF_SOC_CONx registers, that really only contain pretty random bits.
>
> So personally, I'd really prefer soc-specific compatibles as everywhere
> else, instead of trying to push stuff into the devicetree that won't hold
> up on future socs.
>
>
>> On 2018-05-24 3:53 AM, Rob Herring wrote:
>>> On Wed, May 23, 2018 at 10:12 AM, Heiko St?bner <heiko@sntech.de> wrote:
>>>> Hi Rob, Levin,
>>>>
>>>> sorry for being late to the party.
>>>>
>>>> Am Mittwoch, 23. Mai 2018, 16:43:07 CEST schrieb Rob Herring:
>>>>> On Tue, May 22, 2018 at 9:02 PM, Levin Du <djw@t-chip.com.cn> wrote:
>>>>>> On 2018-05-23 2:02 AM, Rob Herring wrote:
>>>>>>> On Fri, May 18, 2018 at 11:52:05AM +0800, djw at t-chip.com.cn wrote:
>>>>>>>> From: Levin Du <djw@t-chip.com.cn>
>>>>>>>>
>>>>>>>> Some GPIOs sit in the GRF_SOC_CON registers of Rockchip SoCs,
>>>>>>>> which do not belong to the general pinctrl.
>>>>>>>>
>>>>>>>> Adding gpio-syscon support makes controlling regulator or
>>>>>>>> LED using these special pins very easy by reusing existing
>>>>>>>> drivers, such as gpio-regulator and led-gpio.
>>>>>>>>
>>>>>>>> Signed-off-by: Levin Du <djw@t-chip.com.cn>
>>>>>>>>
>>>>>>>> ---
>>>>>>>>
>>>>>>>> Changes in v2:
>>>>>>>> - Rename gpio_syscon10 to gpio_mute in doc
>>>>>>>>
>>>>>>>> Changes in v1:
>>>>>>>> - Refactured for general gpio-syscon usage for Rockchip SoCs.
>>>>>>>> - Add doc rockchip,gpio-syscon.txt
>>>>>>>>
>>>>>>>> .../bindings/gpio/rockchip,gpio-syscon.txt | 41
>>>>>>>>
>>>>>>>> ++++++++++++++++++++++
>>>>>>>>
>>>>>>>> drivers/gpio/gpio-syscon.c | 30
>>>>>>>>
>>>>>>>> ++++++++++++++++
>>>>>>>>
>>>>>>>> 2 files changed, 71 insertions(+)
>>>>>>>> create mode 100644
>>>>>>>>
>>>>>>>> Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt
>>>>>>>>
>>>>>>>> diff --git
>>>>>>>> a/Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt
>>>>>>>> b/Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt
>>>>>>>> new file mode 100644
>>>>>>>> index 0000000..b1b2a67
>>>>>>>> --- /dev/null
>>>>>>>> +++ b/Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt
>>>>>>>> @@ -0,0 +1,41 @@
>>>>>>>> +* Rockchip GPIO support for GRF_SOC_CON registers
>>>>>>>> +
>>>>>>>> +Required properties:
>>>>>>>> +- compatible: Should contain "rockchip,gpio-syscon".
>>>>>>>> +- gpio-controller: Marks the device node as a gpio controller.
>>>>>>>> +- #gpio-cells: Should be two. The first cell is the pin number and
>>>>>>>> + the second cell is used to specify the gpio polarity:
>>>>>>>> + 0 = Active high,
>>>>>>>> + 1 = Active low.
>>>>>>> There's no need for this child node. Just make the parent node a gpio
>>>>>>> controller.
>>>>>>>
>>>>>>> Rob
>>>>>> Hi Rob, it is not clear to me. Do you suggest that the grf node should be
>>>>>> a
>>>>>> gpio controller,
>>>>>> like below?
>>>>>>
>>>>>> + grf: syscon at ff100000 {
>>>>>> + compatible = "rockchip,gpio-syscon", "rockchip,rk3328-grf",
>>>>>> "syscon", "simple-mfd";
>>>>> Yes, but drop "rockchip,gpio-syscon" and "simple-mfd".
>>>> I would disagree quite a bit here. The grf are the "general register files",
>>>> a bunch of registers used for quite a lot of things, and so it seems
>>>> among other users, also a gpio-controller for some more random pins
>>>> not controlled through the regular gpio controllers.
>>>>
>>>> For a more fully stocked grf, please see
>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/rk3288.dtsi#n855
>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/rockchip/rk3399.dtsi#n1338
>>>>
>>>> So the gpio controller should definitly also be a subnode.
>>> Sigh, yes, if there are a bunch of functions needing subnodes like the
>>> above, then yes that makes sense. But that's not what has been
>>> presented. Please make some attempt at defining *all* the functions.
>>> An actual binding would be nice, but I'll settle for just a list of
>>> things. The list should have functions that have DT dependencies (like
>>> clocks for phys in the above) because until you do, you don't need
>>> child nodes.
>> In rk3328.dtsi file, there are lots of line "rockchip,grf = <&grf>;" in
>> various nodes,
>> such as tsadc, cru, gmac2io, gmac2phy, and also pinctrl, which are not
>> sub nodes of
>> `grf`, but for reference only. The gpio-syscon node should also have
>> similar behavior.
>> They are not strongly coupled. The gpio-syscon node should be defined
>> outside of the
>> `grf` node.
> Not necessarily.
>
> I.e. things like the tsadc, cru etc have their own register space and only
> some minor additional bits inside the GRF.
>
> Other things like some phys and your mute-gpio are _fully embedded_ inside
> the GRF and thus become child devices. This describes the hardware layout
> way better, helps unclutter the devicetree and also shows this distinction
> between "additional bits" and "embedded" clearly.
>
>
> Heiko
Your good point convinced me. I'd like to discuss the V3 patch here.
Since there's only one GPIO pin (the GPIO_MUTE pin) in GRF_SOC_CON10
register,
the GPIO controller is named `gpio-mute` and has only one GPIO pin which is
referred to as `<&gpio-mute 0>`:
In rk3328.dtsi:
??? grf: syscon at ff100000 {
??????? //...
??? ??? /* The GPIO_MUTE pin is referred to as <&gpio-mute 0>.*/
??? ??? gpio_mute: gpio-mute {
??? ??? ??? compatible = "rockchip,rk3328-mute-gpio";
??? ??? ??? gpio-controller;
??? ??? ??? #gpio-cells = <2>;
??? ??? };
??? };
In gpio-syscon.c:
? static const struct syscon_gpio_data rockchip_rk3328_mute_gpio = {
? ? ???? /* rk3328 mute gpio is an output only pin at GRF_SOC_CON10[1] */
??????? .flags????????? = GPIO_SYSCON_FEAT_OUT,
??????? .bit_count????? = 1,
??????? .dat_bit_offset = 0x0428 * 8 + 1,
??????? .set??????????? = rockchip_gpio_set,
? };
? static const struct of_device_id syscon_gpio_ids[] = {
??? //...
??? {
??? ??? .compatible??? = "rockchip,rk3328-mute-gpio",
??? ??? .data??? ??? = &rockchip_rk3328_mute_gpio,
??? },
??? {}
? };
Compared to V0 patch, the bit_count changes from 2 to 1 and the
dat_bit_offset
increases 1. Therefore the GPIO_MUTE pin is now referred to as
`<&gpio-mute 0>`. IMHO it is better than `<&gpio-mute 1>` in the V0 patch.
In V0, `1` is the physical offset of the output pin in register and
<&gpio-mute 0>
is an invalid GPIO.
Thanks
Levin
^ permalink raw reply
* [Query] PAGE_OFFSET on KASLR enabled ARM64 kernel
From: Baoquan He @ 2018-05-28 3:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180528021609.GA31261@MiWiFi-R3L-srv>
On 05/28/18 at 10:16am, Baoquan He wrote:
> 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.
Oh, it's an offset value, I was mistaken.
>
> 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
>
> _______________________________________________
> kexec mailing list
> kexec at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply
* [PATCH v4 0/9] Add support for mediatek SOC MT2712
From: Stu Hsieh @ 2018-05-28 6:38 UTC (permalink / raw)
To: linux-arm-kernel
This patch add support for the Mediatek MT2712 DISP subsystem.
MT2712 is base on MT8173, there are some difference as following:
MT2712 support three disp output(two ovl and one rdma)
Change in v4:
- Move some modification about AAL1 from patch
"Add support for mediatek SOC MT2712" to
"add ddp component AAL1"
- Move some modification about OD1 from patch
"Add support for mediatek SOC MT2712" to
"add ddp component OD1"
- Move some modification about PWM2 from patch
"Add support for mediatek SOC MT2712" to
"add ddp component PWM2"
- Move some modification about third ddp path from patch
"Add support for mediatek SOC MT2712" to
"add third ddp path"
- Move the definition OD1_MOUT_EN_RDMA1 from patch
"Add support for mediatek SOC MT2712" to
"add connection from OD1 to RDMA1"
- Rebase the patch "add connection from OD1 to RDMA1" after
"add ddp component OD1"
- Rebase the patch "add third ddp path" before
"Add support for mediatek SOC MT2712"
- Modify the 2712 MUTEX MODULE in the order by index
- Added patch for ddp component PWM1
- For patch "add third ddp path"
Add the condition in mtk_crtc_create() that if there
is no ddp path, then return 0 to avoid the null crtc
Change in v3:
- Added patch for ddp component AAL1
- Added patch for ddp component OD1
- Added patch for ddp component PWM2
- Added patch to create third ddp path
- Rebase patch "support maximum 64 mutex mod" before
"Add support for mediatek SOC MT2712"
- Rebase patch "add connection from OD1 to RDMA1" before
"Add support for mediatek SOC MT2712"
- Remove two definition about RDMA0 and RDMA2
- Change the definition about mutex module from
bitwise to index
Changes in v2:
- update dt-bindings for mt2712
- Added patch to connection from OD1 to RDMA1
- Added patch to support maximum 64 mutex mod
- rewrite mutex mod condition for reducing one byte
- Change the component name AAL/OD to AAL0/OD0 for naming consistency
- Move the compatible information about dpi to other patch which modify
the dpi driver for mt2712
Stu Hsieh (9):
drm/mediatek: update dt-bindings for mt2712
drm/mediatek: support maximum 64 mutex mod
drm/mediatek: add ddp component AAL1
drm/mediatek: add ddp component OD1
drm/mediatek: add ddp component PWM1
drm/mediatek: add ddp component PWM2
drm/mediatek: add connection from OD1 to RDMA1
drm/mediatek: add third ddp path
drm/mediatek: Add support for mediatek SOC MT2712
.../bindings/display/mediatek/mediatek,disp.txt | 2 +-
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 3 +
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 124 +++++++++++++++------
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 8 +-
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 7 +-
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 47 +++++++-
drivers/gpu/drm/mediatek/mtk_drm_drv.h | 7 +-
7 files changed, 158 insertions(+), 40 deletions(-)
--
2.12.5
^ permalink raw reply
* [PATCH v4 1/9] drm/mediatek: update dt-bindings for mt2712
From: Stu Hsieh @ 2018-05-28 6:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527489507-24453-1-git-send-email-stu.hsieh@mediatek.com>
Update device tree binding documentation for the display subsystem for
Mediatek MT2712 SoCs.
Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com>
Acked-by: CK Hu <ck.hu@mediatek.com>
---
Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
index 383183a89164..8469de510001 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
@@ -40,7 +40,7 @@ Required properties (all function blocks):
"mediatek,<chip>-dpi" - DPI controller, see mediatek,dpi.txt
"mediatek,<chip>-disp-mutex" - display mutex
"mediatek,<chip>-disp-od" - overdrive
- the supported chips are mt2701 and mt8173.
+ the supported chips are mt2701, mt2712 and mt8173.
- reg: Physical base address and length of the function block register space
- interrupts: The interrupt signal from the function block (required, except for
merge and split function blocks).
--
2.12.5
^ permalink raw reply related
* [PATCH v4 2/9] drm/mediatek: support maximum 64 mutex mod
From: Stu Hsieh @ 2018-05-28 6:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527489507-24453-1-git-send-email-stu.hsieh@mediatek.com>
This patch support that if modules more than 32,
add index more than 31 when using DISP_REG_MUTEX_MOD2 bit
Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com>
Reviewed-by: CK Hu <ck.hu@mediatek.com>
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 75 +++++++++++++++++++++-------------
1 file changed, 47 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index 8130f3dab661..47ffa240bd25 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -41,31 +41,32 @@
#define DISP_REG_MUTEX_RST(n) (0x28 + 0x20 * (n))
#define DISP_REG_MUTEX_MOD(n) (0x2c + 0x20 * (n))
#define DISP_REG_MUTEX_SOF(n) (0x30 + 0x20 * (n))
+#define DISP_REG_MUTEX_MOD2(n) (0x34 + 0x20 * (n))
#define INT_MUTEX BIT(1)
-#define MT8173_MUTEX_MOD_DISP_OVL0 BIT(11)
-#define MT8173_MUTEX_MOD_DISP_OVL1 BIT(12)
-#define MT8173_MUTEX_MOD_DISP_RDMA0 BIT(13)
-#define MT8173_MUTEX_MOD_DISP_RDMA1 BIT(14)
-#define MT8173_MUTEX_MOD_DISP_RDMA2 BIT(15)
-#define MT8173_MUTEX_MOD_DISP_WDMA0 BIT(16)
-#define MT8173_MUTEX_MOD_DISP_WDMA1 BIT(17)
-#define MT8173_MUTEX_MOD_DISP_COLOR0 BIT(18)
-#define MT8173_MUTEX_MOD_DISP_COLOR1 BIT(19)
-#define MT8173_MUTEX_MOD_DISP_AAL BIT(20)
-#define MT8173_MUTEX_MOD_DISP_GAMMA BIT(21)
-#define MT8173_MUTEX_MOD_DISP_UFOE BIT(22)
-#define MT8173_MUTEX_MOD_DISP_PWM0 BIT(23)
-#define MT8173_MUTEX_MOD_DISP_PWM1 BIT(24)
-#define MT8173_MUTEX_MOD_DISP_OD BIT(25)
-
-#define MT2701_MUTEX_MOD_DISP_OVL BIT(3)
-#define MT2701_MUTEX_MOD_DISP_WDMA BIT(6)
-#define MT2701_MUTEX_MOD_DISP_COLOR BIT(7)
-#define MT2701_MUTEX_MOD_DISP_BLS BIT(9)
-#define MT2701_MUTEX_MOD_DISP_RDMA0 BIT(10)
-#define MT2701_MUTEX_MOD_DISP_RDMA1 BIT(12)
+#define MT8173_MUTEX_MOD_DISP_OVL0 11
+#define MT8173_MUTEX_MOD_DISP_OVL1 12
+#define MT8173_MUTEX_MOD_DISP_RDMA0 13
+#define MT8173_MUTEX_MOD_DISP_RDMA1 14
+#define MT8173_MUTEX_MOD_DISP_RDMA2 15
+#define MT8173_MUTEX_MOD_DISP_WDMA0 16
+#define MT8173_MUTEX_MOD_DISP_WDMA1 17
+#define MT8173_MUTEX_MOD_DISP_COLOR0 18
+#define MT8173_MUTEX_MOD_DISP_COLOR1 19
+#define MT8173_MUTEX_MOD_DISP_AAL 20
+#define MT8173_MUTEX_MOD_DISP_GAMMA 21
+#define MT8173_MUTEX_MOD_DISP_UFOE 22
+#define MT8173_MUTEX_MOD_DISP_PWM0 23
+#define MT8173_MUTEX_MOD_DISP_PWM1 24
+#define MT8173_MUTEX_MOD_DISP_OD 25
+
+#define MT2701_MUTEX_MOD_DISP_OVL 3
+#define MT2701_MUTEX_MOD_DISP_WDMA 6
+#define MT2701_MUTEX_MOD_DISP_COLOR 7
+#define MT2701_MUTEX_MOD_DISP_BLS 9
+#define MT2701_MUTEX_MOD_DISP_RDMA0 10
+#define MT2701_MUTEX_MOD_DISP_RDMA1 12
#define MUTEX_SOF_SINGLE_MODE 0
#define MUTEX_SOF_DSI0 1
@@ -278,6 +279,7 @@ void mtk_disp_mutex_add_comp(struct mtk_disp_mutex *mutex,
struct mtk_ddp *ddp = container_of(mutex, struct mtk_ddp,
mutex[mutex->id]);
unsigned int reg;
+ unsigned int offset;
WARN_ON(&ddp->mutex[mutex->id] != mutex);
@@ -292,9 +294,17 @@ void mtk_disp_mutex_add_comp(struct mtk_disp_mutex *mutex,
reg = MUTEX_SOF_DPI0;
break;
default:
- reg = readl_relaxed(ddp->regs + DISP_REG_MUTEX_MOD(mutex->id));
- reg |= ddp->mutex_mod[id];
- writel_relaxed(reg, ddp->regs + DISP_REG_MUTEX_MOD(mutex->id));
+ if (ddp->mutex_mod[id] < 32) {
+ offset = DISP_REG_MUTEX_MOD(mutex->id);
+ reg = readl_relaxed(ddp->regs + offset);
+ reg |= 1 << ddp->mutex_mod[id];
+ writel_relaxed(reg, ddp->regs + offset);
+ } else {
+ offset = DISP_REG_MUTEX_MOD2(mutex->id);
+ reg = readl_relaxed(ddp->regs + offset);
+ reg |= 1 << (ddp->mutex_mod[id] - 32);
+ writel_relaxed(reg, ddp->regs + offset);
+ }
return;
}
@@ -307,6 +317,7 @@ void mtk_disp_mutex_remove_comp(struct mtk_disp_mutex *mutex,
struct mtk_ddp *ddp = container_of(mutex, struct mtk_ddp,
mutex[mutex->id]);
unsigned int reg;
+ unsigned int offset;
WARN_ON(&ddp->mutex[mutex->id] != mutex);
@@ -318,9 +329,17 @@ void mtk_disp_mutex_remove_comp(struct mtk_disp_mutex *mutex,
ddp->regs + DISP_REG_MUTEX_SOF(mutex->id));
break;
default:
- reg = readl_relaxed(ddp->regs + DISP_REG_MUTEX_MOD(mutex->id));
- reg &= ~(ddp->mutex_mod[id]);
- writel_relaxed(reg, ddp->regs + DISP_REG_MUTEX_MOD(mutex->id));
+ if (ddp->mutex_mod[id] < 32) {
+ offset = DISP_REG_MUTEX_MOD(mutex->id);
+ reg = readl_relaxed(ddp->regs + offset);
+ reg &= ~(1 << ddp->mutex_mod[id]);
+ writel_relaxed(reg, ddp->regs + offset);
+ } else {
+ offset = DISP_REG_MUTEX_MOD2(mutex->id);
+ reg = readl_relaxed(ddp->regs + offset);
+ reg &= ~(1 << (ddp->mutex_mod[id] - 32));
+ writel_relaxed(reg, ddp->regs + offset);
+ }
break;
}
}
--
2.12.5
^ permalink raw reply related
* [PATCH v4 3/9] drm/mediatek: add ddp component AAL1
From: Stu Hsieh @ 2018-05-28 6:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527489507-24453-1-git-send-email-stu.hsieh@mediatek.com>
This patch add component AAL1 and
rename AAL to AAL0
Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com>
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 2 +-
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 3 ++-
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 3 ++-
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 2 +-
4 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index 47ffa240bd25..7217665f4b5d 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -110,7 +110,7 @@ static const unsigned int mt2701_mutex_mod[DDP_COMPONENT_ID_MAX] = {
};
static const unsigned int mt8173_mutex_mod[DDP_COMPONENT_ID_MAX] = {
- [DDP_COMPONENT_AAL] = MT8173_MUTEX_MOD_DISP_AAL,
+ [DDP_COMPONENT_AAL0] = MT8173_MUTEX_MOD_DISP_AAL,
[DDP_COMPONENT_COLOR0] = MT8173_MUTEX_MOD_DISP_COLOR0,
[DDP_COMPONENT_COLOR1] = MT8173_MUTEX_MOD_DISP_COLOR1,
[DDP_COMPONENT_GAMMA] = MT8173_MUTEX_MOD_DISP_GAMMA,
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index 4672317e3ad1..0919039805aa 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -218,7 +218,8 @@ struct mtk_ddp_comp_match {
};
static const struct mtk_ddp_comp_match mtk_ddp_matches[DDP_COMPONENT_ID_MAX] = {
- [DDP_COMPONENT_AAL] = { MTK_DISP_AAL, 0, &ddp_aal },
+ [DDP_COMPONENT_AAL0] = { MTK_DISP_AAL, 0, &ddp_aal },
+ [DDP_COMPONENT_AAL1] = { MTK_DISP_AAL, 1, &ddp_aal },
[DDP_COMPONENT_BLS] = { MTK_DISP_BLS, 0, NULL },
[DDP_COMPONENT_COLOR0] = { MTK_DISP_COLOR, 0, NULL },
[DDP_COMPONENT_COLOR1] = { MTK_DISP_COLOR, 1, NULL },
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
index 0828cf8bf85c..eee3c0cc2632 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
@@ -41,7 +41,8 @@ enum mtk_ddp_comp_type {
};
enum mtk_ddp_comp_id {
- DDP_COMPONENT_AAL,
+ DDP_COMPONENT_AAL0,
+ DDP_COMPONENT_AAL1,
DDP_COMPONENT_BLS,
DDP_COMPONENT_COLOR0,
DDP_COMPONENT_COLOR1,
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index a2ca90fc403c..a415260f3d5f 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -149,7 +149,7 @@ static const enum mtk_ddp_comp_id mt2701_mtk_ddp_ext[] = {
static const enum mtk_ddp_comp_id mt8173_mtk_ddp_main[] = {
DDP_COMPONENT_OVL0,
DDP_COMPONENT_COLOR0,
- DDP_COMPONENT_AAL,
+ DDP_COMPONENT_AAL0,
DDP_COMPONENT_OD,
DDP_COMPONENT_RDMA0,
DDP_COMPONENT_UFOE,
--
2.12.5
^ permalink raw reply related
* [PATCH v4 4/9] drm/mediatek: add ddp component OD1
From: Stu Hsieh @ 2018-05-28 6:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527489507-24453-1-git-send-email-stu.hsieh@mediatek.com>
This patch add the component OD1 and
rename the OD to OD1
Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com>
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 4 ++--
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 3 ++-
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 3 ++-
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 2 +-
4 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index 7217665f4b5d..58e44349e315 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -114,7 +114,7 @@ static const unsigned int mt8173_mutex_mod[DDP_COMPONENT_ID_MAX] = {
[DDP_COMPONENT_COLOR0] = MT8173_MUTEX_MOD_DISP_COLOR0,
[DDP_COMPONENT_COLOR1] = MT8173_MUTEX_MOD_DISP_COLOR1,
[DDP_COMPONENT_GAMMA] = MT8173_MUTEX_MOD_DISP_GAMMA,
- [DDP_COMPONENT_OD] = MT8173_MUTEX_MOD_DISP_OD,
+ [DDP_COMPONENT_OD0] = MT8173_MUTEX_MOD_DISP_OD,
[DDP_COMPONENT_OVL0] = MT8173_MUTEX_MOD_DISP_OVL0,
[DDP_COMPONENT_OVL1] = MT8173_MUTEX_MOD_DISP_OVL1,
[DDP_COMPONENT_PWM0] = MT8173_MUTEX_MOD_DISP_PWM0,
@@ -139,7 +139,7 @@ static unsigned int mtk_ddp_mout_en(enum mtk_ddp_comp_id cur,
} else if (cur == DDP_COMPONENT_OVL0 && next == DDP_COMPONENT_RDMA0) {
*addr = DISP_REG_CONFIG_DISP_OVL_MOUT_EN;
value = OVL_MOUT_EN_RDMA;
- } else if (cur == DDP_COMPONENT_OD && next == DDP_COMPONENT_RDMA0) {
+ } else if (cur == DDP_COMPONENT_OD0 && next == DDP_COMPONENT_RDMA0) {
*addr = DISP_REG_CONFIG_DISP_OD_MOUT_EN;
value = OD_MOUT_EN_RDMA0;
} else if (cur == DDP_COMPONENT_UFOE && next == DDP_COMPONENT_DSI0) {
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index 0919039805aa..87acf6be87f6 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -227,7 +227,8 @@ static const struct mtk_ddp_comp_match mtk_ddp_matches[DDP_COMPONENT_ID_MAX] = {
[DDP_COMPONENT_DSI0] = { MTK_DSI, 0, NULL },
[DDP_COMPONENT_DSI1] = { MTK_DSI, 1, NULL },
[DDP_COMPONENT_GAMMA] = { MTK_DISP_GAMMA, 0, &ddp_gamma },
- [DDP_COMPONENT_OD] = { MTK_DISP_OD, 0, &ddp_od },
+ [DDP_COMPONENT_OD0] = { MTK_DISP_OD, 0, &ddp_od },
+ [DDP_COMPONENT_OD1] = { MTK_DISP_OD, 1, &ddp_od },
[DDP_COMPONENT_OVL0] = { MTK_DISP_OVL, 0, NULL },
[DDP_COMPONENT_OVL1] = { MTK_DISP_OVL, 1, NULL },
[DDP_COMPONENT_PWM0] = { MTK_DISP_PWM, 0, NULL },
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
index eee3c0cc2632..9b19fc4423f1 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
@@ -50,7 +50,8 @@ enum mtk_ddp_comp_id {
DDP_COMPONENT_DSI0,
DDP_COMPONENT_DSI1,
DDP_COMPONENT_GAMMA,
- DDP_COMPONENT_OD,
+ DDP_COMPONENT_OD0,
+ DDP_COMPONENT_OD1,
DDP_COMPONENT_OVL0,
DDP_COMPONENT_OVL1,
DDP_COMPONENT_PWM0,
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index a415260f3d5f..08d5d0b47bfe 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -150,7 +150,7 @@ static const enum mtk_ddp_comp_id mt8173_mtk_ddp_main[] = {
DDP_COMPONENT_OVL0,
DDP_COMPONENT_COLOR0,
DDP_COMPONENT_AAL0,
- DDP_COMPONENT_OD,
+ DDP_COMPONENT_OD0,
DDP_COMPONENT_RDMA0,
DDP_COMPONENT_UFOE,
DDP_COMPONENT_DSI0,
--
2.12.5
^ permalink raw reply related
* [PATCH v4 5/9] drm/mediatek: add ddp component PWM1
From: Stu Hsieh @ 2018-05-28 6:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527489507-24453-1-git-send-email-stu.hsieh@mediatek.com>
This patch add component PWM1 in mtk_ddp_matches
Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com>
---
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index 87acf6be87f6..a5c7ac2d162d 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -232,6 +232,7 @@ static const struct mtk_ddp_comp_match mtk_ddp_matches[DDP_COMPONENT_ID_MAX] = {
[DDP_COMPONENT_OVL0] = { MTK_DISP_OVL, 0, NULL },
[DDP_COMPONENT_OVL1] = { MTK_DISP_OVL, 1, NULL },
[DDP_COMPONENT_PWM0] = { MTK_DISP_PWM, 0, NULL },
+ [DDP_COMPONENT_PWM1] = { MTK_DISP_PWM, 1, NULL },
[DDP_COMPONENT_RDMA0] = { MTK_DISP_RDMA, 0, NULL },
[DDP_COMPONENT_RDMA1] = { MTK_DISP_RDMA, 1, NULL },
[DDP_COMPONENT_RDMA2] = { MTK_DISP_RDMA, 2, NULL },
--
2.12.5
^ permalink raw reply related
* [PATCH v4 6/9] drm/mediatek: add ddp component PWM2
From: Stu Hsieh @ 2018-05-28 6:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527489507-24453-1-git-send-email-stu.hsieh@mediatek.com>
This patch add component PWM2
Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com>
---
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 1 +
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index a5c7ac2d162d..86e8c9e5df41 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -233,6 +233,7 @@ static const struct mtk_ddp_comp_match mtk_ddp_matches[DDP_COMPONENT_ID_MAX] = {
[DDP_COMPONENT_OVL1] = { MTK_DISP_OVL, 1, NULL },
[DDP_COMPONENT_PWM0] = { MTK_DISP_PWM, 0, NULL },
[DDP_COMPONENT_PWM1] = { MTK_DISP_PWM, 1, NULL },
+ [DDP_COMPONENT_PWM2] = { MTK_DISP_PWM, 2, NULL },
[DDP_COMPONENT_RDMA0] = { MTK_DISP_RDMA, 0, NULL },
[DDP_COMPONENT_RDMA1] = { MTK_DISP_RDMA, 1, NULL },
[DDP_COMPONENT_RDMA2] = { MTK_DISP_RDMA, 2, NULL },
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
index 9b19fc4423f1..e00c2e798abd 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
@@ -56,6 +56,7 @@ enum mtk_ddp_comp_id {
DDP_COMPONENT_OVL1,
DDP_COMPONENT_PWM0,
DDP_COMPONENT_PWM1,
+ DDP_COMPONENT_PWM2,
DDP_COMPONENT_RDMA0,
DDP_COMPONENT_RDMA1,
DDP_COMPONENT_RDMA2,
--
2.12.5
^ permalink raw reply related
* [PATCH v4 7/9] drm/mediatek: add connection from OD1 to RDMA1
From: Stu Hsieh @ 2018-05-28 6:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527489507-24453-1-git-send-email-stu.hsieh@mediatek.com>
This patch add the connection from OD1 to RDMA1 for ext path.
Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com>
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index 58e44349e315..8bfc0debd2c2 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -75,6 +75,7 @@
#define OVL0_MOUT_EN_COLOR0 0x1
#define OD_MOUT_EN_RDMA0 0x1
+#define OD1_MOUT_EN_RDMA1 BIT(16)
#define UFOE_MOUT_EN_DSI0 0x1
#define COLOR0_SEL_IN_OVL0 0x1
#define OVL1_MOUT_EN_COLOR1 0x1
@@ -151,6 +152,9 @@ static unsigned int mtk_ddp_mout_en(enum mtk_ddp_comp_id cur,
} else if (cur == DDP_COMPONENT_GAMMA && next == DDP_COMPONENT_RDMA1) {
*addr = DISP_REG_CONFIG_DISP_GAMMA_MOUT_EN;
value = GAMMA_MOUT_EN_RDMA1;
+ } else if (cur == DDP_COMPONENT_OD1 && next == DDP_COMPONENT_RDMA1) {
+ *addr = DISP_REG_CONFIG_DISP_OD_MOUT_EN;
+ value = OD1_MOUT_EN_RDMA1;
} else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DPI0) {
*addr = DISP_REG_CONFIG_DISP_RDMA1_MOUT_EN;
value = RDMA1_MOUT_DPI0;
--
2.12.5
^ permalink raw reply related
* [PATCH v4 8/9] drm/mediatek: add third ddp path
From: Stu Hsieh @ 2018-05-28 6:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527489507-24453-1-git-send-email-stu.hsieh@mediatek.com>
This patch create third crtc by third ddp path
Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com>
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 3 +++
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 5 +++++
drivers/gpu/drm/mediatek/mtk_drm_drv.h | 7 +++++--
3 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index 658b8dd45b83..2d6aa150a9ff 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -539,6 +539,9 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
int ret;
int i;
+ if (!path)
+ return 0;
+
for (i = 0; i < path_len; i++) {
enum mtk_ddp_comp_id comp_id = path[i];
struct device_node *node;
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index 08d5d0b47bfe..3d279a299383 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -232,6 +232,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);
+ 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]];
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.h b/drivers/gpu/drm/mediatek/mtk_drm_drv.h
index c3378c452c0a..d867e2683923 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.h
@@ -17,8 +17,8 @@
#include <linux/io.h>
#include "mtk_drm_ddp_comp.h"
-#define MAX_CRTC 2
-#define MAX_CONNECTOR 2
+#define MAX_CRTC 3
+#define MAX_CONNECTOR 3
struct device;
struct device_node;
@@ -33,6 +33,9 @@ struct mtk_mmsys_driver_data {
unsigned int main_len;
const enum mtk_ddp_comp_id *ext_path;
unsigned int ext_len;
+ const enum mtk_ddp_comp_id *third_path;
+ unsigned int third_len;
+
bool shadow_register;
};
--
2.12.5
^ permalink raw reply related
* [PATCH v4 9/9] drm/mediatek: Add support for mediatek SOC MT2712
From: Stu Hsieh @ 2018-05-28 6:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527489507-24453-1-git-send-email-stu.hsieh@mediatek.com>
This patch add support for the Mediatek MT2712 DISP subsystem.
There are two OVL engine and three disp output in MT2712.
Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com>
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 39 ++++++++++++++++++++++++++++++++++
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 38 +++++++++++++++++++++++++++++++++
2 files changed, 77 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index 8bfc0debd2c2..3b22b48a6022 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -61,6 +61,24 @@
#define MT8173_MUTEX_MOD_DISP_PWM1 24
#define MT8173_MUTEX_MOD_DISP_OD 25
+#define MT2712_MUTEX_MOD_DISP_PWM2 10
+#define MT2712_MUTEX_MOD_DISP_OVL0 11
+#define MT2712_MUTEX_MOD_DISP_OVL1 12
+#define MT2712_MUTEX_MOD_DISP_RDMA0 13
+#define MT2712_MUTEX_MOD_DISP_RDMA1 14
+#define MT2712_MUTEX_MOD_DISP_RDMA2 15
+#define MT2712_MUTEX_MOD_DISP_WDMA0 16
+#define MT2712_MUTEX_MOD_DISP_WDMA1 17
+#define MT2712_MUTEX_MOD_DISP_COLOR0 18
+#define MT2712_MUTEX_MOD_DISP_COLOR1 19
+#define MT2712_MUTEX_MOD_DISP_AAL0 20
+#define MT2712_MUTEX_MOD_DISP_UFOE 22
+#define MT2712_MUTEX_MOD_DISP_PWM0 23
+#define MT2712_MUTEX_MOD_DISP_PWM1 24
+#define MT2712_MUTEX_MOD_DISP_OD0 25
+#define MT2712_MUTEX_MOD2_DISP_AAL1 33
+#define MT2712_MUTEX_MOD2_DISP_OD1 34
+
#define MT2701_MUTEX_MOD_DISP_OVL 3
#define MT2701_MUTEX_MOD_DISP_WDMA 6
#define MT2701_MUTEX_MOD_DISP_COLOR 7
@@ -110,6 +128,26 @@ static const unsigned int mt2701_mutex_mod[DDP_COMPONENT_ID_MAX] = {
[DDP_COMPONENT_WDMA0] = MT2701_MUTEX_MOD_DISP_WDMA,
};
+static const unsigned int mt2712_mutex_mod[DDP_COMPONENT_ID_MAX] = {
+ [DDP_COMPONENT_AAL0] = MT2712_MUTEX_MOD_DISP_AAL0,
+ [DDP_COMPONENT_AAL1] = MT2712_MUTEX_MOD2_DISP_AAL1,
+ [DDP_COMPONENT_COLOR0] = MT2712_MUTEX_MOD_DISP_COLOR0,
+ [DDP_COMPONENT_COLOR1] = MT2712_MUTEX_MOD_DISP_COLOR1,
+ [DDP_COMPONENT_OD0] = MT2712_MUTEX_MOD_DISP_OD0,
+ [DDP_COMPONENT_OD1] = MT2712_MUTEX_MOD2_DISP_OD1,
+ [DDP_COMPONENT_OVL0] = MT2712_MUTEX_MOD_DISP_OVL0,
+ [DDP_COMPONENT_OVL1] = MT2712_MUTEX_MOD_DISP_OVL1,
+ [DDP_COMPONENT_PWM0] = MT2712_MUTEX_MOD_DISP_PWM0,
+ [DDP_COMPONENT_PWM1] = MT2712_MUTEX_MOD_DISP_PWM1,
+ [DDP_COMPONENT_PWM2] = MT2712_MUTEX_MOD_DISP_PWM2,
+ [DDP_COMPONENT_RDMA0] = MT2712_MUTEX_MOD_DISP_RDMA0,
+ [DDP_COMPONENT_RDMA1] = MT2712_MUTEX_MOD_DISP_RDMA1,
+ [DDP_COMPONENT_RDMA2] = MT2712_MUTEX_MOD_DISP_RDMA2,
+ [DDP_COMPONENT_UFOE] = MT2712_MUTEX_MOD_DISP_UFOE,
+ [DDP_COMPONENT_WDMA0] = MT2712_MUTEX_MOD_DISP_WDMA0,
+ [DDP_COMPONENT_WDMA1] = MT2712_MUTEX_MOD_DISP_WDMA1,
+};
+
static const unsigned int mt8173_mutex_mod[DDP_COMPONENT_ID_MAX] = {
[DDP_COMPONENT_AAL0] = MT8173_MUTEX_MOD_DISP_AAL,
[DDP_COMPONENT_COLOR0] = MT8173_MUTEX_MOD_DISP_COLOR0,
@@ -430,6 +468,7 @@ static int mtk_ddp_remove(struct platform_device *pdev)
static const struct of_device_id ddp_driver_dt_match[] = {
{ .compatible = "mediatek,mt2701-disp-mutex", .data = mt2701_mutex_mod},
+ { .compatible = "mediatek,mt2712-disp-mutex", .data = mt2712_mutex_mod},
{ .compatible = "mediatek,mt8173-disp-mutex", .data = mt8173_mutex_mod},
{},
};
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index 3d279a299383..3a866e1d6af4 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -146,6 +146,32 @@ static const enum mtk_ddp_comp_id mt2701_mtk_ddp_ext[] = {
DDP_COMPONENT_DPI0,
};
+static const enum mtk_ddp_comp_id mt2712_mtk_ddp_main[] = {
+ DDP_COMPONENT_OVL0,
+ DDP_COMPONENT_COLOR0,
+ DDP_COMPONENT_AAL0,
+ DDP_COMPONENT_OD0,
+ DDP_COMPONENT_RDMA0,
+ DDP_COMPONENT_DPI0,
+ DDP_COMPONENT_PWM0,
+};
+
+static const enum mtk_ddp_comp_id mt2712_mtk_ddp_ext[] = {
+ DDP_COMPONENT_OVL1,
+ DDP_COMPONENT_COLOR1,
+ DDP_COMPONENT_AAL1,
+ DDP_COMPONENT_OD1,
+ DDP_COMPONENT_RDMA1,
+ DDP_COMPONENT_DPI1,
+ DDP_COMPONENT_PWM1,
+};
+
+static const enum mtk_ddp_comp_id mt2712_mtk_ddp_third[] = {
+ DDP_COMPONENT_RDMA2,
+ DDP_COMPONENT_DSI2,
+ DDP_COMPONENT_PWM2,
+};
+
static const enum mtk_ddp_comp_id mt8173_mtk_ddp_main[] = {
DDP_COMPONENT_OVL0,
DDP_COMPONENT_COLOR0,
@@ -173,6 +199,15 @@ static const struct mtk_mmsys_driver_data mt2701_mmsys_driver_data = {
.shadow_register = true,
};
+static const struct mtk_mmsys_driver_data mt2712_mmsys_driver_data = {
+ .main_path = mt2712_mtk_ddp_main,
+ .main_len = ARRAY_SIZE(mt2712_mtk_ddp_main),
+ .ext_path = mt2712_mtk_ddp_ext,
+ .ext_len = ARRAY_SIZE(mt2712_mtk_ddp_ext),
+ .third_path = mt2712_mtk_ddp_third,
+ .third_len = ARRAY_SIZE(mt2712_mtk_ddp_third),
+};
+
static const struct mtk_mmsys_driver_data mt8173_mmsys_driver_data = {
.main_path = mt8173_mtk_ddp_main,
.main_len = ARRAY_SIZE(mt8173_mtk_ddp_main),
@@ -379,6 +414,7 @@ static const struct of_device_id mtk_ddp_comp_dt_ids[] = {
{ .compatible = "mediatek,mt8173-dsi", .data = (void *)MTK_DSI },
{ .compatible = "mediatek,mt8173-dpi", .data = (void *)MTK_DPI },
{ .compatible = "mediatek,mt2701-disp-mutex", .data = (void *)MTK_DISP_MUTEX },
+ { .compatible = "mediatek,mt2712-disp-mutex", .data = (void *)MTK_DISP_MUTEX },
{ .compatible = "mediatek,mt8173-disp-mutex", .data = (void *)MTK_DISP_MUTEX },
{ .compatible = "mediatek,mt2701-disp-pwm", .data = (void *)MTK_DISP_BLS },
{ .compatible = "mediatek,mt8173-disp-pwm", .data = (void *)MTK_DISP_PWM },
@@ -557,6 +593,8 @@ static SIMPLE_DEV_PM_OPS(mtk_drm_pm_ops, mtk_drm_sys_suspend,
static const struct of_device_id mtk_drm_of_ids[] = {
{ .compatible = "mediatek,mt2701-mmsys",
.data = &mt2701_mmsys_driver_data},
+ { .compatible = "mediatek,mt2712-mmsys",
+ .data = &mt2712_mmsys_driver_data},
{ .compatible = "mediatek,mt8173-mmsys",
.data = &mt8173_mmsys_driver_data},
{ }
--
2.12.5
^ permalink raw reply related
* [PATCHv4 1/2] ARM: imx53: add secure-reg-access support for PMU
From: Sebastian Reichel @ 2018-05-28 6:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180528022652.GA3143@dragon>
Hi,
On Mon, May 28, 2018 at 10:26:54AM +0800, Shawn Guo wrote:
> 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?
Yes, all other SoCs supported by Linux ARM PMU counters driver can
just use the registers without having to enable platform specific
bits first.
> In that case, I can live with it.
What about the DT node? I did not add it, since this is a i.MX53
specific workaround anyways.
-- Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180528/03b956df/attachment-0001.sig>
^ permalink raw reply
* [Query] PAGE_OFFSET on KASLR enabled ARM64 kernel
From: Ard Biesheuvel @ 2018-05-28 6:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACi5LpO8KVVD_6ZJTW2SiyR8v0uDMA3H9yKHNw1=RKO+fd7KjA@mail.gmail.com>
On 27 May 2018 at 23:03, Bhupesh Sharma <bhsharma@redhat.com> 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:
>
> [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.
>
Hello Bhupesh,
Could you explain what the relevance is of PAGE_OFFSET to userland?
The only thing that should matter is where the actual linear mapping
of DRAM is, and I am not sure I understand why we care about where it
resides relative to the base of the linear region.
^ permalink raw reply
* [PATCH] mmc: sunxi: mark PM functions as __maybe_unused
From: Maxime Ripard @ 2018-05-28 6:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180525210752.1794502-1-arnd@arndb.de>
On Fri, May 25, 2018 at 11:07:42PM +0200, Arnd Bergmann wrote:
> The newly added runtime-pm functions cause a harmless warning
> when CONFIG_PM is disabled:
>
> drivers/mmc/host/sunxi-mmc.c:1452:12: error: 'sunxi_mmc_runtime_suspend' defined but not used [-Werror=unused-function]
> static int sunxi_mmc_runtime_suspend(struct device *dev)
> ^~~~~~~~~~~~~~~~~~~~~~~~~
> drivers/mmc/host/sunxi-mmc.c:1435:12: error: 'sunxi_mmc_runtime_resume' defined but not used [-Werror=unused-function]
> static int sunxi_mmc_runtime_resume(struct device *dev)
>
> This marks them as __maybe_unused to shut up the warning.
>
> Fixes: 9a8e1e8cc2c0 ("mmc: sunxi: Add runtime_pm support")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Thanks!
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180528/7e148807/attachment.sig>
^ permalink raw reply
* [PATCH v2 7/8] iommu: Remove IOMMU_OF_DECLARE
From: Marek Szyprowski @ 2018-05-28 6:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524175024.19874-8-robh@kernel.org>
Hi Rob,
On 2018-05-24 19:50, Rob Herring wrote:
> Now that we use the driver core to stop deferred probe for missing
> drivers, IOMMU_OF_DECLARE can be removed.
>
> This is slightly less optimal than having a list of built-in drivers in
> that we'll now defer probe twice before giving up. This shouldn't have a
> significant impact on boot times as past discussions about deferred
> probe have given no evidence of deferred probe having a substantial
> impact.
>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Robin Murphy <robin.murphy@arm.com>
> Cc: Joerg Roedel <joro@8bytes.org>
> Cc: Marek Szyprowski <m.szyprowski@samsung.com>
> Cc: Kukjin Kim <kgene@kernel.org>
> Cc: Krzysztof Kozlowski <krzk@kernel.org>
> Cc: Rob Clark <robdclark@gmail.com>
> Cc: Heiko Stuebner <heiko@sntech.de>
> Cc: Frank Rowand <frowand.list@gmail.com>
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: iommu at lists.linux-foundation.org
> Cc: linux-samsung-soc at vger.kernel.org
> Cc: linux-arm-msm at vger.kernel.org
> Cc: linux-rockchip at lists.infradead.org
> Cc: devicetree at vger.kernel.org
> Signed-off-by: Rob Herring <robh@kernel.org>
For Exynos IOMMU:
Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
> drivers/iommu/arm-smmu-v3.c | 2 --
> drivers/iommu/arm-smmu.c | 7 -------
> drivers/iommu/exynos-iommu.c | 2 --
> drivers/iommu/ipmmu-vmsa.c | 3 ---
> drivers/iommu/msm_iommu.c | 2 --
> drivers/iommu/of_iommu.c | 19 +------------------
> drivers/iommu/qcom_iommu.c | 2 --
> drivers/iommu/rockchip-iommu.c | 2 --
> include/linux/of_iommu.h | 4 ----
> 9 files changed, 1 insertion(+), 42 deletions(-)
>
> diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
> index 1d647104bccc..22bdabd3d8e0 100644
> --- a/drivers/iommu/arm-smmu-v3.c
> +++ b/drivers/iommu/arm-smmu-v3.c
> @@ -2915,8 +2915,6 @@ static struct platform_driver arm_smmu_driver = {
> };
> module_platform_driver(arm_smmu_driver);
>
> -IOMMU_OF_DECLARE(arm_smmuv3, "arm,smmu-v3");
> -
> MODULE_DESCRIPTION("IOMMU API for ARM architected SMMUv3 implementations");
> MODULE_AUTHOR("Will Deacon <will.deacon@arm.com>");
> MODULE_LICENSE("GPL v2");
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index 69e7c60792a8..9dd7cbaa3b0c 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -2211,13 +2211,6 @@ static struct platform_driver arm_smmu_driver = {
> };
> module_platform_driver(arm_smmu_driver);
>
> -IOMMU_OF_DECLARE(arm_smmuv1, "arm,smmu-v1");
> -IOMMU_OF_DECLARE(arm_smmuv2, "arm,smmu-v2");
> -IOMMU_OF_DECLARE(arm_mmu400, "arm,mmu-400");
> -IOMMU_OF_DECLARE(arm_mmu401, "arm,mmu-401");
> -IOMMU_OF_DECLARE(arm_mmu500, "arm,mmu-500");
> -IOMMU_OF_DECLARE(cavium_smmuv2, "cavium,smmu-v2");
> -
> MODULE_DESCRIPTION("IOMMU API for ARM architected SMMU implementations");
> MODULE_AUTHOR("Will Deacon <will.deacon@arm.com>");
> MODULE_LICENSE("GPL v2");
> diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
> index 85879cfec52f..b128cb4372d3 100644
> --- a/drivers/iommu/exynos-iommu.c
> +++ b/drivers/iommu/exynos-iommu.c
> @@ -1390,5 +1390,3 @@ static int __init exynos_iommu_init(void)
> return ret;
> }
> core_initcall(exynos_iommu_init);
> -
> -IOMMU_OF_DECLARE(exynos_iommu_of, "samsung,exynos-sysmmu");
> diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
> index 40ae6e87cb88..f026aa16d5f1 100644
> --- a/drivers/iommu/ipmmu-vmsa.c
> +++ b/drivers/iommu/ipmmu-vmsa.c
> @@ -1108,9 +1108,6 @@ static void __exit ipmmu_exit(void)
> subsys_initcall(ipmmu_init);
> module_exit(ipmmu_exit);
>
> -IOMMU_OF_DECLARE(ipmmu_vmsa_iommu_of, "renesas,ipmmu-vmsa");
> -IOMMU_OF_DECLARE(ipmmu_r8a7795_iommu_of, "renesas,ipmmu-r8a7795");
> -
> MODULE_DESCRIPTION("IOMMU API for Renesas VMSA-compatible IPMMU");
> MODULE_AUTHOR("Laurent Pinchart <laurent.pinchart@ideasonboard.com>");
> MODULE_LICENSE("GPL v2");
> diff --git a/drivers/iommu/msm_iommu.c b/drivers/iommu/msm_iommu.c
> index 0d3350463a3f..27377742600d 100644
> --- a/drivers/iommu/msm_iommu.c
> +++ b/drivers/iommu/msm_iommu.c
> @@ -877,7 +877,5 @@ static void __exit msm_iommu_driver_exit(void)
> subsys_initcall(msm_iommu_driver_init);
> module_exit(msm_iommu_driver_exit);
>
> -IOMMU_OF_DECLARE(msm_iommu_of, "qcom,apq8064-iommu");
> -
> MODULE_LICENSE("GPL v2");
> MODULE_AUTHOR("Stepan Moskovchenko <stepanm@codeaurora.org>");
> diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
> index 2aac8387717c..1904ccf9fc4e 100644
> --- a/drivers/iommu/of_iommu.c
> +++ b/drivers/iommu/of_iommu.c
> @@ -27,9 +27,6 @@
>
> #define NO_IOMMU 1
>
> -static const struct of_device_id __iommu_of_table_sentinel
> - __used __section(__iommu_of_table_end);
> -
> /**
> * of_get_dma_window - Parse *dma-window property and returns 0 if found.
> *
> @@ -98,19 +95,6 @@ int of_get_dma_window(struct device_node *dn, const char *prefix, int index,
> }
> EXPORT_SYMBOL_GPL(of_get_dma_window);
>
> -static bool of_iommu_driver_present(struct device_node *np)
> -{
> - /*
> - * If the IOMMU still isn't ready by the time we reach init, assume
> - * it never will be. We don't want to defer indefinitely, nor attempt
> - * to dereference __iommu_of_table after it's been freed.
> - */
> - if (system_state >= SYSTEM_RUNNING)
> - return false;
> -
> - return of_match_node(&__iommu_of_table, np);
> -}
> -
> static int of_iommu_xlate(struct device *dev,
> struct of_phandle_args *iommu_spec)
> {
> @@ -120,8 +104,7 @@ static int of_iommu_xlate(struct device *dev,
>
> ops = iommu_ops_from_fwnode(fwnode);
> if ((ops && !ops->of_xlate) ||
> - !of_device_is_available(iommu_spec->np) ||
> - (!ops && !of_iommu_driver_present(iommu_spec->np)))
> + !of_device_is_available(iommu_spec->np))
> return NO_IOMMU;
>
> err = iommu_fwspec_init(dev, &iommu_spec->np->fwnode, ops);
> diff --git a/drivers/iommu/qcom_iommu.c b/drivers/iommu/qcom_iommu.c
> index 65b9c99707f8..fa0f6c39a144 100644
> --- a/drivers/iommu/qcom_iommu.c
> +++ b/drivers/iommu/qcom_iommu.c
> @@ -947,7 +947,5 @@ static void __exit qcom_iommu_exit(void)
> module_init(qcom_iommu_init);
> module_exit(qcom_iommu_exit);
>
> -IOMMU_OF_DECLARE(qcom_iommu_dev, "qcom,msm-iommu-v1");
> -
> MODULE_DESCRIPTION("IOMMU API for QCOM IOMMU v1 implementations");
> MODULE_LICENSE("GPL v2");
> diff --git a/drivers/iommu/rockchip-iommu.c b/drivers/iommu/rockchip-iommu.c
> index 0468acfa131f..90d37f29c24c 100644
> --- a/drivers/iommu/rockchip-iommu.c
> +++ b/drivers/iommu/rockchip-iommu.c
> @@ -1284,8 +1284,6 @@ static int __init rk_iommu_init(void)
> }
> subsys_initcall(rk_iommu_init);
>
> -IOMMU_OF_DECLARE(rk_iommu_of, "rockchip,iommu");
> -
> MODULE_DESCRIPTION("IOMMU API for Rockchip");
> MODULE_AUTHOR("Simon Xue <xxm@rock-chips.com> and Daniel Kurtz <djkurtz@chromium.org>");
> MODULE_ALIAS("platform:rockchip-iommu");
> diff --git a/include/linux/of_iommu.h b/include/linux/of_iommu.h
> index 4fa654e4b5a9..f3d40dd7bb66 100644
> --- a/include/linux/of_iommu.h
> +++ b/include/linux/of_iommu.h
> @@ -32,8 +32,4 @@ static inline const struct iommu_ops *of_iommu_configure(struct device *dev,
>
> #endif /* CONFIG_OF_IOMMU */
>
> -extern struct of_device_id __iommu_of_table;
> -
> -#define IOMMU_OF_DECLARE(name, compat) OF_DECLARE_1(iommu, name, compat, NULL)
> -
> #endif /* __OF_IOMMU_H */
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* [PATCH v4 3/9] drm/mediatek: add ddp component AAL1
From: CK Hu @ 2018-05-28 7:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527489507-24453-4-git-send-email-stu.hsieh@mediatek.com>
Hi, Stu:
On Mon, 2018-05-28 at 14:38 +0800, Stu Hsieh wrote:
> This patch add component AAL1 and
> rename AAL to AAL0
>
Reviewed-by: CK Hu <ck.hu@mediatek.com>
> Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 2 +-
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 3 ++-
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 3 ++-
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 2 +-
> 4 files changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> index 47ffa240bd25..7217665f4b5d 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -110,7 +110,7 @@ static const unsigned int mt2701_mutex_mod[DDP_COMPONENT_ID_MAX] = {
> };
>
> static const unsigned int mt8173_mutex_mod[DDP_COMPONENT_ID_MAX] = {
> - [DDP_COMPONENT_AAL] = MT8173_MUTEX_MOD_DISP_AAL,
> + [DDP_COMPONENT_AAL0] = MT8173_MUTEX_MOD_DISP_AAL,
> [DDP_COMPONENT_COLOR0] = MT8173_MUTEX_MOD_DISP_COLOR0,
> [DDP_COMPONENT_COLOR1] = MT8173_MUTEX_MOD_DISP_COLOR1,
> [DDP_COMPONENT_GAMMA] = MT8173_MUTEX_MOD_DISP_GAMMA,
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> index 4672317e3ad1..0919039805aa 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> @@ -218,7 +218,8 @@ struct mtk_ddp_comp_match {
> };
>
> static const struct mtk_ddp_comp_match mtk_ddp_matches[DDP_COMPONENT_ID_MAX] = {
> - [DDP_COMPONENT_AAL] = { MTK_DISP_AAL, 0, &ddp_aal },
> + [DDP_COMPONENT_AAL0] = { MTK_DISP_AAL, 0, &ddp_aal },
> + [DDP_COMPONENT_AAL1] = { MTK_DISP_AAL, 1, &ddp_aal },
> [DDP_COMPONENT_BLS] = { MTK_DISP_BLS, 0, NULL },
> [DDP_COMPONENT_COLOR0] = { MTK_DISP_COLOR, 0, NULL },
> [DDP_COMPONENT_COLOR1] = { MTK_DISP_COLOR, 1, NULL },
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> index 0828cf8bf85c..eee3c0cc2632 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> @@ -41,7 +41,8 @@ enum mtk_ddp_comp_type {
> };
>
> enum mtk_ddp_comp_id {
> - DDP_COMPONENT_AAL,
> + DDP_COMPONENT_AAL0,
> + DDP_COMPONENT_AAL1,
> DDP_COMPONENT_BLS,
> DDP_COMPONENT_COLOR0,
> DDP_COMPONENT_COLOR1,
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> index a2ca90fc403c..a415260f3d5f 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> @@ -149,7 +149,7 @@ static const enum mtk_ddp_comp_id mt2701_mtk_ddp_ext[] = {
> static const enum mtk_ddp_comp_id mt8173_mtk_ddp_main[] = {
> DDP_COMPONENT_OVL0,
> DDP_COMPONENT_COLOR0,
> - DDP_COMPONENT_AAL,
> + DDP_COMPONENT_AAL0,
> DDP_COMPONENT_OD,
> DDP_COMPONENT_RDMA0,
> DDP_COMPONENT_UFOE,
^ permalink raw reply
* [PATCH v4 4/9] drm/mediatek: add ddp component OD1
From: CK Hu @ 2018-05-28 7:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527489507-24453-5-git-send-email-stu.hsieh@mediatek.com>
Hi, Stu:
On Mon, 2018-05-28 at 14:38 +0800, Stu Hsieh wrote:
> This patch add the component OD1 and
> rename the OD to OD1
rename the OD to OD0
>
> Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 4 ++--
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 3 ++-
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 3 ++-
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 2 +-
> 4 files changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> index 7217665f4b5d..58e44349e315 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -114,7 +114,7 @@ static const unsigned int mt8173_mutex_mod[DDP_COMPONENT_ID_MAX] = {
> [DDP_COMPONENT_COLOR0] = MT8173_MUTEX_MOD_DISP_COLOR0,
> [DDP_COMPONENT_COLOR1] = MT8173_MUTEX_MOD_DISP_COLOR1,
> [DDP_COMPONENT_GAMMA] = MT8173_MUTEX_MOD_DISP_GAMMA,
> - [DDP_COMPONENT_OD] = MT8173_MUTEX_MOD_DISP_OD,
> + [DDP_COMPONENT_OD0] = MT8173_MUTEX_MOD_DISP_OD,
> [DDP_COMPONENT_OVL0] = MT8173_MUTEX_MOD_DISP_OVL0,
> [DDP_COMPONENT_OVL1] = MT8173_MUTEX_MOD_DISP_OVL1,
> [DDP_COMPONENT_PWM0] = MT8173_MUTEX_MOD_DISP_PWM0,
> @@ -139,7 +139,7 @@ static unsigned int mtk_ddp_mout_en(enum mtk_ddp_comp_id cur,
> } else if (cur == DDP_COMPONENT_OVL0 && next == DDP_COMPONENT_RDMA0) {
> *addr = DISP_REG_CONFIG_DISP_OVL_MOUT_EN;
> value = OVL_MOUT_EN_RDMA;
> - } else if (cur == DDP_COMPONENT_OD && next == DDP_COMPONENT_RDMA0) {
> + } else if (cur == DDP_COMPONENT_OD0 && next == DDP_COMPONENT_RDMA0) {
> *addr = DISP_REG_CONFIG_DISP_OD_MOUT_EN;
> value = OD_MOUT_EN_RDMA0;
> } else if (cur == DDP_COMPONENT_UFOE && next == DDP_COMPONENT_DSI0) {
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> index 0919039805aa..87acf6be87f6 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> @@ -227,7 +227,8 @@ static const struct mtk_ddp_comp_match mtk_ddp_matches[DDP_COMPONENT_ID_MAX] = {
> [DDP_COMPONENT_DSI0] = { MTK_DSI, 0, NULL },
> [DDP_COMPONENT_DSI1] = { MTK_DSI, 1, NULL },
> [DDP_COMPONENT_GAMMA] = { MTK_DISP_GAMMA, 0, &ddp_gamma },
> - [DDP_COMPONENT_OD] = { MTK_DISP_OD, 0, &ddp_od },
> + [DDP_COMPONENT_OD0] = { MTK_DISP_OD, 0, &ddp_od },
> + [DDP_COMPONENT_OD1] = { MTK_DISP_OD, 1, &ddp_od },
> [DDP_COMPONENT_OVL0] = { MTK_DISP_OVL, 0, NULL },
> [DDP_COMPONENT_OVL1] = { MTK_DISP_OVL, 1, NULL },
> [DDP_COMPONENT_PWM0] = { MTK_DISP_PWM, 0, NULL },
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> index eee3c0cc2632..9b19fc4423f1 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> @@ -50,7 +50,8 @@ enum mtk_ddp_comp_id {
> DDP_COMPONENT_DSI0,
> DDP_COMPONENT_DSI1,
> DDP_COMPONENT_GAMMA,
> - DDP_COMPONENT_OD,
> + DDP_COMPONENT_OD0,
> + DDP_COMPONENT_OD1,
> DDP_COMPONENT_OVL0,
> DDP_COMPONENT_OVL1,
> DDP_COMPONENT_PWM0,
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> index a415260f3d5f..08d5d0b47bfe 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> @@ -150,7 +150,7 @@ static const enum mtk_ddp_comp_id mt8173_mtk_ddp_main[] = {
> DDP_COMPONENT_OVL0,
> DDP_COMPONENT_COLOR0,
> DDP_COMPONENT_AAL0,
> - DDP_COMPONENT_OD,
> + DDP_COMPONENT_OD0,
> DDP_COMPONENT_RDMA0,
> DDP_COMPONENT_UFOE,
> DDP_COMPONENT_DSI0,
^ permalink raw reply
* Allwinner A64: Issue on external rtc clock to wifi chip
From: Michael Nazzareno Trimarchi @ 2018-05-28 7:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180514111726.lnxpegipqklyetmv@flea>
Hi Maxime
On Mon, May 14, 2018 at 1:17 PM, Maxime Ripard
<maxime.ripard@bootlin.com> wrote:
> On Mon, May 14, 2018 at 03:12:49PM +0530, Jagan Teki wrote:
>> On Mon, May 14, 2018 at 2:36 PM, Maxime Ripard
>> <maxime.ripard@bootlin.com> wrote:
>> > On Mon, May 14, 2018 at 02:34:22PM +0530, Jagan Teki wrote:
>> >> On Mon, May 14, 2018 at 1:57 PM, Maxime Ripard
>> >> <maxime.ripard@bootlin.com> wrote:
>> >> > On Mon, May 14, 2018 at 01:34:56PM +0530, Jagan Teki wrote:
>> >> >> On Mon, May 14, 2018 at 1:27 PM, Maxime Ripard
>> >> >> <maxime.ripard@bootlin.com> wrote:
>> >> >> > Hi,
>> >> >> >
>> >> >> > On Mon, May 14, 2018 at 12:37:49PM +0530, Jagan Teki wrote:
>> >> >> >> Hi Maxime and All,
>> >> >> >>
>> >> >> >> We are trying to bring-up AP6330 Wifi chip for A64 board. We noticed
>> >> >> >> to have an external rtc clock has driven from wifi chip.
>> >> >> >>
>> >> >> >> So the devicetree is configured according to this as below.
>> >> >> >>
>> >> >> >> / {
>> >> >> >> wifi_pwrseq: wifi-pwrseq {
>> >> >> >> compatible = "mmc-pwrseq-simple";
>> >> >> >> clocks = <&rtc 1>;
>> >> >> >> clock-names = "ext_clock";
>> >> >> >> reset-gpios = <&r_pio 0 2 GPIO_ACTIVE_LOW>; /* PL2 */
>> >> >> >> post-power-on-delay-ms = <400>;
>> >> >> >> };
>> >> >> >> };
>> >> >> >>
>> >> >> >> &rtc {
>> >> >> >> clock-output-names = "rtc-osc32k", "rtc-osc32k-out";
>> >> >> >> clocks = <&osc32k>;
>> >> >> >> #clock-cells = <1>;
>> >> >> >> };
>> >> >> >>
>> >> >> >> &mmc1 {
>> >> >> >> pinctrl-names = "default";
>> >> >> >> pinctrl-0 = <&mmc1_pins>;
>> >> >> >> vmmc-supply = <®_dcdc1>;
>> >> >> >> vqmmc-supply = <®_eldo1>;
>> >> >> >> mmc-pwrseq = <&wifi_pwrseq>;
>> >> >> >> bus-width = <4>;
>> >> >> >> non-removable;
>> >> >> >> status = "okay";
>> >> >> >>
>> >> >> >> brcmf: wifi at 1 {
>> >> >> >> reg = <1>;
>> >> >> >> compatible = "brcm,bcm4329-fmac";
>> >> >> >> interrupt-parent = <&r_pio>;
>> >> >> >> interrupts = <0 3 IRQ_TYPE_LEVEL_LOW>; /* WL-WAKE-AP: PL3 */
>> >> >> >> interrupt-names = "host-wake";
>> >> >> >> };
>> >> >> >> };
>> >> >> >>
>> >> >> >> And observed rtc-osc32k-out clock is never enabled[1] and the value of
>> >> >> >> LOSC_OUT_GATING is 0x0 which eventually not enabling
>> >> >> >> LOSC_OUT_GATING_EN
>> >> >> >>
>> >> >> >> Pls. let us know if we miss anything here?
>> >> >> >>
>> >> >> >> [1] https://paste.ubuntu.com/p/X2By4q8kD2/
>> >> >> >
>> >> >> > Could you paste your config and the logs from a boot to?
>> >> >>
>> >> >> .config
>> >> >> https://paste.ubuntu.com/p/w9w2KB7RFc/
>> >> >>
>> >> >> dmesg
>> >> >> https://paste.ubuntu.com/p/mrZGk5bWRR/
>> >> >
>> >> > This is kind of weird. Have you tested with a 4.17 kernel? We have
>> >> > runtime_pm changes lined up in next, so that might be a regression
>> >> > there, even though we tested it with Quentin at some point.
>> >>
>> >> This is 4.17-rc4 do you want to try it on 4.16 ?
>> >
>> > No, this is next-20180503. Please try with 4.17-rc4
>>
>> Couldn't find any different in behaviour [2]
>>
>> [2] https://paste.ubuntu.com/p/m3PGBwrv6W/
>
> It's hard to tell without the board, but have you looked at the return
> value of devm_clk_get in the pwrseq code?
>
> Enabling the clk ftrace events would also help.
>
The driver has one bug.
diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c
index 2e6fb27..a66f40c 100644
--- a/drivers/rtc/rtc-sun6i.c
+++ b/drivers/rtc/rtc-sun6i.c
@@ -74,7 +74,7 @@
#define SUN6I_ALARM_CONFIG_WAKEUP BIT(0)
#define SUN6I_LOSC_OUT_GATING 0x0060
-#define SUN6I_LOSC_OUT_GATING_EN BIT(0)
+#define SUN6I_LOSC_OUT_GATING_EN 0
You need to pass bit_idx that is 0 and not BIT(0)
Michael
> Maxime
>
> --
> Maxime Ripard, Bootlin (formerly Free Electrons)
> Embedded Linux and Kernel engineering
> https://bootlin.com
--
| Michael Nazzareno Trimarchi Amarula Solutions BV |
| COO - Founder Cruquiuskade 47 |
| +31(0)851119172 Amsterdam 1018 AM NL |
| [`as] http://www.amarulasolutions.com |
^ permalink raw reply related
* [PATCH v4 5/9] drm/mediatek: add ddp component PWM1
From: CK Hu @ 2018-05-28 7:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527489507-24453-6-git-send-email-stu.hsieh@mediatek.com>
Hi, Stu:
On Mon, 2018-05-28 at 14:38 +0800, Stu Hsieh wrote:
> This patch add component PWM1 in mtk_ddp_matches
>
Reviewed-by: CK Hu <ck.hu@mediatek.com>
> Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> index 87acf6be87f6..a5c7ac2d162d 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> @@ -232,6 +232,7 @@ static const struct mtk_ddp_comp_match mtk_ddp_matches[DDP_COMPONENT_ID_MAX] = {
> [DDP_COMPONENT_OVL0] = { MTK_DISP_OVL, 0, NULL },
> [DDP_COMPONENT_OVL1] = { MTK_DISP_OVL, 1, NULL },
> [DDP_COMPONENT_PWM0] = { MTK_DISP_PWM, 0, NULL },
> + [DDP_COMPONENT_PWM1] = { MTK_DISP_PWM, 1, NULL },
> [DDP_COMPONENT_RDMA0] = { MTK_DISP_RDMA, 0, NULL },
> [DDP_COMPONENT_RDMA1] = { MTK_DISP_RDMA, 1, NULL },
> [DDP_COMPONENT_RDMA2] = { MTK_DISP_RDMA, 2, NULL },
^ permalink raw reply
* [PATCH v4 6/9] drm/mediatek: add ddp component PWM2
From: CK Hu @ 2018-05-28 7:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527489507-24453-7-git-send-email-stu.hsieh@mediatek.com>
Hi, Stu:
On Mon, 2018-05-28 at 14:38 +0800, Stu Hsieh wrote:
> This patch add component PWM2
>
Reviewed-by: CK Hu <ck.hu@mediatek.com>
> Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 1 +
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> index a5c7ac2d162d..86e8c9e5df41 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> @@ -233,6 +233,7 @@ static const struct mtk_ddp_comp_match mtk_ddp_matches[DDP_COMPONENT_ID_MAX] = {
> [DDP_COMPONENT_OVL1] = { MTK_DISP_OVL, 1, NULL },
> [DDP_COMPONENT_PWM0] = { MTK_DISP_PWM, 0, NULL },
> [DDP_COMPONENT_PWM1] = { MTK_DISP_PWM, 1, NULL },
> + [DDP_COMPONENT_PWM2] = { MTK_DISP_PWM, 2, NULL },
> [DDP_COMPONENT_RDMA0] = { MTK_DISP_RDMA, 0, NULL },
> [DDP_COMPONENT_RDMA1] = { MTK_DISP_RDMA, 1, NULL },
> [DDP_COMPONENT_RDMA2] = { MTK_DISP_RDMA, 2, NULL },
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> index 9b19fc4423f1..e00c2e798abd 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> @@ -56,6 +56,7 @@ enum mtk_ddp_comp_id {
> DDP_COMPONENT_OVL1,
> DDP_COMPONENT_PWM0,
> DDP_COMPONENT_PWM1,
> + DDP_COMPONENT_PWM2,
> DDP_COMPONENT_RDMA0,
> DDP_COMPONENT_RDMA1,
> DDP_COMPONENT_RDMA2,
^ permalink raw reply
* [PATCH v4 7/9] drm/mediatek: add connection from OD1 to RDMA1
From: CK Hu @ 2018-05-28 7:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527489507-24453-8-git-send-email-stu.hsieh@mediatek.com>
Hi, Stu:
On Mon, 2018-05-28 at 14:38 +0800, Stu Hsieh wrote:
> This patch add the connection from OD1 to RDMA1 for ext path.
>
Reviewed-by: CK Hu <ck.hu@mediatek.com>
> Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> index 58e44349e315..8bfc0debd2c2 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -75,6 +75,7 @@
>
> #define OVL0_MOUT_EN_COLOR0 0x1
> #define OD_MOUT_EN_RDMA0 0x1
> +#define OD1_MOUT_EN_RDMA1 BIT(16)
> #define UFOE_MOUT_EN_DSI0 0x1
> #define COLOR0_SEL_IN_OVL0 0x1
> #define OVL1_MOUT_EN_COLOR1 0x1
> @@ -151,6 +152,9 @@ static unsigned int mtk_ddp_mout_en(enum mtk_ddp_comp_id cur,
> } else if (cur == DDP_COMPONENT_GAMMA && next == DDP_COMPONENT_RDMA1) {
> *addr = DISP_REG_CONFIG_DISP_GAMMA_MOUT_EN;
> value = GAMMA_MOUT_EN_RDMA1;
> + } else if (cur == DDP_COMPONENT_OD1 && next == DDP_COMPONENT_RDMA1) {
> + *addr = DISP_REG_CONFIG_DISP_OD_MOUT_EN;
> + value = OD1_MOUT_EN_RDMA1;
> } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DPI0) {
> *addr = DISP_REG_CONFIG_DISP_RDMA1_MOUT_EN;
> value = RDMA1_MOUT_DPI0;
^ permalink raw reply
* [PATCH] pwm: stm32: fix build warning with CONFIG_DMA_ENGINE disabled
From: Fabrice Gasnier @ 2018-05-28 7:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180525210843.1821071-1-arnd@arndb.de>
On 05/25/2018 11:08 PM, Arnd Bergmann wrote:
> Without dmaengine support, we get a harmless warning about an
> unused function:
>
> drivers/pwm/pwm-stm32.c:166:12: error: 'stm32_pwm_capture' defined but not used [-Werror=unused-function]
>
> Changing the #ifdef to an IS_ENABLED() check shuts up that warning
> and is slightly nicer to read.
>
> Fixes: 53e38fe73f94 ("pwm: stm32: Add capture support")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> drivers/pwm/pwm-stm32.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
Hi Arnd,
Acked-by: Fabrice Gasnier <fabrice.gasnier@st.com>
Thanks,
Fabrice
>
> diff --git a/drivers/pwm/pwm-stm32.c b/drivers/pwm/pwm-stm32.c
> index 60bfc07c4912..97bbc1f18fd6 100644
> --- a/drivers/pwm/pwm-stm32.c
> +++ b/drivers/pwm/pwm-stm32.c
> @@ -484,9 +484,7 @@ static int stm32_pwm_apply_locked(struct pwm_chip *chip, struct pwm_device *pwm,
> static const struct pwm_ops stm32pwm_ops = {
> .owner = THIS_MODULE,
> .apply = stm32_pwm_apply_locked,
> -#if IS_ENABLED(CONFIG_DMA_ENGINE)
> - .capture = stm32_pwm_capture,
> -#endif
> + .capture = IS_ENABLED(CONFIG_DMA_ENGINE) ? stm32_pwm_capture : NULL,
> };
>
> static int stm32_pwm_set_breakinput(struct stm32_pwm *priv,
>
^ 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