From: Patrik Gfeller <patrik.gfeller@gmail.com>
To: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Cc: linux-media@vger.kernel.org
Subject: Re: atomisp kernel driver(s)
Date: Sat, 2 May 2020 16:50:48 +0200 [thread overview]
Message-ID: <20200502165048.7a1891e2@ASUS> (raw)
In-Reply-To: <20200502113414.618964a9@coco.lan>
On Sat, 2 May 2020 11:34:14 +0200
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> wrote:
> Em Sat, 2 May 2020 10:15:42 +0200
> Patrik Gfeller <patrik.gfeller@gmail.com> escreveu:
>
> > On Fri, 1 May 2020 21:30:23 +0200
> > Mauro Carvalho Chehab <mchehab+huawei@kernel.org> wrote:
> >
> [...]
>
> [...]
> >
> > Cool, the code might give additional information.
>
> Yes. And, as it was released from Intel for a specific device,
> it should very likely work for the model supported there (with
> the Yocto 4.4 Kernel). So, it could be valuable to help identifying
> if some of the cleanup patches would have broken something.
>
> ON a quick look, it sounds that such build was is targeted for
> ISP2401:
>
> +++ b/drivers/media/pci/atomisp/Makefile
> @@ -0,0 +1 @@
> +obj-$(CONFIG_VIDEO_ATOMISP) += css2401a0_v21_build/
>
> > I've also send a
> > request regarding the firmware and HW documentation to the author and
> > the engineers that signed the patch. The firmware in the patch has a
> > different version string and the size is surprisingly a few MB bigger
> > than the one I used for the first experiment.
>
> There are some vendors that generate a firmware together with a source
> code. This could be the case here. That's my feeling when looking into
> a file like:
>
> drivers/staging/media/atomisp/pci/css_2401_system/spmem_dump.c
>
> Which contains lots of addresses that it is different betwen 2401 and
> 2400.
>
> If so, using a different firmware version will likely cause at least
> some parts of the driver to fail.
>
>
> > I'll give that one a try as well.
> >
> [...]
> >
> > It looks a this firmware is for the 2400 variant; I could also not
> > extract the irci version string. Thus I'll not try them for the moment
> > to perform experiments.
>
> Ok.
>
> [...]
> >
> > It identifies itself as irci_stable_bw10p_0518_20150801_0537;
>
> Same year as what we had. Just a little older. Yeah, some things there
> could work.
I found another place where the irci_stable_bw10p_0518_20150801_0537
firmware is used together with patches for atomisp 2401. So I assume the
code there matches this firmware. Eventually some of the patches listed
there can be used as information source:
https://github.com/croutor/atomisp2401
>
> > I'll give
> > that one a try first. As usual it will unfortunately take some time
> > until I get back to you with the results, as every experiment takes
> > many hours (building the kernel on what is essentially a tablet takes
> > time).
>
> I would suggest you to build on some other machine. Btw, you don't need
> to build everything every time. If you build atomisp as a module, you
> could do, instead:
>
> $ make modules_prepare && make M=drivers/staging/media/atomisp
>
> This will build just the new module(s).
>
> [...]
>
> Btw, the patch I send earlier today should fix this issue.
>
> -
>
> I need to understand a little bit more about how ACPI is supposed to
> detect and register regulators. While using regulators with DT is very
> common, not many places use it for ACPI.
>
> I'm suspecting that, before being able of calling regulator_get(),
> the code should use some match logic to get the regulators on this
> board and call regulator_register().
>
> Please run this command on your tablet:
>
> $ sudo cat /sys/kernel/debug/regulator/supply_map
>
> If this returns nothing - as I suspect - then calling regulator_get()
> won't be doing anything.
>
> Thanks,
> Mauro
with kind regards,
Patrik
next prev parent reply other threads:[~2020-05-02 14:50 UTC|newest]
Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-18 14:39 atomisp kernel driver(s) Patrik Gfeller
2020-04-18 15:25 ` Mauro Carvalho Chehab
2020-04-18 15:26 ` Mauro Carvalho Chehab
2020-04-18 15:37 ` Patrik Gfeller
2020-04-19 23:31 ` Mauro Carvalho Chehab
2020-04-20 17:48 ` Patrik Gfeller
2020-04-20 18:27 ` Patrik Gfeller
2020-04-20 20:47 ` Mauro Carvalho Chehab
2020-04-22 17:56 ` Patrik Gfeller
2020-04-22 19:13 ` Mauro Carvalho Chehab
2020-04-24 8:52 ` Patrik Gfeller
2020-04-24 9:10 ` Patrik Gfeller
2020-04-24 10:07 ` Patrik Gfeller
2020-04-24 13:58 ` Patrik Gfeller
2020-04-25 11:22 ` Mauro Carvalho Chehab
2020-04-26 11:38 ` Patrik Gfeller
2020-04-26 16:50 ` Mauro Carvalho Chehab
2020-04-27 18:31 ` Patrik Gfeller
2020-04-27 21:50 ` Mauro Carvalho Chehab
2020-04-28 17:59 ` Patrik Gfeller
2020-04-28 23:13 ` Mauro Carvalho Chehab
2020-04-29 17:56 ` Patrik Gfeller
2020-04-29 18:17 ` Mauro Carvalho Chehab
2020-04-30 7:56 ` Patrik Gfeller
2020-04-30 10:55 ` Mauro Carvalho Chehab
2020-04-30 15:09 ` Patrik Gfeller
2020-04-30 22:25 ` Mauro Carvalho Chehab
2020-05-01 8:54 ` Patrik Gfeller
2020-05-01 9:38 ` Mauro Carvalho Chehab
2020-05-01 17:31 ` Patrik Gfeller
2020-05-01 19:30 ` Mauro Carvalho Chehab
2020-05-02 8:15 ` Patrik Gfeller
2020-05-02 9:20 ` Patrik Gfeller
2020-05-02 10:00 ` Mauro Carvalho Chehab
2020-05-02 9:34 ` Mauro Carvalho Chehab
2020-05-02 14:29 ` Patrik Gfeller
2020-05-02 16:28 ` Mauro Carvalho Chehab
2020-05-02 18:23 ` Patrik Gfeller
2020-05-02 14:50 ` Patrik Gfeller [this message]
2020-04-18 15:29 ` Patrik Gfeller
2020-04-25 2:39 ` Laurent Pinchart
2020-04-25 10:36 ` Patrik Gfeller
2020-04-25 12:19 ` Mauro Carvalho Chehab
2020-04-26 19:07 ` Laurent Pinchart
2020-04-26 20:51 ` Mauro Carvalho Chehab
2020-04-26 19:33 ` Laurent Pinchart
2020-04-28 18:13 ` Patrik Gfeller
2020-04-26 7:44 ` Patrik Gfeller
2020-04-26 19:17 ` Laurent Pinchart
2020-04-29 17:59 ` Patrik Gfeller
2020-04-29 18:19 ` Laurent Pinchart
2020-04-30 15:28 ` Patrik Gfeller
2020-05-02 16:08 ` Andy Shevchenko
2020-05-02 17:04 ` Mauro Carvalho Chehab
2020-05-02 17:33 ` Andy Shevchenko
2020-05-03 10:18 ` Mauro Carvalho Chehab
2020-05-12 10:20 ` Mauro Carvalho Chehab
2020-05-12 11:12 ` Andy Shevchenko
2020-05-12 11:21 ` Andy Shevchenko
2020-05-12 14:56 ` Mauro Carvalho Chehab
2020-05-12 16:01 ` Andy Shevchenko
2020-05-13 18:36 ` Patrik Gfeller
2020-05-20 8:04 ` Mauro Carvalho Chehab
2020-05-13 9:56 ` Mauro Carvalho Chehab
2020-05-03 8:46 ` Patrik Gfeller
2020-05-03 10:23 ` Mauro Carvalho Chehab
2020-05-03 12:31 ` Patrik Gfeller
2020-05-03 13:36 ` Patrik Gfeller
2020-05-03 14:43 ` Mauro Carvalho Chehab
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=20200502165048.7a1891e2@ASUS \
--to=patrik.gfeller@gmail.com \
--cc=linux-media@vger.kernel.org \
--cc=mchehab+huawei@kernel.org \
/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