Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v3 01/26] drm/bridge: allow optionally specifying an owner .odev device
From: Peter Rosin @ 2018-05-16 10:14 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20180516101510.13215-1-peda@axentia.se>

Bridge drivers can now (temporarily, in a transition phase) select if
they want to provide a full owner device or keep just providing an
of_node.

By providing a full owner device, the bridge drivers no longer need
to provide an of_node since that node is available via the owner
device.

When all bridge drivers provide an owner device, that will become
mandatory and the .of_node member will be removed.

There is an interaction with the rockchip lvds driver, since that
driver peeks into somewhat private parts of the bridge struct in
order to find out things about the remote bridge. When there are
now two ways to get to the remote bridge, the rockchip lvds driver
has to adapt. That said, the correct thing to do for the rockchip
lvds driver is to use some other way than DT to find things out
about the remote bridge, but that is orthogonal to this patch.

Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Peter Rosin <peda@axentia.se>
---
 drivers/gpu/drm/drm_bridge.c             | 3 ++-
 drivers/gpu/drm/rockchip/rockchip_lvds.c | 4 +++-
 include/drm/drm_bridge.h                 | 2 ++
 3 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index 1638bfe9627c..3872f5379998 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -365,7 +365,8 @@ struct drm_bridge *of_drm_find_bridge(struct device_node *np)
 	mutex_lock(&bridge_lock);
 
 	list_for_each_entry(bridge, &bridge_list, list) {
-		if (bridge->of_node == np) {
+		if ((bridge->odev && bridge->odev->of_node == np) ||
+		    bridge->of_node == np) {
 			mutex_unlock(&bridge_lock);
 			return bridge;
 		}
diff --git a/drivers/gpu/drm/rockchip/rockchip_lvds.c b/drivers/gpu/drm/rockchip/rockchip_lvds.c
index 4bd94b167d2c..557e0079c98d 100644
--- a/drivers/gpu/drm/rockchip/rockchip_lvds.c
+++ b/drivers/gpu/drm/rockchip/rockchip_lvds.c
@@ -377,8 +377,10 @@ static int rockchip_lvds_bind(struct device *dev, struct device *master,
 	}
 	if (lvds->panel)
 		remote = lvds->panel->dev->of_node;
-	else
+	else if (lvds->bridge->of_node)
 		remote = lvds->bridge->of_node;
+	else
+		remote = lvds->bridge->odev->of_node;
 	if (of_property_read_string(dev->of_node, "rockchip,output", &name))
 		/* default set it as output rgb */
 		lvds->output = DISPLAY_OUTPUT_RGB;
diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index 3270fec46979..7c17977c3537 100644
--- a/include/drm/drm_bridge.h
+++ b/include/drm/drm_bridge.h
@@ -254,6 +254,7 @@ struct drm_bridge_timings {
 
 /**
  * struct drm_bridge - central DRM bridge control structure
+ * @odev: device that owns the bridge
  * @dev: DRM device this bridge belongs to
  * @encoder: encoder to which this bridge is connected
  * @next: the next bridge in the encoder chain
@@ -265,6 +266,7 @@ struct drm_bridge_timings {
  * @driver_private: pointer to the bridge driver's internal context
  */
 struct drm_bridge {
+	struct device *odev;
 	struct drm_device *dev;
 	struct drm_encoder *encoder;
 	struct drm_bridge *next;
-- 
2.11.0

^ permalink raw reply related

* [PATCH v3 00/26] device link, bridge supplier <-> drm device
From: Peter Rosin @ 2018-05-16 10:14 UTC (permalink / raw)
  To: linux-arm-kernel

Hi!

It was noted by Russell King [1] that bridges (not using components)
might disappear unexpectedly if the owner of the bridge was unbound.
Jyri Sarha had previously noted the same thing with panels [2]. Jyri
came up with using device links to resolve the panel issue, which
was also my (independent) reaction to the note from Russell.

This series builds up to the addition of that link in the last
patch, but in my opinion the other 25 patches do have merit on their
own.

The last patch needs testing, while the others look trivial. Jyri, are
you able to test? That said, I might have missed some subtlety.

Oh, and the reason I'm pushing this is of course so that the issue
noted by Russell in [1] is addressed which in turn means that the
tda998x bridge driver can be patched according to that series without
objection (hopefully) and then used from the atmel-hlcdc driver (and
other drivers that are not componentized).

Changes since v2    https://lkml.org/lkml/2018/5/4/443

- Russell King spells his name this way. Sorry!
- Add review tag from Andrzej Hajda (patches 1, 25 and 26).
- Add ack tag from Daniel Vetter (patches 1, 24, 25 and 26).
- Mention the interaction with the rockchip_lvds driver in the
  commit message for patch 1.
- Change the comment for the new @link member in patch 26, so that a
  symmetric relationchip between cunsumer/supplier isn't implied.

Changes since v1    https://lkml.org/lkml/2018/4/26/1018

- rename .owner to .odev to not get mixed up with the module owner.
- added patches for new recent drivers thc63lvd1024 and cdns-dsi
- fix for problem in the rockchip_lvds driver reported by 0day
- added a WARN in drm_bridge_add if there is no .odev owner device

Cheers,
Peter

[1] https://lkml.org/lkml/2018/4/23/769
[2] https://www.spinics.net/lists/dri-devel/msg174275.html

Peter Rosin (26):
  drm/bridge: allow optionally specifying an owner .odev device
  drm/bridge: adv7511: provide an owner .odev device
  drm/bridge/analogix: core: specify the owner .odev of the bridge
  drm/bridge: analogix-anx78xx: provide an owner .odev device
  drm/bridge: cdns-dsi: provide an owner .odev device
  drm/bridge: vga-dac: provide an owner .odev device
  drm/bridge: lvds-encoder: provide an owner .odev device
  drm/bridge: megachips-stdpxxxx-ge-b850v3-fw: provide an owner .odev
    device
  drm/bridge: nxp-ptn3460: provide an owner .odev device
  drm/bridge: panel: provide an owner .odev device
  drm/bridge: ps8622: provide an owner .odev device
  drm/bridge: sii902x: provide an owner .odev device
  drm/bridge: sii9234: provide an owner .odev device
  drm/bridge: sii8620: provide an owner .odev device
  drm/bridge: synopsys: provide an owner .odev device for the bridges
  drm/bridge: tc358767: provide an owner .odev device
  drm/bridge: thc63lvd1024: provide an owner .odev device
  drm/bridge: ti-tfp410: provide an owner .odev device
  drm/exynos: mic: provide an owner .odev device for the bridge
  drm/mediatek: hdmi: provide an owner .odev device for the bridge
  drm/msm: specify the owner .odev of the bridges
  drm/rcar-du: lvds: provide an owner .odev device for the bridge
  drm/sti: provide an owner .odev device for the bridges
  drm/bridge: remove the .of_node member
  drm/bridge: require the owner .odev to be filled in on
    drm_bridge_add/attach
  drm/bridge: establish a link between the bridge supplier and consumer

 drivers/gpu/drm/bridge/adv7511/adv7511_drv.c       |  2 +-
 drivers/gpu/drm/bridge/analogix-anx78xx.c          |  5 +----
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c |  1 +
 drivers/gpu/drm/bridge/cdns-dsi.c                  |  2 +-
 drivers/gpu/drm/bridge/dumb-vga-dac.c              |  2 +-
 drivers/gpu/drm/bridge/lvds-encoder.c              |  2 +-
 .../drm/bridge/megachips-stdpxxxx-ge-b850v3-fw.c   |  2 +-
 drivers/gpu/drm/bridge/nxp-ptn3460.c               |  2 +-
 drivers/gpu/drm/bridge/panel.c                     |  4 +---
 drivers/gpu/drm/bridge/parade-ps8622.c             |  2 +-
 drivers/gpu/drm/bridge/sii902x.c                   |  2 +-
 drivers/gpu/drm/bridge/sii9234.c                   |  2 +-
 drivers/gpu/drm/bridge/sil-sii8620.c               |  2 +-
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c          |  4 +---
 drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c      |  4 +---
 drivers/gpu/drm/bridge/tc358767.c                  |  2 +-
 drivers/gpu/drm/bridge/thc63lvd1024.c              |  2 +-
 drivers/gpu/drm/bridge/ti-tfp410.c                 |  2 +-
 drivers/gpu/drm/drm_bridge.c                       | 26 +++++++++++++++++++++-
 drivers/gpu/drm/exynos/exynos_drm_mic.c            |  2 +-
 drivers/gpu/drm/mediatek/mtk_hdmi.c                |  2 +-
 drivers/gpu/drm/msm/dsi/dsi_manager.c              |  1 +
 drivers/gpu/drm/msm/edp/edp_bridge.c               |  1 +
 drivers/gpu/drm/msm/hdmi/hdmi_bridge.c             |  1 +
 drivers/gpu/drm/rcar-du/rcar_lvds.c                |  2 +-
 drivers/gpu/drm/rockchip/rockchip_lvds.c           |  2 +-
 drivers/gpu/drm/sti/sti_dvo.c                      |  2 +-
 drivers/gpu/drm/sti/sti_hda.c                      |  1 +
 drivers/gpu/drm/sti/sti_hdmi.c                     |  1 +
 include/drm/drm_bridge.h                           |  8 +++----
 30 files changed, 57 insertions(+), 36 deletions(-)

-- 
2.11.0

^ permalink raw reply

* [PATCH 2/4] ARM: davinci: board-da850-evm: fix GPIO lookup for MMC/SD
From: Sekhar Nori @ 2018-05-16 10:14 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CAHCN7x+eNpeyv27WPqZyy-X9S7Ffvujo+y3Mmt1ZP=LEk+4+=g@mail.gmail.com>

On Wednesday 16 May 2018 04:23 AM, Adam Ford wrote:
> On Thu, Apr 26, 2018 at 8:40 PM, David Lechner <david@lechnology.com> wrote:
>> On 04/24/2018 09:35 AM, Sekhar Nori wrote:
>>>
>>> The GPIO chip is called davinci_gpio.0 in legacy mode. Fix it, so that
>>> mmc can correctly lookup the wp and cp gpios. Also fix the GPIO numbers
>>> as they are not offsets within a bank.
>>>
>>> Note that it is the gpio-davinci driver that sets the gpiochip label to
>>> davinci_gpio.0.
>>>
>>> Fixes: bdf0e8364fd3 ("ARM: davinci: da850-evm: use gpio descriptor for mmc
>>> pins")
>>> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
>>> ---
>>>   arch/arm/mach-davinci/board-da850-evm.c | 9 +++++++--
>>>   1 file changed, 7 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-davinci/board-da850-evm.c
>>> b/arch/arm/mach-davinci/board-da850-evm.c
>>> index 3063478bcc36..158ed9a1483f 100644
>>> --- a/arch/arm/mach-davinci/board-da850-evm.c
>>> +++ b/arch/arm/mach-davinci/board-da850-evm.c
>>> @@ -763,12 +763,17 @@ static const short da850_evm_mcasp_pins[]
>>> __initconst = {
>>>         -1
>>>   };
>>>   +#define DA850_MMCSD_CD_PIN           GPIO_TO_PIN(4, 0)
>>> +#define DA850_MMCSD_WP_PIN             GPIO_TO_PIN(4, 1)
>>> +
>>>   static struct gpiod_lookup_table mmc_gpios_table = {
>>>         .dev_id = "da830-mmc.0",
>>>         .table = {
>>>                 /* gpio chip 2 contains gpio range 64-95 */
>>> -               GPIO_LOOKUP("davinci_gpio.2", 0, "cd", GPIO_ACTIVE_LOW),
>>> -               GPIO_LOOKUP("davinci_gpio.2", 1, "wp", GPIO_ACTIVE_LOW),
>>> +               GPIO_LOOKUP("davinci_gpio.0", DA850_MMCSD_CD_PIN, "cd",
>>> +                           GPIO_ACTIVE_LOW),
>>> +               GPIO_LOOKUP("davinci_gpio.0", DA850_MMCSD_WP_PIN, "wp",
>>> +                           GPIO_ACTIVE_LOW),
> 
> I don't think the WP polarity is working correctly.  If I boot the
> board 'rw' enabled but WP disabled on the SD card, the system crashes.
> If I enable WP, the board boots correctly.
> 
> Comparing this to the device tree version that I did, and double
> checking the behavior for my sanity, I believe WP needs to be
> GPIO_ACTIVE_HIGH

You are right, I see the issue on my board too. Although this patch did
not touch the polarity, we could have fixed it here.

Anyway, do you want to send a patch for that? Or I can do it too. A
similar fix is needed for DA830 EVM too.

Thanks,
Sekhar

^ permalink raw reply

* [RESEND PATCH v5 0/6] Add support for PWM input capture on STM32
From: Lee Jones @ 2018-05-16 10:13 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <c48acc96-1eca-9adc-abb7-131921305ee8@st.com>

On Wed, 16 May 2018, Fabrice Gasnier wrote:

> On 05/16/2018 10:06 AM, Lee Jones wrote:
> > On Wed, 16 May 2018, Fabrice Gasnier wrote:
> > 
> >> This series adds support for capture to stm32-pwm driver.
> >> Capture is based on DMAs.
> >> - First two patches add support for requesting DMAs to MFD core
> >> - Next three patches add support for capture to stm32-pwm driver
> >> - This has been tested on stm32429i-eval board.
> >>
> >> ---
> >> Changes in v5:
> >> - update patch 2 (mfd: stm32-timers: add support for dmas)
> >>   move stm32_timers_dma struct to header file,
> >>   fix warning on dma_mapping_error().
> >>
> >> Changes in v4:
> >> - Lee's comments on patch 2 (mfd: stm32-timers: add support for dmas)
> >>   Add kerneldoc header, better format comments.
> >>
> >> Changes in v3:
> >> - Dropped 2 precusor patches applied by Thierry in pwm tree:
> >>   "pwm: stm32: fix, remove unused struct device"
> >>   "pwm: stm32: protect common prescaler for all channels"
> >> - Note: this series applies on top on pwm tree
> >> - Implements Lee's comments on MFD part: rework stm32_timers_dma struct,
> >>   exported routine prototype now use generic device struct, more
> >>   various comments (see patch 2 changelog).
> >>
> >> Resend v2:
> >> - Add collected Acks
> >>
> >> Changes in v2:
> >> - Abstract DMA handling from child driver: move it to MFD core
> >> - Rework pwm capture routines to adopt this change
> >> - Comment on optional dma support, beautify DMAs probe
> >>
> >> Fabrice Gasnier (6):
> >>   dt-bindings: mfd: stm32-timers: add support for dmas
> >>   mfd: stm32-timers: add support for dmas
> >>   pwm: stm32: add capture support
> >>   pwm: stm32: improve capture by tuning counter prescaler
> >>   pwm: stm32: use input prescaler to improve period capture
> >>   ARM: dts: stm32: Enable pwm3 input capture on stm32f429i-eval
> > 
> > Applied patches 1-5.
> 
> Many thanks Lee !
> 
> Maybe I missed something, but just in case...
> In your pull request ("[GIT PULL] Immutable branch between MFD and PWM
> due for the v4.18 merge window") I only see 4 patches:
> Fabrice Gasnier (4):
>       mfd: stm32-timers: Add support for DMAs
>       pwm: stm32: Add capture support
>       pwm: stm32: Improve capture by tuning counter prescaler
>       pwm: stm32: Use input prescaler to improve period capture
> 
> I can't see patch 1 ("dt-bindings: mfd: stm32-timers: add support for dmas")
> Is it applied on another tree ?

Good spot.

Looks like a fumbled the key combination for the bindings patch.

Pull-request to follow.

> >>  .../devicetree/bindings/mfd/stm32-timers.txt       |  20 ++
> >>  arch/arm/boot/dts/stm32429i-eval.dts               |   3 +
> >>  drivers/mfd/stm32-timers.c                         | 201 +++++++++++++++-
> >>  drivers/pwm/pwm-stm32.c                            | 257 +++++++++++++++++++++
> >>  include/linux/mfd/stm32-timers.h                   |  58 +++++
> >>  5 files changed, 537 insertions(+), 2 deletions(-)
> >>
> > 

-- 
Lee Jones [???]
Linaro Services Technical Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

^ permalink raw reply

* [PATCH v9 07/11] arm64: kexec_file: add crash dump support
From: James Morse @ 2018-05-16 10:06 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <f8d8305d-42f5-e1e2-20c4-733cb38cbb8d@arm.com>

Hi Akashi,

On 15/05/18 18:11, James Morse wrote:
> On 25/04/18 07:26, AKASHI Takahiro wrote:
>> Enabling crash dump (kdump) includes
>> * prepare contents of ELF header of a core dump file, /proc/vmcore,
>>   using crash_prepare_elf64_headers(), and
>> * add two device tree properties, "linux,usable-memory-range" and
>>   "linux,elfcorehdr", which represent repsectively a memory range
>>   to be used by crash dump kernel and the header's location

>> diff --git a/arch/arm64/kernel/machine_kexec_file.c b/arch/arm64/kernel/machine_kexec_file.c
>> index 37c0a9dc2e47..ec674f4d267c 100644
>> --- a/arch/arm64/kernel/machine_kexec_file.c
>> +++ b/arch/arm64/kernel/machine_kexec_file.c

>> +static struct crash_mem *get_crash_memory_ranges(void)
>> +{
>> +	unsigned int nr_ranges;
>> +	struct crash_mem *cmem;
>> +
>> +	nr_ranges = 1; /* for exclusion of crashkernel region */
>> +	walk_system_ram_res(0, -1, &nr_ranges, get_nr_ranges_callback);
>> +
>> +	cmem = vmalloc(sizeof(struct crash_mem) +
>> +			sizeof(struct crash_mem_range) * nr_ranges);
>> +	if (!cmem)
>> +		return NULL;
>> +
>> +	cmem->max_nr_ranges = nr_ranges;
>> +	cmem->nr_ranges = 0;
>> +	walk_system_ram_res(0, -1, cmem, add_mem_range_callback);
>> +
>> +	/* Exclude crashkernel region */
>> +	if (crash_exclude_mem_range(cmem, crashk_res.start, crashk_res.end)) {
>> +		vfree(cmem);
>> +		return NULL;
>> +	}
>> +
>> +	return cmem;
>> +}
> 
> Could this function be included in prepare_elf_headers() so that the alloc() and
> free() occur together.
> 
> 
>> +static int prepare_elf_headers(void **addr, unsigned long *sz)
>> +{
>> +	struct crash_mem *cmem;
>> +	int ret = 0;
>> +
>> +	cmem = get_crash_memory_ranges();
>> +	if (!cmem)
>> +		return -ENOMEM;
>> +
>> +	ret =  crash_prepare_elf64_headers(cmem, true, addr, sz);
>> +
>> +	vfree(cmem);
> 
>> +	return ret;
>> +}
> 
> All this is moving memory-range information from core-code's
> walk_system_ram_res() into core-code's struct crash_mem, and excluding
> crashk_res, which again is accessible to the core code.
> 
> It looks like this is duplicated in arch/x86 and arch/arm64 because arm64
> doesn't have a second 'crashk_low_res' region, and always wants elf64, instead
> of when IS_ENABLED(CONFIG_X86_64).

Thinking about it some more: don't we want to walk memblock here, not
walk_system_ram_res()? What we want is a list of not-nomap regions that the
kernel may have been using, to form part of vmcore.
walk_system_ram_res() is becoming a murkier list of maybe-nomap, maybe-reserved.

I think we should walk the same list here as we do in patch 4.


Thanks,

James

^ permalink raw reply

* [PATCH 10/14] vgem: separate errno from VM_FAULT_* values
From: Daniel Vetter @ 2018-05-16  9:53 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20180516054348.15950-11-hch@lst.de>

On Wed, May 16, 2018 at 07:43:44AM +0200, Christoph Hellwig wrote:
> And streamline the code in vgem_fault with early returns so that it is
> a little bit more readable.
> 
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>  drivers/gpu/drm/vgem/vgem_drv.c | 51 +++++++++++++++------------------
>  1 file changed, 23 insertions(+), 28 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
> index 2524ff116f00..a261e0aab83a 100644
> --- a/drivers/gpu/drm/vgem/vgem_drv.c
> +++ b/drivers/gpu/drm/vgem/vgem_drv.c
> @@ -61,12 +61,13 @@ static void vgem_gem_free_object(struct drm_gem_object *obj)
>  	kfree(vgem_obj);
>  }
>  
> -static int vgem_gem_fault(struct vm_fault *vmf)
> +static vm_fault_t vgem_gem_fault(struct vm_fault *vmf)
>  {
>  	struct vm_area_struct *vma = vmf->vma;
>  	struct drm_vgem_gem_object *obj = vma->vm_private_data;
>  	/* We don't use vmf->pgoff since that has the fake offset */
>  	unsigned long vaddr = vmf->address;
> +	struct page *page;
>  	int ret;
>  	loff_t num_pages;
>  	pgoff_t page_offset;
> @@ -85,35 +86,29 @@ static int vgem_gem_fault(struct vm_fault *vmf)
>  		ret = 0;
>  	}
>  	mutex_unlock(&obj->pages_lock);
> -	if (ret) {
> -		struct page *page;
> -
> -		page = shmem_read_mapping_page(
> -					file_inode(obj->base.filp)->i_mapping,
> -					page_offset);
> -		if (!IS_ERR(page)) {
> -			vmf->page = page;
> -			ret = 0;
> -		} else switch (PTR_ERR(page)) {
> -			case -ENOSPC:
> -			case -ENOMEM:
> -				ret = VM_FAULT_OOM;
> -				break;
> -			case -EBUSY:
> -				ret = VM_FAULT_RETRY;
> -				break;
> -			case -EFAULT:
> -			case -EINVAL:
> -				ret = VM_FAULT_SIGBUS;
> -				break;
> -			default:
> -				WARN_ON(PTR_ERR(page));
> -				ret = VM_FAULT_SIGBUS;
> -				break;
> -		}
> +	if (!ret)
> +		return 0;
> +
> +	page = shmem_read_mapping_page(file_inode(obj->base.filp)->i_mapping,
> +			page_offset);
> +	if (!IS_ERR(page)) {
> +		vmf->page = page;
> +		return 0;
> +	}
>  
> +	switch (PTR_ERR(page)) {
> +	case -ENOSPC:
> +	case -ENOMEM:
> +		return VM_FAULT_OOM;
> +	case -EBUSY:
> +		return VM_FAULT_RETRY;
> +	case -EFAULT:
> +	case -EINVAL:
> +		return VM_FAULT_SIGBUS;
> +	default:
> +		WARN_ON(PTR_ERR(page));
> +		return VM_FAULT_SIGBUS;
>  	}
> -	return ret;

Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Want me to merge this through drm-misc or plan to pick it up yourself?
-Daniel

>  }
>  
>  static const struct vm_operations_struct vgem_gem_vm_ops = {
> -- 
> 2.17.0
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

^ permalink raw reply

* [PATCH] arm64: dts: move berlin SoC files from marvell dir to synaptics dir
From: Jisheng Zhang @ 2018-05-16  9:51 UTC (permalink / raw)
  To: linux-arm-kernel

Move device tree files as part of transition from Marvell berlin to
Synaptics berlin.

Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
---
 arch/arm64/boot/dts/Makefile                                 | 1 +
 arch/arm64/boot/dts/marvell/Makefile                         | 4 ----
 arch/arm64/boot/dts/synaptics/Makefile                       | 4 ++++
 arch/arm64/boot/dts/{marvell => synaptics}/berlin4ct-dmp.dts | 0
 arch/arm64/boot/dts/{marvell => synaptics}/berlin4ct-stb.dts | 0
 arch/arm64/boot/dts/{marvell => synaptics}/berlin4ct.dtsi    | 0
 6 files changed, 5 insertions(+), 4 deletions(-)
 create mode 100644 arch/arm64/boot/dts/synaptics/Makefile
 rename arch/arm64/boot/dts/{marvell => synaptics}/berlin4ct-dmp.dts (100%)
 rename arch/arm64/boot/dts/{marvell => synaptics}/berlin4ct-stb.dts (100%)
 rename arch/arm64/boot/dts/{marvell => synaptics}/berlin4ct.dtsi (100%)

diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
index 4aa50b9b26bc..3543bc324553 100644
--- a/arch/arm64/boot/dts/Makefile
+++ b/arch/arm64/boot/dts/Makefile
@@ -22,5 +22,6 @@ subdir-y += renesas
 subdir-y += rockchip
 subdir-y += socionext
 subdir-y += sprd
+subdir-y += synaptics
 subdir-y += xilinx
 subdir-y += zte
diff --git a/arch/arm64/boot/dts/marvell/Makefile b/arch/arm64/boot/dts/marvell/Makefile
index cb454beede55..ea9d49f2a911 100644
--- a/arch/arm64/boot/dts/marvell/Makefile
+++ b/arch/arm64/boot/dts/marvell/Makefile
@@ -1,8 +1,4 @@
 # SPDX-License-Identifier: GPL-2.0
-# Berlin SoC Family
-dtb-$(CONFIG_ARCH_BERLIN) += berlin4ct-dmp.dtb
-dtb-$(CONFIG_ARCH_BERLIN) += berlin4ct-stb.dtb
-
 # Mvebu SoC Family
 dtb-$(CONFIG_ARCH_MVEBU) += armada-3720-db.dtb
 dtb-$(CONFIG_ARCH_MVEBU) += armada-3720-espressobin.dtb
diff --git a/arch/arm64/boot/dts/synaptics/Makefile b/arch/arm64/boot/dts/synaptics/Makefile
new file mode 100644
index 000000000000..de71ddda6835
--- /dev/null
+++ b/arch/arm64/boot/dts/synaptics/Makefile
@@ -0,0 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0
+# Berlin SoC Family
+dtb-$(CONFIG_ARCH_BERLIN) += berlin4ct-dmp.dtb
+dtb-$(CONFIG_ARCH_BERLIN) += berlin4ct-stb.dtb
diff --git a/arch/arm64/boot/dts/marvell/berlin4ct-dmp.dts b/arch/arm64/boot/dts/synaptics/berlin4ct-dmp.dts
similarity index 100%
rename from arch/arm64/boot/dts/marvell/berlin4ct-dmp.dts
rename to arch/arm64/boot/dts/synaptics/berlin4ct-dmp.dts
diff --git a/arch/arm64/boot/dts/marvell/berlin4ct-stb.dts b/arch/arm64/boot/dts/synaptics/berlin4ct-stb.dts
similarity index 100%
rename from arch/arm64/boot/dts/marvell/berlin4ct-stb.dts
rename to arch/arm64/boot/dts/synaptics/berlin4ct-stb.dts
diff --git a/arch/arm64/boot/dts/marvell/berlin4ct.dtsi b/arch/arm64/boot/dts/synaptics/berlin4ct.dtsi
similarity index 100%
rename from arch/arm64/boot/dts/marvell/berlin4ct.dtsi
rename to arch/arm64/boot/dts/synaptics/berlin4ct.dtsi
-- 
2.17.0

^ permalink raw reply related

* [PATCH v2 26/26] drm/bridge: establish a link between the bridge supplier and consumer
From: Daniel Vetter @ 2018-05-16  9:31 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <f8215ba1-4cdb-69b9-39ff-68feca3ec502@axentia.se>

On Tue, May 15, 2018 at 01:09:59PM +0200, Peter Rosin wrote:
> On 2018-05-15 12:22, Daniel Vetter wrote:
> > On Mon, May 14, 2018 at 10:40 PM, Peter Rosin <peda@axentia.se> wrote:
> >> On 2018-05-14 18:28, Daniel Vetter wrote:
> >>> On Fri, May 11, 2018 at 09:37:47AM +0200, Peter Rosin wrote:
> >>>> On 2018-05-10 10:10, Andrzej Hajda wrote:
> >>>>> On 04.05.2018 15:52, Peter Rosin wrote:
> >>>>>> If the bridge supplier is unbound, this will bring the bridge consumer
> >>>>>> down along with the bridge. Thus, there will no longer linger any
> >>>>>> dangling pointers from the bridge consumer (the drm_device) to some
> >>>>>> non-existent bridge supplier.
> >>>>>>
> >>>>>> Signed-off-by: Peter Rosin <peda@axentia.se>
> >>>>>> ---
> >>>>>>  drivers/gpu/drm/drm_bridge.c | 18 ++++++++++++++++++
> >>>>>>  include/drm/drm_bridge.h     |  2 ++
> >>>>>>  2 files changed, 20 insertions(+)
> >>>>>>
> >>>>>> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> >>>>>> index 78d186b6831b..0259f0a3ff27 100644
> >>>>>> --- a/drivers/gpu/drm/drm_bridge.c
> >>>>>> +++ b/drivers/gpu/drm/drm_bridge.c
> >>>>>> @@ -26,6 +26,7 @@
> >>>>>>  #include <linux/mutex.h>
> >>>>>>
> >>>>>>  #include <drm/drm_bridge.h>
> >>>>>> +#include <drm/drm_device.h>
> >>>>>>  #include <drm/drm_encoder.h>
> >>>>>>
> >>>>>>  #include "drm_crtc_internal.h"
> >>>>>> @@ -127,12 +128,25 @@ int drm_bridge_attach(struct drm_encoder *encoder, struct drm_bridge *bridge,
> >>>>>>    if (bridge->dev)
> >>>>>>            return -EBUSY;
> >>>>>>
> >>>>>> +  if (encoder->dev->dev != bridge->odev) {
> >>>>>
> >>>>> I wonder why device_link_add does not handle this case (self dependency)
> >>>>> silently as noop, as it seems to be a correct behavior.
> >>>>
> >>>> It's kind-of a silly corner-case though, so perfectly understandable
> >>>> that it isn't handled.
> >>>>
> >>>>>> +          bridge->link = device_link_add(encoder->dev->dev,
> >>>>>> +                                         bridge->odev, 0);
> >>>>>> +          if (!bridge->link) {
> >>>>>> +                  dev_err(bridge->odev, "failed to link bridge to %s\n",
> >>>>>> +                          dev_name(encoder->dev->dev));
> >>>>>> +                  return -EINVAL;
> >>>>>> +          }
> >>>>>> +  }
> >>>>>> +
> >>>>>>    bridge->dev = encoder->dev;
> >>>>>>    bridge->encoder = encoder;
> >>>>>>
> >>>>>>    if (bridge->funcs->attach) {
> >>>>>>            ret = bridge->funcs->attach(bridge);
> >>>>>>            if (ret < 0) {
> >>>>>> +                  if (bridge->link)
> >>>>>> +                          device_link_del(bridge->link);
> >>>>>> +                  bridge->link = NULL;
> >>>>>>                    bridge->dev = NULL;
> >>>>>>                    bridge->encoder = NULL;
> >>>>>>                    return ret;
> >>>>>> @@ -159,6 +173,10 @@ void drm_bridge_detach(struct drm_bridge *bridge)
> >>>>>>    if (bridge->funcs->detach)
> >>>>>>            bridge->funcs->detach(bridge);
> >>>>>>
> >>>>>> +  if (bridge->link)
> >>>>>> +          device_link_del(bridge->link);
> >>>>>> +  bridge->link = NULL;
> >>>>>> +
> >>>>>>    bridge->dev = NULL;
> >>>>>>  }
> >>>>>>
> >>>>>> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
> >>>>>> index b656e505d11e..804189c63a4c 100644
> >>>>>> --- a/include/drm/drm_bridge.h
> >>>>>> +++ b/include/drm/drm_bridge.h
> >>>>>> @@ -261,6 +261,7 @@ struct drm_bridge_timings {
> >>>>>>   * @list: to keep track of all added bridges
> >>>>>>   * @timings: the timing specification for the bridge, if any (may
> >>>>>>   * be NULL)
> >>>>>> + * @link: drm consumer <-> bridge supplier
> >>>>>
> >>>>> Nitpick: "<->" suggests symmetry, maybe "device link from drm consumer
> >>>>> to the bridge" would be better.
> >>>>
> >>>> I meant "<->" to indicate that the link is bidirectional, not that the
> >>>> relationship is in any way symmetric. I wasn't aware of any implication
> >>>> of a symmetric relationship when using "<->", do you have a reference?
> >>>> But I guess the different arrow notations in math are somewhat overloaded
> >>>> and that someone at some point must have used "<->" to indicate a
> >>>> symmetric relationship...
> >>>
> >>> Yeah I agree with Andrzej here, for me <-> implies a symmetric
> >>> relationship. Spelling it out like Andrzej suggested sounds like the
> >>> better idea.
> >>> -Daniel
> >>
> >> Ok, I guess that means I have to do a v3 after all. Or can this
> >> trivial documentation update be done by the committer? I hate to
> >> spam everyone with another volley...
> >>
> >> Or perhaps I should squash patches 2-23 that are all rather similar
> >> and mechanic? I separated them to allow for easier review from
> >> individual driver maintainers, but that didn't seem to happen
> >> anyway...
> > 
> > Do another volley of the full set, or in-reply-to to just replace the
> > patch that needs to be respun (but some people don't like that).
> > 
> > When resending just make sure you're picking up all the acks/r-bs you
> > have already.
> 
> Right, I always try to do that. One Ack that I did not include in v2
> was the one you had on v1 24/24 (i.e. this patch). The reason I did
> not add your Ack for v2 even on the patch where it obviously applied
> was that I didn't know if you'd barf on the odev name.
> 
> But it was (and still is) a bit unclear if that was on Ack on the
> last patch only, or if it was for the whole series? I think it might
> have been for the whole series, but I'm not sure and I hate to be a
> presumptuous idiot...

Ack on the overall concept, and I'm ok with odev too. But definitely get
acks from relevant people (bridge/driver maintainers). In terms of
patches, I'd say patch 1 + 24-26 have my

Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>

-Daniel

> 
> Cheers,
> Peter
> 
> > -Daniel
> >> Cheers,
> >> Peter
> >>
> >>>
> >>>>
> >>>>> Anyway:
> >>>>> Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
> >>>>
> >>>> Thanks!
> >>>>
> >>>> Cheers,
> >>>> Peter
> >>>>
> >>>>>  --
> >>>>> Regards
> >>>>> Andrzej
> >>>>>
> >>>>>>   * @funcs: control functions
> >>>>>>   * @driver_private: pointer to the bridge driver's internal context
> >>>>>>   */
> >>>>>> @@ -271,6 +272,7 @@ struct drm_bridge {
> >>>>>>    struct drm_bridge *next;
> >>>>>>    struct list_head list;
> >>>>>>    const struct drm_bridge_timings *timings;
> >>>>>> +  struct device_link *link;
> >>>>>>
> >>>>>>    const struct drm_bridge_funcs *funcs;
> >>>>>>    void *driver_private;
> >>>>>
> >>>>>
> >>>>
> >>>
> >>
> >> _______________________________________________
> >> dri-devel mailing list
> >> dri-devel at lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > 
> > 
> > 
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

^ permalink raw reply

* [PATCH] arm64: KVM: reduce guest fpsimd trap
From: Marc Zyngier @ 2018-05-16  9:25 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <F348A9E21A573744858FF7E5D32E29D81BDF52AC@dggemi509-mbs.china.huawei.com>

[+Dave]

Hi Nianyao,

On 16/05/18 10:08, Tangnianyao (ICT) wrote:
> Add last_fpsimd_trap to notify if guest last exit reason is handling fpsimd. If guest is using fpsimd frequently, save host's fpsimd state and restore guest's fpsimd state and deactive fpsimd trap before returning to guest. It can avoid guest fpsimd trap soon to improve performance.
> 
> Signed-off-by: Nianyao Tang <tangnianyao@huawei.com>
> ---
>  arch/arm64/kernel/asm-offsets.c |  1 +
>  arch/arm64/kvm/hyp/entry.S      |  5 +++++
>  arch/arm64/kvm/hyp/switch.c     | 38 ++++++++++++++++++++++++++++++++++++--
>  include/linux/kvm_host.h        |  1 +
>  4 files changed, 43 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm64/kernel/asm-offsets.c b/arch/arm64/kernel/asm-offsets.c index 5bdda65..35a9c5c 100644
> --- a/arch/arm64/kernel/asm-offsets.c
> +++ b/arch/arm64/kernel/asm-offsets.c
> @@ -136,6 +136,7 @@ int main(void)
>  #ifdef CONFIG_KVM_ARM_HOST
>    DEFINE(VCPU_CONTEXT,		offsetof(struct kvm_vcpu, arch.ctxt));
>    DEFINE(VCPU_FAULT_DISR,	offsetof(struct kvm_vcpu, arch.fault.disr_el1));
> +  DEFINE(VCPU_LAST_FPSIMD_TRAP, offsetof(struct kvm_vcpu, 
> + last_fpsimd_trap));
>    DEFINE(CPU_GP_REGS,		offsetof(struct kvm_cpu_context, gp_regs));
>    DEFINE(CPU_USER_PT_REGS,	offsetof(struct kvm_regs, regs));
>    DEFINE(CPU_FP_REGS,		offsetof(struct kvm_regs, fp_regs));
> diff --git a/arch/arm64/kvm/hyp/entry.S b/arch/arm64/kvm/hyp/entry.S index e41a161..956e042 100644
> --- a/arch/arm64/kvm/hyp/entry.S
> +++ b/arch/arm64/kvm/hyp/entry.S
> @@ -197,6 +197,11 @@ alternative_endif
>  	add	x0, x2, #CPU_GP_REG_OFFSET(CPU_FP_REGS)
>  	bl	__fpsimd_restore_state
>  
> +	// Mark guest using fpsimd now
> +	ldr x0, [x3, #VCPU_LAST_FPSIMD_TRAP]
> +	add x0, x0, #1
> +	str x0, [x3, #VCPU_LAST_FPSIMD_TRAP]
> +
>  	// Skip restoring fpexc32 for AArch64 guests
>  	mrs	x1, hcr_el2
>  	tbnz	x1, #HCR_RW_SHIFT, 1f
> diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c index d964523..86eea1b 100644
> --- a/arch/arm64/kvm/hyp/switch.c
> +++ b/arch/arm64/kvm/hyp/switch.c
> @@ -92,7 +92,13 @@ static void activate_traps_vhe(struct kvm_vcpu *vcpu)
>  
>  	val = read_sysreg(cpacr_el1);
>  	val |= CPACR_EL1_TTA;
> -	val &= ~(CPACR_EL1_FPEN | CPACR_EL1_ZEN);
> +	val &= ~CPACR_EL1_ZEN;
> +
> +	if (vcpu->last_fpsimd_trap)
> +		val |= CPACR_EL1_FPEN;
> +	else
> +		val &= ~CPACR_EL1_FPEN;
> +
>  	write_sysreg(val, cpacr_el1);
>  
>  	write_sysreg(kvm_get_hyp_vector(), vbar_el1); @@ -105,7 +111,13 @@ static void __hyp_text __activate_traps_nvhe(struct kvm_vcpu *vcpu)
>  	__activate_traps_common(vcpu);
>  
>  	val = CPTR_EL2_DEFAULT;
> -	val |= CPTR_EL2_TTA | CPTR_EL2_TFP | CPTR_EL2_TZ;
> +	val |= CPTR_EL2_TTA | CPTR_EL2_TZ;
> +
> +	if (vcpu->last_fpsimd_trap)
> +		val &= ~CPTR_EL2_TFP;
> +	else
> +		val |= CPTR_EL2_TFP;
> +
>  	write_sysreg(val, cptr_el2);
>  }
>  
> @@ -406,6 +418,17 @@ int kvm_vcpu_run_vhe(struct kvm_vcpu *vcpu)
>  	__activate_traps(vcpu);
>  	__activate_vm(vcpu->kvm);
>  
> +	/*
> +	 * If guest last trap to host for handling fpsimd, last_fpsimd_trap
> +	 * is set. Restore guest's fpsimd state and deactivate fpsimd trap
> +	 * to avoid guest traping soon.
> +	 */
> +	if (vcpu->last_fpsimd_trap) {
> +		__fpsimd_save_state(&host_ctxt->gp_regs.fp_regs);
> +		__fpsimd_restore_state(&guest_ctxt->gp_regs.fp_regs);
> +		vcpu->last_fpsimd_trap = 0;
> +	}
> +
>  	sysreg_restore_guest_state_vhe(guest_ctxt);
>  	__debug_switch_to_guest(vcpu);
>  
> @@ -454,6 +477,17 @@ int __hyp_text __kvm_vcpu_run_nvhe(struct kvm_vcpu *vcpu)
>  	__activate_traps(vcpu);
>  	__activate_vm(kern_hyp_va(vcpu->kvm));
>  
> +	/*
> +	 * If guest last trap to host for handling fpsimd, last_fpsimd_trap
> +	 * is set. Restore guest's fpsimd state and deactivate fpsimd trap
> +	 * to avoid guest traping soon.
> +	 */
> +	if (vcpu->last_fpsimd_trap) {
> +		__fpsimd_save_state(&host_ctxt->gp_regs.fp_regs);
> +		__fpsimd_restore_state(&guest_ctxt->gp_regs.fp_regs);
> +		vcpu->last_fpsimd_trap = 0;
> +	}
> +
>  	__hyp_vgic_restore_state(vcpu);
>  	__timer_enable_traps(vcpu);
>  
> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h index 6930c63..46bdf0d 100644
> --- a/include/linux/kvm_host.h
> +++ b/include/linux/kvm_host.h
> @@ -274,6 +274,7 @@ struct kvm_vcpu {
>  	bool preempted;
>  	struct kvm_vcpu_arch arch;
>  	struct dentry *debugfs_dentry;
> +	unsigned int last_fpsimd_trap;
>  };
>  
>  static inline int kvm_vcpu_exiting_guest_mode(struct kvm_vcpu *vcpu)
> --
> 2.7.4
> 

This doesn't seem to be the 100% correct. I can't see how this works
when being preempted, for example... I suggest you look at Dave Martin's
series[1], which does this correctly.

Thanks,

	M.

[1] https://www.mail-archive.com/kvmarm at lists.cs.columbia.edu/msg17563.html
-- 
Jazz is not dead. It just smells funny...

^ permalink raw reply

* [PATCH 1/4] amba: Export amba_bustype
From: Russell King - ARM Linux @ 2018-05-16  9:18 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CAHp75VfGpS_QkLj4XM8uHW0BAJV0EBWZ_yLP0R2D+ok4Mt=SQg@mail.gmail.com>

On Wed, May 16, 2018 at 12:16:28PM +0300, Andy Shevchenko wrote:
> On Tue, May 8, 2018 at 10:06 PM, Kim Phillips <kim.phillips@arm.com> wrote:
> > This patch is provided in the context of allowing the Coresight driver
> > subsystem to be loaded as modules.  Coresight uses amba_bus in its call
> > to bus_find_device() in of_coresight_get_endpoint_device() when
> > searching for a configurable endpoint device.  This patch allows
> > Coresight to reference amba_bustype when built as a module.
> 
> > --- a/drivers/amba/bus.c
> > +++ b/drivers/amba/bus.c
> > @@ -197,6 +197,7 @@ struct bus_type amba_bustype = {
> >         .pm             = &amba_pm,
> >         .force_dma      = true,
> >  };
> > +EXPORT_SYMBOL_GPL(amba_bustype);
> 
> Oh,
> 
> What wrong with the approach let's say similar to PCI bus?
> 
> Whenever you have a struct device you may use two helpers:
> 
> dev_is_pci() -> is the device of PCI bus type?
> to_pci_dev() -> get's container of struct device for PCI bus case

How does that help with bus_find_device() which requires the bus_type
structure for the type of devices to be searched?

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

^ permalink raw reply

* [PATCH 1/4] amba: Export amba_bustype
From: Andy Shevchenko @ 2018-05-16  9:16 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20180508140628.f30774c70c4c481bff3f8000@arm.com>

On Tue, May 8, 2018 at 10:06 PM, Kim Phillips <kim.phillips@arm.com> wrote:
> This patch is provided in the context of allowing the Coresight driver
> subsystem to be loaded as modules.  Coresight uses amba_bus in its call
> to bus_find_device() in of_coresight_get_endpoint_device() when
> searching for a configurable endpoint device.  This patch allows
> Coresight to reference amba_bustype when built as a module.

> --- a/drivers/amba/bus.c
> +++ b/drivers/amba/bus.c
> @@ -197,6 +197,7 @@ struct bus_type amba_bustype = {
>         .pm             = &amba_pm,
>         .force_dma      = true,
>  };
> +EXPORT_SYMBOL_GPL(amba_bustype);

Oh,

What wrong with the approach let's say similar to PCI bus?

Whenever you have a struct device you may use two helpers:

dev_is_pci() -> is the device of PCI bus type?
to_pci_dev() -> get's container of struct device for PCI bus case

-- 
With Best Regards,
Andy Shevchenko

^ permalink raw reply

* [PATCH] arm64: KVM: reduce guest fpsimd trap
From: Tangnianyao (ICT) @ 2018-05-16  9:08 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1526460738-11157-1-git-send-email-zhangshaokun@hisilicon.com>

Add last_fpsimd_trap to notify if guest last exit reason is handling fpsimd. If guest is using fpsimd frequently, save host's fpsimd state and restore guest's fpsimd state and deactive fpsimd trap before returning to guest. It can avoid guest fpsimd trap soon to improve performance.

Signed-off-by: Nianyao Tang <tangnianyao@huawei.com>
---
 arch/arm64/kernel/asm-offsets.c |  1 +
 arch/arm64/kvm/hyp/entry.S      |  5 +++++
 arch/arm64/kvm/hyp/switch.c     | 38 ++++++++++++++++++++++++++++++++++++--
 include/linux/kvm_host.h        |  1 +
 4 files changed, 43 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/kernel/asm-offsets.c b/arch/arm64/kernel/asm-offsets.c index 5bdda65..35a9c5c 100644
--- a/arch/arm64/kernel/asm-offsets.c
+++ b/arch/arm64/kernel/asm-offsets.c
@@ -136,6 +136,7 @@ int main(void)
 #ifdef CONFIG_KVM_ARM_HOST
   DEFINE(VCPU_CONTEXT,		offsetof(struct kvm_vcpu, arch.ctxt));
   DEFINE(VCPU_FAULT_DISR,	offsetof(struct kvm_vcpu, arch.fault.disr_el1));
+  DEFINE(VCPU_LAST_FPSIMD_TRAP, offsetof(struct kvm_vcpu, 
+ last_fpsimd_trap));
   DEFINE(CPU_GP_REGS,		offsetof(struct kvm_cpu_context, gp_regs));
   DEFINE(CPU_USER_PT_REGS,	offsetof(struct kvm_regs, regs));
   DEFINE(CPU_FP_REGS,		offsetof(struct kvm_regs, fp_regs));
diff --git a/arch/arm64/kvm/hyp/entry.S b/arch/arm64/kvm/hyp/entry.S index e41a161..956e042 100644
--- a/arch/arm64/kvm/hyp/entry.S
+++ b/arch/arm64/kvm/hyp/entry.S
@@ -197,6 +197,11 @@ alternative_endif
 	add	x0, x2, #CPU_GP_REG_OFFSET(CPU_FP_REGS)
 	bl	__fpsimd_restore_state
 
+	// Mark guest using fpsimd now
+	ldr x0, [x3, #VCPU_LAST_FPSIMD_TRAP]
+	add x0, x0, #1
+	str x0, [x3, #VCPU_LAST_FPSIMD_TRAP]
+
 	// Skip restoring fpexc32 for AArch64 guests
 	mrs	x1, hcr_el2
 	tbnz	x1, #HCR_RW_SHIFT, 1f
diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c index d964523..86eea1b 100644
--- a/arch/arm64/kvm/hyp/switch.c
+++ b/arch/arm64/kvm/hyp/switch.c
@@ -92,7 +92,13 @@ static void activate_traps_vhe(struct kvm_vcpu *vcpu)
 
 	val = read_sysreg(cpacr_el1);
 	val |= CPACR_EL1_TTA;
-	val &= ~(CPACR_EL1_FPEN | CPACR_EL1_ZEN);
+	val &= ~CPACR_EL1_ZEN;
+
+	if (vcpu->last_fpsimd_trap)
+		val |= CPACR_EL1_FPEN;
+	else
+		val &= ~CPACR_EL1_FPEN;
+
 	write_sysreg(val, cpacr_el1);
 
 	write_sysreg(kvm_get_hyp_vector(), vbar_el1); @@ -105,7 +111,13 @@ static void __hyp_text __activate_traps_nvhe(struct kvm_vcpu *vcpu)
 	__activate_traps_common(vcpu);
 
 	val = CPTR_EL2_DEFAULT;
-	val |= CPTR_EL2_TTA | CPTR_EL2_TFP | CPTR_EL2_TZ;
+	val |= CPTR_EL2_TTA | CPTR_EL2_TZ;
+
+	if (vcpu->last_fpsimd_trap)
+		val &= ~CPTR_EL2_TFP;
+	else
+		val |= CPTR_EL2_TFP;
+
 	write_sysreg(val, cptr_el2);
 }
 
@@ -406,6 +418,17 @@ int kvm_vcpu_run_vhe(struct kvm_vcpu *vcpu)
 	__activate_traps(vcpu);
 	__activate_vm(vcpu->kvm);
 
+	/*
+	 * If guest last trap to host for handling fpsimd, last_fpsimd_trap
+	 * is set. Restore guest's fpsimd state and deactivate fpsimd trap
+	 * to avoid guest traping soon.
+	 */
+	if (vcpu->last_fpsimd_trap) {
+		__fpsimd_save_state(&host_ctxt->gp_regs.fp_regs);
+		__fpsimd_restore_state(&guest_ctxt->gp_regs.fp_regs);
+		vcpu->last_fpsimd_trap = 0;
+	}
+
 	sysreg_restore_guest_state_vhe(guest_ctxt);
 	__debug_switch_to_guest(vcpu);
 
@@ -454,6 +477,17 @@ int __hyp_text __kvm_vcpu_run_nvhe(struct kvm_vcpu *vcpu)
 	__activate_traps(vcpu);
 	__activate_vm(kern_hyp_va(vcpu->kvm));
 
+	/*
+	 * If guest last trap to host for handling fpsimd, last_fpsimd_trap
+	 * is set. Restore guest's fpsimd state and deactivate fpsimd trap
+	 * to avoid guest traping soon.
+	 */
+	if (vcpu->last_fpsimd_trap) {
+		__fpsimd_save_state(&host_ctxt->gp_regs.fp_regs);
+		__fpsimd_restore_state(&guest_ctxt->gp_regs.fp_regs);
+		vcpu->last_fpsimd_trap = 0;
+	}
+
 	__hyp_vgic_restore_state(vcpu);
 	__timer_enable_traps(vcpu);
 
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h index 6930c63..46bdf0d 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -274,6 +274,7 @@ struct kvm_vcpu {
 	bool preempted;
 	struct kvm_vcpu_arch arch;
 	struct dentry *debugfs_dentry;
+	unsigned int last_fpsimd_trap;
 };
 
 static inline int kvm_vcpu_exiting_guest_mode(struct kvm_vcpu *vcpu)
--
2.7.4

^ permalink raw reply

* [PATCH 06/18] arm64: move sve_user_{enable, disable} to <asm/fpsimd.h>
From: Dave Martin @ 2018-05-16  9:01 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20180515163352.sl7sfaswv4hsktl7@lakrids.cambridge.arm.com>

On Tue, May 15, 2018 at 05:33:52PM +0100, Mark Rutland wrote:
> On Tue, May 15, 2018 at 01:19:26PM +0100, Dave Martin wrote:
> > On Tue, May 15, 2018 at 11:39:36AM +0100, Mark Rutland wrote:
> > > On Mon, May 14, 2018 at 12:06:50PM +0100, Dave Martin wrote:
> > > > On Mon, May 14, 2018 at 10:46:28AM +0100, Mark Rutland wrote:

[...]

> > > > > @@ -107,6 +119,9 @@ static inline int sve_get_current_vl(void)
> > > > >  	return -EINVAL;
> > > > >  }
> > > > >  
> > > > > +static inline void sve_user_disable(void) { }
> > > > > +static inline void sve_user_enable(void) { }
> > > > > +
> > > > 
> > > > Alternatively, just move the full definitions outside the #ifdef
> > > > CONFIG_ARM64_SVE.
> > > 
> > > Can do, though I was trying to keep the exsting pattern with empty
> > > inlines for the !CONFIG_ARM64_SVE case.
> > 
> > There isn't really a pattern.  I tried to avoid dummy versions where
> > there's no real reason to have them.  I don't _think_ they're really
> > needed here, unless I missed something.  Did you get build failures
> > without them?
> 
> I need *some* definition so that sve_user_reset() in the syscall path
> can compile without ifdeferry. 
> 
> In sve_user_reset() I first check system_supports_sve(), which checks
> IS_ENABLED(CONFIG_ARM64_SVE), so the call should be optimised away when
> !CONFIG_ARM64_SVE, but I need a prototype regardless.

What I envisaged is that you move the real definitions outside the
#ifdef so that they're defined unconditionally, and get rid of the
dummies.

Having a dummy definition of sve_user_enable() really feels like it's
papering over something.  How could it be appropriate to call this in a
non-SVE enabled system?  You _do_ guard the call to this already, so
hiding the real function body for CONFIG_ARM64_SVE=n doesn't appear to
achieve anything.  Maybe I missed something somewhere.

A dummy sve_user_disable() is a bit more reasonable though, but we want
this to be a nop on non-SVE hardware even if CONFIG_ARM64_SVE=y.

What about moving the system_supports_sve() check inside
sve_user_disable()?

[...]

> > > Earlier I'd put BUILD_BUG() in the body for the !CONFIG_ARM64_SVE case,
> > > to catch that kind of thing -- I could restore that.
> > 
> > IIUC:
> > 
> > 	if (0) {
> > 		BUILD_BUG_ON(1);
> > 	}
> > 
> > can still fire, in which case it's futile checking for CONFIG_ARM64_SVE
> > in most of the SVE support code.
> 
> We already rely on BUILD_BUG() not firing in paths that can be trivially
> optimized away. e.g. in the cmpxchg code.

Fair enough.  I had been unsure on this point.

If you want to put a BUILD_BUG_ON(!IS_ENABLED(CONFIG_ARM64_SVE)) in
sve_user_enable() and build with CONFIG_ARM64_SVE=n to check it works,
then I'd be fine with that.

This doesn't capture the runtime part of the condition, but it's better
than nothing.

[...]

> > > > > diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
> > > > > index 088940387a4d..79a81c7d85c6 100644
> > > > > --- a/arch/arm64/kernel/fpsimd.c
> > > > > +++ b/arch/arm64/kernel/fpsimd.c
> > > > > @@ -159,7 +159,6 @@ static void sve_free(struct task_struct *task)
> > > > >  	__sve_free(task);
> > > > >  }
> > > > >  
> > > > > -
> > > > 
> > > > Hmmm, Ack.  Check for conflicts with the KVM FPSIMD rework [1] (though
> > > > trivial).
> > > 
> > > I'll assume that Ack stands regardless. :)
> > 
> > Actually, I was just commenting on the deleted blank line... 
> 
> Ah. I've restored that now.

I meant Ack to the deletion.  It looks like the blank line was
spuriously introduced in the first place.  But it doesn't hugely matter
either way.

Cheers
---Dave

^ permalink raw reply

* [PATCH 1/4] amba: Export amba_bustype
From: Ulf Hansson @ 2018-05-16  8:57 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20180515134144.GF16141@n2100.armlinux.org.uk>

On 15 May 2018 at 15:41, Russell King - ARM Linux <linux@armlinux.org.uk> wrote:
> On Tue, May 15, 2018 at 08:59:02AM +0200, Ulf Hansson wrote:
>> On 8 May 2018 at 21:06, Kim Phillips <kim.phillips@arm.com> wrote:
>> > This patch is provided in the context of allowing the Coresight driver
>> > subsystem to be loaded as modules.  Coresight uses amba_bus in its call
>> > to bus_find_device() in of_coresight_get_endpoint_device() when
>> > searching for a configurable endpoint device.  This patch allows
>> > Coresight to reference amba_bustype when built as a module.
>>
>> Sounds like you are fixing a bug, don't your want this to go for
>> stable and then also add a fixes tag?
>
> What bug is this fixing exactly that would qualify it for stable
> backporting?

That was my question, as when reading the changelog of $subject patch,
this isn't clear to me.

>
> The lack of an export is never a bug unless there is some existing
> user which requires it.  This is not the case here.
>
> What Kim is doing in his new patch series is making Coresight - which
> is currently only available as either disabled or built-in - possible
> to be loaded as a module.  This is a new feature, and in the process
> of creating this new feature, Kim needs a symbol that wasn't previously
> needed to be exported.

Thanks for clarifying, I did not review the entire series. The change
make perfect sense, no objections - and of course I agree it's not a
bug fix.

[...]

Kind regards
Uffe

^ permalink raw reply

* [PATCH v2] ARM: dts: r8a7740: Add CEU1
From: Simon Horman @ 2018-05-16  8:55 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CAMuHMdXzc3YLm8u+JgQMhXtErAgBgc4bti9cyUboPZmpB+rVyg@mail.gmail.com>

On Wed, May 16, 2018 at 09:40:10AM +0200, Geert Uytterhoeven wrote:
> Hi Simon,
> 
> On Tue, May 15, 2018 at 10:00 AM, Simon Horman
> <horms+renesas@verge.net.au> wrote:
> > Describe CEU1 peripheral for Renesas R-Mobile A1 R8A7740 Soc.
> >
> > Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
> > ---
> > v2
> > * Correct register range start address
> 
> Thanks for your patch!
> 
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> 
> Minor question below.
> 
> > --- a/arch/arm/boot/dts/r8a7740.dtsi
> > +++ b/arch/arm/boot/dts/r8a7740.dtsi
> > @@ -77,6 +77,16 @@
> >                 status = "disabled";
> >         };
> >
> > +       ceu1: ceu at fe914000 {
> > +               reg = <0xfe914000 0x3000>;
> > +               compatible = "renesas,r8a7740-ceu";
> > +               interrupts = <GIC_SPI 159 IRQ_TYPE_LEVEL_HIGH>;
> > +               clocks = <&mstp1_clks R8A7740_CLK_CEU21>;
> > +               clock-names = "ceu21";
> 
> Why the "clock-names" property? It's not mentioned in the DT bindings, and
> may cause issues if the bindings are ever amended.

Thanks, I copied this from CEU0 where you have also raised the same issue.
I have dropped the property for now.

^ permalink raw reply

* [PATCH 5/6 v3] bus: fsl-mc: supoprt dma configure for devices on fsl-mc bus
From: Nipun Gupta @ 2018-05-16  8:48 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <5AF9916E.8000504@nxp.com>



> -----Original Message-----
> From: Laurentiu Tudor
> Sent: Monday, May 14, 2018 7:10 PM
> To: Nipun Gupta <nipun.gupta@nxp.com>; robin.murphy at arm.com;
> will.deacon at arm.com; mark.rutland at arm.com; catalin.marinas at arm.com
> Cc: hch at lst.de; gregkh at linuxfoundation.org; joro at 8bytes.org;
> robh+dt at kernel.org; m.szyprowski at samsung.com; shawnguo at kernel.org;
> frowand.list at gmail.com; bhelgaas at google.com; iommu at lists.linux-
> foundation.org; linux-kernel at vger.kernel.org; devicetree at vger.kernel.org;
> linux-arm-kernel at lists.infradead.org; linuxppc-dev at lists.ozlabs.org; linux-
> pci at vger.kernel.org; Bharat Bhushan <bharat.bhushan@nxp.com>;
> stuyoder at gmail.com; Leo Li <leoyang.li@nxp.com>
> Subject: Re: [PATCH 5/6 v3] bus: fsl-mc: supoprt dma configure for devices
> on fsl-mc bus
> 
> Hi Nipun,
> 
> On 04/27/2018 01:27 PM, Nipun Gupta wrote:
> > Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
> > ---
> >   drivers/bus/fsl-mc/fsl-mc-bus.c | 16 ++++++++++++----
> >   1 file changed, 12 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/bus/fsl-mc/fsl-mc-bus.c b/drivers/bus/fsl-mc/fsl-mc-
> bus.c
> > index 5d8266c..624828b 100644
> > --- a/drivers/bus/fsl-mc/fsl-mc-bus.c
> > +++ b/drivers/bus/fsl-mc/fsl-mc-bus.c
> > @@ -127,6 +127,16 @@ static int fsl_mc_bus_uevent(struct device *dev,
> struct kobj_uevent_env *env)
> >   	return 0;
> >   }
> >
> > +static int fsl_mc_dma_configure(struct device *dev)
> > +{
> > +	struct device *dma_dev = dev;
> > +
> > +	while (dev_is_fsl_mc(dma_dev))
> > +		dma_dev = dma_dev->parent;
> > +
> > +	return of_dma_configure(dev, dma_dev->of_node, 0);
> > +}
> > +
> >   static ssize_t modalias_show(struct device *dev, struct device_attribute
> *attr,
> >   			     char *buf)
> >   {
> > @@ -148,6 +158,7 @@ struct bus_type fsl_mc_bus_type = {
> >   	.name = "fsl-mc",
> >   	.match = fsl_mc_bus_match,
> >   	.uevent = fsl_mc_bus_uevent,
> > +	.dma_configure  = fsl_mc_dma_configure,
> >   	.dev_groups = fsl_mc_dev_groups,
> >   };
> >   EXPORT_SYMBOL_GPL(fsl_mc_bus_type);
> > @@ -616,6 +627,7 @@ int fsl_mc_device_add(struct fsl_mc_obj_desc
> *obj_desc,
> >   		mc_dev->icid = parent_mc_dev->icid;
> >   		mc_dev->dma_mask = FSL_MC_DEFAULT_DMA_MASK;
> >   		mc_dev->dev.dma_mask = &mc_dev->dma_mask;
> > +		mc_dev->dev.coherent_dma_mask = mc_dev->dma_mask;
> 
> This change seems a bit unrelated to the patch subject. I wonder if it
> makes sense to split it it in a distinct patch.

Okay. I will spin a v5 after splitting this patch and adding changelog (Greg's comment), fixing typo (Bjorn's comment).

Regards,
Nipun

> 
> ---
> Best Regards, Laurentiu

^ permalink raw reply

* [RESEND PATCH v5 0/6] Add support for PWM input capture on STM32
From: Fabrice Gasnier @ 2018-05-16  8:43 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20180516080635.GE5130@dell>

On 05/16/2018 10:06 AM, Lee Jones wrote:
> On Wed, 16 May 2018, Fabrice Gasnier wrote:
> 
>> This series adds support for capture to stm32-pwm driver.
>> Capture is based on DMAs.
>> - First two patches add support for requesting DMAs to MFD core
>> - Next three patches add support for capture to stm32-pwm driver
>> - This has been tested on stm32429i-eval board.
>>
>> ---
>> Changes in v5:
>> - update patch 2 (mfd: stm32-timers: add support for dmas)
>>   move stm32_timers_dma struct to header file,
>>   fix warning on dma_mapping_error().
>>
>> Changes in v4:
>> - Lee's comments on patch 2 (mfd: stm32-timers: add support for dmas)
>>   Add kerneldoc header, better format comments.
>>
>> Changes in v3:
>> - Dropped 2 precusor patches applied by Thierry in pwm tree:
>>   "pwm: stm32: fix, remove unused struct device"
>>   "pwm: stm32: protect common prescaler for all channels"
>> - Note: this series applies on top on pwm tree
>> - Implements Lee's comments on MFD part: rework stm32_timers_dma struct,
>>   exported routine prototype now use generic device struct, more
>>   various comments (see patch 2 changelog).
>>
>> Resend v2:
>> - Add collected Acks
>>
>> Changes in v2:
>> - Abstract DMA handling from child driver: move it to MFD core
>> - Rework pwm capture routines to adopt this change
>> - Comment on optional dma support, beautify DMAs probe
>>
>> Fabrice Gasnier (6):
>>   dt-bindings: mfd: stm32-timers: add support for dmas
>>   mfd: stm32-timers: add support for dmas
>>   pwm: stm32: add capture support
>>   pwm: stm32: improve capture by tuning counter prescaler
>>   pwm: stm32: use input prescaler to improve period capture
>>   ARM: dts: stm32: Enable pwm3 input capture on stm32f429i-eval
> 
> Applied patches 1-5.

Many thanks Lee !

Maybe I missed something, but just in case...
In your pull request ("[GIT PULL] Immutable branch between MFD and PWM
due for the v4.18 merge window") I only see 4 patches:
Fabrice Gasnier (4):
      mfd: stm32-timers: Add support for DMAs
      pwm: stm32: Add capture support
      pwm: stm32: Improve capture by tuning counter prescaler
      pwm: stm32: Use input prescaler to improve period capture

I can't see patch 1 ("dt-bindings: mfd: stm32-timers: add support for dmas")
Is it applied on another tree ?

Best Regards,
Fabrice

> 
>>  .../devicetree/bindings/mfd/stm32-timers.txt       |  20 ++
>>  arch/arm/boot/dts/stm32429i-eval.dts               |   3 +
>>  drivers/mfd/stm32-timers.c                         | 201 +++++++++++++++-
>>  drivers/pwm/pwm-stm32.c                            | 257 +++++++++++++++++++++
>>  include/linux/mfd/stm32-timers.h                   |  58 +++++
>>  5 files changed, 537 insertions(+), 2 deletions(-)
>>
> 

^ permalink raw reply

* [PATCH] media: helene: fix xtal frequency setting at power on
From: Katsuhiro Suzuki @ 2018-05-16  8:41 UTC (permalink / raw)
  To: linux-arm-kernel

This patch fixes crystal frequency setting when power on this device.

Signed-off-by: Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com>
---
 drivers/media/dvb-frontends/helene.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/media/dvb-frontends/helene.c b/drivers/media/dvb-frontends/helene.c
index 0a4f312c4368..8fcf7a00782a 100644
--- a/drivers/media/dvb-frontends/helene.c
+++ b/drivers/media/dvb-frontends/helene.c
@@ -924,7 +924,10 @@ static int helene_x_pon(struct helene_priv *priv)
 	helene_write_regs(priv, 0x99, cdata, sizeof(cdata));
 
 	/* 0x81 - 0x94 */
-	data[0] = 0x18; /* xtal 24 MHz */
+	if (priv->xtal == SONY_HELENE_XTAL_16000)
+		data[0] = 0x10; /* xtal 16 MHz */
+	else
+		data[0] = 0x18; /* xtal 24 MHz */
 	data[1] = (uint8_t)(0x80 | (0x04 & 0x1F)); /* 4 x 25 = 100uA */
 	data[2] = (uint8_t)(0x80 | (0x26 & 0x7F)); /* 38 x 0.25 = 9.5pF */
 	data[3] = 0x80; /* REFOUT signal output 500mVpp */
-- 
2.17.0

^ permalink raw reply related

* [PATCH] media: helene: fix tuning frequency of satellite
From: Katsuhiro Suzuki @ 2018-05-16  8:41 UTC (permalink / raw)
  To: linux-arm-kernel

This patch fixes tuning frequency of satellite to kHz. That as same
as terrestrial one.

Signed-off-by: Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com>
---
 drivers/media/dvb-frontends/helene.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/dvb-frontends/helene.c b/drivers/media/dvb-frontends/helene.c
index 04033f0c278b..0a4f312c4368 100644
--- a/drivers/media/dvb-frontends/helene.c
+++ b/drivers/media/dvb-frontends/helene.c
@@ -523,7 +523,7 @@ static int helene_set_params_s(struct dvb_frontend *fe)
 	enum helene_tv_system_t tv_system;
 	struct dtv_frontend_properties *p = &fe->dtv_property_cache;
 	struct helene_priv *priv = fe->tuner_priv;
-	int frequencykHz = p->frequency;
+	int frequencykHz = p->frequency / 1000;
 	uint32_t frequency4kHz = 0;
 	u32 symbol_rate = p->symbol_rate/1000;
 
-- 
2.17.0

^ permalink raw reply related

* [PATCH v2] media: helene: add I2C device probe function
From: Katsuhiro Suzuki @ 2018-05-16  8:37 UTC (permalink / raw)
  To: linux-arm-kernel

This patch adds I2C probe function to use dvb_module_probe()
with this driver.

Signed-off-by: Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com>

---

Changes since v1:
  - Add documents for dvb_frontend member of helene_config
---
 drivers/media/dvb-frontends/helene.c | 88 ++++++++++++++++++++++++++--
 drivers/media/dvb-frontends/helene.h |  3 +
 2 files changed, 87 insertions(+), 4 deletions(-)

diff --git a/drivers/media/dvb-frontends/helene.c b/drivers/media/dvb-frontends/helene.c
index a0d0b53c91d7..04033f0c278b 100644
--- a/drivers/media/dvb-frontends/helene.c
+++ b/drivers/media/dvb-frontends/helene.c
@@ -666,7 +666,7 @@ static int helene_set_params_s(struct dvb_frontend *fe)
 	return 0;
 }
 
-static int helene_set_params(struct dvb_frontend *fe)
+static int helene_set_params_t(struct dvb_frontend *fe)
 {
 	u8 data[MAX_WRITE_REGSIZE];
 	u32 frequency;
@@ -835,6 +835,19 @@ static int helene_set_params(struct dvb_frontend *fe)
 	return 0;
 }
 
+static int helene_set_params(struct dvb_frontend *fe)
+{
+	struct dtv_frontend_properties *p = &fe->dtv_property_cache;
+
+	if (p->delivery_system == SYS_DVBT ||
+	    p->delivery_system == SYS_DVBT2 ||
+	    p->delivery_system == SYS_ISDBT ||
+	    p->delivery_system == SYS_DVBC_ANNEX_A)
+		return helene_set_params_t(fe);
+
+	return helene_set_params_s(fe);
+}
+
 static int helene_get_frequency(struct dvb_frontend *fe, u32 *frequency)
 {
 	struct helene_priv *priv = fe->tuner_priv;
@@ -843,7 +856,7 @@ static int helene_get_frequency(struct dvb_frontend *fe, u32 *frequency)
 	return 0;
 }
 
-static const struct dvb_tuner_ops helene_tuner_ops = {
+static const struct dvb_tuner_ops helene_tuner_ops_t = {
 	.info = {
 		.name = "Sony HELENE Ter tuner",
 		.frequency_min = 1000000,
@@ -853,7 +866,7 @@ static const struct dvb_tuner_ops helene_tuner_ops = {
 	.init = helene_init,
 	.release = helene_release,
 	.sleep = helene_sleep,
-	.set_params = helene_set_params,
+	.set_params = helene_set_params_t,
 	.get_frequency = helene_get_frequency,
 };
 
@@ -871,6 +884,20 @@ static const struct dvb_tuner_ops helene_tuner_ops_s = {
 	.get_frequency = helene_get_frequency,
 };
 
+static const struct dvb_tuner_ops helene_tuner_ops = {
+	.info = {
+		.name = "Sony HELENE Sat/Ter tuner",
+		.frequency_min = 500000,
+		.frequency_max = 1200000000,
+		.frequency_step = 1000,
+	},
+	.init = helene_init,
+	.release = helene_release,
+	.sleep = helene_sleep,
+	.set_params = helene_set_params,
+	.get_frequency = helene_get_frequency,
+};
+
 /* power-on tuner
  * call once after reset
  */
@@ -1032,7 +1059,7 @@ struct dvb_frontend *helene_attach(struct dvb_frontend *fe,
 	if (fe->ops.i2c_gate_ctrl)
 		fe->ops.i2c_gate_ctrl(fe, 0);
 
-	memcpy(&fe->ops.tuner_ops, &helene_tuner_ops,
+	memcpy(&fe->ops.tuner_ops, &helene_tuner_ops_t,
 			sizeof(struct dvb_tuner_ops));
 	fe->tuner_priv = priv;
 	dev_info(&priv->i2c->dev,
@@ -1042,6 +1069,59 @@ struct dvb_frontend *helene_attach(struct dvb_frontend *fe,
 }
 EXPORT_SYMBOL(helene_attach);
 
+static int helene_probe(struct i2c_client *client,
+			const struct i2c_device_id *id)
+{
+	struct helene_config *config = client->dev.platform_data;
+	struct dvb_frontend *fe = config->fe;
+	struct device *dev = &client->dev;
+	struct helene_priv *priv;
+
+	priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+	if (!priv)
+		return -ENOMEM;
+
+	priv->i2c_address = client->addr;
+	priv->i2c = client->adapter;
+	priv->set_tuner_data = config->set_tuner_priv;
+	priv->set_tuner = config->set_tuner_callback;
+	priv->xtal = config->xtal;
+
+	if (fe->ops.i2c_gate_ctrl)
+		fe->ops.i2c_gate_ctrl(fe, 1);
+
+	if (helene_x_pon(priv) != 0)
+		return -EINVAL;
+
+	if (fe->ops.i2c_gate_ctrl)
+		fe->ops.i2c_gate_ctrl(fe, 0);
+
+	memcpy(&fe->ops.tuner_ops, &helene_tuner_ops,
+	       sizeof(struct dvb_tuner_ops));
+	fe->tuner_priv = priv;
+	i2c_set_clientdata(client, priv);
+
+	dev_info(dev, "Sony HELENE attached on addr=%x at I2C adapter %p\n",
+		 priv->i2c_address, priv->i2c);
+
+	return 0;
+}
+
+static const struct i2c_device_id helene_id[] = {
+	{ "helene", },
+	{}
+};
+MODULE_DEVICE_TABLE(i2c, helene_id);
+
+static struct i2c_driver helene_driver = {
+	.driver = {
+		.name = "helene",
+	},
+	.probe    = helene_probe,
+	.id_table = helene_id,
+};
+module_i2c_driver(helene_driver);
+
 MODULE_DESCRIPTION("Sony HELENE Sat/Ter tuner driver");
 MODULE_AUTHOR("Abylay Ospan <aospan@netup.ru>");
 MODULE_LICENSE("GPL");
diff --git a/drivers/media/dvb-frontends/helene.h b/drivers/media/dvb-frontends/helene.h
index c9fc81c7e4e7..8562d01bc93e 100644
--- a/drivers/media/dvb-frontends/helene.h
+++ b/drivers/media/dvb-frontends/helene.h
@@ -39,6 +39,7 @@ enum helene_xtal {
  * @set_tuner_callback:	Callback function that notifies the parent driver
  *			which tuner is active now
  * @xtal: Cristal frequency as described by &enum helene_xtal
+ * @fe: Frontend for which connects this tuner
  */
 struct helene_config {
 	u8	i2c_address;
@@ -46,6 +47,8 @@ struct helene_config {
 	void	*set_tuner_priv;
 	int	(*set_tuner_callback)(void *, int);
 	enum helene_xtal xtal;
+
+	struct dvb_frontend *fe;
 };
 
 #if IS_REACHABLE(CONFIG_DVB_HELENE)
-- 
2.17.0

^ permalink raw reply related

* [PATCH v9 07/11] arm64: kexec_file: add crash dump support
From: James Morse @ 2018-05-16  8:34 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <f8d8305d-42f5-e1e2-20c4-733cb38cbb8d@arm.com>

Hi Akashi,

On 15/05/18 18:11, James Morse wrote:
> On 25/04/18 07:26, AKASHI Takahiro wrote:
>> Enabling crash dump (kdump) includes
>> * prepare contents of ELF header of a core dump file, /proc/vmcore,
>>   using crash_prepare_elf64_headers(), and
>> * add two device tree properties, "linux,usable-memory-range" and
>>   "linux,elfcorehdr", which represent repsectively a memory range
>>   to be used by crash dump kernel and the header's location

>> diff --git a/arch/arm64/kernel/machine_kexec_file.c b/arch/arm64/kernel/machine_kexec_file.c
>> index 37c0a9dc2e47..ec674f4d267c 100644
>> --- a/arch/arm64/kernel/machine_kexec_file.c
>> +++ b/arch/arm64/kernel/machine_kexec_file.c
>> @@ -76,6 +81,78 @@ int arch_kexec_walk_mem(struct kexec_buf *kbuf,

>> +static void fill_property(void *buf, u64 val64, int cells)
>> +{
>> +	u32 val32;
>> +
>> +	if (cells == 1) {
>> +		val32 = cpu_to_fdt32((u32)val64);
>> +		memcpy(buf, &val32, sizeof(val32));
>> +	} else {
> 
>> +		memset(buf, 0, cells * sizeof(u32) - sizeof(u64));
>> +		buf += cells * sizeof(u32) - sizeof(u64);
> 
> Is this trying to clear the 'top' cells and shuffle the pointer to point at the
> 'bottom' 2? I'm pretty sure this isn't endian safe.

It came to me at 2am: this only works on big-endian, which is exactly what you
want as that is the DT format.


> Do we really expect a system to have #address-cells > 2?


Thanks,

James

^ permalink raw reply

* [PATCH v9 05/12] ACPI/PPTT: Add Processor Properties Topology Table parsing
From: Rafael J. Wysocki @ 2018-05-16  8:24 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <7cefb087-f41a-0a73-ef77-b560d338be4b@arm.com>

On Tue, May 15, 2018 at 11:42 PM, Jeremy Linton <jeremy.linton@arm.com> wrote:
> Hi,
>
>
> On 05/12/2018 05:09 AM, Rafael J. Wysocki wrote:
>>
>> On Sat, May 12, 2018 at 1:58 AM, Jeremy Linton <jeremy.linton@arm.com>
>> wrote:
>>>

[cut]

>>
>>
>> I don't think you really need the explicit type cast here and above,
>> but that's very minor.
>>
>>> +}
>>
>>
>> Please feel free to add
>>
>> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>>
>> to the patch and route it through the arch tree as needed.
>
>
> Thanks for looking at this (and the ack of course)!
>
> As an FYI, the in my build without the type cast, the
> -Werror=incompatible-pointer-types (sourced from the root Makefile) triggers
> an error.

Fair enough.

^ permalink raw reply

* [PATCH] MAINTAINERS: Add entry for STM32 timer and lptimer drivers
From: Lee Jones @ 2018-05-16  8:22 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1526398399-31753-1-git-send-email-fabrice.gasnier@st.com>

On Tue, 15 May 2018, Fabrice Gasnier wrote:

> Add an entry to make myself a maintainer of STM32 timer and lptimer
> drivers.
> 
> Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
> ---
>  MAINTAINERS | 10 ++++++++++
>  1 file changed, 10 insertions(+)

Applied, thanks.

-- 
Lee Jones [???]
Linaro Services Technical Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

^ permalink raw reply

* [PATCH] ARM: berlin: switch to SPDX license identifier
From: Jisheng Zhang @ 2018-05-16  8:19 UTC (permalink / raw)
  To: linux-arm-kernel

Use the appropriate SPDX license identifier and drop the previous
boilerplate license text.

Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
---
 arch/arm/mach-berlin/berlin.c  | 5 +----
 arch/arm/mach-berlin/headsmp.S | 5 +----
 arch/arm/mach-berlin/platsmp.c | 5 +----
 3 files changed, 3 insertions(+), 12 deletions(-)

diff --git a/arch/arm/mach-berlin/berlin.c b/arch/arm/mach-berlin/berlin.c
index ac181c6797ee..2424ad40190c 100644
--- a/arch/arm/mach-berlin/berlin.c
+++ b/arch/arm/mach-berlin/berlin.c
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0
 /*
  * Device Tree support for Marvell Berlin SoCs.
  *
@@ -5,10 +6,6 @@
  *
  * based on GPL'ed 2.6 kernel sources
  *  (c) Marvell International Ltd.
- *
- * This file is licensed under the terms of the GNU General Public
- * License version 2.  This program is licensed "as is" without any
- * warranty of any kind, whether express or implied.
  */
 
 #include <linux/init.h>
diff --git a/arch/arm/mach-berlin/headsmp.S b/arch/arm/mach-berlin/headsmp.S
index dc82a3486b05..3057885d9772 100644
--- a/arch/arm/mach-berlin/headsmp.S
+++ b/arch/arm/mach-berlin/headsmp.S
@@ -1,11 +1,8 @@
+/* SPDX-License-Identifier: GPL-2.0 */
 /*
  * Copyright (C) 2014 Marvell Technology Group Ltd.
  *
  * Antoine T?nart <antoine.tenart@free-electrons.com>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
  */
 
 #include <linux/linkage.h>
diff --git a/arch/arm/mach-berlin/platsmp.c b/arch/arm/mach-berlin/platsmp.c
index a8ae4a566d99..593fc4a69d84 100644
--- a/arch/arm/mach-berlin/platsmp.c
+++ b/arch/arm/mach-berlin/platsmp.c
@@ -1,11 +1,8 @@
+// SPDX-License-Identifier: GPL-2.0
 /*
  * Copyright (C) 2014 Marvell Technology Group Ltd.
  *
  * Antoine T?nart <antoine.tenart@free-electrons.com>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
  */
 
 #include <linux/io.h>
-- 
2.17.0

^ permalink raw reply related

* [GIT PULL] Immutable branch between MFD and PWM due for the v4.18 merge window
From: Lee Jones @ 2018-05-16  8:19 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1526456161-27865-1-git-send-email-fabrice.gasnier@st.com>

Enjoy!

The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:

  Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git ib-mfd-pwm-v4.18

for you to fetch changes up to ab3a897847834bf3e864fb07b733c444895a24ba:

  pwm: stm32: Use input prescaler to improve period capture (2018-05-16 09:11:19 +0100)

----------------------------------------------------------------
Immutable branch between MFD and PWM due for the v4.18 merge window

----------------------------------------------------------------
Fabrice Gasnier (4):
      mfd: stm32-timers: Add support for DMAs
      pwm: stm32: Add capture support
      pwm: stm32: Improve capture by tuning counter prescaler
      pwm: stm32: Use input prescaler to improve period capture

 drivers/mfd/stm32-timers.c       | 201 +++++++++++++++++++++++++++++-
 drivers/pwm/pwm-stm32.c          | 257 +++++++++++++++++++++++++++++++++++++++
 include/linux/mfd/stm32-timers.h |  58 +++++++++
 3 files changed, 514 insertions(+), 2 deletions(-)
 
-- 
Lee Jones [???]
Linaro Services Technical Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox