Home
last modified time | relevance | path

Searched full:seems (Results 1 – 25 of 1849) sorted by relevance

12345678910>>...74

/openbmc/linux/drivers/clk/mstar/
H A Dclk-msc313-cpupll.c17 * 0x140 -- LPF low. Seems to store one half of the clock transition
19 * 0x148 -- LPF high. Seems to store one half of the clock transition
25 * 0x164 -- vendor code says "from low to high" which seems to mean transition from LPF low to
27 * 0x174 -- Seems to be the PLL lock status bit
28 * 0x180 -- Seems to be the current frequency, this might need to be populated by software?
31 * Frequency seems to be calculated like this:
/openbmc/linux/drivers/hid/
H A Dhid-thrustmaster.c54 * @TODO The TMX seems to require multiple control codes to switch.
89 * Seems to be the type of packet
100 * Seems to be the model code of the wheel
205 …// The wheel seems to kill himself before answering the host and therefore is violating the USB pr… in thrustmaster_change_handler()
209 hid_warn(hdev, "URB to change wheel mode seems to have failed with error %d\n", urb->status); in thrustmaster_change_handler()
214 * to get [what it seems to be] the wheel's model.
286 * finally send an USB CONTROL REQUEST to the wheel to get [what it seems to be] its
/openbmc/linux/drivers/accessibility/speakup/
H A DTODO11 It seems to only happen on SMP systems. It seems that text in the output buffer
/openbmc/linux/drivers/gpu/drm/msm/
H A DNOTES5 + MDP3 - ?? seems to be what is on geeksphone peak device
21 seems like we can do some clever tricks like use GPU to trigger
74 seems that access to such docs would prevent me from working on the
/openbmc/openbmc/poky/meta/recipes-devtools/libtool/libtool/
H A D0008-libtool-Avoid-relinking-when-cross-compiling-its-poi.patch17 This patch also removes an annoying "seems to be moved" warning
118 - func_warning "'$deplib' seems to be moved"
120 + # func_warning "'$deplib' seems to be moved"
/openbmc/linux/arch/m68k/include/asm/
H A Dmac_psc.h25 * not understood as there seems to be only one input and one output buffer
42 * set only seems to handle four interrupts instead of seven.
124 * seems to appear in both the input
149 * seems to clobber the control register.
/openbmc/linux/arch/arm/mach-omap2/
H A Dclockdomains81xx_data.c19 * Note that 814x seems to have HWSUP_SWSUP for many clockdomains
22 * seems to have the related ifdef the wrong way around claiming
24 * HWSUP for ALWON_L3_FAST as that seems to be supported for both
/openbmc/linux/Documentation/i2c/busses/
H A Di2c-nforce2.rst22 not publicly available, but seems to be similar to the
49 The SMBus adapter in the nForce2 chipset seems to be very similar to the
/openbmc/openbmc/meta-openembedded/meta-oe/recipes-benchmark/cpuburn/cpuburn-arm/
H A D0001-cpuburn-a8.S-Remove-.func-.endfunc.patch41 /* 16 seems to be a good choice */
58 /* 64 seems to be a good choice */
/openbmc/linux/Documentation/maintainer/
H A Dmodifying-patches.rst15 about this, it seems like prepending the description with your mail and/or
29 Special note to back-porters: It seems to be a common and useful practice
/openbmc/qemu/include/hw/char/
H A Dstm32f2xx_usart.h41 * NB: The reset value mentioned in "24.6.1 Status register" seems bogus.
42 * Looking at "Table 98 USART register map and reset values", it seems it
/openbmc/linux/scripts/coccinelle/misc/
H A Dcond_no_effect.cocci8 // Unfortunately there also seems to be a tendency to use
11 // on kernelnewbies though it seems that this is not really an
/openbmc/linux/arch/hexagon/include/asm/
H A Dthread_info.h38 * seems to have a function pointer and four arguments
44 * not sure if this is used (it's not in the VM model it seems;
/openbmc/linux/drivers/iio/imu/bno055/
H A Dbno055_ser_core.c76 * Serial communication seems very fragile: the BNO055 buffer seems to overflow
77 * very easy; BNO055 seems able to sink few bytes, then it needs a brief pause.
112 * We have to take into account also IMU response time - IMU seems to be often
113 * reasonably quick to respond, but sometimes it seems to be in some "critical
351 * seems consistent with itself; if we got an unexpected in bno055_ser_handle_rx()
/openbmc/linux/Documentation/scsi/
H A Dqlogicfas.rst77 I noticed my system which seems to work 100% would fail this test if
79 cables, and more devices on the SCSI bus. What seems to happen is
/openbmc/u-boot/arch/arm/include/asm/arch-sunxi/
H A Ddram_sun50i_h6.h54 * The DRAM controller in Allwinner A23/A80 SoCs and NXP i.MX7 SoCs seems
150 * By comparing the hardware and the ZynqMP manual, the PGSR seems
158 * but they're tagged "Type B PLL Only" and H6 seems to have
160 * 0x080 is not present in ZynqMP reference but it seems to be
H A Dtve.h23 * than the removed vga out capability the tvencoder seems to be the same.
37 u32 unknown1; /* 0x024, seems to be 1 byte per dac */
/openbmc/u-boot/board/toradex/apalis-tk1/
H A Das3722_init.c90 * NOTE: We do this early because doing it later seems to hose the CPU in pmic_enable_cpu_vdd()
106 * NOTE: We do this early because doing it later seems to hose the CPU in pmic_enable_cpu_vdd()
/openbmc/linux/drivers/gpu/drm/ci/xfails/
H A Damdgpu-stoney-skips.txt1 # Suspend to RAM seems to be broken on this machine
H A Di915-glk-skips.txt1 # Suspend to RAM seems to be broken on this machine
H A Di915-amly-skips.txt1 # Suspend to RAM seems to be broken on this machine
H A Di915-kbl-skips.txt1 # Suspend to RAM seems to be broken on this machine
H A Drockchip-rk3399-skips.txt1 # Suspend to RAM seems to be broken on this machine
/openbmc/linux/Documentation/fb/
H A Dsstfb.rst13 combinations and it seems that it works.
167 - the driver don't detect the 4Mb frame buffer voodoos, it seems that
172 [Actually from inspection it seems to be safe - Alan]
/openbmc/u-boot/drivers/net/phy/
H A Dmeson-gxl.c21 * - Late failures: MII_LPA is filled with a value which seems to make sense
22 * but it actually is not what the LP is advertising. It seems that we

12345678910>>...74