(no subject)

[Walter Cheuk]

Hi,

I sent a patch named "[PATCH] tv tuner max2165 driver: extend
frequency range" two weeks ago (22/10). Is it being reviewed? Thank
you.


Walter Cheuk

Re:

[Alberto Mardegan]

On 11/12/2015 06:25 AM, Walter Cheuk wrote:
> I sent a patch named "[PATCH] tv tuner max2165 driver: extend
> frequency range" two weeks ago (22/10). Is it being reviewed? Thank
> you.

Since such reminders seem to help, I also sent a patch on 27/10:
"[PATCH] [media] em28xx: add Terratec Cinergy T XS (MT2060)"

It's not urgent, given that people have been surviving without support 
for this device for years, but I'd just like to make sure that it won't 
be forgotten.

Ciao,
   Alberto

Re:

[Mauro Carvalho Chehab]

Em Thu, 12 Nov 2015 18:16:18 +0300
Alberto Mardegan <mardy@users.sourceforge.net> escreveu:

> On 11/12/2015 06:25 AM, Walter Cheuk wrote:
> > I sent a patch named "[PATCH] tv tuner max2165 driver: extend
> > frequency range" two weeks ago (22/10). Is it being reviewed? Thank
> > you.
> 
> Since such reminders seem to help, I also sent a patch on 27/10:
> "[PATCH] [media] em28xx: add Terratec Cinergy T XS (MT2060)"
> 
> It's not urgent, given that people have been surviving without support 
> for this device for years, but I'd just like to make sure that it won't 
> be forgotten.

Complaining doesn't help at all. We don't read the mailing list to
check for new patches. Instead, we look for them at:
	https://patchwork.linuxtv.org/project/linux-media/list/

All patches that goes to the ML are automatically stored there, and will be
handled by one of the (sub-)maintainers.

If your patch is stored there, you only need to worry when you receive
an status update. If accepted, it will soon be on my tree. Otherwise,
some action would likely be required from you, and you should likely
have received some e-mail from the (sub-)maintainer that reviewed your
patch with further instructions (except when the issue was already
fixed by some other patch).

However, if the emailer breaks the patch (with was the case of the
"tv tuner max2165..." patch), patchwork won't recognize it as a
patch, and we'll only see the e-mail by accident.

In the case of the em28xx patch, it is there:
	https://patchwork.linuxtv.org/project/linux-media/list/?submitter=Alberto

So, we'll handle it.

Regards,
Mauro

Re:

[Alec Leamas]

On 12/11/15 18:20, Mauro Carvalho Chehab wrote:
> Em Thu, 12 Nov 2015 18:16:18 +0300
> Alberto Mardegan <mardy@users.sourceforge.net> escreveu:

> Complaining doesn't help at all. We don't read the mailing list to
> check for new patches. Instead, we look for them at:
> 	https://patchwork.linuxtv.org/project/linux-media/list/
> 
> All patches that goes to the ML are automatically stored there, and will be
> handled by one of the (sub-)maintainers. 

> However, if the emailer breaks the patch (with was the case of the
> "tv tuner max2165..." patch), patchwork won't recognize it as a
> patch, and we'll only see the e-mail by accident.

Ah... that explains why nobody cares about my patch[1]... Is there any
way around picky emailers? Is putting the patch in an attachment OK?

Cheers!

--alec


[1] https://bugzilla.kernel.org/show_bug.cgi?id=75751

Re:

[Mauro Carvalho Chehab]

Em Thu, 12 Nov 2015 18:31:51 +0100
Alec Leamas <leamas.alec@gmail.com> escreveu:

> On 12/11/15 18:20, Mauro Carvalho Chehab wrote:
> > Em Thu, 12 Nov 2015 18:16:18 +0300
> > Alberto Mardegan <mardy@users.sourceforge.net> escreveu:
> 
> > Complaining doesn't help at all. We don't read the mailing list to
> > check for new patches. Instead, we look for them at:
> > 	https://patchwork.linuxtv.org/project/linux-media/list/
> > 
> > All patches that goes to the ML are automatically stored there, and will be
> > handled by one of the (sub-)maintainers. 
> 
> > However, if the emailer breaks the patch (with was the case of the
> > "tv tuner max2165..." patch), patchwork won't recognize it as a
> > patch, and we'll only see the e-mail by accident.
> 
> Ah... that explains why nobody cares about my patch[1]... Is there any
> way around picky emailers? 

Use a good one ;) Here, I use claws-mail, with works fine if configured
to send text-only e-mails and to not break long lines.

Another alternative is to use git to send the email with something like:

	git send-email HEAD~1 --annotate

That requires some setup at the .git/config file:
	https://git-scm.com/docs/git-send-email

As you use gmail, you could add at the .git/config:

[sendemail]
    smtpEncryption = tls
    smtpServer = smtp.gmail.com
    smtpUser = yourname@gmail.com
    smtpServerPort = 587

> Is putting the patch in an attachment OK?

No, because it doesn't make easy for people to reply with comments.

Regards,
Mauro

Re:

[Alec Leamas]

On 12/11/15 18:41, Mauro Carvalho Chehab wrote:
> Em Thu, 12 Nov 2015 18:31:51 +0100
> Alec Leamas <leamas.alec@gmail.com> escreveu:
> 
>> On 12/11/15 18:20, Mauro Carvalho Chehab wrote:
>>> Em Thu, 12 Nov 2015 18:16:18 +0300
>>> Alberto Mardegan <mardy@users.sourceforge.net> escreveu:
>>
>>> Complaining doesn't help at all. We don't read the mailing list to
>>> check for new patches. Instead, we look for them at:
>>> 	https://patchwork.linuxtv.org/project/linux-media/list/

So, now you find it?!

>>> However, if the emailer breaks the patch (with was the case of the
>>> "tv tuner max2165..." patch), patchwork won't recognize it as a
>>> patch, and we'll only see the e-mail by accident.
>>
>> Ah... that explains why nobody cares about my patch[1]... Is there any
>> way around picky emailers? 
> 
> Use a good one ;) Here, I use claws-mail, with works fine if configured
> to send text-only e-mails and to not break long lines.

Installing claws-mail for this purpose wasn't too hard.

>> Is putting the patch in an attachment OK?
> 
> No, because it doesn't make easy for people to reply with comments.

Fair enough.



Thanks for newbie help. Cheers!

--alec

Re:

[Patrick Boettcher]

On Thu, 12 Nov 2015 15:41:50 -0200 Mauro Carvalho Chehab
<mchehab@osg.samsung.com> wrote:
> > Is putting the patch in an attachment OK?
> 
> No, because it doesn't make easy for people to reply with comments.

Except if you are using claws. With which you can select text in a text
attachment and click the reply button and it will create a response
with the selected text in the message body. But only this part, not the
rest of the message.

regards,
--
Patrick.

Re:

[Mauro Carvalho Chehab]

Em Fri, 13 Nov 2015 10:54:31 +0100
Patrick Boettcher <patrick.boettcher@posteo.de> escreveu:

> On Thu, 12 Nov 2015 15:41:50 -0200 Mauro Carvalho Chehab
> <mchehab@osg.samsung.com> wrote:
> > > Is putting the patch in an attachment OK?
> > 
> > No, because it doesn't make easy for people to reply with comments.
> 
> Except if you are using claws. With which you can select text in a text
> attachment and click the reply button and it will create a response
> with the selected text in the message body. But only this part, not the
> rest of the message.

Yes, I use such feature when needed, but then I need to do two "replies"
and merge on a single reply email, with kinda sucks and spends me more time.
So, I tend to postpone those patches, if I am in a hurry.

However, lots of developers use mutt, with doesn't have such option.

Regards,
Mauro

Re:

[Alberto Mardegan]

On 11/12/2015 07:20 PM, Mauro Carvalho Chehab wrote:
> Complaining doesn't help at all. We don't read the mailing list to

I wasn't complaining, just asking :-)

[...]
> All patches that goes to the ML are automatically stored there, and will be
> handled by one of the (sub-)maintainers.
[...]

That was the information I missed. Then all is fine, thanks. :-)

Ciao,
  Alberto

-- 
http://blog.mardy.it <- geek in un lingua international!

(no subject)

[Mikhail Lobanov]

Subject: [PATCH] cobalt:  adding a check to the driver

This patch addresses an issue in cobalt-flash.c where the return value of the mtd_device_register function, 
was not being checked. This omission could lead to unhandled errors if the registration fails.
The patch adds error handling by checking the return value and logging an error message if registration fails.
It ensures that the function returns the appropriate error code, improving error detection and the robustness 
of the code.

Found by Linux Verification Center (linuxtesting.org) with SVACE.

Fixes: 85756a069c55 ("[media] cobalt: add new driver")
Signed-off-by: Mikhail Lobanov <m.lobanov@rosalinux.ru>
---
 drivers/media/pci/cobalt/cobalt-flash.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/media/pci/cobalt/cobalt-flash.c b/drivers/media/pci/cobalt/cobalt-flash.c
index 1d3c64b4cf6d..06ad9aaeff1b 100644
--- a/drivers/media/pci/cobalt/cobalt-flash.c
+++ b/drivers/media/pci/cobalt/cobalt-flash.c
@@ -1,4 +1,4 @@
-// SPDX-License-Identifier: GPL-2.0-only
+/// SPDX-License-Identifier: GPL-2.0-only
 /*
  *  Cobalt NOR flash functions
  *
@@ -104,6 +104,10 @@ int cobalt_flash_probe(struct cobalt *cobalt)
 	mtd->owner = THIS_MODULE;
 	mtd->dev.parent = &cobalt->pci_dev->dev;
 	mtd_device_register(mtd, NULL, 0);
+        if (ret) {
+        cobalt_err("Registering MTD device failed with error %d\n", ret);
+        return ret;
+    }
 	return 0;
 }
 
-- 
2.43.0

Re:

[Hans Verkuil]

On 01/08/2024 15:54, Mikhail Lobanov wrote:
> Subject: [PATCH] cobalt:  adding a check to the driver

The subject might be here, but it is not in the actual subject line of the email!

> 
> This patch addresses an issue in cobalt-flash.c where the return value of the mtd_device_register function, 
> was not being checked. This omission could lead to unhandled errors if the registration fails.
> The patch adds error handling by checking the return value and logging an error message if registration fails.
> It ensures that the function returns the appropriate error code, improving error detection and the robustness 
> of the code.
> 
> Found by Linux Verification Center (linuxtesting.org) with SVACE.
> 
> Fixes: 85756a069c55 ("[media] cobalt: add new driver")
> Signed-off-by: Mikhail Lobanov <m.lobanov@rosalinux.ru>
> ---
>  drivers/media/pci/cobalt/cobalt-flash.c | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/media/pci/cobalt/cobalt-flash.c b/drivers/media/pci/cobalt/cobalt-flash.c
> index 1d3c64b4cf6d..06ad9aaeff1b 100644
> --- a/drivers/media/pci/cobalt/cobalt-flash.c
> +++ b/drivers/media/pci/cobalt/cobalt-flash.c
> @@ -1,4 +1,4 @@
> -// SPDX-License-Identifier: GPL-2.0-only
> +/// SPDX-License-Identifier: GPL-2.0-only

Why?

>  /*
>   *  Cobalt NOR flash functions
>   *
> @@ -104,6 +104,10 @@ int cobalt_flash_probe(struct cobalt *cobalt)
>  	mtd->owner = THIS_MODULE;
>  	mtd->dev.parent = &cobalt->pci_dev->dev;
>  	mtd_device_register(mtd, NULL, 0);
> +        if (ret) {
> +        cobalt_err("Registering MTD device failed with error %d\n", ret);
> +        return ret;
> +    }

This is obviously wrong, and just as importantly, the caller of cobalt_flash_probe
doesn't check the return code either.

The indentation is wrong as well.

This is a really poor patch...

Regards,

	Hans

>  	return 0;
>  }
>  

(no subject)

[Fritz Koenig]

v2:
- cover letter
- testing methodology
- Signed-off-by

V4L2 has support for hierarchical P frames using the
V4L2_CID_MPEG_VIDEO_H264_HIERARCHICAL_CODING* controls. This allows for
specifing P frame references needed for temporal scalability. Encoding a
single stream with a single layer allows for the layer to be dropped and
the stream to be decoded without artifacts.

ChromeOS is planning to use this feature for the L1T2 web standard[1].
This allows video conferencing apps to encode once for a clients with
different performance/bandwidth capabilities.

The ChromeOS test framework ("tast") was used to verify that no
regressions are present. This was done on SC7180 ("trogdor").

Verification of the added controls was done with a bitstream analyser to
make sure that reference frame management is correct.

[1]: https://www.w3.org/TR/webrtc-svc/#L1T2*

Re:

[Fritz Koenig]

On Mon, Jul 29, 2024 at 12:32 PM Fritz Koenig <frkoenig@chromium.org> wrote:
>
>
> v2:
> - cover letter
> - testing methodology
> - Signed-off-by
>
> V4L2 has support for hierarchical P frames using the
> V4L2_CID_MPEG_VIDEO_H264_HIERARCHICAL_CODING* controls. This allows for
> specifing P frame references needed for temporal scalability. Encoding a
> single stream with a single layer allows for the layer to be dropped and
> the stream to be decoded without artifacts.
>
> ChromeOS is planning to use this feature for the L1T2 web standard[1].
> This allows video conferencing apps to encode once for a clients with
> different performance/bandwidth capabilities.
>
> The ChromeOS test framework ("tast") was used to verify that no
> regressions are present. This was done on SC7180 ("trogdor").
>
> Verification of the added controls was done with a bitstream analyser to
> make sure that reference frame management is correct.
>
> [1]: https://www.w3.org/TR/webrtc-svc/#L1T2*
>

I still have plans to use git send-email correctly. Hopefully by the
next patch series.

Sorry for the missing subject, another email has been sent with the
correct subject.
I didn't realize that this had gone through.

Re:

[Bryan O'Donoghue]

On 29/07/2024 20:46, Fritz Koenig wrote:
> On Mon, Jul 29, 2024 at 12:32 PM Fritz Koenig <frkoenig@chromium.org> wrote:
>>
>>
>> v2:
>> - cover letter
>> - testing methodology
>> - Signed-off-by
>>
>> V4L2 has support for hierarchical P frames using the
>> V4L2_CID_MPEG_VIDEO_H264_HIERARCHICAL_CODING* controls. This allows for
>> specifing P frame references needed for temporal scalability. Encoding a
>> single stream with a single layer allows for the layer to be dropped and
>> the stream to be decoded without artifacts.
>>
>> ChromeOS is planning to use this feature for the L1T2 web standard[1].
>> This allows video conferencing apps to encode once for a clients with
>> different performance/bandwidth capabilities.
>>
>> The ChromeOS test framework ("tast") was used to verify that no
>> regressions are present. This was done on SC7180 ("trogdor").
>>
>> Verification of the added controls was done with a bitstream analyser to
>> make sure that reference frame management is correct.
>>
>> [1]: https://www.w3.org/TR/webrtc-svc/#L1T2*
>>
> 
> I still have plans to use git send-email correctly. Hopefully by the
> next patch series.
> 
> Sorry for the missing subject, another email has been sent with the
> correct subject.
> I didn't realize that this had gone through.

b4 is your friend it will stop you making errors like this.

https://b4.docs.kernel.org/en/latest/index.html

b4 prep --enroll HEAD

git-cherry-pick <your seires of shas you want>

b4 prep --auto-to-cc

b4 prep --edit-cover

b4 prep --check

b4 send --reflect --no-sign

Finally when you're done

b4 send --no-sign

if you get feedback or Signed-off/Reivewed-by whatever

b4 trailers -u

git rebase some-patch

do some stuff

git rebase --continue

when you're done

b4 prep --edit-cover

b4 send --no-sign --reflect

---
bod

(no subject)

[Thomas Devoogdt]

Hi all,


I have two questions:

1.
When running v4l2-compliance on a proprietary driver, I get this error:

```
Input/Output configuration ioctls:
fail: v4l2-test-io-config.cpp(227): fmt.fmt.pix.width >=
enumtimings.timings.bt.width * 1.5
fail: v4l2-test-io-config.cpp(386): Timings check failed for input 0.
test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: FAIL
```

Which brings me here:
https://git.linuxtv.org/v4l-utils.git/tree/utils/v4l2-compliance/v4l2-test-io-config.cpp#n227

```
fail_on_test(fmt.fmt.pix.width < enumtimings.timings.bt.width);
fail_on_test(fmt.fmt.pix.width >= enumtimings.timings.bt.width * 1.5);
fail_on_test(fmt.fmt.pix.height * factor < enumtimings.timings.bt.height);
fail_on_test(fmt.fmt.pix.height * factor >=
enumtimings.timings.bt.height * 1.5);
```

The problem is that the driver supports VIDIOC_S_DV_TIMINGS but is not
able to apply the specific format just returns the actual timings.
This is from what I know, not a violation, so I'm not sure what the
driver should return if it is not able to set a custom timing. Or is
this check just a bit too strict?


2.
For another driver, I get this error:

```
Input ioctls:
fail: v4l2-test-input-output.cpp(443): use of deprecated digital video status
fail: v4l2-test-input-output.cpp(496): invalid attributes for input 0
test VIDIOC_G/S/ENUMINPUT: FAIL
```

It might be true that setting V4L2_IN_ST_NO_CARRIER is deprecated, but
is that really an error, not better to just have it as a warning?
After all, how can userspace know specific details if needed? Perhaps
checking that V4L2_IN_ST_NO_SIGNAL has also been set is enough, and if
V4L2_IN_ST_NO_CARRIER is set, but not V4L2_IN_ST_NO_SIGNAL, then it
might be an error.

Thx in advance!

Kr,

Thomas Devoogdt

Re:

[Hans Verkuil]

On 22/11/2023 10:26, Thomas Devoogdt wrote:
> Hi all,
> 
> 
> I have two questions:
> 
> 1.
> When running v4l2-compliance on a proprietary driver, I get this error:
> 
> ```
> Input/Output configuration ioctls:
> fail: v4l2-test-io-config.cpp(227): fmt.fmt.pix.width >=
> enumtimings.timings.bt.width * 1.5
> fail: v4l2-test-io-config.cpp(386): Timings check failed for input 0.
> test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: FAIL
> ```
> 
> Which brings me here:
> https://git.linuxtv.org/v4l-utils.git/tree/utils/v4l2-compliance/v4l2-test-io-config.cpp#n227
> 
> ```
> fail_on_test(fmt.fmt.pix.width < enumtimings.timings.bt.width);
> fail_on_test(fmt.fmt.pix.width >= enumtimings.timings.bt.width * 1.5);
> fail_on_test(fmt.fmt.pix.height * factor < enumtimings.timings.bt.height);
> fail_on_test(fmt.fmt.pix.height * factor >=
> enumtimings.timings.bt.height * 1.5);
> ```
> 
> The problem is that the driver supports VIDIOC_S_DV_TIMINGS but is not
> able to apply the specific format just returns the actual timings.
> This is from what I know, not a violation, so I'm not sure what the
> driver should return if it is not able to set a custom timing. Or is
> this check just a bit too strict?

This test enumerates all timings returned by VIDIOC_ENUM_DV_TIMINGS.
All these timings should be valid supported timings. For each returned
timing it calls S_DV_TIMINGS to set it. Then it call G_DV_TIMINGS to
verify that the width and height of the new timings match what was
requested. Apparently that worked, otherwise the test would have
failed there.

Next it gets the new format (G_FMT). The driver must update the format
when the timings are updated. In this case the width of the returned
format is more than 1.5 times the width of the requested timings.
That doesn't sound right.

Your claim that S_DV_TIMINGS can't set the new timings is dubious
since G_DV_TIMINGS apparently returns the new timings correctly.
Also, ENUM_DV_TIMINGS shouldn't return unsupported timings either.

> 
> 
> 2.
> For another driver, I get this error:
> 
> ```
> Input ioctls:
> fail: v4l2-test-input-output.cpp(443): use of deprecated digital video status
> fail: v4l2-test-input-output.cpp(496): invalid attributes for input 0
> test VIDIOC_G/S/ENUMINPUT: FAIL
> ```
> 
> It might be true that setting V4L2_IN_ST_NO_CARRIER is deprecated, but
> is that really an error, not better to just have it as a warning?
> After all, how can userspace know specific details if needed? Perhaps
> checking that V4L2_IN_ST_NO_SIGNAL has also been set is enough, and if
> V4L2_IN_ST_NO_CARRIER is set, but not V4L2_IN_ST_NO_SIGNAL, then it
> might be an error.

The NO_CARRIER, NO_EQU and NO_ACCESS status flags are DVB specific, but this
ioctl isn't used by DVB anymore. I think very old drivers in the past (long
since removed or changed) used this, but new drivers must not use this since
it makes no sense. Note that v4l2-compliance is often more strict than the
V4L2 spec itself: it is meant to ensure that drivers follow best practices.

Note that the error message is not very good: it should say "digital TV"
rather than "digital video". I'll fix that since that's confusing.

Regards,

	Hans

> 
> Thx in advance!
> 
> Kr,
> 
> Thomas Devoogdt
> 

Re:

[Thomas Devoogdt]

Hi Hans,

Thx for the fast response!
See inline below.

Kind regards,

Thomas Devoogdt


Op wo 22 nov 2023 om 10:48 schreef Hans Verkuil <hverkuil@xs4all.nl>:
>
> On 22/11/2023 10:26, Thomas Devoogdt wrote:
> > Hi all,
> >
> >
> > I have two questions:
> >
> > 1.
> > When running v4l2-compliance on a proprietary driver, I get this error:
> >
> > ```
> > Input/Output configuration ioctls:
> > fail: v4l2-test-io-config.cpp(227): fmt.fmt.pix.width >=
> > enumtimings.timings.bt.width * 1.5
> > fail: v4l2-test-io-config.cpp(386): Timings check failed for input 0.
> > test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: FAIL
> > ```
> >
> > Which brings me here:
> > https://git.linuxtv.org/v4l-utils.git/tree/utils/v4l2-compliance/v4l2-test-io-config.cpp#n227
> >
> > ```
> > fail_on_test(fmt.fmt.pix.width < enumtimings.timings.bt.width);
> > fail_on_test(fmt.fmt.pix.width >= enumtimings.timings.bt.width * 1.5);
> > fail_on_test(fmt.fmt.pix.height * factor < enumtimings.timings.bt.height);
> > fail_on_test(fmt.fmt.pix.height * factor >=
> > enumtimings.timings.bt.height * 1.5);
> > ```
> >
> > The problem is that the driver supports VIDIOC_S_DV_TIMINGS but is not
> > able to apply the specific format just returns the actual timings.
> > This is from what I know, not a violation, so I'm not sure what the
> > driver should return if it is not able to set a custom timing. Or is
> > this check just a bit too strict?
>
> This test enumerates all timings returned by VIDIOC_ENUM_DV_TIMINGS.
> All these timings should be valid supported timings. For each returned
> timing it calls S_DV_TIMINGS to set it. Then it call G_DV_TIMINGS to
> verify that the width and height of the new timings match what was
> requested. Apparently that worked, otherwise the test would have
> failed there.

Yes, indeed that part is ok.

> Next it gets the new format (G_FMT). The driver must update the format
> when the timings are updated. In this case the width of the returned
> format is more than 1.5 times the width of the requested timings.
> That doesn't sound right.

I found that G_FMT returns 16x16 (not sure where that is done), but
DV_TIMINGS was 0x0.
So fail_on_test(fmt.fmt.pix.width >= enumtimings.timings.bt.width *
1.5) triggered.

> Your claim that S_DV_TIMINGS can't set the new timings is dubious
> since G_DV_TIMINGS apparently returns the new timings correctly.
> Also, ENUM_DV_TIMINGS shouldn't return unsupported timings either.
>

I meant hardware-wise with not supported, but S_DV_TIMINGS itself is
indeed supported.

> >
> >
> > 2.
> > For another driver, I get this error:
> >
> > ```
> > Input ioctls:
> > fail: v4l2-test-input-output.cpp(443): use of deprecated digital video status
> > fail: v4l2-test-input-output.cpp(496): invalid attributes for input 0
> > test VIDIOC_G/S/ENUMINPUT: FAIL
> > ```
> >
> > It might be true that setting V4L2_IN_ST_NO_CARRIER is deprecated, but
> > is that really an error, not better to just have it as a warning?
> > After all, how can userspace know specific details if needed? Perhaps
> > checking that V4L2_IN_ST_NO_SIGNAL has also been set is enough, and if
> > V4L2_IN_ST_NO_CARRIER is set, but not V4L2_IN_ST_NO_SIGNAL, then it
> > might be an error.
>
> The NO_CARRIER, NO_EQU and NO_ACCESS status flags are DVB specific, but this
> ioctl isn't used by DVB anymore. I think very old drivers in the past (long
> since removed or changed) used this, but new drivers must not use this since
> it makes no sense. Note that v4l2-compliance is often more strict than the
> V4L2 spec itself: it is meant to ensure that drivers follow best practices.

I changed V4L2_IN_ST_NO_CARRIER to V4L2_IN_ST_NO_POWER which is fine enough.

> Note that the error message is not very good: it should say "digital TV"
> rather than "digital video". I'll fix that since that's confusing.
>
> Regards,
>
>         Hans
>
> >
> > Thx in advance!
> >
> > Kr,
> >
> > Thomas Devoogdt
> >
>
>

Re:

[Laurent Pinchart]

Hello Jules,

(CC'ing the linux-media mailing list, as discussions about the driver
should happen there, in public)

On Sun, Oct 22, 2023 at 05:46:59PM +0100, Jules Irenge wrote:
> Hi 
> I have some time I would like to volunteer contributing to the omap4iss.
> If it's fine with you, would you give me more info about it

The driver has most likely bit-rotten over the last few years, as to my
knowledge nobody has really tested it recently. The first step would
thus be to try to capture images and see how it behaves (or doesn't
behave).

What hardware will you use for testing ?

-- 
Regards,

Laurent Pinchart

Re:

[Jules Irenge]

On Sun, Oct 22, 2023 at 11:22:53PM +0300, Laurent Pinchart wrote:
Hi Laurent,

Thanks for replying.

> The driver has most likely bit-rotten over the last few years, as to my
> knowledge nobody has really tested it recently. The first step would
> thus be to try to capture images and see how it behaves (or doesn't
> behave).

This looks like an opportunity for me.  

> What hardware will you use for testing ?

About that, I have my PC and a rasberry pi. Would you have an advise on which device  I can best use to test ?

If I have to purchase, I can do that as this is just for my learning and contribution purpose.

Thanks,
Jules

Re:

[Laurent Pinchart]

Hello Jules,

On Mon, Oct 23, 2023 at 01:04:37PM +0100, Jules Irenge wrote:
> On Sun, Oct 22, 2023 at 11:22:53PM +0300, Laurent Pinchart wrote:
> Hi Laurent,
> 
> Thanks for replying.
> 
> > The driver has most likely bit-rotten over the last few years, as to my
> > knowledge nobody has really tested it recently. The first step would
> > thus be to try to capture images and see how it behaves (or doesn't
> > behave).
> 
> This looks like an opportunity for me.  
> 
> > What hardware will you use for testing ?
> 
> About that, I have my PC and a rasberry pi. Would you have an advise
> on which device  I can best use to test ?

You will need a development board with an OMAP4 SoC, and a compatible
camera module. I've used the PandaBoard ([1]) personally back when I
worked on the driver, but I don't recall what camera module I was using.
Looking at ancient git branches, it may have been based on an AR0330,
possibly using a module from Leopard Imaging. This was nearly 10 years
ago though, sourcing the hardware may be fairly difficult.

[1] https://www.digikey.fi/en/product-highlight/t/texas-instruments/pandaboard

> If I have to purchase, I can do that as this is just for my learning
> and contribution purpose.

-- 
Regards,

Laurent Pinchart

[PATCH v5 00/11] Add support for X86/ACPI camera sensor/PMIC setup with clk and regulator platform data

[Hans de Goede]

Here is v5 of my patch-set adding support for camera sensor connected to a
TPS68470 PMIC on x86/ACPI devices.

Changes in v5:
- Update regulator_init_data in patch 10/11 to include the VCM regulator
- Address various small review remarks from Andy
- Make a couple of functions / vars static in the clk + regulator drivers
  Reported-by: kernel test robot <lkp@intel.com>

Changes in v4:
[PATCH 01/11] ACPI: delay enumeration of devices with a _DEP
              pointing to an INT3472 device:
- Move the acpi_dev_ready_for_enumeration() check to acpi_bus_attach()
  (replacing the acpi_device_is_present() check there)

[PATCH 04/11] regulator: Introduce tps68470-regulator driver:
- Make the top comment block use c++ style comments
- Drop the bogus builtin regulator_init_data
- Make the driver enable the PMIC clk when enabling the Core buck
  regulator, this switching regulator needs the PLL to be on
- Kconfig: add || COMPILE_TEST, fix help text

[PATCH 05/11] clk: Introduce clk-tps68470 driver
- Kconfig: select REGMAP_I2C, add || COMPILE_TEST, fix help text
- tps68470_clk_prepare(): Wait for the PLL to lock before returning
- tps68470_clk_unprepare(): Remove unnecesary clearing of divider regs
- tps68470_clk_probe(): Use devm_clk_hw_register()
- Misc. small cleanups

I'm quite happy with how this works now, so from my pov this is the final
version of the device-instantiation deferral code / approach.

###

The clk and regulator frameworks expect clk/regulator consumer-devices
to have info about the consumed clks/regulators described in the device's
fw_node, but on ACPI this info is missing.

This series worksaround this by providing platform_data with the info to
the TPS68470 clk/regulator MFD cells.

Patches 1 - 2 deal with a probe-ordering problem this introduces,
since the lookups are only registered when the provider-driver binds,
trying to get these clks/regulators before then results in a -ENOENT
error for clks and a dummy regulator for regulators. See the patches
for more details.

Patch 3 adds a header file which adds tps68470_clk_platform_data and
tps68470_regulator_platform_data structs. The futher patches depend on
this new header file.

Patch 4 + 5 add the TPS68470 clk and regulator drivers

Patches 6 - 11 Modify the INT3472 driver which instantiates the MFD cells to
provide the necessary platform-data.

Assuming this series is acceptable to everyone, we need to talk about how
to merge this.

Patch 2 has already been acked by Wolfram for merging by Rafael, so patch
1 + 2 can be merged into linux-pm, independent of the rest of the series
(there are some runtime deps on other changes for everything to work,
but the camera-sensors impacted by this are not fully supported yet in
the mainline kernel anyways).

For "[PATCH 03/13] platform_data: Add linux/platform_data/tps68470.h file",
which all further patches depend on I plan to provide an immutable branch
myself (once it has been reviewed), which the clk / regulator maintainers
can then merge before merging the clk / regulator driver which depends on
this.

And I will merge that IM-branch + patches 6-11 into the pdx86 tree myself.

Regards,

Hans


Daniel Scally (1):
  platform/x86: int3472: Enable I2c daisy chain

Hans de Goede (10):
  ACPI: delay enumeration of devices with a _DEP pointing to an INT3472
    device
  i2c: acpi: Use acpi_dev_ready_for_enumeration() helper
  platform_data: Add linux/platform_data/tps68470.h file
  regulator: Introduce tps68470-regulator driver
  clk: Introduce clk-tps68470 driver
  platform/x86: int3472: Split into 2 drivers
  platform/x86: int3472: Add get_sensor_adev_and_name() helper
  platform/x86: int3472: Pass tps68470_clk_platform_data to the
    tps68470-regulator MFD-cell
  platform/x86: int3472: Pass tps68470_regulator_platform_data to the
    tps68470-regulator MFD-cell
  platform/x86: int3472: Deal with probe ordering issues

 drivers/acpi/scan.c                           |  37 ++-
 drivers/clk/Kconfig                           |   8 +
 drivers/clk/Makefile                          |   1 +
 drivers/clk/clk-tps68470.c                    | 257 ++++++++++++++++++
 drivers/i2c/i2c-core-acpi.c                   |   5 +-
 drivers/platform/x86/intel/int3472/Makefile   |   9 +-
 ...lk_and_regulator.c => clk_and_regulator.c} |   2 +-
 drivers/platform/x86/intel/int3472/common.c   |  82 ++++++
 .../{intel_skl_int3472_common.h => common.h}  |   6 +-
 ...ntel_skl_int3472_discrete.c => discrete.c} |  51 ++--
 .../intel/int3472/intel_skl_int3472_common.c  | 106 --------
 ...ntel_skl_int3472_tps68470.c => tps68470.c} |  99 ++++++-
 drivers/platform/x86/intel/int3472/tps68470.h |  25 ++
 .../x86/intel/int3472/tps68470_board_data.c   | 134 +++++++++
 drivers/regulator/Kconfig                     |   9 +
 drivers/regulator/Makefile                    |   1 +
 drivers/regulator/tps68470-regulator.c        | 212 +++++++++++++++
 include/acpi/acpi_bus.h                       |   5 +-
 include/linux/mfd/tps68470.h                  |  11 +
 include/linux/platform_data/tps68470.h        |  35 +++
 20 files changed, 944 insertions(+), 151 deletions(-)
 create mode 100644 drivers/clk/clk-tps68470.c
 rename drivers/platform/x86/intel/int3472/{intel_skl_int3472_clk_and_regulator.c => clk_and_regulator.c} (99%)
 create mode 100644 drivers/platform/x86/intel/int3472/common.c
 rename drivers/platform/x86/intel/int3472/{intel_skl_int3472_common.h => common.h} (94%)
 rename drivers/platform/x86/intel/int3472/{intel_skl_int3472_discrete.c => discrete.c} (91%)
 delete mode 100644 drivers/platform/x86/intel/int3472/intel_skl_int3472_common.c
 rename drivers/platform/x86/intel/int3472/{intel_skl_int3472_tps68470.c => tps68470.c} (54%)
 create mode 100644 drivers/platform/x86/intel/int3472/tps68470.h
 create mode 100644 drivers/platform/x86/intel/int3472/tps68470_board_data.c
 create mode 100644 drivers/regulator/tps68470-regulator.c
 create mode 100644 include/linux/platform_data/tps68470.h

-- 
2.31.1

[PATCH v5 05/11] clk: Introduce clk-tps68470 driver

[Hans de Goede]

The TPS68470 PMIC provides Clocks, GPIOs and Regulators. At present in
the kernel the Regulators and Clocks are controlled by an OpRegion
driver designed to work with power control methods defined in ACPI, but
some platforms lack those methods, meaning drivers need to be able to
consume the resources of these chips through the usual frameworks.

This commit adds a driver for the clocks provided by the tps68470,
and is designed to bind to the platform_device registered by the
intel_skl_int3472 module.

This is based on this out of tree driver written by Intel:
https://github.com/intel/linux-intel-lts/blob/4.14/base/drivers/clk/clk-tps68470.c
with various cleanups added.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
Changes in v5:
- Small comment cleanups based on review from Andy

Changes in v4:
- Kconfig: select REGMAP_I2C, add || COMPILE_TEST, fix help text
- tps68470_clk_prepare(): Wait for the PLL to lock before returning
- tps68470_clk_unprepare(): Remove unnecesary clearing of divider regs
- tps68470_clk_probe(): Use devm_clk_hw_register()
- Misc. small cleanups

Changes in v2:
- Update the comment on why a subsys_initcall is used to register the drv
- Fix trailing whitespice on line 100
---
 drivers/clk/Kconfig          |   8 ++
 drivers/clk/Makefile         |   1 +
 drivers/clk/clk-tps68470.c   | 257 +++++++++++++++++++++++++++++++++++
 include/linux/mfd/tps68470.h |  11 ++
 4 files changed, 277 insertions(+)
 create mode 100644 drivers/clk/clk-tps68470.c

diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index c5b3dc97396a..4e9098d79249 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -169,6 +169,14 @@ config COMMON_CLK_CDCE706
 	help
 	  This driver supports TI CDCE706 programmable 3-PLL clock synthesizer.
 
+config COMMON_CLK_TPS68470
+	tristate "Clock Driver for TI TPS68470 PMIC"
+	depends on I2C
+	depends on INTEL_SKL_INT3472 || COMPILE_TEST
+	select REGMAP_I2C
+	help
+	  This driver supports the clocks provided by the TPS68470 PMIC.
+
 config COMMON_CLK_CDCE925
 	tristate "Clock driver for TI CDCE913/925/937/949 devices"
 	depends on I2C
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index e42312121e51..6b6a88ae1425 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -63,6 +63,7 @@ obj-$(CONFIG_COMMON_CLK_SI570)		+= clk-si570.o
 obj-$(CONFIG_COMMON_CLK_STM32F)		+= clk-stm32f4.o
 obj-$(CONFIG_COMMON_CLK_STM32H7)	+= clk-stm32h7.o
 obj-$(CONFIG_COMMON_CLK_STM32MP157)	+= clk-stm32mp1.o
+obj-$(CONFIG_COMMON_CLK_TPS68470)      += clk-tps68470.o
 obj-$(CONFIG_CLK_TWL6040)		+= clk-twl6040.o
 obj-$(CONFIG_ARCH_VT8500)		+= clk-vt8500.o
 obj-$(CONFIG_COMMON_CLK_VC5)		+= clk-versaclock5.o
diff --git a/drivers/clk/clk-tps68470.c b/drivers/clk/clk-tps68470.c
new file mode 100644
index 000000000000..2ad0ac2f4096
--- /dev/null
+++ b/drivers/clk/clk-tps68470.c
@@ -0,0 +1,257 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Clock driver for TPS68470 PMIC
+ *
+ * Copyright (c) 2021 Red Hat Inc.
+ * Copyright (C) 2018 Intel Corporation
+ *
+ * Authors:
+ *	Hans de Goede <hdegoede@redhat.com>
+ *	Zaikuo Wang <zaikuo.wang@intel.com>
+ *	Tianshu Qiu <tian.shu.qiu@intel.com>
+ *	Jian Xu Zheng <jian.xu.zheng@intel.com>
+ *	Yuning Pu <yuning.pu@intel.com>
+ *	Antti Laakso <antti.laakso@intel.com>
+ */
+
+#include <linux/clk-provider.h>
+#include <linux/clkdev.h>
+#include <linux/kernel.h>
+#include <linux/mfd/tps68470.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/platform_data/tps68470.h>
+#include <linux/regmap.h>
+
+#define TPS68470_CLK_NAME "tps68470-clk"
+
+#define to_tps68470_clkdata(clkd) \
+	container_of(clkd, struct tps68470_clkdata, clkout_hw)
+
+static struct tps68470_clkout_freqs {
+	unsigned long freq;
+	unsigned int xtaldiv;
+	unsigned int plldiv;
+	unsigned int postdiv;
+	unsigned int buckdiv;
+	unsigned int boostdiv;
+} clk_freqs[] = {
+/*
+ *  The PLL is used to multiply the crystal oscillator
+ *  frequency range of 3 MHz to 27 MHz by a programmable
+ *  factor of F = (M/N)*(1/P) such that the output
+ *  available at the HCLK_A or HCLK_B pins are in the range
+ *  of 4 MHz to 64 MHz in increments of 0.1 MHz.
+ *
+ * hclk_# = osc_in * (((plldiv*2)+320) / (xtaldiv+30)) * (1 / 2^postdiv)
+ *
+ * PLL_REF_CLK should be as close as possible to 100kHz
+ * PLL_REF_CLK = input clk / XTALDIV[7:0] + 30)
+ *
+ * PLL_VCO_CLK = (PLL_REF_CLK * (plldiv*2 + 320))
+ *
+ * BOOST should be as close as possible to 2Mhz
+ * BOOST = PLL_VCO_CLK / (BOOSTDIV[4:0] + 16) *
+ *
+ * BUCK should be as close as possible to 5.2Mhz
+ * BUCK = PLL_VCO_CLK / (BUCKDIV[3:0] + 5)
+ *
+ * osc_in   xtaldiv  plldiv   postdiv   hclk_#
+ * 20Mhz    170      32       1         19.2Mhz
+ * 20Mhz    170      40       1         20Mhz
+ * 20Mhz    170      80       1         24Mhz
+ */
+	{ 19200000, 170, 32, 1, 2, 3 },
+	{ 20000000, 170, 40, 1, 3, 4 },
+	{ 24000000, 170, 80, 1, 4, 8 },
+};
+
+struct tps68470_clkdata {
+	struct clk_hw clkout_hw;
+	struct regmap *regmap;
+	unsigned int clk_cfg_idx;
+};
+
+static int tps68470_clk_is_prepared(struct clk_hw *hw)
+{
+	struct tps68470_clkdata *clkdata = to_tps68470_clkdata(hw);
+	int val;
+
+	if (regmap_read(clkdata->regmap, TPS68470_REG_PLLCTL, &val))
+		return 0;
+
+	return val & TPS68470_PLL_EN_MASK;
+}
+
+static int tps68470_clk_prepare(struct clk_hw *hw)
+{
+	struct tps68470_clkdata *clkdata = to_tps68470_clkdata(hw);
+	unsigned int idx = clkdata->clk_cfg_idx;
+
+	regmap_write(clkdata->regmap, TPS68470_REG_BOOSTDIV, clk_freqs[idx].boostdiv);
+	regmap_write(clkdata->regmap, TPS68470_REG_BUCKDIV, clk_freqs[idx].buckdiv);
+	regmap_write(clkdata->regmap, TPS68470_REG_PLLSWR, TPS68470_PLLSWR_DEFAULT);
+	regmap_write(clkdata->regmap, TPS68470_REG_XTALDIV, clk_freqs[idx].xtaldiv);
+	regmap_write(clkdata->regmap, TPS68470_REG_PLLDIV, clk_freqs[idx].plldiv);
+	regmap_write(clkdata->regmap, TPS68470_REG_POSTDIV, clk_freqs[idx].postdiv);
+	regmap_write(clkdata->regmap, TPS68470_REG_POSTDIV2, clk_freqs[idx].postdiv);
+	regmap_write(clkdata->regmap, TPS68470_REG_CLKCFG2, TPS68470_CLKCFG2_DRV_STR_2MA);
+
+	regmap_write(clkdata->regmap, TPS68470_REG_PLLCTL,
+		     TPS68470_OSC_EXT_CAP_DEFAULT << TPS68470_OSC_EXT_CAP_SHIFT |
+		     TPS68470_CLK_SRC_XTAL << TPS68470_CLK_SRC_SHIFT);
+
+	regmap_write(clkdata->regmap, TPS68470_REG_CLKCFG1,
+			   (TPS68470_PLL_OUTPUT_ENABLE << TPS68470_OUTPUT_A_SHIFT) |
+			   (TPS68470_PLL_OUTPUT_ENABLE << TPS68470_OUTPUT_B_SHIFT));
+
+	regmap_update_bits(clkdata->regmap, TPS68470_REG_PLLCTL,
+			   TPS68470_PLL_EN_MASK, TPS68470_PLL_EN_MASK);
+
+	/*
+	 * The PLLCTL reg lock bit is set by the PMIC after approx. 4ms and
+	 * does not indicate a true lock, so just wait 4 ms.
+	 */
+	usleep_range(4000, 5000);
+
+	return 0;
+}
+
+static void tps68470_clk_unprepare(struct clk_hw *hw)
+{
+	struct tps68470_clkdata *clkdata = to_tps68470_clkdata(hw);
+
+	/* Disable clock first ... */
+	regmap_update_bits(clkdata->regmap, TPS68470_REG_PLLCTL, TPS68470_PLL_EN_MASK, 0);
+
+	/* ... and then tri-state the clock outputs. */
+	regmap_write(clkdata->regmap, TPS68470_REG_CLKCFG1, 0);
+}
+
+static unsigned long tps68470_clk_recalc_rate(struct clk_hw *hw, unsigned long parent_rate)
+{
+	struct tps68470_clkdata *clkdata = to_tps68470_clkdata(hw);
+
+	return clk_freqs[clkdata->clk_cfg_idx].freq;
+}
+
+/*
+ * This returns the index of the clk_freqs[] cfg with the closest rate for
+ * use in tps68470_clk_round_rate(). tps68470_clk_set_rate() checks that
+ * the rate of the returned cfg is an exact match.
+ */
+static unsigned int tps68470_clk_cfg_lookup(unsigned long rate)
+{
+	long diff, best_diff = LONG_MAX;
+	unsigned int i, best_idx = 0;
+
+	for (i = 0; i < ARRAY_SIZE(clk_freqs); i++) {
+		diff = clk_freqs[i].freq - rate;
+		if (diff == 0)
+			return i;
+
+		diff = abs(diff);
+		if (diff < best_diff) {
+			best_diff = diff;
+			best_idx = i;
+		}
+	}
+
+	return best_idx;
+}
+
+static long tps68470_clk_round_rate(struct clk_hw *hw, unsigned long rate,
+				    unsigned long *parent_rate)
+{
+	unsigned int idx = tps68470_clk_cfg_lookup(rate);
+
+	return clk_freqs[idx].freq;
+}
+
+static int tps68470_clk_set_rate(struct clk_hw *hw, unsigned long rate,
+				 unsigned long parent_rate)
+{
+	struct tps68470_clkdata *clkdata = to_tps68470_clkdata(hw);
+	unsigned int idx = tps68470_clk_cfg_lookup(rate);
+
+	if (rate != clk_freqs[idx].freq)
+		return -EINVAL;
+
+	clkdata->clk_cfg_idx = idx;
+
+	return 0;
+}
+
+static const struct clk_ops tps68470_clk_ops = {
+	.is_prepared = tps68470_clk_is_prepared,
+	.prepare = tps68470_clk_prepare,
+	.unprepare = tps68470_clk_unprepare,
+	.recalc_rate = tps68470_clk_recalc_rate,
+	.round_rate = tps68470_clk_round_rate,
+	.set_rate = tps68470_clk_set_rate,
+};
+
+static const struct clk_init_data tps68470_clk_initdata = {
+	.name = TPS68470_CLK_NAME,
+	.ops = &tps68470_clk_ops,
+};
+
+static int tps68470_clk_probe(struct platform_device *pdev)
+{
+	struct tps68470_clk_platform_data *pdata = pdev->dev.platform_data;
+	struct tps68470_clkdata *tps68470_clkdata;
+	int ret;
+
+	tps68470_clkdata = devm_kzalloc(&pdev->dev, sizeof(*tps68470_clkdata),
+					GFP_KERNEL);
+	if (!tps68470_clkdata)
+		return -ENOMEM;
+
+	tps68470_clkdata->regmap = dev_get_drvdata(pdev->dev.parent);
+	tps68470_clkdata->clkout_hw.init = &tps68470_clk_initdata;
+	ret = devm_clk_hw_register(&pdev->dev, &tps68470_clkdata->clkout_hw);
+	if (ret)
+		return ret;
+
+	ret = devm_clk_hw_register_clkdev(&pdev->dev, &tps68470_clkdata->clkout_hw,
+					  TPS68470_CLK_NAME, NULL);
+	if (ret)
+		return ret;
+
+	if (pdata) {
+		ret = devm_clk_hw_register_clkdev(&pdev->dev,
+						  &tps68470_clkdata->clkout_hw,
+						  pdata->consumer_con_id,
+						  pdata->consumer_dev_name);
+	}
+
+	return ret;
+}
+
+static struct platform_driver tps68470_clk_driver = {
+	.driver = {
+		.name = TPS68470_CLK_NAME,
+	},
+	.probe = tps68470_clk_probe,
+};
+
+/*
+ * The ACPI tps68470 probe-ordering depends on the clk/gpio/regulator drivers
+ * registering before the drivers for the camera-sensors which use them bind.
+ * subsys_initcall() ensures this when the drivers are builtin.
+ */
+static int __init tps68470_clk_init(void)
+{
+	return platform_driver_register(&tps68470_clk_driver);
+}
+subsys_initcall(tps68470_clk_init);
+
+static void __exit tps68470_clk_exit(void)
+{
+	platform_driver_unregister(&tps68470_clk_driver);
+}
+module_exit(tps68470_clk_exit);
+
+MODULE_ALIAS("platform:tps68470-clk");
+MODULE_DESCRIPTION("clock driver for TPS68470 pmic");
+MODULE_LICENSE("GPL");
diff --git a/include/linux/mfd/tps68470.h b/include/linux/mfd/tps68470.h
index ffe81127d91c..7807fa329db0 100644
--- a/include/linux/mfd/tps68470.h
+++ b/include/linux/mfd/tps68470.h
@@ -75,6 +75,17 @@
 #define TPS68470_CLKCFG1_MODE_A_MASK	GENMASK(1, 0)
 #define TPS68470_CLKCFG1_MODE_B_MASK	GENMASK(3, 2)
 
+#define TPS68470_CLKCFG2_DRV_STR_2MA	0x05
+#define TPS68470_PLL_OUTPUT_ENABLE	0x02
+#define TPS68470_CLK_SRC_XTAL		BIT(0)
+#define TPS68470_PLLSWR_DEFAULT		GENMASK(1, 0)
+#define TPS68470_OSC_EXT_CAP_DEFAULT	0x05
+
+#define TPS68470_OUTPUT_A_SHIFT		0x00
+#define TPS68470_OUTPUT_B_SHIFT		0x02
+#define TPS68470_CLK_SRC_SHIFT		GENMASK(2, 0)
+#define TPS68470_OSC_EXT_CAP_SHIFT	BIT(2)
+
 #define TPS68470_GPIO_CTL_REG_A(x)	(TPS68470_REG_GPCTL0A + (x) * 2)
 #define TPS68470_GPIO_CTL_REG_B(x)	(TPS68470_REG_GPCTL0B + (x) * 2)
 #define TPS68470_GPIO_MODE_MASK		GENMASK(1, 0)
-- 
2.31.1

Re:

[Hans de Goede]

Hi,

On 11/2/21 22:16, Stephen Boyd wrote:
> Quoting Hans de Goede (2021-11-02 02:49:01)
>> diff --git a/drivers/clk/clk-tps68470.c b/drivers/clk/clk-tps68470.c
>> new file mode 100644
>> index 000000000000..2ad0ac2f4096
>> --- /dev/null
>> +++ b/drivers/clk/clk-tps68470.c
>> @@ -0,0 +1,257 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Clock driver for TPS68470 PMIC
>> + *
>> + * Copyright (c) 2021 Red Hat Inc.
>> + * Copyright (C) 2018 Intel Corporation
>> + *
>> + * Authors:
>> + *     Hans de Goede <hdegoede@redhat.com>
>> + *     Zaikuo Wang <zaikuo.wang@intel.com>
>> + *     Tianshu Qiu <tian.shu.qiu@intel.com>
>> + *     Jian Xu Zheng <jian.xu.zheng@intel.com>
>> + *     Yuning Pu <yuning.pu@intel.com>
>> + *     Antti Laakso <antti.laakso@intel.com>
>> + */
>> +
>> +#include <linux/clk-provider.h>
>> +#include <linux/clkdev.h>
>> +#include <linux/kernel.h>
>> +#include <linux/mfd/tps68470.h>
>> +#include <linux/module.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/platform_data/tps68470.h>
>> +#include <linux/regmap.h>
>> +
>> +#define TPS68470_CLK_NAME "tps68470-clk"
>> +
>> +#define to_tps68470_clkdata(clkd) \
>> +       container_of(clkd, struct tps68470_clkdata, clkout_hw)
>> +
> [...]
>> +
>> +static int tps68470_clk_set_rate(struct clk_hw *hw, unsigned long rate,
>> +                                unsigned long parent_rate)
>> +{
>> +       struct tps68470_clkdata *clkdata = to_tps68470_clkdata(hw);
>> +       unsigned int idx = tps68470_clk_cfg_lookup(rate);
>> +
>> +       if (rate != clk_freqs[idx].freq)
>> +               return -EINVAL;
>> +
>> +       clkdata->clk_cfg_idx = idx;
> 
> It deserves a comment that set_rate can only be called when the clk is
> gated. We have CLK_SET_RATE_GATE flag as well that should be set if the
> clk can't support changing rate while enabled. With that flag set, this
> function should be able to actually change hardware with the assumption
> that the framework won't call down into this clk_op when the clk is
> enabled.

Ok for v6 I've added the CLK_SET_RATE_GATE flag + a comment why
it used and moved the divider programming to tps68470_clk_set_rate()m
while keeping the PLL_EN + output-enable writes in tps68470_clk_prepare()


> 
>> +
>> +       return 0;
>> +}
>> +
>> +static const struct clk_ops tps68470_clk_ops = {
>> +       .is_prepared = tps68470_clk_is_prepared,
>> +       .prepare = tps68470_clk_prepare,
>> +       .unprepare = tps68470_clk_unprepare,
>> +       .recalc_rate = tps68470_clk_recalc_rate,
>> +       .round_rate = tps68470_clk_round_rate,
>> +       .set_rate = tps68470_clk_set_rate,
>> +};
>> +
>> +static const struct clk_init_data tps68470_clk_initdata = {
> 
> Is there a reason to make this a static global? It's probably better to
> throw it on the stack so that a structure isn't sitting around after
> driver probe being unused.

Fixed for v6.

Thanks & Regards,

Hans


> 
>> +       .name = TPS68470_CLK_NAME,
>> +       .ops = &tps68470_clk_ops,
>> +};
> 

(no subject)

[David Villasana Jiménez]

linux-kernel@vger.kernel.org, outreachy-kernel@googlegroups.com
Bcc: 
Subject: [PATCH] staging: media: atomisp: i2c: Fix alignment to match open
 parenthesis
Reply-To: 

Change alignment of arguments in the function
__gc0310_write_reg_is_consecutive() to match open parenthesis. Issue found
by checkpatch.pl

Signed-off-by: David Villasana Jiménez <davidvillasana14@gmail.com>
---
 drivers/staging/media/atomisp/i2c/atomisp-gc0310.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/media/atomisp/i2c/atomisp-gc0310.c b/drivers/staging/media/atomisp/i2c/atomisp-gc0310.c
index 2b71de722ec3..6be3ee1d93a5 100644
--- a/drivers/staging/media/atomisp/i2c/atomisp-gc0310.c
+++ b/drivers/staging/media/atomisp/i2c/atomisp-gc0310.c
@@ -192,8 +192,8 @@ static int __gc0310_buf_reg_array(struct i2c_client *client,
 }
 
 static int __gc0310_write_reg_is_consecutive(struct i2c_client *client,
-	struct gc0310_write_ctrl *ctrl,
-	const struct gc0310_reg *next)
+					     struct gc0310_write_ctrl *ctrl,
+					     const struct gc0310_reg *next)
 {
 	if (ctrl->index == 0)
 		return 1;
-- 
2.30.2

Re:

[Greg KH]

On Mon, Apr 05, 2021 at 04:12:48PM -0500, David Villasana Jiménez wrote:
> linux-kernel@vger.kernel.org, outreachy-kernel@googlegroups.com
> Bcc: 
> Subject: [PATCH] staging: media: atomisp: i2c: Fix alignment to match open
>  parenthesis
> Reply-To: 

Something went wrong with your email again :(

RE,

[Miss Sharifah Ahmad Mustahfa]

Hello,

First of all i will like to apologies for my manner of communication because you do not know me personally, its due to the fact that i have a very important proposal for you.

Re:

[Amos Kalonzo]

Attn:

I am wondering why You haven't respond to my email for some days now.
reference to my client's contract balance payment of (11.7M,USD)
Kindly get back to me for more details.

Best Regards

Amos Kalonzo

RE:

[Qin's Yanjun]

How are you today and your family? I require your attention and honest
co-operation about some issues which i will really want to discuss with you
which.  Looking forward to read from you soon.  

Qin's


______________________________

Sky Silk, http://aknet.kz

Re:

[christain147]

Good day,hoping you read this email and respond to me in good time.I do not intend to solicit for funds but  your time and energy in using my own resources to assist the less privileged.I am medically confined at the moment hence I request your indulgence.
I will give you a comprehensive brief once I hear from you.

Please forward your response to my private email address:
gudworks104@yahoo.com

Thanks and reply.

Robert Grondahl

Re:

[kontakt]

Teraz mozesz uzyskac kredyt w wysokosci 2% za uniewaznic i dostac do 40 lat lub wiecej, aby splacic. Nie naleza do kredytów krótkoterminowych, które sprawiaja, ze zwróci sie w kilka tygodni lub miesiecy. Nasza oferta obejmuje; * Refinansowanie * Home Improvement * Kredyty samochodowe * Konsolidacja zadluzenia * Linia kredytowa * Druga hipoteczny * Biznes Pozyczki * Pozyczki Personal

  Zdobadz pieniadze potrzebne dzis z duza iloscia czasu, aby dokonac platnosci powrotem. Aby zastosowac, aby wyslac wszystkie pytania lub zaproszenia fwfshelpdesk@gmail.com: + 1- 435-241-5945

************************************************************
Now you can get a loan at 2% per annul and get up to 40 years or more to pay it back. Don't fall for the short term loans that make you pay back in weeks or months. Our offer include; *Refinance *Home Improvement *Auto Loans *Debt Consolidation*Line of Credit *Second Mortgage *Business Loans*Personal Loans

 Get the money you need today with plenty of time to make the payments back. To apply, send all inquiries to fwfshelpdesk@gmail.com or call : + 1- 435-241-5945

---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

Re:

[Neslihanp]

-- 
Do you received our last email.

(no subject)

[TAN WONG]

I am Mr. Tan Wong,I have a business to inform you about, it involve the transfer of funds ($24,500,000,00) contact (tan.wong222@yahoo.com.hk) with your full names.

Mr. Tan Wong

Re:

[Jens Bauer]

FYI: This "Tain Wong" has been shut down and will not spam us again.


Love
Jens

On Mon, 22 Oct 2012 05:55:20 +0900, TAN WONG wrote:
> 
> I am Mr. Tan Wong,I have a business to inform you about, it involve 
> the transfer of funds ($24,500,000,00) contact 
> (tan.wong222@yahoo.com.hk) with your full names.
> 
> Mr. Tan Wong
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

re:

[Sril]

wow this is crazy check it out http://t.co/wHIQrrcm 



~*Advertisement

re:

[MOHAMMAD IZADI]

please look in to this http://www.nbnews15.net/biz/?read=9539925

Re:

[relinter]

Usted gano setecientos cincuenta mil libras Sterling. Enviar nombres,  
edad, ocupacion, Pais.

Re:

[Irish Lotto]

You won £750,000 GBP. Send Name, Age, occupation, Country.

Re: Re:.

[Meftah Tayeb]

Need moderation.

----- Original Message ----- 
From: "Franklin Meng" <fmeng2002@yahoo.com>
To: <william88tu@hotmail.com>; <scmy80@yahoo.com.sg>; <arbsfruit@aol.com>; 
<kenshiro@dotplanet.com>; <schien61@yahoo.com>; 
<tony.brinneman@wellsfargo.com>; <linux-media@vger.kernel.org>
Sent: Wednesday, January 25, 2012 5:07 PM
Subject: Re:.


>
> OMG! Don’t wait any second! Click this 
> link!http://masfgrafica.com.ar/go.php?kID=41m4
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
> __________ Information from ESET NOD32 Antivirus, version of virus 
> signature database 6826 (20120125) __________
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
> 


__________ Information from ESET NOD32 Antivirus, version of virus signature database 6826 (20120125) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

(no subject)

[asheeshb]

The patches will be applied to the davinci tree the ../drivers/media/video/davinci and will affect the both the capture and display drivers. Apply these patches to the git kernel.
>From asheeshb@ti.com # This line is ignored.
GIT:
From: asheeshb@ti.com
Subject: 
In-Reply-To: 

RE:

[Karicheri, Muralidharan]

Asheesh,

Please re-send this patch with following:-

1) A detailed description of what you are trying to fix in each of this patch. You need to also run the checkpatch.pl script to make sure there are no errors.
2) Please make this patch based on the http://git.linuxtv.org/v4l-dvb.git master branch. I am assuming you have based it upon the Arago tree.
3) add the Signed-off-by field.

Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-karicheri2@ti.com

>-----Original Message-----
>From: linux-media-owner@vger.kernel.org [mailto:linux-media-
>owner@vger.kernel.org] On Behalf Of Bhardwaj, Asheesh
>Sent: Wednesday, May 19, 2010 12:45 PM
>To: linux-media@vger.kernel.org
>Subject:
>
>The patches will be applied to the davinci tree
>the ../drivers/media/video/davinci and will affect the both the capture and
>display drivers. Apply these patches to the git kernel.
>From asheeshb@ti.com # This line is ignored.
>GIT:
>From: asheeshb@ti.com
>Subject:
>In-Reply-To:
>
>--
>To unsubscribe from this list: send the line "unsubscribe linux-media" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re:

[Mr. Vincent Hong]

Dear Friend,
I have a business transaction which I need your assistant, your share will be
40%; please if you are interested do contact me for more details on my  
personal
email: hg.vincent33@gmail.com
Vincent Hong


Quoting sisenbarger@wcsd.k12.oh.us:

>

re:

[Ustin Gavrie]

--
I...HAVE...A...PROFILING...SUM...OF...$25MILLION....WHICH...I...SEEK...YOUR..
.PARTNERSHIP...IN...ACCOMMODATING...FOR...INVESTMENT..PURPOSE...YOU
...SHALL...BE...REWARDED...WITH...THIRTY...PERCENT....IF...INTERESTED...
PLEASE...REPLY...FOR...MORE...DETAILS.

RE:

[Irish News Center]

You won 750,000gbp.Send:Name,Age,Country

(no subject)

[Hasse Hagen Johansen]

subscribe linux-media

Re:

[Mauro Carvalho Chehab]

Em Mon, 26 Oct 2009 15:33:50 +0100
Hasse Hagen Johansen <hasse-linuxmedia@hagenjohansen.dk> escreveu:

> subscribe linux-media

You should send subscribe emails to majordomo@vger.kernel.org instead.

> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html




Cheers,
Mauro

Preliminary working HVR-1850 IR hardware and grey Hauppauge RC-5 remote

[Andy Walls]

Steve,

I've finally have a working implementation of the the HVR-1850 IR
receiver and the grey Hauppauge RC-5 remote with in kernel (non-LIRC) IR
input to key press events.

If you feel adventurous, give it a try for testing the IR receiver:

http://www.linuxtv.org/hg/~awalls/cx23888-ir


Caveat emptor:

1. I would not recommend reviewing the code by individual change sets.
The change sets become an evolutionary mess towards the end, as I would
find a few minutes here or there to add a few lines of code. :)  I will
provide a cleaned up version, most likely some time after the LPC.

2. I need to clean up of some dead/commented out code.

3. I need to port it forward to catch up with recent changes to the
cx25840 module, cx23885 module, and IR keytable changes.  (The code
compiles and works, but I started working from a v4l-dvb clone from a
few months ago. There have been a few changes in areas I have worked.)

4. It only works for CX23888 devices right now. CX23885 devices should
be easy enough to support after cleanup and initial merge of this code.

5. I specifically did not address the RC-6(A) remote.  With the
CX2388[58] hardware, it wouldn't be hard to handle the RC-6(A) remote,
but the v4l-dvb tree is missing lots of RC-6 definitions and helper
functions.  I figured I'd rather focus on a LIRC plug-in for a
v4l_device rather than reinvent RC-6(A) inside the v4l-dvb code.


Regards,
Andy

Re: Preliminary working HVR-1850 IR hardware and grey Hauppauge RC-5 remote

[Steven Toth]

On 9/19/09 10:20 PM, Andy Walls wrote:
> Steve,
>
> I've finally have a working implementation of the the HVR-1850 IR
> receiver and the grey Hauppauge RC-5 remote with in kernel (non-LIRC) IR
> input to key press events.
>
> If you feel adventurous, give it a try for testing the IR receiver:
>
> http://www.linuxtv.org/hg/~awalls/cx23888-ir

Very nice, excellent work. Sorry, my weekend was crazy so I never managed to 
test your tree, even though I saw your email. Today and tomorrow won't be much 
better as I'll be preparing to head out to LPC.

A couple of things on my mind currently:

1. I'd like to test this asap and give you some feedback. This is a very welcome 
addition to the cx23885/25840 driver codebase. In reality this could be a week 
or so.

2. Once you have your patch-sets in order I'd like to pull those patches and do 
some HVR1850 analog encoder work. I have some small patches pending that should 
immediately allow me to start testing various aspects of analog. (Unrelated to 
your IR work but highly related to the fact you're fixed up the clocks inside 
the 25840 nicely).

3. Getting RC5 IR support on the existing HVR1800/HVR1250 would be _really_ nice 
and from the sound of it an incremental step built on the current work. I think 
from memory you only have HVR1600 and HVR1850 Hauppauge boards. Is this correct? 
I want to bring a couple of 'samples' to LPC for you.... Assuming you're 
interested. Let me know as my luggage space will be tight.

4. I'm hoping we'll sample a beer or two in Portland ;)

Regards,

-- 
Steven Toth - Kernel Labs
http://www.kernellabs.com

(no subject)

[George Joseph]

Hello All,

 I am new to the list. I am currently working on a dm7025 platform and
would like to know if there is a possibillity to use the 128 pid filters
on the xilleon 226. currently I see only /dev/dvb/adaptor0/demux0-3 in my
device directory - i,e; at a point in time I can use only 4 tpid filters
from the 128 available at hardware level.


Cheers,
Warm regs,
G.

Re:

[Andreas Oberritter]

Hello George,

demux0-3 represent different TS inputs. You can open each demux device
multiple times. The 128 PID filters are shared between the four devices.

Regards,
Andreas

George Joseph wrote:
> Hello All,
> 
>  I am new to the list. I am currently working on a dm7025 platform and
> would like to know if there is a possibillity to use the 128 pid filters
> on the xilleon 226. currently I see only /dev/dvb/adaptor0/demux0-3 in my
> device directory - i,e; at a point in time I can use only 4 tpid filters
> from the 128 available at hardware level.
> 
> 
> Cheers,
> Warm regs,
> G.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re:

[George Joseph]

Thanks Andreas, That answers my question. I am using a tree I checkd out 3
months ago. I used the DEMUX_SET_SOURCE API to set the ts feed to the
tuner. Is this explicity done on Linux DVB 3?

Thanks,
Warm regs,
George.


> Hello George,
>
> demux0-3 represent different TS inputs. You can open each demux device
> multiple times. The 128 PID filters are shared between the four devices.
>
> Regards,
> Andreas
>
> George Joseph wrote:
>> Hello All,
>>
>>  I am new to the list. I am currently working on a dm7025 platform and
>> would like to know if there is a possibillity to use the 128 pid filters
>> on the xilleon 226. currently I see only /dev/dvb/adaptor0/demux0-3 in
>> my
>> device directory - i,e; at a point in time I can use only 4 tpid filters
>> from the 128 available at hardware level.
>>
>>
>> Cheers,
>> Warm regs,
>> G.
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-media"
>> in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>

Re:

[Andreas Oberritter]

George Joseph wrote:
> Thanks Andreas, That answers my question. I am using a tree I checkd out 3
> months ago. I used the DEMUX_SET_SOURCE API to set the ts feed to the
> tuner. Is this explicity done on Linux DVB 3?

By default, all demux devices are connected to the first frontend slot
of the DM7025. You can use DMX_SET_SOURCE to connect a demux to a
specific slot.

Regards,
Andreas

RE:

[hamiltonss]

I am a foreign Investor, I want to invest in your country and I am writting to seek your assistance in starting a business investment in your country and execute a business investment under your management. If you can assist me in receiving my money and investing it in your country e-mail me with your telephone number so I can explain to you more better and give you further information. My E-mail is -  frankingxs@msn.com    

Re:

[Pavel Valach]

Please, delete this empty topic, I only wanted help how to post, now I know it.