From: "Nirujogi, Pratap" <pnirujog@amd.com>
To: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
Cc: Pratap Nirujogi <pratap.nirujogi@amd.com>,
Hans de Goede <hdegoede@redhat.com>,
W_Armin@gmx.de, mario.limonciello@amd.com,
platform-driver-x86@vger.kernel.org,
LKML <linux-kernel@vger.kernel.org>,
benjamin.chan@amd.com, bin.du@amd.com,
gjorgji.rosikopulos@amd.com, king.li@amd.com, dantony@amd.com
Subject: Re: [PATCH v13] platform/x86: Add AMD ISP platform config for OV05C10
Date: Mon, 12 May 2025 17:20:25 -0400 [thread overview]
Message-ID: <ec702d90-f6c0-479f-a62c-d09bf13fa13c@amd.com> (raw)
In-Reply-To: <d2bdc8a6-1907-77cd-43a2-fb28439bd37f@linux.intel.com>
On 5/12/2025 5:00 PM, Ilpo Järvinen wrote:
> Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.
>
>
> On Mon, 12 May 2025, Nirujogi, Pratap wrote:
>
>> Hi Ilpo,
>>
>> On 5/11/2025 6:54 PM, Ilpo Järvinen wrote:
>>> Caution: This message originated from an External Source. Use proper caution
>>> when opening attachments, clicking links, or responding.
>>>
>>>
>>> On Fri, 9 May 2025, Pratap Nirujogi wrote:
>>>
>>>> ISP device specific configuration is not available in ACPI. Add
>>>> swnode graph to configure the missing device properties for the
>>>> OV05C10 camera device supported on amdisp platform.
>>>>
>>>> Add support to create i2c-client dynamically when amdisp i2c
>>>> adapter is available.
>>>>
>>>> Co-developed-by: Benjamin Chan <benjamin.chan@amd.com>
>>>> Signed-off-by: Benjamin Chan <benjamin.chan@amd.com>
>>>> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
>>>> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
>>>> Reviewed-by: Armin Wolf <W_Armin@gmx.de>
>>>> Signed-off-by: Pratap Nirujogi <pratap.nirujogi@amd.com>
>>>> ---
>>>> Changes v12 -> v13:
>>>>
>>>> * Add "struct amdisp_platform_info" to pass sensor specific
>>>> configuration and make the driver generic to support OV05C10
>>>> and other supported sensor modules in future.
>>>>
>>>> * Address cosmetic and other review comments.
>>>>
>>>> drivers/platform/x86/amd/Kconfig | 11 +
>>>> drivers/platform/x86/amd/Makefile | 1 +
>>>> drivers/platform/x86/amd/amd_isp4.c | 309 ++++++++++++++++++++++++++++
>>>> 3 files changed, 321 insertions(+)
>>>> create mode 100644 drivers/platform/x86/amd/amd_isp4.c
>>>>
>>>> diff --git a/drivers/platform/x86/amd/Kconfig
>>>> b/drivers/platform/x86/amd/Kconfig
>>>> index c3e086ea64fc..152a68a470e8 100644
>>>> --- a/drivers/platform/x86/amd/Kconfig
>>>> +++ b/drivers/platform/x86/amd/Kconfig
>>>> @@ -32,3 +32,14 @@ config AMD_WBRF
>>>>
>>>> This mechanism will only be activated on platforms that advertise
>>>> a
>>>> need for it.
>>>> +
>>>> +config AMD_ISP_PLATFORM
>>>> + tristate "AMD ISP4 platform driver"
>>>> + depends on I2C && X86_64 && ACPI
>>>> + help
>>>> + Platform driver for AMD platforms containing image signal
>>>> processor
>>>> + gen 4. Provides camera sensor module board information to allow
>>>> + sensor and V4L drivers to work properly.
>>>> +
>>>> + This driver can also be built as a module. If so, the module
>>>> + will be called amd_isp4.
>>>> diff --git a/drivers/platform/x86/amd/Makefile
>>>> b/drivers/platform/x86/amd/Makefile
>>>> index c6c40bdcbded..b0e284b5d497 100644
>>>> --- a/drivers/platform/x86/amd/Makefile
>>>> +++ b/drivers/platform/x86/amd/Makefile
>>>> @@ -10,3 +10,4 @@ obj-$(CONFIG_AMD_PMC) += pmc/
>>>> obj-$(CONFIG_AMD_HSMP) += hsmp/
>>>> obj-$(CONFIG_AMD_PMF) += pmf/
>>>> obj-$(CONFIG_AMD_WBRF) += wbrf.o
>>>> +obj-$(CONFIG_AMD_ISP_PLATFORM) += amd_isp4.o
>>>> diff --git a/drivers/platform/x86/amd/amd_isp4.c
>>>> b/drivers/platform/x86/amd/amd_isp4.c
>>>> new file mode 100644
>>>> index 000000000000..27939020634c
>>>> --- /dev/null
>>>> +++ b/drivers/platform/x86/amd/amd_isp4.c
>>>> @@ -0,0 +1,309 @@
>>>> +// SPDX-License-Identifier: GPL-2.0+
>>>> +/*
>>>> + * AMD ISP platform driver for sensor i2-client instantiation
>>>> + *
>>>> + * Copyright 2025 Advanced Micro Devices, Inc.
>>>> + */
>>>> +
>>>> +#include <linux/i2c.h>
>>>> +#include <linux/module.h>
>>>> +#include <linux/platform_device.h>
>>>> +#include <linux/property.h>
>>>> +#include <linux/units.h>
>>>> +
>>>> +#define AMDISP_OV05C10_I2C_ADDR 0x10
>>>> +#define AMDISP_OV05C10_PLAT_NAME "amdisp_ov05c10_platform"
>>>
>>> This is not used anywhere?
>>>
>> Thanks. Will remove it, its not used anymore.
>>
>>>> +#define AMDISP_OV05C10_HID "OMNI5C10"
>>>> +#define AMDISP_OV05C10_REMOTE_EP_NAME "ov05c10_isp_4_1_1"
>>>> +#define AMD_ISP_PLAT_DRV_NAME "amd-isp4"
>>>> +
>>>> +/*
>>>> + * AMD ISP platform info definition to initialize sensor
>>>> + * specific platform configuration to prepare the amdisp
>>>> + * platform.
>>>> + */
>>>> +struct amdisp_platform_info {
>>>> + struct i2c_board_info board_info;
>>>> + const struct software_node **swnodes;
>>>> +};
>>>> +
>>>> +/*
>>>> + * AMD ISP platform definition to configure the device properties
>>>> + * missing in the ACPI table.
>>>> + */
>>>> +struct amdisp_platform {
>>>> + const struct amdisp_platform_info *pinfo;
>>>> + struct i2c_board_info board_info;
>>>> + struct notifier_block i2c_nb;
>>>> + struct i2c_client *i2c_dev;
>>>> + struct mutex lock; /* protects i2c client creation */
>>>
>>> Missing #include.
>>>
>> ok, will #include <linux/mutex.h>. I have not included some of these header
>> files seprately as they are already part of one or the other existing headers
>> in the patch.
>
> We try to include what is used by the file itself but as there's no
> ready to use tool to enforce it automatically, it largely depends on devs /
> reviewers noticing what should be added. Whenever adding a call to
> anything outside the .c file itself or use of non-local macro, it's good
> to check if another #include needs to be added (but I understand devs, me
> included, will often forget it).
>
> There are a few obvious includes where the other one is not needed as the
> path is practically guaranteed, typical examples: linux/xx.h including
> asm/xx.h or uapi/linux/xx.h.
>
> Relying intentionally on indirect includes creates very hard to track
> dependencies making it complex to remove any header from another header
> when the headerfile itself no longer needs that include. Build testing
> will catch some resulting fallout from such removal but it's coverage is
> not perfect.
>
Thanks Ilpo for the detailed explanation and clarifying the significance
of avoiding the indirect includes. Its really helpful. Thanks.
> --
> i.
prev parent reply other threads:[~2025-05-12 21:20 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-09 18:08 Pratap Nirujogi
2025-05-11 22:54 ` Ilpo Järvinen
2025-05-12 20:34 ` Nirujogi, Pratap
2025-05-12 21:00 ` Ilpo Järvinen
2025-05-12 21:20 ` Nirujogi, Pratap [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ec702d90-f6c0-479f-a62c-d09bf13fa13c@amd.com \
--to=pnirujog@amd.com \
--cc=W_Armin@gmx.de \
--cc=benjamin.chan@amd.com \
--cc=bin.du@amd.com \
--cc=dantony@amd.com \
--cc=gjorgji.rosikopulos@amd.com \
--cc=hdegoede@redhat.com \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=king.li@amd.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mario.limonciello@amd.com \
--cc=platform-driver-x86@vger.kernel.org \
--cc=pratap.nirujogi@amd.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®