[00:07] <ndufresne> as an example I express the tile width, a width shift
[00:08] <ndufresne> so 32x32, would be ws == 5, hw ==5
[00:09] <ndufresne> so from num_x_tiles << ws == padded_width
[07:47] <hverkuil> pinchartl: ping
[07:49] <hverkuil> ndufresne: you can't alias an existing format, it would break the uAPI. You can add support for both formats to the driver and refer to the standard format in the description of the vendor format with a note that it should not be used if the standard format is available.
[07:50] <hverkuil> And the driver should of course enumerate the standard format before the vendor format.
[07:55] <hverkuil> ndufresne: you can also do a pr_warn_once if the old vendor format is used to warn that that is deprecated.
[07:57] <pinchartl> hverkuil: pong
[07:57] <hverkuil> pinchartl: omap4/5 question:
[07:58] <hverkuil> I've started work on improving CEC support for omap4/5 (again) and I noticed that if I boot my pandaboard or beagle x15 board (aka omap5) without HDMI, and then plug in the HDMI after it is booted, no video comes up.
[07:59] <hverkuil> hdmi5_bridge_enable does not appear to be called in that case.
[07:59] <hverkuil> If I boot *with* HDMI plugged in, then once it is booted I can freely unplug and replug the HDMI without issues.
[07:59] <hverkuil> Is this a known issue? I tested with 5.8-rc5.
[08:00] <hverkuil> and our media master branch as well.
[08:00] <pinchartl> it's not a known issue to me at least
[08:00] <pinchartl> I can give it a try on the pandaboard
[08:01] <pinchartl> I don't think I have any omap5 board, but I would expect the issue to be the same on both
[08:01] <hverkuil> I would appreciate it if you can give that a quick test, just to make sure it isn't something weird in my setup.
[08:02] <pinchartl> I'll try to do so this afternoon
[08:03] <hverkuil> I'll try to debug a bit more for an hour or so. See where it fails.
[08:27] <hverkuil> pinchartl: testing with pandaboard: I see that the tpd12s015_hpd irq triggers when I plug in the HDMI after boot, but hdmi4_bridge_enable() is never called.
[08:33] <pinchartl> hverkuil: how are you testing that ? with fbcon ?
[08:36] <hverkuil> It boots to X11 (sddm login manager to be precise).
[08:50] <sailus> kbingham: Have you seen Rob Herring's comments on the 3rd patch?
[08:54] <jmondi> sailus: kbingham: Ah! my bad, I missed that. I sent a v10.1 for [1/4] but I missed I had to to the same for [3/4]
[08:55] <jmondi> sailus: if you look at 10.1 you'll see how trivial the fix is
[08:55] <jmondi> I can send it out the same 10.1 version for 3/4 asap
[09:01] <sailus> Please.
[09:01] <sailus> But we should still have Rob's ack.
[09:12] <kbingham> sailus, Would you like a full v11 resent with the two fixes for the dtbs?
[09:13] <kbingham> I've just re-run dt_binding_check with the latest schema (available by pip3 --upgrade at least) so now both pass
[09:18] <sailus> I'm fine with just a single updated 3rd patch, just as on the first one.
[09:33] <koike> hverkuil: o/ when you have some time, if you could please take a look at https://patchwork.linuxtv.org/project/linux-media/list/?series=2844 (or point me to the right people I should ping xD), I would appreciate it :)
[09:39] <hverkuil> koike: regarding Rob's Ack for patch 6/9: is that implicitly also for the preceding changes? I guess Rob Acked the rockchip-isp1.yaml file as it was at that point in the series, right?
[09:39] <kbingham> sailus, Sent.
[09:40] <hverkuil> koike: if so, then I can take patches 1-7.
[09:58] <koike> hverkuil: good question, I pinged him yesterday, but no answer so far, let me try to contact him again
[10:20] <sailus> kbingham: Ah, Rob had acked this earlier. Good.
[10:22] <Nable80> Hi! Is it OK to ask about ipu3-cio2/ipu3-imgu (Intel IPU3) drivers here? I have a tablet PC that is based on Kaby Lake SoC, it contains OV2680 camera sensor that is connected to MIPI CSI-2, I know exactly how it is connected (so it's possible to hardcode pin numbers instead of using ACPI) and I need some way to make this camera working via the
[10:22] <Nable80> usual v4l way.
[10:27] <Nable80> I've built Linux 5.8.0-rc5 with both ipu3-cio2 and ipu3-imgu enabled, these modules are loaded successfully but of course they don't detect any sensors automatically because ACPI tables are unusable on this device. Please, point me to the right place to get some help with making these modules actually work.
[10:29] <sailus> Nable80: Sure.
[10:30] <Nable80> Of course I can provide much more information, I just didn't want to spam the chat with loads of text in one message.
[10:30] <sailus> There are two issues, capturing the images as well as processing them.
[10:31] <sailus> Capturing requires ACPI table to describe the devices (e.g. sensors) in a way Linux understands them. If the system was shipped with Windows, the necessary bits in the ACPI tables are unlikely to be there.
[10:32] <sailus> The camera sensors produce raw Bayer images that need to be processed before being useful for regular applications.
[10:32] <Nable80> Yes, I've found some information about this complex structure: https://hverkuil.home.xs4all.nl/codec-api/v4l-drivers/ipu3.html + "Complex Cameras" presentation.
[10:32] <sailus> This part is unfortunately also not readily available for IPU3.
[10:33] <sailus> libcamera does go some way towards that direction.
[10:35] <Nable80> Let's solve the capturing part first. Vendor has provided schematics so it's possible to completely ignore ACPI and hardcode all values into driver. I just couldn't find the right place to put this information.
[10:43] <Nable80> Camera sensor (OV2680) is connected to CSI2_DN4/DP4 and CSI2_CLKN1/CLKP1 lines of CSI-2 receiver, all other CSI-2 lines are unused. It's also clocked by a 19.2 MHz external generator (I don't know why they added it instead of using PMC). There are several GPIOs to power up the camera, I've switched them manually via sysfs and I was able to
[10:43] <Nable80> successfully communicate with the control part of this camera sensor via I²C.
[10:44] <Nable80> How to tell ipu3-cio2 module that it should use data input channel 4 and clock input channel 1 and that base clock is 19.2 MHz?
[10:46] <Nable80> How to tell this module (or ipu3-imgu?) that it should use I2C2 (/dev/i2c-7) to communicate with sensor at address 0x10?
[10:46] <Nable80> There's no need for ACPI to get this information, it's already known.
[10:48] <Nable80> Probably I can even patch existing ACPI tables to be compatible with the format that Linux drivers expect if you point me at the description of this format.
[10:51] <Nable80> I wonder if it's OK to send e-mail directly to the authors of these drivers. I've asked almost the same question in libcamera channel yesterday and they told me that it's better to ask here.
[10:52] <kbingham> Nable80, You said there, how do you tell the cio2 that it just use specific channels and clocks, and to tell the imgu that it should use the sensor at /dev/i2c-7@0x10...
[10:53] <kbingham> That's done by obtaining the information from ACPI I believe. In embedded platforms, that information is stored in the device-tree, and the equivalent for x86 platforms is ACPI.
[10:53] <kbingham> But you've further said "There's no need for ACPI to get this information, it's already known." - How is it already known ? (generically?)
[10:54] <Nable80> There's a PC that I've mentioned and at the moment I just need to make it working on this specific device.
[10:55] <Nable80> So it's OK for me and my customer to make a specific crippled version of driver that would work just for this device. The version that would use hardcoded values instead of reading ACPI/DT.
[10:55] <Nable80> *DTB.
[10:56] <kbingham> Nable80, If you want to make a crippled version for yourself, specific to your device - then sure ... but that's not something that can work for others, so isn't going to be something 'we' can support.
[10:57] <Nable80> If we make 1 working device, then I can put some efforts to convert this driver into something more generic later.
[10:57] <kbingham> Nable80, I would expect that some of the information is provided in ACPI tables, but in a 'microsoft specific windows' format, and if we can convert that and parse it in linux, that could solve things, but I don't know whats storedi n the ACPI tables on those devices.
[11:00] <Nable80> There's some help from manufacturer. But it's not easy to get all the information from them at once. If I have any successful result in this project, they'll put more efforts into getting information.
[11:01] <kbingham> Nable80, Are you /manufacturing/ a product to run linux with this? If you have control over the ACPI tables from the factory, then I would expect you could get them configured in a way that the linux drivers support/expect ...
[11:02] <Nable80> This is a long and twisted story.
[11:02] <kbingham> For instance ,there are existing chromebooks with that device which have all the required information in ACPI. It's just that the format of that data differs on Chrome vs Windows.
[11:03] <kbingham> So there are very different cases if you are trying to make a 'one off device which has windows run this in linux' vs ... 'creating a product to use this chip with a linux-based os'
[11:03] <Nable80> Can you point me to a specific file that describes IPU3-based camera in ChromeOS sources?
[11:04] <Nable80> I mean ACPI settings (in a Linux-undestandable format) for chromebook with this camera.
[11:09] <Nable80> My current task is to bring a (somehow) complete Linux support to one specific device model. I'm working with an OEM, not with a device manufacturer directly, so I don't have full control over ACPI tables at the moment.
[11:10] <kbingham> Nable80, ChromeOS uses Coreboot I believe, so searching for "coreboot IPU3" returns : https://review.coreboot.org/c/coreboot/+/27124/12 as an interesting thing to look at perhaps, but I don't know any details, and would have to dig as much as you would.
[11:11] <hverkuil> pinchartl: emailed you test results from my pandaboard. I see where things go wrong, but have no idea what the solution is, that needs someone who knows this code.
[11:11] <hverkuil> Happy to test if you have patches.
[11:11] <sailus> Nable80: There's likely a PMIC chip that is used to both power and send a clock signal to the sensors.
[11:11] <Nable80> kbingham: it sound like a significant clue, thank you
[11:12] <sailus> Perhaps 19,2 MHz clock wasn't available from another source?
[11:12] <sailus> Or they needed the PMIC anyway?
[11:14] <Nable80> As far as I've read in Intel datasheets, their SoCs have so-called platform clock peripheral that was added specifically for such kind of tasks.
[11:15] <broonie> Nable80: Might be worth taking a look at sound/soc/intel and searching for ACPI in sound/soc in general.
[11:16] <sailus> Nable80: There's an example here: https://github.com/coreboot/coreboot/tree/master/src/mainboard/google/poppy/variants/baseboard/include/baseboard/acpi
[11:16] <sailus> Which computer is this btw.?
[11:16] <broonie> Modern audio systems have a similar problem with the hardware not being fully described in ACPI and have to key everything off DMI data (thank goodness for standards!)
[11:17] <Nable80> broonie: Wow, this is even a greater clue.
[11:18] <broonie> I wouldn't endorse much of this as a good idea but I'm not sure there's much better we can do :/
[11:22] <sailus> I'm not aware of DMI being used for this on systems with IPU3.
[11:22] <sailus> Schematics would be of great help in making the required ACPI changes for the system at hand btw.
[11:23] <Nable80> Although I'm still tempted to hardcode values in driver directly to avoid modifying firmware (at least for now, I don't want to brick /this/ device, it's too hard to disassemble/assemble the one that was temporary provided to me). But I didn't find where to do it yet.
[11:23] <sailus> Otherwise it's a hit or miss (or smoke).
[11:23] <Nable80> Yes, they've provided schematics but couldn't get the source of ACPI tables or MS driver.
[11:23] <sailus> Nable80: it could be more work in hardcoding the values, as you'll have to change a number of drivers.
[11:24] <kbingham> Nable80, Can you dump the tables through acpidump or such ?
[11:24] <Nable80> I've told it many times: I have schematics and I know exactly which pins are used.
[11:24] <Nable80> I've dumped existing ACPI tables but they look really bogus.
[11:24] <tfiga> I believe mchehab added some framework to the atom isp driver to probe atomisp based on some legacy ACPI data or no ACPI data at all
[11:25] <Nable80> atomisp is a different driver.
[11:25] <Nable80> I've studied it's code before and it was relatively was relatively easy to patch it.
[11:26] <tfiga> I know it is a different driver.
[11:26] <tfiga> But the same framework could be potentially reused with ipu3
[11:27] <tfiga> In general, you might be expecting that hardcoding things is the simple way here, but it often isn't
[11:27] <tfiga> There is more than one driver involved.
[11:27] <tfiga> The sensor driver needs to be probed too.
[11:28] <broonie> This is half the reason why sound/soc/intel is so non-awesome.
[11:28] <tfiga> I think what you need here is exactly some code to fill in the missing platform data on the systems that lack them
[11:28] <tfiga> And then let the generic code handle matching, binding and configuring the drivers the usual way
[11:29] <tfiga> So you exactly don't want to hardcode anything into a specific driver
[11:29] <tfiga> Just some kind of module that injects the missing data before the generic drivers are probed
[11:30] <broonie> That would be nice in general, but currently without that infrastructure we've been ending up adding essentially that in the drivers.
[11:34] <tfiga> well, it could be just a generic helper extracted from the atomisp driver
[11:35] <tfiga> and only to be used by the other media drivers
[11:35] <tfiga> although I would indeed envision this to expand into a more general solution
[11:36] <Nable80> OK. Although I don't feel that I've found a clear step-by-step roadmap, at least I have some new great clues. Thank you very much! Studying this whole amount of code without any clues would be too painful.
[11:37] <tfiga> Nable80: let me see if I can find a pointer to the compatibility framework for atomisp I mentioned before
[11:39] <tfiga> also, if your board design involves a PMIC for the sensor power management, things become much more complicated ;/
[11:40] <Nable80> No PMIC, don't worry.
[11:40] <tfiga> okay, that atomisp compatibility layer seems to be very much specific to the atomisp driver ;/
[11:41] <tfiga> as the driver doesn't use the generic probing mechanism the other drivers use
[11:41] <tfiga> (i.e. the fwnode_graph)
[11:41] <Nable80> Honestly, atomisp driver is an ultimate collection of very specific solutions.
[11:41] <tfiga> I remember we also used to have a legacy ACPI parses in Chrome OS kernel for the initial platform bringup
[11:41] <tfiga> before the proper ACPI tables were added
[11:41] <tfiga> maybe that could help
[11:42] <Nable80> ...but at least it works on some devices and it's easy to hack it further.
[11:43] <tfiga> Nable80: well, "works" :)
[11:43] <tfiga> https://chromium.googlesource.com/chromiumos/third_party/kernel/+/756673640c4a9e7f9b2cb6cad515b5b4861a7580%5E%21/
[11:44] <tfiga> this is the commit that removes the legacy parsing approach
[11:45] <Nable80> Yes, I've read it quickly.
[11:50] <Nable80> Btw, did anyone find an easy way to trace ACPI calls under MS Win10? This way I could collect a reference trace to reproduce under Linux.
[11:52] <tfiga> I think the call sequence is quite standard
[11:52] <Nable80> Using their kernel debugger on acpi.sys doesn't look like an easy way, although they recommend it. I wonder how could they develop anything with these inhumane tools.
[11:53] <Nable80> Which sequence do you mean by "standard" here?
[11:53] <tfiga> I would have to see an ACPI table of a Windows device using MIPI cameras
[11:53] <tfiga> but I imagine the power management calls are just standard for all devices
[11:53] <tfiga> and the only thing that stands out are the binary blobs with camera pipeline information
[11:54] <tfiga> ACPI is a standard :)
[11:54] <Nable80> Like UEFI, aha.
[11:54] <Nable80> Or USB-C >_<
[11:54] <tfiga> no, seriously, it is a standard
[11:55] <tfiga> and that's what allows you to boot Windows on Linux on (almost) any PC
[11:55] <tfiga> Windows or Linux
[11:55] <Nable80> Every manufacture perverts it in a way they like.
[11:55] <tfiga> yeah, but those are usually just some minor quirks
[11:55] <tfiga> (with not necessarily minor effects, but well)
[11:56] <Nable80> Running acpidump + iasl -d was one of the first things that I did when I've received this device.
[11:56] <Nable80> It was truly headbanging experience.
[11:57] <Nable80> At first I thought that I don't understand ACPI well or just stupid.
[11:57] <tfiga> nobody said it's a good standard ;)
[11:57] <Nable80> I was digging more and more into this.
[11:58] <Nable80> And now I'm sure: ACPI tables of this PC definitely contradict with schematics and reality.
[11:58] <Nable80> Yet Win10 (that was provided by OEM) detects camera correcty.
[11:58] <tfiga> or maybe the schematics contradict with reality?
[11:58] <Nable80> Nope, I've checked this part.
[11:59] <tfiga> of course it's possible that windows just ignores the entries for camera hardware
[12:00] <tfiga> regardless of whether the ACPI tables are correct or not, the approach would be still similar
[12:01] <tfiga> the difference would be only in whether the ACPI tables are parsed or the configuration data is hardcoded
[12:01] <tfiga> but injecting the data should look similar
[12:02] <tfiga> does the set of hardware advertised by your ACPI tables at least match the reality?
[12:03] <tfiga> specifically, is there nodes for CIO2 and the sensors?
[12:03] <tfiga> if yes, at least all the drivers would be probed without any hacks
[12:04] <tfiga> and only linking them together would need a bit of hackery
[12:04] <Nable80> Customer, schematics and Win10 reports that this device has OV2680 camera sensor that is connected to I2C2. Guess what I've found in DSDT? CAM0 with Name (_HID, "INT3471") and Name (_DDN, "IMX135-CRDG2"). And CAM1 with Name (_HID, "INT3474") and Name (_DDN, "OV2740-CRDG2") that is connected to I2C4.
[12:04] <Nable80> But in fact there's nothing connected to I2C4 on this PC.
[12:04] <tfiga> uhh
[12:04] <Nable80> And OV2680 is connected to I2C2.
[12:04] <tfiga> there is yet another approach
[12:05] <tfiga> https://01.org/linux-acpi/documentation/overriding-dsdt
[12:05] <tfiga> I'd risk saying that it could be the easiest thing
[12:06] <Nable80> Yes, I was just reading it here now: https://www.kernel.org/doc/html/latest/firmware-guide/acpi/method-customizing.html
[12:07] <Nable80> Learning ChromeOS ACPI format (with all those EP00 and PRT0 extensions) + injecting missing information before loading the driver seems to be a way to go.
[12:08] <tfiga> ah, that seems to be another option
[12:08] <tfiga> I've only used the whole DSDT override in the past
[12:08] <sailus> Nable80: Please see the _STA method: it may be that it returns a value based on a variable on the devices you wouldn't expect to see there.
[12:08] <sailus> That's sometimes used to disable the devices that are not really there.
[12:09] <Nable80> The main problem is that 2680 is not mentioned in current ACPI tables at all.
[12:10] <Nable80> It looks like MS drivers ignore device names and just use _CRS information.
[12:11] <Nable80> Then they probe all mentioned I2C devices to determine the real sensor model. This is just a guess.
[12:12] <sailus> I don't think that is being done, as the sensors use different operating voltages.
[12:12] <tfiga> does that '/sys/kernel/debug/acpi/custom_method' support adding other objects than just methods?
[12:14] <sailus> tfiga: The removed piece of code looks interesting for supporting IPU3 based systems with Windows ACPI tables.
[12:14] <sailus> This had escaped me earlier.
[12:14] <Nable80> tfiga: Unfortunately no. That's why I'll have to override the whole DSDT anyway, I think.
[12:14] <tfiga> the Linux format (which you referred to as Chrome OS format) uses named packages and resourcetemplates so those would have to be added as well
[12:14] <tfiga> yeah
[12:14] <tfiga> sailus: yeah, agreed
[12:15] <tfiga> I believe the format we started with came exactly from Windows
[12:15] <tfiga> although I'd still see something more like an ACPI injection framework
[12:16] <tfiga> or fwnode injection framework
[12:16] <tfiga> so that the drivers wouldn't have to handle the legacy stuff explicitly on their own
[12:17] <Nable80> Oops, I was suddenly disconnected.
[12:19] <sailus> tfiga: I still have a not-so-vague feeling this is not all that would be needed to support the Windows ACPI tables.
[12:19] <sailus> It is something though.
[12:26] <tfiga> sailus: it's possible
[12:26] <tfiga> although we had the cameras working with that code
[12:29] <tfiga> Nable80: you haven't lost anything I believe :)
[12:33] <Nable80> Fortunately there are logs here.
[12:33] <sailus> tfiga: I think there are also differences in the PMIC device nodes.
[12:34] <sailus> In ACPI tables I know sensor power management is missing.
[12:34] <sailus> (Windows ACPI tables, that is.)
[12:35] <tfiga> ah, yes
[12:36] <tfiga> I suspect we had some hacks related to that as well
[12:50] <tfiga> sailus: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/9e16a7ef427d1c168d77e9bc70efb2189afcb432/drivers/media/i2c/ov13858.c#1632
[12:51] <tfiga> speaking of a way to inject fwnodes
[12:51] <tfiga> it looks like we have something that looks like it already
[12:52] <tfiga> https://elixir.bootlin.com/linux/v5.8-rc4/source/drivers/base/swnode.c#L808
[12:52] <tfiga> broonie: not sure how useful that could be for sound use cases
[12:54] <broonie> tfiga: There is no sensible ACPI spec to patch things to match, and we'd need to modify pretty much every single ACPI table to add platform data.
[12:54] <broonie> even for the bits that could be within spec.
[13:01] <sailus> tfiga: Ugh, yes.
[13:01] <sailus> And then driver changes to expose those resources to regulator and clock frameworks.
[13:53] <Nable80> > iasl -tc dsdt_orig.dsl > Compilation successful. 0 Errors, 55 Warnings, 114 Remarks, 384 Optimizations
[13:54] <Nable80> I didn't even start changing it and it's already full of worms^W warnings.
[13:54] <broonie> Firmware tables in poor quality of implementation shocker!
[13:58] <Nable80> I've just mentioned it for you to know that it wasn't not /just my opinion/ that vendor provided some kind of mess instead of proper tables.
[14:20] <hverkuil> jmondi: ping
[14:21] <jmondi> hverkuil: pong
[14:21] <hverkuil> jmondi: is "v4l2-subdev: Introduce [g|s]et_mbus_format pad op" ready to go?
[14:21] <hverkuil> (v6)
[14:21] <jmondi> I'm about to send out an update to address Niklas comments from this morning
[14:22] <jmondi> likely a 6.1 version of the last patch
[14:22] <jmondi> neg: could you ack/rb it asap ?
[14:22] <hverkuil> Ah, I'll wait for that.
[14:22] <jmondi> (if you like it of course :)
[14:22] <jmondi> yeah sorry, las minute review
[14:23] <hverkuil> I really want this in so the old ops are killed off :-)
[14:24] <hverkuil> basically it's pretty much the last soc-camera-derived bit.
[14:25] <jmondi> yes indeed, I would be happy to see it getting in for this release too
[15:04] <hverkuil> jmondi: sorry, the v4l2-mediabus.h header needs some work before I can merge that series.
[15:06] <tfiga> Nable80: it's a well known fact and MS ASL compiler doesn't help either
[15:07] <tfiga> the good part is that at least iasl is much better pointing any problems out and those can be fixed :)
[15:08] <jmondi> hverkuil: what precisely ?
[15:08] <jmondi> hverkuil: my series doesn't touch it
[15:08] <jmondi> (and maybe that's the issue :) )
[15:09] <neg> jmondi: done
[15:09] <jmondi> neg: thanks!
[15:10] <hverkuil> jmondi: that's the issue :-) Replied to 1/9.
[15:10] <jmondi> hverkuil: oh, seen the email now
[15:11] <jmondi> I'll try to update at least the comments between today and tomorro
[15:11] <jmondi> we discussed already how to rework the V4L2_MBUS flags, but decided that should be done on-top
[15:13] <hverkuil> Ah, OK. No problem to change that later. But the header does need to be updated as part of this series.
[15:13] <jmondi> I'll try to update comments at least
[15:14] <jmondi> that change, plus a new version of 9/9 to add a blank line to please neg, will probably require a v7
[15:15] <hverkuil> It's probably easier to post a v7. Less chance of mistakes.
[15:15] <jmondi> yes indeed
[15:15] <jmondi> will send tomorrow then
[15:15] <hverkuil> If it looks good, then I'll make a PR of v7.
[15:16] <jmondi> let's hope so
[15:16] <jmondi> we can sync tomorrow to make sure what I'll send out is ok for you
[15:16] <hverkuil> sure
[15:16] <jmondi> thank you :)
[15:34] <pinchartl> tfiga: I sometimes wonder if the easiest path forward wouldn't be to rewrite the camera-related parts of the DSDT with DSDT override
[15:34] <pinchartl> not pretty though
[15:36] <pinchartl> if it was just about the camera sensors maybe we could use swnodes, but as they need to interact with PM, ...
[16:22] <tfiga> pinchartl: I would hope that users don't have to override the whole DSDT, though
[16:22] <tfiga> I wonder if there is a way to override just a part of it
[16:22] <tfiga> some kind of a DSDT overlay
[16:24] <pinchartl> tfiga: possibly an interesting experiment, but good luck :-)
[16:25] <broonie> I thought there was a mechanism for that already.
[16:27] <pinchartl> broonie: is there ?
[16:39] <broonie> ICBW...
[16:41] <pinchartl> so can I, I'm not an ACPI specialist (and I'm fine with that :-))
[18:25] <dafna2> pinchartl: ping
[18:25] <pinchartl> dafna2: pong
[18:26] <pinchartl> (I'm in a phone call though)
[18:26] <dafna2> oh, not arrgent
[18:29] <ndufresne> did you mean not arrogant ?
[18:30] <ndufresne> (kidding)
[18:34] <dafna2> oh, my spelling
[18:34] <dafna2> urgent
[18:35] <pinchartl> ndufresne: thank you :-)
[18:36] <ndufresne> GCC makes similar suggestions these days, can be funny
[19:11] <ezequielg> not argentine?
[19:12] <pinchartl> dafna2: done with the phone. how can I help you ?
[19:17] <dafna2> hi , so it is regarding synchronization of the frames in rkisp1,
[19:17] <pinchartl> I've seen the e-mail but haven't replied yet as I need to refresh my memory on that and haven't found time yet :-(
[19:18] <dafna2> oh, ok
[19:18] <pinchartl> if you have other specific questions I can try to answer them now, but there's a risk I'll have the same issue
[19:18] <pinchartl> (I'll be back in 30 minutes, sorry about that)
[19:33] <dafna2> so ill ping you tomorrow
[19:33] <dafna2> it is already dark
[21:40] <sailus> kbingham: Could you run checkpatch.pl on the patches and correct the issues as follow-up patches --- as long as they're reasonable? There are a few.