* [PATCH 2/2] ARM64: dump: Convert to use DEFINE_SHOW_ATTRIBUTE macro
From: Peng Donglin @ 2018-06-13 1:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b55024472e101a33b3d6b098aa2ce23c5b5dd6f7.1528819790.git.dolinux.peng@gmail.com>
Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
Signed-off-by: Peng Donglin <dolinux.peng@gmail.com>
---
arch/arm64/mm/ptdump_debugfs.c | 13 +------------
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/arch/arm64/mm/ptdump_debugfs.c b/arch/arm64/mm/ptdump_debugfs.c
index 02b18f8..24d786f 100644
--- a/arch/arm64/mm/ptdump_debugfs.c
+++ b/arch/arm64/mm/ptdump_debugfs.c
@@ -10,18 +10,7 @@ static int ptdump_show(struct seq_file *m, void *v)
ptdump_walk_pgd(m, info);
return 0;
}
-
-static int ptdump_open(struct inode *inode, struct file *file)
-{
- return single_open(file, ptdump_show, inode->i_private);
-}
-
-static const struct file_operations ptdump_fops = {
- .open = ptdump_open,
- .read = seq_read,
- .llseek = seq_lseek,
- .release = single_release,
-};
+DEFINE_SHOW_ATTRIBUTE(ptdump);
int ptdump_debugfs_register(struct ptdump_info *info, const char *name)
{
--
2.7.4
^ permalink raw reply related
* [PATCH 0/2] Re-use DEFINE_SHOW_ATTRIBUTE() macro
From: Peng Donglin @ 2018-06-13 1:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b55024472e101a33b3d6b098aa2ce23c5b5dd6f7.1528819790.git.dolinux.peng@gmail.com>
...instead of open coding file operations followed by custom ->open()
callbacks per each attribute.
Peng Donglin (2):
ARM: dump: Convert to use DEFINE_SHOW_ATTRIBUTE macro
ARM64: dump: Convert to use DEFINE_SHOW_ATTRIBUTE macro
arch/arm/mm/ptdump_debugfs.c | 13 +------------
arch/arm64/mm/ptdump_debugfs.c | 13 +------------
2 files changed, 2 insertions(+), 24 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH 01/10] ARM: OMAP1: ams-delta: drop GPIO lookup table for serio device
From: Janusz Krzysztofik @ 2018-06-13 1:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180612222356.GD38773@dtor-ws>
On Wednesday, June 13, 2018 12:23:56 AM CEST Dmitry Torokhov wrote:
> Hi Janusz,
>
> On Sat, Jun 09, 2018 at 04:02:15PM +0200, Janusz Krzysztofik wrote:
> > GPIO lookup table for ams-delta-serio device was introduced by commit
> > 0486738928bf ("ARM: OMAP1: ams-delta: add GPIO lookup tables").
> > Unfortunately, a follow up patch "Input: ams_delta_serio: use GPIO
> > lookup table" was not accepted by subystem maintainer who requested
> > conversion of the driver to a platform driver, replacepemnt of IRQ GPIO
> > pin with IRQ resource, replacement of GPIO pin providing keyboard power
> > with a regulator and removal of remaining GPIO pins from the driver as
> > not handled by it.
> >
> > Let's start with removal of no the longer needed GPIO lookup table from
> > the board init file.
> >
> > Series created and tested on top of next-20180608 tag from linux-next
> > tree.
>
> This all is really nice (modulo a couple of questions), thank you for
> implementing this. How do you want to merge this? Through OMAP tree or
> input?
Hi Dmitry,
If Tony doesn't mind, I would prefer it merged through OMAP tree as I still
have a few board patches built on top of it in my queue.
Thanks,
Janusz
^ permalink raw reply
* [PATCH v2 01/27] clk: sunxi-ng: r40: Add minimal rate for video PLLs
From: Chen-Yu Tsai @ 2018-06-13 3:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180612200036.21483-2-jernej.skrabec@siol.net>
On Wed, Jun 13, 2018 at 4:00 AM, Jernej Skrabec <jernej.skrabec@siol.net> wrote:
> According to documentation and experience with other similar SoCs, video
> PLLs don't work stable if their output frequency is set below 192 MHz.
>
> Because of that, set minimal rate to both R40 video PLLs to 192 MHz.
>
> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
Reviewed-by: Chen-Yu Tsai <wens@csie.org>
^ permalink raw reply
* [PATCH v2 02/27] clk: sunxi-ng: r40: Allow setting parent rate to display related clocks
From: Chen-Yu Tsai @ 2018-06-13 3:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180612200036.21483-3-jernej.skrabec@siol.net>
On Wed, Jun 13, 2018 at 4:00 AM, Jernej Skrabec <jernej.skrabec@siol.net> wrote:
> Display related peripherals need precise clocks to operate correctly.
>
> Allow DE2, TCONs and HDMI to set parent clock.
>
> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
Reviewed-by: Chen-Yu Tsai <wens@csie.org>
^ permalink raw reply
* [PATCH 01/10] ARM: OMAP1: ams-delta: drop GPIO lookup table for serio device
From: Tony Lindgren @ 2018-06-13 4:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <69494657.T0PeNZxiFJ@z50>
* Janusz Krzysztofik <jmkrzyszt@gmail.com> [180613 01:18]:
> On Wednesday, June 13, 2018 12:23:56 AM CEST Dmitry Torokhov wrote:
> > Hi Janusz,
> >
> > On Sat, Jun 09, 2018 at 04:02:15PM +0200, Janusz Krzysztofik wrote:
> > > GPIO lookup table for ams-delta-serio device was introduced by commit
> > > 0486738928bf ("ARM: OMAP1: ams-delta: add GPIO lookup tables").
> > > Unfortunately, a follow up patch "Input: ams_delta_serio: use GPIO
> > > lookup table" was not accepted by subystem maintainer who requested
> > > conversion of the driver to a platform driver, replacepemnt of IRQ GPIO
> > > pin with IRQ resource, replacement of GPIO pin providing keyboard power
> > > with a regulator and removal of remaining GPIO pins from the driver as
> > > not handled by it.
> > >
> > > Let's start with removal of no the longer needed GPIO lookup table from
> > > the board init file.
> > >
> > > Series created and tested on top of next-20180608 tag from linux-next
> > > tree.
> >
> > This all is really nice (modulo a couple of questions), thank you for
> > implementing this. How do you want to merge this? Through OMAP tree or
> > input?
>
> Hi Dmitry,
>
> If Tony doesn't mind, I would prefer it merged through OMAP tree as I still
> have a few board patches built on top of it in my queue.
Works for me once Dmitry is happy with the patches.
Regards,
Tony
^ permalink raw reply
* [PATCH] arm64/mm: Introduce a variable to hold base address of linear region
From: Bhupesh Sharma @ 2018-06-13 5:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d801005a-5f7a-8fe4-a486-bc6443a406a3@arm.com>
Hi James,
On Tue, Jun 12, 2018 at 3:42 PM, James Morse <james.morse@arm.com> wrote:
> Hi Bhupesh, Ard,
>
> On 12/06/18 09:25, Bhupesh Sharma wrote:
>> On Tue, Jun 12, 2018 at 12:23 PM, Ard Biesheuvel
>> <ard.biesheuvel@linaro.org> wrote:
>>> On 12 June 2018 at 08:36, Bhupesh Sharma <bhsharma@redhat.com> wrote:
>>>> The start of the linear region map on a KASLR enabled ARM64 machine -
>>>> which supports a compatible EFI firmware (with EFI_RNG_PROTOCOL
>>>> support), is no longer correctly represented by the PAGE_OFFSET macro,
>>>> since it is defined as:
>>>>
>>>> (UL(1) << (VA_BITS - 1)) + 1)
>
>>> PAGE_OFFSET is the VA of the start of the linear map. The linear map
>>> can be sparsely populated with actual memory, regardless of whether
>>> KASLR is in effect or not. The only difference in the presence of
>>> KASLR is that there may be such a hole at the beginning, but that does
>>> not mean the linear map has moved, or that the value of PAGE_OFFSET is
>>> now wrong.
>
>>>> So taking an example of a platform with VA_BITS=48, this gives a static
>>>> value of:
>>>> PAGE_OFFSET = 0xffff800000000000
>>>>
>>>> However, for the KASLR case, we use the 'memstart_offset_seed'
>>>> to randomize the linear region - since 'memstart_addr' indicates the
>>>> start of physical RAM, we randomize the same on basis
>>>> of 'memstart_offset_seed' value.
>>>>
>>>> As the PAGE_OFFSET value is used presently by several user space
>>>> tools (for e.g. makedumpfile and crash tools) to determine the start
>>>> of linear region and hence to read addresses (like PT_NOTE fields) from
>>>> '/proc/kcore' for the non-KASLR boot cases, so it would be better to
>>>> use 'memblock_start_of_DRAM()' value (converted to virtual) as
>>>> the start of linear region for the KASLR cases and default to
>>>> the PAGE_OFFSET value for non-KASLR cases to indicate the start of
>>>> linear region.
>
>>> Userland code that assumes that the linear map cannot have a hole at
>>> the beginning should be fixed.
>
>> That is a separate case (although that needs fixing as well via a
>> kernel patch probably as the user-space tools rely on '/proc/iomem'
>> contents to determine the first System RAM/reserved range).
>
> This is for kexec-tools generating the kdump vmcore ELF headers in user-space?
Yes, but again, I would like to reiterate that the case where I see a
hole at the start of the System RAM range (as I listed above) is just
a specific case, which probably deserves a separate patch. The current
patch though is for a generic issue (please see more details below).
>> 1. In that particular case (see [1]) the EFI firmware sets the first
>> EFI block as EfiReservedMemType:
>>
>> Region1: 0x000000000000-0x000000200000 [EfiReservedMemType]
>> Region2: 0x000000200000-0x00000021fffff [EfiRuntimeServiceData]
>>
>> Since EFI firmware won't return the "EfiReservedMemType" memory to
>> Linux kernel,
>
> (Its linux that makes this choice in
> drivers/firmware/efi/arm-init.c::is_usable_memory())
>
>
>> so the kernel can't get any info about the first mem
>> block, and kernel can only see region2 as below:
>>
>> efi: Processing EFI memory map:
>> efi: 0x000000200000-0x00000021ffff [Runtime Data |RUN| | |
>> | | | | |WB|WT|WC|UC]
>>
>> # head -1 /proc/iomem
>> 00200000-0021ffff : reserved
>>
>> 2a. If we add debug prints to 'arch/arm64/mm/init.c' to print the
>> kernel Virtual map we can see that the memory node is set to:
>>
>> # dmesg | grep memory
>> ..........
>> memory : 0xffff800000200000 - 0xffff801800000000
>>
>> 2b. Now if we use kexec-tools to obtain a crash vmcore we can see that
>> if we use 'readelf' to get the last program Header from vmcore (logs
>> below are for the non-kaslr case):
>>
>> # readelf -l vmcore
>>
>> ELF Header:
>> ........................
>>
>> Program Headers:
>> Type Offset VirtAddr PhysAddr
>> FileSiz MemSiz Flags Align
>> ..............................................................................................................................................................
>> LOAD 0x0000000076d40000 0xffff80017fe00000 0x0000000180000000
>> 0x0000001680000000 0x0000001680000000 RWE 0
>>
>> 3. So if we do a simple calculation:
>>
>> (VirtAddr + MemSiz) = 0xffff80017fe00000 + 0x0000001680000000 =
>> 0xFFFF8017FFE00000 != 0xffff801800000000.
>>
>> which indicates that the end virtual memory nodes are not the same
>> between vmlinux and vmcore.
>
> If I've followed this properly: the problem is that to generate the ELF headers
> in the post-kdump vmcore, at kdump-load-time kexec-tools has to guess the
> virtual addresses of the 'System RAM' regions it can see in /proc/iomem.
>
> The problem you are hitting is an invisible hole at the beginning of RAM,
> meaning user-space's guess_phys_to_virt() is off by the size of this hole.
>
> Isn't KASLR a special case for this? You must have to correct for that after
> kdump has happened, based on an elf-note in the vmcore. Can't we always do this?
No, I hit this issue both for the KASLR and non-KASLR boot cases. We
can fix this either in kernel or user-space.
Fixing this in kernel space seems better to me as the definition of
'memstart_addr' is that it indicates the start of the physical ram,
but since in this case there is a hole at the start of the system ram
visible in Linux (and thus to user-space), but 'memstart_addr' is
still 0 which seems contradictory at the least. This causes PHY_OFFSET
to be 0 as well, which is again contradictory.
>> This happens because the kexec-tools rely on 'proc/iomem' contents
>> while 'memstart_addr' is computed as 0 by kernel (as value of
>> memblock_start_of_DRAM() < ARM64_MEMSTART_ALIGN).
>
>> Returning back to this patch, this is a generic requirement where we
>> need the linear region start/base addresses in user-space applications
>> which is used to read addresses which lie in the linear region (for
>> e.g. when we read /proc/kcore contents).
>
>
>>>> I tested this on my qualcomm (which supports EFI_RNG_PROTOCOL)
>>>> and apm mustang (which does not support EFI_RNG_PROTOCOL) arm64 boards
>>>> and was able to use a modified user space utility (like kexec-tools and
>>>> makedumpfile) to determine the start of linear region correctly for
>>>> both the KASLR and non-KASLR boot cases.
>>>>
>>>
>>> Can you explain the nature of the changes to the userland code?
>>
>> The changes are not to rely on the fixed PAGE_OFFSET macro value for
>> determining the base address of the linear region, but rather read the
>> ' linear_reg_start_addr' symbol from kernel and use the same both in
>> case of KASLR and non-KASLR boots to determine the base of the linear
>> region (in [2], I have implemented a test change to kexec-tools to
>> read the 'linear_reg_start_addr' symbol which is available on my
>
> Don't use /dev/mem.
I just used it as a quick hack, we can use other approaches as well.
>> public github tree, I have a similar change available in makedumpfile
>> which I have not yet pushed to github, as it implements other features
>> as well)
>
>>>> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
>>>> index 49d99214f43c..bfd0915ecaf8 100644
>>>> --- a/arch/arm64/include/asm/memory.h
>>>> +++ b/arch/arm64/include/asm/memory.h
>>>> @@ -178,6 +178,9 @@ extern s64 memstart_addr;
>>>> /* PHYS_OFFSET - the physical address of the start of memory. */
>>>> #define PHYS_OFFSET ({ VM_BUG_ON(memstart_addr & 1); memstart_addr; })
>>>>
>>>> +/* the virtual base of the linear region. */
>>>> +extern s64 linear_reg_start_addr;
>>>> +
>>>> /* the virtual base of the kernel image (minus TEXT_OFFSET) */
>>>> extern u64 kimage_vaddr;
>>>>
>>>> diff --git a/arch/arm64/kernel/arm64ksyms.c b/arch/arm64/kernel/arm64ksyms.c
>>>> index d894a20b70b2..a92238ea45ff 100644
>>>> --- a/arch/arm64/kernel/arm64ksyms.c
>>>> +++ b/arch/arm64/kernel/arm64ksyms.c
>>>> @@ -42,6 +42,7 @@ EXPORT_SYMBOL(__arch_copy_in_user);
>>>>
>>>> /* physical memory */
>>>> EXPORT_SYMBOL(memstart_addr);
>>>> +EXPORT_SYMBOL(linear_reg_start_addr);
>>>>
>>>> /* string / mem functions */
>>>> EXPORT_SYMBOL(strchr);
>>>> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
>>>> index 325cfb3b858a..29447adb0eef 100644
>>>> --- a/arch/arm64/mm/init.c
>>>> +++ b/arch/arm64/mm/init.c
>>>> @@ -60,6 +60,7 @@
>>>> * that cannot be mistaken for a real physical address.
>>>> */
>>>> s64 memstart_addr __ro_after_init = -1;
>>>> +s64 linear_reg_start_addr __ro_after_init = PAGE_OFFSET;
>>>> phys_addr_t arm64_dma_phys_limit __ro_after_init;
>>>>
>>>> #ifdef CONFIG_BLK_DEV_INITRD
>>>> @@ -452,6 +453,8 @@ void __init arm64_memblock_init(void)
>>>> }
>>>> }
>>>>
>>>> + linear_reg_start_addr = __phys_to_virt(memblock_start_of_DRAM());
>
> This patch adds a variable that nothing uses, its going to be removed. You can't
> depend on reading this via /dev/mem.
>
> Could you add the information you need as an elf-note to the vmcore instead? You
> must already pick these up to handle kaslr. (from memory, this is where the
> kaslr-offset is described to user-space after we kdump).
No you are mixing up the two cases (please see above), the issue which
this patch fixes is for use cases where we don't have the vmcore
available in case of 'live' debugging via makedumpfile and crash tools
(we only have '/proc/kcore' or 'vmlinux' available in such cases). I
detailed the use case in [1] better (in a reply to Ard), I will detail
the use-case again below:
One specific use case that I am working on at the moment is the
makedumpfile '--mem-usage', which allows one to see the page numbers
of current system (1st kernel) in different use (please see
MAKEDUMPFILE(8) for more details).
Using this we can know how many pages are dumpable when different
dump_level is specified when invoking the makedumpfile.
Normally, makedumpfile analyses the contents of '/proc/kcore' (while
excluding the crashkernel range), and then calculates the page number
of different kind per vmcoreinfo.
For e.g. here is an output from my arm64 board (a non KASLR boot):
TYPE PAGES EXCLUDABLE DESCRIPTION
----------------------------------------------------------------------
ZERO 49524 yes Pages
filled with zero
NON_PRI_CACHE 15143 yes Cache
pages without private flag
PRI_CACHE 29147 yes Cache
pages with private flag
USER 3684 yes User process pages
FREE 1450569 yes Free pages
KERN_DATA 14243 no Dumpable kernel data
page size: 65536
Total pages on system: 1562310
Total size on system: 102387548160 Byte
This use case requires directly reading the '/proc/kcore' and the
hence the PAGE_OFFSET value is used to determine the base address of
the linear region, whose value is not static in case of KASLR boot.
Another use-case is where the crash-utility uses the PAGE_OFFSET value
to perform a virtual-to-physical conversion for the address lying in
the linear region:
ulong
arm64_VTOP(ulong addr)
{
if (machdep->flags & NEW_VMEMMAP) {
if (addr >= machdep->machspec->page_offset)
return machdep->machspec->phys_offset
+ (addr - machdep->machspec->page_offset);
<..snip..>
}
[1] https://www.spinics.net/lists/arm-kernel/msg656751.html
Regards,
Bhupesh
^ permalink raw reply
* [PATCH 04/28] drm/mediatek: add ddp component OD1
From: CK Hu @ 2018-06-13 5:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528687580-549-5-git-send-email-stu.hsieh@mediatek.com>
On Mon, 2018-06-11 at 11:25 +0800, Stu Hsieh wrote:
> This patch add the component OD1 and
> rename the OD to OD0
>
> 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 | 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
* [PATCH 07/28] drm/mediatek: add component DPI1
From: CK Hu @ 2018-06-13 5:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528687580-549-8-git-send-email-stu.hsieh@mediatek.com>
On Mon, 2018-06-11 at 11:25 +0800, Stu Hsieh wrote:
> This patch add the component DPI1
>
> Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com>
Reviewed-by: CK Hu <ck.hu@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 86e8c9e5df41..4f9d81025d69 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> @@ -224,6 +224,7 @@ static const struct mtk_ddp_comp_match mtk_ddp_matches[DDP_COMPONENT_ID_MAX] = {
> [DDP_COMPONENT_COLOR0] = { MTK_DISP_COLOR, 0, NULL },
> [DDP_COMPONENT_COLOR1] = { MTK_DISP_COLOR, 1, NULL },
> [DDP_COMPONENT_DPI0] = { MTK_DPI, 0, NULL },
> + [DDP_COMPONENT_DPI1] = { MTK_DPI, 1, NULL },
> [DDP_COMPONENT_DSI0] = { MTK_DSI, 0, NULL },
> [DDP_COMPONENT_DSI1] = { MTK_DSI, 1, NULL },
> [DDP_COMPONENT_GAMMA] = { MTK_DISP_GAMMA, 0, &ddp_gamma },
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> index e00c2e798abd..54c99c169093 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> @@ -47,6 +47,7 @@ enum mtk_ddp_comp_id {
> DDP_COMPONENT_COLOR0,
> DDP_COMPONENT_COLOR1,
> DDP_COMPONENT_DPI0,
> + DDP_COMPONENT_DPI1,
> DDP_COMPONENT_DSI0,
> DDP_COMPONENT_DSI1,
> DDP_COMPONENT_GAMMA,
^ permalink raw reply
* [PATCH 08/28] drm/mediatek: add component DSI2
From: CK Hu @ 2018-06-13 5:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528687580-549-9-git-send-email-stu.hsieh@mediatek.com>
On Mon, 2018-06-11 at 11:26 +0800, Stu Hsieh wrote:
> This patch add the component DSI2
>
> Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com>
Reviewed-by: CK Hu <ck.hu@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 4f9d81025d69..192f7374d988 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> @@ -227,6 +227,7 @@ static const struct mtk_ddp_comp_match mtk_ddp_matches[DDP_COMPONENT_ID_MAX] = {
> [DDP_COMPONENT_DPI1] = { MTK_DPI, 1, NULL },
> [DDP_COMPONENT_DSI0] = { MTK_DSI, 0, NULL },
> [DDP_COMPONENT_DSI1] = { MTK_DSI, 1, NULL },
> + [DDP_COMPONENT_DSI2] = { MTK_DSI, 2, NULL },
> [DDP_COMPONENT_GAMMA] = { MTK_DISP_GAMMA, 0, &ddp_gamma },
> [DDP_COMPONENT_OD0] = { MTK_DISP_OD, 0, &ddp_od },
> [DDP_COMPONENT_OD1] = { MTK_DISP_OD, 1, &ddp_od },
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> index 54c99c169093..8d152b337f15 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> @@ -50,6 +50,7 @@ enum mtk_ddp_comp_id {
> DDP_COMPONENT_DPI1,
> DDP_COMPONENT_DSI0,
> DDP_COMPONENT_DSI1,
> + DDP_COMPONENT_DSI2,
> DDP_COMPONENT_GAMMA,
> DDP_COMPONENT_OD0,
> DDP_COMPONENT_OD1,
^ permalink raw reply
* [PATCH 09/28] drm/mediatek: add component DSI3
From: CK Hu @ 2018-06-13 5:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528687580-549-10-git-send-email-stu.hsieh@mediatek.com>
Hi, Stu:
On Mon, 2018-06-11 at 11:26 +0800, Stu Hsieh wrote:
> This patch add the component DSI3
>
> 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 192f7374d988..fe6fdc021fc7 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> @@ -228,6 +228,7 @@ 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_DSI2] = { MTK_DSI, 2, NULL },
> + [DDP_COMPONENT_DSI2] = { MTK_DSI, 3, NULL },
DDP_COMPONENT_DSI3
Regards,
CK
> [DDP_COMPONENT_GAMMA] = { MTK_DISP_GAMMA, 0, &ddp_gamma },
> [DDP_COMPONENT_OD0] = { MTK_DISP_OD, 0, &ddp_od },
> [DDP_COMPONENT_OD1] = { MTK_DISP_OD, 1, &ddp_od },
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> index 8d152b337f15..7413ffeb3c9d 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> @@ -51,6 +51,7 @@ enum mtk_ddp_comp_id {
> DDP_COMPONENT_DSI0,
> DDP_COMPONENT_DSI1,
> DDP_COMPONENT_DSI2,
> + DDP_COMPONENT_DSI3,
> DDP_COMPONENT_GAMMA,
> DDP_COMPONENT_OD0,
> DDP_COMPONENT_OD1,
^ permalink raw reply
* [PATCH 11/28] drm/mediatek: add connection from RDMA0 to DPI0
From: CK Hu @ 2018-06-13 5:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528687580-549-12-git-send-email-stu.hsieh@mediatek.com>
On Mon, 2018-06-11 at 11:26 +0800, Stu Hsieh wrote:
> This patch add the connection from RDMA0 to DPI0
>
> 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 | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> index 8bfc0debd2c2..d7953f2f6a36 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -29,6 +29,7 @@
> #define DISP_REG_CONFIG_DISP_COLOR0_SEL_IN 0x084
> #define DISP_REG_CONFIG_DISP_COLOR1_SEL_IN 0x088
> #define DISP_REG_CONFIG_DPI_SEL_IN 0x0ac
> +#define DISP_REG_CONFIG_DISP_RDMA0_MOUT_EN 0x0c4
> #define DISP_REG_CONFIG_DISP_RDMA1_MOUT_EN 0x0c8
> #define DISP_REG_CONFIG_MMSYS_CG_CON0 0x100
>
> @@ -80,6 +81,7 @@
> #define COLOR0_SEL_IN_OVL0 0x1
> #define OVL1_MOUT_EN_COLOR1 0x1
> #define GAMMA_MOUT_EN_RDMA1 0x1
> +#define RDMA0_MOUT_DPI0 0x2
> #define RDMA1_MOUT_DPI0 0x2
> #define DPI0_SEL_IN_RDMA1 0x1
> #define COLOR1_SEL_IN_OVL1 0x1
> @@ -155,6 +157,9 @@ static unsigned int mtk_ddp_mout_en(enum mtk_ddp_comp_id cur,
> } 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_RDMA0 && next == DDP_COMPONENT_DPI0) {
> + *addr = DISP_REG_CONFIG_DISP_RDMA0_MOUT_EN;
> + value = RDMA0_MOUT_DPI0;
> } 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 12/28] drm/mediatek: add connection from RDMA0 to DSI2
From: CK Hu @ 2018-06-13 5:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528687580-549-13-git-send-email-stu.hsieh@mediatek.com>
On Mon, 2018-06-11 at 11:26 +0800, Stu Hsieh wrote:
> This patch add the connection from RDMA0 to DSI2
>
> 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 | 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 d7953f2f6a36..c08aed8dae44 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -82,6 +82,7 @@
> #define OVL1_MOUT_EN_COLOR1 0x1
> #define GAMMA_MOUT_EN_RDMA1 0x1
> #define RDMA0_MOUT_DPI0 0x2
> +#define RDMA0_MOUT_DSI2 0x4
> #define RDMA1_MOUT_DPI0 0x2
> #define DPI0_SEL_IN_RDMA1 0x1
> #define COLOR1_SEL_IN_OVL1 0x1
> @@ -160,6 +161,9 @@ static unsigned int mtk_ddp_mout_en(enum mtk_ddp_comp_id cur,
> } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DPI0) {
> *addr = DISP_REG_CONFIG_DISP_RDMA0_MOUT_EN;
> value = RDMA0_MOUT_DPI0;
> + } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DSI2) {
> + *addr = DISP_REG_CONFIG_DISP_RDMA0_MOUT_EN;
> + value = RDMA0_MOUT_DSI2;
> } 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 13/28] drm/mediatek: add connection from RDMA0 to DSI3
From: CK Hu @ 2018-06-13 5:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528687580-549-14-git-send-email-stu.hsieh@mediatek.com>
Hi, Stu:
Two inline comment.
On Mon, 2018-06-11 at 11:26 +0800, Stu Hsieh wrote:
> This patch add the connection from RDMA0 to DSI3
>
> 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 | 2 +-
> 2 files changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> index c08aed8dae44..fed1b5704355 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -83,6 +83,7 @@
> #define GAMMA_MOUT_EN_RDMA1 0x1
> #define RDMA0_MOUT_DPI0 0x2
> #define RDMA0_MOUT_DSI2 0x4
> +#define RDMA0_MOUT_DSI3 0x5
Usually, each bit of a mout register represent a output enable. Is this
value 0x5 is a correct value?
> #define RDMA1_MOUT_DPI0 0x2
> #define DPI0_SEL_IN_RDMA1 0x1
> #define COLOR1_SEL_IN_OVL1 0x1
> @@ -164,6 +165,9 @@ static unsigned int mtk_ddp_mout_en(enum mtk_ddp_comp_id cur,
> } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DSI2) {
> *addr = DISP_REG_CONFIG_DISP_RDMA0_MOUT_EN;
> value = RDMA0_MOUT_DSI2;
> + } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DSI3) {
> + *addr = DISP_REG_CONFIG_DISP_RDMA0_MOUT_EN;
> + value = RDMA0_MOUT_DSI3;
> } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DPI0) {
> *addr = DISP_REG_CONFIG_DISP_RDMA1_MOUT_EN;
> value = RDMA1_MOUT_DPI0;
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> index fe6fdc021fc7..22f4c72fa785 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> @@ -228,7 +228,7 @@ 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_DSI2] = { MTK_DSI, 2, NULL },
> - [DDP_COMPONENT_DSI2] = { MTK_DSI, 3, NULL },
> + [DDP_COMPONENT_DSI3] = { MTK_DSI, 3, NULL },
I think this is not related to this patch.
Regards,
CK
> [DDP_COMPONENT_GAMMA] = { MTK_DISP_GAMMA, 0, &ddp_gamma },
> [DDP_COMPONENT_OD0] = { MTK_DISP_OD, 0, &ddp_od },
> [DDP_COMPONENT_OD1] = { MTK_DISP_OD, 1, &ddp_od },
^ permalink raw reply
* [PATCH v4 2/6] dt-bindings: add binding for atmel-usart in SPI mode
From: Lee Jones @ 2018-06-13 6:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180525171941.26766-3-radu.pirea@microchip.com>
On Fri, 25 May 2018, Radu Pirea wrote:
> This patch moves the bindings for serial from serial/atmel-usart.txt to
> mfd/atmel-usart.txt and adds bindings for USART in SPI mode.
>
> Signed-off-by: Radu Pirea <radu.pirea@microchip.com>
> ---
> .../bindings/{serial => mfd}/atmel-usart.txt | 25 +++++++++++++++++--
> 1 file changed, 23 insertions(+), 2 deletions(-)
> rename Documentation/devicetree/bindings/{serial => mfd}/atmel-usart.txt (76%)
For my own reference:
Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
--
Lee Jones [???]
Linaro Services Technical Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH 14/28] drm/mediatek: add connection from RDMA1 to DPI1
From: CK Hu @ 2018-06-13 6:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528687580-549-15-git-send-email-stu.hsieh@mediatek.com>
Hi, Stu:
On Mon, 2018-06-11 at 11:26 +0800, Stu Hsieh wrote:
> This patch add the connection from RDMA1 to DPI1
>
> Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> index fed1b5704355..4abd5dabeccf 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -85,7 +85,9 @@
> #define RDMA0_MOUT_DSI2 0x4
> #define RDMA0_MOUT_DSI3 0x5
> #define RDMA1_MOUT_DPI0 0x2
> +#define RDMA1_MOUT_DPI1 0x3
Usually, each bit of a mout register represent a output enable. Is this
value 0x3 a correct value?
Regards,
CK
> #define DPI0_SEL_IN_RDMA1 0x1
> +#define DPI1_SEL_IN_RDMA1 (0x1 << 8)
> #define COLOR1_SEL_IN_OVL1 0x1
>
> #define OVL_MOUT_EN_RDMA 0x1
> @@ -171,6 +173,9 @@ static unsigned int mtk_ddp_mout_en(enum mtk_ddp_comp_id cur,
> } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DPI0) {
> *addr = DISP_REG_CONFIG_DISP_RDMA1_MOUT_EN;
> value = RDMA1_MOUT_DPI0;
> + } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DPI1) {
> + *addr = DISP_REG_CONFIG_DISP_RDMA1_MOUT_EN;
> + value = RDMA1_MOUT_DPI1;
> } else {
> value = 0;
> }
> @@ -190,6 +195,9 @@ static unsigned int mtk_ddp_sel_in(enum mtk_ddp_comp_id cur,
> } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DPI0) {
> *addr = DISP_REG_CONFIG_DPI_SEL_IN;
> value = DPI0_SEL_IN_RDMA1;
> + } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DPI1) {
> + *addr = DISP_REG_CONFIG_DPI_SEL_IN;
> + value = DPI1_SEL_IN_RDMA1;
> } else if (cur == DDP_COMPONENT_OVL1 && next == DDP_COMPONENT_COLOR1) {
> *addr = DISP_REG_CONFIG_DISP_COLOR1_SEL_IN;
> value = COLOR1_SEL_IN_OVL1;
^ permalink raw reply
* [PATCH 0/4] emaclite bug fixes and code cleanup
From: Radhey Shyam Pandey @ 2018-06-13 6:35 UTC (permalink / raw)
To: linux-arm-kernel
This patch series fixes bug in emaclite remove and mdio_setup routines.
It does minor code cleanup.
Radhey Shyam Pandey (4):
net: emaclite: Fix position of lp->mii_bus assignment
net: emaclite: Fix MDIO bus unregister bug
net: emaclite: Remove unused 'has_mdio' flag.
net: emaclite: Remove xemaclite_mdio_setup return check
drivers/net/ethernet/xilinx/xilinx_emaclite.c | 12 ++++--------
1 files changed, 4 insertions(+), 8 deletions(-)
^ permalink raw reply
* [PATCH 1/4] net: emaclite: Fix position of lp->mii_bus assignment
From: Radhey Shyam Pandey @ 2018-06-13 6:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528871719-1681-1-git-send-email-radhey.shyam.pandey@xilinx.com>
To ensure MDIO bus is not double freed in remove() path
assign lp->mii_bus after MDIO bus registration.
Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
---
drivers/net/ethernet/xilinx/xilinx_emaclite.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/xilinx/xilinx_emaclite.c b/drivers/net/ethernet/xilinx/xilinx_emaclite.c
index 69e31ce..37989ce 100644
--- a/drivers/net/ethernet/xilinx/xilinx_emaclite.c
+++ b/drivers/net/ethernet/xilinx/xilinx_emaclite.c
@@ -863,14 +863,14 @@ static int xemaclite_mdio_setup(struct net_local *lp, struct device *dev)
bus->write = xemaclite_mdio_write;
bus->parent = dev;
- lp->mii_bus = bus;
-
rc = of_mdiobus_register(bus, np);
if (rc) {
dev_err(dev, "Failed to register mdio bus.\n");
goto err_register;
}
+ lp->mii_bus = bus;
+
return 0;
err_register:
--
1.7.1
^ permalink raw reply related
* [PATCH 2/4] net: emaclite: Fix MDIO bus unregister bug
From: Radhey Shyam Pandey @ 2018-06-13 6:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528871719-1681-1-git-send-email-radhey.shyam.pandey@xilinx.com>
Since 'has_mdio' flag is not used,sequence insmod->rmmod-> insmod
leads to failure as MDIO unregister doesn't happen in .remove().
Fix it by checking MII bus pointer instead.
Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
---
drivers/net/ethernet/xilinx/xilinx_emaclite.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/xilinx/xilinx_emaclite.c b/drivers/net/ethernet/xilinx/xilinx_emaclite.c
index 37989ce..06eb6c8 100644
--- a/drivers/net/ethernet/xilinx/xilinx_emaclite.c
+++ b/drivers/net/ethernet/xilinx/xilinx_emaclite.c
@@ -1191,7 +1191,7 @@ static int xemaclite_of_remove(struct platform_device *of_dev)
struct net_local *lp = netdev_priv(ndev);
/* Un-register the mii_bus, if configured */
- if (lp->has_mdio) {
+ if (lp->mii_bus) {
mdiobus_unregister(lp->mii_bus);
mdiobus_free(lp->mii_bus);
lp->mii_bus = NULL;
--
1.7.1
^ permalink raw reply related
* [PATCH 3/4] net: emaclite: Remove unused 'has_mdio' flag.
From: Radhey Shyam Pandey @ 2018-06-13 6:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528871719-1681-1-git-send-email-radhey.shyam.pandey@xilinx.com>
Remove unused 'has_mdio' flag.
Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
---
drivers/net/ethernet/xilinx/xilinx_emaclite.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/xilinx/xilinx_emaclite.c b/drivers/net/ethernet/xilinx/xilinx_emaclite.c
index 06eb6c8..ec4608e 100644
--- a/drivers/net/ethernet/xilinx/xilinx_emaclite.c
+++ b/drivers/net/ethernet/xilinx/xilinx_emaclite.c
@@ -123,7 +123,6 @@
* @phy_node: pointer to the PHY device node
* @mii_bus: pointer to the MII bus
* @last_link: last link status
- * @has_mdio: indicates whether MDIO is included in the HW
*/
struct net_local {
@@ -144,7 +143,6 @@ struct net_local {
struct mii_bus *mii_bus;
int last_link;
- bool has_mdio;
};
--
1.7.1
^ permalink raw reply related
* [PATCH 4/4] net: emaclite: Remove xemaclite_mdio_setup return check
From: Radhey Shyam Pandey @ 2018-06-13 6:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528871719-1681-1-git-send-email-radhey.shyam.pandey@xilinx.com>
Errors are already reported in xemaclite_mdio_setup so avoid
reporting it again.
Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
---
drivers/net/ethernet/xilinx/xilinx_emaclite.c | 4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/xilinx/xilinx_emaclite.c b/drivers/net/ethernet/xilinx/xilinx_emaclite.c
index ec4608e..2a0c06e 100644
--- a/drivers/net/ethernet/xilinx/xilinx_emaclite.c
+++ b/drivers/net/ethernet/xilinx/xilinx_emaclite.c
@@ -1143,9 +1143,7 @@ static int xemaclite_of_probe(struct platform_device *ofdev)
xemaclite_update_address(lp, ndev->dev_addr);
lp->phy_node = of_parse_phandle(ofdev->dev.of_node, "phy-handle", 0);
- rc = xemaclite_mdio_setup(lp, &ofdev->dev);
- if (rc)
- dev_warn(&ofdev->dev, "error registering MDIO bus\n");
+ xemaclite_mdio_setup(lp, &ofdev->dev);
dev_info(dev, "MAC address is now %pM\n", ndev->dev_addr);
--
1.7.1
^ permalink raw reply related
* [PATCH 15/28] drm/mediatek: add connection from RDMA1 to DSI1
From: CK Hu @ 2018-06-13 6:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528687580-549-16-git-send-email-stu.hsieh@mediatek.com>
Hi, Stu:
On Mon, 2018-06-11 at 11:26 +0800, Stu Hsieh wrote:
> This patch add the connection from RDMA1 to DSI1
>
> Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> index 4abd5dabeccf..7e4ad5580cf6 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -28,6 +28,7 @@
> #define DISP_REG_CONFIG_DISP_UFOE_MOUT_EN 0x050
> #define DISP_REG_CONFIG_DISP_COLOR0_SEL_IN 0x084
> #define DISP_REG_CONFIG_DISP_COLOR1_SEL_IN 0x088
> +#define DISP_REG_CONFIG_DSIO_SEL_IN 0x0a8
> #define DISP_REG_CONFIG_DPI_SEL_IN 0x0ac
> #define DISP_REG_CONFIG_DISP_RDMA0_MOUT_EN 0x0c4
> #define DISP_REG_CONFIG_DISP_RDMA1_MOUT_EN 0x0c8
> @@ -84,10 +85,12 @@
> #define RDMA0_MOUT_DPI0 0x2
> #define RDMA0_MOUT_DSI2 0x4
> #define RDMA0_MOUT_DSI3 0x5
> +#define RDMA1_MOUT_DSI1 0x1
> #define RDMA1_MOUT_DPI0 0x2
> #define RDMA1_MOUT_DPI1 0x3
> #define DPI0_SEL_IN_RDMA1 0x1
> #define DPI1_SEL_IN_RDMA1 (0x1 << 8)
> +#define DSI1_SEL_IN_RDMA1 0x1
> #define COLOR1_SEL_IN_OVL1 0x1
>
> #define OVL_MOUT_EN_RDMA 0x1
> @@ -170,6 +173,9 @@ static unsigned int mtk_ddp_mout_en(enum mtk_ddp_comp_id cur,
> } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DSI3) {
> *addr = DISP_REG_CONFIG_DISP_RDMA0_MOUT_EN;
> value = RDMA0_MOUT_DSI3;
> + } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DSI1) {
> + *addr = DISP_REG_CONFIG_DISP_RDMA1_MOUT_EN;
> + value = RDMA1_MOUT_DSI1;
> } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DPI0) {
> *addr = DISP_REG_CONFIG_DISP_RDMA1_MOUT_EN;
> value = RDMA1_MOUT_DPI0;
> @@ -198,6 +204,9 @@ static unsigned int mtk_ddp_sel_in(enum mtk_ddp_comp_id cur,
> } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DPI1) {
> *addr = DISP_REG_CONFIG_DPI_SEL_IN;
> value = DPI1_SEL_IN_RDMA1;
> + } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DSI1) {
> + *addr = DISP_REG_CONFIG_DSIO_SEL_IN;
Does data sheet use the naming 'DSI0'? You use this register to select
DSI1 input.
Regards,
CK
> + value = DSI1_SEL_IN_RDMA1;
> } else if (cur == DDP_COMPONENT_OVL1 && next == DDP_COMPONENT_COLOR1) {
> *addr = DISP_REG_CONFIG_DISP_COLOR1_SEL_IN;
> value = COLOR1_SEL_IN_OVL1;
^ permalink raw reply
* [PATCH 15/28] drm/mediatek: add connection from RDMA1 to DSI1
From: CK Hu @ 2018-06-13 6:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528872242.27532.0.camel@mtksdaap41>
Hi, Stu:
On Wed, 2018-06-13 at 14:44 +0800, CK Hu wrote:
> Hi, Stu:
>
> On Mon, 2018-06-11 at 11:26 +0800, Stu Hsieh wrote:
> > This patch add the connection from RDMA1 to DSI1
> >
> > Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com>
> > ---
> > drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 9 +++++++++
> > 1 file changed, 9 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > index 4abd5dabeccf..7e4ad5580cf6 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > @@ -28,6 +28,7 @@
> > #define DISP_REG_CONFIG_DISP_UFOE_MOUT_EN 0x050
> > #define DISP_REG_CONFIG_DISP_COLOR0_SEL_IN 0x084
> > #define DISP_REG_CONFIG_DISP_COLOR1_SEL_IN 0x088
> > +#define DISP_REG_CONFIG_DSIO_SEL_IN 0x0a8
> > #define DISP_REG_CONFIG_DPI_SEL_IN 0x0ac
> > #define DISP_REG_CONFIG_DISP_RDMA0_MOUT_EN 0x0c4
> > #define DISP_REG_CONFIG_DISP_RDMA1_MOUT_EN 0x0c8
> > @@ -84,10 +85,12 @@
> > #define RDMA0_MOUT_DPI0 0x2
> > #define RDMA0_MOUT_DSI2 0x4
> > #define RDMA0_MOUT_DSI3 0x5
> > +#define RDMA1_MOUT_DSI1 0x1
> > #define RDMA1_MOUT_DPI0 0x2
> > #define RDMA1_MOUT_DPI1 0x3
> > #define DPI0_SEL_IN_RDMA1 0x1
> > #define DPI1_SEL_IN_RDMA1 (0x1 << 8)
> > +#define DSI1_SEL_IN_RDMA1 0x1
> > #define COLOR1_SEL_IN_OVL1 0x1
> >
> > #define OVL_MOUT_EN_RDMA 0x1
> > @@ -170,6 +173,9 @@ static unsigned int mtk_ddp_mout_en(enum mtk_ddp_comp_id cur,
> > } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DSI3) {
> > *addr = DISP_REG_CONFIG_DISP_RDMA0_MOUT_EN;
> > value = RDMA0_MOUT_DSI3;
> > + } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DSI1) {
> > + *addr = DISP_REG_CONFIG_DISP_RDMA1_MOUT_EN;
> > + value = RDMA1_MOUT_DSI1;
> > } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DPI0) {
> > *addr = DISP_REG_CONFIG_DISP_RDMA1_MOUT_EN;
> > value = RDMA1_MOUT_DPI0;
> > @@ -198,6 +204,9 @@ static unsigned int mtk_ddp_sel_in(enum mtk_ddp_comp_id cur,
> > } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DPI1) {
> > *addr = DISP_REG_CONFIG_DPI_SEL_IN;
> > value = DPI1_SEL_IN_RDMA1;
> > + } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DSI1) {
> > + *addr = DISP_REG_CONFIG_DSIO_SEL_IN;
>
> Does data sheet use the naming 'DSI0'? You use this register to select
> DSI1 input.
This is DSIO not DSI0, so it's OK for me.
Reviewed-by: CK Hu <ck.hu@mediatek.com>
>
> Regards,
> CK
>
> > + value = DSI1_SEL_IN_RDMA1;
> > } else if (cur == DDP_COMPONENT_OVL1 && next == DDP_COMPONENT_COLOR1) {
> > *addr = DISP_REG_CONFIG_DISP_COLOR1_SEL_IN;
> > value = COLOR1_SEL_IN_OVL1;
>
^ permalink raw reply
* [PATCH 16/28] drm/mediatek: add connection from RDMA1 to DSI2
From: CK Hu @ 2018-06-13 7:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528687580-549-17-git-send-email-stu.hsieh@mediatek.com>
Hi, Stu:
On Mon, 2018-06-11 at 11:26 +0800, Stu Hsieh wrote:
> This patch add the connection from RDMA1 to DSI2
>
> 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 | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> index 7e4ad5580cf6..c3e647b04ffd 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -28,6 +28,7 @@
> #define DISP_REG_CONFIG_DISP_UFOE_MOUT_EN 0x050
> #define DISP_REG_CONFIG_DISP_COLOR0_SEL_IN 0x084
> #define DISP_REG_CONFIG_DISP_COLOR1_SEL_IN 0x088
> +#define DISP_REG_CONFIG_DSIE_SEL_IN 0x0a4
> #define DISP_REG_CONFIG_DSIO_SEL_IN 0x0a8
> #define DISP_REG_CONFIG_DPI_SEL_IN 0x0ac
> #define DISP_REG_CONFIG_DISP_RDMA0_MOUT_EN 0x0c4
> @@ -86,11 +87,13 @@
> #define RDMA0_MOUT_DSI2 0x4
> #define RDMA0_MOUT_DSI3 0x5
> #define RDMA1_MOUT_DSI1 0x1
> +#define RDMA1_MOUT_DSI2 0x4
> #define RDMA1_MOUT_DPI0 0x2
> #define RDMA1_MOUT_DPI1 0x3
> #define DPI0_SEL_IN_RDMA1 0x1
> #define DPI1_SEL_IN_RDMA1 (0x1 << 8)
> #define DSI1_SEL_IN_RDMA1 0x1
> +#define DSI2_SEL_IN_RDMA1 (0x1 << 16)
> #define COLOR1_SEL_IN_OVL1 0x1
>
> #define OVL_MOUT_EN_RDMA 0x1
> @@ -176,6 +179,9 @@ static unsigned int mtk_ddp_mout_en(enum mtk_ddp_comp_id cur,
> } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DSI1) {
> *addr = DISP_REG_CONFIG_DISP_RDMA1_MOUT_EN;
> value = RDMA1_MOUT_DSI1;
> + } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DSI2) {
> + *addr = DISP_REG_CONFIG_DISP_RDMA1_MOUT_EN;
> + value = RDMA1_MOUT_DSI2;
> } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DPI0) {
> *addr = DISP_REG_CONFIG_DISP_RDMA1_MOUT_EN;
> value = RDMA1_MOUT_DPI0;
> @@ -207,6 +213,9 @@ static unsigned int mtk_ddp_sel_in(enum mtk_ddp_comp_id cur,
> } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DSI1) {
> *addr = DISP_REG_CONFIG_DSIO_SEL_IN;
> value = DSI1_SEL_IN_RDMA1;
> + } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DSI2) {
> + *addr = DISP_REG_CONFIG_DSIE_SEL_IN;
> + value = DSI2_SEL_IN_RDMA1;
> } else if (cur == DDP_COMPONENT_OVL1 && next == DDP_COMPONENT_COLOR1) {
> *addr = DISP_REG_CONFIG_DISP_COLOR1_SEL_IN;
> value = COLOR1_SEL_IN_OVL1;
^ permalink raw reply
* [PATCH 17/28] drm/mediatek: add connection from RDMA1 to DSI3
From: CK Hu @ 2018-06-13 7:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528687580-549-18-git-send-email-stu.hsieh@mediatek.com>
Hi, Stu:
On Mon, 2018-06-11 at 11:26 +0800, Stu Hsieh wrote:
> This patch add the connection from RDMA1 to DSI3
>
> Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> index c3e647b04ffd..a5cee4b7f908 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -88,12 +88,14 @@
> #define RDMA0_MOUT_DSI3 0x5
> #define RDMA1_MOUT_DSI1 0x1
> #define RDMA1_MOUT_DSI2 0x4
> +#define RDMA1_MOUT_DSI3 0x5
Usually, each bit of a mout register represent a output enable. Is this
value 0x5 a correct value?
Regards,
CK
> #define RDMA1_MOUT_DPI0 0x2
> #define RDMA1_MOUT_DPI1 0x3
> #define DPI0_SEL_IN_RDMA1 0x1
> #define DPI1_SEL_IN_RDMA1 (0x1 << 8)
> #define DSI1_SEL_IN_RDMA1 0x1
> #define DSI2_SEL_IN_RDMA1 (0x1 << 16)
> +#define DSI3_SEL_IN_RDMA1 (0x1 << 16)
> #define COLOR1_SEL_IN_OVL1 0x1
>
> #define OVL_MOUT_EN_RDMA 0x1
> @@ -182,6 +184,9 @@ static unsigned int mtk_ddp_mout_en(enum mtk_ddp_comp_id cur,
> } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DSI2) {
> *addr = DISP_REG_CONFIG_DISP_RDMA1_MOUT_EN;
> value = RDMA1_MOUT_DSI2;
> + } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DSI3) {
> + *addr = DISP_REG_CONFIG_DISP_RDMA1_MOUT_EN;
> + value = RDMA1_MOUT_DSI3;
> } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DPI0) {
> *addr = DISP_REG_CONFIG_DISP_RDMA1_MOUT_EN;
> value = RDMA1_MOUT_DPI0;
> @@ -216,6 +221,9 @@ static unsigned int mtk_ddp_sel_in(enum mtk_ddp_comp_id cur,
> } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DSI2) {
> *addr = DISP_REG_CONFIG_DSIE_SEL_IN;
> value = DSI2_SEL_IN_RDMA1;
> + } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DSI3) {
> + *addr = DISP_REG_CONFIG_DSIO_SEL_IN;
> + value = DSI3_SEL_IN_RDMA1;
> } else if (cur == DDP_COMPONENT_OVL1 && next == DDP_COMPONENT_COLOR1) {
> *addr = DISP_REG_CONFIG_DISP_COLOR1_SEL_IN;
> value = COLOR1_SEL_IN_OVL1;
^ 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