Re: [PATCH] ANDROID: binder: pr_err() strings should end with newlines
On Mon, Sep 25, 2017 at 12:21:47PM +0530, Arvind Yadav wrote: > Signed-off-by: Arvind Yadav > --- I can't take patches without any changelog text, sorry. greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] ANDROID: binder: pr_err() strings should end with newlines
On Monday 25 September 2017 12:31 PM, Greg KH wrote: On Mon, Sep 25, 2017 at 12:21:47PM +0530, Arvind Yadav wrote: Signed-off-by: Arvind Yadav --- I can't take patches without any changelog text, sorry. As per your concern, I will update. greg k-h ~arvind ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] staging: atomisp: add a driver for ov5648 camera sensor
On Sun, 2017-09-24 at 16:59 +0200, Devid Antonio Floni wrote:
> The ov5648 5-megapixel camera sensor from OmniVision supports up to
> 2592x1944
> resolution and MIPI CSI-2 interface. Output format is raw sRGB/Bayer
> with
> 10 bits per colour (SGRBG10_1X10).
>
> This patch is a port of ov5648 driver after applying following
> 01org/ProductionKernelQuilts patches:
> - 0004-ov2680-ov5648-Fork-lift-source-from-CTS.patch
> - 0005-ov2680-ov5648-gminification.patch
> - 0006-ov5648-Focus-support.patch
> - 0007-Fix-resolution-issues-on-rear-camera.patch
> - 0008-ov2680-ov5648-Enabled-the-set_exposure-functions.patch
> - 0010-IRDA-cameras-mode-list-cleanup-unification.patch
> - 0012-ov5648-Add-1296x972-binned-mode.patch
> - 0014-ov5648-Adapt-to-Atomisp2-Gmin-VCM-framework.patch
> - 0015-dw9714-Gmin-Atomisp-specific-VCM-driver.patch
> - 0017-ov5648-Fix-deadlock-on-I2C-error.patch
> - 0018-gc2155-Fix-deadlock-on-error.patch
> - 0019-ov5648-Add-1280x960-binned-mode.patch
> - 0020-ov5648-Make-1280x960-as-default-video-resolution.patch
> - 0021-MALATA-Fix-testCameraToSurfaceTextureMetadata-CTS.patch
> - 0023-OV5648-Added-5MP-video-resolution.patch
>
> New changes introduced during the port:
> - Rename entity types to entity functions
> - Replace v4l2_subdev_fh by v4l2_subdev_pad_config
> - Make use of media_bus_format enum
> - Rename media_entity_init function to media_entity_pads_init
> - Replace try_mbus_fmt by set_fmt
> - Replace s_mbus_fmt by set_fmt
> - Replace g_mbus_fmt by get_fmt
> - Use s_ctrl/g_volatile_ctrl instead of ctrl core ops
> - Update gmin platform API path
> - Constify acpi_device_id
> - Add "INT5648" value to acpi_device_id
> - Fix some checkpatch errors and warnings
> - Remove FSF's mailing address from the sample GPL notice
>
> Changes in v2:
> - Fix indentation
> - Add atomisp prefix to Kconfig option
The above paragraph usually goes after --- delimiter line.
While v2 is better, it needs much more work. See my few comments (tip of
an iceberg) below.
>
> "INT5648" ACPI device id can be found in following production
> hardware:
> BIOS Information
> Vendor: LENOVO
> Version: 1HCN40WW
> Release Date: 11/04/2016
> ...
> BIOS Revision: 0.40
> Firmware Revision: 0.0
> ...
> System Information
> Manufacturer: LENOVO
> Product Name: 80SG
> Version: MIIX 310-10ICR
> ...
> SKU Number: LENOVO_MT_80SG_BU_idea_FM_MIIX 310-10ICR
> Family: IDEAPAD
> ...
>
> Device DSDT excerpt:
> Device (CA00)
> {
> Name (_ADR, Zero) // _ADR: Address
> Name (_HID, "INT5648") // _HID: Hardware ID
> Name (_CID, "INT5648") // _CID: Compatible ID
> Name (_SUB, "INTL") // _SUB: Subsystem ID
> Name (_DDN, "ov5648") // _DDN: DOS Device Name
> ...
Thanks for the above description!
>
> I was not able to properly test this patch on my Lenovo Miix 310 due
> to other
> issues with atomisp, the output is the same as ov2680 driver
> (OVTI2680)
> which is very similar.
> +#include
(1)
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
(2)
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include "../include/linux/atomisp_gmin_platform.h"
> +
> +#include "ov5648.h"
One of (1) and (2) is redundant.
Can we also keep them in alphabetical order? Rationale is to fast search
among and avoiding duplication.
> +static int ov5648_read_reg(struct i2c_client *client,
> +u16 data_length, u16 reg, u16 *val)
> +{
> + int err;
> + struct i2c_msg msg[2];
> + unsigned char data[6];
> +
> + if (!client->adapter) {
> + dev_err(&client->dev, "%s error, no client-
> >adapter\n",
> + __func__);
> + return -ENODEV;
> + }
Hmm... When it's possible?
> +
> + if (data_length != OV5648_8BIT && data_length != OV5648_16BIT
> + && data_length !=
> OV5648_32BIT) {
> + dev_err(&client->dev, "%s error, invalid data
> length\n",
> + __func__);
> + return -EINVAL;
> + }
> +
>
> +
> + err = i2c_transfer(client->adapter, msg, 2);
> + if (err != 2) {
> + if (err >= 0)
> + err = -EIO;
This will hide an error below (in case it's returned -EIO vs. err ==
1)...
> + dev_err(&client->dev,
> + "read from offset 0x%x error %d", reg, err);
...thus would be better to
dev_err();
return err < 0 ? err : - EIO;
> + return err;
> + }
> +
> + *val = 0;
> + /* high byte comes first */
> + if (data_length == OV5648_8BIT)
> + *val = (u8)data[0];
> + else if (data_length == OV5648_16BIT)
> + *val = be16_to_cpu(*(u16 *)&data[0]);
> + else
> + *val = be32_to_
Re: [PATCH v2 10/11] staging: typec: fusb302: Hook up mux support using tcpc_gen_mux support
On 2017-09-13 17:48, Hans de Goede wrote: > Hi, > > On 13-09-17 17:07, Rob Herring wrote: >> On Wed, Sep 13, 2017 at 9:06 AM, Hans de Goede wrote: >>> Hi, >>> >>> >>> On 13-09-17 15:38, Rob Herring wrote: On Wed, Sep 13, 2017 at 3:56 AM, Hans de Goede wrote: > > Hi, > > > On 13-09-17 00:20, Rob Herring wrote: >> >> >> On Tue, Sep 05, 2017 at 06:42:20PM +0200, Hans de Goede wrote: >>> >>> >>> Add mux support to the fusb302 driver, call devm_tcpc_gen_mux_create() >>> to let the generic tcpc_mux_dev code create a tcpc_mux_dev for us. >>> >>> Also document the mux-names used by the generic tcpc_mux_dev code in >>> our devicetree bindings. >>> >>> Cc: Rob Herring >>> Cc: Mark Rutland >>> Cc: devicet...@vger.kernel.org >>> Signed-off-by: Hans de Goede >>> --- >>> Documentation/devicetree/bindings/usb/fcs,fusb302.txt | 3 +++ >>> drivers/staging/typec/fusb302/fusb302.c | 11 >>> ++- >>> 2 files changed, 13 insertions(+), 1 deletion(-) >>> >>> diff --git a/Documentation/devicetree/bindings/usb/fcs,fusb302.txt >>> b/Documentation/devicetree/bindings/usb/fcs,fusb302.txt >>> index 472facfa5a71..63d639eadacd 100644 >>> --- a/Documentation/devicetree/bindings/usb/fcs,fusb302.txt >>> +++ b/Documentation/devicetree/bindings/usb/fcs,fusb302.txt >>> @@ -6,6 +6,9 @@ Required properties : >>> - interrupts : Interrupt specifier >>> Optional properties : >>> +- mux-controls : List of mux-ctrl-specifiers containing 1 or >>> 2 >>> muxes >>> +- mux-names : "type-c-mode-mux" when using 1 mux, or >>> + "type-c-mode-mux", "usb-role-mux" when >>> using >>> 2 muxes >> >> >> >> I'm not sure this is the right place for this. The mux is outside the >> FUSB302. In a type-C connector node or USB phy node would make more >> sense to me. > > > > The mux certainly does not belong in the USB phy node, it sits between > the > USB PHY > and the Type-C connector and can for example also mux the Type-C pins to > a > Display > Port PHY. Thinking about this some more, the mux(es) should be its own node(s). Then the question is where to put the nodes. >>> >>> >>> Right, the mux will be its own node per >>> Documentation/devicetree/bindings/mux/mux-controller.txt >>> the bindings bit this patch is adding is only adding phandles pointing >>> to that mux-node as the fusb302 "consumes" the mux functionality. >>> >>> So as such (the fusb302 is the component which should control the mux) >>> I do believe that the bindings this patch adds are correct. >> >> Humm, that's not how the mux binding works. The mux controller is what >> drives the mux select lines and is the provider. The consumer is the >> mux device itself. What decides the mux state is determined by what >> you are muxing, not which node has mux-controls property. >> >> By putting mux-controls in fusb302 node, you are saying fusb302 is a >> mux (or contains a mux). >> >> > As for putting it in a type-C connector node, currently we do not have > such > a node, Well, you should. Type-C connectors are certainly complicated enough that we'll need one. Plus we already require connector nodes for display outputs, so what do we do once you add display muxing? >>> >>> >>> An interesting question, I'm working on this for x86 + ACPI boards actually, >>> not a board using DT I've been adding DT bindings docs for device-properties >>> I use because that seems like the right thing to do where the binding is >>> obvious >>> (which I believe it is in this case as the fusb302 is the mux consumer) and >>> because the device-property code should work the same on x86 + ACPI >>> (where some platform-specific drivers attach the device properties) and >>> on e.g. ARM + DT. >>> >>> The rest should probably be left to be figured out when an actual DT >>> using device using the fusb302 or another Type-C controller shows up. >> >> Well this is a new one (maybe, I suppose others have sneaked by). If >> ACPI folks want to use DT bindings, then what do I care. But I have no >> interest in reviewing ACPI properties. The whole notion of sharing >> bindings between DT and ACPI beyond anything trivial is flawed IMO. >> The ptifalls have been discussed multiple times before, so I'm not >> going to repeat them here. > > Ok, so shall I just drop the > Documentation/devicetree/bindings/usb/fcs,fusb302.txt > part of this patch then ? I totally agree with the concern that Rob expressed about handling USB C muxes in a non-adhoc way. And this makes this series scary. I don't know enough details about USB C muxes and PD (I just have a very superficial mental model) to tell if this series is going down the right path. Or how terrib
Re: [PATCH v2 10/11] staging: typec: fusb302: Hook up mux support using tcpc_gen_mux support
Hi, On 25-09-17 12:34, Peter Rosin wrote: On 2017-09-13 17:48, Hans de Goede wrote: Hi, On 13-09-17 17:07, Rob Herring wrote: On Wed, Sep 13, 2017 at 9:06 AM, Hans de Goede wrote: Hi, On 13-09-17 15:38, Rob Herring wrote: On Wed, Sep 13, 2017 at 3:56 AM, Hans de Goede wrote: Hi, On 13-09-17 00:20, Rob Herring wrote: On Tue, Sep 05, 2017 at 06:42:20PM +0200, Hans de Goede wrote: Add mux support to the fusb302 driver, call devm_tcpc_gen_mux_create() to let the generic tcpc_mux_dev code create a tcpc_mux_dev for us. Also document the mux-names used by the generic tcpc_mux_dev code in our devicetree bindings. Cc: Rob Herring Cc: Mark Rutland Cc: devicet...@vger.kernel.org Signed-off-by: Hans de Goede --- Documentation/devicetree/bindings/usb/fcs,fusb302.txt | 3 +++ drivers/staging/typec/fusb302/fusb302.c | 11 ++- 2 files changed, 13 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/usb/fcs,fusb302.txt b/Documentation/devicetree/bindings/usb/fcs,fusb302.txt index 472facfa5a71..63d639eadacd 100644 --- a/Documentation/devicetree/bindings/usb/fcs,fusb302.txt +++ b/Documentation/devicetree/bindings/usb/fcs,fusb302.txt @@ -6,6 +6,9 @@ Required properties : - interrupts : Interrupt specifier Optional properties : +- mux-controls : List of mux-ctrl-specifiers containing 1 or 2 muxes +- mux-names : "type-c-mode-mux" when using 1 mux, or + "type-c-mode-mux", "usb-role-mux" when using 2 muxes I'm not sure this is the right place for this. The mux is outside the FUSB302. In a type-C connector node or USB phy node would make more sense to me. The mux certainly does not belong in the USB phy node, it sits between the USB PHY and the Type-C connector and can for example also mux the Type-C pins to a Display Port PHY. Thinking about this some more, the mux(es) should be its own node(s). Then the question is where to put the nodes. Right, the mux will be its own node per Documentation/devicetree/bindings/mux/mux-controller.txt the bindings bit this patch is adding is only adding phandles pointing to that mux-node as the fusb302 "consumes" the mux functionality. So as such (the fusb302 is the component which should control the mux) I do believe that the bindings this patch adds are correct. Humm, that's not how the mux binding works. The mux controller is what drives the mux select lines and is the provider. The consumer is the mux device itself. What decides the mux state is determined by what you are muxing, not which node has mux-controls property. By putting mux-controls in fusb302 node, you are saying fusb302 is a mux (or contains a mux). As for putting it in a type-C connector node, currently we do not have such a node, Well, you should. Type-C connectors are certainly complicated enough that we'll need one. Plus we already require connector nodes for display outputs, so what do we do once you add display muxing? An interesting question, I'm working on this for x86 + ACPI boards actually, not a board using DT I've been adding DT bindings docs for device-properties I use because that seems like the right thing to do where the binding is obvious (which I believe it is in this case as the fusb302 is the mux consumer) and because the device-property code should work the same on x86 + ACPI (where some platform-specific drivers attach the device properties) and on e.g. ARM + DT. The rest should probably be left to be figured out when an actual DT using device using the fusb302 or another Type-C controller shows up. Well this is a new one (maybe, I suppose others have sneaked by). If ACPI folks want to use DT bindings, then what do I care. But I have no interest in reviewing ACPI properties. The whole notion of sharing bindings between DT and ACPI beyond anything trivial is flawed IMO. The ptifalls have been discussed multiple times before, so I'm not going to repeat them here. Ok, so shall I just drop the Documentation/devicetree/bindings/usb/fcs,fusb302.txt part of this patch then ? I totally agree with the concern that Rob expressed about handling USB C muxes in a non-adhoc way. And this makes this series scary. I don't know enough details about USB C muxes and PD (I just have a very superficial mental model) to tell if this series is going down the right path. Or how terrible it will be to fix things up if not? The series extends the mux subsystem with muxes that pins semantics to specific states. That is new, and shows up exactly here when Rob is not happy about the binding. And if Rob does not want this in the DT bindings then I'm not so sure it is wise to do it at all? This problem doesn't go away just because you remove the binding. I think I would feel much better if there was a path forward on how to represent USB C muxes in DT and how that would fit with the driver structure. If you compare to the i2c-muxes, there is a
[PATCH] HID: hyperv: pr_err() strings should end with newlines
pr_err() messages should terminated with a new-line to avoid
other messages being concatenated onto the end.
Signed-off-by: Arvind Yadav
---
drivers/hid/hid-hyperv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hid/hid-hyperv.c b/drivers/hid/hid-hyperv.c
index 6039f07..3aa2bb9 100644
--- a/drivers/hid/hid-hyperv.c
+++ b/drivers/hid/hid-hyperv.c
@@ -313,7 +313,7 @@ static void mousevsc_on_receive(struct hv_device *device,
break;
default:
- pr_err("unsupported hid msg type - type %d len %d",
+ pr_err("unsupported hid msg type - type %d len %d\n",
hid_msg->header.type, hid_msg->header.size);
break;
}
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 10/11] staging: typec: fusb302: Hook up mux support using tcpc_gen_mux support
On 2017-09-25 13:35, Hans de Goede wrote: > Hi, > > On 25-09-17 12:34, Peter Rosin wrote: >> On 2017-09-13 17:48, Hans de Goede wrote: >>> Hi, >>> >>> On 13-09-17 17:07, Rob Herring wrote: On Wed, Sep 13, 2017 at 9:06 AM, Hans de Goede wrote: > Hi, > > > On 13-09-17 15:38, Rob Herring wrote: >> >> On Wed, Sep 13, 2017 at 3:56 AM, Hans de Goede >> wrote: >>> >>> Hi, >>> >>> >>> On 13-09-17 00:20, Rob Herring wrote: On Tue, Sep 05, 2017 at 06:42:20PM +0200, Hans de Goede wrote: > > > Add mux support to the fusb302 driver, call devm_tcpc_gen_mux_create() > to let the generic tcpc_mux_dev code create a tcpc_mux_dev for us. > > Also document the mux-names used by the generic tcpc_mux_dev code in > our devicetree bindings. > > Cc: Rob Herring > Cc: Mark Rutland > Cc: devicet...@vger.kernel.org > Signed-off-by: Hans de Goede > --- > Documentation/devicetree/bindings/usb/fcs,fusb302.txt | 3 +++ > drivers/staging/typec/fusb302/fusb302.c | 11 > ++- > 2 files changed, 13 insertions(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/usb/fcs,fusb302.txt > b/Documentation/devicetree/bindings/usb/fcs,fusb302.txt > index 472facfa5a71..63d639eadacd 100644 > --- a/Documentation/devicetree/bindings/usb/fcs,fusb302.txt > +++ b/Documentation/devicetree/bindings/usb/fcs,fusb302.txt > @@ -6,6 +6,9 @@ Required properties : > - interrupts : Interrupt specifier >Optional properties : > +- mux-controls : List of mux-ctrl-specifiers containing 1 > or > 2 > muxes > +- mux-names : "type-c-mode-mux" when using 1 mux, or > + "type-c-mode-mux", "usb-role-mux" when > using > 2 muxes I'm not sure this is the right place for this. The mux is outside the FUSB302. In a type-C connector node or USB phy node would make more sense to me. >>> >>> >>> >>> The mux certainly does not belong in the USB phy node, it sits between >>> the >>> USB PHY >>> and the Type-C connector and can for example also mux the Type-C pins to >>> a >>> Display >>> Port PHY. >> >> >> Thinking about this some more, the mux(es) should be its own node(s). >> Then the question is where to put the nodes. > > > Right, the mux will be its own node per > Documentation/devicetree/bindings/mux/mux-controller.txt > the bindings bit this patch is adding is only adding phandles pointing > to that mux-node as the fusb302 "consumes" the mux functionality. > > So as such (the fusb302 is the component which should control the mux) > I do believe that the bindings this patch adds are correct. Humm, that's not how the mux binding works. The mux controller is what drives the mux select lines and is the provider. The consumer is the mux device itself. What decides the mux state is determined by what you are muxing, not which node has mux-controls property. By putting mux-controls in fusb302 node, you are saying fusb302 is a mux (or contains a mux). >>> As for putting it in a type-C connector node, currently we do not have >>> such >>> a node, >> >> >> Well, you should. Type-C connectors are certainly complicated enough >> that we'll need one. Plus we already require connector nodes for >> display outputs, so what do we do once you add display muxing? > > > An interesting question, I'm working on this for x86 + ACPI boards > actually, > not a board using DT I've been adding DT bindings docs for > device-properties > I use because that seems like the right thing to do where the binding is > obvious > (which I believe it is in this case as the fusb302 is the mux consumer) > and > because the device-property code should work the same on x86 + ACPI > (where some platform-specific drivers attach the device properties) and > on e.g. ARM + DT. > > The rest should probably be left to be figured out when an actual DT > using device using the fusb302 or another Type-C controller shows up. Well this is a new one (maybe, I suppose others have sneaked by). If ACPI folks want to use DT bindings, then what do I care. But I have no interest in reviewing ACPI properties. The whole notion of sharing bindings between DT and ACPI beyond anything trivial is flawed IMO. The ptifalls have been discussed multiple times before, so I'm not going to repeat them here. >>> >>> Ok, so shall I just drop the >>> Document
Re: [PATCH v2 10/11] staging: typec: fusb302: Hook up mux support using tcpc_gen_mux support
Hi, On 25-09-17 15:45, Peter Rosin wrote: On 2017-09-25 13:35, Hans de Goede wrote: Hi, On 25-09-17 12:34, Peter Rosin wrote: On 2017-09-13 17:48, Hans de Goede wrote: Hi, On 13-09-17 17:07, Rob Herring wrote: On Wed, Sep 13, 2017 at 9:06 AM, Hans de Goede wrote: Hi, On 13-09-17 15:38, Rob Herring wrote: On Wed, Sep 13, 2017 at 3:56 AM, Hans de Goede wrote: Hi, On 13-09-17 00:20, Rob Herring wrote: On Tue, Sep 05, 2017 at 06:42:20PM +0200, Hans de Goede wrote: Add mux support to the fusb302 driver, call devm_tcpc_gen_mux_create() to let the generic tcpc_mux_dev code create a tcpc_mux_dev for us. Also document the mux-names used by the generic tcpc_mux_dev code in our devicetree bindings. Cc: Rob Herring Cc: Mark Rutland Cc: devicet...@vger.kernel.org Signed-off-by: Hans de Goede --- Documentation/devicetree/bindings/usb/fcs,fusb302.txt | 3 +++ drivers/staging/typec/fusb302/fusb302.c | 11 ++- 2 files changed, 13 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/usb/fcs,fusb302.txt b/Documentation/devicetree/bindings/usb/fcs,fusb302.txt index 472facfa5a71..63d639eadacd 100644 --- a/Documentation/devicetree/bindings/usb/fcs,fusb302.txt +++ b/Documentation/devicetree/bindings/usb/fcs,fusb302.txt @@ -6,6 +6,9 @@ Required properties : - interrupts : Interrupt specifier Optional properties : +- mux-controls : List of mux-ctrl-specifiers containing 1 or 2 muxes +- mux-names : "type-c-mode-mux" when using 1 mux, or + "type-c-mode-mux", "usb-role-mux" when using 2 muxes I'm not sure this is the right place for this. The mux is outside the FUSB302. In a type-C connector node or USB phy node would make more sense to me. The mux certainly does not belong in the USB phy node, it sits between the USB PHY and the Type-C connector and can for example also mux the Type-C pins to a Display Port PHY. Thinking about this some more, the mux(es) should be its own node(s). Then the question is where to put the nodes. Right, the mux will be its own node per Documentation/devicetree/bindings/mux/mux-controller.txt the bindings bit this patch is adding is only adding phandles pointing to that mux-node as the fusb302 "consumes" the mux functionality. So as such (the fusb302 is the component which should control the mux) I do believe that the bindings this patch adds are correct. Humm, that's not how the mux binding works. The mux controller is what drives the mux select lines and is the provider. The consumer is the mux device itself. What decides the mux state is determined by what you are muxing, not which node has mux-controls property. By putting mux-controls in fusb302 node, you are saying fusb302 is a mux (or contains a mux). As for putting it in a type-C connector node, currently we do not have such a node, Well, you should. Type-C connectors are certainly complicated enough that we'll need one. Plus we already require connector nodes for display outputs, so what do we do once you add display muxing? An interesting question, I'm working on this for x86 + ACPI boards actually, not a board using DT I've been adding DT bindings docs for device-properties I use because that seems like the right thing to do where the binding is obvious (which I believe it is in this case as the fusb302 is the mux consumer) and because the device-property code should work the same on x86 + ACPI (where some platform-specific drivers attach the device properties) and on e.g. ARM + DT. The rest should probably be left to be figured out when an actual DT using device using the fusb302 or another Type-C controller shows up. Well this is a new one (maybe, I suppose others have sneaked by). If ACPI folks want to use DT bindings, then what do I care. But I have no interest in reviewing ACPI properties. The whole notion of sharing bindings between DT and ACPI beyond anything trivial is flawed IMO. The ptifalls have been discussed multiple times before, so I'm not going to repeat them here. Ok, so shall I just drop the Documentation/devicetree/bindings/usb/fcs,fusb302.txt part of this patch then ? I totally agree with the concern that Rob expressed about handling USB C muxes in a non-adhoc way. And this makes this series scary. I don't know enough details about USB C muxes and PD (I just have a very superficial mental model) to tell if this series is going down the right path. Or how terrible it will be to fix things up if not? The series extends the mux subsystem with muxes that pins semantics to specific states. That is new, and shows up exactly here when Rob is not happy about the binding. And if Rob does not want this in the DT bindings then I'm not so sure it is wise to do it at all? This problem doesn't go away just because you remove the binding. I think I would feel much better if there was a path forward on how to represent USB C muxes in DT an
Re: [PATCH v3] staging: greybus: light: Release memory obtained by kasprintf
Hi, On Sat, Sep 23, 2017 at 01:25:30PM +0530, Arvind Yadav wrote: > Free memory region, if gb_lights_channel_config is not successful. > > Signed-off-by: Arvind Yadav Thanks for the patch, looks good to me. Reviewed-by: Rui Miguel Silva --- Cheers, Rui > --- > changes in v2: > - Subject line changed. > - add kfree in __gb_lights_led_unregister(). > - No need to check return value of > gb_lights_channel_flash_config(). > > changes ib v3: > - separate patch for "No need to check return value of > gb_lights_channel_flash_config()". > > drivers/staging/greybus/light.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/staging/greybus/light.c b/drivers/staging/greybus/light.c > index 3f4148c..0f538b8 100644 > --- a/drivers/staging/greybus/light.c > +++ b/drivers/staging/greybus/light.c > @@ -925,6 +925,8 @@ static void __gb_lights_led_unregister(struct gb_channel > *channel) > return; > > led_classdev_unregister(cdev); > + kfree(cdev->name); > + cdev->name = NULL; > channel->led = NULL; > } > > -- > 2.7.4 > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: greybus: light: remove unnecessary error check
Hi, On Sat, Sep 23, 2017 at 01:39:15PM +0530, Arvind Yadav wrote: > It is not necessary to check return value of gb_lights_channel_flash_config. > gb_lights_channel_config returns both successful and error value. > > Signed-off-by: Arvind Yadav Thanks for the patch. Reviewed-by: Rui Miguel Silva --- Cheers, Rui > --- > drivers/staging/greybus/light.c | 6 +- > 1 file changed, 1 insertion(+), 5 deletions(-) > > diff --git a/drivers/staging/greybus/light.c b/drivers/staging/greybus/light.c > index 0f538b8..d7da475 100644 > --- a/drivers/staging/greybus/light.c > +++ b/drivers/staging/greybus/light.c > @@ -1000,11 +1000,7 @@ static int gb_lights_channel_config(struct gb_light > *light, > > light->has_flash = true; > > - ret = gb_lights_channel_flash_config(channel); > - if (ret < 0) > - return ret; > - > - return ret; > + return gb_lights_channel_flash_config(channel); > } > > static int gb_lights_light_config(struct gb_lights *glights, u8 id) > -- > 2.7.4 > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 2/2] staging: ion: create one device entry per heap
On 09/20/2017 01:45 AM, Benjamin Gaignard wrote:
Instead a getting one common device "/dev/ion" for
all the heaps this patch allow to create one device
entry ("/dev/ionX") per heap.
Getting an entry per heap could allow to set security rules
per heap and global ones for all heaps.
Allocation requests will be only allowed if the mask_id
match with device minor.
Query request could be done on any of the devices.
Deivce node major will also change and that may impact init scripts.
We should start Cc linux-api for future changes since we're going
to have more than just /dev/ion.
Thinking about this some more, I think we need to allow backwards
compatibility. It's just not feasible to keep throwing workarounds
into userspace if we can avoid it. I'd propose keeping the old /dev/ion
misc interface available under a Kconfig and then creating the new
split heaps in parallel.
On a somewhat related note, there was some interest in possibly
having a sysfs interface for Ion long term. I don't think this
needs to happen right now but I'd like whatever we do to not
make adding that harder.
Thanks,
Laura
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 01/22] mm/shmem: support passing mnt to shmem_file_setup
We are planning to use our own tmpfs mnt in i915 in place of the
shm_mnt such that we can control the mount options, in particular
huge=, which we require to support huge-gtt-pages. So rather than roll
our own version of __shmem_file_setup, it would be preferred if we could
just give shmem our mnt, and let it do the rest.
Based on the patch: https://patchwork.freedesktop.org/patch/178433/
Suggested-by: Chris Wilson
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
Cc: Chris Wilson
Cc: Daniel Vetter
Cc: Dave Hansen
Cc: Kirill A. Shutemov
Cc: Andrew Morton
Cc: Hugh Dickins
Cc: Greg Kroah-Hartman
Cc: "Arve Hjønnevåg"
Cc: Riley Andrews
Cc: dri-de...@lists.freedesktop.org
Cc: linux...@kvack.org
Cc: de...@driverdev.osuosl.org
---
drivers/gpu/drm/drm_gem.c| 2 +-
drivers/gpu/drm/ttm/ttm_tt.c | 2 +-
drivers/staging/android/ashmem.c | 3 ++-
include/linux/shmem_fs.h | 4 +++-
mm/shmem.c | 24 ++--
5 files changed, 21 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 7199bba68c37..12e5fdc90a6f 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -138,7 +138,7 @@ int drm_gem_object_init(struct drm_device *dev,
drm_gem_private_object_init(dev, obj, size);
- filp = shmem_file_setup("drm mm object", size, VM_NORESERVE);
+ filp = shmem_file_setup(TMPFS_MNT, "drm mm object", size, VM_NORESERVE);
if (IS_ERR(filp))
return PTR_ERR(filp);
diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index 8ebc8d3560c3..4eef07d8b8ed 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -336,7 +336,7 @@ int ttm_tt_swapout(struct ttm_tt *ttm, struct file
*persistent_swap_storage)
BUG_ON(ttm->caching_state != tt_cached);
if (!persistent_swap_storage) {
- swap_storage = shmem_file_setup("ttm swap",
+ swap_storage = shmem_file_setup(TMPFS_MNT, "ttm swap",
ttm->num_pages << PAGE_SHIFT,
0);
if (IS_ERR(swap_storage)) {
diff --git a/drivers/staging/android/ashmem.c b/drivers/staging/android/ashmem.c
index 0f695df14c9d..184fcbb6d127 100644
--- a/drivers/staging/android/ashmem.c
+++ b/drivers/staging/android/ashmem.c
@@ -391,7 +391,8 @@ static int ashmem_mmap(struct file *file, struct
vm_area_struct *vma)
name = asma->name;
/* ... and allocate the backing shmem file */
- vmfile = shmem_file_setup(name, asma->size, vma->vm_flags);
+ vmfile = shmem_file_setup(TMPFS_MNT, name, asma->size,
+ vma->vm_flags);
if (IS_ERR(vmfile)) {
ret = PTR_ERR(vmfile);
goto out;
diff --git a/include/linux/shmem_fs.h b/include/linux/shmem_fs.h
index b6c3540e07bc..00b199d804ca 100644
--- a/include/linux/shmem_fs.h
+++ b/include/linux/shmem_fs.h
@@ -44,12 +44,14 @@ static inline struct shmem_inode_info *SHMEM_I(struct inode
*inode)
return container_of(inode, struct shmem_inode_info, vfs_inode);
}
+#define TMPFS_MNT NULL
+
/*
* Functions in mm/shmem.c called directly from elsewhere:
*/
extern int shmem_init(void);
extern int shmem_fill_super(struct super_block *sb, void *data, int silent);
-extern struct file *shmem_file_setup(const char *name,
+extern struct file *shmem_file_setup(struct vfsmount *mnt, const char *name,
loff_t size, unsigned long flags);
extern struct file *shmem_kernel_file_setup(const char *name, loff_t size,
unsigned long flags);
diff --git a/mm/shmem.c b/mm/shmem.c
index 07a1d22807be..ae2e46291ffa 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -3715,7 +3715,7 @@ SYSCALL_DEFINE2(memfd_create,
(flags >> MFD_HUGE_SHIFT) &
MFD_HUGE_MASK);
} else
- file = shmem_file_setup(name, 0, VM_NORESERVE);
+ file = shmem_file_setup(TMPFS_MNT, name, 0, VM_NORESERVE);
if (IS_ERR(file)) {
error = PTR_ERR(file);
goto err_fd;
@@ -4183,7 +4183,7 @@ static const struct dentry_operations anon_ops = {
.d_dname = simple_dname
};
-static struct file *__shmem_file_setup(const char *name, loff_t size,
+static struct file *__shmem_file_setup(struct vfsmount *mnt, const char *name,
loff_t size,
unsigned long flags, unsigned int
i_flags)
{
struct file *res;
@@ -4192,8 +4192,11 @@ static struct file *__shmem_file_setup(const char *name,
loff_t size,
struct super_block *sb;
struct qstr this;
- if (IS_ERR(shm_mnt))
- return ERR_CAST(shm_mnt);
+ if (mnt =
[PATCH 02/22] drm/i915: introduce simple gemfs
Not a fully blown gemfs, just our very own tmpfs kernel mount. Doing so
moves us away from the shmemfs shm_mnt, and gives us the much needed
flexibility to do things like set our own mount options, namely huge=
which should allow us to enable the use of transparent-huge-pages for
our shmem backed objects.
v2: various improvements suggested by Joonas
v3: move gemfs instance to i915.mm and simplify now that we have
file_setup_with_mnt
v4: fallback to tmpfs shm_mnt upon failure to setup gemfs
v5: make tmpfs fallback kinder
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
Cc: Chris Wilson
Cc: Daniel Vetter
Cc: Dave Hansen
Cc: Kirill A. Shutemov
Cc: Andrew Morton
Cc: Hugh Dickins
Cc: Greg Kroah-Hartman
Cc: "Arve Hjønnevåg"
Cc: Riley Andrews
Cc: dri-de...@lists.freedesktop.org
Cc: linux...@kvack.org
Cc: de...@driverdev.osuosl.org
---
drivers/gpu/drm/i915/Makefile| 1 +
drivers/gpu/drm/i915/i915_drv.h | 5 +++
drivers/gpu/drm/i915/i915_gem.c | 26 +++-
drivers/gpu/drm/i915/i915_gemfs.c| 52
drivers/gpu/drm/i915/i915_gemfs.h| 34
drivers/gpu/drm/i915/selftests/mock_gem_device.c | 4 ++
6 files changed, 121 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/i915/i915_gemfs.c
create mode 100644 drivers/gpu/drm/i915/i915_gemfs.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 5182e3d5557d..980c41568f46 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -47,6 +47,7 @@ i915-y += i915_cmd_parser.o \
i915_gem_tiling.o \
i915_gem_timeline.o \
i915_gem_userptr.o \
+ i915_gemfs.o \
i915_trace_points.o \
i915_vma.o \
intel_breadcrumbs.o \
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 61a4be9c2d37..d2079c863a9f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1501,6 +1501,11 @@ struct i915_gem_mm {
/** Usable portion of the GTT for GEM */
dma_addr_t stolen_base; /* limited to low memory (32-bit) */
+ /**
+* tmpfs instance used for shmem backed objects
+*/
+ struct vfsmount *gemfs;
+
/** PPGTT used for aliasing the PPGTT with the GTT */
struct i915_hw_ppgtt *aliasing_ppgtt;
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 73eeb6b1f1cd..26a3ad2668d7 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -35,6 +35,7 @@
#include "intel_drv.h"
#include "intel_frontbuffer.h"
#include "intel_mocs.h"
+#include "i915_gemfs.h"
#include
#include
#include
@@ -4251,6 +4252,24 @@ static const struct drm_i915_gem_object_ops
i915_gem_object_ops = {
.pwrite = i915_gem_object_pwrite_gtt,
};
+static int i915_gem_object_create_shmem(struct drm_device *dev,
+ struct drm_gem_object *obj,
+ size_t size)
+{
+ struct drm_i915_private *i915 = to_i915(dev);
+ struct file *filp;
+
+ drm_gem_private_object_init(dev, obj, size);
+
+ filp = shmem_file_setup(i915->mm.gemfs, "i915", size, VM_NORESERVE);
+ if (IS_ERR(filp))
+ return PTR_ERR(filp);
+
+ obj->filp = filp;
+
+ return 0;
+}
+
struct drm_i915_gem_object *
i915_gem_object_create(struct drm_i915_private *dev_priv, u64 size)
{
@@ -4275,7 +4294,7 @@ i915_gem_object_create(struct drm_i915_private *dev_priv,
u64 size)
if (obj == NULL)
return ERR_PTR(-ENOMEM);
- ret = drm_gem_object_init(&dev_priv->drm, &obj->base, size);
+ ret = i915_gem_object_create_shmem(&dev_priv->drm, &obj->base, size);
if (ret)
goto fail;
@@ -4914,6 +4933,9 @@ i915_gem_load_init(struct drm_i915_private *dev_priv)
spin_lock_init(&dev_priv->fb_tracking.lock);
+ if (i915_gemfs_init(dev_priv))
+ DRM_NOTE("Unable to create a private tmpfs mountpoint, hugepage
support will be disabled.\n");
+
return 0;
err_priorities:
@@ -4952,6 +4974,8 @@ void i915_gem_load_cleanup(struct drm_i915_private
*dev_priv)
/* And ensure that our DESTROY_BY_RCU slabs are truly destroyed */
rcu_barrier();
+
+ i915_gemfs_fini(dev_priv);
}
int i915_gem_freeze(struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/i915_gemfs.c
b/drivers/gpu/drm/i915/i915_gemfs.c
new file mode 100644
index ..168d0bd98f60
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_gemfs.c
@@ -0,0 +1,52 @@
+/*
+ * Copyright © 2017 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+
[PATCH v1 0/2] NVIDIA Tegra20 video decoder driver
This driver provides accelerated video decoding to NVIDIA Tegra20 SoC's, it is a result of reverse-engineering efforts. Driver has been tested on Toshiba AC100 and Acer A500, it should work on any Tegra20 device. In userspace this driver is utilized by libvdpau-tegra [0] that implements VDPAU interface, so any video player that supports VDPAU can provide accelerated video decoding on Tegra20 on Linux. [0] https://github.com/grate-driver/libvdpau-tegra Dmitry Osipenko (2): staging: Introduce NVIDIA Tegra20 video decoder driver ARM: dts: tegra20: Add video decoder node .../bindings/arm/tegra/nvidia,tegra20-vde.txt | 38 + arch/arm/boot/dts/tegra20.dtsi | 16 + drivers/staging/Kconfig| 2 + drivers/staging/Makefile | 1 + drivers/staging/tegra-vde/Kconfig | 6 + drivers/staging/tegra-vde/Makefile | 1 + drivers/staging/tegra-vde/TODO | 8 + drivers/staging/tegra-vde/uapi.h | 99 +++ drivers/staging/tegra-vde/vde.c| 971 + 9 files changed, 1142 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-vde.txt create mode 100644 drivers/staging/tegra-vde/Kconfig create mode 100644 drivers/staging/tegra-vde/Makefile create mode 100644 drivers/staging/tegra-vde/TODO create mode 100644 drivers/staging/tegra-vde/uapi.h create mode 100644 drivers/staging/tegra-vde/vde.c -- 2.14.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v1 1/2] staging: Introduce NVIDIA Tegra20 video decoder driver
Video decoder, found on NVIDIA Tegra20 SoC, supports a standard set of
video formats like H.264 / MPEG-4 / WMV / VC1. Currently driver supports
decoding of CAVLC H.264 only.
Signed-off-by: Dmitry Osipenko
---
.../bindings/arm/tegra/nvidia,tegra20-vde.txt | 38 +
drivers/staging/Kconfig| 2 +
drivers/staging/Makefile | 1 +
drivers/staging/tegra-vde/Kconfig | 6 +
drivers/staging/tegra-vde/Makefile | 1 +
drivers/staging/tegra-vde/TODO | 8 +
drivers/staging/tegra-vde/uapi.h | 99 +++
drivers/staging/tegra-vde/vde.c| 971 +
8 files changed, 1126 insertions(+)
create mode 100644
Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-vde.txt
create mode 100644 drivers/staging/tegra-vde/Kconfig
create mode 100644 drivers/staging/tegra-vde/Makefile
create mode 100644 drivers/staging/tegra-vde/TODO
create mode 100644 drivers/staging/tegra-vde/uapi.h
create mode 100644 drivers/staging/tegra-vde/vde.c
diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-vde.txt
b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-vde.txt
new file mode 100644
index ..e5ca6f5e96c0
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-vde.txt
@@ -0,0 +1,38 @@
+NVIDIA Tegra Video Decoder Engine
+
+Required properties:
+- compatible : "nvidia,tegra20-vde"
+- reg : Must contain 2 register ranges: registers and IRAM area.
+- reg-names : Must include the following entries:
+ - regs
+ - iram
+- interrupts : Must contain an entry for each entry in interrupt-names.
+- interrupt-names : Must include the following entries:
+ - ucq-error
+ - sync-token
+ - bsev
+ - bsea
+ - sxe
+- clocks : Must contain one entry, for the module clock.
+ See ../clocks/clock-bindings.txt for details.
+- resets : Must contain an entry for each entry in reset-names.
+ See ../reset/reset.txt for details.
+- reset-names : Must include the following entries:
+ - vde
+
+Example:
+ vde@6001a000 {
+ compatible = "nvidia,tegra20-vde";
+ reg = <0x6001a000 0x3D00/* VDE registers */
+ 0x4400 0x3FC00>; /* IRAM area */
+ reg-names = "regs", "iram";
+ interrupts = , /* UCQ error
interrupt */
+, /* Sync token
interrupt */
+, /* BSE-V
interrupt */
+, /* BSE-A
interrupt */
+; /* SXE interrupt
*/
+ interrupt-names = "ucq-error", "sync-token", "bsev", "bsea",
"sxe";
+ clocks = <&tegra_car TEGRA20_CLK_VDE>;
+ resets = <&tegra_car 61>;
+ reset-names = "vde";
+ };
diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
index 554683912cff..10c982811093 100644
--- a/drivers/staging/Kconfig
+++ b/drivers/staging/Kconfig
@@ -118,4 +118,6 @@ source "drivers/staging/vboxvideo/Kconfig"
source "drivers/staging/pi433/Kconfig"
+source "drivers/staging/tegra-vde/Kconfig"
+
endif # STAGING
diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile
index 8951c37d8d80..d07c167d5773 100644
--- a/drivers/staging/Makefile
+++ b/drivers/staging/Makefile
@@ -49,3 +49,4 @@ obj-$(CONFIG_BCM2835_VCHIQ) += vc04_services/
obj-$(CONFIG_CRYPTO_DEV_CCREE) += ccree/
obj-$(CONFIG_DRM_VBOXVIDEO)+= vboxvideo/
obj-$(CONFIG_PI433)+= pi433/
+obj-$(CONFIG_ARCH_TEGRA) += tegra-vde/
diff --git a/drivers/staging/tegra-vde/Kconfig
b/drivers/staging/tegra-vde/Kconfig
new file mode 100644
index ..b947c012a373
--- /dev/null
+++ b/drivers/staging/tegra-vde/Kconfig
@@ -0,0 +1,6 @@
+config TEGRA_VDE
+ tristate "NVIDIA Tegra20 video decoder driver"
+ depends on ARCH_TEGRA_2x_SOC
+ help
+ Say Y here to enable support for a NVIDIA Tegra20 video decoder
+ driver.
diff --git a/drivers/staging/tegra-vde/Makefile
b/drivers/staging/tegra-vde/Makefile
new file mode 100644
index ..e7c0df1174bf
--- /dev/null
+++ b/drivers/staging/tegra-vde/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_TEGRA_VDE)+= vde.o
diff --git a/drivers/staging/tegra-vde/TODO b/drivers/staging/tegra-vde/TODO
new file mode 100644
index ..533ddfc5190e
--- /dev/null
+++ b/drivers/staging/tegra-vde/TODO
@@ -0,0 +1,8 @@
+All TODO's require reverse-engineering to be done first, it is very
+unlikely that NVIDIA would ever release HW specs to public.
+
+TODO:
+ - properly handle decoding faults
+ - support more formats
+
+Contact: Dmitry Osipenko
diff --git a/drivers/staging/tegra-vde/uapi.h b/drivers/staging/tegra-vde/uapi.h
new file mode 100644
index ..4e60449f688e
--- /dev/null
+++ b/drivers/staging/tegra-vde/uapi.h
@@ -0,0 +1,99 @@
+/*
+ * Copyright (C) 2016-2017 Dmitry Osipenko
+ * All Rights Res
[PATCH v1 2/2] ARM: dts: tegra20: Add video decoder node
Add a device node for the video decoder engine found on Tegra20.
Signed-off-by: Dmitry Osipenko
---
arch/arm/boot/dts/tegra20.dtsi | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm/boot/dts/tegra20.dtsi b/arch/arm/boot/dts/tegra20.dtsi
index 7c85f97f72ea..fb485a5e63d7 100644
--- a/arch/arm/boot/dts/tegra20.dtsi
+++ b/arch/arm/boot/dts/tegra20.dtsi
@@ -249,6 +249,22 @@
*/
};
+ vde@6001a000 {
+ compatible = "nvidia,tegra20-vde";
+ reg = <0x6001a000 0x3D00/* VDE registers */
+ 0x4400 0x3FC00>; /* IRAM area */
+ reg-names = "regs", "iram";
+ interrupts = , /* UCQ error
interrupt */
+, /* Sync token
interrupt */
+, /* BSE-V
interrupt */
+, /* BSE-A
interrupt */
+; /* SXE interrupt
*/
+ interrupt-names = "ucq-error", "sync-token", "bsev", "bsea",
"sxe";
+ clocks = <&tegra_car TEGRA20_CLK_VDE>;
+ resets = <&tegra_car 61>;
+ reset-names = "vde";
+ };
+
apbmisc@7800 {
compatible = "nvidia,tegra20-apbmisc";
reg = <0x7800 0x64 /* Chip revision */
--
2.14.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v1 1/2] staging: Introduce NVIDIA Tegra20 video decoder driver
On 09/25/2017 04:15 PM, Dmitry Osipenko wrote: Video decoder, found on NVIDIA Tegra20 SoC, supports a standard set of video formats like H.264 / MPEG-4 / WMV / VC1. Currently driver supports decoding of CAVLC H.264 only. Note: I don't know anything much about video decoding on Tegra (just NV desktop GPUs, and that was a while ago), but I had a couple small comments on the DT binding: diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-vde.txt b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-vde.txt +NVIDIA Tegra Video Decoder Engine + +Required properties: +- compatible : "nvidia,tegra20-vde" +- reg : Must contain 2 register ranges: registers and IRAM area. +- reg-names : Must include the following entries: + - regs + - iram I think the IRAM region needs more explanation: What is the region used for and by what? Can it be moved, and if so does the move need to be co-ordinated with any other piece of SW? +- clocks : Must contain one entry, for the module clock. + See ../clocks/clock-bindings.txt for details. +- resets : Must contain an entry for each entry in reset-names. + See ../reset/reset.txt for details. +- reset-names : Must include the following entries: + - vde Let's require a clock-names property too. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] hv_netvsc: make const array ver_list static, reduces object code size
From: Colin King Date: Fri, 22 Sep 2017 16:50:23 +0100 > From: Colin Ian King > > Don't populate const array ver_list on the stack, instead make it > static. Makes the object code smaller by over 400 bytes: > > Before: >text data bss dec hex filename > 18444 3168 320 2193255ac drivers/net/hyperv/netvsc.o > > After: >text data bss dec hex filename > 17950 3224 320 2149453f6 drivers/net/hyperv/netvsc.o > > (gcc 6.3.0, x86-64) > > Signed-off-by: Colin Ian King Applied to net-next, thanks. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v1 1/2] staging: Introduce NVIDIA Tegra20 video decoder driver
On 26.09.2017 02:01, Stephen Warren wrote: > On 09/25/2017 04:15 PM, Dmitry Osipenko wrote: >> Video decoder, found on NVIDIA Tegra20 SoC, supports a standard set of >> video formats like H.264 / MPEG-4 / WMV / VC1. Currently driver supports >> decoding of CAVLC H.264 only. > > Note: I don't know anything much about video decoding on Tegra (just NV > desktop > GPUs, and that was a while ago), but I had a couple small comments on the DT > binding: > >> diff --git >> a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-vde.txt >> b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-vde.txt > >> +NVIDIA Tegra Video Decoder Engine >> + >> +Required properties: >> +- compatible : "nvidia,tegra20-vde" >> +- reg : Must contain 2 register ranges: registers and IRAM area. >> +- reg-names : Must include the following entries: >> + - regs >> + - iram > > I think the IRAM region needs more explanation: What is the region used for > and > by what? Can it be moved, and if so does the move need to be co-ordinated with > any other piece of SW? > IRAM region is used by Video Decoder HW for internal use and some of decoding parameters are supplied via IRAM, like frames order list. AFAIK IRAM addresses are hardwired in HW and aren't movable, it is not 100% but I'm pretty sure. Should it be explained in the binding? >> +- clocks : Must contain one entry, for the module clock. >> + See ../clocks/clock-bindings.txt for details. >> +- resets : Must contain an entry for each entry in reset-names. >> + See ../reset/reset.txt for details. >> +- reset-names : Must include the following entries: >> + - vde > > Let's require a clock-names property too. Okay, I'll add this property to the binding. -- Dmitry ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 2/2] staging: ion: create one device entry per heap
On Mon, Sep 25, 2017 at 11:26:27AM -0700, Laura Abbott wrote:
> On 09/20/2017 01:45 AM, Benjamin Gaignard wrote:
> > Instead a getting one common device "/dev/ion" for
> > all the heaps this patch allow to create one device
> > entry ("/dev/ionX") per heap.
> > Getting an entry per heap could allow to set security rules
> > per heap and global ones for all heaps.
> >
> > Allocation requests will be only allowed if the mask_id
> > match with device minor.
> > Query request could be done on any of the devices.
> > Deivce node major will also change and that may impact init scripts.
> >
>
> We should start Cc linux-api for future changes since we're going
> to have more than just /dev/ion.
>
> Thinking about this some more, I think we need to allow backwards
> compatibility. It's just not feasible to keep throwing workarounds
> into userspace if we can avoid it. I'd propose keeping the old /dev/ion
> misc interface available under a Kconfig and then creating the new
> split heaps in parallel.
>
> On a somewhat related note, there was some interest in possibly
> having a sysfs interface for Ion long term. I don't think this
> needs to happen right now but I'd like whatever we do to not
> make adding that harder.
Not sure sysfs is a good idea for allocating buffers. The backlight
interface is in sysfs, which defacto makes it a root-only interface.
Distros really hate that, because it makes unpriviledged X/wayland really
hard to pull of. Passing a device file otoh from logind to the compositor
is dead simple (and how X et al get at e.g. the drm/input devices
already).
Adding some links from devices to corresponding ion heaps somewhere in
sysfs makes sense, and those could be read by anyone.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v1 1/2] staging: Introduce NVIDIA Tegra20 video decoder driver
On 09/25/2017 05:45 PM, Dmitry Osipenko wrote: > On 26.09.2017 02:01, Stephen Warren wrote: >> On 09/25/2017 04:15 PM, Dmitry Osipenko wrote: >>> Video decoder, found on NVIDIA Tegra20 SoC, supports a standard set of >>> video formats like H.264 / MPEG-4 / WMV / VC1. Currently driver supports >>> decoding of CAVLC H.264 only. >> >> Note: I don't know anything much about video decoding on Tegra (just NV >> desktop >> GPUs, and that was a while ago), but I had a couple small comments on the DT >> binding: >> >>> diff --git >>> a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-vde.txt >>> b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-vde.txt >> >>> +NVIDIA Tegra Video Decoder Engine >>> + >>> +Required properties: >>> +- compatible : "nvidia,tegra20-vde" >>> +- reg : Must contain 2 register ranges: registers and IRAM area. >>> +- reg-names : Must include the following entries: >>> + - regs >>> + - iram >> >> I think the IRAM region needs more explanation: What is the region used for >> and >> by what? Can it be moved, and if so does the move need to be co-ordinated >> with >> any other piece of SW? > > IRAM region is used by Video Decoder HW for internal use and some of decoding > parameters are supplied via IRAM, like frames order list. AFAIK IRAM addresses > are hardwired in HW and aren't movable, it is not 100% but I'm pretty sure. > Should it be explained in the binding? I think this should be briefly mentioned, yes. Otherwise at least people who don't know the VDE HW well (like me) will wonder why on earth VDE interacts with IRAM at all. I would have assumed all parameters were supplied via registers or via descriptors in DRAM. Thanks. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v1 0/2] NVIDIA Tegra20 video decoder driver
On Tue, Sep 26, 2017 at 01:15:41AM +0300, Dmitry Osipenko wrote: > This driver provides accelerated video decoding to NVIDIA Tegra20 SoC's, > it is a result of reverse-engineering efforts. Driver has been tested on > Toshiba AC100 and Acer A500, it should work on any Tegra20 device. > > In userspace this driver is utilized by libvdpau-tegra [0] that implements > VDPAU interface, so any video player that supports VDPAU can provide > accelerated video decoding on Tegra20 on Linux. Why not use the v4l2 api instead? Doesn't that provide the same needed user/kernel api here instead of creating yet-another-custom ioctl? thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 2/2] staging: ion: create one device entry per heap
On Tue, Sep 26, 2017 at 07:09:14AM +0200, Daniel Vetter wrote:
> On Mon, Sep 25, 2017 at 11:26:27AM -0700, Laura Abbott wrote:
> > On 09/20/2017 01:45 AM, Benjamin Gaignard wrote:
> > > Instead a getting one common device "/dev/ion" for
> > > all the heaps this patch allow to create one device
> > > entry ("/dev/ionX") per heap.
> > > Getting an entry per heap could allow to set security rules
> > > per heap and global ones for all heaps.
> > >
> > > Allocation requests will be only allowed if the mask_id
> > > match with device minor.
> > > Query request could be done on any of the devices.
> > > Deivce node major will also change and that may impact init scripts.
> > >
> >
> > We should start Cc linux-api for future changes since we're going
> > to have more than just /dev/ion.
> >
> > Thinking about this some more, I think we need to allow backwards
> > compatibility. It's just not feasible to keep throwing workarounds
> > into userspace if we can avoid it. I'd propose keeping the old /dev/ion
> > misc interface available under a Kconfig and then creating the new
> > split heaps in parallel.
> >
> > On a somewhat related note, there was some interest in possibly
> > having a sysfs interface for Ion long term. I don't think this
> > needs to happen right now but I'd like whatever we do to not
> > make adding that harder.
>
> Not sure sysfs is a good idea for allocating buffers. The backlight
> interface is in sysfs, which defacto makes it a root-only interface.
> Distros really hate that, because it makes unpriviledged X/wayland really
> hard to pull of. Passing a device file otoh from logind to the compositor
> is dead simple (and how X et al get at e.g. the drm/input devices
> already).
sysfs is not a good idea for allocating buffers. We already have some
out-of-tree drm drivers doing horrid things in sysfs in ways that
totally abuse that api, and vendors have to do crazy things with selinux
rules to try to lock it down because of that. A device node is fine, we
are used to that for graphics stuff :)
thanks,
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
