| /linux-6.12.1/drivers/crypto/tegra/ ! |
| D | tegra-se-main.c | 15 #include "tegra-se.h"
121 static struct tegra_se_cmdbuf *tegra_se_host1x_bo_alloc(struct tegra_se *se, ssize_t size) in tegra_se_host1x_bo_alloc() argument
124 struct device *dev = se->dev->parent; in tegra_se_host1x_bo_alloc()
144 int tegra_se_host1x_submit(struct tegra_se *se, u32 size) in tegra_se_host1x_submit() argument
149 job = host1x_job_alloc(se->channel, 1, 0, true); in tegra_se_host1x_submit()
151 dev_err(se->dev, "failed to allocate host1x job\n"); in tegra_se_host1x_submit()
155 job->syncpt = host1x_syncpt_get(se->syncpt); in tegra_se_host1x_submit()
157 job->client = &se->client; in tegra_se_host1x_submit()
158 job->class = se->client.class; in tegra_se_host1x_submit()
160 job->engine_fallback_streamid = se->stream_id; in tegra_se_host1x_submit()
[all …]
|
| D | tegra-se-aes.c | 23 #include "tegra-se.h"
26 struct tegra_se *se; member
43 struct tegra_se *se; member
67 struct tegra_se *se; member
206 struct tegra_se *se = ctx->se; in tegra_aes_prep_cmd() local
207 u32 *cpuvaddr = se->cmdbuf->addr; in tegra_aes_prep_cmd()
222 cpuvaddr[i++] = se_host1x_opcode_incr_w(se->hw->regs->linear_ctr); in tegra_aes_prep_cmd()
227 cpuvaddr[i++] = se_host1x_opcode_nonincr(se->hw->regs->last_blk, 1); in tegra_aes_prep_cmd()
231 cpuvaddr[i++] = se_host1x_opcode_incr(se->hw->regs->config, 6); in tegra_aes_prep_cmd()
244 cpuvaddr[i++] = se_host1x_opcode_nonincr(se->hw->regs->op, 1); in tegra_aes_prep_cmd()
[all …]
|
| D | tegra-se-key.c | 11 #include "tegra-se.h"
51 static unsigned int tegra_key_prep_ins_cmd(struct tegra_se *se, u32 *cpuvaddr, in tegra_key_prep_ins_cmd() argument
57 cpuvaddr[i++] = se_host1x_opcode_incr_w(se->hw->regs->op); in tegra_key_prep_ins_cmd()
61 cpuvaddr[i++] = se_host1x_opcode_incr_w(se->hw->regs->manifest); in tegra_key_prep_ins_cmd()
62 cpuvaddr[i++] = se->manifest(se->owner, alg, keylen); in tegra_key_prep_ins_cmd()
64 cpuvaddr[i++] = se_host1x_opcode_incr_w(se->hw->regs->key_dst); in tegra_key_prep_ins_cmd()
71 cpuvaddr[i++] = se_host1x_opcode_incr_w(se->hw->regs->key_addr); in tegra_key_prep_ins_cmd()
76 cpuvaddr[i++] = se_host1x_opcode_incr_w(se->hw->regs->key_data); in tegra_key_prep_ins_cmd()
81 cpuvaddr[i++] = se_host1x_opcode_incr_w(se->hw->regs->config); in tegra_key_prep_ins_cmd()
85 cpuvaddr[i++] = se_host1x_opcode_incr_w(se->hw->regs->op); in tegra_key_prep_ins_cmd()
[all …]
|
| D | tegra-se-hash.c | 22 #include "tegra-se.h"
25 struct tegra_se *se; member
214 static int tegra_sha_prep_cmd(struct tegra_se *se, u32 *cpuvaddr, in tegra_sha_prep_cmd() argument
274 host1x_uclass_incr_syncpt_indx_f(se->syncpt_id); in tegra_sha_prep_cmd()
276 dev_dbg(se->dev, "msg len %llu msg left %llu cfg %#x", in tegra_sha_prep_cmd()
282 static void tegra_sha_copy_hash_result(struct tegra_se *se, struct tegra_sha_reqctx *rctx) in tegra_sha_copy_hash_result() argument
287 rctx->result[i] = readl(se->base + se->hw->regs->result + (i * 4)); in tegra_sha_copy_hash_result()
290 static void tegra_sha_paste_hash_result(struct tegra_se *se, struct tegra_sha_reqctx *rctx) in tegra_sha_paste_hash_result() argument
296 se->base + se->hw->regs->result + (i * 4)); in tegra_sha_paste_hash_result()
304 u32 *cpuvaddr = ctx->se->cmdbuf->addr; in tegra_sha_do_update()
[all …]
|
| D | Makefile | 4 tegra-se-objs := tegra-se-key.o tegra-se-main.o
6 tegra-se-y += tegra-se-aes.o
7 tegra-se-y += tegra-se-hash.o
9 obj-$(CONFIG_CRYPTO_DEV_TEGRA) += tegra-se.o
|
| /linux-6.12.1/drivers/soc/qcom/ ! |
| D | qcom-geni-se.c | 17 #include <linux/soc/qcom/geni-se.h>
22 * Generic Interface (GENI) Serial Engine (SE) Wrapper driver is introduced
36 * determined by the firmware loaded to the serial engine. Each SE consists
44 * --QUP & SE Clocks--> | Serial Engine N | +-IO------>
54 * <------SE IRQ------+ +----------------------------+ |
70 * GENI SE Wrapper driver is structured into 2 parts:
115 /* Common SE registers */
191 * @se: Pointer to the corresponding serial engine.
195 u32 geni_se_get_qup_hw_version(struct geni_se *se) in geni_se_get_qup_hw_version() argument
197 struct geni_wrapper *wrapper = se->wrapper; in geni_se_get_qup_hw_version()
[all …]
|
| /linux-6.12.1/drivers/i2c/busses/ ! |
| D | i2c-qcom-geni.c | 17 #include <linux/soc/qcom/geni-se.h>
81 struct geni_se se; member
174 writel_relaxed(0, gi2c->se.base + SE_GENI_CLK_SEL); in qcom_geni_i2c_conf()
177 writel_relaxed(val, gi2c->se.base + GENI_SER_M_CLK_CFG); in qcom_geni_i2c_conf()
182 writel_relaxed(val, gi2c->se.base + SE_I2C_SCL_COUNTERS); in qcom_geni_i2c_conf()
187 u32 m_cmd = readl_relaxed(gi2c->se.base + SE_GENI_M_CMD0); in geni_i2c_err_misc()
188 u32 m_stat = readl_relaxed(gi2c->se.base + SE_GENI_M_IRQ_STATUS); in geni_i2c_err_misc()
189 u32 geni_s = readl_relaxed(gi2c->se.base + SE_GENI_STATUS); in geni_i2c_err_misc()
190 u32 geni_ios = readl_relaxed(gi2c->se.base + SE_GENI_IOS); in geni_i2c_err_misc()
191 u32 dma = readl_relaxed(gi2c->se.base + SE_GENI_DMA_MODE_EN); in geni_i2c_err_misc()
[all …]
|
| /linux-6.12.1/include/linux/soc/qcom/ ! |
| D | geni-se.h | 15 * @GENI_SE_FIFO: FIFO mode. Data is transferred with SE FIFO
18 * with SE by DMAengine internal to SE
63 * @icc_paths: Array of ICC paths for SE
75 /* Common SE registers */
296 /* QUP SE VERSION value for major number 2 and minor number 5 */
316 u32 geni_se_get_qup_hw_version(struct geni_se *se);
320 * @se: Pointer to the concerned serial engine.
324 static inline u32 geni_se_read_proto(struct geni_se *se) in geni_se_read_proto() argument
328 val = readl_relaxed(se->base + GENI_FW_REVISION_RO); in geni_se_read_proto()
335 * @se: Pointer to the concerned serial engine.
[all …]
|
| /linux-6.12.1/Documentation/translations/sp_SP/process/ ! |
| D | 2.Process.rst | 16 problemas. Se requiere una comprensión solida de cómo funciona el proceso
25 lanzamientos se ve así:
43 Se sigue una disciplina relativamente sencilla con respecto a la fusión
45 se dice que la "merge window" (ventana de fusión) está abierta. En ese
46 momento, el código que se considera lo suficientemente estable (y que es
47 aceptado por la comunidad de desarrollo) se fusiona en el kernel mainline.
49 los cambios principales) se fusionarán durante este tiempo, a un ritmo
55 y montados con anticipación. Como funciona ese proceso se describirá en
61 ejemplo, el lanzamiento al final de la ventana de fusión se llamará
67 problemas deben enviarse al mainline. En ocasiones, se permitirá un cambio
[all …]
|
| D | maintainer-kvm-x86.rst | 11 KVM se esfuerza por ser una comunidad acogedora; las contribuciones de los
12 recién llegados son valoradas e incentivadas. Por favor, no se desanime ni
13 se sienta intimidado por la extensión de este documento y las numerosas
27 KVM x86 se encuentra actualmente en un período de transición de ser parte
33 Por lo general, las correcciones para el ciclo en curso se aplican
35 para el siguiente ciclo se dirige a través del árbol de KVM x86. En el
36 improbable caso de que una corrección para el ciclo actual se dirija a
37 través del árbol KVM x86, se aplicará a la rama ``fixes`` antes de llegar
40 Tenga en cuenta que se espera que este periodo de transición dure bastante
53 Todas las ramas temáticas, excepto ``next`` y ``fixes``, se agrupan en
[all …]
|
| D | 1.Intro.rst | 25 (merge window). Se cubren las distintas fases en el desarrollo del parche,
27 herramientas y listas de correo. Se anima a los desarrolladores que deseen
35 :ref:`sp_development_coding` trata sobre el proceso de codificación. Se
36 discuten varios escollos encontrados por otros desarrolladores. Se cubren
51 etapa. Se advierte a los desarrolladores que no asuman que el trabajo está
52 terminado cuando un parche se fusiona en mainline.
68 del sistema operativo que se ejecuta en reproductores de música digital
83 cambiar Linux para que se adapte mejor a sus necesidades.
101 se cambian todos los días. Por lo tanto, no es sorprendente que el
111 aprender, tiene poco tiempo para aquellos que no escuchan o que no se
[all …]
|
| D | handling-regressions.rst | 24 * Cuando se reciba un correo que no incluyó a la lista, inclúyalo en la
42 * Cuando se mandan informes desde un gestor de incidentes a la lista de
49 #. Cuando se manden correcciones para las regresiones, añadir etiquetas
50 "Link:" a la descripción, apuntado a todos los sitios donde se informó
51 del incidente, como se indica en el documento:
66 Qué hacer cuando se recibe un aviso de regresión.
74 * Cuando se recibe un informe por email que no tiene en CC la lista,
83 anteriormente, como se indica en:
86 Cuando se realice cualquiera de las acciones anteriores, considere
90 * Para los informes enviados por email, verificar si se ha incluido un
[all …]
|
| D | howto.rst | 18 este archivo, que se encuentra en la parte superior del documento.
43 bien se adhiere al estándar ISO C89, utiliza una serie de extensiones que
56 largo del tiempo en función de lo que se ha encontrado que funciona mejor
59 que están bien documentados; no espere que la gente se adapte a usted o a
64 El código fuente del kernel de Linux se publica bajo licencia GPL. Por
79 comunidad del kernel. Cuando se agregan nuevas funciones al kernel, se
80 recomienda que se incluyan nuevos archivos de documentación que expliquen
82 que el kernel expone espacio de usuario cambie, se recomienda que envíe la
101 razones detrás de esto. Se espera que todo el código nuevo siga las
103 aceptarán parches si se siguen estas reglas, y muchas personas solo
[all …]
|
| D | researcher-guidelines.rst | 11 en su producción, otros subproductos de su desarrollo. Linux se
19 de Linux para mejorar a partir de ella. En cualquier caso, se recomienda
43 La investigación pasiva que se basa completamente en fuentes disponibles
46 Aunque, como con cualquier investigación, todavía se debe seguir la ética
51 completa a los desarrolladores individuales involucrados. No se puede
57 en buena fe. No se ha dado consentimiento para enviar parches intencionalmente
69 cuando se trata de desarrollar o ejecutar herramientas de análisis que
72 Cuando se interactúa con la comunidad de desarrolladores, enviar un
87 * ¿Cuál es el problema específico que se ha encontrado?
90 * ¿Como se encontró el problema? Incluya específicamente detalles sobre
[all …]
|
| D | deprecated.rst | 17 han de ir creándose en el kernel, mientras que las antiguas se quitan,
38 "imposibles" tan elegantemente como se pueda. Mientras que la familia de
42 "¿en qué orden se necesitan liberar los locks? ¿Se han restaurado sus
51 en situaciones que se "esperan no sean alcanzables". Si se quiere
64 que se realicen reservas de memoria menores que las que se esperaban. El
69 como se sugiere a continuación para evitar las operaciones aritméticas en
83 Si no existen funciones con dos argumentos, utilice las funciones que se
98 .. note:: Si se usa struct_size() en una estructura que contiene un elemento
137 es la función strscpy(), aunque se ha de tener cuidado con cualquier caso
140 compilados (o el valor negativo de errno cuando se trunca la cadena de
[all …]
|
| D | submitting-patches.rst | 12 el proceso puede en ocasiones resultar desalentador si no se está
14 que pueden aumentar considerablemente las posibilidades de que se acepte su
40 que se puede descargar con::
64 evidentes. Incluso si se detectó un problema durante la revisión del
78 CPU, memoria y legibilidad; o, cuando se trata de heurísticas, entre
85 lenguaje sencillo para que el revisor verifique que el código se está
86 comportando como se pretende.
89 formato que se pueda incorporar fácilmente en la gestión del código fuente
98 descripción completa del parche y justificación del mismo. No se limite a
112 Si desea hacer referencia a un commit específico, no se limite a hacer
[all …]
|
| /linux-6.12.1/sound/soc/codecs/ ! |
| D | pcm186x.c | 69 "VINL1[SE]", /* Default for ADC1L */
70 "VINL2[SE]", /* Default for ADC2L */
71 "VINL2[SE] + VINL1[SE]",
72 "VINL3[SE]",
73 "VINL3[SE] + VINL1[SE]",
74 "VINL3[SE] + VINL2[SE]",
75 "VINL3[SE] + VINL2[SE] + VINL1[SE]",
76 "VINL4[SE]",
77 "VINL4[SE] + VINL1[SE]",
78 "VINL4[SE] + VINL2[SE]",
[all …]
|
| /linux-6.12.1/drivers/spi/ ! |
| D | spi-geni-qcom.c | 16 #include <linux/soc/qcom/geni-se.h>
20 /* SPI SE specific registers and respective register fields */
79 struct geni_se se; member
108 struct geni_se *se = &mas->se; in spi_slv_setup() local
110 writel(SPI_SLAVE_EN, se->base + SE_SPI_SLAVE_EN); in spi_slv_setup()
111 writel(GENI_IO_MUX_0_EN, se->base + GENI_OUTPUT_CTRL); in spi_slv_setup()
112 writel(START_TRIGGER, se->base + SE_GENI_CFG_SEQ_START); in spi_slv_setup()
125 ret = geni_se_clk_freq_match(&mas->se, in get_spi_clk_cfg()
153 struct geni_se *se = &mas->se; in handle_se_timeout() local
158 writel(0, se->base + SE_GENI_TX_WATERMARK_REG); in handle_se_timeout()
[all …]
|
| /linux-6.12.1/Documentation/translations/sp_SP/scheduler/ ! |
| D | sched-design-CFS.rst | 18 del previo gestor de tareas SCHED_OTHER. Hoy en día se está abriendo camino
19 para el gestor de tareas EEVDF, cuya documentación se puede ver en
30 como si se ejecutaran en paralelo.
32 En hardware real, se puede ejecutar una única tarea a la vez, así que
33 se ha usado el concepto de "tiempo de ejecución virtual". El tiempo
44 En CFS, el tiempo de ejecución virtual se expresa y se monitoriza por
45 cada tarea, en su valor de p->se.vruntime (en unidades de nanosegundos).
50 tareas pueden tener el mismo valor de p->se.vruntime --- i.e., tareas
51 se podrían ejecutar simultáneamente y ninguna tarea podría escaparse del
54 La lógica de elección del tareas de CFS se basa en el valor de p->se.vruntime
[all …]
|
| /linux-6.12.1/Documentation/scsi/ ! |
| D | aic7xxx.rst | 63 AHA-274X[A] aic7770 EISA SE-50M SE-HD50F
64 AHA-274X[A]W aic7770 EISA SE-HD68F SE-HD68F
65 SE-50M
66 AHA-274X[A]T aic7770 EISA 2 X SE-50M SE-HD50F
67 AHA-2842 aic7770 VL SE-50M SE-HD50F
68 AHA-2940AU aic7860 PCI/32 SE-50M SE-HD50F
69 AVA-2902I aic7860 PCI/32 SE-50M
70 AVA-2902E aic7860 PCI/32 SE-50M
71 AVA-2906 aic7856 PCI/32 SE-50M SE-DB25F
72 APC-7850 aic7850 PCI/32 SE-50M 1
[all …]
|
| /linux-6.12.1/kernel/sched/ ! |
| D | fair.c | 289 static inline u64 calc_delta_fair(u64 delta, struct sched_entity *se) in calc_delta_fair() argument
291 if (unlikely(se->load.weight != NICE_0_LOAD)) in calc_delta_fair()
292 delta = __calc_delta(delta, NICE_0_LOAD, &se->load); in calc_delta_fair()
306 #define for_each_sched_entity(se) \ argument
307 for (; se; se = se->parent)
409 is_same_group(struct sched_entity *se, struct sched_entity *pse) in is_same_group() argument
411 if (se->cfs_rq == pse->cfs_rq) in is_same_group()
412 return se->cfs_rq; in is_same_group()
417 static inline struct sched_entity *parent_entity(const struct sched_entity *se) in parent_entity() argument
419 return se->parent; in parent_entity()
[all …]
|
| /linux-6.12.1/arch/sh/tools/ ! |
| D | mach-types | 8 SE SH_SOLUTION_ENGINE
22 7206SE SH_7206_SOLUTION_ENGINE
23 7343SE SH_7343_SOLUTION_ENGINE
24 7619SE SH_7619_SOLUTION_ENGINE
25 7721SE SH_7721_SOLUTION_ENGINE
26 7722SE SH_7722_SOLUTION_ENGINE
27 7724SE SH_7724_SOLUTION_ENGINE
28 7751SE SH_7751_SOLUTION_ENGINE
29 7780SE SH_7780_SOLUTION_ENGINE
|
| /linux-6.12.1/Documentation/translations/it_IT/process/ ! |
| D | 6.Followthrough.rst | 36 resa molto più facile se tenete presente alcuni dettagli:
38 - Se avete descritto la vostra modifica correttamente, i revisori ne
51 fatti ancora e ancora. Se ricevete una revisione che vi sembra abbia
75 comunicarvi. Se possibile, sistemate le cose che il revisore vi chiede di
80 suggerita dai revisori. Se credete che il revisore non abbia compreso
81 il vostro codice, spiegateglielo. Se avete un'obiezione tecnica da fargli
83 al problema. Se la vostra spiegazione ha senso, il revisore la accetterà.
85 specialmente se altri iniziano ad essere d'accordo con il revisore.
97 che se ne andranno. Non andranno via. Se pubblicherete nuovamente il
106 famigliarizzare con ciò che è stato detto l'ultima volta; se li aiutate
[all …]
|
| /linux-6.12.1/drivers/gpu/drm/v3d/ ! |
| D | v3d_submit.c | 160 u32 in_sync, struct v3d_submit_ext *se, enum v3d_queue queue) in v3d_job_init() argument
163 bool has_multisync = se && (se->flags & DRM_V3D_EXT_ID_MULTI_SYNC); in v3d_job_init()
176 if (se->in_sync_count && se->wait_stage == queue) { in v3d_job_init()
177 struct drm_v3d_sem __user *handle = u64_to_user_ptr(se->in_syncs); in v3d_job_init()
179 for (i = 0; i < se->in_sync_count; i++) { in v3d_job_init()
229 struct v3d_submit_ext *se, in v3d_attach_fences_and_unlock_reservation() argument
233 bool has_multisync = se && (se->flags & DRM_V3D_EXT_ID_MULTI_SYNC); in v3d_attach_fences_and_unlock_reservation()
256 if (se->out_sync_count) { in v3d_attach_fences_and_unlock_reservation()
257 for (i = 0; i < se->out_sync_count; i++) { in v3d_attach_fences_and_unlock_reservation()
258 drm_syncobj_replace_fence(se->out_syncs[i].syncobj, in v3d_attach_fences_and_unlock_reservation()
[all …]
|
| /linux-6.12.1/Documentation/translations/sp_SP/ ! |
| D | memory-barriers.txt | 44 (1) especificar la funcionalidad mínima en la que se puede confiar para
69 - ¿Qué no se puede asumir sobre las barreras de memoria?
93 (*) ¿Dónde se necesitan barreras de memoria?
172 El conjunto de accesos visto por el sistema de memoria en el medio se puede
221 de ubicaciones de memoria, pero el orden en que se accede a los registros
223 un conjunto de registros a los que se accede a través de un registro de
236 ya que se estableció la dirección _después_ de intentar leer el registro.
242 Hay algunas garantías mínimas que se pueden esperar de una CPU:
244 (*) En cualquier CPU dada, los accesos a la memoria dependiente se
281 (Los loads y stores se superponen si están destinados a piezas
[all …]
|