On 05/12/2020 15:21, Rafael J. Wysocki wrote:
> On Friday, December 4, 2020 1:27:40 AM CET Daniel Scally wrote:
>> Switching this function to AE_CTRL_TERMINATE broke the documented
>> behaviour of acpi_dev_get_resources() - AE_CTRL_TERMINATE does not, in
>> fact, terminate the resource walk
On 02/12/2020 15:08, Andy Shevchenko wrote:
> On Wed, Dec 02, 2020 at 02:42:28PM +0200, Laurent Pinchart wrote:
>> On Wed, Dec 02, 2020 at 01:09:56PM +0200, Sakari Ailus wrote:
>>> On Tue, Dec 01, 2020 at 08:37:58PM +0200, Laurent Pinchart wrote:
>
> ...
>
>> I think we should consider ACPI to
On 02/12/2020 09:39, Andy Shevchenko wrote:
> On Tue, Dec 01, 2020 at 08:59:53PM +0000, Dan Scally wrote:
>> On 01/12/2020 18:49, Andy Shevchenko wrote:
>
> ...
>
>>> Seems we can do this, by locating intel_int3472.c under PDx86 hood and
>>> dropping
>&g
On 02/12/2020 12:02, Andy Shevchenko wrote:
> On Wed, Dec 02, 2020 at 10:53:05AM +0000, Dan Scally wrote:
>> On 02/12/2020 10:38, Sakari Ailus wrote:
>
> ...
>
>>>>> Argh, thanks, this is the curse of using VS code on multiple machines...
>>>>
On 30/11/2020 17:11, Laurent Pinchart wrote:
> Hi Daniel,
>
> Thank you for the patch.
>
> On Mon, Nov 30, 2020 at 01:31:26PM +, Daniel Scally wrote:
>> Some places in the kernel allow users to map resources to a device
>> using device name (for example, gpiod_lookup_table). Currently
>>
On 02/12/2020 10:38, Sakari Ailus wrote:
> Hi Laurent,
>
> On Wed, Dec 02, 2020 at 12:30:53AM +0200, Laurent Pinchart wrote:
>> Hi Daniel,
>>
>> On Tue, Dec 01, 2020 at 10:08:25PM +, Dan Scally wrote:
>>> On 30/11/2020 17:09, Laurent Pinchart wrote:
>
On 30/11/2020 17:29, Andy Shevchenko wrote:
> On Mon, Nov 30, 2020 at 01:31:13PM +, Daniel Scally wrote:
>> This function is used to find fwnode endpoints against a device. In
>> some instances those endpoints are software nodes which are children of
>> fwnode->secondary. Add support to
On 30/11/2020 17:47, Andy Shevchenko wrote:
> On Mon, Nov 30, 2020 at 06:17:16PM +0200, Laurent Pinchart wrote:
>> Hi Daniel,
>>
>> Thank you for the patch.
>>
>> The subject line is very long. We try to keep it within a 72 characters
>> limit in the kernel. That can be a challenge sometimes, and
en called
it a night
> On Mon, Nov 30, 2020 at 09:18:56PM +0200, Andy Shevchenko wrote:
>> On Mon, Nov 30, 2020 at 07:12:41PM +0200, Laurent Pinchart wrote:
>>> On Mon, Nov 30, 2020 at 01:31:27PM +, Daniel Scally wrote:
>>>> From: Dan Scally
>>>>
>>&g
On 30/11/2020 17:12, Laurent Pinchart wrote:
> Hi Daniel,
>
> Thank you for the patch.
>
> On Mon, Nov 30, 2020 at 01:31:27PM +, Daniel Scally wrote:
>> From: Dan Scally
>>
>> To make sure the new i2c_acpi_dev_name() always reflects the name of i2c
Hi Andy
On 30/11/2020 17:45, Andy Shevchenko wrote:
> On Mon, Nov 30, 2020 at 01:31:16PM +, Daniel Scally wrote:
>> Software nodes that are children of another software node should be
>> unregistered before their parent. To allow easy unregistering of an array
>> of software_nodes ordered
happen, as long as nothing else is touching the swnodes
>> I've registered or anything. I've never seen it happen. That didn't feel
>> like quite enough to say it can't ever happen - but I'm happy to skip
>> the check if you think thats ok.
> It seems a bit overki
On 01/12/2020 22:08, Dan Scally wrote:
>>> +
>>> + for_each_acpi_dev_match(adev, this_device, NULL, -1) {
>>> + if (!adev || !(adev->status.present &&
>>> adev->status.enabled))
>> if (!ad
>> create mode 100644 drivers/media/pci/intel/ipu3/cio2-bridge.c
>> create mode 100644 drivers/media/pci/intel/ipu3/cio2-bridge.h
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 9702b886d6a4..188559a0a610 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
&g
On 01/12/2020 19:21, Andy Shevchenko wrote:
> On Tue, Dec 01, 2020 at 09:06:38PM +0200, Laurent Pinchart wrote:
>> On Tue, Dec 01, 2020 at 09:05:23PM +0200, Andy Shevchenko wrote:
>>> On Tue, Dec 01, 2020 at 08:55:48PM +0200, Laurent Pinchart wrote:
>>>
Do you think the Windows driver would
Hi Andy
On 01/12/2020 18:49, Andy Shevchenko wrote:
> P.S. Dan, can you drop unrelated text when replying?
Ah - sure, sorry.
> Seems we can do this, by locating intel_int3472.c under PDx86 hood and
> dropping
> ACPI ID table from TPS68470 MFD driver. The PMIC can be instantiated via
>
On 01/12/2020 15:10, Andy Shevchenko wrote:
> On Mon, Nov 30, 2020 at 11:54:44PM +0000, Dan Scally wrote:
>> Hi Andy
>>
>> On 30/11/2020 18:23, Andy Shevchenko wrote:
>>> On Mon, Nov 30, 2020 at 01:31:25PM +, Daniel Scally wrote:
>>>> ACPI dev
On 01/12/2020 12:32, Sakari Ailus wrote:
> Hi Dan,
>
> On Tue, Dec 01, 2020 at 08:08:26AM +0000, Dan Scally wrote:
>> On 01/12/2020 06:44, Sakari Ailus wrote:
>>> Hi Dan,
>>>
>>> On Mon, Nov 30, 2020 at 11:06:03PM +, Dan Scally wrote:
>>&g
Hi Bingbu
On 01/12/2020 03:12, Bingbu Cao wrote:
> Daniel, thanks for your patch.
>
> On 11/30/20 9:31 PM, Daniel Scally wrote:
>> Some types of fwnode_handle do not implement the device_is_available()
>> check, such as those created by software_nodes. There isn't really a
>> meaningful way to
Hi Andy, thanks for comments
On 30/11/2020 20:07, Andy Shevchenko wrote:
>> We know that at least some of those pins have to be toggled active for the
>> sensor devices to be available in i2c, so the conclusion we came to was
>> that those GPIO entries assigned to the INT3472 device actually
| 6 +
>> 7 files changed, 421 insertions(+)
>> create mode 100644 drivers/media/pci/intel/ipu3/cio2-bridge.c
>> create mode 100644 drivers/media/pci/intel/ipu3/cio2-bridge.h
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 9702b886d6a4..188559a0a610 1
On 01/12/2020 06:44, Sakari Ailus wrote:
> Hi Dan,
>
> On Mon, Nov 30, 2020 at 11:06:03PM +0000, Dan Scally wrote:
>> Hi Sakari
>>
>> On 30/11/2020 20:52, Sakari Ailus wrote:
>>>> +static const struct acpi_device_id int3472_device_id[] = {
>>>>
On 01/12/2020 08:08, Dan Scally wrote:
> On 01/12/2020 06:44, Sakari Ailus wrote:
>> Hi Dan,
>>
>> On Mon, Nov 30, 2020 at 11:06:03PM +, Dan Scally wrote:
>>> Hi Sakari
>>>
>>> On 30/11/2020 20:52, Sakari Ailus wrote:
>>>
On 30/11/2020 23:21, Laurent Pinchart wrote:
>>> Instead, I propose, that you add this as an option to the tps68470 driver
>>> that figures out whether the ACPI device for the tps68470 device actually
>>> describes something else, in a similar fashion you do with the cio2-bridge
>>> driver. I
Hi Andy
On 30/11/2020 18:23, Andy Shevchenko wrote:
> On Mon, Nov 30, 2020 at 01:31:25PM +, Daniel Scally wrote:
>> ACPI devices declare themselves dependent on other devices via the _DEP
>> buffer. Fetching the dependee from dependent is a matter of parsing
>> _DEP, but currently there's no
Hi Laurent
On 30/11/2020 16:25, Laurent Pinchart wrote:
> Hi Daniel and Heikki,
>
> Thank you for the patch.
>
> On Mon, Nov 30, 2020 at 01:31:18PM +, Daniel Scally wrote:
>> From: Heikki Krogerus
>>
>> From: Heikki Krogerus
>>
> There seems to be one From: line too many. You can drop the
/pci/intel/ipu3/Makefile
>> @@ -1,5 +1,6 @@
>> # SPDX-License-Identifier: GPL-2.0-only
>> obj-$(CONFIG_VIDEO_IPU3_CIO2) += ipu3-cio2.o
>> +obj-$(CONFIG_INT3472) += int3472.o
>>
>> ipu3-cio2-y += ipu3-cio2-main.o
>> ipu3-cio2-$(CONFIG_CIO2_BRIDGE) += cio2-b
Hi Laurent
On 30/11/2020 16:12, Laurent Pinchart wrote:
> On Mon, Nov 30, 2020 at 06:11:52PM +0200, Laurent Pinchart wrote:
>> Hi Daniel,
>>
>> Thank you for the patch.
>>
>> On Mon, Nov 30, 2020 at 01:31:15PM +, Daniel Scally wrote:
>>> Registering software_nodes with the .parent member set
.remove = int3472_remove,
>> +},
>> + .owner = THIS_MODULE,
>> +};
>> +
>> +module_acpi_driver(int3472_driver);
>> +
>> +MODULE_LICENSE("GPL v2");
>> +MODULE_AUTHOR("Dan Scally ");
>> +MODULE_DESCRIPTION(&quo
On 17/11/2020 16:42, Andy Shevchenko wrote:
> On Tue, Nov 17, 2020 at 2:02 PM Dan Scally wrote:
>> On 16/11/2020 16:16, Andy Shevchenko wrote:
>>> On Mon, Nov 16, 2020 at 02:15:01PM +, Dan Scally wrote:
>>>> On 16/11/2020 14:10, Laurent Pinchart wrote:
>>&g
On 16/11/2020 16:16, Andy Shevchenko wrote:
> On Mon, Nov 16, 2020 at 02:15:01PM +0000, Dan Scally wrote:
>> On 16/11/2020 14:10, Laurent Pinchart wrote:
>>> I thought we were looking for ACPI devices, not companion devices, in
>>> order to extract informat
> On Fri, Nov 13, 2020 at 6:22 PM Laurent Pinchart wrote:
>>>>> On Fri, Nov 13, 2020 at 10:02:30AM +, Dan Scally wrote:
>>>>>> On 29/10/2020 22:51, Laurent Pinchart wrote:
>>>>>>> On Fri, Oct 30, 2020 at 12:22:15AM +0200, Andy S
t;> On Thu, Oct 29, 2020 at 10:21 PM Laurent Pinchart wrote:
>>>>> On Mon, Oct 26, 2020 at 06:10:50PM +0200, Andy Shevchenko wrote:
>>>>>> On Sat, Oct 24, 2020 at 12:37:02PM +0300, Laurent Pinchart wrote:
>>>>>>> On Sat, Oct 24, 2020 a
Hi both
On 29/10/2020 20:17, Laurent Pinchart wrote:
> Hi Andy,
>
> On Mon, Oct 26, 2020 at 06:05:49PM +0200, Andy Shevchenko wrote:
>> On Mon, Oct 26, 2020 at 08:20:14AM +0000, Dan Scally wrote:
>>> On 24/10/2020 23:36, Laurent Pinchart wrote:
>>>> On S
On 24/10/2020 23:36, Laurent Pinchart wrote:
> Hi Dan,
>
> On Sat, Oct 24, 2020 at 11:28:06PM +0100, Daniel Scally wrote:
>> On 24/10/2020 10:37, Laurent Pinchart wrote:
> I wonder if we could avoid depending on the I2C device being created by
> getting the fwnode from adev, and setting
On 24/10/2020 16:14, Sakari Ailus wrote:
> Hi Daniel,
>
> Thanks for the update.
Thanks for the comments as always
>> +// SPDX-License-Identifier: GPL-2.0
>> +// Author: Dan Scally
> /* Author: ... */
>
> But not the SPDX tag.
Weird - okedokey
>> +
On 24/10/2020 15:29, Sakari Ailus wrote:
> On Sat, Oct 24, 2020 at 03:39:55AM +0300, Laurent Pinchart wrote:
>> Hi Sakari
>>
>> On Wed, Oct 21, 2020 at 01:49:10AM +0300, Sakari Ailus wrote:
>>> On Tue, Oct 20, 2020 at 08:56:07PM +0100, Dan Scally wrote:
>>>&g
create mode 100644 drivers/media/pci/intel/ipu3/cio2-bridge.h
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 5d768d5ad..4c9c646c7 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -8848,6 +8848,7 @@ INTEL IPU3 CSI-2 CIO2 DRIVER
>> M: Yong Zhi
>
On 22/10/2020 14:40, Andy Shevchenko wrote:
> On Thu, Oct 22, 2020 at 3:59 PM Daniel Scally wrote:
>> On 20/10/2020 10:41, Andy Shevchenko wrote:
> ...
>
+static const char * const port_names[] = {
+"port0", "port1", "port2", "port3"
>>> + comma.
>> I think 4 ports is the maximum
On 21/10/2020 10:33, Andy Shevchenko wrote:
> On Wed, Oct 21, 2020 at 12:25:28AM +0100, Dan Scally wrote:
>> On 20/10/2020 14:31, Sakari Ailus wrote:
>>> On Mon, Oct 19, 2020 at 11:58:57PM +0100, Daniel Scally wrote:
>>>> + return software_node_get(>
On 21/10/2020 10:40, Andy Shevchenko wrote:
> On Tue, Oct 20, 2020 at 11:52:56PM +0100, Dan Scally wrote:
>> On 20/10/2020 11:05, Sakari Ailus wrote:
>>> On Mon, Oct 19, 2020 at 11:58:55PM +0100, Daniel Scally wrote:
>>>> Software nodes that are children o
Hi Sakari
On 20/10/2020 14:31, Sakari Ailus wrote:
> Hi Daniel,
>
> On Mon, Oct 19, 2020 at 11:58:57PM +0100, Daniel Scally wrote:
>> The software_node_get_next_child() function currently does not hold a kref
>> to the child software_node; fix that.
>>
>> Fixes: 59abd83672f7 ("drivers: base:
Hi Sakari
On 20/10/2020 23:49, Sakari Ailus wrote:
> Hi Dan,
>
> On Tue, Oct 20, 2020 at 08:56:07PM +0100, Dan Scally wrote:
>> Hi Sakari
>>
>> On 20/10/2020 13:06, Sakari Ailus wrote:
>>> Hi Andy,
>>>
>>> On Tue, Oct 20, 2020 at 12:19:58PM +
Hi Sakari
On 20/10/2020 11:05, Sakari Ailus wrote:
> Hi Daniel, Andy,
>
> On Mon, Oct 19, 2020 at 11:58:55PM +0100, Daniel Scally wrote:
>> Software nodes that are children of another software node should be
>> unregistered before their parent. To allow easy unregistering of an array
>> of
On 20/10/2020 10:15, Andy Shevchenko wrote:
> On Mon, Oct 19, 2020 at 11:59:00PM +0100, Daniel Scally wrote:
>> ipu3-cio2 driver needs extending with multiple files; rename the main
>> source file and specify the renamed file in Makefile to accommodate that.
> Suggested-by?
Oops - yes of course,
Hi Sakari
On 20/10/2020 13:06, Sakari Ailus wrote:
> Hi Andy,
>
> On Tue, Oct 20, 2020 at 12:19:58PM +0300, Andy Shevchenko wrote:
>> On Mon, Oct 19, 2020 at 11:59:01PM +0100, Daniel Scally wrote:
>>> fwnode_graph_get_endpoint_by_id() will optionally parse enabled devices
>>> only; that status
ore) in a series I would expect.
Yeah no problem, I'll do that too.
>
>>>> +// SPDX-License-Identifier: GPL-2.0
>>> Author line perhaps?
>> You mean literally just like /* Authored By: Dan Scally */ or something?
>> OK, no problem.
> * Author: Dan
ine perhaps?
You mean literally just like /* Authored By: Dan Scally */ or something?
OK, no problem.
>> +static const struct ipu3_sensor supported_devices[] = {
>> +IPU3_SENSOR("INT33BE", "INT33BE:00"),
>> +IPU3_SENSOR("OVTI2680", "OVTI2680:00&q
On 17/09/2020 11:33, Sakari Ailus wrote:
>> +sensor_props[3] = PROPERTY_ENTRY_U32_ARRAY_LEN("data-lanes",
>> + data_lanes,
>> +
>> (int)ssdb->lanes);
>> +
Hi Sakari
On 17/09/2020 11:33, Sakari Ailus wrote:
>> +ret = software_node_register_nodes(nodes);
>> +if (ret) {
>> +dev_err(dev,
>> +"Failed to register software nodes for %s\n",
>> +
On 18/09/2020 14:07, Andy Shevchenko wrote:
> On Fri, Sep 18, 2020 at 10:51:57AM +0300, Sakari Ailus wrote:
>> On Thu, Sep 17, 2020 at 03:45:14PM +0300, Andy Shevchenko wrote:
>>> On Thu, Sep 17, 2020 at 11:52:28AM +0100, Dan Scally wrote:
>>>> On 17/09/
Hi Dan - thanks for all your comments. Sorry it took a while to get to
yours.
On 17/09/2020 10:34, Dan Carpenter wrote:
> On Wed, Sep 16, 2020 at 10:36:18PM +0100, Daniel Scally wrote:
>> diff --git a/drivers/media/pci/intel/ipu3/ipu3-cio2.c
>> b/drivers/media/pci/intel/ipu3/ipu3-cio2.c
>>
On 18/09/2020 10:15, Sakari Ailus wrote:
> On Fri, Sep 18, 2020 at 11:57:09AM +0300, Heikki Krogerus wrote:
>> On Fri, Sep 18, 2020 at 10:57:41AM +0300, Sakari Ailus wrote:
>>> On Fri, Sep 18, 2020 at 08:46:52AM +0100, Dan Scally wrote:
>>>> On 18/09/2020 08:34, Sa
On 18/09/2020 09:57, Heikki Krogerus wrote:
> On Fri, Sep 18, 2020 at 10:57:41AM +0300, Sakari Ailus wrote:
>> On Fri, Sep 18, 2020 at 08:46:52AM +0100, Dan Scally wrote:
>>> On 18/09/2020 08:34, Sakari Ailus wrote:
>>>> On Fri, Sep 18, 2020 at 07:49:31AM +0100
Ah, shoot - good spot, thanks
On 18/09/2020 09:03, Dan Carpenter wrote:
> I ran Smatch over the code and it spotted an off by one.
>
> On Wed, Sep 16, 2020 at 10:36:18PM +0100, Daniel Scally wrote:
>> +#define MAX_CONNECTED_DEVICES 4
>> +#define SWNODE_SENSOR_HID
On 18/09/2020 08:34, Sakari Ailus wrote:
> On Fri, Sep 18, 2020 at 07:49:31AM +0100, Dan Scally wrote:
>> Good morning
>>
>> On 18/09/2020 07:22, Sakari Ailus wrote:
>>> Hi Dan,
>>>
>>> On Wed, Sep 16, 2020 at 02:22:10PM +0100, Dan Scally
Good morning
On 18/09/2020 07:22, Sakari Ailus wrote:
> Hi Dan,
>
> On Wed, Sep 16, 2020 at 02:22:10PM +0100, Dan Scally wrote:
>> Hi Sakari - thanks for the comments
>>
>> On 16/09/2020 10:17, Sakari Ailus wrote:
>>> Moi Daniel and Heikki,
>>>
>>
Hi Andy, thanks for input (as always)
On 17/09/2020 13:45, Andy Shevchenko wrote:
> On Thu, Sep 17, 2020 at 11:52:28AM +0100, Dan Scally wrote:
>> On 17/09/2020 11:33, Sakari Ailus wrote:
> I will do better review for next version, assuming you will Cc reviewers and
> TWIMC people
Hey Sakari - thanks for the reply
On 17/09/2020 11:33, Sakari Ailus wrote:
> Hi Daniel,
>
> Thank you for the patch.
>
> Is this all that it takes to add support for some machines shipped with
> Windows?
Almost
> The ones I know require PMIC control done in software (not even
> sensors are
On 17/09/2020 11:15, Dan Carpenter wrote:
> On Thu, Sep 17, 2020 at 10:47:50AM +0100, Dan Scally wrote:
>> Hi Greg - thanks for the comments, appreciate it (sorry there's so many,
>> I'm new to both C and kernel work)
> It's pretty impressive work if you're new to C...
Thanks (
Hi Greg - thanks for the comments, appreciate it (sorry there's so many,
I'm new to both C and kernel work)
On 17/09/2020 08:53, Greg KH wrote:
> On Wed, Sep 16, 2020 at 10:36:18PM +0100, Daniel Scally wrote:
>> MAINTAINERS | 6 +
>>
Hi Sakari - thanks for the comments
On 16/09/2020 10:17, Sakari Ailus wrote:
> Moi Daniel and Heikki,
>
> On Wed, Sep 16, 2020 at 12:28:27AM +0100, Daniel Scally wrote:
>> From: Heikki Krogerus
>>
>> This implements the remaining .graph_* callbacks in the
>> fwnode operations vector for the
62 matches
Mail list logo
