* [PATCH] arm64/acpi: Add fixup for HPE m400 quirks
From: Mark Salter @ 2018-06-15 17:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8a3034b9-6cf3-5182-717f-dd1dc8a087aa@infradead.org>
On Fri, 2018-06-15 at 10:17 -0700, Geoff Levand wrote:
> > > + if (ACPI_SUCCESS(status) && !strncmp(header->oem_id, "HPE ", 6) &&
> > > + !strncmp(header->oem_table_id, "ProLiant", 8) &&
> >
> > You should match the affected range of OEM table revisions too, that way a
> > firmware upgrade should start working, instead of being permanently disabled
> > because we think its unlikely.
>
> The m400 has reached end of life. No one really expects to see any firmware
> update. I don't know what the effected OEM table revisions are, and I don't
> think there is an active platform maintainer who could give that info either.
>
> If someone can provide the info. I'll update the fix.
>
> > > + MIDR_IMPLEMENTOR(read_cpuid_id()) == ARM_CPU_IMP_APM) {
> >
> > How is the CPU implementer relevant?
>
> That was just a copy of what other fixes had. Should I remove it?
It was there because HPE ProLiant strings are generic and you may end up
disabling platforms which would otherwise work. It is the ProLiant system
based on the APM chipset which is the problem. Thus the check for cpu
implementor.
^ permalink raw reply
* [linux-sunxi] Re: [PATCH v2 11/27] drm/sun4i: tcon: Add support for tcon-top gate
From: Jernej Škrabec @ 2018-06-15 17:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v66UFRKRF4_zbm8nQJYoOHb-iLbiU_0iYWep=WNiQDftMQ@mail.gmail.com>
Dne petek, 15. junij 2018 ob 19:13:17 CEST je Chen-Yu Tsai napisal(a):
> On Sat, Jun 16, 2018 at 12:41 AM, Jernej ?krabec
>
> <jernej.skrabec@siol.net> wrote:
> > Hi,
> >
> > Dne petek, 15. junij 2018 ob 10:31:10 CEST je Maxime Ripard napisal(a):
> >> Hi,
> >>
> >> On Tue, Jun 12, 2018 at 10:00:20PM +0200, Jernej Skrabec wrote:
> >> > TV TCONs connected to TCON TOP have to enable additional gate in order
> >> > to work.
> >> >
> >> > Add support for such TCONs.
> >> >
> >> > Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> >> > ---
> >> >
> >> > drivers/gpu/drm/sun4i/sun4i_tcon.c | 11 +++++++++++
> >> > drivers/gpu/drm/sun4i/sun4i_tcon.h | 4 ++++
> >> > 2 files changed, 15 insertions(+)
> >> >
> >> > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> >> > b/drivers/gpu/drm/sun4i/sun4i_tcon.c index 08747fc3ee71..0afb5a94a414
> >> > 100644
> >> > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> >> > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> >> > @@ -688,6 +688,16 @@ static int sun4i_tcon_init_clocks(struct device
> >> > *dev,
> >> >
> >> > dev_err(dev, "Couldn't get the TCON bus clock\n");
> >> > return PTR_ERR(tcon->clk);
> >> >
> >> > }
> >> >
> >> > +
> >> > + if (tcon->quirks->has_tcon_top_gate) {
> >> > + tcon->top_clk = devm_clk_get(dev, "tcon-top");
> >> > + if (IS_ERR(tcon->top_clk)) {
> >> > + dev_err(dev, "Couldn't get the TCON TOP bus
> >> > clock\n");
> >> > + return PTR_ERR(tcon->top_clk);
> >> > + }
> >> > + clk_prepare_enable(tcon->top_clk);
> >> > + }
> >> > +
> >>
> >> Is it required for the TCON itself to operate, or does the TCON
> >> requires the TCON TOP, which in turn requires that clock to be
> >> functional?
> >>
> >> I find it quite odd to have a clock that isn't meant for a particular
> >> device to actually be wired to another device. I'm not saying this
> >> isn't the case, but it would be a first.
> >
> > Documentation doesn't say much about that gate. I did few tests and TCON
> > registers can be read and written even if TCON TOP TV TCON gate is
> > disabled. However, there is no image, as expected.
>
> The R40 manual does include it in the diagram, on page 504. There's also a
> mux to select whether the clock comes directly from the CCU or the TV
> encoder (a feedback mode?). I assume this is the gate you are referring to
> here, in which case it is not a bus clock, but rather the TCON module or
> channel clock, strangely routed.
>
> > More interestingly, I enabled test pattern directly in TCON to eliminate
> > influence of the mixer. As soon as I disabled that gate, test pattern on
> > HDMI screen was gone, which suggest that this gate influences something
> > inside TCON.
> >
> > Another test I did was that I moved enable/disable gate code to
> > sun4i_tcon_channel_set_status() and it worked just as well.
> >
> > I'll ask AW engineer what that gate actually does, but from what I saw, I
> > would say that most appropriate location to enable/disable TCON TOP TV
> > TCON
> > gate is TCON driver. Alternatively, TCON TOP driver could check if any TV
> > TCON is in use and enable appropriate gate. However, that doesn't sound
> > right to me for some reason.
>
> If what I said above it true, then yes, the appropriate location to enable
> it is the TCON driver, but moreover, the representation of the clock tree
> should be fixed such that the TCON takes the clock from the TCON TOP as its
> channel/ module clock instead. That way you don't need this patch, but
> you'd add another for all the clock routing.
Can you be more specific? I not sure what you mean here.
Best regards,
Jernej
^ permalink raw reply
* [PATCH] MAINTAINERS: Remove the AT91 clk driver entry
From: Stephen Boyd @ 2018-06-15 17:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180613082936.14038-1-boris.brezillon@bootlin.com>
Quoting Boris Brezillon (2018-06-13 01:29:36)
> I've stopped actively maintaining this driver for quite some time
> already, and at91 maintainers are doing a good job at maintaining it.
> Remove the AT91 clk driver entry so that the driver automatically
> falls under the "ARM/Microchip (AT91) SoC support" entry.
>
> Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
> ---
Acked-by: Stephen Boyd <sboyd@kernel.org>
^ permalink raw reply
* [PATCH] arm64/acpi: Add fixup for HPE m400 quirks
From: Geoff Levand @ 2018-06-15 18:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5120aa9f167c19712c01dc812f689eaef23bf0c5.camel@redhat.com>
Hi Mark,
On 06/15/2018 10:33 AM, Mark Salter wrote:
> On Fri, 2018-06-15 at 10:17 -0700, Geoff Levand wrote:
>>>> + MIDR_IMPLEMENTOR(read_cpuid_id()) == ARM_CPU_IMP_APM) {
>>>
>>> How is the CPU implementer relevant?
>>
>> That was just a copy of what other fixes had. Should I remove it?
>
> It was there because HPE ProLiant strings are generic and you may end up
> disabling platforms which would otherwise work. It is the ProLiant system
> based on the APM chipset which is the problem. Thus the check for cpu
> implementor.
Your original fix that had this cpu implementor check was in the main
ACPI code, so would be built for other arches. This is now in
arch/arm64/kernel/acpi.c, which will only be built for arm64. Is that
enough to limit it, or do we still need the check?
-Geoff
^ permalink raw reply
* [PATCH v4 00/26] Fix some doc build warnings/errors and broken links
From: Jonathan Corbet @ 2018-06-15 19:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1529079119.git.mchehab+samsung@kernel.org>
On Fri, 15 Jun 2018 13:30:28 -0300
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
> As discussed during the review of v2, your plans were to merge
> things with potential to conflict with merges by the end of the
> merge window. So, I'm resubmitting it in order to help you with
> that.
Is there any chance you could send them directly Linusward with my ack?
I'm fighting a few real-world complications at the moment, and barely
have time to breathe...
Thanks,
jon
^ permalink raw reply
* [PATCH] arm64/acpi: Add fixup for HPE m400 quirks
From: Mark Salter @ 2018-06-15 19:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7a1768e2-bab5-c9f3-51b4-2131c9009498@infradead.org>
On Fri, 2018-06-15 at 11:15 -0700, Geoff Levand wrote:
> Hi Mark,
>
> On 06/15/2018 10:33 AM, Mark Salter wrote:
> > On Fri, 2018-06-15 at 10:17 -0700, Geoff Levand wrote:
> > > > > + MIDR_IMPLEMENTOR(read_cpuid_id()) == ARM_CPU_IMP_APM) {
> > > >
> > > > How is the CPU implementer relevant?
> > >
> > > That was just a copy of what other fixes had. Should I remove it?
> >
> > It was there because HPE ProLiant strings are generic and you may end up
> > disabling platforms which would otherwise work. It is the ProLiant system
> > based on the APM chipset which is the problem. Thus the check for cpu
> > implementor.
>
> Your original fix that had this cpu implementor check was in the main
> ACPI code, so would be built for other arches. This is now in
> arch/arm64/kernel/acpi.c, which will only be built for arm64. Is that
> enough to limit it, or do we still need the check?
The original code was protected by #ifdef ARM64. But yes, HPE has announced
another aarch64 ProLiant system based on Cavium ThunderX2. So we need to
allow everything but the APM XGene based ProLiant products.
^ permalink raw reply
* [PATCH 0/3] ARM: imx: Make DRM_MXSFB and FB_MXS coexist
From: Leonard Crestez @ 2018-06-15 19:43 UTC (permalink / raw)
To: linux-arm-kernel
Some imx boards have new drm-style bindings for lcdif devices but using
them requires rebuilding the kernel with FB_MXS=n DRM_MXSFB=y.
It is relatively easy to allow both drivers to coexist by renaming
drm/mxsfb to "mxsfb-drm" and making the old fbdev driver return -ENODEV
instead of -ENOENT when it fails to find the display node.
This makes display on imx6sx-sdb "just work" with both styles of
bindings. In order to test the old bindings I locally reverted commit
7caa59e0d40c ("ARM: dts: imx6sx-sdb: Convert from fbdev to drm bindings")
Leonard Crestez (3):
drm: mxsfb: Change driver.name to mxsfb-drm
fbdev: mxsfb: Return ENODEV on missing display node
ARM: imx_v6_v7_defconfig: Enable DRM_MXSFB
arch/arm/configs/imx_v6_v7_defconfig | 2 ++
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 2 +-
drivers/video/fbdev/mxsfb.c | 2 +-
3 files changed, 4 insertions(+), 2 deletions(-)
--
2.17.1
^ permalink raw reply
* [PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm
From: Leonard Crestez @ 2018-06-15 19:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1529091248.git.leonard.crestez@nxp.com>
The FBDEV driver uses the same name and both can't be registered at the
same time. Fix this by renaming the drm driver to mxsfb-drm
Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
---
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
index ffe5137ccaf8..dd1dd58e4956 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
@@ -417,11 +417,11 @@ static int mxsfb_remove(struct platform_device *pdev)
static struct platform_driver mxsfb_platform_driver = {
.probe = mxsfb_probe,
.remove = mxsfb_remove,
.id_table = mxsfb_devtype,
.driver = {
- .name = "mxsfb",
+ .name = "mxsfb-drm",
.of_match_table = mxsfb_dt_ids,
},
};
module_platform_driver(mxsfb_platform_driver);
--
2.17.1
^ permalink raw reply related
* [PATCH 2/3] fbdev: mxsfb: Return ENODEV on missing display node
From: Leonard Crestez @ 2018-06-15 19:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1529091248.git.leonard.crestez@nxp.com>
When this driver encounters drm-style bindings it returns -ENOENT and
this reports a probe error. Make it return -ENODEV to signal an explicit
rejection instead.
This allows peaceful coexistence between the DRM_MXSFB and FB_MXS config
options.
Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
---
drivers/video/fbdev/mxsfb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/mxsfb.c b/drivers/video/fbdev/mxsfb.c
index 12c8bd1d24d5..9ec8882d7b3d 100644
--- a/drivers/video/fbdev/mxsfb.c
+++ b/drivers/video/fbdev/mxsfb.c
@@ -736,11 +736,11 @@ static int mxsfb_init_fbinfo_dt(struct fb_info *fb_info,
int ret;
display_np = of_parse_phandle(np, "display", 0);
if (!display_np) {
dev_err(dev, "failed to find display phandle\n");
- return -ENOENT;
+ return -ENODEV;
}
ret = of_property_read_u32(display_np, "bus-width", &width);
if (ret < 0) {
dev_err(dev, "failed to get property bus-width\n");
--
2.17.1
^ permalink raw reply related
* [PATCH 3/3] ARM: imx_v6_v7_defconfig: Enable DRM_MXSFB
From: Leonard Crestez @ 2018-06-15 19:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1529091248.git.leonard.crestez@nxp.com>
Multiple boards have drm-style bindings on imx lcdif nodes, enable the
driver so that they work by default.
Also enable DRM_PANEL_SEIKO_43WVF1G, it is one of the supported display
attachments for imx development boards.
Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
---
arch/arm/configs/imx_v6_v7_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/configs/imx_v6_v7_defconfig b/arch/arm/configs/imx_v6_v7_defconfig
index f70507ab91ee..dd0f64da2243 100644
--- a/arch/arm/configs/imx_v6_v7_defconfig
+++ b/arch/arm/configs/imx_v6_v7_defconfig
@@ -256,18 +256,20 @@ CONFIG_VIDEO_ADV7180=m
CONFIG_VIDEO_OV5640=m
CONFIG_IMX_IPUV3_CORE=y
CONFIG_DRM=y
CONFIG_DRM_PANEL_LVDS=y
CONFIG_DRM_PANEL_SIMPLE=y
+CONFIG_DRM_PANEL_SEIKO_43WVF1G=y
CONFIG_DRM_DW_HDMI_AHB_AUDIO=m
CONFIG_DRM_DW_HDMI_CEC=y
CONFIG_DRM_IMX=y
CONFIG_DRM_IMX_PARALLEL_DISPLAY=y
CONFIG_DRM_IMX_TVE=y
CONFIG_DRM_IMX_LDB=y
CONFIG_DRM_IMX_HDMI=y
CONFIG_DRM_ETNAVIV=y
+CONFIG_DRM_MXSFB=y
CONFIG_FB_MXS=y
CONFIG_LCD_CLASS_DEVICE=y
CONFIG_LCD_L4F00242T03=y
CONFIG_LCD_PLATFORM=y
CONFIG_BACKLIGHT_PWM=y
--
2.17.1
^ permalink raw reply related
* [PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm
From: Fabio Estevam @ 2018-06-15 19:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <47ea7572011735b68a8a70f0e11bdf00cb2fd86a.1529091248.git.leonard.crestez@nxp.com>
Hi Leonard,
On Fri, Jun 15, 2018 at 4:43 PM, Leonard Crestez
<leonard.crestez@nxp.com> wrote:
> The FBDEV driver uses the same name and both can't be registered at the
> same time. Fix this by renaming the drm driver to mxsfb-drm
>
> Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
Stefan sent the same patch a few days ago:
https://www.spinics.net/lists/dri-devel/msg179489.html
^ permalink raw reply
* [PATCH] arm64/mm: Introduce a variable to hold base address of linear region
From: Bhupesh Sharma @ 2018-06-15 20:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180615165225.GD2202@arm.com>
Hi Will,
On Fri, Jun 15, 2018 at 10:22 PM, Will Deacon <will.deacon@arm.com> wrote:
> Hi Bhupesh,
>
> On Thu, Jun 14, 2018 at 11:53:53AM +0530, Bhupesh Sharma wrote:
>> On Wed, Jun 13, 2018 at 3:41 PM, Will Deacon <will.deacon@arm.com> wrote:
>> > On Wed, Jun 13, 2018 at 10:46:56AM +0530, Bhupesh Sharma wrote:
>> >> On Tue, Jun 12, 2018 at 3:42 PM, James Morse <james.morse@arm.com> wrote:
>> >> > On 12/06/18 09:25, Bhupesh Sharma wrote:
>> >> >> 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.
>> >
>> > Contradictory to who?
>>
>> I meant that the 'memstart_addr' and PHY_OFFSET value are computed as
>> 0 in the above particular case, which is not the real representation
>> of the start of System RAM as the 1st memory block available in Linux
>> starts from 2MB [as confirmed by the 'memblock_start_of_DRAM()' value
>> of 0x200000] and indicated by '/proc/iomem':
>>
>> # head -1 /proc/iomem
>> 00200000-0021ffff : reserved
>
> Who said it's supposed to be the "real representation of the start of System
> RAM"? The kernel is fine with this being 0 in the case you describe. How
> about we rename the variable to 'memstart_addr_sometimes_zero'? Does that
> help?
Other architectures (like ppc) have historically used 'memstart_addr'
as the representation of the start of System RAM (and it probably
inspired the usage of the same in arm64, but I am not sure..).
$ grep -inr "memstart_addr" arch/powerpc/
<..snip..>
arch/powerpc/include/asm/page.h:123:#define MEMORY_START memstart_addr
<..snip..>
If we want to have a special interpretation of 'memstart_addr' for
arm64, I personally have no issues with it (other than it being, well
*confusing*), so I would leave that to your and other arm64
maintainer's discretion.
>> > Userspace has no business messing around with this
>> > stuff and I'm reluctant to make this an ABI by adding a symbol with a
>> > special name. Why can't the various constants needed by these tools be
>> > exported in the ELF headers for kcore/vmcore, or as a NOTE as James
>> > suggests? That sounds a lot less fragile to me.
>>
>> But we already add the 'memstart_addr' variable to kallsyms in the
>> kernel, don't we? And so user-space tools do use the same - so we
>> already have a precedent available.
>
> Whoa, whoa -- hold up! The implication here is that variables exposed via
> kallsyms are ABI. That's simply not true, otherwise we'd be breaking the
> ABI every kernel release.
I understand, but just to provide a detailed background, since we have
use cases in user-space currently (for tools like crash-utility and
makedumpfile), where we need to perform a virt_to_phys conversion to
determine the physical address of an equivalent virtual address and we
need similar computation as done in kernel's 'memory.h':
phys_addr_t __x = (phys_addr_t)(x); \
__x & BIT(VA_BITS - 1) ? (__x & ~PAGE_OFFSET) + PHYS_OFFSET : \
(__x - kimage_voffset); })
Also since we define PHYS_OFFSET as:
# define PHYS_OFFSET ({ VM_BUG_ON(memstart_addr & 1); memstart_addr; })
So, currently we calculate PHYS_OFFSET (or 'memstart_addr' value), in
user-space by reading '/proc/iomem' nodes (or read the 'memstart_addr'
value via '/dev/mem' which is available via '/proc/kallsyms') and use
the same to perform the virt_to_phy conversions.
An example of how we do the same virt_to_phy conversions in the
crash-utility code (see [1]) is shared below for reference:
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);
else if (machdep->machspec->kimage_voffset)
return addr - machdep->machspec->kimage_voffset;
else /* no randomness */
return machdep->machspec->phys_offset
+ (addr - machdep->machspec->vmalloc_start_addr);
} else {
return machdep->machspec->phys_offset
+ (addr - machdep->machspec->page_offset);
}
}
Please share your views.
[1] https://github.com/crash-utility/crash/blob/master/arm64.c#L955
Thanks,
Bhupesh
^ permalink raw reply
* [PATCH 1/2] ARM: dts: imx6qdl-sabreauto: Add sensors
From: Fabio Estevam @ 2018-06-15 20:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a20cc6a0c278cc2791c0bdfc30a79b022de396ef.camel@nxp.com>
On Thu, Jun 14, 2018 at 7:17 AM, Leonard Crestez
<leonard.crestez@nxp.com> wrote:
> Should I also assign a label, like "isl29023: light-sensor at 44"? I
> couldn't find any recommendation on this.
>
> There are no immediate uses for a label but this practice is very
> common. Having labels allows creating minor board variants with reduced
> churn in the base dts so it seems good.
In the case of this specific board we don't have board variants, so no
need to add a label.
^ permalink raw reply
* [PATCH v4 00/26] Fix some doc build warnings/errors and broken links
From: Mauro Carvalho Chehab @ 2018-06-15 20:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180615130951.303a3ebb@lwn.net>
Em Fri, 15 Jun 2018 13:09:51 -0600
Jonathan Corbet <corbet@lwn.net> escreveu:
> On Fri, 15 Jun 2018 13:30:28 -0300
> Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
>
> > As discussed during the review of v2, your plans were to merge
> > things with potential to conflict with merges by the end of the
> > merge window. So, I'm resubmitting it in order to help you with
> > that.
>
> Is there any chance you could send them directly Linusward with my ack?
> I'm fighting a few real-world complications at the moment, and barely
> have time to breathe...
Ok, I'll send him a pull request (likely tomorrow), adding your
ack on the patches at this series.
Regards,
Mauro
^ permalink raw reply
* [PATCH] Revert "drm/sun4i: Handle DRM_BUS_FLAG_PIXDATA_*EDGE"
From: Giulio Benetti @ 2018-06-15 20:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <99b2583187fe9925251029e876b061aac9172597.camel@bootlin.com>
Hi Paul,
Il 14/06/2018 09:26, Paul Kocialkowski ha scritto:
> Hi,
>
> On Wed, 2018-06-13 at 23:52 +0200, Giulio Benetti wrote:
>> Hello,
>>
>> sorry for my ignorance.
>> I don't know the right patch workflow in the case of "revert commit".
>> When I fix this bug, should I have to re-submit the previous patch
>> entire plus bug-fix?
>>
>> Or do I have to submit patch with bug-fix only?
>
> Yes, that is usually how it works! The revert patch will be picked up by
> the maintainer (Maxime), integrated in his tree and eventually merged
> into Linus' tree (along with stable trees).
>
> Fixup patches for this will need to take into account the revert patch,
> so it becomes equivalent to submitting the same patch with that issue
> resolved.
Thanks for explaining me.
I'm going to submit new patch asap.
Giulio
^ permalink raw reply
* [PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm
From: Leonard Crestez @ 2018-06-15 20:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5B8i0gN+rCq-yPrd112NkwJWTxYCtsLVeLhD1JLRuX6EQ@mail.gmail.com>
On Fri, 2018-06-15 at 16:47 -0300, Fabio Estevam wrote:
> On Fri, Jun 15, 2018 at 4:43 PM, Leonard Crestez
> <leonard.crestez@nxp.com> wrote:
> > The FBDEV driver uses the same name and both can't be registered at the
> > same time. Fix this by renaming the drm driver to mxsfb-drm
> >
> > Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
>
> Stefan sent the same patch a few days ago:
> http://www.spinics.net/lists/dri-devel/msg179489.html
In that thread there is a proposal for removing the old fbdev/mxsfb
driver entirely.
That would break old DTBs, isn't this generally considered bad? Also,
are we sure the removal of fbdev/mxsfb wouldn't lose any features?
What my series does is make both drivers work with the same kernel
image and turns the choice into a board-level dtb decision. Supporting
everything at once seems desirable to me and it allows for a very
smooth upgrade path.
The old driver could be removed later, after all users are converted.
--
Regards,
Leonard
^ permalink raw reply
* [PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm
From: Fabio Estevam @ 2018-06-15 21:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <07be6d9a85b6be655fc2b084be81d8bf9715b57a.camel@nxp.com>
On Fri, Jun 15, 2018 at 5:58 PM, Leonard Crestez
<leonard.crestez@nxp.com> wrote:
> In that thread there is a proposal for removing the old fbdev/mxsfb
> driver entirely.
>
> That would break old DTBs, isn't this generally considered bad? Also,
> are we sure the removal of fbdev/mxsfb wouldn't lose any features?
Yes, I also think we should not break old dtb's.
> What my series does is make both drivers work with the same kernel
> image and turns the choice into a board-level dtb decision. Supporting
> everything at once seems desirable to me and it allows for a very
> smooth upgrade path.
>
> The old driver could be removed later, after all users are converted.
Agreed.
Maybe the mxs fbdev driver needs to warn users saying that that the
driver is deprecated and the bindings need to be updated to the DRM
bindings style.
^ permalink raw reply
* [PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm
From: Marek Vasut @ 2018-06-15 21:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <07be6d9a85b6be655fc2b084be81d8bf9715b57a.camel@nxp.com>
On 06/15/2018 10:58 PM, Leonard Crestez wrote:
> On Fri, 2018-06-15 at 16:47 -0300, Fabio Estevam wrote:
>
>> On Fri, Jun 15, 2018 at 4:43 PM, Leonard Crestez
>> <leonard.crestez@nxp.com> wrote:
>>> The FBDEV driver uses the same name and both can't be registered at the
>>> same time. Fix this by renaming the drm driver to mxsfb-drm
>>>
>>> Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
>>
>> Stefan sent the same patch a few days ago:
>> http://www.spinics.net/lists/dri-devel/msg179489.html
>
> In that thread there is a proposal for removing the old fbdev/mxsfb
> driver entirely.
>
> That would break old DTBs, isn't this generally considered bad? Also,
> are we sure the removal of fbdev/mxsfb wouldn't lose any features?
>
> What my series does is make both drivers work with the same kernel
> image and turns the choice into a board-level dtb decision. Supporting
> everything at once seems desirable to me and it allows for a very
> smooth upgrade path.
Having two drivers in the kernel with different set of bugs is always bad.
> The old driver could be removed later, after all users are converted.
Both drivers were in for long enough already. And let's be realistic,
how many MX23/MX28 users of old DTs with new kernels are there who
cannot update the DT as well ?
IMO keeping the old FBDEV driver in is just an excuse to postpone the
long overdue DT update and I dislike that. Update any remaining DTs and
nuke the FBDEV driver already.
--
Best regards,
Marek Vasut
^ permalink raw reply
* [PATCH v3 16/27] docs: Fix more broken references
From: Stephen Boyd @ 2018-06-15 21:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e1bf52a721005b2017434acc54ec5ddc152d6fe4.1528990947.git.mchehab+samsung@kernel.org>
Quoting Mauro Carvalho Chehab (2018-06-14 09:09:01)
> As we move stuff around, some doc references are broken. Fix some of
> them via this script:
> ./scripts/documentation-file-ref-check --fix
>
> Manually checked that produced results are valid.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> ---
> .../devicetree/bindings/clock/st/st,clkgen.txt | 8 ++++----
> .../devicetree/bindings/clock/ti/gate.txt | 2 +-
> .../devicetree/bindings/clock/ti/interface.txt | 2 +-
Acked-by: Stephen Boyd <sboyd@kernel.org>
^ permalink raw reply
* [RFC PATCH 3/6] serial: 8250_omap: Add support for AM654 UART controller
From: Rob Herring @ 2018-06-15 21:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8c553dcc-e352-6e69-e08c-4e6237555ea7@ti.com>
On Fri, Jun 15, 2018 at 11:17 AM, Sekhar Nori <nsekhar@ti.com> wrote:
> Hi Rob,
>
> On Wednesday 13 June 2018 02:36 AM, Rob Herring wrote:
>> On Tue, Jun 05, 2018 at 01:01:22AM -0500, Nishanth Menon wrote:
>>> AM654 uses a UART controller that is compatible (partially) with
>>> existing 8250 UART, however, has a few differences with respect to DMA
>>> support and control paths. Introduce a base definition that allows us
>>> to build up the differences in follow on patches.
>>>
>>> Cc: Sekhar Nori <nsekhar@ti.com>
>>> Cc: Vignesh R <vigneshr@ti.com>
>>> Signed-off-by: Nishanth Menon <nm@ti.com>
>>> ---
>>> Documentation/devicetree/bindings/serial/omap_serial.txt | 1 +
>>> drivers/tty/serial/8250/8250_omap.c | 1 +
>>> 2 files changed, 2 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/serial/omap_serial.txt b/Documentation/devicetree/bindings/serial/omap_serial.txt
>>> index 4b0f05adb228..c35d5ece1156 100644
>>> --- a/Documentation/devicetree/bindings/serial/omap_serial.txt
>>> +++ b/Documentation/devicetree/bindings/serial/omap_serial.txt
>>> @@ -1,6 +1,7 @@
>>> OMAP UART controller
>>>
>>> Required properties:
>>> +- compatible : should be "ti,am654-uart" for AM654 controllers
>>
>> Not compatible with any existing TI 8250 UARTs?
>
> Curious on why you asked about this. Are you suggesting why not:
>
> "ti,<new-soc>-uart", "ti,<old-soc>-uart"
Correct.
> or you are asking why introduce "ti,<new-soc>-uart" unless there is
> clear demonstrable need for using it in driver code.
>
> In general, I think "ti,<new-soc>-uart", "ti,<old-soc>-uart" in
> device-tree (and by extension in binding document) is better even in
> there are no _known_ incompatibilities at the time of initial driver
> submission. The reason is silicon integration and process differences
> many times spill over into driver.
Yes, and chip designers can't be trusted. ;)
> Of course, the idea is not to go postal and create a new compatible for
> every pin-compatible part number that gets created, but probably a new
> compatible should be created for a new silicon die.
Yes, that's the criteria I would use too. That's sometimes hard if
it's not the chip vendor doing the DT bindings.
> We have just started introducing support for this SoC, and since it
> reuses many IPs, this question is likely to come up again.
>
> In this particular case though, Nishanth is perfectly right in not saying
>
> compatible : should be "ti,am654-uart", "ti,omap4-uart"
>
> Because we *know* UART DMA integration is different and a match against
> omap4 would result in non-working UART once DMA is enabled by default.
Okay, makes sense. I'd suggest rewording the commit message to include
this. The "compatible to 8250 except for DMA" part I would have
applied to all TI UARTs rather than DMA differences with other TI
UARTs.
Rob
^ permalink raw reply
* [PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm
From: Fabio Estevam @ 2018-06-15 22:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <638457fd-85da-8fec-d146-517c43f71813@denx.de>
On Fri, Jun 15, 2018 at 6:36 PM, Marek Vasut <marex@denx.de> wrote:
> Having two drivers in the kernel with different set of bugs is always bad.
Sure, but breaking dtb's is also bad.
Can the mxsfb driver be modified to handle the old style bindings?
The IPU drm driver is capable of handling both the old style where the
display timing is passed in dts and the new drm style.
For example:
arch/arm/boot/dts/imx6qdl-sabresd.dtsi uses the drm style binding
arch/arm/boot/dts/imx6qdl-sabreauto.dtsi uses the old style of passing
the display timings in dts
Both formats are accepted by the ipu drm driver.
Can't mxsfb drm driver support both? Then we don't need to worry about
breaking dtb's and could safely remove the mxs fbdev driver.
^ permalink raw reply
* [PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm
From: Leonard Crestez @ 2018-06-15 22:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <638457fd-85da-8fec-d146-517c43f71813@denx.de>
On Fri, 2018-06-15 at 23:36 +0200, Marek Vasut wrote:
> On 06/15/2018 10:58 PM, Leonard Crestez wrote:
> > On Fri, 2018-06-15 at 16:47 -0300, Fabio Estevam wrote:
> > > On Fri, Jun 15, 2018 at 4:43 PM, Leonard Crestez
> > > <leonard.crestez@nxp.com> wrote:
> > > > The FBDEV driver uses the same name and both can't be registered at the
> > > > same time. Fix this by renaming the drm driver to mxsfb-drm
> > >
> > > Stefan sent the same patch a few days ago:
> >
> > In that thread there is a proposal for removing the old fbdev/mxsfb
> > driver entirely.
> >
> > That would break old DTBs, isn't this generally considered bad? Also,
> > are we sure the removal of fbdev/mxsfb wouldn't lose any features?
> >
> > What my series does is make both drivers work with the same kernel
> > image and turns the choice into a board-level dtb decision. Supporting
> > everything at once seems desirable to me and it allows for a very
> > smooth upgrade path.
>
> Having two drivers in the kernel with different set of bugs is always bad.
>
> > The old driver could be removed later, after all users are converted.
>
> Both drivers were in for long enough already. And let's be realistic,
> how many MX23/MX28 users of old DTs with new kernels are there who
> cannot update the DT as well ?
Grepping for "display =" in arch/arm/boot/dts/imx* I see that old
bindings are also used by 3rd-party boards for imx6/7:
* imx6sx-nitrogen6sx
* imx6ul-geam
* imx6ul-isiot
* imx6ul-opos6uldev
* imx6ul-pico-hobbit
* imx6ul-tx6ul
* imx7d-nitrogen7
Converting everything might be quite a bit of work, and explicitly
supporting old bindings is also work.
It is very confusing that there is a whole set of displays for imx6/7
which are supported by upstream but only with a non-default config.
While it is extremely common in the embedded field to have custom
configs the default one in the kernel should try to "just work".
Couldn't this patch series be considered a bugfix? It was also
surprisingly small.
--
Regards,
Leonard
^ permalink raw reply
* [PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm
From: Marek Vasut @ 2018-06-15 23:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5DJju6oBRLakkTx4np7w9nMwPm6TMkGGYjbMLUPDUugYw@mail.gmail.com>
On 06/16/2018 12:22 AM, Fabio Estevam wrote:
> On Fri, Jun 15, 2018 at 6:36 PM, Marek Vasut <marex@denx.de> wrote:
>
>> Having two drivers in the kernel with different set of bugs is always bad.
>
> Sure, but breaking dtb's is also bad.
You picked only the first part of my argument, the less important one ;-)
> Can the mxsfb driver be modified to handle the old style bindings?
Maybe, but do we care ? Cfr my comment about the amount of users who
will be affected by this.
> The IPU drm driver is capable of handling both the old style where the
> display timing is passed in dts and the new drm style.
>
> For example:
>
> arch/arm/boot/dts/imx6qdl-sabresd.dtsi uses the drm style binding
> arch/arm/boot/dts/imx6qdl-sabreauto.dtsi uses the old style of passing
> the display timings in dts
>
> Both formats are accepted by the ipu drm driver.
>
> Can't mxsfb drm driver support both? Then we don't need to worry about
> breaking dtb's and could safely remove the mxs fbdev driver.
This might be a way forward, but again, does it justify the effort ?
We will be adding compatibility code which we will have to maintain for
maybe a handful of users I think.
--
Best regards,
Marek Vasut
^ permalink raw reply
* [PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm
From: Marek Vasut @ 2018-06-15 23:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b3fa74c5110b45e5992920485749869ab1f7ebce.camel@nxp.com>
On 06/16/2018 12:42 AM, Leonard Crestez wrote:
> On Fri, 2018-06-15 at 23:36 +0200, Marek Vasut wrote:
>> On 06/15/2018 10:58 PM, Leonard Crestez wrote:
>>> On Fri, 2018-06-15 at 16:47 -0300, Fabio Estevam wrote:
>>>> On Fri, Jun 15, 2018 at 4:43 PM, Leonard Crestez
>>>> <leonard.crestez@nxp.com> wrote:
>
>>>>> The FBDEV driver uses the same name and both can't be registered at the
>>>>> same time. Fix this by renaming the drm driver to mxsfb-drm
>>>>
>>>> Stefan sent the same patch a few days ago:
>>>
>>> In that thread there is a proposal for removing the old fbdev/mxsfb
>>> driver entirely.
>>>
>>> That would break old DTBs, isn't this generally considered bad? Also,
>>> are we sure the removal of fbdev/mxsfb wouldn't lose any features?
>>>
>>> What my series does is make both drivers work with the same kernel
>>> image and turns the choice into a board-level dtb decision. Supporting
>>> everything at once seems desirable to me and it allows for a very
>>> smooth upgrade path.
>>
>> Having two drivers in the kernel with different set of bugs is always bad.
>>
>>> The old driver could be removed later, after all users are converted.
>>
>> Both drivers were in for long enough already. And let's be realistic,
>> how many MX23/MX28 users of old DTs with new kernels are there who
>> cannot update the DT as well ?
>
> Grepping for "display =" in arch/arm/boot/dts/imx* I see that old
> bindings are also used by 3rd-party boards for imx6/7:
> * imx6sx-nitrogen6sx
> * imx6ul-geam
> * imx6ul-isiot
> * imx6ul-opos6uldev
> * imx6ul-pico-hobbit
> * imx6ul-tx6ul
> * imx7d-nitrogen7
Er, yes, a handful of boards which could be updated :)
> Converting everything might be quite a bit of work, and explicitly
> supporting old bindings is also work.
Does adding support for old bindings justify the effort invested ? I
doubt so, it only adds more code to maintain.
> It is very confusing that there is a whole set of displays for imx6/7
> which are supported by upstream but only with a non-default config.
> While it is extremely common in the embedded field to have custom
> configs the default one in the kernel should try to "just work".
>
> Couldn't this patch series be considered a bugfix? It was also
> surprisingly small.
I think it's just a workaround which allows you to postpone the real
fix, and I don't like that.
--
Best regards,
Marek Vasut
^ permalink raw reply
* [linux-sunxi] Re: [PATCH v2 11/27] drm/sun4i: tcon: Add support for tcon-top gate
From: Chen-Yu Tsai @ 2018-06-16 5:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3871160.F3Km1rQkUz@jernej-laptop>
On Sat, Jun 16, 2018 at 1:33 AM, Jernej ?krabec <jernej.skrabec@siol.net> wrote:
> Dne petek, 15. junij 2018 ob 19:13:17 CEST je Chen-Yu Tsai napisal(a):
>> On Sat, Jun 16, 2018 at 12:41 AM, Jernej ?krabec
>>
>> <jernej.skrabec@siol.net> wrote:
>> > Hi,
>> >
>> > Dne petek, 15. junij 2018 ob 10:31:10 CEST je Maxime Ripard napisal(a):
>> >> Hi,
>> >>
>> >> On Tue, Jun 12, 2018 at 10:00:20PM +0200, Jernej Skrabec wrote:
>> >> > TV TCONs connected to TCON TOP have to enable additional gate in order
>> >> > to work.
>> >> >
>> >> > Add support for such TCONs.
>> >> >
>> >> > Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
>> >> > ---
>> >> >
>> >> > drivers/gpu/drm/sun4i/sun4i_tcon.c | 11 +++++++++++
>> >> > drivers/gpu/drm/sun4i/sun4i_tcon.h | 4 ++++
>> >> > 2 files changed, 15 insertions(+)
>> >> >
>> >> > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> >> > b/drivers/gpu/drm/sun4i/sun4i_tcon.c index 08747fc3ee71..0afb5a94a414
>> >> > 100644
>> >> > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> >> > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> >> > @@ -688,6 +688,16 @@ static int sun4i_tcon_init_clocks(struct device
>> >> > *dev,
>> >> >
>> >> > dev_err(dev, "Couldn't get the TCON bus clock\n");
>> >> > return PTR_ERR(tcon->clk);
>> >> >
>> >> > }
>> >> >
>> >> > +
>> >> > + if (tcon->quirks->has_tcon_top_gate) {
>> >> > + tcon->top_clk = devm_clk_get(dev, "tcon-top");
>> >> > + if (IS_ERR(tcon->top_clk)) {
>> >> > + dev_err(dev, "Couldn't get the TCON TOP bus
>> >> > clock\n");
>> >> > + return PTR_ERR(tcon->top_clk);
>> >> > + }
>> >> > + clk_prepare_enable(tcon->top_clk);
>> >> > + }
>> >> > +
>> >>
>> >> Is it required for the TCON itself to operate, or does the TCON
>> >> requires the TCON TOP, which in turn requires that clock to be
>> >> functional?
>> >>
>> >> I find it quite odd to have a clock that isn't meant for a particular
>> >> device to actually be wired to another device. I'm not saying this
>> >> isn't the case, but it would be a first.
>> >
>> > Documentation doesn't say much about that gate. I did few tests and TCON
>> > registers can be read and written even if TCON TOP TV TCON gate is
>> > disabled. However, there is no image, as expected.
>>
>> The R40 manual does include it in the diagram, on page 504. There's also a
>> mux to select whether the clock comes directly from the CCU or the TV
>> encoder (a feedback mode?). I assume this is the gate you are referring to
>> here, in which case it is not a bus clock, but rather the TCON module or
>> channel clock, strangely routed.
>>
>> > More interestingly, I enabled test pattern directly in TCON to eliminate
>> > influence of the mixer. As soon as I disabled that gate, test pattern on
>> > HDMI screen was gone, which suggest that this gate influences something
>> > inside TCON.
>> >
>> > Another test I did was that I moved enable/disable gate code to
>> > sun4i_tcon_channel_set_status() and it worked just as well.
>> >
>> > I'll ask AW engineer what that gate actually does, but from what I saw, I
>> > would say that most appropriate location to enable/disable TCON TOP TV
>> > TCON
>> > gate is TCON driver. Alternatively, TCON TOP driver could check if any TV
>> > TCON is in use and enable appropriate gate. However, that doesn't sound
>> > right to me for some reason.
>>
>> If what I said above it true, then yes, the appropriate location to enable
>> it is the TCON driver, but moreover, the representation of the clock tree
>> should be fixed such that the TCON takes the clock from the TCON TOP as its
>> channel/ module clock instead. That way you don't need this patch, but
>> you'd add another for all the clock routing.
>
> Can you be more specific? I not sure what you mean here.
For clock related properties in the device tree:
&tcon_top {
clocks = <&ccu CLK_BUS_TCON_TOP>,
<&ccu CLK_TCON_TV0>,
<&tve0>,
<&ccu CLK_TCON_TV1>,
<&tve1>;
clock-names = "bus", "tcon-tv0", "tve0", "tcon-tv1", "tve1";
clock-output-names = "tcon-top-tv0", "tcon-top-tv1";
};
&tcon_tv0 {
clocks = <&ccu CLK_BUS_TCON_TV0>, <&tcon_top 0>'
clock-names = "ahb", "tcon-ch1";
};
A diagram would look like:
| This part is TCON TOP |
v v
CCU CLK_TCON_TV0 --|----\ |
| mux ---- gate ----|-- TCON_TV0
TVE0 --------------|----/ |
And the same goes for TCON_TV1 and TVE1.
The user manual is a bit lacking on how TVE outputs a clock though.
ChenYu
^ 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