Re: [PATCH v2] leds: pm8058: Silence pointer to integer size warning
On Thu, 30 Nov 2017, Bjorn Andersson wrote:
> The pointer returned by of_device_get_match_data() doesn't have the same
> size as u32 on 64-bit architectures, causing a compile warning when
> compile-testing the driver on such platform.
>
> Cast the return value of of_device_get_match_data() to unsigned long and
> then to u32 to silence this warning.
>
> Cc: Linus Walleij
> Fixes: 7f866986e705 ("leds: add PM8058 LEDs driver")
> Signed-off-by: Bjorn Andersson
> ---
> drivers/leds/leds-pm8058.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/leds/leds-pm8058.c b/drivers/leds/leds-pm8058.c
> index a52674327857..8988ba3b2d65 100644
> --- a/drivers/leds/leds-pm8058.c
> +++ b/drivers/leds/leds-pm8058.c
> @@ -106,7 +106,7 @@ static int pm8058_led_probe(struct platform_device *pdev)
> if (!led)
> return -ENOMEM;
>
> - led->ledtype = (u32)of_device_get_match_data(&pdev->dev);
> + led->ledtype = (u32)(unsigned long)of_device_get_match_data(&pdev->dev);
Wouldn't (u32)(void *) be even more correct?
... if the compiler will let you get away with it.
> map = dev_get_regmap(pdev->dev.parent, NULL);
> if (!map) {
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH] leds: pm8058: Make ledtype pointer sized type
On Thu, 30 Nov 2017, Jacek Anaszewski wrote:
> On 11/30/2017 09:31 AM, Lee Jones wrote:
> > On Thu, 30 Nov 2017, Lee Jones wrote:
> >
> >> On Wed, 29 Nov 2017, Bjorn Andersson wrote:
> >>
> >>> The pointer returned by of_device_get_match_data() doesn't have the same
> >>> size as u32 on 64-bit architectures, causing issues when compile testing
> >>> the driver on such platform. Make ledtype unsigned long instead, to
> >>> solve this problem.
> >>>
> >>> Fixes: 7f866986e705 ("leds: add PM8058 LEDs driver")
> >>> Cc: Linus Walleij
> >>> Signed-off-by: Bjorn Andersson
> >>> ---
> >>> drivers/leds/leds-pm8058.c | 4 ++--
> >>> 1 file changed, 2 insertions(+), 2 deletions(-)
> >>
> >> Hi Bjorn,
> >>
> >> (Nice to see you) :)
> >>
> >> I'm going to apply this *before* Linus' fix.
> >>
> >> Applied, thanks.
> >
> > After I rx an Ack from Richard, Jacek or Pavel of course. :)
> >
> > Will send a pull-request.
>
> Huh? This is for LED subsystem AFAICS.
Right, hence why I said I'd sent out a pull-request.
The problem, however, arose due to a change in its parent driver's
Kconfig entry, which has been applied to the MFD tree. We need to
ensure this patch is applied *before* the other 'fix' to quash the
warning before it starts, so to speak.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH v4 3/8] MIPS: Octeon: Add a global resource manager.
Carlos, On Thu, Nov 30, 2017 at 11:53 PM, James Hogan wrote: > On Tue, Nov 28, 2017 at 04:55:35PM -0800, David Daney wrote: >> From: Carlos Munoz >> >> Add a global resource manager to manage tagged pointers within >> bootmem allocated memory. This is used by various functional >> blocks in the Octeon core like the FPA, Ethernet nexus, etc. >> >> Signed-off-by: Carlos Munoz >> Signed-off-by: Steven J. Hill >> Signed-off-by: David Daney >> --- >> arch/mips/cavium-octeon/Makefile | 3 +- >> arch/mips/cavium-octeon/resource-mgr.c | 371 >> + >> arch/mips/include/asm/octeon/octeon.h | 18 ++ >> 3 files changed, 391 insertions(+), 1 deletion(-) >> create mode 100644 arch/mips/cavium-octeon/resource-mgr.c >> >> diff --git a/arch/mips/cavium-octeon/Makefile >> b/arch/mips/cavium-octeon/Makefile >> index 7c02e542959a..0a299ab8719f 100644 >> --- a/arch/mips/cavium-octeon/Makefile >> +++ b/arch/mips/cavium-octeon/Makefile >> @@ -9,7 +9,8 @@ >> # Copyright (C) 2005-2009 Cavium Networks >> # >> >> -obj-y := cpu.o setup.o octeon-platform.o octeon-irq.o csrc-octeon.o >> +obj-y := cpu.o setup.o octeon-platform.o octeon-irq.o csrc-octeon.o \ >> + resource-mgr.o > > Maybe put that on a separate line like below. > >> obj-y += dma-octeon.o >> obj-y += octeon-memcpy.o >> obj-y += executive/ >> diff --git a/arch/mips/cavium-octeon/resource-mgr.c >> b/arch/mips/cavium-octeon/resource-mgr.c >> new file mode 100644 >> index ..ca25fa953402 >> --- /dev/null >> +++ b/arch/mips/cavium-octeon/resource-mgr.c >> @@ -0,0 +1,371 @@ >> +// SPDX-License-Identifier: GPL-2.0 >> +/* >> + * Resource manager for Octeon. >> + * >> + * This file is subject to the terms and conditions of the GNU General >> Public >> + * License. See the file "COPYING" in the main directory of this archive >> + * for more details. >> + * >> + * Copyright (C) 2017 Cavium, Inc. >> + */ Since you nicely included an SPDX id, you would not need the boilerplate anymore. e.g. these can go alright? >> + * This file is subject to the terms and conditions of the GNU General >> Public >> + * License. See the file "COPYING" in the main directory of this archive >> + * for more details. -- Cordially Philippe Ombredanne
Re: [PATCH RFC 2/2] arm64: allwinner: a64: Add Brava Keller initial support
On Fri, Dec 01, 2017 at 12:12:14AM +0530, Jagan Teki wrote:
> Brava Keller is A64 based IoT device, which support
> - Allwinner A64 Cortex-A53
> - AXP803 PMIC
> - 1GB DDR3 RAM
> - 8GB eMMC
> - Mali-400MP2 GPU
> - AP6330 Wifi/BLE
> - Camera OV5640
> - USB Host and OTG
>
> Signed-off-by: Jagan Teki
> ---
> Note: Need to test it on hardware
>
> arch/arm64/boot/dts/allwinner/Makefile | 1 +
> .../boot/dts/allwinner/sun50i-a64-brava-keller.dts | 244
> +
> 2 files changed, 245 insertions(+)
> create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-brava-keller.dts
>
> diff --git a/arch/arm64/boot/dts/allwinner/Makefile
> b/arch/arm64/boot/dts/allwinner/Makefile
> index f505227..af80ca0 100644
> --- a/arch/arm64/boot/dts/allwinner/Makefile
> +++ b/arch/arm64/boot/dts/allwinner/Makefile
> @@ -1,5 +1,6 @@
> # SPDX-License-Identifier: GPL-2.0
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-bananapi-m64.dtb
> +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-brava-keller.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-nanopi-a64.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-olinuxino.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-orangepi-win.dtb
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-brava-keller.dts
> b/arch/arm64/boot/dts/allwinner/sun50i-a64-brava-keller.dts
> new file mode 100644
> index 000..f5303a3
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-brava-keller.dts
> @@ -0,0 +1,244 @@
> +/*
> + * Copyright (C) 2017 Jagan Teki
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + * a) This library is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * This library is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + * b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +/dts-v1/;
> +
> +#include "sun50i-a64.dtsi"
> +
> +#include
> +
> +/ {
> + model = "Brava Keller";
> + compatible = "brava,brava-keller", "allwinner,sun50i-a64";
> +
> + aliases {
> + serial2 = &uart2;
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
Same comment than on U-Boot.
> + wifi_pwrseq: wifi_pwrseq {
> + compatible = "mmc-pwrseq-simple";
> + pinctrl-names = "default";
> + reset-gpios = <&pio 0 2 GPIO_ACTIVE_LOW>; /* WL-PMU-EN: PL2 */
> + post-power-on-delay-ms = <200>;
> + };
> +};
> +
> +&ehci0 {
> + status = "okay";
> +};
> +
> +&ehci1 {
> + status = "okay";
> +};
> +
> +&mmc1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&mmc1_pins>;
> + vmmc-supply = <®_dcdc1>;
> + vqmmc-supply = <®_dldo4>;
> + mmc-pwrseq = <&wifi_pwrseq>;
> + bus-width = <4>;
> + non-removable;
> + status = "okay";
> +
> + brcmf: wifi@1 {
> + reg = <1>;
> + compatible = "brcm,bcm4329-fmac";
> + interrupt-parent = <&r_pio>;
> + interrupts = <0 7 IRQ_TYPE_LEVEL_LOW>; /* WL-WAKE-AP: PL3 */
> + interrupt-names = "host-wake";
> + };
> +};
> +
> +&mmc2 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&mmc2_pins>;
> + vmmc-supply = <®_dcdc1>;
You probably have a vqmmc tosetup t
[PATCH v2 3/3] ARM: CMA: avoid double mapping to the CMA area if CONFIG_HIGHMEM = y
From: Joonsoo Kim
CMA area is now managed by the separate zone, ZONE_MOVABLE,
to fix many MM related problems. In this implementation, if
CONFIG_HIGHMEM = y, then ZONE_MOVABLE is considered as HIGHMEM and
the memory of the CMA area is also considered as HIGHMEM.
That means that they are considered as the page without direct mapping.
However, CMA area could be in a lowmem and the memory could have
direct mapping.
In ARM, when establishing a new mapping for DMA, direct mapping should
be cleared since two mapping with different cache policy could cause
unknown problem. With this patch, PageHighmem() for the CMA memory
located in lowmem returns true so that the function for DMA mapping
cannot notice whether it needs to clear direct mapping or not, correctly.
To handle this situation, this patch always clears direct mapping
for such CMA memory.
Signed-off-by: Joonsoo Kim
---
arch/arm/mm/dma-mapping.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index ada8eb2..8c398fe 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -466,6 +466,12 @@ void __init dma_contiguous_early_fixup(phys_addr_t base,
unsigned long size)
void __init dma_contiguous_remap(void)
{
int i;
+
+ if (!dma_mmu_remap_num)
+ return;
+
+ /* call flush_cache_all() since CMA area would be large enough */
+ flush_cache_all();
for (i = 0; i < dma_mmu_remap_num; i++) {
phys_addr_t start = dma_mmu_remap[i].base;
phys_addr_t end = start + dma_mmu_remap[i].size;
@@ -498,7 +504,15 @@ void __init dma_contiguous_remap(void)
flush_tlb_kernel_range(__phys_to_virt(start),
__phys_to_virt(end));
- iotable_init(&map, 1);
+ /*
+* All the memory in CMA region will be on ZONE_MOVABLE.
+* If that zone is considered as highmem, the memory in CMA
+* region is also considered as highmem even if it's
+* physical address belong to lowmem. In this case,
+* re-mapping isn't required.
+*/
+ if (!is_highmem_idx(ZONE_MOVABLE))
+ iotable_init(&map, 1);
}
}
--
2.7.4
[PATCH v2 1/3] mm/cma: manage the memory of the CMA area by using the ZONE_MOVABLE
From: Joonsoo Kim 0. History This patchset is the follow-up of the discussion about the "Introduce ZONE_CMA (v7)" [1]. Please reference it if more information is needed. 1. What does this patch do? This patch changes the management way for the memory of the CMA area in the MM subsystem. Currently, The memory of the CMA area is managed by the zone where their pfn is belong to. However, this approach has some problems since MM subsystem doesn't have enough logic to handle the situation that different characteristic memories are in a single zone. To solve this issue, this patch try to manage all the memory of the CMA area by using the MOVABLE zone. In MM subsystem's point of view, characteristic of the memory on the MOVABLE zone and the memory of the CMA area are the same. So, managing the memory of the CMA area by using the MOVABLE zone will not have any problem. 2. Motivation There are some problems with current approach. See following. Although these problem would not be inherent and it could be fixed without this conception change, it requires many hooks addition in various code path and it would be intrusive to core MM and would be really error-prone. Therefore, I try to solve them with this new approach. Anyway, following is the problems of the current implementation. o CMA memory utilization First, following is the freepage calculation logic in MM. - For movable allocation: freepage = total freepage - For unmovable allocation: freepage = total freepage - CMA freepage Freepages on the CMA area is used after the normal freepages in the zone where the memory of the CMA area is belong to are exhausted. At that moment that the number of the normal freepages is zero, so - For movable allocation: freepage = total freepage = CMA freepage - For unmovable allocation: freepage = 0 If unmovable allocation comes at this moment, allocation request would fail to pass the watermark check and reclaim is started. After reclaim, there would exist the normal freepages so freepages on the CMA areas would not be used. FYI, there is another attempt [2] trying to solve this problem in lkml. And, as far as I know, Qualcomm also has out-of-tree solution for this problem. o useless reclaim There is no logic to distinguish CMA pages in the reclaim path. Hence, CMA page is reclaimed even if the system just needs the page that can be usable for the kernel allocation. o atomic allocation failure This is also related to the fallback allocation policy for the memory of the CMA area. Consider the situation that the number of the normal freepages is *zero* since the bunch of the movable allocation requests come. Kswapd would not be woken up due to following freepage calculation logic. - For movable allocation: freepage = total freepage = CMA freepage If atomic unmovable allocation request comes at this moment, it would fails due to following logic. - For unmovable allocation: freepage = total freepage - CMA freepage = 0 It was reported by Aneesh [3]. o useless compaction Usual high-order allocation request is unmovable allocation request and it cannot be served from the memory of the CMA area. In compaction, migration scanner try to migrate the page in the CMA area and make high-order page there. As mentioned above, it cannot be usable for the unmovable allocation request so it's just waste. 3. Current approach and new approach Current approach is that the memory of the CMA area is managed by the zone where their pfn is belong to. However, these memory should be distinguishable since they have a strong limitation. So, they are marked as MIGRATE_CMA in pageblock flag and handled specially. However, as mentioned in section 2, the MM subsystem doesn't have enough logic to deal with this special pageblock so many problems raised. New approach is that the memory of the CMA area is managed by the MOVABLE zone. MM already have enough logic to deal with special zone like as HIGHMEM and MOVABLE zone. So, managing the memory of the CMA area by the MOVABLE zone just naturally work well because constraints for the memory of the CMA area that the memory should always be migratable is the same with the constraint for the MOVABLE zone. There is one side-effect for the usability of the memory of the CMA area. The use of MOVABLE zone is only allowed for a request with GFP_HIGHMEM && GFP_MOVABLE so now the memory of the CMA area is also only allowed for this gfp flag. Before this patchset, a request with GFP_MOVABLE can use them. IMO, It would not be a big issue since most of GFP_MOVABLE request also has GFP_HIGHMEM flag. For example, file cache page and anonymous page. However, file cache page for blockdev file is an exception. Request for it has no GFP_HIGHMEM flag. There is pros and cons on this exception. In my experience, blockdev file cache pages are one of the top reason that causes cma_alloc() to fail temporarily. So, we can get more guarantee of cma_alloc() success by discarding this case. Note that there is no chang
[PATCH v2 2/3] mm/cma: remove ALLOC_CMA
From: Joonsoo Kim
Now, all reserved pages for CMA region are belong to the ZONE_MOVABLE
and it only serves for a request with GFP_HIGHMEM && GFP_MOVABLE.
Therefore, we don't need to maintain ALLOC_CMA at all.
Reviewed-by: Aneesh Kumar K.V
Acked-by: Vlastimil Babka
Signed-off-by: Joonsoo Kim
---
mm/compaction.c | 4 +---
mm/internal.h | 1 -
mm/page_alloc.c | 28 +++-
3 files changed, 4 insertions(+), 29 deletions(-)
diff --git a/mm/compaction.c b/mm/compaction.c
index 10cd757..b8c2388 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -1450,14 +1450,12 @@ static enum compact_result __compaction_suitable(struct
zone *zone, int order,
* if compaction succeeds.
* For costly orders, we require low watermark instead of min for
* compaction to proceed to increase its chances.
-* ALLOC_CMA is used, as pages in CMA pageblocks are considered
-* suitable migration targets
*/
watermark = (order > PAGE_ALLOC_COSTLY_ORDER) ?
low_wmark_pages(zone) : min_wmark_pages(zone);
watermark += compact_gap(order);
if (!__zone_watermark_ok(zone, 0, watermark, classzone_idx,
- ALLOC_CMA, wmark_target))
+ 0, wmark_target))
return COMPACT_SKIPPED;
return COMPACT_CONTINUE;
diff --git a/mm/internal.h b/mm/internal.h
index 1cfa4c7..3e5dc95 100644
--- a/mm/internal.h
+++ b/mm/internal.h
@@ -498,7 +498,6 @@ unsigned long reclaim_clean_pages_from_list(struct zone
*zone,
#define ALLOC_HARDER 0x10 /* try to alloc harder */
#define ALLOC_HIGH 0x20 /* __GFP_HIGH set */
#define ALLOC_CPUSET 0x40 /* check for correct cpuset */
-#define ALLOC_CMA 0x80 /* allow allocations from CMA areas */
enum ttu_flags;
struct tlbflush_unmap_batch;
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index eb5cdd5..18df47e 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -2773,7 +2773,7 @@ int __isolate_free_page(struct page *page, unsigned int
order)
* exists.
*/
watermark = min_wmark_pages(zone) + (1UL << order);
- if (!zone_watermark_ok(zone, 0, watermark, 0, ALLOC_CMA))
+ if (!zone_watermark_ok(zone, 0, watermark, 0, 0))
return 0;
__mod_zone_freepage_state(zone, -(1UL << order), mt);
@@ -3049,12 +3049,6 @@ bool __zone_watermark_ok(struct zone *z, unsigned int
order, unsigned long mark,
}
-#ifdef CONFIG_CMA
- /* If allocation can't use CMA areas don't use free CMA pages */
- if (!(alloc_flags & ALLOC_CMA))
- free_pages -= zone_page_state(z, NR_FREE_CMA_PAGES);
-#endif
-
/*
* Check watermarks for an order-0 allocation request. If these
* are not met, then a high-order request also cannot go ahead
@@ -3081,10 +3075,8 @@ bool __zone_watermark_ok(struct zone *z, unsigned int
order, unsigned long mark,
}
#ifdef CONFIG_CMA
- if ((alloc_flags & ALLOC_CMA) &&
- !list_empty(&area->free_list[MIGRATE_CMA])) {
+ if (!list_empty(&area->free_list[MIGRATE_CMA]))
return true;
- }
#endif
if (alloc_harder &&
!list_empty(&area->free_list[MIGRATE_HIGHATOMIC]))
@@ -3104,13 +3096,6 @@ static inline bool zone_watermark_fast(struct zone *z,
unsigned int order,
unsigned long mark, int classzone_idx, unsigned int alloc_flags)
{
long free_pages = zone_page_state(z, NR_FREE_PAGES);
- long cma_pages = 0;
-
-#ifdef CONFIG_CMA
- /* If allocation can't use CMA areas don't use free CMA pages */
- if (!(alloc_flags & ALLOC_CMA))
- cma_pages = zone_page_state(z, NR_FREE_CMA_PAGES);
-#endif
/*
* Fast check for order-0 only. If this fails then the reserves
@@ -3119,7 +3104,7 @@ static inline bool zone_watermark_fast(struct zone *z,
unsigned int order,
* the caller is !atomic then it'll uselessly search the free
* list. That corner case is then slower but it is harmless.
*/
- if (!order && (free_pages - cma_pages) > mark +
z->lowmem_reserve[classzone_idx])
+ if (!order && free_pages > mark + z->lowmem_reserve[classzone_idx])
return true;
return __zone_watermark_ok(z, order, mark, classzone_idx, alloc_flags,
@@ -3735,10 +3720,6 @@ gfp_to_alloc_flags(gfp_t gfp_mask)
} else if (unlikely(rt_task(current)) && !in_interrupt())
alloc_flags |= ALLOC_HARDER;
-#ifdef CONFIG_CMA
- if (gfpflags_to_migratetype(gfp_mask) == MIGRATE_MOVABLE)
- alloc_flags |= ALLOC_CMA;
-#endif
return alloc_flags;
}
@@ -4205,9 +4186,6 @@ static inline bool prepare_alloc_pages(gfp_t gfp_mask,
u
[PATCH v2 0/3] mm/cma: manage the memory of the CMA area by using the ZONE_MOVABLE
From: Joonsoo Kim v2 o previous failure in linux-next turned out that it's not the problem of this patchset. It was caused by the wrong assumption by specific architecture. lkml.kernel.org/r/20171114173719.ga28...@atomide.com o add missing cache flush to the patch "ARM: CMA: avoid double mapping to the CMA area if CONFIG_HIGHMEM = y" This patchset is the follow-up of the discussion about the "Introduce ZONE_CMA (v7)" [1]. Please reference it if more information is needed. In this patchset, the memory of the CMA area is managed by using the ZONE_MOVABLE. Since there is another type of the memory in this zone, we need to maintain a migratetype for the CMA memory to account the number of the CMA memory. So, unlike previous patchset, there is less deletion of the code. Otherwise, there is no big change. Motivation of this patchset is described in the commit description of the patch "mm/cma: manage the memory of the CMA area by using the ZONE_MOVABLE". Please refer it for more information. This patchset is based on linux-next-20170822 plus "mm/page_alloc: don't reserve ZONE_HIGHMEM for ZONE_MOVABLE". Thanks. [1]: lkml.kernel.org/r/1491880640-9944-1-git-send-email-iamjoonsoo@lge.com Joonsoo Kim (3): mm/cma: manage the memory of the CMA area by using the ZONE_MOVABLE mm/cma: remove ALLOC_CMA ARM: CMA: avoid double mapping to the CMA area if CONFIG_HIGHMEM = y arch/arm/mm/dma-mapping.c | 16 +++- include/linux/memory_hotplug.h | 3 -- include/linux/mm.h | 1 + mm/cma.c | 83 -- mm/compaction.c| 4 +- mm/internal.h | 4 +- mm/page_alloc.c| 83 +++--- 7 files changed, 145 insertions(+), 49 deletions(-) -- 2.7.4
[PATCH v5 5/5] misc serdev: w2sg0004: add debugging code and Kconfig
This allows to set CONFIG_W2SG0004_DEBUG which will
make the driver report more activities and it will turn on the
GPS module during boot while the driver assumes that it
is off. This can be used to debug the correct functioning of
the hardware. Therefore we add it as an option to the driver
because we think it is of general use (and a little tricky to
add by system testers).
Normally it should be off.
Signed-off-by: H. Nikolaus Schaller
---
drivers/misc/Kconfig| 8
drivers/misc/w2sg0004.c | 37 +
2 files changed, 45 insertions(+)
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index a3b11016ed2b..ad6e60f0cc8c 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -518,4 +518,12 @@ config W2SG0004
is opened/closed.
It also provides a rfkill gps name to control the LNA power.
+config W2SG0004_DEBUG
+ bool "W2SG0004 on/off debugging"
+ depends on W2SG0004
+ help
+ Enable driver debugging mode of W2SG0004 GPS. If you say y here
+ this will turn on the module and you can check if it is turned
+ off by the driver.
+
endmenu
diff --git a/drivers/misc/w2sg0004.c b/drivers/misc/w2sg0004.c
index 6bfd12eb8e02..82c708fce510 100644
--- a/drivers/misc/w2sg0004.c
+++ b/drivers/misc/w2sg0004.c
@@ -26,6 +26,10 @@
*
*/
+#ifdef CONFIG_W2SG0004_DEBUG
+#define DEBUG 1
+#endif
+
#include
#include
#include
@@ -256,6 +260,7 @@ static int w2sg_tty_install(struct tty_driver *driver,
struct tty_struct *tty)
pr_debug("%s() tty = %p\n", __func__, tty);
data = w2sg_get_by_minor(tty->index);
+ pr_debug("%s() data = %p\n", __func__, data);
if (!data)
return -ENODEV;
@@ -342,6 +347,8 @@ static int w2sg_probe(struct serdev_device *serdev)
if (data == NULL)
return -ENOMEM;
+ pr_debug("w2sg serdev_device_set_drvdata\n");
+
serdev_device_set_drvdata(serdev, data);
data->on_off_gpio = of_get_named_gpio_flags(serdev->dev.of_node,
@@ -375,6 +382,8 @@ static int w2sg_probe(struct serdev_device *serdev)
INIT_DELAYED_WORK(&data->work, toggle_work);
+ pr_debug("w2sg devm_gpio_request\n");
+
err = devm_gpio_request(&serdev->dev, data->on_off_gpio,
"w2sg0004-on-off");
if (err < 0)
@@ -388,6 +397,8 @@ static int w2sg_probe(struct serdev_device *serdev)
serdev_device_set_baudrate(data->uart, 9600);
serdev_device_set_flow_control(data->uart, false);
+ pr_debug("w2sg rfkill_alloc\n");
+
rf_kill = rfkill_alloc("GPS", &serdev->dev, RFKILL_TYPE_GPS,
&w2sg0004_rfkill_ops, data);
if (rf_kill == NULL) {
@@ -395,6 +406,8 @@ static int w2sg_probe(struct serdev_device *serdev)
goto err_rfkill;
}
+ pr_debug("w2sg register rfkill\n");
+
err = rfkill_register(rf_kill);
if (err) {
dev_err(&serdev->dev, "Cannot register rfkill device\n");
@@ -403,6 +416,8 @@ static int w2sg_probe(struct serdev_device *serdev)
data->rf_kill = rf_kill;
+ pr_debug("w2sg alloc_tty_driver\n");
+
/* allocate the tty driver */
data->tty_drv = alloc_tty_driver(1);
if (!data->tty_drv)
@@ -428,6 +443,8 @@ static int w2sg_probe(struct serdev_device *serdev)
*/
tty_set_operations(data->tty_drv, &w2sg_serial_ops);
+ pr_debug("w2sg tty_register_driver\n");
+
/* register the tty driver */
err = tty_register_driver(data->tty_drv);
if (err) {
@@ -443,9 +460,27 @@ static int w2sg_probe(struct serdev_device *serdev)
tty_port_init(&data->port);
data->port.ops = &w2sg_port_ops;
+ pr_debug("w2sg call tty_port_register_device\n");
+
data->dev = tty_port_register_device(&data->port,
data->tty_drv, minor, &serdev->dev);
+ pr_debug("w2sg tty_port_register_device -> %p\n", data->dev);
+ pr_debug("w2sg port.tty = %p\n", data->port.tty);
+
+ pr_debug("w2sg probed\n");
+
+#ifdef CONFIG_W2SG0004_DEBUG
+ pr_debug("w2sg DEBUGGING MODE enabled\n");
+ /* turn on for debugging rx notifications */
+ pr_debug("w2sg power gpio ON\n");
+ gpio_set_value_cansleep(data->on_off_gpio, 1);
+ mdelay(100);
+ pr_debug("w2sg power gpio OFF\n");
+ gpio_set_value_cansleep(data->on_off_gpio, 0);
+ mdelay(300);
+#endif
+
/* keep off until user space requests the device */
w2sg_set_power(data, false);
@@ -455,6 +490,8 @@ static int w2sg_probe(struct serdev_device *serdev)
rfkill_destroy(rf_kill);
serdev_device_close(data->uart);
out:
+ pr_debug("w2sg error %d\n", err);
+
return err;
}
--
2.12.2
[PATCH v5 1/5] dt-bindings: define vendor prefix for Wi2Wi, Inc.
Introduce vendor prefix for Wi2Wi, Inc. for W2SG00x4 GPS modules and W2CBW003 Bluetooth/WiFi combo (CSR/Marvell). Signed-off-by: H. Nikolaus Schaller Acked-by: Rob Herring --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 0994bdd82cd3..879f1d9291cd 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -382,6 +382,7 @@ voipac Voipac Technologies s.r.o. wd Western Digital Corp. wetek WeTek Electronics, limited. wexler Wexler +wi2wi Wi2Wi, Inc. winbond Winbond Electronics corp. winstarWinstar Display Corp. wlfWolfson Microelectronics -- 2.12.2
[PATCH v5 3/5] misc serdev: Add w2sg0004 (gps receiver) power control driver
Add driver for Wi2Wi W2SG0004/84 GPS module connected to some SoC UART.
It uses serdev API hooks to monitor and forward the UART traffic to /dev/ttyGPSn
and turn on/off the module. It also detects if the module is turned on (sends
data)
but should be off, e.g. if it was already turned on during boot or
power-on-reset.
Additionally, rfkill block/unblock can be used to control an external LNA
(and power down the module if not needed).
The driver concept is based on code developed by Neil Brown
but simplified and adapted to use the new serdev API introduced in v4.11.
Signed-off-by: H. Nikolaus Schaller
---
drivers/misc/Kconfig| 10 +
drivers/misc/Makefile | 1 +
drivers/misc/w2sg0004.c | 553
3 files changed, 564 insertions(+)
create mode 100644 drivers/misc/w2sg0004.c
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index f1a5c2357b14..a3b11016ed2b 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -508,4 +508,14 @@ source "drivers/misc/mic/Kconfig"
source "drivers/misc/genwqe/Kconfig"
source "drivers/misc/echo/Kconfig"
source "drivers/misc/cxl/Kconfig"
+
+config W2SG0004
+ tristate "W2SG00x4 on/off control"
+ depends on GPIOLIB && SERIAL_DEV_BUS
+ help
+ Enable on/off control of W2SG00x4 GPS moduled connected
+ to some SoC UART to allow powering up/down if the /dev/ttyGPSn
+ is opened/closed.
+ It also provides a rfkill gps name to control the LNA power.
+
endmenu
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 5ca5f64df478..d9d824b3d20a 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -50,6 +50,7 @@ obj-$(CONFIG_SRAM_EXEC) += sram-exec.o
obj-y += mic/
obj-$(CONFIG_GENWQE) += genwqe/
obj-$(CONFIG_ECHO) += echo/
+obj-$(CONFIG_W2SG0004) += w2sg0004.o
obj-$(CONFIG_VEXPRESS_SYSCFG) += vexpress-syscfg.o
obj-$(CONFIG_CXL_BASE) += cxl/
obj-$(CONFIG_ASPEED_LPC_CTRL) += aspeed-lpc-ctrl.o
diff --git a/drivers/misc/w2sg0004.c b/drivers/misc/w2sg0004.c
new file mode 100644
index ..6bfd12eb8e02
--- /dev/null
+++ b/drivers/misc/w2sg0004.c
@@ -0,0 +1,553 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Driver for power controlling the w2sg0004/w2sg0084 GPS receiver.
+ *
+ * Copyright (C) 2013 Neil Brown
+ * Copyright (C) 2015-2017 H. Nikolaus Schaller ,
+ * Golden Delicious Computers
+ *
+ * This receiver has an ON/OFF pin which must be toggled to
+ * turn the device 'on' of 'off'. A high->low->high toggle
+ * will switch the device on if it is off, and off if it is on.
+ *
+ * To enable receiving on/off requests we register with the
+ * UART power management notifications.
+ *
+ * It is not possible to directly detect the state of the device.
+ * However when it is on it will send characters on a UART line
+ * regularly.
+ *
+ * To detect that the power state is out of sync (e.g. if GPS
+ * was enabled before a reboot), we register for UART data received
+ * notifications.
+ *
+ * In addition we register as a rfkill client so that we can
+ * control the LNA power.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/*
+ * There seems to be restrictions on how quickly we can toggle the
+ * on/off line. data sheets says "two rtc ticks", whatever that means.
+ * If we do it too soon it doesn't work.
+ * So we have a state machine which uses the common work queue to ensure
+ * clean transitions.
+ * When a change is requested we record that request and only act on it
+ * once the previous change has completed.
+ * A change involves a 10ms low pulse, and a 990ms raised level, so only
+ * one change per second.
+ */
+
+enum w2sg_state {
+ W2SG_IDLE, /* is not changing state */
+ W2SG_PULSE, /* activate on/off impulse */
+ W2SG_NOPULSE/* deactivate on/off impulse */
+};
+
+struct w2sg_data {
+ struct rfkill *rf_kill;
+ struct regulator *lna_regulator;
+ int lna_blocked;/* rfkill block gps active */
+ int lna_is_off; /* LNA is currently off */
+ int is_on; /* current state (0/1) */
+ unsigned long last_toggle;
+ unsigned long backoff;/* time to wait since last_toggle */
+ int on_off_gpio;/* the on-off gpio number */
+ struct serdev_device *uart;/* uart connected to the chip */
+ struct tty_driver *tty_drv;/* this is the user space tty */
+ struct device *dev;/* from tty_port_register_device() */
+ struct tty_port port;
+ int open_count; /* how often we were opened */
+ enumw2sg_stat
[PATCH v5 4/5] DTS: gta04: add uart2 child node for w2sg00x4
GTA04 has a W2SG0004/84 connected to UART2 of the OMAP3
processor. A GPIO can pulse the on/off toggle switch.
The VSIM regulator is used to power on/off the LNA of an external
active GPS antenna so that a driver can turn the LNA off if GPS is
not needed to save battery energy.
Signed-off-by: H. Nikolaus Schaller
---
arch/arm/boot/dts/omap3-gta04.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi
b/arch/arm/boot/dts/omap3-gta04.dtsi
index 4504908c23fe..1ad744a25c36 100644
--- a/arch/arm/boot/dts/omap3-gta04.dtsi
+++ b/arch/arm/boot/dts/omap3-gta04.dtsi
@@ -477,6 +477,13 @@
&uart2 {
pinctrl-names = "default";
pinctrl-0 = <&uart2_pins>;
+
+ gps: gps {
+ compatible = "wi2wi,w2sg0004";
+ lna-supply = <&vsim>; /* LNA regulator */
+ /* GPIO_145: trigger for on/off-impulse for w2sg0004 */
+ enable-gpios = <&gpio5 17 GPIO_ACTIVE_HIGH>;
+ };
};
&uart3 {
--
2.12.2
[PATCH v5 0/5] misc serdev: new serdev based driver for Wi2Wi w2sg00x4 GPS module
Changes V5: * clarified to keep it in drivers/misc and not create a new group drivers/gps * fix formatting of new entry in omap3-gta04.dtsi (suggested by Tony Lindgren) * removed MODULE_ALIAS (suggested by Andrew F. Davis) * some more formatting, code&style fixes (suggested by Andrew F. Davis) * apply __maybe_unused for PM (suggested by Andrew F. Davis) * fixed copyright and author records (suggested by Andrew F. Davis) 2017-11-15 22:38:01: Changes V4: * removed all pdata remains (suggested by Arnd Bergmann and Rob Herring) * fixed minor issues and subject/commit messages (suggested by Rob Herring) * added one missing Signed-off-By: (suggested by Andreas Färber) * added SPDX header (suggested by Rob Herring) 2017-11-15 16:19:17: Changes V3: * worked in suggestions by kbuild test robot * added misc+serdev to the subject 2017-11-12 22:00:02: Changes V2: * reduced to submit only w2sg00x4 GPS driver code * add DT node for GTA04 device to make use of the driver * split into base code and a debugging Kconfig option (brings device into false power state after boot) * worked in comments by kbuild robot and Rob Herring 2017-05-21 12:44:07: RFC V1 * RFC concerning new serdev based drivers for Wi2Wi w2sg00x4 GPS module and w2cbw003 bluetooth Years long history of getting this devices supported (original work by Neil Brown). H. Nikolaus Schaller (5): dt-bindings: define vendor prefix for Wi2Wi, Inc. dt-bindings: gps: add w2sg00x4 bindings documentation (GPS module with UART)) misc serdev: Add w2sg0004 (gps receiver) power control driver DTS: gta04: add uart2 child node for w2sg00x4 misc serdev: w2sg0004: add debugging code and Kconfig .../devicetree/bindings/gps/wi2wi,w2sg0004.txt | 24 + .../devicetree/bindings/vendor-prefixes.txt| 1 + arch/arm/boot/dts/omap3-gta04.dtsi | 7 + drivers/misc/Kconfig | 18 + drivers/misc/Makefile | 1 + drivers/misc/w2sg0004.c| 590 + 6 files changed, 641 insertions(+) create mode 100644 Documentation/devicetree/bindings/gps/wi2wi,w2sg0004.txt create mode 100644 drivers/misc/w2sg0004.c -- 2.12.2
[PATCH v5 2/5] dt-bindings: gps: add w2sg00x4 bindings documentation (GPS module with UART))
add bindings documentation for Wi2Wi W2SG00x4 GPS module.
Signed-off-by: H. Nikolaus Schaller
Acked-by: Rob Herring
---
.../devicetree/bindings/gps/wi2wi,w2sg0004.txt | 24 ++
1 file changed, 24 insertions(+)
create mode 100644 Documentation/devicetree/bindings/gps/wi2wi,w2sg0004.txt
diff --git a/Documentation/devicetree/bindings/gps/wi2wi,w2sg0004.txt
b/Documentation/devicetree/bindings/gps/wi2wi,w2sg0004.txt
new file mode 100644
index ..bcf307382afb
--- /dev/null
+++ b/Documentation/devicetree/bindings/gps/wi2wi,w2sg0004.txt
@@ -0,0 +1,24 @@
+Wi2Wi GPS module connected through UART
+
+Should be a subnode of the SoC UART it is connected to.
+
+Required properties:
+- compatible: should be one of (depending on precise model)
+ "wi2wi,w2sg0004"
+ "wi2wi,w2sg0084"
+- enable-gpio: the GPIO that controls the module's power toggle
+ input. A positive impulse of sufficent length toggles the
+ power state.
+
+Optional properties:
+- lna-supply: an (optional) LNA regulator that is enabled together with the
GPS receiver
+
+Example:
+
+&uart2 {
+ w2sg0004: gps {
+ compatible = "wi2wi,w2sg0004";
+ lna-supply = <&vsim>; /* LNA regulator */
+ enable-gpios = <&gpio5 17 GPIO_ACTIVE_HIGH>;/* GPIO_145:
trigger for turning on/off w2sg0004 */
+};
+};
--
2.12.2
Re: [PATCH v4 2/5] soc: qcom: Introduce QMI helpers
On Fri, Dec 1, 2017 at 6:35 AM, Bjorn Andersson wrote: > On Thu 30 Nov 00:18 PST 2017, Philippe Ombredanne wrote: > >> Bjorn, >> >> On Thu, Nov 30, 2017 at 2:16 AM, Bjorn Andersson >> wrote: >> [] >> > diff --git a/drivers/soc/qcom/qmi_interface.c >> > b/drivers/soc/qcom/qmi_interface.c >> > new file mode 100644 >> > index ..4027b52b0834 >> > --- /dev/null >> > +++ b/drivers/soc/qcom/qmi_interface.c >> > @@ -0,0 +1,857 @@ >> > +/* >> > + * Copyright (C) 2017 Linaro Ltd. >> > + * >> > + * This software is licensed under the terms of the GNU General Public >> > + * License version 2, as published by the Free Software Foundation, and >> > + * may be copied, distributed, and modified under those terms. >> > + * >> > + * This program is distributed in the hope that it will be useful, >> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of >> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the >> > + * GNU General Public License for more details. >> > + */ >> >> Could it make sense, especially for new files, to use the new SPDX ids >> and avoid adding boilerplate that will need to be cleaned up later? >> e.g. something like this instead, using the new conventions started by >> greg-kh and by documented tglx? >> >> NB: the // comment style is not a mistake and is what Linus wants >> there. See the threads on this topic. >> >> > @@ -0,0 +1,857 @@ >> > +// SPDX-License-Identifier: GPL-2.0 >> > +/* >> > + * Copyright (C) 2017 Linaro Ltd. >> > + */ >> >> Isn't this shorter and better? :P >> > > That sounds very reasonable, I will update the patches. Note that when you only have a copyright left in a header comment after removing the boilerplate, you might want to consider this even shorter and cleaner form instead. But that's just me telling this: >> > +// SPDX-License-Identifier: GPL-2.0 >> > +// Copyright (C) 2017 Linaro Ltd. >> BTW, if you need help to fix this on the rest of Linaro contributed >> code, I maintain a tool that can help there. >> > > I haven't seen any guidelines on how this should be introduced > throughout the kernel, Thomas has sent a first doc patch [1] set. AFAIK he is working on an updated version whenever his real time body clock yields a few ticks so he can wrap this out. But his real time clock only rarely yield ticks outside of hard real time coding work ;) Jonathan also wrote a nice background article on the topic at LWN [2]. I heard this was also briefly discussed among maintainers at the plumbers meetup in Los Angeles: for me I only briefly discussed this with Linus and Greg just before the meetup, but I could not stay longer. > should I make a similar push for the subsystems I > maintain? That would be great! And beside the fact it always feels good to delete lines of code for once, this is one of the rare areas where you can kill some lines and be pretty sure it will still compile and run afterwards well in most cases: Greg and Thomas found funny cases of .h headers included in assembly where using the // comment style was actually making things break weirdly and the compilation would go down in flames with a beautiful tail spin : in these cases, the convention is to use /**/ comments instead) Again, if you need help with this, I can modestly chip in with my scancode-toolkit tool and good intentions. [1] https://marc.info/?l=linux-kernel&m=151051532322831&w=2 [2] https://lwn.net/SubscriberLink/739183/262749cbe307ddc7/ -- Cordially Philippe Ombredanne, a happy licensing comments cleaner
Re: [PATCH v3 1/4] omapdrm: panel: fix compatible vendor string for td028ttec1
> Am 01.12.2017 um 02:57 schrieb Rob Herring :
>
> On Tue, Nov 28, 2017 at 04:48:54PM +0100, H. Nikolaus Schaller wrote:
>> The vendor name was "toppoly" but other panels and the vendor list
>> have defined it as "tpo". So let's fix it in driver and bindings.
>>
>> We keep the old definition in parallel to stay compatible with
>> potential older DTB setup.
>>
>> Signed-off-by: H. Nikolaus Schaller
>> ---
>> .../display/panel/{toppoly,td028ttec1.txt => tpo,td028ttec1.txt} | 4
>> ++--
>> drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c | 3 +++
>> drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td028ttec1.c | 3 +++
>> 3 files changed, 8 insertions(+), 2 deletions(-)
>> rename
>> Documentation/devicetree/bindings/display/panel/{toppoly,td028ttec1.txt =>
>> tpo,td028ttec1.txt} (84%)
>>
>> diff --git
>> a/Documentation/devicetree/bindings/display/panel/toppoly,td028ttec1.txt
>> b/Documentation/devicetree/bindings/display/panel/tpo,td028ttec1.txt
>> similarity index 84%
>> rename from
>> Documentation/devicetree/bindings/display/panel/toppoly,td028ttec1.txt
>> rename to Documentation/devicetree/bindings/display/panel/tpo,td028ttec1.txt
>> index 7175dc3740ac..ed34253d9fb1 100644
>> --- a/Documentation/devicetree/bindings/display/panel/toppoly,td028ttec1.txt
>> +++ b/Documentation/devicetree/bindings/display/panel/tpo,td028ttec1.txt
>> @@ -2,7 +2,7 @@ Toppoly TD028TTEC1 Panel
>>
>>
>> Required properties:
>> -- compatible: "toppoly,td028ttec1"
>> +- compatible: "tpo,td028ttec1"
>>
>> Optional properties:
>> - label: a symbolic name for the panel
>> @@ -14,7 +14,7 @@ Example
>> ---
>>
>> lcd-panel: td028ttec1@0 {
>> -compatible = "toppoly,td028ttec1";
>> +compatible = "tpo,td028ttec1";
>> reg = <0>;
>> spi-max-frequency = <10>;
>> spi-cpol;
>> diff --git a/drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c
>> b/drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c
>> index 0a38a0e8c925..a0dfa14f4fab 100644
>> --- a/drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c
>> +++ b/drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c
>> @@ -452,6 +452,8 @@ static int td028ttec1_panel_remove(struct spi_device
>> *spi)
>> }
>>
>> static const struct of_device_id td028ttec1_of_match[] = {
>> +{ .compatible = "omapdss,tpo,td028ttec1", },
>
> Why the omapdss part?
I think because they are (currently and still) omapdrm
(omapdss) specific since SoC specific drivers for the
same panel may exist in parallel.
All panel drivers in drivers/gpu/drm/omapdrm/displays
have and need this prefix.
As far as I understand, the omapdss driver takes the
DTS compatible string, adds "omapdss," and then looks for
a panel driver to probe.
See also: Sebastian Reichel's comment to "[PATCH v3 4/4] DTS: Pandora: fix
panel compatibility string"
BR,
Nikolaus Schaller
[PATCH 1/1] timecounter: Make cyclecounter struct part of timecounter struct
There is no real need for the users of timecounters to define cyclecounter
and timecounter variables separately. Since timecounter will always be
based on cyclecounter, have cyclecounter struct as member of timecounter
struct.
Suggested-by: Chris Wilson
Signed-off-by: Sagar Arun Kamble
Cc: Chris Wilson
Cc: John Stultz
Cc: Thomas Gleixner
Cc: Stephen Boyd
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: net...@vger.kernel.org
Cc: intel-wired-...@lists.osuosl.org
Cc: linux-r...@vger.kernel.org
Cc: alsa-de...@alsa-project.org
Cc: kvm...@lists.cs.columbia.edu
---
arch/microblaze/kernel/timer.c | 20 ++--
drivers/clocksource/arm_arch_timer.c | 19 ++--
drivers/net/ethernet/amd/xgbe/xgbe-dev.c | 3 +-
drivers/net/ethernet/amd/xgbe/xgbe-ptp.c | 9 +++---
drivers/net/ethernet/amd/xgbe/xgbe.h | 1 -
drivers/net/ethernet/broadcom/bnx2x/bnx2x.h| 1 -
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 20 ++--
drivers/net/ethernet/freescale/fec.h | 1 -
drivers/net/ethernet/freescale/fec_ptp.c | 30 +-
drivers/net/ethernet/intel/e1000e/e1000.h | 1 -
drivers/net/ethernet/intel/e1000e/netdev.c | 27
drivers/net/ethernet/intel/e1000e/ptp.c| 2 +-
drivers/net/ethernet/intel/igb/igb.h | 1 -
drivers/net/ethernet/intel/igb/igb_ptp.c | 25 ---
drivers/net/ethernet/intel/ixgbe/ixgbe.h | 1 -
drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c | 17 +-
drivers/net/ethernet/mellanox/mlx4/en_clock.c | 28 -
drivers/net/ethernet/mellanox/mlx4/mlx4_en.h | 1 -
.../net/ethernet/mellanox/mlx5/core/lib/clock.c| 34 ++--
drivers/net/ethernet/qlogic/qede/qede_ptp.c| 20 ++--
drivers/net/ethernet/ti/cpts.c | 36 --
drivers/net/ethernet/ti/cpts.h | 1 -
include/linux/mlx5/driver.h| 1 -
include/linux/timecounter.h| 4 +--
include/sound/hdaudio.h| 1 -
kernel/time/timecounter.c | 28 -
sound/hda/hdac_stream.c| 7 +++--
virt/kvm/arm/arch_timer.c | 6 ++--
28 files changed, 163 insertions(+), 182 deletions(-)
diff --git a/arch/microblaze/kernel/timer.c b/arch/microblaze/kernel/timer.c
index 7de941c..b7f89e9 100644
--- a/arch/microblaze/kernel/timer.c
+++ b/arch/microblaze/kernel/timer.c
@@ -199,27 +199,25 @@ static u64 xilinx_read(struct clocksource *cs)
return (u64)xilinx_clock_read();
}
-static struct timecounter xilinx_tc = {
- .cc = NULL,
-};
-
static u64 xilinx_cc_read(const struct cyclecounter *cc)
{
return xilinx_read(NULL);
}
-static struct cyclecounter xilinx_cc = {
- .read = xilinx_cc_read,
- .mask = CLOCKSOURCE_MASK(32),
- .shift = 8,
+static struct timecounter xilinx_tc = {
+ .cc.read = xilinx_cc_read,
+ .cc.mask = CLOCKSOURCE_MASK(32),
+ .cc.mult = 0,
+ .cc.shift = 8,
};
static int __init init_xilinx_timecounter(void)
{
- xilinx_cc.mult = div_sc(timer_clock_freq, NSEC_PER_SEC,
- xilinx_cc.shift);
+ struct cyclecounter *cc = &xilinx_tc.cc;
+
+ cc->mult = div_sc(timer_clock_freq, NSEC_PER_SEC, cc->shift);
- timecounter_init(&xilinx_tc, &xilinx_cc, sched_clock());
+ timecounter_init(&xilinx_tc, sched_clock());
return 0;
}
diff --git a/drivers/clocksource/arm_arch_timer.c
b/drivers/clocksource/arm_arch_timer.c
index 57cb2f0..31543e5 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -179,11 +179,6 @@ static u64 arch_counter_read_cc(const struct cyclecounter
*cc)
.flags = CLOCK_SOURCE_IS_CONTINUOUS,
};
-static struct cyclecounter cyclecounter __ro_after_init = {
- .read = arch_counter_read_cc,
- .mask = CLOCKSOURCE_MASK(56),
-};
-
struct ate_acpi_oem_info {
char oem_id[ACPI_OEM_ID_SIZE + 1];
char oem_table_id[ACPI_OEM_TABLE_ID_SIZE + 1];
@@ -915,7 +910,10 @@ static u64 arch_counter_get_cntvct_mem(void)
return ((u64) vct_hi << 32) | vct_lo;
}
-static struct arch_timer_kvm_info arch_timer_kvm_info;
+static struct arch_timer_kvm_info arch_timer_kvm_info = {
+ .timecounter.cc.read = arch_counter_read_cc,
+ .timecounter.cc.mask = CLOCKSOURCE_MASK(56),
+};
struct arch_timer_kvm_info *arch_timer_get_kvm_info(void)
{
@@ -925,6 +923,7 @@ struct arch_timer_kvm_info *arch_timer_get_kvm_info(void)
static void __init arch_counter_register(unsigned type)
{
u64 start_count;
+ struct cyclecounter *cc = &arch_timer_kvm_info.timecounter.cc;
/* Register the CP15 based counter if we ha
[PATCH v4 1/2] DTS: GTA04: improve panel compatibility string
Official vendor string is now "tpo" and not "toppoly".
Requires patch "omapdrm: panel: fix compatible vendor string for td028ttec1"
so that the driver understands both.
Signed-off-by: H. Nikolaus Schaller
---
arch/arm/boot/dts/omap3-gta04.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi
b/arch/arm/boot/dts/omap3-gta04.dtsi
index 4504908c23fe..ec27ed67a22a 100644
--- a/arch/arm/boot/dts/omap3-gta04.dtsi
+++ b/arch/arm/boot/dts/omap3-gta04.dtsi
@@ -86,7 +86,7 @@
/* lcd panel */
lcd: td028ttec1@0 {
- compatible = "toppoly,td028ttec1";
+ compatible = "tpo,td028ttec1";
reg = <0>;
spi-max-frequency = <10>;
spi-cpol;
--
2.12.2
Re: Creating cyclecounter and lock member in timecounter structure [ Was Re: [RFC 1/4] drm/i915/perf: Add support to correlate GPU timestamp with system time]
On 12/1/2017 2:33 AM, Saeed Mahameed wrote: On Mon, Nov 27, 2017 at 2:05 AM, Sagar Arun Kamble wrote: On 11/24/2017 7:01 PM, Thomas Gleixner wrote: On Fri, 24 Nov 2017, Sagar Arun Kamble wrote: On 11/24/2017 12:29 AM, Thomas Gleixner wrote: On Thu, 23 Nov 2017, Sagar Arun Kamble wrote: We needed inputs on possible optimization that can be done to timecounter/cyclecounter structures/usage. This mail is in response to review of patch https://patchwork.freedesktop.org/patch/188448/. As Chris's observation below, about dozen of timecounter users in the kernel have below structures defined individually: spinlock_t lock; struct cyclecounter cc; struct timecounter tc; Can we move lock and cc to tc? That way it will be convenient. Also it will allow unifying the locking/overflow watchdog handling across all drivers. Looks like none of the timecounter usage sites has a real need to separate timecounter and cyclecounter. Yes. Will share patch for this change. The lock is a different question. The locking of the various drivers differs and I have no idea how you want to handle that. Just sticking the lock into the datastructure and then not making use of it in the timercounter code and leave it to the callsites does not make sense. Most of the locks are held around timecounter_read. In some instances it is held when cyclecounter is updated standalone or is updated along with timecounter calls. Was thinking if we move the lock in timecounter functions, drivers just have to do locking around its operations on cyclecounter. But then another problem I see is there are variation of locking calls like lock_irqsave, lock_bh, write_lock_irqsave (some using rwlock_t). Should this all locking be left to driver only then? You could have the lock in the struct and protect the inner workings in the related core functions. That might remove locking requirements from some of the callers and the others still have their own thing around it. For drivers having static/fixed cyclecounter, we can rely only on lock inside timecounter. Most of the network drivers update cyclecounter at runtime and they will have to rely on two locks if we add one to timecounter. This may not be efficient for them. Also the lock in timecounter has to be less restrictive (may be seqlock) I guess. Cc'd Mellanox list for inputs on this. I have started feeling that the current approach of drivers managing the locks is the right one so better leave the lock out of timecounter. I agree here, In mlx5 we rely on our own read/write lock to serialize access to mlx5_clock struct (mlx5 timecounter and cyclecounter). the access is not as simple as lock() call time_counter_API unlock() Sometimes we also explicitly update/adjust timecycles counters with mlx5 specific calculations after we read the timecounter all inside our lock. e.g. @mlx5_ptp_adjfreq() write_lock_irqsave(&clock->lock, flags); timecounter_read(&clock->tc); clock->cycles.mult = neg_adj ? clock->nominal_c_mult - diff : clock->nominal_c_mult + diff; write_unlock_irqrestore(&clock->lock, flags); So i don't think it will be a simple task to have a generic thread safe timecounter API, without the need to specifically adjust it for all driver use-cases. Also as said above, in runtime it is not obvious in which context the timecounter will be accessed irq/soft irq/user. let's keep it as is, and let the driver decide which locking scheme is most suitable for it. Yes. Thanks for your inputs Saeed. Regards Sagar Thanks, Saeed. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 2/2] DTS: Pandora: fix panel compatibility string
We can remove the unnecessary "omapdss," prefix because
the omapdrm driver takes care of it when matching with
the driver table.
Signed-off-by: H. Nikolaus Schaller
---
arch/arm/boot/dts/omap3-pandora-common.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap3-pandora-common.dtsi
b/arch/arm/boot/dts/omap3-pandora-common.dtsi
index 53e007abdc71..64d967ec8c58 100644
--- a/arch/arm/boot/dts/omap3-pandora-common.dtsi
+++ b/arch/arm/boot/dts/omap3-pandora-common.dtsi
@@ -626,7 +626,7 @@
lcd: lcd@1 {
reg = <1>; /* CS1 */
- compatible ="omapdss,tpo,td043mtea1";
+ compatible ="tpo,td043mtea1";
spi-max-frequency = <10>;
spi-cpol;
spi-cpha;
--
2.12.2
[PATCH v4 0/2] Fixes for omapdrm on OpenPandora and GTA04
Changes V4: * removed already accepted panel driver patches * reworded commit subject to clarify 2017-11-28 16:49:00: Changes V3: * stay compatible with old DTB files which still use "toppoly" (suggested by Tomi Valkeinen) * replaced MODULE_ALIAS entries by MODULE_DEVICE_TABLE (suggested by Andrew F. Davis) * removed DSI VDDS patch as it has already been accepted 2017-11-16 09:50:22: Changes V2: * replaced patch to fix DSI VDDS for OMAP3 by equivalent patch from Laurent Pinchart * keep previous compatibility option in panel driver to handle older device tree binaries 2017-11-08 22:09:36: This patch set fixes vendor names of the panels and fixes a problem on omapdrm with enabling VDD_DSI for OMAP3 which is needed for displaying the Red and Green channel on OMAP3530 (Pandora). H. Nikolaus Schaller (2): DTS: GTA04: improve panel compatibility string DTS: Pandora: fix panel compatibility string arch/arm/boot/dts/omap3-gta04.dtsi | 2 +- arch/arm/boot/dts/omap3-pandora-common.dtsi | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) -- 2.12.2
Re: [PATCH v3 4/4] DTS: Pandora: fix panel compatibility string
> Am 30.11.2017 um 16:24 schrieb Tony Lindgren : > > * H. Nikolaus Schaller [171128 18:35]: >> Hi, >> >>> Am 28.11.2017 um 17:18 schrieb Tony Lindgren : >>> >>> * H. Nikolaus Schaller [171128 16:17]: Hi Tony, > Am 28.11.2017 um 17:04 schrieb Tony Lindgren : > > * H. Nikolaus Schaller [171128 15:52]: >> We can remove the unnecessary "omapdss," prefix because >> the omapdrm driver takes care of it when matching with >> the driver table. > > So is this needed as a fix or is this another clean-up? > > So is this is really needed as a fix? Hm. How do you differentiate between "fix" and "cleanup"? Maybe it is more a wording than a content issue... For me it is a "fix" because it is semantically wrong to have a prefix where it is not needed. And "fixing" it changes the compiler output by 8 bytes. >>> >>> How about let's call it a "typo fix" then? :) >> >> Well, it is not really a typo. > > Well what if the stable people pick it into earlier stable series > based on the word fix in the subject? That has happened before. Well, that may happen but IMHO *every* such backport must be checked for reasonability and compatibility and sometimes even modified to apply. And I think the author of the original patch receives a notification from the stable maintainers and can then veto. For Example I received "[PATCH 4.7 118/186] w1:omap_hdq: fix regression" "4.7-stable review patch. If anyone has any objections, please let me know." If that process still fails, we simply have to revert it... Has also happened before. So it will not be end of mankind :) > > I suggest you update the dts patches to use wording like > "update compatible to use new naming" or something similar. I have applied s/fix/improve/ for patch 3/4 and left 4/4 as suggested by Sebastian since it is really a strongly suggested correction. Since Tomi has already accepted the underlaying driver patch, [PATCH v4] will only have the remaining DTS patches. BR and thanks, Nikolaus
Re: [PATCH 00/18] introduce a new tool, valid access checker
On Wed, Nov 29, 2017 at 10:27:00AM +0100, Dmitry Vyukov wrote: > On Tue, Nov 28, 2017 at 8:48 AM, wrote: > > From: Joonsoo Kim > > > > Hello, > > > > This patchset introduces a new tool, valid access checker. > > > > Vchecker is a dynamic memory error detector. It provides a new debug feature > > that can find out an un-intended access to valid area. Valid area here means > > the memory which is allocated and allowed to be accessed by memory owner and > > un-intended access means the read/write that is initiated by non-owner. > > Usual problem of this class is memory overwritten. > > > > Most of debug feature focused on finding out un-intended access to > > in-valid area, for example, out-of-bound access and use-after-free, and, > > there are many good tools for it. But, as far as I know, there is no good > > tool > > to find out un-intended access to valid area. This kind of problem is really > > hard to solve so this tool would be very useful. > > > > This tool doesn't automatically catch a problem. Manual runtime > > configuration > > to specify the target object is required. > > > > Note that there was a similar attempt for the debugging overwritten problem > > however it requires manual code modifying and recompile. > > > > http://lkml.kernel.org/r/<20171117223043.7277-1-wen.gang.w...@oracle.com> > > > > To get more information about vchecker, please see a documention at > > the last patch. > > > > Patchset can also be available at > > > > https://github.com/JoonsooKim/linux/tree/vchecker-master-v1.0-next-20171122 > > > > Enjoy it. > > > Hi Joonsoo, > > I skimmed through the code and this looks fine from KASAN point of > view (minimal code changes and no perf impact). > I don't feel like I can judge if this should go in or not. I will not > use this, we use KASAN for large-scale testing, but vchecker is in a > different bucket, it is meant for developers debugging hard bugs. > Wengang come up with a very similar change, and Andi said that this > looks useful. Thanks for comment. Hello, other reviewers! Please let me know more opinions about this patchset. > > If the decision is that this goes in, please let me take a closer look > before this is merged. I will let you know when the decision is made. Thanks.
a racy access flag clearing warning when calling mmap system call
Hi will I find a warning by a syzkaller test; When the mmap syscall is called to create a virtual memory, firstly it delete a old huge page mapping area; Before splitting the huge page, the pmd of a huge page is set up. But The PTE_AF is zreo belonging to the current pmd of huge page. I suspect that when the child process is created, the PTE_AF is cleared in copy_one_pte(); So, the set_pte_at() can have a warning. There, whether the set_pte_at() should detect PTE_AF? Thanks. The log: set_pte_at: racy access flag clearing: 00e09d200bd1 -> 01e09d200bd1 [ cut here ] WARNING: at ../../../../../kernel/linux-4.1/arch/arm64/include/asm/pgtable.h:211 Modules linked in: CPU: 0 PID: 3665 Comm: syz-executor7 Not tainted 4.1.44+ #1 Hardware name: linux,dummy-virt (DT) task: ffc06a873fc0 ti: ffc05aefc000 task.ti: ffc05aefc000 PC is at pmdp_splitting_flush+0x194/0x1b0 LR is at pmdp_splitting_flush+0x194/0x1b0 pc : [] lr : [] pstate: 8145 sp : ffc05aeff770 x29: ffc05aeff770 x28: ffc05ae45800 x27: 2020 x26: ffc061fdf450 x25: 0002 x24: 0001 x23: ffc06333d9c8 x22: ffc0014ba000 x21: 01e09d200bd1 x20: 00e09d200bd1 x19: ffc05ae45800 x18: x17: 004b4000 x16: ffc00017fdc0 x15: 038ee280 x14: 3030653130203e2d x13: 2031646230303264 x12: 3930303030306530 x11: 30203a676e697261 x10: 656c632067616c66 x9 : 2073736563636120 x8 : 79636172203a7461 x7 : ffc05aeff430 x6 : ffc00015f38c x5 : 0003 x4 : x3 : 0003 x2 : 0001 x1 : ff9005a03000 x0 : 004b Call trace: [] pmdp_splitting_flush+0x194/0x1b0 [] split_huge_page_to_list+0x168/0xdb0 [] __split_huge_page_pmd+0x1b0/0x510 [] split_huge_page_pmd_mm+0x84/0x88 [] split_huge_page_address+0xc4/0xe8 [] __vma_adjust_trans_huge+0x15c/0x190 [] vma_adjust+0x884/0x9f0 [] __split_vma.isra.5+0x200/0x310 [] do_munmap+0x5e0/0x608 [] mmap_region+0x12c/0x900 [] do_mmap_pgoff+0x484/0x540 [] vm_mmap_pgoff+0x128/0x158 [] SyS_mmap_pgoff+0x188/0x300 [] sys_mmap+0x58/0x80
Re: [Intel-gfx] [RFC PATCH 3/6] drm/i915: Add HDCP framework + base implementation
On Fri, Dec 01, 2017 at 12:53:31PM +0530, Ramalingam C wrote:
> Sean,
>
> IMHO, it will good if we can have all generic hdcp1.4 authentication flow in
> drm helpers and all interested display drivers to use them.
>
> This Design will make the extending of hdcp easy for other display drivers
> based on DRM.
>
> We can have the required drm_hdcp_shim type of implementation at drm
> structure which will be called for platform specific operations (like
> prepare an, send aksv, program bksv/repeater/r0 and verify sha1 etc)?
I discussed this exact question with Sean Paul, and apparently the
hardware designs are too diverse to make shared code much useful. Some hw
has the entire hdcp flow in hw, some almost nothing (like i915 here), and
then there's everything in between.
Given that Sean has seen a lot more hdcp implementations than we have,
that we right now have no other implementation than i915 in upstream and
than wrong abstraction is much harder to fix than no abstraction I'm going
with Sean's approach of "no generic abstraction" here. Personally I'm not
even fully sold on the shim abstraction, but I think by&large that one is
fine.
> On Thursday 30 November 2017 08:38 AM, Sean Paul wrote:
> > This patch adds the framework required to add HDCP support to intel
> > connectors. It implements Aksv loading from fuse, and parts 1/2/3
> > of the HDCP authentication scheme.
> >
> > Note that without shim implementations, this does not actually implement
> > HDCP. That will come in subsequent patches.
> >
> > Signed-off-by: Sean Paul
> > ---
> > drivers/gpu/drm/i915/Makefile | 1 +
> > drivers/gpu/drm/i915/i915_reg.h | 83 +
> > drivers/gpu/drm/i915/intel_atomic.c | 26 +-
> > drivers/gpu/drm/i915/intel_ddi.c| 14 +
> > drivers/gpu/drm/i915/intel_drv.h| 53 +++
> > drivers/gpu/drm/i915/intel_hdcp.c | 636
> >
> > 6 files changed, 811 insertions(+), 2 deletions(-)
> > create mode 100644 drivers/gpu/drm/i915/intel_hdcp.c
> >
> > diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> > index 6c3b0481ef82..1e745508e437 100644
> > --- a/drivers/gpu/drm/i915/Makefile
> > +++ b/drivers/gpu/drm/i915/Makefile
> > @@ -87,6 +87,7 @@ i915-y += intel_audio.o \
> > intel_fbc.o \
> > intel_fifo_underrun.o \
> > intel_frontbuffer.o \
> > + intel_hdcp.o \
> > intel_hotplug.o \
> > intel_modes.o \
> > intel_overlay.o \
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 68a58cce6ab1..43128030171d 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -7991,6 +7991,7 @@ enum {
> > #define GEN9_MEM_LATENCY_LEVEL_1_5_SHIFT 8
> > #define GEN9_MEM_LATENCY_LEVEL_2_6_SHIFT 16
> > #define GEN9_MEM_LATENCY_LEVEL_3_7_SHIFT 24
> > +#define SKL_PCODE_LOAD_HDCP_KEYS 0x5
> > #define SKL_PCODE_CDCLK_CONTROL 0x7
> > #define SKL_CDCLK_PREPARE_FOR_CHANGE 0x3
> > #define SKL_CDCLK_READY_FOR_CHANGE0x1
> > @@ -8285,6 +8286,88 @@ enum skl_power_gate {
> > #define SKL_PW_TO_PG(pw) ((pw) - SKL_DISP_PW_1 + SKL_PG1)
> > #define SKL_FUSE_PG_DIST_STATUS(pg) (1 << (27 - (pg)))
> > +
> > +/* HDCP Key Registers */
> > +#define SKL_HDCP_KEY_CONF _MMIO(0x66c00)
> > +#define SKL_HDCP_AKSV_SEND_TRIGGER BIT(31)
> > +#define SKL_HDCP_CLEAR_KEYS_TRIGGER BIT(30)
> > +#define SKL_HDCP_KEY_STATUS_MMIO(0x66c04)
> > +#define SKL_HDCP_FUSE_IN_PROGRESS BIT(7)
> > +#define SKL_HDCP_FUSE_ERROR BIT(6)
> > +#define SKL_HDCP_FUSE_DONEBIT(5)
> > +#define SKL_HDCP_KEY_LOAD_STATUS BIT(1)
> > +#define SKL_HDCP_KEY_LOAD_DONEBIT(0)
> > +#define SKL_HDCP_AKSV_LO _MMIO(0x66c10)
> > +#define SKL_HDCP_AKSV_HI _MMIO(0x66c14)
> > +
> > +/* HDCP Repeater Registers */
> > +#define SKL_HDCP_REP_CTL _MMIO(0x66d00)
> > +#define SKL_HDCP_DDIB_REP_PRESENT BIT(30)
> > +#define SKL_HDCP_DDIA_REP_PRESENT BIT(29)
> > +#define SKL_HDCP_DDIC_REP_PRESENT BIT(28)
> > +#define SKL_HDCP_DDID_REP_PRESENT BIT(27)
> > +#define SKL_HDCP_DDIF_REP_PRESENT BIT(26)
> > +#define SKL_HDCP_DDIE_REP_PRESENT BIT(25)
> > +#define SKL_HDCP_DDIB_SHA1_M0 (1 << 20)
> > +#define SKL_HDCP_DDIA_SHA1_M0 (2 << 20)
> > +#define SKL_HDCP_DDIC_SHA1_M0 (3 << 20)
> > +#define SKL_HDCP_DDID_SHA1_M0 (4 << 20)
> > +#define SKL_HDCP_DDIF_SHA1_M0 (5 << 20)
> > +#define SKL_HDCP_DDIE_SHA1_M0 (6 << 20) // Bspec says 5?
> > +#define SKL_HDCP_SHA1_BUSYBIT(16)
> > +#define SKL_HDCP_SHA1_READY BIT(17)
> > +#define SKL_HDCP_SHA1_COMPLETEBIT(18)
> > +#define SKL_HDCP_SHA1_V_MATCH BIT(19)
> > +#define SKL_HDCP_SHA1_TEXT_32 (1 << 1)
> > +
Re: [PATCH v4] f2fs: obsolete free nid list approach
Hi Chao,
This is really hard to review and risky a lot to apply it shortly. Do we have a
strong reason we have to do this? The original design goal was to minimize
allocation delay which is almost zero for now. Of course, I agreed that there'd
be some trade-off though, we don't have a critical issue with this, FWIW.
Can we expect to see some speed gains with this? How much?
Thanks,
On 11/30, Chao Yu wrote:
> Previously, we use free nid list to manage free nid entry, so during nid
> allocation, we can just pick up one entry from list header, which has
> quite low overhead.
>
> But sadly, during initialization of free nid list, we should do lookup
> combining with lots of different inner caches, including NAT page cache,
> nat entry cache, curseg journal cache and free nid bitmap, so flow became
> quite complicated.
>
> In this patch, we choose to obsolete old free nid management approach,
> instead, we use existing free nid bitmap which has the same functionality
> to manage free nid, in order to make free nid management codes more easy
> to maintain.
>
> Signed-off-by: Chao Yu
> ---
> v4: clean up codes.
> fs/f2fs/checkpoint.c | 1 -
> fs/f2fs/debug.c | 7 +-
> fs/f2fs/f2fs.h | 9 +-
> fs/f2fs/inode.c | 2 +
> fs/f2fs/node.c | 487
> +--
> fs/f2fs/node.h | 22 ---
> fs/f2fs/segment.c| 5 -
> fs/f2fs/shrinker.c | 14 --
> 8 files changed, 164 insertions(+), 383 deletions(-)
>
> diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
> index d1f160ae4959..885525a0d981 100644
> --- a/fs/f2fs/checkpoint.c
> +++ b/fs/f2fs/checkpoint.c
> @@ -1024,7 +1024,6 @@ static void __prepare_cp_block(struct f2fs_sb_info *sbi)
> struct f2fs_nm_info *nm_i = NM_I(sbi);
> nid_t last_nid = nm_i->next_scan_nid;
>
> - next_free_nid(sbi, &last_nid);
> ckpt->valid_block_count = cpu_to_le64(valid_user_blocks(sbi));
> ckpt->valid_node_count = cpu_to_le32(valid_node_count(sbi));
> ckpt->valid_inode_count = cpu_to_le32(valid_inode_count(sbi));
> diff --git a/fs/f2fs/debug.c b/fs/f2fs/debug.c
> index a66107b5cfff..413e031b10c4 100644
> --- a/fs/f2fs/debug.c
> +++ b/fs/f2fs/debug.c
> @@ -100,9 +100,8 @@ static void update_general_status(struct f2fs_sb_info
> *sbi)
> si->dirty_nats = NM_I(sbi)->dirty_nat_cnt;
> si->sits = MAIN_SEGS(sbi);
> si->dirty_sits = SIT_I(sbi)->dirty_sentries;
> - si->free_nids = NM_I(sbi)->nid_cnt[FREE_NID];
> + si->free_nids = NM_I(sbi)->available_free_nids;
> si->avail_nids = NM_I(sbi)->available_nids;
> - si->alloc_nids = NM_I(sbi)->nid_cnt[PREALLOC_NID];
> si->bg_gc = sbi->bg_gc;
> si->util_free = (int)(free_user_blocks(sbi) >> sbi->log_blocks_per_seg)
> * 100 / (int)(sbi->user_block_count >> sbi->log_blocks_per_seg)
> @@ -233,10 +232,6 @@ static void update_mem_info(struct f2fs_sb_info *sbi)
> atomic_read(&SM_I(sbi)->dcc_info->discard_cmd_cnt);
> }
>
> - /* free nids */
> - si->cache_mem += (NM_I(sbi)->nid_cnt[FREE_NID] +
> - NM_I(sbi)->nid_cnt[PREALLOC_NID]) *
> - sizeof(struct free_nid);
> si->cache_mem += NM_I(sbi)->nat_cnt * sizeof(struct nat_entry);
> si->cache_mem += NM_I(sbi)->dirty_nat_cnt *
> sizeof(struct nat_entry_set);
> diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> index d92eba66263c..f08e0feb38c1 100644
> --- a/fs/f2fs/f2fs.h
> +++ b/fs/f2fs/f2fs.h
> @@ -723,14 +723,13 @@ struct f2fs_nm_info {
> unsigned int nat_blocks;/* # of nat blocks */
>
> /* free node ids management */
> - struct radix_tree_root free_nid_root;/* root of the free_nid cache */
> - struct list_head free_nid_list; /* list for free nids excluding
> preallocated nids */
> - unsigned int nid_cnt[MAX_NID_STATE];/* the number of free node id */
> - spinlock_t nid_list_lock; /* protect nid lists ops */
> + spinlock_t free_nid_lock; /* protect nid lists ops */
> struct mutex build_lock;/* lock for build free nids */
> unsigned char (*free_nid_bitmap)[NAT_ENTRY_BITMAP_SIZE];
> + unsigned char (*prealloc_nid_bitmap)[NAT_ENTRY_BITMAP_SIZE];
> unsigned char *nat_block_bitmap;
> unsigned short *free_nid_count; /* free nid count of NAT block */
> + unsigned int available_free_nids; /* available free nid count in
> bitmaps */
>
> /* for checkpoint */
> char *nat_bitmap; /* NAT bitmap pointer */
> @@ -2622,11 +2621,9 @@ int fsync_node_pages(struct f2fs_sb_info *sbi, struct
> inode *inode,
> struct writeback_control *wbc, bool atomic);
> int sync_node_pages(struct f2fs_sb_info *sbi, struct writeback_control *wbc,
> bool do_balance, enum iostat_type io_type);
> -void build_free_nids(struct f2fs_sb_info *sbi, bool syn
Re: [RFC PATCH 5/6] drm/i915: Implement HDCP for HDMI
Sean,
We might want to check the panel's HDCP capability? Agreed that majority
of HDMI/DP panel's supports it, but there is a possibility that we might
avoid authentication on non-hdcp panels.
As per HDCP specification, check for valid bksv will serve the purpose.
On Thursday 30 November 2017 08:39 AM, Sean Paul wrote:
This patch adds HDCP support for HDMI connectors by implementing
the intel_hdcp_shim.
Nothing too special, just a bunch of DDC reads/writes.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_ddi.c | 50
drivers/gpu/drm/i915/intel_hdmi.c | 253 ++
3 files changed, 304 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 78370877fea3..061c52a5d7d7 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8400,6 +8400,7 @@ enum skl_power_gate {
#define TRANS_DDI_EDP_INPUT_A_ONOFF (4<<12)
#define TRANS_DDI_EDP_INPUT_B_ONOFF (5<<12)
#define TRANS_DDI_EDP_INPUT_C_ONOFF (6<<12)
+#define TRANS_DDI_HDCP_SIGNALLING (1<<9)
#define TRANS_DDI_DP_VC_PAYLOAD_ALLOC(1<<8)
#define TRANS_DDI_HDMI_SCRAMBLER_CTS_ENABLE (1<<7)
#define TRANS_DDI_HDMI_SCRAMBLER_RESET_FREQ (1<<6)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 0e69337f410d..0324b09ecf76 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1650,6 +1650,56 @@ void intel_ddi_disable_transcoder_func(struct
drm_i915_private *dev_priv,
I915_WRITE(reg, val);
}
+int intel_ddi_disable_hdcp_signalling(struct intel_encoder *intel_encoder)
+{
+ struct drm_device *dev = intel_encoder->base.dev;
+ struct drm_i915_private *dev_priv = to_i915(dev);
+ enum pipe pipe = 0;
+ int ret = 0;
+ uint32_t tmp;
+
+ if (!intel_display_power_get_if_enabled(dev_priv,
+ intel_encoder->power_domain))
+ return -ENXIO;
+
+ if (!intel_encoder->get_hw_state(intel_encoder, &pipe)) {
+ ret = -EIO;
+ goto out;
+ }
+
+ tmp = I915_READ(TRANS_DDI_FUNC_CTL(pipe));
+ tmp &= ~TRANS_DDI_HDCP_SIGNALLING;
+ I915_WRITE(TRANS_DDI_FUNC_CTL(pipe), tmp);
+out:
+ intel_display_power_put(dev_priv, intel_encoder->power_domain);
+ return ret;
+}
+
+int intel_ddi_enable_hdcp_signalling(struct intel_encoder *intel_encoder)
+{
+ struct drm_device *dev = intel_encoder->base.dev;
+ struct drm_i915_private *dev_priv = to_i915(dev);
+ enum pipe pipe = 0;
+ int ret = 0;
+ uint32_t tmp;
+
+ if (!intel_display_power_get_if_enabled(dev_priv,
+ intel_encoder->power_domain))
+ return -ENXIO;
+
+ if (!intel_encoder->get_hw_state(intel_encoder, &pipe)) {
+ ret = -EIO;
+ goto out;
+ }
+
+ tmp = I915_READ(TRANS_DDI_FUNC_CTL(pipe));
+ tmp |= TRANS_DDI_HDCP_SIGNALLING;
+ I915_WRITE(TRANS_DDI_FUNC_CTL(pipe), tmp);
+out:
+ intel_display_power_put(dev_priv, intel_encoder->power_domain);
+ return ret;
+}
+
bool intel_ddi_connector_get_hw_state(struct intel_connector *intel_connector)
{
struct drm_device *dev = intel_connector->base.dev;
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 59247a49a077..563168897dd9 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -34,6 +34,7 @@
#include
#include
#include
+#include
#include
#include "intel_drv.h"
#include
@@ -875,6 +876,252 @@ void intel_dp_dual_mode_set_tmds_output(struct intel_hdmi
*hdmi, bool enable)
adapter, enable);
}
+static int intel_hdmi_hdcp_read(struct intel_digital_port *intel_dig_port,
+ unsigned int offset, void *buffer, size_t size)
+{
+ struct intel_hdmi *hdmi = &intel_dig_port->hdmi;
+ struct drm_i915_private *dev_priv =
+ intel_dig_port->base.base.dev->dev_private;
+ struct i2c_adapter *adapter = intel_gmbus_get_adapter(dev_priv,
+ hdmi->ddc_bus);
+ int ret;
+ u8 start = offset & 0xff;
+ struct i2c_msg msgs[] = {
+ {
+ .addr = DRM_HDCP_DDC_ADDR,
+ .flags = 0,
+ .len = 1,
+ .buf = &start,
+ },
+ {
+ .addr = DRM_HDCP_DDC_ADDR,
+ .flags = I2C_M_RD,
+ .len = size,
+ .buf = buffer
+ }
+ };
+ ret = i2c_transfer(adapter, msgs, ARRAY_SIZE(msgs));
+ if (ret == ARRAY_SIZE(msgs))
+ return 0;
Re: [PATCH 1/2] x86/stacktrace: do not fail when regs on stack for ORC
On 11/30/2017, 08:59 PM, Josh Poimboeuf wrote: > On Thu, Nov 30, 2017 at 01:57:10PM -0600, Josh Poimboeuf wrote: >> On Thu, Nov 30, 2017 at 09:03:24AM +0100, Jiri Slaby wrote: >>> save_stack_trace_reliable now returns "non reliable" when there are >>> kernel pt_regs on stack. This means an interrupt or exception happened. >>> Somewhere down the route. It is a problem for frame pointer unwinder, >>> because the frame might now have been set up yet when the irq happened, >>> so it might fail to unwind from the interrupted function. >>> >>> With ORC, this is not a problem, as ORC has out-of-band data. We can >>> find ORC data even for the IP in interrupted function and always unwind >>> one level up. >>> >>> So introduce `unwind_regs_reliable' which decides if this is an issue >>> for the currently selected unwinder at all and change the code >>> accordingly. >> >> Thanks. I'm thinking there a few ways we can simplify things. (Most of >> these are actually issues with the existing code.) >> >> - Currently we check to make sure that there's no frame *after* the user >> space regs. I think there's no way that could ever happen and the >> check is overkill. >> >> - We should probably remove the STACKTRACE_DUMP_ONCE() warnings. There >> are some known places where a stack trace will fail, particularly with >> generated code. I wish we had a DEBUG_WARN_ON() macro which used >> pr_debug(), but oh well. At least the livepatch code has some helpful >> pr_warn()s, those are probably good enough. > ^^^ > meant to say pr_debug()s. > > Also adding the live patching mailing list as an FYI. The changes are now in: https://git.kernel.org/pub/scm/linux/kernel/git/jirislaby/linux.git/log/?h=devel Letting 01 bot to run through them, then I will send a v2. thanks, -- js suse labs
Re: [PATCH 1/2] f2fs: pass down write hints to block layer for bufferd write
On 11/30, Chao Yu wrote:
> On 2017/11/28 8:23, Hyunchul Lee wrote:
> > From: Hyunchul Lee
> >
> > This implements which hint is passed down to block layer
> > for datas from the specific segment type.
> >
> > segment type hints
> > -
> > COLD_NODE & COLD_DATAWRITE_LIFE_EXTREME
> > WARM_DATAWRITE_LIFE_NONE
> > HOT_NODE & WARM_NODE WRITE_LIFE_LONG
> > HOT_DATA WRITE_LIFE_MEDIUM
> > META_DATAWRITE_LIFE_SHORT
>
> The correspondence looks good to me.
Still, I don't fully get the point. Why do we have to assign WRITE_LIFE_NONE
to WARM_DATA? Why not using WRITE_LIFE_NOT_SET?
> >
> > Many thanks to Chao Yu and Jaegeuk Kim for comments to
> > implement this patch.
> >
> > Signed-off-by: Hyunchul Lee
> > ---
> > fs/f2fs/data.c| 1 +
> > fs/f2fs/f2fs.h| 2 ++
> > fs/f2fs/segment.c | 29 +
> > fs/f2fs/super.c | 2 ++
> > 4 files changed, 34 insertions(+)
> >
> > diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
> > index a7ae418..0919a43 100644
> > --- a/fs/f2fs/data.c
> > +++ b/fs/f2fs/data.c
> > @@ -437,6 +437,7 @@ int f2fs_submit_page_write(struct f2fs_io_info *fio)
> > }
> > io->bio = __bio_alloc(sbi, fio->new_blkaddr,
> > BIO_MAX_PAGES, false);
> > + io->bio->bi_write_hint = io->write_hint;
>
> Need to assign bi_write_hint for IPU path?
>
> - rewrite_data_page
> - f2fs_submit_page_bio
>
> > io->fio = *fio;
> > }
> >
> > diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> > index 7bcd148..be3cb0c 100644
> > --- a/fs/f2fs/f2fs.h
> > +++ b/fs/f2fs/f2fs.h
> > @@ -969,6 +969,7 @@ struct f2fs_bio_info {
> > struct rw_semaphore io_rwsem; /* blocking op for bio */
> > spinlock_t io_lock; /* serialize DATA/NODE IOs */
> > struct list_head io_list; /* track fios */
> > + enum rw_hint write_hint;
>
> Add missing comment?
>
> > };
> >
> > #define FDEV(i)(sbi->devs[i])
> > @@ -2674,6 +2675,7 @@ int lookup_journal_in_cursum(struct f2fs_journal
> > *journal, int type,
> > int __init create_segment_manager_caches(void);
> > void destroy_segment_manager_caches(void);
> > int rw_hint_to_seg_type(enum rw_hint hint);
> > +enum rw_hint io_type_to_rw_hint(enum page_type page, enum temp_type temp);
> >
> > /*
> > * checkpoint.c
> > diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
> > index c117e09..0570db7 100644
> > --- a/fs/f2fs/segment.c
> > +++ b/fs/f2fs/segment.c
> > @@ -2446,6 +2446,35 @@ int rw_hint_to_seg_type(enum rw_hint hint)
> > }
> > }
> >
>
> It will be better to copy commit log here to declare correspondence
> more clearly.
>
> Thanks,
>
> > +enum rw_hint io_type_to_rw_hint(enum page_type page, enum temp_type temp)
> > +{
> > + if (page == DATA) {
> > + switch (temp) {
> > + case WARM:
> > + return WRITE_LIFE_NONE;
> > + case COLD:
> > + return WRITE_LIFE_EXTREME;
> > + case HOT:
> > + return WRITE_LIFE_MEDIUM;
> > + default:
> > + return WRITE_LIFE_NOT_SET;
> > + }
> > + } else if (page == NODE) {
> > + switch (temp) {
> > + case WARM:
> > + case HOT:
> > + return WRITE_LIFE_LONG;
> > + case COLD:
> > + return WRITE_LIFE_EXTREME;
> > + default:
> > + return WRITE_LIFE_NOT_SET;
> > + }
> > +
> > + } else {
> > + return WRITE_LIFE_SHORT;
> > + }
> > +}
> > +
> > static int __get_segment_type_2(struct f2fs_io_info *fio)
> > {
> > if (fio->type == DATA)
> > diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
> > index a6c5dd4..51c19a0 100644
> > --- a/fs/f2fs/super.c
> > +++ b/fs/f2fs/super.c
> > @@ -2508,6 +2508,8 @@ static int f2fs_fill_super(struct super_block *sb,
> > void *data, int silent)
> > sbi->write_io[i][j].bio = NULL;
> > spin_lock_init(&sbi->write_io[i][j].io_lock);
> > INIT_LIST_HEAD(&sbi->write_io[i][j].io_list);
> > + sbi->write_io[i][j].write_hint =
> > + io_type_to_rw_hint(i, j);
> > }
> > }
> >
> >
Re: KASAN: stack-out-of-bounds Read in xfrm_state_find (3)
On Wed, Nov 22, 2017 at 08:05:00AM -0800, syzbot wrote:
> syzkaller has found reproducer for the following crash on
> 0c86a6bd85ff0629cd2c5141027fc1c8bb6cde9c
> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> C reproducer is attached
> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> for information about syzkaller reproducers
>
>
> BUG: KASAN: stack-out-of-bounds in xfrm_state_find+0x30fc/0x3230
> net/xfrm/xfrm_state.c:1051
> Read of size 4 at addr 8801ccaa7af8 by task syzkaller231684/3045
The patch below should fix this. I plan to apply it to the ipsec tree
after some advanced testing.
Subject: [PATCH RFC] xfrm: Fix stack-out-of-bounds with misconfigured transport
mode policies.
On policies with a transport mode template, we pass the addresses
from the flowi to xfrm_state_find(), assuming that the IP addresses
(and address family) don't change during transformation.
Unfortunately our policy template validation is not strict enough.
It is possible to configure policies with transport mode template
where the address family of the template does not match the selectors
address family. This lead to stack-out-of-bound reads because
we compare arddesses of the wrong family. Fix this by refusing
such a configuration, address family can not change on transport
mode.
We use the assumption that, on transport mode, the first templates
address family must match the address family of the policy selector.
Subsequent transport mode templates must mach the address family of
the previous template.
Reported-by: syzbot
Signed-off-by: Steffen Klassert
---
net/xfrm/xfrm_user.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c
index 983b0233767b..57ad016ae675 100644
--- a/net/xfrm/xfrm_user.c
+++ b/net/xfrm/xfrm_user.c
@@ -1419,11 +1419,14 @@ static void copy_templates(struct xfrm_policy *xp,
struct xfrm_user_tmpl *ut,
static int validate_tmpl(int nr, struct xfrm_user_tmpl *ut, u16 family)
{
+ u16 prev_family;
int i;
if (nr > XFRM_MAX_DEPTH)
return -EINVAL;
+ prev_family = family;
+
for (i = 0; i < nr; i++) {
/* We never validated the ut->family value, so many
* applications simply leave it at zero. The check was
@@ -1435,6 +1438,12 @@ static int validate_tmpl(int nr, struct xfrm_user_tmpl
*ut, u16 family)
if (!ut[i].family)
ut[i].family = family;
+ if ((ut[i].mode == XFRM_MODE_TRANSPORT) &&
+ (ut[i].family != prev_family))
+ return -EINVAL;
+
+ prev_family = ut[i].family;
+
switch (ut[i].family) {
case AF_INET:
break;
--
2.14.1
Re: [RFC PATCH 3/6] drm/i915: Add HDCP framework + base implementation
Sean,
IMHO, it will good if we can have all generic hdcp1.4 authentication
flow in drm helpers and all interested display drivers to use them.
This Design will make the extending of hdcp easy for other display
drivers based on DRM.
We can have the required drm_hdcp_shim type of implementation at drm
structure which will be called for platform specific operations (like
prepare an, send aksv, program bksv/repeater/r0 and verify sha1 etc)?
On Thursday 30 November 2017 08:38 AM, Sean Paul wrote:
This patch adds the framework required to add HDCP support to intel
connectors. It implements Aksv loading from fuse, and parts 1/2/3
of the HDCP authentication scheme.
Note that without shim implementations, this does not actually implement
HDCP. That will come in subsequent patches.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/i915_reg.h | 83 +
drivers/gpu/drm/i915/intel_atomic.c | 26 +-
drivers/gpu/drm/i915/intel_ddi.c| 14 +
drivers/gpu/drm/i915/intel_drv.h| 53 +++
drivers/gpu/drm/i915/intel_hdcp.c | 636
6 files changed, 811 insertions(+), 2 deletions(-)
create mode 100644 drivers/gpu/drm/i915/intel_hdcp.c
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 6c3b0481ef82..1e745508e437 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -87,6 +87,7 @@ i915-y += intel_audio.o \
intel_fbc.o \
intel_fifo_underrun.o \
intel_frontbuffer.o \
+ intel_hdcp.o \
intel_hotplug.o \
intel_modes.o \
intel_overlay.o \
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 68a58cce6ab1..43128030171d 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7991,6 +7991,7 @@ enum {
#define GEN9_MEM_LATENCY_LEVEL_1_5_SHIFT 8
#define GEN9_MEM_LATENCY_LEVEL_2_6_SHIFT 16
#define GEN9_MEM_LATENCY_LEVEL_3_7_SHIFT 24
+#define SKL_PCODE_LOAD_HDCP_KEYS 0x5
#define SKL_PCODE_CDCLK_CONTROL 0x7
#define SKL_CDCLK_PREPARE_FOR_CHANGE 0x3
#define SKL_CDCLK_READY_FOR_CHANGE0x1
@@ -8285,6 +8286,88 @@ enum skl_power_gate {
#define SKL_PW_TO_PG(pw) ((pw) - SKL_DISP_PW_1 + SKL_PG1)
#define SKL_FUSE_PG_DIST_STATUS(pg) (1 << (27 - (pg)))
+
+/* HDCP Key Registers */
+#define SKL_HDCP_KEY_CONF _MMIO(0x66c00)
+#define SKL_HDCP_AKSV_SEND_TRIGGER BIT(31)
+#define SKL_HDCP_CLEAR_KEYS_TRIGGER BIT(30)
+#define SKL_HDCP_KEY_STATUS_MMIO(0x66c04)
+#define SKL_HDCP_FUSE_IN_PROGRESS BIT(7)
+#define SKL_HDCP_FUSE_ERROR BIT(6)
+#define SKL_HDCP_FUSE_DONEBIT(5)
+#define SKL_HDCP_KEY_LOAD_STATUS BIT(1)
+#define SKL_HDCP_KEY_LOAD_DONEBIT(0)
+#define SKL_HDCP_AKSV_LO _MMIO(0x66c10)
+#define SKL_HDCP_AKSV_HI _MMIO(0x66c14)
+
+/* HDCP Repeater Registers */
+#define SKL_HDCP_REP_CTL _MMIO(0x66d00)
+#define SKL_HDCP_DDIB_REP_PRESENT BIT(30)
+#define SKL_HDCP_DDIA_REP_PRESENT BIT(29)
+#define SKL_HDCP_DDIC_REP_PRESENT BIT(28)
+#define SKL_HDCP_DDID_REP_PRESENT BIT(27)
+#define SKL_HDCP_DDIF_REP_PRESENT BIT(26)
+#define SKL_HDCP_DDIE_REP_PRESENT BIT(25)
+#define SKL_HDCP_DDIB_SHA1_M0 (1 << 20)
+#define SKL_HDCP_DDIA_SHA1_M0 (2 << 20)
+#define SKL_HDCP_DDIC_SHA1_M0 (3 << 20)
+#define SKL_HDCP_DDID_SHA1_M0 (4 << 20)
+#define SKL_HDCP_DDIF_SHA1_M0 (5 << 20)
+#define SKL_HDCP_DDIE_SHA1_M0 (6 << 20) // Bspec says 5?
+#define SKL_HDCP_SHA1_BUSYBIT(16)
+#define SKL_HDCP_SHA1_READY BIT(17)
+#define SKL_HDCP_SHA1_COMPLETEBIT(18)
+#define SKL_HDCP_SHA1_V_MATCH BIT(19)
+#define SKL_HDCP_SHA1_TEXT_32 (1 << 1)
+#define SKL_HDCP_SHA1_COMPLETE_HASH (2 << 1)
+#define SKL_HDCP_SHA1_TEXT_24 (4 << 1)
+#define SKL_HDCP_SHA1_TEXT_16 (5 << 1)
+#define SKL_HDCP_SHA1_TEXT_8 (6 << 1)
+#define SKL_HDCP_SHA1_TEXT_0 (7 << 1)
+#define SKL_HDCP_SHA_V_PRIME_H0_MMIO(0x66d04)
+#define SKL_HDCP_SHA_V_PRIME_H1_MMIO(0x66d08)
+#define SKL_HDCP_SHA_V_PRIME_H2_MMIO(0x66d0C)
+#define SKL_HDCP_SHA_V_PRIME_H3_MMIO(0x66d10)
+#define SKL_HDCP_SHA_V_PRIME_H4_MMIO(0x66d14)
+#define SKL_HDCP_SHA_V_PRIME(h)_MMIO((0x66d04 + h * 4))
+#define SKL_HDCP_SHA_TEXT _MMIO(0x66d18)
+
+/* HDCP Auth Registers */
+#define _SKL_PORTA_HDCP_AUTHENC0x66800
+#define _SKL_PORTB_HDCP_AUTHENC0x66500
+#define _SKL_PORTC_HDCP_AUTHENC0x66600
+#define _SKL_PORTD_HDCP_AUTHENC0x66700
+#define _SKL_PORTE_HDCP_AUTHENC
Re: [PATCH resend] mm/page_alloc: fix comment is __get_free_pages
On Thu 30-11-17 13:17:06, Andrew Morton wrote: > On Thu, 30 Nov 2017 07:53:35 +0100 Michal Hocko wrote: > > > > mm... So we have a caller which hopes to be getting highmem pages but > > > isn't. Caller then proceeds to pointlessly kmap the page and wonders > > > why it isn't getting as much memory as it would like on 32-bit systems, > > > etc. > > > > How he can kmap the page when he gets a _virtual_ address? > > doh. > > > > I do think we should help ferret out such bogosity. A WARN_ON_ONCE > > > would suffice. > > > > This function has always been about lowmem pages. I seriously doubt we > > have anybody confused and asking for a highmem page in the kernel. I > > haven't checked that but it would already blow up as VM_BUG_ON tends to > > be enabled on many setups. > > OK. But silently accepting __GFP_HIGHMEM is a bit weird - callers > shouldn't be doing that in the first place. Yes, they shouldn't be. > I wonder what happens if we just remove the WARN_ON and pass any > __GFP_HIGHMEM straight through. The caller gets a weird address from > page_to_virt(highmem page) and usually goes splat? Good enough > treatment for something which never happens anyway? page_address will return NULL so they will blow up and leak the freshly allocated memory. I do not think this is really desirable. We _could_ handle this case but I am not really sure this is a win. A silent fixup sounds like the most simply protection. -- Michal Hocko SUSE Labs
Re: [PATCH v2] staging: xgifb: remove macros with hidden variable
On Thu, Nov 30, 2017 at 10:39:48AM -0500, Joshua Abraham wrote:
> diff --git a/drivers/staging/xgifb/XGI_main_26.c
> b/drivers/staging/xgifb/XGI_main_26.c
> index 6feecc55d2bc..6de66eaad96b 100644
> --- a/drivers/staging/xgifb/XGI_main_26.c
> +++ b/drivers/staging/xgifb/XGI_main_26.c
> @@ -34,16 +34,16 @@ static void dumpVGAReg(struct xgifb_video_info
> *xgifb_info)
> {
> u8 i, reg;
>
> - xgifb_reg_set(XGISR, 0x05, 0x86);
> + xgifb_reg_set(xgifb_info->dev_info.P3c4, 0x05, 0x86);
This patch is OK, but it might be nicer to create a temporary variable
so the lines are not so long:
struct vb_device_info *vb = &xgifb_info->dev_info;
u8 i, reg;
xgifb_reg_set(vb->P3c4, 0x05, 0x86);
I chose "vb" based on the struct name... "dev" and "info" aren't very
useful in a name because there are a lot of devices and lots of types
of info.
regards,
dan carpneter
Re: [PATCH 1/3] vhost: fix skb leak in handle_rx()
On 2017年12月01日 13:54, w...@redhat.com wrote:
From: Wei Xu
Matthew found a roughly 40% tcp throughput regression with commit
c67df11f(vhost_net: try batch dequing from skb array) as discussed
in the following thread:
https://www.mail-archive.com/netdev@vger.kernel.org/msg187936.html
Eventually we figured out that it was a skb leak in handle_rx()
when sending packets to the VM. This usually happens when a guest
can not drain out vq as fast as vhost fills in, afterwards it sets
off the traffic jam and leaks skb(s) which occurs as no headcount
to send on the vq from vhost side.
This can be avoided by making sure we have got enough headcount
before actually consuming a skb from the batched rx array while
transmitting, which is simply done by moving checking the zero
headcount a bit ahead.
Signed-off-by: Wei Xu
Reported-by: Matthew Rosato
---
drivers/vhost/net.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index 8d626d7..c7bdeb6 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -778,16 +778,6 @@ static void handle_rx(struct vhost_net *net)
/* On error, stop handling until the next kick. */
if (unlikely(headcount < 0))
goto out;
- if (nvq->rx_array)
- msg.msg_control = vhost_net_buf_consume(&nvq->rxq);
- /* On overrun, truncate and discard */
- if (unlikely(headcount > UIO_MAXIOV)) {
- iov_iter_init(&msg.msg_iter, READ, vq->iov, 1, 1);
- err = sock->ops->recvmsg(sock, &msg,
-1, MSG_DONTWAIT | MSG_TRUNC);
- pr_debug("Discarded rx packet: len %zd\n", sock_len);
- continue;
- }
/* OK, now we need to know about added descriptors. */
if (!headcount) {
if (unlikely(vhost_enable_notify(&net->dev, vq))) {
@@ -800,6 +790,16 @@ static void handle_rx(struct vhost_net *net)
* they refilled. */
goto out;
}
+ if (nvq->rx_array)
+ msg.msg_control = vhost_net_buf_consume(&nvq->rxq);
+ /* On overrun, truncate and discard */
+ if (unlikely(headcount > UIO_MAXIOV)) {
+ iov_iter_init(&msg.msg_iter, READ, vq->iov, 1, 1);
+ err = sock->ops->recvmsg(sock, &msg,
+1, MSG_DONTWAIT | MSG_TRUNC);
+ pr_debug("Discarded rx packet: len %zd\n", sock_len);
+ continue;
+ }
/* We don't need to be notified again. */
iov_iter_init(&msg.msg_iter, READ, vq->iov, in, vhost_len);
fixup = msg.msg_iter;
I suggest to reorder this patch to 3/3.
Thanks
Re: [PATCH 3/3] tap: free skb if flags error
On 2017年12月01日 13:54, w...@redhat.com wrote:
From: Wei Xu
tap_recvmsg() supports accepting skb by msg_control after
commit 3b4ba04acca8 ("tap: support receiving skb from msg_control"),
the skb if presented should be freed within the function, otherwise
it would be leaked.
Signed-off-by: Wei Xu
Reported-by: Matthew Rosato
---
drivers/net/tap.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/net/tap.c b/drivers/net/tap.c
index e9489b8..1c66b75 100644
--- a/drivers/net/tap.c
+++ b/drivers/net/tap.c
@@ -1154,9 +1154,13 @@ static int tap_recvmsg(struct socket *sock, struct
msghdr *m,
size_t total_len, int flags)
{
struct tap_queue *q = container_of(sock, struct tap_queue, sock);
+ struct sk_buff *skb = m->msg_control;
int ret;
- if (flags & ~(MSG_DONTWAIT|MSG_TRUNC))
+ if (flags & ~(MSG_DONTWAIT|MSG_TRUNC)) {
+ if (skb)
+ kfree_skb(skb);
return -EINVAL;
+ }
ret = tap_do_read(q, &m->msg_iter, flags & MSG_DONTWAIT,
m->msg_control);
Need to deal with iov_iterator_count() == 0.
Thanks
if (ret > total_len) {
Re: [PATCH 2/3] tun: free skb in early errors
On 2017年12月01日 13:54, w...@redhat.com wrote:
From: Wei Xu
tun_recvmsg() supports accepting skb by msg_control after
commit ac77cfd4258f ("tun: support receiving skb through msg_control"),
the skb if presented should be freed within the function, otherwise it
would be leaked.
Signed-off-by: Wei Xu
Reported-by: Matthew Rosato
---
drivers/net/tun.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 6a7bde9..5563430 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -2067,14 +2067,17 @@ static int tun_recvmsg(struct socket *sock, struct
msghdr *m, size_t total_len,
{
struct tun_file *tfile = container_of(sock, struct tun_file, socket);
struct tun_struct *tun = tun_get(tfile);
+ struct sk_buff *skb = m->msg_control;
int ret;
- if (!tun)
- return -EBADFD;
+ if (!tun) {
+ ret = -EBADFD;
+ goto out_free_skb;
Unfortunately, you can't to there since tun is NULL.
+ }
if (flags & ~(MSG_DONTWAIT|MSG_TRUNC|MSG_ERRQUEUE)) {
ret = -EINVAL;
- goto out;
+ goto out_free_skb;
}
if (flags & MSG_ERRQUEUE) {
ret = sock_recv_errqueue(sock->sk, m, total_len,
@@ -2087,6 +2090,11 @@ static int tun_recvmsg(struct socket *sock, struct
msghdr *m, size_t total_len,
m->msg_flags |= MSG_TRUNC;
ret = flags & MSG_TRUNC ? ret : total_len;
}
+ goto out;
We usually don't use goto in the case of success, and you need deal with
the case skb != NULL but iov_iter_count(to) == 0 in tun_do_read().
Thanks
+
+out_free_skb:
+ if (skb)
+ kfree_skb(skb);
out:
tun_put(tun);
return ret;
[PATCH v2 1/2] drm/panel: support Innolux P097PFG panel
Support Innolux P097PFG 9.7" 1536x2048 TFT LCD panel,
it refactor Innolux P079ZCA panel driver, let it support
multi panel, and add support P097PFG panel in this driver.
Signed-off-by: Lin Huang
---
Changes in v2:
- change regulator property name to meet the panel datasheet
drivers/gpu/drm/panel/panel-innolux-p079zca.c | 178 --
1 file changed, 136 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-innolux-p079zca.c
b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
index 6ba9344..5d690b7 100644
--- a/drivers/gpu/drm/panel/panel-innolux-p079zca.c
+++ b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
@@ -20,12 +20,32 @@
#include
+struct panel_desc {
+ const struct drm_display_mode *modes;
+ unsigned int bpc;
+ struct {
+ unsigned int width;
+ unsigned int height;
+ } size;
+};
+
+struct panel_desc_dsi {
+ struct panel_desc desc;
+
+ unsigned long flags;
+ enum mipi_dsi_pixel_format format;
+ unsigned int lanes;
+};
+
struct innolux_panel {
struct drm_panel base;
struct mipi_dsi_device *link;
+ const struct panel_desc_dsi *dsi_desc;
struct backlight_device *backlight;
- struct regulator *supply;
+ struct regulator *vddi;
+ struct regulator *avdd;
+ struct regulator *avee;
struct gpio_desc *enable_gpio;
bool prepared;
@@ -78,9 +98,9 @@ static int innolux_panel_unprepare(struct drm_panel *panel)
/* T8: 80ms - 1000ms */
msleep(80);
- err = regulator_disable(innolux->supply);
- if (err < 0)
- return err;
+ regulator_disable(innolux->avee);
+ regulator_disable(innolux->avdd);
+ regulator_disable(innolux->vddi);
innolux->prepared = false;
@@ -97,10 +117,18 @@ static int innolux_panel_prepare(struct drm_panel *panel)
gpiod_set_value_cansleep(innolux->enable_gpio, 0);
- err = regulator_enable(innolux->supply);
+ err = regulator_enable(innolux->vddi);
if (err < 0)
return err;
+ err = regulator_enable(innolux->avdd);
+ if (err < 0)
+ goto disable_vddi;
+
+ err = regulator_enable(innolux->avee);
+ if (err < 0)
+ goto disable_avdd;
+
/* T2: 15ms - 1000ms */
usleep_range(15000, 16000);
@@ -134,12 +162,13 @@ static int innolux_panel_prepare(struct drm_panel *panel)
return 0;
poweroff:
- regulator_err = regulator_disable(innolux->supply);
- if (regulator_err)
- DRM_DEV_ERROR(panel->dev, "failed to disable regulator: %d\n",
- regulator_err);
-
gpiod_set_value_cansleep(innolux->enable_gpio, 0);
+ regulator_disable(innolux->avee);
+disable_avdd:
+ regulator_disable(innolux->avdd);
+disable_vddi:
+ regulator_disable(innolux->vddi);
+
return err;
}
@@ -164,7 +193,7 @@ static int innolux_panel_enable(struct drm_panel *panel)
return 0;
}
-static const struct drm_display_mode default_mode = {
+static const struct drm_display_mode innolux_p079zca_mode = {
.clock = 56900,
.hdisplay = 768,
.hsync_start = 768 + 40,
@@ -177,15 +206,59 @@ static const struct drm_display_mode default_mode = {
.vrefresh = 60,
};
+static const struct panel_desc_dsi innolux_p079zca_panel_desc = {
+ .desc = {
+ .modes = &innolux_p079zca_mode,
+ .bpc = 8,
+ .size = {
+ .width = 120,
+ .height = 160,
+ },
+ },
+ .flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_SYNC_PULSE |
+MIPI_DSI_MODE_LPM,
+ .format = MIPI_DSI_FMT_RGB888,
+ .lanes = 4,
+};
+
+static const struct drm_display_mode innolux_p097pfg_mode = {
+ .clock = 22,
+ .hdisplay = 1536,
+ .hsync_start = 1536 + 100,
+ .hsync_end = 1536 + 100 + 24,
+ .htotal = 1536 + 100 + 24 + 100,
+ .vdisplay = 2048,
+ .vsync_start = 2048 + 18,
+ .vsync_end = 2048 + 18 + 2,
+ .vtotal = 2048 + 18 + 2 + 18,
+ .vrefresh = 60,
+};
+
+static const struct panel_desc_dsi innolux_p097pfg_panel_desc = {
+ .desc = {
+ .modes = &innolux_p097pfg_mode,
+ .bpc = 8,
+ .size = {
+ .width = 147,
+ .height = 196,
+ },
+ },
+ .flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_SYNC_PULSE |
+MIPI_DSI_MODE_LPM,
+ .format = MIPI_DSI_FMT_RGB888,
+ .lanes = 8,
+};
+
static int innolux_panel_get_modes(struct drm_panel *panel)
{
struct drm_display_mode *mode;
+ struct innolux_panel *innolux = to_innolux_panel(panel);
+ const struct drm_display_mode *m = innolux->dsi_desc->desc.modes;
- mode = drm_mode_duplicate(panel->drm, &default_m
[PATCH v2 2/2] dt-bindings: Add INNOLUX P097PFG panel bindings
The Innolux P097PFG panel is 9.7" panel with 1536X2048 resolution, it reuse P079ZCA panel driver, so improve p079ZCA dt-binding to support P097PFG. Signed-off-by: Lin Huang --- .../devicetree/bindings/display/panel/innolux,p079zca.txt | 11 +-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/display/panel/innolux,p079zca.txt b/Documentation/devicetree/bindings/display/panel/innolux,p079zca.txt index d0f5516..8cadd8c 100644 --- a/Documentation/devicetree/bindings/display/panel/innolux,p079zca.txt +++ b/Documentation/devicetree/bindings/display/panel/innolux,p079zca.txt @@ -1,13 +1,18 @@ Innolux P079ZCA 7.85" 768x1024 TFT LCD panel +Innolux P097PFG 9.7" 1536x2048 TFT LCD panel Required properties: -- compatible: should be "innolux,p079zca" +- compatible: should be should be one of the following. +-"innolux,p079zca" for Innolux 7.9" P079ZCA 768*1024 panel +-"innolux,p097pfg" for Innolux 9.7" P097PFG 1536*2048 panel - reg: DSI virtual channel of the peripheral -- power-supply: phandle of the regulator that provides the supply voltage - enable-gpios: panel enable gpio Optional properties: - backlight: phandle of the backlight device attached to the panel +- power-supply: phandle of the regulator that provides the supply voltage +- avdd-supply: phandle of the regulator that provides positive voltage +- avee-supply: phandle of the regulator that provides negative voltage Example: @@ -16,6 +21,8 @@ Example: compatible = "innolux,p079zca"; reg = <0>; power-supply = <...>; + avdd-supply = <...>; + avee-supply = <...>; backlight = <&backlight>; enable-gpios = <&gpio1 13 GPIO_ACTIVE_HIGH>; }; -- 2.7.4
Re: [PATCH] bus: simple-pm-bus: convert bool SIMPLE_PM_BUS to tristate
On Thu, Nov 30, 2017 at 12:57:00PM +0100, Geert Uytterhoeven wrote: > From: Paul Gortmaker > > The Kconfig currently controlling compilation of this code is: > > config SIMPLE_PM_BUS > bool "Simple Power-Managed Bus Driver" > > ...meaning that it currently is not being built as a module by anyone. > > In removing the orphaned modular support in a previous patch set, > Geert indicated he'd rather see this code converted to tristate. > > I normally don't do that because it extends functionality that I > can't easily run time test or even know if the use case makes sense, > but since in this case the author has nominated it as such, we do > the conversion here. > > Note that doesn't change the lack of run time testing ; this change > is only tested for sucessful compile and modpost. > > [geert: Ethernet is probed successfully on sh73a0/kzm9g after > insmodding simple-pm-bus.ko] > > Cc: Kevin Hilman > Cc: Simon Horman > Cc: linux-arm-ker...@lists.infradead.org > Signed-off-by: Paul Gortmaker > Tested-by: Geert Uytterhoeven > Signed-off-by: Geert Uytterhoeven Acked-by: Simon Horman > --- > drivers/bus/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig > index dc7b3c7b7d42fd09..57e011d36a79fce3 100644 > --- a/drivers/bus/Kconfig > +++ b/drivers/bus/Kconfig > @@ -120,7 +120,7 @@ config QCOM_EBI2 > SRAM, ethernet adapters, FPGAs and LCD displays. > > config SIMPLE_PM_BUS > - bool "Simple Power-Managed Bus Driver" > + tristate "Simple Power-Managed Bus Driver" > depends on OF && PM > help > Driver for transparent busses that don't need a real driver, but > -- > 2.7.4 >
Re: [PATCH 1/4] MODSIGN: do not load mok when secure boot disabled
Hi James,
First, thank you for reviewing and comment!
On Thu, Nov 30, 2017 at 07:51:03AM -0800, James Bottomley wrote:
> On Wed, 2017-11-29 at 22:11 +0800, Lee, Chun-Yi wrote:
> > The mok can not be trusted when the secure boot is disabled. Which
> > means that the kernel embedded certificate is the only trusted key.
> >
> > Due to db/dbx are authenticated variables, they needs manufacturer's
> > KEK for update. So db/dbx are secure when secureboot disabled.
> >
> > Cc: David Howells
> > Cc: Josh Boyer
> > Signed-off-by: "Lee, Chun-Yi"
> > ---
> > certs/load_uefi.c | 26 +++---
> > 1 file changed, 15 insertions(+), 11 deletions(-)
> >
> > diff --git a/certs/load_uefi.c b/certs/load_uefi.c
> > index 3d88459..d6de4d0 100644
> > --- a/certs/load_uefi.c
> > +++ b/certs/load_uefi.c
> > @@ -164,17 +164,6 @@ static int __init load_uefi_certs(void)
> > }
> > }
> >
> > - mok = get_cert_list(L"MokListRT", &mok_var, &moksize);
> > - if (!mok) {
> > - pr_info("MODSIGN: Couldn't get UEFI MokListRT\n");
> > - } else {
> > - rc = parse_efi_signature_list("UEFI:MokListRT",
> > - mok, moksize,
> > get_handler_for_db);
> > - if (rc)
> > - pr_err("Couldn't parse MokListRT signatures:
> > %d\n", rc);
> > - kfree(mok);
> > - }
> > -
> > dbx = get_cert_list(L"dbx", &secure_var, &dbxsize);
> > if (!dbx) {
> > pr_info("MODSIGN: Couldn't get UEFI dbx list\n");
> > @@ -187,6 +176,21 @@ static int __init load_uefi_certs(void)
> > kfree(dbx);
> > }
> >
> > + /* the MOK can not be trusted when secure boot is disabled
> > */
> > + if (!efi_enabled(EFI_SECURE_BOOT))
> > + return 0;
> > +
> > + mok = get_cert_list(L"MokListRT", &mok_var, &moksize);
>
> This isn't really a criticism of your patch but the underlying: all of
> the *RT variables, like MokListRT are insecure runtime variables and
> can be tampered with. I can agree that I can't see a tamper attack
> between exit boot services and pulling this in to the key list, but I'd
> feel a lot happier if the values were obtained directly from the BS
> variable before exit boot services because that's means the path for
> getting the values is directly within the secure envelope and doesn't
> rely on passing via an insecure element.
>
The shim creates MokListRT as a Runtime-Volatile variable then copies
MokList to MokListRT at boot time. According to spec, the Runtime-Volatile
variable is read only after ExitBootService:
UEFI Sepc V2.7, P.281
...
Once ExitBootServices() is performed, only variables that have
EFI_VARIABLE_RUNTIME_ACCESS and EFI_VARIABLE_NON_VOLATILE set can be
set with SetVariable().
Variables that have runtime access but that are not nonvolatile
are read-only data variables once ExitBootServices() is performed.
...
On the other hand, the kernel code is signed and verified by shim. So
all codes in initial kernel path are secure.
But, your suggestion reminds me that the code in get_cert_list() must
checks MOK/MOKx's attribute to make sure they are Runtime-Volatile
variables. I will update this patch.
Thanks a lot!
Joey Lee
blk-mq + bfq IO hangs after writing partition table
Hi, I think I am triggering a blk-mq + bfq bug that I can reproduce 100% of the time by using gdisk (1.0.1-1 in Debian stretch) to write a partition table to a USB flash drive. After it is triggered, IO hangs forever to that device and the machine cannot be shut down cleanly. I have reproduced this on two very different amd64 machines and two different USB drives. I don't know if this affects other storage devices. This happens *only* with blk-mq + bfq, never with mq-deadline or kyber. I built df8ba95c572a187ed2aa7403e97a7a7f58c01f00 (2017-11-30) from Linus's tree with make-kpkg, without patches of any sort. My cmdline was: scsi_mod.use_blk_mq=y dm_mod.use_blk_mq=y apparmor=1 security=apparmor .config file: https://gist.githubusercontent.com/ivan/35935783e3153878ce650ab105c1695f/raw/b3de6c85eabd342118b5fecf2b4fab362bde7aa6/config To reproduce: boot with blk-mq plug in a USB stick without any data you want to keep echo bfq > /sys/block/sdX/queue/scheduler gdisk /dev/sdX delete some partitions or add some partitions "w" to write the partition table observe IO hang and call trace (below) in the journal after 2 minutes Note the log below does not show "bfq" because it was loaded earlier. If it does not reproduce, try another USB flash drive; if that does not reproduce, cat /dev/zero over it first. Best regards, Ivan Dec 01 05:12:17 kernel: usb 3-1: new high-speed USB device number 2 using xhci_hcd Dec 01 05:12:18 kernel: usb 3-1: New USB device found, idVendor=26bf, idProduct=201a Dec 01 05:12:18 kernel: usb 3-1: New USB device strings: Mfr=0, Product=3, SerialNumber=4 Dec 01 05:12:18 kernel: usb 3-1: Product: STORAGE DEVICE Dec 01 05:12:18 kernel: usb 3-1: SerialNumber: 44705421454402634814 Dec 01 05:12:18 mtp-probe[3289]: checking bus 3, device 2: "/sys/devices/pci:00/:00:1c.7/:26:00.0/usb3/3-1" Dec 01 05:12:18 mtp-probe[3289]: bus: 3, device: 2 was not an MTP device Dec 01 05:12:18 kernel: usb-storage 3-1:1.0: USB Mass Storage device detected Dec 01 05:12:18 kernel: scsi host6: usb-storage 3-1:1.0 Dec 01 05:12:18 kernel: usbcore: registered new interface driver usb-storage Dec 01 05:12:18 kernel: usbcore: registered new interface driver uas Dec 01 05:12:19 kernel: scsi 6:0:0:0: Direct-Access Specific STORAGE DEVICE 0009 PQ: 0 ANSI: 5 Dec 01 05:12:19 kernel: sd 6:0:0:0: Attached scsi generic sg2 type 0 Dec 01 05:12:19 kernel: sd 6:0:0:0: [sdc] 7864320 512-byte logical blocks: (4.03 GB/3.75 GiB) Dec 01 05:12:19 kernel: sd 6:0:0:0: [sdc] Attached SCSI removable disk Dec 01 05:12:19 kernel: sdc: Dec 01 05:12:24 kernel: sdc: Dec 01 05:12:35 kernel: sdc: sdc1 sdc2 Dec 01 05:12:36 kernel: sdc: sdc1 sdc2 Dec 01 05:12:40 kernel: io scheduler kyber registered Dec 01 05:12:41 kernel: sdc: sdc1 sdc2 Dec 01 05:12:52 kernel: sdc: sdc1 Dec 01 05:12:53 kernel: sdc: sdc1 Dec 01 05:12:59 kernel: sdc: sdc1 Dec 01 05:14:00 systemd-udevd[331]: seq 2520 '/devices/pci:00/:00:1c.7/:26:00.0/usb3/3-1/3-1:1.0/host6/target6:0:0/6:0:0:0/block/sdc' is taking a long time Dec 01 05:14:05 systemd[1]: Started Getty on tty3. Dec 01 05:14:09 login[3339]: pam_unix(login:session): session opened for user root by LOGIN(uid=0) Dec 01 05:14:09 systemd[1]: Created slice User Slice of root. Dec 01 05:14:09 systemd[1]: Starting User Manager for UID 0... Dec 01 05:14:09 systemd[3344]: pam_unix(systemd-user:session): session opened for user root by (uid=0) Dec 01 05:14:09 systemd-logind[545]: New session 3 of user root. Dec 01 05:14:09 systemd[1]: Started Session 3 of user root. Dec 01 05:14:09 systemd[3344]: Reached target Paths. Dec 01 05:14:09 systemd[3344]: Starting D-Bus User Message Bus Socket. Dec 01 05:14:09 systemd[3344]: Listening on GnuPG cryptographic agent and passphrase cache (restricted). Dec 01 05:14:09 systemd[3344]: Listening on GnuPG cryptographic agent and passphrase cache. Dec 01 05:14:09 systemd[3344]: Listening on GnuPG cryptographic agent (access for web browsers). Dec 01 05:14:09 systemd[3344]: Listening on GnuPG cryptographic agent (ssh-agent emulation). Dec 01 05:14:09 systemd[3344]: Reached target Timers. Dec 01 05:14:09 systemd[3344]: Listening on D-Bus User Message Bus Socket. Dec 01 05:14:09 systemd[3344]: Reached target Sockets. Dec 01 05:14:09 systemd[3344]: Reached target Basic System. Dec 01 05:14:09 systemd[3344]: Reached target Default. Dec 01 05:14:09 systemd[3344]: Startup finished in 13ms. Dec 01 05:14:09 systemd[1]: Started User Manager for UID 0. Dec 01 05:14:09 login[3350]: ROOT LOGIN on '/dev/tty3' Dec 01 05:15:23 kernel: INFO: task kworker/2:1:34 blocked for more than 120 seconds. Dec 01 05:15:23 kernel: Not tainted 4.15.0-rc1+ #2 Dec 01 05:15:23 kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Dec 01 05:15:23 kernel: kworker/2:1 D034 2 0x8000 Dec 01 05:15:23 kernel: Workqueue: events_freezable_power_ disk_events_workfn Dec 01 05:15:23 kernel: Call Trace: Dec 01 05:15:23 kernel: ?
Re: [PATCH v3 4/5] drm/rockchip: Add ROCKCHIP DW MIPI DSI controller driver
Hi Matthias, On 2017年11月29日 04:48, Matthias Kaehlcke wrote: El Tue, Nov 28, 2017 at 07:20:05PM +0800 Nickey Yang ha dit: Add the ROCKCHIP DSI controller driver that uses the Synopsys DesignWare MIPI DSI host controller bridge. v2: add err_pllref, remove unnecessary encoder.enable & disable correct spelling mistakes v3: call dw_mipi_dsi_unbind() in dw_mipi_dsi_rockchip_unbind() fix typo, use of_device_get_match_data(), change some ‘bind()’ logic into 'probe()' add 'dev_set_drvdata()' Signed-off-by: Nickey Yang --- drivers/gpu/drm/rockchip/Kconfig|2 +- drivers/gpu/drm/rockchip/Makefile |2 +- drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 1349 --- drivers/gpu/drm/rockchip/dw-mipi-dsi_rockchip.c | 764 + drivers/gpu/drm/rockchip/rockchip_drm_drv.c |2 +- drivers/gpu/drm/rockchip/rockchip_drm_drv.h |2 +- 6 files changed, 768 insertions(+), 1353 deletions(-) delete mode 100644 drivers/gpu/drm/rockchip/dw-mipi-dsi.c create mode 100644 drivers/gpu/drm/rockchip/dw-mipi-dsi_rockchip.c diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig index 0ccc762..9eb4795 100644 --- a/drivers/gpu/drm/rockchip/Kconfig +++ b/drivers/gpu/drm/rockchip/Kconfig @@ -7,7 +7,7 @@ config DRM_ROCKCHIP select VIDEOMODE_HELPERS select DRM_ANALOGIX_DP if ROCKCHIP_ANALOGIX_DP select DRM_DW_HDMI if ROCKCHIP_DW_HDMI - select DRM_MIPI_DSI if ROCKCHIP_DW_MIPI_DSI + select DRM_DW_MIPI_DSI if ROCKCHIP_DW_MIPI_DSI select SND_SOC_HDMI_CODEC if ROCKCHIP_CDN_DP && SND_SOC help Choose this option if you have a Rockchip soc chipset. diff --git a/drivers/gpu/drm/rockchip/Makefile b/drivers/gpu/drm/rockchip/Makefile index a314e21..c05fe47 100644 --- a/drivers/gpu/drm/rockchip/Makefile +++ b/drivers/gpu/drm/rockchip/Makefile @@ -11,7 +11,7 @@ rockchipdrm-$(CONFIG_DRM_FBDEV_EMULATION) += rockchip_drm_fbdev.o rockchipdrm-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o rockchipdrm-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp-core.o cdn-dp-reg.o rockchipdrm-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o -rockchipdrm-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o +rockchipdrm-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi_rockchip.o rockchipdrm-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o rockchipdrm-$(CONFIG_ROCKCHIP_LVDS) += rockchip_lvds.o diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c deleted file mode 100644 index b15755b..000 --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c +++ /dev/null @@ -1,1349 +0,0 @@ -/* - * Copyright (c) 2016, Fuzhou Rockchip Electronics Co., Ltd - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License as published by - * the Free Software Foundation; either version 2 of the License, or - * (at your option) any later version. - */ -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include - -#include "rockchip_drm_drv.h" -#include "rockchip_drm_vop.h" - -#define DRIVER_NAME"dw-mipi-dsi" - -#define RK3288_GRF_SOC_CON60x025c -#define RK3288_DSI0_SEL_VOP_LITBIT(6) -#define RK3288_DSI1_SEL_VOP_LITBIT(9) - -#define RK3399_GRF_SOC_CON20 0x6250 -#define RK3399_DSI0_SEL_VOP_LITBIT(0) -#define RK3399_DSI1_SEL_VOP_LITBIT(4) - -/* disable turnrequest, turndisable, forcetxstopmode, forcerxmode */ -#define RK3399_GRF_SOC_CON22 0x6258 -#define RK3399_GRF_DSI_MODE0x - -#define DSI_VERSION0x00 -#define DSI_PWR_UP 0x04 -#define RESET 0 -#define POWERUPBIT(0) - -#define DSI_CLKMGR_CFG 0x08 -#define TO_CLK_DIVIDSION(div) (((div) & 0xff) << 8) -#define TX_ESC_CLK_DIVIDSION(div) (((div) & 0xff) << 0) - -#define DSI_DPI_VCID 0x0c -#define DPI_VID(vid) (((vid) & 0x3) << 0) - -#define DSI_DPI_COLOR_CODING 0x10 -#define EN18_LOOSELY BIT(8) -#define DPI_COLOR_CODING_16BIT_1 0x0 -#define DPI_COLOR_CODING_16BIT_2 0x1 -#define DPI_COLOR_CODING_16BIT_3 0x2 -#define DPI_COLOR_CODING_18BIT_1 0x3 -#define DPI_COLOR_CODING_18BIT_2 0x4 -#define DPI_COLOR_CODING_24BIT 0x5 - -#define DSI_DPI_CFG_POL0x14 -#define COLORM_ACTIVE_LOW BIT(4) -#define SHUTD_ACTIVE_LOW BIT(3) -#define HSYNC_ACTIVE_LOW BIT(2) -#define VSYNC_ACTIVE_LOW BIT(1) -#define DATAEN_ACTIVE_LOW BIT(0) - -#define DSI_DPI_LP_CMD_TIM 0x18 -#define OUTVACT_LPCMD_TI
RE: [PATCH v3 7/9] KVM: x86: Implement Intel Processor Trace MSRs read/write
> > + case MSR_IA32_RTIT_ADDR0_A ... MSR_IA32_RTIT_ADDR3_B: {
> > + u32 eax, ebx, ecx, edx;
> > +
> > + cpuid_count(0x14, 1, &eax, &ebx, &ecx, &edx);
>
> Please cache the cpuid_count result, or do the cpuid_count after testing
> vmx_pt_supported() (which you can use instead of going through kvm_x86_ops).
Hi Paolo,
Thanks for your reply. I have cache EAX in "struct pt_desc" and will
initialize in vmx_vcpu_setup().
+struct pt_desc {
+ unsigned int addr_num;
+ struct pt_ctx host;
+ struct pt_ctx guest;
+};
But kvm_init_msr_list() is invoked too early, I have to read from hardware.
So, what about change like this.
- cpuid_count(0x14, 1, &eax, &ebx, &ecx, &edx);
- if (!kvm_x86_ops->pt_supported() || msrs_to_save[i] -
- MSR_IA32_RTIT_ADDR0_A >= (eax & 0x7))
+ if (!kvm_x86_ops->pt_supported())
continue;
+ cpuid_count(0x14, 1, &eax, &ebx, &ecx, &edx);
+ if (msrs_to_save[i] -
+ MSR_IA32_RTIT_ADDR0_A >= (eax & 0x7))
+ continue;
Thanks,
Luwei Kang
>
> Thanks,
>
> Paolo
>
> > + if (!kvm_x86_ops->pt_supported() || msrs_to_save[i] -
> > + MSR_IA32_RTIT_ADDR0_A >= (eax & 0x7))
> > + continue;
> > + break;
[PATCH 1/4] arm: dts: imx28: Use phandles instead of unit addresses
From: Ravi Eluri
Unit addresses for all peripherals of imx28 are defined in
the corresponding dtsi file, use phandles instead of unit addresses
to reference peripheral nodes in dts files. This makes the DT more
robust and readable.
Signed-off-by: Ravi Eluri
Signed-off-by: Suniel Mahesh
---
Note:
- This is the first patch of the four patch series.
- Patch was compile tested and built(ARCH=arm, imx28) on linux-next
(latest).
- No build issues reported.
- Please discard this changeset, if this is not making any better.
---
arch/arm/boot/dts/imx28-evk.dts | 44 -
1 file changed, 22 insertions(+), 22 deletions(-)
diff --git a/arch/arm/boot/dts/imx28-evk.dts b/arch/arm/boot/dts/imx28-evk.dts
index 7f5b804..21ac4fa 100644
--- a/arch/arm/boot/dts/imx28-evk.dts
+++ b/arch/arm/boot/dts/imx28-evk.dts
@@ -22,14 +22,14 @@
apb@8000 {
apbh@8000 {
- gpmi-nand@8000c000 {
+ &gpmi {
pinctrl-names = "default";
pinctrl-0 = <&gpmi_pins_a &gpmi_status_cfg
&gpmi_pins_evk>;
status = "okay";
};
- ssp0: ssp@8001 {
+ &ssp0 {
compatible = "fsl,imx28-mmc";
pinctrl-names = "default";
pinctrl-0 = <&mmc0_8bit_pins_a
@@ -40,13 +40,13 @@
status = "okay";
};
- ssp1: ssp@80012000 {
+ &ssp1 {
compatible = "fsl,imx28-mmc";
bus-width = <8>;
wp-gpios = <&gpio0 28 0>;
};
- ssp2: ssp@80014000 {
+ &ssp2 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,imx28-spi";
@@ -63,7 +63,7 @@
};
};
- pinctrl@80018000 {
+ &pinctrl {
pinctrl-names = "default";
pinctrl-0 = <&hog_pins_a>;
@@ -119,7 +119,7 @@
};
};
- lcdif@8003 {
+ &lcdif {
pinctrl-names = "default";
pinctrl-0 = <&lcdif_24bit_pins_a
&lcdif_pins_evk>;
@@ -152,14 +152,14 @@
};
};
- can0: can@80032000 {
+ &can0 {
pinctrl-names = "default";
pinctrl-0 = <&can0_pins_a>;
xceiver-supply = <®_can_3v3>;
status = "okay";
};
- can1: can@80034000 {
+ &can1 {
pinctrl-names = "default";
pinctrl-0 = <&can1_pins_a>;
xceiver-supply = <®_can_3v3>;
@@ -168,20 +168,20 @@
};
apbx@8004 {
- saif0: saif@80042000 {
+ &saif0 {
pinctrl-names = "default";
pinctrl-0 = <&saif0_pins_a>;
status = "okay";
};
- saif1: saif@80046000 {
+ &saif1 {
pinctrl-names = "default";
pinctrl-0 = <&saif1_pins_a>;
fsl,saif-master = <&saif0>;
status = "okay";
};
- lradc@8005 {
+ &lradc {
status = "okay";
fsl,lradc-touchscreen-wires = <4>;
fsl,ave-ctrl = <4>;
@@ -189,7 +189,7 @@
fsl,settling = <10>;
};
- i2c0: i2c@80058000 {
+ &i2c0 {
pinctrl-names = "default";
pinctrl-0 = <&i2c0_pins_a>;
status = "okay";
@@ -209,55 +209,55 @@
};
};
- pwm: pwm@80064000 {
+ &pwm {
pinctrl-names = "default";
pinctr
[PATCH 4/4] arm: dts: imx28: Device tree cleanup
From: Ravi Eluri
Cleaned up device tree.
Signed-off-by: Ravi Eluri
Signed-off-by: Suniel Mahesh
---
Note:
- This is the fourth patch of the four patch series.
- Patch was compile tested and built(ARCH=arm, imx28) on linux-next
(latest).
- No build issues reported.
- Please discard this changeset, if this is not making any better.
---
arch/arm/boot/dts/imx28-evk.dts | 448
1 file changed, 224 insertions(+), 224 deletions(-)
diff --git a/arch/arm/boot/dts/imx28-evk.dts b/arch/arm/boot/dts/imx28-evk.dts
index 9d74486..eb683264 100644
--- a/arch/arm/boot/dts/imx28-evk.dts
+++ b/arch/arm/boot/dts/imx28-evk.dts
@@ -121,249 +121,249 @@
};
};
- &gpmi {
- pinctrl-names = "default";
- pinctrl-0 = <&gpmi_pins_a &gpmi_status_cfg
-&gpmi_pins_evk>;
- status = "okay";
- };
+&gpmi {
+ pinctrl-names = "default";
+ pinctrl-0 = <&gpmi_pins_a &gpmi_status_cfg
+&gpmi_pins_evk>;
+ status = "okay";
+};
- &ssp0 {
- compatible = "fsl,imx28-mmc";
- pinctrl-names = "default";
- pinctrl-0 = <&mmc0_8bit_pins_a
- &mmc0_cd_cfg &mmc0_sck_cfg>;
- bus-width = <8>;
- wp-gpios = <&gpio2 12 0>;
- vmmc-supply = <®_vddio_sd0>;
- status = "okay";
- };
+&ssp0 {
+ compatible = "fsl,imx28-mmc";
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc0_8bit_pins_a
+&mmc0_cd_cfg &mmc0_sck_cfg>;
+ bus-width = <8>;
+ wp-gpios = <&gpio2 12 0>;
+ vmmc-supply = <®_vddio_sd0>;
+ status = "okay";
+};
- &ssp1 {
- compatible = "fsl,imx28-mmc";
- bus-width = <8>;
- wp-gpios = <&gpio0 28 0>;
- };
+&ssp1 {
+ compatible = "fsl,imx28-mmc";
+ bus-width = <8>;
+ wp-gpios = <&gpio0 28 0>;
+};
- &ssp2 {
- #address-cells = <1>;
- #size-cells = <0>;
- compatible = "fsl,imx28-spi";
- pinctrl-names = "default";
- pinctrl-0 = <&spi2_pins_a>;
- status = "okay";
-
- flash: m25p80@0 {
- #address-cells = <1>;
- #size-cells = <1>;
- compatible = "sst,sst25vf016b",
"jedec,spi-nor";
- spi-max-frequency = <4000>;
- reg = <0>;
- };
- };
+&ssp2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,imx28-spi";
+ pinctrl-names = "default";
+ pinctrl-0 = <&spi2_pins_a>;
+ status = "okay";
- &pinctrl {
- pinctrl-names = "default";
- pinctrl-0 = <&hog_pins_a>;
-
- hog_pins_a: hog@0 {
- reg = <0>;
- fsl,pinmux-ids = <
- MX28_PAD_SSP1_CMD__GPIO_2_13
- MX28_PAD_SSP1_DATA3__GPIO_2_15
- MX28_PAD_ENET0_RX_CLK__GPIO_4_13
- MX28_PAD_SSP1_SCK__GPIO_2_12
- MX28_PAD_PWM3__GPIO_3_28
- MX28_PAD_LCD_RESET__GPIO_3_30
- MX28_PAD_AUART2_RX__GPIO_3_8
- MX28_PAD_AUART2_TX__GPIO_3_9
- >;
- fsl,drive-strength = ;
- fsl,voltage = ;
- fsl,pull-up = ;
- };
-
- led_pin_gpio3_5: led_gpio3_5@0 {
- reg = <0>;
- fsl,pinmux-ids = <
- MX28_PAD_AUART1_TX__GPIO_3_5
- >;
- fsl,drive-strength = ;
- fsl,voltage = ;
-
Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules
It was suggested that the feature would only be adopted in niches like Android and I pointed out that it's not really relevant to Android. It's a waste of time to try convincing me that it's useful elsewhere. I never said or implied that it wasn't. On Thu, 2017-11-30 at 09:50 +0100, Djalal Harouni wrote: > On Thu, Nov 30, 2017 at 7:51 AM, Daniel Micay > wrote: > [...] > > Lots of potential module attack surface also gets eliminated by > > default > > via their SELinux whitelists for /dev, /sys, /proc, debugfs, ioctl > > commands, etc. The global seccomp whitelist might be relevant in > > some > > cases too. > > In embedded systems we can't maintain a SELinux policy, distro man > power hardly manage. We have abstracted seccomp etc, but the kernel > inherited the difficult multiplex things, plus all other paths that > trigger this. It's cheaper to use an existing system like Android Things where device makers only need to make their apps and perhaps some userspace hardware drivers for cases not covered by mainline kernel drivers. I don't think it makes sense for every device vendor to manage an OS and I seriously doubt that's how the ecosystem is going to end up as it matures. > > Android devices like to build everything into the kernel too, so > > even if > > they weren't using a module this feature wouldn't usually help them. > > It > > would need to work like this existing sysctl: > > > > net.ipv4.tcp_available_congestion_control = cubic reno lp > > > > i.e. whitelists for functionality offered by the modules, not just > > whether they can be loaded. > > Yes, but it is hard to maintain a whitelist policy, the code is hardly > maintained... if you include everything you should have an LSM policy > or something like that, and compiling kernels is expert thing. I'm not talking about whitelist vs. blacklist, compiling kernels or anything like that. > Otherwise IMHO the kernel should provide default secure behaviour on > how to load or add new functionality to the running one. From a user > perspective, a switch "yes/no" that a privileged entity will > *understand* and assume is what should be there, and the switch or > flag as discussed here is local to processes, the sysctl will be > removed. IMO it should come from userspace point of view, cause as an > example the sysctl: > > net.ipv4.tcp_available_congestion_control = cubic reno lp > > Is kernel thing, too technical, userspace developers, admins or > privileged entity will not understand what cubic or reno mean. Congestion control algorithms are being used as an example in terms of the mechanism being used to control which are available to unprivileged users. The obscurity of congestion control algorithms is irrelevant. > Doing > the same per functionality directly like this seems to much of a > burden compared to the use case. The kernel maybe can do this to > advance the art of the networking stack and for advanced cases, but in > IMHO a sane default behaviour + an abstracted process/sandbox flag > "yes/no" for most others, userspace developers and humans is what > should be provided and we need the kernel to help here. There are cases where unprivileged module auto-loading is relied upon like network protocols. Having configuration for which protocols can be used by unprivileged users is superior to limiting only which ones can be auto-loaded. That's why I bought up the existing congestion control knob. It works well in terms of having a whitelist of the sane, widely used cases with exposing anything obscure requiring configuration. They happen to be implemented as modules too. Killing off unprivileged module loading other than a few cases like that makes sense, and then those can provide similar control with similarly sane defaults.
[PATCH 3/4] arm: dts: imx28: Rearrange nodes for better readability
From: Ravi Eluri
Moved regulator, sound, leds, backlight nodes to the top of the
device tree, cleaned up for better readability.
Signed-off-by: Ravi Eluri
Signed-off-by: Suniel Mahesh
---
Note:
- This is the third patch of the four patch series.
- Patch was compile tested and built(ARCH=arm, imx28) on linux-next
(latest).
- No build issues reported.
- Please discard this changeset, if this is not making any better.
---
arch/arm/boot/dts/imx28-evk.dts | 203
1 file changed, 101 insertions(+), 102 deletions(-)
diff --git a/arch/arm/boot/dts/imx28-evk.dts b/arch/arm/boot/dts/imx28-evk.dts
index 28564864..9d74486 100644
--- a/arch/arm/boot/dts/imx28-evk.dts
+++ b/arch/arm/boot/dts/imx28-evk.dts
@@ -20,6 +20,107 @@
reg = <0x4000 0x0800>;
};
+ regulators {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ reg_3p3v: regulator@0 {
+ compatible = "regulator-fixed";
+ reg = <0>;
+ regulator-name = "3P3V";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-always-on;
+ };
+
+ reg_vddio_sd0: regulator@1 {
+ compatible = "regulator-fixed";
+ reg = <1>;
+ regulator-name = "vddio-sd0";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ gpio = <&gpio3 28 0>;
+ };
+
+ reg_fec_3v3: regulator@2 {
+ compatible = "regulator-fixed";
+ reg = <2>;
+ regulator-name = "fec-3v3";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ gpio = <&gpio2 15 0>;
+ };
+
+ reg_usb0_vbus: regulator@3 {
+ compatible = "regulator-fixed";
+ reg = <3>;
+ regulator-name = "usb0_vbus";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ gpio = <&gpio3 9 0>;
+ enable-active-high;
+ };
+
+ reg_usb1_vbus: regulator@4 {
+ compatible = "regulator-fixed";
+ reg = <4>;
+ regulator-name = "usb1_vbus";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ gpio = <&gpio3 8 0>;
+ enable-active-high;
+ };
+
+ reg_lcd_3v3: regulator@5 {
+ compatible = "regulator-fixed";
+ reg = <5>;
+ regulator-name = "lcd-3v3";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ gpio = <&gpio3 30 0>;
+ enable-active-high;
+ };
+
+ reg_can_3v3: regulator@6 {
+ compatible = "regulator-fixed";
+ reg = <6>;
+ regulator-name = "can-3v3";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ gpio = <&gpio2 13 0>;
+ enable-active-high;
+ };
+ };
+
+ sound {
+ compatible = "fsl,imx28-evk-sgtl5000",
+"fsl,mxs-audio-sgtl5000";
+ model = "imx28-evk-sgtl5000";
+ saif-controllers = <&saif0 &saif1>;
+ audio-codec = <&sgtl5000>;
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&led_pin_gpio3_5>;
+
+ user {
+ label = "Heartbeat";
+ gpios = <&gpio3 5 0>;
+ linux,default-trigger = "heartbeat";
+ };
+ };
+
+ backlight {
+ compatible = "pwm-backlight";
+ pwms = <&pwm 2 500>;
+ brightness-levels = <0 4 8 16 32 64 128 255>;
+ default-brightness-level = <6>;
+ };
+};
+
&gpmi {
pinctrl-names = "default";
pinctrl-0 = <&gpmi_pins_a &gpmi_status_cfg
@@ -266,105 +367,3 @@
pinctrl-0 = <&mac1_pins_a>;
status = "okay";
};
-
- regulators {
- compa
[PATCH 2/4] arm: dts: imx28: Remove system bus unit addresses
From: Ravi Eluri
Unit addresses for the system buses of imx28 are defined in
the corresponding dtsi file. Any peripheral node on APBH, APBX
and AHB busses can be accessed via phandle. Removed duplicate
system bus unit address entries, this makes the DT more robust
and readable.
Signed-off-by: Ravi Eluri
Signed-off-by: Suniel Mahesh
---
Note:
- This is the second patch of the four patch series.
- Patch was compile tested and built(ARCH=arm, imx28) on linux-next
(latest).
- No build issues reported.
- Please discard this changeset, if this is not making any better.
---
arch/arm/boot/dts/imx28-evk.dts | 8
1 file changed, 8 deletions(-)
diff --git a/arch/arm/boot/dts/imx28-evk.dts b/arch/arm/boot/dts/imx28-evk.dts
index 21ac4fa..28564864 100644
--- a/arch/arm/boot/dts/imx28-evk.dts
+++ b/arch/arm/boot/dts/imx28-evk.dts
@@ -20,8 +20,6 @@
reg = <0x4000 0x0800>;
};
- apb@8000 {
- apbh@8000 {
&gpmi {
pinctrl-names = "default";
pinctrl-0 = <&gpmi_pins_a &gpmi_status_cfg
@@ -165,9 +163,7 @@
xceiver-supply = <®_can_3v3>;
status = "okay";
};
- };
- apbx@8004 {
&saif0 {
pinctrl-names = "default";
pinctrl-0 = <&saif0_pins_a>;
@@ -241,10 +237,7 @@
&usbphy1 {
status = "okay";
};
- };
- };
- ahb@8008 {
&usb0 {
pinctrl-names = "default";
pinctrl-0 = <&usb0_id_pins_a>;
@@ -273,7 +266,6 @@
pinctrl-0 = <&mac1_pins_a>;
status = "okay";
};
- };
regulators {
compatible = "simple-bus";
--
1.9.1
[PATCH 0/4] arm: dts: imx28: imx28-evk device tree cleanup
From: Ravi Eluri Removed lot of redundant device tree syntax from imx28-evk device tree to make it more robust and readable. Total four changesets and are described as follows: Changeset 1 removes unit addresses for all peripherals of imx28 in imx28-evk DT as they are already defined in the corresponding dtsi file. Make use of phandles reference peripheral nodes in dts files. Changeset 2 removes unit addresses for the system buses of imx28 as they are already defined in the corresponding dtsi file. Changeset 3 rearranges nodes for better readability. Changeset 4 does DT cleanup (whitespaces, tabs ...) Note: - Changesets were compile tested and built(ARCH=arm, imx28) on linux-next (latest). - No build issues reported. - Please discard this changesets, if this is not making any better." Ravi Eluri (4): arm: dts: imx28: Use phandles instead of unit addresses arm: dts: imx28: Remove system bus unit addresses arm: dts: imx28: Rearrange nodes for better readability arm: dts: imx28: Device tree cleanup arch/arm/boot/dts/imx28-evk.dts | 503 1 file changed, 247 insertions(+), 256 deletions(-) -- 1.9.1
[PATCH 1/6] x86/orc: Don't bail on stack overflow
If we overflow the stack into a guard page and then try to unwind it
with ORC, it should work well: by construction, there can't be any
meaningful data in the guard page because no writes to the guard page
will have succeeded.
This patch fixes a bug that unwinding from working correctly: if the
starting register state has RSP pointing into a stack guard page, the
ORC unwinder bails out immediately. This patch fixes that: the ORC
unwinder will start the unwind.
I tested this by intentionally overflowing the task stack. The
result is an accurate call trace instead of a trace consisting
purely of '?' entries.
There are a few other bugs that are triggered if the unwinder
encounters a stack overflow after the first step, and Josh has WIP
patches to fix those as well.
Signed-off-by: Andy Lutomirski
---
arch/x86/kernel/unwind_orc.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/unwind_orc.c b/arch/x86/kernel/unwind_orc.c
index a3f973b2c97a..ff8e1132b2ae 100644
--- a/arch/x86/kernel/unwind_orc.c
+++ b/arch/x86/kernel/unwind_orc.c
@@ -553,8 +553,18 @@ void __unwind_start(struct unwind_state *state, struct
task_struct *task,
}
if (get_stack_info((unsigned long *)state->sp, state->task,
- &state->stack_info, &state->stack_mask))
- return;
+ &state->stack_info, &state->stack_mask)) {
+ /*
+* We weren't on a valid stack. It's possible that
+* we overflowed a valid stack into a guard page.
+* See if the next page up is valid so that we can
+* generate some kind of backtrace if this happens.
+*/
+ void *next_page = (void *)PAGE_ALIGN((unsigned long)state->sp);
+ if (get_stack_info(next_page, state->task, &state->stack_info,
+ &state->stack_mask))
+ return;
+ }
/*
* The caller can provide the address of the first frame directly
--
2.13.6
[PATCH 3/6] Fixup "x86/asm: Remap the TSS into the cpu entry area"
Signed-off-by: Andy Lutomirski --- arch/x86/kvm/vmx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c index 2abe0073b573..62ee4362e1c1 100644 --- a/arch/x86/kvm/vmx.c +++ b/arch/x86/kvm/vmx.c @@ -2291,7 +2291,7 @@ static void vmx_vcpu_load(struct kvm_vcpu *vcpu, int cpu) * processors. See 22.2.4. */ vmcs_writel(HOST_TR_BASE, - (unsigned long)this_cpu_ptr(&cpu_tss.x86_tss)); + (unsigned long)&get_cpu_entry_area(cpu)->tss.x86_tss); vmcs_writel(HOST_GDTR_BASE, (unsigned long)gdt); /* 22.2.4 */ /* -- 2.13.6
[PATCH 5/6] Fixup "x86/entry/64: Move the IST stacks into cpu_entry_area"
I'm not entirely certain, but I suspect this caused the last kbuild
bot error. I wasn't able to reproduce it, but it seems plausble.
Add to the commit log:
The IST stacks are unlike the rest of cpu_entry_area: they're used
even for entries from kernel mode. This means that they should be set
up before we load the final IDT. Since the kernel sets up all
possible CPUs' percpu areas early in boot of the BP, move
cpu_entry_area setup to trap_init() and do it for all CPUs at once.
Signed-off-by: Andy Lutomirski
---
arch/x86/include/asm/fixmap.h | 2 ++
arch/x86/kernel/cpu/common.c | 26 +++---
arch/x86/kernel/traps.c | 6 ++
3 files changed, 27 insertions(+), 7 deletions(-)
diff --git a/arch/x86/include/asm/fixmap.h b/arch/x86/include/asm/fixmap.h
index 5a1013df456e..9a4caed665fd 100644
--- a/arch/x86/include/asm/fixmap.h
+++ b/arch/x86/include/asm/fixmap.h
@@ -242,5 +242,7 @@ static inline struct SYSENTER_stack *cpu_SYSENTER_stack(int
cpu)
return &get_cpu_entry_area((cpu))->tss.SYSENTER_stack;
}
+extern void setup_cpu_entry_areas(void);
+
#endif /* !__ASSEMBLY__ */
#endif /* _ASM_X86_FIXMAP_H */
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 1509f09abf5e..c0f11a684acf 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -490,7 +490,8 @@ void load_percpu_segment(int cpu)
load_stack_canary_segment();
}
-static void set_percpu_fixmap_pages(int fixmap_index, void *ptr, int pages,
pgprot_t prot)
+static void __init
+set_percpu_fixmap_pages(int fixmap_index, void *ptr, int pages, pgprot_t prot)
{
int i;
@@ -520,7 +521,7 @@ static DEFINE_PER_CPU_PAGE_ALIGNED(char, exception_stacks
#endif
/* Setup the fixmap mappings only once per-processor */
-static inline void setup_cpu_entry_area(int cpu)
+static void __init setup_cpu_entry_area(int cpu)
{
#ifdef CONFIG_X86_64
extern char _entry_trampoline[];
@@ -569,7 +570,7 @@ static inline void setup_cpu_entry_area(int cpu)
PAGE_KERNEL);
#ifdef CONFIG_X86_32
- this_cpu_write(cpu_entry_area, get_cpu_entry_area(cpu));
+ per_cpu(cpu_entry_area, cpu) = get_cpu_entry_area(cpu);
#endif
#ifdef CONFIG_X86_64
@@ -586,6 +587,21 @@ static inline void setup_cpu_entry_area(int cpu)
#endif
}
+void __init setup_cpu_entry_areas(void)
+{
+ int cpu;
+
+ /*
+* For better or for worse, the kernel allocates percpu space
+* for all possible CPUs early in BP startup. Map every CPU's
+* cpu_entry_area right off the bat so that they're available
+* before anything in AP boot could need them.
+*/
+ for_each_possible_cpu(cpu) {
+ setup_cpu_entry_area(cpu);
+ }
+}
+
/* Load the original GDT from the per-cpu structure */
void load_direct_gdt(int cpu)
{
@@ -1658,8 +1674,6 @@ void cpu_init(void)
initialize_tlbstate_and_flush();
enter_lazy_tlb(&init_mm, me);
- setup_cpu_entry_area(cpu);
-
/*
* Initialize the TSS. sp0 points to the entry trampoline stack
* regardless of what task is running.
@@ -1718,8 +1732,6 @@ void cpu_init(void)
initialize_tlbstate_and_flush();
enter_lazy_tlb(&init_mm, curr);
- setup_cpu_entry_area(cpu);
-
/*
* Initialize the TSS. Don't bother initializing sp0, as the initial
* task never enters user mode.
diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index 61e26b03afd8..b70aec60ebbd 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -946,6 +946,12 @@ dotraplinkage void do_iret_error(struct pt_regs *regs,
long error_code)
void __init trap_init(void)
{
+ /*
+* We need cpu_entry_area working before any IST-using entries could
+* happen.
+*/
+ setup_cpu_entry_areas();
+
idt_setup_traps();
/*
--
2.13.6
[PATCH 2/6] Fixup "x86/asm: Fix assumptions that the HW TSS is at the beginning of cpu_tss"
Signed-off-by: Andy Lutomirski --- arch/x86/kvm/vmx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c index a6f4f095f8f4..2abe0073b573 100644 --- a/arch/x86/kvm/vmx.c +++ b/arch/x86/kvm/vmx.c @@ -2291,7 +2291,7 @@ static void vmx_vcpu_load(struct kvm_vcpu *vcpu, int cpu) * processors. See 22.2.4. */ vmcs_writel(HOST_TR_BASE, - (unsigned long)this_cpu_ptr(&cpu_tss)); + (unsigned long)this_cpu_ptr(&cpu_tss.x86_tss)); vmcs_writel(HOST_GDTR_BASE, (unsigned long)gdt); /* 22.2.4 */ /* -- 2.13.6
[PATCH 4/6] Unsuck "x86/entry/64: Create a percpu SYSCALL entry trampoline"
This fixes a huge performance regression. Please add to the changelog: This patch actually seems to be a small speedup. With this patch, SYSCALL touches an extra cache line and an extra virtual page, but the pipeline no longer stalls waiting for SWAPGS. It seems that, at least in a tight loop, the latter outweights the former. Thanks to David Laight for an optimization tip. [end addition to changelog] Signed-off-by: Andy Lutomirski --- arch/x86/entry/entry_64.S | 16 +--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S index caf74a1bb3de..28f4e7553c26 100644 --- a/arch/x86/entry/entry_64.S +++ b/arch/x86/entry/entry_64.S @@ -180,14 +180,24 @@ ENTRY(entry_SYSCALL_64_trampoline) /* * x86 lacks a near absolute jump, and we can't jump to the real -* entry text with a relative jump, so we fake it using retq. +* entry text with a relative jump. We could push the target +* address and then use retq, but this destroys the pipeline on +* many CPUs (wasting over 20 cycles on Sandy Bridge). Instead, +* spill RDI and restore it in a second-stage trampoline. */ - pushq $entry_SYSCALL_64_after_hwframe - retq + pushq %rdi + movq$entry_SYSCALL_64_stage2, %rdi + jmp *%rdi END(entry_SYSCALL_64_trampoline) .popsection +ENTRY(entry_SYSCALL_64_stage2) + UNWIND_HINT_EMPTY + popq%rdi + jmp entry_SYSCALL_64_after_hwframe +END(entry_SYSCALL_64_stage2) + ENTRY(entry_SYSCALL_64) UNWIND_HINT_EMPTY /* -- 2.13.6
[PATCH 6/6] x86/entry/64: Make cpu_entry_area.tss read-only
The TSS is a fairly juicy target for exploits, and, now that the TSS
is in the cpu_entry_area, it's no longer protected by kASLR. Make it
read-only on x86_64.
On x86_32, it can't be RO because it's written by the CPU during task
switches, and we use a task gate for double faults. I'd also be
nervous about errata if we tried to make it RO even on configurations
without double fault handling.
Signed-off-by: Andy Lutomirski
---
arch/x86/entry/entry_32.S | 4 ++--
arch/x86/entry/entry_64.S | 8
arch/x86/include/asm/fixmap.h | 13 +
arch/x86/include/asm/processor.h | 17 -
arch/x86/include/asm/switch_to.h | 4 ++--
arch/x86/include/asm/thread_info.h | 2 +-
arch/x86/kernel/asm-offsets.c | 6 ++
arch/x86/kernel/asm-offsets_32.c | 4 ++--
arch/x86/kernel/cpu/common.c | 23 ---
arch/x86/kernel/ioport.c | 2 +-
arch/x86/kernel/process.c | 6 +++---
arch/x86/kernel/process_32.c | 2 +-
arch/x86/kernel/process_64.c | 2 +-
arch/x86/kernel/traps.c| 4 ++--
arch/x86/lib/delay.c | 4 ++--
arch/x86/xen/enlighten_pv.c| 2 +-
16 files changed, 57 insertions(+), 46 deletions(-)
diff --git a/arch/x86/entry/entry_32.S b/arch/x86/entry/entry_32.S
index 3629bcbf85a2..bd8b57a5c874 100644
--- a/arch/x86/entry/entry_32.S
+++ b/arch/x86/entry/entry_32.S
@@ -942,7 +942,7 @@ ENTRY(debug)
/* Are we currently on the SYSENTER stack? */
movlPER_CPU_VAR(cpu_entry_area), %ecx
- addl$CPU_ENTRY_AREA_tss + TSS_STRUCT_SYSENTER_stack +
SIZEOF_SYSENTER_stack, %ecx
+ addl$CPU_ENTRY_AREA_SYSENTER_stack + SIZEOF_SYSENTER_stack, %ecx
subl%eax, %ecx /* ecx = (end of SYSENTER_stack) - esp */
cmpl$SIZEOF_SYSENTER_stack, %ecx
jb .Ldebug_from_sysenter_stack
@@ -986,7 +986,7 @@ ENTRY(nmi)
/* Are we currently on the SYSENTER stack? */
movlPER_CPU_VAR(cpu_entry_area), %ecx
- addl$CPU_ENTRY_AREA_tss + TSS_STRUCT_SYSENTER_stack +
SIZEOF_SYSENTER_stack, %ecx
+ addl$CPU_ENTRY_AREA_SYSENTER_stack + SIZEOF_SYSENTER_stack, %ecx
subl%eax, %ecx /* ecx = (end of SYSENTER_stack) - esp */
cmpl$SIZEOF_SYSENTER_stack, %ecx
jb .Lnmi_from_sysenter_stack
diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index 28f4e7553c26..0b0735030328 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -158,7 +158,7 @@ END(native_usergs_sysret64)
_entry_trampoline - CPU_ENTRY_AREA_entry_trampoline(%rip)
/* The top word of the SYSENTER stack is hot and is usable as scratch space. */
-#define RSP_SCRATCHCPU_ENTRY_AREA_tss + TSS_STRUCT_SYSENTER_stack + \
+#define RSP_SCRATCHCPU_ENTRY_AREA_SYSENTER_stack + \
SIZEOF_SYSENTER_stack - 8 + CPU_ENTRY_AREA
ENTRY(entry_SYSCALL_64_trampoline)
@@ -394,7 +394,7 @@ syscall_return_via_sysret:
* Save old stack pointer and switch to trampoline stack.
*/
movq%rsp, %rdi
- movqPER_CPU_VAR(cpu_tss + TSS_sp0), %rsp
+ movqPER_CPU_VAR(cpu_tss_rw + TSS_sp0), %rsp
pushq RSP-RDI(%rdi) /* RSP */
pushq (%rdi) /* RDI */
@@ -722,7 +722,7 @@ GLOBAL(swapgs_restore_regs_and_return_to_usermode)
* Save old stack pointer and switch to trampoline stack.
*/
movq%rsp, %rdi
- movqPER_CPU_VAR(cpu_tss + TSS_sp0), %rsp
+ movqPER_CPU_VAR(cpu_tss_rw + TSS_sp0), %rsp
/* Copy the IRET frame to the trampoline stack. */
pushq 6*8(%rdi) /* SS */
@@ -937,7 +937,7 @@ apicinterrupt IRQ_WORK_VECTOR
irq_work_interrupt smp_irq_work_interrupt
/*
* Exception entry points.
*/
-#define CPU_TSS_IST(x) PER_CPU_VAR(cpu_tss) + (TSS_ist + ((x) - 1) * 8)
+#define CPU_TSS_IST(x) PER_CPU_VAR(cpu_tss_rw) + (TSS_ist + ((x) - 1) * 8)
/*
* Switch to the thread stack. This is called with the IRET frame and
diff --git a/arch/x86/include/asm/fixmap.h b/arch/x86/include/asm/fixmap.h
index 9a4caed665fd..3c291d0ebfcd 100644
--- a/arch/x86/include/asm/fixmap.h
+++ b/arch/x86/include/asm/fixmap.h
@@ -56,9 +56,14 @@ struct cpu_entry_area {
char gdt[PAGE_SIZE];
/*
-* The GDT is just below cpu_tss and thus serves (on x86_64) as a
-* a read-only guard page for the SYSENTER stack at the bottom
-* of the TSS region.
+* The GDT is just below SYSENTER_stack and thus serves (on x86_64) as
+* a a read-only guard page.
+*/
+ struct SYSENTER_stack_page SYSENTER_stack_page;
+
+ /*
+* On x86_64, the TSS is mapped RO. On x86_32, it's mapped RW because
+* we need task switches to work, and task switches write to the TSS.
*/
struct tss_struct tss;
@@ -239,7 +244,7 @@ static inline struct cp
[PATCH 0/6] WIP.x86/mm fixes
This is a bit oddly formatted, since it's meant to by a set of changes to a tree, not a normal patch set. "x86/orc: Don't bail on stack overflow" is a fixed version of "x86/unwinder/orc: Don't bail on stack overflow". If you'd rather just manually patch it, change "regs->sp" to "state->sp". Bug noticed by Dan Carpenter. Patch 2 is a bugfix that prevents a potential KVM explosion. The original patch failed to update KVM. Thanks, KVM, for having a separate copy of everything related to CPU state. Patch 3 is another bugfix that prevents a potential KVM explosion once the rest of KAISER is patched in. (I haven't tested, but I imagine we'd blow up horribly on the first interrupt from user mode after a VM exit.) Patch 4 fixes a *huge* performance regression. Well, not as huge as KAISER, but still huge. It turns out that pushq; retq is very, very slow. Patch 5 fixes a potential bug. Thomas, I think you said you had a fix on top of this fix. If you want my help, let me know. Patch 6 is new. It makes the TSS remap RO on 64-bit kernels. Andy Lutomirski (6): x86/orc: Don't bail on stack overflow Fixup "x86/asm: Fix assumptions that the HW TSS is at the beginning of cpu_tss" Fixup "x86/asm: Remap the TSS into the cpu entry area" Unsuck "x86/entry/64: Create a percpu SYSCALL entry trampoline" Fixup "x86/entry/64: Move the IST stacks into cpu_entry_area" x86/entry/64: Make cpu_entry_area.tss read-only arch/x86/entry/entry_32.S | 4 ++-- arch/x86/entry/entry_64.S | 24 +-- arch/x86/include/asm/fixmap.h | 15 arch/x86/include/asm/processor.h | 17 +++-- arch/x86/include/asm/switch_to.h | 4 ++-- arch/x86/include/asm/thread_info.h | 2 +- arch/x86/kernel/asm-offsets.c | 6 ++--- arch/x86/kernel/asm-offsets_32.c | 4 ++-- arch/x86/kernel/cpu/common.c | 49 +++--- arch/x86/kernel/ioport.c | 2 +- arch/x86/kernel/process.c | 6 ++--- arch/x86/kernel/process_32.c | 2 +- arch/x86/kernel/process_64.c | 2 +- arch/x86/kernel/traps.c| 10 ++-- arch/x86/kernel/unwind_orc.c | 14 +-- arch/x86/kvm/vmx.c | 2 +- arch/x86/lib/delay.c | 4 ++-- arch/x86/xen/enlighten_pv.c| 2 +- 18 files changed, 110 insertions(+), 59 deletions(-) -- 2.13.6
Re: [PATCH net-next 3/3] xfrm: Add ESN support for IPSec HW offload
On Tue, Nov 28, 2017 at 11:49:30AM +0200, yoss...@mellanox.com wrote:
> From: Yossef Efraim
>
> This patch adds ESN support to IPsec device offload.
> Adding new xfrm device operation to synchronize device ESN.
>
> Signed-off-by: Yossef Efraim
> ---
> include/linux/netdevice.h | 1 +
> include/net/xfrm.h| 12
> net/xfrm/xfrm_device.c| 4 ++--
> net/xfrm/xfrm_replay.c| 2 ++
> 4 files changed, 17 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> index 7de7656..d4e9198 100644
> --- a/include/linux/netdevice.h
> +++ b/include/linux/netdevice.h
> @@ -825,6 +825,7 @@ struct xfrmdev_ops {
> void(*xdo_dev_state_free) (struct xfrm_state *x);
> bool(*xdo_dev_offload_ok) (struct sk_buff *skb,
> struct xfrm_state *x);
> + void(*xdo_dev_state_advance_esn) (struct xfrm_state *x);
We now have a documentation for the xfrm offloadin API in the
ipsec-next tree. Please document the new device operation
there and resubmit.
Thanks!
Re: [PATCH net-next 2/3] xfrm: Fix xfrm_dev_state_add to fail for unsupported HW SA option
On Tue, Nov 28, 2017 at 11:49:29AM +0200, yoss...@mellanox.com wrote: > From: Yossef Efraim > > xfrm_dev_state_add function returns success for unsupported HW SA options. > Resulting the calling function to create SW SA without corrlating HW SA. > Desipte IPSec device offloading option was chosen. > These not supported HW SA options are hard coded within xfrm_dev_state_add > function. > SW backward compatibility will break if we add any of these option as old > HW will fail with new SW. > > This patch changes the behaviour to return -EINVAL in case unsupported > option is chosen. > Notifying user application regarding failure and not breaking backward > compatibility for newly added HW SA options. > > Signed-off-by: Yossef Efraim Also applied to ipsec-next, thanks a lot!
Re: [PATCH net-next 1/3] xfrm: Fix xfrm_replay_overflow_offload_esn
On Tue, Nov 28, 2017 at 11:49:28AM +0200, yoss...@mellanox.com wrote:
> From: Yossef Efraim
>
> In case of wrap around, replay_esn->oseq_hi is not updated
> before it is tested for it's actual value, leading function
> to fail with overflow indication and packets being dropped.
>
> This patch updates replay_esn->oseq_hi in the right place.
>
> Fixes: d7dbefc45cf5 ("xfrm: Add xfrm_replay_overflow functions for
> offloading")
> Signed-off-by: Yossef Efraim
Applied to ipsec-next, thanks!
Re: [PATCH 0/4] pci-dra7xx: Fix legacy IRQ handling and errata handling
On Friday 01 December 2017 11:43 AM, Vignesh R wrote: > This series contains two fixes: > 1. Make workaround for errata i870 applicable in Host mode as > well(previously it was enabled only for EP mode) as per errata > documentation: http://www.ti.com/lit/er/sprz429k/sprz429k.pdf > 2. Fix problem with handling of legacy INTD interrupts. > > Tested on 66AK2G EVM and ICE boards > Oops, sorry, I meant tested on DRA74 EVM and AM572 GP EVM here. > > Vignesh R (4): > pci: dwc: pci-dra7xx: Enable errata i870 for both EP and RC mode > dt-bindings: PCI: dra7xx: Add bindings for unaligned access in host > mode > ARM: dts: dra7: Add DT property to allow unaligned mem access to PCIe > RC > PCI: dwc: pci-dra7xx: Fix legacy IRQ handling > > Documentation/devicetree/bindings/pci/ti-pci.txt | 5 + > arch/arm/boot/dts/dra7.dtsi | 2 ++ > drivers/pci/dwc/pci-dra7xx.c | 23 ++- > 3 files changed, 21 insertions(+), 9 deletions(-) > -- Regards Vignesh
[PATCH 1/4] pci: dwc: pci-dra7xx: Enable errata i870 for both EP and RC mode
Errata i870 is applicable in both EP and RC mode. Therefore rename
function dra7xx_pcie_ep_unaligned_memaccess(), that implements errata
workaround, to dra7xx_pcie_unaligned_memaccess() and call it from a
common place. So, that errata workaround is applied for both modes of
operation.
Reported-by: Chris Welch
Signed-off-by: Vignesh R
---
drivers/pci/dwc/pci-dra7xx.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/pci/dwc/pci-dra7xx.c b/drivers/pci/dwc/pci-dra7xx.c
index e77a4ceed74c..53f721d1cc40 100644
--- a/drivers/pci/dwc/pci-dra7xx.c
+++ b/drivers/pci/dwc/pci-dra7xx.c
@@ -546,7 +546,7 @@ static const struct of_device_id of_dra7xx_pcie_match[] = {
};
/*
- * dra7xx_pcie_ep_unaligned_memaccess: workaround for AM572x/AM571x Errata i870
+ * dra7xx_pcie_unaligned_memaccess: workaround for AM572x/AM571x Errata i870
* @dra7xx: the dra7xx device where the workaround should be applied
*
* Access to the PCIe slave port that are not 32-bit aligned will result
@@ -556,7 +556,7 @@ static const struct of_device_id of_dra7xx_pcie_match[] = {
*
* To avoid this issue set PCIE_SS1_AXI2OCP_LEGACY_MODE_ENABLE to 1.
*/
-static int dra7xx_pcie_ep_unaligned_memaccess(struct device *dev)
+static int dra7xx_pcie_unaligned_memaccess(struct device *dev)
{
int ret;
struct device_node *np = dev->of_node;
@@ -703,6 +703,10 @@ static int __init dra7xx_pcie_probe(struct platform_device
*pdev)
if (dra7xx->link_gen < 0 || dra7xx->link_gen > 2)
dra7xx->link_gen = 2;
+ ret = dra7xx_pcie_unaligned_memaccess(dev);
+ if (ret)
+ goto err_gpio;
+
switch (mode) {
case DW_PCIE_RC_TYPE:
dra7xx_pcie_writel(dra7xx, PCIECTRL_TI_CONF_DEVICE_TYPE,
@@ -715,10 +719,6 @@ static int __init dra7xx_pcie_probe(struct platform_device
*pdev)
dra7xx_pcie_writel(dra7xx, PCIECTRL_TI_CONF_DEVICE_TYPE,
DEVICE_TYPE_EP);
- ret = dra7xx_pcie_ep_unaligned_memaccess(dev);
- if (ret)
- goto err_gpio;
-
ret = dra7xx_add_pcie_ep(dra7xx, pdev);
if (ret < 0)
goto err_gpio;
--
2.15.0
Re: [PATCH V11 0/5] hash addresses printed with %p
On (11/30/17 19:26), Sergey Senozhatsky wrote: > On (11/30/17 10:23), David Laight wrote: > [..] > > > Maybe I'm being thick, but... if we're rendering these addresses > > > unusable by hashing them, why not just print something like > > > "" in their place? That loses the uniqueness thing but I > > > wonder how valuable that is in practice? > > > > My worry is that is you get a kernel 'oops' print with actual register > > values you have no easy way of tying an address or address+offset to > > the corresponding hash(address) printed elsewhere. > > print the existing hash:pointer mappings in panic()? [if we can do that] by this I meant "when oops_in_progress == 1 then print hash:pointer for %p, not just hash". -ss
[PATCH v2 01/27] drm/sun4i: Fix format mask in DE2 driver
Format mask is one bit too short. Fix it. Fixes: 9d75b8c0b999 (drm/sun4i: add support for Allwinner DE2 mixers) Signed-off-by: Jernej Skrabec --- drivers/gpu/drm/sun4i/sun8i_mixer.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.h b/drivers/gpu/drm/sun4i/sun8i_mixer.h index 4785ac090b8c..c142fbb8661e 100644 --- a/drivers/gpu/drm/sun4i/sun8i_mixer.h +++ b/drivers/gpu/drm/sun4i/sun8i_mixer.h @@ -80,7 +80,7 @@ #define SUN8I_MIXER_CHAN_UI_LAYER_ATTR_EN BIT(0) #define SUN8I_MIXER_CHAN_UI_LAYER_ATTR_ALPHA_MODE_MASK GENMASK(2, 1) -#define SUN8I_MIXER_CHAN_UI_LAYER_ATTR_FBFMT_MASK GENMASK(11, 8) +#define SUN8I_MIXER_CHAN_UI_LAYER_ATTR_FBFMT_MASK GENMASK(12, 8) #define SUN8I_MIXER_CHAN_UI_LAYER_ATTR_ALPHA_MASK GENMASK(31, 24) #define SUN8I_MIXER_CHAN_UI_LAYER_ATTR_ALPHA_MODE_DEF (1 << 1) #define SUN8I_MIXER_CHAN_UI_LAYER_ATTR_FBFMT_ARGB (0 << 8) -- 2.15.1
[PATCH v2 03/27] drm/sun4i: Remove setting alpha mode in DE2 driver
Current code sets alpha mode to global alpha mode and global alpha value to 0xff which is totaly opaque. That is not needed for two reasons: - only one plane is active and thus it can be blended only with background, which is black, - it will hinder proper blending when more than one plane is supported Default mode (0) considers pixel alpha value or 0xff if pixel has no alpha information. Global alpha value is ignored in this case. Because of that, just remove the code. Signed-off-by: Jernej Skrabec --- drivers/gpu/drm/sun4i/sun8i_mixer.c | 10 -- drivers/gpu/drm/sun4i/sun8i_mixer.h | 2 -- 2 files changed, 12 deletions(-) diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c b/drivers/gpu/drm/sun4i/sun8i_mixer.c index b9c48c60131f..d3dee6131209 100644 --- a/drivers/gpu/drm/sun4i/sun8i_mixer.c +++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c @@ -54,16 +54,6 @@ void sun8i_mixer_layer_enable(struct sun8i_mixer *mixer, regmap_update_bits(mixer->engine.regs, SUN8I_MIXER_CHAN_UI_LAYER_ATTR(chan, layer), SUN8I_MIXER_CHAN_UI_LAYER_ATTR_EN, val); - - /* Set the alpha configuration */ - regmap_update_bits(mixer->engine.regs, - SUN8I_MIXER_CHAN_UI_LAYER_ATTR(chan, layer), - SUN8I_MIXER_CHAN_UI_LAYER_ATTR_ALPHA_MODE_MASK, - SUN8I_MIXER_CHAN_UI_LAYER_ATTR_ALPHA_MODE_DEF); - regmap_update_bits(mixer->engine.regs, - SUN8I_MIXER_CHAN_UI_LAYER_ATTR(chan, layer), - SUN8I_MIXER_CHAN_UI_LAYER_ATTR_ALPHA_MASK, - SUN8I_MIXER_CHAN_UI_LAYER_ATTR_ALPHA_DEF); } static int sun8i_mixer_drm_format_to_layer(struct drm_plane *plane, diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.h b/drivers/gpu/drm/sun4i/sun8i_mixer.h index 82c3416fbf3a..a7fe013c1d4a 100644 --- a/drivers/gpu/drm/sun4i/sun8i_mixer.h +++ b/drivers/gpu/drm/sun4i/sun8i_mixer.h @@ -83,8 +83,6 @@ #define SUN8I_MIXER_CHAN_UI_LAYER_ATTR_FBFMT_MASK GENMASK(12, 8) #define SUN8I_MIXER_CHAN_UI_LAYER_ATTR_FBFMT_OFFSET8 #define SUN8I_MIXER_CHAN_UI_LAYER_ATTR_ALPHA_MASK GENMASK(31, 24) -#define SUN8I_MIXER_CHAN_UI_LAYER_ATTR_ALPHA_MODE_DEF (1 << 1) -#define SUN8I_MIXER_CHAN_UI_LAYER_ATTR_ALPHA_DEF (0xff << 24) #define SUN8I_MIXER_FBFMT_ARGB 0 #define SUN8I_MIXER_FBFMT_XRGB 4 -- 2.15.1
[PATCH 3/4] ARM: dts: dra7: Add DT property to allow unaligned mem access to PCIe RC
Add ti,syscon-unaligned-access property to PCIe RC nodes in order to
enable workaround for errata i870 in PCIe RC mode as well.
Signed-off-by: Vignesh R
---
arch/arm/boot/dts/dra7.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index ac9216293b7c..e4182f4cc36d 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -314,6 +314,7 @@
<0 0 0 2 &pcie1_intc 2>,
<0 0 0 3 &pcie1_intc 3>,
<0 0 0 4 &pcie1_intc 4>;
+ ti,syscon-unaligned-access = <&scm_conf1 0x14
2>;
status = "disabled";
pcie1_intc: interrupt-controller {
interrupt-controller;
@@ -367,6 +368,7 @@
<0 0 0 2 &pcie2_intc 2>,
<0 0 0 3 &pcie2_intc 3>,
<0 0 0 4 &pcie2_intc 4>;
+ ti,syscon-unaligned-access = <&scm_conf1 0x14
1>;
pcie2_intc: interrupt-controller {
interrupt-controller;
#address-cells = <0>;
--
2.15.0
[PATCH v2 00/27] Improve DE2 support
Current DE2 driver is very basic and uses a lot of magic constants since there is no documentation and knowledge about it was limited at the time. With studying BSP source code, deeper knowledge was gained which allows to improve mainline driver considerably. At the beginning of this series, some code refactoring is done as well as adding some checks (patches 1-15). Further patches add multi-plane support with HW scaling and all possible RGB formats (patches 16-21). At last, support for YUV formats is added (patches 22-26). At the end, I included patch which puts lowest plane before second lowest. This should help testing VI planes when mixer has configuration 1 VI plane and 1 or more UI planes (most SoCs except V3s). This code was developed on H3, but it should work on every SoC if correct configuration structure is provided. H3 code can be found here: https://github.com/jernejsk/linux-1/commits/de2_impr_for_next Best regards, Jernej Changes from v1: - Split two patches to multiple smaller ones and better explain why those changes are needed and added fixes tag where appropriate. - channel parameters represents HW better (layer id -> channel, overlay) - add kerneldoc to configuration structure - nicer code style in atomic_check functions - changed WARN() to DRM_WARN() in csc code - split common scaler file to separate ui and vi scaler files - move channel specific code out of mixer code to sun8i_ui_layer.c and sun8i_vi_layer.c - defined macros for min and max supported scaler factor for each type of scaler Jernej Skrabec (27): drm/sun4i: Fix format mask in DE2 driver drm/sun4i: Rename DE2 RGB format macros drm/sun4i: Remove setting alpha mode in DE2 driver drm/sun4i: Fix debug message in DE2 drm/sun4i: Remove setting default values in DE2 driver drm/sun4i: Explain color macro in DE2 driver drm/sun4i: Set blending mode for all channels (DE2) drm/sun4i: Rename some macros in DE2 driver drm/sun4i: Rework enabling plane in DE2 driver drm/sun4i: Start using layer id in DE2 driver drm/sun4i: Add constraints checking to DE2 driver drm/sun4i: Use values calculated by atomic check drm/sun4i: Move line width setting in DE2 drm/sun4i: Move channel size related code in DE2 drm/sun4i: Move interlace related code in DE2 drm/sun4i: Add multi plane support to DE2 driver drm/sun4i: Add support for all HW supported DE2 RGB formats drm/sun4i: Reorganize UI layer code in DE2 drm/sun4i: Add support for DE2 VI planes drm/sun4i: Add scaler configuration to DE2 mixers drm/sun4i: Add support for HW scaling to DE2 drm/sun4i: Add CCSC property to DE2 configuration drm/sun4i: Add DE2 CSC library drm/sun4i: Add DE2 definitions for YUV formats drm/sun4i: Expand DE2 scaler lib with YUV support drm/sun4i: Wire in DE2 YUV support [DO NOT MERGE]drm/sun4i: Change zpos of bottom VI plane drivers/gpu/drm/sun4i/Makefile | 4 +- drivers/gpu/drm/sun4i/sun8i_csc.c | 93 +++ drivers/gpu/drm/sun4i/sun8i_csc.h | 36 ++ drivers/gpu/drm/sun4i/sun8i_layer.c | 134 - drivers/gpu/drm/sun4i/sun8i_layer.h | 36 -- drivers/gpu/drm/sun4i/sun8i_mixer.c | 496 +--- drivers/gpu/drm/sun4i/sun8i_mixer.h | 123 ++-- drivers/gpu/drm/sun4i/sun8i_ui_layer.c | 351 drivers/gpu/drm/sun4i/sun8i_ui_layer.h | 63 +++ drivers/gpu/drm/sun4i/sun8i_ui_scaler.c | 172 ++ drivers/gpu/drm/sun4i/sun8i_ui_scaler.h | 49 ++ drivers/gpu/drm/sun4i/sun8i_vi_layer.c | 389 + drivers/gpu/drm/sun4i/sun8i_vi_layer.h | 51 ++ drivers/gpu/drm/sun4i/sun8i_vi_scaler.c | 971 drivers/gpu/drm/sun4i/sun8i_vi_scaler.h | 58 ++ 15 files changed, 2595 insertions(+), 431 deletions(-) create mode 100644 drivers/gpu/drm/sun4i/sun8i_csc.c create mode 100644 drivers/gpu/drm/sun4i/sun8i_csc.h delete mode 100644 drivers/gpu/drm/sun4i/sun8i_layer.c delete mode 100644 drivers/gpu/drm/sun4i/sun8i_layer.h create mode 100644 drivers/gpu/drm/sun4i/sun8i_ui_layer.c create mode 100644 drivers/gpu/drm/sun4i/sun8i_ui_layer.h create mode 100644 drivers/gpu/drm/sun4i/sun8i_ui_scaler.c create mode 100644 drivers/gpu/drm/sun4i/sun8i_ui_scaler.h create mode 100644 drivers/gpu/drm/sun4i/sun8i_vi_layer.c create mode 100644 drivers/gpu/drm/sun4i/sun8i_vi_layer.h create mode 100644 drivers/gpu/drm/sun4i/sun8i_vi_scaler.c create mode 100644 drivers/gpu/drm/sun4i/sun8i_vi_scaler.h -- 2.15.1
[PATCH v2 04/27] drm/sun4i: Fix debug message in DE2
Debug message would print "Enabling" even when disabling plane.
Fix it.
Fixes: 9d75b8c0b999 (drm/sun4i: add support for Allwinner DE2 mixers)
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/sun8i_mixer.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c
b/drivers/gpu/drm/sun4i/sun8i_mixer.c
index d3dee6131209..b947ee2e4fe4 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
@@ -44,7 +44,8 @@ void sun8i_mixer_layer_enable(struct sun8i_mixer *mixer,
/* Currently the first UI channel is used */
int chan = mixer->cfg->vi_num;
- DRM_DEBUG_DRIVER("Enabling layer %d in channel %d\n", layer, chan);
+ DRM_DEBUG_DRIVER("%sabling layer %d in channel %d\n",
+enable ? "En" : "Dis", layer, chan);
if (enable)
val = SUN8I_MIXER_CHAN_UI_LAYER_ATTR_EN;
--
2.15.1
[PATCH v2 07/27] drm/sun4i: Set blending mode for all channels (DE2)
BSP driver always sets blend mode for all channels, no matter if they are really used or not. Do the same here. The exact meaning of the value is not exactly known, but BSP driver mentions "SRC OVER" and by digging through code some more info can be found. Signed-off-by: Jernej Skrabec --- drivers/gpu/drm/sun4i/sun8i_mixer.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c b/drivers/gpu/drm/sun4i/sun8i_mixer.c index 5144e6d0ac56..23659ce1cf27 100644 --- a/drivers/gpu/drm/sun4i/sun8i_mixer.c +++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c @@ -239,6 +239,7 @@ static int sun8i_mixer_bind(struct device *dev, struct device *master, struct sun8i_mixer *mixer; struct resource *res; void __iomem *regs; + int plane_cnt; int i, ret; /* @@ -324,8 +325,6 @@ static int sun8i_mixer_bind(struct device *dev, struct device *master, /* Initialize blender */ regmap_write(mixer->engine.regs, SUN8I_MIXER_BLEND_FCOLOR_CTL, SUN8I_MIXER_BLEND_FCOLOR_CTL_DEF); - regmap_write(mixer->engine.regs, SUN8I_MIXER_BLEND_MODE(0), -SUN8I_MIXER_BLEND_MODE_DEF); regmap_write(mixer->engine.regs, SUN8I_MIXER_BLEND_ATTR_FCOLOR(0), @@ -337,6 +336,11 @@ static int sun8i_mixer_bind(struct device *dev, struct device *master, regmap_write(mixer->engine.regs, SUN8I_MIXER_BLEND_ROUTE, mixer->cfg->vi_num); + plane_cnt = mixer->cfg->vi_num + mixer->cfg->ui_num; + for (i = 0; i < plane_cnt; i++) + regmap_write(mixer->engine.regs, SUN8I_MIXER_BLEND_MODE(i), +SUN8I_MIXER_BLEND_MODE_DEF); + return 0; err_disable_bus_clk: -- 2.15.1
[PATCH 2/4] dt-bindings: PCI: dra7xx: Add bindings for unaligned access in host mode
Update device tree binding documentation of TI's dra7xx PCI controller for enabling unaligned mem access as applicable not just in EP mode but in host mode as well. Signed-off-by: Vignesh R --- Documentation/devicetree/bindings/pci/ti-pci.txt | 5 + 1 file changed, 5 insertions(+) diff --git a/Documentation/devicetree/bindings/pci/ti-pci.txt b/Documentation/devicetree/bindings/pci/ti-pci.txt index 7f7af3044016..452fe48c4fdd 100644 --- a/Documentation/devicetree/bindings/pci/ti-pci.txt +++ b/Documentation/devicetree/bindings/pci/ti-pci.txt @@ -26,6 +26,11 @@ HOST MODE ranges, interrupt-map-mask, interrupt-map : as specified in ../designware-pcie.txt + - ti,syscon-unaligned-access: phandle to the syscon DT node. The 1st argument + should contain the register offset within syscon + and the 2nd argument should contain the bit field + for setting the bit to enable unaligned + access. DEVICE MODE === -- 2.15.0
[PATCH 0/4] pci-dra7xx: Fix legacy IRQ handling and errata handling
This series contains two fixes: 1. Make workaround for errata i870 applicable in Host mode as well(previously it was enabled only for EP mode) as per errata documentation: http://www.ti.com/lit/er/sprz429k/sprz429k.pdf 2. Fix problem with handling of legacy INTD interrupts. Tested on 66AK2G EVM and ICE boards Vignesh R (4): pci: dwc: pci-dra7xx: Enable errata i870 for both EP and RC mode dt-bindings: PCI: dra7xx: Add bindings for unaligned access in host mode ARM: dts: dra7: Add DT property to allow unaligned mem access to PCIe RC PCI: dwc: pci-dra7xx: Fix legacy IRQ handling Documentation/devicetree/bindings/pci/ti-pci.txt | 5 + arch/arm/boot/dts/dra7.dtsi | 2 ++ drivers/pci/dwc/pci-dra7xx.c | 23 ++- 3 files changed, 21 insertions(+), 9 deletions(-) -- 2.15.0
[PATCH 4/4] PCI: dwc: pci-dra7xx: Fix legacy IRQ handling
Legacy INTD IRQ handling is broken on dra7xx due to fact that driver
uses hwirq in range of 1-4 for INTA, INTD whereas IRQ domain is of size
4 which is numbered 0-3. Therefore when INTD IRQ line is used with
pci-dra7xx driver following warning is seen:
WARNING: CPU: 0 PID: 1 at kernel/irq/irqdomain.c:342
irq_domain_associate+0x12c/0x1c4
error: hwirq 0x4 is too large for dummy
Fix this by using pci_irqd_intx_xlate() helper to translate the INTx 1-4
range into the 0-3 as done in other PCIe drivers.
Also, iterate over all the INTx bits and call their respective IRQ
handlers before clearing the status register.
Suggested-by: Bjorn Helgaas
Reported-by: Chris Welch
Signed-off-by: Vignesh R
---
drivers/pci/dwc/pci-dra7xx.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/pci/dwc/pci-dra7xx.c b/drivers/pci/dwc/pci-dra7xx.c
index 53f721d1cc40..59e8de34cec6 100644
--- a/drivers/pci/dwc/pci-dra7xx.c
+++ b/drivers/pci/dwc/pci-dra7xx.c
@@ -226,6 +226,7 @@ static int dra7xx_pcie_intx_map(struct irq_domain *domain,
unsigned int irq,
static const struct irq_domain_ops intx_domain_ops = {
.map = dra7xx_pcie_intx_map,
+ .xlate = pci_irqd_intx_xlate,
};
static int dra7xx_pcie_init_irq_domain(struct pcie_port *pp)
@@ -256,7 +257,8 @@ static irqreturn_t dra7xx_pcie_msi_irq_handler(int irq,
void *arg)
struct dra7xx_pcie *dra7xx = arg;
struct dw_pcie *pci = dra7xx->pci;
struct pcie_port *pp = &pci->pp;
- u32 reg;
+ unsigned long reg;
+ u32 virq, bit;
reg = dra7xx_pcie_readl(dra7xx, PCIECTRL_DRA7XX_CONF_IRQSTATUS_MSI);
@@ -268,8 +270,11 @@ static irqreturn_t dra7xx_pcie_msi_irq_handler(int irq,
void *arg)
case INTB:
case INTC:
case INTD:
- generic_handle_irq(irq_find_mapping(dra7xx->irq_domain,
- ffs(reg)));
+ for_each_set_bit(bit, ®, PCI_NUM_INTX) {
+ virq = irq_find_mapping(dra7xx->irq_domain, bit);
+ if (virq)
+ generic_handle_irq(virq);
+ }
break;
}
--
2.15.0
[PATCH v2 09/27] drm/sun4i: Rework enabling plane in DE2 driver
If we want to support multiple planes in the future, code which enables
pipe has to be moved to appropriate place and it must depend on channel
id instead of being hardcoded.
Side effect of that rework is definition of default Z position. For now,
put first channel at the bottom, second above it and so on.
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/sun8i_mixer.c | 28 +---
1 file changed, 17 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c
b/drivers/gpu/drm/sun4i/sun8i_mixer.c
index c7d4ccd605e0..015943c0ed5a 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
@@ -55,6 +55,15 @@ void sun8i_mixer_layer_enable(struct sun8i_mixer *mixer,
regmap_update_bits(mixer->engine.regs,
SUN8I_MIXER_CHAN_UI_LAYER_ATTR(chan, layer),
SUN8I_MIXER_CHAN_UI_LAYER_ATTR_EN, val);
+
+ if (enable)
+ val = SUN8I_MIXER_BLEND_PIPE_CTL_EN(chan);
+ else
+ val = 0;
+
+ regmap_update_bits(mixer->engine.regs,
+ SUN8I_MIXER_BLEND_PIPE_CTL,
+ SUN8I_MIXER_BLEND_PIPE_CTL_EN(chan), val);
}
static int sun8i_mixer_drm_format_to_layer(struct drm_plane *plane,
@@ -98,7 +107,7 @@ int sun8i_mixer_update_layer_coord(struct sun8i_mixer *mixer,
state->crtc_h));
DRM_DEBUG_DRIVER("Updating blender size\n");
regmap_write(mixer->engine.regs,
-SUN8I_MIXER_BLEND_ATTR_INSIZE(0),
+SUN8I_MIXER_BLEND_ATTR_INSIZE(chan),
SUN8I_MIXER_SIZE(state->crtc_w,
state->crtc_h));
regmap_write(mixer->engine.regs, SUN8I_MIXER_BLEND_OUTSIZE,
@@ -322,20 +331,17 @@ static int sun8i_mixer_bind(struct device *dev, struct
device *master,
regmap_write(mixer->engine.regs, SUN8I_MIXER_BLEND_BKCOLOR,
SUN8I_MIXER_BLEND_COLOR_BLACK);
- /* Initialize blender */
+ /*
+* Set fill color of bottom plane to black. Generally not needed
+* except when VI plane is at bottom (zpos = 0) and enabled.
+*/
regmap_write(mixer->engine.regs, SUN8I_MIXER_BLEND_PIPE_CTL,
-SUN8I_MIXER_BLEND_PIPE_CTL_EN(0) |
SUN8I_MIXER_BLEND_PIPE_CTL_FC_EN(0));
-
- regmap_write(mixer->engine.regs,
-SUN8I_MIXER_BLEND_ATTR_FCOLOR(0),
+ regmap_write(mixer->engine.regs, SUN8I_MIXER_BLEND_ATTR_FCOLOR(0),
SUN8I_MIXER_BLEND_COLOR_BLACK);
- /* Select the first UI channel */
- DRM_DEBUG_DRIVER("Selecting channel %d (first UI channel)\n",
-mixer->cfg->vi_num);
- regmap_write(mixer->engine.regs, SUN8I_MIXER_BLEND_ROUTE,
-mixer->cfg->vi_num);
+ /* Fixed zpos for now */
+ regmap_write(mixer->engine.regs, SUN8I_MIXER_BLEND_ROUTE, 0x43210);
plane_cnt = mixer->cfg->vi_num + mixer->cfg->ui_num;
for (i = 0; i < plane_cnt; i++)
--
2.15.1
[PATCH v2 05/27] drm/sun4i: Remove setting default values in DE2 driver
Premultiply and color key control registers are already set to zero by initialization code few lines above. Furthermore, it seems that colorkeying doesn't really work. It's not used in BSP driver and experiments with it all failed. Just remove the code. Signed-off-by: Jernej Skrabec --- drivers/gpu/drm/sun4i/sun8i_mixer.c | 4 drivers/gpu/drm/sun4i/sun8i_mixer.h | 2 -- 2 files changed, 6 deletions(-) diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c b/drivers/gpu/drm/sun4i/sun8i_mixer.c index b947ee2e4fe4..f4a7fa0ba7ad 100644 --- a/drivers/gpu/drm/sun4i/sun8i_mixer.c +++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c @@ -320,14 +320,10 @@ static int sun8i_mixer_bind(struct device *dev, struct device *master, /* Initialize blender */ regmap_write(mixer->engine.regs, SUN8I_MIXER_BLEND_FCOLOR_CTL, SUN8I_MIXER_BLEND_FCOLOR_CTL_DEF); - regmap_write(mixer->engine.regs, SUN8I_MIXER_BLEND_PREMULTIPLY, -SUN8I_MIXER_BLEND_PREMULTIPLY_DEF); regmap_write(mixer->engine.regs, SUN8I_MIXER_BLEND_BKCOLOR, SUN8I_MIXER_BLEND_BKCOLOR_DEF); regmap_write(mixer->engine.regs, SUN8I_MIXER_BLEND_MODE(0), SUN8I_MIXER_BLEND_MODE_DEF); - regmap_write(mixer->engine.regs, SUN8I_MIXER_BLEND_CK_CTL, -SUN8I_MIXER_BLEND_CK_CTL_DEF); regmap_write(mixer->engine.regs, SUN8I_MIXER_BLEND_ATTR_FCOLOR(0), diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.h b/drivers/gpu/drm/sun4i/sun8i_mixer.h index a7fe013c1d4a..db005a4bca43 100644 --- a/drivers/gpu/drm/sun4i/sun8i_mixer.h +++ b/drivers/gpu/drm/sun4i/sun8i_mixer.h @@ -48,10 +48,8 @@ /* The following numbers are some still unknown magic numbers */ #define SUN8I_MIXER_BLEND_ATTR_FCOLOR_DEF 0xff00 #define SUN8I_MIXER_BLEND_FCOLOR_CTL_DEF 0x0101 -#define SUN8I_MIXER_BLEND_PREMULTIPLY_DEF 0x0 #define SUN8I_MIXER_BLEND_BKCOLOR_DEF 0xff00 #define SUN8I_MIXER_BLEND_MODE_DEF 0x03010301 -#define SUN8I_MIXER_BLEND_CK_CTL_DEF 0x0 #define SUN8I_MIXER_BLEND_OUTCTL_INTERLACEDBIT(1) -- 2.15.1
[PATCH v2 16/27] drm/sun4i: Add multi plane support to DE2 driver
Support for multiple UI planes can now be easily enabled just by adding
more planes with different index.
For now, add immutable zpos property.
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/sun8i_layer.c | 38 +
1 file changed, 17 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_layer.c
b/drivers/gpu/drm/sun4i/sun8i_layer.c
index 1eced63f365d..65d6eb7d5cbf 100644
--- a/drivers/gpu/drm/sun4i/sun8i_layer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_layer.c
@@ -22,12 +22,6 @@
#include "sun8i_layer.h"
#include "sun8i_mixer.h"
-struct sun8i_plane_desc {
- enum drm_plane_type type;
- const uint32_t *formats;
- uint32_tnformats;
-};
-
static int sun8i_mixer_layer_atomic_check(struct drm_plane *plane,
struct drm_plane_state *state)
{
@@ -106,35 +100,38 @@ static const uint32_t sun8i_mixer_layer_formats[] = {
DRM_FORMAT_XRGB,
};
-static const struct sun8i_plane_desc sun8i_mixer_planes[] = {
- {
- .type = DRM_PLANE_TYPE_PRIMARY,
- .formats = sun8i_mixer_layer_formats,
- .nformats = ARRAY_SIZE(sun8i_mixer_layer_formats),
- },
-};
-
static struct sun8i_layer *sun8i_layer_init_one(struct drm_device *drm,
struct sun8i_mixer *mixer,
- const struct sun8i_plane_desc
*plane)
+ int index)
{
struct sun8i_layer *layer;
+ enum drm_plane_type type;
int ret;
layer = devm_kzalloc(drm->dev, sizeof(*layer), GFP_KERNEL);
if (!layer)
return ERR_PTR(-ENOMEM);
+ type = index == 0 ? DRM_PLANE_TYPE_PRIMARY : DRM_PLANE_TYPE_OVERLAY;
+
/* possible crtcs are set later */
ret = drm_universal_plane_init(drm, &layer->plane, 0,
&sun8i_mixer_layer_funcs,
- plane->formats, plane->nformats,
- NULL, plane->type, NULL);
+ sun8i_mixer_layer_formats,
+ ARRAY_SIZE(sun8i_mixer_layer_formats),
+ NULL, type, NULL);
if (ret) {
dev_err(drm->dev, "Couldn't initialize layer\n");
return ERR_PTR(ret);
}
+ /* fixed zpos for now */
+ ret = drm_plane_create_zpos_immutable_property(&layer->plane, index);
+ if (ret) {
+ dev_err(drm->dev, "Couldn't add zpos property\n");
+ return ERR_PTR(ret);
+ }
+
drm_plane_helper_add(&layer->plane,
&sun8i_mixer_layer_helper_funcs);
layer->mixer = mixer;
@@ -149,16 +146,15 @@ struct drm_plane **sun8i_layers_init(struct drm_device
*drm,
struct sun8i_mixer *mixer = engine_to_sun8i_mixer(engine);
int i;
- planes = devm_kcalloc(drm->dev, ARRAY_SIZE(sun8i_mixer_planes) + 1,
+ planes = devm_kcalloc(drm->dev, mixer->cfg->ui_num + 1,
sizeof(*planes), GFP_KERNEL);
if (!planes)
return ERR_PTR(-ENOMEM);
- for (i = 0; i < ARRAY_SIZE(sun8i_mixer_planes); i++) {
- const struct sun8i_plane_desc *plane = &sun8i_mixer_planes[i];
+ for (i = 0; i < mixer->cfg->ui_num; i++) {
struct sun8i_layer *layer;
- layer = sun8i_layer_init_one(drm, mixer, plane);
+ layer = sun8i_layer_init_one(drm, mixer, i);
if (IS_ERR(layer)) {
dev_err(drm->dev, "Couldn't initialize %s plane\n",
i ? "overlay" : "primary");
--
2.15.1
[PATCH v2 11/27] drm/sun4i: Add constraints checking to DE2 driver
Since current DE2 driver doesn't know how to scale yet, add atomic check
function which checks that.
Nice side effect of that function is that populates clipped coordinates
and checks visibility of the plane. That data will be used in the
future.
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/sun8i_layer.c | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun8i_layer.c
b/drivers/gpu/drm/sun4i/sun8i_layer.c
index 5aa6e2c9728e..40e6b83aef3b 100644
--- a/drivers/gpu/drm/sun4i/sun8i_layer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_layer.c
@@ -13,7 +13,9 @@
* the License, or (at your option) any later version.
*/
+#include
#include
+#include
#include
#include
@@ -26,6 +28,31 @@ struct sun8i_plane_desc {
uint32_tnformats;
};
+static int sun8i_mixer_layer_atomic_check(struct drm_plane *plane,
+ struct drm_plane_state *state)
+{
+ struct drm_crtc *crtc = state->crtc;
+ struct drm_crtc_state *crtc_state;
+ struct drm_rect clip;
+
+ if (!crtc)
+ return 0;
+
+ crtc_state = drm_atomic_get_existing_crtc_state(state->state, crtc);
+ if (WARN_ON(!crtc_state))
+ return -EINVAL;
+
+ clip.x1 = 0;
+ clip.y1 = 0;
+ clip.x2 = crtc_state->adjusted_mode.hdisplay;
+ clip.y2 = crtc_state->adjusted_mode.vdisplay;
+
+ return drm_plane_helper_check_state(state, &clip,
+ DRM_PLANE_HELPER_NO_SCALING,
+ DRM_PLANE_HELPER_NO_SCALING,
+ true, true);
+}
+
static void sun8i_mixer_layer_atomic_disable(struct drm_plane *plane,
struct drm_plane_state
*old_state)
{
@@ -53,6 +80,7 @@ static void sun8i_mixer_layer_atomic_update(struct drm_plane
*plane,
}
static struct drm_plane_helper_funcs sun8i_mixer_layer_helper_funcs = {
+ .atomic_check = sun8i_mixer_layer_atomic_check,
.atomic_disable = sun8i_mixer_layer_atomic_disable,
.atomic_update = sun8i_mixer_layer_atomic_update,
};
--
2.15.1
[PATCH v2 13/27] drm/sun4i: Move line width setting in DE2
Line width is a property of a framebuffer and it belongs to
sun8i_mixer_update_layer_buffer(). This will became even more obvious
when support for multi-plane formats will be added.
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/sun8i_mixer.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c
b/drivers/gpu/drm/sun4i/sun8i_mixer.c
index 37fcc5ed18c5..9635c30651d6 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
@@ -91,7 +91,6 @@ int sun8i_mixer_update_layer_coord(struct sun8i_mixer *mixer,
int channel,
int overlay, struct drm_plane *plane)
{
struct drm_plane_state *state = plane->state;
- struct drm_framebuffer *fb = state->fb;
u32 width, height, size;
DRM_DEBUG_DRIVER("Updating channel %d overlay %d\n", channel, overlay);
@@ -122,12 +121,6 @@ int sun8i_mixer_update_layer_coord(struct sun8i_mixer
*mixer, int channel,
size);
}
- /* Set the line width */
- DRM_DEBUG_DRIVER("Layer line width: %d bytes\n", fb->pitches[0]);
- regmap_write(mixer->engine.regs,
-SUN8I_MIXER_CHAN_UI_LAYER_PITCH(channel, overlay),
-fb->pitches[0]);
-
/* Set height and width */
DRM_DEBUG_DRIVER("Layer size W: %u H: %u\n", width, height);
regmap_write(mixer->engine.regs,
@@ -202,6 +195,12 @@ int sun8i_mixer_update_layer_buffer(struct sun8i_mixer
*mixer, int channel,
paddr += (state->src.x1 >> 16) * bpp;
paddr += (state->src.y1 >> 16) * fb->pitches[0];
+ /* Set the line width */
+ DRM_DEBUG_DRIVER("Layer line width: %d bytes\n", fb->pitches[0]);
+ regmap_write(mixer->engine.regs,
+SUN8I_MIXER_CHAN_UI_LAYER_PITCH(channel, overlay),
+fb->pitches[0]);
+
DRM_DEBUG_DRIVER("Setting buffer address to %pad\n", &paddr);
regmap_write(mixer->engine.regs,
--
2.15.1
[PATCH v2 15/27] drm/sun4i: Move interlace related code in DE2
There is no point having code which sets interlace mode of mixer in
channel related function. Interlace mode will only change when CRTC
state will change, so let's move it to the block which is executed only
when primary plane state is changed.
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/sun8i_mixer.c | 33 -
1 file changed, 20 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c
b/drivers/gpu/drm/sun4i/sun8i_mixer.c
index 00c0cc6440e2..f35a08dc260b 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
@@ -104,6 +104,9 @@ int sun8i_mixer_update_layer_coord(struct sun8i_mixer
*mixer, int channel,
size = SUN8I_MIXER_SIZE(width, height);
if (plane->type == DRM_PLANE_TYPE_PRIMARY) {
+ bool interlaced = false;
+ u32 val;
+
DRM_DEBUG_DRIVER("Primary layer, updating global size W: %u H:
%u\n",
width, height);
regmap_write(mixer->engine.regs,
@@ -111,6 +114,23 @@ int sun8i_mixer_update_layer_coord(struct sun8i_mixer
*mixer, int channel,
size);
regmap_write(mixer->engine.regs, SUN8I_MIXER_BLEND_OUTSIZE,
size);
+
+ if (state->crtc)
+ interlaced = state->crtc->state->adjusted_mode.flags
+ & DRM_MODE_FLAG_INTERLACE;
+
+ if (interlaced)
+ val = SUN8I_MIXER_BLEND_OUTCTL_INTERLACED;
+ else
+ val = 0;
+
+ regmap_update_bits(mixer->engine.regs,
+ SUN8I_MIXER_BLEND_OUTCTL,
+ SUN8I_MIXER_BLEND_OUTCTL_INTERLACED,
+ val);
+
+ DRM_DEBUG_DRIVER("Switching display mixer interlaced mode %s\n",
+interlaced ? "on" : "off");
}
/* Set height and width */
@@ -140,22 +160,9 @@ int sun8i_mixer_update_layer_formats(struct sun8i_mixer
*mixer, int channel,
{
struct drm_plane_state *state = plane->state;
struct drm_framebuffer *fb = state->fb;
- bool interlaced = false;
u32 val;
int ret;
- if (plane->state->crtc)
- interlaced = plane->state->crtc->state->adjusted_mode.flags
- & DRM_MODE_FLAG_INTERLACE;
-
- regmap_update_bits(mixer->engine.regs, SUN8I_MIXER_BLEND_OUTCTL,
- SUN8I_MIXER_BLEND_OUTCTL_INTERLACED,
- interlaced ?
- SUN8I_MIXER_BLEND_OUTCTL_INTERLACED : 0);
-
- DRM_DEBUG_DRIVER("Switching display mixer interlaced mode %s\n",
-interlaced ? "on" : "off");
-
ret = sun8i_mixer_drm_format_to_layer(plane, fb->format->format,
&val);
if (ret) {
--
2.15.1
[PATCH v2 17/27] drm/sun4i: Add support for all HW supported DE2 RGB formats
Currently only a few RGB formats are supported by the DE2 driver. Add
support for all formats supported by the HW.
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/sun8i_layer.c | 19 -
drivers/gpu/drm/sun4i/sun8i_mixer.c | 134
drivers/gpu/drm/sun4i/sun8i_mixer.h | 17 +
3 files changed, 139 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_layer.c
b/drivers/gpu/drm/sun4i/sun8i_layer.c
index 65d6eb7d5cbf..cdeda083c60e 100644
--- a/drivers/gpu/drm/sun4i/sun8i_layer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_layer.c
@@ -95,8 +95,25 @@ static const struct drm_plane_funcs sun8i_mixer_layer_funcs
= {
};
static const uint32_t sun8i_mixer_layer_formats[] = {
- DRM_FORMAT_RGB888,
+ DRM_FORMAT_ABGR1555,
+ DRM_FORMAT_ABGR,
+ DRM_FORMAT_ABGR,
+ DRM_FORMAT_ARGB1555,
+ DRM_FORMAT_ARGB,
DRM_FORMAT_ARGB,
+ DRM_FORMAT_BGR565,
+ DRM_FORMAT_BGR888,
+ DRM_FORMAT_BGRA5551,
+ DRM_FORMAT_BGRA,
+ DRM_FORMAT_BGRA,
+ DRM_FORMAT_BGRX,
+ DRM_FORMAT_RGB565,
+ DRM_FORMAT_RGB888,
+ DRM_FORMAT_RGBA,
+ DRM_FORMAT_RGBA5551,
+ DRM_FORMAT_RGBA,
+ DRM_FORMAT_RGBX,
+ DRM_FORMAT_XBGR,
DRM_FORMAT_XRGB,
};
diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c
b/drivers/gpu/drm/sun4i/sun8i_mixer.c
index f35a08dc260b..d49eed97b452 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
@@ -29,6 +29,105 @@
#include "sun8i_layer.h"
#include "sunxi_engine.h"
+struct de2_fmt_info {
+ u32 drm_fmt;
+ u32 de2_fmt;
+};
+
+static const struct de2_fmt_info de2_formats[] = {
+ {
+ .drm_fmt = DRM_FORMAT_ARGB,
+ .de2_fmt = SUN8I_MIXER_FBFMT_ARGB,
+ },
+ {
+ .drm_fmt = DRM_FORMAT_ABGR,
+ .de2_fmt = SUN8I_MIXER_FBFMT_ABGR,
+ },
+ {
+ .drm_fmt = DRM_FORMAT_RGBA,
+ .de2_fmt = SUN8I_MIXER_FBFMT_RGBA,
+ },
+ {
+ .drm_fmt = DRM_FORMAT_BGRA,
+ .de2_fmt = SUN8I_MIXER_FBFMT_BGRA,
+ },
+ {
+ .drm_fmt = DRM_FORMAT_XRGB,
+ .de2_fmt = SUN8I_MIXER_FBFMT_XRGB,
+ },
+ {
+ .drm_fmt = DRM_FORMAT_XBGR,
+ .de2_fmt = SUN8I_MIXER_FBFMT_XBGR,
+ },
+ {
+ .drm_fmt = DRM_FORMAT_RGBX,
+ .de2_fmt = SUN8I_MIXER_FBFMT_RGBX,
+ },
+ {
+ .drm_fmt = DRM_FORMAT_BGRX,
+ .de2_fmt = SUN8I_MIXER_FBFMT_BGRX,
+ },
+ {
+ .drm_fmt = DRM_FORMAT_RGB888,
+ .de2_fmt = SUN8I_MIXER_FBFMT_RGB888,
+ },
+ {
+ .drm_fmt = DRM_FORMAT_BGR888,
+ .de2_fmt = SUN8I_MIXER_FBFMT_BGR888,
+ },
+ {
+ .drm_fmt = DRM_FORMAT_RGB565,
+ .de2_fmt = SUN8I_MIXER_FBFMT_RGB565,
+ },
+ {
+ .drm_fmt = DRM_FORMAT_BGR565,
+ .de2_fmt = SUN8I_MIXER_FBFMT_BGR565,
+ },
+ {
+ .drm_fmt = DRM_FORMAT_ARGB,
+ .de2_fmt = SUN8I_MIXER_FBFMT_ARGB,
+ },
+ {
+ .drm_fmt = DRM_FORMAT_ABGR,
+ .de2_fmt = SUN8I_MIXER_FBFMT_ABGR,
+ },
+ {
+ .drm_fmt = DRM_FORMAT_RGBA,
+ .de2_fmt = SUN8I_MIXER_FBFMT_RGBA,
+ },
+ {
+ .drm_fmt = DRM_FORMAT_BGRA,
+ .de2_fmt = SUN8I_MIXER_FBFMT_BGRA,
+ },
+ {
+ .drm_fmt = DRM_FORMAT_ARGB1555,
+ .de2_fmt = SUN8I_MIXER_FBFMT_ARGB1555,
+ },
+ {
+ .drm_fmt = DRM_FORMAT_ABGR1555,
+ .de2_fmt = SUN8I_MIXER_FBFMT_ABGR1555,
+ },
+ {
+ .drm_fmt = DRM_FORMAT_RGBA5551,
+ .de2_fmt = SUN8I_MIXER_FBFMT_RGBA5551,
+ },
+ {
+ .drm_fmt = DRM_FORMAT_BGRA5551,
+ .de2_fmt = SUN8I_MIXER_FBFMT_BGRA5551,
+ },
+};
+
+static const struct de2_fmt_info *sun8i_mixer_format_info(u32 format)
+{
+ unsigned int i;
+
+ for (i = 0; i < ARRAY_SIZE(de2_formats); ++i)
+ if (de2_formats[i].drm_fmt == format)
+ return &de2_formats[i];
+
+ return NULL;
+}
+
static void sun8i_mixer_commit(struct sunxi_engine *engine)
{
DRM_DEBUG_DRIVER("Committing changes\n");
@@ -64,29 +163,6 @@ void sun8i_mixer_layer_enable(struct sun8i_mixer *mixer,
int channel,
SUN8I_MIXER_BLEND_PIPE_CTL_EN(channel), val);
}
-static int sun8i_mixer_drm_format_to_layer(struct drm_plane *plane,
-u32 format, u32 *mode)
-{
- switch (format) {
- case DRM_FORMAT_ARGB:
-
[PATCH v2 21/27] drm/sun4i: Add support for HW scaling to DE2
Scaling is currently supported only for RGB framebuffers
Coefficients and algorithm which coefficients to select are taken
from BSP driver.
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/Makefile | 3 +-
drivers/gpu/drm/sun4i/sun8i_mixer.h | 4 -
drivers/gpu/drm/sun4i/sun8i_ui_layer.c | 73 +++--
drivers/gpu/drm/sun4i/sun8i_ui_scaler.c | 172 ++
drivers/gpu/drm/sun4i/sun8i_ui_scaler.h | 49 +++
drivers/gpu/drm/sun4i/sun8i_vi_layer.c | 62 +++-
drivers/gpu/drm/sun4i/sun8i_vi_scaler.c | 535
drivers/gpu/drm/sun4i/sun8i_vi_scaler.h | 56
8 files changed, 915 insertions(+), 39 deletions(-)
create mode 100644 drivers/gpu/drm/sun4i/sun8i_ui_scaler.c
create mode 100644 drivers/gpu/drm/sun4i/sun8i_ui_scaler.h
create mode 100644 drivers/gpu/drm/sun4i/sun8i_vi_scaler.c
create mode 100644 drivers/gpu/drm/sun4i/sun8i_vi_scaler.h
diff --git a/drivers/gpu/drm/sun4i/Makefile b/drivers/gpu/drm/sun4i/Makefile
index b0a2eb2c4806..a458ddbf4a8e 100644
--- a/drivers/gpu/drm/sun4i/Makefile
+++ b/drivers/gpu/drm/sun4i/Makefile
@@ -10,7 +10,8 @@ sun4i-drm-hdmi-y += sun4i_hdmi_i2c.o
sun4i-drm-hdmi-y += sun4i_hdmi_tmds_clk.o
sun8i-mixer-y += sun8i_mixer.o sun8i_ui_layer.o \
- sun8i_vi_layer.o
+ sun8i_vi_layer.o sun8i_ui_scaler.o \
+ sun8i_vi_scaler.o
sun4i-tcon-y += sun4i_crtc.o
sun4i-tcon-y += sun4i_dotclock.o
diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.h
b/drivers/gpu/drm/sun4i/sun8i_mixer.h
index a6270b307ae5..9bbd762d26f7 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.h
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.h
@@ -77,10 +77,6 @@
* These sub-engines are still unknown now, the EN registers are here only to
* be used to disable these sub-engines.
*/
-#define SUN8I_MIXER_VSU_EN 0x2
-#define SUN8I_MIXER_GSU1_EN0x3
-#define SUN8I_MIXER_GSU2_EN0x4
-#define SUN8I_MIXER_GSU3_EN0x5
#define SUN8I_MIXER_FCE_EN 0xa
#define SUN8I_MIXER_BWS_EN 0xa2000
#define SUN8I_MIXER_LTI_EN 0xa4000
diff --git a/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
b/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
index 3ecf39c50111..3cf0729cc7e9 100644
--- a/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
@@ -24,6 +24,7 @@
#include "sun8i_ui_layer.h"
#include "sun8i_mixer.h"
+#include "sun8i_ui_scaler.h"
static void sun8i_ui_layer_enable(struct sun8i_mixer *mixer, int channel,
int overlay, bool enable)
@@ -56,29 +57,35 @@ static int sun8i_ui_layer_update_coord(struct sun8i_mixer
*mixer, int channel,
int overlay, struct drm_plane *plane)
{
struct drm_plane_state *state = plane->state;
- u32 width, height, size;
+ u32 src_w, src_h, dst_w, dst_h;
+ u32 outsize, insize;
+ u32 hphase, vphase;
- DRM_DEBUG_DRIVER("Updating channel %d overlay %d\n", channel, overlay);
+ DRM_DEBUG_DRIVER("Updating UI channel %d overlay %d\n",
+channel, overlay);
- /*
-* Same source and destination width and height are guaranteed
-* by atomic check function.
-*/
- width = drm_rect_width(&state->dst);
- height = drm_rect_height(&state->dst);
- size = SUN8I_MIXER_SIZE(width, height);
+ src_w = drm_rect_width(&state->src) >> 16;
+ src_h = drm_rect_height(&state->src) >> 16;
+ dst_w = drm_rect_width(&state->dst);
+ dst_h = drm_rect_height(&state->dst);
+
+ hphase = state->src.x1 & 0x;
+ vphase = state->src.y1 & 0x;
+
+ insize = SUN8I_MIXER_SIZE(src_w, src_h);
+ outsize = SUN8I_MIXER_SIZE(dst_w, dst_h);
if (plane->type == DRM_PLANE_TYPE_PRIMARY) {
bool interlaced = false;
u32 val;
DRM_DEBUG_DRIVER("Primary layer, updating global size W: %u H:
%u\n",
-width, height);
+dst_w, dst_h);
regmap_write(mixer->engine.regs,
SUN8I_MIXER_GLOBAL_SIZE,
-size);
+outsize);
regmap_write(mixer->engine.regs, SUN8I_MIXER_BLEND_OUTSIZE,
-size);
+outsize);
if (state->crtc)
interlaced = state->crtc->state->adjusted_mode.flags
@@ -99,23 +106,42 @@ static int sun8i_ui_layer_update_coord(struct sun8i_mixer
*mixer, int channel,
}
/* Set height and width */
- DRM_DEBUG_DRIVER("Layer size W: %u H: %u\n", width, height);
+ DRM_DEBUG_DRIVER("Layer
[PATCH v2 19/27] drm/sun4i: Add support for DE2 VI planes
This commit adds basic support for VI planes. They are meant for video
overlay and because of that they support YUV formats too. However, using
YUV format is not straightforward, so only RGB formats are supported for
now.
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/Makefile | 3 +-
drivers/gpu/drm/sun4i/sun8i_mixer.c| 19 ++-
drivers/gpu/drm/sun4i/sun8i_vi_layer.c | 276 +
drivers/gpu/drm/sun4i/sun8i_vi_layer.h | 51 ++
4 files changed, 346 insertions(+), 3 deletions(-)
create mode 100644 drivers/gpu/drm/sun4i/sun8i_vi_layer.c
create mode 100644 drivers/gpu/drm/sun4i/sun8i_vi_layer.h
diff --git a/drivers/gpu/drm/sun4i/Makefile b/drivers/gpu/drm/sun4i/Makefile
index 0a839674cd1d..b0a2eb2c4806 100644
--- a/drivers/gpu/drm/sun4i/Makefile
+++ b/drivers/gpu/drm/sun4i/Makefile
@@ -9,7 +9,8 @@ sun4i-drm-hdmi-y+= sun4i_hdmi_enc.o
sun4i-drm-hdmi-y += sun4i_hdmi_i2c.o
sun4i-drm-hdmi-y += sun4i_hdmi_tmds_clk.o
-sun8i-mixer-y += sun8i_mixer.o sun8i_ui_layer.o
+sun8i-mixer-y += sun8i_mixer.o sun8i_ui_layer.o \
+ sun8i_vi_layer.o
sun4i-tcon-y += sun4i_crtc.o
sun4i-tcon-y += sun4i_dotclock.o
diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c
b/drivers/gpu/drm/sun4i/sun8i_mixer.c
index 1de98ad9f6c1..888620b1d3f1 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
@@ -27,6 +27,7 @@
#include "sun4i_drv.h"
#include "sun8i_mixer.h"
#include "sun8i_ui_layer.h"
+#include "sun8i_vi_layer.h"
#include "sunxi_engine.h"
static const struct de2_fmt_info de2_formats[] = {
@@ -138,11 +139,25 @@ static struct drm_plane **sun8i_layers_init(struct
drm_device *drm,
struct sun8i_mixer *mixer = engine_to_sun8i_mixer(engine);
int i;
- planes = devm_kcalloc(drm->dev, mixer->cfg->ui_num + 1,
+ planes = devm_kcalloc(drm->dev,
+ mixer->cfg->vi_num + mixer->cfg->ui_num + 1,
sizeof(*planes), GFP_KERNEL);
if (!planes)
return ERR_PTR(-ENOMEM);
+ for (i = 0; i < mixer->cfg->vi_num; i++) {
+ struct sun8i_vi_layer *layer;
+
+ layer = sun8i_vi_layer_init_one(drm, mixer, i);
+ if (IS_ERR(layer)) {
+ dev_err(drm->dev,
+ "Couldn't initialize overlay plane\n");
+ return ERR_CAST(layer);
+ };
+
+ planes[i] = &layer->plane;
+ };
+
for (i = 0; i < mixer->cfg->ui_num; i++) {
struct sun8i_ui_layer *layer;
@@ -153,7 +168,7 @@ static struct drm_plane **sun8i_layers_init(struct
drm_device *drm,
return ERR_CAST(layer);
};
- planes[i] = &layer->plane;
+ planes[mixer->cfg->vi_num + i] = &layer->plane;
};
return planes;
diff --git a/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
b/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
new file mode 100644
index ..b78d4f3e2b48
--- /dev/null
+++ b/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
@@ -0,0 +1,276 @@
+/*
+ * Copyright (C) Jernej Skrabec
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "sun8i_vi_layer.h"
+#include "sun8i_mixer.h"
+
+static void sun8i_vi_layer_enable(struct sun8i_mixer *mixer, int channel,
+ int overlay, bool enable)
+{
+ u32 val;
+
+ DRM_DEBUG_DRIVER("%sabling VI channel %d overlay %d\n",
+enable ? "En" : "Dis", channel, overlay);
+
+ if (enable)
+ val = SUN8I_MIXER_CHAN_VI_LAYER_ATTR_EN;
+ else
+ val = 0;
+
+ regmap_update_bits(mixer->engine.regs,
+ SUN8I_MIXER_CHAN_VI_LAYER_ATTR(channel, overlay),
+ SUN8I_MIXER_CHAN_VI_LAYER_ATTR_EN, val);
+
+ if (enable)
+ val = SUN8I_MIXER_BLEND_PIPE_CTL_EN(channel);
+ else
+ val = 0;
+
+ regmap_update_bits(mixer->engine.regs,
+ SUN8I_MIXER_BLEND_PIPE_CTL,
+ SUN8I_MIXER_BLEND_PIPE_CTL_EN(channel), val);
+}
+
+static int sun8i_vi_layer_update_coord(struct sun8i_mixer *mixer, int channel,
+ int overlay, struct drm_plane *plane)
+{
+ struct drm_plane_state *state = plane->state;
+ u32 width, height, size;
+
+ DRM_DEBUG_DRIVER("Updating VI channel %d overlay %d\n",
+channel, overlay);
+
[PATCH v2 24/27] drm/sun4i: Add DE2 definitions for YUV formats
This commit expands translation of DRM YUV format to HW specific
information.
It doesn't do any functional changes.
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/sun8i_mixer.c| 136 +
drivers/gpu/drm/sun4i/sun8i_mixer.h| 23 +-
drivers/gpu/drm/sun4i/sun8i_ui_layer.c | 2 +-
drivers/gpu/drm/sun4i/sun8i_vi_layer.c | 2 +-
4 files changed, 159 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c
b/drivers/gpu/drm/sun4i/sun8i_mixer.c
index 7f88cf5f97eb..29ceeb016d72 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
@@ -34,82 +34,218 @@ static const struct de2_fmt_info de2_formats[] = {
{
.drm_fmt = DRM_FORMAT_ARGB,
.de2_fmt = SUN8I_MIXER_FBFMT_ARGB,
+ .rgb = true,
+ .csc = SUN8I_CSC_MODE_OFF,
},
{
.drm_fmt = DRM_FORMAT_ABGR,
.de2_fmt = SUN8I_MIXER_FBFMT_ABGR,
+ .rgb = true,
+ .csc = SUN8I_CSC_MODE_OFF,
},
{
.drm_fmt = DRM_FORMAT_RGBA,
.de2_fmt = SUN8I_MIXER_FBFMT_RGBA,
+ .rgb = true,
+ .csc = SUN8I_CSC_MODE_OFF,
},
{
.drm_fmt = DRM_FORMAT_BGRA,
.de2_fmt = SUN8I_MIXER_FBFMT_BGRA,
+ .rgb = true,
+ .csc = SUN8I_CSC_MODE_OFF,
},
{
.drm_fmt = DRM_FORMAT_XRGB,
.de2_fmt = SUN8I_MIXER_FBFMT_XRGB,
+ .rgb = true,
+ .csc = SUN8I_CSC_MODE_OFF,
},
{
.drm_fmt = DRM_FORMAT_XBGR,
.de2_fmt = SUN8I_MIXER_FBFMT_XBGR,
+ .rgb = true,
+ .csc = SUN8I_CSC_MODE_OFF,
},
{
.drm_fmt = DRM_FORMAT_RGBX,
.de2_fmt = SUN8I_MIXER_FBFMT_RGBX,
+ .rgb = true,
+ .csc = SUN8I_CSC_MODE_OFF,
},
{
.drm_fmt = DRM_FORMAT_BGRX,
.de2_fmt = SUN8I_MIXER_FBFMT_BGRX,
+ .rgb = true,
+ .csc = SUN8I_CSC_MODE_OFF,
},
{
.drm_fmt = DRM_FORMAT_RGB888,
.de2_fmt = SUN8I_MIXER_FBFMT_RGB888,
+ .rgb = true,
+ .csc = SUN8I_CSC_MODE_OFF,
},
{
.drm_fmt = DRM_FORMAT_BGR888,
.de2_fmt = SUN8I_MIXER_FBFMT_BGR888,
+ .rgb = true,
+ .csc = SUN8I_CSC_MODE_OFF,
},
{
.drm_fmt = DRM_FORMAT_RGB565,
.de2_fmt = SUN8I_MIXER_FBFMT_RGB565,
+ .rgb = true,
+ .csc = SUN8I_CSC_MODE_OFF,
},
{
.drm_fmt = DRM_FORMAT_BGR565,
.de2_fmt = SUN8I_MIXER_FBFMT_BGR565,
+ .rgb = true,
+ .csc = SUN8I_CSC_MODE_OFF,
},
{
.drm_fmt = DRM_FORMAT_ARGB,
.de2_fmt = SUN8I_MIXER_FBFMT_ARGB,
+ .rgb = true,
+ .csc = SUN8I_CSC_MODE_OFF,
},
{
.drm_fmt = DRM_FORMAT_ABGR,
.de2_fmt = SUN8I_MIXER_FBFMT_ABGR,
+ .rgb = true,
+ .csc = SUN8I_CSC_MODE_OFF,
},
{
.drm_fmt = DRM_FORMAT_RGBA,
.de2_fmt = SUN8I_MIXER_FBFMT_RGBA,
+ .rgb = true,
+ .csc = SUN8I_CSC_MODE_OFF,
},
{
.drm_fmt = DRM_FORMAT_BGRA,
.de2_fmt = SUN8I_MIXER_FBFMT_BGRA,
+ .rgb = true,
+ .csc = SUN8I_CSC_MODE_OFF,
},
{
.drm_fmt = DRM_FORMAT_ARGB1555,
.de2_fmt = SUN8I_MIXER_FBFMT_ARGB1555,
+ .rgb = true,
+ .csc = SUN8I_CSC_MODE_OFF,
},
{
.drm_fmt = DRM_FORMAT_ABGR1555,
.de2_fmt = SUN8I_MIXER_FBFMT_ABGR1555,
+ .rgb = true,
+ .csc = SUN8I_CSC_MODE_OFF,
},
{
.drm_fmt = DRM_FORMAT_RGBA5551,
.de2_fmt = SUN8I_MIXER_FBFMT_RGBA5551,
+ .rgb = true,
+ .csc = SUN8I_CSC_MODE_OFF,
},
{
.drm_fmt = DRM_FORMAT_BGRA5551,
.de2_fmt = SUN8I_MIXER_FBFMT_BGRA5551,
+ .rgb = true,
+ .csc = SUN8I_CSC_MODE_OFF,
+ },
+ {
+ .drm_fmt = DRM_FORMAT_UYVY,
+ .de2_fmt = SUN8I_MIXER_FBFMT_UYVY,
+ .rgb = false,
+ .csc = SUN8I_CSC_MODE_YUV2RGB,
+ },
+ {
+ .drm_fmt = DRM_FORMAT_VYUY,
+ .de2_fmt = SUN8I_MIXER_FBFMT_VYUY,
+ .rgb = false,
+ .csc = SUN8I_CSC_MODE_YUV2RGB,
[PATCH v2 26/27] drm/sun4i: Wire in DE2 YUV support
Now that we have all required bits, add support for YUV formats.
DRM subsystem doesn't know YUV411 semi-planar format, so leave that out
for now.
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/sun8i_vi_layer.c | 127 ++---
1 file changed, 102 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
b/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
index 02aaa7d3fceb..0b4800fd7ba1 100644
--- a/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
@@ -55,6 +55,7 @@ static int sun8i_vi_layer_update_coord(struct sun8i_mixer
*mixer, int channel,
u32 src_w, src_h, dst_w, dst_h;
u32 outsize, insize;
u32 hphase, vphase;
+ bool subsampled;
DRM_DEBUG_DRIVER("Updating VI channel %d overlay %d\n",
channel, overlay);
@@ -67,12 +68,32 @@ static int sun8i_vi_layer_update_coord(struct sun8i_mixer
*mixer, int channel,
hphase = state->src.x1 & 0x;
vphase = state->src.y1 & 0x;
+ /* make coordinates dividable by subsampling factor */
+ if (format->hsub > 1) {
+ int mask, remainder;
+
+ mask = format->hsub - 1;
+ remainder = (state->src.x1 >> 16) & mask;
+ src_w = (src_w + remainder) & ~mask;
+ hphase += remainder << 16;
+ }
+
+ if (format->vsub > 1) {
+ int mask, remainder;
+
+ mask = format->vsub - 1;
+ remainder = (state->src.y1 >> 16) & mask;
+ src_h = (src_h + remainder) & ~mask;
+ vphase += remainder << 16;
+ }
+
insize = SUN8I_MIXER_SIZE(src_w, src_h);
outsize = SUN8I_MIXER_SIZE(dst_w, dst_h);
/* Set height and width */
DRM_DEBUG_DRIVER("Layer source offset X: %d Y: %d\n",
-state->src.x1 >> 16, state->src.y1 >> 16);
+(state->src.x1 >> 16) & ~(format->hsub - 1),
+(state->src.y1 >> 16) & ~(format->vsub - 1));
DRM_DEBUG_DRIVER("Layer source size W: %d H: %d\n", src_w, src_h);
regmap_write(mixer->engine.regs,
SUN8I_MIXER_CHAN_VI_LAYER_SIZE(channel, overlay),
@@ -81,7 +102,13 @@ static int sun8i_vi_layer_update_coord(struct sun8i_mixer
*mixer, int channel,
SUN8I_MIXER_CHAN_VI_OVL_SIZE(channel),
insize);
- if (insize != outsize || hphase || vphase) {
+ /*
+* Scaler must be enabled for subsampled formats, so it scales
+* chroma to same size as luma.
+*/
+ subsampled = format->hsub > 1 || format->vsub > 1;
+
+ if (insize != outsize || subsampled || hphase || vphase) {
u32 hscale, vscale;
DRM_DEBUG_DRIVER("HW scaling is enabled\n");
@@ -120,7 +147,7 @@ static int sun8i_vi_layer_update_formats(struct sun8i_mixer
*mixer, int channel,
u32 val;
fmt_info = sun8i_mixer_format_info(state->fb->format->format);
- if (!fmt_info || !fmt_info->rgb) {
+ if (!fmt_info) {
DRM_DEBUG_DRIVER("Invalid format\n");
return -EINVAL;
}
@@ -128,9 +155,23 @@ static int sun8i_vi_layer_update_formats(struct
sun8i_mixer *mixer, int channel,
val = fmt_info->de2_fmt << SUN8I_MIXER_CHAN_VI_LAYER_ATTR_FBFMT_OFFSET;
regmap_update_bits(mixer->engine.regs,
SUN8I_MIXER_CHAN_VI_LAYER_ATTR(channel, overlay),
- SUN8I_MIXER_CHAN_VI_LAYER_ATTR_FBFMT_MASK |
- SUN8I_MIXER_CHAN_VI_LAYER_ATTR_RGB_MODE,
- val | SUN8I_MIXER_CHAN_VI_LAYER_ATTR_RGB_MODE);
+ SUN8I_MIXER_CHAN_VI_LAYER_ATTR_FBFMT_MASK, val);
+
+ if (fmt_info->csc != SUN8I_CSC_MODE_OFF) {
+ sun8i_csc_set_ccsc_coefficients(mixer, channel, fmt_info->csc);
+ sun8i_csc_enable_ccsc(mixer, channel, true);
+ } else {
+ sun8i_csc_enable_ccsc(mixer, channel, false);
+ }
+
+ if (fmt_info->rgb)
+ val = SUN8I_MIXER_CHAN_VI_LAYER_ATTR_RGB_MODE;
+ else
+ val = 0;
+
+ regmap_update_bits(mixer->engine.regs,
+ SUN8I_MIXER_CHAN_VI_LAYER_ATTR(channel, overlay),
+ SUN8I_MIXER_CHAN_VI_LAYER_ATTR_RGB_MODE, val);
return 0;
}
@@ -140,34 +181,53 @@ static int sun8i_vi_layer_update_buffer(struct
sun8i_mixer *mixer, int channel,
{
struct drm_plane_state *state = plane->state;
struct drm_framebuffer *fb = state->fb;
+ const struct drm_format_info *format = fb->format;
struct drm_gem_cma_object *gem;
+ u32 dx, dy, src_x, src_y;
dma_addr_t paddr;
- int bpp;
+ int i;
- /* Get the physical address of the buffer in memory */
- gem = drm_fb_cma_get_gem_obj(fb, 0);
+ /* Adjust x and y to
[PATCH v2 25/27] drm/sun4i: Expand DE2 scaler lib with YUV support
Basic principle of operation when using YUV framebuffer is that chroma
planes have to be upscaled to same size as luma.
Because of that, expand DE2 scaler library to support that.
BSP driver uses another set of FIR filter coefficients for YUV planes.
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/sun8i_vi_layer.c | 4 +-
drivers/gpu/drm/sun4i/sun8i_vi_scaler.c | 458 +++-
drivers/gpu/drm/sun4i/sun8i_vi_scaler.h | 4 +-
3 files changed, 453 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
b/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
index 5a09abec189b..02aaa7d3fceb 100644
--- a/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
@@ -51,6 +51,7 @@ static int sun8i_vi_layer_update_coord(struct sun8i_mixer
*mixer, int channel,
int overlay, struct drm_plane *plane)
{
struct drm_plane_state *state = plane->state;
+ const struct drm_format_info *format = state->fb->format;
u32 src_w, src_h, dst_w, dst_h;
u32 outsize, insize;
u32 hphase, vphase;
@@ -89,7 +90,8 @@ static int sun8i_vi_layer_update_coord(struct sun8i_mixer
*mixer, int channel,
vscale = state->src_h / state->crtc_h;
sun8i_vi_scaler_setup(mixer, channel, src_w, src_h, dst_w,
- dst_h, hscale, vscale, hphase, vphase);
+ dst_h, hscale, vscale, hphase, vphase,
+ format);
sun8i_vi_scaler_enable(mixer, channel, true);
} else {
DRM_DEBUG_DRIVER("HW scaling is not needed\n");
diff --git a/drivers/gpu/drm/sun4i/sun8i_vi_scaler.c
b/drivers/gpu/drm/sun4i/sun8i_vi_scaler.c
index 68b92e46be68..d3f1acb234b7 100644
--- a/drivers/gpu/drm/sun4i/sun8i_vi_scaler.c
+++ b/drivers/gpu/drm/sun4i/sun8i_vi_scaler.c
@@ -422,6 +422,417 @@ static const u32 lan2coefftab32[480] = {
0x0e1d1401, 0x0f1d1301, 0x0f1d1301, 0x101e1200,
};
+static const u32 bicubic8coefftab32_left[480] = {
+ 0x4000, 0x40ff, 0x3ffe, 0x3efe,
+ 0x3dfd, 0x3cfc, 0x3bfc, 0x39fc,
+ 0x36fc, 0x35fb, 0x33fb, 0x31fb,
+ 0x2ffb, 0x2cfb, 0x29fc, 0x27fc,
+ 0x24fc, 0x21fc, 0x1efd, 0x1cfd,
+ 0x19fd, 0x16fe, 0x14fe, 0x11fe,
+ 0x0dff, 0x0cff, 0x0aff, 0x08ff,
+ 0x0500, 0x0300, 0x0200, 0x0100,
+
+ 0x3904ff00, 0x3903ff00, 0x3902ff00, 0x3801,
+ 0x3700, 0x36ff, 0x35ff, 0x34fe,
+ 0x32fe, 0x31fd, 0x30fd, 0x2efc,
+ 0x2cfc, 0x2afc, 0x28fc, 0x26fc,
+ 0x24fc, 0x22fc, 0x20fc, 0x1efc,
+ 0x1cfc, 0x19fc, 0x17fc, 0x15fd,
+ 0x12fd, 0x11fd, 0x0ffd, 0x0dfe,
+ 0x0bfe, 0x09fe, 0x08fe, 0x06ff,
+
+ 0x3209fe00, 0x3407fe00, 0x3306fe00, 0x3305fe00,
+ 0x3204fe00, 0x3102ff00, 0x3102ff00, 0x3001ff00,
+ 0x2f00ff00, 0x2e00, 0x2cff, 0x2bfe,
+ 0x29fe, 0x28fe, 0x26fd, 0x24fd,
+ 0x23fd, 0x21fd, 0x20fc, 0x1efc,
+ 0x1dfc, 0x1bfc, 0x19fc, 0x17fc,
+ 0x16fc, 0x14fc, 0x12fc, 0x10fd,
+ 0x0ffd, 0x0dfd, 0x0cfd, 0x0afd,
+
+ 0x2e0cfd00, 0x2e0bfd00, 0x2e09fd00, 0x2e08fd00,
+ 0x2e07fd00, 0x2c06fe00, 0x2c05fe00, 0x2b04fe00,
+ 0x2b03fe00, 0x2a02fe00, 0x2901fe00, 0x2701ff00,
+ 0x2700ff00, 0x2600, 0x2400, 0x2300,
+ 0x22feff00, 0x20fe, 0x1ffe, 0x1efd,
+ 0x1dfd, 0x1bfd, 0x1afd, 0x19fd,
+ 0x17fd, 0x15fd, 0x13fd, 0x12fd,
+ 0x11fd, 0x10fd, 0x0ffd, 0x0cfd,
+
+ 0x2a0efd00, 0x2a0dfd00, 0x2a0cfd00, 0x290bfd00,
+ 0x290afd00, 0x2909fd00, 0x2908fd00, 0x2807fd00,
+ 0x2706fd00, 0x2705fd00, 0x2604fe00, 0x2603fe00,
+ 0x2502fe00, 0x2402fe00, 0x2401fe00, 0x2200fe00,
+ 0x2200fe00, 0x2000ff00, 0x1f00, 0x1e00,
+ 0x1dfeff00, 0x1cfeff00, 0x1afeff00, 0x19feff00,
+ 0x17fe, 0x16fd, 0x15fd, 0x14fd,
+ 0x12fd, 0x11fd, 0x10fd, 0x0ffd,
+
+ 0x2610fd00, 0x260ffd00, 0x260efd00, 0x260dfd00,
+ 0x260cfd00, 0x260bfd00, 0x260afd00, 0x2609fd00,
+ 0x2508fd00, 0x2507fd00, 0x2406fd00, 0x2406fd00,
+ 0x2305fd00, 0x2304fd00, 0x2203fe00, 0x2103fe00,
+ 0x2002fe00, 0x1f01fe00, 0x1e01fe00, 0x1e00fe00,
+ 0x1c00fe00, 0x1b00fe00, 0x1afffe00, 0x1900,
+ 0x1800, 0x17feff00, 0x16feff00, 0x15feff00,
+ 0x14feff00, 0x13feff00, 0x11feff00, 0x10fd,
+
+ 0x2411feff, 0x2410feff, 0x240ffeff, 0x230efeff,
+ 0x240dfeff, 0x240cfeff, 0x230cfd00, 0x230bfd00,
+ 0x230afd00, 0x2309fd00, 0x2208fd00, 0x2108fd00,
+ 0x
[PATCH v2 23/27] drm/sun4i: Add DE2 CSC library
DE2 have many CSC units - channel input CSC, channel output CSC and
mixer output CSC and maybe more.
Fortunately, they have all same register layout, only base offsets
differs.
Add support only for channel output CSC for now.
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/Makefile| 2 +-
drivers/gpu/drm/sun4i/sun8i_csc.c | 93 +++
drivers/gpu/drm/sun4i/sun8i_csc.h | 36 +++
3 files changed, 130 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/sun4i/sun8i_csc.c
create mode 100644 drivers/gpu/drm/sun4i/sun8i_csc.h
diff --git a/drivers/gpu/drm/sun4i/Makefile b/drivers/gpu/drm/sun4i/Makefile
index a458ddbf4a8e..82a6ac57fbe3 100644
--- a/drivers/gpu/drm/sun4i/Makefile
+++ b/drivers/gpu/drm/sun4i/Makefile
@@ -11,7 +11,7 @@ sun4i-drm-hdmi-y += sun4i_hdmi_tmds_clk.o
sun8i-mixer-y += sun8i_mixer.o sun8i_ui_layer.o \
sun8i_vi_layer.o sun8i_ui_scaler.o \
- sun8i_vi_scaler.o
+ sun8i_vi_scaler.o sun8i_csc.o
sun4i-tcon-y += sun4i_crtc.o
sun4i-tcon-y += sun4i_dotclock.o
diff --git a/drivers/gpu/drm/sun4i/sun8i_csc.c
b/drivers/gpu/drm/sun4i/sun8i_csc.c
new file mode 100644
index ..b14925b40ccf
--- /dev/null
+++ b/drivers/gpu/drm/sun4i/sun8i_csc.c
@@ -0,0 +1,93 @@
+/*
+ * Copyright (C) Jernej Skrabec
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ */
+
+#include
+
+#include "sun8i_csc.h"
+#include "sun8i_mixer.h"
+
+static const u32 ccsc_base[2][2] = {
+ {CCSC00_OFFSET, CCSC01_OFFSET},
+ {CCSC10_OFFSET, CCSC11_OFFSET},
+};
+
+/*
+ * Factors are in two's complement format, 10 bits for fractinal part.
+ * First tree values in each line are multiplication factor and last
+ * value is constant, which is added at the end.
+ */
+static const u32 yuv2rgb[] = {
+ 0x04A8, 0x, 0x0662, 0xFFFC845A,
+ 0x04A8, 0xFE6F, 0xFCBF, 0x00021DF4,
+ 0x04A8, 0x0813, 0x, 0xFFFBAC4A,
+};
+
+static const u32 yvu2rgb[] = {
+ 0x04A8, 0x0662, 0x, 0xFFFC845A,
+ 0x04A8, 0xFCBF, 0xFE6F, 0x00021DF4,
+ 0x04A8, 0x, 0x0813, 0xFFFBAC4A,
+};
+
+static void sun8i_csc_set_coefficients(struct regmap *map, u32 base,
+ enum sun8i_csc_mode mode)
+{
+ const u32 *table;
+ int i, data;
+
+ switch (mode) {
+ case SUN8I_CSC_MODE_YUV2RGB:
+ table = yuv2rgb;
+ break;
+ case SUN8I_CSC_MODE_YVU2RGB:
+ table = yvu2rgb;
+ break;
+ default:
+ DRM_WARN("Wrong CSC mode specified.\n");
+ return;
+ }
+
+ for (i = 0; i < 12; i++) {
+ data = table[i];
+ /* For some reason, 0x200 must be added to constant parts */
+ if (((i + 1) & 3) == 0)
+ data += 0x200;
+ regmap_write(map, SUN8I_CSC_COEFF(base, i), data);
+ }
+}
+
+static void sun8i_csc_enable(struct regmap *map, u32 base, bool enable)
+{
+ u32 val;
+
+ if (enable)
+ val = SUN8I_CSC_CTRL_EN;
+ else
+ val = 0;
+
+ regmap_update_bits(map, SUN8I_CSC_CTRL(base), SUN8I_CSC_CTRL_EN, val);
+}
+
+void sun8i_csc_set_ccsc_coefficients(struct sun8i_mixer *mixer, int layer,
+enum sun8i_csc_mode mode)
+{
+ u32 base;
+
+ base = ccsc_base[mixer->cfg->ccsc][layer];
+
+ sun8i_csc_set_coefficients(mixer->engine.regs, base, mode);
+}
+
+void sun8i_csc_enable_ccsc(struct sun8i_mixer *mixer, int layer, bool enable)
+{
+ u32 base;
+
+ base = ccsc_base[mixer->cfg->ccsc][layer];
+
+ sun8i_csc_enable(mixer->engine.regs, base, enable);
+}
diff --git a/drivers/gpu/drm/sun4i/sun8i_csc.h
b/drivers/gpu/drm/sun4i/sun8i_csc.h
new file mode 100644
index ..880e8fbb0855
--- /dev/null
+++ b/drivers/gpu/drm/sun4i/sun8i_csc.h
@@ -0,0 +1,36 @@
+/*
+ * Copyright (C) Jernej Skrabec
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ */
+
+#ifndef _SUN8I_CSC_H_
+#define _SUN8I_CSC_H_
+
+struct sun8i_mixer;
+
+/* VI channel CSC units offsets */
+#define CCSC00_OFFSET 0xAA050
+#define CCSC01_OFFSET 0xFA000
+#define CCSC10_OFFSET 0xA
+#define CCSC11_OFFSET 0xF
+
+#define SUN8I_CSC_CTRL(base) (base + 0x0)
+#define SUN8I_CSC_COEFF(base, i) (base + 0x10 +
[PATCH v2 27/27] [DO NOT MERGE]drm/sun4i: Change zpos of bottom VI plane
Change zpos of VI plane so it is above primary.
Clearly this works only if mixer supports only one VI plane, but it is
good enough for testing and developing.
Proper solution with zpos property should be developed instead.
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/sun8i_mixer.c| 2 +-
drivers/gpu/drm/sun4i/sun8i_ui_layer.c | 10 ++
drivers/gpu/drm/sun4i/sun8i_vi_layer.c | 10 ++
3 files changed, 13 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c
b/drivers/gpu/drm/sun4i/sun8i_mixer.c
index 29ceeb016d72..5a6774d40912 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
@@ -424,7 +424,7 @@ static int sun8i_mixer_bind(struct device *dev, struct
device *master,
SUN8I_MIXER_BLEND_COLOR_BLACK);
/* Fixed zpos for now */
- regmap_write(mixer->engine.regs, SUN8I_MIXER_BLEND_ROUTE, 0x43210);
+ regmap_write(mixer->engine.regs, SUN8I_MIXER_BLEND_ROUTE, 0x43201);
plane_cnt = mixer->cfg->vi_num + mixer->cfg->ui_num;
for (i = 0; i < plane_cnt; i++)
diff --git a/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
b/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
index fd76ffd40580..472a846ac967 100644
--- a/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
@@ -26,6 +26,8 @@
#include "sun8i_mixer.h"
#include "sun8i_ui_scaler.h"
+static int lmap[] = {1, 0, 2, 3, 4};
+
static void sun8i_ui_layer_enable(struct sun8i_mixer *mixer, int channel,
int overlay, bool enable)
{
@@ -44,13 +46,13 @@ static void sun8i_ui_layer_enable(struct sun8i_mixer
*mixer, int channel,
SUN8I_MIXER_CHAN_UI_LAYER_ATTR_EN, val);
if (enable)
- val = SUN8I_MIXER_BLEND_PIPE_CTL_EN(channel);
+ val = SUN8I_MIXER_BLEND_PIPE_CTL_EN(lmap[channel]);
else
val = 0;
regmap_update_bits(mixer->engine.regs,
SUN8I_MIXER_BLEND_PIPE_CTL,
- SUN8I_MIXER_BLEND_PIPE_CTL_EN(channel), val);
+ SUN8I_MIXER_BLEND_PIPE_CTL_EN(lmap[channel]), val);
}
static int sun8i_ui_layer_update_coord(struct sun8i_mixer *mixer, int channel,
@@ -137,10 +139,10 @@ static int sun8i_ui_layer_update_coord(struct sun8i_mixer
*mixer, int channel,
state->dst.x1, state->dst.y1);
DRM_DEBUG_DRIVER("Layer destination size W: %d H: %d\n", dst_w, dst_h);
regmap_write(mixer->engine.regs,
-SUN8I_MIXER_BLEND_ATTR_COORD(channel),
+SUN8I_MIXER_BLEND_ATTR_COORD(lmap[channel]),
SUN8I_MIXER_COORD(state->dst.x1, state->dst.y1));
regmap_write(mixer->engine.regs,
-SUN8I_MIXER_BLEND_ATTR_INSIZE(channel),
+SUN8I_MIXER_BLEND_ATTR_INSIZE(lmap[channel]),
outsize);
return 0;
diff --git a/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
b/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
index 0b4800fd7ba1..e4ee2b51457f 100644
--- a/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
@@ -20,6 +20,8 @@
#include "sun8i_mixer.h"
#include "sun8i_vi_scaler.h"
+static int lmap[] = {1, 0, 2, 3, 4};
+
static void sun8i_vi_layer_enable(struct sun8i_mixer *mixer, int channel,
int overlay, bool enable)
{
@@ -38,13 +40,13 @@ static void sun8i_vi_layer_enable(struct sun8i_mixer
*mixer, int channel,
SUN8I_MIXER_CHAN_VI_LAYER_ATTR_EN, val);
if (enable)
- val = SUN8I_MIXER_BLEND_PIPE_CTL_EN(channel);
+ val = SUN8I_MIXER_BLEND_PIPE_CTL_EN(lmap[channel]);
else
val = 0;
regmap_update_bits(mixer->engine.regs,
SUN8I_MIXER_BLEND_PIPE_CTL,
- SUN8I_MIXER_BLEND_PIPE_CTL_EN(channel), val);
+ SUN8I_MIXER_BLEND_PIPE_CTL_EN(lmap[channel]), val);
}
static int sun8i_vi_layer_update_coord(struct sun8i_mixer *mixer, int channel,
@@ -130,10 +132,10 @@ static int sun8i_vi_layer_update_coord(struct sun8i_mixer
*mixer, int channel,
state->dst.x1, state->dst.y1);
DRM_DEBUG_DRIVER("Layer destination size W: %d H: %d\n", dst_w, dst_h);
regmap_write(mixer->engine.regs,
-SUN8I_MIXER_BLEND_ATTR_COORD(channel),
+SUN8I_MIXER_BLEND_ATTR_COORD(lmap[channel]),
SUN8I_MIXER_COORD(state->dst.x1, state->dst.y1));
regmap_write(mixer->engine.regs,
-SUN8I_MIXER_BLEND_ATTR_INSIZE(channel),
+SUN8I_MIXER_BLEND_ATTR_INSIZE(lmap[channel]),
outsize);
return 0;
--
2.15.1
[PATCH v2 18/27] drm/sun4i: Reorganize UI layer code in DE2
Till now, DE2 driver supported only UI planes. Before we add support for
VI planes, lets split out UI layer specific code from common parts. This
commit does the following:
- renames sun8i_layer.c to sun8i_ui_layer.c
- moves UI channel specific code to sun8i_ui_layer.c
- moves common code from sun8i_layer.c to sun8i_mixer.c
- renames function and structure names so it is apparent where they
belong to
No functional change is made.
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/Makefile | 2 +-
drivers/gpu/drm/sun4i/sun8i_layer.c| 187
drivers/gpu/drm/sun4i/sun8i_layer.h| 37
drivers/gpu/drm/sun4i/sun8i_mixer.c| 174 +++---
drivers/gpu/drm/sun4i/sun8i_mixer.h| 43 +
drivers/gpu/drm/sun4i/sun8i_ui_layer.c | 314 +
drivers/gpu/drm/sun4i/sun8i_ui_layer.h | 63 +++
7 files changed, 406 insertions(+), 414 deletions(-)
delete mode 100644 drivers/gpu/drm/sun4i/sun8i_layer.c
delete mode 100644 drivers/gpu/drm/sun4i/sun8i_layer.h
create mode 100644 drivers/gpu/drm/sun4i/sun8i_ui_layer.c
create mode 100644 drivers/gpu/drm/sun4i/sun8i_ui_layer.h
diff --git a/drivers/gpu/drm/sun4i/Makefile b/drivers/gpu/drm/sun4i/Makefile
index 0c2f8c7facae..0a839674cd1d 100644
--- a/drivers/gpu/drm/sun4i/Makefile
+++ b/drivers/gpu/drm/sun4i/Makefile
@@ -9,7 +9,7 @@ sun4i-drm-hdmi-y+= sun4i_hdmi_enc.o
sun4i-drm-hdmi-y += sun4i_hdmi_i2c.o
sun4i-drm-hdmi-y += sun4i_hdmi_tmds_clk.o
-sun8i-mixer-y += sun8i_mixer.o sun8i_layer.o
+sun8i-mixer-y += sun8i_mixer.o sun8i_ui_layer.o
sun4i-tcon-y += sun4i_crtc.o
sun4i-tcon-y += sun4i_dotclock.o
diff --git a/drivers/gpu/drm/sun4i/sun8i_layer.c
b/drivers/gpu/drm/sun4i/sun8i_layer.c
deleted file mode 100644
index cdeda083c60e..
--- a/drivers/gpu/drm/sun4i/sun8i_layer.c
+++ /dev/null
@@ -1,187 +0,0 @@
-/*
- * Copyright (C) Icenowy Zheng
- *
- * Based on sun4i_layer.h, which is:
- * Copyright (C) 2015 Free Electrons
- * Copyright (C) 2015 NextThing Co
- *
- * Maxime Ripard
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License as
- * published by the Free Software Foundation; either version 2 of
- * the License, or (at your option) any later version.
- */
-
-#include
-#include
-#include
-#include
-#include
-
-#include "sun8i_layer.h"
-#include "sun8i_mixer.h"
-
-static int sun8i_mixer_layer_atomic_check(struct drm_plane *plane,
- struct drm_plane_state *state)
-{
- struct drm_crtc *crtc = state->crtc;
- struct drm_crtc_state *crtc_state;
- struct drm_rect clip;
-
- if (!crtc)
- return 0;
-
- crtc_state = drm_atomic_get_existing_crtc_state(state->state, crtc);
- if (WARN_ON(!crtc_state))
- return -EINVAL;
-
- clip.x1 = 0;
- clip.y1 = 0;
- clip.x2 = crtc_state->adjusted_mode.hdisplay;
- clip.y2 = crtc_state->adjusted_mode.vdisplay;
-
- return drm_plane_helper_check_state(state, &clip,
- DRM_PLANE_HELPER_NO_SCALING,
- DRM_PLANE_HELPER_NO_SCALING,
- true, true);
-}
-
-static void sun8i_mixer_layer_atomic_disable(struct drm_plane *plane,
- struct drm_plane_state
*old_state)
-{
- struct sun8i_layer *layer = plane_to_sun8i_layer(plane);
- struct sun8i_mixer *mixer = layer->mixer;
-
- sun8i_mixer_layer_enable(mixer, layer->channel,
-layer->overlay, false);
-}
-
-static void sun8i_mixer_layer_atomic_update(struct drm_plane *plane,
- struct drm_plane_state *old_state)
-{
- struct sun8i_layer *layer = plane_to_sun8i_layer(plane);
- struct sun8i_mixer *mixer = layer->mixer;
-
- if (!plane->state->visible) {
- sun8i_mixer_layer_enable(mixer, layer->channel,
-layer->overlay, false);
- return;
- }
-
- sun8i_mixer_update_layer_coord(mixer, layer->channel,
- layer->overlay, plane);
- sun8i_mixer_update_layer_formats(mixer, layer->channel,
-layer->overlay, plane);
- sun8i_mixer_update_layer_buffer(mixer, layer->channel,
- layer->overlay, plane);
- sun8i_mixer_layer_enable(mixer, layer->channel,
-layer->overlay, true);
-}
-
-static struct drm_plane_helper_funcs sun8i_mixer_layer_helper_funcs = {
- .atomic_check = sun8i_mixer_layer_atomic_check,
- .atomic_disable = sun8i_mixer_layer_atomic_disable,
- .atomic
[PATCH v2 22/27] drm/sun4i: Add CCSC property to DE2 configuration
Base addresses of channel output CSC (CCSC) depends whether mixer in
question is first or second and if it is second, if supports VEP or not.
This new property will tell which set of base addresses to take.
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/sun8i_mixer.c | 1 +
drivers/gpu/drm/sun4i/sun8i_mixer.h | 5 +
2 files changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c
b/drivers/gpu/drm/sun4i/sun8i_mixer.c
index e3296a060352..7f88cf5f97eb 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
@@ -337,6 +337,7 @@ static const struct sun8i_mixer_cfg sun8i_v3s_mixer_cfg = {
.vi_num = 2,
.ui_num = 1,
.scaler_mask = 0x3,
+ .ccsc = 0,
};
static const struct of_device_id sun8i_mixer_of_table[] = {
diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.h
b/drivers/gpu/drm/sun4i/sun8i_mixer.h
index 9bbd762d26f7..994090858b18 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.h
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.h
@@ -98,11 +98,16 @@ struct de2_fmt_info {
* First, scaler supports for VI channels is defined and after that, scaler
* support for UI channels. For example, if mixer has 2 VI channels without
* scaler and 2 UI channels with scaler, bitmask would be 0xC.
+ * @ccsc: select set of CCSC base addresses
+ * Set value to 0 if this is first mixer or second mixer with VEP support.
+ * Set value to 1 if this is second mixer without VEP support. Other values
+ * are invalid.
*/
struct sun8i_mixer_cfg {
int vi_num;
int ui_num;
int scaler_mask;
+ int ccsc;
};
struct sun8i_mixer {
--
2.15.1
[PATCH v2 20/27] drm/sun4i: Add scaler configuration to DE2 mixers
No all SoCs support scaling on all channels. For example, V3s support
scaling only on VI channels. Because of that, add additional
configuration bitmask which tells which channel support scaler.
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/sun8i_mixer.c | 1 +
drivers/gpu/drm/sun4i/sun8i_mixer.h | 10 ++
2 files changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c
b/drivers/gpu/drm/sun4i/sun8i_mixer.c
index 888620b1d3f1..e3296a060352 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
@@ -336,6 +336,7 @@ static int sun8i_mixer_remove(struct platform_device *pdev)
static const struct sun8i_mixer_cfg sun8i_v3s_mixer_cfg = {
.vi_num = 2,
.ui_num = 1,
+ .scaler_mask = 0x3,
};
static const struct of_device_id sun8i_mixer_of_table[] = {
diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.h
b/drivers/gpu/drm/sun4i/sun8i_mixer.h
index bad0969ac105..a6270b307ae5 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.h
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.h
@@ -94,9 +94,19 @@ struct de2_fmt_info {
u32 de2_fmt;
};
+/**
+ * struct sun8i_mixer_cfg - mixer HW configuration
+ * @vi_num: number of VI channels
+ * @ui_num: number of UI channels
+ * @scaler_mask: bitmask which tells which channel supports scaling
+ * First, scaler supports for VI channels is defined and after that, scaler
+ * support for UI channels. For example, if mixer has 2 VI channels without
+ * scaler and 2 UI channels with scaler, bitmask would be 0xC.
+ */
struct sun8i_mixer_cfg {
int vi_num;
int ui_num;
+ int scaler_mask;
};
struct sun8i_mixer {
--
2.15.1
[PATCH v2 10/27] drm/sun4i: Start using layer id in DE2 driver
Till now, plane selection was hardcoded to first overlay in first UI
channel and layer parameter is unused.
Rename and add parameters to layer functions so they would represent HW
more accurately and start using then.
It turns out that overlays don't fit well in current DRM design, because
they can't be blended together or scaled independetly when they are set
to same channel. Because of that, always use only first overlay in each
channel.
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/sun8i_layer.c | 18 -
drivers/gpu/drm/sun4i/sun8i_layer.h | 3 ++-
drivers/gpu/drm/sun4i/sun8i_mixer.c | 50 -
drivers/gpu/drm/sun4i/sun8i_mixer.h | 16 ++--
4 files changed, 43 insertions(+), 44 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_layer.c
b/drivers/gpu/drm/sun4i/sun8i_layer.c
index 23810ff72684..5aa6e2c9728e 100644
--- a/drivers/gpu/drm/sun4i/sun8i_layer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_layer.c
@@ -32,7 +32,8 @@ static void sun8i_mixer_layer_atomic_disable(struct drm_plane
*plane,
struct sun8i_layer *layer = plane_to_sun8i_layer(plane);
struct sun8i_mixer *mixer = layer->mixer;
- sun8i_mixer_layer_enable(mixer, layer->id, false);
+ sun8i_mixer_layer_enable(mixer, layer->channel,
+layer->overlay, false);
}
static void sun8i_mixer_layer_atomic_update(struct drm_plane *plane,
@@ -41,10 +42,14 @@ static void sun8i_mixer_layer_atomic_update(struct
drm_plane *plane,
struct sun8i_layer *layer = plane_to_sun8i_layer(plane);
struct sun8i_mixer *mixer = layer->mixer;
- sun8i_mixer_update_layer_coord(mixer, layer->id, plane);
- sun8i_mixer_update_layer_formats(mixer, layer->id, plane);
- sun8i_mixer_update_layer_buffer(mixer, layer->id, plane);
- sun8i_mixer_layer_enable(mixer, layer->id, true);
+ sun8i_mixer_update_layer_coord(mixer, layer->channel,
+ layer->overlay, plane);
+ sun8i_mixer_update_layer_formats(mixer, layer->channel,
+layer->overlay, plane);
+ sun8i_mixer_update_layer_buffer(mixer, layer->channel,
+ layer->overlay, plane);
+ sun8i_mixer_layer_enable(mixer, layer->channel,
+layer->overlay, true);
}
static struct drm_plane_helper_funcs sun8i_mixer_layer_helper_funcs = {
@@ -126,7 +131,8 @@ struct drm_plane **sun8i_layers_init(struct drm_device *drm,
return ERR_CAST(layer);
};
- layer->id = i;
+ layer->channel = mixer->cfg->vi_num + i;
+ layer->overlay = 0;
planes[i] = &layer->plane;
};
diff --git a/drivers/gpu/drm/sun4i/sun8i_layer.h
b/drivers/gpu/drm/sun4i/sun8i_layer.h
index e5eccd27cff0..d246e0dd3d48 100644
--- a/drivers/gpu/drm/sun4i/sun8i_layer.h
+++ b/drivers/gpu/drm/sun4i/sun8i_layer.h
@@ -22,7 +22,8 @@ struct sun8i_layer {
struct drm_planeplane;
struct sun4i_drv*drv;
struct sun8i_mixer *mixer;
- int id;
+ int channel;
+ int overlay;
};
static inline struct sun8i_layer *
diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c
b/drivers/gpu/drm/sun4i/sun8i_mixer.c
index 015943c0ed5a..2bf7ba1e5ba7 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
@@ -37,15 +37,13 @@ static void sun8i_mixer_commit(struct sunxi_engine *engine)
SUN8I_MIXER_GLOBAL_DBUFF_ENABLE);
}
-void sun8i_mixer_layer_enable(struct sun8i_mixer *mixer,
- int layer, bool enable)
+void sun8i_mixer_layer_enable(struct sun8i_mixer *mixer, int channel,
+ int overlay, bool enable)
{
u32 val;
- /* Currently the first UI channel is used */
- int chan = mixer->cfg->vi_num;
- DRM_DEBUG_DRIVER("%sabling layer %d in channel %d\n",
-enable ? "En" : "Dis", layer, chan);
+ DRM_DEBUG_DRIVER("%sabling channel %d overlay %d\n",
+enable ? "En" : "Dis", channel, overlay);
if (enable)
val = SUN8I_MIXER_CHAN_UI_LAYER_ATTR_EN;
@@ -53,17 +51,17 @@ void sun8i_mixer_layer_enable(struct sun8i_mixer *mixer,
val = 0;
regmap_update_bits(mixer->engine.regs,
- SUN8I_MIXER_CHAN_UI_LAYER_ATTR(chan, layer),
+ SUN8I_MIXER_CHAN_UI_LAYER_ATTR(channel, overlay),
SUN8I_MIXER_CHAN_UI_LAYER_ATTR_EN, val);
if (enable)
- val = SUN8I_MIXER_BLEND_PIPE_CTL_EN(chan);
+ val = SUN8I_MIXER_BLEND_PIPE_CTL_EN(channel);
else
val = 0;
regmap_update_bits(mixer->engine.regs,
SUN8I_M
[PATCH v2 14/27] drm/sun4i: Move channel size related code in DE2
Channel size should be set every time plane is changed, not only when
primary plane changes. Current code works only because only one
(primary) plane is supported at the moment.
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/sun8i_mixer.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c
b/drivers/gpu/drm/sun4i/sun8i_mixer.c
index 9635c30651d6..00c0cc6440e2 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
@@ -109,16 +109,8 @@ int sun8i_mixer_update_layer_coord(struct sun8i_mixer
*mixer, int channel,
regmap_write(mixer->engine.regs,
SUN8I_MIXER_GLOBAL_SIZE,
size);
- DRM_DEBUG_DRIVER("Updating blender size\n");
- regmap_write(mixer->engine.regs,
-SUN8I_MIXER_BLEND_ATTR_INSIZE(channel),
-size);
regmap_write(mixer->engine.regs, SUN8I_MIXER_BLEND_OUTSIZE,
size);
- DRM_DEBUG_DRIVER("Updating channel size\n");
- regmap_write(mixer->engine.regs,
-SUN8I_MIXER_CHAN_UI_OVL_SIZE(channel),
-size);
}
/* Set height and width */
@@ -126,6 +118,9 @@ int sun8i_mixer_update_layer_coord(struct sun8i_mixer
*mixer, int channel,
regmap_write(mixer->engine.regs,
SUN8I_MIXER_CHAN_UI_LAYER_SIZE(channel, overlay),
size);
+ regmap_write(mixer->engine.regs,
+SUN8I_MIXER_CHAN_UI_OVL_SIZE(channel),
+size);
/* Set base coordinates */
DRM_DEBUG_DRIVER("Layer coordinates X: %d Y: %d\n",
@@ -133,6 +128,9 @@ int sun8i_mixer_update_layer_coord(struct sun8i_mixer
*mixer, int channel,
regmap_write(mixer->engine.regs,
SUN8I_MIXER_BLEND_ATTR_COORD(channel),
SUN8I_MIXER_COORD(state->dst.x1, state->dst.y1));
+ regmap_write(mixer->engine.regs,
+SUN8I_MIXER_BLEND_ATTR_INSIZE(channel),
+size);
return 0;
}
--
2.15.1
[PATCH v2 12/27] drm/sun4i: Use values calculated by atomic check
Now that we have properly clipped coordinates in plane state structure,
use them.
This also fixes bug where source x and y were adjusted for negative
value, but width and height weren't. It wasn't discovered because
primary plane usually doesn't have negative coordinates.
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/sun8i_layer.c | 6 +
drivers/gpu/drm/sun4i/sun8i_mixer.c | 52 -
2 files changed, 28 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_layer.c
b/drivers/gpu/drm/sun4i/sun8i_layer.c
index 40e6b83aef3b..1eced63f365d 100644
--- a/drivers/gpu/drm/sun4i/sun8i_layer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_layer.c
@@ -69,6 +69,12 @@ static void sun8i_mixer_layer_atomic_update(struct drm_plane
*plane,
struct sun8i_layer *layer = plane_to_sun8i_layer(plane);
struct sun8i_mixer *mixer = layer->mixer;
+ if (!plane->state->visible) {
+ sun8i_mixer_layer_enable(mixer, layer->channel,
+layer->overlay, false);
+ return;
+ }
+
sun8i_mixer_update_layer_coord(mixer, layer->channel,
layer->overlay, plane);
sun8i_mixer_update_layer_formats(mixer, layer->channel,
diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c
b/drivers/gpu/drm/sun4i/sun8i_mixer.c
index 2bf7ba1e5ba7..37fcc5ed18c5 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
@@ -92,28 +92,34 @@ int sun8i_mixer_update_layer_coord(struct sun8i_mixer
*mixer, int channel,
{
struct drm_plane_state *state = plane->state;
struct drm_framebuffer *fb = state->fb;
+ u32 width, height, size;
DRM_DEBUG_DRIVER("Updating channel %d overlay %d\n", channel, overlay);
+ /*
+* Same source and destination width and height are guaranteed
+* by atomic check function.
+*/
+ width = drm_rect_width(&state->dst);
+ height = drm_rect_height(&state->dst);
+ size = SUN8I_MIXER_SIZE(width, height);
+
if (plane->type == DRM_PLANE_TYPE_PRIMARY) {
DRM_DEBUG_DRIVER("Primary layer, updating global size W: %u H:
%u\n",
-state->crtc_w, state->crtc_h);
- regmap_write(mixer->engine.regs, SUN8I_MIXER_GLOBAL_SIZE,
-SUN8I_MIXER_SIZE(state->crtc_w,
- state->crtc_h));
+width, height);
+ regmap_write(mixer->engine.regs,
+SUN8I_MIXER_GLOBAL_SIZE,
+size);
DRM_DEBUG_DRIVER("Updating blender size\n");
regmap_write(mixer->engine.regs,
SUN8I_MIXER_BLEND_ATTR_INSIZE(channel),
-SUN8I_MIXER_SIZE(state->crtc_w,
- state->crtc_h));
+size);
regmap_write(mixer->engine.regs, SUN8I_MIXER_BLEND_OUTSIZE,
-SUN8I_MIXER_SIZE(state->crtc_w,
- state->crtc_h));
+size);
DRM_DEBUG_DRIVER("Updating channel size\n");
regmap_write(mixer->engine.regs,
SUN8I_MIXER_CHAN_UI_OVL_SIZE(channel),
-SUN8I_MIXER_SIZE(state->crtc_w,
- state->crtc_h));
+size);
}
/* Set the line width */
@@ -123,18 +129,17 @@ int sun8i_mixer_update_layer_coord(struct sun8i_mixer
*mixer, int channel,
fb->pitches[0]);
/* Set height and width */
- DRM_DEBUG_DRIVER("Layer size W: %u H: %u\n",
-state->crtc_w, state->crtc_h);
+ DRM_DEBUG_DRIVER("Layer size W: %u H: %u\n", width, height);
regmap_write(mixer->engine.regs,
SUN8I_MIXER_CHAN_UI_LAYER_SIZE(channel, overlay),
-SUN8I_MIXER_SIZE(state->crtc_w, state->crtc_h));
+size);
/* Set base coordinates */
DRM_DEBUG_DRIVER("Layer coordinates X: %d Y: %d\n",
-state->crtc_x, state->crtc_y);
+state->dst.x1, state->dst.y1);
regmap_write(mixer->engine.regs,
SUN8I_MIXER_BLEND_ATTR_COORD(channel),
-SUN8I_MIXER_COORD(state->crtc_x, state->crtc_y));
+SUN8I_MIXER_COORD(state->dst.x1, state->dst.y1));
return 0;
}
@@ -194,21 +199,8 @@ int sun8i_mixer_update_layer_buffer(struct sun8i_mixer
*mixer, int channel,
paddr = gem->paddr + fb->offsets[0];
/* Fixup framebuffer address for src coordinates */
- paddr += (state->src_x >> 16) * bpp;
- paddr += (state->src_y >> 16) * fb->pitches[0];
-
-
[PATCH v2 02/27] drm/sun4i: Rename DE2 RGB format macros
Current RGB formats macros are actually not specific to UI planes.
Rename it to something more universal and introduce shift macro.
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/sun8i_mixer.c | 7 ---
drivers/gpu/drm/sun4i/sun8i_mixer.h | 8 +---
2 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c
b/drivers/gpu/drm/sun4i/sun8i_mixer.c
index cb193c5f1686..b9c48c60131f 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
@@ -71,15 +71,15 @@ static int sun8i_mixer_drm_format_to_layer(struct drm_plane
*plane,
{
switch (format) {
case DRM_FORMAT_ARGB:
- *mode = SUN8I_MIXER_CHAN_UI_LAYER_ATTR_FBFMT_ARGB;
+ *mode = SUN8I_MIXER_FBFMT_ARGB;
break;
case DRM_FORMAT_XRGB:
- *mode = SUN8I_MIXER_CHAN_UI_LAYER_ATTR_FBFMT_XRGB;
+ *mode = SUN8I_MIXER_FBFMT_XRGB;
break;
case DRM_FORMAT_RGB888:
- *mode = SUN8I_MIXER_CHAN_UI_LAYER_ATTR_FBFMT_RGB888;
+ *mode = SUN8I_MIXER_FBFMT_RGB888;
break;
default:
@@ -173,6 +173,7 @@ int sun8i_mixer_update_layer_formats(struct sun8i_mixer
*mixer,
return ret;
}
+ val <<= SUN8I_MIXER_CHAN_UI_LAYER_ATTR_FBFMT_OFFSET;
regmap_update_bits(mixer->engine.regs,
SUN8I_MIXER_CHAN_UI_LAYER_ATTR(chan, layer),
SUN8I_MIXER_CHAN_UI_LAYER_ATTR_FBFMT_MASK, val);
diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.h
b/drivers/gpu/drm/sun4i/sun8i_mixer.h
index c142fbb8661e..82c3416fbf3a 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.h
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.h
@@ -81,13 +81,15 @@
#define SUN8I_MIXER_CHAN_UI_LAYER_ATTR_EN BIT(0)
#define SUN8I_MIXER_CHAN_UI_LAYER_ATTR_ALPHA_MODE_MASK GENMASK(2, 1)
#define SUN8I_MIXER_CHAN_UI_LAYER_ATTR_FBFMT_MASK GENMASK(12, 8)
+#define SUN8I_MIXER_CHAN_UI_LAYER_ATTR_FBFMT_OFFSET8
#define SUN8I_MIXER_CHAN_UI_LAYER_ATTR_ALPHA_MASK GENMASK(31, 24)
#define SUN8I_MIXER_CHAN_UI_LAYER_ATTR_ALPHA_MODE_DEF (1 << 1)
-#define SUN8I_MIXER_CHAN_UI_LAYER_ATTR_FBFMT_ARGB (0 << 8)
-#define SUN8I_MIXER_CHAN_UI_LAYER_ATTR_FBFMT_XRGB (4 << 8)
-#define SUN8I_MIXER_CHAN_UI_LAYER_ATTR_FBFMT_RGB888(8 << 8)
#define SUN8I_MIXER_CHAN_UI_LAYER_ATTR_ALPHA_DEF (0xff << 24)
+#define SUN8I_MIXER_FBFMT_ARGB 0
+#define SUN8I_MIXER_FBFMT_XRGB 4
+#define SUN8I_MIXER_FBFMT_RGB888 8
+
/*
* These sub-engines are still unknown now, the EN registers are here only to
* be used to disable these sub-engines.
--
2.15.1
[PATCH v2 08/27] drm/sun4i: Rename some macros in DE2 driver
Now that some knowledge of DE2 is gained, rename or add some macros to make code more readable. Max channel macro is removed, since it is not used and it is not clear if it has right value. Structures in BSP driver shows possibility of 5 channels maximum although there is no SoC with such configuration. Signed-off-by: Jernej Skrabec --- drivers/gpu/drm/sun4i/sun8i_mixer.c | 5 +++-- drivers/gpu/drm/sun4i/sun8i_mixer.h | 13 ++--- 2 files changed, 9 insertions(+), 9 deletions(-) diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c b/drivers/gpu/drm/sun4i/sun8i_mixer.c index 23659ce1cf27..c7d4ccd605e0 100644 --- a/drivers/gpu/drm/sun4i/sun8i_mixer.c +++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c @@ -323,8 +323,9 @@ static int sun8i_mixer_bind(struct device *dev, struct device *master, SUN8I_MIXER_BLEND_COLOR_BLACK); /* Initialize blender */ - regmap_write(mixer->engine.regs, SUN8I_MIXER_BLEND_FCOLOR_CTL, -SUN8I_MIXER_BLEND_FCOLOR_CTL_DEF); + regmap_write(mixer->engine.regs, SUN8I_MIXER_BLEND_PIPE_CTL, +SUN8I_MIXER_BLEND_PIPE_CTL_EN(0) | +SUN8I_MIXER_BLEND_PIPE_CTL_FC_EN(0)); regmap_write(mixer->engine.regs, SUN8I_MIXER_BLEND_ATTR_FCOLOR(0), diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.h b/drivers/gpu/drm/sun4i/sun8i_mixer.h index 9b50733298b8..76f0b2bd91e2 100644 --- a/drivers/gpu/drm/sun4i/sun8i_mixer.h +++ b/drivers/gpu/drm/sun4i/sun8i_mixer.h @@ -16,8 +16,6 @@ #include "sunxi_engine.h" -#define SUN8I_MIXER_MAX_CHAN_COUNT 4 - #define SUN8I_MIXER_SIZE(w, h) (((h) - 1) << 16 | ((w) - 1)) #define SUN8I_MIXER_COORD(x, y)((y) << 16 | (x)) @@ -26,14 +24,14 @@ #define SUN8I_MIXER_GLOBAL_DBUFF 0x8 #define SUN8I_MIXER_GLOBAL_SIZE0xc -#define SUN8I_MIXER_GLOBAL_CTL_RT_EN 0x1 +#define SUN8I_MIXER_GLOBAL_CTL_RT_EN BIT(0) -#define SUN8I_MIXER_GLOBAL_DBUFF_ENABLE0x1 +#define SUN8I_MIXER_GLOBAL_DBUFF_ENABLEBIT(0) -#define SUN8I_MIXER_BLEND_FCOLOR_CTL 0x1000 +#define SUN8I_MIXER_BLEND_PIPE_CTL 0x1000 #define SUN8I_MIXER_BLEND_ATTR_FCOLOR(x) (0x1004 + 0x10 * (x) + 0x0) #define SUN8I_MIXER_BLEND_ATTR_INSIZE(x) (0x1004 + 0x10 * (x) + 0x4) -#define SUN8I_MIXER_BLEND_ATTR_OFFSET(x) (0x1004 + 0x10 * (x) + 0x8) +#define SUN8I_MIXER_BLEND_ATTR_COORD(x)(0x1004 + 0x10 * (x) + 0x8) #define SUN8I_MIXER_BLEND_ROUTE0x1080 #define SUN8I_MIXER_BLEND_PREMULTIPLY 0x1084 #define SUN8I_MIXER_BLEND_BKCOLOR 0x1088 @@ -45,10 +43,11 @@ #define SUN8I_MIXER_BLEND_CK_MIN(x)(0x10e0 + 0x04 * (x)) #define SUN8I_MIXER_BLEND_OUTCTL 0x10fc +#define SUN8I_MIXER_BLEND_PIPE_CTL_EN(pipe)BIT(8 + pipe) +#define SUN8I_MIXER_BLEND_PIPE_CTL_FC_EN(pipe) BIT(pipe) /* colors are always in AARRGGBB format */ #define SUN8I_MIXER_BLEND_COLOR_BLACK 0xff00 /* The following numbers are some still unknown magic numbers */ -#define SUN8I_MIXER_BLEND_FCOLOR_CTL_DEF 0x0101 #define SUN8I_MIXER_BLEND_MODE_DEF 0x03010301 #define SUN8I_MIXER_BLEND_OUTCTL_INTERLACEDBIT(1) -- 2.15.1
[PATCH v2 06/27] drm/sun4i: Explain color macro in DE2 driver
Color attribute have same format troughout the whole driver.
Rename macro, add comment with simple explanation and remove redundant
definitions.
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/sun8i_mixer.c | 8 +---
drivers/gpu/drm/sun4i/sun8i_mixer.h | 4 ++--
2 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c
b/drivers/gpu/drm/sun4i/sun8i_mixer.c
index f4a7fa0ba7ad..5144e6d0ac56 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
@@ -317,17 +317,19 @@ static int sun8i_mixer_bind(struct device *dev, struct
device *master,
regmap_write(mixer->engine.regs, SUN8I_MIXER_GLOBAL_CTL,
SUN8I_MIXER_GLOBAL_CTL_RT_EN);
+ /* Set background color to black */
+ regmap_write(mixer->engine.regs, SUN8I_MIXER_BLEND_BKCOLOR,
+SUN8I_MIXER_BLEND_COLOR_BLACK);
+
/* Initialize blender */
regmap_write(mixer->engine.regs, SUN8I_MIXER_BLEND_FCOLOR_CTL,
SUN8I_MIXER_BLEND_FCOLOR_CTL_DEF);
- regmap_write(mixer->engine.regs, SUN8I_MIXER_BLEND_BKCOLOR,
-SUN8I_MIXER_BLEND_BKCOLOR_DEF);
regmap_write(mixer->engine.regs, SUN8I_MIXER_BLEND_MODE(0),
SUN8I_MIXER_BLEND_MODE_DEF);
regmap_write(mixer->engine.regs,
SUN8I_MIXER_BLEND_ATTR_FCOLOR(0),
-SUN8I_MIXER_BLEND_ATTR_FCOLOR_DEF);
+SUN8I_MIXER_BLEND_COLOR_BLACK);
/* Select the first UI channel */
DRM_DEBUG_DRIVER("Selecting channel %d (first UI channel)\n",
diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.h
b/drivers/gpu/drm/sun4i/sun8i_mixer.h
index db005a4bca43..9b50733298b8 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.h
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.h
@@ -45,10 +45,10 @@
#define SUN8I_MIXER_BLEND_CK_MIN(x)(0x10e0 + 0x04 * (x))
#define SUN8I_MIXER_BLEND_OUTCTL 0x10fc
+/* colors are always in AARRGGBB format */
+#define SUN8I_MIXER_BLEND_COLOR_BLACK 0xff00
/* The following numbers are some still unknown magic numbers */
-#define SUN8I_MIXER_BLEND_ATTR_FCOLOR_DEF 0xff00
#define SUN8I_MIXER_BLEND_FCOLOR_CTL_DEF 0x0101
-#define SUN8I_MIXER_BLEND_BKCOLOR_DEF 0xff00
#define SUN8I_MIXER_BLEND_MODE_DEF 0x03010301
#define SUN8I_MIXER_BLEND_OUTCTL_INTERLACEDBIT(1)
--
2.15.1
Re: [PATCH ipsec] xfrm: fix XFRMA_OUTPUT_MARK policy entry
On Wed, Nov 29, 2017 at 06:23:56PM +0100, Michal Kubecek wrote:
> This seems to be an obvious typo, NLA_U32 is type of the attribute, not its
> (minimal) length.
>
> Fixes: 077fbac405bf ("net: xfrm: support setting an output mark.")
> Signed-off-by: Michal Kubecek
Patch applied, thanks Michal!
Re: [PATCH v3 14/19] x86/entry/64: Create a percpu SYSCALL entry trampoline
On Fri, Nov 24, 2017 at 3:39 AM, David Laight wrote: > From: Andy Lutomirski >> Sent: 24 November 2017 04:33 > ... >> + /* >> + * x86 lacks a near absolute jump, and we can't jump to the real >> + * entry text with a relative jump, so we fake it using retq. >> + */ >> + pushq $entry_SYSCALL_64_after_hwframe >> + retq > > Don't some of the cpus have hardware logic that follows call and return? > The above will break that logic and slow things down (unless it is an > expected sequence). Indeed, and it makes a *huge* difference. > > Is there a scratch register that can be used for an indirect jump? No, but I can fudge it. > > David >
[PATCH net,stable v3] vhost: fix a few skb leaks
From: Wei Xu Matthew found a roughly 40% tcp throughput regression with commit c67df11f(vhost_net: try batch dequing from skb array) as discussed in the following thread: https://www.mail-archive.com/netdev@vger.kernel.org/msg187936.html This is v3. v3: - move freeing skb from vhost to tun/tap recvmsg() to not confuse the callers. v2: - add Matthew as the reporter, thanks matthew. - moving zero headcount check ahead instead of defer consuming skb due to jason and mst's comment. - add freeing skb in favor of recvmsg() fails. Wei Xu (3): vhost: fix skb leak in handle_rx() tun: free skb in early errors tap: free skb if flags error drivers/net/tap.c | 6 +- drivers/net/tun.c | 14 +++--- drivers/vhost/net.c | 20 ++-- 3 files changed, 26 insertions(+), 14 deletions(-) -- 1.8.3.1
[PATCH 2/3] tun: free skb in early errors
From: Wei Xu
tun_recvmsg() supports accepting skb by msg_control after
commit ac77cfd4258f ("tun: support receiving skb through msg_control"),
the skb if presented should be freed within the function, otherwise it
would be leaked.
Signed-off-by: Wei Xu
Reported-by: Matthew Rosato
---
drivers/net/tun.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 6a7bde9..5563430 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -2067,14 +2067,17 @@ static int tun_recvmsg(struct socket *sock, struct
msghdr *m, size_t total_len,
{
struct tun_file *tfile = container_of(sock, struct tun_file, socket);
struct tun_struct *tun = tun_get(tfile);
+ struct sk_buff *skb = m->msg_control;
int ret;
- if (!tun)
- return -EBADFD;
+ if (!tun) {
+ ret = -EBADFD;
+ goto out_free_skb;
+ }
if (flags & ~(MSG_DONTWAIT|MSG_TRUNC|MSG_ERRQUEUE)) {
ret = -EINVAL;
- goto out;
+ goto out_free_skb;
}
if (flags & MSG_ERRQUEUE) {
ret = sock_recv_errqueue(sock->sk, m, total_len,
@@ -2087,6 +2090,11 @@ static int tun_recvmsg(struct socket *sock, struct
msghdr *m, size_t total_len,
m->msg_flags |= MSG_TRUNC;
ret = flags & MSG_TRUNC ? ret : total_len;
}
+ goto out;
+
+out_free_skb:
+ if (skb)
+ kfree_skb(skb);
out:
tun_put(tun);
return ret;
--
1.8.3.1
[PATCH 1/3] vhost: fix skb leak in handle_rx()
From: Wei Xu
Matthew found a roughly 40% tcp throughput regression with commit
c67df11f(vhost_net: try batch dequing from skb array) as discussed
in the following thread:
https://www.mail-archive.com/netdev@vger.kernel.org/msg187936.html
Eventually we figured out that it was a skb leak in handle_rx()
when sending packets to the VM. This usually happens when a guest
can not drain out vq as fast as vhost fills in, afterwards it sets
off the traffic jam and leaks skb(s) which occurs as no headcount
to send on the vq from vhost side.
This can be avoided by making sure we have got enough headcount
before actually consuming a skb from the batched rx array while
transmitting, which is simply done by moving checking the zero
headcount a bit ahead.
Signed-off-by: Wei Xu
Reported-by: Matthew Rosato
---
drivers/vhost/net.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index 8d626d7..c7bdeb6 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -778,16 +778,6 @@ static void handle_rx(struct vhost_net *net)
/* On error, stop handling until the next kick. */
if (unlikely(headcount < 0))
goto out;
- if (nvq->rx_array)
- msg.msg_control = vhost_net_buf_consume(&nvq->rxq);
- /* On overrun, truncate and discard */
- if (unlikely(headcount > UIO_MAXIOV)) {
- iov_iter_init(&msg.msg_iter, READ, vq->iov, 1, 1);
- err = sock->ops->recvmsg(sock, &msg,
-1, MSG_DONTWAIT | MSG_TRUNC);
- pr_debug("Discarded rx packet: len %zd\n", sock_len);
- continue;
- }
/* OK, now we need to know about added descriptors. */
if (!headcount) {
if (unlikely(vhost_enable_notify(&net->dev, vq))) {
@@ -800,6 +790,16 @@ static void handle_rx(struct vhost_net *net)
* they refilled. */
goto out;
}
+ if (nvq->rx_array)
+ msg.msg_control = vhost_net_buf_consume(&nvq->rxq);
+ /* On overrun, truncate and discard */
+ if (unlikely(headcount > UIO_MAXIOV)) {
+ iov_iter_init(&msg.msg_iter, READ, vq->iov, 1, 1);
+ err = sock->ops->recvmsg(sock, &msg,
+1, MSG_DONTWAIT | MSG_TRUNC);
+ pr_debug("Discarded rx packet: len %zd\n", sock_len);
+ continue;
+ }
/* We don't need to be notified again. */
iov_iter_init(&msg.msg_iter, READ, vq->iov, in, vhost_len);
fixup = msg.msg_iter;
--
1.8.3.1
[PATCH 3/3] tap: free skb if flags error
From: Wei Xu
tap_recvmsg() supports accepting skb by msg_control after
commit 3b4ba04acca8 ("tap: support receiving skb from msg_control"),
the skb if presented should be freed within the function, otherwise
it would be leaked.
Signed-off-by: Wei Xu
Reported-by: Matthew Rosato
---
drivers/net/tap.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/net/tap.c b/drivers/net/tap.c
index e9489b8..1c66b75 100644
--- a/drivers/net/tap.c
+++ b/drivers/net/tap.c
@@ -1154,9 +1154,13 @@ static int tap_recvmsg(struct socket *sock, struct
msghdr *m,
size_t total_len, int flags)
{
struct tap_queue *q = container_of(sock, struct tap_queue, sock);
+ struct sk_buff *skb = m->msg_control;
int ret;
- if (flags & ~(MSG_DONTWAIT|MSG_TRUNC))
+ if (flags & ~(MSG_DONTWAIT|MSG_TRUNC)) {
+ if (skb)
+ kfree_skb(skb);
return -EINVAL;
+ }
ret = tap_do_read(q, &m->msg_iter, flags & MSG_DONTWAIT,
m->msg_control);
if (ret > total_len) {
--
1.8.3.1
