similar to: i2c bus access

On Thu, 2014-02-27 at 11:49 -0800, H. Peter Anvin wrote: > On 02/27/2014 07:51 AM, Jo?o Henrique Freitas wrote: > > Hi, > > > > I have a particular situation that syslinux could access a i2c bus to get > > some data from specific device that my hardware has. Based on these data, > > syslinux should or not to boot. > > > > It's feasible to create

Am 27.02.2014 20:49, schrieb H. Peter Anvin: > I2C can be provided through an almost infinite number of controllers, > and building an I2C subsystem in Syslinux would be a good step toward > making it a fullblown operating system. Why not use linux as bootloader? Booting a (rather small) linux kernel with I?C support and either shutting down or kexecing another linux kernel (plus

Hi, Yes, probably using syslinux as 1st stage bootloader and a small linux (and this [1]) as 2nd stage boot will be a quite good solution. A bit more explanation about my needs: my custom hardware has a i2c controller over PCIe bus. We are using Intel Atom (with EG20T hub). I think that is not so simple to create a solid i2c framework inside syslinux to do it. Even thought I will need i2c to

On 02/27/2014 07:51 AM, Jo?o Henrique Freitas wrote: > Hi, > > I have a particular situation that syslinux could access a i2c bus to get > some data from specific device that my hardware has. Based on these data, > syslinux should or not to boot. > > It's feasible to create some i2c infraestructure to syslinux access i2c > bus? It could be used to something more than

Am 28.02.2014 12:11, schrieb Jo?o Henrique Freitas: > Based on the above I will get the Mattias idea. > > Thanks a lot. > > [1] > https://www.kernel.org/pub/linux/kernel/people/geoff/petitboot/petitboot.html Petitboot seems to "Grand" for this purpose. kexec is so simple if you put the kernel and initramfs you want to boot into the initramfs used to test your

mhh, we shouldn't call to Linux APIs from within of nvkm. Rather gaurd the Linux glue code to the i2c stuff instead, but this is all done from inside of nvkm. I think we should move it out into drm/nouveau/nouveau_i2c.c and do the handling there. On Tue, Jul 17, 2018 at 1:59 AM, Lyude Paul <lyude at redhat.com> wrote: > The i2c bus can be both accessed by DRM itself, along with any

On Thu, 2019-04-11 at 08:48 +1000, Ben Skeggs wrote: > On Wed, 10 Apr 2019 at 06:23, Lyude Paul <lyude at redhat.com> wrote: > > For a while, we've had the problem of i2c bus access not grabbing > > a runtime PM ref when it's being used in userspace by i2c-dev, resulting > > in nouveau spamming the kernel log with errors if anything attempts to > > access

On 02/28/2014 03:11 AM, Jo?o Henrique Freitas wrote: > Hi, > > Yes, probably using syslinux as 1st stage bootloader and a small linux (and > this [1]) as 2nd stage boot will be a quite good solution. > > A bit more explanation about my needs: my custom hardware has a i2c > controller over PCIe bus. We are using Intel Atom (with EG20T hub). I think > that is not so simple

For a while, we've had the problem of i2c bus access not grabbing a runtime PM ref when it's being used in userspace by i2c-dev, resulting in nouveau spamming the kernel log with errors if anything attempts to access the i2c bus while the GPU is in runtime suspend. An example: [ 130.078386] nouveau 0000:01:00.0: i2c: aux 000d: begin idle timeout ffffffff Since the GPU is in runtime

Hello there! I'm working on some modifications on Asterisk to adapt it to our needs considering some particular demandings of the infraestructure we want to provide. Two of these modifications are: 1- A proprietary configuration driver that will communicate with a server that will be the source of information for the entire infraestructure; and, 2- A call control application that will be

On 2020/9/3 14:12, Jason Wang wrote: > > On 2020/9/3 ??1:34, Jie Deng wrote: >> Add an I2C bus driver for virtio para-virtualization. >> >> The controller can be emulated by the backend driver in >> any device model software by following the virtio protocol. >> >> This driver communicates with the backend driver through a >> virtio I2C message

On Tue, 17 Jul 2018 at 20:18, Karol Herbst <kherbst at redhat.com> wrote: > > mhh, we shouldn't call to Linux APIs from within of nvkm. Rather gaurd > the Linux glue code to the i2c stuff instead, but this is all done > from inside of nvkm. I think we should move it out into > drm/nouveau/nouveau_i2c.c and do the handling there. Huh? No, this is completely fine. >

The i2c bus can be both accessed by DRM itself, along with any of it's devnodes (/sys/class/i2c). So, we need to make sure that all codepaths using the i2c bus keep the GPU resumed. Signed-off-by: Lyude Paul <lyude at redhat.com> Cc: Karol Herbst <karolherbst at gmail.com> Cc: stable at vger.kernel.org --- drivers/gpu/drm/nouveau/nvkm/subdev/i2c/bus.c | 12 +++++++++++- 1 file

Signed-off-by: Viktor Novotny <noviktor at seznam.cz> --- Hi, I think I found a bug - my NV11 fails to init i2c ports and is then unable to read EDID. It's because while i2c_table in nouveau_i2c.c:324 returns null for this card, i2c is initialized anyway at line 341 and wrong i2c table format is then selected at line 350. This patch fixes the problem on NV11 and was tested also on NV25.

For a while, we've had the problem of i2c bus access not grabbing a runtime PM ref when it's being used in userspace by i2c-dev, resulting in nouveau spamming the kernel log with errors if anything attempts to access the i2c bus while the GPU is in runtime suspend. An example: [ 130.078386] nouveau 0000:01:00.0: i2c: aux 000d: begin idle timeout ffffffff Since the GPU is in runtime

Fix typo introduced when converting to core infrastructure. Signed-off-by: Dmitry Eremin-Solenikov <dmitry_eremin at mentor.com> --- drivers/gpu/drm/nouveau/core/subdev/bios/i2c.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/nouveau/core/subdev/bios/i2c.c b/drivers/gpu/drm/nouveau/core/subdev/bios/i2c.c index 5fcce5d..ad577db 100644 ---

On 2020/9/4 12:06, Jason Wang wrote: > >> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig >> index 293e7a0..70c8e30 100644 >> --- a/drivers/i2c/busses/Kconfig >> +++ b/drivers/i2c/busses/Kconfig >> @@ -21,6 +21,17 @@ config I2C_ALI1535 >> ??????? This driver can also be built as a module.? If so, the module >> ??????? will be called

On 2020/9/4 12:06, Jason Wang wrote: > >> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig >> index 293e7a0..70c8e30 100644 >> --- a/drivers/i2c/busses/Kconfig >> +++ b/drivers/i2c/busses/Kconfig >> @@ -21,6 +21,17 @@ config I2C_ALI1535 >> ??????? This driver can also be built as a module.? If so, the module >> ??????? will be called

This is another attempt at fixing an issue with yes | sensors-detect Causing some machines with nouveau loaded to hang if certain kinds of displays are attached. I've also included one minor fix that I found along the way of troubleshooting this issue. Lyude Paul (2): drm/nouveau: Fix missing elses in g94_i2c_aux_xfer drm/nouveau: Don't retry infinitely when receiving no data on i2c

On Wed, 10 Apr 2019 at 06:23, Lyude Paul <lyude at redhat.com> wrote: > > For a while, we've had the problem of i2c bus access not grabbing > a runtime PM ref when it's being used in userspace by i2c-dev, resulting > in nouveau spamming the kernel log with errors if anything attempts to > access the i2c bus while the GPU is in runtime suspend. An example: > > [