Re: [RFC PATCH v1 0/2] send credit update during setting SO_RCVLOWAT

2023-11-15 Thread Stefano Garzarella
On Wed, Nov 08, 2023 at 10:20:02AM +0300, Arseniy Krasnov wrote: Hello, DESCRIPTION This patchset fixes old problem with hungup of both rx/tx sides and adds test for it. This happens due to non-default SO_RCVLOWAT value and deferred credit update in virtio/vsock. L

Re: [RFC PATCH v1 0/2] rk3318 A95X Z2 board

2020-06-25 Thread Johan Jonker
Hi, Status update. On 6/20/20 3:46 PM, Johan Jonker wrote: > status: EXPERIMENTAL > What works: > uart2 > mmc > emmc > sd card > usb2 /// USB2: The usb2 port only works reliable with: dr_mode = "host"; Question for Heiko: Should we change that in rk3328.

Re: [RFC PATCH v1 0/2] rk3318 A95X Z2 board

2020-06-22 Thread Johan Jonker
Hi, BUG report 1: About phy-rockchip-inno-usb2.c and rk3318. Goal is to use ttyUSB0 as console in combination with agetty as long as we don't have a working HDMI signal on a DVI monitor. Boot with rk3318 starts normal on emmc with U-boot OK. It then loads the kernel and initrd on SD card. Log vie

Re: [RFC PATCH v1 0/2] printk: Shared kernel logging

2016-09-30 Thread Kees Cook
On Fri, Sep 30, 2016 at 6:56 PM, Sean Hudson wrote: > On 9/29/2016 8:36 PM, Kees Cook wrote: >> On Thu, Sep 29, 2016 at 5:55 PM, Sean Hudson >> wrote: >>> This patch set is based on Linus' v4.8-rc8 tag. >>> >>> This debug feature allows the kernel to use an external buffer and >>> control block f

Re: [RFC PATCH v1 0/2] printk: Shared kernel logging

2016-09-30 Thread Sean Hudson
On 9/29/2016 8:36 PM, Kees Cook wrote: > On Thu, Sep 29, 2016 at 5:55 PM, Sean Hudson > wrote: >> This patch set is based on Linus' v4.8-rc8 tag. >> >> This debug feature allows the kernel to use an external buffer and >> control block for kernel log messages. The feature is controlled by >> an o

Re: [RFC PATCH v1 0/2] printk: Shared kernel logging

2016-09-29 Thread Kees Cook
On Thu, Sep 29, 2016 at 5:55 PM, Sean Hudson wrote: > This patch set is based on Linus' v4.8-rc8 tag. > > This debug feature allows the kernel to use an external buffer and control > block for kernel log messages. The feature is controlled by an optional > command line parameter. The existing buff

Re: [RFC PATCH v1 0/2] Add Hisilicon Djtag driver

2016-07-24 Thread Tan Xiaojun
On 2016/7/22 21:27, Arnd Bergmann wrote: > On Friday, July 22, 2016 11:56:49 AM CEST Mark Rutland wrote: >> Hi, >> >> I understand that some SoC/socket level PMU is accessed via these >> registers. It doesn't make sense to review either in isolation. Please >> put together a unified series, with bo

Re: [RFC PATCH v1 0/2] Add Hisilicon Djtag driver

2016-07-24 Thread Tan Xiaojun
On 2016/7/22 18:56, Mark Rutland wrote: > Hi, > > I understand that some SoC/socket level PMU is accessed via these > registers. It doesn't make sense to review either in isolation. Please > put together a unified series, with both the djtag accessors and the > PMU code. > > On it's own, it's *ve

Re: [RFC PATCH v1 0/2] Add Hisilicon Djtag driver

2016-07-22 Thread Arnd Bergmann
On Friday, July 22, 2016 11:56:49 AM CEST Mark Rutland wrote: > Hi, > > I understand that some SoC/socket level PMU is accessed via these > registers. It doesn't make sense to review either in isolation. Please > put together a unified series, with both the djtag accessors and the > PMU code. > >

Re: [RFC PATCH v1 0/2] Add Hisilicon Djtag driver

2016-07-22 Thread Mark Rutland
Hi, I understand that some SoC/socket level PMU is accessed via these registers. It doesn't make sense to review either in isolation. Please put together a unified series, with both the djtag accessors and the PMU code. On it's own, it's *very* difficult to understand how this fits into the SoC,

Re: [RFC PATCH v1 0/2]

2016-06-02 Thread Daniel Vetter
On Wed, Jun 01, 2016 at 10:54:09AM +0800, Yakir Yang wrote: > Hi Daniel, > > On 05/31/2016 10:38 PM, Daniel Vetter wrote: > > On Tue, May 31, 2016 at 09:37:36PM +0800, Yakir Yang wrote: > > > The full name of PSR is Panel Self Refresh, panel device could refresh > > > itself with the hardware fram

Re: [RFC PATCH v1 0/2]

2016-05-31 Thread Yakir Yang
Hi Daniel, On 05/31/2016 10:38 PM, Daniel Vetter wrote: On Tue, May 31, 2016 at 09:37:36PM +0800, Yakir Yang wrote: The full name of PSR is Panel Self Refresh, panel device could refresh itself with the hardware framebuffer in panel, this would make a lots of sense to save the power consumption

Re: [RFC PATCH v1 0/2]

2016-05-31 Thread Daniel Vetter
On Tue, May 31, 2016 at 09:37:36PM +0800, Yakir Yang wrote: > The full name of PSR is Panel Self Refresh, panel device could refresh > itself with the hardware framebuffer in panel, this would make a lots > of sense to save the power consumption. > > For example, when desktop haven't change the co

Re: [RFC PATCH v1 0/2] Introduce Innosilicon HDMI driver on Rockchip platforms

2015-12-20 Thread Yakir Yang
Hi Mark On 12/21/2015 03:25 PM, Mark yao wrote: Hi Yakir I want to convert drm/rockchip to support atomic api, I'd like you can do some modify to adapt it. Sure, would update as soon as possible. Thanks, - Yakir - Mark On 2015年11月11日 15:45, Yakir Yang wrote: Hi guys: Here are a

Re: [RFC PATCH v1 0/2] Introduce Innosilicon HDMI driver on Rockchip platforms

2015-12-20 Thread Mark yao
Hi Yakir I want to convert drm/rockchip to support atomic api, I'd like you can do some modify to adapt it. - Mark On 2015年11月11日 15:45, Yakir Yang wrote: Hi guys: Here are a brief introduction to Innosilicon HDMI IP: - Support HDMI 1.4a, HDCP 1.2 and DVI 1.0 standard compliant trans

Re: [RFC PATCH v1 0/2] perf: Support for SDT markers

2014-02-26 Thread Hemant Kumar
On 02/26/2014 03:12 PM, Masami Hiramatsu wrote: (2014/02/26 18:03), Hemant Kumar wrote: On 02/26/2014 01:48 PM, Namhyung Kim wrote: Hi Masami and Hemant, On Tue, 25 Feb 2014 21:27:07 +0530, Hemant Kumar wrote: On 02/25/2014 05:14 PM, Masami Hiramatsu wrote: (2014/02/24 18:14), Hemant Kumar w

Re: Re: [RFC PATCH v1 0/2] perf: Support for SDT markers

2014-02-26 Thread Masami Hiramatsu
(2014/02/26 18:03), Hemant Kumar wrote: > On 02/26/2014 01:48 PM, Namhyung Kim wrote: >> Hi Masami and Hemant, >> >> On Tue, 25 Feb 2014 21:27:07 +0530, Hemant Kumar wrote: >>> On 02/25/2014 05:14 PM, Masami Hiramatsu wrote: (2014/02/24 18:14), Hemant Kumar wrote: > First, scan the binarie

Re: Re: [RFC PATCH v1 0/2] perf: Support for SDT markers

2014-02-26 Thread Masami Hiramatsu
(2014/02/26 17:18), Namhyung Kim wrote: > Hi Masami and Hemant, > > On Tue, 25 Feb 2014 21:27:07 +0530, Hemant Kumar wrote: >> On 02/25/2014 05:14 PM, Masami Hiramatsu wrote: >>> (2014/02/24 18:14), Hemant Kumar wrote: First, scan the binaries using : # perf list sdt --scan Cre

Re: [RFC PATCH v1 0/2] perf: Support for SDT markers

2014-02-26 Thread Hemant Kumar
On 02/26/2014 01:48 PM, Namhyung Kim wrote: Hi Masami and Hemant, On Tue, 25 Feb 2014 21:27:07 +0530, Hemant Kumar wrote: On 02/25/2014 05:14 PM, Masami Hiramatsu wrote: (2014/02/24 18:14), Hemant Kumar wrote: First, scan the binaries using : # perf list sdt --scan Creating a cache of SDT ma

Re: [RFC PATCH v1 0/2] perf: Support for SDT markers

2014-02-26 Thread Namhyung Kim
Hi Masami and Hemant, On Tue, 25 Feb 2014 21:27:07 +0530, Hemant Kumar wrote: > On 02/25/2014 05:14 PM, Masami Hiramatsu wrote: >> (2014/02/24 18:14), Hemant Kumar wrote: >>> First, scan the binaries using : >>> # perf list sdt --scan >>> >>> Creating a cache of SDT markers... >>> perf sdt cache c

Re: [RFC PATCH v1 0/2] perf: Support for SDT markers

2014-02-25 Thread Hemant Kumar
On 02/25/2014 05:14 PM, Masami Hiramatsu wrote: (2014/02/24 18:14), Hemant Kumar wrote: This patchset helps in listing dtrace style markers(SDT) present in user space applications through perf. Notes/markers are placed at important places by the developers. They have a negligible overhead when n

Re: [RFC PATCH v1 0/2] perf: Support for SDT markers

2014-02-25 Thread Masami Hiramatsu
(2014/02/24 18:14), Hemant Kumar wrote: > This patchset helps in listing dtrace style markers(SDT) present in user space > applications through perf. > Notes/markers are placed at important places by the > developers. They have a negligible overhead when not enabled. > We can enable them and probe