Re: [PATCH v12 10/11] sparc64: Add support for ADI (Application Data Integrity)

[Khalid Aziz]

On 02/23/2018 11:57 AM, David Miller wrote:

From: Khalid Aziz <khalid.a...@oracle.com>
Date: Fri, 23 Feb 2018 11:51:25 -0700


On 02/22/2018 07:50 PM, kbuild test robot wrote:

Hi Khalid,
I love your patch! Yet something to improve:
[auto build test ERROR on sparc-next/master]
[also build test ERROR on v4.16-rc2]
[cannot apply to next-20180222]
[if your patch is applied to the wrong git tree, please drop us a note
to help improve the system]
url:
https://github.com/0day-ci/linux/commits/Khalid-Aziz/Application-Data-Integrity-feature-introduced-by-SPARC-M7/20180223-071725
base:
https://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc-next.git
master
config: sparc64-allyesconfig (attached as .config)
compiler: sparc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
  wget
  
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross
  -O ~/bin/make.cross
  chmod +x ~/bin/make.cross
  # save the attached .config to linux build tree
  make.cross ARCH=sparc64
All error/warnings (new ones prefixed by >>):


Hi Dave,

Including linux/sched.h in arch/sparc/include/asm/mmu_context.h should
eliminate these build warnings. My gcc version 6.2.1 does not report
these errors. Build bot is using 7.2.0.

I can add a patch 12 to add the include, revise patch 10 or you can
add the include in your tree. Let me know how you would prefer to
resolve this.


You need to update patch #10 so that your patch series is fully
bisectable.


Hi Dave,

That sounds like the right thing to do. I am updating patch 10 and will 
send out v13 for patch 10/11. Rest of the series is unchanged but I can 
send the whole series if you prefer that.


Thanks,
Khalid
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

response

[Ms. Ella Golan]

I am Ms.Ella Golan, I am the Executive Vice President Banking Division with 
FIRST INTERNATIONAL BANK OF ISRAEL LTD (FIBI). I am getting in touch with you 
regarding an extremely important and urgent matter. If you would oblige me the 
opportunity, I shall provide you with details upon your response.

Faithfully,
Ms.Ella Golan
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 7/8] [PATCH 7/8] drivers/hwmon: Add a generic PECI hwmon client driver

[Miguel Ojeda]

On Thu, Feb 22, 2018 at 2:29 AM, Jae Hyun Yoo
 wrote:
> On 2/21/2018 4:37 PM, Andrew Lunn wrote:
>>>
>>> But even with this change, it still needs to use delayed creation
>>> because BMC side kernel doesn't know how many DIMMs are populated on
>>> a remote server before the remote server completes its memory
>>> training and testing in BIOS, but it needs to check the remote
>>> server's CPU temperature as immediate as possible to make
>>> appropriate thermal control based on the remote CPU's temperature to
>>> avoid any critical thermal issue. What would be a better solution in
>>> this case?
>>
>>
>> You could change this driver so that it supports one DIMM.  Move the
>> 'hotplug' part into another driver which creates and destroys
>> instances of the hwmon DIMM device as the DIMMS come and go.
>>
>> Also, do you need to handle CPU hotplug? You could split the CPU
>> temperature part into a separate hwmon driver? And again create and
>> destroy devices as CPUs come and go?
>>
>> Andrew
>>
>
> That seems like a possible option. I'll rewrite the hwmon driver again like
> that.
>
> Thanks for the good idea. :)

By the way, in the rewrite, please try to avoid the create*workqueue()
functions (they are deprecated :).

Cheers,
Miguel

>
> Jae
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/7] i3c: Add core I3C infrastructure

[Boris Brezillon]

On Fri, 23 Feb 2018 16:56:14 +
Vitor Soares  wrote:


> > +
> > +/**
> > + * struct i3c_ccc_setda - payload passed to ENTTM CCC
> > + *
> > + * @mode: one of the  i3c_ccc_test_mode modes
> > + *
> > + * Information passed to the ENTTM CCC to instruct an I3C device to enter a
> > + * specific test mode.

Oops, copy error. I'll fix the kernel-doc header.

> > + */
> > +struct i3c_ccc_setda {
> > +   u8 addr;
> > +} __packed;  
> 
>  what do you mean with struct? Maybe setdasa? if so, what is the addr?

It's the payload passed to SETDASA and SETNEWDA, hence the generic
_setda suffix. addr is the new dynamic address assigned to the
device.



-- 
Boris Brezillon, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 1/4] drm: Add writeback connector type

[Sean Paul]

On Fri, Feb 23, 2018 at 04:48:58PM +, Liviu Dudau wrote:
> On Fri, Feb 23, 2018 at 11:43:29AM -0500, Sean Paul wrote:
> > On Fri, Feb 23, 2018 at 11:25:11AM -0500, Rob Clark wrote:
> > > On Fri, Feb 23, 2018 at 10:59 AM, Sean Paul  wrote:
> > > >
> > > > Have we considered hiding writeback behind a client cap instead?
> > > 
> > > It is kinda *almost* unneeded, since the connector reports itself as
> > > disconnected.
> > > 
> > > I'm not sure what the reason was to drop the cap, but I think it would
> > > be better to have a cap so WB connectors don't show up in, for ex,
> > > xrandr
> > 
> > Yeah, the disconnected hack is kind of gross, IMO. I hate to introduce 
> > churn in
> > the patch series given that it was initially introduced with the client cap.
> 
> Haha, that's the reverse of Daniel's position:
> 
> https://lists.freedesktop.org/archives/dri-devel/2016-October/120519.html

Yeah, it happens :(. I don't think it's a dealbreaker either way, it just seems
awkward to expose a connector which is "disconnected", but available for use. I
don't think we have any other connectors which are supposed to be used in this
state.

> 
> > 
> > There are also cases where we might want to make writeback unavailable, 
> > such as
> > when content protection is enabled. In those cases, it's conceivable that we
> > might want to use disconnected as a signal to u/s. I suppose we could also 
> > just
> > fail the check, so most of this is just academic.
> 
> Not sure what other hardware out there does, but on Mali DP's case you
> would be outputing the protected content by putting the display
> processor in secure mode, which automatically disables writeback for us.
> Or to put in another way, you don't need a writeback framebuffer if you
> are in non-secure mode as you can get access to the framebuffer used for
> the plane anyway.

Yeah, I was mostly thinking about the case where you might have HDCP enabled on
the HDMI connector and be able to slurp up the content via a writeback. However
if the buffer is not secure in the first place, then it's already accessible in
userspace so I don't think that writeback presents a new security hole.

/me needs to get HDCP out of his head.

Sean


> 
> Best regards,
> Liviu
> 
> > 
> > Sean
> > 
> > 
> > > 
> > > BR,
> > > -R
> > 
> > -- 
> > Sean Paul, Software Engineer, Google / Chromium OS
> 
> -- 
> 
> | I would like to |
> | fix the world,  |
> | but they're not |
> | giving me the   |
>  \ source code!  /
>   ---
> ¯\_(ツ)_/¯

-- 
Sean Paul, Software Engineer, Google / Chromium OS
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 1/4] drm: Add writeback connector type

[Liviu Dudau]

On Fri, Feb 23, 2018 at 10:59:35AM -0500, Sean Paul wrote:
> On Fri, Feb 23, 2018 at 08:17:51AM -0500, Rob Clark wrote:
> > From: Brian Starkey 
> > 
> > Writeback connectors represent writeback engines which can write the
> > CRTC output to a memory framebuffer. Add a writeback connector type and
> > related support functions.
> > 
> > Drivers should initialize a writeback connector with
> > drm_writeback_connector_init() which takes care of setting up all the
> > writeback-specific details on top of the normal functionality of
> > drm_connector_init().
> > 
> > Writeback connectors have a WRITEBACK_FB_ID property, used to set the
> > output framebuffer, and a WRITEBACK_PIXEL_FORMATS blob used to expose the
> > supported writeback formats to userspace.
> > 
> > When a framebuffer is attached to a writeback connector with the
> > WRITEBACK_FB_ID property, it is used only once (for the commit in which
> > it was included), and userspace can never read back the value of
> > WRITEBACK_FB_ID. WRITEBACK_FB_ID can only be set if the connector is
> > attached to a CRTC.
> > 
> > Changes since v1:
> >  - Added drm_writeback.c + documentation
> >  - Added helper to initialize writeback connector in one go
> >  - Added core checks
> >  - Squashed into a single commit
> >  - Dropped the client cap
> >  - Writeback framebuffers are no longer persistent
> > 
> > Changes since v2:
> >  Daniel Vetter:
> >  - Subclass drm_connector to drm_writeback_connector
> >  - Relax check to allow CRTC to be set without an FB
> >  - Add some writeback_ prefixes
> >  - Drop PIXEL_FORMATS_SIZE property, as it was unnecessary
> >  Gustavo Padovan:
> >  - Add drm_writeback_job to handle writeback signalling centrally
> > 
> > Changes since v3:
> >  - Rebased
> >  - Rename PIXEL_FORMATS -> WRITEBACK_PIXEL_FORMATS
> > 
> > Changes since v4:
> >  - Added atomic_commit() vfunc to connector helper funcs, so that
> >writeback jobs are committed from atomic helpers
> > 
> > Signed-off-by: Brian Starkey 
> > [rebased and fixed conflicts]
> > Signed-off-by: Mihail Atanassov 
> > Signed-off-by: Liviu Dudau 
> > [rebased and added atomic_commit() vfunc for writeback jobs]
> > Signed-off-by: Rob Clark 
> > ---
> >  Documentation/gpu/drm-kms.rst|   9 ++
> >  drivers/gpu/drm/Makefile |   2 +-
> >  drivers/gpu/drm/drm_atomic.c | 130 
> >  drivers/gpu/drm/drm_atomic_helper.c  |  30 
> >  drivers/gpu/drm/drm_connector.c  |   4 +-
> >  drivers/gpu/drm/drm_writeback.c  | 257 
> > +++
> >  include/drm/drm_atomic.h |   3 +
> >  include/drm/drm_connector.h  |  13 ++
> >  include/drm/drm_mode_config.h|  14 ++
> >  include/drm/drm_modeset_helper_vtables.h |  11 ++
> >  include/drm/drm_writeback.h  |  89 +++
> >  include/uapi/drm/drm_mode.h  |   1 +
> >  12 files changed, 561 insertions(+), 2 deletions(-)
> >  create mode 100644 drivers/gpu/drm/drm_writeback.c
> >  create mode 100644 include/drm/drm_writeback.h
> > 
> > diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
> > index 2dcf5b42015d..e7590dd2f71e 100644
> > --- a/Documentation/gpu/drm-kms.rst
> > +++ b/Documentation/gpu/drm-kms.rst
> > @@ -370,6 +370,15 @@ Connector Functions Reference
> >  .. kernel-doc:: drivers/gpu/drm/drm_connector.c
> > :export:
> >  
> > +Writeback Connectors
> > +
> > +
> > +.. kernel-doc:: drivers/gpu/drm/drm_writeback.c
> > +  :doc: overview
> > +
> > +.. kernel-doc:: drivers/gpu/drm/drm_writeback.c
> > +  :export:
> > +
> >  Encoder Abstraction
> >  ===
> >  
> > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> > index 50093ff4479b..3d708959b224 100644
> > --- a/drivers/gpu/drm/Makefile
> > +++ b/drivers/gpu/drm/Makefile
> > @@ -18,7 +18,7 @@ drm-y   :=drm_auth.o drm_bufs.o drm_cache.o \
> > drm_encoder.o drm_mode_object.o drm_property.o \
> > drm_plane.o drm_color_mgmt.o drm_print.o \
> > drm_dumb_buffers.o drm_mode_config.o drm_vblank.o \
> > -   drm_syncobj.o drm_lease.o
> > +   drm_syncobj.o drm_lease.o drm_writeback.o
> >  
> >  drm-$(CONFIG_DRM_LIB_RANDOM) += lib/drm_random.o
> >  drm-$(CONFIG_DRM_VM) += drm_vm.o
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index 46733d534587..019f131fe8be 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -30,6 +30,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  
> >  #include "drm_crtc_internal.h"
> > @@ -638,6 +639,46 @@ static void drm_atomic_crtc_print_state(struct 
> > drm_printer *p,
> > crtc->funcs->atomic_print_state(p, state);
> >  }
> >  
> > +/**
> > + * 

Re: [v2, 7/7] tty: serial: msm_geni_serial: Add serial driver support for GENI based QUP

[Guenter Roeck]

On Fri, Jan 12, 2018 at 06:05:47PM -0700, Karthikeyan Ramasubramanian wrote:
> This driver supports GENI based UART Controller in the Qualcomm SOCs. The
> Qualcomm Generic Interface (GENI) is a programmable module supporting a
> wide range of serial interfaces including UART. This driver support console
> operations using FIFO mode of transfer.
> 
> Signed-off-by: Girish Mahadevan 
> Signed-off-by: Karthikeyan Ramasubramanian 
> Signed-off-by: Sagar Dharia 
> ---
>  drivers/tty/serial/Kconfig|   10 +
>  drivers/tty/serial/Makefile   |1 +
>  drivers/tty/serial/qcom_geni_serial.c | 1414 
> +
>  3 files changed, 1425 insertions(+)
>  create mode 100644 drivers/tty/serial/qcom_geni_serial.c
> 
> diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
> index b788fee..1be30e5 100644
> --- a/drivers/tty/serial/Kconfig
> +++ b/drivers/tty/serial/Kconfig
> @@ -1098,6 +1098,16 @@ config SERIAL_MSM_CONSOLE
>   select SERIAL_CORE_CONSOLE
>   select SERIAL_EARLYCON
>  
> +config SERIAL_QCOM_GENI
> + tristate "QCOM on-chip GENI based serial port support"
> + depends on ARCH_QCOM
> + select SERIAL_CORE
> + select SERIAL_CORE_CONSOLE

Serial console drivers have to be bool, not tristate.
Building a console driver as module doesn't make sense
(it is needed before modules are loaded). It also results
in a build failure due to a symbol which is not exported.

> + select SERIAL_EARLYCON
> + help
> +   Serial driver for Qualcomm Technologies Inc's GENI based QUP
> +   hardware.
> +
>  config SERIAL_VT8500
>   bool "VIA VT8500 on-chip serial port support"
>   depends on ARCH_VT8500
> diff --git a/drivers/tty/serial/Makefile b/drivers/tty/serial/Makefile
> index 842d185..64a8d82 100644
> --- a/drivers/tty/serial/Makefile
> +++ b/drivers/tty/serial/Makefile
> @@ -63,6 +63,7 @@ obj-$(CONFIG_SERIAL_SGI_IOC3) += ioc3_serial.o
>  obj-$(CONFIG_SERIAL_ATMEL) += atmel_serial.o
>  obj-$(CONFIG_SERIAL_UARTLITE) += uartlite.o
>  obj-$(CONFIG_SERIAL_MSM) += msm_serial.o
> +obj-$(CONFIG_SERIAL_QCOM_GENI) += qcom_geni_serial.o
>  obj-$(CONFIG_SERIAL_NETX) += netx-serial.o
>  obj-$(CONFIG_SERIAL_KS8695) += serial_ks8695.o
>  obj-$(CONFIG_SERIAL_OMAP) += omap-serial.o
> diff --git a/drivers/tty/serial/qcom_geni_serial.c 
> b/drivers/tty/serial/qcom_geni_serial.c
> new file mode 100644
> index 000..0dbd329
> --- /dev/null
> +++ b/drivers/tty/serial/qcom_geni_serial.c
> @@ -0,0 +1,1414 @@
> +/*
> + * Copyright (c) 2017-2018, The Linux foundation. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only version 2 as published by the Free Software Foundation.
> + *
> + * 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.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* UART specific GENI registers */
> +#define SE_UART_TX_TRANS_CFG (0x25C)
> +#define SE_UART_TX_WORD_LEN  (0x268)
> +#define SE_UART_TX_STOP_BIT_LEN  (0x26C)
> +#define SE_UART_TX_TRANS_LEN (0x270)
> +#define SE_UART_RX_TRANS_CFG (0x280)
> +#define SE_UART_RX_WORD_LEN  (0x28C)
> +#define SE_UART_RX_STALE_CNT (0x294)
> +#define SE_UART_TX_PARITY_CFG(0x2A4)
> +#define SE_UART_RX_PARITY_CFG(0x2A8)
> +
> +/* SE_UART_TRANS_CFG */
> +#define UART_TX_PAR_EN   (BIT(0))
> +#define UART_CTS_MASK(BIT(1))
> +
> +/* SE_UART_TX_WORD_LEN */
> +#define TX_WORD_LEN_MSK  (GENMASK(9, 0))
> +
> +/* SE_UART_TX_STOP_BIT_LEN */
> +#define TX_STOP_BIT_LEN_MSK  (GENMASK(23, 0))
> +#define TX_STOP_BIT_LEN_1(0)
> +#define TX_STOP_BIT_LEN_1_5  (1)
> +#define TX_STOP_BIT_LEN_2(2)
> +
> +/* SE_UART_TX_TRANS_LEN */
> +#define TX_TRANS_LEN_MSK (GENMASK(23, 0))
> +
> +/* SE_UART_RX_TRANS_CFG */
> +#define UART_RX_INS_STATUS_BIT   (BIT(2))
> +#define UART_RX_PAR_EN   (BIT(3))
> +
> +/* SE_UART_RX_WORD_LEN */
> +#define RX_WORD_LEN_MASK (GENMASK(9, 0))
> +
> +/* SE_UART_RX_STALE_CNT */
> +#define RX_STALE_CNT (GENMASK(23, 0))
> +
> +/* SE_UART_TX_PARITY_CFG/RX_PARITY_CFG */
> +#define PAR_CALC_EN  (BIT(0))
> +#define PAR_MODE_MSK (GENMASK(2, 1))
> +#define PAR_MODE_SHFT(1)
> +#define PAR_EVEN (0x00)
> +#define PAR_ODD  (0x01)
> +#define PAR_SPACE(0x10)
> +#define PAR_MARK (0x11)
> +
> 

Re: [RFC 1/4] drm: Add writeback connector type

[Sean Paul]

On Fri, Feb 23, 2018 at 04:21:05PM +, Liviu Dudau wrote:
> On Fri, Feb 23, 2018 at 10:59:35AM -0500, Sean Paul wrote:
> > On Fri, Feb 23, 2018 at 08:17:51AM -0500, Rob Clark wrote:
> > > From: Brian Starkey 
> > > 
> > > Writeback connectors represent writeback engines which can write the
> > > CRTC output to a memory framebuffer. Add a writeback connector type and
> > > related support functions.
> > > 
> > > Drivers should initialize a writeback connector with
> > > drm_writeback_connector_init() which takes care of setting up all the
> > > writeback-specific details on top of the normal functionality of
> > > drm_connector_init().
> > > 
> > > Writeback connectors have a WRITEBACK_FB_ID property, used to set the
> > > output framebuffer, and a WRITEBACK_PIXEL_FORMATS blob used to expose the
> > > supported writeback formats to userspace.
> > > 
> > > When a framebuffer is attached to a writeback connector with the
> > > WRITEBACK_FB_ID property, it is used only once (for the commit in which
> > > it was included), and userspace can never read back the value of
> > > WRITEBACK_FB_ID. WRITEBACK_FB_ID can only be set if the connector is
> > > attached to a CRTC.
> > > 
> > > Changes since v1:
> > >  - Added drm_writeback.c + documentation
> > >  - Added helper to initialize writeback connector in one go
> > >  - Added core checks
> > >  - Squashed into a single commit
> > >  - Dropped the client cap
> > >  - Writeback framebuffers are no longer persistent
> > > 
> > > Changes since v2:
> > >  Daniel Vetter:
> > >  - Subclass drm_connector to drm_writeback_connector
> > >  - Relax check to allow CRTC to be set without an FB
> > >  - Add some writeback_ prefixes
> > >  - Drop PIXEL_FORMATS_SIZE property, as it was unnecessary
> > >  Gustavo Padovan:
> > >  - Add drm_writeback_job to handle writeback signalling centrally
> > > 
> > > Changes since v3:
> > >  - Rebased
> > >  - Rename PIXEL_FORMATS -> WRITEBACK_PIXEL_FORMATS
> > > 
> > > Changes since v4:
> > >  - Added atomic_commit() vfunc to connector helper funcs, so that
> > >writeback jobs are committed from atomic helpers
> > > 
> > > Signed-off-by: Brian Starkey 
> > > [rebased and fixed conflicts]
> > > Signed-off-by: Mihail Atanassov 
> > > Signed-off-by: Liviu Dudau 
> > > [rebased and added atomic_commit() vfunc for writeback jobs]
> > > Signed-off-by: Rob Clark 
> > > ---
> > >  Documentation/gpu/drm-kms.rst|   9 ++
> > >  drivers/gpu/drm/Makefile |   2 +-
> > >  drivers/gpu/drm/drm_atomic.c | 130 
> > >  drivers/gpu/drm/drm_atomic_helper.c  |  30 
> > >  drivers/gpu/drm/drm_connector.c  |   4 +-
> > >  drivers/gpu/drm/drm_writeback.c  | 257 
> > > +++
> > >  include/drm/drm_atomic.h |   3 +
> > >  include/drm/drm_connector.h  |  13 ++
> > >  include/drm/drm_mode_config.h|  14 ++
> > >  include/drm/drm_modeset_helper_vtables.h |  11 ++
> > >  include/drm/drm_writeback.h  |  89 +++
> > >  include/uapi/drm/drm_mode.h  |   1 +
> > >  12 files changed, 561 insertions(+), 2 deletions(-)
> > >  create mode 100644 drivers/gpu/drm/drm_writeback.c
> > >  create mode 100644 include/drm/drm_writeback.h
> > > 
> > > diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
> > > index 2dcf5b42015d..e7590dd2f71e 100644
> > > --- a/Documentation/gpu/drm-kms.rst
> > > +++ b/Documentation/gpu/drm-kms.rst
> > > @@ -370,6 +370,15 @@ Connector Functions Reference
> > >  .. kernel-doc:: drivers/gpu/drm/drm_connector.c
> > > :export:
> > >  
> > > +Writeback Connectors
> > > +
> > > +
> > > +.. kernel-doc:: drivers/gpu/drm/drm_writeback.c
> > > +  :doc: overview
> > > +
> > > +.. kernel-doc:: drivers/gpu/drm/drm_writeback.c
> > > +  :export:
> > > +
> > >  Encoder Abstraction
> > >  ===
> > >  
> > > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> > > index 50093ff4479b..3d708959b224 100644
> > > --- a/drivers/gpu/drm/Makefile
> > > +++ b/drivers/gpu/drm/Makefile
> > > @@ -18,7 +18,7 @@ drm-y   :=  drm_auth.o drm_bufs.o drm_cache.o \
> > >   drm_encoder.o drm_mode_object.o drm_property.o \
> > >   drm_plane.o drm_color_mgmt.o drm_print.o \
> > >   drm_dumb_buffers.o drm_mode_config.o drm_vblank.o \
> > > - drm_syncobj.o drm_lease.o
> > > + drm_syncobj.o drm_lease.o drm_writeback.o
> > >  
> > >  drm-$(CONFIG_DRM_LIB_RANDOM) += lib/drm_random.o
> > >  drm-$(CONFIG_DRM_VM) += drm_vm.o
> > > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > > index 46733d534587..019f131fe8be 100644
> > > --- a/drivers/gpu/drm/drm_atomic.c
> > > +++ b/drivers/gpu/drm/drm_atomic.c
> > > @@ -30,6 +30,7 @@
> > >  #include 
> > >  #include 
> > >  

response

[Ms. Ella Golan]

I am Ms.Ella Golan, I am the Executive Vice President Banking Division with 
FIRST INTERNATIONAL BANK OF ISRAEL LTD (FIBI). I am getting in touch with you 
regarding an extremely important and urgent matter. If you would oblige me the 
opportunity, I shall provide you with details upon your response.

Faithfully,
Ms.Ella Golan
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 1/4] drm: Add writeback connector type

[Sean Paul]

On Fri, Feb 23, 2018 at 11:25:11AM -0500, Rob Clark wrote:
> On Fri, Feb 23, 2018 at 10:59 AM, Sean Paul  wrote:
> >
> > Have we considered hiding writeback behind a client cap instead?
> 
> It is kinda *almost* unneeded, since the connector reports itself as
> disconnected.
> 
> I'm not sure what the reason was to drop the cap, but I think it would
> be better to have a cap so WB connectors don't show up in, for ex,
> xrandr

Yeah, the disconnected hack is kind of gross, IMO. I hate to introduce churn in
the patch series given that it was initially introduced with the client cap.

There are also cases where we might want to make writeback unavailable, such as
when content protection is enabled. In those cases, it's conceivable that we
might want to use disconnected as a signal to u/s. I suppose we could also just
fail the check, so most of this is just academic.

Sean


> 
> BR,
> -R

-- 
Sean Paul, Software Engineer, Google / Chromium OS
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] doc-guide: kernel-doc: add comment about formatting verification

[Jonathan Corbet]

On Tue, 20 Feb 2018 20:36:25 +0200
Mike Rapoport  wrote:

> Currently there is no automated checking for kernel-doc comments except
> running 'kernel-doc -v -none '. Mention the possibility to run
> kernel-doc to verify formatting of the comments in the kernel-doc guide.
> 
> Signed-off-by: Mike Rapoport 

Applied, thanks.

jon
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] block/loop: add documentation for sysfs interface

[Jonathan Corbet]

On Sat, 17 Feb 2018 11:43:04 +0530
Aishwarya Pant  wrote:

> Documentation has been compiled from git logs and by reading through
> code.
> 
> Signed-off-by: Aishwarya Pant 
> ---
> For drivers/block/loop.c, I don't see any maintainers or mailing lists except
> for LKML. I am guessing linux-block mailing list should be okay.
> 
> Changes in v2:
> - Add linux-bl...@vger.kernel.org to the recipient list.

Applied to the docs tree, thanks.

jon
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] Documentation: rapidio: move sysfs interface to ABI

[Jonathan Corbet]

On Fri, 19 Jan 2018 18:01:47 +0530
Aishwarya Pant  wrote:

> Right now, the description of the rapidio sysfs interfaces is in
> Documentation/rapidio/sysfs.txt. Since these are a part of the ABI, they
> should be in Documentation/ABI along with the rest.
> 
> Signed-off-by: Aishwarya Pant 

Applied to the docs tree, thanks.

jon
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 1/4] drm: Add writeback connector type

[Liviu Dudau]

On Fri, Feb 23, 2018 at 11:43:29AM -0500, Sean Paul wrote:
> On Fri, Feb 23, 2018 at 11:25:11AM -0500, Rob Clark wrote:
> > On Fri, Feb 23, 2018 at 10:59 AM, Sean Paul  wrote:
> > >
> > > Have we considered hiding writeback behind a client cap instead?
> > 
> > It is kinda *almost* unneeded, since the connector reports itself as
> > disconnected.
> > 
> > I'm not sure what the reason was to drop the cap, but I think it would
> > be better to have a cap so WB connectors don't show up in, for ex,
> > xrandr
> 
> Yeah, the disconnected hack is kind of gross, IMO. I hate to introduce churn 
> in
> the patch series given that it was initially introduced with the client cap.

Haha, that's the reverse of Daniel's position:

https://lists.freedesktop.org/archives/dri-devel/2016-October/120519.html

> 
> There are also cases where we might want to make writeback unavailable, such 
> as
> when content protection is enabled. In those cases, it's conceivable that we
> might want to use disconnected as a signal to u/s. I suppose we could also 
> just
> fail the check, so most of this is just academic.

Not sure what other hardware out there does, but on Mali DP's case you
would be outputing the protected content by putting the display
processor in secure mode, which automatically disables writeback for us.
Or to put in another way, you don't need a writeback framebuffer if you
are in non-secure mode as you can get access to the framebuffer used for
the plane anyway.

Best regards,
Liviu

> 
> Sean
> 
> 
> > 
> > BR,
> > -R
> 
> -- 
> Sean Paul, Software Engineer, Google / Chromium OS

-- 

| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---
¯\_(ツ)_/¯
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 1/4] drm: Add writeback connector type

[Liviu Dudau]

On Fri, Feb 23, 2018 at 11:39:06AM -0500, Sean Paul wrote:
> On Fri, Feb 23, 2018 at 04:21:05PM +, Liviu Dudau wrote:
> > On Fri, Feb 23, 2018 at 10:59:35AM -0500, Sean Paul wrote:
> > > On Fri, Feb 23, 2018 at 08:17:51AM -0500, Rob Clark wrote:
> > > > From: Brian Starkey 
> > > > 
> > > > Writeback connectors represent writeback engines which can write the
> > > > CRTC output to a memory framebuffer. Add a writeback connector type and
> > > > related support functions.
> > > > 
> > > > Drivers should initialize a writeback connector with
> > > > drm_writeback_connector_init() which takes care of setting up all the
> > > > writeback-specific details on top of the normal functionality of
> > > > drm_connector_init().
> > > > 
> > > > Writeback connectors have a WRITEBACK_FB_ID property, used to set the
> > > > output framebuffer, and a WRITEBACK_PIXEL_FORMATS blob used to expose 
> > > > the
> > > > supported writeback formats to userspace.
> > > > 
> > > > When a framebuffer is attached to a writeback connector with the
> > > > WRITEBACK_FB_ID property, it is used only once (for the commit in which
> > > > it was included), and userspace can never read back the value of
> > > > WRITEBACK_FB_ID. WRITEBACK_FB_ID can only be set if the connector is
> > > > attached to a CRTC.
> > > > 
> > > > Changes since v1:
> > > >  - Added drm_writeback.c + documentation
> > > >  - Added helper to initialize writeback connector in one go
> > > >  - Added core checks
> > > >  - Squashed into a single commit
> > > >  - Dropped the client cap
> > > >  - Writeback framebuffers are no longer persistent
> > > > 
> > > > Changes since v2:
> > > >  Daniel Vetter:
> > > >  - Subclass drm_connector to drm_writeback_connector
> > > >  - Relax check to allow CRTC to be set without an FB
> > > >  - Add some writeback_ prefixes
> > > >  - Drop PIXEL_FORMATS_SIZE property, as it was unnecessary
> > > >  Gustavo Padovan:
> > > >  - Add drm_writeback_job to handle writeback signalling centrally
> > > > 
> > > > Changes since v3:
> > > >  - Rebased
> > > >  - Rename PIXEL_FORMATS -> WRITEBACK_PIXEL_FORMATS
> > > > 
> > > > Changes since v4:
> > > >  - Added atomic_commit() vfunc to connector helper funcs, so that
> > > >writeback jobs are committed from atomic helpers
> > > > 
> > > > Signed-off-by: Brian Starkey 
> > > > [rebased and fixed conflicts]
> > > > Signed-off-by: Mihail Atanassov 
> > > > Signed-off-by: Liviu Dudau 
> > > > [rebased and added atomic_commit() vfunc for writeback jobs]
> > > > Signed-off-by: Rob Clark 
> > > > ---
> > > >  Documentation/gpu/drm-kms.rst|   9 ++
> > > >  drivers/gpu/drm/Makefile |   2 +-
> > > >  drivers/gpu/drm/drm_atomic.c | 130 
> > > >  drivers/gpu/drm/drm_atomic_helper.c  |  30 
> > > >  drivers/gpu/drm/drm_connector.c  |   4 +-
> > > >  drivers/gpu/drm/drm_writeback.c  | 257 
> > > > +++
> > > >  include/drm/drm_atomic.h |   3 +
> > > >  include/drm/drm_connector.h  |  13 ++
> > > >  include/drm/drm_mode_config.h|  14 ++
> > > >  include/drm/drm_modeset_helper_vtables.h |  11 ++
> > > >  include/drm/drm_writeback.h  |  89 +++
> > > >  include/uapi/drm/drm_mode.h  |   1 +
> > > >  12 files changed, 561 insertions(+), 2 deletions(-)
> > > >  create mode 100644 drivers/gpu/drm/drm_writeback.c
> > > >  create mode 100644 include/drm/drm_writeback.h
> > > > 
> > > > diff --git a/Documentation/gpu/drm-kms.rst 
> > > > b/Documentation/gpu/drm-kms.rst
> > > > index 2dcf5b42015d..e7590dd2f71e 100644
> > > > --- a/Documentation/gpu/drm-kms.rst
> > > > +++ b/Documentation/gpu/drm-kms.rst
> > > > @@ -370,6 +370,15 @@ Connector Functions Reference
> > > >  .. kernel-doc:: drivers/gpu/drm/drm_connector.c
> > > > :export:
> > > >  
> > > > +Writeback Connectors
> > > > +
> > > > +
> > > > +.. kernel-doc:: drivers/gpu/drm/drm_writeback.c
> > > > +  :doc: overview
> > > > +
> > > > +.. kernel-doc:: drivers/gpu/drm/drm_writeback.c
> > > > +  :export:
> > > > +
> > > >  Encoder Abstraction
> > > >  ===
> > > >  
> > > > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> > > > index 50093ff4479b..3d708959b224 100644
> > > > --- a/drivers/gpu/drm/Makefile
> > > > +++ b/drivers/gpu/drm/Makefile
> > > > @@ -18,7 +18,7 @@ drm-y   :=drm_auth.o drm_bufs.o 
> > > > drm_cache.o \
> > > > drm_encoder.o drm_mode_object.o drm_property.o \
> > > > drm_plane.o drm_color_mgmt.o drm_print.o \
> > > > drm_dumb_buffers.o drm_mode_config.o drm_vblank.o \
> > > > -   drm_syncobj.o drm_lease.o
> > > > +   drm_syncobj.o drm_lease.o drm_writeback.o
> > > >  
> > > >  drm-$(CONFIG_DRM_LIB_RANDOM) += 

Re: [RFC 1/4] drm: Add writeback connector type

[Sean Paul]

On Fri, Feb 23, 2018 at 08:17:51AM -0500, Rob Clark wrote:
> From: Brian Starkey 
> 
> Writeback connectors represent writeback engines which can write the
> CRTC output to a memory framebuffer. Add a writeback connector type and
> related support functions.
> 
> Drivers should initialize a writeback connector with
> drm_writeback_connector_init() which takes care of setting up all the
> writeback-specific details on top of the normal functionality of
> drm_connector_init().
> 
> Writeback connectors have a WRITEBACK_FB_ID property, used to set the
> output framebuffer, and a WRITEBACK_PIXEL_FORMATS blob used to expose the
> supported writeback formats to userspace.
> 
> When a framebuffer is attached to a writeback connector with the
> WRITEBACK_FB_ID property, it is used only once (for the commit in which
> it was included), and userspace can never read back the value of
> WRITEBACK_FB_ID. WRITEBACK_FB_ID can only be set if the connector is
> attached to a CRTC.
> 
> Changes since v1:
>  - Added drm_writeback.c + documentation
>  - Added helper to initialize writeback connector in one go
>  - Added core checks
>  - Squashed into a single commit
>  - Dropped the client cap
>  - Writeback framebuffers are no longer persistent
> 
> Changes since v2:
>  Daniel Vetter:
>  - Subclass drm_connector to drm_writeback_connector
>  - Relax check to allow CRTC to be set without an FB
>  - Add some writeback_ prefixes
>  - Drop PIXEL_FORMATS_SIZE property, as it was unnecessary
>  Gustavo Padovan:
>  - Add drm_writeback_job to handle writeback signalling centrally
> 
> Changes since v3:
>  - Rebased
>  - Rename PIXEL_FORMATS -> WRITEBACK_PIXEL_FORMATS
> 
> Changes since v4:
>  - Added atomic_commit() vfunc to connector helper funcs, so that
>writeback jobs are committed from atomic helpers
> 
> Signed-off-by: Brian Starkey 
> [rebased and fixed conflicts]
> Signed-off-by: Mihail Atanassov 
> Signed-off-by: Liviu Dudau 
> [rebased and added atomic_commit() vfunc for writeback jobs]
> Signed-off-by: Rob Clark 
> ---
>  Documentation/gpu/drm-kms.rst|   9 ++
>  drivers/gpu/drm/Makefile |   2 +-
>  drivers/gpu/drm/drm_atomic.c | 130 
>  drivers/gpu/drm/drm_atomic_helper.c  |  30 
>  drivers/gpu/drm/drm_connector.c  |   4 +-
>  drivers/gpu/drm/drm_writeback.c  | 257 
> +++
>  include/drm/drm_atomic.h |   3 +
>  include/drm/drm_connector.h  |  13 ++
>  include/drm/drm_mode_config.h|  14 ++
>  include/drm/drm_modeset_helper_vtables.h |  11 ++
>  include/drm/drm_writeback.h  |  89 +++
>  include/uapi/drm/drm_mode.h  |   1 +
>  12 files changed, 561 insertions(+), 2 deletions(-)
>  create mode 100644 drivers/gpu/drm/drm_writeback.c
>  create mode 100644 include/drm/drm_writeback.h
> 
> diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
> index 2dcf5b42015d..e7590dd2f71e 100644
> --- a/Documentation/gpu/drm-kms.rst
> +++ b/Documentation/gpu/drm-kms.rst
> @@ -370,6 +370,15 @@ Connector Functions Reference
>  .. kernel-doc:: drivers/gpu/drm/drm_connector.c
> :export:
>  
> +Writeback Connectors
> +
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_writeback.c
> +  :doc: overview
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_writeback.c
> +  :export:
> +
>  Encoder Abstraction
>  ===
>  
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 50093ff4479b..3d708959b224 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -18,7 +18,7 @@ drm-y   :=  drm_auth.o drm_bufs.o drm_cache.o \
>   drm_encoder.o drm_mode_object.o drm_property.o \
>   drm_plane.o drm_color_mgmt.o drm_print.o \
>   drm_dumb_buffers.o drm_mode_config.o drm_vblank.o \
> - drm_syncobj.o drm_lease.o
> + drm_syncobj.o drm_lease.o drm_writeback.o
>  
>  drm-$(CONFIG_DRM_LIB_RANDOM) += lib/drm_random.o
>  drm-$(CONFIG_DRM_VM) += drm_vm.o
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 46733d534587..019f131fe8be 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -30,6 +30,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  #include "drm_crtc_internal.h"
> @@ -638,6 +639,46 @@ static void drm_atomic_crtc_print_state(struct 
> drm_printer *p,
>   crtc->funcs->atomic_print_state(p, state);
>  }
>  
> +/**
> + * drm_atomic_connector_check - check connector state
> + * @connector: connector to check
> + * @state: connector state to check
> + *
> + * Provides core sanity checks for connector state.
> + *
> + * RETURNS:
> + * Zero on success, error code on failure
> + */
> +static int 

Re: [RFC 1/4] drm: Add writeback connector type

[Rob Clark]

On Fri, Feb 23, 2018 at 10:59 AM, Sean Paul  wrote:
>
> Have we considered hiding writeback behind a client cap instead?

It is kinda *almost* unneeded, since the connector reports itself as
disconnected.

I'm not sure what the reason was to drop the cap, but I think it would
be better to have a cap so WB connectors don't show up in, for ex,
xrandr

BR,
-R
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/7] i3c: Add core I3C infrastructure

[Vitor Soares]

Hi Boris,

Às 3:16 PM de 12/14/2017, Boris Brezillon escreveu:
> +
> +enum i3c_addr_slot_status i3c_bus_get_addr_slot_status(struct i3c_bus *bus,
> +u16 addr)
> +{
> + int status, bitpos = addr * 2;
> +
> + if (addr > I2C_MAX_ADDR)
> + return I3C_ADDR_SLOT_RSVD;
> +
> + status = bus->addrslots[bitpos / BITS_PER_LONG];
> + status >>= bitpos % BITS_PER_LONG;
> +
> + return status & I3C_ADDR_SLOT_STATUS_MASK;
> +}

I don't understand the size of addr. The I3C only allow 7-bit addresses.

Is the addrslots used to store the addresses and its status?

> +
> +void i3c_bus_set_addr_slot_status(struct i3c_bus *bus, u16 addr,
> +   enum i3c_addr_slot_status status)
> +{
> + int bitpos = addr * 2;
> + unsigned long *ptr;
> +
> + if (addr > I2C_MAX_ADDR)
> + return;
> +
> + ptr = bus->addrslots + (bitpos / BITS_PER_LONG);
> + *ptr &= ~(I3C_ADDR_SLOT_STATUS_MASK << (bitpos % BITS_PER_LONG));
> + *ptr |= status << (bitpos % BITS_PER_LONG);
> +}
> +
> +bool i3c_bus_dev_addr_is_avail(struct i3c_bus *bus, u8 addr)
> +{
> + enum i3c_addr_slot_status status;
> +
> + status = i3c_bus_get_addr_slot_status(bus, addr);
> +
> + return status == I3C_ADDR_SLOT_FREE;
> +}
> +
> +int i3c_bus_get_free_addr(struct i3c_bus *bus, u8 start_addr)
> +{
> + enum i3c_addr_slot_status status;
> + u8 addr;
> +
> + for (addr = start_addr; addr < I3C_MAX_ADDR; addr++) {
> + status = i3c_bus_get_addr_slot_status(bus, addr);
> + if (status == I3C_ADDR_SLOT_FREE)
> + return addr;
> + }
> +
> + return -ENOMEM;
> +}
> +
> +static void i3c_bus_init_addrslots(struct i3c_bus *bus)
> +{
> + int i;
> +
> + /* Addresses 0 to 7 are reserved. */
> + for (i = 0; i < 8; i++)
> + i3c_bus_set_addr_slot_status(bus, i, I3C_ADDR_SLOT_RSVD);
> +
> + /*
> +  * Reserve broadcast address and all addresses that might collide
> +  * with the broadcast address when facing a single bit error.
> +  */
> + i3c_bus_set_addr_slot_status(bus, I3C_BROADCAST_ADDR,
> +  I3C_ADDR_SLOT_RSVD);
> + for (i = 0; i < 7; i++)
> + i3c_bus_set_addr_slot_status(bus, I3C_BROADCAST_ADDR ^ BIT(i),
> +  I3C_ADDR_SLOT_RSVD);
> +}
> +
> +static const char * const i3c_bus_mode_strings[] = {
> + [I3C_BUS_MODE_PURE] = "pure",
> + [I3C_BUS_MODE_MIXED_FAST] = "mixed-fast",
> + [I3C_BUS_MODE_MIXED_SLOW] = "mixed-slow",
> +};
> +
> +static ssize_t mode_show(struct device *dev,
> +  struct device_attribute *da,
> +  char *buf)
> +{
> + struct i3c_bus *i3cbus = container_of(dev, struct i3c_bus, dev);
> + ssize_t ret;
> +
> + i3c_bus_normaluse_lock(i3cbus);
> + if (i3cbus->mode < 0 ||
> + i3cbus->mode > ARRAY_SIZE(i3c_bus_mode_strings) ||
> + !i3c_bus_mode_strings[i3cbus->mode])
> + ret = sprintf(buf, "unknown\n");
> + else
> + ret = sprintf(buf, "%s\n", i3c_bus_mode_strings[i3cbus->mode]);
> + i3c_bus_normaluse_unlock(i3cbus);
> +
> + return ret;
> +}
> +static DEVICE_ATTR_RO(mode);
> +
> +static ssize_t current_master_show(struct device *dev,
> +struct device_attribute *da,
> +char *buf)
> +{
> + struct i3c_bus *i3cbus = container_of(dev, struct i3c_bus, dev);
> + ssize_t ret;
> +
> + i3c_bus_normaluse_lock(i3cbus);
> + ret = sprintf(buf, "%s\n", dev_name(>cur_master->dev));
> + i3c_bus_normaluse_unlock(i3cbus);
> +
> + return ret;
> +}
> +static DEVICE_ATTR_RO(current_master);
> +
> +static ssize_t i3c_scl_frequency_show(struct device *dev,
> +   struct device_attribute *da,
> +   char *buf)
> +{
> + struct i3c_bus *i3cbus = container_of(dev, struct i3c_bus, dev);
> + ssize_t ret;
> +
> + i3c_bus_normaluse_lock(i3cbus);
> + ret = sprintf(buf, "%ld\n", i3cbus->scl_rate.i3c);
> + i3c_bus_normaluse_unlock(i3cbus);
> +
> + return ret;
> +}
> +static DEVICE_ATTR_RO(i3c_scl_frequency);
> +
> +static ssize_t i2c_scl_frequency_show(struct device *dev,
> +   struct device_attribute *da,
> +   char *buf)
> +{
> + struct i3c_bus *i3cbus = container_of(dev, struct i3c_bus, dev);
> + ssize_t ret;
> +
> + i3c_bus_normaluse_lock(i3cbus);
> + ret = sprintf(buf, "%ld\n", i3cbus->scl_rate.i2c);
> + i3c_bus_normaluse_unlock(i3cbus);
> +
> + return ret;
> +}
> +static DEVICE_ATTR_RO(i2c_scl_frequency);
> +
> +static struct attribute *i3c_busdev_attrs[] = {
> + _attr_mode.attr,
> + _attr_current_master.attr,
> + _attr_i3c_scl_frequency.attr,
> + _attr_i2c_scl_frequency.attr,
> + 

Re: [PATCH v12 10/11] sparc64: Add support for ADI (Application Data Integrity)

[David Miller]

From: Khalid Aziz <khalid.a...@oracle.com>
Date: Fri, 23 Feb 2018 11:51:25 -0700

> On 02/22/2018 07:50 PM, kbuild test robot wrote:
>> Hi Khalid,
>> I love your patch! Yet something to improve:
>> [auto build test ERROR on sparc-next/master]
>> [also build test ERROR on v4.16-rc2]
>> [cannot apply to next-20180222]
>> [if your patch is applied to the wrong git tree, please drop us a note
>> to help improve the system]
>> url:
>> https://github.com/0day-ci/linux/commits/Khalid-Aziz/Application-Data-Integrity-feature-introduced-by-SPARC-M7/20180223-071725
>> base:
>> https://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc-next.git
>> master
>> config: sparc64-allyesconfig (attached as .config)
>> compiler: sparc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
>> reproduce:
>>  wget
>>  
>> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross
>>  -O ~/bin/make.cross
>>  chmod +x ~/bin/make.cross
>>  # save the attached .config to linux build tree
>>  make.cross ARCH=sparc64
>> All error/warnings (new ones prefixed by >>):
> 
> Hi Dave,
> 
> Including linux/sched.h in arch/sparc/include/asm/mmu_context.h should
> eliminate these build warnings. My gcc version 6.2.1 does not report
> these errors. Build bot is using 7.2.0.
> 
> I can add a patch 12 to add the include, revise patch 10 or you can
> add the include in your tree. Let me know how you would prefer to
> resolve this.

You need to update patch #10 so that your patch series is fully
bisectable.

Thank you.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v2, 7/7] tty: serial: msm_geni_serial: Add serial driver support for GENI based QUP

[Doug Anderson]

Hi,

On Fri, Jan 12, 2018 at 5:05 PM, Karthikeyan Ramasubramanian
 wrote:
> This driver supports GENI based UART Controller in the Qualcomm SOCs. The
> Qualcomm Generic Interface (GENI) is a programmable module supporting a
> wide range of serial interfaces including UART. This driver support console
> operations using FIFO mode of transfer.
>
> Signed-off-by: Girish Mahadevan 
> Signed-off-by: Karthikeyan Ramasubramanian 
> Signed-off-by: Sagar Dharia 
> ---
>  drivers/tty/serial/Kconfig|   10 +
>  drivers/tty/serial/Makefile   |1 +
>  drivers/tty/serial/qcom_geni_serial.c | 1414 
> +
>  3 files changed, 1425 insertions(+)
>  create mode 100644 drivers/tty/serial/qcom_geni_serial.c
>
> diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
> index b788fee..1be30e5 100644
> --- a/drivers/tty/serial/Kconfig
> +++ b/drivers/tty/serial/Kconfig
> @@ -1098,6 +1098,16 @@ config SERIAL_MSM_CONSOLE
> select SERIAL_CORE_CONSOLE
> select SERIAL_EARLYCON
>
> +config SERIAL_QCOM_GENI
> +   tristate "QCOM on-chip GENI based serial port support"

Should this be bool instead of tristate?  Guenter noticed that we'll
get link errors if we try building this as a module.  Specifically, he
noted that the "qcom_geni_serial.c" file refers to
"uart_console_device" and "uart_console_device" is not exported (and
shouldn't be since a console has to be available before modules are
loaded).


-Doug
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v12 10/11] sparc64: Add support for ADI (Application Data Integrity)

[Khalid Aziz]

On 02/22/2018 07:50 PM, kbuild test robot wrote:

Hi Khalid,

I love your patch! Yet something to improve:

[auto build test ERROR on sparc-next/master]
[also build test ERROR on v4.16-rc2]
[cannot apply to next-20180222]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Khalid-Aziz/Application-Data-Integrity-feature-introduced-by-SPARC-M7/20180223-071725
base:   https://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc-next.git 
master
config: sparc64-allyesconfig (attached as .config)
compiler: sparc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
 wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
 chmod +x ~/bin/make.cross
 # save the attached .config to linux build tree
 make.cross ARCH=sparc64

All error/warnings (new ones prefixed by >>):


Hi Dave,

Including linux/sched.h in arch/sparc/include/asm/mmu_context.h should 
eliminate these build warnings. My gcc version 6.2.1 does not report 
these errors. Build bot is using 7.2.0.


I can add a patch 12 to add the include, revise patch 10 or you can add 
the include in your tree. Let me know how you would prefer to resolve this.


Thanks,
Khalid



In file included from arch/sparc/include/asm/mmu_context.h:5:0,
 from include/linux/mmu_context.h:5,
 from drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h:29,
 from drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c:23:
arch/sparc/include/asm/mmu_context_64.h: In function 
'arch_start_context_switch':

arch/sparc/include/asm/mmu_context_64.h:157:4: error: implicit declaration of 
function 'set_tsk_thread_flag'; did you mean 'set_ti_thread_flag'? 
[-Werror=implicit-function-declaration]

set_tsk_thread_flag(prev, TIF_MCDPER);
^~~
set_ti_thread_flag

arch/sparc/include/asm/mmu_context_64.h:159:4: error: implicit declaration of 
function 'clear_tsk_thread_flag'; did you mean 'clear_ti_thread_flag'? 
[-Werror=implicit-function-declaration]

clear_tsk_thread_flag(prev, TIF_MCDPER);
^
clear_ti_thread_flag
arch/sparc/include/asm/mmu_context_64.h: In function 
'finish_arch_post_lock_switch':

arch/sparc/include/asm/mmu_context_64.h:180:25: error: dereferencing pointer to 
incomplete type 'struct task_struct'

   if (current && current->mm && current->mm->context.adi) {
 ^~
In file included from arch/sparc/include/asm/processor.h:5:0,
 from arch/sparc/include/asm/spinlock_64.h:12,
 from arch/sparc/include/asm/spinlock.h:5,
 from include/linux/spinlock.h:88,
 from arch/sparc/include/asm/mmu_context_64.h:9,
 from arch/sparc/include/asm/mmu_context.h:5,
 from include/linux/mmu_context.h:5,
 from drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h:29,
 from drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c:23:

arch/sparc/include/asm/processor_64.h:194:28: error: implicit declaration of 
function 'task_thread_info'; did you mean 'test_thread_flag'? 
[-Werror=implicit-function-declaration]

 #define task_pt_regs(tsk) (task_thread_info(tsk)->kregs)
^

arch/sparc/include/asm/mmu_context_64.h:183:11: note: in expansion of macro 
'task_pt_regs'

regs = task_pt_regs(current);
   ^~~~

arch/sparc/include/asm/processor_64.h:194:49: error: invalid type argument of 
'->' (have 'int')

 #define task_pt_regs(tsk) (task_thread_info(tsk)->kregs)
 ^

arch/sparc/include/asm/mmu_context_64.h:183:11: note: in expansion of macro 
'task_pt_regs'

regs = task_pt_regs(current);
   ^~~~
In file included from include/linux/cred.h:21:0,
 from include/linux/seq_file.h:12,
 from include/linux/pinctrl/consumer.h:17,
 from include/linux/pinctrl/devinfo.h:21,
 from include/linux/device.h:23,
 from include/linux/cdev.h:8,
 from include/drm/drmP.h:36,
 from drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c:25:
include/linux/sched.h: At top level:

include/linux/sched.h:1530:20: warning: conflicting types for 
'set_tsk_thread_flag'

 static inline void set_tsk_thread_flag(struct task_struct *tsk, int flag)
^~~

include/linux/sched.h:1530:20: error: static declaration of 
'set_tsk_thread_flag' follows non-static declaration

In file included from arch/sparc/include/asm/mmu_context.h:5:0,
 from include/linux/mmu_context.h:5,
 from drive

response

[Ms. Ella Golan]

I am Ms.Ella Golan, I am the Executive Vice President Banking Division with 
FIRST INTERNATIONAL BANK OF ISRAEL LTD (FIBI). I am getting in touch with you 
regarding an extremely important and urgent matter. If you would oblige me the 
opportunity, I shall provide you with details upon your response.

Faithfully,
Ms.Ella Golan
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/7] i3c: Add core I3C infrastructure

[Boris Brezillon]

Hi Vitor,

On Fri, 23 Feb 2018 16:56:14 +
Vitor Soares  wrote:

> Hi Boris,
> 
> Às 3:16 PM de 12/14/2017, Boris Brezillon escreveu:
> > +
> > +enum i3c_addr_slot_status i3c_bus_get_addr_slot_status(struct i3c_bus *bus,
> > +  u16 addr)
> > +{
> > +   int status, bitpos = addr * 2;
> > +
> > +   if (addr > I2C_MAX_ADDR)
> > +   return I3C_ADDR_SLOT_RSVD;
> > +
> > +   status = bus->addrslots[bitpos / BITS_PER_LONG];
> > +   status >>= bitpos % BITS_PER_LONG;
> > +
> > +   return status & I3C_ADDR_SLOT_STATUS_MASK;
> > +}  
> 
> I don't understand the size of addr. The I3C only allow 7-bit addresses.
> 
> Is the addrslots used to store the addresses and its status?

No, slots are used for both I2C and I3C addresses, and an I2C address
can be 10-bits wide, hence the u16 type.


[...]

> > +/**
> > + * i3c_device_do_priv_xfers() - do I3C SDR private transfers directed to a
> > + * specific device
> > + *
> > + * @dev: device with which the transfers should be done
> > + * @xfers: array of transfers
> > + * @nxfers: number of transfers
> > + *
> > + * Initiate one or several private SDR transfers with @dev.
> > + *
> > + * This function can sleep and thus cannot be called in atomic context.
> > + *
> > + * Return: 0 in case of success, a negative error core otherwise.
> > + */
> > +int i3c_device_do_priv_xfers(struct i3c_device *dev,
> > +struct i3c_priv_xfer *xfers,
> > +int nxfers)
> > +{
> > +   struct i3c_master_controller *master;
> > +   int i, ret;
> > +
> > +   master = i3c_device_get_master(dev);
> > +   if (!master)
> > +   return -EINVAL;
> > +
> > +   i3c_bus_normaluse_lock(master->bus);
> > +   for (i = 0; i < nxfers; i++)
> > +   xfers[i].addr = dev->info.dyn_addr;
> > +
> > +   ret = i3c_master_do_priv_xfers_locked(master, xfers, nxfers);
> > +   i3c_bus_normaluse_unlock(master->bus);
> > +
> > +   return ret;
> > +}
> > +EXPORT_SYMBOL_GPL(i3c_device_do_priv_xfers);  
> 
>  The controller should know the speed mode for each xfer. The SDR0 mode 
> is used by default but if any device have read or write speed 
> limitations the controller can use SDRx.

I might be wrong, but that's not my understanding of the spec. A device
can express a speed limitation for SDR priv transfers, but this
limitation applies to all SDR transfers.

The speed R/W speed limitation is encoded in the device object, so, if
the controller has to configure that on a per-transfer basis, one
solution would be to pass the device to the ->priv_xfers().

> 
> This could be also applied to i2c transfers.

Not really. The max SCL frequency is something that applies to the
whole bus, because all I2C devices have to decode the address when
messages are sent on the bus to determine if they should ignore or
process the message.

> > +#endif /* I3C_INTERNAL_H */
> > diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c
> > new file mode 100644
> > index ..1c85abac08d5
> > --- /dev/null
> > +++ b/drivers/i3c/master.c
> > @@ -0,0 +1,1433 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (C) 2017 Cadence Design Systems Inc.
> > + *
> > + * Author: Boris Brezillon
> > + */
> > +
> > +#include 
> > +
> > +#include "internals.h"
> > +
> > +/**
> > + * i3c_master_entdaa_locked() - start a DAA (Dynamic Address Assignment)
> > + * procedure
> > + * @master: master used to send frames on the bus
> > + *
> > + * Send a ENTDAA CCC command to start a DAA procedure.
> > + *
> > + * Note that this function only sends the ENTDAA CCC command, all the logic
> > + * behind dynamic address assignment has to be handled in the I3C master
> > + * driver.
> > + *
> > + * This function must be called with the bus lock held in write mode.
> > + *
> > + * Return: 0 in case of success, a negative error code otherwise.
> > + */
> > +int i3c_master_entdaa_locked(struct i3c_master_controller *master)
> > +{
> > +   struct i3c_ccc_cmd_dest dest = { };
> > +   struct i3c_ccc_cmd cmd = { };
> > +   int ret;
> > +
> > +   dest.addr = I3C_BROADCAST_ADDR;
> > +   cmd.dests = 
> > +   cmd.ndests = 1;
> > +   cmd.rnw = false;
> > +   cmd.id = I3C_CCC_ENTDAA;
> > +
> > +   ret = i3c_master_send_ccc_cmd_locked(master, );
> > +   if (ret)
> > +   return ret;
> > +
> > +   return 0;
> > +}
> > +EXPORT_SYMBOL_GPL(i3c_master_entdaa_locked);  
> 
>  can you explain the process?

Not sure what you mean. The ENTDAA is just a CCC command that is used
to trigger a DAA procedure. What the master controller does when it
sends such a command is likely to be controller dependent, and it might
even be possible that you don't need to call this function in your
controller driver to trigger a DAA. If you want more details about the
bus initialization steps and how the ENTDAA CCC command fits into it I
recommend reading 

Re: [PATCH 00/13] Remove metag architecture

[James Hogan]

On Fri, Feb 23, 2018 at 11:26:58AM +0100, Arnd Bergmann wrote:
> On Thu, Feb 22, 2018 at 12:38 AM, James Hogan  wrote:
> > So lets call it a day and drop the Meta architecture port from the
> > kernel. RIP Meta.
> 
> Since I brought up the architecture removal independently, I could
> pick this up into a git tree that also has the removal of some of the
> other architectures.
> 
> I see your tree is part of linux-next, so you could also just put it
> in there and send a pull request at the merge window if you prefer.
> 
> The only real reason I see for a shared git tree would be to avoid
> conflicts when we touch the same Kconfig files or #ifdefs in driver,
> but Meta only appears in
> 
> config FRAME_POINTER
> bool "Compile the kernel with frame pointers"
> depends on DEBUG_KERNEL && \
> (CRIS || M68K || FRV || UML || \
>  SUPERH || BLACKFIN || MN10300 || METAG) || \
> ARCH_WANT_FRAME_POINTERS
> 
> and
> 
> include/trace/events/mmflags.h:#elif defined(CONFIG_PARISC) ||
> defined(CONFIG_METAG) || defined(CONFIG_IA64)
> 
> so there is little risk.

I'm happy to put v2 in linux-next now (only patch 4 has changed, I just
sent an updated version), and send you a pull request early next week so
you can take it from there. The patches can't be directly applied with
git-am anyway thanks to the -D option to make them more concise.

Sound okay?

Thanks
James


signature.asc
Description: Digital signature

Re: [PATCH 05/10] hwmon: generic-pwm-tachometer: Add generic PWM based tachometer

[RAJKUMAR]

On Wednesday 21 February 2018 09:38 PM, Guenter Roeck wrote:

On Wed, Feb 21, 2018 at 05:20:29PM +0200, Mikko Perttunen wrote:

On 21.02.2018 16:46, Guenter Roeck wrote:

On 02/20/2018 11:15 PM, Mikko Perttunen wrote:

AIUI, the PWM framework already exposes a sysfs node with period
information. We should just use that instead of adding a new driver
for this.


I am kind of lost. Please explain.

Are you saying that we should drop the pwm-fan driver as well (which goes
the opposite way), as well as any other drivers doing anything with pwm
signals,
because after all those signals are already exposed to userspace a sysfs
attributes,
and a kernel driver to abstract those values is thus not needed ?

The only thing this driver does is do a constant division in kernelspace.
I'm not really seeing why that couldn't be done in userspace. But if you
think it's appropriate to do the RPM conversion in kernelspace then I'm not
greatly opposed to that.


Isn't that true for any conversion from and to pwm values ? Voltages,
for example ? Should those be handled in userspace as well ?

Note that I am not entirely convinced that the approach suggested in this
patch series makes sense. Patch 4 seems to move the notion of a tachometer
into the pwm subsystem. I am not really convinced that this makes sense
(maybe all that code should be in the hwmon driver instead, or in a thermal
driver if the author prefers). But that is a different issue. The question
you raised is if there should be any abstraction to or from raw pwm values
in the kernel.
Since tachometer driver implements PWM capture callback feature, I have 
added it under pwm driver as pwm-tegra-tachometer.c driver.
If the best approach is to have this tachometer driver under hwmon 
driver then I will move it to hwmon driver.



In any case, we cannot add something like this to device tree since
it's not a hardware device.


So you are saying there is no means to express in devicetree that
a pwm input is connected to a fan ? How is that not hardware ?

If so, how do you express in devicetree that a pwm signal is connected
to anything ?

If we want to describe that the tachometer is connected to a fan, then we
should have a fan node in the board's device tree. We don't have a chip that
has a thing called "generic-pwm-tachometer" attached to it. (We have chips
that have a "nvidia,tegra186-tachometer", so it's proper to have that.)


So you are concerned about the property name ? I don't really care how
it is called.

Guenter


Thanks,
Mikko


Guenter


Mikko

On 21.02.2018 08:58, Rajkumar Rampelli wrote:

Add generic PWM based tachometer driver via HWMON interface
to report the RPM of motor. This drivers get the period/duty
cycle from PWM IP which captures the motor PWM output.

This driver implements a simple interface for monitoring the speed of
a fan and exposes it in roatations per minute (RPM) to the user space
by using the hwmon's sysfs interface

Signed-off-by: Rajkumar Rampelli 
---
Documentation/hwmon/generic-pwm-tachometer |  17 +
drivers/hwmon/Kconfig  |  10 +++
drivers/hwmon/Makefile |   1 +
drivers/hwmon/generic-pwm-tachometer.c | 112
+
4 files changed, 140 insertions(+)
create mode 100644 Documentation/hwmon/generic-pwm-tachometer
create mode 100644 drivers/hwmon/generic-pwm-tachometer.c

diff --git a/Documentation/hwmon/generic-pwm-tachometer
b/Documentation/hwmon/generic-pwm-tachometer
new file mode 100644
index 000..e0713ee
--- /dev/null
+++ b/Documentation/hwmon/generic-pwm-tachometer
@@ -0,0 +1,17 @@
+Kernel driver generic-pwm-tachometer
+
+
+This driver enables the use of a PWM module to monitor a fan. It
uses the
+generic PWM interface and can be used on SoCs as along as the SoC
supports
+Tachometer controller that moniors the Fan speed in periods.
+
+Author: Rajkumar Rampelli 
+
+Description
+---
+
+The driver implements a simple interface for monitoring the Fan
speed using
+PWM module and Tachometer controller. It requests period value
through PWM
+capture interface to Tachometer and measures the Rotations per
minute using
+received period value. It exposes the Fan speed in RPM to the user
space by
+using the hwmon's sysfs interface.
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index ef23553..8912dcb 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1878,6 +1878,16 @@ config SENSORS_XGENE
   If you say yes here you get support for the temperature
   and power sensors for APM X-Gene SoC.

+config GENERIC_PWM_TACHOMETER
+tristate "Generic PWM based tachometer driver"
+depends on PWM
+help
+  Enables a driver to use PWM signal from motor to use
+  for measuring the motor speed. The RPM is captured by
+  PWM modules which has PWM capture capability and this
+  drivers reads the captured data from PWM IP to convert
+  it 

Re: [PATCH 00/13] Remove metag architecture

[Arnd Bergmann]

On Fri, Feb 23, 2018 at 12:02 PM, James Hogan  wrote:
> On Fri, Feb 23, 2018 at 11:26:58AM +0100, Arnd Bergmann wrote:
>> On Thu, Feb 22, 2018 at 12:38 AM, James Hogan  wrote:
>> > So lets call it a day and drop the Meta architecture port from the
>> > kernel. RIP Meta.
>>
>> Since I brought up the architecture removal independently, I could
>> pick this up into a git tree that also has the removal of some of the
>> other architectures.
>>
>> I see your tree is part of linux-next, so you could also just put it
>> in there and send a pull request at the merge window if you prefer.
>>
>> The only real reason I see for a shared git tree would be to avoid
>> conflicts when we touch the same Kconfig files or #ifdefs in driver,
>> but Meta only appears in
>>
>> config FRAME_POINTER
>> bool "Compile the kernel with frame pointers"
>> depends on DEBUG_KERNEL && \
>> (CRIS || M68K || FRV || UML || \
>>  SUPERH || BLACKFIN || MN10300 || METAG) || \
>> ARCH_WANT_FRAME_POINTERS
>>
>> and
>>
>> include/trace/events/mmflags.h:#elif defined(CONFIG_PARISC) ||
>> defined(CONFIG_METAG) || defined(CONFIG_IA64)
>>
>> so there is little risk.
>
> I'm happy to put v2 in linux-next now (only patch 4 has changed, I just
> sent an updated version), and send you a pull request early next week so
> you can take it from there. The patches can't be directly applied with
> git-am anyway thanks to the -D option to make them more concise.
>
> Sound okay?

Yes, sounds good, thanks!

   Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 00/13] Remove metag architecture

[Arnd Bergmann]

On Thu, Feb 22, 2018 at 12:38 AM, James Hogan  wrote:
> These patches remove the metag architecture and tightly dependent
> drivers from the kernel. With the 4.16 kernel the ancient gcc 4.2.4
> based metag toolchain we have been using is hitting compiler bugs, so
> now seems a good time to drop it altogether.
>
> Quoting from patch 1:
>
> The earliest Meta architecture port of Linux I have a record of was an
> import of a Meta port of Linux v2.4.1 in February 2004, which was worked
> on significantly over the next few years by Graham Whaley, Will Newton,
> Matt Fleming, myself and others.
>
> Eventually the port was merged into mainline in v3.9 in March 2013, not
> long after Imagination Technologies bought MIPS Technologies and shifted
> its CPU focus over to the MIPS architecture.
>
> As a result, though the port was maintained for a while, kept on life
> support for a while longer, and useful for testing a few specific
> drivers for which I don't have ready access to the equivalent MIPS
> hardware, it is now essentially dead with no users.
>
> It is also stuck using an out-of-tree toolchain based on GCC 4.2.4 which
> is no longer maintained, now struggles to build modern kernels due to
> toolchain bugs, and doesn't itself build with a modern GCC. The latest
> buildroot port is still using an old uClibc snapshot which is no longer
> served, and the latest uClibc doesn't build with GCC 4.2.4.
>
> So lets call it a day and drop the Meta architecture port from the
> kernel. RIP Meta.

Since I brought up the architecture removal independently, I could
pick this up into a git tree that also has the removal of some of the
other architectures.

I see your tree is part of linux-next, so you could also just put it
in there and send a pull request at the merge window if you prefer.

The only real reason I see for a shared git tree would be to avoid
conflicts when we touch the same Kconfig files or #ifdefs in driver,
but Meta only appears in

config FRAME_POINTER
bool "Compile the kernel with frame pointers"
depends on DEBUG_KERNEL && \
(CRIS || M68K || FRV || UML || \
 SUPERH || BLACKFIN || MN10300 || METAG) || \
ARCH_WANT_FRAME_POINTERS

and

include/trace/events/mmflags.h:#elif defined(CONFIG_PARISC) ||
defined(CONFIG_METAG) || defined(CONFIG_IA64)

so there is little risk.

  Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/1] mm, compaction: correct the bounds of __fragmentation_index()

[Michal Hocko]

On Mon 19-02-18 14:30:36, Robert Harris wrote:
> 
> 
> > On 19 Feb 2018, at 12:39, Michal Hocko  wrote:
> > 
> > On Mon 19-02-18 12:14:26, Robert Harris wrote:
> >> 
> >> 
> >>> On 19 Feb 2018, at 08:26, Michal Hocko  wrote:
> >>> 
> >>> On Sun 18-02-18 16:47:55, robert.m.har...@oracle.com wrote:
>  From: "Robert M. Harris" 
>  
>  __fragmentation_index() calculates a value used to determine whether
>  compaction should be favoured over page reclaim in the event of 
>  allocation
>  failure.  The calculation itself is opaque and, on inspection, does not
>  match its existing description.  The function purports to return a value
>  between 0 and 1000, representing units of 1/1000.  Barring the case of a
>  pathological shortfall of memory, the lower bound is instead 500.  This 
>  is
>  significant because it is the default value of sysctl_extfrag_threshold,
>  i.e. the value below which compaction should be avoided in favour of page
>  reclaim for costly pages.
>  
>  This patch implements and documents a modified version of the original
>  expression that returns a value in the range 0 <= index < 1000.  It 
>  amends
>  the default value of sysctl_extfrag_threshold to preserve the existing
>  behaviour.
> >>> 
> >>> It is not really clear to me what is the actual problem you are trying
> >>> to solve by this patch. Is there any bug or are you just trying to
> >>> improve the current implementation to be more effective?
> >> 
> >> There is not a significant bug.
> >> 
> >> The first problem is that the mathematical expression in
> >> __fragmentation_index() is opaque, particularly given the lack of
> >> description in the comments or the original commit message.  This patch
> >> provides such a description.
> >> 
> >> Simply annotating the expression did not make sense since the formula
> >> doesn't work as advertised.  The fragmentation index is described as
> >> being in the range 0 to 1000 but the bounds of the formula are instead
> >> 500 to 1000.  This patch changes the formula so that its lower bound is
> >> 0.
> > 
> > But why do we want to fix that in the first place? Why don't we simply
> > deprecate the tunable and remove it altogether? Who is relying on tuning
> > this option. Considering how it doesn't work as advertised and nobody
> > complaining I have that feeling that it is not really used in wild…
> 
> I think it's a useful feature.  Ignoring any contrived test case, there
> will always be a lower limit on the degree of fragmentation that can be
> achieved by compaction.  If someone takes the trouble to measure this
> then it is entirely reasonable that he or she should be able to inhibit
> compaction for cases when fragmentation falls below some correspondingly
> sized threshold.

Do you have any practical examples?
-- 
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/1] mm, compaction: correct the bounds of __fragmentation_index()

[Robert Harris]

> On 23 Feb 2018, at 09:10, Michal Hocko  wrote:
> 
> On Mon 19-02-18 14:30:36, Robert Harris wrote:
>> 
>> 
>>> On 19 Feb 2018, at 12:39, Michal Hocko  wrote:
>>> 
>>> On Mon 19-02-18 12:14:26, Robert Harris wrote:
 
 
> On 19 Feb 2018, at 08:26, Michal Hocko  wrote:
> 
> On Sun 18-02-18 16:47:55, robert.m.har...@oracle.com wrote:
>> From: "Robert M. Harris" 
>> 
>> __fragmentation_index() calculates a value used to determine whether
>> compaction should be favoured over page reclaim in the event of 
>> allocation
>> failure.  The calculation itself is opaque and, on inspection, does not
>> match its existing description.  The function purports to return a value
>> between 0 and 1000, representing units of 1/1000.  Barring the case of a
>> pathological shortfall of memory, the lower bound is instead 500.  This 
>> is
>> significant because it is the default value of sysctl_extfrag_threshold,
>> i.e. the value below which compaction should be avoided in favour of page
>> reclaim for costly pages.
>> 
>> This patch implements and documents a modified version of the original
>> expression that returns a value in the range 0 <= index < 1000.  It 
>> amends
>> the default value of sysctl_extfrag_threshold to preserve the existing
>> behaviour.
> 
> It is not really clear to me what is the actual problem you are trying
> to solve by this patch. Is there any bug or are you just trying to
> improve the current implementation to be more effective?
 
 There is not a significant bug.
 
 The first problem is that the mathematical expression in
 __fragmentation_index() is opaque, particularly given the lack of
 description in the comments or the original commit message.  This patch
 provides such a description.
 
 Simply annotating the expression did not make sense since the formula
 doesn't work as advertised.  The fragmentation index is described as
 being in the range 0 to 1000 but the bounds of the formula are instead
 500 to 1000.  This patch changes the formula so that its lower bound is
 0.
>>> 
>>> But why do we want to fix that in the first place? Why don't we simply
>>> deprecate the tunable and remove it altogether? Who is relying on tuning
>>> this option. Considering how it doesn't work as advertised and nobody
>>> complaining I have that feeling that it is not really used in wild…
>> 
>> I think it's a useful feature.  Ignoring any contrived test case, there
>> will always be a lower limit on the degree of fragmentation that can be
>> achieved by compaction.  If someone takes the trouble to measure this
>> then it is entirely reasonable that he or she should be able to inhibit
>> compaction for cases when fragmentation falls below some correspondingly
>> sized threshold.
> 
> Do you have any practical examples?

Are you looking for proof that the existing feature is useful?

It is possible today to induce compaction, observe a fragmentation index
and then use the same index as a starting point for setting the
tuneable.  The fact that the actual range of reported indices is
500--1000 rather than the documented 0--1000 would have no practical
effect on this approach.  Therefore that fact that the feature doesn't
work precisely as advertised does not mean that it is not useful.

If you are asking me to prove whether modifying the tuneable in the
manner above, thereby preferring compaction for more fragmented systems,
is successful then I can't answer now.  I assume that the onus would
have been on Mel to show this at the time of the original commit.
However, I interpret his last comment on this patch as a request to
verify that changing the preference yields sane results.

Robert Harris

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/1] mm, compaction: correct the bounds of __fragmentation_index()

[Michal Hocko]

On Fri 23-02-18 13:40:09, Robert Harris wrote:
> If you are asking me to prove whether modifying the tuneable in the
> manner above, thereby preferring compaction for more fragmented systems,
> is successful then I can't answer now.  I assume that the onus would
> have been on Mel to show this at the time of the original commit.
> However, I interpret his last comment on this patch as a request to
> verify that changing the preference yields sane results.

Yes, this is exactly were I was aiming... This might have been useful
during the initial compaction implementation but I am not aware of any
real users and I am also quite skeptical it is very much useful. I do
realize that this is hand waving because I do not have any numbers at
hands. The bottom line is that the users should care, really. The
compaction should be as automatic as possible. We can argue about
tuning for certain allocation orders and make the compaction more
pro-active to provide lower latencies for those requests but deciding
whether to reclaim or compact sounds like a too low level decision for
admin to make and kind of unstable interface for different kernels as
the implementation of the compaction changes over time.

So I would really prefer to kill the tuning than try to "fix" it.
-- 
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 1/4] drm: Add writeback connector type

[Liviu Dudau]

Hi Rob,

On Fri, Feb 23, 2018 at 08:17:51AM -0500, Rob Clark wrote:
> From: Brian Starkey 
> 
> Writeback connectors represent writeback engines which can write the
> CRTC output to a memory framebuffer. Add a writeback connector type and
> related support functions.
> 
> Drivers should initialize a writeback connector with
> drm_writeback_connector_init() which takes care of setting up all the
> writeback-specific details on top of the normal functionality of
> drm_connector_init().
> 
> Writeback connectors have a WRITEBACK_FB_ID property, used to set the
> output framebuffer, and a WRITEBACK_PIXEL_FORMATS blob used to expose the
> supported writeback formats to userspace.
> 
> When a framebuffer is attached to a writeback connector with the
> WRITEBACK_FB_ID property, it is used only once (for the commit in which
> it was included), and userspace can never read back the value of
> WRITEBACK_FB_ID. WRITEBACK_FB_ID can only be set if the connector is
> attached to a CRTC.

[snip]

> +static bool create_writeback_properties(struct drm_device *dev)
> +{
> + struct drm_property *prop;
> +
> + if (!dev->mode_config.writeback_fb_id_property) {
> + prop = drm_property_create_object(dev, DRM_MODE_PROP_ATOMIC,
> +   "WRITEBACK_FB_ID",
> +   DRM_MODE_OBJECT_FB);
> + if (!prop)
> + return false;
> + dev->mode_config.writeback_fb_id_property = prop;
> + }
> +
> + if (!dev->mode_config.writeback_pixel_formats_property) {
> + prop = drm_property_create(dev, DRM_MODE_PROP_BLOB | 
> DRM_MODE_PROP_IMMUTABLE,
> +"WRITEBACK_PIXEL_FORMATS", 0);
> + if (!prop)
> + return false;
> + dev->mode_config.writeback_pixel_formats_property = prop;
> + }
> +
> + return true;
> +}

based on a buildbot warning and the fact that the next patch starts
returning -ENOMEM inside the above function, I have this variant in my
internal tree that I was preparing to send out once I've got my i-g-t
tests in better shape:

+static int create_writeback_properties(struct drm_device *dev)
+{
+   struct drm_property *prop;
+
+   if (!dev->mode_config.writeback_fb_id_property) {
+   prop = drm_property_create_object(dev, DRM_MODE_PROP_ATOMIC,
+ "WRITEBACK_FB_ID",
+ DRM_MODE_OBJECT_FB);
+   if (!prop)
+   return -ENOMEM;
+   dev->mode_config.writeback_fb_id_property = prop;
+   }
+
+   if (!dev->mode_config.writeback_pixel_formats_property) {
+   prop = drm_property_create(dev, DRM_MODE_PROP_BLOB | 
DRM_MODE_PROP_IMMUTABLE,
+  "WRITEBACK_PIXEL_FORMATS", 0);
+   if (!prop)
+   return -ENOMEM;
+   dev->mode_config.writeback_pixel_formats_property = prop;
+   }
+
+   return 0;
+}


Feel free to use this version in the next update if you're going to send
one, otherwise I guess we could be patching it later.

Best regards,
Liviu


> +
> +static const struct drm_encoder_funcs drm_writeback_encoder_funcs = {
> + .destroy = drm_encoder_cleanup,
> +};
> +
> +/**
> + * drm_writeback_connector_init - Initialize a writeback connector and its 
> properties
> + * @dev: DRM device
> + * @wb_connector: Writeback connector to initialize
> + * @con_funcs: Connector funcs vtable
> + * @enc_helper_funcs: Encoder helper funcs vtable to be used by the internal 
> encoder
> + * @formats: Array of supported pixel formats for the writeback engine
> + * @n_formats: Length of the formats array
> + *
> + * This function creates the writeback-connector-specific properties if they
> + * have not been already created, initializes the connector as
> + * type DRM_MODE_CONNECTOR_WRITEBACK, and correctly initializes the property
> + * values. It will also create an internal encoder associated with the
> + * drm_writeback_connector and set it to use the @enc_helper_funcs vtable for
> + * the encoder helper.
> + *
> + * Drivers should always use this function instead of drm_connector_init() to
> + * set up writeback connectors.
> + *
> + * Returns: 0 on success, or a negative error code
> + */
> +int drm_writeback_connector_init(struct drm_device *dev,
> +  struct drm_writeback_connector *wb_connector,
> +  const struct drm_connector_funcs *con_funcs,
> +  const struct drm_encoder_helper_funcs 
> *enc_helper_funcs,
> +  const u32 *formats, int n_formats)
> +{
> + int ret;
> + struct drm_property_blob *blob;
> + struct drm_connector *connector = _connector->base;
> + struct drm_mode_config *config = >mode_config;

[RFC 1/4] drm: Add writeback connector type

[Rob Clark]

From: Brian Starkey 

Writeback connectors represent writeback engines which can write the
CRTC output to a memory framebuffer. Add a writeback connector type and
related support functions.

Drivers should initialize a writeback connector with
drm_writeback_connector_init() which takes care of setting up all the
writeback-specific details on top of the normal functionality of
drm_connector_init().

Writeback connectors have a WRITEBACK_FB_ID property, used to set the
output framebuffer, and a WRITEBACK_PIXEL_FORMATS blob used to expose the
supported writeback formats to userspace.

When a framebuffer is attached to a writeback connector with the
WRITEBACK_FB_ID property, it is used only once (for the commit in which
it was included), and userspace can never read back the value of
WRITEBACK_FB_ID. WRITEBACK_FB_ID can only be set if the connector is
attached to a CRTC.

Changes since v1:
 - Added drm_writeback.c + documentation
 - Added helper to initialize writeback connector in one go
 - Added core checks
 - Squashed into a single commit
 - Dropped the client cap
 - Writeback framebuffers are no longer persistent

Changes since v2:
 Daniel Vetter:
 - Subclass drm_connector to drm_writeback_connector
 - Relax check to allow CRTC to be set without an FB
 - Add some writeback_ prefixes
 - Drop PIXEL_FORMATS_SIZE property, as it was unnecessary
 Gustavo Padovan:
 - Add drm_writeback_job to handle writeback signalling centrally

Changes since v3:
 - Rebased
 - Rename PIXEL_FORMATS -> WRITEBACK_PIXEL_FORMATS

Changes since v4:
 - Added atomic_commit() vfunc to connector helper funcs, so that
   writeback jobs are committed from atomic helpers

Signed-off-by: Brian Starkey 
[rebased and fixed conflicts]
Signed-off-by: Mihail Atanassov 
Signed-off-by: Liviu Dudau 
[rebased and added atomic_commit() vfunc for writeback jobs]
Signed-off-by: Rob Clark 
---
 Documentation/gpu/drm-kms.rst|   9 ++
 drivers/gpu/drm/Makefile |   2 +-
 drivers/gpu/drm/drm_atomic.c | 130 
 drivers/gpu/drm/drm_atomic_helper.c  |  30 
 drivers/gpu/drm/drm_connector.c  |   4 +-
 drivers/gpu/drm/drm_writeback.c  | 257 +++
 include/drm/drm_atomic.h |   3 +
 include/drm/drm_connector.h  |  13 ++
 include/drm/drm_mode_config.h|  14 ++
 include/drm/drm_modeset_helper_vtables.h |  11 ++
 include/drm/drm_writeback.h  |  89 +++
 include/uapi/drm/drm_mode.h  |   1 +
 12 files changed, 561 insertions(+), 2 deletions(-)
 create mode 100644 drivers/gpu/drm/drm_writeback.c
 create mode 100644 include/drm/drm_writeback.h

diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index 2dcf5b42015d..e7590dd2f71e 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -370,6 +370,15 @@ Connector Functions Reference
 .. kernel-doc:: drivers/gpu/drm/drm_connector.c
:export:
 
+Writeback Connectors
+
+
+.. kernel-doc:: drivers/gpu/drm/drm_writeback.c
+  :doc: overview
+
+.. kernel-doc:: drivers/gpu/drm/drm_writeback.c
+  :export:
+
 Encoder Abstraction
 ===
 
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 50093ff4479b..3d708959b224 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -18,7 +18,7 @@ drm-y   :=drm_auth.o drm_bufs.o drm_cache.o \
drm_encoder.o drm_mode_object.o drm_property.o \
drm_plane.o drm_color_mgmt.o drm_print.o \
drm_dumb_buffers.o drm_mode_config.o drm_vblank.o \
-   drm_syncobj.o drm_lease.o
+   drm_syncobj.o drm_lease.o drm_writeback.o
 
 drm-$(CONFIG_DRM_LIB_RANDOM) += lib/drm_random.o
 drm-$(CONFIG_DRM_VM) += drm_vm.o
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 46733d534587..019f131fe8be 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "drm_crtc_internal.h"
@@ -638,6 +639,46 @@ static void drm_atomic_crtc_print_state(struct drm_printer 
*p,
crtc->funcs->atomic_print_state(p, state);
 }
 
+/**
+ * drm_atomic_connector_check - check connector state
+ * @connector: connector to check
+ * @state: connector state to check
+ *
+ * Provides core sanity checks for connector state.
+ *
+ * RETURNS:
+ * Zero on success, error code on failure
+ */
+static int drm_atomic_connector_check(struct drm_connector *connector,
+   struct drm_connector_state *state)
+{
+   struct drm_crtc_state *crtc_state;
+   struct drm_writeback_job *writeback_job = state->writeback_job;
+
+   if ((connector->connector_type != DRM_MODE_CONNECTOR_WRITEBACK) ||
+   !writeback_job)
+

Re: [RFC 1/4] drm: Add writeback connector type

[Rob Clark]

On Fri, Feb 23, 2018 at 9:00 AM, Liviu Dudau  wrote:
> Hi Rob,
>
> On Fri, Feb 23, 2018 at 08:17:51AM -0500, Rob Clark wrote:
>> From: Brian Starkey 
>>
>> Writeback connectors represent writeback engines which can write the
>> CRTC output to a memory framebuffer. Add a writeback connector type and
>> related support functions.
>>
>> Drivers should initialize a writeback connector with
>> drm_writeback_connector_init() which takes care of setting up all the
>> writeback-specific details on top of the normal functionality of
>> drm_connector_init().
>>
>> Writeback connectors have a WRITEBACK_FB_ID property, used to set the
>> output framebuffer, and a WRITEBACK_PIXEL_FORMATS blob used to expose the
>> supported writeback formats to userspace.
>>
>> When a framebuffer is attached to a writeback connector with the
>> WRITEBACK_FB_ID property, it is used only once (for the commit in which
>> it was included), and userspace can never read back the value of
>> WRITEBACK_FB_ID. WRITEBACK_FB_ID can only be set if the connector is
>> attached to a CRTC.
>
> [snip]
>
>> +static bool create_writeback_properties(struct drm_device *dev)
>> +{
>> + struct drm_property *prop;
>> +
>> + if (!dev->mode_config.writeback_fb_id_property) {
>> + prop = drm_property_create_object(dev, DRM_MODE_PROP_ATOMIC,
>> +   "WRITEBACK_FB_ID",
>> +   DRM_MODE_OBJECT_FB);
>> + if (!prop)
>> + return false;
>> + dev->mode_config.writeback_fb_id_property = prop;
>> + }
>> +
>> + if (!dev->mode_config.writeback_pixel_formats_property) {
>> + prop = drm_property_create(dev, DRM_MODE_PROP_BLOB | 
>> DRM_MODE_PROP_IMMUTABLE,
>> +"WRITEBACK_PIXEL_FORMATS", 0);
>> + if (!prop)
>> + return false;
>> + dev->mode_config.writeback_pixel_formats_property = prop;
>> + }
>> +
>> + return true;
>> +}
>
> based on a buildbot warning and the fact that the next patch starts
> returning -ENOMEM inside the above function, I have this variant in my
> internal tree that I was preparing to send out once I've got my i-g-t
> tests in better shape:
>
> +static int create_writeback_properties(struct drm_device *dev)
> +{
> +   struct drm_property *prop;
> +
> +   if (!dev->mode_config.writeback_fb_id_property) {
> +   prop = drm_property_create_object(dev, DRM_MODE_PROP_ATOMIC,
> + "WRITEBACK_FB_ID",
> + DRM_MODE_OBJECT_FB);
> +   if (!prop)
> +   return -ENOMEM;
> +   dev->mode_config.writeback_fb_id_property = prop;
> +   }
> +
> +   if (!dev->mode_config.writeback_pixel_formats_property) {
> +   prop = drm_property_create(dev, DRM_MODE_PROP_BLOB | 
> DRM_MODE_PROP_IMMUTABLE,
> +  "WRITEBACK_PIXEL_FORMATS", 0);
> +   if (!prop)
> +   return -ENOMEM;
> +   dev->mode_config.writeback_pixel_formats_property = prop;
> +   }
> +
> +   return 0;
> +}
>
>
> Feel free to use this version in the next update if you're going to send
> one, otherwise I guess we could be patching it later.
>

hmm, I meant to keep my addition of funcs->atomic_commit() as a
separate fixup patch so it would be easier for you to fold back into
your patchset, but accidentally squashed it at some point and was too
lazy to split it out again.  Sorry about that.

BR,
-R

> Best regards,
> Liviu
>
>
>> +
>> +static const struct drm_encoder_funcs drm_writeback_encoder_funcs = {
>> + .destroy = drm_encoder_cleanup,
>> +};
>> +
>> +/**
>> + * drm_writeback_connector_init - Initialize a writeback connector and its 
>> properties
>> + * @dev: DRM device
>> + * @wb_connector: Writeback connector to initialize
>> + * @con_funcs: Connector funcs vtable
>> + * @enc_helper_funcs: Encoder helper funcs vtable to be used by the 
>> internal encoder
>> + * @formats: Array of supported pixel formats for the writeback engine
>> + * @n_formats: Length of the formats array
>> + *
>> + * This function creates the writeback-connector-specific properties if they
>> + * have not been already created, initializes the connector as
>> + * type DRM_MODE_CONNECTOR_WRITEBACK, and correctly initializes the property
>> + * values. It will also create an internal encoder associated with the
>> + * drm_writeback_connector and set it to use the @enc_helper_funcs vtable 
>> for
>> + * the encoder helper.
>> + *
>> + * Drivers should always use this function instead of drm_connector_init() 
>> to
>> + * set up writeback connectors.
>> + *
>> + * Returns: 0 on success, or a negative error code
>> + */
>> +int drm_writeback_connector_init(struct drm_device *dev,
>> 

Re: [RFC 1/4] drm: Add writeback connector type

[Liviu Dudau]

On Fri, Feb 23, 2018 at 09:24:10AM -0500, Rob Clark wrote:
> On Fri, Feb 23, 2018 at 9:00 AM, Liviu Dudau  wrote:
> > Hi Rob,
> >
> > On Fri, Feb 23, 2018 at 08:17:51AM -0500, Rob Clark wrote:
> >> From: Brian Starkey 
> >>
> >> Writeback connectors represent writeback engines which can write the
> >> CRTC output to a memory framebuffer. Add a writeback connector type and
> >> related support functions.
> >>
> >> Drivers should initialize a writeback connector with
> >> drm_writeback_connector_init() which takes care of setting up all the
> >> writeback-specific details on top of the normal functionality of
> >> drm_connector_init().
> >>
> >> Writeback connectors have a WRITEBACK_FB_ID property, used to set the
> >> output framebuffer, and a WRITEBACK_PIXEL_FORMATS blob used to expose the
> >> supported writeback formats to userspace.
> >>
> >> When a framebuffer is attached to a writeback connector with the
> >> WRITEBACK_FB_ID property, it is used only once (for the commit in which
> >> it was included), and userspace can never read back the value of
> >> WRITEBACK_FB_ID. WRITEBACK_FB_ID can only be set if the connector is
> >> attached to a CRTC.
> >
> > [snip]
> >
> >> +static bool create_writeback_properties(struct drm_device *dev)
> >> +{
> >> + struct drm_property *prop;
> >> +
> >> + if (!dev->mode_config.writeback_fb_id_property) {
> >> + prop = drm_property_create_object(dev, DRM_MODE_PROP_ATOMIC,
> >> +   "WRITEBACK_FB_ID",
> >> +   DRM_MODE_OBJECT_FB);
> >> + if (!prop)
> >> + return false;
> >> + dev->mode_config.writeback_fb_id_property = prop;
> >> + }
> >> +
> >> + if (!dev->mode_config.writeback_pixel_formats_property) {
> >> + prop = drm_property_create(dev, DRM_MODE_PROP_BLOB | 
> >> DRM_MODE_PROP_IMMUTABLE,
> >> +"WRITEBACK_PIXEL_FORMATS", 0);
> >> + if (!prop)
> >> + return false;
> >> + dev->mode_config.writeback_pixel_formats_property = prop;
> >> + }
> >> +
> >> + return true;
> >> +}
> >
> > based on a buildbot warning and the fact that the next patch starts
> > returning -ENOMEM inside the above function, I have this variant in my
> > internal tree that I was preparing to send out once I've got my i-g-t
> > tests in better shape:
> >
> > +static int create_writeback_properties(struct drm_device *dev)
> > +{
> > +   struct drm_property *prop;
> > +
> > +   if (!dev->mode_config.writeback_fb_id_property) {
> > +   prop = drm_property_create_object(dev, DRM_MODE_PROP_ATOMIC,
> > + "WRITEBACK_FB_ID",
> > + DRM_MODE_OBJECT_FB);
> > +   if (!prop)
> > +   return -ENOMEM;
> > +   dev->mode_config.writeback_fb_id_property = prop;
> > +   }
> > +
> > +   if (!dev->mode_config.writeback_pixel_formats_property) {
> > +   prop = drm_property_create(dev, DRM_MODE_PROP_BLOB | 
> > DRM_MODE_PROP_IMMUTABLE,
> > +  "WRITEBACK_PIXEL_FORMATS", 0);
> > +   if (!prop)
> > +   return -ENOMEM;
> > +   dev->mode_config.writeback_pixel_formats_property = prop;
> > +   }
> > +
> > +   return 0;
> > +}
> >
> >
> > Feel free to use this version in the next update if you're going to send
> > one, otherwise I guess we could be patching it later.
> >
> 
> hmm, I meant to keep my addition of funcs->atomic_commit() as a
> separate fixup patch so it would be easier for you to fold back into
> your patchset, but accidentally squashed it at some point and was too
> lazy to split it out again.  Sorry about that.

I'm not too fussed about who pushes Brian's framework patches into
drm-next so I don't mind at all you merging your addition. Just wanted
to make sure we're on the same page (didn't know you're going to send
your series this week).

I also feel I need to appologise for my delay in getting the i-g-t
patches into shape, I've been splitting myself between various other
tasks, not all kernel related.

Best regards,
Liviu

> 
> BR,
> -R
> 
> > Best regards,
> > Liviu
> >
> >
> >> +
> >> +static const struct drm_encoder_funcs drm_writeback_encoder_funcs = {
> >> + .destroy = drm_encoder_cleanup,
> >> +};
> >> +
> >> +/**
> >> + * drm_writeback_connector_init - Initialize a writeback connector and 
> >> its properties
> >> + * @dev: DRM device
> >> + * @wb_connector: Writeback connector to initialize
> >> + * @con_funcs: Connector funcs vtable
> >> + * @enc_helper_funcs: Encoder helper funcs vtable to be used by the 
> >> internal encoder
> >> + * @formats: Array of supported pixel formats for the writeback engine
> >> + * @n_formats: 

Re: [PATCH v2] doc: admin-guide/module-signing.rst fixes

[Jonathan Corbet]

On Mon, 19 Feb 2018 10:39:00 +0100
Philipp Hahn  wrote:

> Two trivial corrections for the module signing documentation.
> 
> v2: Add missing Signed-off-by
> 
> Philipp Hahn (2):
>   doc: Rename .system_keyring to .builtin_trusted_keys
>   doc: module-signing.rst: Fix reST formatting
> 
>  Documentation/admin-guide/module-signing.rst | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)

I've applied both to the docs tree, thanks.

jon
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html