* [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
* [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 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
* [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 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: 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] 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 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 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] 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/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 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 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 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 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] 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 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: 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] 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
* [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] 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
* [RFC PATCH 3/6] serial: 8250_omap: Add support for AM654 UART controller
From: Sekhar Nori @ 2018-06-15 17:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180612210640.GA20728@rob-hp-laptop>
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"
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.
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.
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.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH] arm64/acpi: Add fixup for HPE m400 quirks
From: Geoff Levand @ 2018-06-15 17:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <098e6d53-8dc7-439f-7165-adbe0e7c4941@arm.com>
Hi James,
Just for background, this is a well known bug in the m400's AEPI/HEST
firmware. There are a number of fixes out there the different distros
have. I just put together this patch to unify things and have a
common 'upstream' fix.
On 06/15/2018 04:14 AM, James Morse wrote:
> On 13/06/18 19:22, Geoff Levand wrote:
>> Adds a new ACPI init routine acpi_fixup_m400_quirks that adds
>> a work-around for HPE ProLiant m400 APEI firmware problems.
>>
>> The work-around disables APEI when CONFIG_ACPI_APEI is set and
>> m400 firmware is detected. Without this fixup m400 systems
>> experience errors like these on startup:
>>
>> [Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 2
>> [Hardware Error]: event severity: fatal
>> [Hardware Error]: Error 0, type: fatal
>> [Hardware Error]: section_type: memory error
>> [Hardware Error]: error_status: 0x0000000000001300
>
> "Access to a memory address which is not mapped to any component"
>
>
>> [Hardware Error]: error_type: 10, invalid address
>> Kernel panic - not syncing: Fatal hardware error!
>
> Why is this a problem?
>
> Surely this is a valid description of an error.
The firmware bug causes this failure, not bad hardware.
> (okay its not particularly useful without the physical address, but the address
> is optional in that structure)
>
> When does this happen during boot? This looks like a driver mapping some
> non-existent physical address space to see if its device is present...
> unsurprisingly this doesn't go well.
> (might also be a typo in the DSDT)
>
> Can't we pin down the driver that does this and fix it. Its either wrong for
> everyone, or still broken after you disable APEI.
>
>
>> It seems unlikely there will be any m400 firmware updates to fix
>> this problem.
>
> What is the problem? This patch looks like it shoots the messenger for bringing
> bad news.
The news is incorrect, so this patch disables the source (APEI code).
>> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
>> index 7b09487ff8fb..3c315c2c7476 100644
>> --- a/arch/arm64/kernel/acpi.c
>> +++ b/arch/arm64/kernel/acpi.c
>> @@ -31,6 +31,8 @@
>> #include <asm/cpu_ops.h>
>> #include <asm/smp_plat.h>
>>
>> +#include <acpi/apei.h>
>> +
>> #ifdef CONFIG_ACPI_APEI
>> # include <linux/efi.h>
>> # include <asm/pgtable.h>
>> @@ -177,6 +179,33 @@ static int __init acpi_fadt_sanity_check(void)
>> return ret;
>> }
>>
>> +/*
>> + * acpi_fixup_m400_quirks - Work-around for HPE ProLiant m400 APEI firmware
>> + * problems.
>> + */
>> +static void __init acpi_fixup_m400_quirks(void)
>> +{
>> + acpi_status status;
>> + struct acpi_table_header *header;
>> +#if !defined(CONFIG_ACPI_APEI)
>> + int hest_disable = HEST_DISABLED;
>> +#endif
>
> Yuck.
Yes, unfortunately, the hest code conditionally defines hest_disable.
>> +
>> + if (!IS_ENABLED(CONFIG_ACPI_APEI) || hest_disable != HEST_ENABLED)
>> + return;
>> +
>> + status = acpi_get_table(ACPI_SIG_HEST, 0, &header);
>> +
>> + 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?
> You suggest a firmware-update would make this issue go away...
>
>
>> + hest_disable = HEST_DISABLED;
>> + pr_info("Disabled APEI for m400.\n");
>> + }
>> +
>> + acpi_put_table(header);
>> +}
>> +
>> /*
>> * acpi_boot_table_init() called from setup_arch(), always.
>> * 1. find RSDP and get its address, and then find XSDT
>
> Nothing arch-specific here. You're adding this to arch/arm64 because
> drivers/acpi/apei doesn't have an existing quirks table?
There was a fix submitted that had it in drivers/acpi/scan.c, but the
ACPI maintainer said he didn't want the fix in the main ACPI code.
See:
https://lkml.org/lkml/2018/4/19/1020 (ACPI / scan: Fix regression related to X-Gene UARTs)
The m400 is an arm64 platform, so it seems most appropriate to
have it in arch/arm64/kernel/acpi.c. I followed what was done
for x86 quirks (into arch/x86/kernel/acpi/boot.c), and what was
suggested here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900581 (linux: Enable Buster kernel features for newer ARM64 servers)
Thanks for the review.
-Geoff
^ 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-15 17:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2948115.KggauuSURZ@jernej-laptop>
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.
ChenYu
^ permalink raw reply
* [PATCH 1/1] iommu/arm-smmu: Add support to use Last level cache
From: Jordan Crouse @ 2018-06-15 17:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180615165232.GE2202@arm.com>
On Fri, Jun 15, 2018 at 05:52:32PM +0100, Will Deacon wrote:
> Hi Vivek,
>
> On Fri, Jun 15, 2018 at 04:23:29PM +0530, Vivek Gautam wrote:
> > Qualcomm SoCs have an additional level of cache called as
> > System cache or Last level cache[1]. This cache sits right
> > before the DDR, and is tightly coupled with the memory
> > controller.
> > The cache is available to all the clients present in the
> > SoC system. The clients request their slices from this system
> > cache, make it active, and can then start using it. For these
> > clients with smmu, to start using the system cache for
> > dma buffers and related page tables [2], few of the memory
> > attributes need to be set accordingly.
> > This change makes the related memory Outer-Shareable, and
> > updates the MAIR with necessary protection.
> >
> > The MAIR attribute requirements are:
> > Inner Cacheablity = 0
> > Outer Cacheablity = 1, Write-Back Write Allocate
> > Outer Shareablity = 1
>
> Hmm, so is this cache coherent with the CPU or not? Why don't normal
> non-cacheable mappings allocated in the LLC by default?
>
> > diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> > index f7a96bcf94a6..8058e7205034 100644
> > --- a/drivers/iommu/arm-smmu.c
> > +++ b/drivers/iommu/arm-smmu.c
> > @@ -249,6 +249,7 @@ struct arm_smmu_domain {
> > struct mutex init_mutex; /* Protects smmu pointer */
> > spinlock_t cb_lock; /* Serialises ATS1* ops and TLB syncs */
> > struct iommu_domain domain;
> > + bool has_sys_cache;
> > };
> >
> > struct arm_smmu_option_prop {
> > @@ -862,6 +863,8 @@ static int arm_smmu_init_domain_context(struct iommu_domain *domain,
> >
> > if (smmu->features & ARM_SMMU_FEAT_COHERENT_WALK)
> > pgtbl_cfg.quirks = IO_PGTABLE_QUIRK_NO_DMA;
> > + if (smmu_domain->has_sys_cache)
> > + pgtbl_cfg.quirks |= IO_PGTABLE_QUIRK_SYS_CACHE;
> >
> > smmu_domain->smmu = smmu;
> > pgtbl_ops = alloc_io_pgtable_ops(fmt, &pgtbl_cfg, smmu_domain);
> > @@ -1477,6 +1480,9 @@ static int arm_smmu_domain_get_attr(struct iommu_domain *domain,
> > case DOMAIN_ATTR_NESTING:
> > *(int *)data = (smmu_domain->stage == ARM_SMMU_DOMAIN_NESTED);
> > return 0;
> > + case DOMAIN_ATTR_USE_SYS_CACHE:
> > + *((int *)data) = smmu_domain->has_sys_cache;
> > + return 0;
>
> I really don't like exposing this to clients directly like this,
> particularly as there aren't any in-tree users. I would prefer that we
> provide a way for the io-pgtable code to have its MAIR values overridden
> so that all non-coherent DMA ends up using the system cache.
FWIW here is a future in-tree user for LLC:
https://patchwork.freedesktop.org/series/40545/
Specifically:
https://patchwork.freedesktop.org/patch/212400/
Jordan
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ 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